Quote:
|
Quote:
|
Quote:
|
I use the KISS method 18 months ago the bug was found.
The developer on the project closed the bug said it was the kernel problem. Well after looking at it the kernel developers over 18 months ago said nope your bug. Your program created this environment so it is your bug. The developer said nope take it to the forums. The real problem is same as you get with pulse audio. never really fixed. Is Systemd going to become a module in the kernel if I am wrong correct me. And a option to build for the Red Hat folks. So Greg A very much part of the kernel team had to fix Kay's stuff. It is not for the Kernel developer to work on that. It is up to the developers to test test test. Just think there is how many systems out there right now using a broken init. The Hacks are having fun. The Kernel is more than one man. Linus has a lot of power. With power comes responsibility. I my self do not see Him as anything more than another human on this earth. As Adam Time said if your going to play in Linus sand box than you will have to deal with it. Other wise the source it is free go make your own sand. |
Quote:
The fact remains that at the time of Linus's mail, the bug was already closed by Kay with a clear statement that 'That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.'.. That's a quote.. So, I'm fair to presume that he either knew this was already fixed but didn't bother to mention it (unlikely, judging by the response) or didn't know it's fixed but somehow decided it's not worth looking into.. At that point he suggested the use of 'loglevel=' since, of course, 'debug' is 'a convenience shortcut for the kernel AND the Base OS' even if it renders the entire debug process useless. They are not the first init system, and somehow others thought it would be nice not to interfere with the current workflow.. Kay and Lennart don't see it, they must be equally important at all cost.. And the fact is they are, and that is the whole damn problem.. You can switch it however you like and say the kernel had a problem, that systemd had a problem, that they we're right to use 'debug' but that is quite irrelevant.. The whole point is that someone thought that if his project can't be debuged normally or with some amount of easiness, neither should the kernel be.. And even now, if you enter debug then systemd still needs to fill half (just a guess, I admit) of the entries, just so you don't forget it's there, albeit, most of the times you won't be interested in that output.. Again, I ask, whose damn fault is that? P.S. Don't forget this isn't the first time this happened.. It's the most wide-spread because this time Linus answered them in public.. P.P.S. If I as a programmer, somehow create.. pff, let's say a PHP script that crashes the apache server.. Even if it's apaches problem, do you think it would be normal for me to leave my script as it is or fix it from my part too? |
Quote:
i broke it yesterday by playing with alsa is it an alsa-s flaw that i am an idiot ? to compensate for what i did would make alsa less efficient as it would have to check things a lot, and what i did is very much bad practice so should i report it ? |
Quote:
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
If you broke Alsa by misconfiguration or by using it in a way that it not is intended to be used then this is not a bug, but may be interesting to look at nonetheless from a security point of view. |
After all this I still can't understand why systemd even exists. Why would we need it?
|
For a good time in F-land, get into XFCE, then unplug a usb device. That generated over 2100 lines of kernel fault messages and stack dumps. Fortunately, I didn't tell abrt kerneloops how to log into bugzilla.
The hplip developers are covering all bases. The slackware hplip package contains both /usr/lib/systemd/system/hplip-printer@.service and /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi. Is that the way of the future where package developers have to include every possible system configuration? I was under the impression that the kernel was the kernal, providing the interface between user-land and the hardware; the OS was in the realm of the system administrator, which shell to install, which packages, to X or to console, etc. A computer is a tool, nothing more. Different people use different sets of tools in their work area. Chefs use pots, pans, ovens, salamanders, freezers, food, etc.; furniture makers use chisels, hammers, saws, routers, joiners etc.; fabricators use mills, press brakes, benders, welding equipment, lathes, band saws, etc. To build a system that includes all of that would be ludicrous. The customer chooses what they need, not the operating system packager. Linux is not Windoes. Why would I want a gui when a simple console session gets me into a cluster server where I can run weather simulations, stack thousands of layers of telescope images, calculate radio interferometry, calculate the moments and tensors of earthquakes, etc.? Tossing code at the screen in the hope that it turns into something useful is not the way of a computer scientist, who spends only 10% of a project coding, 90% planning, documenting, designing algorithms, etc. When I examine code with no overall documentation, descriptions of functions, sidebar comments for explaining subtleties and side effects, I gotta wonder why someone is shipping stuff that is incomplete? Folks who find flaws in Microsoft products have no access to the source code, yet they've been finding flaws and exploits for decades. A rare flaw in the source code of a Linux program gets reported to the chief software developer who either delegates or designs a patch that is pushed to public distribution the same day. PS. I traced my scanner problem to sane-backends. An undocumented change moved my scanner backend from avision to genesys. I apologize for criticizing the usual suspects. |
Hope Linus would remain strong in his attitude and advance kernel interests consistently. This is not just an episode of one systemd issue which was finally (after embarrassing publicity) fixed so everybody including kernel devs should shut up from now again. This is more than a minor technological detail. It's also a sociological and strategical situation many narrow minded nerds can hard to understand.
The linked G+ shows or rather complete the situation Linux is currently heading toward. RH as the most influential commercial subject tries to better monetize their investments and I don't intend to blame them here, but as a side effect it leads to hijacking of work of many volunteers and other non-by-RH paid developers into their own complete "Core/Base" OS and break compatibilities and conventions with system handling. One of the strategical bottlenecks between Linux and userland is the init system so the target is more than obvious. In addition as one of the greatest breadwinners has good breeding ground for enough apostles to push their interests without direct task assignments. Google managed so far with their Android just use Linux without attempts to take control over it. It may come time to re-think licensing of future Linux code to be better protected before hijacking of non-community sphere and what consequences it may lead including reaction of upset companies profiting from Linux business. |
What I don't understand is, in last 20 years no other application or developer has managed to spam the kernel by using the debug option along with their own userspace parameters?
Regards. |
Quote:
To those who keep claiming this was somehow a kernel bug, here's a car analogy that works pretty well: The "debug" flag is the Linux kernel equivalent of starting your car engine with the hood open. You can't actually drive your car when it's in this "mode" (and no sane person would ever try), but it's very useful for "debugging" the engine. Now, assume that the "hood is open" state can be detected over the CAN bus, and that the manufacturer of the stereo, sorry, "car entertainment system", decides to interpret this as a signal that the stereo should enter "debug mode" as well. In and by itself that's perfectly fine, and I'm sure the engine manufacturer would have no issues with it. Unfortunately, the "debug mode" for the stereo system turns out to involve continuously outputting a 50 Hz signal at maximum volume, which not only drowns out the engine noise (which the mechanic needs to hear), but also quickly drains the battery since the engine is idling, ultimately causing the engine to stop. I guess you could could blame the car manufacturer for insufficient soundproofing between the coupe and the engine compartment, or point out that a better regulator might have made it possible for the generator to power both the stereo and the ignition even with the engine idling and the stereo at full blast, but ... |
Quote:
Quote:
Quote:
In the meantime, can we not turn this into another "I don't like the design of systemd" thread? The topic here is not systemd itself, it is the behavior of a developer (which I by the way find unacceptable and which is a reason why I won't run systemd on any of my systems for other than experimental purposes). |
All times are GMT -5. The time now is 05:41 PM. |