13 ms·

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've re

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragmented and sometimes many places you have to look for error logs. Fed up with the many files you have to edit to configure the network correctly (different on every major distribution). Fed up with the half dozen ways to configure X, where X is a common function to every modern operating system. It seems Lennart has taken the advice and followed through, and distribution maintainers liked it. They liked the idea that someone was taking all this complicated work - this dirty, boring to write and maintain code - and making their lives easier. Why else would nearly every distribution be on board? Systemd is offering a more compelling solution than anyone else, and if you don't like it, well, you should submit a patch, write some code, or implement it yourself.

badgersandjam 12y ago
I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never lost that much time on a system function before. This is not what I expected and there is no way I could possibly introduce that to our production environment. I think that might why people are slightly sensitive to it. Yes you're exactly right, but replacing something with something less stable, more complicated and more difficult to debug isn't a rational or good engineering. I'm sure many people will be fed up with systemd much quicker than what was already there. Not impressed with a community which pushes this as stable, quality software. Voting with my feet: FreeBSD is being trialled instead. WhatsApp throwing a million dollars at it draws a lot of valuable attention and puts it in the business's mindset. Choice is as much of a valuable aspect of open source too...
- paulfurtado 12y ago
  Out of curiosity, what ended up being the root cause of the timedatectl problem?
  - badgersandjam 12y ago
    Absolutely no idea. It just went away spontaneously which is even more worrying as that suggests the system is non-deterministic. I don't have the error on my phone which I'm on at the moment but it threw a dbus error with no debug info.
    - watt 12y ago
      It must be a hardware problem on your side, dude. Simple as that. I imagine 10 years ago you would be the person complaining that GCC segfaults randomly during compiling Linux kernel, complaining that it's not "tested completely". While the segfault was caused by CPU overheating (not cooled properly) and flaky memory (causing bits to flip).
      - badgersandjam 12y ago
        Known good HP DL380 G8 pulled from production, ECC RAM, monitoring, SAS disks, full hardware test and memtest86 pass. Nope. Not that. We don't buy crappy hardware or not test it.
      - dap 12y ago
        Dude, prove it. The system should be able to exonerate itself by detecting and reporting those problems (and other systems do). At the very least, point to some actual evidence. This is the "engineering" process that the parent poster referred to elsewhere. Just because a problem is unusual, intermittent, or only affects one person doesn't mean it's not a regular old software bug. And in my experience, it almost always is. And once you do debug it, you often (but not always) understand why it was intermittent, under what conditions it happened, and why you were the only person that saw it.
    - ambrice 12y ago
zackelan 12y ago
I completely agree with you that Lennart scratched an itch, which is the way all good software gets started, and others picked up on it. Where I think the systemd-naysayers have a valid point is around the tight coupling that has been introduced, and is still being introduced, between systemd and various other components of a fully functional Linux system. To take your "just submit a patch" example - say N years from now I'm unhappy with some aspect of how systemd works. I can submit a patch, or I can rewrite that whole component from scratch. However, it's entirely possible that the piece I'm unhappy with is so tightly coupled to the rest of systemd that I can't rewrite one component of it without rewriting the rest of systemd, or convincing the systemd maintainers to accept my rewrite and bake it in as the new "official" version of that component. Where I think the criticism of systemd is valid is that the idea of modularity has taken a backseat, and the APIs between the different components of systemd haven't been very well-thought-out. The informal spec is "whatever systemd does today is correct", which of course destroys any sort of interoperability. And by way of full disclosure, I'm an Arch user, and run systemd on 4 systems I use everyday - home desktop, home server, work desktop, work laptop. Whatever else I have to say about its design, I use it every day, and actually like the parts of it that I use. eg, the boot time for my desktop is stupidly fast, and if I want to know about some log message, I just run journalctl. I no longer care whether the foo daemon uses syslog, or writes to its own /var/log/foo.log that I should set up rotation for, or handles its own rotation as /var/log/foo/2014-11-20.log, and so on. And just to play devil's advocate with my own position - there's a certain point where tight coupling makes sense. Linux kernel modules, for example, are tightly coupled to the Linux kernel, and don't work unmodified when compiled against a *BSD or Solaris kernel.
- hwh 12y ago
  Well, the very distro-specific bunch of scripts in /etc/init.d (or is it /etc/rc.d/init.d/? or /etc/rc.d? or a symlink to ...?) were some kind of tight coupling, too. Plus: This tight coupling did not exactly replace existing communication features. It created new ones. These are made use of. Yes, systemd is bringing lots of new functionality. Under the hood - that is why sysadmins love or loathe it and users mostly don't care. That "tight integration" argument is mostly one that comes from people (please do not take offence, you're weighting it carefully indeed!) who bemoan that other userspace system infrastructure is left behind feature-wise. And those who love to argue about and against design decisions.
