Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Gusar
    replied
    Originally posted by scjet View Post
    that so-called foundation(of simple init scripts) has been in place, and has worked flawlessly for over 30 years
    There are a lot of sysadmins who would take a big exception to that "flawlessly" claim.

    Originally posted by scjet View Post
    Your "systemd", has to learn to curb their arrogance and admit their mistakes, and then FIX they're buggy crap, or else.
    Or else you'll write another ranty comment on a forum?

    Originally posted by scjet View Post
    Systemd is simply a "tool" to make a "dev's" programming world easier to manage, and unfortunately "control", with their binary-non-portable bloberia
    -sadly their isn;t anything more about it, except the obvous UN-needed complexity of itself. -get it ?
    Yes, I get that you're making some vague unsubstantiated claims that might sound good to you, but are completely devoid of any substance. I'm surprised you didn't put a RedHat/NSA conspiracy theory in there while you were at it.

    Originally posted by scjet View Post
    ,,, and sorry clyde, but that link is the first here, in this thread, -don't like it? then don't read it, and continue pretending it's all wrong.
    And here you enter the WTF territory. There's no head or tail to this sentence, it makes no sense whatsoever. So... WTF??

    Leave a comment:


  • scjet
    replied
    Originally posted by Gusar View Post
    Yes, an article devoid of concrete detail. An article that says systemd can't be restarted and then mentions how to restart systemd. An article that shows a minimal init, while completely ignoring the complexity and fragility of the scripts framework you have to put on top of that init to actually have it do something.

    So you'll have to be sayin' more than just pointing out that link, which I'm sure has been mentioned in this thread already.
    "...ignoring the complexity and fragility of the scripts framework..." - that so-called foundation(of simple init scripts) has been in place, and has worked flawlessly for over 30 years, in the "real" unix/linux world.
    Your "systemd", has to learn to curb their arrogance and admit their mistakes, and then FIX they're buggy crap, or else.
    Cause nobody wants a potential "systemd" heartbleed, ...

    Systemd is simply a "tool" to make a "dev's" programming world easier to manage, and unfortunately "control", with their binary-non-portable bloberia
    -sadly their isn;t anything more about it, except the obvous UN-needed complexity of itself. -get it ?

    ,,, and sorry clyde, but that link is the first here, in this thread, -don't like it? then don't read it, and continue pretending it's all wrong.
    Last edited by scjet; 05-01-2014, 12:22 PM.

    Leave a comment:


  • scjet
    replied
    Originally posted by oleid View Post
    Putting something on a web page doesn't automatically make it true.
    Sure, unless of course, if the web-page was put up by one-sided "systemd-fanboys" heaping glorious, (but obviously misplaced) praise for systemd, then that would be "true" too,
    right !?

    -Well, then it goes "both" ways sunshine.

    jus' sayin'.

    Leave a comment:


  • oleid
    replied
    Originally posted by scjet View Post
    Then again, there is this:
    http://ewontfix.com/14/

    ...jus' sayin'.
    Putting something on a web page doesn't automatically make it true.

    Leave a comment:


  • Gusar
    replied
    Originally posted by scjet View Post
    Then again, there is this:
    http://ewontfix.com/14/

    ...jus' sayin'.
    Yes, an article devoid of concrete detail. An article that says systemd can't be restarted and then mentions how to restart systemd. An article that shows a minimal init, while completely ignoring the complexity and fragility of the scripts framework you have to put on top of that init to actually have it do something.

    So you'll have to be sayin' more than just pointing out that link, which I'm sure has been mentioned in this thread already.

    Leave a comment:


  • scjet
    replied
    Broken by design: systemd

    Then again, there is this:
    http://ewontfix.com/14/

    ...jus' sayin'.

    Leave a comment:


  • erendorn
    replied
    Originally posted by chrisb View Post
    I don't think this has much to do with Linux configuration. The whole problem was caused by one developer taking an internal kernel parameter for enabling debugging, and using that parameter to also enable debugging in his user space project. His "you don't own the debug parameter" was ridiculous - it is clearly documented that the kernel debug parameter is for debugging the kernel:



    I don't see what's so hard to understand about that. Parsing the kernel parameter in user space, using it to enable debugging in another project, and then expecting the kernel developers to fix the problems that caused, shows a distinct lack of consideration. It's also technically dumb to pollute different namespaces - what if a kernel developer wants to enable kernel debug without systemd debug, or vice versa? Well, they can't do that, because someone thought it would be a good idea to use the same parameter to control them both.
    The whole problem was also a bit caused by the kernel crashing on a user space program outputting too much.
    It is also true that it's dumb to pollute different namespaces, but for that to happen, you need at least to pick a namespace, which is something neither systemd nor the kernel did.

    Leave a comment:


  • chrisb
    replied
    Originally posted by gamerk2 View Post
    This whole thread highlights the downside to Linux: Configuration hell.

    And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?
    I don't think this has much to do with Linux configuration. The whole problem was caused by one developer taking an internal kernel parameter for enabling debugging, and using that parameter to also enable debugging in his user space project. His "you don't own the debug parameter" was ridiculous - it is clearly documented that the kernel debug parameter is for debugging the kernel:

    debug [KNL] Enable kernel debugging (events log level).
    I don't see what's so hard to understand about that. Parsing the kernel parameter in user space, using it to enable debugging in another project, and then expecting the kernel developers to fix the problems that caused, shows a distinct lack of consideration. It's also technically dumb to pollute different namespaces - what if a kernel developer wants to enable kernel debug without systemd debug, or vice versa? Well, they can't do that, because someone thought it would be a good idea to use the same parameter to control them both.

    Leave a comment:


  • Vim_User
    replied
    Originally posted by gamerk2 View Post
    This whole thread highlights the downside to Linux: Configuration hell.

    And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?
    It shouldn't at all.

    Leave a comment:


  • gamerk2
    replied
    This whole thread highlights the downside to Linux: Configuration hell.

    And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?

    Leave a comment:

Working...
X