Page 15 of 25 FirstFirst ... 51314151617 ... LastLast
Results 141 to 150 of 247

Thread: Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

  1. #141
    Join Date
    Jan 2014
    Location
    Wonderland
    Posts
    103

    Default

    Ok, will respond to you while trying to keep it civil:

    "This is simply wrong. You are operating under the mistake assumption that systemd is solely an init for daemons. It isn't, it is a generic system for handling services."

    My exact point was that it INIT system shouldn't be doing anything else and rest of the fucnctionality deserves separate project. So your counterargument about systemd failing at this is that systemd failing is failing at this.

    "This can include general system daemons, and up to this point largely has been restricted to that, but there is nothing in systemd's design that restricts it to that, and other software is considering using it for other things. "

    It should be restricted to that, your words (also mine), but it isn't. When you install systemd on a laptop, it overrides any acpid functionality and when you close lid, it suspends by default (this has been reported and criticized, but nobody has changed default config). And thats just one example.

    No software should be using systemd for anything, but indeed, many software packages do because they are reliant on udev (back to my criticizm).

    "For example KDE is planning on replacing the inefficient and ancient bash startup script and replacing it with systemd when run under wayland. "

    Why would KDE even use any 'ancient bash startup script'. When X is started, you tell it to execute either WM directly (via ancient script like startx) or exec xdm, gdm, kdm which in turn execute WM.

    There is virtually no reason to interact with systemd, systemd should only start X which then does rest of the job (or Weston).

    This works for ages and there is no reason to fix it or make it dependant upon systemd (back to philosofy "linux is about choice".
    "So why try to enforce artificial limitations that prevent it from being used where it is helpful? "
    Answered above.

    "The problem isn't the formats, the problem is the dependencies."

    This is true and I provided nice video "why linux sucks" that explains this in much more detail and comes form a developer. As an QA tester and developer I'm well aware of this, but I didnt wanted to go to too much detail so I just linked the video.

    "The problem is that the packages will be built against different versions of dependencies, quite likely with different names, built with different options, with files installed in different places."

    We are not living back in day of static libraries anymore and libraries can be built without propper linkage and still be linked properly most of the time.

    This is much easier than it used to be, nowadays packaging is lagely automated and fairly easy, but it still requires some manpower (redhat maintainers could attest to this, despite them having huge servers and automated scripts that do packaging and linkage checks).

    "Of course if you are careful you might be able to build a generic rpm or deb that works across multiple distros by targeting LSB, but if you just pull a random package out of a repo almost certianly won'y work."

    It should work most of the time and if not, most of the time it can be solved by LD_PRELOAD hacks.

    "Having one package format won't fix that."

    Never claimed it would, but it would be step in right direction.
    These formats aren't just containers, they represent building processes and handle dependencies.

    "Cyanogenmod isn't a distro in any meaningful sense of the word. It is more like a respin or variant, like Ubuntu vs. Kubuntu. It uses the same toolchain, same package versions, same naming conventions, same file locations. It is fully "binary-compatible"."

    I would argue that by this logic there isn't a single distro in linux world, because very few distros bring their own stuff to the table.
    Everything is "binary compatible" assuming one platform (I'm talking at ABI level).

    Even if you take 32bit binary and its libs, its gonna work on 64bit gentoo (assuming the owner has multilib and 32bit support compiled in kernel).


    Phew, quite an answer, it has few simplifications, but else it would be much longer.
    Now go watch "Why linux rox" and "why linux sucks" on youtube, it has all the arguments
    (discounting systemd stuff that was brought upon us only recently).

  2. #142
    Join Date
    Feb 2011
    Posts
    1,297

    Default

    Quote Originally Posted by tpruzina View Post
    My exact point was that it INIT system shouldn't be doing anything else and rest of the fucnctionality deserves separate project. So your counterargument about systemd failing at this is that systemd failing is failing at this.
    This isn't about separate functionality, that is another issue entirely. The question is whether the same functionality (starting services) should be allowed to be used in more than one situation. You are asserting, without basis, that we should put artificial barriers around what sort of services a generic service manager is allowed to manage. I see no reason to do that. Having a flexible, generic code-base that can be used in a wide variety of situations is a good thing, not a bad thing.

    Quote Originally Posted by tpruzina View Post
    Why would KDE even use any 'ancient bash startup script'. When X is started, you tell it to execute either WM directly (via ancient script like startx) or exec xdm, gdm, kdm which in turn execute WM.
    Uh, you do realize there are a lot of other programs and services that have to be started besides the WM, right? And many of these services depend on other services being started first. The route KDE has been taking up to this point is to use a bash script to start these services in the proper order. But this is slow, complicated, and brittle. systemD allows them to do it in a smaller, faster, more portable, and more flexible manner. It is basically the exact same thing that the system has to do when booting, only with the per-user services associated with the desktop environment rather than system-wide services.

    Quote Originally Posted by tpruzina View Post
    We are not living back in day of static libraries anymore and libraries can be built without propper linkage and still be linked properly most of the time.

    This is much easier than it used to be, nowadays packaging is lagely automated and fairly easy, but it still requires some manpower (redhat maintainers could attest to this, despite them having huge servers and automated scripts that do packaging and linkage checks).
    I have done a large amount of packaging, and I can tell you it is not that simple. Those issues I listed are not theoretical issues, they are real problems. Whether you think they should be an issue is irrelevant, the fact of the matter is they are a problem, and having a single package format will not change that.

    Quote Originally Posted by tpruzina View Post
    I would argue that by this logic there isn't a single distro in linux world, because very few distros bring their own stuff to the table.
    Everything is "binary compatible" assuming one platform (I'm talking at ABI level).
    No, my whole point is that they are not binary compatible. You think they theoretically should be, but in the real world they aren't.

    Grab a random binary from the latest version of Ubuntu, run it through alien, and try to install it on Red Hat. If what you are claiming is true, it should work just fine.

    But even with a standard package format, things in android are not always compatible. Try running a Samsung-specific apk on an HTC phone. Or an arm-specific apk on a x86 android device. Or a tegra-specific apk on a non-tegra device. It won't work, even with a shared package format.

    Quote Originally Posted by tpruzina View Post
    Now go watch "Why linux rox" and "why linux sucks" on youtube, it has all the arguments
    No, sorry. If you are going to make an argument, then make it. But I am not going to watch a 45 minute video by someone else to find out what you argument is.
    Last edited by TheBlackCat; 04-14-2014 at 10:32 AM.

  3. #143
    Join Date
    Jun 2012
    Posts
    362

    Default

    Quote Originally Posted by TheBlackCat View Post
    This is simply wrong. You are operating under the mistake assumption that systemd is solely an init for daemons. It isn't, it is a generic system for handling services. This can include general system daemons, and up to this point largely has been restricted to that, but there is nothing in systemd's design that restricts it to that, and other software is considering using it for other things.

    For example KDE is planning on replacing the inefficient and ancient bash startup script and replacing it with systemd when run under wayland. This isn't bloat by systemd, it is just that systemd's architecture is flexible enough that it can be useful for other things besides simply starting and stopping daemons. So why try to enforce artificial limitations that prevent it from being used where it is helpful?
    Because you have now locked your software in with another software package you do not control. That's the issue here. It's not plug and play anymore; you can't replace Systemd with something else without re-coding your software. You have a dependency within your INIT, which lets face it, should be independent of everything else.

  4. #144
    Join Date
    Feb 2012
    Posts
    505

    Default

    Quote Originally Posted by gamerk2 View Post
    You have a dependency within your INIT
    No, what you have is a dependency on a service manager. And that's because the DE developers explicitly want to use a service manager, because it performs the duties of starting and monitoring DE services better than their homegrown bash script.

    Quote Originally Posted by gamerk2 View Post
    which lets face it, should be independent of everything else.
    Which holy scripture says that? Yes that just sounded very condescending, but the thing is, I often see arguments the likes of "X should be Y and Z and nothing else" as if it's written in stone or something. And explanations why it should be like that are often either missing or consist of vague, taken out of context references

    TheBlackCat is fully correct in that DEs also have services in need of starting and monitoring, just like the system itself does. Following your argumentation, there'd be one service manager for system-wide services and another manager written by the DE devs for their DE. That's inefficient on two parts - why have two managers when one can do both tasks (manage both system-wide and DE services), and having to write and support/maintain their own manager takes away dev resources that could be used for working on the DE itself.

  5. #145
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    466

    Default

    Quote Originally Posted by Gusar View Post
    That's inefficient on two parts - why have two managers when one can do both tasks (manage both system-wide and DE services), and having to write and support/maintain their own manager takes away dev resources that could be used for working on the DE itself.
    Why have 'ls' and 'grep' when the new, improved 'lsgrep' can do both?

    DEs are, by themselves, a horrible violation of traditional Unix design principles. Just look at all the crap KDE spews out if you run a KDE app over the LAN to a Gnome desktop, for example. No, KDE, I do not what you to forget about all the audio interfaces on the machine I'm running it from, just because you can't find them when not running a KDE desktop.

  6. #146
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    528

    Default

    Quote Originally Posted by movieman View Post
    Why have 'ls' and 'grep' when the new, improved 'lsgrep' can do both?
    Like busybox? It's already there since almost 20 years :-P

  7. #147
    Join Date
    Feb 2012
    Posts
    505

    Default

    Quote Originally Posted by movieman View Post
    Why have 'ls' and 'grep' when the new, improved 'lsgrep' can do both?
    *facepalm*

    That's gotta be among the crappiest arguments I've ever seen. Dafuq, guys, seriously?

  8. #148
    Join Date
    Jan 2014
    Location
    Wonderland
    Posts
    103

    Default

    He is most definitely trolling us, if there was ever any doubt, now it must be clear to everyone.

  9. #149
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by droste View Post
    Like busybox? It's already there since almost 20 years :-P
    With reduced features aimed for minimal size, so it can replace ls and grep only if you don't need or want all the features.

  10. #150
    Join Date
    Oct 2010
    Posts
    469

    Default

    Quote Originally Posted by movieman View Post
    Why have 'ls' and 'grep' when the new, improved 'lsgrep' can do both?
    ...really? Maybe because, I dunno, 'ls' has one purpose while 'grep' has an entirely different one? On the other hand, you might be considered more-or-less sane if you merged 'less' and 'more', and just used an option to choose the desired action.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •