To clarify a few things regarding that "debug" mess:
I will change systemd to not log to kmsg if journald is around when "debug" is specified. We will continue to log to kmsg during the early bootphase however als long as journald is not running yet. At that point there is simply no other option for that, because persistent storage is not available yet at that point and we need som way for people to get their logs out of the system, and early kmsg is the only way really, since it is hooked up with netconsole, serial tty, crashkernels, ... and all that other stuff.
I also believe that it is the right thing for the kernel to ratelimit whatever userspace sends it. For the same reason as we have to ratelimit all log streams in journald too, regardless where they come from. If you get a stream of logs from a 'differently priviliged' component then you need to rate limit it, that should be common sense. Of course I wish the ratelimiting applied is always configurable for the user, so that he can control how much and how soon things get dropped.
For me it is out of question though that systemd and other core os components should continue to parse the 'debug' kernel cmdline option, and increase their debug levels then. Generic options like that are supposed to be useful for real people, and there's a long history of options like that which influence both kernel and userspace (quiet, root=, ...). We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers. Moreover, there are individual kernel cmdline options for both the kernel itself and systemd to control just their log levels, and nothing else. so if you want finegrained control, you already have it, 'debug' is just the simple option that groups them all under a single oneshot option. It's the option an admin can specify which tells him why the system doesnt boot, regardless whether the kernel or systemd is at fault or any other part of the core os involved in boot. Thats simply userfriendly.
I do not appreciate all that talk from certain parts of the community that the systemd folks need to 'get tought a lesson'. That turns this into some kind of power game, which I am totally not interested in. Comparing us to Putin, or trying to bind merging of completely unrelated code to us doing whatever some kernel devs want (which is blackmail at worst, and childish at best, and childish we can be on our own enough, thanks) will just make us ignore you, and that's it. I prefer to deal with technical questions, and intimidation is not a technical question.
what the various news outlets wrote about all this is quite ridiculous. It's sad how badly these sites report, quite a shame.
And that is all.
I will change systemd to not log to kmsg if journald is around when "debug" is specified. We will continue to log to kmsg during the early bootphase however als long as journald is not running yet. At that point there is simply no other option for that, because persistent storage is not available yet at that point and we need som way for people to get their logs out of the system, and early kmsg is the only way really, since it is hooked up with netconsole, serial tty, crashkernels, ... and all that other stuff.
I also believe that it is the right thing for the kernel to ratelimit whatever userspace sends it. For the same reason as we have to ratelimit all log streams in journald too, regardless where they come from. If you get a stream of logs from a 'differently priviliged' component then you need to rate limit it, that should be common sense. Of course I wish the ratelimiting applied is always configurable for the user, so that he can control how much and how soon things get dropped.
For me it is out of question though that systemd and other core os components should continue to parse the 'debug' kernel cmdline option, and increase their debug levels then. Generic options like that are supposed to be useful for real people, and there's a long history of options like that which influence both kernel and userspace (quiet, root=, ...). We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers. Moreover, there are individual kernel cmdline options for both the kernel itself and systemd to control just their log levels, and nothing else. so if you want finegrained control, you already have it, 'debug' is just the simple option that groups them all under a single oneshot option. It's the option an admin can specify which tells him why the system doesnt boot, regardless whether the kernel or systemd is at fault or any other part of the core os involved in boot. Thats simply userfriendly.
I do not appreciate all that talk from certain parts of the community that the systemd folks need to 'get tought a lesson'. That turns this into some kind of power game, which I am totally not interested in. Comparing us to Putin, or trying to bind merging of completely unrelated code to us doing whatever some kernel devs want (which is blackmail at worst, and childish at best, and childish we can be on our own enough, thanks) will just make us ignore you, and that's it. I prefer to deal with technical questions, and intimidation is not a technical question.
what the various news outlets wrote about all this is quite ridiculous. It's sad how badly these sites report, quite a shame.
And that is all.
View 59 previous comments
Watching kernel developers vs. systemd developers is like celebrity deathmatch, not very smart but quite entertaining. :)Apr 6, 2014
After the success of Git, Linus Torvalds should start his own init system project. Something in the line of "system initialization done right".Apr 6, 2014
I don't know how valid my comments are, and I'm pretty sure i've misssed some serious fundimentals of this 'arguement'/'misunderstanding' -- But I'm going to add my 2 pence anyway
Where I work, if Project B, relies on functionality from Project A, and Project B builds some new stuff that 'confuses' Project A, that is forces Project A into a work around, I got a kick Project B's ass! We don't care that it's works/is easier/is cool/awesome/can blame someone else ... it's quite simply against 'good etiquette' because now, Project B is pushing 'technical debt' onto Project A -- and Project A is relied on by Project B - Z.
In a nut shell, if the Kernel says 'NO' then screw you Project B, don't cause extra pain -- submit a patch to Project A, or request assistance via 'back channels' not in the public space - In my eyes, the kernel will 'always' take precedence, simply because more systems rely on it. Having said all that - I'm not a developer/coder for anything distro related, so it's very possible, i've completely misunderstood this issue - but in my world, if your app breaks my infrastructure, your app gets ripped out by it's hair, until it behaves properly, i don't see why this is a problem here :)Apr 6, 2014
Nobody is forcing anybody to run systemd. Granted, on most distros you probably won't be given a choice about the matter either way, but nobody said you had to run that distro. Other distros are likely to give you a choice, and certainly Gentoo will be one of them. However, I doubt eudev will ever become mainstream. It will probably be a while before systemd is entertained as the recommended default, but at this point you can set up a Gentoo install using systemd with very little effort (just a matter of picking the right kernel options, setting a USE flag, and pointing the boot line at it). Hard dependencies on OpenRC are being removed, and there will probably be a profile that drops it and sysvinit entirely in the fairly near future and stage3s which eliminate the need to set up anything to use systemd. Most likely both will exist in parallel for a while then.
The biggest issue I have with systemd is that the interfaces/etc are all unstable making it hard for anybody to keep up. But, sooner or later the project will mature (I can't see RedHat sustaining that rate of change once it ships in RHEL). They really have done a lot to advance the state of the art and the whole socket-level dependency management concept was a paradigm shift. That is what makes some of the attitude issues frustrating. There is a lot to be said for getting kdbus into the kernel - imagine being able to control what processes are allowed to talk to other processes via SELinux roles, or better still to allow them to send some types of messages but not others! In some ways it might do for userspace APIs what capabilities are doing for the system call interface.
Nobody is going to force anybody to use any of this stuff. However, I think that just mocking the folks doing the work is foolish. I think Linus is right to call them out on attitude (and to be honest more than a few have called him out on his own demeanor). However, you don't really see him knocking the basic design of systemd, and there is a reason that just about everybody is starting to move in that direction. Sure, if you're just running one desktop plugged into a LAN whose hardware rarely changes you can get away without most of this stuff, but then again setting IRQ/DMAs with jumpers on ISA cards wasn't all that hard in such a situation either.Apr 6, 2014
+Oleg Vinichenko Ironic. That thread pretty much sums up everything what +Linus Torvalds has been screaming about.Apr 6, 2014
time to clean up this thread by deleting all of the stupid responses, and just closing it for comments, you all suck.Apr 6, 2014
