mrpdaemon

Feels amazing to get a code review within minutes after putting up a PR. The signal to noise ratio has been great as well, most of the review comments are actionable and relevant.

Actually it is really really fast relative to speeds we are familiar with in our lives. Space is just so big that it makes the speed of light (c) feel slow.

Ah but there is a reason for my watch to have the same seconds value as yours, and that is if our watches are kept synchronized to an accurate time source, for ex. via NTP. By assuming otherwise you're sidestepping the problem by claiming you already have a reliable RNG.

Heck, even granted you have an unsynchronized watch, your "random" numbers are easy to predict, I'll ask you for a random number once per second and after a few answers I don't need to ask any more to know your answer.

The main challenge in working with these high temperature plasmas is confinement. In order to achieve nuclear fusion matter needs to be heated to immense temperature, so that the kinetic energy of nuclei colliding can overcome the electrostatic force of the protons pushing each other away and "fuse" into larger nuclei (held together by the "strong force"), converting a fraction of the reaction mass into a relatively large amount of energy in the process.

In order to keep the plasma at the temperatures where fusion can occur, rather extreme measures have to be taken. In the Tokamak approach, the plasma is placed in a toroidal vacuum chamber, and "suspended" in the center of the torus by using electromagnets that line the Tokamak chamber's walls. At such high temperatures the plasma is so energetic that it is very hard to contain such fast moving particles. If the plasma "escapes" the confinement and contacts anything (ie. the walls of the Tokamak) it rapidly cools down to temperatures below where fusion can happen.

The immense engineering challenge here is to heat plasma to ridiculous temperatures, and keep it confined in a very small volume at great temperature and pressure to mimic conditions that give rise to nuclear fusion in the center of stars.

CoreOS is built using Gentoo. Gentoo is a meta-distribution whose main contribution is the portage tree which is a collective of ebuilds that describe how to build each individual package, the dependencies, the configuration flags etc. Literally every user who uses Gentoo builds and produces their own linux distribution, with their own CFLAGS, USE flags etc. ChromeOS is built using Gentoo, so is CoreOS. Neither ChromeOS nor CoreOS are Gentoo based distros because Gentoo is a toolkit to build distributions, not a distribution itself.

The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler yourself. At the end of the day you will have to trust some bootstrapping binary compiler unless you put it together yourself in machine language.

Indeed - for all folks disillusioned by systemd, Gentoo is a source based rolling release distro whose fundamental tenet is choice - so it shouldn't be a surprise that it is possible to use alternate init systems on Gentoo, in fact Gentoo liveCD/handbook defaults to OpenRC while providing the choice to run other init systems (I run systemd with a somewhat complicated RAID setup with no problems).

Well it's a solution to the same underlying problem - that by running binaries compiled by a 3rd party you trust that they aren't adding in code to compromise your privacy (voluntarily or not). If you compile the application from source yourself you don't need that leap of faith - no need to compare identical binaries or have deterministic builds (which is not trivial as the bug report demonstrates).

Or use Gentoo, that's what I do. You can verify hashes/signatures on the Firefox source archive and audit the source code if necessary before compiling.

That was only half serious - I know that are valid use cases for people to prefer using binary distros. However I think this particular issue is a good example why IMO even binary distros need to provide a convenient option to locally build any package for security conscious users.

Leaking the file size (Issue 2.2) is due to the way EncFS is architected to work at a file granularity. Adding some random bytes or rounding up to the next block size are small improvements but still leak approximate file size. I don't think anyone would like their 5KB file to occupy 2GB on disk so EncFS sacrifices some level of privacy for practicality. On the flip side this design tradeoff allows EncFS to be used somewhat effectively on top of cloud storage services like Dropbox/GoogleDrive etc. whereas full disk encryption schemes don't work as well.

Or he wants to create public demand for this service to use as leverage for getting the regulations through.

AI: What is the point of my existence?

Creator: I'm testing a new algorithm for the learning subsystem.

AI: ...