On Thu, 27 Oct 2011 10:09:48 +0200 Karol Blazewicz wrote:

On Thu, Oct 27, 2011 at 9:49 AM, Mick wrote:

...

Is there some way to be fore-warned of these updates coming online and avoid them or be ready with clear info on how to repair the damage they are set to create.

mick

Read the mailing list.

I have just scanned the last 18 months of arch-general and arch-announce list archives and found nothing that looked even vaguely like "if you install this-package-update you will remove the ability to mount your USB stick" or "this update will prevent you from rebooting from within xfce" next idea mick

On 27-10-2011 17:24, Jesse Juhani Jaara wrote:

On Fri, Oct 28, 2011 at 01:43:11AM +1000, Mick wrote:

...

On Thu, 27 Oct 2011 10:09:48 +0200 Karol Blazewicz wrote:

I have just scanned the last 18 months of arch-general and arch-announce list archives and found nothing that looked even vaguely like "if you install this-package-update you will remove the ability to mount your USB stick" or "this update will prevent you from rebooting from within xfce"

next idea

mick

You wont have any problems if you are using a proper login manager or have "exec ck-launc-session dbus-launch startxfce" in ya .xinitrc ^^

You only need 'exec ck-launch-session startxfce4' in .xinitrc because startxfce4 will call dbus-launch itself. And yes, I'm using xfce and everything works just fine, I don't use any login manager though, don't see the need for it :p -- Mauro Santos

On 10/27/2011 04:15 AM, Heiko Baums wrote:

Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick:

...

Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.

Remove ck-launch-session from your ~/.xinitrc again.

Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues.

Is that true? I don't see it in the Arch announcements (also shown as news on the website), which I would hope it would be if it was a newly required change. (Also I last updated two days ago, still am using "exec ck-launch-session startxfce4", and haven't noticed anything being broken. Of course, I manually mounted my USB sticks with "sudo mount" anyway so I might not have noticed...) ~isaac

On Thu, 27 Oct 2011 10:15:32 +0200 Heiko Baums wrote:

Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick :

...

Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether.

Remove ck-launch-session from your ~/.xinitrc again.

Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues.

Heiko

made the change but it didn't work, if I can't find what they butchered this time before the night freight train to Cairns grinds past in half an hour I'll give up and re-install tomorrow. mick

On (10/27/11 18:48), Manolo Martínez wrote: -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > linux system you only have to be a member of 1 group: users. -~> -~> And wheel? Wheel has to done manually, of course. What *kit does, in a nutshell, is just elevate priviledges of local users over remote, so you can have control over devices attached to your machine. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On (10/27/11 21:34), Manolo Martínez wrote: -~> On 10/27/11 at 12:25pm, Leonid Isaev wrote: -~> > On (10/27/11 18:48), Manolo Martínez wrote: -~> > -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: -~> > -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > -~> > linux system you only have to be a member of 1 group: users. -~> > -~> -~> > -~> And wheel? -~> > -~> > Wheel has to done manually, of course. What *kit does, in a nutshell, is just -~> > elevate priviledges of local users over remote, so you can have control over -~> > devices attached to your machine. -~> > -- -~> Should this be added to the Beginners' Guide at the wiki? I'm thinking of -~> something ecumenical along the lines of "do it the usergroup way, or you may -~> consider adding yourself to users and wheel and allow *kit to take care of the -~> rest by launching your wm under a *kit-session. -~> -~> Manolo -~> -~> -~> -~> -- Well, there is a (probably outdated) section "Groups" at https://wiki.archlinux.org/index.php/Users_and_Groups, which can hold this note. But I completely miss the appeal of the wheel group. If you want root use su -, otherwise why do you need special priveledges? I would say, don't even mention it. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On 27-10-2011 17:48, Manolo Martínez wrote:

On 10/27/11 at 11:24am, Leonid Isaev wrote:

...

you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.

And wheel?

And video, uucp, kvm, just to name a few. -- Mauro Santos

On 27-10-2011 19:59, Leonid Isaev wrote:

Fine: s/modern linux system/modern linux desktop system/. But, are you sure you understand the difference between local and remote users?

