All energy inevitably changes into heat eventually, and in the steady state, power in = power out.

There is no way to get rid of heat. It has to go somewhere; otherwise, the temperature of the system will increase without bound.

For example, why couldn't you use the waste heat like a power plant? Use it to boil water, to turn turbines, to generate electricity, which gets sent and consumed elsewhere? Adding to the heat wherever the electricity is finally consumed. (Ignoring various losses along the way).

“Elsewhere” is still somewhere on the Dyson sphere.

Or if you magically beam 100% of the captured energy somewhere else, now that place gets to deal with shedding the heat from however many 1e26W+ of power were consumed. God help the poor planet you aim that ray of death at.

At 15:00, she says "quantum computers are surprisingly good at [...] quantum simulations [of electron behavior]", which would seem to contradict you.

Now anybody with root/sudo/physical access to the remote machine has full R/W access to your entire home directory.

Well, what if it's a separate directory meant exclusively for remote systems alone? And what if the remote mount is read-only, perhaps with a writable layer on top using overlayfs that can be discarded on logout?

It's actually far less complex than what container runtimes do. I've even done parts of those, which is why I'm able to suggest it. I'm thinking about implementing it and was checking if anybody else wanted to do it or if they foresee any problems that I can't.

Are you trying to assure others or reassure yourself?

Same question can be asked to either side of this debate. We're all self-soothing apes, after all.

Just extrapolating a trend of the past few years. If you disagree, then carry on and time will tell.

Not even correct for a third party CA (unless they MITM you).

Not OP, and not a very experienced with NixOS (I just use Nix for building containers), but roughly speaking:

* With NixOS, you define the configuration for the entire system in one or a couple .nix files that import each other.

* You can very easily put these .nix files under version control and follow a convention of never leaving the system in a state where you have uncommitted changes.

* See the NixOS/infra repo for an example of managing multiple machines' configurations in a single repo: https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c...

Both of those things are true of running containers, no?

Enable 'showdead' in HN preferences. Clicking a direct link to the comment should work too: https://news.ycombinator.com/item?id=46171635

Thanks!

edit: a great read indeed

Only if you have a broken kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.

> Only if you have an old-style kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.

Fixed that for you. It used to be normal to use the device path (/dev/hd* or /dev/sd*) to reference the filesystem partitions. Using the UUID or the by-id symlink instead is a novelty, introduced precisely to fix these device enumeration order issues.

FTUE = First Time User Experience

G^n curvature solely depends on the geometry of the curve, while C^n continuity also depends on how you parameterize the curve. So, G^n is what you want if you're talking about a purely geometric shape rather than an (x(t), y(t)) trajectory.

* reference: section 2.1 of https://graphics.stanford.edu/courses/cs348a-21-winter/Reade...