Greg Kroah-Hartman: 'Don't Make Users Mad' (thenewstack.io) 204
From a recent report:
Greg Kroah-Hartman, the Linux Foundation fellow currently responsible for stable Linux kernel releases, shared the lessons he's learned as a kernel developer that are applicable to other developers at this year's Linux App Summit. He started by showing how he could succinctly distill the essence of the talk into a single five-word slide:
"Don't make your users mad...."
Kroah-Hartman explains that one of Linus Torvalds' most deeply-held convictions: don't break userspace. "Other operating systems have this rule as well — it's a very solid rule — because we always want you to upgrade. And we want you to upgrade without worrying about it. We don't want you to feel scared. If you see a new release, and we say, 'Hey, this fixes a bunch of problems,' we don't want you to feel worried about taking that. That's really really important — especially with security...."
If you do make a change, make sure there truly is a compelling reason. "You have to provide enough reason and enough goodness to force somebody to take the time to learn to do something else. That's very rare."
His example of this was systemd, which unified a variety of service configurations and initialization processes. "They did it right. They provided all the functionality, they solved a real problem that was there. They unified all these existing tools and problems in such a way that it was just so much better to use, and it provided enough impetus that everybody was willing to do the work to modify their own stuff and move to the new model. It worked. People still complain about it, but it worked. Everybody switched... It works well. It solves a real problem.
"That was an example of how you can provide a compelling reason to move on — and make the change."
"Don't make your users mad...."
Kroah-Hartman explains that one of Linus Torvalds' most deeply-held convictions: don't break userspace. "Other operating systems have this rule as well — it's a very solid rule — because we always want you to upgrade. And we want you to upgrade without worrying about it. We don't want you to feel scared. If you see a new release, and we say, 'Hey, this fixes a bunch of problems,' we don't want you to feel worried about taking that. That's really really important — especially with security...."
If you do make a change, make sure there truly is a compelling reason. "You have to provide enough reason and enough goodness to force somebody to take the time to learn to do something else. That's very rare."
His example of this was systemd, which unified a variety of service configurations and initialization processes. "They did it right. They provided all the functionality, they solved a real problem that was there. They unified all these existing tools and problems in such a way that it was just so much better to use, and it provided enough impetus that everybody was willing to do the work to modify their own stuff and move to the new model. It worked. People still complain about it, but it worked. Everybody switched... It works well. It solves a real problem.
"That was an example of how you can provide a compelling reason to move on — and make the change."
Oh no (Score:2)
He awoke the dragon. This will be good.
Re: (Score:3, Insightful)
And systemd did it in the worst possible way causing total confusion and annoyance among a lot of experienced users.
Other cases have been to create new "improved" programs. Like "dig" to replace "nslookup" but where dig has a completely different syntax and output compared to nslookup. There are a number of other examples as well.
What was a problem with the old "init" system was mainly that it was sequential - and not dependency oriented. But instead of re-using well-known tools a completely new bastard nam
Re: (Score:2)
Which was a problem solved earlier by OpenRC and predecessors in the Gentoo world.
Re: (Score:2)
Nothing is wrong with openrc. I use it with ARTIX Linux
https://artixlinux.org/ [artixlinux.org]
Re: Oh no (Score:2)
Differences in targets (Score:3)
Which was a problem solved earlier by OpenRC and predecessors in the Gentoo world.
It was a problem even solved by the latest versions of the that infamous older ini
There's a big difference between the parallel versions of init and OpenRC on one side, and what new gen stuff like SystemD, Upstart, Daemontools, or Apple's own LaunchD do (but also some peripheral tools like udev, inetd and cron, whose functionnality is integrated into the new gen systems).
The first category of tools basically just add the notion of dependence between initscripts in init, so instead of running everything sequentially, it will can start daemons and/or run init scripts in parallel if they do
ironically, android doesn't use systemd (Score:2)
and anecdotally my phones seem to be much better able to handle dealing with constantly changing environments and other hardware, than my laptop or desktop.
Re:Oh no (Score:5, Informative)
If you think that is the only thing wrong with sysv init I don't want my data anywhere near systems you manage, because you're an idiot.
Let's forget the mess of shell scripts, each one different enough to give distribution maintainers headaches. Let's forget the way it ignores failures on boot. Let's ignore the fact that it can't keep track of what it starts in a reliable way...
And that's just the major failures I can remember off the top of my head. This list is not exhaustive.
Not that tired canard again...
You list at least three special tools that need to be installed to parse the regular logs, but you protest against one more tool to parse the journal? And nice sleight of hand there, by implying you need multiple tools.
Well, by default journal forwards to syslog anyway, so shut the fuck up and stick with your old tools. Meanwhile, if I need some information between two points in time, I don't have to worry about error-prone regexes anymore, --since and --until work just fine, thank you very much.
Re: (Score:2)
Not sure why this is informative. What you refer to "that mess of scripts" didn't break with a new release. Just a simple thing such as the startup of Apache not working after an upgrade hasn't ever happened to me until systemd. It happened both on Fedora and Ubuntu which according to most here are the popular ones. I decided to mention them in case people think I'm talking about an obscure version. It happened again this year.
As for syslog it only helps when you are the original maintainer of a system. It
Re: (Score:3)
That 'mess of scripts' means you have to accept whatever whoever wrote it on faith, because there is no unity in how those scripts manage services nor even unity in scripting style, and changing it for your own needs is therefore horribly fragile. I mean, Debian is about the best in unifying the init script code, and it still is a mess of different styles; and don't ask the Debian maintainers how much they love maintaining those scripts. There's a reason distro maintainers were the biggest boosters of syste
Re: (Score:2)
That 'mess of scripts' means you have to accept whatever whoever wrote it on faith, because there is no unity in how those scripts manage services
Services are different, and have to be managed differently. Film at 11! Even systemd has to manage them differently under the hood, because they don't all behave the same way.
Everything systemd does with booting (including cgroups!) could have been solved with some tweaks to the init script boilerplate, especially on distributions like redhate where every init script uses it.
Re: (Score:2)
So explain to me how you are going to keep track of launched services and everything they fork, even after double forks, using shell scripts. All while being able to set a CPU resource limit on the entire bundle. No handwaving, show your work.
I'll settle for one mildly complex service as an example. Something that launches one process and nothing else is no challenge.
Re: (Score:2)
So explain to me how you are going to keep track of launched services and everything they fork, even after double forks, using shell scripts. All while being able to set a CPU resource limit on the entire bundle. No handwaving, show your work.
Sure, for $150/hr I'll write you the script. What, you thought I would do your homework for you for free? Noob.
All of the commands to manipulate cgroups are simple ones, in fact most of them are basic shell commands like mkdir, and what you are talking about is cgroup functionality.
Here's starting a process in a cgroup: https://access.redhat.com/docu... [redhat.com]
Here's some info on checking on cgroups. Mostly it's dominated by systemd-related stuff, but not all of it. For example, " The aforementioned systemctl comm
Re: (Score:2)
That's a lot of text for a handwave...
If that's all you can see there, then you are lacking in vision.
Saying that something can be done with spit and baling wire, and then showing a puddle of spit and a bale of wire, but not the actual construction is not quite the same, now is it?
systemd is doing it with spit and baling wire behind the scenes, and all the basic functionality is in the OS, and not in systemd at all. The same effort that went into making systemd suck could have instead gone into making openrc and sysklogd better. systemd added complexity, some of it unnecessary, and in the process created a whole new class of problem. It's easy to see that less effort would have reached the same goals without systemd.
Re: (Score:2)
systemd uses encoded logs that can't easily be browsed and searched with normal tools like tail, grep, sed and awk but forces the user to use the systemd specific tools
Not that tired canard again...
You list at least three special tools that need to be installed to parse the regular logs, but you protest against one more tool to parse the journal? ...
Over my 35 years of using computers, I have yet to sit at a Unix or linux-based box that did not have tail, grep, sed, and awk on it, but I've used plenty that didn't have systemd, even recently. I've even used a fair fraction of Widows boxes that had tail, grep, sed and awk, thanks to MinGW. Your premise of calling those command-line tools "special" is demonstrably false since they are ubiquitous within the Unix family, and can be found even beyond. Systemd is the special one, still.
Re: (Score:2)
If they don't have systemd, why would you want to use journalctl? They won't have a journal, so you don't need it. And if they run systemd, they will have journalctl.
Do you realise how you sound like desperately clawing for a rationalisation for your hate?
Re: (Score:2)
Let's forget the mess of shell scripts, each one different enough to give distribution maintainers headaches.
Those people are not smart enough to create packages for other people to use and should fuck off immediately. Shell scripting is a basic Unix feature, it's literally one of the bullet point features that make Unix what it is. If you can't write a shell script, nobody should be depending on you for Unix support.
by default journal forwards to syslog anyway, so shut the fuck up and stick with your old tools.
The problem with shutting the fuck up is that messages go to the binary log first, and then they get proxied to syslog. That means that they may not make it to syslog at all when the chips are down, a
I condensed it down to its essence: (Score:5, Interesting)
The essence of the conflict with systemd is this:
A) The core idea of systemd, to have a generic dependency-based event system in your OS, is a great one. It is useful fo everything from init to hardware events to cron jobs and whatever you can think of. I think almost everyone agrees with that.
B) The implementation of systemd is horrific in its cluelessness of everything we learned in the past decades and in its resulting arrogance. It is designed like a framework: Thou shalt have no other gods beside me. It is monolithic, incompatible often for the sake of being incompatible, not even not half-assed in implementing the core idea (A) either, and overall, mostly due to certain, let's say Windowsy/businessy mindsets, very inelegantly designed. I'm no friend of traditions and "doing it the old way" if the old way is bad. I prefer picking the best way we currently know. And here, I have to go with the old ways, simply out of fundamental superiority of Unix's core ideas.
Namely, what is often called "emergence". Having a huge number of possibilities with very few elements. An efficient, elegant beauty. Lego, the old-style basic bricks, is highly emergent. Minecraft is too. Call of Duty is not emergent at all. Lego's newer single-usage parts aren't much either. And ... apps ... and single-purpose gadgets are the least emergent of all. There's an app for everything because there *has* to be an app for every permutation of features to be available.
Conclusion: Clearly what we need, to bring everyone together, and keep the clueless from doing damage, is something that does (A), but not (B). In a way that follows the Unix principles: Small parts, great interfaces, fitting right in. (I favor implementing ideas from Plan 9 and Inferno too, due to even higher emergence.)
If somebody implemented such a system, everyone from both "sides" would welcome it.
And to be frank, it could very very likely be done on a single weekend in a single shell script. Given a smart enough mind.
(Another advantage of emergence: Very few parts to implement. But at the cost of requiring higher brain power.)
Re: I condensed it down to its essence: (Score:3)
Why: Can anyone name me a distribution which allows transparent, seamless TPM-backed full disk encryption in a couple of clicks? How about a distribution which can ship pre-signed out-of-tree drivers and correctly revoke them when they are found to be vulnerabl
Re: (Score:3)
Hey seems we CAN find points of agreement! Just not on politics.
A) The core idea of systemd, to have a generic dependency-based event system in your OS, is a great one. It is useful fo everything from init to hardware events to cron jobs and whatever you can think of. I think almost everyone agrees with that.
Basically yeah I agree. An OS is more than just a kernel, and there's plenty of room for infrastructure beyond libc. And dependency resolution for this kind of thing is a fine idea. I remember donkeys y
Re: (Score:2)
systemd and its hooks have broken dozens of interfaces and even code from journaling, alsa sound, mounting, etc.
And how about UEFI and UUID.
Python is busy with an upgrade that has rended dozens of packages drozen for MONTHS
Re: (Score:3)
Anyone that thinks that systemd was a great idea should have made a completely new OS instead of creating a crippled.
On what would you base this Operating system? Is someone forcing you to use a distro that uses systemd?
This whole systemd versus not systemd is so reminiscent of the editor wars. Or James T Kirk versus Jean-Luc Picard for that matter.
The gnashing of teeth and yelling would be a lot more convincing if there were no options.
But there are plenty of options: https://www.slant.co/topics/18... [slant.co]
Or of course, you could roll your own distro.
Re: (Score:2)
It seems that's exactly what they're trying to do, it's like a parasite eating Linux from the inside out.
Praising systemd? (Score:5, Funny)
Oh boy... *grabs popcorn*
Re: (Score:2)
Being that Systemd has been around for about 10 years now. You think that most of the "Experts" would be able to get a grasp of it now, and stop complaining about it.
To make Systemd a popular option loved by all, I propose making a new system manager software. I doesn't need to be good, just popular enough to get some attention. Than everyone will be like, don't get rid of my beloved systemd. We all love systemd why change it?
Re:Praising systemd? (Score:5, Interesting)
Yeah. For people who actually have to use this stuff in day to day work, SystemD was a godsend. Its *so* much cleaner to introduce new daemons etc. There where a few head scratchers at first, but for the most part once you understood why those things where there, they made perfect sense.
I also think its why you just dont see as much complaining about it anymore. Its an old dispute and most came to realise that trusting your system stability to crudely hacked together bash scripts wasnt really a sustainable way to build systems.
Re: (Score:3)
Actually, as someone taking of these systems as a profession for nearly 40 years... It was NOT a godsend.
It's been a godforsaken nightmare of unexpected side effects of poorly thought out design. When it works correctly, it's simply a replacement for init and the "stuff" that surrounded it. When it doesn't it's a huge "cluster" that distracts from the work at hand and a time sink.
Re:Praising systemd? (Score:5, Insightful)
I agree, 30 years of use here, it made a few corner cases easier, and made day to day work different enough to be a huge pain, without any gain.
It also introduced a bunch of complexity that was unwarranted, and broke a LOT of older maintenance/admin tools that just worked.
It has also shown absolutely NO form of community engagement, which is probably more of a problem than all the other issues.
It just keeps adopting dumb ways of doing things, when way WAY better ways are well understood because it seems to need to be 'different'
Re: (Score:2, Interesting)
Well, if you post constructively to the mailing list, you're likely to get a decent response. If you don't believe me, just go read the archives. Plenty of people posting and getting thoughtful answers.
It's true that they didn't participate in the flame fest here on Slashdot, though. I wonder why.
Re: (Score:2)
You seem to be in a minority of people having problems with it. The reason almost every distro and all the commercial Linux vendors have adopted it is because it works so much better for them.
Is there something unusual about your configuration that it doesn't work well with? You must have some fairly unique set up if most people are finding it okay but you are not. If you can identify the issue it might get fixed.
Re: (Score:2)
Dunno. If Gnome didn't depend on it would it really have gotten the traction to spread out to non-redhat based distros?
I've always felt it somewhat weird that the needs of a single desktop environment was able to force such a pervasive change across so many distros and installs, including those that don't use a GUI at all.
billions of android users (Score:2)
are using linux and are not using systemd.
Re: (Score:2)
I have a few issues with their design choices, like using '-' to replace the '/' path separator in unit names, but that only comes up if you do things like create a root .mount unit. And it feels a tad overengineered in places.
But overall, it's superiority in tracking state of the entire service and its dependencies by whacking everything that forks from the service unit in its own cgroup, and as a bonus giving me reliable service-level resource control was indeed a godsend.
Re: (Score:3, Insightful)
The solution to crudely hacked together BASH scripts is crudely hacked together C code?
That's not especially reassuring.
There are still complaints about systemD, but they're a sort of background radiation not like pulse audio fucking up yet again. System D is a rainbow idea, but poorly implemented and poorly conceived. It also follows the modern style of being hugely intrusive where lots of things have fairly deep requirements on it.
Being somewhat poorly designed meant it just replaced or set of problems wi
Re: (Score:2)
People stopped complaining because nobody is listening. It's 2020 and Apache, as one example, breaks on upgrades. In order to trust system stability it needs to work after the upgrade not just on new installations.
Re: (Score:3, Insightful)
Yes, and they were such a tiny minority that they all flocked to a minor Debian branch that has so much trouble keeping up with their upstream, it took them until this year to catch up. And they're dependent on the good will of the main Debian maintainers to help them keep up, so much so that they at least started behaving civilly on the mailing lists.
Give it up. Systemd is software, it has its normal share of flaws, but the majority of comp
Re: (Score:3)
It shows by the leaps and bounds that Linux is making against all other OS's. You are right systemd is software that has it's share of normal flaws that now brings down the whole installation and not just the service after an upgrade. I'm not being smug but I dread a Linux upgrade more than I dread a Windows upgrade and I try to avoid Windows upgrades as much as I can. The only upgrades I don't dread are FreeBSD. I haven't had a FreeBSD upgrade fail yet, even with complex installations with jails, vms and L
adopted? (Score:5, Insightful)
BS.
SystemD was enforced (adopted would be far too kind) because 'Redhat'. End of conversation.
There was no debate, there was no choice, there was no input. SystemD was simply done, like it or not.
THAT was a huge part of the problem.
Counting is challenging, sometimes (Score:2)
Re: (Score:2)
systemd did it right? (Score:4, Interesting)
It provided _one_ genuinely usseful function. Logging of kernel activity at boot time. There were several working daemon activation tools more powerful than SysV init scripts, such as upstart and damontools. Systemd has been inserting itself into DNS (which was done more safely and more robustly with nscd), into user permissions, into automounting (which worked more safely and more predictably with autofs), with wifi configuration (which it's profoundly destabilized) and even for terminating processes when people log out (which broke nohup and backgrounding jobs)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: systemd did it right? (Score:2)
Get a therapy, please.
And read my other bigger comment up there. (The one with the parts in bold.) We're, not enemies. We want the same thing. People like you are only painfully clueless. Including in their awareness of their cluelessness. But not to blame... It't not like wisdom comes with birth. I was clueless too. It takes somebody to offer them the information, so they can grow said clue, decide for themselves. So I'm not leaving a brother hangin, as they say. Read my other comment. If it does nothing e
"into a single four-word slide" (Score:2)
Counting is hard.
Re: (Score:3)
Meh. Off by one error.
Re: (Score:2)
it's a classic one off problem./p
Or go the Microsoft route (Score:2)
And push Windows 10 to everyone, independent of when/if they want to upgrade. Either way's good.
Re: (Score:2)
Not everyone. It turns out that if you use the OS-supported feature to migrate home directories to a different drive (my work machine has the OS on C:, which is an SSD, and the user directory on E:, which is spinning rust), the upgrader fails. Just another example of top quality QA by Microsoft.
Re: Or go the Microsoft route (Score:2)
Do directory softlinks and mounts finally work? I still remember that there seemed to be two kinds of paths on Windows. old ones and new ones. New ones included network drives, and apparently mounts and symlinks too. And a lot of stuff simply fell flat on its face whenever it encountered a new-style path. Because it was not transparently implemented, it seems.
If you knew everything better than your users (Score:2)
who would care about users ?
Re: (Score:3)
Re: Or go the Microsoft route (Score:2)
Well the whole architecture of systemd is windowsy and businessy. Selfish instead of cooperative. Exclusive instead of social (=compatible). Monolithic and frameworkey. Everyone can see that. That's the whole point. Not the idea behind it.
But I don't hate Poettering. How can you know that which you do not know you do not know? Kid hasn't got the first clue and sticks to an evironment of people who do not either and yes men because it feels good. Grows extremely overconfident. And other, more humble or also
systemd - bad example (Score:4, Informative)
systemd broke my DNS. i figured out how to work around it.
Re:systemd - bad example (Score:4, Insightful)
Funny, I just learned that systemd-resolved exists today when I was trying to track something down. I guess it's fine but I don't really understand what problem it was trying to solve.
Re:systemd - bad example (Score:5, Insightful)
I just learned that systemd-resolved exists today...
I guess it's fine but I don't really understand what problem it was trying to solve.
Like many systemd modules, it was developed to solve the problem of it not being built into systemd.
Re: (Score:2)
Ha you beat me to it
Re: systemd - bad example (Score:4, Funny)
You just forgot to install the "systemd-kernel" module to replace Linux. ;)
It comes with the systemd-pc that I got in my systmd-apartment when I switched to systemd-life.
Anyone know when systemd-universe comes out? Can't be far off. I heard Poettering in private already goes by the name Nyarlathotep.
Change Icon Colors and Shapes (Score:2)
But did you change icon colors and shapes for no reason?
No? Well, then you are not competing very well with G**gle
Meanwhile, at Mozilla (Score:2)
systemd (Score:5, Informative)
"That was an example of how you can provide a compelling reason to move on"
Yup, that's honestly what got me to move on to FreeBSD.
"dont break user space", well that's EXACTLY what systemd did. it took on average twice as long to diagnose service issues when they arose in the systemd world compared to prior. I don't give two fucks if it saves me some boot time on a server that already takes minutes to boot. I care about when shit hits the fan, how quickly can admins get in and do their job to restore service.
FreeBSD was initially used as a "backup" system so to speak, an entirely different platform in case a crippling kernel bug broke production (happens more often than i'd like to admit) - but after the troubles with systemd, we found that maintaining FreeBSD was actually quicker and simpler than pre-systemd linux, so we made the switch.
Re: (Score:2)
saves boot time? It doubled it and more for my systems.
It "says" it finished starting things... But they're still starting up long after is says it finished.
They're still starting because they're all contending for resources... But they all started at the same time and waiting for something to finish.
Re: (Score:3)
saves boot time? It doubled it and more for my systems.
It "says" it finished starting things... But they're still starting up long after is says it finished. They're still starting because they're all contending for resources... But they all started at the same time and waiting for something to finish.
Like with Windows, the boot to login prompt time is very quick, with things starting up in the background but if one actually tries to immediately login, they'll notice the system isn't actually entirely ready, but the vendor/developers can still boast a apparently quick boot time. For some reason, this seems to matter to someone, somewhere; I find it annoying.
Re: systemd (Score:4, Insightful)
I imagine your workflow doesn't involve the continuous, scripted booting up and shutting down, on demand, of hundreds of also-automatically built VMs, otherwise any reduction in boot times for those VMs, even if it's of just a few seconds per instance, would matter very, very much for you. In fact, they not booting in barely a few seconds would cause literal monetary loss for your company.
Systemd caught because VMs became the main source of boot ups, not bare metal. Bare metal taking minutes to boot followed by uptimes of hundreds of days is fine. VMs taking minutes to boot for uptimes of also minutes isn't.
systemd "They did it right". Seriously? (Score:4, Informative)
Breaks user-space like nothing did before. Basic stuff, can't keep its hands off your mount points, issue opened in 2015, still not fixed today but "locked as too heated" since earlier this year: https://github.com/systemd/sys... [github.com]
Re: (Score:2)
Well, for some very VERY small subset of "it." And if you start disabling the broken ancillary services that it grew like some mutant monster - right now, it's best to get rid of stuff like the broken "internal" dhcp client, the ntp service, the resolver service ... add your favorite "you'll get less functionality and you'll like it" piece of systemd-adjacent pseudo-cake.
Besides, it seems dear old Greg is getting forgetful in his advanced years. One might want to take a trip down the memory line to the poin
Re: (Score:2)
I don't work on systemd or have any dog in the race, but one thing is for sure - from my vantage point, systemd critics do themselves no favours when they come across as utterly unreasonable whiny bitches. Whatever sy
Re: (Score:2, Informative)
Oh fuck off with your long-debunked talking point.
The use of the general debug parameter for user space applications is admitted by the kernel devs to be completely appropriate. What caused the shitstorm in the first place is that despite this being noted in the docs, some hotheads immediately said systemd couldn't use it, and the ensuing discussion with systemd guys going "The docs say we can" camouflaged the real reason this broke, a buggy assertion in systemd filling up the kernel log buffer (a too verbo
Social media begs to differ (Score:5, Informative)
Systemd (Score:4, Interesting)
No. It does not work. It causes a ton of problems - and removes the abilty to isolate them and debug them . We complained because it was a hideous pile of shite with a complete avoidance of "Unix philosophy".
Wifi is fucked by systemd. Particularly hideous is the handling of static IPs on Wifi,
I have put my money where my mouth is .... and moved my workstations and laptops to Devuan, and my servers to OpenBSD, and now I am slightly happy.
The people I support are OK with Devuan+Mate - assuming they notice any other differences than that it does not randomly crash. The only complaints I have had with Devuan Beowulf+Mate is that by default, you cannot click in a directory window and do "open a terminal here", and that, on some machines (???) you cannot click on "logout" and then do switch user (I do not think "switch user" should be part of logout anyway, but it is really useful to be able to login to someone else's machine as me, fix some settings with sudo, and then logout without screwing with their session). (That is not true - handling of high dpi screens is pathetic).
Re: (Score:2, Interesting)
Re: (Score:3)
"We complained because it was a hideous pile of shite with a complete avoidance of "Unix philosophy"." in that case so does the kernel, X etc.
That's what people who don't understand Unix always say.
Unix programs should be as small as possible. Even X is that. It's not one big binary, X has lots of smaller programs. Anything that doesn't need to be part of the server isn't. Same for the kernel.
Those who do not understand Unix are doomed to leave comments proving that they don't understand it.
Good luck with that... (Score:3)
Nowadays, it seems people get mad completely blindly, regardless of it being in any way related to reality or what you meant.
So in reality, unless you know everyone's ridiculous triggers, of which they are usually completely unaware and refuse to even attempt to become aware of, users *will* get mad.
And then statistics enter the match... Given enougj users, some will *always* become mad. No matter what it is. Even "Hello" will trigger a trauma in some people on this planet.
To make matters worse, the Internet sprays napalm into that fire by enabling a mob mentality, so that before you know it, you're in the headlines for a 'scandal' of whatever some nutter could make up and twist into interpreting it as 'discrimination', no matter your intentions. ... Yet, here we are.)
(Literally nobody associated the usage of the master/slave terminology in IT with thinking lesser of black people. Then only ones that did think that way, already did so before. And yes, that set specifically includes the SJWs who screamed "racism!". *They* thought like that. *They* discriminated with the prejudice of assuming people who say that are racists.
So clearly, being a spineless windsock, trying to please everyone, is not the solution. SJW and other bullies will walk all over you and wipe the floor with you.
And they already started. Just look at Linus.
Ribbon on windows explorer??? (Score:3)
Re: (Score:2)
I in general despise the simplification of UIs. The problem is that they're trying to cater to two different kind of input modes: Touch (which requires ample whitespace) and mouse and keyboard. Since it's easier to have just one UI we get the lowest common denominator and thus, mouse and keyb users, have
Biggest reason to use Windows (Score:2)
You can still install and run apps written and compiled for Windows 95 in most recent version of Windows 25 years later. Try that with Linux, I dare you - run a binary from slacker on latest Ubuntu. I've used Linux since the 90's, but really hate the Linux community "fuck backwards compatibility" attitude, so I only upgrade when I absolutely have to, and stick with LTS releases as long as they are supported purely for security patches. So many times since the 90's I installed a new Linux release, only to fi
Re: (Score:2)
Re: (Score:2)
Ah yes, the no closed source applications or drivers for Linux approach - less applications and less hardware support is definite selling point to you? That said, I bet plenty of applications with source from 1995 would still not compile today, but you clarified you beliefs perfectly with "Linux users care about Linux" - a fanatic approach to a latest and greatest, bleeding edge, non-backwards compatible OS perfectly describes why Linux has the reputation it does today - a research project, not a product. I
Re: (Score:2)
Re: (Score:2)
The point is not that you can run 30 year old app, the point is that in 30 years backwards compatibility was not broken, which means you can run 2 year old app, 5 year old app, even an 8 year old app, etc. If you have something which does the job, why would you want to go through the trouble of reinstalling, possibly buying a new version of the software (especially if you have absolutely no need for any of the new features, or worse, some features you were using are no longer available), and learning all ne
Re: (Score:3)
You can still install and run apps written and compiled for Windows 95 in most recent version of Windows 25 years later. Try that with Linux, I dare you - run a binary from slacker on latest Ubuntu.
OK, I'll bite...
yes you can. If it was statically compiled then I bet you it still just runs. If it wasn't statically compiled and you didn't ship all the dynamic dependencies like you would have done on Windows, well, you made a mistake that many people made but isn't really the fault of Linux. Hell, Linux sti
Apple should take note (Score:2)
don't break userspace.
I know someone who recently had their Mac auto-upgrade to the newest release. Upon completion, they found out the upgrade had either wiped out their email or rearranged it across the OS. They aren't sure which. Whereas before they had one Inbox, they now had six, all named differently, and when email did arrive, it didn't go where they wanted it.
Apparently this new "upgrade" is trying to use "AI" to figure out where to put things. Now, when an email is received, it's a treasure hun
Re: (Score:2)
Re: (Score:2)
My example would have been Firefox, they have repeatedly annoyed the hell out of their user base.
Predictable responses... (Score:2)
How can an article like this not result in another screamfast about the evils of systemd? But, as someone without skin in the game (I don't give a flying fuck about init systems), perhaps I can ask this: why have so many distro's switched to systemd, then? Were they all bribed? Are all those distro maintainers stupid? Or do they see something of value in systemd?
Re: (Score:2)
Things started using systemd.
So they used systemd to use the things.
Then because you have systemd, other things started using systemd.
Before you know it, they're all using systemd, and all the thing require systemd, for no real obvious reason.
And then when you want to make a distro that doesn't use systemd, you have to patch all that stuff out, and when you then use some unrelated component, it's pulling in systemd anyway.
I have no objection to the concept of systemd, but the execution is absolutely dire an
systemd (Score:2)
I think presenting systemd is a good change just rubs salt on some wounds.
I will be fair. It really solves issues for *some* scenarios. For example, unattended virtual machine deployment, or management of large fleets. There are probably others that benefit, but not me.
Me, personally, once again become novice to Linux administration. The tasks I could do from memory for over 20 years became very difficult. Some, impossible. The simple things like using a custom X11 server config requires going through many
systemd "did it right"? (Score:3)
Horseshit.
Why would you need a seperate journal file that can *only* be read by a tool, rather than plain text - are you going to talk about "lack of space"?
Why would you move the configuration out of /etc, where *all* configuration should be?
Why would you make the who procedure of enabling and starting a new service so much *more* complicated, and break old initialization?
No. There was a reason that debian partly split.
Re: Who? (Score:5, Informative)
His name is Greg Kroah-Hartman. He is the Linux Foundation fellow currently responsible for stable Linux kernel releases.
That info is a little hard to find, though.
Re: Who? (Score:4, Funny)
Re: Who? (Score:4, Informative)
Re:Who? (Score:5, Funny)
You could at least read the first sentence of the summary!
Re: (Score:2)
Re: Who? (Score:2)
Go back to Reddit if yo don't even know that.
What's next? "Who is this Torvalds guy?" "Richard Stallman? Eric S. Raymond? Rob Malda? Who are these people?
Re: (Score:2)
Your tinfoil hat fell off.
Re: I'm cyberbullied by mega corporations. (Score:2)
Good. Apparently a tinfoil hat is a gread parabolic dish / mind ray concentrator. ;)
(Disclaimer: I know how to build a ray to make people hear voices or alter their mood, but I find it much easier to just use their traditional neural inputs for delusion and false memory creation. ;)
Re: (Score:2, Insightful)
Re: slow clap (Score:2)
As somebody who compiled Gentoo from stage 1 with custom compiler and linker flags fifteen years ago and still has the same installation running squeaky clean, several complete hardware and platform changes later ...
We are exactly the LEAST likely to ever touch systemd with even a ten bigfoot transdimensional toxic waste stirrer.
My init system is half self-programmed. You think I'm replacing that??