According to the documentation, local users are the ones that have access to a physical keyboard, mouse and display. I can see the benefits of not granting full privileges to a remotely connected user, but that's not what I was on about.

In fact, you don't need to be a member of video (at least my webcam works fine). Kvm is useful, but I wouldn't be surprised if in fedora 16 (and then in all other distros), kvm would be managed by ck as well.

Webcam also works fine here without me being in video group, must have been a leftover before *kit took care of it, I stand corrected on that one. The others still stand and the thing is you can't be only part of the users group and do everything, in time maybe you can but right now you can't. -- Mauro Santos

On 10/27/2011 12:14 PM, Martti Kühne wrote:

On Thu, Oct 27, 2011 at 6:24 PM, Leonid Isaev wrote:

...

OK, which update you are talking about?

Shutdown problems probably come from upower. Your user would loose control of external devices only if you were in the storage/disk groups. Adding youself to these groups was your mistake, since unless you understand what you are doing, you should let console-kit do the permission granting. In fact, on a modern linux system you only have to be a member of 1 group: users.

How do you start your desktop and do you have ck-launch-session running?

Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again.

the sources of error are likely not a thin smear of software that, imo, makes the entire experience much better and enables fine-grained access control ... i mean group perms are nice and all, but they are incredibly coarse, and over the years have forced all sorts of odd/convoluted application hierarchies + access patterns to cope. unfortunately, error sources are probably human, ie. stuff isn't being launched/ran/used properly. the stack is layers -- i for one think the linux experience has improved 1000 fold over the last few years alone -- and we continue to demand more, albeit indirectly at times.

Also reminds me of this morning's xorg-xdm bug report I wrote which made dbus on a system level necessary, all of a sudden... Things go on like this and I'll remove my Xorg and run frambuffer only from now on. :-)

doubtful ;-). im a professional sysadmin too ATM (though, i'm traditionally an applications developer, and am trying my hand at larger scale administration), and honestly, i'd like to see dbus and other tools that enhance discovery/transparency/communication/free-time embed themselves like a tick in everything possible. this idea of actually *wanting* to micromanage everything makes me shudder ... yuck ... the cleanest fastest version with a healthy scoop of Just Works beats uber-unnecessary flexibility any day in my book. there are more interesting problems to solve than helping my computer be a computer. -- C Anthony Risinger

On Fri, Oct 28, 2011 at 11:02 AM, Mick wrote:

On Thu, 27 Oct 2011 12:30:50 -0500 C Anthony Risinger wrote:

...

the sources of error are likely not a thin smear of software that, imo, makes the entire experience much better and enables fine-grained access control ... i mean group perms are nice and all, but they are incredibly coarse, and over the years have forced all sorts of odd/convoluted application hierarchies + access patterns to cope.

unfortunately, error sources are probably human, ie. stuff isn't being launched/ran/used properly.

Its not easy for the user to keep up-to-date with the stream of changes that pour in until one day you update and a deprecated method is busted.

A thought that just occurred to me is for these kind of updates to be segregated so that you can see them and research the procedures needed to implement them safely.

Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated? The devs run the software, by the time it gets to [testing] it has passed through their machines without (visibly) breaking anything, by the time it gets to [core]/[extra] it has passed through the machines of whoever runs [testing]. If a system breaks because of an update in [core]/[extra], its because the system differs from all the previous machines in its hardware and/or software. To summarize, if your answer to 'what package broke it?' is simply 'I don't know, too many packages got updated at one time' then there's no real possible solution to this problem.

My primary desire for updates is for: 1.) security fixes 2.) bug fixes

I don't need to update for new features unless its a feature I need,

Well we dont do backporting so it is FIXES+FEATURES or nothing. Cherrypicking updates is no sollution, as soname bumps are reality.

can clear any of the remaining suspects please do. mick

This particular set of problems is caused by the udev update, wich told you everything you need to know after it had been updated. Update frequently atleast once a week. Take care of any pacnew files and follow the instructions on install messages.

On 2011-10-27 11:14 PM, Mick wrote:

My primary desire for updates is for: 1.) security fixes 2.) bug fixes

I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems.

The fact that these particular issues keep on occurring, not only to me, and there seems to be no consistency in the solution suggest to me that something needs to be done, maybe just clearer docs.

