The "all in/usr" comes out of the containerized web monkeys that is running the userspace Linux show these days...
What they do is they boot the "node" (aka computer) via a compressed boot image (initramfs), and then once that has set thing up, they just remount / read only to a SAN backend.
Hell, systemd is basically built around this being the expected way. This to the point that said boot image needs to get dbus up before handing things over to systemd loaded from/. Systemd will then use that for its early stuff before killing the boot image dbus, and starting a new one from/.
Observe how all of this is cooked up by the trifecta of Gnome, Freedesktop and Fedora, with most of the devs involved being on Red Hat payroll. Linux above the kernel has long since stopped being a community project, and become an extended arm of Red Hat.
The basic problem with deb, and rpm, and similar package manager, are that they get hung up on the package name and version.
Meaning that you can only have one version of a particular name installed at any one time.
Want to install another version? Either you remove the old version or you change the name to avoid a conflict. But changing the name plays havoc with the dependencies tracking.
If deb and/or rpm was changed so that the manager could handle tracking multiple versions of the same package name, the need for the likes of snappy, xdg-app, or a myriad of similar systems would not be needed.
You can see this if you check out NixOS/Guix or Gobolinux that have implemented slightly different solutions to the same problem.
Update to a recent Gnome and it will bellyache about logind, that in turn is part of system. End result, what used to be a desktop that can run on top of any init requires a specific init.
Moving forward i am expecting to see similar with their cron replacement, their networking and firewall stuff, etc etc etc.
This where before things would not care if you booted via sysv, openrc, upstart, bsd rc, or a flat shell script with a bunch of commands.
That Torvalds has bought the whole "just a init" marketing spiel surrounding systemd.
It is a init. And a cron. And a inetd. And a network manager. And a dhcp client. And a (caching) DNS client. And a session/seat manager. And a firewall manager. And a boot manager. And a/dev manager. And soon to be a tty manager.
Its proponents may claim that all those are optional.
From a init point of view sure.
But from a desktop point of view, wanting to use any of those make systemd-as-init mandatory.
What people gloss over is that you don't install OSX on your own. You buy a Mac (the worlds biggest dongle, imo) and it comes preinstalled.
Similarly with Windows, outside of the build it yourself enthusiasts people buy Windows preinstalled on some kind of x86 device.
Look at Chromebooks and you see preinstalled Linux.
Look at Android and you see preinstalled Linux.
Netbooks (that Chromebooks could be considered related to) started out as preinstalled Linux, but MS and Intel joined forces in smothering that baby in the crib.
Having done a bit of digging, and perhaps some soul searching, it seems that Poettering, and others, think that a tightly coupled system is the only way to build a OS.
This because they see generic distros, like Debian and Gentoo, have in effect dug themselves a hole thanks to the number of permutations involved in packaging (though with Gentoo being compiled by user/admin rather than distro maintainer it may not be fully correct to include them).
But to go from saying distros may have bitten over more than they can chew, to saying that everything between kernel and desktop needs to be a tightly coupled whole is quite the leap.
Yes, distros can be built to be highly specialized, and has been so since the early days. But that is not an excuse for making the software that goes into making a distro tightly coupled.
Also, way to much of what is happening above the kernel is happening from the desktop environment (Gnome in particular) down.
Take dbus for instance, it balks at talking across user accounts. But if it was amended to do so, user accounts become sandboxes.
But instead we get the whole rigmarole of cgroups and namespaces, managed by systemd.
Torvalds do maintain some ground rules for accepting patches though.
One of them is that they do not break userspace.
This involves making sure that any interfaces exposed to userspace processes behave the same across versions.
When a patch(-set) violates this, the developer(s) behind it will be at the receiving end of some nasty language. In particular if they refuse to acknowledge the breakage, and/or claim it is userspace that should be corrected.
There was point in time when Alan Cox stepped away from kernel development because Torvalds was having issues coping with the patch traffic and Cox's staging tree was bordering on turning into a de-facto release tree.
He may have produced some excellent code over the years and done a nice job maintaining stable kernel releases. but as of late he seems to have gotten very "one true way"-ish.
Not only the snark regarding maintaining a independent udev, but also the pushing of kdbus into the kernel when the gains are at best questionable.
As best i can tell the forces in the background pushing to get kdbus accepted are the car manufacturers and others wanting to use Linux in commercial embedded hardware.
This because they are coming from other platforms where using a RPC for everything (including the likes of moving massive amounts of raw streaming media data around) was norm, and they latched onto dbus as being the same thing on Linux.
But dbus performance sucks compared to what they used to use, and rather than locate alternatives (like say netlink) they are pushing to get a dbus derivative into the kernel so they can continue their old ways in a new "land".
Frankly i am starting to regret my support for Nokia's Maemo project from years back, as more and more it seems like everything that is, well, crapifying Linux these days seems to have originated from that project.
More and more it feels like very heavy corporate and government interests wants to turn Linux into Windows, with little regard to the potency of *nix concepts.
Note that it has been going on for two years already when that article was published in 2008. Meaning that Apple was in the middle a legal wrangle about their DRM when Jobs essay was published.
The whole thing about gun regulations over there is to regulate without actually regulating, because they have this constitutional amendment that everyone is so hot and bothered about.
What things like this mill does is reveal that the emperor has no clothes. A fact that everyone with a bit of interest in the subject knew, but kept mum about to maintain appearance.
Sounds about right. More and more long running software is facing a changing of the guards, and the new ones approach software development as if it is website devops (you know the bottom has been reached when a ever changing site is being talked about as an "app").
I'm tempted to blame Google and Facebook for this, especially the likes of Zuckerberg's "move fast and break things" slogan.
Slashdot Mirror
Already there:
RHEL vs Oracle vs MS...
The "all in /usr" comes out of the containerized web monkeys that is running the userspace Linux show these days...
What they do is they boot the "node" (aka computer) via a compressed boot image (initramfs), and then once that has set thing up, they just remount / read only to a SAN backend.
Hell, systemd is basically built around this being the expected way. This to the point that said boot image needs to get dbus up before handing things over to systemd loaded from /. Systemd will then use that for its early stuff before killing the boot image dbus, and starting a new one from /.
Observe how all of this is cooked up by the trifecta of Gnome, Freedesktop and Fedora, with most of the devs involved being on Red Hat payroll. Linux above the kernel has long since stopped being a community project, and become an extended arm of Red Hat.
Yes and no.
The basic problem with deb, and rpm, and similar package manager, are that they get hung up on the package name and version.
Meaning that you can only have one version of a particular name installed at any one time.
Want to install another version? Either you remove the old version or you change the name to avoid a conflict. But changing the name plays havoc with the dependencies tracking.
If deb and/or rpm was changed so that the manager could handle tracking multiple versions of the same package name, the need for the likes of snappy, xdg-app, or a myriad of similar systems would not be needed.
You can see this if you check out NixOS/Guix or Gobolinux that have implemented slightly different solutions to the same problem.
Yeah, choice. Like how Wayland depends on logind depends on systemd-as-init.
Damn it, one screwball in the dependencies chain and Gimp depended on systemd-as-init.
Hit update at that time and boom your perfectly functional distro install gets a init-ectomy.
To a init that will refuse to boot if you have a vestigial entry sitting around in fstab, no less.
Bingo.
Update to a recent Gnome and it will bellyache about logind, that in turn is part of system. End result, what used to be a desktop that can run on top of any init requires a specific init.
Moving forward i am expecting to see similar with their cron replacement, their networking and firewall stuff, etc etc etc.
This where before things would not care if you booted via sysv, openrc, upstart, bsd rc, or a flat shell script with a bunch of commands.
That Torvalds has bought the whole "just a init" marketing spiel surrounding systemd.
It is a init. /dev manager.
And a cron.
And a inetd.
And a network manager.
And a dhcp client.
And a (caching) DNS client.
And a session/seat manager.
And a firewall manager.
And a boot manager.
And a
And soon to be a tty manager.
Its proponents may claim that all those are optional.
From a init point of view sure.
But from a desktop point of view, wanting to use any of those make systemd-as-init mandatory.
Gnome, KDE, heck even XFCE or LXDE/LXQT would do.
What it comes down to is not the interface, but that it comes preinstalled and configured for the hardware it runs on.
OSX comes preinstalled on Mac (basically a massive dongle these days). Windows comes preinstalled on a range of x86 based devices.
The buyer unpacks, turns on, enters some basic account data, and starts using.
What people gloss over is that you don't install OSX on your own. You buy a Mac (the worlds biggest dongle, imo) and it comes preinstalled.
Similarly with Windows, outside of the build it yourself enthusiasts people buy Windows preinstalled on some kind of x86 device.
Look at Chromebooks and you see preinstalled Linux.
Look at Android and you see preinstalled Linux.
Netbooks (that Chromebooks could be considered related to) started out as preinstalled Linux, but MS and Intel joined forces in smothering that baby in the crib.
Bitcoin is not a currency, it is a virtualized commodity.
Having done a bit of digging, and perhaps some soul searching, it seems that Poettering, and others, think that a tightly coupled system is the only way to build a OS.
This because they see generic distros, like Debian and Gentoo, have in effect dug themselves a hole thanks to the number of permutations involved in packaging (though with Gentoo being compiled by user/admin rather than distro maintainer it may not be fully correct to include them).
But to go from saying distros may have bitten over more than they can chew, to saying that everything between kernel and desktop needs to be a tightly coupled whole is quite the leap.
Yes, distros can be built to be highly specialized, and has been so since the early days. But that is not an excuse for making the software that goes into making a distro tightly coupled.
Also, way to much of what is happening above the kernel is happening from the desktop environment (Gnome in particular) down.
Take dbus for instance, it balks at talking across user accounts. But if it was amended to do so, user accounts become sandboxes.
But instead we get the whole rigmarole of cgroups and namespaces, managed by systemd.
And that is when we sit back, grab some popcorn, and watch the fireworks.
After having some adjustments done to fit alongside code that was already in there doing similar things.
Torvalds do maintain some ground rules for accepting patches though.
One of them is that they do not break userspace.
This involves making sure that any interfaces exposed to userspace processes behave the same across versions.
When a patch(-set) violates this, the developer(s) behind it will be at the receiving end of some nasty language. In particular if they refuse to acknowledge the breakage, and/or claim it is userspace that should be corrected.
There was point in time when Alan Cox stepped away from kernel development because Torvalds was having issues coping with the patch traffic and Cox's staging tree was bordering on turning into a de-facto release tree.
Yeah i have been wondering about GregKH lately.
He may have produced some excellent code over the years and done a nice job maintaining stable kernel releases. but as of late he seems to have gotten very "one true way"-ish.
Not only the snark regarding maintaining a independent udev, but also the pushing of kdbus into the kernel when the gains are at best questionable.
As best i can tell the forces in the background pushing to get kdbus accepted are the car manufacturers and others wanting to use Linux in commercial embedded hardware.
This because they are coming from other platforms where using a RPC for everything (including the likes of moving massive amounts of raw streaming media data around) was norm, and they latched onto dbus as being the same thing on Linux.
But dbus performance sucks compared to what they used to use, and rather than locate alternatives (like say netlink) they are pushing to get a dbus derivative into the kernel so they can continue their old ways in a new "land".
Frankly i am starting to regret my support for Nokia's Maemo project from years back, as more and more it seems like everything that is, well, crapifying Linux these days seems to have originated from that project.
More and more it feels like very heavy corporate and government interests wants to turn Linux into Windows, with little regard to the potency of *nix concepts.
Meh, he already have GregKH on a leash and Sievers in the wing.
Sticking his neck out directly would be silly, even for him.
Sorry for being late, but have a look at this:
https://gigaom.com/2008/10/08/...
Note that it has been going on for two years already when that article was published in 2008. Meaning that Apple was in the middle a legal wrangle about their DRM when Jobs essay was published.
So even with the latest Fedora they have yet to figure out network storage mounting.
And this is supposed to be the backbone of CoreOS...
Indeed. Apple didn't really turn "anti-DRM" until they got into trouble with market regulators...
The whole thing about gun regulations over there is to regulate without actually regulating, because they have this constitutional amendment that everyone is so hot and bothered about.
What things like this mill does is reveal that the emperor has no clothes. A fact that everyone with a bit of interest in the subject knew, but kept mum about to maintain appearance.
Sounds about right. More and more long running software is facing a changing of the guards, and the new ones approach software development as if it is website devops (you know the bottom has been reached when a ever changing site is being talked about as an "app").
I'm tempted to blame Google and Facebook for this, especially the likes of Zuckerberg's "move fast and break things" slogan.
Costing just as many dollars...
> USB C was something Apple gave the USB folks
Huh?!
There are times i wonder if WW2 was facists vs facists about who was to run the circus.
Only because they are exporting like gangbusters.
Domestically the economy is at a virtual standstill.
In a sense Germany is damn close to Japan economically. If exports fail for either nation, its going to get messy.