[arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
obviously i do NOT want to remove xorg-server. i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either. the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1 thanks -- Arvid Asgaard Technologies
On Tue, 2009-12-01 at 12:43 +0100, Arvid Picciani wrote:
obviously i do NOT want to remove xorg-server.
i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either.
the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1
thanks
What about your own package versions (the ones currently installed)?
Ng Oon-Ee wrote:
On Tue, 2009-12-01 at 12:43 +0100, Arvid Picciani wrote:
obviously i do NOT want to remove xorg-server.
i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either.
the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1
thanks
What about your own package versions (the ones currently installed)?
xorg-server : 1.6.3.901-1 xf86-input-evdev : 2.2.5-something on irc the idea came up that the local versions conflict with the repo versions, hence pacman is confused about the dependencies. i removed evdev, and all the other drivers localy. Which turned out to be a very bad idea. Now i'm left with a half dead system. warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" THAT is the actual problem. It now depends on HAL, which doesn't work. Anyone got a hack available for this? Patch? Maybe it's just a configure option. I'll have to build my own xorg anyway then i guess. *sigh* archlinux vs lfs 0:1 -- Arvid Asgaard Technologies
Arvid Picciani wrote:
warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server"
never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg <3 arch -- Arvid Asgaard Technologies
2009/12/1 Arvid Picciani <aep@exys.org>:
Arvid Picciani wrote:
warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server"
never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg
<3 arch
Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree.
On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
2009/12/1 Arvid Picciani <aep@exys.org>:
Arvid Picciani wrote:
warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server"
never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg
<3 arch
Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree.
Unless his system is fairly old and he hasn't updated in a while. xorg-server depending on hal happened a fairly long time ago, didn't it?
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
2009/12/1 Arvid Picciani <aep@exys.org>:
Arvid Picciani wrote:
warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server"
never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg
<3 arch
Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree.
-Syu
Unless his system is fairly old and he hasn't updated in a while. xorg-server depending on hal happened a fairly long time ago, didn't it?
nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal I guess the new way is better, since it seperates the ubuntu aproach from power user systems in a clean way. If my source is reliable (some dude on irc), X.org will continue to support both versions and seperate them clearly, maybe even with modules. That'd be _nice_! -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 12:45 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
2009/12/1 Arvid Picciani <aep@exys.org>:
Arvid Picciani wrote:
warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server"
never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg
<3 arch
Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree.
-Syu
Unless his system is fairly old and he hasn't updated in a while. xorg-server depending on hal happened a fairly long time ago, didn't it?
nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal
Oh shit, seriously? Looks like I'll have to rebuild this as well. Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage...
I guess the new way is better, since it seperates the ubuntu aproach from power user systems in a clean way. If my source is reliable (some dude on irc), X.org will continue to support both versions and seperate them clearly, maybe even with modules. That'd be _nice_!
Oh a module would be wonderful
Aaron,
Oh shit, seriously? Looks like I'll have to rebuild this as well.
It's your distro. I fail to see the whole reason why you have always been in support of KISS and the arch way, but never seem to take action to enforce it. Maybe it's something social, which i tend to be ignorant towards.
Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage...
Xorg had and still has decent hardware detection. I do have crazy gaming hardware and it isn't correctly detected on ubuntu while it works just fine here on my customized arch without hal ever since X.org. Without any xorg.conf i might add. I'm not going to go as far as claiming the hal/dbus thing is social engineering, but it sure as hell smells like it. However, some chatter on their mailing list suggests it actually has a positive effect for some users, while the negative effect remains undiscovered by the (majority of gnu/linux)~(ubuntu) users.
I guess the new way is better, since it seperates the ubuntu aproach from power user systems in a clean way. If my source is reliable (some dude on irc), X.org will continue to support both versions and seperate them clearly, maybe even with modules. That'd be _nice_!
Oh a module would be wonderful
There is hope. Mostly due to the fact that X is used on embedded systems. Beware though, that argument is fading, as embedded devices get more powerful and users expectations shift from usable to shiny. Even your toaster is going to run kde in the long run. It won't do toasts anymore, but at least it has the latest fashionable widgets. The solution to this political problem is indeed political. Some people can't be educated at all, but the average arch user proves to be capable of learning the basic unix, kiss, and arch philosophies. Back to the point. As long as the X.org upstream is reminded, that the arch/unix/kiss user base is still worth supporting, i'm positive they will continue to support it. In fact we're probably the reason they fixed xft? No one else is using it. I find it hard to argue about the mentioned user base, since its supposed favorite distro archlinux, does in fact add downstream patches to ADD the very features i am opposing. I assume, for now, removing those again via abs is acceptable for most power users, including me and you, until someone finally forks arch. You'd be perfectly suited to throw the first stone, Aaron. -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 2:14 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron,
Oh shit, seriously? Looks like I'll have to rebuild this as well.
It's your distro. I fail to see the whole reason why you have always been in support of KISS and the arch way, but never seem to take action to enforce it. Maybe it's something social, which i tend to be ignorant towards.
Well, I'm not an Xorg authority, nor am I the packager of it. I imagine removing this will have a detrimental effect to all those people using the large monolithic desktop environments, but cannot make a factual claim either way. The point is, just because *I* prefer something one way doesn't mean it's a good decision at the distro level. Jan has always done a good job in the past of keeping Xorg as impartial as possible without breaking things, and I'm assuming he did the same here.
I find it hard to argue about the mentioned user base, since its supposed favorite distro archlinux, does in fact add downstream patches to ADD the very features i am opposing. I assume, for now, removing those again via abs is acceptable for most power users, including me and you, until someone finally forks arch. You'd be perfectly suited to throw the first stone, Aaron.
I'm confused by this. It seems rather standoffish and I'm not sure what you're trying to say here. As I alluded to early, I do not watch each and every single package change that is made. No one has the time for that. That is why we have maintainers we can generally trust about these decisions. Which package has patches to add these features? Looking at xorg-server, I only see one extraneous patch that simple replaces the default grey stipple pattern with black. The rest seem (at a glance) to fix real bugs
Aaron Griffin wrote:
Which package has patches to add these features? Looking at xorg-server, I only see one extraneous patch that simple replaces the default grey stipple pattern with black. The rest seem (at a glance) to fix real bugs
You have a point here, in that i have used a fuzzy description of the problem, in the assumption you and possible other readers remember the numerous rants on this ML. At very least I'd except You to remember your own blog. I'm going to post some hard facts to your convenience. aep@andariel: ~ egrep 'enable|disable|patch -N' /var/abs/extra/xorg-server/PKGBUILD | wc -l 24
Jan has always done a good job in the past of keeping Xorg as impartial as possible without breaking things, and I'm assuming he did the same here.
i was about to state that i didnt target him at all. Then i ran this: aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1); do egrep "enable|disable|patch -N" $i; done) | wc -l 543 Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent" aep@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot <jgc@archlinux.org> and "bias" aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome
/dev/null); then echo $i; fi; done) | wc -l 149
The point is, just because *I* prefer something one way doesn't mean it's a good decision at the distro level.
So there is the name of some guy, who approves the unix philosophy, on this distro, but that guy decides it's a good idea that people who prefer ubuntu make the vital decisions. I claim, You are leading a project whichs developers mainly disprove what You stand for, or claim to stand for. Which is why, ...
You'd be perfectly suited to throw the first stone, Aaron. I'm confused by this. It seems rather standoffish and I'm not sure what you're trying to say here.
.. i have offered my support numerous times. I can see how the daily nuisance of fixing upstream bugs can blur the own goals. Alternatively, You lie about your goals. The very reason, for me to again zombify this minor issue into an open attack, is that you have responded to it, agreeing to the user base you promised to support, but not taken action.
we have maintainers we can generally trust about these decisions.
Your opinions on trust vary, depending on topic. Last time we had this, You promised to kick out tpowa. You didn't. I don't track if the abuse is ongoing, since I maintain all these packages myself now. -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani <aep@exys.org> wrote:
...stuff...
Not sure what just happened here. I thought we were having a legitimate discussion about xorg-server and this ballooned into something crazy. Apparently, you've been holding onto this for some time. If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani <aep@exys.org> wrote:
...stuff...
Not sure what just happened here. I thought we were having a legitimate discussion about xorg-server and this ballooned into something crazy.
You wanted detailed proof, here you are. i doubt you have grasped the essence of it in the 5 minutes you bothered to invest.
Apparently, you've been holding onto this for some time.
for 3 years now. iterating each 6 months.
If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration. -- Arvid Asgaard Technologies
2009/12/1, Arvid Picciani <aep@exys.org>:
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
is this a threat? :-) -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Giovanni Scafora wrote:
2009/12/1, Arvid Picciani <aep@exys.org>:
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
is this a threat? :-)
if patches are lethal, YES :D -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani <aep@exys.org> wrote:
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
Assuming you meant "packages to the tracker that DON'T adhere to the arch way", then that is fine. Assuming of course it isn't just a bug report saying "package foobar doesn't adhere to the arch way". I'd hope there's be some "why" and "how to fix" parts
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani <aep@exys.org> wrote:
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
Assuming you meant "packages to the tracker that DON'T adhere to the arch way", then that is fine. Assuming of course it isn't just a bug report saying "package foobar doesn't adhere to the arch way". I'd hope there's be some "why" and "how to fix" parts
my sentence was stating exactly that, condensed and in inverse order. i was saying, i will post my fixed packages, which i manage downstream anyway. Let me know if this bugformat works for you: http://bugs.archlinux.org/task/17341 -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 5:30 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani <aep@exys.org> wrote:
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
Assuming you meant "packages to the tracker that DON'T adhere to the arch way", then that is fine. Assuming of course it isn't just a bug report saying "package foobar doesn't adhere to the arch way". I'd hope there's be some "why" and "how to fix" parts
my sentence was stating exactly that, condensed and in inverse order. i was saying, i will post my fixed packages, which i manage downstream anyway.
Let me know if this bugformat works for you:
Looks ok to me. Thanks.
On Wed, 2009-12-02 at 00:03 +0100, Arvid Picciani wrote:
Aaron Griffin wrote:
If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
I'm not sure exactly what 'Arch Way' you're referring to here. I fail to see any reference in http://wiki.archlinux.org/index.php/The_Arch_Way to "The Arch Way means choosing against anything developed in the last decade or so which doesn't conform to my idea of minimalism". As I understand it properly, Arch provides a minimalist Base you can then build on (or change as necessary). Build it up in a minimalist manner, fine. Some of us prefer Gnome/KDE, and all the associated 'bloat', and posting up (for example) an xorg-server which would cripple those packages (and probably necessitate xorg-server-hal to compensate) is needlessly complicating things. When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
2009/12/1, Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I totally agree here. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Giovanni Scafora wrote:
2009/12/1, Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I totally agree here.
glad we all agree on that :) i'm about to post packages which work for both of us. They have been stripped of dbus and happen to be the upstream default. -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 5:27 PM, Arvid Picciani <aep@exys.org> wrote:
Giovanni Scafora wrote:
2009/12/1, Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I totally agree here.
glad we all agree on that :) i'm about to post packages which work for both of us. They have been stripped of dbus and happen to be the upstream default.
Oh, I misread the intent previously. I was expecting bug reports of the form "foo is broken, remove X and Y", but you're actually planning on posting new-and-improved PKGBUILDs? It might be nice to include diffs in that case, so it's easier to see what was done on a change-by-change basis.
On 02.12.2009 00:22, Ng Oon-Ee wrote:
On Wed, 2009-12-02 at 00:03 +0100, Arvid Picciani wrote:
Aaron Griffin wrote:
If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
I'm not sure exactly what 'Arch Way' you're referring to here. I fail to see any reference in http://wiki.archlinux.org/index.php/The_Arch_Way to "The Arch Way means choosing against anything developed in the last decade or so which doesn't conform to my idea of minimalism".
As I understand it properly, Arch provides a minimalist Base you can then build on (or change as necessary). Build it up in a minimalist manner, fine. Some of us prefer Gnome/KDE, and all the associated 'bloat', and posting up (for example) an xorg-server which would cripple those packages (and probably necessitate xorg-server-hal to compensate) is needlessly complicating things.
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
Indeed. If anything, the Arch way says "Keep shit simple". Minimalism comes out of this by nature. However, enforced minimalism does more harm than good. Simplicity is the most important guideline of the Arch way. If including HAL or other integral features of other source packages means stuff will get less complicated at a small to no cost, then this should be the preferred way as opposed to enforcing minimalism no matter what. Just my 0.0135€. -- Sven-Hendrik
2009/12/1 Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I've been thinking about this particular part of the "Arch way". I think what causes the conflict in some of these cases is that "trusting upstream" - one of our major principles - only works when upstream is sane. Wacky things (like what freedesktop.org has been doing to Xorg for a while now) make me begin to think this assumption is violated in some important cases. When upstream ceases to really care about Arch-like systems and only support more Ubuntu-like systems, we have a problem with our "don't patch" philosophy.
Ray Kohler wrote:
2009/12/1 Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I've been thinking about this particular part of the "Arch way". I think what causes the conflict in some of these cases is that "trusting upstream" - one of our major principles - only works when upstream is sane. Wacky things (like what freedesktop.org has been doing to Xorg for a while now) make me begin to think this assumption is violated in some important cases. When upstream ceases to really care about Arch-like systems and only support more Ubuntu-like systems, we have a problem with our "don't patch" philosophy.
This implies that you're not ok with what happened to X. So you support my position. What you did not realize, however, is that these things are not upstream defaults. They have been specifically enabled downstream by the arch maintainers. It is likely that the upstream will, as a reaction to my suggestion to reset to upstream defaults, add these options as default. I then suggest to still keep the upstream defaults, and maintain a fixed version of the package on aur. The "sanity" here is very biased, hence there is no non-biased correct solution, other then that suggested by the founder Judd. -- Arvid Asgaard Technologies
On Tue, Dec 1, 2009 at 6:46 PM, Arvid Picciani <aep@exys.org> wrote:
Ray Kohler wrote:
2009/12/1 Ng Oon-Ee <ngoonee@gmail.com>:
When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
I've been thinking about this particular part of the "Arch way". I think what causes the conflict in some of these cases is that "trusting upstream" - one of our major principles - only works when upstream is sane. Wacky things (like what freedesktop.org has been doing to Xorg for a while now) make me begin to think this assumption is violated in some important cases. When upstream ceases to really care about Arch-like systems and only support more Ubuntu-like systems, we have a problem with our "don't patch" philosophy.
This implies that you're not ok with what happened to X. So you support my position. What you did not realize, however, is that these things are not upstream defaults. They have been specifically enabled downstream by the arch maintainers.
Actually, I did notice that. I didn't intend my comments to apply directly to this particular case. I am, however, in support of the particular changes you want for this case, though not strongly enough to get excited about it.
It is likely that the upstream will, as a reaction to my suggestion to reset to upstream defaults, add these options as default. I then suggest to still keep the upstream defaults, and maintain a fixed version of the package on aur.
The "sanity" here is very biased, hence there is no non-biased correct solution, other then that suggested by the founder Judd.
What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.)
Ray Kohler wrote:
What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.)
Indeed. As brought up by others, forcing minimalism is as much violation as forcing bloat. However, arch has been built around the idea that users are capable of customizing packages to non-upstream settings. I urge you to do exactly that. I have posted and will continue to post various bugs to the tracker to restore upstream defaults in favor for minimalism. If these reverts get rejected in favor for bloat, the clear bias is a disregard of the very core ideas of arch, and I will eventually fork arch entirely, given enough support. Either way, i'd welcome if you contribute, in order to get the user experience you (and others including me) desire. That is, either contribute packages to aur, to fix insane upstream defaults, or contribute to an eventual fork to restore upstream defaults. Will you? :) -- Arvid Asgaard Technologies
On Wed, 2009-12-02 at 08:38 +0100, Arvid Picciani wrote:
Ray Kohler wrote:
What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.)
Indeed. As brought up by others, forcing minimalism is as much violation as forcing bloat. However, arch has been built around the idea that users are capable of customizing packages to non-upstream settings. I urge you to do exactly that. Fair enough
I have posted and will continue to post various bugs to the tracker to restore upstream defaults in favor for minimalism. If these reverts get rejected in favor for bloat, the clear bias is a disregard of the very core ideas of arch, and I will eventually fork arch entirely, given enough support. Implying a bias if things do not go the way you want is just a bit of a stretch, don't you think? What's the percentage which would tip you off? 50%? 40%? In the end, the devs make a decision and (if they're nice) explain it, and that should be that.
All this 'fork this fork that' threatening is really quite sad. I know its common in open source and linux in particular, but I certainly don't see threatening a fork and dilution of resources as in an way beneficial to Arch as a distro and to us individually as users.
Either way, i'd welcome if you contribute, in order to get the user experience you (and others including me) desire. That is, either contribute packages to aur, to fix insane upstream defaults, or contribute to an eventual fork to restore upstream defaults. Will you? :)
I see dbus/hal and the rest of this bloat as part of a good user experience. This is a difference in opinion, not a heresy. Having said all that, contributing the appropriate packages to the AUR is a very good initiative. Expand the choice of the user, I know some, maybe many, agree with you on minimalism w.r.t dbus/hal/the like. Forking is ridiculous and non-practical, and it would be better for everyone involved in Arch if its not used as a proverbial hammer to get one's way.
Ng Oon-Ee wrote:
All this 'fork this fork that' threatening is really quite sad.
A fork is not a "threat". It's a suggestion to resolve problems outside the current project politics. I can't see why anyone would be offended by this. I know
its common in open source and linux in particular, but I certainly don't see threatening a fork and dilution of resources as in an way beneficial to Arch as a distro
Me neither. Where did i say that? and to us individually as users. It would be beneficial to the other "us users" which doesnt include you, but me. Which is why i have made suggestions to another user part of this other "us". Not to your "us".
I see dbus/hal and the rest of this bloat as part of a good user experience. This is a difference in opinion, not a heresy.
That's nice for you. You are welcome to get packages of abs and reconfigure them to add non upstream features, if you like them.
Having said all that, contributing the appropriate packages to the AUR is a very good initiative. Expand the choice of the user, I know some, maybe many, agree with you on minimalism w.r.t dbus/hal/the like. Forking is ridiculous and non-practical,
I already maintain a 50% fork. The remaining act is merely political. Obviously i will not bother to maintain a website and stuff if no one else cares contributing.
and it would be better for everyone involved in Arch if its not used as a proverbial hammer to get one's way.
I'm very sure my previous mail does not have any effect on the devs decision to follow their own founder or not. My hope is that it has an effect of users, so we can, in the event of failure, gather together and rebuild arch outside of the current project politics. -- Arvid Asgaard Technologies
On 02/12/09 07:38, Arvid Picciani wrote:
Ray Kohler wrote:
What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.)
Indeed. As brought up by others, forcing minimalism is as much violation as forcing bloat. However, arch has been built around the idea that users are capable of customizing packages to non-upstream settings. I urge you to do exactly that.
I have posted and will continue to post various bugs to the tracker to restore upstream defaults in favor for minimalism. If these reverts get rejected in favor for bloat, the clear bias is a disregard of the very core ideas of arch, and I will eventually fork arch entirely, given enough support.
Either way, i'd welcome if you contribute, in order to get the user experience you (and others including me) desire. That is, either contribute packages to aur, to fix insane upstream defaults, or contribute to an eventual fork to restore upstream defaults. Will you? :)
Let me just leave this right here. http://www.youtube.com/watch?v=-F-3E8pyjFo
Arvid Picciani wrote:
Aaron Griffin wrote:
If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
please comment on: http://bugs.archlinux.org/task/17346 summary: 1) I suggested reverting the dbus configure flag to upstream default. 2) Jan de Groot closed the bug with WONTFIX since this revert WILL break some third party gui configure util. -- Arvid Asgaard Technologies
On Wed, 2009-12-02 at 09:13 +0100, Arvid Picciani wrote:
Arvid Picciani wrote:
Aaron Griffin wrote:
If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration.
please comment on: http://bugs.archlinux.org/task/17346
summary:
1) I suggested reverting the dbus configure flag to upstream default.
2) Jan de Groot closed the bug with WONTFIX since this revert WILL break some third party gui configure util.
Dbus support in wpa-supplicant is not broken. A not working networkmanager is broken. We have to make a choice here, and having broken software isn't the right choice, is it?
Jan de Groot wrote:
Dbus support in wpa-supplicant is not broken. A not working networkmanager is broken. We have to make a choice here, and having broken software isn't the right choice, is it?
dbus is indeed broken. so its a different tradeof then you suggest. Additionaly, i don't intent to argue about that. My point is that the idea of archlinux is not centered around the gnome desktop, but rather around upstream defaults. -- Arvid Asgaard Technologies
Arvid Picciani wrote:
Jan de Groot wrote:
Dbus support in wpa-supplicant is not broken. A not working networkmanager is broken. We have to make a choice here, and having broken software isn't the right choice, is it?
dbus is indeed broken. so its a different tradeof then you suggest. Additionaly, i don't intent to argue about that.
Can you actually point out what is broken with dbus? That would actually clarify why you want it removed from cups, because as I commented in that bug report, the only advantage I see there is saving 4Mb of deps off your system. So far you opinion means nothing to me as it is only a rant with very little backing in terms of information. Allan
Allan McRae wrote:
Can you actually point out what is broken with dbus? That would actually clarify why you want it removed from cups, because as I commented in that bug report, the only advantage I see there is saving 4Mb of deps off your system.
I'm aware that minimalism is not a valid argument. My point was, that adding specific features for supporting a corner case for a specific subset of users, is a way worse argument.
So far you opinion means nothing to me as it is only a rant with very little backing in terms of information.
I have not provided details on dbus, because it is irrelevant to the argument. It is undeniable that my most pressing concern is removing dbus where the arch way argument holds (i will NOT post bug reports that remove dbus from packages where it is upstream default), however this does in no way affect the validity of my points. If you care anyway: dbus does crash frequently and some software that has been configured with it, dies ungracefully, leaving the system dead. Additionally hal is using 100% cpu on my system. I don't care to fix this, as i see no requirement for any of this software in the first place. This is a minimalism argument, yes, but it is in compliance with arch ideas under the conditions: - the effected software has not been built under the assumption the dependency is available this would for example not hold true for any gnome app. if i would complain about gnome depending on dbus, it would indeed be an invalid point - the upstream encourages usage of the software without that dependency default configure options are an easy indicator for this.1 - technical elegance beats "ease of use" if reading the manual leads to a better user experience then using a non default convenience option - there are multiple "correct" ways Arch is not about gnome. -- Arvid Asgaard Technologies
Arvid Picciani wrote:
Allan McRae wrote:
Can you actually point out what is broken with dbus? That would actually clarify why you want it removed from cups, because as I commented in that bug report, the only advantage I see there is saving 4Mb of deps off your system.
I'm aware that minimalism is not a valid argument. My point was, that adding specific features for supporting a corner case for a specific subset of users, is a way worse argument.
And blindly not enabling it for a specific subset is also stupid. In fact, the logical choice would be to supply a package that the minimal number of people need to recompile, if only to minimize user bitching. While I am at it, lets see why your arguements just grepping for "enable|disable" etc are idiotic. Take the gcc PKGBUILD: --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-clocale=gnu --disable-libstdcxx-pch etc... Should I revert them to the "default" values. No. How many of the other flags counted by your grep are needed?
So far you opinion means nothing to me as it is only a rant with very little backing in terms of information.
I have not provided details on dbus, because it is irrelevant to the argument. It is undeniable that my most pressing concern is removing dbus where the arch way argument holds (i will NOT post bug reports that remove dbus from packages where it is upstream default), however this does in no way affect the validity of my points.
I personally think your mis-reading the "Arch Way". We do not patch to add features that are not supported upstream but I have never seen anything mentioned about using minimal configure flags.
If you care anyway: dbus does crash frequently and some software that has been configured with it, dies ungracefully, leaving the system dead. Additionally hal is using 100% cpu on my system.
So you filed bug reports about this? Or just bitched? Or is this only occurring on your system where you maintain a 50% fork and not being noticed by others? Allan
Allan McRae wrote:
While I am at it, lets see why your arguements just grepping for "enable|disable" etc are idiotic. Take the gcc PKGBUILD:
i have pointed out myself that those do not form a valid argument. Trying to disprove my other points by doing that _again_ does not work.
I personally think your mis-reading the "Arch Way". We do not patch to add features that are not supported upstream but I have never seen anything mentioned about using minimal configure flags.
Let me quote "the arch way 2.0" which has a very nice condensed statement that does in fact support minimalism: " without unnecessary additions, modifications, or complications Simplicity is the primary principle. All other principles must be sacrificed in favor of design simplicity. Implementation simplicity is more important than interface simplicity. " Please provide an interpretaton of this statement that does support enabling features for the sake of interface simplicity, breaking design simplicity in the process.
So you filed bug reports about this?
I can, for the sake of disarming that as counter argument. I can't see how this adds anything to the original points though. -- Arvid Asgaard Technologies
On Wed, 2009-12-02 at 10:11 +0100, Arvid Picciani wrote:
Let me quote "the arch way 2.0" which has a very nice condensed statement that does in fact support minimalism:
" without unnecessary additions, modifications, or complications
Simplicity is the primary principle. All other principles must be sacrificed in favor of design simplicity. Implementation simplicity is more important than interface simplicity. "
Please provide an interpretaton of this statement that does support enabling features for the sake of interface simplicity, breaking design simplicity in the process.
Design simplicity? How is --enable-dbus less simple than --disable-dbus or the equivalents? Simplicity isn't a hammer with which to attack every package that doesn't conform to minimalism by your definition. Are you suggesting the removal of KDE/Gnome from the repos? Because to disable dbus would require:- a) Parallel packages be maintained with dbus enabled for usage of gnome and the like packages OR b) Gnome and the like will have to be moved to AUR/community since they would need recompiling some core packages for dbus support. Neither of the options seems much like design simplicity to me. It would be good if the UNIX way (tm) or the Arch Way (tm) is not treated as some kind of religious doctrine. Systems evolve and grow, and the desktop does as well, thankfully.
Ng Oon-Ee wrote:
Design simplicity? How is --enable-dbus less simple than --disable-dbus or the equivalents?
My argument was "--enable-dbus" vs "" ie the defaults.
Simplicity isn't a hammer with which to attack every package that doesn't conform to minimalism by your definition.
Yes you can. Otherwise what is there difference between arch and ubuntu or whatever your prefered desktop os is?
Are you suggesting the removal of KDE/Gnome from the repos? Because to disable dbus would require:- a) Parallel packages be maintained with dbus enabled for usage of gnome and the like packages OR b) Gnome and the like will have to be moved to AUR/community since they would need recompiling some core packages for dbus support.
I suggest fixing them instead, so they compile with the default options of their dependencies. Preferable fixing them upstream of course.
Neither of the options seems much like design simplicity to me.
I have provided a way that confirms with the arch way.
It would be good if the UNIX way (tm) or the Arch Way (tm) is not treated as some kind of religious doctrine.
It is what arch is based on. I can't see why people who follow some projects root ideas have to leave the project because somone else has other ideas.
Systems evolve and grow, and the desktop does as well, thankfully.
And thankfully they grow beyond your gnome/kde world :) -- Arvid Asgaard Technologies
Ng Oon-Ee wrote:
Simplicity isn't a hammer with which to attack every package that doesn't conform to minimalism by your definition.
Yes you can. Otherwise what is there difference between arch and ubuntu or whatever your prefered desktop os is? The difference certainly isn't in minimalism, else we shouldn't even
On Wed, 2009-12-02 at 10:30 +0100, Arvid Picciani wrote: provide gnome/kde. The objective of Arch isn't to be different from Ubuntu, any more than the objective of Linux isn't to be different from Windows.
Are you suggesting the removal of KDE/Gnome from the repos? Because to disable dbus would require:- a) Parallel packages be maintained with dbus enabled for usage of gnome and the like packages OR b) Gnome and the like will have to be moved to AUR/community since they would need recompiling some core packages for dbus support.
I suggest fixing them instead, so they compile with the default options of their dependencies. Preferable fixing them upstream of course.
The term 'fixing' implies something is broken. DBus and hal are not (contrary to your personal experience) broken for the majority of users. There's only so much breakage an open source package can have before users start leaving (look at initial KDE4 releases for an example). Removing dbus and hal is not 'fixing' anything, its making decisions based on politics.
Neither of the options seems much like design simplicity to me.
I have provided a way that confirms with the arch way.
It would be good if the UNIX way (tm) or the Arch Way (tm) is not treated as some kind of religious doctrine.
It is what arch is based on. I can't see why people who follow some projects root ideas have to leave the project because somone else has other ideas.
Arch was never based on 'only use non-dbus/hal/any other new thing packages'. Once again, if you object to dbus etc on the grounds of minimalism, why not campaign for removing gnome/kde? The net effect is the same, and the likelihood of it getting implemented is about the same as well.
Systems evolve and grow, and the desktop does as well, thankfully.
And thankfully they grow beyond your gnome/kde world :)
And here I was thinking that growing involved accepting change and not stagnating in an 'old is best' mind-set. Just because "it's always worked without this new-fangled thing" doesn't mean "this new-fangled thing is bloat and shouldn't be used". Whyever did we make computers with more than 8MB of RAM....
On Wed, Dec 02, 2009 at 10:30:57AM +0100, Arvid Picciani wrote: [snip]
Systems evolve and grow, and the desktop does as well, thankfully.
And thankfully they grow beyond your gnome/kde world :)
I am curious. What desktop do you use Arvid ? Regards ppk
Piyush P Kurur wrote:
I am curious. What desktop do you use Arvid ?
None at all. I used one of these desktops (kde3) a few years ago because terminals started to age and lack modern features. But then the antidesktop movement has lifted keyboard centric user experience to a modern level, basicly bringing everything i like about unix together with the good parts of the modern world. Now i'm running xmonad, with a mix of gui (gimp,inkscape,browser) and non gui applications (basicly everything that makes sense to be used with a keyboard) -- Arvid Asgaard Technologies
None at all.
Now i'm running xmonad, with a mix of gui (gimp,inkscape,browser) and non gui
My english wasn't one of the best, but isn't a windows manager the same thing as a desktop ? -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Wed, 2009-12-02 at 14:15 +0100, ludovic coues wrote:
None at all.
Now i'm running xmonad, with a mix of gui (gimp,inkscape,browser) and non gui
My english wasn't one of the best, but isn't a windows manager the same thing as a desktop ?
Nope, a WM manages windows, a desktop (typically DE - Desktop Environment) comprises a window manager (Metacity for Gnome, KWin for KDE) and some other 'helper apps' to do stuff like display backgrounds, present a panel and widgets, automate mounting, power-management, file browsing, copy/paste, etc. In other words, DEs have WMs, WMs are not DEs. Therefore WMs are by definition 'lighter' than DEs unless REALLY badly done. Its a matter of preference, I believe. I prefer to have all the hard work done for me, perhaps sacrificing some pure performance. Others don't want ANYTHING they don't need on their systems, DEs wouldn't work here.
Arvid Picciani wrote:
Allan McRae wrote:
I personally think your mis-reading the "Arch Way". We do not patch to add features that are not supported upstream but I have never seen anything mentioned about using minimal configure flags.
Let me quote "the arch way 2.0" which has a very nice condensed statement that does in fact support minimalism:
Nice... so not the original Arch Way as defined by Judd that you keep referring to... For those that do not know this version: http://wiki.archlinux.org/index.php/The_Arch_Way_v2.0 . No offense meant to Jules who started writing this, but you are quoting an interpretation of the original design principles of Arch that has had absolutely no direct import from any devs.
" without unnecessary additions, modifications, or complications
Simplicity is the primary principle. All other principles must be sacrificed in favor of design simplicity. Implementation simplicity is more important than interface simplicity. "
Please provide an interpretaton of this statement that does support enabling features for the sake of interface simplicity, breaking design simplicity in the process.
So another person who mistakes the use of simplicity for minimalism. I thought we had been through that many, many times. And how is adding a configure flag or a dep a sacrifice of design simplicity? I see no way that statement is conflicting with either of the sides of this argument. Allan
On Wed, Dec 2, 2009 at 3:31 AM, Allan McRae <allan@archlinux.org> wrote:
Arvid Picciani wrote:
Let me quote "the arch way 2.0" which has a very nice condensed statement that does in fact support minimalism:
Nice... so not the original Arch Way as defined by Judd that you keep referring to... For those that do not know this version: http://wiki.archlinux.org/index.php/The_Arch_Way_v2.0 . No offense meant to Jules who started writing this, but you are quoting an interpretation of the original design principles of Arch that has had absolutely no direct import from any devs.
I would just like to emphasize this point. I was going to post something to this effect. Look at the history of that wiki page. The authors have taken artistic license with it.
Allan McRae wrote:
I personally think your mis-reading the "Arch Way".
So another person who mistakes the use of simplicity for minimalism. I thought we had been through that many, many times.
Can we, independently of the technical details of dbus, agree all, that I and some other people have been interpreting the arch way wrong? If yes, can we please change the wiki to reflect that? i suggest removing the words "minimalistic" and "unix like" from http://wiki.archlinux.org/index.php/The_Arch_Way also possibly "A freshly installed Arch Linux system contains only basic core components" as the definition of "basic" is unclear. additionaly i propose that a conclusion to this whole thing is noted on the page, that says something like: "Archlinux is optimized, to work well with all desktops, not just one, including that it will not sacrifice commonly available desktop software for the sake of simplicity." It's very fuzzy, as i try not to offend anyone again. maybe more concrete: "As an example: there have been ongoing discussions to sacrifice feature X,Y for the advantage of commandline or antidesktop users, and to the disadvantage of desktop users. This is not what archlinux is about, as we want to provide a good user experience for the largest possible user base" I prefer a clear "this distro is not for you, go away" over "we share your mindset. maybe. or maybe not.". and this would have helped to avoid this situation alltogether. Thank you. -- Arvid Asgaard Technologies
On Thu, 2009-12-03 at 23:23 +0100, Arvid Picciani wrote:
Allan McRae wrote:
I personally think your mis-reading the "Arch Way".
So another person who mistakes the use of simplicity for minimalism. I thought we had been through that many, many times.
Can we, independently of the technical details of dbus, agree all, that I and some other people have been interpreting the arch way wrong?
I actually think the you've been over-focusing on a single part of the 'arch way', that its 'all about' minimalism.
If yes, can we please change the wiki to reflect that?
i suggest removing the words "minimalistic" and "unix like" from
http://wiki.archlinux.org/index.php/The_Arch_Way
also possibly "A freshly installed Arch Linux system contains only basic core components" as the definition of "basic" is unclear.
additionaly i propose that a conclusion to this whole thing is noted on the page, that says something like:
"Archlinux is optimized, to work well with all desktops, not just one, including that it will not sacrifice commonly available desktop software for the sake of simplicity."
It's very fuzzy, as i try not to offend anyone again. maybe more concrete:
"As an example: there have been ongoing discussions to sacrifice feature X,Y for the advantage of commandline or antidesktop users, and to the disadvantage of desktop users. This is not what archlinux is about, as we want to provide a good user experience for the largest possible user base"
Throughout this thread the vibe I've been getting for you is that you somehow feel disadvantaged and biased-against because dbus/hal exist and are selected as options in building general-purpose binaries. As an example, I'm a pulseaudio user, and I'm very happy with its features. Unfortunately (in my view) it is not integrated into our current gnome packages though it is upstream, nor are packages with pulse support provided in a binary form which can output to pulse (mpd for one). I understand, however, that most do not want/need/care about Pulseaudio, so I compile my own packages with pulse support. DISCLAIMER: JGC has stated that he will eventually include Pulseaudio in Gnome, but that its a lot of work, and I totally understand that. Its not an either/or for 'minimalist' and 'desktop' users, for an entire distro...
I prefer a clear "this distro is not for you, go away" over "we share your mindset. maybe. or maybe not.". and this would have helped to avoid this situation alltogether.
Thank you.
Why is Arch not for the minimalist user? Because dbus/hal are enabled in some packages in binary? Is Arch not for the standard desktop user who doesn't have a wifi card because wifi modules are compiled into the standard kernel26? For me, one of the primary benefits of Arch is that PKGBUILDs are simple to read and modify, allowing me to customize my system without having to compile outside the package manager (try doing that in Ubuntu). This allows ALL users the freedom to decide what their system should be like. Arch is what you make it.
Ng Oon-Ee wrote:
I actually think the you've been over-focusing on a single part of the 'arch way', that its 'all about' minimalism.
then i suggest we remove the statement that it is all about minimalism.
Throughout this thread the vibe I've been getting for you is that you somehow feel disadvantaged and biased-against because dbus/hal exist and are selected as options in building general-purpose binaries.
I feel in fact like wasting my time. I am a very simple person. I understand "fuck you" very well and can handle it, other things like blurry project goals make me act stupid.
Why is Arch not for the minimalist user?
Because it was officially stated by two arch devs that it is not.
Because dbus/hal are enabled in some packages in binary?
Because its philosophy does not match. That goes way deeper then arguing vim vs emacs. Please, can we stop beating it now, and just officialy tell minimalists to fuck off so everyone can stop wasting their time? -- Arvid Asgaard Technologies
2009/12/3 Arvid Picciani <aep@exys.org>:
Ng Oon-Ee wrote:
I actually think the you've been over-focusing on a single part of the 'arch way', that its 'all about' minimalism.
then i suggest we remove the statement that it is all about minimalism.
Throughout this thread the vibe I've been getting for you is that you somehow feel disadvantaged and biased-against because dbus/hal exist and are selected as options in building general-purpose binaries.
I feel in fact like wasting my time.
I am a very simple person. I understand "fuck you" very well and can handle it, other things like blurry project goals make me act stupid.
Why is Arch not for the minimalist user?
Because it was officially stated by two arch devs that it is not.
Because dbus/hal are enabled in some packages in binary?
Because its philosophy does not match. That goes way deeper then arguing vim vs emacs.
Please, can we stop beating it now, and just officialy tell minimalists to fuck off so everyone can stop wasting their time?
-- Arvid Asgaard Technologies
It all just depends on the degree of minimalism one is after. I went from Gentoo to Ubuntu to Arch Linux (With a whole lot of other distros before and in between, including Crux, Slackware, and the BSDs). For me, Arch is far more minimal than Gentoo and Ubuntu. (More minimal than Gentoo because package building is minimized, and more minimal than Ubuntu as far as package dependencies/complexities and also configuration/runlevels/etc). For me Arch is the best balance of minimalism and overall functionality that I've found in any Linux distro. Yes, compared to slackware, Arch Linux might not be minimal, but compared to the desktop distros Fedora, Ubuntu, Mandriva, OpenSUSE, and the likes, ArchLinux is very lightweight and minimal. Arch can't be the ideal distro for everybody. Like others have said, it is what you make it, and being able to easily add your own packages and repositories makes Arch far flexible than the non minimal desktop distros. Yeah, maybe I should not add to this discussion. It has gone on long enough. Dwight
On Fri, Dec 04, 2009 at 12:08:29AM +0100, Arvid Picciani wrote:
Please, can we stop beating it now, and just officialy tell minimalists to fuck off so everyone can stop wasting their time?
Bad spelling and foul language. I'd suggest to tell those who want a bloated system with lots of useless dependencies to move to Ubuntu or Fedora so everybody can stop wasting his/her time. Ciao, -- FA
fons@kokkinizita.net wrote:
On Fri, Dec 04, 2009 at 12:08:29AM +0100, Arvid Picciani wrote:
Please, can we stop beating it now, and just officialy tell minimalists to fuck off so everyone can stop wasting their time?
Bad spelling and foul language.
Yeah once again i fail at not offending anyone... suggest better wording please. this honestly not feeling offensive for me, and i'm incapable of doing it your way. -- Arvid Asgaard Technologies
Please, stop filling my inbox with useless junk.
Sébastien Leblanc wrote:
Please, stop filling my inbox with useless junk.
Please use the kill thread option of your MUA. Messages like this aren't helping anyone, and are especcialy not helping to minimize the thread length. -- Arvid Asgaard Technologies
On Thu, Dec 3, 2009 at 9:28 PM, <fons@kokkinizita.net> wrote:
I'd suggest to tell those who want a bloated system with lots of useless dependencies to move to Ubuntu or Fedora so everybody can stop wasting his/her time.
I wouldn't go that far. That kind of attitude is what derails the conversation. Again, simplicity is not mensurable. Maybe the Arch Way does more harm than good talking in terms of things we can't measure. Or maybe people should stop reading it as a gospel. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Am Fri, 04 Dec 2009 00:08:29 +0100 schrieb Arvid Picciani <aep@exys.org>:
then i suggest we remove the statement that it is all about minimalism.
This statement shouldn't be removed. Minimalism doesn't mean that no optional features are compiled into a package. Minimalism also doesn't mean that every package is compiled only for your needs. Minimalism means that you only need to install those packages you really need and that you know what is installed on your system. A distribution is not for only one user but for many users who have their own needs. This doesn't contradict minimalism. Show me a more minimalist distribution than Arch and Gentoo. I guess you won't find one. And if you did I suggest you switching to this distro. And again also Gentoo sometime forces you to compile features into a package which you don't like and want to just because they are needed by other packages. If Arch doesn't fit your needs then choose another distro or build one by yourself. Heiko
Heiko Baums wrote:
Show me a more minimalist distribution than Arch and Gentoo. I guess you won't find one. And if you did I suggest you switching to this distro.
This is the entire reason i want arch to officialy state that these users are not welcome. I want to move on, so we can split up the user bases. Ultimately so both sides can continue their life without the constant (and i'm meaning constant. this isnt the first time this discussion exploded) need to reevaluate if arch should do this or that.
If Arch doesn't fit your needs then choose another distro or build one by yourself.
It's done. All i want is to settle this in a useful way. -- Arvid Asgaard Technologies
On Fri, 2009-12-04 at 00:49 +0100, Arvid Picciani wrote:
Heiko Baums wrote:
Show me a more minimalist distribution than Arch and Gentoo. I guess you won't find one. And if you did I suggest you switching to this distro.
This is the entire reason i want arch to officialy state that these users are not welcome. I want to move on, so we can split up the user bases. Ultimately so both sides can continue their life without the constant (and i'm meaning constant. this isnt the first time this discussion exploded) need to reevaluate if arch should do this or that.
If Arch doesn't fit your needs then choose another distro or build one by yourself.
It's done. All i want is to settle this in a useful way.
I think that's about all that can be said then. Arch Linux, and its devs/community, does not dislike (or fail to welcome) minimalist users. The only users Arch does not welcome are those who don't want to do their homework, as far as I can see (obviously not you). All users are welcome to make THEIR Arch install what they want.
Am Fri, 04 Dec 2009 00:49:14 +0100 schrieb Arvid Picciani <aep@exys.org>:
This is the entire reason i want arch to officialy state that these users are not welcome. I want to move on, so we can split up the user bases. Ultimately so both sides can continue their life without the constant (and i'm meaning constant. this isnt the first time this discussion exploded) need to reevaluate if arch should do this or that.
You still don't understand or don't want to understand it. Arch is for both sides. Arch as it is can be used by the so called power users who only want to use the keyboard and the console. And Arch as it is can also be used by the average user who just want a nice desktop and just want to read and write his e-mails, surf through the web and write some letters with an office suite. Both user bases can choose what they want to install on Arch as it is now. That's minimalism.
It's done. All i want is to settle this in a useful way.
So why do you continue ranting about Arch? Write your own website and build your own mirrors and writer there why you are forking Arch and what's the difference between Arch and your distro. But again I doubt that you can keep such a minimalism as you like especially if you'll get a bigger user base. Heiko
Heiko Baums wrote:
So why do you continue ranting about Arch?
I tried not to. All i wanted is a clear cut, but i think i'm alone with that wish, so i'll stop beating it. You're the ones who'll have to deal with this procedure over and over again (not with me. no worries) -- Arvid Asgaard Technologies
On 03/12/09 23:49, Arvid Picciani wrote:
Heiko Baums wrote:
Show me a more minimalist distribution than Arch and Gentoo. I guess you won't find one. And if you did I suggest you switching to this distro.
This is the entire reason i want arch to officialy state that these users are not welcome. I want to move on, so we can split up the user bases. Ultimately so both sides can continue their life without the constant (and i'm meaning constant. this isnt the first time this discussion exploded) need to reevaluate if arch should do this or that.
If Arch doesn't fit your needs then choose another distro or build one by yourself.
It's done. All i want is to settle this in a useful way.
I originally identified you as a poisonous person and you just keep confirming my theory.
Arvid Picciani wrote:
It's done. All i want is to settle this in a useful way.
Nathan Wayde wrote:
I originally identified you as a poisonous person and you just keep confirming my theory.
a I found a problem b I made aware of the problem c I have provided patches d I have provided packages e I have expressed the wish to find a way that suits both sides f You accuse me of being poisonous. I'm a strong person, but there are things i am not capable of just letting go. Calling someone who drives the very foundation You spit on poisonous is a very sad new addition to the foss world. Usually I'd take such insult with a grain of salt and swallow it, but seeing that You are backed by a very large amount of people, it might be wise to just accept that I'm not welcome anymore, in a world I once helped creating. Maybe I'm like a father who can't let his kids go, and i am indeed poisonous in a way that i deny the kids to make their own mistakes. For the time being, good luck on your journey. Just remember that the cake is a lie. /s/ Arvid
On Fri, 2009-12-04 at 04:36 +0100, Arvid Picciani wrote:
Arvid Picciani wrote:
It's done. All i want is to settle this in a useful way.
Nathan Wayde wrote:
I originally identified you as a poisonous person and you just keep confirming my theory.
a I found a problem b I made aware of the problem c I have provided patches d I have provided packages e I have expressed the wish to find a way that suits both sides f You accuse me of being poisonous.
I'm a strong person, but there are things i am not capable of just letting go. Calling someone who drives the very foundation You spit on poisonous is a very sad new addition to the foss world.
I'm unsure what foundation you're driving. Perhaps you code and package? Well done to you then, such work is always appreciated. But it doesn't come with the right to look down on and insult those who don't share your vision on Linux, or Arch.
Usually I'd take such insult with a grain of salt and swallow it, but seeing that You are backed by a very large amount of people, it might be wise to just accept that I'm not welcome anymore, in a world I once helped creating. Maybe I'm like a father who can't let his kids go, and i am indeed poisonous in a way that i deny the kids to make their own mistakes. For the time being, good luck on your journey. Just remember that the cake is a lie.
/s/ Arvid
/me thinks Arvid is perhaps Judd in disguise? 'deny the kids to make their own mistakes', such as using software and DEs which you don't agree with and think are fundamentally broken (but surprisingly 'just work' (tm) for others). I keep wanting to ignore these threads... somehow the absurdities keep getting worse though.
For a thread with subject "peaceful" this has really gone downhill. Anyway, I doubt anybody that "matters" in terms of making decisions around here is still reading this. I only read the last couple of emails out of some sort of morbid curiosity... Allan
On Fri, 2009-12-04 at 14:00 +1000, Allan McRae wrote:
For a thread with subject "peaceful" this has really gone downhill.
Anyway, I doubt anybody that "matters" in terms of making decisions around here is still reading this. I only read the last couple of emails out of some sort of morbid curiosity...
Allan I get the hint. Thanks Allan. Signing off this thread.
On Fri, 04 Dec 2009 00:08:29 +0100, Arvid Picciani <aep@exys.org> wrote:
Please, can we stop beating it now, and just officialy tell minimalists to fuck off so everyone can stop wasting their time?
I've been following this thread off an on. Great to see you having an opinion and standing up for it, the same for everyone else. As I understand from above part, you just would be happy with a fuck off, right? Well, Fuck off if you think about minimalism in a way like you do. It is obviously not the same as the most in the Arch community understands it. Now you've got a fuck off and you can stop wasting your time. The Arch way in the wiki are just words, you have to become part of the community to really understand it. -- Jeroen Op 't Eynde jeroen@xprsyrslf.be http://xprsyrslf.be How to set up a cheap professional website @ XprsYrslf.be
2009/12/3 Ng Oon-Ee <ngoonee@gmail.com>:
Arch is what you make it.
I think you nailed it. I always thought the Arch Way as a principle, not a rule. We're not a religion, neither a nation. The few rules we have are for the well of the community, so that it can go forward without losing time with nitpicking. The Arch Way should not be used as a stick to bash other people on the head. This is a problem inherent to any positive principle. People are more easily led by a list of negative commandments (don't do this, don't do that) than broad positive principles, as the Arch Way, in which each one can extract a different truth. Oh, the people... -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
2009/12/3 Arvid Picciani <aep@exys.org>:
Allan McRae wrote:
I personally think your mis-reading the "Arch Way".
So another person who mistakes the use of simplicity for minimalism. I thought we had been through that many, many times.
Can we, independently of the technical details of dbus, agree all, that I and some other people have been interpreting the arch way wrong?
If yes, can we please change the wiki to reflect that?
i suggest removing the words "minimalistic" and "unix like" from
http://wiki.archlinux.org/index.php/The_Arch_Way
also possibly "A freshly installed Arch Linux system contains only basic core components" as the definition of "basic" is unclear.
additionaly i propose that a conclusion to this whole thing is noted on the page, that says something like:
"Archlinux is optimized, to work well with all desktops, not just one, including that it will not sacrifice commonly available desktop software for the sake of simplicity."
It's very fuzzy, as i try not to offend anyone again. maybe more concrete:
"As an example: there have been ongoing discussions to sacrifice feature X,Y for the advantage of commandline or antidesktop users, and to the disadvantage of desktop users. This is not what archlinux is about, as we want to provide a good user experience for the largest possible user base"
I prefer a clear "this distro is not for you, go away" over "we share your mindset. maybe. or maybe not.". and this would have helped to avoid this situation alltogether.
Thank you.
-- Arvid Asgaard Technologies
Holy *beep*, why are you doing that?! Stop filling my inbox with useless crap! Why don't you make your own distribution? I'd be glad to annoy you all the day with pointless nitpicking. I wish I could filter your e-mails. Life would be so much easier than… Damn, it's so difficult to ignore trolls.
Arvid: Linux from scratch.
Am Wed, 02 Dec 2009 09:13:59 +0100 schrieb Arvid Picciani <aep@exys.org>:
please comment on: http://bugs.archlinux.org/task/17346
summary:
1) I suggested reverting the dbus configure flag to upstream default.
2) Jan de Groot closed the bug with WONTFIX since this revert WILL break some third party gui configure util.
Especially this bug is pretty the same as the question I asked some days ago about moving smbclient from depends to optdepends in various packages like mplayer. KISS doesn't mean minimalist, KISS means simple. Arch is a binary distribution so if an upstream package has optional features which need to be chosen at compile time then in most cases these features should be compiled into this package by downstream. If a dependency can be made optional at runtime then these dependencies are already put to optdepends instead of depends so that the user can choose if he wants them or not. Regarding my mplayer/smbclient question it's obvious that I don't need smbclient as I'm using a Linux only system. But there are at least some people who need or want to use mplayer with samba. Because this optional samba feature has to be compiled into mplayer - I didn't know this when I asked this question - it's obvious that it's compiled into mplayer. With your wpa_supplicant example it's obvious that you don't need networkmanager and therefore don't need its dbus support. But there are a lot of people who need networkmanager and therefore the dbus support. I on my own PC don't need networkmanager, too, but I'll soon install Arch on another computer and there I'll need networkmanager. Because the optional dbus support has to be compiled into wpa_supplicant it's obvious that it is compiled in. Forcing those people who need one or two features which are optional but need to be chosen at compile time to rebuild these packages (would be nearly every package) from ABS or AUR is not KISS and not the sense of a binary distribution. If you need a minimal instead of a simple system you should go for Gentoo. There you have USE flags for every single optional feature of a package and with those USE flags you can omit hal and dbus completely from your system. But you should consider that in most cases you will end in activating most of these optional features/USE flags because you just need most of these optional features to get your system running or at least to make it a bit more comfortable. See e.g. various media players which have a USE flag for nearly every codec. But do you really want a media player without MP3, Ogg/Vorbis or FLAC support? And it's not so seldom on Gentoo that you get a message that you first need to turn on a particular USE flag for a particular package and reinstall/recompile this package before you can install the package you actually want to install. This particularly happens with USE flags like dbus and hal. Including such USE flags into a binary distribution is just not possible. There have been many such discussions before in the forums and on the mailing lists. And the result of every such discussion was that Arch is good as it is. And in my experience the decisions of the downstream developers of Gentoo and of Arch are usually (not always) deliberate if one thinks about it closer. On Gentoo there are from time to time similar discussions, too, btw. I on my own PC don't need networkmanager but I'll soon install Arch on another computer and there I'll need networkmanager. If networkmanager needs dbus to work then dbus is of course to be compiled into xorg in a binary distribution and infact it does no harm. The same with my mplayer smbclient example. If I wouldn't want smbclient I could compile mplayer from ABS. But I switched from Gentoo to Arch because I want to compile as few packages as possible. I just want a binary distribution which gives nearly the same choice as Gentoo does but without compiling. And this is what Arch does perfectly. If I only get this at the price of having a handful dependencies installed which I don't need and which costs only a few MB or KB on my harddisk then I'm absolutely willing to pay this price because compiling the whole system as in Gentoo takes too much time. There is a second option regarding your dbus/wpa_supplicant example. Why not file a bug report/feature request to upstream of networkmanager to remove dbus from it? Of course you need to file this bug report/feature request to upstream of every package which depends on dbus. As soon as dbus is removed from every package or made optional at runtime then you could reopen this bug report/feature request to Arch again. Otherwise it's better to keep the optional dbus support in wpa_supplicant. So I'd suggest you to either compile the appropriate packages by yourself from ABS or use Gentoo. Btw., I, too, don't like hal and dbus much. But it's needed by many packages and infact it doesn't hurt much. Heiko
Heiko Baums wrote:
There is a second option regarding your dbus/wpa_supplicant example. Why not file a bug report/feature request to upstream of networkmanager to remove dbus from it? Of course you need to file this bug report/feature request to upstream of every package which depends on dbus. As soon as dbus is removed from every package or made optional at runtime then you could reopen this bug report/feature request to Arch again. Otherwise it's better to keep the optional dbus support in wpa_supplicant.
This is a VERY good point. I shall do that. -- Arvid Asgaard Technologies
Am Wed, 02 Dec 2009 10:35:59 +0100 schrieb Arvid Picciani <aep@exys.org>:
Heiko Baums wrote:
There is a second option regarding your dbus/wpa_supplicant example. Why not file a bug report/feature request to upstream of networkmanager to remove dbus from it? Of course you need to file this bug report/feature request to upstream of every package which depends on dbus. As soon as dbus is removed from every package or made optional at runtime then you could reopen this bug report/feature request to Arch again. Otherwise it's better to keep the optional dbus support in wpa_supplicant.
This is a VERY good point. I shall do that.
But I doubt that you will have much success. Maybe you should read and think about dbus and it's intention before you file such bug reports/feature requests. As far as I understand it brings features like KDE's dcop to other software, if it's not replacing dcop. Heiko
On Tue, 2009-12-01 at 23:51 +0100, Arvid Picciani wrote:
Aaron Griffin wrote:
Which package has patches to add these features? Looking at xorg-server, I only see one extraneous patch that simple replaces the default grey stipple pattern with black. The rest seem (at a glance) to fix real bugs
You have a point here, in that i have used a fuzzy description of the problem, in the assumption you and possible other readers remember the numerous rants on this ML. At very least I'd except You to remember your own blog. I'm going to post some hard facts to your convenience.
aep@andariel: ~ egrep 'enable|disable|patch -N' /var/abs/extra/xorg-server/PKGBUILD | wc -l 24
Jan has always done a good job in the past of keeping Xorg as impartial as possible without breaking things, and I'm assuming he did the same here.
i was about to state that i didnt target him at all. Then i ran this:
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1); do egrep "enable|disable|patch -N" $i; done) | wc -l 543
Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent"
aep@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot <jgc@archlinux.org>
and "bias"
So, just because I'm the maintainer of a package that is required for a lot of the packages I maintain makes me biased. Now, first of all: most of the patches that I apply are from upstream git/svn, or come from upstream bugtrackers fixing accepted bugs. Then about the dbus dependency in xorg: we do specifically enable config-dbus, but dbus is a dependency anyways: AC_ARG_ENABLE(config-hal, AS_HELP_STRING([--disable-config-hal], [Build HAL support (default: auto)]), [CONFIG_HAL=$enableval], [CONFIG_HAL=auto]) So, having hal installed on your system means vanilla hal autoconfiguration in xorg-server. As for the other --disable and --enable flags: most of them are default or autodetected. In some cases we don't want something and --disable it, in some other cases we want these things enabled so we --enable them. Flaming based on the count of --enable/--disable flags and the amount of applied patches does not help anything, and it doesn't improve a distribution or discussion either.
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome
/dev/null); then echo $i; fi; done) | wc -l 149
Ooh, so I'm the GNOME maintainer, what next?
The point is, just because *I* prefer something one way doesn't mean it's a good decision at the distro level.
So there is the name of some guy, who approves the unix philosophy, on this distro, but that guy decides it's a good idea that people who prefer ubuntu make the vital decisions.
I claim, You are leading a project whichs developers mainly disprove what You stand for, or claim to stand for. Which is why, ...
I never even installed Ubuntu on any system, how can I prefer it? Arch has thousands of packages that need to work together, sometimes you can't stick to your so called "unix philosophy".
Jan de Groot wrote:
Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent"
aep@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot <jgc@archlinux.org>
and "bias"
So, just because I'm the maintainer of a package that is required for a lot of the packages I maintain makes me biased.
Please read from top to down. This grep was to prove "intent". It is in fact, not required for alot of packages upstream, and especially there is no valid reason to put it in core.
we do specifically enable config-dbus, but dbus is a dependency anyways:
indeed, i am wrong on this one. hal is already upstream default.
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome
/dev/null); then echo $i; fi; done) | wc -l 149
Ooh, so I'm the GNOME maintainer, what next?
please don't quote out of context. this statement was to prove your bias towards gnome, which in combination with the above dbus-core point, shows why this is a problem.
I never even installed Ubuntu on any system, how can I prefer it? Arch has thousands of packages that need to work together, sometimes you can't stick to your so called "unix philosophy".
Thank's for confirming once again that you do NOT wish to follow unix philosophy. This was indeed, the entire point of this rant. -- Arvid Asgaard Technologies
On Wed, 2009-12-02 at 09:18 +0100, Arvid Picciani wrote:
Jan de Groot wrote:
Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent"
aep@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot <jgc@archlinux.org>
and "bias"
So, just because I'm the maintainer of a package that is required for a lot of the packages I maintain makes me biased.
Please read from top to down. This grep was to prove "intent". It is in fact, not required for alot of packages upstream, and especially there is no valid reason to put it in core.
Ah, so my intent is to put dbus support in every possible package in the repository. Am I convicted now? What's the sentence?
we do specifically enable config-dbus, but dbus is a dependency anyways:
indeed, i am wrong on this one. hal is already upstream default.
aep@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome
/dev/null); then echo $i; fi; done) | wc -l 149
Ooh, so I'm the GNOME maintainer, what next?
please don't quote out of context. this statement was to prove your bias towards gnome, which in combination with the above dbus-core point, shows why this is a problem.
dbus is a freedesktop.org project, gnome isn't. The fact that GNOME uses a freedesktop.org project has nothing to do with the fact that I enable dbus support in packages that need it.
I never even installed Ubuntu on any system, how can I prefer it? Arch has thousands of packages that need to work together, sometimes you can't stick to your so called "unix philosophy".
Thank's for confirming once again that you do NOT wish to follow unix philosophy. This was indeed, the entire point of this rant.
So, the fact that I maintain desktop software and the fact that I can't always follow the vanilla configure options make me not wish to follow them. I don't see your point. Let's take a look at a bug you reported: the qt bug. You filed a bug that asked to remove all patches. For some of the patches, I think you're right, for others, I don't think you're right. One of your removed patches is one that integrates use of ca-certificates in qt instead of the bundled certificates. By following your so-called "unix philosophy", you want us to ship several certificate bundles with the same certificates with every package that needs certificate bundles. This is nice if Qt is the only piece of software on your system, but as soon as a 2nd package is installed with a certificate bundle, it's a waste of disk space and a complication of management.
Jan de Groot wrote:
Ah, so my intent is to put dbus support in every possible package in the repository.
This is in fact what i claim.
Am I convicted now? What's the sentence?
That you read and reflect on the ideas archlinux was built on.
One of your removed patches is one that integrates use of ca-certificates in qt instead of the bundled certificates.
Ok you got me there. This IS a fix. It didn't work on 4.6 so i didn't bother investigating what it actually does. Sorry, my fault. -- Arvid Asgaard Technologies
Thanks to enough input i have learned two things of this thread: 1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it. Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally. 2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should 2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass The combination of 1 and 2 invalidates everything i have said in this thread. Jan did a great job at packaging clearly broken packages in the least harmful way for the majority of users, who happen to have a microsoft windows background. Sorry about being too ignorant to see these in the first place. I'll go do 2.1 or 2.2 now. have a nice day. -- Arvid Asgaard Technologies
On 02/12/09 09:55, Arvid Picciani wrote:
Thanks to enough input i have learned two things of this thread:
1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it.
Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally.
2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should 2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass
The combination of 1 and 2 invalidates everything i have said in this thread.
Jan did a great job at packaging clearly broken packages in the least harmful way for the majority of users, who happen to have a microsoft windows background.
Sorry about being too ignorant to see these in the first place. I'll go do 2.1 or 2.2 now. have a nice day.
lol, i didn't see that one coming.
On Wed, Dec 02, 2009 at 10:55:22AM +0100, Arvid Picciani wrote:
Thanks to enough input i have learned two things of this thread:
1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it.
Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally.
2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should 2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass
The combination of 1 and 2 invalidates everything i have said in this thread.
I think you are just reading more that what is said. Many GNU/Linux distros and Arch and Debian in particular are definitely not free Windows. I run Arch and Debian servers and desktops and have never install any of the gnome/kde stuff unless asked to on gunpoint. I use xmonad and share your dislike for hal/dbus. This however does not justify not having a decent PnP particulary when you want to install it for non-experts. To my eyes Arch has been quite snappy and minimalist, even made me switch from Debian stable on my laptop. It is definitely far better than the monstrosity of Ubuntu or Fedora. I dont know how you find it otherwise. Regards ppk
Piyush P Kurur wrote:
I use xmonad and share your dislike for hal/dbus. This however does not justify not having a decent PnP particulary
it would ...
when you want to install it for non-experts.
.. if what i THOUGHT archlinux is about (experts) was true. However you appear to agree that this is not the case (anymore?).
To my eyes Arch has been quite snappy and minimalist,
as you can read on this thread, that isn't actually a goal. I'm not sure WHAT it's goals are anymore, but i have been educated that it is NOT about: - power users - minimalism
switch from Debian stable on my laptop. It is definitely far better than the monstrosity of Ubuntu or Fedora. I dont know how you find it otherwise.
err yeah,.. i guess if you have other distros as comparison, arch feels like cake :D -- Arvid Asgaard Technologies
On Wed, Dec 02, 2009 at 11:28:37AM +0100, Arvid Picciani wrote:
Piyush P Kurur wrote:
switch from Debian stable on my laptop. It is definitely far better than the monstrosity of Ubuntu or Fedora. I dont know how you find it otherwise.
err yeah,.. i guess if you have other distros as comparison, arch feels like cake :D
Okey so you agree that Arch != Ubuntu. Now we have a way forward. Arvid's reply to me made me search for antidesktop (I did not know about such a movement) and I find this xorg-server-antidesktop 1.6.1.1 in AUR. Whatever happended to it I do not know. Arvid can you start maintainning it and may be give it the status that if finally makes to the official Arch repository ? You dont have to fork Arch for that. I for one would definitely use this instead of the standard xorg-server with hal/dbus as I have always been a xmonad + xterm + screen user. I think there is nothing wrong in having two xorg-server packages besides anitdesktop sounds so cool. Regards ppk
Piyush P Kurur wrote:
Okey so you agree that Arch != Ubuntu. Now we have a way forward.
heh yeah, sorry, that comparison is rather childish. I regret i responded to Thomas mail...
Arvid's reply to me made me search for antidesktop (I did not know about such a movement)
i have no idea how "official" that term is. its used by various projects to denote "not centered around traditional windows desktop ideas" and I find this xorg-server-antidesktop 1.6.1.1 yeah for example that.
in AUR. Whatever happended to it I do not know. Arvid can you start maintainning it
yes. in fact i just have to publish my local repository.
and may be give it the status that if finally makes to the official Arch repository ?
I'm uncertain about how to handle this right now. It would require a mediator for me to contribute to arch as i am incapable of finding common ground. You sound like you are able to do that?
You dont have to fork Arch for that.
yeah, a custom repo would work i think. I'd just grab official packages and remove stuff anyway.
I for one would definitely use this instead of the standard xorg-server with hal/dbus as I have always been a xmonad + xterm + screen user. I think there is nothing wrong in having two xorg-server packages besides anitdesktop sounds so cool.
well the work certainly is "cool" :D but it's a serious HCI concern brought up here. I think the original author of that phrase did write a good article about it, if i remember correctly. -- Arvid Asgaard Technologies
On Wed, Dec 02, 2009 at 12:03:36PM +0100, Arvid Picciani wrote:
and may be give it the status that if finally makes to the official Arch repository ?
I'm uncertain about how to handle this right now. It would require a mediator for me to contribute to arch as i am incapable of finding common ground. You sound like you are able to do that?
I am a mere user of Arch and as of now have not contributed in any way to the Arch system. Dont find myself, a hot headed fundamentalist, in the role of a mediator. But you can see your xorg-server-antidesktop into the official packages. Have a look at the wiki for AUR. It clearly says that packages start as being in AUR and then finally end up in the official repository after getting enough support. I think there are others who would also like to have a non hal/dbus xorg-servers. They will support you. But please don't fork Arch. The issue you pointed out is too minor, at least to me, to justify such a drastic action. If there aren't many supporters you AUR package will remain there. That should also be fine, after all world domination is never a goal with free software. It is just a side-effect. Regards ppk
On Wed, 2009-12-02 at 17:15 +0530, Piyush P Kurur wrote:
But you can see your xorg-server-antidesktop into the official packages. Have a look at the wiki for AUR. It clearly says that packages start as being in AUR and then finally end up in the official repository after getting enough support.
I think there are others who would also like to have a non hal/dbus xorg-servers. They will support you. But please don't fork Arch. The issue you pointed out is too minor, at least to me, to justify such a drastic action.
Disabling hal/dbus in xorg-server is a matter of one extra option in xorg.conf, so there's no need for such a package unless you absolutely hate hal and dbus so much that you don't want those packages to exist on your system. As for the config-dbus thing in xorg-server: I think we can remove it. It's not used by anything, and upstream has intentions to kill it anyways. As for hal support in xorg-server: Upstream is still debating about this, but in the future hal will get killed and xorg-server will use udev directly. They're still debating about details though, as configuration will have to move from hal .fdi files to somewhere else. This could be udev rules, xorg.conf or even an xorg.conf.d/*.conf implementation. Until upstream makes that switch, hal will remain a dependency.
Arvid Picciani schrieb:
Thanks to enough input i have learned two things of this thread:
1) The problem IS upstream related. Some packages do enable dbus when it is available, for the convenience of those users who do not understand what dbus is and hence need it.
So every user who wants to use dbus is dumb? Needing dbus is a criterion for not understanding what it is? dbus is something very cool and useful and allows applications to conveniently interoperate, which is something that has to happen in every modern computing environment.
Archs philosophy dictates, that if the upstream is retarded, so shall be the package. I used this as argument, and i shall comply to it equally.
In a sense yes, but we can make it less retarded to some extent.
2) I am in fact the minority, not those who see linux as a free windows copy. Hence i should
Insult number one, watch your step.
2.1) stfu and obey the will of the mass 2.2) find or found a distro that is not based on the will of the mass
Arch is not based on the will of the mass, but on the will of the developers who use and develop it. Those developers happen to want cool systems instead of feature-free ones. And you know what? I don't see your problem, because my system works just fine and does everything I want it to exactly like I want it to. For me, nothing else counts.
The combination of 1 and 2 invalidates everything i have said in this thread.
No, some of the things you have said are invalidated by them being just rants and stupid.
Jan did a great job at packaging clearly broken packages in the least harmful
He did, yes.
way for the majority of users, who happen to have a microsoft windows background.
Insult number two. I give you one piece of advice: Apologize for being an asshole. Resorting to calling what you don't like the "Ubuntu way of doing things" and calling the majority of Arch's developers "people with Windows background" doesn't help you here. In fact, I feel personally insulted by these statements. You can either apologize to me now or STFU and get yourself another distro - preferably one whose developers like being insulted like this. It is one thing to discuss the sense and nonsense of how we do things. It is another to be an asshole about it and insult the people who do not share your opinion. And there is one thing that Arch definitely does not need: assholes. And before people start bitching about what I just said: Statements like "Arch is becoming Ubuntu" and "Arch is for users who want a free Windows replacement" (and many similar ones) are made mostly because someone is out of arguments and wants to make the other end of the discussion angry (which Arvid succeeded in). I consider such statements an insult (not because Ubuntu or Windows are evil, but because Arch is very different from either of those and I am quite proud of that) and I will not tolerate such statements.
Thomas Bächler wrote:
Apologize for being an asshole.
I have not intended to insult arch developers, and i apologize if i did,..
You can either apologize to me now or STFU
to everyone but you, just to anger you. and get yourself another
distro
well i guess that settles any ultimatum prematurely. - preferably one whose developers like being insulted like this. like what? maybe you are feeling insecure about it? There is a saying in my native language that goes like: "Dogs only bite if you hit their spot." The other devs at least managed to respond in professional and calm way, which ultimately convinced me that they are right.
I consider such statements an insult
whine more... that's sure going to save your image.
but because Arch is very different from either of those and I am quite proud of that
and insecure.
and I will not tolerate such statements.
my address is publicly available. go find me? -- Arvid Asgaard Technologies
I don't think arch general list is the appropriated to fight like kids so please continue your little fight using your own personal email. On Wed, Dec 2, 2009 at 7:38 PM, Arvid Picciani <aep@exys.org> wrote:
Thomas Bächler wrote:
Apologize for being an asshole.
I have not intended to insult arch developers, and i apologize if i did,..
You can either apologize to me now or STFU
to everyone but you, just to anger you.
and get yourself another
distro
well i guess that settles any ultimatum prematurely.
- preferably one whose developers like being insulted like this.
like what? maybe you are feeling insecure about it? There is a saying in my native language that goes like: "Dogs only bite if you hit their spot."
The other devs at least managed to respond in professional and calm way, which ultimately convinced me that they are right.
I consider such statements an insult
whine more... that's sure going to save your image.
but because Arch is very different from either of those and I am quite proud of that
and insecure.
and I will not tolerate such statements.
my address is publicly available. go find me?
-- Arvid Asgaard Technologies
Arvid Picciani schrieb:
like what? maybe you are feeling insecure about it?
Yes, I am so insecure. You are right, I am going to kill myself just now.
There is a saying in my native language that goes like: "Dogs only bite if you hit their spot."
Old sayings like this are usually stupid.
The other devs at least managed to respond in professional and calm way, which ultimately convinced me that they are right.
Until now, I was professional and managed to ignore this thread completely. But you just had to pull the Windows card. You were trying to convince people that you were right by telling them "either you agree with me or you are just another Windows user who doesn't want to pay". That is not acceptable and breaks the rules of any discussion between grown-ups. Again: Comparisons like that just mean you are out of arguments and are still trying to convince people. Tell me why you think what we do is bad without mentioning Windows or Ubuntu or any comparison to anything and we can talk professionally.
but because Arch is very different from either of those and I am quite proud of that
and insecure.
Okay okay okay, after this e-mail I will definitely kill myself, sorry for keeping you waiting.
and I will not tolerate such statements.
my address is publicly available. go find me?
Don't bother - all I will do is be an ass about it every time.
Thomas Bächler wrote:
I consider such statements an insult
Sorry Thomas, my response was retarded. can you help me find another term i should use to denote the desktop idea, that is not offensive? I'll propably need it for further discussion, and prefer NOT to piss of people. "gnomies" "mouse users" etc is all the same level of offensiveness. I lack ideas here. -- Arvid Asgaard Technologies
On Wed, 02 Dec 2009 12:53:21 +0100 Arvid Picciani <aep@exys.org> wrote:
can you help me find another term i should use to denote the desktop idea, that is not offensive?
"integrationist" ?
On Wed, Dec 2, 2009 at 9:53 AM, Arvid Picciani <aep@exys.org> wrote:
"gnomies" "mouse users" etc is all the same level of offensiveness. I lack ideas here.
No, I think you just are furious because you can have things working without losing 5 days of your life. Maybe you are just old and until they make a time machine, you'll not be able to come back to the 70's and work like a "real man". Sorry, but I never understood this mindset of being against automatic configuratino when it makes sense. Why don't you just use dd for every read and write operation to the disk? Why do you need a filesystem? Pff.... Anyways, you should really try gnome or kde nowadays, you would be impressed. Maybe with a system without xorg.conf which recognizes automatically a new monitor when plugged in. This happened to me just the other day. Best whishes. -- ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani <aep@exys.org> wrote:
Thomas Bächler wrote:
I consider such statements an insult
Sorry Thomas, my response was retarded.
can you help me find another term i should use to denote the desktop idea, that is not offensive?
In general, it is called the WIMP paradigm - Windows, Icons, Menus, Pointing Device http://en.wikipedia.org/wiki/WIMP_(computing)
On Wed, 2009-12-02 at 11:06 -0600, Aaron Griffin wrote:
On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani <aep@exys.org> wrote:
Thomas Bächler wrote:
I consider such statements an insult
Sorry Thomas, my response was retarded.
can you help me find another term i should use to denote the desktop idea, that is not offensive?
In general, it is called the WIMP paradigm - Windows, Icons, Menus, Pointing Device http://en.wikipedia.org/wiki/WIMP_(computing)
Ouch, I'm sure that's a correct term, but I fail to see how using WIMP in a combustible conversation is going to help any =)
2009/12/2 Ng Oon-Ee <ngoonee@gmail.com>:
On Wed, 2009-12-02 at 11:06 -0600, Aaron Griffin wrote:
On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani <aep@exys.org> wrote:
Thomas Bächler wrote:
I consider such statements an insult
Sorry Thomas, my response was retarded.
can you help me find another term i should use to denote the desktop idea, that is not offensive?
In general, it is called the WIMP paradigm - Windows, Icons, Menus, Pointing Device http://en.wikipedia.org/wiki/WIMP_(computing)
Ouch, I'm sure that's a correct term, but I fail to see how using WIMP in a combustible conversation is going to help any =)
Yeah I just noticed the wiki page even points out that most people find it derogatory.
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua). And secondly, if you have stuff like hal/dbus running, it is not going to slow your system unless you are running it on your mobile or a 100MHz CPU. I have tried hal/dbus with and without. I don't see a noticeable latency. But disabling dbus can help in situations where you are not using that DM or some other reason.(for example - evince - i disable it, thunar - i disable it) Finally, true anti-desktop is using lynx or watching mplayer with ascii renderer :) , all in virtual terminal(with directfb if required) On Wed, Dec 2, 2009 at 10:41 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
2009/12/2 Ng Oon-Ee <ngoonee@gmail.com>:
On Wed, 2009-12-02 at 11:06 -0600, Aaron Griffin wrote:
On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani <aep@exys.org> wrote:
Thomas Bächler wrote:
I consider such statements an insult
Sorry Thomas, my response was retarded.
can you help me find another term i should use to denote the desktop idea, that is not offensive?
In general, it is called the WIMP paradigm - Windows, Icons, Menus, Pointing Device http://en.wikipedia.org/wiki/WIMP_(computing)
Ouch, I'm sure that's a correct term, but I fail to see how using WIMP in a combustible conversation is going to help any =)
Yeah I just noticed the wiki page even points out that most people find it derogatory.
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
(snipped)
The problem is that using ABS is impracticable if you have a big number of custom PKGBUILDs. OTOH, having packages with minimal dependencies isn't so great. During the (short) time I've used Gentoo, I noticed the consume of RAM is a little lower, but there isn't a big difference in performance. The problems arise when you compile packages with way to minimal dependencies, and later realize it was a mistake, and now you have to recompile lots of packages.
On Wed, Dec 2, 2009 at 3:40 PM, André Ramaciotti da Silva <andre.ramaciotti@gmail.com> wrote:
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
(snipped)
The problem is that using ABS is impracticable if you have a big number of custom PKGBUILDs.
OTOH, having packages with minimal dependencies isn't so great. During the (short) time I've used Gentoo, I noticed the consume of RAM is a little lower, but there isn't a big difference in performance. The problems arise when you compile packages with way to minimal dependencies, and later realize it was a mistake, and now you have to recompile lots of packages.
True. Although I favor minimalism, it's practically never worth actually doing anything to get it. Right now I've achieved zero use of both ABS and AUR. The resulting ease of maintenance totally trumps any gains I'd get by tweaking PKGBUILDs.
There is customizepkg in AUR which can greatly simplify and help. I agree that it is not practical to build everything(otherwise it will be a gentoo). However,what i have seen is dependencies are like A->B->C and C gets A added sometimes as dependency, in which case recompiling B alone should help. If it is 1 or 2 packages only, then build :) On Thu, Dec 3, 2009 at 2:10 AM, André Ramaciotti da Silva < andre.ramaciotti@gmail.com> wrote:
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
(snipped)
The problem is that using ABS is impracticable if you have a big number of custom PKGBUILDs.
OTOH, having packages with minimal dependencies isn't so great. During the (short) time I've used Gentoo, I noticed the consume of RAM is a little lower, but there isn't a big difference in performance. The problems arise when you compile packages with way to minimal dependencies, and later realize it was a mistake, and now you have to recompile lots of packages.
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
I don't think it is about not having a feature X. For example I think PnP is a worthwhile feature to have. But many do not like hal/dbus. Again the counter argument is that disabling hal/dbus is just an additional line in xorg.conf. Point well taken but if we can compile xorg-server package without hal/dbus enabled and then whomsoever wants to use hal/dbus make a small change in xorg.conf to facilitate it (I dont know whether this is possible) I would prefer such an xorg-server. Again it is purely my preference. Such an xorg-server, I think will be both ``minimalist'' and ``featurefull'' whatever those terms mean.
Finally, true anti-desktop is using lynx or watching mplayer with ascii renderer :) , all in virtual terminal(with directfb if required)
Yes many prefer lynx/w3m/elinks/edbrowse over other webbrowsers. But saying that anti-desktop means mplayer with ascii is just streatching it a bit too much. If you use screen + xterm + xmonad then you will, I hope, see the advantage of not using gnome/kde. Regards ppk
On Thu, 2009-12-03 at 11:34 +0530, Piyush P Kurur wrote:
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
I don't think it is about not having a feature X. For example I think PnP is a worthwhile feature to have. But many do not like hal/dbus. Again the counter argument is that disabling hal/dbus is just an additional line in xorg.conf. Point well taken but if we can compile xorg-server package without hal/dbus enabled and then whomsoever wants to use hal/dbus make a small change in xorg.conf to facilitate it (I dont know whether this is possible) I would prefer such an xorg-server. Again it is purely my preference. Such an xorg-server, I think will be both ``minimalist'' and ``featurefull'' whatever those terms mean.
It is not possible to turn on features which aren't compiled in. I presume you meant compiling it in but with it defaulting to not being used. This would both not satisfy those who don't want dbus/hal in the first place while also breaking those apps which DO need dbus/hal.
Finally, true anti-desktop is using lynx or watching mplayer with ascii renderer :) , all in virtual terminal(with directfb if required)
Yes many prefer lynx/w3m/elinks/edbrowse over other webbrowsers. But saying that anti-desktop means mplayer with ascii is just streatching it a bit too much. If you use screen + xterm + xmonad then you will, I hope, see the advantage of not using gnome/kde.
Anti-desktop, as a movement, is well and good. Linux is about choice, after all. Not restraining choice. Hence why its counter-productive for 'anti-desktop' followers to insist that those who don't agree with them be disadvantaged.
Piyush P Kurur wrote:
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
I don't think it is about not having a feature X. For example I think PnP is a worthwhile feature to have. But many do not like hal/dbus. Again the counter argument is that disabling hal/dbus is just an additional line in xorg.conf. Point well taken but if we can compile xorg-server package without hal/dbus enabled and then whomsoever wants to use hal/dbus make a small change in xorg.conf to facilitate it (I dont know whether this is possible) I would prefer such an xorg-server. Again it is purely my preference. Such an xorg-server, I think will be both ``minimalist'' and ``featurefull'' whatever those terms mean.
I blame this one on the upstream. Leaving X dead with default config and no dbus started is one of the worst solutions they could have come up with. Similar, my main argument against dbus is based on the fact that software will fail when configured but not run with dbus. "i dont want my software crashing because it requires a defect user space dameon for features i dont want anyway" is signifcantly different to: "i dont like feature X is wasting 2kb ram" But this is a free world and people are free to ignore the difference.
Finally, true anti-desktop is using lynx or watching mplayer with ascii renderer :) , all in virtual terminal(with directfb if required)
Yes many prefer lynx/w3m/elinks/edbrowse over other webbrowsers. But saying that anti-desktop means mplayer with ascii is just streatching it a bit too much. If you use screen + xterm + xmonad then you will, I hope, see the advantage of not using gnome/kde.
The general ignorance towards power user setups might explain why people describe us as "old timers who can't get along with change" or "ricers" funny thing is that the wimp desktop didnt change in 20 years while antidesktop brings new and fresh ideas all the time. Just think about keyboard-user browsers. THATS a HCI improvement. Guess where 10GUi got its ideas from.. It's a vim vs emacs argument though, ie a waste of time for everyone, and a nuisance if the discussion participants generally know only one side. Some people can't be educated, others are educated and chose a side based on own experience. I prefer the second kind, no matter which side they chose. -- Arvid Asgaard Technologies
Am Thu, 03 Dec 2009 07:16:47 +0100 schrieb Arvid Picciani <aep@exys.org>:
The general ignorance towards power user setups might explain why people describe us as "old timers who can't get along with change" or "ricers" funny thing is that the wimp desktop didnt change in 20 years while antidesktop brings new and fresh ideas all the time. Just think about keyboard-user browsers. THATS a HCI improvement. Guess where 10GUi got its ideas from..
There's no general ignorance towards power users. You generally ignore the desktop users. "The wimp desktop didn't change in 20 years" shows that you're really ignoring desktops and don't know anything about desktops. WIMP desktops have changed a lot not only in the last 20 years but also in the last 5 years. That's probably why such things like hal and dbus are necessary. fvwm2 is or at least was a good window manager but is indeed an "old timer". Compiling hal/dbus into xorg doesn't force you to use the mouse. You don't need to install xorg. Just keep using the console and the keyboard. I don't know if xmonad needs xorg. If yes hal/dbus wouldn't do any harm, too. Nobody detains you from using the keyboard. But if hal/dbus e.g. was removed from xorg then other users would be detained from using some software they need. There are not only console users but also desktop users. As I said before. If you really want a minimal system I'd suggest using Gentoo. But you will see that you will be forced to set several USE flags and rebuild several with minimal features built packages depending on what other packages you install e.g. hal/dbus. And nobody said that there haven't been improvements in anti-desktop in the last years. Heiko
Heiko Baums wrote:
If yes hal/dbus wouldn't do any harm, too. Nobody detains you from using the keyboard.
Just for the sake of proving the legatimicity of this project for those who still didnt get it: as an example. do you follow the irc channel? Somone just triggered the qgtkstyle bug that makes it assert when you dont run dbus and gconf. But you can't do that, as it conflicts with other software. fixing the bug on the other hand breaks gnome. I can provide the fix in antidesktop, as the users arent expected to run gnome. -- Arvid Asgaard Technologies
Am Thu, 03 Dec 2009 10:41:27 +0100 schrieb Arvid Picciani <aep@exys.org>:
as an example. do you follow the irc channel? Somone just triggered the qgtkstyle bug that makes it assert when you dont run dbus and gconf. But you can't do that, as it conflicts with other software. fixing the bug on the other hand breaks gnome. I can provide the fix in antidesktop, as the users arent expected to run gnome.
Do you know what a bug report is and what it is for? Heiko
Heiko Baums wrote:
Do you know what a bug report is and what it is for?
http://bugreports.qt.nokia.com/browse/QTBUG-5545 this is an upstream bug, and a workaround inaproppriate to apply to archs main repo, as i said. Please read mails entirely and assume good faith and intelligence, as i try to do. ( i know i fail at it from time to time, but i promise to try harder ) -- Arvid Asgaard Technologies
Am Thu, 03 Dec 2009 13:04:23 +0100 schrieb Arvid Picciani <aep@exys.org>:
Heiko Baums wrote:
Do you know what a bug report is and what it is for?
http://bugreports.qt.nokia.com/browse/QTBUG-5545
this is an upstream bug, and a workaround inaproppriate to apply to archs main repo, as i said.
Please read mails entirely and assume good faith and intelligence, as i try to do. ( i know i fail at it from time to time, but i promise to try harder )
You don't want to insult me, too, as you did with some other people here? Heiko
That mplayer with ascii was a joke :)...not a serious comment. On Thu, Dec 3, 2009 at 11:34 AM, Piyush P Kurur <ppk@cse.iitk.ac.in> wrote:
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote:
One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua).
I don't think it is about not having a feature X. For example I think PnP is a worthwhile feature to have. But many do not like hal/dbus. Again the counter argument is that disabling hal/dbus is just an additional line in xorg.conf. Point well taken but if we can compile xorg-server package without hal/dbus enabled and then whomsoever wants to use hal/dbus make a small change in xorg.conf to facilitate it (I dont know whether this is possible) I would prefer such an xorg-server. Again it is purely my preference. Such an xorg-server, I think will be both ``minimalist'' and ``featurefull'' whatever those terms mean.
Finally, true anti-desktop is using lynx or watching mplayer with ascii renderer :) , all in virtual terminal(with directfb if required)
Yes many prefer lynx/w3m/elinks/edbrowse over other webbrowsers. But saying that anti-desktop means mplayer with ascii is just streatching it a bit too much. If you use screen + xterm + xmonad then you will, I hope, see the advantage of not using gnome/kde.
Regards
ppk
http://heresy.asgaartech.com/ Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it. Contributors very welcome :) -- Arvid Asgaard Technologies
On 12/02/2009 08:19 PM, Arvid Picciani wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
you fail from start. your repo is called antidesktop but having xorg-server in your repo is pro desktop :D
On Wed, Dec 2, 2009 at 12:27 PM, Ionut Biru <ibiru@archlinux.org> wrote:
On 12/02/2009 08:19 PM, Arvid Picciani wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
you fail from start. your repo is called antidesktop but having xorg-server in your repo is pro desktop :D
The term "antidesktop" comes from an old freshmeat posting: http://freshmeat.net/articles/the-antidesktop
On Wed, Dec 2, 2009 at 12:19 PM, Arvid Picciani <aep@exys.org> wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
This is exactly in the spirit of the whole arch community thing. As an FYI, I may use your xorg-server package myself (I won't have to recompile it myself). The only change you made is to disable the hal stuff? The sole reason I still have an xorg.conf is so I can turn that option (AutoAddDevices) off. X detects my machine just fine except for that. Would you mind throwing the PKGBUILDs you use up there as well?
Aaron Griffin wrote:
On Wed, Dec 2, 2009 at 12:19 PM, Arvid Picciani <aep@exys.org> wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
This is exactly in the spirit of the whole arch community thing.
glad i finally did understand some parts of it :D
As an FYI, I may use your xorg-server package myself (I won't have to recompile it myself). The only change you made is to disable the hal stuff? The sole reason I still have an xorg.conf is so I can turn that option (AutoAddDevices) off. X detects my machine just fine except for that.
Would you mind throwing the PKGBUILDs you use up there as well?
of course. they are available on the linked bitbucket project. http://bitbucket.org/aep/arch-antidesktop/src/tip/xorg-server/PKGBUILD -- Arvid Asgaard Technologies
On Wed, Dec 2, 2009 at 12:29 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote:
Would you mind throwing the PKGBUILDs you use up there as well?
of course. they are available on the linked bitbucket project.
http://bitbucket.org/aep/arch-antidesktop/src/tip/xorg-server/PKGBUILD
Doh, didn't see that link at the bottom (PS typo on the web page s/wellcome/welcome/)
Aaron Griffin wrote:
On Wed, Dec 2, 2009 at 12:29 PM, Arvid Picciani <aep@exys.org> wrote:
Aaron Griffin wrote:
Would you mind throwing the PKGBUILDs you use up there as well?
of course. they are available on the linked bitbucket project.
http://bitbucket.org/aep/arch-antidesktop/src/tip/xorg-server/PKGBUILD
Doh, didn't see that link at the bottom
(PS typo on the web page s/wellcome/welcome/)
While we're at it s/apropriate/appropriate/ I'm not sure I'm ready for this system though. I'd like to think I'm not a Linux weakling, but poweruser? Not that powerful :) Hope it goes well though.
On Wed, Dec 02, 2009 at 12:27:09PM -0600, Aaron Griffin wrote:
Would you mind throwing the PKGBUILDs you use up there as well?
I'd be interested in these as well, just to compare to what is shipped by our maintainers.
The only change you made is to disable the hal stuff? The sole reason I still have an xorg.conf is so I can turn that option (AutoAddDevices) off. X detects my machine just fine except for that.
Since when does xorg support automatic device configuration without HAL? I
On Wed, Dec 2, 2009 at 1:27 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote: thought that without HAL you would need a complete xorg.conf just like the old days. Has this changed?
On Thu, Dec 3, 2009 at 3:12 PM, Robert Howard <howard.rob@gmail.com> wrote:
On Wed, Dec 2, 2009 at 1:27 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
The only change you made is to disable the hal stuff? The sole reason I still have an xorg.conf is so I can turn that option (AutoAddDevices) off. X detects my machine just fine except for that.
Since when does xorg support automatic device configuration without HAL? I thought that without HAL you would need a complete xorg.conf just like the old days. Has this changed?
It handles standard mice and keyboards just fine
On 12/2/09, Arvid Picciani <aep@exys.org> wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Regardless of the fact that I like this initiative, and might use some, I find the site too "boasty": "large user base" ... "for power users"... "unfixed packages that adhere to the arch way" I would be more humble. After all, you're "fixing" only an extremely small bit of the whole archlinux. Good luck, Jan
On Wed, Dec 2, 2009 at 7:33 PM, bender02 <bender02@archlinux.us> wrote:
On 12/2/09, Arvid Picciani <aep@exys.org> wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Regardless of the fact that I like this initiative, and might use some, I find the site too "boasty": "large user base" ... "for power users"... "unfixed packages that adhere to the arch way" I would be more humble. After all, you're "fixing" only an extremely small bit of the whole archlinux.
Good luck, Jan
Actually, I propose to change the catchphrase to "Arch Linux for Minimalists". There's plenty of power users (called so because they know a lot about the system) and prefer to use gnome/kde.
Arvid Picciani wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
Suggestions: 1. Rename all your packages appropriately (e.g. append -heresy or -nodbus or -whatever). This way your packages won't get unistalled if they lag behind the official ones. 2. Add your repo to the unofficial user repos at the wiki (http://wiki.archlinux.org/index.php/Unofficial_user_repositories) 3. Make x86_64 builds (remember, the main reason of UURs is convenience, so that people don't have to compile themselves - otherwise ABS/AUR would suffice) 4. Rewrite some stuff in "philosophy", being polite never hurt anyone. -- X.
On Mon, Dec 7, 2009 at 12:55 PM, Christos Nouskas <nous@archlinux.us> wrote:
Arvid Picciani wrote:
Let me know if this solution works for everyone and/or if anyone is offended by anything on that site or the fact that it exists and/or if anything should be added to it.
Contributors very welcome :)
Suggestions:
1. Rename all your packages appropriately (e.g. append -heresy or -nodbus or -whatever). This way your packages won't get unistalled if they lag behind the official ones.
No, this isn't how pacman works. If his repo comes before the official ones in pacman.conf, it will override them regardless of version comparisons.
Ray Kohler wrote:
Suggestions:
1. Rename all your packages appropriately (e.g. append -heresy or -nodbus or -whatever). This way your packages won't get unistalled if they lag behind the official ones.
No, this isn't how pacman works. If his repo comes before the official ones in pacman.conf, it will override them regardless of version comparisons.
I know, but why would anyone in their right mind put some tro^Wguy's custom repo _before_ the official ones, especially when the provided packages are not the nightly builds of <insert_your_fav_app> but ones like xorg-server? -- X.
On Tue, 2009-12-08 at 05:29 +0200, Christos Nouskas wrote:
Ray Kohler wrote:
Suggestions:
1. Rename all your packages appropriately (e.g. append -heresy or -nodbus or -whatever). This way your packages won't get unistalled if they lag behind the official ones.
No, this isn't how pacman works. If his repo comes before the official ones in pacman.conf, it will override them regardless of version comparisons.
I know, but why would anyone in their right mind put some tro^Wguy's custom repo _before_ the official ones, especially when the provided packages are not the nightly builds of <insert_your_fav_app> but ones like xorg-server?
In the preceding conversations some have said they would. The whole point of his repo is to maintain separate versions of xorg-server sans some bloat.
Ng Oon-Ee wrote:
I know, but why would anyone in their right mind put some tro^Wguy's custom repo _before_ the official ones, especially when the provided packages are not the nightly builds of <insert_your_fav_app> but ones like xorg-server?
In the preceding conversations some have said they would. The whole point of his repo is to maintain separate versions of xorg-server sans some bloat.
IMO, custom packages providing different functionality (or having important different dependencies for that matter) should have different names, e.g. nvidia-beta, kernel26-bfs, skype-oss, [kdemod-*], [nightly]. At the very least, it allows for for faster troubleshooting. Again, IMO. -- X.
On Tue, 2009-12-08 at 06:39 +0200, Christos Nouskas wrote:
Ng Oon-Ee wrote:
I know, but why would anyone in their right mind put some tro^Wguy's custom repo _before_ the official ones, especially when the provided packages are not the nightly builds of <insert_your_fav_app> but ones like xorg-server?
In the preceding conversations some have said they would. The whole point of his repo is to maintain separate versions of xorg-server sans some bloat.
IMO, custom packages providing different functionality (or having important different dependencies for that matter) should have different names, e.g. nvidia-beta, kernel26-bfs, skype-oss, [kdemod-*], [nightly]. At the very least, it allows for for faster troubleshooting. Again, IMO.
=) There's been plenty of opinions in this discussion. I'd tend to agree that different names for significantly different functionality/patching is necessary, but for some compile-time options REMOVING functionality? Probably still a yes, but much more open to interpretation.
On Tue, Dec 1, 2009 at 8:02 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Oh shit, seriously? Looks like I'll have to rebuild this as well.
Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage...
I just noticed there is a decent section on the wiki about this subject : http://wiki.archlinux.org/index.php/Xorg_input_hotplugging#Rationale Digging a bit more, I also found a similar page on debian wiki which might be even more interesting : http://wiki.debian.org/XStrikeForce/InputHotplugGuide The fun part is that the end of the article actually gives a reference to arch wiki page. Debian also have a bunch of "we do not need hal" whiners, which lead to a bug report. And for example this answer from a developer is also informative : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515214#91 I have yet to see someone serious and informed saying input hotplug sucks. All xorg developers I have seen (on the web : ML, blogs, irc, ...) seem to agree this new infrastructure is much better. Anyway hal is dead : http://wiki.x.org/wiki/Events/XDC2009/Notes?highlight=%28hal%29|%28udev%29#head-75cccc4e4968dd043dcf2166dff61afd7d0d06c5 But since that functionality is definitely needed, it will have to be replaced.. somehow.
On Tue, Dec 1, 2009 at 7:26 PM, Xavier <shiningxc@gmail.com> wrote:
I have yet to see someone serious and informed saying input hotplug sucks. All xorg developers I have seen (on the web : ML, blogs, irc, ...) seem to agree this new infrastructure is much better.
Just to be clear, I am one of the "whiners". I never once claimed that the hal integration is useless, and such is the reason I never attempted to get rid of it from the Arch package. However, the hal integration is 100% useless *for me*. There's an important distinction there
Why is hal dead? More information on this and on "libudev"? Vlad --
On Wed, 2009-12-02 at 03:09 +0100, vlad wrote:
Why is hal dead? More information on this and on "libudev"?
Vlad
I'd like to know more about this as well. The articles I've found online seem more marketing than details orientated (udev will cook your lunch while paying your income tax stuff).
It seems that devicekit will replace some functions of hal, while udev replaces some other parts. But I don't know much further details either. Maybe a roadmap would make all these stuff clear~ Regards 2009/12/2 Ng Oon-Ee <ngoonee@gmail.com>:
On Wed, 2009-12-02 at 03:09 +0100, vlad wrote:
Why is hal dead? More information on this and on "libudev"?
Vlad
I'd like to know more about this as well. The articles I've found online seem more marketing than details orientated (udev will cook your lunch while paying your income tax stuff).
-- LI Ye M.S. Student School of Information Science and Engineering Southeast University, P.R. China liye@seu.edu.cn
On Tue, 2009-12-01 at 19:57 -0600, Aaron Griffin wrote:
On Tue, Dec 1, 2009 at 7:26 PM, Xavier <shiningxc@gmail.com> wrote:
I have yet to see someone serious and informed saying input hotplug sucks. All xorg developers I have seen (on the web : ML, blogs, irc, ...) seem to agree this new infrastructure is much better.
Just to be clear, I am one of the "whiners". I never once claimed that the hal integration is useless, and such is the reason I never attempted to get rid of it from the Arch package. However, the hal integration is 100% useless *for me*. There's an important distinction there
Seems to be the most reasonable approach.
On Wed, 2 Dec 2009 02:26:39 +0100 Xavier <shiningxc@gmail.com> wrote:
On Tue, Dec 1, 2009 at 8:02 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Oh shit, seriously? Looks like I'll have to rebuild this as well.
Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage...
I just noticed there is a decent section on the wiki about this subject : http://wiki.archlinux.org/index.php/Xorg_input_hotplugging#Rationale
Digging a bit more, I also found a similar page on debian wiki which might be even more interesting : http://wiki.debian.org/XStrikeForce/InputHotplugGuide The fun part is that the end of the article actually gives a reference to arch wiki page.
Debian also have a bunch of "we do not need hal" whiners, which lead to a bug report. And for example this answer from a developer is also informative : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515214#91
I have yet to see someone serious and informed saying input hotplug sucks. All xorg developers I have seen (on the web : ML, blogs, irc, ...) seem to agree this new infrastructure is much better.
Anyway hal is dead : http://wiki.x.org/wiki/Events/XDC2009/Notes?highlight=%28hal%29|%28udev%29#head-75cccc4e4968dd043dcf2166dff61afd7d0d06c5 But since that functionality is definitely needed, it will have to be replaced.. somehow.
Isn't that somehow going to be device-kit? If so, we won't get rid of dbus.
On Wed, 2009-12-02 at 16:40 +0100, hollunder@gmx.at wrote:
On Wed, 2 Dec 2009 02:26:39 +0100 Xavier <shiningxc@gmail.com> wrote:
Anyway hal is dead : http://wiki.x.org/wiki/Events/XDC2009/Notes?highlight=%28hal%29|%28udev%29#head-75cccc4e4968dd043dcf2166dff61afd7d0d06c5 But since that functionality is definitely needed, it will have to be replaced.. somehow.
Isn't that somehow going to be device-kit? If so, we won't get rid of dbus.
Is that really a goal? Seems like the holy grail sometimes, getting rid of dbus.
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote:
nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal
Looks like nobody ever reads documentation. Read the freaking wiki link posted when upgrading/installing xorg-server and you'll know you can disable hal interaction from xorg.conf with one single option. Is it that hard?
Jan de Groot wrote:
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote:
nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal
Looks like nobody ever reads documentation. Read the freaking wiki link posted when upgrading/installing xorg-server and you'll know you can disable hal interaction from xorg.conf with one single option. Is it that hard?
hah there he is seeking the frontal battle. counter point: Looks like no one ever reads mails completely before assuming the other side is a complete moron. Where did i say i have a problem related to that upgrade? In fact, let me requote that to prove you didnt read it.
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote:
The difference is that previously you could get get away with a hack in xorg.conf
Jan de Groot wrote:
and you'll know you can disable hal interaction from xorg.conf with one single option.
Thanks for being so smart and education me though! -- Arvid Asgaard Technologies
On Tue, 01 Dec 2009 23:58:20 +0100 Arvid Picciani <aep@exys.org> wrote:
Jan de Groot wrote:
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote:
nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal
Looks like nobody ever reads documentation. Read the freaking wiki link posted when upgrading/installing xorg-server and you'll know you can disable hal interaction from xorg.conf with one single option. Is it that hard?
hah there he is seeking the frontal battle.
counter point: Looks like no one ever reads mails completely before assuming the other side is a complete moron. Where did i say i have a problem related to that upgrade? In fact, let me requote that to prove you didnt read it.
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote:
The difference is that previously you could get get away with a hack in xorg.conf
Jan de Groot wrote:
and you'll know you can disable hal interaction from xorg.conf with one single option.
Thanks for being so smart and education me though!
You know, it's really hard to take you seriously (or not being angry at you) when you keep insulting Arch developers like this, especially when one considered that all of your "demands", your complains, is really nothing new. "Arch is not minimalist enough?" "Arch is no longer being KISS?" These are all ages-old complains that have been discussed and debunked to death a lot of time before. The only _new_ things about your... "rant" are the unprecedented rudeness and the grudge that you've seem to harbor against some of the devs. Seriously, no one from the dev team should have to put up this...
On 12/01/2009 01:43 PM, Arvid Picciani wrote:
obviously i do NOT want to remove xorg-server.
i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either.
the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1
thanks
why you want to remove evdev? if you use autodetecting thing from xorg you need that. in other case just install xf86-input-keyboard and xf86-input-mouse.
participants (35)
-
Aaron Griffin
-
Allan McRae
-
André Ramaciotti da Silva
-
Arvid Picciani
-
bender02
-
christopher floess
-
Christos Nouskas
-
Daenyth Blank
-
Denis A. Altoé Falqueto
-
Dwight Schauer
-
fons＠kokkinizita.net
-
Geoff
-
Giovanni Scafora
-
Heiko Baums
-
hollunder＠gmx.at
-
Ionut Biru
-
Jan de Groot
-
Jeroen Op 't Eynde
-
Juan Diego
-
LI Ye
-
ludovic coues
-
Lukáš Jirkovský
-
Nathan Wayde
-
Ng Oon-Ee
-
Piyush P Kurur
-
Raghavendra Prabhu
-
Randy Morris
-
Ray Kohler
-
Robert Howard
-
Smith Dhumbumroong
-
Sven-Hendrik Haase
-
Sébastien Leblanc
-
Thomas Bächler
-
vlad
-
Xavier