From: Bill K. <bi...@ii...> - 2012-10-01 01:14:44
|
Does LXDE have a position on systemd/udev etc? I am thinking of the apsect where gnome will, and where its being talked about that any desktop will have no choice but to move to systemd exclusively to function at all. Currently gentoo is moving to stubs/scripts and work arounds to avoid replacing what is a more flexible init system. I moved from (what was for me a disaster) gnome 3 to LXDE and being on Gentoo, I am looking to avoid the systemd and udev direction being pushed. BillK |
From: John S. <mai...@ba...> - 2012-10-01 02:15:32
|
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. almost everything that's broken around the linux desktop is his invention. > > I am thinking of the apsect where gnome will, and where its being talked > about that any desktop will have no choice but to move to systemd > exclusively to function at all. Currently gentoo is moving to 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. > stubs/scripts and work arounds to avoid replacing what is a more > flexible init system. more flexible ? more complex and error prone. the binary syslog is just stupid. 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. > > I moved from (what was for me a disaster) gnome 3 to LXDE and being on > Gentoo, I am looking to avoid the systemd and udev direction being > pushed. if nothing else, you can stick to/fork versions of sw that dont depend on the bloated new freedesktop crap. as long as you're able to compile your entire system yourself, there's hope. |
From: Bill K. <bi...@ii...> - 2012-10-01 02:36:36
|
On Mon, 2012-10-01 at 04:24 +0200, John Spencer wrote: > 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. > almost everything that's broken around the linux desktop is his invention. > > > > > I am thinking of the apsect where gnome will, and where its being talked > > about that any desktop will have no choice but to move to systemd > > exclusively to function at all. Currently gentoo is moving to > > 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. I agree with the above ... I am trying to avoid going down that path. So my question is will LXDE follow the path of gnome etc? > > > stubs/scripts and work arounds to avoid replacing what is a more > > flexible init system. > > more flexible ? more complex and error prone. the binary syslog is just > stupid. > > 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. I think you misunderstood what I meant. The majority of gentoo does not seem to want systemd etc so the devs are currently doing minimal workarounds. I expect to have to move to mdev eventually unless upstream come to their senses. > > > > I moved from (what was for me a disaster) gnome 3 to LXDE and being on > > Gentoo, I am looking to avoid the systemd and udev direction being > > pushed. > > if nothing else, you can stick to/fork versions of sw that dont depend > on the bloated new freedesktop crap. > as long as you're able to compile your entire system yourself, there's hope. Theres hope, but only so many hours in a day, most of which cant be allocated to creating software or fixes so my systems run in order to earn bread with those other hours :) With LXDE I have a functional desktop, but will it stay that way without systemd integration. I dont want to get into the pro/mostly con systemd flame wars that have sprung up elsewhere, but looking for a simple statement that LXDE will not tie itself to that mess. BillK |
From: Christoph W. <chr...@gm...> - 2012-10-01 21:23:04
|
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? > almost everything that's broken around the linux desktop is his invention. Such as? > > I am thinking of the apsect where gnome will, and where its being talked > > about that any desktop will have no choice but to move to systemd > > exclusively to function at all. Currently gentoo is moving to > > 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 meritocracy at it's best. > > stubs/scripts and work arounds to avoid replacing what is a more > > flexible init system. > > more flexible ? more complex and error prone. sysv init has no error handling, you need to rely on the services handling errors correctly, but there is no central authority to make sure they really do. Say your service (apache, postfix, whatever) needs the network to be up, DNS to be available and a (remote) file system mounted before it can start. Have fun writing checks for all these conditions and executing them over and over during boot. Knock yourself out figuring out the right order and to change it when you add another service. Then tell me again what is more complex and error prone. BTW: I have already replaced lxsession with a systemd user session and it was trivial. Just 3 files of 9 lines each. > the binary syslog is just stupid. That is the claim. Where is your reasoning? > 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? Best regards, Christoph |
From: John S. <mai...@ba...> - 2012-10-02 01:08:29
|
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. 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. > >> almost everything that's broken around the linux desktop is his invention. > > Such as? pulseaudio, dbus, *kit, you name it. >> >> 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. > meritocracy at it's best. meritocracy implies merit, and that can't be said about poettering code. "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. > >> 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... |
From: Christoph W. <chr...@gm...> - 2012-10-02 19:02:39
|
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 |
From: Stephan S. <gma...@sp...> - 2012-10-02 19:35:15
|
On 12-10-02 03:02 PM, Christoph Wickert wrote: > > 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. > Assuming we're not on Lubuntu and needing to use Skype 4. Whatever the Ubuntu maintainers did to ALSA, removing pulseaudio the officially-recommended way introduces a 10 second latency into all Skype audio playback. (Without bothering any other app on the system) Thankfully, I found a link to the static build of Skype 2.2 beta that still worked since, when I filed a bug, I basically got dismissed with "Ubuntu's approach for removing PA is broken somehow". |
From: Andrej N. G. <an...@re...> - 2012-10-03 19:07:56
|
Hello! Stephan Sokolow has written on Tuesday, 2 October, at 15:34: >Thankfully, I found a link to the static build of Skype 2.2 beta that >still worked since, when I filed a bug, I basically got dismissed with >"Ubuntu's approach for removing PA is broken somehow". One friend of mine complained that sound on her system sometimes just vanishes - the movie was playing then no sound and mixer shows the sound is on and 100% but no sound at all. Unlogging doesn't help, only reboot. There was no way to reproduce it, it just happens. After I've removed the PA from her Ubuntu that problem disappeared forever. How I can report the bug to Ubuntu? Or it will be another bug report that will be never fixed? Not saying Lennart will never accept the bug from non-RH user. Do I have any other solution but purge PA from every system where some problem with sound appears? It happened on many already, unfortunately for PA. And I'm afraid systemd is much more problematic (and harder to resolve) than PA. And if systemd work for someone that doesn't mean it should be installed for everyone. WBR, Andriy. |
From: <me...@gm...> - 2012-10-03 20:11:21
|
On Wed, 3 Oct 2012 22:07:46 +0300 "Andrej N. Gritsenko" <an...@re...> wrote: > Hello! > > Stephan Sokolow has written on Tuesday, 2 October, at 15:34: > >Thankfully, I found a link to the static build of Skype 2.2 beta that > >still worked since, when I filed a bug, I basically got dismissed with > >"Ubuntu's approach for removing PA is broken somehow". > > One friend of mine complained that sound on her system sometimes just > vanishes - the movie was playing then no sound and mixer shows the sound > is on and 100% but no sound at all. Unlogging doesn't help, only reboot. > There was no way to reproduce it, it just happens. After I've removed the > PA from her Ubuntu that problem disappeared forever. How I can report the > bug to Ubuntu? Or it will be another bug report that will be never fixed? > Not saying Lennart will never accept the bug from non-RH user. Do I have > any other solution but purge PA from every system where some problem with > sound appears? It happened on many already, unfortunately for PA. And I'm > afraid systemd is much more problematic (and harder to resolve) than PA. > And if systemd work for someone that doesn't mean it should be installed > for everyone. > > WBR, Andriy. Hi, This is two very different topics. For PulseAudio, do report at the launchpad bugzilla, check that no other bug related has been reported, if some exist, just continue on the comment thread to add your testimonial, be sure you give detail on the sound card : brand and model involved. About systemd, I have looked at some docs a few weeks ago to understand why it it interesting to have it, and indeed it brings a bunch of additional features which are desirable. Trying to find the frame related to it now to provide the link here… http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/why.html good reading ! If you want to read faster look at the frame in the second link. Regards, Mélodie -- LinuxVillage http://www.linuxvillage.net |
From: Christoph W. <chr...@gm...> - 2012-10-05 17:36:49
|
Am Mittwoch, den 03.10.2012, 22:07 +0300 schrieb Andrej N. Gritsenko: > Hello! > > Stephan Sokolow has written on Tuesday, 2 October, at 15:34: > >Thankfully, I found a link to the static build of Skype 2.2 beta that > >still worked since, when I filed a bug, I basically got dismissed with > >"Ubuntu's approach for removing PA is broken somehow". > > One friend of mine complained that sound on her system sometimes just > vanishes - the movie was playing then no sound and mixer shows the sound > is on and 100% but no sound at all. Unlogging doesn't help, only reboot. > There was no way to reproduce it, it just happens. After I've removed the > PA from her Ubuntu that problem disappeared forever. How I can report the > bug to Ubuntu? Through http://bugs.launchpad.net/ > Or it will be another bug report that will be never fixed? That depends on the Ubuntu maintainers. They should work with upstream, track development closely and if they cannot do this, they should not ship it. The simple rule is: Don't ship software you cannot support! And this rule not only applies to PA but to every piece of software and especially to closed source like Sykpe. If you cannot fix the code, you cannot support it. > Not saying Lennart will never accept the bug from non-RH user. I'm afraid he will, unless you compiled latest git from source. If you don't know what people are using and what patches have been applied or not, it's hard or impossible to support it. > Do I have > any other solution but purge PA from every system where some problem with > sound appears? If you are going to remove every piece of software that doesn't work 100% there will not be much left I guess. > It happened on many already, unfortunately for PA. I have to admit that when PA came up, it was rough and did not work correctly for me either. But I haven't had problems with it for years now and whenever I had, it was mostly due to other applications that did not work correctly. Many programs did not implement ALSA correctly, e.g. they hardcoded "hw0:0" instead of using the "default" soundcard and all this stuff suddenly broke with PA. But PA was not the culprit, it just revealed the bugs. > And I'm > afraid systemd is much more problematic (and harder to resolve) than PA. What makes you think so? > And if systemd work for someone that doesn't mean it should be installed > for everyone. That is up to your distribution. They should make sure it works for everyone and if not, that it can be swapped with sysvinit. Even in Fedora, which implemented systemd first, I can go back to sysvinit. Kind regards, Christoph |
From: Andrej N. G. <an...@re...> - 2012-10-05 19:17:06
|
Hello! Christoph Wickert has written on Friday, 5 October, at 19:36: >Am Mittwoch, den 03.10.2012, 22:07 +0300 schrieb Andrej N. Gritsenko: >> Stephan Sokolow has written on Tuesday, 2 October, at 15:34: >> >Thankfully, I found a link to the static build of Skype 2.2 beta that >> >still worked since, when I filed a bug, I basically got dismissed with >> >"Ubuntu's approach for removing PA is broken somehow". >> One friend of mine complained that sound on her system sometimes just >> vanishes - the movie was playing then no sound and mixer shows the sound >> is on and 100% but no sound at all. Unlogging doesn't help, only reboot. >> There was no way to reproduce it, it just happens. After I've removed the >> PA from her Ubuntu that problem disappeared forever. How I can report the >> bug to Ubuntu? >Through http://bugs.launchpad.net/ And what kind of bugreport it will be then? "Sound vanishes after few minutes or hours. After reboot everything is fine again. Without the PA installed sound never vanishes." - That kind of report will be marked as invalid which require more data. And I never can give them any other data except for that. Unfortunately. There are some of bugreports that aren't fixed for years, you know. >> Or it will be another bug report that will be never fixed? >That depends on the Ubuntu maintainers. They should work with upstream, >track development closely and if they cannot do this, they should not >ship it. The simple rule is: Don't ship software you cannot support! If there is no known way how to reproduce it I'm afraid it will be never fixed. >> Do I have >> any other solution but purge PA from every system where some problem with >> sound appears? >If you are going to remove every piece of software that doesn't work >100% there will not be much left I guess. Not every piece of software can lead to not working something in the system. Other kinds of software even if is bugged, will work again when terminated and restarted. Not PA unfortunately - even logout doesn't help as it was reported to me by my friend. She isn't programmer or whatever so cannot do more detailed diagnostics. And I believe she shouldn't do either - she have to use software which just works, not "either works or doesn't when you have unlucky hour". >> It happened on many already, unfortunately for PA. >I have to admit that when PA came up, it was rough and did not work >correctly for me either. But I haven't had problems with it for years >now and whenever I had, it was mostly due to other applications that did >not work correctly. Many programs did not implement ALSA correctly, e.g. >they hardcoded "hw0:0" instead of using the "default" soundcard and all >this stuff suddenly broke with PA. But PA was not the culprit, it just >revealed the bugs. It may be so but everything else that I use works fine with ALSA and I have no extra time nor interest to debug PA a lot, as I have a lot of other work to do so I just choose what works already instead of what not always does. May be it's your hobby to test all kinds of software to find bugs but it's not mine hobby, I'm sorry. WBR, Andriy. |
From: <me...@gm...> - 2012-10-05 20:32:00
|
On Fri, 5 Oct 2012 22:16:56 +0300 "Andrej N. Gritsenko" <an...@re...> wrote: > Hello! > > Christoph Wickert has written on Friday, 5 October, at 19:36: > >Am Mittwoch, den 03.10.2012, 22:07 +0300 schrieb Andrej N. Gritsenko: > >> Stephan Sokolow has written on Tuesday, 2 October, at 15:34: > >> >Thankfully, I found a link to the static build of Skype 2.2 beta that > >> >still worked since, when I filed a bug, I basically got dismissed with > >> >"Ubuntu's approach for removing PA is broken somehow". > >> One friend of mine complained that sound on her system sometimes just > >> vanishes - the movie was playing then no sound and mixer shows the sound > >> is on and 100% but no sound at all. Unlogging doesn't help, only reboot. > >> There was no way to reproduce it, it just happens. After I've removed the > >> PA from her Ubuntu that problem disappeared forever. How I can report the > >> bug to Ubuntu? > > >Through http://bugs.launchpad.net/ > > And what kind of bugreport it will be then? "Sound vanishes after few > minutes or hours. After reboot everything is fine again. Without the PA > installed sound never vanishes." - That kind of report will be marked as > invalid which require more data. And I never can give them any other data > except for that. Unfortunately. There are some of bugreports that aren't > fixed for years, you know. > > >> Or it will be another bug report that will be never fixed? > >That depends on the Ubuntu maintainers. They should work with upstream, > >track development closely and if they cannot do this, they should not > >ship it. The simple rule is: Don't ship software you cannot support! > > If there is no known way how to reproduce it I'm afraid it will be > never fixed. > > >> Do I have > >> any other solution but purge PA from every system where some problem with > >> sound appears? > >If you are going to remove every piece of software that doesn't work > >100% there will not be much left I guess. > > Not every piece of software can lead to not working something in the > system. Other kinds of software even if is bugged, will work again when > terminated and restarted. Not PA unfortunately - even logout doesn't help > as it was reported to me by my friend. She isn't programmer or whatever > so cannot do more detailed diagnostics. And I believe she shouldn't do > either - she have to use software which just works, not "either works or > doesn't when you have unlucky hour". > > >> It happened on many already, unfortunately for PA. > >I have to admit that when PA came up, it was rough and did not work > >correctly for me either. But I haven't had problems with it for years > >now and whenever I had, it was mostly due to other applications that did > >not work correctly. Many programs did not implement ALSA correctly, e.g. > >they hardcoded "hw0:0" instead of using the "default" soundcard and all > >this stuff suddenly broke with PA. But PA was not the culprit, it just > >revealed the bugs. > > It may be so but everything else that I use works fine with ALSA and > I have no extra time nor interest to debug PA a lot, as I have a lot of > other work to do so I just choose what works already instead of what not > always does. May be it's your hobby to test all kinds of software to find > bugs but it's not mine hobby, I'm sorry. > > WBR, Andriy. Hi, I found the same with Pulse Audio, example recently installed Xubuntu 12.04 to someone's laptop. After all was installed setup and updated, I fixed the sound not working by removing Pulse Audio components. This was about any sound: music files, videos from the hard drive or from a DVD, and also videos on youtube. And I also find bug reports seem to not get lot of care... but I could mistake on this one. Regards, Mélodie -- LinuxVillage http://www.linuxvillage.net |
From: Andrej N. G. <an...@re...> - 2012-10-01 12:03:02
|
Hello! Bill Kenworthy has written on Monday, 1 October, at 9:14: >Does LXDE have a position on systemd/udev etc? >I am thinking of the apsect where gnome will, and where its being talked >about that any desktop will have no choice but to move to systemd >exclusively to function at all. Currently gentoo is moving to >stubs/scripts and work arounds to avoid replacing what is a more >flexible init system. >I moved from (what was for me a disaster) gnome 3 to LXDE and being on >Gentoo, I am looking to avoid the systemd and udev direction being >pushed. Correct me if I'm wrong but systemd is middle-ware, i.e. OS specific thing, and LXDE is user-space software. How those could be related? You should rather ask your distro about systemd or udev, LXDE has nothing to do with it. Cheers! Andriy. |
From: William K. <bi...@ii...> - 2012-10-01 12:42:34
|
On Mon, 2012-10-01 at 15:02 +0300, Andrej N. Gritsenko wrote: > Hello! > > Bill Kenworthy has written on Monday, 1 October, at 9:14: > >Does LXDE have a position on systemd/udev etc? > > >I am thinking of the apsect where gnome will, and where its being talked > >about that any desktop will have no choice but to move to systemd > >exclusively to function at all. Currently gentoo is moving to > >stubs/scripts and work arounds to avoid replacing what is a more > >flexible init system. > > >I moved from (what was for me a disaster) gnome 3 to LXDE and being on > >Gentoo, I am looking to avoid the systemd and udev direction being > >pushed. > > Correct me if I'm wrong but systemd is middle-ware, i.e. OS specific > thing, and LXDE is user-space software. How those could be related? You > should rather ask your distro about systemd or udev, LXDE has nothing to > do with it. > > Cheers! > Andriy. > Yes and no! The problem is they were middle (or rather, lower level replacements for initscripts, devfs etc. However, in the interests of marketing and integration (i.e., lockin) its looking like it will be a systemd+udev+pulseaudio+*kit desktop world eventually because the core software of the big distros are going that way, and dragging everyone else along as well, whether they want to or not. I expect the lightest desktops will be able to avoid it, but I am using LXDE without systemd now and would like to know if that will continue or should I jump ship now. Have a look at some of the long (very) threads about this on the gentoo and other lists ... BillK > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Martin B. / b. <br...@bs...> - 2012-10-01 19:06:15
|
On Mon, 1 Oct 2012, Bill Kenworthy wrote: > Does LXDE have a position on systemd/udev etc? No. And no plan in either direction. -- /brother http://martin.bagge.nu Bruce Schneier's social security number is a Sophie Germain prime number having a reciprocal generating an infinite stream of pseudorandom numbers. |
From: PCMan <pcm...@gm...> - 2012-10-02 04:44:05
|
On Mon, Oct 1, 2012 at 9:14 AM, Bill Kenworthy <bi...@ii...> wrote: > Does LXDE have a position on systemd/udev etc? > > I am thinking of the apsect where gnome will, and where its being talked > about that any desktop will have no choice but to move to systemd > exclusively to function at all. Currently gentoo is moving to > stubs/scripts and work arounds to avoid replacing what is a more > flexible init system. > > I moved from (what was for me a disaster) gnome 3 to LXDE and being on > Gentoo, I am looking to avoid the systemd and udev direction being > pushed. > > BillK This is a real issue, but the answer to the questions depends on the popularity and acceptance of the proposed solution among existing distros. I personally want to avoid unnecessary layers and complexity, but it's harder and harder to make things KISS. DBus is a good example. Now it's hard to find a system working completely without dbus and newer glib/gio has built-in dbus support. Whether you use it or not, it's built-into glib so even if you don't use it, it's still there. Gnome people constantly moves many of the so-called gnome technologies to glib, gio, and gtk+ and make them part of these base libraries. Since we're using the library, we get the gnome technologies/dependencies automatically by this way. So some things are not determined by ourselves. One of the best example must be glib/gio. To make it function properly, you needs gvfs (replacement of gnome-vfs) and gsettings (replacement for gconf). Gvfs actually requires dbus and udisks2, which depends on polkit and udev. By using gio to manage devices, we get dependency on polkit + dbus + udisks2 + udev no matter we like them or not. But what if we don't use them? Our program won't work properly with other existing gtk+/glib programs and will has some additional permission problems. Instead of reinventing another system doing the same thing and cause incompatibility, it's apparently a better idea to use the solutions provided by glib/gio/gtk+. Free software is all about choice, but the current condition is all about having no choices. LXDE does not requires these dependency itself, but if the dependencies are acquired indirectly by gtk+/glib, there is no way to avoid them. That means, if in the future, glib/gio/gtk+ requires systemd to function properly, it's hard for us to avoid that. If they don't make this a hard dependency and keep gtk+/glib independent from systemd, we can avoid using it if we have better alternatives. If all major distros are using systemd, it's hard for us not to use it. Of course we need to support other non-Linux OSes when possible. If in the future only fedora is using systemd and it's not widely accepted, we should not have a hard dependency on it. Being a small project, we don't have many choices, though. Not using existing solutions means we have create and maintain alternatives ourselves, which is very labor-intensive and time-consuming. So the answer to the question is, that depends. |