View previous topic :: View next topic |
Author |
Message |
cach0rr0 Bodhisattva
Joined: 13 Nov 2008 Posts: 4123 Location: Houston, Republic of Texas
|
Posted: Tue Nov 29, 2011 8:51 pm Post subject: |
|
|
Dr.Willy wrote: |
How is that a problem? How is that even annoying? |
...seriously? |
|
Back to top |
|
|
Dr.Willy Guru
Joined: 15 Jul 2007 Posts: 547 Location: NRW, Germany
|
Posted: Tue Nov 29, 2011 9:39 pm Post subject: |
|
|
cach0rr0 wrote: | ...seriously? |
Yes. Seriously.
If you want to find out why, I suggest you read the rest of the posting. |
|
Back to top |
|
|
cach0rr0 Bodhisattva
Joined: 13 Nov 2008 Posts: 4123 Location: Houston, Republic of Texas
|
Posted: Tue Nov 29, 2011 10:17 pm Post subject: |
|
|
Dr.Willy wrote: |
Yes. Seriously.
If you want to find out why, I suggest you read the rest of the posting. |
i read the rest of that post
i read all of your next post
and im still having trouble seeing how you seriously think it's *just* DE maintainers jumping the shark in depending on these new *kits
remember when even X itself was dependent on HAL? Yeah that was a fun one.
We're not even talking about the DE yet, just to get your system unfucked and unHAL'd after Xorg had let HAL get balls-deep in its guts you had to jump through a thousand hoops. You now have to learn your way around HAL just to get rid of HAL and back to square one.
I mean hey we could all just run fancy framebuffer consoles instead of X, but when the pestilence has infected X itself hard to blame the DE devs for adapting to what everyone is telling them is THE standard, that they'll be up a shit creek for not adopting. And when you're a user who's found you cant even run barebones X with a functional keyboard and mouse without HAL running, yeah, sorta hard for that NOT to be annoying. |
|
Back to top |
|
|
mrsteven Veteran
Joined: 04 Jul 2003 Posts: 1938
|
Posted: Tue Nov 29, 2011 11:31 pm Post subject: |
|
|
As I said before, I don't want to switch to another init system, just because my desktop environment, window manager or whatever depends on a feature (let's say session management), that does not really have to be in the init system. As we know, init is the root of the process tree in Unix, so it is absolutely necessary that this piece of software is rock-solid (the Linux kernel even panics if it has to kill init for some reason). I really doubt that systemd can give me that level of stability.
And now, to put this "systemd does everything" mentality even further, they also want to include a logger with some - well weird format. No, I don't need a new logger, but at some point my desktop environment might need systemd and thus forces me to use the systemd logger as well. And in the next steps systemd might include a cron replacement, a new fstab format (Hey, why not use XML? Should be shitty enough to read...)... Okay, let's stop here, I don't want to provide the systemd guys with another bunch of crappy ideas.
To put it short: Basic system services should be as simple as possible. At upper layers you can add complexity, but not at services that are absolutely necessary to get the machine running. _________________ Unix philosophy: "Do one thing and do it well."
systemd: "Do everything and do it wrong." |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
Posted: Tue Nov 29, 2011 11:48 pm Post subject: |
|
|
cach0rr0 wrote: | and im still having trouble seeing how you seriously think it's *just* DE maintainers jumping the shark in depending on these new *kits
remember when even X itself was dependent on HAL? Yeah that was a fun one. |
No I don't. It always had the "hal" flag, and I kept it disabled _________________ “And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010 |
|
Back to top |
|
|
cach0rr0 Bodhisattva
Joined: 13 Nov 2008 Posts: 4123 Location: Houston, Republic of Texas
|
Posted: Wed Nov 30, 2011 12:47 am Post subject: |
|
|
Etal wrote: |
No I don't. It always had the "hal" flag, and I kept it disabled |
worked fine for 1.6
butttt then came 1.7 _________________ Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
Posted: Wed Nov 30, 2011 1:14 am Post subject: |
|
|
cach0rr0 wrote: | Etal wrote: |
No I don't. It always had the "hal" flag, and I kept it disabled |
worked fine for 1.6
butttt then came 1.7 |
What happened in 1.7? _________________ “And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010 |
|
Back to top |
|
|
cach0rr0 Bodhisattva
Joined: 13 Nov 2008 Posts: 4123 Location: Houston, Republic of Texas
|
Posted: Wed Nov 30, 2011 1:30 am Post subject: |
|
|
Etal wrote: |
What happened in 1.7? |
from what i remember, you could more or less live without HAL in 1.6
with 1.7 it became "you're going to lose a limb removing HAL", you had to do all of the "AutoAddDevice False" nonsense in xorg.conf, big hassle
by 1.8 we were already on to udev _________________ Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
Back to top |
|
|
Dr.Willy Guru
Joined: 15 Jul 2007 Posts: 547 Location: NRW, Germany
|
Posted: Wed Nov 30, 2011 10:51 am Post subject: |
|
|
cach0rr0 wrote: | im still having trouble seeing how you seriously think it's *just* DE maintainers jumping the shark in depending on these new *kits
remember when even X itself was dependent on HAL? Yeah that was a fun one. |
Well, you raise a valid point. X is the only player on the field so if X leads, the rest must follow. Also at that time it wasn't so sure that HAL wasn't there to stay, so from a DE maintainer's point of view you might aswell migrate.
However, the release->deprecation cycle is now going into it third iteration, one would think that by now everyone knows what's going on. Especially since, unlike HAL, neither of the other *kits has anything to do with X.
mrsteven wrote: | I really doubt that systemd can give me that level of stability. | FUD
Other than that, yeah, if you don't agree with your DE's decisions, don't use that DE.
cach0rr0 wrote: | Etal wrote: |
What happened in 1.7? |
from what i remember, you could more or less live without HAL in 1.6
with 1.7 it became "you're going to lose a limb removing HAL", you had to do all of the "AutoAddDevice False" nonsense in xorg.conf, big hassle
by 1.8 we were already on to udev |
Interestingly there are migration guides for 1.5->1.6, 1.7->1.8, 1.8->1.9 but none for 1.6 -> 1.7. Odd.
Anyway, HAL was optional before and was not required after. Also in the process the X devs removed the need for an xorg.conf entirely which had you jump through various hoops aswell, so you might argue they had the right idea in general, just going for HAL specifically was wrong.
So how does that bring us back to our DE devs?
Well, either these *kits provide them with something they need and can't find elsewhere in which case there isn't much to complain about OR they are just being dumb. |
|
Back to top |
|
|
aidanjt Veteran
Joined: 20 Feb 2005 Posts: 1118 Location: Rep. of Ireland
|
Posted: Wed Nov 30, 2011 11:34 am Post subject: |
|
|
They're just being dumb. _________________
juniper wrote: | you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault. |
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Nov 30, 2011 9:57 pm Post subject: |
|
|
Quote: | Well, either these *kits provide them with something they need and can't find elsewhere |
They provide an enormous framework for running specific programs as root with NTFS-esque access control lists, and can make completely random guesses as to whether you should have access to things like the sound card, by reinventing identd in a half-arsed and broken way. That's all.
50% of what they're actually used for is functionality already provided by tiny setuid binaries — or more securely, normal binaries with setcap(8) privileges added, client-server programs over a socket, or simply sudo — things like mounting a disk (use pmount or /etc/fstab) or shutting down the system (Xfce used to do this sanely using sudo and a helper binary) or handling various hardware things (acpid will keep working even when the fragile, bloated, enterprise-framework-enabled desktop that's supposed to be managing your battery power crashes yet again...)
The other 50% is emulating Windows UAC. Conditioning users to click "next" unconsciously is a great way to make Linux more secure.~ |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2283 Location: Adendorf, Germany
|
Posted: Fri Dec 02, 2011 2:18 pm Post subject: |
|
|
First of all I do agree that it is not ... ah... convenient to have changing sub-systems (and sub-sub-systems) forced down our throats as end-users. But this one caught my Eye: Dr.Willy wrote: | …but I still don't care. Why? Because:
Code: | root@xps drwilly # find /var/db/pkg/sys-* -name "*kit" -o -name upower -o -name udisks
root@xps drwilly # |
| *hemhem* Code: | sed-notebook ~ # find /var/db/pkg/sys-* -name "*kit" -o -name upower -o -name udisks
sed-notebook ~ # eix -c -I -C sys-* "(udisk|upower|kit)"
[I] sys-auth/consolekit (0.4.5-r1@14.08.2011): Framework for defining and tracking users, login sessions and seats.
[I] sys-auth/polkit (0.102@27.09.2011): Policy framework for controlling privileges for system-wide services
[I] sys-auth/polkit-kde-agent (0.99.0(4)@27.09.2011): PolKit agent module for KDE.
[I] sys-auth/polkit-qt (0.99.0@27.09.2011): PolicyKit Qt4 API wrapper library.
[I] sys-fs/udisks (1.0.4-r1@09.10.2011): Daemon providing interfaces to work with storage devices
[I] sys-power/upower (0.9.13-r1@09.10.2011): D-Bus abstraction for enumerating power devices and querying history and statistics
6 Treffer. | /var/db/pkg is not a reliable source of information if you leave out the version information. The command should have read: Code: | sed-notebook ~ # find /var/db/pkg/sys-* -maxdepth 1 -name "*kit*" -o -name "upower*" -o -name "udisks*"
/var/db/pkg/sys-auth/polkit-0.102
/var/db/pkg/sys-auth/polkit-qt-0.99.0
/var/db/pkg/sys-auth/polkit-kde-agent-0.99.0
/var/db/pkg/sys-auth/consolekit-0.4.5-r1
/var/db/pkg/sys-fs/udisks-1.0.4-r1
/var/db/pkg/sys-power/upower-0.9.13-r1 | But before you jump down my throat, I am convinced that everybody understood that you simply wanted to show that you haven't had any of those installed. Ant P. wrote: | The other 50% is emulating Windows UAC. Conditioning users to click "next" unconsciously is a great way to make Linux more secure.~ | No, but it helps Ubuntu raising their user count. _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Dec 17, 2011 5:29 pm Post subject: |
|
|
aidanjt wrote: | all privilege escalation should have been done as it has always been done, with su/sudo, and login/out should be dealt with by PAM and the environment. My only regret for consolekit getting killed off is systemd is going to replace it |
I am really not up for systemd; I appreciate that Gentoo devs are going to keep consolekit around, but I'm wondering:
What would it take to have KDE running without consolekit or anything else, just the old standard Unix stuff?
After all it runs on BSD etc without this kind of stuff (though I did read BSD provides a hal API.) I'm just thinking there must be portability configuration that would allow us to build KDE (or another desktop) the way we want it. I'll deal with udev since upstream kernel insists on it, but I don't want any of this other stuff: just basic Unix pam logins, no ACL, no capabilities and most of all none of this crap that's been half-implemented then dumped for the next great thing over the last 5 or 6 years, for desktops that only get used by 4 people.
I'm happy to help with coding etc if others have an idea of how this can be done. |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
Posted: Sat Dec 17, 2011 10:51 pm Post subject: |
|
|
steveL wrote: | What would it take to have KDE running without consolekit or anything else, just the old standard Unix stuff? |
It was definitely possible about a year and a half ago (before I jumped ship to Xfce as the desktop, now I just use KDE applications), and from looking now, you can build plasma-workspace without them just fine. You have to globally disable policykit and consolekit, and for kdelibs, disable udisks/upower. Of course, device notifier, battery monitor, K3b, etc., wouldn't work. _________________ “And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010 |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Dec 18, 2011 2:51 pm Post subject: |
|
|
Hmm thanks Etal. Not sure I'd like to live without K3b. It's a shame we can't get those devices (and udisk/upower) working with just udev. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Dec 18, 2011 5:33 pm Post subject: |
|
|
Does K3b have some feature you can't get anywhere else? You only need to run `wodim $file.iso` as a user in the cdrom group to burn images, and I'd be surprised if there weren't other GUI programs that can create iso9660s. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|