deleted 12y ago
[deleted]
rythie 12y ago
You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.
- XorNot 12y ago
  You can fork it. You can fork all of Debian. But there's numerous reasons that's going nowhere. Most being: this is not the issue the loudest voices say it is.
  - mbainter 12y ago
    Forking a distribution will help by giving an alternative, but it's not as easy as just saying it. Maintaining a distribution is a massive effort that takes a lot of work. Building a team of people with enough time to make that happen isn't something you do overnight. The fact that one hasn't magically appeared since this started has more to do with that than anything else. (Followed closely by people generally waiting to see how this shakes out before they pull the trigger.) Second - while it will provide an alternative that helps frame the debate, this is not a minor undertaking. With every other distribution caving maintaining a distribution that does not use Systemd will require a lot of work to keep all of the software out there working properly with whatever alternative init system it chooses to use. This alternative distro is also going to have to deal with how to solve the init problem. We had some good options in play but I don't believe we'd found the best answer to the problem yet when Lennart came bowling through like a bull in a china shop. So any distribution effort is going to have to take on the role of choosing the best of breed alternative and make the effort to ensure it continues to develop and improve. This isn't something you take on lightly.
- pdkl95 12y ago
  Not only would submitting a patch be agreeing to their goals (Lennart gets to push the Overton window a bit further), suggesting that we should simply submit patches presupposes that the systemd cabal would ever accept them. Unless it is perfectly in agreement with their goals - including the complete software - they probably won't accept it. They don't even accept already written and tested patches for trivial things like #ifdef-ing a couple minor fixes so the project can build on a different libc. Lennart Poettering[1]: Humm, I know this will disappoint you, but we are not particularly interested in merging patches supporting other libcs, if those are not compatible with glibc. We don't want the compatibility kludges in systemd, and if a libc which claims to be compatible with glibc actually is not, then this should really be fixed in the libc, not worked around in systemd. If they aren't interested in trivial compatibility patches, they certainly aren't going to accept any patch that dares to disrupt their tight integration or questionable design choices. As for forking the whole thing, remember that logind was briefly liberated so it could be build as a standalone package, Lennart went and did a big rewrite so the next version was much more integrated with systemd. When he controls the internal APIs and can change them whenever he wants, a clone will have to be a total replacement right from the start, or it ends up perpetually having to catch up to the changes that will be introduced just to cause breakage. [1] http://lists.freedesktop.org/archives/systemd-devel/2011-July/002935.html http://lists.freedesktop.org/archives/systemd-devel/2011-Jul...
pjc50 12y ago
Or stop using Linux entirely and move to FreeBSD.
- icantthinkofone 12y ago
  Linux Torvalds said he would never have created Linux is FreeBSD was available at the time. And the only reason it wasn't available is because it was embroiled in a lawsuit over embedded ATT UNIX code back in the 1990s(?).
  - chimeracoder 12y ago
    I'm not sure how this is relevant. Saying he wouldn't have created Linux at the time is not the same thing as saying he wouldn't work on it or use it today instead of FreeBSD.
    - morganvachon 12y ago
      I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, hence Torvalds wouldn't have had a need to create Linux. Obviously, Torvalds hasn't abandoned Linux in favor of FreeBSD today, and no one said he has or is planning on it.
      - chimeracoder 12y ago
        > I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, But that's not at all what Torvalds's quote means. He meant that, if FreeBSD had been available, he would have worked on contributing to that instead and improving it for daily use, rather than building Linux to be used for daily use. (The state of FreeBSD in this hypothetical world has no bearing on the state of FreeBSD today). In terms of FreeBSD today, while it's possible to use it for daily use, it suffers from even worse driver issues than Linux does, and of all the problems of just simply having much smaller market share (both for contributing developers and users) than Linux does. This may or may not be 'good enough' for OP's purposes, but it's disingenuous to suggest that Torvalds's hypothetical from the early 1990s implies that FreeBSD is a clean substitute for end-user Linux today.
