Reads to me like the browser will check if the flag is present, and if not keep on going anyways (perhaps with a nag to the user that things are less secure than they could be).

what has always puzzled me about Chrome/Chromium, is that the latter do not come as easy to handle tar-balls.

If you want to compile it you have to download special tools, then aim those at their source repo to grab a tagged branch, and then compile from that the variant you want (said repo mix Chromium and ChromiumOS as best i can tell).

Sometimes i wonder if he confused magic with religion when formulating that last one.

Maybe i am old, but i kinda liked the autoexec.bat/config.sys duo. Open up two files, see exactly what the system was doing to get started. But then DOS booted fairly rapidly at the worst of times, thanks to not having a massive tree of interlocking processes that all needed to save state upon shutdown.

With roid rage.

With systemd a troubled boot seems to go from "it booted, but lack half the daemons" to "something in the dependency chain broke, here is a (buggy) emergency login, you're on your own" (the last bit systemd will actually state when presenting you with said login).

At that point you are better off hitting hardware reset and fire up the kernel with /bin/bash as init (not sure how friendly journald is about giving out anything without systemd running though).

Seriously, at one point that emergency login was found to be executing commands, as root, if they were typed into the password prompt.

It "is", if you treat your laptop like a oversized smartphone.

Fundamentally the "server" argument is not aimed at traditional (some would call it "pet") servers. It is aimed at cloud servers, like amazon's EC2 service. There being able to spin up 1000 extra "server" instances at the drop of a fedora is key.

Don't have a URL handy, but i think it may be a reference to systemd presenting the user with a emergency login prompt that would execute commands, as root no less, entered at the password prompt.

Want to try something new in init, go with openRC or similar projects that do init and init only.

One may wonder when Gnome will announce that the project will be renamed systemd-gnome, and the code of its projects will be merged with that of systemd.

Maybe at first. But by now it has outgrown launchd massively.

Launchd is nowhere near as sprawling as systemd.

Not surprising, given that the systemd talk is done by the head honcho himself. Do wonder what kind of bus factor he was within the project...

I have yet to figure out why this is such a big deal for everyone.

What kind of gordian knot of a boot up sequence does the daemon has that only the provider can do the init script properly?

Ship the binary, ship proper instructions, let the admin do his job.

Then again, half the supposed issues that the push to containerize everything "Linux" can be fixed by not having the package manager do dependencies.

This because it is Linux or the GNU toolchains that has issues with multiple lib versions (the major source of "dependency hell"), it is the package managers.

Both DEB and RPM balk at having libxyz-v1.0 and lubxyz-v1.1 installed at the same time (unless you do something fancy with the package names). Libtool don't care, as it has SONAME to keep track of the lib version that the binary wants.

But to "fix" this the clever boys behind systemd and Gome are planning to cram everything into containers so that each "app" can only see the libs it claims to need.

Dude that's a tweety bird you are trying to shoot down, not a B-52!