- Arch-general - lists.archlinux.org

[arch-general] Hardcoded or not
by gan lu 08 Apr '08

08 Apr '08

I put my words here but it's just my opinion: 1. Arch's devs are great and cute. 2. I am against to hardcoded-things. 3. If possible, I prefer what has been hardcoded in file system mounting should put int one file: fstab. 4. Should I open a bug tracker for the discussion.

2 1

Re: [arch-general] signoff kernel26-2.6.24.3-6
by RedShift 08 Apr '08

08 Apr '08

Simo Leone wrote: > On Mon, Mar 24, 2008 at 07:28:13PM +0100, Tobias Powalowski wrote: >> Users are happy with the new ISOs, just read the Forum thread about it. >> > You know what. I don't care if the users are happy with the new ISOs. > That's right, I finally said it. > _I DON'T CARE_ > > I don't care because _I_ am not happy with them. As someone who can see > that from a technological standpoint, it's a marvel that they even work, > that is, as a software developer, I'm ashamed to be associated with such > a shoddy product. > > I've offered alternatives, hell I've spent a lot of time offering > alternatives, built on more solid software enginerring principles > than "Users are Happy", but no one around here, save Dan and Aaron, who > just happen to be code contributors, seems to give a damn. What's up > with that? > *** Prelude *** This discussion was started when tpowa was asking for a signoff on the kernel26 package, which includes patches for an out-of-tree kernel module for a certain wireless card. *** What Dan McGee said *** I have an Eee, I managed to pull off an FTP install just fine. I compiled the driver by hand, just as has always been the case for out-of-tree driver with Arch if there is not already a separate package for it. I did this 22 months ago for my zd1211 wireless stick before it was in the mainline kernel, and I had *0 days of desktop linux experience* at that time (on my own machine). 0 days. And now we bend over backwards for someone needing a driver? Ugh. I thought April fools and the rename to Newb Linux wasn't for another week. -Dan *** My response *** I find myself in 100% agreement on Simo's and Dan's opinion. I've warned for this situation before (see the bug tracker). An example should be taken from CRUX, they've held true to their principles and said screw those who don't agree. And they're right, otherwise we're just on the road to the next Ubuntu. Lots of software is patched nowadays, even for very stupid things most of the old user base wouldn't have cared about. And when PKGBUILDs starts to grow to the point they need scrolling and comments to be clarified, that's just going the wrong way. (Hint, kernel26 PKGBUILD). I wanted to steer clear of personal attacks but unfortunately, tpowa has been a large contributer to the "lets adapt to the community"-style. I'm sorry to say it, but that's how I experience it (because of his work on kernel26 and qt) - and it needs to be said! Arch used to be different. I wouldn't be very surprised if Judd raised eyebrows on what's been going on lately. Notice the large influx of new users. The fact alone that a topic has been started for a stable package repository *and people are willing to contribute to this*, shows the kind of users we're getting: the wrong ones. There has been an ongoing discussion on the bug tracker whether or not post uninstall scripts should stop daemons upon removal. These ideas come from users that are either inexperienced, or trying to mold Arch in something its not. And what about dependencies in initscripts... wtf? Any sane user can find them out for themselves and put them in the right order in rc.conf. What if someone doesn't want this behaviour? For example I don't want dbus and hal started, but what if the kdm rc.d script will do this for me? It ends up with a pretty big mess. Let alone the complexity that is added to the initscripts. What Arch needs, is to say NO to things. There will always be users that disagree, can't use some package because it doesn't fit them. Especially the kernel, all these half-baked largely untested patches for things only a few people (or even just 1) use is a threat to the stability of the kernel package. I've had my share of hardware that didn't work for me, these issues are solved by either compiling your own kernel, replacing the hardware or simply waiting for the next kernel release. But adding largely untested and nobody-knows-where-it-came-from patches to the kernel is *evil*. Another example is the addition of the uucp group by default to /etc/groups. The number of users that use dailup and faxing is *so limited*. And they can just as well addgroup themselves. But meanwhile, all the other users have to take this uucp crap on a default install. And don't say they can groupdel afterwards, Arch is supposed to be slim BY DEFAULT. If people need to start removing crap after they've installed Arch, then something is definitely wrong. What Arch needs is to have strict guidelines on PKGBUILDs and kick out any developers that don't have the same idea. A proposition: * Patches are unacceptable unless in the case the software wouldn't work *at all* (Hint, qt PKGBUILD) * Pre and post install/remove actions should be kept at a minimum. Assume the user is smart (quite the opposite of the current trend). Everybody can read the manpage to adduser and addgroup. Post install echos pointing out small hints to get going quickly is acceptable * Stress the fact that users must read pacman's output and the news. Alot of problems on IRC are related to the fact that people are lazy and don't read pacman's output _at all_. That's their own damn fault * No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...) * Bugs and other issues that come from upstream, _should be fixed upstream_. If people do have problems with a certain issue, they can abs and makepkg themselves. (See rule 1) * No branding or "Arch defaults". It only makes the PKGBUILDs more complex, and ruins the idea of the software coming in its original form from the authors Another point of interest may be that many people used to find gnome coming "ugly" by default (I don't know if this still the case). So what? Selecting your own theme is just a few mouse clicks away. Arch should never come with a fscked up KDE or Gnome profile like Ubuntu and others do. In fact, packages should *always* come with the defaults shipped by upstream. That being said, there's no such thing as one size fits all. There will *always* be users that "fall out of the boat" (a Dutch expression). But the fact is, because of Arch's simplicity, Arch can be made to work for these people in a very easy way. But when you have a kernel26 PKGBUILD that's 320 lines long, that simplicity is gone. The users should adapt to Arch, not the other way around. Glenn

21 37

[arch-general] arch and xen = awesome
by Arvid Ephraim Picciani 07 Apr '08

07 Apr '08

btw. something positive: anyone following the xen mailing list? half of the problems are becouse somone fucked something really badly downstream. like an automatic kernel install script that overwrites your grub config, becouse it is oh so much smarter then a human. wuuush production server gone. yay. arch doesn't have those problems. guess why? thanks for all those years of assuming humans are smarter then scripts! -- best regards Arvid Ephraim Picciani

2 1

Re: [arch-general] [arch-dev-public] initscripts changes
by RedShift 07 Apr '08

07 Apr '08

Thomas Bächler wrote: > I am hacking initscripts and can't quite decide on two issues: > > 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. > 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 > from rc.sysinit. > > Can I get opinions on these? > Thomas, Having read your last e-mail you are right, I should have *pointed out* my opinion instead of going omgwtf. The thread resulted in savagery - nowhere near civilized. I apologize for that. I will try and keep my e-mails more professional. Glenn

3 2

[arch-general] graphviz needs to come out of testing for gnome-2.22 upgrade
by Neil Darlow 07 Apr '08

07 Apr '08

Hi, graphviz-2.18 is a dependency of anjuta and currently it's stuck in testing. Looking at its repo information it appears to be maintainerless. Could someone please progress it out of testing. Thanks. Regards, Neil Darlow

1 0

Re: [arch-general] [arch-dev-public] initscripts changes
by Giovanni Scafora 07 Apr '08

07 Apr '08

2008/4/6, Thomas Bächler <thomas(a)archlinux.org>: > 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 from > rc.sysinit. +1 here. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania(a)gmail.com

1 0

[arch-general] RIT.EDU New Mirror
by Lee R. Burton 06 Apr '08

06 Apr '08

http://mirror.rit.edu/archlinux Supports ftp and rsync as well, I would like to make it an official mirror. (do you all do push mirroring?) Located Rochester, NY, USA ~200mbps, Academic backbone No IPV6 yet... Is there any other information needed? --- Lee Burton lburton(a)mrow.org 301 910 0246

4 5

[arch-general] How to create archlinux install CD?
by Karolina Lindqvist 05 Apr '08

05 Apr '08

I have a new i586 machine and want to install archlinux i586 on it. So I want to recreate the archlinux install CD. But how do i do it? I have unpacked the install ISO, and is replacing all the packages, but when it comes to inird.img, the instructions in the wiki do not work. I cannot mount the unzipped inird.img. What should I do? file say that it is a cpio archive, but how do I unpack and mount it? And then, what is lowcore.img? Of course I could do it by booting debian, or something, and then replacing it with archlinux, but actually having an archlinux install CD would be pretty handy for my i586 machines.

6 6

[arch-general] initscripts-splash
by Elia Yehuda 05 Apr '08

05 Apr '08

Hey all, as been advised before to use the new functions.d functionality i've wrote a splashy functions file which seems to work pretty well. one problem though - since the /etc/rc.d/functions file only expose the source_functions function and doesn't actually execute it, all the functions.d/* files will be ignored unless the source_functions is specifically being called to. this raise a problem with progressing the progress-bar when starting the daemons in rc.multi - since i was trying to keep the initscripts intact and not change any of the scripts, ive recreated add_daemon in my functions.d/splashy file which does increment the progress bar, but functions.d/splashy will be ignored since all the daemon scripts simply source /etc/rc.d/functions but dont call the source_functions. the only solution i could find was to call source_functions within /etc/rc.d/functions itself which means whenever /etc/rc.d/functions is being sourced, source_functions will be called too. i would like to know the cons for this behavior and whether this shouldn't be the default behavior anyway. also, if someone has a better alternative to make rc.multi/daemons be aware of splashy or the functions.d/* files i'll be glad to hear. Blessings, z4ziggy

1 0

[arch-general] HP C3180 connected using usb no longer works
by Neil Darlow 04 Apr '08

04 Apr '08

Hi, My HP C3180, connected using usb, has recently stopped working. I'm not sure if it's related to recent changes in udev. lsusb -vv gives: Bus 002 Device 007: ID 03f0:5611 Hewlett-Packard PhotoSmart C3180 ls -l /dev/usbdev2.7 gives: crw-rw-rw- 1 root lp 189, 134 2008-04-04 19:40 /dev/usbdev2.7 My groups setting is: sys tty lp wheel network video audio optical storage scanner camera power users neil I am using udev-119-1, foomatic-db-hpijs 20080211-1 and cups-1.3.7-1 on i686. Any suggestions as to where to look for debugging this would be appreciated. I recall having to do this once before. Regards, Neil Darlow

1 0