jbb555 12y ago
> Systemd is offering a more compelling solution than anyone else, and if you don't like it, well, you should submit a patch, write some code, or implement it yourself. Or go back to using windows for general use and software development which is in fact what I've done. It's amazingly sad after many years of being a strong linux supported but this has killed linux for me. I see no point in continuing to use it.
- badgersandjam 12y ago
  That's really not a terrible idea actually. I switch back and forth a lot between the Windows and the Unixy ecosystems and by far the best end user experience, tailored[1] developer experience and (I'm going to get slated for this), mobile experience is on Windows by far. [1] tailored as in platform specific. For cross platform stuff, it's not so good.
  - anonbanker 12y ago
    Someone created a new account in order to post a pro-windows reply in a systemd thread. Color me surprised.
    - badgersandjam 12y ago
      Sigh. Read my other posts. And my account existed before the systemd article was posted. More correctly. Someone assumed a new user was a shill for Microsoft, incorrectly... Reading your history, you might want to lay off the weed. It's linked to paranoia.
      - anonbanker 12y ago
        Nice, a personal attack at the end. I'll definitely not call you a shill now!
        badgersandjam 12y ago
        Ok perhaps the personal attack was uncalled for. Please accept my apologies.
lmm 12y ago
Lennart didn't just submit the code and put it out there. He lobbied other projects to hard-depend on it, and lobbied distros to adopt it. Systemd didn't succeed where less poisonous equivalents failed because it was technically superior (it isn't), it succeeded because of shady back-room politics.
- mdellabitta 12y ago
  How dare he ask other people to use the software he wrote.
  - fapjacks 12y ago
    I think "ask" here is the wrong word, and you know it.
    - jptman 12y ago
      I'm curious to know what kind of leverage he had over the distros where it wasn't just "ask". Any suggestions on where I can find some info?
- ngrilly 12y ago
  Let's say you're right. What kind of "political" leverage Lennard had to convince distros to use systemd?
  - lmm 12y ago
    All he would've needed was the support of RedHat management, after that everything falls into place: most Gnome contributors work for RedHat, so they can convince Gnome to follow a particular direction and hard-depend on systemd. Then most distributions are under pressure from their userbase to support Gnome (because of a legacy of politics and FUD about the KDE license, because a minimally-configurable environment is popular with the kind of large, inflexible organization that buys expensive support contracts, and because it's actually quite good software) and are therefore also obliged to hard-depend on systemd. It's in RedHat's interest for software that's currently portable to FreeBSD or especially to Solaris to become tied to Linux. This wouldn't be the first time RedHat has adopted anti-opensource methods out of fear of Oracle - compare their policy of deliberately obfuscating the history of their kernel source.
