Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Linux

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."

This discussion has been archived. No new comments can be posted.

Greg Kroah-Hartman: 'Don't Make Users Mad'

Comments Filter:
  • by MrNaz ( 730548 )

    He awoke the dragon. This will be good.

    • Re: (Score:3, Insightful)

      by Z00L00K ( 682162 )

      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

      • What was a problem with the old "init" system was mainly that it was sequential - and not dependency oriented

        Which was a problem solved earlier by OpenRC and predecessors in the Gentoo world.

        • by MrBrklyn ( 4775 )

          Nothing is wrong with openrc. I use it with ARTIX Linux

          https://artixlinux.org/ [artixlinux.org]

        • OpenRC did not (at the time) provide proper support for things like cgroups, namespacing, user-initiated services, device-triggered services, network-triggered services, SELinux MCS and much, much more. systemd fixed a whole raft of basic issues which other OSes solved a long time ago and with any luck, it will begin to implement stuff like protocol-aware port sharing too.
      • Re:Oh no (Score:5, Informative)

        by mvdwege ( 243851 ) <mvdwege@mail.com> on Monday November 30, 2020 @03:14AM (#60777504) Homepage Journal

        What was a problem with the old "init" system was mainly that it was sequential - and not dependency oriented.

        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.

        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? 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.

        • by MeNeXT ( 200840 )

          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

          • by mvdwege ( 243851 )

            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

            • 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.

              • by mvdwege ( 243851 )

                Everything systemd does with booting (including cgroups!) could have been solved with some tweaks to the init script boilerplate

                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.

                • 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

        • by pz ( 113803 )

          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.

          • by mvdwege ( 243851 )

            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?

        • 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

      • by BAReFO0t ( 6240524 ) on Monday November 30, 2020 @04:09AM (#60777574)

        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.)

        • Having the one framework is actually a good thing in this instance and I would almost say it does not go far enough. It should take over kernel module loading, automatic driver management, disk encryption and Secure Boot too - just to name a few.

          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
        • 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

      • by MrBrklyn ( 4775 )

        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

      • 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.

      • by msauve ( 701917 )
        >Anyone that thinks that systemd was a great idea should have made a completely new OS

        It seems that's exactly what they're trying to do, it's like a parasite eating Linux from the inside out.
  • by Dutch Gun ( 899105 ) on Monday November 30, 2020 @12:29AM (#60777314)

    Oh boy... *grabs popcorn*

    • 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?

    • We already know that /. editors can't edit. You don't expect them to be able to count, do you?
  • by Anonymous Coward on Monday November 30, 2020 @12:31AM (#60777322)

    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)

    • by dargaud ( 518470 )
      I've been trying to figure out why recently you cannot switch users anymore in KDE. The menu option is gone and the sddm option is gone. My wife has to forcefully shutdown my laptop if she needs to use it now. And investigating it seems to reveal the involvement of systemd...
      • its on my menu, maybe someone has been fiddling with your menu options
        • by dargaud ( 518470 )
          Nope, a lot of users are complaining about it, no solutions or workarounds yet besides waiting for updates...
  • And push Windows 10 to everyone, independent of when/if they want to upgrade. Either way's good.

    • by pjt33 ( 739471 )

      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.

      • 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.

  • by Skapare ( 16644 ) on Monday November 30, 2020 @01:01AM (#60777368) Homepage

    systemd broke my DNS. i figured out how to work around it.

  • But did you change icon colors and shapes for no reason?
    No? Well, then you are not competing very well with G**gle

  • The malignant echo chamber of imperious wokeness decides that you are compelled to take their fucking upgrade immediately, unable to open a new tab until you destroy all of your visual context.
  • systemd (Score:5, Informative)

    by darkain ( 749283 ) on Monday November 30, 2020 @01:15AM (#60777392) Homepage

    "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.

    • 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.

      • 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)

      by alexgieg ( 948359 ) <alexgieg@gmail.com> on Monday November 30, 2020 @04:49AM (#60777624) Homepage

      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.

  • by itsme1234 ( 199680 ) on Monday November 30, 2020 @02:30AM (#60777444)

    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]

    • 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

      • So you want Greg to keep harboring all past issues as grudges through all of time and not, maybe, keep track of whether things have improved over time? Furthermore, you want Greg to keep banging on about one incident over and over again instead of taking a long-sighted view of the situation?

        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)

        by mvdwege ( 243851 )

        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

  • by niftydude ( 1745144 ) on Monday November 30, 2020 @02:46AM (#60777458)
    Facebook and Twitter keep their users engaged by making them mad. It's the majority of their business model.
  • Systemd (Score:4, Interesting)

    by Anne Thwacks ( 531696 ) on Monday November 30, 2020 @03:03AM (#60777482)
    His example of this was systemd, ... "They did it right. They provided all the functionality, they solved a real problem that was there. ... It works well. It solves a real problem.

    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)

      by Barsteward ( 969998 )
      "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. As to the rest of your whine about being an old dog not wanting to learn new tricks, most others find it works just fine.
      • "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.

  • by BAReFO0t ( 6240524 ) on Monday November 30, 2020 @03:38AM (#60777540)

    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.
    (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. ... Yet, here we are.)

    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.

  • by AndyKron ( 937105 ) on Monday November 30, 2020 @04:47AM (#60777620)
    A solid rule not to piss off users? Who forgot to tell Microsoft?
    • You think Ribbon is bad? Wait until Explorer is rewritten in the "touch-first" style of "Settings". Then you'll have a better reason to be mad(not that I don't understand the reasons to dislike the ribbon).
      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
  • 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

    • Firstly, Linux provides the capability to compile the source code of your favourite application. Try to do that with your 25 yo Windows app. Secondly, Linux doesn't care about the users and their desktops. The users care about Linux.
      • 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

    • Yeah, that's a huge reason to use Windows. The ability to run 30 year old binaries is a great thing. If there's something Windows does right is backwards compatibility including certain APIs working in a certain way depending on the application being run. That's obviously not something good generally, but in this case was used to get apps that used the APIs in a wrong way working on newer versions of Windows.
      • 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

    • 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

  • 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

    • FYI, macOS does not auto-upgrade. You actually have to get in there and explicitly press the Upgrade Now button to do it, and not once, and you have to provide your password, too, if memory serves correctly. They do it right, unlike some other OS I've encountered. Now, I've no idea as to how your acquaintance's mailbox fubared. I am not saying it cannot happen, even though I upgraded my Hackintosh to Big Sur with zero glitches. Just – no idea how that could come to pass. I've upgraded from 10.4 on and
    • My example would have been Firefox, they have repeatedly annoyed the hell out of their user base.

  • 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?

    • by ledow ( 319597 )

      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

  • 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

  • by whitroth ( 9367 ) <whitroth@@@5-cent...us> on Monday November 30, 2020 @12:45PM (#60778932) Homepage

    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.

"The pathology is to want control, not that you ever get it, because of course you never do." -- Gregory Bateson

Working...