Re: [arch-general] systemd, running scripts after suspend/hibernate
Am Tue, 2 Oct 2012 12:12:24 +0200 schrieb Tom Gundersen t...@jklm.no: The way I read it is that the sort of problems you would typically workaround with suspend hooks are best solved somewhere else, probably in the kernel driver. That's so typical for those Poetterix fanboys and developers. Firstly ALSA was blamed for the PulseAudio insufficiencies and bugs. ALSA was blamed for PulseAudio not working with a lot of professional audio and sound cards even if ALSA supported them perfectly by default out-of-the-box since years. Now the Linux kernel is blamed for the systemd insufficiencies and bugs. That's really funny. *rofl* I take my popcorn. Heiko
Re: [arch-general] systemd, running scripts after suspend/hibernate
Am Tue, 2 Oct 2012 13:28:40 +0200 schrieb Heiko Baums lis...@baums-on-web.de: That's so typical for those Poetterix fanboys and developers. Firstly ALSA was blamed for the PulseAudio insufficiencies and bugs. ALSA was blamed for PulseAudio not working with a lot of professional audio and sound cards even if ALSA supported them perfectly by default out-of-the-box since years. Now the Linux kernel is blamed for the systemd insufficiencies and bugs. That's really funny. *rofl* I take my popcorn. And btw. ... So much about the very effective banning. Yes, I was indeed banned, and like Allan told me, he wanted to ban me forever, because I sent him a few comments on his banning. *rofl* That's really censorship, arrogance and ignorance. Just ban everyone who has a different opinion, because of his own experiences. If you really want to improve Arch Linux have a look at runit if you don't want to keep sysvinit. That looks a lot easier, cleaner and clearer than systemd from what I've read in its documentation. But, hey, Arch Linux is KISS, so why using simple and easy solutions if we could have complicated crap like systemd? Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 29 Sep 2012 18:54:04 -0300 schrieb Martín Cigorraga m...@archlinux.us: On Wed, Sep 26, 2012 at 7:39 AM, Heiko Baums li...@baums-on-web.de wrote: Heiko Most of the time is not what you say but rather how you say it - your tone. The Frenchs have a saying for that: The tone makes to the song or in its original: C'est le ton qui fait la chanson. Or in other words: What goes around, comes around. Or: As the question, so the answer. In German we say: Wie man in den Wald hineinruft, so schallt es heraus. Now think about it again and/or re-read the whole discussion, particularly the e-mails I've responded to. And, yes, I'm very direct and I say directly what I'm thinking. And if something goes way too far, I sometimes can get a bit more, say, stronger. Some people can deal with it and like it, some people not. I could tell you which people aren't able to deal with it, but then I would be called a troll again by these people. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Wed, 26 Sep 2012 10:28:20 +0200 schrieb Thomas Bächler tho...@archlinux.org: This is not about opinions at all. No, this is about opinions. Well, not only about opinions, also or rather about personal experience. Everything useful that is to say about this topic has been said. All that can be added are flames. You restart a discussion that will lead nowhere, and you know that. That is trolling, and trolling will not be tolerated any longer. And this is not trolling. This (my initial comment) just had to be said to open the systemd fanboys' eyes and to show them that their so super superior evolution is apparently not so superior and not such an evolution, and that upstream (Lennart) is probably not the best developer. And all my answers have been just corrections of the worst bullshit and totally false allegations. That's not trolling, too. And, yes, those systemd fanboys are the ones who make the most noise, and who are totally blinded. The trolling comes only from the systemd fanboys like Denis A. Altoe Falqueto, who really said nothing not even systemd related, who just flamed and write hate mails about people who don't like systemd and who criticize systemd. This is trolling and flaming. See also Denis' blog to which he sent a link in his last e-mail. And read particularly the comments, especially the one written by njanja (even if the tone is not the nicest) and Denis' reply to it. It speaks volumes, especially about Denis' attitude which is the attitude of most of those systemd fanboys. So if you want to ban someone then ban the real trolls who really always stir the flame up. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Tue, 25 Sep 2012 15:35:47 +0200 schrieb Øyvind Heggstad mrelen...@har-ikkje.net: Don't worry, you are not at fault in any way here, the systemd hateboy(z)/fudspreader(s) are. Wrong. The systemd fanboys who want to force this crap on everybody else are. The fudspreaders, as you call them, have already made their (bad) experiences with Poetterix, and know that this is crap. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Tue, 25 Sep 2012 09:28:40 -0300 schrieb Denis A. Altoé Falqueto denisfalqu...@gmail.com: How long will we have to endure such nonsense? Heiko, you hijacked a thread just to tell your opinion, which everyone already know from your previous posts. And, please, don't reply to me. I don't care. Thomas, wasn't he banned? I just thought he was, because he was threat and, yet, was pretty harsh on his later reply. I really don't understand that. Of course, the list managers have all the freedom to do as they please, but a threat that is not upheld is counterproductive. What about banning you, because of writing totally bullshit which has totally nothing to do with systemd, because of just telling your hate against systemd haters? One more who wants to have other people being banned just because he doesn't want to read other people's opinions. Hey, I don't like him and his opinion. So admins, ban him. Is it this what you want to say? Sorry, I really don't want to and won't continue this way, but I just had to answer to this. And, btw., no, I wasn't the one who got personal here. So don't blame me, blame Denis. People, particularly the systemd fanboys, should really start opening their eyes and taking off their rose-colored glasses. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 15:09:02 +0900 schrieb Zhengyu Xu xzy3...@gmail.com: After updating systemd to 191-1 in testing repo, I had following messages during booting and the process was stuck (crashed). [ 10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8 error 4 in libc-2.16.so[b752a000+1a4000] [ 10.539700] systemd[1]: Caught SEGV, core dump failed. Downgrade to 189-4 can solve this problem. I want to know if this is a personal problem or a general bug affecting others as well. Why am I not surprised? Yes, binary init system is so much better than a script based init system. And Poetterix is so damn good, so advanced, such an evolution and so much better than the common and over 40 years well tested sysvinit. Come on systemd fanboys, here you have the first example. There's more to come. I'll get my popcorn. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 18:18:49 +1000 schrieb Allan McRae al...@archlinux.org: Medical condition? I'm very fine. Thanks. Do I really need to say PulseAudio and Lennart Poettering? And do I really need to say made my own experiences (with PA and systemd, btw.). Because we have never had unbootable systems due to upgrades in [testing] before... And now you have them. Did you have even one totally unbootable system with sysvinit and initscripts? I doubt that. You say sysvinit but that relied on many compiled binaries (e.g. bash) And how many segfaults were brought to you by bash over all those years? And all the other binaries? Right, if one of them would really segfault (I've never seen this) the system would still be bootable, because then only this one binary segfaults, but not the whole initsystem. And if it's just one daemon, it can easily be deactivated like faulty parts of an initscript. But yes, it's so hard to debug those scripts. Now with systemd you can allegedly easily debug the systemd but you can't boot the system anymore to be able to debug systemd. *rofl* Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 10:15:16 +0200 schrieb fredbezies fredbez...@gmail.com: Don't you read the *important* word : testing ! Are you blind ? I read that. And what goes into [testing]? Yes! Bingo! Software version which are released by upstream as *stable*. So yes, upstream was supposed to have this tested before it went into Arch's [testing]. *rofl* And how do [testing] users update their system when initscripts will be removed? How do you fix a borked Windoze systemd? Right, with a Windoze free LiveCD. How do you fix a borked systemd system? Right, with a systemd free LiveCD. *lol* Are you stuck in 1690 or are we in the 2010's ? Even in the 2010's it can be better to stuck with 40 years old, well tested software instead of switching to new crap. You don't consider that I'm not against new software and new versions, but I'm against crap. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 10:52:10 +0200 schrieb fredbezies fredbez...@gmail.com: Just use another distribution. Do you think before you write? What exactly does this have to do with the distribution? Maybe I even would use another distribution if you tell me one Arch like binary distribution which doesn't and never will use systemd. Why walking if we can crawl ? Nonsense ! If there was a serious and well working alternative to sysvinit then it would be nonsense. But this is not the case with Poetterix. So you should do a brain surgery quickly. I would recommend it to you, since you get personal. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 18:52:01 +1000 schrieb Allan McRae al...@archlinux.org: Yes. A bash update in [testing] resulted in unbootable systems. I thought you were around then... maybe it just feels that long. I never used [testing] except for once when I started with Arch. Yes, I once had a serious issue why I switched to the stable repos very quickly. But I don't remember what issue this was and I don't remember that bash once resulted in an unbootable system. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 11:00:59 +0200 schrieb G. Schlisio g.schli...@gmx.de: please stop trolling on this list. this is very disturbing and already resultet in devs unsubscribing from this list. Sorry, but this is not trolling. This is just telling that I told it before, when almost everybody laughed at me and claimed how good and superior systemd is (an evolution *lol*). Now they have their first technical proof that it is not. And that's what they all always called for. Now they have it. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 11:11:12 +0200 schrieb fredbezies fredbez...@gmail.com: I was fed up by the crap of the original poster. So I said what need to be written, even if it was a little hard. I will remove myself from this list, because it is no more than crap because of systemd haters. Oh, other people's opinions and experiences are crap? And yes, the systemd haters have good reasons to hate it, because systemd is crap exactly like PulseAudio. And, yes, most of the systemd haters have tested both themselves. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 11:24:09 +0200 schrieb Sven-Hendrik Haase s...@lutzhaase.com: Doesn't seem to be possible with Heiko around. Since nobody seems happy with banning him, I'm also unsubscribing. So you want to have me banned because you don't like my opinions and experiences, and you don't like that I'm saying them? But you know that the GDR doesn't exist anymore since a few years? Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 11:28:58 +0200 schrieb G. Schlisio g.schli...@gmx.de: its ok to tell your opinion, thats not what i mean with trolling. impertinent exclamations and unconstructive i-always-told-you allegations do not help anyone to solve the problem. Oh, this can indeed help. And why shouldn't I tell it to those people? OTOHS its quite difficult ATM to get a constructive diskussion about arch init system, because it is already decides by our devs Decisions can be revoked if it turns out that they are wrong. I'm just telling that it looks like it gets proofed that systemd is not as good as those fanboys think. And why are there so many devs who already said that they don't use systemd because they don't like it? Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 15:06:28 +0200 schrieb Thomas Bächler tho...@archlinux.org: After the recent outbreaks, we have been discussing banning people from arch-general. At the time, the people we talked about had calmed down and everything went back to normal, so there was no point in going forward with it. However, your name just made top of the list. If I see you interrupting one more technical discussion with trolls and flames, you will be banned indefinitely without further notice. I will not see another one week flamewar on this list. Sorry, but the flamewar was not started by me but by all of the systemd fanboys who also infiltrated initscripts with those crappy systemd-tools which make the boot process slower, more error-prone and more instable, not only because of this systemd-cryptsetup and its new syntax. I always said, keep systemd totally optional and keep initscripts as they have been (without this systemd(-tools) crap), and you won't have any problems, no discussions and totally no flamewar. So it was your decision. So don't blame me. And, btw., I was really not the loudest one in this flamewar. And I always said that it sometimes can be worth thinking about what I say, even if I don't always give exact technical proof. And you also should know that the GDR doesn't exist anymore. Btw., I think you can imagine that I know how to get a new e-mail address. Without wanting to be offensive. But you really should think before threatening people. And I don't let myself being threatened. Sorry to have to get rude now. You of all people here should know that I'm usually not, and that one can talk to me. If you can't live with other people's opinions it's your problem, not mine. You are a grown man (at least you look like one), so you should know that this kind of post adds nothing to the discussion, but starts yet another flamewar. Start acting like a grown man and keep it to yourself, unless you have something to say that's worth saying. I had and have something to say and I did that. And I did that like a grown up. And that had not only but also technical reasons. If you think you should ignore the people who are totally concerned about Poetterix then you have to live with those consequences. And again, I was definitely not the one who made the most noise. But I and all the other people who criticized systemd have always been asked to give technical proof without giving technical proof for systemd's superiority. Now you really don't need to wonder that you get corresponding comments. I am completely against banning people, but at this point, it is either banning people or shutting down this list entirely. Then you should think at least twice about both. Both won't stop this discussion. And think this mailing list is not the only mailing list with such a long discussion about systemd. Why? Because it is crap, not only in Arch Linux. Even if you don't want to hear this, but PA and systemd are both crap. E.g. why does a logfile need to be in an unreadable binary form so that the logfile can only be read with an additional tool instead of just cat, less and grep? And why does everything need to be written into one single log file? And meanwhile I tested both, PA and systemd. And no, I don't file bug reports for crappy software I totally don't want to have anyway. But don't worry. As soon as I find a systemd free Arch Linux like alternative to Arch Linux I will switch to it. It's a pity, because Arch Linux was actually and could still be one of the best distros until you started switching to systemd. There's a reason why I'm using Arch Linux for about 5 years now. Heiko
Re: [arch-general] testing/systemd 191-1 failed to boot
Am Sat, 22 Sep 2012 15:06:28 +0200 schrieb Thomas Bächler tho...@archlinux.org: After the recent outbreaks, we have been discussing banning people from arch-general. At the time, the people we talked about had calmed down and everything went back to normal, so there was no point in going forward with it. However, your name just made top of the list. And, btw., instead of threatening and banning people with different opinions you rather should take their criticisms serious and take them as an incentive to improve Arch Linux and to make it better instead of worse. Heiko
Re: [arch-general] [arch-dev-public] fontconfig 2.10.1 will require user interaction
Am Thu, 6 Sep 2012 09:25:06 +0200 schrieb Andreas Radke andy...@archlinux.org: Am Wed, 5 Sep 2012 23:02:27 +0200 schrieb Rémy Oudompheng remyoudomph...@gmail.com: I would simply recommend removing the offending files using rm, we certainly know the list. Rémy. News draft: fontconfig 2.10.1 update - manual intervention required Fontconfig 2.10.1 update overwrites symlinks created by the former package version. These symlinks need to be removed before any further update: rm -f /etc/fonts/conf.d/20-unhint-small-vera.conf rm -f /etc/fonts/conf.d/29-replace-bitmap-fonts.conf rm -f /etc/fonts/conf.d/30-metric-aliases.conf rm -f /etc/fonts/conf.d/30-urw-aliases.conf rm -f /etc/fonts/conf.d/40-nonlatin.conf rm -f /etc/fonts/conf.d/45-latin.conf rm -f /etc/fonts/conf.d/49-sansserif.conf rm -f /etc/fonts/conf.d/50-user.conf rm -f /etc/fonts/conf.d/51-local.conf rm -f /etc/fonts/conf.d/60-latin.conf rm -f /etc/fonts/conf.d/65-fonts-persian.conf rm -f /etc/fonts/conf.d/65-nonlatin.conf rm -f /etc/fonts/conf.d/69-unifont.conf rm -f /etc/fonts/conf.d/80-delicious.conf rm -f /etc/fonts/conf.d/90-synthetic.conf pacman -Syu Main systemwide configuration should be done by symlinks (especially for autohinting, sub-pixel and lcdfilter): cd /etc/fonts/conf.d ln -s ../conf.avail/XX-foo.conf Wouldn't it be possible and make sense to remove those in the pre_install() or pre_upgrade() functions of the new packages? Heiko
Re: [arch-general] [arch-dev-public] fontconfig 2.10.1 will require user interaction
Am Thu, 6 Sep 2012 10:06:57 +0200 schrieb Andreas Radke andy...@archlinux.org: Pacman will detect the symlinks and break before the install scriptlet will be run. So this is not an option. Did you test it? I'm pretty sure it won't, since I tested this before in one of my AUR packages. Well, it was the removal of files in /lib due to the change from /lib to /usr/lib, but at least this has worked. Heiko
Re: [arch-general] cannot set locale (systemd)
Am Fri, 31 Aug 2012 12:10:01 -0300 schrieb Tomás Acauan Schertel tscher...@gmail.com: Both /etc/locale.conf and /etc/environment have this lines: LANG=pt_BR.UTF-8 LC_MESSAGES=C And my system (LXDM + XFCE) keeps en_US. No, it uses C, because Xfce unfortunately uses LC_MESSAGES, not LANG, to set its locale. To get pt_BR.UTF-8 in Xfce you need to remove LC_MESSAGES=C. If you need the messages in the terminal with the locale C for filing bug reports e.g., I'd suggest you to always prefix the command with LC_MESSAGES=C or set an alias for those commands. This issue has nothing to do with systemd, btw. Heiko
Re: [arch-general] cannot set locale (systemd)
Am Fri, 31 Aug 2012 13:14:24 -0300 schrieb Tomás Acauan Schertel tscher...@gmail.com: It was working right before last update. What changed? Nothing, unless you haven't changed your locale configuration or a package changed it, but then you would have had at least a *.pacnew file. Heiko
Re: [arch-general] systemd-pulseaudio-no sound card
Am Wed, 29 Aug 2012 19:32:54 +0200 schrieb Arno Gaboury arnaud.gabo...@gmail.com: On 29/08/12||13:20, Sébastien Leblanc wrote: My issue comes from permission. On console mod, $ aplay -l returns correctly the devices. When I am on X, it doesn't. Might be a PolicyKit issue. How do you start your X server / desktop manager? -- Sébastien Leblanc Maybe. I startx with : exec startxfce4 --with-ck-launch. Try only: exec startxfce4 When I start Xfce with exec ck-launch-session startxfce4 I get some issues with permissions, too. The action buttons don't work and I only can logout but not halt or reboot (both grayed out) when I use ck-launch-session. Without it I have absolutely no problems. I don't know if this could affect your issue, too. I'd recommend not using PA anyway. Heiko
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner d...@falconindy.com: I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage. As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;) Nobody is forcing systemd on anybody. Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody? Nobody has the intention to build a wall. Heiko
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Am Mon, 27 Aug 2012 11:30:46 +0200 schrieb Joakim Hernberg j...@alchemy.lu: I don't run gnome, but kde is just as bad in this case :( Try Xfce. ;-) Heiko
Re: [arch-general] SystemD poll
Am Fri, 17 Aug 2012 10:20:47 +0100 schrieb mike cloaked mike.cloa...@gmail.com: Isn't it interesting that the vote is currently 81% support for arch to switch to systemd (even with the misspelling in the poll), and only 19% against! Looks like at least from the perspective of this poll (even with only 237 votes in total which just shows the low level of interest in the poll given that the arch community must be many times that number of users) that the proposal that the devs made is overwhelmingly being supported by the community despite all the fuss that appeared in this mailing list! And what does this poll say? Exactly nothing. Do you know how many people have voted how many times? You only need one systemd fanboy with a few minutes spare time to get such a result. A poll would only make sense if it's ensured that everybody can vote exactly once. Heiko
Re: [arch-general] Arch-general is becoming a mess !
Am Thu, 16 Aug 2012 14:22:58 +0200 schrieb Thomas Bächler tho...@archlinux.org: So you're saying that instead of fixing the problem, every user should remove the offending posts. The problem here are a small handful of people who start flames and spread FUD. Banning a handful of people from the list is an easier solution IMO. I am generally against such measures, but it seems we will have no choice. And how do you decide whom to ban? Just because his opinion differs from yours? No personal offend. But there are or have been quite a lot of people here - I would even say, most of the people who are currently screaming the loudest - who are calling other people troll, while being trolls themselves, and shout for banning those people just because those people have different opinions and they can't bear other opinions. If you want to ban one of them you should ban both of them. Of course, this thread is very long. Of course, there's a lot of off-topic in this thread. Of course, there are a lot of pointless and silly e-mails in this thread. Nevertheless there are a lot of interesting and helpful information in this thread. And I think everybody has a right to say his opinion, even if he doesn't have a detailed, technical proof of his opinion. And if people can't bear other people's opinions they should think about themselves and not ban the others. Btw., there have been some other long threads on this mailing list as well as on other mailing lists. All of those threads eventually came to an end. And I'm pretty sure that this will be the case with this thread, too. Heiko
Re: [arch-general] Arch-general is becoming a mess !
Am Fri, 17 Aug 2012 01:56:57 +1000 schrieb Gaetan Bisson bis...@archlinux.org: Why would any of us care about your personal life? ... Your head must be such as mess if you can make sense of the above... ... Do either. And when you have five seconds please reflect on why none of us would read your blog... ... Our mistake is to read your messages. And you know what you have written? Have you really read my e-mail? I don't think so. I would say, everything you told me outright you should better tell yourself. Honestly I really can't understand what you are referring to, and what you want to tell me. Where have I written anything about my personal life? But never mind. I really don't care. Oh, sorry. I forgot. I shouldn't feed the trolls. Heiko
Re: [arch-general] What can be deleted, when not using systemd - was: polkit package upgrade patch
Am Sat, 11 Aug 2012 09:45:34 +0200 schrieb Jelle van der Waa je...@vdwaa.nl: Have you ever tried to report your problems with PA and your soundcard to upstream? How many times does it have to be said, that there are bug reports filed to upstream which have been ignored by upstream resp. which have been closed as fixed by first blaming ALSA for the PA problems, even if ALSA supports those cards perfectly out-of-the-box since years, then writing an obscure ALSA configuration which cripples those cards to simple stereo cards and now, after many discussions like this one, they suddenly say that PA is only meant for desktop purposes and not for professional purposes? How often does this have to be mentioned? Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 03:47:09 +0300 schrieb Thanasis Georgiou sakisd...@gmail.com: So you had a problem but when Tom wrote a patch you were unwilling to help test it? What part of I had no time to set up a VM. and I have only one stable system which needs to be stable and reliable. didn't you get? Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 03:02:03 +0200 schrieb Tom Gundersen t...@jklm.no: Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML. Is it really that hard to respect other people's opinions and wishes? Is it really that hard? Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space. But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once. And I just don't want this systemd stuff on my harddisk. But, hey, it's really hard to respect other people's opinions and wishes. I understand. If other people don't want to have anything to do with a certain software then this software has to be forced onto them because the maintainer is a fanboy of this software and can't respect other people's opinions due to his rose-colored glasses. I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version. You do force every Arch Linux user to install that systemd stuff. Why else do I have systemd-tools installed on my harddisk? Why else do I have all this systemd stuff in /usr/lib/systemd/system? Why else do I have even this directory /usr/lib/systemd on my harddisk? I tell you, because you force it on me. I never have installed this on my own. To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining. I don't know what you didn't get. I have already coded the cryptsetup part of initscripts which still works, which works better than this systemd-cryptsetup thing, and which you want to replace by some untrustworthy, and at least incomplete systemd stuff. And, yes, I totally disagree that your plan to make initscripts and systemd as close to each other as possible are good. And I'm not the only one as you should know meanwhile. This, too, is forcing systemd on everbody. Initscripts worked before and would still do this. If you are a systemd fanboy then provide and support systemd optional, but leave initscripts alone and revert it to what it was, before you made all those systemd changes. But, yes, I forgot again, other people's opinions and wishes are dull and all those people don't know anything and have no clue what they are talking about. All those people on the whole wide web. And you are the wisdom in person. Are you really sure that you know what you are talking about? Are you really sure that you know what you are doing with initscripts? And, btw., I would also be interested in some opinions of the other devs and TUs about your activities in forcing this systemd stuff on everybody. You are the only dev who is permanently talking about this and hyping systemd, and meanwhile I know that you are a systemd fanboy. What about the other devs? Have your plans with all their pros and cons and the users' opinions and wishes been discussed before with the other devs? Or are you doing this all on your own? Meanwhile I have the opinion that it's the latter one. And still no word about the other tools which work on top of sysvinit which have recently be mentioned by someone else here on this mailing list. Only this systemd fanboy jabbering. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 09:56:49 +0200 schrieb Jelle van der Waa je...@vdwaa.nl: Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. Then, why are there regularly so many, so long discussions on the web? And most of them are not started by me, and I don't even participate in a lot of them. And why are all those critical comments about PA, systemd, and Lennart Poettering marked green by so many people? Why is Lennart Poettering's software the only software about which there are so many discussions? Really because it's so damn good? I don't know what's going on behind the scenes of all those major distros. So I don't know how big Lennart's or someone else's influence is. But I think it's a mistake to switch to systemd. Well, offering it optionally, would be no problem. Speaking of which, I doubt that the RHEL and SUSE users care this much about the init system and the system internals as Arch Linux users do. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. ) I know that Poettering is not the only one behind systemd and PA, but it was his idea and he still is the maintainer. So it's still his software. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 22:21:01 +0200 schrieb Damjan gdam...@gmail.com: not to worry, the whole world of free software developers (including Arch) are here and have all the time to serve your wishes. Have you thought about that comment before sending it? Heiko
Re: [arch-general] note about beginners guide
Am Fri, 10 Aug 2012 14:52:09 +0200 schrieb Ralf Mardorf ralf.mard...@alice-dsl.net: Because cd + ls gives an overview about the structure? The output of $ cd /usr/share/zoneinfo/Europe $ ls is exactly the same as $ ls /usr/share/zoneinfo/Europe There's only one difference. The first one firstly changes the working directory from `pwd` to /usr/share/zoneinfo/Europe while the second one keeps `pwd` as the working directory. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Fri, 10 Aug 2012 23:38:15 +0200 schrieb Heiko Baums li...@baums-on-web.de: I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me. That said, nearly every comment on heise.de against PA, systemd and Lennart Poettering gets a lot of green, and heise is very well known IT publisher and has a lot of readers. Also such comments on pro-linux.de get regularly a lot of approval and positive feedback. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:57:46 +0200 schrieb Tom Gundersen t...@jklm.no: I prefer the reviews (good or bad) from someone who has actually read the book. You can usually assume that everybody who writes a review has actually read the book. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen t...@jklm.no: This is not the right mailinglist for this issue. And this certainly is not the right thread for it. This is the right mailing list for this issue, because downstream is also affected by this. And it is also downstream's decision whether to ship systemd or not. And you do it by forcing all that systemd stuff like systemd-tools and all those service files on every user if he wants to have systemd on his system or not. So this IS the right mailing list. You are free to reimplement all those tools and ship a competing package. The configuration formats are well-documented, so it should not be hard. Why would I? There are tools which are working. Systemd is still not working. For cryptsetup there was and currently still is a working code in initscripts. So principally no need to use some systemd-tools for this. And this code covered a lot more use cases than systemd-cryptsetup originally. And I know this code, because I have written at least most part of this code. The syntax could indeed a bit more clearer, but that could have been done without systemd-cryptsetup. What about all the already existing tools, someone else recently mentioned here on the list? Still no word about them. Still no discussion it they are sufficient or probably better than systemd. What are you talking about? No one forgot anything. This is what happened: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give), one week later I posted the patch upstream and (on the same day) Lennart replied: Applied. The functionality should now be part of systemd 188, which is in testing. What more could you possibly ask for? Just simple. I ask for first thinking about use cases and about reliability before writing such a tool and before trying to make it a de facto standard. I ask for thinking about professional users and their usage. And I ask for firstly learning about professional computer usage and about UNIX and the UNIX principle. And first of all I mean Lennart Poettering in this case. That's only one point. I, btw., also mentioned that you filed a bug report about this particular issue to upstream and that it is hopefully fixed. But nevertheless it shows that systemd was not complete, and that the systemd developer didn't think enough before releasing it, exactly like PulseAudio. I have the impression that you don't have a clue what you are talking about. And all those people who criticise PA, systemd and Lennart Poettering, too, have also no clue about what they are talking? All those people who mark those comments in several other forums totally green and who send comments in which they agree have also no clue? They are all stupid? And only you have the necessary knowledge? And only you are the wisdom in person? Is this what you want to say? I have the impression that you are one of those systemd fanboys, and just don't want to hear that systemd and PA have a lot of serious issues. And like I said in another thread, we're not talking about some fancy stuff like installing a GTK theme or the like. We're talking about serious and important, system relevant stuff. Btw., still no word about the reasons, why there are regularly so many and so long discussions about PA, systemd and Lennart Poettering, and not only here on this mailing list, but everywhere on the web. Still no word why those many, long discussions only appear about PA, systemd and Lennart Poettering and not about any other piece of software. You really should start thinking about this. And you should start soon. You really should take off your rose-colored glasses. Why don't you just delete the things you don't want? Why are those things, which I don't need and want, installed? Why am I forced to have this systemd stuff installed? And what, if I delete them manually? Shall I always delete them again and again after every system update? Sorry, that's not the way to go. Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know. Heiko
Re: [arch-general] OT: [arch-dev-public] polkit package upgrade patch
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen t...@jklm.no: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give) Just to mention, you've also written that this patch you've written should not be used or tested in stable, productive environments. I only have one PC which needs to run stably and reliably. I can't run into danger that my data gets accidentally corrupted. And I don't trust systemd this much, but I trust my initscripts code. And I hadn't had time to set up a VM. Heiko
Re: [arch-general] locale.conf
Am Wed, 01 Aug 2012 14:10:14 +0200 schrieb Thomas Bächler tho...@archlinux.org: I don't know why you set it, but I find LC_COLLATE=C extremely annoying. If you want an English speaking system, but live in Switzerland, I recommend this: LANG=fr_CH.UTF-8 LC_MESSAGES=en_US.UTF-8 You should be careful with LC_MESSAGES if you use desktop environments which don't have their own language setting like Xfce. They use LC_MESSAGES to set their language. Means if you're e.g. in Germany, use Xfce and have this locale.conf as it is recommended in man locale.conf: LANG=de_DE.UTF-8 LC_MESSAGES=C Then you get a fully English system. The same with: LANG=fr_CH.UTF-8 LC_MESSAGES=en_US.UTF-8 I would recommend to just set LANG=fr_CH.UTF-8 in locale.conf. If you really need an English output on the console, e.g. for filing bug reports, I would recommend to set LC_MESSAGES explicitly each time you really need it: LC_MESSAGES=C command-to-be-executed Heiko
Re: [arch-general] locale.conf
Am Wed, 01 Aug 2012 14:48:02 +0200 schrieb Thomas Bächler tho...@archlinux.org: You should be careful with LC_MESSAGES if you use desktop environments which don't have their own language setting like Xfce. ? I know that you're using KDE, if you haven't switched in the meantime. ;-) So, KDE uses its own language setting and doesn't care about the LANG and LC_* variables. Xfce doesn't have its own language setting and uses LC_MESSAGES - unfortunately not LANG - to set the language of the desktop. Maybe I should file a bug report or feature request to upstream. They use LC_MESSAGES to set their language. Of course, that's the point of LC_MESSAGES. What else would it do? Well, actually I would expect that the language is set by LANG and not by LC_MESSAGES. I would expect, and I guess this is what it's meant for, that just the output on stdout or stderr is affected by LC_MESSAGES. That is, that LC_MESSAGES only sets the console output of CLI programs, but not the language of the whole desktop environment like Xfce and all the GUI programs. What was the sense of LANG otherwise? Heiko
Re: [arch-general] incorrect sort order in thunar
Am Tue, 31 Jul 2012 19:13:24 -0400 schrieb Ray Kohler ataraxia...@gmail.com: You might check if ls sorts in this same odd fashion. It might be a locale setting - if LC_COLLATE is set to your actual locale, it text will be sorted as if were natural language (i.e., prose), rather than sorting in the usual technical manner. Thunar doesn't use LC_COLLATE, it has its own sorting algorithms, which had some bugs with Latin characters in the past. So this is an upstream issue which should be reported to the Thunar devs. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Wed, 25 Jul 2012 07:22:28 +0200 schrieb Nelson Marambio nelsonmaram...@gmx.de: that is / was right for Win 98 or Win ME. Having an exception error which was caused by damaged registry files always meant a reset to state short after the OS-installation, so all the drivers and programs had to be re-installed. But my XP-Installation ran more than five years stable though being stressed by many test-installations of applications. Does not mean that XP or Win 7 is going to make an admin feel happy - but yes, there was an improvement, at least for the users. But that was not such an improvement, maybe Windoze XP ran slightly longer than 3 months. But it's still not what I call stable. And it still is a PITA, particularly when it comes to administration. And it still gets unstable because of the (more and more growing) registry. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Wed, 25 Jul 2012 10:44:34 +0200 schrieb Nicolas Sebrecht nsebre...@piing.fr: I can find anything in systemd which could make think of the registry on Windows. I didn't say that. You are mixing up two things: - adding/removing services on boot; - configuring the services. The first - adding/removing services - changes with systemd. Yes, it is done using a dedicated command (which comes naturally with autocompletion, here with zsh at least). This is for services provided by the distribution. And this is against UNIX philosophy and makes it like something proprietary, at least it's anything else than comfortable. Why not just using a simple text file where I can list every service that I want to have started? systemd could easily read this file and do whatever it thinks to have been done internally. Btw., it's called daemon in Linux and UNIX. It's called service in Windoze. So one more step towards a second Windoze. The naming scheme in systemd is also not really the best. If people want a second Windoze they should stay with Windoze or help to improve ReactOS. If a service is not provided: - with SysVinit you have to write the whole script usually relying on whatever library the distribution provides (which tend to be error-prone); - with systemd, you just write a configuration file. Writing such a whole script is usually very easy and pretty little error-prone. A configuration file can also be pretty inconvenient. I haven't yet tested systemd, but from what I saw so far it doesn't look too intuitive or easy. But maybe I'm wrong in this case. Why do I have to tell systemd in all of those init scripts what service has to run before or after this service? In DAEMONS in rc.conf I just have a list of daemons I want to have started in one single line. And the order in which they have to be started is the order in which I list those daemons. Just plain and simple, and can easily be parsed. For the second, whether you use systemd or SysVinit, configuring a service is typically done by editing the configuration file dedicated to this service. In systemd, the file is declared like this EnvironmentFile=/etc/conf.d/nfs which is by itself much easier to hack (rather than reading in a shell script to find where and how such a file is used). You really don't need to read in a shell script to find where and how a config file is used. With SysVinit you have a rc script in /etc/rc.d and the corresponding config file in /etc/conf.d, both have the same name and the config files are usually very well documented, either by comments or by a man page. And what's hard in reading a very short init script with only a few lines? Btw., most lines are always the same (function declarations, case structures, etc.). The only important part is usually only one line. This is systemd internals. It's not expected from the user to play with symlinks. Just like in proprietary software. Once again: Why does it need such symlinks in some cryptic directories? The point is, I want to have full control over my system and not to rely on some software's internals. And I don't want to read source codes to know what an init system is doing. And full control includes knowing what file is saved where and doing what. No, I won't assume something that the software is going wrong. I assume the change raise fear, whether it is well-founded or not. Wrong, if there's such a long discussion, there is something going pretty wrong. If this software would be that well-founded, nobody had a problem with it, nobody would fear anything, and there would only be a very short discussion. Someone asks or mentions his concerns, somebody else clarifies it, and everything is good. This is not the case with Poetterix. And like I said before, I never - never ever - saw such a long discussion and so many concerns about a software like I saw for PulseAudio and systemd. So something must go pretty wrong in this case. This software can't be so well-founded. The people who are discussing about it, who have concerns against it and/or don't like systemd are not all stupid. OTOH for the systemd case, we are changing of paradigm for the boot process. I'm not aware of such a change in the boot process for years. All recent event-based init systems have raise fear. Which init systems? I only know SysVinit. And why wasn't there a change for years? Actually there was never a change. Because this init system is so bad? I would rather say because it's so well tested and approved, and because it's simple and just works and does what it is supposed to do. Maybe there are things that can be improved. Maybe there is code which has to be written or executed more than once with SysVinit. Well, this could be changed and improved. If this justifies a complete new init system is questionable I think. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Wed, 25 Jul 2012 07:51:15 +0200 (CEST) schrieb okra...@arcor.de: this is simply not true. Sorry, but this is simply true. I know Windoze XP and I had to use it long enough, far too long. First of all, starting with Windows XP the stability of Windows (yes, Windows, not Windoze) got much better and there are very few crashes which are mostly related to driver issues, IMO. Much better? Slightly better! And, yes, Windoze. Secondly, Windows doesn't need to be reinstalled every 3 months. Come on, most companies use Windows on their desktops and they don't need to reinstall them every 3 months. And their employees actually can work with their computers. I used Windoze long enough. And I had to reinstall it every 3 months, and I know a lot of people who also had to do it this often. Since Windoze XP it was maybe not every 3 months anymore, but still often enough. And i don't say this because i like Windows but because i'm realistic and not unfair. I don't live in a world where one system is perfect and the others are all completely crap. If you think that Windows is completely bad then you're not professional. I am realistic and professional, because I speak from experience, like I said before more than 25 years. Windoze is completely bad. Otherwise I wouldn't get fits of raving madness every time I have to work with this crap, which is fortunately not too often anymore. BTW: pacman.conf is written in an ini-style as well. Not really. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Wed, 25 Jul 2012 10:05:37 -0400 schrieb Stephen E. Baker baker.stephe...@gmail.com: This DAEMONS array is nice, one of the things I like about Arch, but it is specific to Arch not SysV. If you run Gentoo, or others you won't have something like that, you'll have a program that arranges symlinks, not entirely unlike systemd. Well, yes. I guess you're right, at least somehow. It's long ago that I switched from Gentoo to Arch. Nevertheless I'm not quite sure if systemd does the same as Gentoo does. At least Gentoo does this with shell scripts. But I still had no time to read the links about systemd, Tom posted recently. Why you would want to specify which services had to come before or after which other services is obvious when you consider that systemd boots services in parallel. Principally right again. But I have a problem with booting daemons in parallel, on Gentoo as well as on Arch. Made several problems. But I can't tell anymore which. So I prefer booting in serial, even if it's slower. If I recall correctly this was also one of Arch's advantages over Gentoo that I just could add the daemons to the DAEMONS array in rc.conf and choose the order myself. Odd, Arch uses SysV's init, but it certainly doesn't have a SysVinit init system. It's much closer to BSD, and a lot of the tools we use are custom. I know, and it's not necessarily bad. Others include OpenRC (used by Gentoo), Upstart (used by Ubuntu) and of course systemd (used by Fedora) I must admit that I didn't use OpenRC and Upstart, yet. I switch to Arch right before OpenRC was introduced in Gentoo. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 23:40:51 +1000 schrieb Gaetan Bisson bis...@archlinux.org: [2012-07-24 09:19:27 -0400] Baho Utot: He is stating his opinion and that should be valued Baseless opinions are not valuable, they are spam. Actually they are not baseless even if he didn't explain every single argument in detail. But I think e.g. regarding the UNIX philosophy he is totally right. And it actually shouldn't be necessary to explain in detail as the UNIX philosophy should be very well known anyway. Yes, I don't like those Windoze like ini files of systemd, too. Everything is and should stay a file, and every tool should do only one task but this should be done well. This is, btw., also the KISS philosophy. I really regularly wonder why people become offensive if other people say their opinions and if other people's opinions doesn't match their own opinions. Well, yes, some of Kevin's e-mails have been a bit pointless. But he is not really spamming. He just says his opinion. And it doesn't seem to be unqualified. Btw., in all those discussions about systemd as well as in all those discussions about PulseAudio, I always read more or less technical arguments from people who have objections against them or have tried them and have seen that they don't really work. From the people who like systemd and/or PulseAudio I only read arguments like it's faster, it's an evolution, it's new, everybody (distribution) uses it, it has this and that feature, which actually only makes sense and works in a very few cases or can easily be achieved in other ways. But I haven't, yet, read any technical argument for them, why it is technically better, why it doesn't break the UNIX philosophy, why it is reliable enough etc. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 16:07:50 +0200 schrieb Heiko Baums li...@baums-on-web.de: Btw., in all those discussions about systemd as well as in all those discussions about PulseAudio, I always read more or less technical arguments from people who have objections against them or have tried them and have seen that they don't really work. From the people who like systemd and/or PulseAudio I only read arguments like it's faster, it's an evolution, it's new, everybody (distribution) uses it, it has this and that feature, which actually only makes sense and works in a very few cases or can easily be achieved in other ways. But I haven't, yet, read any technical argument for them, why it is technically better, why it doesn't break the UNIX philosophy, why it is reliable enough etc. Well, now I must correct myself. I just read Tom's explanation about some technical details of systemd. The first one so far, which clarifies it a bit. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 10:08:26 -0500 schrieb Leonid Isaev lis...@umail.iu.edu: One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming. You really shouldn't do such assumptions. You couldn't have noticed it, you're just assuming. What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... And I assume that you never really administrated a Windoze PC. Then you would know that particularly the registry is a PITA. Over time various linux projects took a lot from windows: gconf/dconf (~registry), Gconf is also almost a PITA. At least it's a lot more inconvenient than simple text files. KDE4 indexing services (~superfetch/desktop indexing), This indexing is one thing which makes KDE4 so slow and unstable. KDE4 was the reason why I switched to Xfce. And, yes, I tried KDE4. But Gnome and KDE4 are just optional, systemd is meant as the new init system. That's a big difference. If this all was only about an optional piece of software I wouldn't say anything. I just wouldn't use it. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 11:31:22 -0500 schrieb Leonid Isaev lis...@umail.iu.edu: The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry. Bad programming is the most favorite answer, and totally nonsense. The registry just gets bigger and bigger and is totally cryptic. And the registry is one of the most frequent reasons for system crashes and instabilities. And it's the most frequent reason why Windoze regularly (usually every 3 months) needs to be reinstalled. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 16:25:52 +0200 schrieb Tom Gundersen t...@jklm.no: Talking about UNIX philosophy and Windoze like ini files is probably what gets some people going. It is not technical. In fact it is technical. Of course, at first glance config files for rc scripts and ini files are simple text files. But the structure, the way how they are handled (sourced or parsed), etc. is pretty different. And it's not only the ini thing. It's the whole possible move to making Linux a lot more Windoze like what I'm afraid of. The UNIX philosophy has worked for about 40 years and is totally tested and approved. Systemd is not. Of course, new things don't need to be bad and times are changing and sometimes there have to be made some adjustments, but it's a question how those new things are designed. And that's another point which I'm afraid of. I have tested PulseAudio and I know who has written and designed it. And I know that it totally doesn't work with a very few exceptions. And then I see that the same person starts writing something else at the same time, which intervenes even more into the system, even if the first software doesn't work correctly. So what do you think, how this looks like? Do you really think that this sounds trustworthy? Added to this I read that there are Windoze like ini files again in this second software of this person. Why do you think I have switched from Windoze to Linux? Of course, it was not the ini files in the first place. It was the whole terrible design and concept of Windoze incl. the registry. I still always get fits of raving madness if I have to work with Windoze, because I regularly need several hours for fixing something which I had fixed within minutes in Linux because of those simple and small config files and shell scripts (and because of the UNIX philosophy). And I know Windoze pretty well, too. Btw., I'm working with Computers since more than 25 years now and with Linux exclusively more than 10 years. And I started with an Apple IIc and a 8086 with PC-DOS 3.1, worked with several Windoze versions and I know Linux since 1993. So I guess I know what I'm talking about. In Linux I have/had some simple text files with which I can/could configure the whole system, while I had a terrible, cryptic registry on Windoze. In Linux I just can/could add a daemon to rc.conf to have it run. From what I read so far about systemd in all those discussions, in systemd I have to run a special command to have a daemon started at boot time (which I additionally have to remember), I have to write such an ini file instead of just writing or editing a simple and small config file or shell script, then systemd creates some symlinks of files into another directory whose name is also totally cryptic, at least way to long. This is a total mess, if this is really true, and it's absolutely a step towards a second Windoze. You have explained some of the advantages of systemd. And this sounds quite good, I admit. But I fear it's badly designed, at least everything around those advantages. And this all is technical. Yeah, we might agree that UNIX is great and Windows is bad. But in a technical argument, it is just annoying to point to tradition and philosophy rather than technical facts, regardless of what side of the argument you are on. It's not really annoying. Well, yes, if there was no substance behind it and if the tradition wasn't approved this well as it is in Linux and UNIX. See above. The problem in such long discussions is, that it's sometimes not possible or that people just don't have the time or the nerves to explain all the arguments in detail. But if there's such a long discussion and if there are so many complains about a software or a change, then you can assume that there's something going pretty wrong. Either this software or change hasn't been explained good enough to the people (and just saying RTFM is not enough in such cases) or the software is indeed not well enough designed, which should probably be fixed. And, btw., I never ever have read such long discussions and so many complains about a software like about the software of Lennart Poettering (PulseAudio and systemd). I was definitely not the only one who complained about it. And this must have a reason. And you can't tell me, that all those people have too little knowledge. If you claim that systemd does not follow the UNIX philosophy (I disagree, but whatever), and if you claim that anything not following the UNIX philosophy is bad (I disagree, but whatever), then you should be able to combine these two claims and point to a technical flaw or shortcomming in systemd without any reference to UNIX, or Windows, or KISS at all. See above. I think, I don't need to search for links which explain the UNIX philosophy. Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Mon, 23 Jul 2012 09:36:05 +0200 schrieb Nicolas Sebrecht nsebre...@piing.fr: Sounds like you (don't take this a personal critism, you're not alone) have poor administration practices. First, I do have administration practices. Editing multiple files instead of one in not a problem at all. In fact, it's the exactly opposite. The pain is the need to merge new changes while updating. Some tools (like pacdiff) can help with the job but it's very frustrating to have one configuration file and merge lot of changes in it. Especially when it comes to cosmetic/comments changes. Having one big configuration file means it's much easier to make mistakes in it and have strong problems because of that. Dedicated files to services/requirements make such problems more isolated. So, we're going a better robustness, better expectations compliance for new incoming users (and admins having more than one arch desktop to maintain). You are right when it comes to such long config files like for Apache or PHP. But we are talking about rc.conf. That is not a long configuration file. And I really don't see how there are chances to make mistakes. Btw., chances that those merging tools make mistakes are much bigger with such big config files like e.g. php.ini. And it takes a lot more time to check if they did their job correctly. Who is manually editing each configuration one after the other need lessons on administration tasks. I don't think so. Who manually edits config files just don't trust all those merging tools, because he has made bad experience with those tools or has other reasons and wants to keep full control over his config files. And believe me, checking if the merging tools made what they are expected to do is much more time consuming than manually editing those files. How many times do you get a .pacnew file? And how big are those files usually? I don't need to edit those files so many times. And if I have only one short file like /etc/rc.conf I have all my settings at a glance and only need to type nano /etc/rc.conf only once instead of several times nano /etc/vconsole.conf, nano /etc/hostname.conf or whatever. This is a lot more time consuming. Btw., in several cases a simple mv something.conf.pacnew something.conf is sufficient. But this all (I mean the whole discussion here) is complaining on a high level, a very high level. And Tom already said several times, that he will support both the single rc.conf and the separate config files. So I really don't understand this discussion. I just hope that those single files are not created by default or will be integrated into systemd, so that they are only installed if systemd is installed. If merging tools are not good enough, then let's improve them. But please all, don't make a shoot on current changes. Then improve the merging tools. I haven't complained about them, and I don't use them. You brought them in. What Tom is doing is exactly what most of ArchLinux users expect. That's why there is such a long discussion and why most people write that they are worried about it. I would rather say, it's what you expect. I have experience with both and principally don't have a problem with both ways. I just say that I prefer one single /etc/rc.conf, because it's clearer and easier to maintain. And the philosophy, KISS principle or whatever theory that you think is good in Archlinux is not beeing broken at all. One single /etc/rc.conf is a bit more KISS. But like I said that's complaining on a very high level. Heiko
Re: [arch-general] Grub2 config file needs to be tweaked with last official ISO
Am Sun, 22 Jul 2012 14:34:12 +0200 schrieb Nelson Marambio nelsonmaram...@gmx.de: Am 22.07.2012 13:50, schrieb Damjan: ps. any special reason that you have a separate /boot partition? /boot is still mentioned in the beginner's guide on https://wiki.archlinux.org/index.php/Beginners%27_Guide#Selecting_a_partitioning_scheme Maybe it should be removed there ? No, a separate /boot partition is still necessary if the whole harddisk is encrypted with dm-crypt/LUKS. I haven't heard yet that grub2 is able to unlock LUKS containers. And if not kept mounted, it can also make the system a bit more secure for really paranoid people. Btw., if I recall correctly somewhere in the grub2 docs or Wiki I read something that in some cases (BIOS/MBR or something like that) a separate /boot partition is necessary. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Sun, 22 Jul 2012 12:43:39 + schrieb Fons Adriaensen f...@linuxaudio.org: Fair enough, but for this sort of thing, who is 'upstream' ? In this case the super-ingenious Lennart Poettering, I guess. That said, Gentoo always had separate config files located in /etc/conf.d. So the idea of not having one single rc.conf is not this new. Nevertheless one single /etc/rc.conf makes the administration a bit more comfortable, because you have all settings at a glance and don't need to cat or edit several files. Regarding the threats of switching from Arch to Fedora: Fedora is Redhat. As far as I know Lennart Poettering is an employee of Redhat. So do you guys really think that Fedora is better in this regard and won't support systemd and those single config files? Heiko
Re: [arch-general] my Arch box randomly becomes irresponsible
Am Sun, 15 Jul 2012 22:06:01 -0400 schrieb Not To Miss not.to.m...@gmail.com: Dear Arch users, I have latest Arch installed on my desktop at work. In recent two weeks, the system randomly suspends at night (I call it randomly because it didn't happen every night. And it seems to happen after a random period idle time) when I am off. I can't wake it up in the next morning thru mouse or keyboard. I tried to disable suspension and hibernation by editing /usr/share/polkit-1/actions/org.freedesktop.upower.policy to change from allow_activeyes/allow_active to allow_activeno/allow_active But it doesn't work. While I call it suspend, I am not sure it suspend to RAM or hibernate to disk, because I find the CPU fan and power fan still spin normally. RAM light is also on. So it might be a video driver / setting related issue. For your information, I am using nvidia-302.17-2-x86_64 and have dual monitor set up with nvidia-utils-302.17-1-x86_64 This really bothers me a lot. Any help is appreciated. Thanks! Another question, probably not related to this. What about SMP? Do you have a multi core CPU? And do you also have instabilities, probably including kernel panics, if you run tasks which use both cores under heavy load like compiling the kernel from ABS or converting videos e.g. ripping a DVD with HandBrake or something like that, particularly when X is running at the same time? Heiko
Re: [arch-general] Upgraded kmod, but --ignored linux glibc, modules still in /lib - can I reboot safely?
Am Sun, 15 Jul 2012 00:35:58 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: Tom, All, I see the glibc /lib move is out of testing. I updated with --ignore linux,glibc and received an install warning from kmod stating: == Kernel modules are now only read from /usr/lib/modules... My modules are still shown in /lib. Does this mean I cannot reboot safely and expect it to work? Since I wanted to delay install of the new kernel and glibc, should I also have excluded kmod? If you ignore (don't update) linux then the modules are, of course, still in /lib. Maybe you should update your system following the News on the homepage. Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 10:17:45 +0300 schrieb Chris Sakalis chrissaka...@gmail.com: Hello, pulseaudio[1] has that functionality. You should check it out. On KDE , Kmix supports pulseaudio and I am pretty sure it support auto switching too. PulseAudio is more or less crap. It still doesn't support (semi-)professional audio cards. If you don't really need it's super-duper extra functions like gaplessly moving a stream from one sound card to another you better don't bother with PA. It rather makes things worse than better. I don't have a solution for the original question, because I don't use two sound cards at the same time, but there are other and better ways to disable the internal notebook speakers. Usually you can choose in every application which sound card to be used (sometimes in it's config files). I guess there are software mixers for every desktop environment which let you choose the sound card, which shall be used. Btw., isn't there a button on the notebook which can mute those speakers? Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 18:06:20 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: Yes, why not repeat that opinion in every thread where pulse is brought up? Its not like its repetitive. Yes, why not repeat that suggestion installing PulseAudio in every thread where somebody has a simple question about selecting an audio card? It's not like it's repetitive. And the most useless suggestion anyway. Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 18:22:45 +0800 schrieb ShichaoGao xgd...@gmail.com: True! Maybe many people got the bad impression of PA in previous versions. Wrong! Maybe many people got the bad impression of PA, because PA just still doesn't work with their audio cards, and because PA still causes more problems than it solves. There are only a very few SoundBlaster and AC'97 onboard sound cards which are supported by PA. Maybe PA works with those sound cards. But it doesn't work with other ones like the (semi-)professional audio cards. And most of PA's features - well, every useful feature - is available by ALSA and/or the audio applications themselves. Nevertheless installing PA just adds a new additional layer that can cause problems. So finding the reason for a bug is unnecessarily more complicated than without PA. Oh yes, I forgot, PA doesn't and never will have any bugs. Bugs are always only caused by ALSA, which works absolute flawlessly, even with those (semi-)professional audio cards. Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 13:00:56 +0100 schrieb Mauro Santos registo.maill...@gmail.com: Have you actually tried using the latest pulseaudio for a couple of weeks? For supported hardware it sure does something somewhat similar to what the OP wants. It sure seems you have some gripe with pulseaudio and/or pulseaudio's upstream and are on a personal crusade to bash it every time you can. Pulseaudio is not perfect but neither is alsa, if alsa only solves the problem then fine, if some user has better luck with pulseaudio+alsa so be it, the user will decide for itself if it sucks or not so just let it rest. I haven't tried using the latest PA for a couple of weeks, because I've got an M-Audio Audiophile 24/96. And this is one of those (semi-)professional audio cards which are not supported by PA. So, yes, I have made my experiences. It's not a personal crusade, and it's not bashing. It's just my personal experiences with PA, which totally doesn't work with my audio card. The problems that I have in those discussions, why I bash it (as you call it), are those: 1. PA may work with some certain sound cards (only consumer sound cards), but not with every sound and audio card. Still it always gets hyped as the ultimate sound server by the PA fanboys, which allegedly solves every problem and question. But unfortunately those fanboys are usually only those users who only know their own SoundBlaster or AC'97 onboard sound card and simply ignore the fact that there are some other, more professional audio cards. So they think if PA works for them, it has to work for everybody else, which is totally wrong. 2. Those PA fanboys ignore the fact, that PA indeed is an additional layer which can indeed cause additional issues, which make it harder to find the real reason for those issues. 3. Even the PA developers blame ALSA, which works perfectly with those more professional audio cards out-of-the-box, for the bugs in PA, even if it was clear that it is PA's fault. 4. The PA developers try to having made PA to a new de facto Linux standard - that's at least my impression -, even if it doesn't support every sound and audio card. From a de facto Linux standard it can be expected that it supports every hardware of that kind. Until this is not the case it just has to be called crap, if it's treated as a standard. 5. It's somehow related to 4. At least the GNOME developers and some distribution developers force the users to install PA as a dependency of GNOME or the whole distro. This probably isn't a problem for those PA fanboys with some consumer cards. But it is a very big problem for people who own a better sound or audio card, which doesn't work with PA. Those people not only want but even need a working sound output. 6. The PA fanboys always answer every sound related question by suggesting to install PA, regardless of the question and if the problem can be easily solved in other ways. 7. The PA fanboys seem to be persuaded that PA doesn't have and never will have any bugs. 8. PA is just overrated regarding its features. Maybe there are use cases for PA, maybe it can make some things a bit easier for some people. But it's in most cases not necessary as some PA fanboys are always claiming. And this is not bashing. Those are just facts. If PA would be treated as a normal and optional piece of software which can be installed or not, and if it would not be treated as a de facto Linux standard, and if the users would not be forced to install PA as a dependency, I would have absolutely no problem with PA. But as long as the situation is as I described above, you always will read such comments, if someone mentions PA. Either PA has to support every sound and audio card incl. the (semi-)professional audio cards as they are meant to be used (not crippled down to stereo cards) or PA has to be removed as a dependency from every desktop environment and distro. And the PA fanboys should consider if it's really necessary to install PA to solve a problem or to answer a question, or if there are easier ways (in user friendlyness and in KISS). And they should ask before, if PA would even make sense for the questioner. That's the point. Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 06:27:47 -0700 schrieb David Benfell benf...@parts-unknown.org: I think it *might* be possible to configure PulseAudio to work correctly. But in my experience, only LinuxMint has gotten this right out of the box. Unfortunately not. The configuration methods you find in the web, in several forums and mailing lists is just a workaround. Well, I wouldn't even call it workaround, because those professional audio cards are crippled down to simple stereo cards by those configurations. PA is not able to handle those audio cards as they are meant to be handled. And in the majority of these cases over the last few years, removing pulseaudio was the *only* thing I had to do to get sound working. I must admit that I'm not a GNOME user, I'm using Xfce, but I don't think that it is the right way to force the users to install PA as a dependency, even if PA can be uninstalled afterwards. On the other hand I read that it's not that easy to just uninstall PA. Heiko
Re: [arch-general] Muting internal speakers
Am Sat, 16 Jun 2012 00:05:11 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: That load of drivel below isn't bashing? You refer to fanboys and proceed to list a whole loss of statements not made by anyone in this thread. And then you insist that for pulse to be standard it must conform to your standards, which by the way something like cups also fails. Man, I can't believe my office photocopier can't print out stapled copies using cups, it shouldn't be called a standard until it can do that Not to mention the multiple times you assume that pulse is being forced on everyone just because it's a dependency of some software. May as well complain how X is being forced on everyone. You, sir, are a troll. That's funny. A troll is calling someone else, who just wrote facts, a troll. But you may keep comparing apples with oranges, if it makes you happy. If your photocopier can't print out staple copies using cups, this is totally different from not being able to hear any sound, because you only have a professional audio card and the sound server you are forced to use is not able to handle this audio card. And cups is not the only printing server. You see the difference? Heiko
Re: [arch-general] *** GMX Spamverdacht *** Re: Muting internal speakers
Am Fri, 15 Jun 2012 20:00:10 +0200 schrieb Nelson Marambio nelsonmaram...@gmx.de: Heiko, by installing GNOME, pulseaudio was installed as dependency I guess. That's one of the problems I have with PA, indeed. ;-) So please don't blame for starting with pulse, ok ? I don't blame you, but I blame the people who always at once suggest installing and using PA as the ultimate solution and answer for everything. And I blame the developers who force the users to installing PA as a dependency. If PA is working for you, you want to deal with PA and PA solves your problem, it's totally OK for me. ^^ After all I am confused if my installation uses ALSA or pulse now. I installed ALSA but the ALSAmixer shows me the volume level of pulse ??? I guess alsamixer only shows its own volume level. PA can set its own volume level which is, of course, relative to the ALSA level. Just turn up the volume to the highest level in PA and switch the volume level in alsamixer. I guess then you will have a clue. If you made the experience that pulse failed where ALSA succeeded there is nothing to say against it. But I have to deal with my consumer-card (it's really an HDA-chip by Intel) and thus I can't contribute something relevant. What I learned from this discussion 1) there are several sound-layer (OSS, ALSA, pulse, Jack (?)) 2) several layer can work together but also can result conflicts (nothing but logical) That's absolutely right. With one exception, OSS and ALSA are two different sound drivers on the same level. OSS is the older one, and I don't know if there's still an up-to-date version. ALSA has a OSS plugin for compatibility reasons. PulseAudio and Jack are two sound servers which are on the layer on top of ALSA or OSS. Heiko
Re: [arch-general] Muting internal speakers
Am Fri, 15 Jun 2012 16:08:40 -0700 schrieb David Benfell benf...@parts-unknown.org: I found it more annoying to uninstall pulseaudio than difficult. And it's fair to say I was already annoyed, so there has also been a cathartic element to it. Basically, using whatever package manager was appropriate to the distribution, I searched and removed pulse*, remembering that some packages that list pulseaudio as a dependency are in fact meta-packages that simply exist to bring in all associated packages and which can in fact be removed once you have a functioning installation (though you may find you want to mark other desired packages as manually selected). This sounds like PA isn't a dependency for GNOME any longer? This would mean that it's just a downstream bug, and PA should be handled as an optional dependency or not as a dependency at all by the distros. Heiko
Re: [arch-general] Muting internal speakers
Am Sat, 16 Jun 2012 08:23:54 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: Your facts are opinions and assumptions, mostly about putting words in the mythical pulse fanboy's mouth. Not to mention totally unhelpful to the discussion. I would say, your nonsense is unhelpful. And my facts are facts. Just read them again, and read all other discussions about questions or problems regarding PA, and you will see it. Those people, who always mention PA as their first and ultimate suggestions without thinking about it - if it really helps, if it really doesn't add additional problems, if it's really useful or necessary for the questioner -, who always say that PA can't have any bugs and can't cause any problems are just fanboys, because this all is just nonsense. If PA works for you, go for it. But if it works for you, doesn't mean, that PA is generally good. And its super-duper features are in most cases just unnecessary. You should really think about that, before you write such a stuff and call other people a troll. Your previous email indicated sounds could be heard, but only stereo sound. Afaik that's the case for most 5.1 and all 7.1 cards. How is that different from cups not supporting advanced options in my printer? Because pulse is the only existing sound server? It's different, because those professional audio cards are not stereo sound cards and are not meant for that. And with the users being forced to install and use PA, professional users just can't use these audio cards and can't do their job in the worst case. That's the difference. And, btw., this crippling down to a stereo sound card didn't work for me either if I recall correctly. Buy such an audio card and try it yourself, and you will see. Or ask all the other pro-audio users who need such audio cards. They all will tell you the same. In fact they already did. You can't and won't use pulse, fine, just don't use it. Jack or pure alsa still work. I don't use PA, and I don't use GNOME. But there are people who like GNOME and want to use it, but they can't use it, at least not always that easily, because PA is installed as a dependency. As David just mentioned, it seems to be possible meanwhile to uninstall PA. Nevertheless it's more than annoying having PA installed as a dependency, if PA is indeed not a real dependency for GNOME anymore. But when I tried PA it was not possible to use pure ALSA anymore. It was just crap. Just stop pretending that your arbitrary criteria for pulse is in any way an inalienable truth. Just to summarize, it seems your two main gripes are lack of support for semi pro cards and being forced to use it. The former is not likely to change, the latter is patently untrue seeing as how you are already not using it. Not untrue, it's true. I have such an audio card and I tested PA myself. I bet you don't have such an audio card, you don't know how they work and you haven't tested PA with them. So who should stop pretending anything? You or me? Heiko
Re: [arch-general] No sound (anymore)
Am Wed, 13 Jun 2012 23:09:09 +0300 schrieb angelinheavysyrup angelinvert...@hotmail.com: Is there anything I can do about this? Do you get any messages from ALSA during boot? Have you tried to reset your ALSA settings in alsamixer? Sometimes it happens that ALSA changes some channel names or the like, which can be easily fixed by running alsamixer, and check and save the settings again. Sometimes it's just a matter of time (usually a few days) until it gets fixed automatically with the next kernel and/or ALSA update. And as Ralf mentioned, if you use PulseAudio, have you tried to disable it? Heiko
Re: [arch-general] UEFI secure boot
Am Mon, 4 Jun 2012 22:44:31 +0200 schrieb Alexandre Ferrando alfer...@gmail.com: Arch doesn't seems to have the same kind of user than fedora, Arch if I don't remember it wrong, tends to be aimed for a competent user. Such a competent user can disable secure boot in x86 devices. (ARM devices doesn't seem a problem to Arch because we don't do ARM) Well, there is an ARM port of Arch Linux even if it's unofficial and unsupported. But as far as I know UEFI secure boot only needs to be activated and must not be deactivated, if ARM computers are shipped with Windoze, because this is only written in an M$ policy and not in a law. So principally it shouldn't be a problem for hardware manufacturers to assemble ARM computers without UEFI secure boot or with a UEFI secure boot which can be disabled, if they either preinstall Linux, Android or just ship it without Windoze resp. any OS. If there will be such hardware manufacturers is another question. But I'm not too pessimistic if I think of the Raspberry Pi e.g. Heiko
[arch-general] Mirrors not synchronized or a problem with the package database?
Is there a problem with the mirrors and their synchronization or with the package database? Since a while pacman tells me that my package databases for all repos are up-to-date. The latest version of linux in those databases is linux 3.3.6-1 while the latest version in [core] should be 3.3.7-1 according to the online package database at https://www.archlinux.org/packages and the ABS. This happens with every mirror in my mirrorlist. According to the mirror status at https://www.archlinux.org/mirrors/status/ they are all up-to-date and 100% complete. Of course, I already did a pacman -Syy, but this didn't help. Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 10:36:36 +0200 schrieb Maximilian Bräutigam m...@xbra.de: I discovered the same problem for German mirrors. Finally, I got my kernel 3.3.7 from It's not only the German mirrors, it's at least one French mirror, too. Server = http://mirrors.kernel.org/archlinux/$repo/os/$arch Server = http://mirror.archlinux.no/$repo/os/$arch seems to work, too. Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 11:02:29 +0200 schrieb Patrick Steinhardt steinhardt@googlemail.com: I've experienced the same problems. I was able to solve the problem by forcing database-updates with 'pacman -Syy'. Like I've written in my first e-mail this didn't help me. Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 14:45:22 +0300 schrieb Axilleas Pi axillea...@ymail.com: I had the same problem. I think the problem is with ftp mirrors. Try one http and see how it goes. At least, one I tried solved this problem. I forgot to mention this, I admit, but I only use http mirrors. Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 16:19:54 +0200 schrieb Bjoern Franke b...@nord-west.org: Do you mean mir.archlinux.fr? Yes. Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 12:26:02 +0200 schrieb Jakob Wadsager jakob.wadsa...@gmail.com: On 25 May 2012 10:09, Heiko Baums li...@baums-on-web.de wrote: Is there a problem with the mirrors and their synchronization or with the package database? Our uk2.net mirror has some problems. For this reason we have added a new tier 1 mirror (hosted by LeaseWeb). The mirrors that sync of uk2[1] will hopefully soon switch to LeaseWeb or any other up-to-date tier 1 mirror. In addition I can report that our gwdg.de mirror is also having filesystem issues. This will hopefully be resolved soon. [1] academica.fi arch.apt-get.eu archlinux.kz archlinux.ro arch.ping.uio.no bytemark.co.uk cinosure.com datacenter.by dkm.cz eenet.ee ftp.wa.co.za i3d.net lividpenguin.com neolabs.kz piotrkosoft.net (inactive) portlane.com (inactive) rnl.ist.utl.pt root.lu Unfortunately I use none of those mirrors. So uk2.net couldn't be the reason. Currently this is my mirrorlist: Server = http://mir.archlinux.fr/$repo/os/$arch Server = http://ftp.hosteurope.de/mirror/ftp.archlinux.org/$repo/os/$arch Server = http://archlinux.limun.org/$repo/os/$arch Server = http://ftp.spline.inf.fu-berlin.de/mirrors/archlinux/$repo/os/$arch Server = http://ftp5.gwdg.de/pub/linux/archlinux/$repo/os/$arch Server = http://ftp.halifax.rwth-aachen.de/archlinux/$repo/os/$arch Server = http://ftp.heanet.ie/mirrors/ftp.archlinux.org/$repo/os/$arch Server = http://ftp.tu-chemnitz.de/pub/linux/archlinux/$repo/os/$arch Server = http://mirror.archlinux.no/$repo/os/$arch Server = http://mirrors.kernel.org/archlinux/$repo/os/$arch If I recall correctly syncing failed at least from these mirrors, probably from some more: Server = http://mir.archlinux.fr/$repo/os/$arch Server = http://ftp.hosteurope.de/mirror/ftp.archlinux.org/$repo/os/$arch Server = http://ftp.halifax.rwth-aachen.de/archlinux/$repo/os/$arch This mirror worked: Server = http://mirror.archlinux.no/$repo/os/$arch Heiko
Re: [arch-general] Mirrors not synchronized or a problem with the package database?
Am Fri, 25 May 2012 21:41:08 +0200 schrieb Jakob Wadsager jakob.wadsa...@gmail.com: gwdg.de is upstream for some of the mirrors in your mirrorlist, and it had problems. I've been in contact with an admin earlier this day and it seems the problems have been resolved. The third in your mirrorlist (archlinux.limun.org) should work though. OK, good to know. Thanks. Heiko
Re: [arch-general] [arch-dev-public] cpufrequtils in [core]
Am Thu, 19 Apr 2012 13:23:40 +0200 schrieb Seblu se...@seblu.net: Currently i removed the last kernel version dot in linux-tools to avoid user confusion between stable kernel number and linux-tools version. I manually check if stable release embed fix for cpupower and perf to avoid user to update when not needed. As a side note, Kernel dev have choosen to ship with kernel source tree those tools. They had the choice of moving them into linux-util or others source tree. My suggestion was to avoid work to be done twice for us. It's done on other distro like debian. There's another problem with merging linux-tools into linux, that just came to my mind: customized kernels, which are based on linux from [core]. They would probably always need to build those tools even if it's not necessary to building them for every single customized kernel. Otherwise the package maintainers had a lot more work to remove all the building commands from the PKGBUILD if possible. Heiko
Re: [arch-general] [arch-dev-public] cpufrequtils in [core]
Am Thu, 19 Apr 2012 01:58:09 +0200 schrieb Tom Gundersen t...@jklm.no: I agree it would make sense to make it a split package with the kernel as the source is shipped with the kernel (afaiu). I missed that Seblu meant this. This would, indeed, make sense. Heiko
Re: [arch-general] A bug reported, no response in two weeks
Am Sat, 31 Mar 2012 14:24:43 +0200 schrieb Lukáš Jirkovský l.jirkov...@gmail.com: Oh, I forgot to mention that I've fixed both the mentioned bug and a related osmo bug a few hours ago. Thanks form me, too. Heiko
Re: [arch-general] A bug reported, no response in two weeks
Am Sat, 31 Mar 2012 01:23:07 +0200 schrieb Karol Blazewicz karol.blazew...@gmail.com: There's a nasty typo in libgringotts PKGBUILD http://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/libgringotts : 'pckage()' should be changed to 'package()', otherwise the package creates no files: https://bbs.archlinux.org/viewtopic.php?id=137648 http://www.archlinux.org/packages/community/i686/libgringotts/files/ I've reported the bug on 14 March 2012 https://bugs.archlinux.org/task/28920 and I've got no response so far. I guess aur-general would be the better mailing list for this thread, since libgringotts is in [community] and maintained by a TU. ;-) Nevertheless I can confirm this bug and pacman -Ql libgringotts indeed puts out nothing. Severity should be changed to high, btw. Heiko
Re: [arch-general] makepkg/PKGBUILD - handle same files provided by 2 non-dependent packages?
Am Sun, 25 Mar 2012 20:30:52 +0300
schrieb Jesse Juhani Jaara jesse.ja...@gmail.com:
su, 2012-03-25 kello 12:24 -0500, David C. Rankin kirjoitti:
Is there a go-by PKGBUILD that anyone can think of that does just
that?
In tdesdk's PKGBUILD do somthing like this
build () {
pach -Np -i patches
sed 's|clause|fix|' file.c
.configure --prefix
}
package_tdesdk ()
{
make install
rm $pkgdir/opt/trinity/share/services/svn*
}
package_tdeservices () {
cp $srcdir/tdeskd/src/service/generated/svn*.protocol \
$pkgdir/opt/trinity/share/services/
}
Thats kind of thng should do it :D
Also the assumption here is that the tdesdk and tdesvn pkgs provide
exactly same version of those .protocol files :D
AUR still doesn't support split packages, and split packages can't be
handled by the AUR wrappers. So this is really the worst ideas for AUR,
and should only be used for binary repos for now.
The better way is to create three single packages which depend on each
other.
Heiko
Re: [arch-general] makepkg/PKGBUILD - handle same files provided by 2 non-dependent packages?
Am Sun, 25 Mar 2012 22:08:43 +0200 schrieb Heiko Baums li...@baums-on-web.de: AUR still doesn't support split packages, and split packages can't be handled by the AUR wrappers. So this is really the worst ideas for AUR, and should only be used for binary repos for now. The better way is to create three single packages which depend on each other. Sorry, missed that it is meant for the trinity binary repo. Sorry for the noise. Heiko
Re: [arch-general] makepkg/PKGBUILD - handle same files provided by 2 non-dependent packages?
Am Sun, 25 Mar 2012 18:02:33 -0400
schrieb Baho Utot baho-u...@columbus.rr.com:
You stiil had/have a workable solution though
But you don't mean this solution?
pkgbase=splittest
pkgname=splittest
true pkgname=('splittest' 'splittest-foo')
This doesn't really work as already explained once on aur-general and
in the AUR comments for some of those split packages.
Heiko
Re: [arch-general] apparently bash export is broken for users
Am Mon, 12 Mar 2012 11:08:57 +0800 schrieb XeCycle xecy...@gmail.com: Not everyone uses bash as the default shell, you can also source ~/.profile in your bash_profile if you like. But the thread subject says bash export. Heiko
Re: [arch-general] apparently bash export is broken for users
Am Sun, 11 Mar 2012 21:18:43 +0800 schrieb XeCycle xecy...@gmail.com: Aren't you supposed to edit ~/.profile by hand? Isn't the correct file to set such environment variables locally ~/.bash_profile resp. ~/.bashrc? For global settings it's /etc/profile or better a new file in /etc/profile.d with the permissions 755. Heiko
Re: [arch-general] problem with pulseaudio when resuming from pm-suspend
Am Sat, 10 Mar 2012 10:35:07 +0200 schrieb Thanasis Georgiou sakisd...@gmail.com: No it's not. Sorry, but it is. The developers decided they want it a part of their desktop environment and now it's a dependency. And that's the problem and the reason, why those flame wars regularly pop up if PA is mentioned. Those dependencies are absolutely not necessary resp. if those DEs are designed to only work with PA then it's a misconception in those DEs. I do see that PA can give some additional features for some users, but those users who really need these features are the vast minority. Who really needs to move a sound gapless from an internal sound card to a USB sound card? Who really needs PA to set different volume levels for different programs? Every program I know has its own volume control. So PA may be seen as a little bit more comfortable, but it's not necessary. Just two examples. The mixing of the audio output of several programs is also not an argument for PA, because ALSA does this perfectly with its dmix by default for years. Well, meanwhile there seems to be an issue with some software not detecting an audio device anymore if another software is already playing sound. Stopping both programs and starting them in reverse order makes both programs play sound at the same time again. This seems to mostly happen with KDE/Qt-Software. But that's a different topic, and most likely a bug in either kdelibs, qt or ALSA, but installing PA is not a solution. So there may be a few users for whom PA makes sense, but not for the most people. You obviously have problems with PA, I saw your other thread, but this doesn't mean it's useless. Have you tried reporting your problems to PA and providing data about your cards so someone can fix them? Yes, there is a bug report about the ice1712 (envy24) audio cards in upstream's bug tracker for years. It was recently been fixed by giving a asound.conf for ALSA which cripples those (semi-)professional audio cards to simple stereo cards. I then reopened this bug, explained why this is not a solution, and never heard anything about this again. Instead the PA developers now regularly say that PA is not meant for professional users but only for consumers. This also proves that PA is not working correctly and most likely never will. And this also proves that PA should not be made as a dependency for DEs, because it is not meant for everybody. That's why I regularly say that there wouldn't be a problem if PA is only treated as a normal, and especially optional piece of software, and not as a dependency for anything. Keep in mind that most users use a stereo or maybe surround sound card like SoundBlaster or AC'97, I guess like you. I have no doubt that PA works with such sound cards. But even if probably most users use such cards those are only two cases. There are a lot of ice1712 (envy24) audio cards from the simplest ones like M-Audio Audiophile 24/96 up to the most professional ones like the RME Hammerfall which are totally not supported by PA. And if you knew those audio cards and how they are working you would agree that crippling them to stereo is really not a solution, not even a dirty workaround. I don't know how many other sound cards don't work with PA. ALSA, btw., supports every sound cards incl. those ice1712 cards out of the box, maybe in conjunction with envy24control from alsa-tools. So that the PA developer usually blame ALSA for being the reason for the PA issue is also nonsense. It's not an ALSA issue, it is a PA issue. Maybe contact Gnome/KDE and purpose to make pulseaudio optional or at least, easy to disable? This should indeed be done. I personally don't use GNOME or KDE so I can't file a bug report there. But I will do it for KDE or Qt as soon as I see that the current dmix issues are a KDE or Qt issue. That said, I really like pulseaudio. It fixed every single problem I had with flash playing audio without killing everything else and the application-specific control is nice. If you had issues with flash playing audio why didn't file a bug report to Adobe or probably ALSA? I never had any problems with the audio output of flash. Using PA is just a workaround but no fix for this issue. Application-specific volume control may be a nice gimmick but is definitely not necessary as I explained above. With that said Ralf is totally right with his explanations. Heiko
Re: [arch-general] problem with pulseaudio when resuming from pm-suspend
Am Fri, 09 Mar 2012 11:51:01 + schrieb John K Pate j.k.p...@sms.ed.ac.uk: does every single question about pulseaudio really need to be confronted with a holy war against pulseaudio? As long as it is such a crap, still doesn't work, doesn't support every sound and audio card, causes more problems than it solves - maybe with a few exceptions -, and is so extremely hyped and forced to being installed as a dependency by several distros and PA fanboys, I guess it will. If PA would be treated as a normal, and especially optional piece of software which can, but doesn't need to be installed, and/or if the PA devs will do their homework and fix all the issues which always lead to those discussions, I guess those discussions will end. But only then. Heiko
Re: [arch-general] Using Shift + F1 on XFCE
Am Tue, 28 Feb 2012 10:14:13 +0100 schrieb Vitor Garcia vitorlopesgar...@gmail.com: Any ideas of how to do that? I can't reproduce this, too. But maybe you could check if you have set a keyboard shortcut to Shift+F1 in Xfce here: Settings - Keyboard - Application Shortcuts Settings - Window Manager - Keyboard Switching from X to a virtual console is usually done by Ctrl+Alt+F1. So maybe you or an application has changed this setting somehow. Heiko
Re: [arch-general] An empty /etc/crontab file maybe needed bo be add in to package filesystem.
Am Sat, 18 Feb 2012 14:25:54 +0800 schrieb 郑文辉(Techlive Zheng) techlivezh...@gmail.com: Due to cronie doesn't contain an /etc/crontab anymore, there are losts of msgs of missing crontab as shown below in errors.log. /usr/sbin/crond[1236]: (root) CAN'T OPEN (/etc/crontab): No such file or directory Such an empty /etc/crontab would belong into the package cronie and not into the package filesystem. It's cronie specific since fcron, which I use, doesn't need and provide one. The corresponding, but also not necessary file for fcron would be /etc/fcrontab. And I'm not sure if such an empty /etc/crontab would affect fcron. If cronie doesn't provide an empty /etc/crontab and doesn't run without it, it is a bug in cronie. Heiko
Re: [arch-general] offtopic ml (WAS eons ago: Re: change in mount behaviour?)
Am Mon, 30 Jan 2012 16:17:48 +0100 schrieb Martti Kühne mysat...@gmail.com: On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote: ... s, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...) who's with me? +1, wondering why no one picked that up yet. This wouldn't change much. The original topic was Arch related. The discussion about PA etc. evolved from this. So such a discussion wouldn't be switched to another mailing list. Same for any other similar discussions. See my try to change the subject from mount to PA. The discussion about PA has mostly been continued under the original subject. And there's another disadvantage. This arch-offtopic list would most likely not read by so many people and probably not by the right people whatever that might mean. A new mailing-list arch-offtopic would only be used for discussions which are originally be totally offtopic. And probably not even then, if someone isn't aware that his topic is offtopic. So if such a discussion would indeed be moved to an arch-offtopic list this would mean people can directly shut their mouth. So almost no chance for changes. People who are not interested in a thread can either ignore this thread, just filter it out or move its e-mails to /dev/null with their e-mail clients. Heiko
Re: [arch-general] offtopic ml (WAS eons ago: Re: change in mount behaviour?)
Am Mon, 30 Jan 2012 12:14:01 -0600 schrieb C Anthony Risinger anth...@xtfx.me: not always, and i use a mobile 70%+ of the time. i don't want to create a new filter for every long-winded thread to nowhere. maybe i can create a label - trash, and flag multiple conversations ... maybe i can't. why should i? Because you don't want to see those e-mails. What do you think to how many mailing lists I am subscribed and in how many threads I'm not interested even on arch-general, aur-general etc. You know what I do with those threads? What anyone else would do. I just ignore them and delete those e-mails, because they may be important and interesting to other people, maybe to the devs, but not to me. Do I tell the people to shut up and not discuss their Nvidia problems because I have an ATI card and am not affected by Nvidia issues? For me discussions about Nvidia are not necessary, for Nvidia users they likely are. For you discussions about PA may be unnecessary, for pro-audio users they are important. Or what do you mean, why there came so much feedback from so many people incl. pro-audio users and why this thread got that long? If your mobile is not capable to handle such e-mail filters, just don't use your mobile for reading such mailing lists or buy a more capable one. ... you know what's way cooler? believing others are capable of respecting each other's time, and the reason others join a list in the first place (ie. the expected boundaries). Oh, you mean because I should respect your time I should shut up and suspend my judgement? You really mean I should let myself censored because of your time? What about respecting other people's opinion? If such a discussion is unimportant to you and you're not interested in it, just ignore it. I think such a discussions like this one about PA is important, even if it's on an Arch related mailing list. But the problem with PA e.g. resp. this ongoing dependency hell is a general one and Arch is part of the general Linux community. And probably such a discussion is read by other more important people and then brought to the right place, etc. And again, this discussion about PA has evolved from an Arch related topic. So should this discussion just be stopped, because it gets off-topic somehow and you are not interested in it? I guess you should think about that. Heiko
Re: [arch-general] Merge /bin to /usr/bin?
Am Mon, 30 Jan 2012 19:32:50 +0100 schrieb Tom Gundersen t...@jklm.no: I'm not at all a fan of the way Fedora is going to do the move btw... Maybe the way of going over a committee is the better way after all? ;-) I just say: FHS and the chaos and the imcompatibilities because every distro goes its own way. Maybe it is better to follow a standard and first rewrite this standard. Well, I didn't say anything. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen t...@jklm.no: Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues. This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio. Maybe I'm not the best to explain the concepts of those audio cards, but that doesn't mean that I don't know anything about them. When I bought this card it took me a while until I got to know what they are doing and how they work, so maybe I can't explain it in detail. But that doesn't mean that I'm missing anything. We just package their software, we don't decide their priorities or policies. But you and the developers of the other distributions are the people who decide if they just want to package what upstream thinks should become a standard. So if every distribution just install PA as a dependency then nothing will change and a very big regression regarding audio will happen, because PA will indeed become a standard, and no pro-audio user will be able to hear and work with sound anymore. If the distros refuse to package those bad software dependencies, then also upstream probably has to change their minds. So I think this has to be discussed with downstream, too. And I think this discussion has gone on for way too long... Think about it again. Think again why this discussion about PA always pops up on every occasion in almost every mailing list and forum. Rethink if pro-audio users really have no knowledge about the underlying concepts. I bet pro-audio users have a lot more knowledge than PA upstream and all the people who claim that pro-audio users are missing something. I'm sure that this discussion will always pop up until these issues regarding PA are fixed. That said, it will end if either PA will fully support those audio cards and show that they learned about (pro-)audio or if PA wouldn't be installed as a dependency anymore by upstream as well as by downstream of all distros and just be treated as a normal and optional piece of software which can but doesn't need to be installed and used. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 14:42:33 + schrieb Fons Adriaensen f...@linuxaudio.org: They *DO* know and understand the difference between consumer and 'pro' audio. I have another impression. I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'. I didn't say anything about pro-audio software, I've spoken about DEs like Gnome 3 and some distros which want to have PA installed as a dependency and probably don't work anymore without PA. If this is or at least will be the case then also the pro-audio software won't work anymore with those. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 18:35:07 +0100 schrieb Jelle van der Waa je...@vdwaa.nl: Indeed, this should be the thing the complainers _should_ be doing. Archlinux ships vanilla upstream, so you're really barking at the wrong tree here. Please consider asking either PA for help or ditch it. I don't think this is the totally wrong place, maybe not the very best, but not the worst. Because even if this mailing list is generally distribution specific and the Arch Linux devs try their best to keep PA optional, it's not quite unlikely that other people read this mailing list. Sometimes important changes come from downstream to upstream. Tom also mentioned that regarding the FHS. He told me - I'm not sure anymore if he did this on the list or in a private e-mail - that the new directory structures are first tested in the distros and then will be worked into the new FHS. So those new directory structures are first discussed in the distro specific mailing lists, too, like it has been done on this list with the discussion about /var/run and /run recently. So I think those discussions don't necessarily need to, but can be quite important. If nobody opens his mouth no matter where, nothing will change. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 11:03:13 -0400 schrieb Norbert Zeh n...@cs.dal.ca: Let me chime in here to add an important point to this discussion. The whole discussion so far sounds as if PA works great with non-pro cards and breaks only on pro cards. That's not the case: PA has problems even with what is probably the lowest end of chips: built-in audio chips on all my motherboards. And the behaviour I observed is exactly what Heiko and Ralf observed too: everything works great with ALSA and starts to act up when using PA. Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. That's not the point with pro-audio hardware. The problem with ice1712 chips is that those chips aren't stereo or surround sound chips. Those cards have instead separate lines for in- and output. They can of course be mixed as normal stereo, but they can mixed however you want. Those cards don't have a master volume control or an amplifier, they only have attenuators. So those cards can't be handled like those consumer sound cards, and they need a special mixer and patch bay. ALSA delivers one in the package alsa-tools called envy24control. PA just knows pure stereo and maybe surround sound. PA wants to have a master volume control. PA doesn't have a mixer and patch bay for those cards. And the PA developers blame ALSA for this and just think crippling down those cards to pure stereo cards with an ominous ALSA configuration. Of course, this is a very dirty workaround to get those cards somehow working with PA, but with this configuration you disable all the other functionality of those cards. That is the problem. Well, it's not a problem as long as PA stays just optional so that people who like the features of PA and just use a consumer sound card can use PA and the pro-audio users don't need to use it. So the problem is that PA is made more and more as a standard by several up- and downstreams. That is what worries me. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). Simultaneous audio streams from different applications are mixed together by ALSA's dmix which is activated by default since years. I haven't tested sound from VirtualBox, yet. Heiko
Re: [arch-general] change in mount behaviour?
Am Sun, 29 Jan 2012 21:55:28 + schrieb Fons Adriaensen f...@linuxaudio.org: Could be. My impression is based on talking with LP face to face. And yours ? My is based on a bug report, upstream's solution for closing this bug report - this weird ALSA configuration which cripples those cards to pure stereo cards - and their response to the reopening of this bug report. I fully agree that designing Gnome or KDE so they can't be installed easily without PA by a user who accepts the consequences of doing so (no desktop sounds) is a sign of *very crappy* engineering. OTOH, if you use one of those desktops you can just suspend PA, start Jack and your apps and go on. I don't use Gnome or KDE, I don't have PA installed so I can't talk from experience. But I know that people are doing this all the time. For example Joern Nettingsmeier, who is probably using the most complex and advanced pro audio setups ever done in Linux, apparently has no problem with this. OK, looks like there is a working workaround, but not a real solution. The solution would be a better engineering. Heiko
Re: [arch-general] change in mount behaviour?
Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger anth...@xtfx.me: well, i can't say i care much about the FHS either. IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. i also make extensive use of avahi/libnss-mdns/libnss-myhost ... s, they seem to work OK ;-) Do I really need to repeat it? PulseAudio and ice1712? No, PulseAudio doesn't work fantastic, it's pure crap as long as it can't handle every sound and audio card, which ALSA, btw., does perfectly out-of-the-box. And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudios fault. And why should I trust other software by Lennart Poettering if he isn't able to get this one software working perfectly. And, yes, he tried to declare this PulseAudio crap as a standard. Heiko
Re: [arch-general] change in mount behaviour?
Am Sat, 28 Jan 2012 11:24:47 +0100 schrieb Tom Gundersen t...@jklm.no: Maybe I (or others) were unclear in our explanations, but at least you should have had a look at the software you are claiming to be buggy (you would quickly see that there is no problem). Again, PulseAudio which Lennart Poettering likes to have as a standard completely doesn't work with (semi-)professional audio cards with an ice1712 chip. Yes, I had a look at PulseAudio. And as I already asked previously, why should I believe that his other software really works if he's not able to get that one software working. And, yes, there are incompatibilities in systemd. As far as I read there are a lot of initscripts which don't work with systemd and therefore have/had to be rewritten to get them working with systemd. Where's the bug? In the scripts or in systemd? This is what all DEs I'm aware of have been doing for a long time. They create mountpoints and mount removable media under /media, which is perfectly in line with the FHS. If they create a subdirectory under /media it's indeed corresponding to the FHS. Whatever the difference [...] may be, this should give you a hint that there is something you are missing... Then explain it to me. An optical drive is also only mounted temporarily. I don't see a difference between mounting a harddisk temporarily or mounting a dvd temporarily. Maybe you can explain the difference. Please stop this nonsense. First of all, the way in which /media is (and has been) used has nothing to do with Lennart. Secondly, the FHS has not been breached in this instance. Thirdly, anyone who knows anything about these matters agree that the FHS is outdated and needs to be rewritten (and that until it is, we should not care too much about it). So let everybody invent their own directory scheme, because FHS is so called outdated so that every Linux distribution and every Unix derivate is totally incompatible with each other? Right, great idea! What about first rewriting the FHS first to make it up-to-date again and only then using this new FHS? Until then the FHS should be fully respected. And why doesn't have anyone who knows anything about these matters updated this FHS, yet? Because anyone who knows anything about these matters agrees that the FHS is outdated and needs to be rewritten? Come on, if this was really true then the FHS would have already been rewritten by those guys. So this is nonesense. And, btw., I don't see any point in which the FHS doesn't work anymore. But maybe you can explain this, too. This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional. Wrong again, it's not intentional, it's buggy. It was intentional if the FHS would first be rewritten and the upstream developers would then follow the new FHS. Heiko
Re: [arch-general] change in mount behaviour?
Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen t...@jklm.no: Have you tried after this fix was released: http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253? Like I've written in another e-mail in this thread: And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault. This is what is done by this fix. But those (semi-)professional audio cards with an ice1712 chip aren't SoundBlaster like stereo sound cards for playing some games. They work completely different, because they have several separate channels which can be mixed however you want (of course to normal stereo, too, but not only). Look at the only working mixer for this card, envy24control in alsa-tools (or alsa-tools-ice1712 from AUR), to get a clue. It's sort of a clone of the original mixer and patchbay of the Windows driver for these cards. Or search for documentation of these cards. The problem is, that Lennart Poettering and the other PulseAudio guys don't know anything about these cards. There's also an upstream bug (I don't have the URL to hand), which was indeed closed as fixed with a reference to this commit. Since this is not a fix and not even a workaround I reopened the bug report and never got an update of this bug, yet. So, no, as long as the PulseAudio developers don't know enough about sound and audio and as long as they don't support every sound and audio card in the way those cards are supposed to by the hardware developers and the users, it's just crap, and definitely not a candidate for being a standard. ALSA can handle every sound and audio card including the ice1712 cards perfectly out-of-the-box without such a strange configuration. Dunno. Depends on the bug. Point me at it and I'll fix it wherever it is. I'm not using systemd and never will until Arch Linux switches officially to it. But it was already announced that this will most likely not happen. I guess there are good reasons for this decision. The different usecases of /media and /mnt are explained in the FHS link you provided. I don't see any difference there. Optical media contain a filesystem and harddisks contain filesystems. Both are usually mounted temporarily. So what's the difference? Nope. We are working with the other distros to make things more uniform, not less. In my humble opinion doing this work within the framework of the FHS is not very effective. Coding by committee seldom works. If this is really done this way it's OK. But somehow I still have my doubts. But I'm open to conviction. My impression recently was that there are a lot of people doing and inventing a lot of things on their own which has almost nothing to do with any Linux standards, particularly again Lennart Poettering, and that some other distros just take Lennart's ideas without thinking about it, while other distros don't do this, etc. And you know what I still think of Lennart. The things that are agreed upon are being added to the next version of FHS, but I guess things are not done in the order you would prefer. If this will indeed happen, then it's OK for me. Still I have some doubts. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 15:29:33 +0100 schrieb Ralf Mardorf ralf.mard...@alice-dsl.net: The majority of Linux users on non-audio Linux mailing lists praise PA, ... And the most computer users use Windows. So what's the point? That doesn't mean that Windows is better than Linux or that Windows works perfectly. I'm sure that most Linux users just use their stereo or maybe surround SoundBlaster like or onboard AC'97 sound card and not a (semi-)professional audio card. For those people PulseAudio may work, but that doesn't mean that it really works, because they just don't see all the flaws. And it definitely doesn't work with those ice1712 cards. And I've seen a lot of discussions in Linux and IT forums where PulseAudio absolutely wasn't praised, where most users said that it is crap or at least unnecessary, because of the missing hardware support, and because most of the features are already done by ALSA itself out-of-the-box. I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage. You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them. So you see, that some people just don't care, maybe because they don't know better. I would call those 2% buggy and a waste of resources. Another reason not to using PulseAudio. Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;). This comparison is flawed. A guitarist wouldn't go on stage and drum, if he can't drum, and vice versa. But Lennart writes a software for something he at least doesn't know enough about (PulseAudio) and tries to have this declared as standard, and at the same time writes another software (systemd), which also has several issues or is at least not really compatible with existing systems or script as far as I know, instead of first fixing the first one, so that it really works. And then he thinks he has to get involved in other things at the same time. This is something completely different, and this is what I'm worried about. If he would do one thing and would really try to fix its issues and he would really try to learn how to fix them, I wouldn't say much. But I don't see this. So how should I trust him and his software if he gets himself involved in several different things if he's not able to do the one and even the other thing correctly? Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 17:05:25 + schrieb Fons Adriaensen f...@linuxaudio.org: PA is for 'consumer' use, its scope ends at ITU 5.1 or so. It doesn't support any serious multichannel card (like the the comlete RME series, up to 64+64 channels). Users of such cards don't need or want PA, so it's really not a problem at all. That's principally what I said. The problem is that several distros and DEs like Gnome depend on PulseAudio as far as I know. This is what I'm concerned about. Arch Linux and Xfce, what I'm using, fortunately don't depend on it. If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care. If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client. I'm using an M-Audio Audiophile 24/96, so one of the cheapest semi-professional audio cards of this kind. And I admit I primarily use it for listening to music, watching videos etc. because of its sound quality. But you're right I don't want and need PulseAudio. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 18:22:05 +0100 schrieb Stefan Wilkens stefanwilk...@gmail.com: Does this really need to be rehashed yet again? This isn't arch related yet these PA back and forths keeps popping up in the mailboxes of all the registered people looking for arch-related content. I didn't follow the original discussion so I cant argument on that extent, but the last thing we need on this list is more noise. I guess there's a reason why this always pops up on several mailing lists. I would say it's just related to Lennart Poettering who has also developed systemd which was originally mentioned regarding the mount behaviour, and who thinks he needs to take part on the discussion about the FHS and thinks he needs to change every standard. And both tools shall be declared as a new Linux standard (that's at least my impression) even if both don't work very well, don't support every hardware or are just unnecessary (PulseAudio) or have issues regarding incompatibilities (systemd). That's the point and that's why you always will read PulseAudio in threads which are at least partly related to Lennart Poettering or his software. If Lennart would either fix all those issues in PulseAudio and systemd, so that they would really work for everybody and would really bring advantages for everybody or at least no disadvantages, or if his software would just be optional and not needed as a dependency by some distros or DEs, I'm pretty sure this discussion wouldn't always pop up again. Heiko
Re: [arch-general] PulseAudio again (was: change in mount behaviour?)
Am Sat, 28 Jan 2012 17:34:32 + schrieb Fons Adriaensen f...@linuxaudio.org: It's part of a more general trend, that of dependencies on specific desktop junk trickling down into even basic system components and plain apps. And that's a problem. This should be changed again. And it's staring to affect Arch as well, be it much less than some others. The Arch devs fortunately try to avoid this trend as good as possible. I hope they can keep it up. And I hope that other distros and upstream developers will rethink soon. Heiko