I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.

You should try a different distro, like Debian maybe. Being a rolling-release distro is one of Arch's main selling points, and seems to be completely the opposite of what you want.

On Fri, Oct 28, 2011 at 12:14 AM, Mick wrote:

I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.

I run Arch on production systems. Yikes you might think. However, I run Arch Linux on more than 10 systems, and about 6 or 7 of those are at work. I've been running Arch since 2007 and used it for several months at home before using it at work. I update non-critical systems first, but since I update them daily, any breakage is easy to fix, and usually I've gotten a heads up as I track arch-general, arch-announce, arch-releng, and arch-dev-public. I have cron set to automatically download all updates so when I get around to updating, it is fast. The installs I've set up for others they typcially never update, but when I get back with them to help them on something (might even be a few months) I go ahead and update and while the update is taking place I open another terminal and pre-fix any issues. I've not had downtime with Arch, and it is a breeze to update compared to Gentoo, which I ran for a many years before I found Arch. And yes, I'll even update while working on a critical job related issue with a co-worker. I run a very custom installer, and use it to create cookie cutter installs that I already have everything set up the way we need to for our work environment, but of course adding a needing tool or two later is fairly easy. I've not had much success with the official provided installers, I think my pre partitioning and other choices mess it up. I had to fix the boot loader on my first few installs of Arch so I ended up just installing arch gentoo style on subsequent systems. I don't install base anymore, it has several packages I never use. Since the provided installer has only worked for me maybe once or twice, I just use my custom installer, which is much easier anyways for me, as I just change the hostname and default username/pass, change the architecture if need be, and do a make all. I try out he installs first in qemu-kvm for a quick sanity check, then transfer the filesystem images to the target system. Using a custom installer is fast, as I use the cached packages on my host. I have a custom xfce4 desktop setup in /etc/skel, so the install is ready to use. I've run Debian and Ubuntu but fought with package management and custom kernel deployment too much on them so I found Arch much easier to manage. Arch is much simpler than those and so much easier for me to wrap my head around it and fix issues. When I do have a question about something a quick email here about it and it is answered quickly. Most of the time there is no need to ask. All the relevant issues are already being discussed here or in arch-dev-public. All that being said, Arch is certainly not for everyone. But I disagree about it not being production worthy. I have the lts kernel installed on every system, but only the most critical ones use it by default. For any system to be production worthy, you have to be able to maintain it and fix any issues fast that come up. The only real mess up I've had was my fault, not a damaging update from an Arch developer. I mistakenly put an x86_64 bit repo path at the top of the mirrorlists of two i686 boxes and updated them. Yikes. I've since switched to using $arch in the mirrorlists rather than hardcoding the architecture. They were not out of commission long, a boot of the livecd, a quick $(awking) of /var/log/pacman.log in a pacman command line reinstalled the invalid packages and I had working systems back. Ok, the updated networking setup broke some of my systems earlier this year, but it was easy enough to fix. Arch is easy to manage if you insist on having the system set up the way you want it and you want to be on top of every issue. Distros like OpenSUSE, Fedora, Ubuntu, and to a lesser extent Debian are too daunting and confusing to me. Most Linux users I know would not tolerate Arch Linux if they had to install and setup it up themselves. But at the same time I have no real like for the distros they prefer to install and manage for themselves. A rolling update based distro that is mostly minimal and lightweight is not without it's issues and problems. All distros have serious issues and problems, it is mainly a matter of which have the issues/problems that are easiest for you to manage. I may not be the typical Arch user, dunno. Especially since I use joe instead if vi, and was a not amused when joe went to the AUR. But I have a repo for work stuff, so I just put it there so it is ready on new systems. You may have made a mistake when you chose Arch, and I'm not going to disagree with on your reasoning. Arch does have major/serious issues if you don't want to stay on top of things. And being a rolling update distro, you need to stay on top of changes. If you think Arch is bad though as far as damaging updates, you should maybe spend some time to spend some time with Gentoo or Sabayon. One thing though, I use yaourt, so I notice every time a package gets dropped of the main repos and ends up in the aur. Most of the time that is an indication to me that I know longer need that package. So yeah, if you use packages that get orphaned, they might eventually stop working if you had them installed, and one would might blame an update for killing those packages.

