Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises (was: xf86-input-evdev conflicts with xorg-server. Remove xorg-server?)
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. a...@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: a...@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 a...@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot j...@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. a...@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.
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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?
Re: [arch-general] Another rant on arch way abuse and false promises
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 a...@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot j...@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. a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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 a...@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot j...@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. a...@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.
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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.
Re: [arch-general] Another rant on arch way abuse and false promises
Am Wed, 02 Dec 2009 09:13:59 +0100 schrieb Arvid Picciani a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
On Wed, 2009-12-02 at 10:30 +0100, Arvid Picciani wrote: 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 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
Re: [arch-general] Another rant on arch way abuse and false promises
Am Wed, 02 Dec 2009 10:35:59 +0100 schrieb Arvid Picciani a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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.
Re: [arch-general] Another rant on arch way abuse and false promises
On Wed, Dec 2, 2009 at 3:31 AM, Allan McRae al...@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.
[arch-general] Another rant on arch way abuse and false promises (was: xf86-input-evdev conflicts with xorg-server. Remove xorg-server?)
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. a...@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: a...@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 a...@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot j...@archlinux.org and bias a...@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
Re: [arch-general] Another rant on arch way abuse and false promises (was: xf86-input-evdev conflicts with xorg-server. Remove xorg-server?)
On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani a...@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.
Re: [arch-general] Another rant on arch way abuse and false promises
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
Giovanni Scafora wrote: 2009/12/1, Arvid Picciani a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
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.
Re: [arch-general] Another rant on arch way abuse and false promises
2009/12/1, Ng Oon-Ee ngoo...@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
Re: [arch-general] Another rant on arch way abuse and false promises
Giovanni Scafora wrote: 2009/12/1, Ng Oon-Ee ngoo...@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
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 5:27 PM, Arvid Picciani a...@exys.org wrote: Giovanni Scafora wrote: 2009/12/1, Ng Oon-Ee ngoo...@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.
Re: [arch-general] Another rant on arch way abuse and false promises
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani a...@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
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 5:30 PM, Arvid Picciani a...@exys.org wrote: Aaron Griffin wrote: On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani a...@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 Looks ok to me. Thanks.
Re: [arch-general] Another rant on arch way abuse and false promises
2009/12/1 Ng Oon-Ee ngoo...@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.
Re: [arch-general] Another rant on arch way abuse and false promises
Ray Kohler wrote: 2009/12/1 Ng Oon-Ee ngoo...@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
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 6:46 PM, Arvid Picciani a...@exys.org wrote: Ray Kohler wrote: 2009/12/1 Ng Oon-Ee ngoo...@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.)
Re: [arch-general] Another rant on arch way abuse and false promises
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
Re: [arch-general] Another rant on arch way abuse and false promises
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.
