7 ms·

Why is this upsetting to so many people? This seems to me like a simple request to add platform-specific code, and in the end there was a decision to take a di

• quickben 10y ago
  It's the invasiveness or the approach. To use the (wrong) car analogy, the blinker manufacturer shouldn't demand a specific engine oil being used. Amalgamation of components, in the software world, carries long term risk and problems.
  • JBReefer 10y ago
    This is the OS level, though - despite the difference in orgs, it's like complaining that Windows is moving away from WCF . Normal coupling rules do not apply.
    • tremon 10y ago
      What is "OS level" though? This breaks user applications, which is three stories above "OS level" IMHO.
  • justinsaccount 10y ago
    To me, the car analogy would be: For years people have been locking their keys in their car and then having a locksmith open the door when they get back. Now, someone is trying to improve the locks so that a locksmith cant open the door and people are complaining that it ruins a perfectly good arrangement. In this analogy, 'locking the keys in the car' is 'logging out' and the locksmith is 'nohup'. systemd isn't really out to break nohup, they are trying to fix the logging out process. Sure, nohup has worked for decades, but 'logout' has never worked right. The problem is that 'nohup' is designed to 'run a command immune to hangups' not 'run a command even after I logout' and there has never been a distinction between an individual connection 'hangup' and a full user 'logout'. With systemd, there is, and programs don't handle the distinction. If you don't think there should be a distinction KillUserProcesses can be turned off.
• raverbashing 10y ago
  It's not "platform specific code", it's breaking historical behaviour. Killing user processes after logout (when they have been set to not do so, through nohup usually) is not sensible. Edit: clarification
  • danudey 10y ago
    Killing user processes which aren't meant to stay alive after the user logs out is sensible. Killing all user processes unless they update their code to implement a new API just for this one platform, because of a breaking change to a 21-year-old API, is not sensible. In other words, if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided and we'd all be happier, but since it didn't the systemd guys are trying to implement it retroactively, which is going to break a lot more stuff than tmux/screen/etc.
    • tremon 10y ago
      Killing user processes which aren't meant to stay alive after the user logs out is sensible Only if you can succesfully determine which ones the user wants to keep running. Otherwise it's just breaking stuff, as this story shows. if this functionality had been added 21 years ago as well, a lot of mess and confusion would have been avoided Not really. You will always have sub-standard software that doesn't adhere to the system's declared semantics, and just goes by "what works" (ask the WineHQ guys). Any API that has been around for 21 years will have corner cases where software just breaks. That does not mean you're then free to break the old API yourself.
  • embik 10y ago
    I'd like to respectfully disagree here. IMHO, killing user processes after logout is totally reasonable and something I would expect to happen on desktop computers. On servers this might be a bit more difficult, but I like the idea of having to explicitly allow user processes to run outside of the session's scope. That keeps my server used by multiple people clean. I'd argue most sysadmins could simply deploy an alias to their servers for specific applications and be done with it. edit: If you're already using a specific command to tell the application to stay alive (e.g. nohup), you can use the "new" systemd command as well. nohup never related to a "session" scope because that didn't really exist before systemd. A new command _does_ break historical behaviour, but thanks god we do that from time to time. That's how innovation works.