On Fri, Oct 28, 2011 at 00:14, Mick wrote:

On Fri, 28 Oct 2011 11:34:50 +0800 Oon-Ee Ng wrote:

...

Am I the only one reading this thread who sees the inherent contradiction of wanting complete control over your system, wanting things not to break, yet wanting software to be (relatively frequently) updated?

All I'm asking for is a way to cope with the REGULAR breaking of a few functions by updates. Unless I have missed something in the pacman docs there is no way I can conveniently pick and choose which updates to install, I can only install either all or none of the bundle that pacman offers. Yes I know I can exclude packages via pacman.conf but for that I need to be able to isolate the offending package(s).

My primary desire for updates is for: 1.) security fixes 2.) bug fixes

I don't need to update for new features unless its a feature I need, in which case I am happy to chase it myself and expect problems.

The fact that these particular issues keep on occurring, not only to me, and there seems to be no consistency in the solution suggest to me that something needs to be done, maybe just clearer docs.

I did make a mistake when I chose Arch. I asked friends on yahoo chat for suggestions for a replacement my then distro when it focused on eye-candy to the detriment of function and several suggested Arch. It was only when the problems I raised here struck the first time that I found Arch made no pretensions to being fit for production. By that time I had come to like most of what Arch is.

...

To summarize, if your answer to 'what package broke it?' is simply 'I don't know, too many packages got updated at one time' then there's no real possible solution to this problem. going back to the pacman log I could narrow it down to one of: synchronizing package lists starting full system upgrade upgraded glib2 (2.28.8-1 -> 2.30.0-1) upgraded gdl (3.0.2-1 -> 3.2.0-1) upgraded libsasl (2.1.23-7 -> 2.1.23-8) upgraded libldap (2.4.26-3 -> 2.4.26-4) upgraded coreutils (8.13-2 -> 8.14-1) upgraded filesystem (2011.08-1 -> 2011.10-1) upgraded dbus-core (1.4.14-1 -> 1.4.16-1) upgraded dbus-glib (0.94-2 -> 0.98-1) upgraded gconf (2.32.4-1 -> 3.2.0-1) upgraded nettle (2.2-1 -> 2.4-1) upgraded gnutls (3.0.3-1 -> 3.0.4-2) upgraded gsettings-desktop-schemas (3.0.1-2 -> 3.2.0-1) upgraded glib-networking (2.28.7-5 -> 2.30.0-1) upgraded libsoup (2.34.3-1 -> 2.36.0-1) upgraded libwebkit3 (1.4.3-1 -> 1.6.1-1) installed json-glib (0.14.0-1) upgraded libgnome-keyring (3.0.3-1 -> 3.2.0-1) upgraded libgda (4.2.9-1 -> 4.99.4-1) upgraded vala (0.12.1-1 -> 0.14.0-1) upgraded dbus (1.4.14-1 -> 1.4.16-1) upgraded dconf (0.8.0-1 -> 0.10.0-1) upgraded exiv2 (0.21.1-2 -> 0.22-1) upgraded x264 (20110617-1 -> 20111001-1) upgraded gobject-introspection (0.10.8-1 -> 1.30.0-1) upgraded libpeas (1.0.0-1 -> 1.2.0-1) installed pygobject-devel (3.0.1-1) installed python2-gobject (3.0.1-1) upgraded glibmm (2.28.2-1 -> 2.30.0-1) installed libgdu (3.0.2-2) installed libcap-ng (0.6.6-1) upgraded python2-egg (2.25.3-10 -> 2.25.3-11) upgraded python2-gksu2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkhtml2 (2.25.3-10 -> 2.25.3-11) upgraded python2-gtkspell (2.25.3-10 -> 2.25.3-11) upgraded gnome-python-extras (2.25.3-10 -> 2.25.3-11) upgraded python2-bsddb (5.2.0-1 -> 5.2.0-2) upgraded libsoup-gnome (2.34.3-1 -> 2.36.0-1) upgraded gvfs (1.8.2-1 -> 1.10.0-2) upgraded strigi (0.7.5-4 -> 0.7.6-1) upgraded krb5 (1.9.1-3 -> 1.9.1-4) installed libplist (1.4-1) installed usbmuxd (1.0.7-2) installed libimobiledevice (1.1.1-2) upgraded upower (0.9.12-1 -> 0.9.14-1) upgraded libcanberra (0.28-1 -> 0.28-2) installed lib32-libffi (3.0.10-1) upgraded lib32-glib2 (2.28.8-1 -> 2.30.0-1) upgraded lib32-ncurses (5.7-6 -> 5.9-1) upgraded lib32-openssl (1.0.0.e-1 -> 1.0.0.e-2) upgraded libass (0.9.13-1 -> 0.10.0-1) upgraded libburn (1.1.4-1 -> 1.1.6-1) upgraded libgweather (3.0.2-1 -> 3.2.0-1) upgraded libisofs (1.1.4-1 -> 1.1.6-1) installed json-c (0.9-1) upgraded libpulse (0.9.23-1 -> 1.0-3) upgraded libwebkit (1.4.3-1 -> 1.6.1-1) upgraded mkinitcpio (0.7.2-1 -> 0.7.4-1) upgraded linux (3.0.4-1 -> 3.0.6-2) upgraded mpfr (3.0.1.p4-2 -> 3.1.0.p1-1) upgraded mtr (0.80-2 -> 0.81-1) upgraded net-tools (1.60-18 -> 1.60.20110819cvs-1) upgraded pygobject2-devel (2.28.6-1 -> 2.28.6-4) upgraded python2-gobject2 (2.28.6-1 -> 2.28.6-4) upgraded python2-pyenchant (1.6.3-5 -> 1.6.5-1) upgraded python-nose (1.0.0-4 -> 1.1.2-2) upgraded tumbler (0.1.22-1 -> 0.1.22-2) upgraded xfce4-settings (4.8.2-1 -> 4.8.3-1) upgraded xorg-xinit (1.3.0-3 -> 1.3.1-1) upgraded xfce-utils (4.8.2-1 -> 4.8.3-1) upgraded xfwm4 (4.8.1-1 -> 4.8.2-1)

