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

2009/12/1 Arvid Picciani :

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.

Aaron Griffin wrote:

On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank wrote:

...

2009/12/1 Arvid Picciani :

...

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

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

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 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

Aaron Griffin wrote:

On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani 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

Giovanni Scafora wrote:

2009/12/1, Arvid Picciani :

...

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

Aaron Griffin wrote:

On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani 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 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.

Giovanni Scafora wrote:

2009/12/1, Ng Oon-Ee :

...

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 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

Ray Kohler wrote:

2009/12/1 Ng Oon-Ee :

...

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

Please, stop filling my inbox with useless junk.

On Thu, Dec 3, 2009 at 9:28 PM, 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 -------------------------------------------

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

Am Fri, 04 Dec 2009 00:49:14 +0100 schrieb Arvid Picciani :

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

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.

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.

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.

2009/12/3 Ng Oon-Ee :

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 -------------------------------------------

Arvid: Linux from scratch.

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

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

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".

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

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.

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 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

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

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

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.

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 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

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, Dec 2, 2009 at 9:53 AM, Arvid Picciani 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, 2009-12-02 at 11:06 -0600, Aaron Griffin wrote:

On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani 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 =)

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 wrote:

2009/12/2 Ng Oon-Ee :

...

On Wed, 2009-12-02 at 11:06 -0600, Aaron Griffin wrote:

...

On Wed, Dec 2, 2009 at 5:53 AM, Arvid Picciani 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 Wed, Dec 2, 2009 at 3:40 PM, André Ramaciotti da Silva 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.

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

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

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

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

That mplayer with ascii was a joke :)...not a serious comment. On Thu, Dec 3, 2009 at 11:34 AM, 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.

...

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 12/02/2009 08:19 PM, Arvid Picciani wrote:

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 :)

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:19 PM, Arvid Picciani wrote:

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 :)

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?

On Wed, Dec 2, 2009 at 12:29 PM, Arvid Picciani 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/)

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.

On Thu, Dec 3, 2009 at 3:12 PM, Robert Howard wrote:

On Wed, Dec 2, 2009 at 1:27 PM, Aaron Griffin 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 Wed, Dec 2, 2009 at 7:33 PM, bender02 wrote:

On 12/2/09, Arvid Picciani wrote:

...

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.

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.

On Mon, Dec 7, 2009 at 12:55 PM, Christos Nouskas wrote:

Arvid Picciani wrote:

...

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 :)

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.

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 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.

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 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 7:26 PM, Xavier 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

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).

On Tue, 2009-12-01 at 19:57 -0600, Aaron Griffin wrote:

On Tue, Dec 1, 2009 at 7:26 PM, Xavier 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, 2009-12-02 at 16:40 +0100, hollunder@gmx.at wrote:

On Wed, 2 Dec 2009 02:26:39 +0100 Xavier 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.

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