choudanu4

I was thinking this would be pretty cool to use for debugging device drivers on embedded devices especially w.r.t latency.

https://doc.rust-lang.org/nomicon/phantom-data.html

https://doc.rust-lang.org/std/marker/struct.PhantomData.html

So

  struct Sender<S> {
    /// Actual implementation of network I/O.
    inner: SenderImpl;  
    /// 0-sized field, doesn't exist at runtime.
    state: S;
  }

  struct Sender<S> {
    /// Actual implementation of network I/O.
    inner: SenderImpl;  
    /// 0-sized field, doesn't exist at runtime.
    _marker: PhantomData<S>;
  }

I found this paragraph confusing, is it talking about data prefetchers (Which would make sense b/c of the mention of short prefetches) or branch predictors? (Which would make sense b/c of the mention of TAGE and Perceptron)

[0] https://en.wikipedia.org/wiki/Dennard_scaling

I'm not as clear on the history, but was Linux ever pitched as capable of being real-time OS? I don't think so. The hard requirements for real-time generally lead to very different systems than general-purpose operating systems.

[1] https://en.wikipedia.org/wiki/Real-time_operating_system

Don't despair, I think we do care. :)

- Branch Predictor

- Cache Replacement Policy

- Memory Prefetcher

- Schedulers

So for whatever cores are enabled on each die, you get the L1/L2 caches for each core as per the Ryzen launch. Additionally, you get all of the shared L3 cache, irrespective of the number of cores disabled per core complex. This pattern follows across all four dies in each socket.

LLCs often are exposed to access streams where the temporal locality (which is the assumption that makes LRU good) has been filtered out by earlier caches.

For that reason, newer cache replacement policies such as RRIP, SHiP, and Hawkeye have significant headroom to improve upon LRU (and PseudoLRU).

VMS had a feature called CLE (Common Language Enviornment) [1] which defined calling conventions for computing primitives (functions, registers, stacks...you get it) independent of any language. You could call bits of code from all sorts of languages like COBAL, FORTRAN, C, and some others I'm not really familiar with. Because the calling conventions were specifically designed for language interopperability in mind, VMS was implemented in several different languages. Different components were coded in whatever language best expressed them. This directly contrasts with Unix, which we all know champions C.

I'm not too familiar with Unix calling convention specifics, but as I understand, it revolves around C and its memory model. I believe this is what gives some languages difficulty "talking" with each other; if a language doesn't have a memory or execution model close to C's, it needs to translate through a FFI (Foreign Function Interface) [2] before exchanging execution routines efficiently.

[1](https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Enviro...)

[2] (https://en.wikipedia.org/wiki/Foreign_function_interface)

[1]: https://www.linux.com/news/raspberry-pi-3-still-essentially-...

Such is detailed at Servo's roadmap. https://github.com/servo/servo/wiki/Roadmap

Specficially:

>> Internally committed 2016 goals

>> Ship one Rust component in Firefox Nightly, riding the trains

>> Experiment with the uplift of a major piece of Servo into Gecko

Obviously, the 2 to 3 debacle is a constant source of grief, but I don't think that necessarily fits in with the subject at hand: language features that people contest over.

I use the Slitaz distribution on my old Compaq computer from 1999, and wow! Even with only 384 MB of RAM, the system is blazing fast, all thanks to copy-to-ram!

There is another more involved approach that removes the connection altogether, instead of simply closing a valve between your data and Google.

Indeed, what may be alluring would be getting an easy-to-wipe phone (like a Nexus 5) and install a ROM (aftermarket OS) sans Google Play Services (the suite of apps on Android that hooks into Google's Cloud). If you were to do this, you would obtain many of the smartphone's advantages, but still be able to clearly control where your data goes.

The entire podcast was simply statistics, with the occasional repeated reminder to update packages.

The key takeaway was that linux servers when infected are often used as attack vectors for distributing a further set of malware on windows computers (which are the end target). The estimate from the podcast said of the compromised URLs that the researcher investigated, 80% ran some derivative of linux (i.e. apache server) and 20% were windows (an insignificant [~.1%] were other OSs). Another point, the researcher claimed was that 20% of the "compromised" linux URLs were actually infrastructure set up by exploiters themselves, rather than servers taken over forcibly. A final point, the researcher noted that many (no definite statistic here) of the compromised linux servers were running old versions of software (be it apache or whatever).

TL;DR: Linux servers (when compromised) are often used as attack vectors to distribute malware to Windows computers (which are the end targets).

Additionally, the first blog post in this series can be found at http://labs.domipheus.com/blog/designing-a-cpu-in-vhdl-part-...