Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 23 July 2012 23:42, David C. Rankin wrote: > On 07/23/2012 09:22 PM, Martin Cigorraga wrote: > > Again: people don't read, screw up their system and then blame the > > change... :P > > In some case yes, in some cases, that's not quite true. The usrlib change > depended a great deal on how old your Arch install was, how many custom > packages > you had built with files in /lib, how many initramfs you have generated > over the > years, whether you have older versions of virtualbox around, whether you > every > used nvidia, etc.., etc.. etc.. > > It was no small change for those with older systems or many custom > packages. > > Read, yes, read, but if you read the wiki and did the first: > > pacman -Syu --ignore glibc > > _before_ you rebuilt all the needed custom packages, then you were left > unable > to build them until you completed the glibc install due to linker and other > needed links being moved from /lib to /usr/lib before the symlink of /lib > -> > /usr/lib is created _after_ the glibc update. There are a few sticky > wickets in > there, involving temporary package removal with -Rdd in order to complete > the > glibc install to be able to rebuild some of the offending packages. > > The better was to first verify what packages had files in /lib and then > rebuild > until only glibc had files in /lib, then do the first pacman -Syu --ignore > glibc > > Only experience showed that was the way to go.. > > -- > David C. Rankin, J.D.,P.E. > > > Good point - I didn't see that. I agree with you, but my personal experience with the upgrade was quite smooth in my three home machines: 1 old laptop I use as server, 1 tower I use for NAS and my personal laptop which is a 4x4 multi purpose system - being my notebook a 1 and half year old and the other two 1 year old each. All I had to do was remove a few packages that had files installed in /lib, update glibc reinstall them and continue with my life :) The beauty behind this is we are now enjoying the new paradigm without reinstalling the system while with other distros your only chance to make the switch is reinstall not only your OS but everything else! Cheers. -- -msx
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, Jul 23, 2012 at 05:57:46PM +0200, Tom Gundersen wrote: > > Is debian switching > > That remains to be seen. If Debian intends to continue support for Hurd and KfreeBSD they can't move to systemd -- which relies on Linux kernel features to work. That debian has a disincentive is not the same as Arch having a disincentive, tho'. I would rather we use DJB's daemontools as process 1 but I know exactly how these arguments tend to go.
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/23/2012 09:22 PM, Martin Cigorraga wrote: > Again: people don't read, screw up their system and then blame the > change... :P In some case yes, in some cases, that's not quite true. The usrlib change depended a great deal on how old your Arch install was, how many custom packages you had built with files in /lib, how many initramfs you have generated over the years, whether you have older versions of virtualbox around, whether you every used nvidia, etc.., etc.. etc.. It was no small change for those with older systems or many custom packages. Read, yes, read, but if you read the wiki and did the first: pacman -Syu --ignore glibc _before_ you rebuilt all the needed custom packages, then you were left unable to build them until you completed the glibc install due to linker and other needed links being moved from /lib to /usr/lib before the symlink of /lib -> /usr/lib is created _after_ the glibc update. There are a few sticky wickets in there, involving temporary package removal with -Rdd in order to complete the glibc install to be able to rebuild some of the offending packages. The better was to first verify what packages had files in /lib and then rebuild until only glibc had files in /lib, then do the first pacman -Syu --ignore glibc Only experience showed that was the way to go.. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] rc.local.shutdown equivalent in systemd
On 07/23/12 20:10, Manolo Martínez wrote: Hello, I've decided to try systemd and see for myself. Anyway, I need to remove a module before shutdown, which rc.local.shutdown did nicely for me. I know there is an initscripts-systemd packages that would allow me to keep using rc.local.shutdown, but the wiki discourages its use and recommends instead using systemd native configuration files. Hence my question: what's the systemd native way to do stuff (in my case, remove a module) before shutdown? Thanks, Manolo Perhaps something like this? [Unit] Description=Unload module before shutdown Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=multi-user.target Haven't tried it, might not work, no guarantees, etc..
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
The problem is not Arch is bleeding edge nor this deep change from /lib to /usr/lib, the problem is that _people don't read_: everything was *clearly* explained in the website's frontpage news and in the wiki. Here's what the people at Project Zomboid had to do to ensure it's customers READ a notice: http://projectzomboid.com/blog/index.php/buy-our-games/ Again: people don't read, screw up their system and then blame the change... :P -- -msx
Re: [arch-general] rc.local.shutdown equivalent in systemd
On 07/23/2012 09:10 PM, Manolo Martínez wrote: Hence my question: what's the systemd native way to do stuff (in my case, remove a module) before shutdown? You might try something like this (untested as I am not currently using systemd)- I'm not sure if you need the Before= since your "stuff" is in ExecStop ... I'm also not sure how to guarantee system logging is still active when your program runs ... but perhaps there are experts here who can help. [unit] Before=shutdown.target ... [Service] Type=oneshot RemainAfterExit=true ExecStart=/bin/true ExecStop= Gene/
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 22 July 2012 13:41, Damjan wrote: > Also, by splitting it in different files you make it more robust. You > don't want to bork your network setup just because you were editing your > locale and forgot to close a quote. @Damjan: this isn't completely true because if the config file parser is well coded it just can ignore the faulty locale line while correctly parsing everything else, that's what I do when I need to parse a file: if a line has a typo or a value is out of range or plain wrong I make the parser show a warning message and keep parsing the config file :) My 2 cents regarding rc.conf (as a 2-years Arch fan): Seems I've been out of sync lately because I was totally unaware about this grand change. First of all I want to say I'm admitedly in love with Arch (as strange as it sounds, being in love with software): for a lazy guy like me Arch is both easy and simple, in fact easier and simpler than any other GNU/Linux distro out there (may be with the only exception of Slackware). It has a clean file layout, the packaging system is one of the best out there -if not the best- and it's easy to see The Arch Way is implemented system wide. One of the great things I specially love about Arch is /etc/rc.conf and it's whole sysconfig scheme: it's plain *awesome* to have init configuration centralized in one slim file instead scattered through god-may-know where; /etc/rc.conf is almost *perfect* specially if I compare it with SysV Init cumbersome scheme, with plenty of directories and S and K files, come on, that really sucks. But as things change and as systemd is becoming a de-facto on GNU/Linux distros, and there's nothing that can be done to keep the awesome rc.conf from being splitted, I vote for EMBRACE THE CHANGE AS SOON AS WE CAN. If rc.conf has it's days counted, then don't delay what must be done: Arch is bleeding edge so let's honour it. While I don't like the idea of losing rc.conf and I know I will miss the 'good old days' I don't want to delay a change I know it's unavoidable :'( Since I first met Arch Linux and since I first read The Arch Way I instantly knew this was the distro I was looking for since so much time, it was already packed with nothing else than awesomeness. Because that I strongly believe devs and TUs and everyone else who contribute to the distro development knows what's the best way to keep up with the The Arch Way and to keep Arch Linux a simple, minimalist, clean, easy and lightweight GNU/Linux distribution. Cheers =) -- -msx
[arch-general] rc.local.shutdown equivalent in systemd
Hello, I've decided to try systemd and see for myself. Anyway, I need to remove a module before shutdown, which rc.local.shutdown did nicely for me. I know there is an initscripts-systemd packages that would allow me to keep using rc.local.shutdown, but the wiki discourages its use and recommends instead using systemd native configuration files. Hence my question: what's the systemd native way to do stuff (in my case, remove a module) before shutdown? Thanks, Manolo --
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Jul 24, 2012 12:10 AM, "Gaetan Bisson" wrote: > > [2012-07-23 16:35:26 +0100] Kevin Chadwick: > > You should work for Redhat. > > Could you give us a break for a couple minutes and reflect on how many > people you just spammed with your dozen content-free emails? Thanks for > thinking for more than half a second next time you send something here. > > -- > Gaetan Couldn't have said it better. I'm not by any means a technical expert, but even I could see how much "basis" his posts had (or didn't)
Re: [arch-general] Skype locks up my system, not even sysrq keys work
On 23-07-2012 22:27, SanskritFritz wrote: > When I do a videochat in skype, the whole system freezes after a > while. This while can be a couple to 10+ minutes. The system locks up > usually when I start or close some other apps in the background. When > it happens the screen doesnt change anymore, and the sound stutters > the last half second over and over again. > Nothing helps, not even the magic sysrq keys (REISUB), which otherwise > do work (tested it). > I suspect this could be a result of a new videocard in the system (the > problem started around that time, when I swapped the old GeForce 7300 > GS to a new 8600 GT), but everything else works flawlessly, 3D games, > movies, compiz, everything, except skype. Is it possible that a > hardware problem causes a problem of this magnitude only with skype? > I couldn't find anything in the logfiles after reboot. There is no > overheating of the nvidia card or cpu, I constantly check it with > conky. > Later I'm going to switch back to the old videocard, and test, to see > if it is hardware related. > Please help me to find the problem if software related. > Cheers > SanskritFritz > Try some programs that deal only with the webcam, you could try vlc or guvcview to stream only video from the webcam and check if it hangs. There are reports that the uvcvideo module needs to be loaded with nodrop=1 in order to get things to work smoothly, do search in the forums, I believe I saw something about this there. -- Mauro Santos
Re: [arch-general] Skype locks up my system, not even sysrq keys work
2012/7/23 SanskritFritz > When I do a videochat in skype, the whole system freezes after a > while. This while can be a couple to 10+ minutes. The system locks up > usually when I start or close some other apps in the background. When > it happens the screen doesnt change anymore, and the sound stutters > the last half second over and over again. > Nothing helps, not even the magic sysrq keys (REISUB), which otherwise > do work (tested it). > I suspect this could be a result of a new videocard in the system (the > problem started around that time, when I swapped the old GeForce 7300 > GS to a new 8600 GT), but everything else works flawlessly, 3D games, > movies, compiz, everything, except skype. Is it possible that a > hardware problem causes a problem of this magnitude only with skype? > I couldn't find anything in the logfiles after reboot. There is no > overheating of the nvidia card or cpu, I constantly check it with > conky. > Later I'm going to switch back to the old videocard, and test, to see > if it is hardware related. > Please help me to find the problem if software related. > Cheers > SanskritFritz > Any hint from /var/log/errors? Else any hint from calling skype from a terminal and observing tty output? Regards.
[arch-general] Skype locks up my system, not even sysrq keys work
When I do a videochat in skype, the whole system freezes after a while. This while can be a couple to 10+ minutes. The system locks up usually when I start or close some other apps in the background. When it happens the screen doesnt change anymore, and the sound stutters the last half second over and over again. Nothing helps, not even the magic sysrq keys (REISUB), which otherwise do work (tested it). I suspect this could be a result of a new videocard in the system (the problem started around that time, when I swapped the old GeForce 7300 GS to a new 8600 GT), but everything else works flawlessly, 3D games, movies, compiz, everything, except skype. Is it possible that a hardware problem causes a problem of this magnitude only with skype? I couldn't find anything in the logfiles after reboot. There is no overheating of the nvidia card or cpu, I constantly check it with conky. Later I'm going to switch back to the old videocard, and test, to see if it is hardware related. Please help me to find the problem if software related. Cheers SanskritFritz
Re: [arch-general] Arch's move to systemd integration
Hi all, I've used Arch for the last 4 years and I'm increasingly comfortable using it On the switch to systemd, people interested in the topic should give a look at the Fosdem presentation about the project a year ago ;) systemd, beyond init http://www.youtube.com/watch?v=TyMLi8QF6sw&feature=plcp Best, Antoine 2012/7/23 Myra Nelson : > On Mon, Jul 23, 2012 at 3:38 AM, Paul Gideon Dann wrote: >> On Sunday 22 Jul 2012 15:14:13 Myra Nelson wrote: >>> My comparison to file size was meant to be extended to the complete >>> removal of rc.d and conf.d or the removal of several files in those >>> directories. Maybe that concept is not that important. I didn't mean >>> to imply the KISS principle was about size, just trying to imply this >>> change doesn't necessarily violate that principle. >> >> When I read about file sizes, my immediate thought was that it's being used >> as >> a metric for simplicity of configuration. Did noone else think this? If the >> configuration file sizes are small, this might indicate that it won't be a >> nightmare to configure. >> >>> My main argument >>> was "If I can get this done anyone can. It's not that much different, >>> it's just different". It appears to me to be just as portable as the >>> current setup and it might just save the Devs some time, and provide >>> better integration with upstream devs. Another salient point is just >>> because it's been done that way since Moses was a baby doesn't make it >>> right. Sorry if I offend anyone. >> >> Thank you for sharing this Myra; I think this is a helpful argument. The >> lesson seems to be: systemd is not difficult to use; it's just new, shiny, >> and >> different. Don't be scared of it. >> >> As for me, I haven't made the switch yet mainly because I haven't had the >> time >> to look into it properly. >> >> Paul > > Paul: > > A voice of reason in the darkness. The size comparisons were a silly > comparison to such BS in another thread about systemd. You seem to be > the only one who picked up on the central point of my argument. If a > half brain dead old woman can do this with minimal problems the > younger generation shouldn't have any problem with it. > > Thank you very much. > > Myra > > -- > Life's fun when your sick and psychotic!
Re: [arch-general] Upcoming changes to virtualbox
On 07/23/2012 06:11 AM, Sébastien Luttringer wrote: >> Come to think of this, would dkms then be a hard dep for virtualbox? > dkms become an hard dep for virtualbox-source (and > virtualbox-archlinux-source). You can still use virtualbox-modules. > What about for those using virtualbox-bin and virtualbox-ext-oracle for AUR? I attempted to build the virtualbox-ext-oracle package which pulled in as dependencies: virtualbox 4.1.18-2 virtualbox-modules 4.1.18-4 Neither were wanted. Does this new dependency requirement need to be fixed in the AUR packages so that virtualbox-ext-oracle does not automatically pull in the Arch versions? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] linux-3.5.0-1 enters [testing]
On Mon, Jul 23, 2012 at 7:24 PM, Marius T. wrote: > I know that you are not supposed to run long scripts from udev rules, maybe > this has something to do with it (although the script shouldn't take much > time). I'm gonna have a look into it... A short-running script to configure something should be fine. Just no "daemons". -t
Re: [arch-general] linux-3.5.0-1 enters [testing]
Am 23.07.2012 19:24, schrieb Marius T.: Am 23.07.2012 19:10, schrieb Karol Babioch: Hi, Am 23.07.2012 18:46, schrieb Leonid Isaev: Rebuild your initramfs. Of course, I have completely forgotten that I've updated the kernel first this time. Quite stupid, sorry for the noise. Nevertheless I don't get any errors: http://pastebin.com/NwmNAciN So, I'm afraid this is something specific to your system :(. Best regards, Karol Babioch I found the culprit: I have a custom udev rule which watches for a HDMI hotplug event and then starts a script which configures the screens with xrandr accordingly. When I disable it, 3.5 boots up without errors. Still strange that it works fine in 3.4.6 (I downgraded to confirm it). I know that you are not supposed to run long scripts from udev rules, maybe this has something to do with it (although the script shouldn't take much time). I'm gonna have a look into it... thanks and best regards, Marius sorry, turns out I spoke too soon, this wasn't related to the udev rule, it just doesn't happen on every boot. sometimes it also gets stuck at the stack trace and I have to do a hard reset. suspending is also broken, it gets stuck with the following: Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks... (elapsed 0.01 seconds) done. PM: Entering mem sleep Suspending console(s) (use no_console_suspend to debug) god damnit, I hate this laptop, one issue after the other... :(
Re: [arch-general] Why was wv2 dropped from extra? wv does _not_ provide the wv2 headers
On 07/22/2012 11:47 PM, David C. Rankin wrote: > Guys, > > Why was wv2 dropped from extra? Nothing else provides the headers: > > wv2 /usr/include/wv2/associatedstrings.h > wv2 /usr/include/wv2/convert.h > wv2 /usr/include/wv2/dllmagic.h > wv2 /usr/include/wv2/fields.h > wv2 /usr/include/wv2/fonts.h > wv2 /usr/include/wv2/functor.h > wv2 /usr/include/wv2/functordata.h > wv2 /usr/include/wv2/global.h > wv2 /usr/include/wv2/handlers.h > wv2 /usr/include/wv2/lists.h > wv2 /usr/include/wv2/olestorage.h > wv2 /usr/include/wv2/olestream.h > wv2 /usr/include/wv2/paragraphproperties.h > wv2 /usr/include/wv2/parser.h > wv2 /usr/include/wv2/parserfactory.h > wv2 /usr/include/wv2/sharedptr.h > wv2 /usr/include/wv2/styles.h > wv2 /usr/include/wv2/textconverter.h > wv2 /usr/include/wv2/ustring.h > wv2 /usr/include/wv2/utilities.h > wv2 /usr/include/wv2/word95_generated.h > wv2 /usr/include/wv2/word97_generated.h > wv2 /usr/include/wv2/word_helper.h > wv2 /usr/include/wv2/wv2version.h > wv2 /usr/include/wv2/wvlog.h > > It still builds fine (one glib fix to olestream.h - filed upstream). I was > surprised when I went to install dependencies in a new chroot only to find > that > install failed due to no wv2. Can you guys put it back in extra? > I created an AUR package with olestream.h patched for new glib inclusion scheme. See: https://aur.archlinux.org/packages.php?ID=61146 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] linux-3.5.0-1 enters [testing]
My integrated USB Wacom tablet ISDv4 (056a:0094) is no longer recognized, the wacom kernel module doesn't get loaded, the device shows up in lsusb, but isn't even mentioned in Xorg.0.log (xf86-input-wacom 0.16.0-1) Then, the system completely froze an hour ago, not even sysrqs were working. Nothing was logged after the freeze. signature.asc Description: OpenPGP digital signature
Re: [arch-general] linux-3.5.0-1 enters [testing]
Am 23.07.2012 19:10, schrieb Karol Babioch: Hi, Am 23.07.2012 18:46, schrieb Leonid Isaev: Rebuild your initramfs. Of course, I have completely forgotten that I've updated the kernel first this time. Quite stupid, sorry for the noise. Nevertheless I don't get any errors: http://pastebin.com/NwmNAciN So, I'm afraid this is something specific to your system :(. Best regards, Karol Babioch I found the culprit: I have a custom udev rule which watches for a HDMI hotplug event and then starts a script which configures the screens with xrandr accordingly. When I disable it, 3.5 boots up without errors. Still strange that it works fine in 3.4.6 (I downgraded to confirm it). I know that you are not supposed to run long scripts from udev rules, maybe this has something to do with it (although the script shouldn't take much time). I'm gonna have a look into it... thanks and best regards, Marius
Re: [arch-general] linux-3.5.0-1 enters [testing]
Hi, Am 23.07.2012 18:46, schrieb Leonid Isaev: > Rebuild your initramfs. Of course, I have completely forgotten that I've updated the kernel first this time. Quite stupid, sorry for the noise. Nevertheless I don't get any errors: http://pastebin.com/NwmNAciN So, I'm afraid this is something specific to your system :(. Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Hi, Am 23.07.2012 17:29, schrieb Kevin Chadwick: > Tested, simply sophisticated and as fast as you make it. There is no parallelization, no socket activation and no auto mounting. In no way can it be as fast as systemd. > Once you get to desktop level and SSDs, who cares about a few seconds. It's not only about speed, but speed is a nice bonus. Its also about reliability. But I'm not going to enumerate the advantages of systemd over and over again. Just read the blog posts by Lennart ;). > The fastest booting systems (< 1 second) use init and won't use systemd. Which systems do you have in mind? Personally I can tell you out of experience that my system boots up faster with systemd. > WRT pulse audio it won't run under a grsecurity kernel so first > I'd say define modern desktop. How functional, how secure. On a "modern desktop" you probably have bigger concerns regarding security then running grsecurity. That said it should run fine with SElinux, which Fedora is using by default. Furthermore grsecurity seems to focus on servers anyway, so I'm not sure why you even bring this up? Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] linux-3.5.0-1 enters [testing]
On Mon, 23 Jul 2012 18:36:52 +0200 Karol Babioch wrote: > Hi, > > Am 23.07.2012 18:11, schrieb Marius T.: > > I get a "systemd-udevd not tainted" error with a stack trace on boot on > > my Sony Vaio VPCS11C5E. Other than that the system seems to work fine. > > Since you happen to have a similiar Vaio model, can you confirm any of > > this, Karol? > > Interestingly I don't get any of this. I've tried it with both the old > systemd 186-2 (http://pastebin.com/mvVK763V) as well as the new 187-2 > (http://pastebin.com/QzhFSfhF) one. > > What else have you upgraded? So far I've upgraded the following packages > from testing amd/or community-testing: > > [2012-07-23 18:21] upgraded linux-headers (3.4.6-1 -> 3.5-1) > [2012-07-23 18:22] upgraded linux-docs (3.4.6-1 -> 3.5-1) > [2012-07-23 18:22] upgraded linux (3.4.6-1 -> 3.5-1) > [2012-07-23 18:22] upgraded virtualbox-modules (4.1.18-4 -> 4.1.18-5) > [2012-07-23 18:26] upgraded systemd-sysvcompat (186-2 -> 187-2) > [2012-07-23 18:26] upgraded libsystemd (186-2 -> 187-2) > [2012-07-23 18:26] upgraded systemd-tools (186-2 -> 187-2) > [2012-07-23 18:26] upgraded systemd (186-2 -> 187-2) > > Interestingly enough my dmesg output still contains the following: > > [0.904375] systemd-udevd[51]: starting version 186 > > Yours is reporting version 187 here, so I'm not entirely sure what is > going on. Is there something wrong with the packages? Rebuild your initramfs. > > > systemctl status systemd-udevd.service: > > [johnpatcher@vpcs ~]$ systemctl status systemd-udevd.service > systemd-udevd.service - udev Kernel Device Manager > Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; > static) Active: active (running) since Mon, 23 Jul 2012 18:27:08 +0200; 8min > ago Docs: man:systemd-udevd.service(8) > man:udev(7) > Main PID: 213 (systemd-udevd) > CGroup: name=systemd:/system/systemd-udevd.service > └ 213 /usr/lib/systemd/systemd-udevd > > Warning: Journal has been rotated since unit was started. Log output is > incomplete or unavailable. > > Best regards, > Karol Babioch > > > > -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] linux-3.5.0-1 enters [testing]
Hi, Am 23.07.2012 18:11, schrieb Marius T.: > I get a "systemd-udevd not tainted" error with a stack trace on boot on > my Sony Vaio VPCS11C5E. Other than that the system seems to work fine. > Since you happen to have a similiar Vaio model, can you confirm any of > this, Karol? Interestingly I don't get any of this. I've tried it with both the old systemd 186-2 (http://pastebin.com/mvVK763V) as well as the new 187-2 (http://pastebin.com/QzhFSfhF) one. What else have you upgraded? So far I've upgraded the following packages from testing amd/or community-testing: [2012-07-23 18:21] upgraded linux-headers (3.4.6-1 -> 3.5-1) [2012-07-23 18:22] upgraded linux-docs (3.4.6-1 -> 3.5-1) [2012-07-23 18:22] upgraded linux (3.4.6-1 -> 3.5-1) [2012-07-23 18:22] upgraded virtualbox-modules (4.1.18-4 -> 4.1.18-5) [2012-07-23 18:26] upgraded systemd-sysvcompat (186-2 -> 187-2) [2012-07-23 18:26] upgraded libsystemd (186-2 -> 187-2) [2012-07-23 18:26] upgraded systemd-tools (186-2 -> 187-2) [2012-07-23 18:26] upgraded systemd (186-2 -> 187-2) Interestingly enough my dmesg output still contains the following: [0.904375] systemd-udevd[51]: starting version 186 Yours is reporting version 187 here, so I'm not entirely sure what is going on. Is there something wrong with the packages? > systemctl status systemd-udevd.service: [johnpatcher@vpcs ~]$ systemctl status systemd-udevd.service systemd-udevd.service - udev Kernel Device Manager Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static) Active: active (running) since Mon, 23 Jul 2012 18:27:08 +0200; 8min ago Docs: man:systemd-udevd.service(8) man:udev(7) Main PID: 213 (systemd-udevd) CGroup: name=systemd:/system/systemd-udevd.service └ 213 /usr/lib/systemd/systemd-udevd Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, 23 Jul 2012 17:57:46 +0200 Tom Gundersen wrote: > On Mon, Jul 23, 2012 at 5:35 PM, Kevin Chadwick > wrote: > > Systemd is > > larger than init, so for embedded it may well quadruple boot time. > > What utter bullshit. Please, Kevin, if you are going to throw around > numbers, do some measurements first. > > systemd is so far even more successful in embedded environments than > in desktop ones (i.e. embedded people seem to be more eager to ship > it), I doubt that would be the case if it is four times slower to > boot. I'm currently using it on my raspberry pi, without any problems. > I have not done any performance measurements, but there are very good > reasons why initscripts are expected to be slower than systemd (on the > same setup) and it has nothing to do with bash versus C, or the size > of the binaries. To add, in general sysVinit does not see much use in modern embedded systems. For instance, (open)webOS (and probably android) has gone the upstart way. So far, only network appliances use sysVinit, but these are pretty conservative, e.g. many are still on 2.4 kernels (stock cisco, tomato, dd-wrt, etc). > > > Is debian switching > > That remains to be seen. There are certainly lots of debian people > involved with systemd upstream, and there are people working on > systemd integration in debian. > > -t -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] linux-3.5.0-1 enters [testing]
Am 23.07.2012 16:11, schrieb Karol Babioch: Am 23.07.2012 14:57, schrieb Tobias Powalowski: Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Please report any issues that arise. Thanks. greetings tpowa Booted fine for me as well. I was affected by the backlight regression, so its nice to see this included into mainline now ;). Best regards, Karol Babioch hi, I get a "systemd-udevd not tainted" error with a stack trace on boot on my Sony Vaio VPCS11C5E. Other than that the system seems to work fine. Since you happen to have a similiar Vaio model, can you confirm any of this, Karol? dmesg: http://pastebin.com/qguWkgR4 (line 853) systemctl status systemd-udevd.service: systemd-udevd.service - udev Kernel Device Manager Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static) Active: active (running) since Mon, 23 Jul 2012 17:58:20 +0200; 4min 40s ago Docs: man:systemd-udevd.service(8) man:udev(7) Main PID: 179 (systemd-udevd) CGroup: name=systemd:/system/systemd-udevd.service └ 179 /usr/lib/systemd/systemd-udevd Jul 23 17:58:20 mus-laptop systemd-udevd[179]: worker [210] terminated by signal 9 (Killed) Jul 23 17:58:20 mus-laptop systemd-udevd[179]: worker [210] failed while handling '/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:10/SNY5001:00' Jul 23 17:58:20 mus-laptop su[296]: pam_unix(su:session): session opened for user mus by (uid=0) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. best regards, Marius
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
For having used systemd myself, I am inclined to believe that it definitely fits the KISS principle. Systemctl is only a frontend to simplify the addition and removal of services. Simplicity is only a matter of learning new commands (systemctl enable .service, e.g.). What systemctl really does when you enable a service is that it creates symbolic links in /etc/systemd/system/.wants.target/ that point to appropriate deamon launch helpers located in /usr/lib/systemd/system/. The proper target folder (graphical, multi-user, single-user) is obtained by reading the actual target file, but this can be overridden if you do the links manually. What I find really powerful of systemd is that it hooks onto the daemon itself and monitors exit codes and log files. Finding what's wrong with your sshd service is only a matter of typing "systemctl status sshd.service". You get current activity, its PID, the actual command it ran to start it, its status code if it ceased working, and the few last lines from the log file. To find out what runs at startup, you may use systemctl. I don't know the particular command, so I don't use it myself. I managed to figure out how to do it in a couple of seconds: you only have to "ls" the right directory. Graphical mode? "ls /etc/systemd/system/graphical.target.wants". Multi-user: "ls multi-user.target.wants". Could not be simpler. I have also found that my system boots much more rapidly with systemd. I can have a fully logged-in system running XFCE4, on older hardware (Intel Pentium 64-bit laptop) in less that 40 seconds. -- Sébastien Leblanc
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
[2012-07-23 16:35:26 +0100] Kevin Chadwick: > You should work for Redhat. Could you give us a break for a couple minutes and reflect on how many people you just spammed with your dozen content-free emails? Thanks for thinking for more than half a second next time you send something here. -- Gaetan
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, Jul 23, 2012 at 5:35 PM, Kevin Chadwick wrote: > Systemd is > larger than init, so for embedded it may well quadruple boot time. What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first. systemd is so far even more successful in embedded environments than in desktop ones (i.e. embedded people seem to be more eager to ship it), I doubt that would be the case if it is four times slower to boot. I'm currently using it on my raspberry pi, without any problems. I have not done any performance measurements, but there are very good reasons why initscripts are expected to be slower than systemd (on the same setup) and it has nothing to do with bash versus C, or the size of the binaries. > Is debian switching That remains to be seen. There are certainly lots of debian people involved with systemd upstream, and there are people working on systemd integration in debian. -t
Re: [arch-general] linux-3.5.0-1 enters [testing]
On 07/23/2012 08:57 AM, Tobias Powalowski wrote: Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Please report any issues that arise. Thanks. Thank you for getting this to us so quickly :-) 1 machine in testing so far - ecnrypted home/swap - intel graphics, iwlagn wireless - as of now no problems. I am aware of the AP mode intel wireless problem, tho' it seems it will be pushed to stable shortly. (https://lkml.org/lkml/2012/7/23/38) gene
Re: [arch-general] [arch-dev-public] [RFC, after the fact] initscripts config
On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen wrote: > On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo wrote: > > 3) Personally this depends on the final rc.conf, is [1] or [2] going > > to be it? > > [1] > > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc7 > > [2] > > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f7 > > At the moment it is [1], so if no one tells me otherwise, that's it. > > > 4.1) Are we going to ship default (possibly empty) replacement > > configuration files, which currently may not exist on many systems, > > and add these to the backup array? This includes (/etc/vconsole.conf, > > /etc/locale.conf, /etc/hostname). > > I'd be against it, as it seems pointless. But it would be Dave's decision. > > > 4.2) To be clear, is there going to be a separate configuration for > > the HARDWARECLOCK and TIMEZONE variables? > > There already are. That's the problem. HARDWARECLOCK is configured in > the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is > configured by pointing the /etc/localtime symlink at what you want. I wonder if there a need for TIMEZONE as a config variable at all (whereever it is located, as opposed to an install-time setting), especially if it is recommended to be left empty? > > d) The new format does not require a bash interpreter to be read > > > > 4.d) I think this is a terrible justification. A programming language > > embedded in a configuration system grants a lot of possibilities. > > It also makes it impossible to reason about. Or to parse from another > language than what it was defined in. > > > Also there is a sound way to read configuration files written in a > > programming language - simply evaluate the code. > > But there is no sound way to then change the options and write them back. > > > In any case, to preserve compatibility with systemd, the new files > > (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not > > contain bash. > > These files can all be read by bash, but are strictly defined. This > means we can know their format and update them in a sound way. > > > 5) With the plethora of changes, each for different reasons, I think > > there is justifcation for a comprehensive news item summarizing > > changes to each variable: > > LOCALE -> /etc/locale.conf > > HARDWARECLOCK -> deprecated > > Sure. > > > USE_BTRFS -> esoteric, removed for cosmetic reasons > > Won't kill this one, but I get your point. > > -t -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Arch's move to systemd integration
On Mon, Jul 23, 2012 at 3:38 AM, Paul Gideon Dann wrote: > On Sunday 22 Jul 2012 15:14:13 Myra Nelson wrote: >> My comparison to file size was meant to be extended to the complete >> removal of rc.d and conf.d or the removal of several files in those >> directories. Maybe that concept is not that important. I didn't mean >> to imply the KISS principle was about size, just trying to imply this >> change doesn't necessarily violate that principle. > > When I read about file sizes, my immediate thought was that it's being used as > a metric for simplicity of configuration. Did noone else think this? If the > configuration file sizes are small, this might indicate that it won't be a > nightmare to configure. > >> My main argument >> was "If I can get this done anyone can. It's not that much different, >> it's just different". It appears to me to be just as portable as the >> current setup and it might just save the Devs some time, and provide >> better integration with upstream devs. Another salient point is just >> because it's been done that way since Moses was a baby doesn't make it >> right. Sorry if I offend anyone. > > Thank you for sharing this Myra; I think this is a helpful argument. The > lesson seems to be: systemd is not difficult to use; it's just new, shiny, and > different. Don't be scared of it. > > As for me, I haven't made the switch yet mainly because I haven't had the time > to look into it properly. > > Paul Paul: A voice of reason in the darkness. The size comparisons were a silly comparison to such BS in another thread about systemd. You seem to be the only one who picked up on the central point of my argument. If a half brain dead old woman can do this with minimal problems the younger generation shouldn't have any problem with it. Thank you very much. Myra -- Life's fun when your sick and psychotic!
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > to get rid of all that > > Poetterix > > Once again this is not a technical argument, but a very subjective > reason with - at least for me - no basis. Its more of a philosophy and > that's not what this should be about. > > If you *really* like an audio stack without PulseAudio (which I would > consider quite useless on a modern desktop) and an init system based > upon something as old, "stupid" and slow as SysVinit, then you are free > to stick with it. Nobody forces you to use PA and/or systemd. Tested, simply sophisticated and as fast as you make it. Once you get to desktop level and SSDs, who cares about a few seconds. The fastest booting systems (< 1 second) use init and won't use systemd. It would be good if you would practice what you preach especially when he has made hugely valid contributions that can't be fixed using systemd. Systemds functions can be replicated in the unix style of many tools doing a single job well. WRT pulse audio it won't run under a grsecurity kernel so first I'd say define modern desktop. How functional, how secure. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > that without ck. Change ownership of some things to a > > 'local' login ? I don't want that to happen. > > You're free to fight again changes or improvements. The simplest way I > know consist in installing a 70th year old system and don't update it. You should work for Redhat. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> Once again: I'm not sure whether there ever was something like a "Unix" > system. Furthermore I don't get why systemd is not Unix-like. The Unix philosophy of write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface (Doug McIlroy) > I would > argue that it is a response needed in order to get the maximum out of > our hardware, which differs quite extensively from the one Unix was > originally designed for. > That is exactly what unix was designed for in various flavours but performance and so cpu handling depends on the application. Systemd is larger than init, so for embedded it may well quadruple boot time. > Am 22.07.2012 18:17, schrieb Nicholas MIller: > > I'm also curious how the people who work on initscript believe systemd is > > superior. > > Just take a look at [1]. > A list made to impress. If you actually look at what it means to you, is it so attractive. > Am 22.07.2012 18:22, schrieb Jorge Almeida: > > That's what worries me, that you sincerelly find it superior. I don't doubt > > your good intentions. > > I'm not aware of anyone who has looked into it and doesn't find it > superior. How else would you explain that all the major distributions > are switching over and/or already have? Even before systemd there was > "Upstart", because Canonical "discovered" that the old way of booting is > not up to make most out of today's hardware. Is debian switching if not I believe ubuntu and debian probably make up far more share than perhaps all the others. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> No, no. Even without merging tool, 3 or 5 files instead of one is not > time consuming. > Ignoring systemctl output which is still less clear and slowed me down. Show what daemons will be running if you were to boot a filesystem which isn't running and tell me it's as quick to work out on a systemd system. > What is time consuming is a system strongly damaged because of human > mistake in a configuration file, more likely to happen with a > one-central-configuration-file-for-non-related-things-around. Have you ever had this problem in rc.conf? -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> I will be too. I'm testing fedora in a virtualbox session, and besides > some software not being truly "bleeding edge". Except they chose grub2-beta (still beta, though grub2 is released) before it supported automatic detection and multi-booting setup requiring manual intervention. Arch are making good discussion and testing. I was intrigued by the selinux by default of fedora but I will not install Fedora again for a long time for a few reasons. Many criticise Debian but it is a lot better than fedora. -- Why not do something good every day and install BOINC.
Re: [arch-general] Arch's move to systemd integration
> systemd is not difficult to use; But it isn't as easy untill the gui comes along is it. I'd guess an ncurses gui is planned but apparently Fedora is only meant as a desktop? -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > > > However one fine day, an abrupt power-cut later, my home partition was no > > longer mountable under systemd. Initscripts worked fine. So I switched > > back.. > > didn't miss a thing.. > > You're wrong. SysV init scripts _are_ broken, today. But it's silently > failing without even noticing it to users in many cases. Finding such > boot errors is painfull and time consuming. Did you read this before posting. It's obvious that reviewing the config files and getting the source and finding the bug in C is much easier of course and can be fixed immediately by anyone without another OS or machine. 'silently failing', only if it's meant to. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > But developpers must know better than users what is the best for the > > distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS > > oriented than /etc/locale.conf, /etc/vconsole.conf, > > /etc/modprobe.d/*.conf files. > > > > As I said, it is my $0.02. Excuse my bad english, I'm no really awake ! > > > I agree with your .02 fred, > > I prefer a well commented rc.conf config file to virtually all of the other > sysv and variations I've seen. A single file, well laid out and easily set up > with reasonable defaults by Arch and simple to customize for the user. KISS in > the best sense. > > I'll also add my .02 on commented v. non-commented config/init files. There > is > no substitution for a well commented file. I hate opening a commentless config > file and then having to switch to another vt to guess at which man page to > open. > (then alt+left, alt+right back and forth hunting down each option in some > badly > readable man page) > > For those that don't like comments, then please just 'grep -v "^#" old.conf > > > new.conf' to get rid of the comments. There is nothing the rest of the users > can > do to put the comments back in once there gone. Well said. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > 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. > specifically relevent > Sounds like you (don't take this a personal critism, you're not alone) > have poor administration practices. Editing multiple files instead of > one in not a problem at all. In fact, it's the exactly opposite. > Offended for no reason > 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). Irrelevent here. It's poor administration practice not to check your seds, eds, files to install or sudoedits anyway. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> I don't think a single Arch specific file is as simple as some > "standardized" files, where the filename already tells you what it is > supposed to do. Both comments and defaults are allowed and appreciated, > so this is not an argument at all. It is not necessarily this difference but the fact that this bsdism guarantees plain sight whilst almost all other systems I have seen are far less clear and arch was refreshing in this regard in the linux world. OpenBSD has always had an rc.conf with default base provided package settings (almost everything =NO (off)) and an override rc.conf.local showing the name and non-default commandline arguments used, which I love. Fairly recently it has gotten a single rc.d folder for user installed packages which sometimes require longer scripts too. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> Of course you could complain directly upstream, but in general there are > good reasons why they make use of things Polkit and ConsoleKit. > Otherwise each and every program would have to implement the > functionalities these packages provide for them self, which would be > even worse. Or much better -- Why not do something good every day and install BOINC.
Re: [arch-general] Arch's move to systemd integration
> i don't have any figures/proof but i think systemd is gaining quite a > bit of populatiry on the embedded linux market -- where space and > minimalist is king -- at least ii feel like i've read that a few times > recently :-) You must mean a fraction of the embedded world as. Systemd is larger than init. I wonder if arm arch is moving to systemd, though that is still quite a large OS in embedded terms compared to non MMU systems like uclibc and lower. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > 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. > Hear, hear -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
> > Simple example: I didn't have consolekit for some years, and I don't > > care about whatever it has to offer. Recent updates of xdm have pulled > > it in. So far it hasn't done anything evil except being useless and > > consuming system resources (50 or so threads). Same about polkit, it's > > pulled in only as a depency of gconf which in turn is only there because > > the Emacs package wants it. > > But this does not have anything to do with the recent proposal / change > of the "rc.conf" and the split up coming along with this. So you > shouldn't mix things up here. It does because this proposal has been thankfully and honestly made out as an expected softener of the inevitable. Breaking up systemd into smaller optional packages rather than sucking more and more in and so bugs as more code equals more bugs, should perhaps be rallied upstream and I hope is inevitable too. -- Why not do something good every day and install BOINC.
Re: [arch-general] linux-3.5.0-1 enters [testing]
Am 23.07.2012 14:57, schrieb Tobias Powalowski: > Hi guys, > > Upstream changes: > http://kernelnewbies.org/LinuxChanges > > Please report any issues that arise. > Thanks. > > greetings > tpowa > Booted fine for me as well. I was affected by the backlight regression, so its nice to see this included into mainline now ;). Best regards, Karol Babioch signature.asc Description: OpenPGP digital signature
Re: [arch-general] linux-3.5.0-1 enters [testing]
2012/7/23 Ike Devolder : > Op maandag 23 juli 2012 15:43:12 schreef fredbezies: >> 2012/7/23 Tobias Powalowski : >> > Hi guys, >> > >> > Upstream changes: >> > http://kernelnewbies.org/LinuxChanges >> > >> > Please report any issues that arise. >> > Thanks. >> > >> > greetings >> > tpowa >> > -- >> > Tobias Powalowski >> > Archlinux Developer & Package Maintainer (tpowa) >> > http://www.archlinux.org >> > tp...@archlinux.org >> >> Booted flawlessly. Only issues is vbox modules, but I can leave a day >> or two without vbox :) >> [...] > > do you have community-testing enabled? the virtualbox modules should be there. > I do have it enabled. Looks like packages were *not totally* spread when I done my sudo pacman -Syu in order to get linux-3.5.0-1. Bad luck, so :D -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] linux-3.5.0-1 enters [testing]
Op maandag 23 juli 2012 15:43:12 schreef fredbezies: > 2012/7/23 Tobias Powalowski : > > Hi guys, > > > > Upstream changes: > > http://kernelnewbies.org/LinuxChanges > > > > Please report any issues that arise. > > Thanks. > > > > greetings > > tpowa > > -- > > Tobias Powalowski > > Archlinux Developer & Package Maintainer (tpowa) > > http://www.archlinux.org > > tp...@archlinux.org > > Booted flawlessly. Only issues is vbox modules, but I can leave a day > or two without vbox :) > > Besides this, so far so good. Here is my lspci : > > [fred@fredo-arch ~]$ lspci > 00:00.0 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a1) > 00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2) > 00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2) > 00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2) > 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3) > 00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev > a3) 00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1) > 00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev > a2) 00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2) > 00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) > 00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) > 00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) > 00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) > 00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) > 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > HyperTransport Configuration > 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Address Map > 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > DRAM Controller > 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Miscellaneous Control > 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor > Link Control > 02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce > 210] (rev a2) > 02:00.1 Audio device: NVIDIA Corporation High Definition Audio > Controller (rev a1) > > Great work as usual. > > My 2 cents :D > > -- > Frederic Bezies > fredbez...@gmail.com Frederic, do you have community-testing enabled? the virtualbox modules should be there. --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] linux-3.5.0-1 enters [testing]
2012/7/23 Tobias Powalowski : > Hi guys, > > Upstream changes: > http://kernelnewbies.org/LinuxChanges > > Please report any issues that arise. > Thanks. > > greetings > tpowa > -- > Tobias Powalowski > Archlinux Developer & Package Maintainer (tpowa) > http://www.archlinux.org > tp...@archlinux.org > Booted flawlessly. Only issues is vbox modules, but I can leave a day or two without vbox :) Besides this, so far so good. Here is my lspci : [fred@fredo-arch ~]$ lspci 00:00.0 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a1) 00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2) 00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2) 00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2) 00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3) 00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3) 00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1) 00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2) 00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2) 00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) 00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2) 00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 02:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) Great work as usual. My 2 cents :D -- Frederic Bezies fredbez...@gmail.com
[arch-general] linux-3.5.0-1 enters [testing]
Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Please report any issues that arise. Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
[...] >> Not 3, but 6 more files. I do agree you don't have to modify them >> everyday, but it is - in a way - harder to set u than a single one. > If it's documented it's hard? > > Sure one file would be easier, but if the 3,4,5 or 6 files are > documented there should be no real problems. I do agree. So telling the users : do not forget to setup these files (followed by a file list) could help. Just an idea. And for 6, I also have to modules like vbox ones, so there is a file for them. -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 23/07/12 13:10, fredbezies wrote: > 2012/7/23 Rodrigo Rivas : >> On Mon, Jul 23, 2012 at 12:35 PM, 1126 >> wrote: >> >>> For you this change might be a reason to switch to Fedora, you say. I >>> mean, seriously? How is it all handled in Fedora then? Well, I don't >>> now, actually. >>> >> >> Fedora is RedHat, and that's where systemd came to live, so you can guess... >> > > I wrote the first message before I successfully done a setup with a > minimal rc.conf > >> >>> - It's a rolling release distro: You only have to carefully do pacman >> ./> -Syu to keep your system up-to-date. I started using Linux with Ubuntu >>> and first I really looked forward to a new release, I mean new >>> features, new artwork and all that stuff. But distupgrade nearly >>> always failed and so I re-installed my system every six months. This >>> is not good! With ArchLinux I can spent way more time just using my >>> system instead of playing admin. >>> >> >> Well said. I came from Ubuntu also, and I expected that in Arch some things >> would break because of it being rolling and more bleeding-edge than Ubuntu. > > For the record, I'm using arch since end of 2008 / beginning of 2009. > > It is the first time I was very upset by a change from developer team. > >> I accepted that, but as it happened, it breaks _less_ than Ubuntu. >> >> And, actually, about the rc.conf split, I couldn't care less. One file, >> three files, doesn't make a difference to me. As long as they are text >> files, and not binary ones, like some other mainstream systems, all is good. >> > > Not 3, but 6 more files. I do agree you don't have to modify them > everyday, but it is - in a way - harder to set u than a single one. If it's documented it's hard? Sure one file would be easier, but if the 3,4,5 or 6 files are documented there should be no real problems. > > >> Just my 0.02 € >> -- >> Regards. > > > -- Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-general] Upcoming changes to virtualbox
On Mon, Jul 23, 2012 at 3:29 AM, Oon-Ee Ng wrote: > On Mon, Jul 23, 2012 at 9:04 AM, Sébastien Luttringer wrote: >> On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch wrote: >>> Am 23.07.2012 02:01, schrieb Sébastien Luttringer: > My current practice is to use my own simple wrapper script to call > vboxbuild $KERNEL to rebuild for all my currently installed kernels. > Will this be possible with dkms install? You can build/install script for a custom kernel version with something like $ dkms install vbhoxhost/4.1.18 -k $KERNEL You can also let dkms rc script do it for you at boot. > Come to think of this, would dkms then be a hard dep for virtualbox? dkms become an hard dep for virtualbox-source (and virtualbox-archlinux-source). You can still use virtualbox-modules. > could I just save a copy of the currently working vboxbuild and continue to > use that? For a time probably. However, there is some bug reports open which will not be fixed. > I used to have my own script (its > probably backed up somewhere) for doing this, but vboxbuild was just > easier to use. This change is soft and can open new way of handling custom modules. Take a look at dkms, it's a non-upstream modules manager. You can use it to build/install/load _all_ your custom modules with "dkms autoinstall". -- Sébastien "Seblu" Luttringer www.seblu.net
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
2012/7/23 Rodrigo Rivas : > On Mon, Jul 23, 2012 at 12:35 PM, 1126 > wrote: > >> For you this change might be a reason to switch to Fedora, you say. I >> mean, seriously? How is it all handled in Fedora then? Well, I don't >> now, actually. >> > > Fedora is RedHat, and that's where systemd came to live, so you can guess... > I wrote the first message before I successfully done a setup with a minimal rc.conf > >> - It's a rolling release distro: You only have to carefully do pacman >./> -Syu to keep your system up-to-date. I started using Linux with Ubuntu >> and first I really looked forward to a new release, I mean new >> features, new artwork and all that stuff. But distupgrade nearly >> always failed and so I re-installed my system every six months. This >> is not good! With ArchLinux I can spent way more time just using my >> system instead of playing admin. >> > > Well said. I came from Ubuntu also, and I expected that in Arch some things > would break because of it being rolling and more bleeding-edge than Ubuntu. For the record, I'm using arch since end of 2008 / beginning of 2009. It is the first time I was very upset by a change from developer team. > I accepted that, but as it happened, it breaks _less_ than Ubuntu. > > And, actually, about the rc.conf split, I couldn't care less. One file, > three files, doesn't make a difference to me. As long as they are text > files, and not binary ones, like some other mainstream systems, all is good. > Not 3, but 6 more files. I do agree you don't have to modify them everyday, but it is - in a way - harder to set u than a single one. > Just my 0.02 € > -- > Regards. -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, Jul 23, 2012 at 12:35 PM, 1126 wrote: > For you this change might be a reason to switch to Fedora, you say. I > mean, seriously? How is it all handled in Fedora then? Well, I don't > now, actually. > Fedora is RedHat, and that's where systemd came to live, so you can guess... > - It's a rolling release distro: You only have to carefully do pacman > -Syu to keep your system up-to-date. I started using Linux with Ubuntu > and first I really looked forward to a new release, I mean new > features, new artwork and all that stuff. But distupgrade nearly > always failed and so I re-installed my system every six months. This > is not good! With ArchLinux I can spent way more time just using my > system instead of playing admin. > Well said. I came from Ubuntu also, and I expected that in Arch some things would break because of it being rolling and more bleeding-edge than Ubuntu. I accepted that, but as it happened, it breaks _less_ than Ubuntu. And, actually, about the rc.conf split, I couldn't care less. One file, three files, doesn't make a difference to me. As long as they are text files, and not binary ones, like some other mainstream systems, all is good. Just my 0.02 € -- Regards.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 23 July 2012 11:35, 1126 wrote: > Okay, time to drop my 0.02¢ as well. And I'm pretty sure everything said > here in this mail has been said elsewhere as well, but hey... ;) > [...] > the features that ArchLinux really make the best linux distro out there imho: > [...] Good points indeed. BTW, I've read the thread, I've reconsidered it my own opinions and I've come to the conclusion that I have no reason to not to trust that Arch developers won't keep their actions aligned with "The Arch Way". As long as the "The Arch Way" won't wiggle too much or too often, I'm cool. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: [arch-general] [arch-dev-public] [RFC, after the fact] initscripts config
On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo wrote: > 3) Personally this depends on the final rc.conf, is [1] or [2] going > to be it? > [1] > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc7 > [2] > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f7 At the moment it is [1], so if no one tells me otherwise, that's it. > 4.1) Are we going to ship default (possibly empty) replacement > configuration files, which currently may not exist on many systems, > and add these to the backup array? This includes (/etc/vconsole.conf, > /etc/locale.conf, /etc/hostname). I'd be against it, as it seems pointless. But it would be Dave's decision. > 4.2) To be clear, is there going to be a separate configuration for > the HARDWARECLOCK and TIMEZONE variables? There already are. That's the problem. HARDWARECLOCK is configured in the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is configured by pointing the /etc/localtime symlink at what you want. d) The new format does not require a bash interpreter to be read > > 4.d) I think this is a terrible justification. A programming language > embedded in a configuration system grants a lot of possibilities. It also makes it impossible to reason about. Or to parse from another language than what it was defined in. > Also there is a sound way to read configuration files written in a > programming language - simply evaluate the code. But there is no sound way to then change the options and write them back. > In any case, to preserve compatibility with systemd, the new files > (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not > contain bash. These files can all be read by bash, but are strictly defined. This means we can know their format and update them in a sound way. > 5) With the plethora of changes, each for different reasons, I think > there is justifcation for a comprehensive news item summarizing > changes to each variable: > LOCALE -> /etc/locale.conf > HARDWARECLOCK -> deprecated Sure. > USE_BTRFS -> esoteric, removed for cosmetic reasons Won't kill this one, but I get your point. -t
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Okay, time to drop my 0.02¢ as well. And I'm pretty sure everything said here in this mail has been said elsewhere as well, but hey... ;) ArchLinux tries to be as KISS as possible. That's true. And I think, it does a pretty good job at that. And switching to systemd with a couple of config-files instead of one rc.conf might seem like a huge step away from this principle, but in fact it ain't. What is rc.conf used for right now anyway? Most of the settings in the rc.conf are set during setup and not changed afterwards. I mean, who changes his locale or his hostname? Then there are deamons, it's really nice to have an array where you enter a name for a startup service and this array is used to start services fifo. Great. But as far as I saw, systemd provides a simple command to add services and the like. And since it works for services, mountpoints and sockets alike, it provides a good and coherent way to work with a lot of your system-admin things... I like that. So.. in my point of view, it's not such a bad thing that rc.conf gets replaced by a couple of other files and a nice cli-interface. For you this change might be a reason to switch to Fedora, you say. I mean, seriously? How is it all handled in Fedora then? Well, I don't now, actually. But I get kinda offended by neglecting the features that ArchLinux really make the best linux distro out there imho: - It's a rolling release distro: You only have to carefully do pacman -Syu to keep your system up-to-date. I started using Linux with Ubuntu and first I really looked forward to a new release, I mean new features, new artwork and all that stuff. But distupgrade nearly always failed and so I re-installed my system every six months. This is not good! With ArchLinux I can spent way more time just using my system instead of playing admin. - It has pacman: Pacman really is KISS. It does its job and it does it really, really good. It's fast and quite simple to use and to configure. - It has PKGBUILD: If you want compile a package due to some patches or extra settings (by using ABS) or if you want to install a package that is not in the official repos, you have to work with PKGBUILD and makepkg. The first being a really nice and easy to grasp file you can read and understand and configure to your own desires, the second being a tool to download the desired software, take care of dependencies and compiling the software. This is just dead-simple and great. KISS again, through and through. - Mentioned a lot of times: the community, the wiki and the mailinglist, the channel. All of them are excellent and outstanding. Well, That's why I am staying with ArchLinux, that's why I came back after enjoying Gentoo for quite a while, that's why I recommend it to people asking me with which Linux they should go. Maybe you really switch to Fedora due to rc.conf losing it's job a little, maybe you just did a great job trolling the list, I'm glad to write down why I really like ArchLinux :) 1126 On Sun, 22. Jul 06:59, fredbezies wrote: > > text added by mvmf mail filter > > mvmda: regcomp failed. > mvmda: regcomp failed. > mvmda: regcomp failed. > > > end of text added by mvmf mail filter > > > Hello. > > I've read all the arguments of Tom and Ionut. Here is my own $0.02 on > it. When I started using archlinux back in end of 2008, the winning > point was this file. A centralized one where you can set up a lot of > single options. > > It is *far* simpler to edit /etc/rc.conf to load daemons or modules > than editing 2 or 3 files. > > "Killing" /etc/rc.conf can't be do so soon. Or you'll see a lot of old > users moving their on other distributions. For me it will be a one way > ticket to fedora. And I *do hate* this idea. > > But developpers must know better than users what is the best for the > distro. Killing /etc/rc.conf ? Why not. But for me, it is more KISS > oriented than /etc/locale.conf, /etc/vconsole.conf, > /etc/modprobe.d/*.conf files. > > As I said, it is my $0.02. Excuse my bad english, I'm no really awake ! > > -- > Frederic Bezies > fredbez...@gmail.com
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Fons Adriaensen wrote: >Please tell me why you think > I need it. Mount usb keys as a normal user ? So, you're more aware of some benefits than what you stated before. > I can arrange > that without ck. So, requiring that someone has to "arrange" things is not the choice done by upstream. Does it have to do with Arch? No. Precisely _because_ Arch wants itself to KISS. > that without ck. Change ownership of some things to a > 'local' login ? I don't want that to happen. You're free to fight again changes or improvements. The simplest way I know consist in installing a 70th year old system and don't update it. -- Nicolas Sebrecht
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, Jul 23, 2012 at 10:30:37AM +0200, Nicolas Sebrecht wrote: > The 22/07/12, Fons Adriaensen wrote: > > > Simple example: I didn't have consolekit for some years, and I don't > > care about whatever it has to offer. > > ...This may be why you don't understand benefits of such tools... If you could point out the benefits it could have for me please do. Until some recent xdm update I didn't have ck, and everything worked exactly as I wanted it. That is still the case, so at best ck is useless for me, it just eats recources. > ...and why you think it's only comsuming resources. So what else is it doing ? Please tell me why you think I need it. Mount usb keys as a normal user ? I can arrange that without ck. Change ownership of some things to a 'local' login ? I don't want that to happen. Anything else ? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Heiko Baums wrote: > Am Mon, 23 Jul 2012 09:36:05 +0200 > schrieb Nicolas Sebrecht : > > 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. I think we are not talking about the same thing. I'm talking about merging tools. I don't know of any merging tool on earth doing the choice of patching whithout asking for conflict resolution from the user. > 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. No, no. Even without merging tool, 3 or 5 files instead of one is not time consuming. What is time consuming is a system strongly damaged because of human mistake in a configuration file, more likely to happen with a one-central-configuration-file-for-non-related-things-around. > One single /etc/rc.conf is a bit more KISS. One single rc.conf is not KISS. :-) I think this principle is mainly misunderstood. KISS principle makes sense for integration from upstream. It's definetly NOT about "how simple it looks like". -- Nicolas Sebrecht
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 : > 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] Arch's move to systemd integration
On Sunday 22 Jul 2012 15:14:13 Myra Nelson wrote: > My comparison to file size was meant to be extended to the complete > removal of rc.d and conf.d or the removal of several files in those > directories. Maybe that concept is not that important. I didn't mean > to imply the KISS principle was about size, just trying to imply this > change doesn't necessarily violate that principle. When I read about file sizes, my immediate thought was that it's being used as a metric for simplicity of configuration. Did noone else think this? If the configuration file sizes are small, this might indicate that it won't be a nightmare to configure. > My main argument > was "If I can get this done anyone can. It's not that much different, > it's just different". It appears to me to be just as portable as the > current setup and it might just save the Devs some time, and provide > better integration with upstream devs. Another salient point is just > because it's been done that way since Moses was a baby doesn't make it > right. Sorry if I offend anyone. Thank you for sharing this Myra; I think this is a helpful argument. The lesson seems to be: systemd is not difficult to use; it's just new, shiny, and different. Don't be scared of it. As for me, I haven't made the switch yet mainly because I haven't had the time to look into it properly. Paul
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Fons Adriaensen wrote: > Simple example: I didn't have consolekit for some years, and I don't > care about whatever it has to offer. ...This may be why you don't understand benefits of such tools... >So far it hasn't done anything evil except being useless and > consuming system resources (50 or so threads). ...and why you think it's only comsuming resources. >Same about polkit Erf! Same causes, same consequences? Do you really think upstream developers are all doing the bad choices in order to make you feel less compliant with the so-loved historical Unix philosophy? Come'on guys. You can't make serious argumentation wihout making a bit of expected normal researches or by starting in the /same/ mail "I don't care about whatever it has to offer". Upstream choices is not about feelings. -- Nicolas Sebrecht
Re: [arch-general] Upcoming changes to virtualbox
Sébastien Luttringer on Mon, 2012/07/23 03:04:
> On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch wrote:
> > Are there systemd unit files for this?
>
> Not yet. Patch welcomed.
There are, please take a look at AUR package dkms-systemd.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Shridhar Daithankar wrote: > > I was on systemd once, about an year back.. just to find out first-hand, what > the hoopla is all about. It worked, no fuss but nothing great over current > initscripts for a typical developer workstation/desktop. > > However one fine day, an abrupt power-cut later, my home partition was no > longer mountable under systemd. Initscripts worked fine. So I switched back.. > didn't miss a thing.. You're wrong. SysV init scripts _are_ broken, today. But it's silently failing without even noticing it to users in many cases. Finding such boot errors is painfull and time consuming. > -- Nicolas Sebrecht
[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 22/07/12, Heiko Baums wrote: > 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. Sounds like you (don't take this a personal critism, you're not alone) have poor 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). Who is manually editing each configuration one after the other need lessons on administration tasks. If merging tools are not good enough, then let's improve them. But please all, don't make a shoot on current changes. What Tom is doing is exactly what most of ArchLinux users expect. And the philosophy, KISS principle or whatever theory that you think is good in Archlinux is not beeing broken at all. -- Nicolas Sebrecht
