Hi John, it seems you just answered to half of my mail, but anyway...
Am Dienstag, den 02.10.2012, 03:17 +0200 schrieb John Spencer: > On 10/01/2012 11:22 PM, Christoph Wickert wrote: > > Am Montag, den 01.10.2012, 04:24 +0200 schrieb John Spencer: > >> On 10/01/2012 03:14 AM, Bill Kenworthy wrote: > >>> Does LXDE have a position on systemd/udev etc? > >> > >> it's a PoS, designed by the hallucinating lennart 'mezcalero' poettering > >> who constantly tries to shove his shit down our throats. > > > > How so? Does anybody force you to use his software? > > that seems to be the plan: > > http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html > > "(Yes, udev on non-systemd systems is in our eyes a dead end, in case > you haven't noticed it yet. I am looking forward to the day when we can > drop that support entirely.)" > -- Poettering > > to use X, Y, and Z, I need udev, and as soon as udev is no longer usable > without systemd, I am forced to use systemd in order to use X, Y, and Z. Nobody said it won't be usable without systemd. The maintainer of udev (which is NOT Lennart!) just thinks that it does not make much sense to use it without. He and Lennart have no intentions to support it till the end of days, but of course somebody else can. Canonical for example will stick to upstart for political reasons and already announced they will support a standalone udev if necessary. If you use others software, you use it under their conditions. If they no longer want to support it in the way you want to use it, it's on you to do something about it. It's still Free Software, if you don't like their decisions, you can always fork it. > this is how red hat operates: invent overengineered layer of bloat > nobody (i.e. less than 0.1% of users) needs, let dependencies creep into > other packages that they control (or let fanboys do the job), until > there's no way around said PoS anymore. > > heck, even if thousands of users *needed* a network-transparent audio > daemon, that doesn't justify it being installed in almost any distro > (without any means to configure it) by *default*, always-on, constantly > getting in your way, and compiled into hundreds of packages. Network-transparency is just one of many features of pulseaudio. I find simultaneous streams on a single channel way more important. This is something that *everybody* needs, because people want to be able to receive a notification while the system is playing music. Many projects have addressed this issue, but they were either desktop dependent (ESD, ARTS), cpu hungry (ARTS!) or required manual configuration (ALSA!). And except ALSA all of them were way more bloated and broken than pulseaudio has ever been. And none of them ever supported volume levels per application. These two are killer features, so it's no surprise that so many distributions have switched to pulseaudio. That is the very own purpose of distributions: Delivering a collection of software that works out of the box. If you don't like the way it works, you can still change it. Even on Fedora, the distribution that first adopted pulseaudio, you can still remove it, change a single configuration setting and you are done. > >> almost everything that's broken around the linux desktop is his invention. > > > > Such as? > > pulseaudio, dbus, *kit, you name it. Too bad only pulseaudio and rtkit was done by Lennart. And none of them is broken. > >> that's just FUD. there are and will be distros that dont bow down to the > >> red hat/freedesktop dictatorship. the more resist, the better. > > > > Your statement makes me wonder if you really understand FLOSS. It's not > > and has never been democracy, not every random individual has the same > > rights. Of course everyone can state his or her opinion - and that > > includes even you and your rant - but at the end of the day those who do > > the work set the pace and direction. If your code is good, people will > > adopt it. This has absolutely nothing to do with dictatorship, it's > > yes, in a perfect, well-informed world good code would win, or at least > bad ideas/code would not become popular. > in a non-perfect world, due to bigger influence and propaganda > machinery, you get dbus, pulseaudio & co shoved down your throat, if you > like it or not. Influence comes from merit. And I fail to see where there was any propaganda. Did Lennard hire a PR agency to advocate his software? You are right, dbus is a good example of a non-perfect world. People are aware of it's shortcomings, even Lennart, who uses it extensively, is. But until somebody comes up with a better message bus, it's the de-facto standard. And when we have something better, we switch to it - problem solved. At least until comes up with something better. This concept is called 'innovation' or 'progress'. > > meritocracy at it's best. > > meritocracy implies merit, and that can't be said about poettering code. So it is no merit that people can just discover printers and other services on the local network with avahi? It's no merit usb soundcards or bluetooth audio devices just work with pulseaudio? Of course you can do all of that with manual configuration if you want to, if you have too much free time and if you are willing to use ugly hacks (like using the bluetooth MAC of the *user's* mobile in a *global* configuration file under /etc) > "Every time I hear of yet another one of Poettering's fads, I can't help > but remember the Henry Spencer quote "Those who don't understand UNIX > are condemned to reinvent it, poorly.". Poettering is a near-perfect > exemplar of that." -- cas (http://lwn.net/Articles/468381/) > > > > >> the binary syslog is just stupid. > > > > That is the claim. Where is your reasoning? > > simple: it can't be processed by the standard UNIX tools. > > to access the logs from *your own* code, you either have to reverse > engineer the format, read thousands of lines of horribly complex, > inefficient and ugly GNU-formatted [sic] code, or wait for someone to > come up with library that is possible to use sanely. but you still have > to write a special program to parse it, instead of a shell one-liner. > > we should not strive to make existing systems more complicated, we > should strive to make them so simple that a single human, not working at > Red Hat, in a reasonable amount of time, 1) can understand how all the > pieces work together, 2) is able to build it from scratch. The fact that you cannot parse the logs easily is a valid point of criticism. But I am optimistic that over time tools and libraries to do that will emerge. The code is open, no reverse engineering required. And if you still don't like it, don't use it, simple as that. > > > >> there's nothing more flexible than a shell script started by pid 1 > >> (init), which can be as slim as ~20 lines of C code. > > > > sysv's init has around 3200 lines of code. Would you mind showing me an > > init implementation with 20 lines of code? > > here's a ~10 line version of init.c that Rich Felker (author of musl > libc), authored and shared: > > #define _XOPEN_SOURCE 700 > #include <signal.h> > #include <unistd.h> > > int main() { > sigset_t set; > int status; > > if (getpid() != 1) return 1; > > sigfillset(&set); > sigprocmask(SIG_BLOCK, &set, 0); > > if (fork()) for (;;) wait(&status); > > sigprocmask(SIG_UNBLOCK, &set, 0); > > setsid(); > setpgid(0, 0); > return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 }); > } > > > as you can see, this is totally robust - no dynamic memory, simple, > small (statically linked against musl libc: 5 KB), and flexible - you're > free to use whatever you want as /etc/rc, as long as it is executable... Come on, an init is not just starting whatever it finds in /etc/rc, it's about controlling a system, that needs starting *and* stopping, different runlevels and much more. sysv's init is about ~3200 lines (just the init, not to mention programs like service, shutdown), that is more than 3 times as much than systemd. Of course systemd comes with more binaries and libraries, but that's just the good old *NIX principle :"Make each program do one thing well." Kind regards, Christoph ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
