Linux kernel 6.11 lands with vintage TV support
io_uring
is getting more capable, and PREEMPT_RT is going mainstream Version 251 of the controversial systemd Linux init system is here, and you can expect it to feature in the next version of your preferred distro. The unified system and service manager for Linux continues to grow and develop, as does Linux itself. There is a comprehensive changelog on Github, so we will just try to pick out a …
Presumably the users are happy too: Chromebook sales may be down, and they only have a fixed lifespan, but there are still well over a hundred million of them out there.
Have we really come down to having Computer hardware that is so locked down that at the end of its [cough][cough] supported life we are expected to send it to Landfill?
I know that we have a disposable society but this is getting stupid and is a total waste of finite resources.
Google and the people behind this can go ''F' themselves. This makes me even more determined to extinguish google from my life.
I submit that there are several things that contradict you.
[1]
As I linked in the article, the default support lifetime is 6½ years:
https://www.theregister.com/2019/08/22/buying_a_chromebook_dont_forget_to_check_when_it_expires/
For a rock-bottom price bracket, cheap consumer laptop, 6 years is a pretty long time. I suspect a great many of them will be clapped out or broken by then.
[2]
They won't suddenly stop work working. They just stop getting OS updates. They may continue to get browser updates for a while.
[3]
Secondly, as the ChromeOS Flex article I linked to also points out, it *is* possible to "root" most ChromeBooks and install your own OS. If you do that and install ChromeOS Flex, you get OS updates again.
For a rock-bottom price bracket, cheap consumer laptop, 6 years is a pretty long time. I suspect a great many of them will be clapped out or broken by then.
The Chromebook was positioned as an internet appliance rather than as a laptop. That is, it's a piece of kit sold for doing pretty much one thing — running a browser — rather than as a general-purpose computer.
Most appliances, once purchased, can be used in their original state until they do fall apart, because they have one thing to do and they don't get any worse at doing it until they begin to fail mechanically.
A Chromebook, though, is unlike most traditional appliances in that it does need occasional updates to correct security failings in the original programming.
My Chromebook is about a dozen years old (it's one of the original Acer C720s) which means it's been out of support for almost half its life. It isn't clapped out or broken, and it does still work well as a browsing tool ... but I wonder whether it is as secure as it was or as it should be.
They won't suddenly stop work working. They just stop getting OS updates. They may continue to get browser updates for a while.
Which is really not good enough. A device that is used as an interface to the wild and hostile world of the internet really needs its security to be up-to-date.
... it *is* possible to "root" most ChromeBooks and install your own OS. If you do that and install ChromeOS Flex, you get OS updates again.
That's true. One of the things I had in mind when I bought the C720 was that if I didn't like ChromeOS I could just install Debian/whatever instead. Unfortunately although Acer did make a 4GB version of the C720 I couldn't find one in the UK, so I have a 2GB machine. I could run a normal Linux distro on it, but that's a bigger system than ChromeOS and I wonder how usable it would be in that little RAM? I've never tried.
I shall have to look into ChromeOS Flex when it becomes a little less "early access".
... I could run a normal Linux distro on it ...
Most probably.
I run Devuan Linux 32bit on an Asus 1000HE Atom N280/2Gb RAM and take it with me when I need to go out of town, does everything I need. When not on the road, it works as the hardware behind my coffee roasting application.
Purchased it used back in 2011 and six years later snapped up one for a song as a donor for the a couple of shaky USB ports and a couple of plastic parts that were in bad shape.
US$50 (recovered by selling the donor screen) plus a couple of hours of my time and it was as good as new.
So yes, I'd expect that you may be able to do something with it.
O.
To be honest, I'd expect a continual update, and a main line codebase. Just like you can upgrade Ubuntu based machines to the latest, or one of the more resource efficient versions for lower spec machines.
This is not rocket science by any measure. I have a laptop from the end of the '90s that STILL runs quite happily on Linux. I don't expect much from it, but it does for mail, general browsing and so on. So that's almost a quarter of a century of support.
The crux of it is that you need to "Root" the device to be able to upgrade it, as the vendor has artificially limited the lifespan by determining that it will not provide any further updates (these don't take huge amounts of resource; the drivers are already there). This will keep perfectly functional devices deliberately insecure so that a user is forced to upgrade to a newer product (with associated spend).
So, the real answer to how long I would expect updates is "As long as the vendor is around". Or, at the very least, when your product goes out of mainstream support, release the drivers to the Open community and allow updates using an alternative after market supplier.
Well I see your point of view but I disagree. At some point it is not worth time for a vendor to support something. I have seen a 70 year old water boiler in a house. Should the manufacturer still be keeping spare heating elements around (if they even still in business)?
If you were paying a continual service fee for the software that would be another matter. But I am guessing that you are not.
" have seen a 70 year old water boiler in a house. Should the manufacturer still be keeping spare heating elements around (if they even still in business)?"
Bad example. Those parts are usually universal, not proprietary. I fixed the HVAC in my parental-units home a couple months ago. The parts were readily available. It was installed in 1947. I just called MeDearOldMum and she reports the AC is humming along quite nicely.
"You didn't get it from the original supplier, did you?"
Yes, I got the part from the OEM manufacturer (Honeywell), same as the HVAC assembler/seller did 75 years ago. I could have bought it directly from the HVAC assembler/seller (Frigidaire), but their markup is hostile for old kit.
You mean like the classic car scene has a roaring trade in aftermarket spares? And a whole host of other areas that require parts.
If you're playing analogies, this is more akin to building something to a standard which will have newer parts available ad infinitum, but putting an artificial limiter on it so that it will stop being of use (for example, having an engine management in a car that will, after a pre-determined period, or just when the vendor of the car decides that it's time for people to upgrade, which will prevent the locks ever working again).
Or, perhaps in your boiler case, parts made to exactly the same spec are made for all the newer boilers, so they fit, tighten, and would be mechanically functional, except the parts are only available from the manufacturer, and they refuse to sell them to individuals, only their own repair departments, who refuse to fit them onto the model that the vendor decides is "currently supported".
The hardware is good, solid and working. There is just an artificial limitation to prevent you getting after market support (which, if you really know what you're doing, you can probably circumvent, but your average person wouldn't have a clue).
And if you don't know the difference between compiling in a kernel driver and building heating elements, and the relative impact the distribution has, then I'd advise looking carefully at both.
One can be done very quickly and tested, and distributed for almost free to tens or hundreds of thousands of units in seconds, versus a deep supply chain and a logistics cost that's non-trivial.
You are either missing - or being obtuse - the main point of the argument.
Chromebooks are locked down so it's not possible for someone else to support it via standard components or after-market efforts, unlike with the examples provided of boilers, HVACs, old cars, etc, that aren't locked down so support is in fact provided via 3rd parties in the form of standardized components that are still availalable or niche after-market manufacturers.
One of the options offered instead of the original manufacturer supporting it forever mentioned by the posters you are replying to is:
> Or, at the very least, when your product goes out of mainstream support, release the drivers to the Open community and allow updates using an alternative after market supplier.
The argument is that while the vendor deilberately keeps it locked down with the intention of preventing anyone else from supporting it they should maintain support. Once they decide to cease support they should open it up so it can be supported by 3rd parties.
Evidently you haven't.
Some people, and particularly some people in the Linux mob, think that manufacturers owe them everything for ever. Can you ring up Ford today and say "hello, I have a Model T and it needs a new bobble'? No, you can't. Well you can try but you will get no for an answer. The fact that your Model T has worked up until now is irrelevant.
When I asked earlier how long hardware should be supported for, the first reply was 'a continual update'. In other words forever.
Have you ever worked in IT? I am guessing not, because you don't seem to have a clue. I cannot think of any piece of hardware we have bought that did not have an EOL date. Quite often we run that hardware beyond EOL, in a less critical role. Other times we had third party support (sometimes). If you look today at Cisco, Oracle (Sun), HP, etc, they announce EOL dates for hardware.
So why would a cheapo chromebook be expected to last with continual updates until the next ice age?
Some people, and particularly some people in the Linux mob, think that manufacturers owe them everything for ever
What a pile of male bovine manure.
What most people want is not that the manufacturer support a product for ever, not that the manufacturer will give them support in "doing other stuff with it", but that the manufacturer doesn't put more effort into preventing anyone using a product in any way not deemed acceptable to the manufacturer.
The "particularly some people in the Linux mob" actually would be quite happy if the device wasn't locked down to prevent them loading whatever software they want on it and using it how they like. If it doesn't work, fine, the manufacturer can wash their hands of it. But too much stuff now is locked down, and quite frankly there is a LOT of effort that goes into that. And mostly it's done under the cover of "but, security" while it's actually to create artificial obsolescence so the manufacturer gets to sell more stuff and/or prevent people buying stuff without giving the manufacturer 30% protection money.
The poster boy for open hardware used to be Linksys. You could buy a WRT54G and put different software on it - it was great. Linksys didn't expend any effort or provide support - they just left the hardware open and accessible so that people who wanted to could work out the details themselves. Back in the day, we (my employer) bought quite a few of those (instead of anything else) for just that reason.
If Linksys appears on any poster relating to this it's likely a satirical one. They had no intention of any of this, but they went and copied some GPL code and inadvertently violated the license. When they got found out, they were (eventually) forced to open-source the firmware.
They learned their lesson and used VxWorks after that.
I bought an Acer C-710 on sale at Fry's in 2013, and it still works, though the mouse buttons are begnning to go flakey and battery runtime is decreasing.
The first thing I did was back up ChromeOS, then installed SeaBIOS so it acted like "a regular computer", then installed OpenBSD. The only downside was OpenBSD (still) not dealing with the builtin wireless, which I fixed with a USB-attached wireless unit.
If OpenBSD is not your thing, there are other Unix and Linux distros you can run. Elsewhere, I run Devuan to avoid the plague of Systemd.
This laptop is 18 years old. It is still running a supported version of Slackware, one which has no EOL announced as of yet. It is fully capable of running all of my myriad interlinked businesses when I'm on the road ... and thanks to FOSS advances (and a RAM increase ... 256megs to 2gigs), it works better than it did when I bought it!
Some of us don't listen to marketing weasels. They lie, by training and inclination.
I've also replaced the hard drive twice, and a cooling fan once.
Sorry - You missed the point. Not "laptop", but instead, "Locked-down Goggle Chrome Book".
Until you've had to first compile and install a custom boot loader onto your Chrome Book boot ROM, before you are able to install your preferred Linux distribution, you may not really appreciate the difference.
I bought my Chromebook because:
(a) It was the only Chromebook I'd seen with a real-all-the-keys PC-style keyboard;
(b) I knew there was a procedure and freely-available code available I could use to install SeaBIOS, and hence install my preferred OS; and,
(c) It was only $199.00 (store demonstrator on-sale).
I don't recommend this for Ma-and-Pa, but for techies, I do.
Google doesn't believe in dynamic linking. It makes software management trivial if you don't mind each app being 20 to 500 MB. It's fine for Google but that's a lot to serve up to the world when your open source project has a revenue of zero.
Snap, Docker, etc. claims to fix dependency management, but that's never how it goes in real use. The layers are customized so close to the root that every project ends up being 100 to 2500 MB. That size creates dependencies on well-funded hosting services.
So, here we are with complex dependency management to keep free software free and scalable.
I know someone who had an Acer Chromebook passed to her as a gift.
I think it's support is ending in another 2 months or so. The hardware seems to be still working fine, and hopefully it can be repurposed or unlocked when the support ends.
She recently got a laptop from me, so she is planning to pass that Chromebook over to someone else. Hopefully it will still have some use until the hardware itself fails.
I got a Commodore 64 in 1986; got rid in 1989, and then got another one in 2010. Still does what it says on the tin, still got (limited) numbers of people writing software for it, and frankly, still a lot more fun than anything modern.
No, I can't do finite element analysis on it. But a very potent gas pipeline simulation still in professional use was originally developed to run on such limited hardware.
An occasional replacement of the capacitors or the PSU is warranted. All readily available parts, and of course, the system came with the schematics.
So yeah, I'll raise you your anti-Google consumerism and point the middle finger at the entire supply chain built around enforced obsolescence. Old shit is so much more fun, the sweet spot for me being mid-80's.
Systemd is not (just) an init system, and was never intended to be so. The init system was just one of the first modules of Systemd, and was used to get its foot in the door in most distros.
Since then we've pretty much just had to accept whatever the Systemd team gave us, because they're well funded, have feet in all the doors, and its codebase is complex, ever changing, and monolithic.
(someone's going to want to now come back with "Systemd isn't monolithic, it's modular!" because they don't understand the difference between codebases and processes)
... and its codebase is complex, ever changing, and monolithic.
Quite so.
A virus, exactly like MS's registry:
---
Systemd is a virus.
It works just like the registry does in MS operating systems.
It's a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the host with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what is going on inside your box as it becomes more and more obscure.
Systemd is nothing but a putsch to eventually generate and then force a convergence of Windows with or into Linux, which is obviously not good for Linux and if unchecked, will be Linux's undoing.
So it does not seem as there's nothing new here: it's the well known MSBrace at work.
Now go and tell me that Microsoft has absolutely nothing to do with how systemd is crawling inside/infecting the Linux ecosystem.
---
O.
Rather, systemd is a cancer.
Consider: systemd takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host. That sounds an awful lot like a cancer to me ...
So do what I do and call it the systemd-cancer. Short, descriptive, accurate, has been known to scare management/moneybags away from distributions containing it ... what's not to like?
Systemd is not a virus.
I think we share the same love for it.
So we can probably agree that it is just as damaging.
... doesn't reproduce itself.
Not by itself, but by successive iterations. ie: developer induced.
But you've nailed it: yet
Short, descriptive, accurate ...
It's my many years' experience with the MS registry speaking.
Best,
O.
Yeah... that is a good point. It was never intended as "only the init replacement". Does it address problems? Sure! Are those problems serious? I guess, as far as I can wrap my head around them (I know my limits), there are some apparently more balanced discussions I stumbled accross (other than the "systemd sucks" vs. "LP is the saviour" shouting matches I have seen). Do I really think they should be addressed the way systemd does? Nah, not really. I do not have to be a musician to hear if somebody is singing out of tune, and I do not have to be a kernel / OS developer to find the systemd-approach irritating. (plus I got burned by LP's other project, pulseaudio, when it started to ship as standard in some distros when it was still half-baked and much worse than alsa at that time - though it has apparently improved I am not really willing to try, no time for that stuff).
I like my distro's package manager (apt-get), which leaves the system in a known state (unless I do... stuff I should not do, which I am aware of), mostly in a known and _good_ state. The only issues I have with it are when the kernel gets updated and then some network drivers or somesuch are missing - but then I can boot the known working kernel. No problem there. (or when I had packages installed by hand to fulfill dependencies, or had them pinned...)
There are also file systems that allow snapshots that can be mounted (zfs, for example, I think bttrfs or however it is spelled as well), which can be used in the "dual system partition" scenario described above. Not sure why this is so "new" and "exciting". I don't use it (currently), but thought about doing that when I do an install from scratch for a new device. This decade. I guess.
So... I think I'll pass that "opportunity", and continue to run something else.
"Since then we've pretty much just had to accept whatever the Systemd team gave us"
Who is "we", Kemosabe?
As a side note, did you realize that the so-called "team" that you reference consists of two people who were banned from the Linux kernel by Linus because they do not play well with others? Some "team", that.
www.without-systemd.org
Len has figured out a successful way to hijack most Linux distros. He is committed to re-writing everything as he sees fit, regardless of how the changes he makes break things for the community and existing stakeholders.
All you have to do is keep spamming commits. Since the Distros aren't protecting themselves from political takeovers, all he has had to do is keep taking over other peoples work and making it dependent on his system.
Someone at A$$hat Linux management should have had the "Stay in your lane" conversation with him years ago. He isn't just clueless either, people have grilled him about the unnecessary breaking changes and systemd sprawl violating the core UNIX principles of software design. He personally destroyed the "everything is a file" IO layer, not just because he didn't appreciate the value of it(or the deployments dependent on it) but because by breaking these things, he forced everyone to re-write to only his way of doing things. This isn't an accident or an inability to function at an interpersonal communication level.
It gives the systemd team defacto control of the future direction of Linux, which is centered apparently around what runs well on Pottering's laptop, but also lets them plan and implement whatever new vision for Linux they wan't without taking input from the rest of the community. Since A$$hat Linux is either the upstream source or necessitates compatibility for project developers and packagers like 2/3 of the community is forced to follow what they are doing.
In an era where bad actors with authoritarian and autocratic tendencies are taking over governments, companies, churches, and whole countries, you'd think that governance of OS that is critical infrastructure for the world would receive more attention. The fact that the Systemd team as been allowed to take over so much would make people's heads catch on fire if it was coming from China or Russia. The community still hasn't quite grown up enough address these gorvernace issues. As a result, I think we should be moving critical infrastructure onto BSD. It's more suited to it anyway.
I'd love to see the problem fixed at it's root instead, but the Systemd team won't just stop. Even if you started trying to build a replacement at this point, they would just stay on the gas pedal, trying to change other parts of the core OS to make them dependent on systemd. At this point it would be hard for a non state backed project to catch up, so unless the community forces them to fix the mess, they will eventually force most of the Linux distros to become Lennux distros. It seems though that the vox populi mostly cares about a free OS they don't have to code themselves, so I expect that any such effort to tame systemd will split the developer community because of the wasteful effort of trying to support both, and stave off another round of breaking changes when the "fixes" start to land.
I wrote in a post to a different article (about the release of FreeBSD 13) that "It seems to me that Linux has become a platform for running systemd, rather than systemd being a tool for Linux."
At some point enough Linux users (or perhaps one of the major distros) will wake up and dump systemd. It is the antithesis of UNIX as a whole and should be called out as such.
The supposed positives to systemd are are not actually all that positive. They bring some benefits. But those benefits are hardly necessities. All the major improvements to UNIX (and by extension Linux) were made before systemd. Now we have software dependent on systemd. How did this happen?
Unless systemd is stopped, it will emerge as a permanent layer above the kernel and everything will have to pass through it.
This isn't an accident or an inability to function at an interpersonal communication level.
I have been saying the very same thing for a few years now, only to get booed.
It gives the systemd team defacto control of the future direction of Linux, which is ...
To slowly but steadily infiltrate the MS way into the Linux ecosystem.
ie: the 30+ year ol "Embrace, extend, and extinguish" method.
... you'd think that governance of OS that is critical infrastructure for the world would receive more attention.
But it did ....
From Microsoft.
The writing has been on the wall for ages.
O.
I've just read his blog post that was linked in the article - its long.
I don't like Poettering, I don't like systemd. My first encounter with him/it was when some GUI packages started requiring it, back then I was using FreeBSD, and his approach to non-Linux back then was "I don't care. This is about Linux". He seems to have a natural ability to alienate people.
Reading his blog post, he's trying to solve a lot of valid issues. How do we have a fully secure OS? How can we treat a PC like an appliance, to make it more reliable and bulletproof? How do we add software to an OS? What is a package?
The problem is that he sees all these problems, and the answer that comes to his mind is "lets add an extension to systemd that handles this". So you have systemd-boot for working out what kernel to run, systemd-sysupdate for updating your "system image", systemd-oomd for handling OOM, systemd-nspawn for running containers, systemd-portabled for running isolated services, systemd-sysext for adding system packages to the OS, systemd-repart to automatically create/destroy partitions on the fly.
All of this work, for him, is essential, and all of it is developed under his aegis. It's not the collaborative pick-n-choose, best of breed wins style that Linux is based upon (eg, cron. When the original cron didn't quite fit its need, people developed many different versions - the one we use today is the best of those - thanks Paul Vixie).
I don't disagree with most of his blog post.. just his methods.
@Tom 38 and all
I'm thinking there is something of the Dominic Cummings about Dr Poettering. Often identifies important problems. Proposes and somehow manages to action comically inappropriate solutions.
Slackware, as others have pointed out, should be added to the list of perfectly viable Linux based operating systems currently not consuming systemd. Then there is always OpenBSD.
"So Linux is as impenetrable to the average nerd at home as is Microsoft Windows."
Totally incorrect. This average nerd at home has legal access to the Linux source code, and can read it for himself. I can not say the same thing about Windows.
"other remarks are not fit for a civilised general readership."
Here on ElReg? I'm fairly certain the commentardariat can handle whatever you chose to dish out.
The OP is right. As an average nerd at home, I can understand the concepts, I can read the open source projects descriptions, and I can compare them to see if they suit my needs, and, of course, I can search the flame wars.
But what I can't do is read the source code (even if it is in a language I understand) and determine how or even if it does what it claims. I write bug reports and feature requests, not suggested software patches.
Having access to the source code does not make Linux any less impenetrable to the average nerd at home.
Shhh, Linux-heads believe that since FOSS allows everyone to have access to the source code, it is thereby established that everyone SHOULD understand that source code and be able to work with it.
Never accepting that billions of people are just...computer users, not "nerds" or code jockeys.
"Linux-heads believe that since FOSS allows everyone to have access to the source code, it is thereby established that everyone SHOULD understand that source code and be able to work with it."
\
Oh, bullshit. Nobody ever said that, except Microsoft shills spreading FUD.
What we are saying is that it's there for anybody who cares enough to read (and/or fix), unlike the commercial competition where you are stuck with wherever Marketing decides you have to go today.
"But what I can't do is read the source code (even if it is in a language I understand) and determine how or even if it does what it claims."
Yes, you can. You just choose not to. Which is fine, nobody is even remotely suggesting you have to.
"Having access to the source code does not make Linux any less impenetrable to the average nerd at home."
It's a lot less impenetrable than Microsoft's unavailable source code. And some of us can, and do read it. Including this average nerd at home. You might not be doing so, but it sounds like you are suggesting that thousands, or perhaps tens of thousands (dare I suggest hundreds of thousands?) of us who are should not be bothering because other people aren't bothering.
There are 2 kinds of progress, or perhaps a 3rd less obvious one as well.
Evolutionary: Progress forward in which things become faster, better, more reliable, by making EVOLUTIONARY changes.
Rotting: Progress towards a BAD END by making RADICAL changes that distrupt, and eventually CORRUPT everything to the point of decay.
Stagnation: a possible third which is as bad as ROTTING SLOWLY
Guess which one is systemd?
Howdy doody, bombastic bob, nice to speak to you, to speak to you, nice.
You failed to mention and introduce the progress made by Revolutionary Missing Link Quantum Leap Bulletin Boards, where one can alongside in plain sight and full knowledge of the almightily bored and undereducated hordes, read/see/hear/experience and experiment in worlds with strings of words creating, commanding and controlling and destroying worlds.
Was that unintentional and not by intelligent design an oversight and omission resulting from a lack of necessary information ... which would easily explain it?
None of them quite obviously. Systemd is a replacement of upstart which itself was a replacement for init scripts. It is quite clear what it intends to do and why it succeeds in doing it.
1. starting services in the proper order, and concurrently
2. bringing up or shutting down dependent services properly
3. declarative
4. principle of least privilege
5. security
6. auditing & logging
There is a reason that all the major distributions are using it and will continue to do so.
If it did any of that well it would be an argument, but still not a good argument for it being monolithic.
Its auditing and logging is generally piss-poor, security of course is a joke and the principle of least privilege is a bizarre claim for something that collects and spreads out root-level access all over the place where it's not needed.
Configuration is indeed declarative, as in "I declare that this is the worst, most over-engineered, complicated mass of spaghetti I have ever seen masquerading as an init system."
Starting and bringing down services in the correct order is not rocket-science and was a solved problem before systemd fell out of Pottering's arse.
The reason it's in all major distributions is that someone is funding it. That's the reality of commercial distributions - if someone else is paying to develop and maintain something then no beancounter will consider an alternative that comes out of the bottom line that they are charged with protecting. If it's shit, who cares? That's someone else's fault/problem.
Systemd is garbage-ware that belongs in Windows where it would fit right in.
It is monolithic.
It may well be in different files, but it's not modular.
To be modular, then the different bits would need to communicate via documented and stable interfaces - it fails both of these, especially the stable bit. Then each module would need to do a defined set of functions. And if all this is done right, for any part it would be easy to sit down and build an alternative for that. Systemd isn't "done right", and they don't care. They reserve unto themselves the right to change anything, anytime, and without notice.
If what you claim is all systemd is supposed to do then where does the system update module fit in?
Systemd did solve some problems i never had and caused some problems that did force me to take action to make the system work again.
Ok, by now it runs pretty stable and provides a cleaner way to describe dependencies between services/processes and is usable.
Doesn't explain why it needs to add more and more functionality; it really seems LP is on a path to take control of everything running in user space.
starting services in the proper order, and concurrently
For what genuine reason, other than to cause instability and indeterminism ? Concurrently starting stuff then leads to all the problems we see of trying to properly handle all the "B can't start until A is running" stuff. And frequently, though much less so these days with solid state storage, starting things in parallel can slow everything down.
principle of least privilege
Which is presumably why systemd creates such a massively increased attack surface in PID 1 ? It actively breaks the principle of "do one thing and do it well" and "keep the most critical bits small".
security
Security and systemd ? In their rush to "fix" stuff that wasn't broken, working fast to embed as far as possible before the world wakes up, and with coding so bad that Linus told at least one of their developers where to shove his patches - they've had no end of security problems. And their attitude to reporting anything they don't consider important (lie, working properly) is stuff of legend.
1) Because if something depends on something else you want the something else to start first. Duh.
2) No it doesn't. This is absurd, especially comparing to what it replaces.
3) They are fixing stuff which has demonstrable limitations or weaknesses.
Honestly I find the systemd hatred just stupid on multiple levels.
Because if something depends on something else you want the something else to start first. Duh
Exactly, so why start them at the same time - which is what "concurrent!" means. OK, we're not to the point of actually starting A and B at the same time (yet), but starting C and D and E at the same time as B is just creating race conditions and probably slowing things down.
It's a lot easier debugging when only ONE thing is started at a time.
Of course, a MUCH better way of doing it would be to just start every process at the same time, and let each process look for and wait for the dependencies to be running. Trivially easy to do when you've got some shell scripts you can fiddle with - impossible when the stuff you need to work with is obfuscated away from access. You see, the problem is that different people and programs have different ideas of what "X is up" means.
Take "network" for example - does "up" mean there's at least one interface that is "up", or that a specific interface is "up", or that we have access to something on the local network, or we have access to something on the internet ? All these can be true, on the same system, at the same time. For example, I might want to bring up a DNS service as soon as there's any network up. But if there's something dependent on a database then I might want to wait until that database is available - which might mean that a specific interface is up and running (as well as the remote database).
So there is an argument for each service/process to start off with a "are my dependencies ready yet ? No ? OK I'll sleep for a bit and try again" bit of code. But I can't see that being popular in systemd land because it gives the power to the processes, not to systemd.
Oh yes, and systemd's PID1 is massive compared to the alternatives - creating a significantly larger scope for problems in arguably the most critical piece of software on teh system.
This post has been deleted by its author
This is a great tight little project, but it needs a bit more support from the community. (By that I mean $$ kinda support).
Slackware has been a great platform to build a buttoned down server off of for years. Almost like BSD (and it IS very BSDish for a Linux distro). Almost nothing in the base install, and you can quickly add what you need. Only issue is it's hard to justify putting systems in production when they are totally dependent on on person on a shoestring budget.
I'd love to see them get the support they need to get things back to the way they were years ago, with enough resources in the core project that it wasn't a risk the project could stall out at any moment.
I think if you dig into it, you'll find there is a lot more than one person working on Slackware.
It is on a shoe-string budget, though ... but then it always has been. PV manages to muddle through, though, as he has for over a quarter century. I agree that it'd be nice if more people would contribute.
Several months ago, I had to blow away and reinstall my laptop, and decided to give Slackware a go, based largely on your posts here. (As context, I consider myself reasonably au fait with Linux, having run Gentoo, Ubuntu, Fedora, Linux From Scratch and OpenSUSE in one form or another since before 2006, and fully agree with your characterisation of systemd.)
I felt at home in Slackware, it was great! But I couldn't find how to update packages. Key internet-facing packages and libraries relied on OpenSSL versions (1.0.2) that were EOL at the time, and it seemed like the way to know if something was patched was via email list. I dug myself into a waist-deep morass of dependencies trying to update and recompile packages manually to get the latest security fixes, and in the end retreated to Kubuntu where I can just run apt-get and get the updates I need.
As an experienced Slackware user, what did I miss? How do you keep things patched?
"As an experienced Slackware user, what did I miss?"
Probably slackpkg,
"How do you keep things patched?"
Uncomment the mirror of your choice in /etcslackpkg/mirrors, taking note that there are two lists in that file, one for -stable (what it sounds like) and one for -current (the rolling release). Just stick with -stable until you fully understand how it all works. Only uncomment one mirror at a time.
Then run slackpkg update to get the new list of packages & their version numbers (etc.), followed by slackpkg upgrade-all. It'll burble away to itself for a bit, then present you with a list of software that has upgrades available. Select the bits you want, and tell it to go get 'em. A couple minutes later, dependent on your network speed, your system will be updated. You will be prompted if a reboot is necessary ... this is mostly only needed for kernel updates these days.
Obviously there is more, but that's the gist of it and all you need to upgrade your system.
More info available at https://slackpkg.org/documentation.html ... note that if you've done a full installation of Slackware, the slackpkg tool is already on your system, no need to re-download it.
Following up to my own post ... I should know better than to post late-night. (Why bother with the follow-up? Because someone might run across this someday. Hopefully it'll help at least one person, eventually.)
That's /etc/slackpkg/mirrors
You can also run slackpkg install-new before upgrade-all to pick up any new packages PV has added to the distro. This is rare in -stable, but can be common in -current.
A web page to keep an eye on for changes to the distribution:
slackware.com/changelog/
Need I tell you to please pick the mirror that is logically closest to you?
A host is a host from coast to coast
And no one will talk to a host that's close
Unless the host (that isn't close)
is busy, hung or dead. —David Lesher
"more and more are adopting SystemD*ck-free distros every day."
No need to pretend you aren't really swearing[0] ... just call it what it is, the systemd-cancer. Totally safe for work, and you can even use it in mixed company.
[0] Why do people do that, anyway? If you feel like fucking swearing, then fucking swear! The only person you are fooling is yourself.
"Nope. Ever heard of geek humour?"
Rumo(u)r has it the dinosaurs suicided because their version of Millennials wouldn't stop telling the same "jokes" over and over and over ... The survivors, who still found it funny after many generations, eventually turned into chickens.
"Besides, cancer doesn't begin with a D, even I know that."
No, but Daemon does. I'm tryin' m'best to cast one out ...
... and you can expect it to feature in the next version of your preferred distro.
@Liam Proven
Are you sure that was sugar you sprinkled on your cup of tea?
I am not expecting any such thing.
Quite the contrary, actually.
Ah ...
It was a joke, eh?
Granted, there is some solid funding behind Poettering's antics but that is only money, it is not a substitute for intelligence.
He codes crap and eventually, everyone with some common sense will realise that.
O.
It's a numbers game.
I was careful to link to *Reg articles about* a few systemd-free distros at the end. Note, not just any old systemd-free distro, but one we've covered relatively recently.
There are plenty more, and I hope in time I will get to give most of them a look. So far, personally, my favourite is Devuan, but that's mainly because of long familiarity with Ubuntu.
But the real point here is the numbers. I said "to your preferred distro" because the user numbers of Linux in general are small (except ChromeOS), and then inside the Linux world, there are a handful of distros with large numbers of users (Mint, Ubuntu, Fedora, Debian)...
And, for better or for worse, *all* of them use systemd.
So the probability is that if any random reader runs Linux, they run a distro that uses systemd.
For the simple reason that all the non-systemd distros put together constitute a few % of the Linux desktop and hand-rolled server market.
I do not love systemd, but OTOH, now I know how to avoid the big problems it caused me in the early days, I don't hate it either. In fact, I just ignore it.
So my line was not a joke: it was a bet.
A fairly safe bet.
Maybe that is a sad thing, but there it is: almost everyone running Linux on their own computer almost certainly runs systemd.
So my line was not a joke: it was a bet.
A fairly safe bet.
Hmm .... (apologies if I seemed to come across the wrong way, not intended)
As a horse track enthusiast, I can certainly understand your point of view and even sympathise with it.
But if there's one thing I've learnt at the track is that there's no such thing as a given when a bet is involved.
It cost me quite a few $$$ to realise that.
O.
Seriously, you think that we'll only be able to install anything via snap? That is going to be one hell of a losing idea. Snap installed software is insanely bloated, it requires half an OS worth of dependencies for each application, and running a complete VM based system even to create an install package. Do you think established users are going to give up the convenience and speed of package managers for that unholy crap? The GCC packaged as a snap? How the hell would that work? (other than very badly) All the handy little utilities like apt-clone gone?
If this ever happens (which I doubt) we'd be hearing that we can only install from the 'Linux Store'............. and whatever decent easy-to-use path away from that madness emerges, I'll be taking it.
Yes, I do.
ChromeOS is a closed box. You *can* install apps -- my single ChromeOS Flex machine has Firefox on it, just because -- but you have to know what you are doing.
But if Fedora Silverblue or Ubuntu Core eventually mutate into some kind of immutable-root-filesystem, largely bomb-proof end-user Linux, then yes, I think they will adopt the good bits of ChromeOS' design:
• dual redundant root FSs, because disk space is cheap now;
• a largely lid-welded-shut sealed-down OS design, with a read-only root FS;
• just the bare essential core tools provided: a minimal desktop, a web browser, a file manager with a few file viewers, and a shell.
As simple as it can be while being generally useful.
But my bet is that they will leave open some kind of cross-distro containerised app-distribution format, which ChromeOS does not have.
And the result will do all most end users need, it won't be very customisable, but it will be largely bulletproof. You will be able to pull the battery in the middle of a file transfer, or an OS upgrade, and when you turn it back on, it will resume exactly where it was.
And that will be a good thing for most people most of the time.
There will still be some oddball Linux distros out there that do things the old-fashioned way, and there will still be the BSDs.
Maybe Minix 3 will sort out SMP and subsume NetBSD.
Maybe someone will work out some kind of ML-powered code-auditing tool and be able to automate OpenBSD's code-checking, and it will merge with FreeBSD and DragonflyBSD as the last modern continuing scion of original UNIX™.
Or maybe, perhaps most likely, we will all end up running CollapseOS or FreeDOS, with the survivors of humanity living at the poles, as the rest of the planet is uninhabitable.
"systemd is submitted as a patch to the Linux kernel, or the Linux kernel becomes part of systemd?"
The lead systemd-cancer developer has been banned from contributing to the kernel, so the first might happen, but the submission will be shit-canned. Linus has stated repeatedly that there is no place in the kernel for an init. Intelligent developers agree with him.
Your second is possible, but in that case the kernel will need to be forked (again), and everybody will ignore the non-Linus-led version (again). This last will finally kill the systemd-cancer, so I'm pulling for it.
The twin /root for upgrade or fallback is very recent AIX like, for values less than a decade. HPUX 10 had something like it earlier I think. Vague recollection of messing with it in late 19990s. I have the impression that LP is trying to copy AIX concepts and doing it badly. AIX system resource controller is elegant and just works. You can also choose to use init scripts also like real nerds
The idea of an active/passive pair of OS images has been around for decades. OS/400 had it in the '80s, and it wasn't considered novel then. Implementations have probably been around for half a century or so.
And of course you could roll your own with any number of boot managers. IIRC, even with BSD 4.3 Tahoe (1988) the bootloader could be told what label to use when locating the root partition.
Sure, it's "a benefit". It was a benefit 35+ years ago. Everything old is new again, generally without the implementors taking any note of the lessons learned in the previous incarnations.
"What is disappearing is their role as the tool that allow end-users to customise and update their OS. Instead, they are becoming the tools that vendors use to build the distributions."
Somehow I doubt that will appeal to the market. What happens when a significant vulnerability is found in some library. Do we wait until RedHat or whoever roll out the next ISO to install and reboot, just like a Windows update?
So in the article on Pipewire, the commenters mentioned Bluetooth doesn't work with PulseAudio because they reject all the patches to fix it, thus we need Yet Another Sound System.
(https://forums.theregister.com/forum/all/2022/05/24/new_audio_server_pipewire_coming/#c_4464459 for example)
THAT is my issue with Poettering... over and beyond his "do all the things in systemd" mentality
Linux audio has always been screwed. Back when FreeBSD had multiple channels (supporting hardware multiplexing and software multiplexing), and separate mixer controls per channel, under OSS. Linux OSS was stuck with a single channel, causing the proliferation of horrible hacky sound daemons.
Instead of fixing their OSS implementation (Not Invented Here), they came out with ALSA. The "L" in ALSA stands for Linux. This was around the time Linux users used to often criticise software that only ran on windows for not being multi-platform - proving that when they cried for "multi-platform", the actually meant "runs on Linux". They didn't give a shite about all the stupid linuxisms other unixes have to work around to get software to work.
systemd is the worst example of this, and ironically, is affecting many linux users who didn't give a crap about "creeping linuxisms" before.
I'm not mocking about this, but there is a bit of reap/sow about the whole systemd takeover.
-> proving that when they cried for "multi-platform", the actually meant "runs on Linux". They didn't give a shite about all the stupid linuxisms other unixes have to work around to get software to work.
Yes! Some people confuse open source with Linux open source. They are two different things.
Not mentioned, because not relevant.
FreeBSD uses the API. Nothing about FreeBSD OSS was related to the proprietary version. There was nothing stopping Linux doing the same, or even importing FreeBSDs enhancements.
Quote:
"FreeBSD contains an independently developed implementation of the OSS API, which includes, among other things, in-kernel resampling, mixing (vchans), equalizer, surround sound, and independent volume control for each application. It also supports bit-perfect mode."
"ChromeOS has two root partitions: one live and one spare. The currently running OS updates the spare partition, then you reboot into that one. If everything works, it updates the now-idle second root partition. If it doesn't all work perfectly, then you still have the previous version available to use, and you can just reboot into that again."
Define "everything" in the phrase "everything works". And "it updates the now-idle second root partition", precisely when does that happen? Because after that second update you most certainly *don't* have the previous version available.
Not that I am using Android or ChromeOS any time soon, but these complete image updates are the worst feature of iOS and macOS, and only tolerable because Apple has the funding to get it mostly right. It's still a risk I would rather not take.
In the Linux distros I have used, when I update the kernel I still have the old one in the boot menu, and it's my choice which to boot and which to remove. So all this jive about modern OSes are too complex and need new ways of managing just sounds like drivel. Computers are now and have always been very complex. There are good ways to deal with complexity, and there are bad ways. The monolithic anti-pattern is one of the bad ways.
In the Linux distros I have used, when I update the kernel I still have the old one in the boot menu, and it's my choice which to boot and which to remove. So all this jive about modern OSes are too complex and need new ways of managing just sounds like drivel.
Exactly. And it's not exactly rocket science to keep a spare copy of root around and have booting from it as an option to the boot loader.
Why does systemd need to add this? It has been a (very useful when things are broken) feature since linux first got a kernel command line, back before grub existed.
This sounds like a way of cutting out independent software developers. If a distro becomes nothing more than a build system configuration, and it’s not really in the gift of the end user to change that build system, how are third party packages going to be installed?
It’s kinda crazy as it is already…
Other OSes don’t have this problem. I can, for better or worse, install Windows and that will update itself. I can install Firefox and that will independently update itself. No problems.
And that's a reason to follow suit in a general purpose desktop OS is it?
LP / RedHat seems fixated on mimicking mobile OSes. Gnome on the desktop with Touch Friendly sized UI controls? Total control of app ecosystem? One way, their way, in which things are done? What's the problem with just having a decent desktop OS, like everyone else now focuses on (now that Ms has given up trying to make Windows look like a touch-friendly OS).
> This brings it into line with the Linux kernel itself
That almost sounds like once systemd has assimilated enough, the kernel will be next on the menu.
I finally worked out that one thing that systemd does and does really well better than anything else. It has become the largest attack surface, most of the recent high number (7,8,9,10's CVE's) security flaws required systemd to function.
To systemd haters: make me a Devuan that is as easy to use as Manjaro and I'll be there.
I get the arguments against systemd because Windows registry hell. Instead of arguing, go and create it.
I'd do it myself, but you know, teams of developers needed. And some of us have jobs & mortgages to pay. Funny that, redhats commercialisation creating income.
That's fair - I'd hazard that you want an appliance, not a DIY kit. I generally feel the same way about my work computer and phone, although it hurts every time I hit their arbitrary limits. My personal machine runs Slackware, and while I do like things to work reasonably smoothly, I don't want them to be "easy" because that generally implies taking away choice. I place significantly more value on flexibility, customisability, and transparency of the system.
For example, I've swapped out the BSD-style init scripts of Slackware for an s6-based system (purely for personal preference, and as an experiment) with a bit of work but minimal pain, but I see no way to make something like that easy. Or, printing from my machine is currently broken, but I know pretty well where it's going wrong because I can follow the data path through CUPS and various filters scripts it calls in its execution in as much detail as I want. I prefer my printer system to be broken but visible and easily dissected rather than working but inscrutable, and I have confidence I'll fix it eventually precisely because it's so open. Given the same issue on Windows or OS X, I'd give up and buy a new printer.
I've used systemd-based distros (mainly on RPIs), and didn't like their restrictive nature. I'm happy there's still a niche in the Linux world that caters to my use case, despite creeping systemdization, and if there comes a day that even Slackware adopts the appliance model, I'll jump ship to FreeBSD while cursing Pottering for finally destroying my niche. The BSDs have their own issues, but at least I agree more with their design philosophies.
tl;dr, I think our use cases are mutually exclusive, because easy-to-use and DIY are opposite ends of a spectrum.
Pretty much, yes. I like the concepts of avoiding systemd but as a desktop consumer; the distros without need significant user knowledge to get anything out of them. Manjaro, mint, even Arch I can be running steam in 5 minutes from a blank ssd.
I’ve fought with gentoo as a learning exercise from the ground up; and while it obviously works; it is wholly unsuited as a daily drive. Cue someone saying ‘I daily drive it’. Good for them! Was the DIY element fun/interesting? To a certain extent. Would I want to be in that world all the time? Nope. Is the option a good thing? Yes.
As for “why don’t I like windows” don’t get me started on that one. Absolute hatred since win 8. And barely tolerant before back to 95.
The downvotes above are amusing and demonstrate the fallacy that while making your own furniture is possible; sometimes you just want the kit from IKEA. And consider a mass market user. They don’t give a hoot what systemd is; if you want to encourage users to try something else; it needs to be every bit as convenient or they will give up on it. Devuan, and Debian are both bloody awful to an uninitiated user. Both would do well to act on that (akin to pushing water up a hill that request. Especially debian). C’est la vie.
Small, modular, does one job well. None of which applies to systemd.
systemd is a monolithic behemoth which sticks its nose into way too many things for its stated purpose: being a service manager.
eg One of its jobs is to start a logging service: not BE the logging service.
And when ever it goes wrong, it's an absolute mare to debug. I just counted 1380 .service files on an Ubuntu server install.
Still can't get why one earth Debian & Ubuntu adopted this monstrosity.
It definitely should not be trying to do MORE!!
And that solution is this.
All of your old electronic "waste", instead of recycling it,simply shred it up into tiny pieces and scatter it over a large area.
You might think this is a terrible idea, but it has reason attached to it
And that reasoning is this
When you scatter valuable precious metals over a wide area, this makes it economically unviable to retrieve, nobody is going to bother, because the only thing that motivates people, is money and profits.
This will mean we will run out of precious metals to make electronic devices.
Problem solved
Also, nobody can accuse you of being an "e-waste hoarder"
You might not have heard this phrase before, but going forward, you're going to hear it more and more often
Maybe we might start to appreciate our place in the universe, as an "at risk of extinction species"
You are so close to the future.
The eWaste has much higher concentrations of end products than mined ore.
Taking all the eWaste, crushing it up, then put it through extraction processes is the cheapest and easiest way to 'create' all those rare and not so rare materials.
We're looking at the end of mining if we already have enough materials in the re-cycling loop.
Every time I interact with systemd, or one of its tentacles, I have to use special systemd-provided tools. The logs are a particular pain. I was used to using tools such as less and grep to search for error messages, but I can't do that any more. I have to use journalctl, which seems to have fewer useful features than less, if that is possible. Maybe the features are there, but a have to learn a whole load more stuff to access them.
When it comes to reboot speed, I am inclined to think that whatever benefits systemd might have are far outweighed by the awkwardness of using it. In my particular case, there is evidently a bug in the setup, so shutdown is delayed by 90 seconds while systemd waits for something. I have no idea what. So in fact systemd can be slower than the old init scripts.
io_uring
is getting more capable, and PREEMPT_RT is going mainstream