peterwwillis 12y ago
> Why else would nearly every distribution be on board? This informal fallacy is based on the idea that everything in the world can be distilled to a single answer. The real answer is more complicated. For example: Red Hat is on board because they pay its creator's salary. So they rely on an individual bias. Debian is on board because they rely upon 'collective wisdom' and committees to make decisions. So they rely on the bias of group thinking. Ubuntu is on board because Debian is on board. So they rely on the bias of the other. Other distributions are using it because 'every other distribution is using it', or they're small enough that it doesn't cause conflicts for its use base, or because it's a GNOME dependency, or because it's just new technology. -- To make someone think something is a good idea, show them someone else thinks it's a good idea. This is a fact of all human beings' thought processes. Decisions are not based on merit, or logic, or even a quorum; it is based on fallacies created by heuristics. There exists a heuristic in which the more an idea is adopted, the more other people think it is a good idea. We imagine our thoughts are logical, and that other people also think logically, and that their decisions must be made for a good reason. But in fact, the great majority of all decisions we make are based on guesses; this is how our brains are able to carry out complex calculations and come to decisions in split-seconds. For example, you might look at systemd and say, "it fixes so many problems! it provides so many features! it standardizes Linux! CLEARLY this is superior. we must adopt it." For people who care about the purity of the highest technical ideals, this makes sense. For people who care about being able to use their computer, these things don't matter, and in the systemd implementation, actually makes things worse for them. The changes systemd purports to make are not bad things. It's really just the way in which they did it that is bad. -- It's like wanting to upgrade your bicycle to four wheels, but requiring the rider now operate it lying flat down and using mirrors to navigate. The four wheels was a great idea. Using mirrors to navigate? Maybe not so great. Of course, its creators will turn this inconvenience into a feature, saying "you get to lay down! it's therefore more efficient and easier to use!", completely ignoring how other people want to ride a 4-wheeler.
blutgens 12y ago
haphazard? fragmented? many places for error logs? half-a-dozen ways to configure X? Have you ever run a linux box? How about dozens or hundreds of them in a production environment? I'm guessing no on both counts based on the nonsense you're spewing forth in your post. If you don't know what you're talking about, it's best to just keep quiet.
101914 12y ago
"Someone finally got fed up with the haphazard state of affairs in Linux-land" But wouldn't the path of least resistance be to switch to a project that does not have this "haphazard state of affairs"? When I originally tried Linux I got fed up within _days_. It is the _relative_ lack of default "configuration" (that is decided by someone else) that makes me stay with FreeBSD and NetBSD. Of course, lack of default configuration is the antithesis of popular Linux distributions. Whenever I have to use one, I spend more time learning how to turn things off than I ever did learning how to turn things on. The answer to the original question is, I think, "no", switching is probably not the path of least resistance for many Linux users. Because when the Linux user makes that switch, they immediately find that someone has not done everything for them. And from what I have seen, observing the questions of Linux users who first try FreeBSD or NetBSD, they generally do not like that. It means they have to do some configuration of their own. And even if they are comfortable doing configuration, it means they have to learn things that are different from the "Linux way"; and they inevitably encounter shortcomings that are due to lack of developer resources (read: time). In doing things for yourself you learn about how things work. The rc.d system that all BSD projects use is coherent and relatively easy to understand. For whatever that is worth. This debate over systemd seems to cut to the core of the value of learning about how things work. The reader can draw their own conclusions. Linux is only a kernel and it should still be possible and thus optional to run that kernel with a basic init (or init alternative, e.g., one based on daemontools) and with userland utilties that do not need systemd. The question I have is how difficult the popular Linux distribution folks are going to make that for their users to do. And if they do make it difficult, it raises the question, "Why?"

badgersandjam 12y ago

I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never lost that much time on a system function before. This is not what I expected and there is no way I could possibly introduce that to our production environment. I think that might why people are slightly sensitive to it. Yes you're exactly right, but replacing something with something less stable, more complicated and more difficult to debug isn't a rational or good engineering. I'm sure many people will be fed up with systemd much quicker than what was already there. Not impressed with a community which pushes this as stable, quality software. Voting with my feet: FreeBSD is being trialled instead. WhatsApp throwing a million dollars at it draws a lot of valuable attention and puts it in the business's mindset. Choice is as much of a valuable aspect of open source too...

paulfurtado 12y ago
Out of curiosity, what ended up being the root cause of the timedatectl problem?
- badgersandjam 12y ago
  Absolutely no idea. It just went away spontaneously which is even more worrying as that suggests the system is non-deterministic. I don't have the error on my phone which I'm on at the moment but it threw a dbus error with no debug info.
  - watt 12y ago
    It must be a hardware problem on your side, dude. Simple as that. I imagine 10 years ago you would be the person complaining that GCC segfaults randomly during compiling Linux kernel, complaining that it's not "tested completely". While the segfault was caused by CPU overheating (not cooled properly) and flaky memory (causing bits to flip).
    - badgersandjam 12y ago
      Known good HP DL380 G8 pulled from production, ECC RAM, monitoring, SAS disks, full hardware test and memtest86 pass. Nope. Not that. We don't buy crappy hardware or not test it.
    - dap 12y ago
      Dude, prove it. The system should be able to exonerate itself by detecting and reporting those problems (and other systems do). At the very least, point to some actual evidence. This is the "engineering" process that the parent poster referred to elsewhere. Just because a problem is unusual, intermittent, or only affects one person doesn't mean it's not a regular old software bug. And in my experience, it almost always is. And once you do debug it, you often (but not always) understand why it was intermittent, under what conditions it happened, and why you were the only person that saw it.
  - ambrice 12y ago