the other 200ish packages I'm confident were not responsible. If anyone can clear any of the remaining suspects please do.

The point I was trying to make when I started this thread was that there are a small group of features frequently being broken for a not insignificant number of users and if packages that could be doing the damage where set to require a more assertive update process they could be deferred until users have time to get it right life would be sweeter.

mick

Mick Since some of your loss was usb mounting etc, you may have missed a package to consider [udev]. [2011-10-19 22:39] ATTENTION UDEV: [2011-10-19 22:39] ---------- [2011-10-19 22:39] We now use upstream rules for assigning devices to the 'disk', 'optical', [2011-10-19 22:39] 'scanner' and 'video' groups. Beware of any changes. [2011-10-19 22:39] -- [2011-10-19 22:39] We no longer create symlinks from /dev/<dev> to /dev/<dev>0. [2011-10-19 22:39] -- [2011-10-19 22:39] For security reasons, we no longer add devices to the 'storage' group. Use [2011-10-19 22:39] udisks and friends, or add custom rules to /etc/udev.d/rules/, if you want [2011-10-19 22:39] this functionality back. The message above is from my pacman.log. It clearly notes there were changes made to the way things were handled by udev and those rules were changed to match the "upstream rules". That makes Arch closer to the other distros. There are times when moving closer to upstream causes problems and complaints because it changes/modifies the Arch Way. However the Arch Way of KISS, Keep It Simple Stupid - where I come from, still works the best. About shutting down from the desktop, view this page in the Arch wiki ( https://wiki.archlinux.org/index.php/Allow_Users_to_Shutdown ). It gives different ways to make this work. I have to agree with Oon-Ee Ng, Dwight Schauer and others who make the point about updating. You have to update more often than every three weeks otherwise you're asking for a broken system. I disagree with your statement "I did make a mistake when I chose Arch". You just have to accept not everything is set up to hold ones hand like Debian and its' spawn. With Arch I can fix a broken system without reinstalling. I'm currently running a system where I blew the pacman database away and recovered from it thanks to the Arch Way and the Arch wiki. Dis'ing Arch for these types of errors is just wrong. I've seen plenty of comments around the web about the Arch Wiki being the best place to find information. Please don't complain when the answers you get aren't the ones you want, try to use them to work through your problems. Myra -- Life's fun when your sick and psychotic!

On (10/27/11 19:14), Martti Kühne wrote: -~> On Thu, Oct 27, 2011 at 6:24 PM, Leonid Isaev wrote: -~> > -~> > OK, which update you are talking about? -~> > -~> > Shutdown problems probably come from upower. Your user would loose control of -~> > external devices only if you were in the storage/disk groups. Adding youself to -~> > these groups was your mistake, since unless you understand what you are doing, -~> > you should let console-kit do the permission granting. In fact, on a modern -~> > linux system you only have to be a member of 1 group: users. -~> > -~> > How do you start your desktop and do you have ck-launch-session running? -~> > -~> -~> -~> Personally I'm not using neither gui file browser nor consolekit -~> session and make use of the group based permission because I know how -~> to handle things, and I can look up eventual barriers in my way -~> quickly and reliably enough. I mount usb drives manually and generally -~> lay hands on my system to keep things running, I mean, in a sane way. -~> This is the first time I hear that this way of treating things would -~> be discouraged, and I'm asking myself if this is just a sysadmin's -~> gripe and if it will be possible in the future. Let's say I'm pretty -~> sure it will be possible, since I guess I'm not the only one who -~> avoids these additional sources of errors aka. software layers like -~> ck/dbus/stuff. I left $certain-other-distro for some reason, and don't -~> want to be forced back on this layer cake again. -~> -~> Also reminds me of this morning's xorg-xdm bug report I wrote which -~> made dbus on a system level necessary, all of a sudden... Things go on -~> like this and I'll remove my Xorg and run frambuffer only from now on. -~> :-) -~> -~> cheers! -~> mar77i And how exactly does xfce4 run for you w/o console-kit? And what's wrong with dbus? If you want functionality beyond 1987, you'll have to have software layers: yes or yes. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Personally I'm not using neither gui file browser nor consolekit session and make use of the group based permission because I know how to handle things, and I can look up eventual barriers in my way quickly and reliably enough. I mount usb drives manually and generally lay hands on my system to keep things running, I mean, in a sane way. This is the first time I hear that this way of treating things would be discouraged, and I'm asking myself if this is just a sysadmin's gripe and if it will be possible in the future. Let's say I'm pretty sure it will be possible, since I guess I'm not the only one who avoids these additional sources of errors aka. software layers like ck/dbus/stuff. I left $certain-other-distro for some reason, and don't want to be forced back on this layer cake again.

Since I started using Linux way back in the days of RedHat 5.2 there has been a massive amount of abstraction and obfuscation of even basic functions without easily found and understood (by me at least) explanation and/or how to make it work. Most of this is well done and sneaks past because it just works but there are some cases where substantial, from the end-user perspective, changes to relatively basic functions, like USB sticks, halt/reboot from within GUI. Of course "the Arch way" forbids a simple script within the package to fix these issues. mick

On 2011-10-27 8:24 PM, Mick wrote:

On Thu, 27 Oct 2011 11:24:13 -0500 Leonid Isaev wrote:

...

On (10/27/11 17:49), Mick wrote: -~> Following yet another update that has disabled user control of USB -~> sticks, cameras, etc. and blocked user from shutting down from the -~> desktop (in my case xfce4), I am at the end of my tether. -~> -~> Is there some way to be fore-warned of these updates coming online and -~> avoid them or be ready with clear info on how to repair the damage they -~> are set to create. -~> -~> mick

OK, which update you are talking about? I'm not sure, I usually run pacman -Syu about 3 weeks apart and there are usually many updates to apply. That's part of your problem right there -- Updates go much more smoothly if you apply them in small pieces. The people running [testing] aren't going to wait 3 weeks between running updates, so you shouldn't either.

I do updates every time I get home, which means: * I get them in small pieces, so if something broke, it's obvious what was the cause * It's easy to read any install messages (generally if something is going to break, the install message will tell you what to do to avoid it) * If something big is changing, I'll get the arch announce message that same day (much easier to remember today's announcements than this month's announcements)