Re: [Bulk] RE: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, 4 Jan 2013 18:22:37 -0500 Mike Edenfield kut...@kutulu.org wrote: I have never personally run into any case where I had a single /+/usr and regretted it, but I *have* encountered situations where I could not get /usr mounted and ended up merging it with /. FWIW, YMMV, etc. And why was that, not udev? What is your point, others have avoided regretting it by having a seperate /usr. I can tell you that Pandu's analogy vis a vis Windows is a bit flawed. What Windows has done recently is (by default for clean installs) to split the boot loader and related bootstrap code into a separate partition from the actual operating system. Claiming that this is analogous to / and /usr is quite a stretch. It is much more accurate to make it analogous to / and /boot. The System Partition has no Windows files on it, just the equivalent to grub (and it's also used if you have BitLocker, to decrypt your boot partition). Which, to me, means it has absolutely nothing to do with the current discussion one way or the other :) He did define the fact that he mentioned it because he claimed the repair tools are stored in a small seperate partition like / or root is defined in the FHS which means he brought more to the discussion than you just have. In any case there are major benefits to having Windows with program files on a seperate partition and you shouldn't be stopped from having a seperate /usr without good reason and which there is not or if there is good reason in a hidden agenda/future plan it has not been brought to any discussion, note though that lies and mystery have. Broken for years indeed, more like tiny issues that few care about and so haven't been fixed by default. I re-assert that eudevs mentioning of moving potentially less stable/audited or even arbitrary code to later in the boot process is also welcomed by me.
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Should perl be in / or /usr? Now that is a good question, if only because Perl traditionally _loathes_ being in /bin, for its own philosophical reasons. Now, as a practical matter? WTF are the scripts written in Perl? Or in anything other than sh? If they're intended for emergency use, they've got some pretty fat dependencies, and should probably be launched from a full rescue environment instead. Or the log files should be copied to some place with more featureful tools available. Can perl be built statically and moved to / by the admin for this corner case? If not you should have all the tools to fix /usr in root and then if anything needs fixing via perl then you should be able to mount /usr or mount -a and have a fully working single user system to run perl from. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 9:10 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Should perl be in / or /usr? Now that is a good question, if only because Perl traditionally _loathes_ being in /bin, for its own philosophical reasons. Now, as a practical matter? WTF are the scripts written in Perl? Or in anything other than sh? If they're intended for emergency use, they've got some pretty fat dependencies, and should probably be launched from a full rescue environment instead. Or the log files should be copied to some place with more featureful tools available. Can perl be built statically and moved to / by the admin for this corner case? Certainly, but you still have modules to consider...but those can of course be bundled. If not you should have all the tools to fix /usr in root and then if anything needs fixing via perl then you should be able to mount /usr or mount -a and have a fully working single user system to run perl from. Indeed. The only reason I can imagine this to not be the case is if the mount for /usr fails. Most of the reasons imaginable also apply equally strongly to initramfs+root-on-special-mount and everything-in-/usr. -- :wq
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, or the fact that some udev programs tend to be located in /usr, or even just a solid detailed specification on the precise criteria for inclusion into /. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. If you have something more than FUD to back up your technical claims, go ahead. You're directly claiming that wherever systemd is used, the system will be less reliable and secure, and that Lennart isn't pointing out buggy behaviors in - what's the analogue for sendmail? oh yeah - SysVInit scripts. To carry the analogy, DJB's main point was that the size of the code was one of - if not the - most important factors in increasing code quality and security, and worked to make qmail and its configuration about as spartan as you can get. That's kind of the point of systemd unit files, trimming the boilerplate size to reduce gotchas like init scripts failing to detect whether a service is running or not, or if its dependencies have been started. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:22 PM, Mark David Dumlao madum...@gmail.comwrote: On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, If the basics are kept in /, with prod-additionals kept in /usr, then you should be able to boot to basics, and restore /usr. or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. I'd say that warrants bug reports against those programs. Also, isn't busybox under /? I think it has nano built-in. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. It's not that the spec is broken. It's that the spec doesn't lay out every single detail imaginable, and as a consequence, people assuming that the spec should be able to do their thinking for them assume the spec is broken when it's silent on a given query. -- :wq
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem. To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? For example, there's a virtualbox udev rule in /usr that doesn't mount other filesystems or stop udev from starting. However, given the right race conditions, udev will fail to start the requisite script because /usr isn't mounted. [2] fuse-based filesystems allow an administrator the crazy possibility of, for example, demanding that /home be an ssh connection. Should the ssh client belong in /? ftp? substitute any arbitrary client program. [3] a fuse-based filesystem depends on a local network service being started. For example, someone writes a crazy fuse mysql browser that also is coincidentally mounted at boot time. Should the mysqld service belong in /? ldap? substitute any arbitrary server program. [4] /root (which is why it's separated from /home) contains docs and custom utilities used by root user for recovery. Unfortunately, there's a lot of perl scripts there specifically for doing filesystem checks / reports. Should perl be in in /? substitute any scripting language. The point is not whether _you_ can come up with an answer for
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem. To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? Udev is a dispatcher. Actually, in substance, it's a piece of the kernel that resides in userland; it exists because it was decided back around the time of devfs that what devfs was doing is something that ought to be outside the kernel. In reality, it's effectively been a userland kernel-support process its entire life. What should probably happen is that udev should be fixed to defer hotplug events until a rules file is able to sucessfully handle it. And rules files should perform sanity checking and
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. Compare this with the
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. I understand that. I made that point myself; that the Gentoo dev moved udev into /usr to reduce the bug passing load on himself. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. That's one solution, but the cure is worse than the disease. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. The spec also doesn't say anything about /usr/lib vs /usr/lib32 vs /usr/lib64, yet decisions about those can also cause conflicts. I suppose you'd argue that that's also a bug. I already gave you a pretty succinct definition of what I thought the treatment of /usr should be. And you quoted FHS on the subject, which was eerily similar to what I described. Now, further down, you actually raise specific issues. Let's focus on those. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. So let's look at it deeply, since nobody else will. I'm game. This is the most detailed technical discussion of the problem anyone's cared to actually have, as far as I've been able to observe. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
It was in fact a weirdo corner case since day 1. Right, a weirdo corner case that is part of best practice and the default suggestion on debian stable used on many many servers and for good reason. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Dienstag, 18. Dezember 2012, 23:02:41 schrieb Marc Joliet: Am Tue, 18 Dec 2012 13:34:07 + schrieb Kevin Chadwick ma1l1i...@yahoo.co.uk: [...] Going back in time his claim of pulse audio being good for professional audio was also completely off the mark. Seperating Gnome and pulse can now cause pro audio users on binary distro's major headaches too. I pointed one fellow in the direction of a pro audio on gentoo tutorial rather than deal with some new problems a little after systemd hit Arch. Holy cow, did he really? Link, please! I thought pulseaudio was only ever advertised for desktop and some embedded use cases, and that Lennart is perfectly aware of the fundamental differences between JACK and PA and that they target a completely different range of applications [0]. I wouldn't *dream* of using anything other than JACK (with LADISH) for pro-audio work (well, more like home recording in my case, but close enough). I actually like pulseaudio for desktop use, though. When you start JACK it will kindly get out of the way, so the two aren't necessarily mutually exclusive (actually, you can set it up to automatically set up ports in JACK2 with the jackdbus-detect module, if you want that). After a few years of use I finally ended up requiring one of its more advanced features: moving streams between sound cards at runtime. [0] http://0pointer.de/blog/projects/when-pa-and-when-not.html remember this? a solution without a problem to solve, making a lot of people's lifes harder, dropped onto them by the godlike Lennart P.? http://lalists.stanford.edu/lad/2009/06/0218.html -- #163933
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 19, 2012 at 07:48:45PM +0100, Volker Armin Hemmann wrote remember this? a solution without a problem to solve, making a lot of people's lifes harder, dropped onto them by the godlike Lennart P.? http://lalists.stanford.edu/lad/2009/06/0218.html The thread was started by Lennart. In the first message http://lalists.stanford.edu/lad/2009/06/0191.html he says... If you don't do RT development or doing RT development only for embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy then it doesn't mean anything for you. And people wonder why Gentoo-ers dislike the guy. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Thankfully, I've never had to maintain systems whose disks were small and low performing enough that it actually mattered to separate / from /usr. So you don't understand it much at all. Actually many of lennarts pages such as his security.html are full of wildly incorrect claims and innaccurate assumptions and feature plagiarism leading me to believe he doesn't have much experience outside of coding. Going back in time his claim of pulse audio being good for professional audio was also completely off the mark. Seperating Gnome and pulse can now cause pro audio users on binary distro's major headaches too. I pointed one fellow in the direction of a pro audio on gentoo tutorial rather than deal with some new problems a little after systemd hit Arch. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Tue, 18 Dec 2012 13:34:07 + schrieb Kevin Chadwick ma1l1i...@yahoo.co.uk: [...] Going back in time his claim of pulse audio being good for professional audio was also completely off the mark. Seperating Gnome and pulse can now cause pro audio users on binary distro's major headaches too. I pointed one fellow in the direction of a pro audio on gentoo tutorial rather than deal with some new problems a little after systemd hit Arch. Holy cow, did he really? Link, please! I thought pulseaudio was only ever advertised for desktop and some embedded use cases, and that Lennart is perfectly aware of the fundamental differences between JACK and PA and that they target a completely different range of applications [0]. I wouldn't *dream* of using anything other than JACK (with LADISH) for pro-audio work (well, more like home recording in my case, but close enough). I actually like pulseaudio for desktop use, though. When you start JACK it will kindly get out of the way, so the two aren't necessarily mutually exclusive (actually, you can set it up to automatically set up ports in JACK2 with the jackdbus-detect module, if you want that). After a few years of use I finally ended up requiring one of its more advanced features: moving streams between sound cards at runtime. [0] http://0pointer.de/blog/projects/when-pa-and-when-not.html -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