zackelan 12y ago

I completely agree with you that Lennart scratched an itch, which is the way all good software gets started, and others picked up on it. Where I think the systemd-naysayers have a valid point is around the tight coupling that has been introduced, and is still being introduced, between systemd and various other components of a fully functional Linux system. To take your "just submit a patch" example - say N years from now I'm unhappy with some aspect of how systemd works. I can submit a patch, or I can rewrite that whole component from scratch. However, it's entirely possible that the piece I'm unhappy with is so tightly coupled to the rest of systemd that I can't rewrite one component of it without rewriting the rest of systemd, or convincing the systemd maintainers to accept my rewrite and bake it in as the new "official" version of that component. Where I think the criticism of systemd is valid is that the idea of modularity has taken a backseat, and the APIs between the different components of systemd haven't been very well-thought-out. The informal spec is "whatever systemd does today is correct", which of course destroys any sort of interoperability. And by way of full disclosure, I'm an Arch user, and run systemd on 4 systems I use everyday - home desktop, home server, work desktop, work laptop. Whatever else I have to say about its design, I use it every day, and actually like the parts of it that I use. eg, the boot time for my desktop is stupidly fast, and if I want to know about some log message, I just run journalctl. I no longer care whether the foo daemon uses syslog, or writes to its own /var/log/foo.log that I should set up rotation for, or handles its own rotation as /var/log/foo/2014-11-20.log, and so on. And just to play devil's advocate with my own position - there's a certain point where tight coupling makes sense. Linux kernel modules, for example, are tightly coupled to the Linux kernel, and don't work unmodified when compiled against a *BSD or Solaris kernel.

hwh 12y ago
Well, the very distro-specific bunch of scripts in /etc/init.d (or is it /etc/rc.d/init.d/? or /etc/rc.d? or a symlink to ...?) were some kind of tight coupling, too. Plus: This tight coupling did not exactly replace existing communication features. It created new ones. These are made use of. Yes, systemd is bringing lots of new functionality. Under the hood - that is why sysadmins love or loathe it and users mostly don't care. That "tight integration" argument is mostly one that comes from people (please do not take offence, you're weighting it carefully indeed!) who bemoan that other userspace system infrastructure is left behind feature-wise. And those who love to argue about and against design decisions.

deleted 12y ago

[deleted]

rythie 12y ago

You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.

XorNot 12y ago
You can fork it. You can fork all of Debian. But there's numerous reasons that's going nowhere. Most being: this is not the issue the loudest voices say it is.
- mbainter 12y ago
  Forking a distribution will help by giving an alternative, but it's not as easy as just saying it. Maintaining a distribution is a massive effort that takes a lot of work. Building a team of people with enough time to make that happen isn't something you do overnight. The fact that one hasn't magically appeared since this started has more to do with that than anything else. (Followed closely by people generally waiting to see how this shakes out before they pull the trigger.) Second - while it will provide an alternative that helps frame the debate, this is not a minor undertaking. With every other distribution caving maintaining a distribution that does not use Systemd will require a lot of work to keep all of the software out there working properly with whatever alternative init system it chooses to use. This alternative distro is also going to have to deal with how to solve the init problem. We had some good options in play but I don't believe we'd found the best answer to the problem yet when Lennart came bowling through like a bull in a china shop. So any distribution effort is going to have to take on the role of choosing the best of breed alternative and make the effort to ensure it continues to develop and improve. This isn't something you take on lightly.
pdkl95 12y ago
Not only would submitting a patch be agreeing to their goals (Lennart gets to push the Overton window a bit further), suggesting that we should simply submit patches presupposes that the systemd cabal would ever accept them. Unless it is perfectly in agreement with their goals - including the complete software - they probably won't accept it. They don't even accept already written and tested patches for trivial things like #ifdef-ing a couple minor fixes so the project can build on a different libc. Lennart Poettering[1]: Humm, I know this will disappoint you, but we are not particularly interested in merging patches supporting other libcs, if those are not compatible with glibc. We don't want the compatibility kludges in systemd, and if a libc which claims to be compatible with glibc actually is not, then this should really be fixed in the libc, not worked around in systemd. If they aren't interested in trivial compatibility patches, they certainly aren't going to accept any patch that dares to disrupt their tight integration or questionable design choices. As for forking the whole thing, remember that logind was briefly liberated so it could be build as a standalone package, Lennart went and did a big rewrite so the next version was much more integrated with systemd. When he controls the internal APIs and can change them whenever he wants, a clone will have to be a total replacement right from the start, or it ends up perpetually having to catch up to the changes that will be introduced just to cause breakage. [1] http://lists.freedesktop.org/archives/systemd-devel/2011-July/002935.html http://lists.freedesktop.org/archives/systemd-devel/2011-Jul...

pjc50 12y ago

Or stop using Linux entirely and move to FreeBSD.

icantthinkofone 12y ago
Linux Torvalds said he would never have created Linux is FreeBSD was available at the time. And the only reason it wasn't available is because it was embroiled in a lawsuit over embedded ATT UNIX code back in the 1990s(?).
- chimeracoder 12y ago
  I'm not sure how this is relevant. Saying he wouldn't have created Linux at the time is not the same thing as saying he wouldn't work on it or use it today instead of FreeBSD.
  - morganvachon 12y ago
    I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, hence Torvalds wouldn't have had a need to create Linux. Obviously, Torvalds hasn't abandoned Linux in favor of FreeBSD today, and no one said he has or is planning on it.
    - chimeracoder 12y ago
      > I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, But that's not at all what Torvalds's quote means. He meant that, if FreeBSD had been available, he would have worked on contributing to that instead and improving it for daily use, rather than building Linux to be used for daily use. (The state of FreeBSD in this hypothetical world has no bearing on the state of FreeBSD today). In terms of FreeBSD today, while it's possible to use it for daily use, it suffers from even worse driver issues than Linux does, and of all the problems of just simply having much smaller market share (both for contributing developers and users) than Linux does. This may or may not be 'good enough' for OP's purposes, but it's disingenuous to suggest that Torvalds's hypothetical from the early 1990s implies that FreeBSD is a clean substitute for end-user Linux today.

jbb555 12y ago

> Systemd is offering a more compelling solution than anyone else, and if you don't like it, well, you should submit a patch, write some code, or implement it yourself. Or go back to using windows for general use and software development which is in fact what I've done. It's amazingly sad after many years of being a strong linux supported but this has killed linux for me. I see no point in continuing to use it.

badgersandjam 12y ago
That's really not a terrible idea actually. I switch back and forth a lot between the Windows and the Unixy ecosystems and by far the best end user experience, tailored[1] developer experience and (I'm going to get slated for this), mobile experience is on Windows by far. [1] tailored as in platform specific. For cross platform stuff, it's not so good.
- anonbanker 12y ago
  Someone created a new account in order to post a pro-windows reply in a systemd thread. Color me surprised.
  - badgersandjam 12y ago
    Sigh. Read my other posts. And my account existed before the systemd article was posted. More correctly. Someone assumed a new user was a shill for Microsoft, incorrectly... Reading your history, you might want to lay off the weed. It's linked to paranoia.
    - anonbanker 12y ago
      Nice, a personal attack at the end. I'll definitely not call you a shill now!
      - badgersandjam 12y ago
        Ok perhaps the personal attack was uncalled for. Please accept my apologies.

lmm 12y ago

Lennart didn't just submit the code and put it out there. He lobbied other projects to hard-depend on it, and lobbied distros to adopt it. Systemd didn't succeed where less poisonous equivalents failed because it was technically superior (it isn't), it succeeded because of shady back-room politics.

mdellabitta 12y ago
How dare he ask other people to use the software he wrote.
- fapjacks 12y ago
  I think "ask" here is the wrong word, and you know it.
  - jptman 12y ago
    I'm curious to know what kind of leverage he had over the distros where it wasn't just "ask". Any suggestions on where I can find some info?
ngrilly 12y ago
Let's say you're right. What kind of "political" leverage Lennard had to convince distros to use systemd?
- lmm 12y ago
  All he would've needed was the support of RedHat management, after that everything falls into place: most Gnome contributors work for RedHat, so they can convince Gnome to follow a particular direction and hard-depend on systemd. Then most distributions are under pressure from their userbase to support Gnome (because of a legacy of politics and FUD about the KDE license, because a minimally-configurable environment is popular with the kind of large, inflexible organization that buys expensive support contracts, and because it's actually quite good software) and are therefore also obliged to hard-depend on systemd. It's in RedHat's interest for software that's currently portable to FreeBSD or especially to Solaris to become tied to Linux. This wouldn't be the first time RedHat has adopted anti-opensource methods out of fear of Oracle - compare their policy of deliberately obfuscating the history of their kernel source.