• danudey 10y ago
  I think it's pushback against what a lot of people see as systemd overreach/arrogance. "Hey, can you implement and maintain new platform-specific code to work around this problem we're going to introduce by breaking behaviour of programs using a 21-year-old API?" It feels especially egregious because, as commenters pointed out, implementing the PAM API is a better (and undoubtedly more portable) way to do this that the developers of systemd didn't seem to consider. Instead, they jumped straight to "implement a custom fix just for us so our breaking change doesn't break your app too".
  • pfg 10y ago
    > It feels especially egregious because, as commenters pointed out, implementing the PAM API is a better (and undoubtedly more portable) way to do this that the developers of systemd didn't seem to consider. I wouldn't consider that bit to be particularly egregious. The thought process of a systemd developer confronted with a regression caused by systemd changing some well-known behaviour would naturally lead to a solution where program X tells systemd that it needs to be handled differently. It's basically a version of the anecdote that experienced developers aren't better because they know the answer to every question, but rather that they know which question to ask. Apparently the discussion has lead to a better solution (not that I would be a good judge of that), so this seems like a bit of a storm in a teacup.
  • detaro 10y ago
    s/"we're going to introduce"/"we introduced" They already released systemd 230 with this behavior and the bug reports from users of unstable/rawhide sparked the "public" discussion. (The bug report in the link says this right, but it still comes a week after the release instead of before)
  • mwfunk 10y ago
    If it's a reaction against perceived overreach/arrogance, then those people are just contributing noise to the whole process. People complain about software development in the corporate world being overinfluenced by interpersonal politics rather than pure engineering, but stuff like this is 100x worse than almost anything you'll find in the most toxic corporate environment. Seriously, every single person who feels compelled to offer their opinion based on what is an emotional response to Lennart's (or anyone's) "overreach/arrogance" is contributing little more than noise to the whole process. It's far too easy for someone who doesn't interact face-to-face with someone else to fall in a trap of assuming the worst about another person when there's a technical disagreement; this is a form of cognitive bias that pollutes development in the corporate world all the time. I'm as guilty of it as anyone, and I've learned to be wary of the temptation to project bad qualities on other people who I disagree with but don't interact with directly. In the open source world it's so much worse though- not only do almost all developers interact indirectly (i.e. not face-to-face), but there are potentially thousands of people who are basically just casual observers who want to jump in to give their 2 cents. That's great! But it's only great as long as those 2 cents aren't just people bikeshedding, or actively trying to make things personal rather than technical. Unfortunately, more often than not it is bikeshedding, and literally the only thing they have to bikeshed about is to try to make it personal. :(
• erikb 10y ago
  Well, do you know the init-wars? That's the result of polarizing people. A lot of them won't do you a favour, just because they read your name. Even when it may be a reasonable choice, from a technical perspective. Seeing such an emotional reaction so long after the war makes me wonder if systemd can survive in the long run, though. Seems to be an issue of "The north remembers."
• cnvogel 10y ago
  Yes, it's quite sad how unconciliatory the two camps (systemd implementors on one side, the traditionalits on the other side) have become. Both sides' arguments have their merits, but with this unnecessary hate and anger everywhere no one really wants to join the discussion anymore. :-(
  • themartorana 10y ago
    You're asking people that were here before systemd and argued quite deftly against systemd's takeover of Linux to now "have a conversation" about systemd's further encroachment.
  • sklogic 10y ago
    Why should we even talk to them? They're invaders. They must be exterminated.
• busterarm 10y ago
  The whole reason Lennart started systemd was because to create a daemon you had to have separate init scripts for every distro (i.e., platform-specific code). So now not only have we not achieved that goal, but now we've inserted an additional layer of complexity into the mix.
  • Gonzih 10y ago
    Could you please us to this extra complexity you are talking about?
    • busterarm 10y ago
      Systemd itself? It's an entire middleware layer that sits between userland and the kernel that we did not have before.
      • jsmthrowaway 10y ago
        Er, what does that make init and Upstart?
        • tremon 10y ago
          init systems.
          • jsmthrowaway 10y ago
            Since you're forcing me to belabor the obvious question just to score some low-effort snark points (thanks!): The distinction being? Edit: I'm out of my HN comment quota but kind of glad I am. Because I'm clearly not going to get anything productive from a thread where I wonder aloud why systemd is classified differently and where that distinction lies. When does an init system become middleware "that we didn't have before?" I can think of a few answers but was curious what others think. Fuck me, right? Instead, ask a question, get snarkily called obtuse and downvoted because we have the misfortune of systemd being the topic of conversation. History shows us you might as well not even participate; if all the people who argued about systemd invested that time into productive activities we'd have warp drive by now. Which would be useful to flee systemd threads. I swear, systemd is tech's abortion debate.
• mjolk 10y ago
  It's upsetting because the end result of taking a different approach was because the systemd contributor was told to go "pound sand" and not out of a realization of "oh, I'm actually asking for something bad." This is an example of one of the concerns people had -- and were told to stop spreading FUD -- about systemd in that it seriously overstepped the bounds and desires of an init system.
  • busterarm 10y ago
    the systemd contributor was told to go pound sand because it's a different flavor of a question that systemd folks have been asking nicm for 5 years now. After having the same conversation over and over stating your same reasoning to deny the change, you'd probably tell people to go pound sand too.
    • mjolk 10y ago
      I believe you misread me. I'm glad nicm refused to add to the Rube Goldberg machine.
      • busterarm 10y ago
        Oh totally. My apologies.
• msbarnett 10y ago
  Red Hat developers decided to break the semantics of nohup/daemon(3), which are long established mechanisms for achieving the ability to run beyond user logout. They then decided that, rather than encapsulate fixes for their breaking change in portable APIs like daemon(3) and PAM to allow user space to keep working as intended, it'd be easier to just outsource the labour onto the community by demanding every user space program that was working just fine do the work of adding a couple of hundred lines of systemd specific code directly, encapsulation be damned. That's an insult to the tmux developers in particular, and disdainful of Open Source devs in general. Don't show up at my door telling me to do a bunch of work for you to fix your shit. You broke the contract; encapsulate the fix so I don't have to care.
  • sandGorgon 10y ago
    Nohup was invented in response to a new SIGHUP which broke persistent processes. And today, it is accepted as the Right Way. This is no more an insult than removing cgroup write access from processes or any other new kernel feature. Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance. Think about Chrome having flags to "run background processes after app is closed". Systemd is trying to maintain backwards compatible behavior by collaborating with developers. We should not do these things cost "that's the way they've always been" is killing innovation.
    • msbarnett 10y ago
      > Nohup was invented in response to a new SIGHUP which broke persistent processes. And today, it is accepted as the Right Way. Correct > This is no more an insult than removing cgroup write access from processes or any other new kernel feature. False. Empoyees of a 2 billion dollar corporation deciding to demand free labour from the community to accommodate what they've decided by fiat is the new Right Way is incredibly insulting. The tmux developers do not exist to serve your whims. The community is not here to save you money. > Systemd is trying to build a new feature that is useful - reaping processes after logout should help improve security and performance. There's NOTHING new or innovative about this! Processes are already reaped at logout, unless they're nohup'd. Changing the state of affairs to "processes are reaped at logout, unless they use dbus to ask systemd to not reap them" is just a bunch of mechanism churn to get the same result > Think about Chrome having flags to "run background processes after app is closed". What would stop Chrome from doing that under this new regime? Literally the only difference is that they'd be accomplishing that via systemd-specific code rather than portable, SUS-compliant code. Ultimately all this change is accomplishing is deprecating simple, portable interfaces for achieving nohup behaviour with baroque, dbus-laden, systemd-specific ones. Red Hat's goal here seems to be little more than increasing systemd's surface area; otherwise, why not simply hide the sausage-making systemd cruft behind the portable API? > Systemd is trying to maintain backwards compatible behavior by collaborating with developers. "Collaboration" is not a synonym for "I have altered the user space contract. Pray I do not alter it further". > We should not do these things cost "that's the way they've always been" is killing innovation. "Innovation" is not a synonym for "instead of a daemon(3) call, here's 150 lines of dbus crud to get right back to where you were before".
• deleted 10y ago
  [deleted]
• Bahamut 10y ago
  As an open source maintainer, I see requests like this quite frequently, and almost wholly are poorly thought through requests. Library specific code has a lot of negative ramifications, and almost never is worth it. Requesting the specific desired feature/fix is almost always preferable.