Systemd Debates

I still haven’t decided what to do about systemd. It seems to be working here and Debian GNU/Linux is inching towards its next release with systemd as default init.“Systemd thus appears to be a massive, fundamental change to core Linux administration for no perceivable gain. This is what is meant when people say that systemd was an answer to a question nobody asked.” TFA, linked below, identifies two or more solitudes fighting over systemd. It identifies desktop and server users as two camps who want/don’t want systemd to run their lives.

I’m kind of straddling the fence… I run multiple PCs and servers and did just fine without systemd and I only tolerate systemd because it hasn’t completely broken my systems. It seems to me that Debian is dangerously close to breaking my systems by even considering that all kinds of stuff could be made to depend on systemd. That’s just not the Debian I know… Why is this even up for discussion?

In case anyone needs reminding, this is from the Debian Social Contract:
“We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments.”
Making all kinds of stuff depend on systemd doesn’t sound like what users need/want. The whole idea of dependencies in APT is making it easy to build systems. If you don’t want systemd and GNOME depends on it, that’s going to be hard. My system doesn’t depend on GNOME but I have a few applications that have a few libraries that do. Even before systemd there were a few applications I did not install because they sucked in half the GNOME repository. Having applications tightly integrated into the underlying OS is a recipe for disaster and the original reason I chose GNU/Linux fifteen years ago. We should be looking forwards not backwards. Why repeat the mistakes that M$ made?

See What we talk about when we talk about Linux and systemd.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , . Bookmark the permalink.