peterwwillis 12y ago

> Why else would nearly every distribution be on board? This informal fallacy is based on the idea that everything in the world can be distilled to a single answer. The real answer is more complicated. For example: Red Hat is on board because they pay its creator's salary. So they rely on an individual bias. Debian is on board because they rely upon 'collective wisdom' and committees to make decisions. So they rely on the bias of group thinking. Ubuntu is on board because Debian is on board. So they rely on the bias of the other. Other distributions are using it because 'every other distribution is using it', or they're small enough that it doesn't cause conflicts for its use base, or because it's a GNOME dependency, or because it's just new technology. -- To make someone think something is a good idea, show them someone else thinks it's a good idea. This is a fact of all human beings' thought processes. Decisions are not based on merit, or logic, or even a quorum; it is based on fallacies created by heuristics. There exists a heuristic in which the more an idea is adopted, the more other people think it is a good idea. We imagine our thoughts are logical, and that other people also think logically, and that their decisions must be made for a good reason. But in fact, the great majority of all decisions we make are based on guesses; this is how our brains are able to carry out complex calculations and come to decisions in split-seconds. For example, you might look at systemd and say, "it fixes so many problems! it provides so many features! it standardizes Linux! CLEARLY this is superior. we must adopt it." For people who care about the purity of the highest technical ideals, this makes sense. For people who care about being able to use their computer, these things don't matter, and in the systemd implementation, actually makes things worse for them. The changes systemd purports to make are not bad things. It's really just the way in which they did it that is bad. -- It's like wanting to upgrade your bicycle to four wheels, but requiring the rider now operate it lying flat down and using mirrors to navigate. The four wheels was a great idea. Using mirrors to navigate? Maybe not so great. Of course, its creators will turn this inconvenience into a feature, saying "you get to lay down! it's therefore more efficient and easier to use!", completely ignoring how other people want to ride a 4-wheeler.

blutgens 12y ago

haphazard? fragmented? many places for error logs? half-a-dozen ways to configure X? Have you ever run a linux box? How about dozens or hundreds of them in a production environment? I'm guessing no on both counts based on the nonsense you're spewing forth in your post. If you don't know what you're talking about, it's best to just keep quiet.

101914 12y ago

"Someone finally got fed up with the haphazard state of affairs in Linux-land" But wouldn't the path of least resistance be to switch to a project that does not have this "haphazard state of affairs"? When I originally tried Linux I got fed up within _days_. It is the _relative_ lack of default "configuration" (that is decided by someone else) that makes me stay with FreeBSD and NetBSD. Of course, lack of default configuration is the antithesis of popular Linux distributions. Whenever I have to use one, I spend more time learning how to turn things off than I ever did learning how to turn things on. The answer to the original question is, I think, "no", switching is probably not the path of least resistance for many Linux users. Because when the Linux user makes that switch, they immediately find that someone has not done everything for them. And from what I have seen, observing the questions of Linux users who first try FreeBSD or NetBSD, they generally do not like that. It means they have to do some configuration of their own. And even if they are comfortable doing configuration, it means they have to learn things that are different from the "Linux way"; and they inevitably encounter shortcomings that are due to lack of developer resources (read: time). In doing things for yourself you learn about how things work. The rc.d system that all BSD projects use is coherent and relatively easy to understand. For whatever that is worth. This debate over systemd seems to cut to the core of the value of learning about how things work. The reader can draw their own conclusions. Linux is only a kernel and it should still be possible and thus optional to run that kernel with a basic init (or init alternative, e.g., one based on daemontools) and with userland utilties that do not need systemd. The question I have is how difficult the popular Linux distribution folks are going to make that for their users to do. And if they do make it difficult, it raises the question, "Why?"