Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 3:27 AM, Peter Zijlstra wrote: > On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: >> Steven Rostedt writes: >> >> > Nice rant, I sympathize with you (just complaining about this on G+). >> >> Made my day. >> >> > I'm just waiting for Linus to get pissed enough to write his own init >> > routine. Maybe he'll call it "Boot Init Through Computer Hardware". >> >> The trouble is that most of the heavy-weight kernel developers don't >> seem to care at all about what goes on in userspace. > > Well, I know for a fact that quite a number do; but so far most people > who care have been able to steer clear of this trainwreck so we did. > > I'm about to switch all my machines to Gentoo (from Debian) because that > will indeed allow you to build a distro without much of this nonsense > in -- because as has been eloquently said; you simply don't need this > fucking shite to run a 'normal' machine. > > And the thing is; we're all very busy so we tend to take the 'easy' way > out for things like this; but wholesale switching all my machines is > indeed painful, and I'm not liking. Another solution here which is more similar to Debian than Gentoo, is Alpine (http://www.alpinelinux.org). Alpine is a distribution which takes a lot of design cues from Debian (although we do use OpenRC). The typical user experience when using the alpine package management tools is easy for Debian users to understand, being modeled on the apt package manager. Another interesting detail is that we have adopted musl libc recently, and are working on glibc binary compatibility where it matters - the non-free flash player is already working here, and nvidia/fglrx are interesting targets as well. We feel that our usage of musl libc allows for improved security of the entire distribution, as musl's simplified implementation of standard library features has a much lower attack surface, and indeed a common observation is that many applications behave more robustly on Alpine (using musl) than other distributions they are developing against. At present, there are no plans to adopt systemd there, and systemd would need to be radically different than it is now to even be considered as the init system. The main blockers for systemd on Alpine are believed to be permanent: - systemd intentionally uses non-standard extensions to glibc - systemd components cannot be safely split up to reduce installation footprint - systemd has too much attack surface on PID 1 (d-bus, etc.) - kdbus support could be reasonably implemented without systemd - alpine does not wish to be 'forced' into adopting systemd through applications using systemd-exclusive APIs It should also be mentioned that Alpine is lightweight by default. This has been a goal that Debian in many ways has strayed from over the years. An empty LXC container with an alpine install in it, but no deployed applications, only takes approximately 3 megabytes of disc. Debian takes many orders of magnitude more now. William -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 3:27 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Another solution here which is more similar to Debian than Gentoo, is Alpine (http://www.alpinelinux.org). Alpine is a distribution which takes a lot of design cues from Debian (although we do use OpenRC). The typical user experience when using the alpine package management tools is easy for Debian users to understand, being modeled on the apt package manager. Another interesting detail is that we have adopted musl libc recently, and are working on glibc binary compatibility where it matters - the non-free flash player is already working here, and nvidia/fglrx are interesting targets as well. We feel that our usage of musl libc allows for improved security of the entire distribution, as musl's simplified implementation of standard library features has a much lower attack surface, and indeed a common observation is that many applications behave more robustly on Alpine (using musl) than other distributions they are developing against. At present, there are no plans to adopt systemd there, and systemd would need to be radically different than it is now to even be considered as the init system. The main blockers for systemd on Alpine are believed to be permanent: - systemd intentionally uses non-standard extensions to glibc - systemd components cannot be safely split up to reduce installation footprint - systemd has too much attack surface on PID 1 (d-bus, etc.) - kdbus support could be reasonably implemented without systemd - alpine does not wish to be 'forced' into adopting systemd through applications using systemd-exclusive APIs It should also be mentioned that Alpine is lightweight by default. This has been a goal that Debian in many ways has strayed from over the years. An empty LXC container with an alpine install in it, but no deployed applications, only takes approximately 3 megabytes of disc. Debian takes many orders of magnitude more now. William -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian If the developers of ALSA made a nuclear reactor, it would have five different control panels for controlling the rods in the reactor core, and each would do something different and not what the documentation said. Actually, I lied about that. It wouldn't have any usable documentation. But, there would be a hidden feature that you could sound the overload alarm by pulling out the stapler in the control office. Useful feature, that. As an audio developer on Linux, I must say that developing with ALSA is absolute fucking hell. If there was a way where both APIs could natively be supported, more people would be happy with the current state of affairs in the kernel. The most fucked up thing that I can think of about the current state of affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's software mixing in kernel space. The applications never even know about it. It's not only until recently (2005-2006 or so) that ALSA came close to this, but there are still problems. Many cards need workarounds to make dmix work because of the way it works, and the way that ALSA buffers data around. For the non-technically inclined, ALSA only keeps two fragments for input/output data each. This is horribly unusable because most soundcard fragments are only 1KB, so applications have to adopt ringbuffers to pass data to ALSA. If you're doing video, this leads to possible timing issues unless you sit down and well design your abstraction layer for audio I/O. So people switch to things like JACK and PulseAudio because it's the only way they can get workable Audio I/O on ALSA. What's even worse for the ALSA API is that it's designed around lowlatency programming, but only a few drivers properly support it. Why do you need lowlatency access to play a beep or a ding or whatever? The simple answer is you don't. ALSA could and can be done correctly, but OSS4 is already here and provides an API which solves all of ALSA's current problems. So why waste time with that, when OSS4 is already here and more friendly to the developers of the software most Linux users use? If OSS4 and ALSA apis could run on the same base driver, then a lot more people will be happier, as there will be choice available in which API to use, e.g. OSS4 or the libasound self-abuse method. Hannu has ideas on how that could work. I suggest all of the kernel developers listen, and listen well, or this mess will never be fixed in a way that is truly usable. -nenolod - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian If the developers of ALSA made a nuclear reactor, it would have five different control panels for controlling the rods in the reactor core, and each would do something different and not what the documentation said. Actually, I lied about that. It wouldn't have any usable documentation. But, there would be a hidden feature that you could sound the overload alarm by pulling out the stapler in the control office. Useful feature, that. As an audio developer on Linux, I must say that developing with ALSA is absolute fucking hell. If there was a way where both APIs could natively be supported, more people would be happy with the current state of affairs in the kernel. The most fucked up thing that I can think of about the current state of affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's software mixing in kernel space. The applications never even know about it. It's not only until recently (2005-2006 or so) that ALSA came close to this, but there are still problems. Many cards need workarounds to make dmix work because of the way it works, and the way that ALSA buffers data around. For the non-technically inclined, ALSA only keeps two fragments for input/output data each. This is horribly unusable because most soundcard fragments are only 1KB, so applications have to adopt ringbuffers to pass data to ALSA. If you're doing video, this leads to possible timing issues unless you sit down and well design your abstraction layer for audio I/O. So people switch to things like JACK and PulseAudio because it's the only way they can get workable Audio I/O on ALSA. What's even worse for the ALSA API is that it's designed around lowlatency programming, but only a few drivers properly support it. Why do you need lowlatency access to play a beep or a ding or whatever? The simple answer is you don't. ALSA could and can be done correctly, but OSS4 is already here and provides an API which solves all of ALSA's current problems. So why waste time with that, when OSS4 is already here and more friendly to the developers of the software most Linux users use? If OSS4 and ALSA apis could run on the same base driver, then a lot more people will be happier, as there will be choice available in which API to use, e.g. OSS4 or the libasound self-abuse method. Hannu has ideas on how that could work. I suggest all of the kernel developers listen, and listen well, or this mess will never be fixed in a way that is truly usable. -nenolod - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