101 Responses to Systemd Debates

  1. oiaohm says:

    DrLoser you should know I believes in traps and you walked into this one hook line and sinker.

    Reason why some people use GNU/Linux is remove the Glibc remove the Posix conformance.

    Reason for removing the posix conformance makes program smaller.

    Note the 4% was in the HP white paper saying that the Migration would cost Munich a fortune that Microsoft paid for.

  2. oiaohm says:

    DrLoser no still no homework lets just use Oiaohm cite lets not bother finding my own. Heck lets not even be able to understand what Oiaohm cite is referring to.

    Yes Posix.1 defines what a process is. Linux man page only list requirements that Linux kinda does.

    Process ID in Linux kernel space is LWP not Posix Process.

    Lets take the list you decide to quote that is from a GNU Libc man page not a Linux kernel one and how untrue it is.
    Lets look at what a LWP inside a thread group is allowed compared to that quote.
    1. process ID=This posix functions get from Linux kernel tgid.
    2. parent process ID
    3. process group ID and session ID
    4. controlling terminal=Non conformance Each LWP can have its own Terminal.
    5. user and group IDs=Non conformance Each LWP under linux is allowed a unique user and group.
    6. open file descriptors=Non conformance Each LWP can have unique file descriptors not shown to the rest of process. This is a security thing.
    7. record locks (see fcntl(2))=Non conformance if file descriptor is not shared so is record locks not shared.
    8. signal dispositions
    9. file mode creation mask (umask(2))=Non conformance each LWP can have unique mask.
    10. current directory (chdir(2)) and root directory (chroot(2))=Non conformance each LWP can have unique of these.
    11. interval timers (setitimer(2)) and POSIX timers (timer_create(2))
    12. nice value (setpriority(2))=Non Conformance each LWP always unique here worse until the introduction of cgroups nice value was never used by the any of the schedulers yes was meant to be used by the scheduler to be posix conforming.
    13. resource limits (setrlimit(2))=Non Conformance each LWP can have unique here.
    14. measurements of the consumption of CPU time (times(2)) and resources (getrusage(2))=This is borked and never reports correctly on Linux because it would cost too much cpu time on NUMA systems to report this correctly. Close enough keeps posix application happy.

    All those differences are true under NPTL Linux. Just to trigger them in most case you have to use a direct syscall and avoid the libc so that the libc does not enforce posix conformance.

    How have unique here happens fairly much if a posix thread or linux LWP process that is not the thread master decides to mess with settings and used uses a non Posix function todo it or uses a posix process that uses a signal between glibc to update the LWP settings. User and Group sync on LWP is done by a signal if for some reason 1 LWP in a TGID is too busy or suspened to process signal its not going to update.

    Sorry the Man page lists what Posix.1 wants it does not say Linux conforms. The truth of the matter Linux does not conform.

    Ok your Consider this DrLoser click threw on the header file in the man page.
    http://linux.die.net/include/unistd.h
    Read the top copyright. That is right it is GNU Libc. All those functions are libc emulated. This is why you have POSIX.1 and BSD versions. Reality the Linux kernel supports neither. Not a single item on your consider this man page is a Linux kernel feature or action.

    Yes the pthreads I linked to is not a Linux kernel man page either. Its a GNU Libc.

    Problem here you are a DrLoser you cannot tell the difference between a Linux kernel man page and a GNU libc man page.

    GNU Libc wraps over the Linux kernel to make it pretend to be BSD or Posix conforming. Linux the kernel itself is not BSD or Posix conforming.

    DrLoser what is the difference between what Glibc is doing and wine does for Windows applications on Linux. Very little.

    “Linux Programmer’s Manual” at the top is a completely deceptive trap that you fell for hook line and sinker. Yes the Pthread man page is listing what glibc conforms to not Linux kernel itself.

    DrLoser the Linux kernel does not have anything called Pthreads. Linux kernel has NPTL and LinuxThreads. If you are talking about what Linux does you are talking about those two. If you are reading a Pthread man page or Posix.1 stuff you are reading some libc emulation information.

    Posix requirements is fairly much screw it as far as Linux kernel developers care that is the libc job to work out how to achieve.

    How to blow your feet off under Linux decide to use syscalls to increase speed to mess with values that are required to be synced to be posix conforming.

  3. DrLoser says:

    Oh, and just to get you started on #3, oiaohm:

    Consider this.

    Notwithstanding your ignorant nitwit claims, it appears that Linux is fully compliant with Posix.1 in this respect.

  4. DrLoser says:

    process group ID does not match a Linux thread group ID.

    DrLoser reality Linux does not obey Posix.1 the first edition completely. Items that are meant be shared Posix Process Wide under Linux turn out to be only LWP so many places it not funny. Its like the universal Linux breaches Posix here.

    Unmitigated drivel, accompanied by your familiar worthless cite, oiaohm. Here’s what Posix.1 (off that astonishing and completely unbeatable cite to the Posix standards, ie Linux man page pthreads(7), who’d a thunk, no possible better!) says … well, I’m limited to the contingent idiocy that you, oiaohm, provide … So, in terms of Posix requirements on Linux, regarding processes:

    1. process ID
    2. parent process ID
    3. process group ID and session ID
    4. controlling terminal
    5. user and group IDs
    6. open file descriptors
    7. record locks (see fcntl(2))
    8. signal dispositions
    9. file mode creation mask (umask(2))
    10. current directory (chdir(2)) and root directory (chroot(2))
    11. interval timers (setitimer(2)) and POSIX timers (timer_create(2))
    12. nice value (setpriority(2))
    13. resource limits (setrlimit(2))
    14. measurements of the consumption of CPU time (times(2)) and resources (getrusage(2))

    Those appear to be the Posix requirements for a process. As interpreted via Linux, which was your cite, oiaohm.

    Now, I have one or two issues with them (essentially I believe that Linux has screwed the pooch), but whatever.

    Pick a number from 1 to 14 and argue with it, oiaohm.

    Remember: not only is it not an official Posix cite: it’s yours.

  5. oiaohm says:

    DrLoser
    I’m not aware that Posix (2008, 2001, or prior) has any “definition” of “processes” at all, oiaohm. I’m not at all sure that Posix has ever needed one.
    That you say this means you are complete screwed.

    Posix threads standard section defines what a Process is as per Posix. Yes it goes on to talk about interactions between processes.

    http://man7.org/linux/man-pages/man7/pthreads.7.html

    Its part of Posix.1 Yes first edition of Posix defines how a Posix Process is constructed this define is copied into all versions of Posix since.

    process group ID does not match a Linux thread group ID.

    DrLoser reality Linux does not obey Posix.1 the first edition completely. Items that are meant be shared Posix Process Wide under Linux turn out to be only LWP so many places it not funny. Its like the universal Linux breaches Posix here.

    No cite, I see.
    Why did I have cite this. This is first edition posix stuff. Basically DrLoser you have been commenting on a topic where you completely don’t have a clue.

  6. DrLoser says:

    Yes a split brain event is possible inside a Linux supercomputer if the scheduler screws up (because someone has been trying to optimize it) where a single LWP ends up running on two different cores at exactly the same time. The fall out from that is really nasty.

    No particular comment on this.

    I just found it hilarious.

  7. DrLoser says:

    Price of Linux not being Posix conforming things get strange and you have to be aware Linux does not follow the Posix define of Process very closely at all.

    I’m not aware that Posix (2008, 2001, or prior) has any “definition” of “processes” at all, oiaohm. I’m not at all sure that Posix has ever needed one.

    I am therefore proposing that I should file this as #4 (I think: I may have lost count) in the continuing series of things that you, oiaohm, have pulled out of your backside about “Posix definitions” or “Posix requirements” that do not exist and have never done so.

    There are doubtless many more within your capacious yet fundamentally well-informed backside. Let them all pour out!

  8. DrLoser says:

    I have stayed away from NUMA up until now. Just to see if you would beat me to it and call me out for lieing. You should have by now…

    There was no particular reason to do so, oiaohm.

    I’m always happy to wait until you call yourself for lying.

    Doesn’t happen very often, alas. To what do we owe this brutal self-examination?

  9. DrLoser says:

    DrLoser Posix defines that all threads of a process own to the same PID. Linux is TGID for Posix applications to give this lie. Also Posix defines a lot of things are per Posix Process.

    No cite, I see.

    What happens with Posix calls on Linux, oiaohm, and this is specifically why “thread groups” were designed the way they were, is that there is a one-to-one relationship between a PID and a thread group.

    Do you seriously need this explained to you once more? Are you Ad Hominem But Obvious Deprecation Of Mental Facility Inserted Here?

  10. oiaohm says:

    DrLoser Posix defines that all threads of a process own to the same PID. Linux is TGID for Posix applications to give this lie. Also Posix defines a lot of things are per Posix Process.

    Linux kernel PID1 is LWP 1 or TID1. The fact that LWP processes can have different user and group information inside a TGID is in fact a breach of Posix.

    http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/linux-thread-problems.html
    This here is a list of breaches to Posix.

    I’m game. Describe a single “highly dangerous way.”
    With specific consequences.

    open_sem I will stick to that one. Notice the xid_command message this tells all LWP in a TGID to update there process information. You have one thread change user id and another thread performing a open_sem. By Posix access permissions should remain aligned. Linux who gives a F you opened it with the wrong user id live with it. This can cause security holes, crashes the whole 9 yards of trouble.

    Please note xid_command signal in a 4000+ cpu core system on Linux might take a few mins before all LWP in a TGID know about it at best at worst it could take unlimited amount of time if LWP is suspend. Yes the Posix Process signals inside Linux don’t exactly move at high speed. So on Linux you are mostly better off forgetting the idea of changing a posix processes UID/GID information and just start LWPs with the correct information in the first place and kill those off that are incorrect(even this might take days). Best option don’t start a Light Weight Process with the wrong UID/GID information under Linux. Posix you are meant to be able to change it after the fact.

    Yes a task group can contain multi I/O contexts under Linux. This is not Posix behavior.
    This is in fact correct for newer posix.
    POSIX makes no such stipulation.
    DrLoser please get upto 2008 Posix. I will give you that this was correct in older Posix standards.
    .
    POSIX I/O interfaces in Posix 2008 define that I/O control is linked to the Posix process structure not to the Posix threads. Linux I/O control does not follow Posix 2008 and latter. Before 2008 it was not defined. Linux developers have done it the way they like and are not changing now of course.

    DrLoser this is the problem POSIX is an evolving standard. Many areas Linux was suitable for years ago. Current day Posix Linux is not that conforming. Posix standard has gone one way Linux has gone a different path. The distance between a Linux system and a true Posix is getting larger.

    I have stayed away from NUMA up until now. Just to see if you would beat me to it and call me out for lieing. You should have by now..

    Something really nasty. LWP is not 1 kernel thread. We talk about it being 1 kernel thread but it not. NUMA supporting scheduler inside Linux might in fact have more than 1 Kernel thread to a LWP. Kernel threads on Linux are in fact CPU Core Dependant. When a light weight process migrated between cpu’s guess what happens more kthreads get generated.

    LWP to Kthread is somewhere between 1 LWP to 1 Kthread and 1 LWP to number of cpu cores in Kthreads. The record found when debugging a Linux is 1 LWP to 1024 Kthreads. Fairly much cause of NUMA scheduler changing mind where the LWP should be running. Of course only 1 of those Kthreads should be getting CPU time at a time. Correct define of LWP is should only ever have one active Kthread may have many zombie kthreads that have not been cleaned up yet and may have two suspended Kthreads one being source and one being destination when moving between cpus. Of course you can see why LWP makes life simpler than using a Posix define process. Its hard enough with 1022 threads to be deleted to keep track of what is going on. Remember NUMA is not shared memory.

    Yes a split brain event is possible inside a Linux supercomputer if the scheduler screws up (because someone has been trying to optimize it) where a single LWP ends up running on two different cores at exactly the same time. The fall out from that is really nasty.

    The reason why a LWP process is so stand alone is accessing other CPU to find out if anything has changed will cause massive amounts of locking. Linux LWP style is about avoiding NUMA issues. Functioning as per Posix would cause Linux to suffer from performance problems from the Posix design. So Linux is not Posix. True Posix OS’s suffer from a particular list of issues due to being Posix conforming in a NUMA environment.

    Price of Linux not being Posix conforming things get strange and you have to be aware Linux does not follow the Posix define of Process very closely at all.

    Linux kernel define of Process being LWP is more suitable for NUMA than Posix define of Process where you are meant to be able to change a stack of things after a process/thread is started.

  11. DrLoser says:

    To further nit-pick myself, this one-to-one relationship only holds within the context of the kernel scheduler.

    For other purposes, one would have to consider the consequences of, for example, specifying the CLONE_IO flag.

  12. DrLoser says:

    ” there is a direct foreign key relationship” provided that there is a corresponding i in I, of course. Apparently I have to nit-pick myself, which is fine.

  13. DrLoser says:

    Yes a task group can contain multi I/O contexts under Linux. This is not Posix behavior.

    POSIX makes no such stipulation.

    In a short, OK, drearily long, three posts, oiaohm, you have just upped your inane comment count from 23 to something nearer to 30.

    Are you trying for some sort of deviant record or something?

  14. DrLoser says:

    Like the fact PID1 by Linux kernel is not the Posix define of PID1.

    A link to the POSIX definition of “PID1,” please.

  15. DrLoser says:

    DrLoser I bet you miss read the sem_open page because you are so focus on attempt to pretend Light Weight Processes don’t exist. If you pretend Light Weight Processes don’t exist Linux will bite you when porting programs to Linux.

    Pure fantasy.

    There are at least five posts lower down where I discuss (correctly or incorrectly) the function of a Linux LWP.

    What leads you to believe that I would discuss something that I don’t believe exists?

    I mean, that’s your domain, isn’t it, oiaohm?

  16. DrLoser says:

    Calling Light Weight Processes just Threads results in you miss reading man pages in highly dangerous ways. Most of the breakages trace to the existence of Light Weight Processes.

    I’m game. Describe a single “highly dangerous way.”

    With specific consequences.

  17. DrLoser says:

    Problem here is not a 1 to 1 mapping. Every LWP has a Kernel thread but not even kernel thread has a LWP.

    That’s because a kernel thread has no reason whatsoever to identify itself with an LWP. One would have to be blind not to recognise this obvious fact.

    OK, I’ll refine my definition:

    a) There is a set of kernel threads, call it K.
    b) There is a set of user-space LWPs, call it U.
    c) There is an intersection between these two sets, call it I.

    For every i in I, there is a one-to-one mapping between the k in K and the u in U.

    To present this in simple terms: if you consider all three sets as SQL tables, there is a direct foreign key relationship between each member of K and the corresponding member of U.

    Thus my statement that there is a “one-to-one mapping.”

  18. oiaohm says:

    DrLoser open semaphore is where things go horible wrong and its critical to understand the existance of Light Weight process..
    http://linux.die.net/man/3/sem_open
    The owner (user ID) of the semaphore is set to the effective user ID of the calling process. The group ownership (group ID) is set to the effective group ID of the calling process.

    http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/linux-thread-problems.html
    Remember from here UID/GID/Credentionals are per Light Weight Process not per Posix Process/TGID.

    “calling process” on that complete man page by implementation is linked to Light Weight Process. Linux implementation of POSIX semaphores is not 100 percent Posix conforming. Yes the result of a virtual non existent structure.

    There are example after example where Linux will behave strange because its not Posix at core.

    Calling Light Weight Processes just Threads results in you miss reading man pages in highly dangerous ways. Most of the breakages trace to the existence of Light Weight Processes.

    Just keep on going DrLoser keep on pulling random Posix things you just find more and more cases Linux is not Posix. Now how can a init system like sysvinit that is designed around the idea system is Posix work well on a system that by reality is not 100 percent Posix conforming.

    DrLoser I bet you miss read the sem_open page because you are so focus on attempt to pretend Light Weight Processes don’t exist. If you pretend Light Weight Processes don’t exist Linux will bite you when porting programs to Linux. Yes Linux unique behavior traces in a large way to the fact the word process has a different meaning to posix standard. Lots of the man pages describing functions on Linux will use the word process when reality they are referring to light weight process not posix process.

  19. oiaohm says:

    Notice I/O context allows multi threads per I/O context where LWP decide it would only allow one.

    I missed something critical. The same I/O context multi kernel threads. Can include kernel threads owning to different LWP owning to different task groups/Posix processes. Yes a task group can contain multi I/O contexts under Linux. This is not Posix behavior. This is where big trouble starts. Linux internals and Posix don’t in fact match.

  20. oiaohm says:

    DrLoser I/O context is another set of grouping. I was staying away from that. What I/O context a kernel thread is happens to be stored in the Kernel Thread Structure. Not the LWP. Basically for a I/O the I/O context is used instead of LWP. There are a stack of items like this. Notice I/O context allows multi threads per I/O context where LWP decide it would only allow one.

    A thread is the smallest Scheduler controllable part. This is computer science.

    All schedulers inside the Linux kernel are handling kernel threads. Not all handle LWP. The two points you find all scheduler controls are cgroups and kernel threads.

    Arrrgh, OK, the inessential detail. The POSIX standard requires that:
    a) All threads in a process have the same PID, and consequently that
    b) All actions that affect the entire process, such as pthread_sigmask(3), are tied to this PID.

    That is the trap. At core Linux is not Posix. Linux is a non Posix OS with a Posix emulator on top. Issue is the Posix emulation has bugs. Like the fact PID1 by Linux kernel is not the Posix define of PID1.

    Most Unix based OS’s at core are not the same. Some internally follow posix some don’t.

    Also notice Light Weight Process has different meaning based on OS as well. Linux each Light Weight Process has it own kernel thread. Other OS’s each Light Weight Process can be sharing a single kernel thread.

    http://www.cosc.brocku.ca/Offerings/4P13/slides/threads.ppt

    And yet, surprisingly, oiaohm, there is a one-to-one mapping.
    Problem here is not a 1 to 1 mapping. Every LWP has a Kernel thread but not even kernel thread has a LWP. It is not a 1 to 1 mapping from Kernel threads side. LWP is a limited group of Kernel Threads. Unified kernel by longene exploits this fact. Allowing NT Process structure to be created inside Linux kernel space using Kernel Threads and then use no LWP. Unified Kernel provides own bridge across to user-space.

    DrLoser
    http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/linux-thread-problems.html
    Start reading and start crying. pthread_sigmask use to not work at all. Ok it works. But items like sync credentials does not work.

    resource limit information is shareable amongst tasks
    Items like this I highly hate for strangeness it can bring. Under Posix this should be in the process structure guess what Linux does not have one. So yes it shareable as now a independent structure but each LWP in a Posix process on Linux can still decide to have it own.

    As of 2010, the controlling TTY and session information for all of the tasks in a “task group” (i.e. process) are those of a distinguished task that is the “group leader”.
    This is another bit of nice fun. Posix TTY and session information own to the process structure. Since Linux does not have a Posix Process structure lets just make all LWP in a Process process reference the first LWP right. Nop. All alterations to the controlling LWP TTY/session are just replicated to all other LWP making up the Posix process. Again no Posix Process Structure. Yes it is possible for one LWP inside a Posix Process to end up with wrong TTY and session information.

    Linux is different. Lack of a Posix Process structure makes Linux behave strange at times.

  21. DrLoser says:

    That would actually be not specifying CLONE_IO … but, either way.

    Strikes me that us “trolls” seem to know more about this stuff than you do, Robert.

    I mean, the very least you could do is to follow up oiaohm’s random links, rather than re-quoting them yourself as though none of us “trolls” had previously considered them.

    Do try to keep up with the discussion, old man!

  22. DrLoser says:

    It [thread context] is what the scheduler works with.

    100% correct again, luvr.

    I wonder what else the kernel is responsible for?

    Once we’ve got through oiaohm’s pathetic misrepresentations of the way the Linux kernel process/thread/whatever scheduler works, we might possibly start another discussion about I/O scheduling.

    Which, btw, is an entirely different thing, and very much not a specific kthread thing. (Clue: remember that nothing prevents you from spawning a new process or thread and specifying CLONE_IO.)

  23. DrLoser says:

    Yes a Linux kernel-space thread is different to a Light Weight Process.

    And yet, surprisingly, oiaohm, there is a one-to-one mapping.

    You can put your socks and shoes back on, now.

  24. DrLoser says:

    DrLoser there is a technical difference between a true thread and a Light weight process.

    Go on then. Amuse us once again by explaining that technical difference, with specific reference to the Linux user space.

  25. DrLoser says:

    Oh well, up to #23 in continuing inanities, I believe:

    A single kthread is inside a Light Weight Process PID/TID.

    Not only is that demonstrably wrong, in the sense that you cannot fit the data structure — Hello, Data Structures! — inside a 64-bit number …

    … But it’s also completely and utterly meaningless.

    Sure, there are several things that an LWP can do, irrespective of the kthread involved.

    For example, an LWP can multiply 2 by 2. No kthread involved!

    Or an LWP can add 19 to 2. No kthread involved! (although oiaohm might have to take his shoes and socks of first, to verify the results.)

    So what, oiaohm?

  26. DrLoser says:

    The least you could have done at this point would have been to consult your favourite source Wikipedia on the issue – or have you already realised that your understanding of all the relevant terminology is so hopelessly wrong that quoting it will simply make you look like an idiot?

    Very possibly unfair. I believe that you, TEG, are referring to this Wikipedia article. Which, I have to say, is a pretty fair summary of the subject.

    Read it and weep, oiaohm. Or (and this is an extraordinarily unlikely eventuality), recant.

  27. DrLoser says:

    If I understand correctly, they are pretty much what is often referred to as “co-processes” (but there may be subtleties that I’m missing here).

    Arrrgh again. This might actually be a handy way of looking at threads, processes and the kernel in some ways, but I think it’s more likely to be misleading.

    Here’s a reasonable cite on co-processes, which might well lead you to the (correct?) conclusion that co-processes are something of an outdated concept.

    To me, a set of “co-processes” is simply a set of processes that communicate via a mechanism like a named pipe. (Or probably two. Maybe even three or four, if you include error messaging.)

    Which brings me neatly back to sem_open(3).

    I wonder if oiaohm has figured out a thread-based excuse for this one yet?

  28. DrLoser says:

    Unless you’re talking about what the referenced article calls “simple POSIX threads”, which are unknown to the kernel and, therefore, to the scheduler.

    Arrrgh, OK, the inessential detail. The POSIX standard requires that:
    a) All threads in a process have the same PID, and consequently that
    b) All actions that affect the entire process, such as pthread_sigmask(3), are tied to this PID.

    These requirements are precisely why oiaohm’s so-called “discrepancies” appear on either side of the kernel boundary.

    Inessential, but worth pointing out if we’re making claims such as “POSIX threads are unknown to the kernel,” which isn’t, strictly speaking, true. (Although admittedly all the implementation details of POSIX have been stripped away by the time you get to a kthread … so, the statement is broadly true.)

  29. DrLoser says:

    Indeed. There is, however, one more detail to be mentioned: a thread has its own execution context. It is what the scheduler works with.

    Absolutely correct in all but inessential details, luvr. That’s what a kthread is there for. (Indeed, it’s why Linux has the concept of thread groups in the first place.

    Unfortunately the fairly straightforward details have been muddied by oiaohm’s insistence on seeing separate data structures where no separate data structures exist; seeing “nastiness” where no “nastiness” exists; and so on. Hopefully TEG, Deaf Spy and on occasion I have cleared all this up. (Please don’t let us start talking about “user space threads” or “green threads…” I shudder to think of the botch-job that oiaohm would spin out of fresh air.)

    One small extra detail: on Linux, a HWP is nothing more than a LWP with one or more threads. At least I think so. TEG may very well contradict me here.

  30. luvr says:

    “A thread shares its memory space with other threads in the same process. A thread shares its handles with other threads in the same process.”
    Indeed. There is, however, one more detail to be mentioned: a thread has its own execution context. It is what the scheduler works with.
    Unless you’re talking about what the referenced article calls “simple POSIX threads”, which are unknown to the kernel and, therefore, to the scheduler. If I understand correctly, they are pretty much what is often referred to as “co-processes” (but there may be subtleties that I’m missing here).

  31. DrLoser says:

    Incidentally I got Windows NT processes/threads hopelessly wrong lower down. Ask TEG nicely and he’ll give you a proper, accurate, description.

  32. DrLoser says:

    That’s actually the one cited by oiaohm lower down, Robert. We’ve been using it as a proxy for an academic reference. (It’s actually mostly correct.)

    TEG’s comment on data structures and LWPs is brief and to the point. Data structures mean nothing in this, er, context.

    Let’s take this from the top, in terms of an abstract OS. A process is something that (ignoring explicitly shared memory, eg shmem) has its own address space, shared with nobody else — thus the MMU. It also has its own collection of other resources (file access, socket access, whatever) which for the sake of argument we can call “handles.” (I’m leaving signals, namespaces, etc to one side for simplicity.)

    A thread shares its memory space with other threads in the same process. A thread shares its handles with other threads in the same process.

    Clearly, using these descriptions: in Linux, a “thread group” is a process. A user space thread is, er, a thread.

    As a thread group/process, you call clone() with CLONE_VM and CLONE_THREAD and very possibly CLONE_IO to ask the kernel for a new thread. If you don’t use the first two flags, you are effectively calling fork() (almost…), and asking the kernel for a new process.

    That’s basically it. No magic involved, no matter what oiaohm claims. And if he ever gets around to his explanation of what sem_open(3) does, this will be even more obvious.

  33. I came across a fairly concise description of these things not on Wikipedia.

    See Understanding Processes In Linux

  34. That Exploit Guy says:

    A Light Weight Process in fact contains complete process data structure. Each kernel PID/TID is complete Process data structure in it own right.

    There are a couple of things that determine whether something is a lightweight process. “Data structure” is not one of them.

    The least you could have done at this point would have been to consult your favourite source Wikipedia on the issue – or have you already realised that your understanding of all the relevant terminology is so hopelessly wrong that quoting it will simply make you look like an idiot?

    Seriously, what’s wrong with impressing people with things that don’t involve lying? As far as the Internet is concerned, you could have been famous doing nothing other than eating your own booger. Give that a try.

  35. oiaohm says:

    DrLoser there is a technical difference between a true thread and a Light weight process.

    In other words, Linux implements Posix threads by mapping them to LWPs … which are, to all intents and purposes (leaving silly labelling conventions to one side), THREADS.
    Completely wrong because LWP is not a Thread.

    A Light Weight Process in fact contains complete process data structure. Each kernel PID/TID is complete Process data structure in it own right.

    In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler (typically as part of an operating system).
    A kthread on Linux is the smallest part that can be managed independently by the scheduler. A kthread does not require A Light Weight Process PID/TID assigned(yes internal linux kernel threading). A single kthread is inside a Light Weight Process PID/TID.

    This is the problem by the generic define of process the Linux Light Weight Process is a Process. Just a process that can only support 1 thread.

    Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.
    If you look up thread then look at Linux you then have a big problem. You can share same resources between TID’s in different TGID groups under Linux exactly the same as TID items in the TGID group.

    http://www.fsl.cs.sunysb.edu/~vass/linux-aio.txt
    Sorry Drloser Linux does have asynchronous I/O.

    DrLoser what has the process like behavior on Linux is cgroups. Cgroups also contain unique information for that group.

    DrLoser Linux is 4 layers of confusion when it comes to what is a thread.
    1) kthread/ Kernel Thread data type being task_struct.
    2) Light Weight Process/Kernel PID/Posix Thread/User space TID
    3) Kernel/Userspace TGID/Posix Process/ Userspace PID.
    4) Cgroups.
    The only one that passes the define of process properly for unique data is 2. 3 and 4 both are just grouping so you can share data between groups without problems.

    What does the Linux scheduler work with? THREADS!
    Right until this point you are correct DrLoser.
    More accurately, it works with LWPs, since a process may be single threaded
    Now you go off into deep blue sea of incorrect.

    The Linux kernel scheduler handles Kthreads. Looks up a reference information in LWP and Cgroup structs that the task_struct of kthreads provides then decide priority. 1,2 and 4 are used and 3 is bogus. Just happens that 3 is what you call a Posix Process.

    Yes a Linux kernel-space thread is different to a Light Weight Process.

  36. DrLoser says:

    Or in other words, Robert (and me before I looked into it):

    If you don’t understand what the kernel scheduler does, then what the hell do you understand?

  37. DrLoser says:

    All of which, in what I think is a quite fascinating way, brings us back to Robert’s original objection to systemd:

    See? That makes my head spin. I need to know what’s running on my PC and why. With systemd, the system is no longer that simple.

    I wish to stress, Robert, that I am not accusing you of gross negligence in this area — because until I started thinking about the Linux kernel in response to oiaohm’s various malformed claims, I didn’d know what was running underneath the covers either! (And yes, I have run various distros of Linux, for several years. My personal choice would be CentOS, but whatever.)

    Did you know the difference between a Posix thread, a Linux kernel-space thread, a Light-Weight Process, a process, a Linux task and a Linux “task group?”

    I think this might be a helpful way of looking at the systemd issue. Because, reading around and using my prior knowledge of how operating systems work, I think I’ve finally figured the important details out. And as mentioned, I now understand why the Linux kernel made the choices it made, and I do not regard them as bad choices.

    May I cordially suggest that you take the same approach with systemd? Regard it as an intellectual challenge, if you will. At the end of which, you are still free to object to the thing.

  38. DrLoser says:

    Incidentally, I personally feel the fact that the Linux scheduler works with threads (and as far as I am aware, with nothing else but threads; but I could be wrong) to be something of a bad policy choice.

    I suspect that it stems from the fact that, unlike Windows NT, Linux has no concept of asynchronous I/O, which means that (as oiaohm’s cite correctly points out) it’s all too easy for a process to starve its own threads by blocking on synchronous I/O.

    There are ways around this deficiency (I’ll leave you to infer what would be the far better way, and you have all the information in front of you to do so), but I suppose imposition of a policy in this case (SURPRISE! NOT A MECHANISM!) is one way to go.

    Without modelling the thing thoroughly, or looking up learned articles in dusty “peer approved” journals — and who needs peer approval, anyhow? — I strongly suspect that this is a perfectly adequate solution for a Linux web server, which basically consists of two heavyweight processes — Apache and MySQL/postGRES/whatever — and a bunch of tiddlers. If you’re I/O bound (and that includes data access to the RDBMS), then I can see this being almost as efficient as having a modern OS with asynchronous I/O.

    On a desktop, it kinda sucks, though.

  39. DrLoser says:

    Remind me again, oiaohm, why Linux feels the need to implement sem_open(3)?

    I say “remind me.” You haven’t bothered to address your encyclopaedic knowledge of the subject to this issue even once, have you?

    I assure you that it is entirely pertinent to the subject matter at hand.

  40. DrLoser says:

    To further explain what the Linux kernel is doing, let’s turn to your cite.

    A straightforward way to implement multithreaded applications is to associate a lightweight process with each thread created in the pthreads library.

    In other words, Linux implements Posix threads by mapping them to LWPs … which are, to all intents and purposes (leaving silly labelling conventions to one side), THREADS.

    In this way, the threads can access the same set of application data structures by simply sharing the same memory address space, the same set of open files, and so on…

    THREADS.

    at the same time, each thread can be scheduled independently by the kernel so that one may sleep while another remains runnable.

    It’s a shame you didn’t follow through on my earlier cite, oiaohm. I genuinely provided it in an attempt to let you argue about the Linux scheduler. (Which is the only possible place for this confusion to arise.)

    What does the Linux scheduler work with? THREADS! More accurately, it works with LWPs, since a process may be single threaded; but to all intents and purposes the scheduler works with THREADS!

    There is an advantage of this implementation. To the kernel everything is seen as processes and the scheduler does not distinguish between threads and processes.

    And here we have a single case where your cite seems to back you up … basically, because it’s wrong and has confused itself. It should read:

    To the kernel scheduler everything is seen as lightweight processes

    Because, believe me, the Linux kernel still recognises processes as processes when it comes to things like memory management. It might call them “task groups,” but that is an implementation detail.

    They are PROCESSES.

    LWP and threads are both used interchangeably to describe an LWP, since typically any application runtime that supports the creation of threads, always creates an LWP underlying the thread though it can be otherwise. In this document therefore we use a thread, a task and an LWP to mean the same.

    But not “a process.”

    Which is interesting, because the rest of the document goes on to talk about PROCESSES.

  41. DrLoser says:

    DrLoser This is direct kernel reporting. Notice something here nasty.

    I’ll truffle around, oiaohm. Let’s see what I can find … oh, this is unspeakably vile! The Tgid and the PPid are identical on both sides of the kernel/task boundary!

    How dare the Linux kernel pull a fast one on you, oiaohm, and prove your contention (that threads and processes are interchangeable in Linux) hopelessly wrong!

    I say again: what is labelled in user space with a pid is labelled in kernel space with a Tgid — in fact, the very same one. Change the labels to “goat” and “sheep” if you like — it’s still a process, not a thread, and the Linux kernel treats it like a process, not a thread.

    Naturally, you didn’t bother to stop and think why both sides of the divide have exactly the same PPid, labelled in both cases as the PPid, did you?

    I wonder if that might finally hit you with a Giant Clue Bat.

    Direct kernel reporting TID does not exist. TID is PID in kernel space. Yes the entry in the kernel structs is PID.

    And once again, it’s just a label. The kernel structures in question deal with threads. They do not deal with processes.

    So PID1 by Linux kernel is always TID1.

    As TEG never tires of telling you, this is merely an implementation detail. It is convenient to refer to the thing as “PID1” rather than “TID1” because, historically speaking, *nixen have always used “PID1.”

    I mean, just how many threads do you think the main kernel process can usefully have?

    Here’s a small hint: ONE. In this single case, the process and the thread are always the same thing.

  42. oiaohm says:

    [user@server ~]$ cat /proc/23638/status
    Name: mysqld
    State: S (sleeping)
    SleepAVG: 98%
    Tgid: 23638
    Pid: 23638
    PPid: 2561

    [user@server ~]$ cat /proc/23638/task/14514/status
    Name: mysqld
    State: S (sleeping)
    SleepAVG: 98%
    Tgid: 23638
    Pid: 14514
    PPid: 2561

    DrLoser This is direct kernel reporting. Notice something here nasty. Direct kernel reporting TID does not exist. TID is PID in kernel space. Yes the entry in the kernel structs is PID. So PID1 by Linux kernel is always TID1.

    Processes have two different meaning on Linux.

  43. oiaohm says:

    DrLoser there is a issue here and its a big one.

    Early Linux. Threading is done by pthread code in userspace. So Internal Linux only has a concept of process being single threaded. PID inside the Linux kernel is still single threaded.

    The fact that the kernel considers a process to be a “thread group” while user space considers a process to be a “process” is a mere detail of implementation, as TEG has tirelessly attempted to drill into your uncomprehending mind.
    This is wrong. Reason TID1 does not have to be in TGID1.

    Hurd kill PID1 from userspace system stops. Linux kill PID1 from user-space system only stops if TGID1 still contains TID1.

    http://careers.directi.com/display/tu/Understanding+Processes+in+Linux
    In effect therefore in Linux everything is a process which either shares the resources of its parent OR does not. In fact fork() is implemented as a wrapper over clone() by setting all flags to share nothing between the parent and child processes.

    DrLoser here is a detailed write up saying exactly what I have been saying.

    I knew I was forgetting something “Light-weight Processes” yes what Linux is has a formal name for its kernel design style.

  44. DrLoser says:

    Oh, go on … it’s only fair. Here’s the relevant link from your original cite, oiaohm.

    Entertain us all by running with it.

  45. DrLoser says:

    Look, to make this even more obvious to someone with an excess of nominalist fervour, let me provide this theoretical example of a generalised OS. Just for fun, I’ll call it “SeenOS” (as in Seen, but not Hurd).

    SeenOS is GPLv3 compliant — unlike Linux — and rather boringly its kernel calls processes, processes. It labels processes with PIDs. It also calls threads, threads. It labels threads with TIDs.

    Now, because SeenOS is GPLv3 compliant, I am fully at liberty to fork it. In fact I think I’ll do so right now (why not? It’s only a theoretical construct). I choose to call it BobOS, in honour of a local hero of Freedom.

    But I’m lazy, and I really don’t want to put the effort in to make BobOS distinctive when compared to SeenOS.

    I know! All I need to do is to rename kernel “processes” to “Pogsons.” And I’ll label them as oidohms, in further homage to the person who first proposed this wonderful concept.

    Hey presto! A completely distinct OS that no longer has any notion of processes in the kernel!

    … except … it does, doesn’t it, oiaohm?

    This is wretched intellectual gruel. Try a little harder, won’t you? Crack a joke or something.

  46. DrLoser says:

    So in this case inside Linux if you see from user-space you have 2 processes if you see from kernel space you have 3 processes.
    That Exploit Guy explain this line away. Come on. Or will you except the reality that Linux the word of process does not have a uniform define. So using the word process when talking about Linux is being careless.

    If I may brusquely jump in ahead of TEG (my apologies, TEG), the only thing to explain here is how you, oiaohm, managed to mangle the information in your cite so thoroughly. We don’t need to explain this. You do.

    The diagram in the top answer of that link clearly shows two processes in user space: #42 and #43. In user space these are labelled with “PIDs.”

    The diagram also clearly shows two processes in kernel space: #42 and #43. In kernel space these are labelled with “TGIDs.”

    So, not only is there a one-to-one labelling correspondence between processes in user space and processes in kernel space as amply demonstrated by your own cite, there isn’t even a projection between the two sets.

    The two labelling systems use precisely the same cardinality.

    The fact that the kernel considers a process to be a “thread group” while user space considers a process to be a “process” is a mere detail of implementation, as TEG has tirelessly attempted to drill into your uncomprehending mind.

    And the fact that the kernel considers a process to be a “thread group” might also, and I stress might because you seem reluctant to face reality in this instance, suggest to you that Linux regards threads and processes as two entirely separate entities.

    “Explain this line away” indeed, you impertinent whippersnapper.

    Any chance of you “explaining away” my toy example of “processy-thready thingies” — A, B, C and D — from the Munich thread?

    I mean, clearly, not even you can come up with an explanation of sem_open(3) that doesn’t feature a distinction between threads and processes.

  47. Deaf Spy says:

    Because to the Linux kernel a multi thread program in user-space is multi process in kernel space.

    If this was true, Ohio, then Linux kernel would be the worst popular kernel out there. 🙂

    You keep your good shape from the Munich thread.

  48. oiaohm says:

    Deaf Spy
    Yet a multi threaded program can be treated and multi process
    No, it cannot. You really can’t grasp this simple difference, can you? Even reading Wikipedia doesn’t help. Tell me, Ohio, have your reading comprehension skills been assessed in school?

    Sorry if you cannot call a multi thread program a multi process program. Linux kernel logic of process define implode. Because to the Linux kernel a multi thread program in user-space is multi process in kernel space.

    Its not a case of comprehension skills it a case of how do you fit the define to how it really used. Linux kernel and Linux userspace have 2 different defines of process.

    Deaf Spy go and look a the diagram notice Linux is strange. Linux does not use word process in ways you generally expect.

  49. oiaohm says:

    That Exploit Guy you might think you are making fun of me. I am about to point out something critical.

    What PID1 is critical to a Linux kernel staying running. All of User-space PID1(TGID1) or just Kernel space PID1(TID1). The answer is TID1. Even if user-space PID1 shows many threads doing stacks of different things the kernel will only reset/reboot… on the direction of TID1 since to the kernel all the other threads of PID1 from user-space are not PID1.

    Reality the arguement that the huge stack of extra features in PID1 is going to cause problems is wrong for Linux. Systemd init threads early to equal to independent process from the kernel point of view. Problem here userspace point of view does not show this picture.

    The difference in meaning of process causes a very big problem assessing the stability of systemd.

    The error in logic that process is a uniform define is causing people to complain about systemd and other advanced init systems incorrectly on Linux. On a system like BSD where PID from kernel space is the same a PID from user space yes the complaints about too much in PID1 is correct for something like BSD. Yes too much in PID1 user space is one reason why systemd is not portable. Complain about possible extra memory consume is kinda valid until you add up how much shell scripts from sysvinit consume up.

    Of course most have missed that everyone is complaining about PID1 when if there was a true issue for Linux the complaints should be TID1.

    A lot of people are caught out by the fact Linux has 2 things that are in fact different called PID1. By using TID1 and TGID1 you have clear meaning what PID1 you are referring to. Kernel developers and Userspace define process differently.

  50. Deaf Spy says:

    Yet a multi threaded program can be treated and multi process
    No, it cannot. You really can’t grasp this simple difference, can you? Even reading Wikipedia doesn’t help. Tell me, Ohio, have your reading comprehension skills been assessed in school?

  51. oiaohm says:

    That Exploit Guy sorry the define of a thread is solid without any room for interpretation. Both the userspace and the kernel space of Linux have two different but valid defines of what a process is.

    Distinction between threads and processes write it up That Exploit Guy covering the mess that the Linux kernel is. And I will have fun ripping y0u to bits for the corner cases that Linux is.

    In computing, a process is an instance of a computer program that is being executed. It contains the program code and its current activity.
    The problem comes down to what you call current activity. A thread meets all the requirements to be a process. But its only a part instance of a multi threaded computer program. Yet a multi threaded program can be treated and multi process.

    That Exploit Guy both usages of process by Linux meet the define of process based on what you call an instance of a computer program. Problem here is the word process is fairly much undefined. You need particular terms defined or word process is meaningless.

    Using the term process with a OS that does not used a single define of Process is asking for it That Exploit Guy.

    So in this case inside Linux if you see from user-space you have 2 processes if you see from kernel space you have 3 processes.
    That Exploit Guy explain this line away. Come on. Or will you except the reality that Linux the word of process does not have a uniform define. So using the word process when talking about Linux is being careless.

  52. That Exploit Guy says:

    This is a good point out where Linux can get magically nuts. Thread Groups are consistent. So in this case inside Linux if you see from user-space you have 2 processes if you see from kernel space you have 3 processes.

    Again, as I said, thread groups are merely a mechanism that allows the possibility of kernel-based POSIX thread implementations. What you are blathering about has fundamentally nothing to do with whether something constitutes a thread/process.

    Keep trying, though. If you keep swinging that bat hard enough, one day you will eventually hit the piñata.

  53. oiaohm says:

    That Exploit Guy
    http://www.postgresql.org/about/licence/
    Read the postgresql license. If you are using one of the commercial modified versions of postgresql you may not have the source code. It is not GPL. At this point its mitigation or not use the commercial features. So you link to source code is worthless for some of these postgresql problems.

    That Exploit Guy
    Again, that has fundamentally nothing to do with the distinction between threads and processes.
    http://stackoverflow.com/questions/9305992/linux-threads-and-process
    Userspace [– PID 43 ————] [————— PID 42 ——————-]
    Datastruct [pid=43 tgid=43]-fork- [ pid=42 tgid=42]- thread-[pid=44 tgid=42]
    Kernel……. [– PID 43 ———–] [– PID 42 ——–][— PID 44 ————]
    This is a good point out where Linux can get magically nuts. Thread Groups are consistent. So in this case inside Linux if you see from user-space you have 2 processes if you see from kernel space you have 3 processes.

    That Exploit Guy what is the distinction between threads and processes from the kernel point of view answer is nothing. Linux kernel will issue a new process id for a new thread. When userspace wants to know that in kernel PID value it has to request gettid. Yes get Thread ID.

    That Exploit Guy see the problem Linux 2 defines of process. Define 1 every thread is a process this is the kernel space define. Define 2 every group of threads is at least process with the fact that every group of threads can be define with more than 1 process ID. Yes a thread group appearing in many cgroup PID namespaces may have many different PID values all being correct.

    That Exploit Guy if you want sanity talking about Linux you don’t talk about processes and threads. What Linux calls processes is too badly defined to be practical. Threads, Thread Groups, cgroups is at least sanely defined and consistent between kernel space and user-space.

    The distinction between processes and threads does not have a static meaning when it comes to Linux it changes with point of view.

  54. DrLoser says:

    DrLoser for someone so called anti-Linux not to know what PID 1 means really is a laugh.

    It was a joke, oiaohm, a light-hearted sally.

    Do you ever essay light-hearted sallies? I haven’t seen one. Perhaps you should give them a go?

    You couldn’t possibly be any more inept at them than you are at technical commentary.

  55. That Exploit Guy says:

    You don’t alway have the source code to patch something. Sometime mitigation is your only option.

    Are you sure about that?

    That is the define right. Except that is not what the Linux kernel is processing. Linux kernel is processing each of the threads individually then group those threads up as it sees fit.

    Again, that has fundamentally nothing to do with the distinction between threads and processes.

    Perhaps you should keep searching in Wikipedia for the answer? XD

  56. Here’s another one:
    lxsession Depends: systemd

    Package: lxsession
    Description-en: LXDE default session manager
    LXSession is the default session manager for the Lightweight X11 Desktop Environment (LXDE).
    .
    It is derived from XSM, has fewer dependencies and more features. It is desktop-independent and can be used with any window manager.

  57. ram says:

    Recent posts indicate this area is sereously serious and complex in the computer science sense. A temporary fix (kinda of, not really) would be for Debian to include both options in their next release and see if the competing teams (both of which have very good arguments) can solve the problems. Perhaps, and it has been known to happen in the Linux community, they can agree on a, perhaps third alternative, that addresses all the problems.

  58. oiaohm says:

    That Exploit Guy
    What you are suggesting is a synchronisation issue. Only an idiot would suggest masking the problem by “blocking network access” rather than fixing the actual problem by patching the daemon.
    You don’t alway have the source code to patch something. Sometime mitigation is your only option. Sysvinit by design lacks the mitigation options forcing you to to extra hacks to work around these problems. Yes synchronization issues do happen. Systemd is about starting stuff in a synchronized way. So you don’t start things in the wrong orders or at the wrong times.

    That Exploit Guy
    In computing, a process is an instance of a computer program that is being executed. It contains the program code and its current activity.
    That is the define right. Except that is not what the Linux kernel is processing. Linux kernel is processing each of the threads individually then group those threads up as it sees fit.

    Threads inside the same PID don’t have to come from the same executable file or the same computer science meaning of process on Linux. So you can have 2 or more processes by computer science terms but only appear as one PID/Process by Linux logic. That Exploit Guy the computer science theory of processes don’t match Linux. How do you think you replace PID1 running code under Linux. Yep that is right start up a new process have it take PID1 and then have what was on PID1 quit. So 2 processes sharing exactly the same Process ID. Process ID’s virtual beasts with basically no trust-able meaning under Linux.

    The computer science concept of Process does not exist in the Linux kernel. Yes there are things that suggest they do but you miss the examples where one ProcessID could be a unlimited number of computer science processes.

    Threads and groups have real meanings in Linux kernel. A process on a Linux kernel is just a virtual group of stuff That Exploit Guy. Get it now. There is no such thing in the Linux kernel what you would normally call a process restricted to obey the define computer science process. There is something that is called a process that is so far virtual that its not funny that is nothing more than a group of what you call computer science processes/threads.

    Using the computer science meaning of process will lead you into trouble with Linux because that is not what the Linux kernel is using. Threads and groups is what Linux is using. Process data has to appear to keep posix application happy. But since its only existing to keep applications happy Linux can break the rules all over the place.

    Process ID in Linux terms is a group that could contain 1 process or many processes. Thinking term process makes you think each only contains 1 process that can be critically wrong.

    That Exploit Guy the linux kernel define of process does not match the computer science define. Linux kernel define of process matching the computer science define group of processes/threads.

  59. That Exploit Guy says:

    One of the historic postgres faults is that it would open up it network connection before either logging or writing was enabled.

    What you are suggesting is a synchronisation issue. Only an idiot would suggest masking the problem by “blocking network access” rather than fixing the actual problem by patching the daemon.

    Internal Linux kernel does not really know what a processes is. A thread and cgroup yes but process no.

    Again, this simply shows your complete lack of understanding of the difference between a thread and a process. I must say it’s absolutely amusing to watch you desperately throwing blind guesses like these in the hope of hitting the right answer, though.

  60. oiaohm says:

    That Exploit Guy you know stuff all about Linux threading. Reality development history is evil. Early Linux uses user-space threading with kernel space process ID. When Linux implements kernel native threading. The difference between process and thread was never implemented in any of the schedulers.

    Multithreaded programming. Is part the right question part the wrong question. Buffer overflows can happen in some applications because particular sections are not running yet. Databases are sometime what you call multi process not just multi threaded. Buffer bloat is a related issue. A running postgres is in fact 6 different process listing. Only one of those processes writes to data to database. One of those processes is logging. One of the historic postgres faults is that it would open up it network connection before either logging or writing was enabled. Now you could fill the process sitting on the socket buffers until it died. This has been fixed but its not the only program out their with this kind of issue.

    Due to the fact Linux kernel internal only knows threading and cgroups (including sched_autogroup_enabled) it very possible for the threads of your multi threaded and multi process applications and be having strange trouble on Linux when on BSD and other UNIX systems don’t happen. BSD and other Unix systems schedulers would load balance between processes. Internal Linux kernel does not really know what a processes is. A thread and cgroup yes but process no.

    That Exploit Guy sysvinit is design for real Unix System V. Unix System V had idea of processes and threads. So depends on PID tracking and performance tweaking. Linux PID tracking is mostly a joke.

    Linux is a different model. Now if users wish to keep sysvinit they really need some kernel developers to implement process support properly in Linux not just the I create data structures so I can tell the userspace what it expects as the Linux kernel uses now.

  61. That Exploit Guy says:

    Remember a complex service like a database may take many mins to get fully started up but in fact might open its network sockets before its ready.

    Interesting. Care to explain this in the context of multithreaded programming (even though we all know you understand stuff all about the subject)?

  62. oiaohm says:

    DrLoser for someone so called anti-Linux not to know what PID 1 means really is a laugh.

    Linux is interesting. PID=Process ID. PID0 is reserved by the Linux kernel and in fact PID2 is also reserved by kernel under Linux.

    PID1 is the init process started by PID0 this shows up if you do a ps -eaf only one other thing is started by PID0 is PID2 that is kernel part kthread. If kthread or init exit the system will either shutdown, reboot or kernel panic. That is if of course the PID or PPID values you are seeing are reality kernel. cgroup PID namespace allows PID and PPID information applications are seeing to be false.

    Yes there is worry about making PID 1 more complex but it comes down to exploit possibilities. The risks of making PID 1 more complex are offset by the flaws that are prevented.

    Once a daemon is “booted up,” as per what system is intended to do (with effectively a root security premise, fwiw), the “attack vector” is the same at minute one as it is at the Rapture. It really does not change. There is no reason for it to change. Do you have any useful contribution here? You do not. The attack vector is pretty much static.

    This is what happens when a person does not understand cgroups and Linux security and systemd. With sysvinit and selinux/apparmor the security settings are fairly much static. With systemd mixed with logind security settings don’t have to be static. cgroup file-system name-space displayed to daemon can changed based on what is going on. Other cgroup limitations can also be adjusted on the fly as the application is running.

    Early init of service attack is possible under sysvinit many end up not possible under systemd or openrc. Remember a complex service like a database may take many mins to get fully started up but in fact might open its network sockets before its ready. Service changes secuirty under systemd and openrc when its believed ready to process incoming traffic. Systemd and openrc does that is interesting is block network access by cgroup on starting services until they reach running state. Systemd and openrc is dynamic security. Linux has supported at kernel level dynamic security for a long time.

    It really does not change. There is no reason for it to change.
    This is completely bogus. There are reasons like connecting to a public network and no longer connected to a company network any service that not required should be isolated and possibly shutdown. Only users logged and accessing system have no rights to access a particular service then the service should be shutdown. List goes on and on of mitigation actions that require the system to operate dynamically.

    Sysvinit is static security. Systemd and openrc are dynamic. This means Systemd and openrc have different flaws to sysvinit. Remember some history service hacks against Unix and Linux have been that the service has been running for days leaking memory. If you restart services every so often you reduce memory leak problems and prevent particular security flaws from becoming functionally exploitable. If a service is not in use its better off shutdown this is exploit mitigation.

    The reality is when you get down to it sysvinit is 1 not compatible with the Linux kernel due to Linux kernel difference in meaning of what a process means to fairly much every other Unix. Number 2 sysvinit is design for starting processes with static only security when Linux provides dynamic.

    Dynamic world static security fits poorly. Implementing dynamic security has not been done that much because its hard.

  63. DrLoser says:

    dbus as an integral part of PID 1? You must be kidding, eh? dbus was intended to supply frills to GUI applications much higher up on the stack. Aren’t we getting rid of X because it’s insecure? Why use dbus to take up the slack?

    I believe you are confusing me (Dr Loser) with an ad hominem, Robert.

    I neither know nor care about PID1. Is it a vanity license plate in Toronto, perchance?

  64. DrLoser says:

    Boot-up is the least-likely time for an attack. It’s when all those processes systemd runs are sitting in RAM 24×7 for years that you should worry.

    If you’ll permit me to observe this, Robert, you are somewhat lacking in security knowledge. Two simple observations:

    1) Once a daemon is “booted up,” as per what system is intended to do (with effectively a root security premise, fwiw), the “attack vector” is the same at minute one as it is at the Rapture. It really does not change. There is no reason for it to change. Do you have any useful contribution here? You do not. The attack vector is pretty much static.
    2) Should part of the “booting up” process for a daemon involve a shell script, the “attack vector” is instantly indeterminate and completely out of control.

    But, have fun exercising your rights to fiddle with bash shell scripts that control important parts of the system.

    Which raises another interesting question.

    When was the last time you felt the need to do this?

  65. oiaohm says:

    DrLoser
    You’d actually have to carefully craft a deliberately subversive init script to get around the security protections that systemd gives you.
    This is one of the interesting points. Subversive init script may not be given privilege by unit file in systemd. In fact what UID/PID/filesystem… the script may be seeing may be completely false. This is the containerization that systemd has. Long term goals of systemd is progressively take rights away so making subversive attacks harder. Reduce access to services results in limitation of possible damage.

    openrc and systemd have a lot in common. One of the big hazards with sysvinit is the share common script files. There is a big hazard with with sysvinit is /lib/lsb/init-functions.

    Robert Pogson
    dbus as an integral part of PID 1
    You are forgetting that due to systemd cgroup options being able to access the process at PID1 can blocked access completely from every other process on the system even show a false PID1 data. Sysvinit related use a socket solution with PID1 with only the requirement to have UID 0 to be obeyed with no option to say X services may not order the init system around. You depend on selinux or apparmor or some other LSM to prevent a sysvinit system service from being able to order system to shutdown. systemd is about having init system control secured no matter the LSM is use.

    Something super fun is that PID1 of systemd in fact will start with dbus disabled. It is possible to build systemd to use socket control. The question is containment.

    It’s when all those processes systemd runs are sitting in RAM 24×7 for years that you should worry.
    Reality here systemd using pure unit has a smaller ram profile than sysvinit scripts and don’t have the issue like /lib/lsb/init-functions. Yep modify the common share /lib/lsb/init-functions in a sysvinit system and you are able to exploit a lot of locations at once. Also its far more complex interaction. A bug in init-functions script could appear to be coming from other locations. systemd is cleaner.

    Robert Pogson the problem here is sysvinit was not secure to start off with.

    Every time you see what appear to be a extra risk with systemd from a security point of view you find mitigation.

    Now openrc vs systemd is a closer competition. The historic sysvinit based systems need to die. Of course some are saying they will migration to freebsd and so on. At least this is moving to using a more secure design init system.

  66. ram says:

    Robert Pogson wrote: “Boot-up is the least-likely time for an attack.”

    To which I’ll add, especially if networking gets turned on last!

  67. DrLoser wrote, “a systemd boot-up will have a smaller “security attack surface” than a SysV init boot-up”.

    Boot-up is the least-likely time for an attack. It’s when all those processes systemd runs are sitting in RAM 24×7 for years that you should worry. dbus as an integral part of PID 1? You must be kidding, eh? dbus was intended to supply frills to GUI applications much higher up on the stack. Aren’t we getting rid of X because it’s insecure? Why use dbus to take up the slack?

  68. DrLoser says:

    And once more I am compelled to admit that oiaohm has picked up on a very relevant point: this time, a complete misapprehension by Robert of what constitutes a security attack surface:

    It gives a huge attack-surface to a single point of failure.

    Ummm, Robert. That’s not actually what an “attack surface” means.

    Not to get too medievally mathematical on your butt here, but I’d like to hope that you understand the difference between a two-dimensional surface and a one-dimensional point.

    Which is actually an almost exact mapping of what oiaohm is talking about here, bless the little lad.

  69. DrLoser says:

    (Those init scripts, by the way, would not just be vanilla init scripts. systemd is by design open to init scripts.

    (You’d actually have to carefully craft a deliberately subversive init script to get around the security protections that systemd gives you.

    (In other words, you would have to be your own personal infection!)

  70. DrLoser says:

    The reality is running sysv init based solutions you attack surface is in fact larger than running systemd.

    It’s not like me to agree wholeheartedly with oiaohm, Robert. We all know that, I think.

    But in this particular case, he is right and you are evading his point. Almost per definitionem, a systemd boot-up will have a smaller “security attack surface” than a SysV init boot-up. Which is why Apple and Sun use a similar approach (cf finalzone on this point).

    It’s possibly to increase the attack surface of a systemd boot-up to the point where it entirely matches the attack surface of a SysV init boot-up, I suspect, if you blurt enough pointless init scripts into the process. But it isn’t possible to exceed it.

    Y’see, Robert, back in the day I was employed to do an analysis of these SysV init attack surfaces, for a major telecoms supplier. The results were frightening to say the least.

    I am prepared to accept that both oiaohm and finalzone have been tasked with similar activities. Both of them, in this case, sound like they know what they are talking about.

    I’ll bet you’ve never even considered the possible attack surfaces of your SysV init process once, have you, Robert?

  71. Finalzone says:

    Robert Pogson wrote:
    Finalzone defended systemd…
    Yes because I have never seen a FOSS software receiving tremendous misinformation having following its development from day one and the transition from sysvint to systemd via upstart within Fedora Project. Systemd idea is nothing new, being done before by SUN with its Service Management Facility and Apple Launchd.

    Robert Pogson wrote:
    My analysis of commits to systemd shows in the last 14 days, commits were from 5 people:

    Colin Guthrie: Mageia developer and contributor involved in systemd
    LennartPoettering: famous software engineer behind avahi, pulseaudio and currently systemd. Currenty works for Red Hat and also a Fedora contributor.
    PeterHutterer: sofware engineer behind Xorg input notably evdev and multiple pointers X. Also involved in Wayland input. Fedora contributor and current Red Hat employee.
    Tanu Kaskinen: PulseAudio developer currently works for Intel

    It is interesting that you mention you don’t know them yet the same thing applies on any FOSS software you use. Their contributions help improving GNU/Linux ecosystem

  72. Finalzone says:

    “Arch, with systemd running a native systemd configuration, consistently booted in 40 seconds, 10 seconds slower than Debian running SysV init.”
    Left in details is the author failed to mention which update Arch runs on and compared it with Debian Jessie. Interesting that the same person got identical time of Debian Jessie running systemd with systemd as he mentioned: After all, I’m forcing systemd to use SysV init scripts rather than native systemd configuration files..

    It’s possible there’s something wrong with those comparisons but the vaunted speed of booting isn’t obvious.
    Yes as quoted above. Factors to take account are the service themselves. Speed will come after Debian complete its transitions to systemd.

    I have some optimization of booting within sysvinit, with the innserv package […]
    Then systemd can also be optimized as well with this linked example
    http://www.harald-hoyer.de/2013/11/13/fedora-boot-optimization/ . Note this is for Fedora but other distributions may have similar experiences. In addition, bootchart is included to track services slowing down boot. Once you get used to service configuration, you will never go back using script to do similar task.

  73. A guy discusses various pros and cons of systemd and then makes a test of booting-speed. “Arch, with systemd running a native systemd configuration, consistently booted in 40 seconds, 10 seconds slower than Debian running SysV init.”He found no difference between Sysvinit and systemd on Debian GNU/Linux.

    It’s possible there’s something wrong with those comparisons but the vaunted speed of booting isn’t obvious. Again, more evidence of useless changes. I have some optimization of booting within sysvinit, with the innserv package:
    “boot sequence organizer using LSB init.d script dependency information
    The insserv program is used by the standard SysV-based init system. It updates the order of symlinks in /etc/rc?.d/ based on dependencies specified by LSB headers in the init.d scripts themselves.
    These declared relations between scripts make it possible to optimize the boot sequence for the currently installed set of packages, while detecting and rejecting dependency loops.”

    See Debian, systemd and forks.

  74. oiaohm wrote, “The reality is running sysv init based solutions you attack surface is in fact larger than running systemd.”

    Sys V Init basically starts and stops processes. Systemd is doing everything but washing the dishes. I find it hard to believe that some hacker won’t find a crack in systemd and bring the house down just like that other OS always fell. Every method of containment has always developed some vulnerability. Just because cgroups is newish doesn’t change that. What this new means of isolation does is make me less in control of my computer. I don’t like that. GNU/Linux is like the little red convertible for this old guy. I get to feel the wind in my hair. I feel that systemd is putting all that I love in boxes and putting it in storage. I hate that. That’s what M$ did, put layers between the users and the guts. It doesn’t work. We have more than enough layers of abstraction. Less is more.

    All the arguments people make about cloud v local apply here. Systemd is like some local cloud, a foreign operating system splattered all over GNU/Linux like Android was. It may work. It may even have some theoretical advantages but it is not my operating system of choice. I like to know what my processes are doing. I don’t need systemd to watch over them.

  75. oiaohm says:

    That’s absolutely wonderful except I don’t need any of that.
    Except there are problem.

    Freebsd and the rest of the BSD OS’s use a init system designed for the way their kernel operates. BSD Init. Sysvinit was design for how a Sysv system operated. Sysv is not how a Linux kernel.

    Linux needs init systems designed for it.

    What systemd is for becomes extremely clear when you read this.
    https://code.google.com/p/d-bus/source/browse/kdbus.txt

    Notice how kdbus is designed with the idea of running items inside containers/cgroup. kdbus becomes the communication.

    Systemd is stage 1. kdbus is stage 2. Stage 3 is more isolation between processes and users. Stage 3 is where we start seeing systemd changes providing their major advantages.

    The reality
    It gives a huge attack-surface to a single point of failure.
    Yes systemd does give a single point of failure possibility. But the huge attack-surface area arguement is why implementing systemd is required. The reality is running sysv init based solutions you attack surface is in fact larger than running systemd. cgroups in fact reduce the surface area that an exploit can access. Like application running in a process namespace in cgroup can find it impossible to send kill signal to the init system.

    Remember each sub application of systemd is running in it own cgroup. Own cgroup equals nice things like private temp directory limited read/write all over the system.

    With kdbus everything changes. Services only need to see the dbus entries they need to use or interface with with kdbus. Same with users.

    Systemd advantages will become more clear over time. Remember systemd mandates cgroups on. Why this is to mandate a min security level.

    keeps track of processes using Linux control groups
    This is the problem this is half the story. Control groups 1 track process 2 apply limitations on what processes can and cannot do.

    There are going to be those who reject systemd mostly because they cannot see why yet.

    Systemd also gets away from a huge stack of undefined shell features.

    offers on-demand starting of daemons
    This is something a lot of people want but don’t know it. Systemd does not just do start on demard. Systemd also include per deamon watchdog.
    http://0pointer.de/blog/projects/watchdog.html

    A systemd init system can be finding out about errors before anyone notices. Systemd does pick up without requiring user to look that all processes in a service has stopped and does not give a false positive that a service is running when its dead or the reverse.

    I do think others will appear to compete with systemd. kdbus standardized in kernel will help the other compete. Question here is if kdbus will become part of BSD kernels as well.

    You can think of the existing dbus as a prototype and kdbus is final form. kdbus is feature enough complete to use dmabuf threw it.

    kdbus also removes the over network feature of dbus. This is the problem you are ready running lots of stuff using dbus.

  76. DrLoser says:

    Now, naturally, quoting John Pilger back at a (presumed) Canadian newcomer to this site who claims that John Pilger Rocks!

    I feel compelled to leave here this entirely justified Fisking of John Pilger, however.

    No disrespect intended to your otherwise eminent commentator, Robert. But Pilger is a well-documented liar, bigot and all-around dangerous fool.

  77. DrLoser says:

    (For Pottering read Pid Eins.)

  78. DrLoser says:

    This is Debian we’re discussing, as well as systemd. The average Debian user is quite likely to be well informed and probably installed the OS him/herself. Yes, I know Debian runs in a lot of schools where perhaps only the computer guy knows about it.

    So, let’s posit a school with 100+ Debian desktops/thin clients and a server or two. And only the computer guy “knows about” — translated, has probably read a few Slashdot articles and other secondary cites — systemd.

    In a sense, that fits in with your intended usage of “essential,” Robert. systemd clearly isn’t essential.

    But it’s there anyway. And is it obviously a bad thing? You seem to be coming up with some resistance on that point from readers who are otherwise very much on your side.

    Would it hurt you to read Pottering’s eloquent defence of the thing (as cited by me)?

    Oops, pardon me. You’ve already made your mind up. That’s what academic types do, isn’t it? Once they’ve made their minds up, there’s no sense cluttering up absolute imperatives with externalities like, well, evidence.

  79. DrLoser says:

    So, the lack of “bloat” in OpenOffice.org is likely that developers have not been developing, rather than any quality of the operation.

    This renders the entire concept of “bloat” completely meaningless, doesn’t it? (I happen to think that it is, but you seem to believe otherwise.)

    How else do you measure this elusive yet vital quantity, Robert?

    Oh, and 146MB + dictionaries is still considerably less than 219MB, isn’t it? Particularly since dictionaries (which incidentally would fit most people’s definition of “bloat,” unless you are a polymath who speaks 20+ languages) compress down rather nicely.

    “I managed to find a version of OpenOffice which is slightly more bloated than your version of OpenOffice, even though it’s still considerably less bloated than LibreOffice” is some sort of argument, isn’t it, Robert?

    What sort of argument? Let’s see. I’d say its the sort of special pleading argument in which oiaohm is so well versed.

    Not, I submit, a direction you should aim to head in.

  80. DrLoser says:

    I don’t know these people and don’t trust them to control my systems.

    You are, I presume, on first-name terms, complete with private mobile number and email address, with all the other people you trust to control your systems?

    Linus Torvalds, Ian Murdock, Greg Kroah-Hartman, for example?

    Obviously you don’t need to know these people personally when it comes to

    a) Developing and patching a kernel
    b) Organising, packaging and releasing a distro or
    c) Maintaining critical (I might even be so bold as to use the word “essential,” although only in the sense of “smelling of the bullshit they are built out of”) system libraries.

    You can, of course, do all those things yourself. It is, after all, what gives you control over “your systems.”

    Oh, wait, this is just another of your little hobby-horses reinforced by irrational dislike of other people on a personal basis, isn’t it?

    Carry on; I see what you’re getting at, now.

  81. Finalzone defended systemd…

    From the website,“systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.”

    That’s absolutely wonderful except I don’t need any of that. I know it might be useful to have the tree structure of processes and their offspring and predecessors but I only use that kind of information rarely and I have ~1K processes running on my LAN. It just makes no sense to me to require one package to do all that. It gives a huge attack-surface to a single point of failure. That’s how M$ did things and it all fell down many times.

    My analysis of commits to systemd shows in the last 14 days, commits were from 5 people:

    • Colin Guthrie
    • LennartPoettering
    • PeterHutterer
    • sthibaul
    • TanuKaskinen

    I don’t know these people and don’t trust them to control my systems. I’ve read Poettering’s stuff and I’m not impressed. He doesn’t understand that I want to use my system and not make it his playground. Systemd seems about ego, not good IT.

  82. Finalzone made some good points but made this dig, “It is currently outdated with a seemly lack of activity for years.”

    Some technology becomes mature and no longer needs frantic development. When you retire, maybe you will understand such patience. Here’s the list of releases with dates. The 4.11 desktop was released a few weeks ago. The next release of XFCE4 is imminent judging by how many 4.11 components have been released. It seems to me only a couple remain to be updated: xfce4-docs, and xfconf. I’m using 4.10 in Jessie/testing.

    Finalzone wrote, “Faster input and security where intruder will have hard time modifying the log reports.”

    If the message is generated in binary form, say a time and some code, that would be true, but then I would need some application to interpret it. If the messages are generated as character strings and then encoded, that would not be true. If I want to monitor the logs and take some action automatically by some script, that would not be true. So, I see the binary logs removing flexibility for some doubtful benefit. One could run over the logs and generate some checksums but that would slow down the process of logging… I don’t have any system busy enough that binary logs would be a benefit.

  83. Finalzone says:

    Robert Pogson,à
    Systemd is a modern GNU tool under LGPL license where everyone can contribute as its tremendous amount of contributors shows combining existing ideas and implements them better. Linux kernel badly needs that kind of system management for a long time after several failed attempts in three decades.
    The adoption of systemd in nearly everywhere from embedded to supercomputers by non only distributons but also bigger industries like GENEVI is evidence that it solves real world problem. In that case, a standard of better practice is needed. Think systemd as a toolbox.

  84. Finalzone says:

    ram,
    could you explain how systemd is a wrong approach?

    Robert Pogson,
    John Pilger rocks! has a point about average (ordinary) users i.e. not caring about systemd let alone sysvint and other parts currently used in stable Debian because those components are practically technical. Did average accept that sysvint was imposed to them when better alternative were available back then?
    Why on Earth would a distro known for openness even think of binary logs?
    Faster input and security where intruder will have hard time modifying the log reports. You can request text format by using for example journalctl > logs.txt. Binary are practically everywhere including in apt-get via tar, gzip and even database.
    I would have no objection to the distro adding the package but it’s not “a package”. It’s a whole new way of doing things with no particular purpose except to change a bunch of things.
    Actually the whole Debian Technical Committees already covered that part and already selected systemd for the next Debian release. The current issue is the implementation which is Debian specific in contrast of other distribution like Fedora, openSuse and Arch. Debian is no longer a leader for a long time.
    Users demanded the change to XFCE4 but now they are switching to GNOME because it’s “aware” of systemd! That’s not what users wanted. I can easily work around GNOME by installing XFCE4 but I have to give up a bunch of applications I like.,
    XFCE4 is default on non x86 and non x86-64 system. It is currently outdated with a seemly lack of activity for years. GNOME depends of D-Bus features implemented by logind and consolekit is dead for years without maintainers despite the pleas. Be in mind that most systemd components are optional as explained several times. You should better read more and see how systemd exactly work.

  85. ram says:

    Seems to me that systemd is the wrong approach. Debian should either reject it or just offer it as an option. It certainly should not be the default.

  86. John Pilger rocks! wrote, “The idea that the average user knows or has even heard of systemd or this ‘crisis’ is laughable. If you know of systemd, you are definitely in the 1% of tech and have no idea what an average user is. And even less what the user wants.”

    This is Debian we’re discussing, as well as systemd. The average Debian user is quite likely to be well informed and probably installed the OS him/herself. Yes, I know Debian runs in a lot of schools where perhaps only the computer guy knows about it.

    I chose Debian many years ago because of its reputation as solid and reliable which is what I desperately needed after nightmares with that other OS. Other distros worked but IMHO Debian’s policies, openness and APT are killer-features. I like many other average users of Debian GNU/Linux have learned how to do whatever we needed to do and changing the init system is something we can see. Why on Earth would a distro known for openness even think of binary logs? The GNU tools are in Debian to be used. Why on Earth would a distro with a policy of serving users, change to systemd without any demand by users? I certainly didn’t demand it. I would have no objection to the distro adding the package but it’s not “a package”. It’s a whole new way of doing things with no particular purpose except to change a bunch of things. One of the biggest reasons an ordinary user trusts Debian is that the defaults are pretty reasonable. Users demanded the change to XFCE4 but now they are switching to GNOME because it’s “aware” of systemd! That’s not what users wanted. I can easily work around GNOME by installing XFCE4 but I have to give up a bunch of applications I like.

  87. >I mean, the Gnome desktop was designed by Miguel de Icaza.
    >Now, there’s a visionary champion of FLOSS that we can both look up to, for once!

    Miguel de Icaza.
    Miguel de Icaza.
    Miguel de Icaza.
    Ok. so i guess its NOT like Beetlejuice when you say his name 3 times.

    Finalzone wins this one.

    Overall, Gerhard Mack sums it up best:

    – At the same time, “I think if they were likely to actually fork Debian, they would have just gone and done it rather than throw a massive public temper tantrum,” consultant and Slashdot blogger Gerhard Mack suggested.

    “Secondly, I think there is a lot of misinformation out there about what Systemd does and how it works,” Mack added. ‘At the beginning of all of this I was very worried about the stability and security of the systems I maintain after reading the nerd rage on Slashdot, The Register, and sites like Boycott Systemd, so I looked into Systemd for myself.

    “What I have discovered is that they seem to be confusing Systemd with things that are bundled with Systemd but run separately using a ‘least privilege needed for the task’ type design,” he explained. “There are things I don’t like, such as the binary logs, but then I can just configure it to run through syslogd as usual and ignore the binary logs.”
    Particularly “hilarious,” Mack added, is that people “suggest that only desktops need to boot quickly,” he said. “I have seen some automated systems that load VMs on demand, and they would be much more effective if they booted faster.”-

    MrPog: Is this “run through syslogd as usual and ignore the binary logs.” a problem to do like Mack?

    And to be honest I cant help laughing when I read everyone talking about what the ‘user’ wants. The idea that the average user knows or has even heard of systemd or this ‘crisis’ is laughable. If you know of systemd, you are definitely in the 1% of tech and have no idea what an average user is. And even less what the user wants.
    Unless were still going with ‘Linux is only used by techies and nerds’ memes.
    The ‘user’ is no different than Rev Lovejoy’s wife ‘children’. Its more of a concept in the minds of these developers. “Im doing this for the children. Im doing this for the user. Im doing this to fight terrorism.”
    Its not about users for developers.

  88. Finalzone says:

    Agent Smith,
    Disagreed. GNU/Linux days are still present but adapted to modern environment. Gone are the relics of duplicated efforts to do same functions i.e. systemctl combine both service and chkconfig command. Systemd, a LGPL2+ software, is the collaboration of over 500 contributors from distributions to IT industry to make a standard when it comes to core functionality.

    Debian is victim of its own problems trying to support everything including multiple inits and core functionality while attempting to impose their will on upstream. One of its developers trying to slow down the entire project unhappy the trend goes against his will. Looking at Debian own stat from popcon.debian.org, 99 percents of users run on Linux kernel meaning other kernels are so minuscule it is ridiculous to assume that tiny portion influences the decision.

    Basically, it comes to a few people who never actually try, refuse to read documents or spread misinformation about systemd as system management. The current state of Debian Jessie are mainly related to packaging issues, the maintainers should ask other distributions for guides.

  89. DrLoser wrote, “Apache OpenOffice 4.1.1*: 130.5MB.”

    I don’t know where you looked but my download was 146MB including an 11MB “language-pack” and it didn’t include dictionaries. So, it’s not that much different. Now let’s consider the feature list…
    OpenOffice 4.0 v LibreOffice4.1 is about a draw, but meanwhile LibreOffice is up to 4.3 and excelled with Coverity.
    “the greatest difference is revealed on Open Hub: while LibreOffice has 298 active contributors to its code, OpenOffice has only 39. Unless this ratio alters quickly, OpenOffice is unlikely to stay competitive, no matter how dedicated its developers are.”

    So, the lack of “bloat” in OpenOffice.org is likely that developers have not been developing, rather than any quality of the operation.

  90. DrLoser says:

    And the asterisk? Whoops.

    * We all love Apache, don’t we?

  91. DrLoser says:

    The Document Foundation has spent years overhauling the OpenOffice.org code to strip out as much unnecessary stuff, added over the years by olderman’s process, as possible.

    Apache OpenOffice 4.1.1*: 130.5MB.
    Libre: 219.6MB

    You’re not exactly winning this argument, are you, Robert? I’d hate to go to a strip club in Manitoba.

    Laydeez and the inevitable Gents — may I present Lola “Lolita” McFlibbertygibbet?

    A nymphet who will toy with your affections, starting with a coy outfit of, let’s say, a purple polyester pant-suit, and end up swathed with so much bloat that she ends up looking like an Inuit in the middle of winter accidentally pretending to be a clump of moose in a single spot?

    I have absolutely no idea what the collective noun for moose is, but that’s basically what we’re talking about when we’re considering the ongoing Document Foundation efforts to strip Libre of “bloat,” isn’t it, Robert?

  92. DrLoser says:

    The Document Foundation has spent years overhauling the OpenOffice.org code to strip out as much unnecessary stuff, added over the years by olderman’s process

    Stand up, Olderman, stand up Proud!

    Er … what precisely was that weird little interjection supposed to mean, Robert?

  93. DrLoser says:

    Well, now, on my system running Jessie…

    The fact that your favourite downstream amateurs are unable to get the simplest bit of system initialization packaged correctly doesn’t really prove anything at all, does it, Robert?

    Well, one thing. But on the other hand, they’re presumably still your favourite downstream amateurs.

    Even though they’ve apparently embraced systemd.

  94. DrLoser says:

    If it helps you in this regard, Robert, shared object libraries, commonly suffixed with the letters “so,” are merely delivered as part of a package and do not in any obvious way drag in dependencies to systemd, which is clearly a framework for organising daemons.

    Now, should your applications depend upon those daemons, then I guess you’re shit out of luck. But in all honesty that sounds like an unlikely eventuality, given the fact that you’re talking about the Gnome desktop.

    I mean, the Gnome desktop was designed by Miguel de Icaza.

    Now, there’s a visionary champion of FLOSS that we can both look up to, for once!

  95. DrLoser says:

    gnome, the desktop environment…

    … is not “Gnome libraries, the set of which other desktop applications rely upon,” Robert.

    That was my point.

    May I suggest that you download that huge bunch of what we would both call “bloat” and see whether systemd has in some weird and unaccountable way infected the applications you use?

  96. olderman wrote, “The world uses what it needs to make its software, and if that means that a developer pull in pre-made libraries that add bulk, then that is the way it’s going to be.”

    That’s often true except in the embedded world or places with few resources but this is the init-system of most of GNU/Linux, not some GUI application. The lower layers of any system are better off being leaner. What systemd seems to be headed for is everything running in a virtual machine running on top of Linux. No user or developer is asking for that. Nothing I know requires it. It just seems to be some egos wanting to make a mark entangling some new software in everything.

    On my computer, the Linux kernel and perhaps the big applications LibreOffice and FireFox are the most complex/sophisticated/naturally-bloated things around. My kernel is ~5MB compressed, LibreOffice comes to a couple of hundred MB, and FireFox is a 30MB package. Linus tolerates bloat in the form of zillions of drivers so that Linux will be universal but there’s nowhere he allows patches hauling in a bunch of stuff for no very good reason, even convenience of the developer. The Document Foundation has spent years overhauling the OpenOffice.org code to strip out as much unnecessary stuff, added over the years by olderman’s process, as possible. At the same time they increased the feature-count. Adding stuff for convenience inevitably slows things down, increases total bug-count and adds vulnerabilities.

  97. DrLoser wrote, “I suspect that most if not all Gnome dependencies will be entirely unaffected by systemd”.

    Well, now, on my system running Jessie:

    • gnome, the desktop environment, depends on
    • avahi-daemon, “Avahi is a fully LGPL framework for Multicast DNS Service Discovery. It allows programs to publish and discover services and hosts running on a local network with no specific configuration.”
    • , which depends on

    • init-system-helpers, which breaks systemd

    Now, init-system-helpers is not supposed to do that: “This package contains helper tools that are necessary for switching between the various init systems that Debian contains (e.g. sysvinit, upstart, systemd). An example is deb-systemd-helper, a script that enables systemd unit files without depending on a running systemd.”

    See? That makes my head spin. I need to know what’s running on my PC and why. With systemd, the system is no longer that simple. Too many dependencies. Too many layers. Too much opacity. Why, on Earth, should gnome package have anything to do with init? It’s in a totally different layer of things. XFCE4 has no such dependencies.

  98. DrLoser says:

    And if we’re going to “talk about” systemd (please add the word to your spell-checker, Robert), it’s worth linking to Pid Eins on “systemd myths.”

    This stuff really isn’t all that hard, Robert. And it’s not even particularly invasive.

    Why not just embrace it as a step forwards? Note in particular “Myth 22;”

    Myth: systemd is not scriptable, because of its D-Bus use.

    You can easily call these [command-line] tools from shell scripts, they open up pretty much the entire API from the command line with easy-to-use commands.

    And of course “Myth 27:”

    Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world.

    Lazy reportage, Robert, simply lazy reportage.

  99. DrLoser says:

    I don’t suppose that it will make any difference to the various FOSS people here with strangely fixed opinions, but system has fundamentally nothing at all to do with Red Hat.

    It was developed by Poettering (Red Hat, true) and Sievers (Novell) and a few others, pretty much in their classical Googly “20% spare time.”

    Naturally this won’t change anybody’s opinions about it, but I like to inject as much honesty and historical accuracy into a discussion as I can.

    Oh, and also, Robert? I seriously doubt that your comment:

    My system doesn’t depend on GNOME but I have a few applications that have a few libraries that do

    … is even remotely relevant. I’m prepared to be proven wrong, of course, but I suspect that most if not all Gnome dependencies will be entirely unaffected by systemd. Give it a shot and let us know the results.

  100. olderman says:

    “We should be looking forwards not backwards”

    Actually it is you who sound more and more like someone who is looking firmly backwards. The world uses what it needs to make its software, and if that means that a developer pull in pre-made libraries that add bulk, then that is the way it’s going to be. If the application in question works, and runs well on the hardware, then that is all that counts to the software’s user.

    The original windows 3.1 based version 1.x of Finale of 25 years ago was tiny in comparison to the current version finale 2014. It also did orders of magnitude less then than it did now.

    That’s the way that it works in the real world Robert Pogson.

  101. Agent Smith says:

    The best days of GNU/Linux are long gone. Since corporate intrusion is killing it, it saddens me to see how the once mighty and free Debian was reduced to a RH’s delivery boy.

Leave a Reply