Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
It would appear that on Mar 15, Damien Churchill did say:
http://wiki.archlinux.org/index.php/Beginners'_Guide is always a good
place to start.
Yeah, I guess maybe I woulda if only my brain hadn't run out of steam. Now
that I've looked a little closer at it than the quick glance I did
pre-install I've gotta agree, I shoulda started there...
It would appear that on Mar 15, Ananda Samaddar did say:
The wiki is your friend:
When your right... Your right! Now that I've looked a little closer, I have
to admit that the wiki (at least the one for Arch Linux) appears to be
overflowing with good stuff that I'm embarrassed to say I didn't notice.
http://wiki.archlinux.org/index.php/Beginners%27_Guide
http://wiki.archlinux.org/index.php/Xfce4
http://wiki.archlinux.org/index.php/Firefox
And thanks for the additional links :) I couldn't ask for better.
you can use Lynx to view these in the console:
pacman -S lynx
Whoa! It's been so long since I used lynx that I kinda forgot about it. I
didn't give up on it easy though. It's just that so much of the web is
specifically designed for graphical browsers. But I suppose that I should
have realized that wiki pages tend to be formatted properly. And looking
at Arch's wiki with lynx is, well, beautiful... I guess lynx is back in my
vocabulary.
It would appear that on Mar 15, Jeffrey Parke did say:
Have you read the beginners guide? It's a great help for times like these,
I'll post it below. Well what you wanna do now is to install the xorg group
(pacman -S xorg) then the xfce group (pacman -S xfce4). Then move the .xinitrc
file to your home folder (cp /etc/skel/.xinitrc/ /home/user/.xinitrc); edit
this file to so that the line with startxfce4 is uncommented (in other words
has a '#' in front of it. Finally, run 'startx'
But do read the beginners guide, it is a very nice page that details all of
these steps and more.
Thanks, for the info. Incidentally, I am familiar with using startx. But I
wouldn't have
thought to look in /etc/skel for a sample .xinitrc with initialization details
for the
most recent desktop installed. Does that also happen when other desktop/window
managers
such as e17 or kde are installed?
While I spend most of my computer time inside some GUI desktop... I always
prefer
to boot to a console and use startx when and if I'm ready. I'll likely wind up
starting XFCE with a script that if I select xfce will do a:
cp ~/xintrc-xfce ~/.xinitrc startx
It would appear that on Mar 15, Guus Snijders did say:
Actually, you should /remove/ the '#' from the start of that line... ;)
It would appear that on Mar 15, Jeffrey Lynn Parke Jr. did say:
that's exactly what I said, just wanted to make sure he new what a comment
was.
Actually THAT I do understand. But I'm guessing you get more refugees from other
GUI configured distros that don't than do... I always did think it was dumb to
replace well commented human readable config files with GUI only configs.
Especially when a GUI can just as easily be written to parse modify or at
least
rewrite such a file as to hide all the settings away someplace where you can't
edit
them by hand. But from what I've seen of Arch so far I think I may just be
preaching to the choir...
It would appear that on Mar 15, Ond?ej Ku?era did say:
I don't know much about xfce, being a KDE user, but start by looking at
/var/log/pacman.log. It should tell you what packages actually were installed
or which errors occured.
Thanks... Just had a peek at the log, and evidently the error wasn't significant
enough to be mentioned there. And all it says about xfdesktop is:
[2010-03-15 01:29] installed xfdesktop (4.6.1-1)
Or for a basic troubleshooting you could try a terminal-based browser, such as
links. It's not much, but at least ArchLinux wiki will be perfectly readable.
Yeah, since ArchLinux wiki is evidently so well designed for text based
browsers
I think I'll go with lynx (for nostalgic reasons) And I will do so not only
because I haven't got a GUI up on Arch yet, But because the test I just ran
from my PCLinuxOS install tells me that it's actually easier on the eyes
to read ArchLinux's wiki with lynx than with opera... Whoda thunk it?
It would appear that on Mar 15, Peter Cannon did say:
You don't need to understand the *Order* in Arch either?
Good! Since pacman is supposed to resolve dependencies I hadn't thought I'd
have to until installing the xfdesktop, didn't pull in enough of it's
dependencies to run it... But armed with the wiki links above I'm sure I'll
figure out what I did wrong.
I installed mc and vim without a problem. Then I thought it would be nice
if I could get a desktop up.
Well it would those are non GUI apps as you know with your opensuse ect
experience.
Yeah they (like alpine {my chosen mail client}) don't require a GUI to run.
But I've
yet to find a GUI tool that I like to use instead of any of them. I suppose I
would
survive if I absolutely had to
Re: [arch-general] Btrfs more than twice as fast compared to ext4
On 16/03/10 00:48, Shridhar Daithankar wrote:
[...]
But as far as file system performance goes, the overhead should be identical
for both the runs, no?
I'm not too sure about that. I'm guessing there is less seeking going on
with Btrfs. Some files systems (reiserfs + reiserfs4 IIRC) are very good
with many small files, better than the ext*fs, this may be another case
of that.
Besides, I need to run the comparison(rather verification of file contents)
many times over during the application life-cycle and I cannot afford to bring
in another copy from disk. The working set is expected to be 30-40GB at a
time, 3GB is just test setup.
With md5sum, I can store it in database and verify it on one copy only.
Fair enough.
And finally, it is terrible on timings. Running md5sum is lot faster, about 3
times in the best case.
[...]
wow, that's slow!
So when the source file system is btrfs, it is still couple of times faster at
least.
I still think you could achieve better times by not calling the external
command that many times.
Since you're already gonna store the checksums in a database, I'd just
write a proper program in python or something.
Or even just a shellscript, but you might wanna refrain from for .. in
`find .. , it's the slowest and that relies on the fact that your
filenames don't have spaces in them.
[[ky] ~]# }} time find /usr/bin -type f -print0 | xargs -0 md5sum /tmp/1
real0m3.633s
[[ky] ~]# }} time find /usr/bin -type f -exec md5sum {} \; /tmp/2
real0m10.196s
[[ky] ~]# }} time for i in `find /usr/bin -type f`;do md5sum $i;done
/tmp/3
real0m11.245s
this last version missed a file because it has spaces in its name and as
result the file 3 was inconsistent with files 1 and 2
[[ky] ~]# }} diff /tmp/{1,2}
[[ky] ~]# }} diff /tmp/{3,2}
3054a3055
0c5d8f10aa0731671a00961f059dc46e /usr/bin/New SMB and DCERPC
features in Impacket.pdf
that was a test against just 4008, so you can imagine time savings with
5+ files.
Re: [arch-general] Btrfs more than twice as fast compared to ext4
On Tuesday 16 March 2010 14:41:41 Nathan Wayde wrote: On 16/03/10 00:48, Shridhar Daithankar wrote: [...] But as far as file system performance goes, the overhead should be identical for both the runs, no? I'm not too sure about that. I'm guessing there is less seeking going on with Btrfs. Some files systems (reiserfs + reiserfs4 IIRC) are very good with many small files, better than the ext*fs, this may be another case of that. Yes btrfs does have tail packing i.e. storing inode and the file together in a single block. However all the files I had in the tree were 50-55K in size and that definitely does not fit in a block. I still think you could achieve better times by not calling the external command that many times. Since you're already gonna store the checksums in a database, I'd just write a proper program in python or something. The application I am developing already has copy/copyttree and md5sum built- in. I mmap the whole file and do memcpy/memcmp/md5sum in a single pass. That is already a bit faster than native cp, which uses write and buffer management. I changed/refactored the tree copy code and created a new tree. And I wanted to verify outside the application that the tree copy has gone good. Hence did find/md5sum. This was a one time exercise only but the result were drastic enough to be published. -- Regards Shridhar
Re: [arch-general] Arch Linux security is still poor....
I would have thought that this only makes sense in the context of a point-in-time release. i.e. you have a server which isn't updated as regularly as your desktop. The onus then is on the user to ensure that the versions of packages they are using are safe. I don't see this as a problem with the rolling release system that Arch uses. Where it does make sense is if a publicly available, LTS type server repository is used. Then it would be up to the maintainer of the repo to keep on top of security fixes. regards Chris -- Calling the unnamed register the unnamed register really does nothing but negate the name the unnamed register and render the unnamed register useless as a name, thus the unnamed register is named the unnamed register and is no longer the unnamed register as it is named the unnamed register, so where is the unnamed register to be found and what do we call it! Steve Oualline, The book of vim.
Re: [arch-general] Arch Linux security is still poor....
On 03/16/2010 06:53 PM, Chris Allison wrote: I would have thought that this only makes sense in the context of a point-in-time release. i.e. you have a server which isn't updated as regularly as your desktop. The onus then is on the user to ensure that the versions of packages they are using are safe. I don't see this as a problem with the rolling release system that Arch uses. Where it does make sense is if a publicly available, LTS type server repository is used. Then it would be up to the maintainer of the repo to keep on top of security fixes. regards Chris Actually speaking, Arch is ideal for a server. With proper customization abilities and up-to-date software, your server is less likely to get compromised (unless improperly configured) in contrary to those of CentOS, RHEL (yeah it is less than) Fedora, Ubuntu, etc. which keep very old packages. -- Nilesh Govindarajan Site Server Adminstrator www.itech7.com
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 8:49 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Tue, Mar 16, 2010 at 12:32 AM, Nilesh Govindarajan li...@itech7.com wrote: I don't think we need any security team for Arch. New packages are released within a week of their updates. GPG signing and md5sum verification is a must though. md5sum verification has ALWAYS been done In a security context, verification of files installed by a package _after installation_ would be nice. i.e. pacman --verify /usr/sbin/sshd would tell me if the md5sum (or sha1sum, etc) of my /usr/sbin/sshd matches that of the official package. Jared
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 10:48 PM, Jared Casper jaredcas...@gmail.com wrote: On Tue, Mar 16, 2010 at 8:49 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Tue, Mar 16, 2010 at 12:32 AM, Nilesh Govindarajan li...@itech7.com wrote: I don't think we need any security team for Arch. New packages are released within a week of their updates. GPG signing and md5sum verification is a must though. md5sum verification has ALWAYS been done In a security context, verification of files installed by a package _after installation_ would be nice. i.e. pacman --verify /usr/sbin/sshd would tell me if the md5sum (or sha1sum, etc) of my /usr/sbin/sshd matches that of the official package. Jared Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. -- Nilesh Govindarajan Site Server Administrator www.itech7.com
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 13:24, Nilesh Govindarajan li...@itech7.com wrote: Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. And you're paying them how much that allows you to tell them what to work on? Seriously, patches welcome.
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.1-1
On 03/15/2010 01:16 PM, Thomas Bächler wrote: No idea if it is time for signoff yet, I have to check that with tpowa. However, I put 2.6.31.1 in testing with these changes: - Added a trivial patch to support my touchpad (selfish, I know, but it is already accepted upstream for 2.6.34) - Removed EXT4_USE_FOR_EXT23 due to some problems that upstream isn't quite finished discussing yet - we can keep using the ext2 and ext3 drivers for now. sign off x86_64 ATI KMS early start is working again ! Ignacio signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch Linux security is still poor....
Am Dienstag, 16. März 2010 18:24:46 schrieb Nilesh Govindarajan: Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. You got it wrong. Nothing will change until you start working on this. I have seen those discussions during the last 6 years and none of them ever lead into a working implementation. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 1:24 PM, Nilesh Govindarajan li...@itech7.com wrote: On Tue, Mar 16, 2010 at 10:48 PM, Jared Casper jaredcas...@gmail.com wrote: On Tue, Mar 16, 2010 at 8:49 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Tue, Mar 16, 2010 at 12:32 AM, Nilesh Govindarajan li...@itech7.com wrote: I don't think we need any security team for Arch. New packages are released within a week of their updates. GPG signing and md5sum verification is a must though. md5sum verification has ALWAYS been done In a security context, verification of files installed by a package _after installation_ would be nice. i.e. pacman --verify /usr/sbin/sshd would tell me if the md5sum (or sha1sum, etc) of my /usr/sbin/sshd matches that of the official package. Jared Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. Users who want these things, please start joining the pacman dev team.
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 12:18 PM, Jared Casper jaredcas...@gmail.com wrote: On Tue, Mar 16, 2010 at 8:49 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Tue, Mar 16, 2010 at 12:32 AM, Nilesh Govindarajan li...@itech7.com wrote: I don't think we need any security team for Arch. New packages are released within a week of their updates. GPG signing and md5sum verification is a must though. md5sum verification has ALWAYS been done In a security context, verification of files installed by a package _after installation_ would be nice. i.e. pacman --verify /usr/sbin/sshd would tell me if the md5sum (or sha1sum, etc) of my /usr/sbin/sshd matches that of the official package. Is this a feature request in the bug tracker? Please add it if you want this functionality. That's the only way it will ever happen
Re: [arch-general] Arch Linux security is still poor....
On 03/16/2010 07:24 PM, Nilesh Govindarajan wrote: On Tue, Mar 16, 2010 at 10:48 PM, Jared Casperjaredcas...@gmail.com wrote: On Tue, Mar 16, 2010 at 8:49 AM, Aaron Griffinaaronmgrif...@gmail.com wrote: On Tue, Mar 16, 2010 at 12:32 AM, Nilesh Govindarajanli...@itech7.com wrote: I don't think we need any security team for Arch. New packages are released within a week of their updates. GPG signing and md5sum verification is a must though. md5sum verification has ALWAYS been done In a security context, verification of files installed by a package _after installation_ would be nice. i.e. pacman --verify /usr/sbin/sshd would tell me if the md5sum (or sha1sum, etc) of my /usr/sbin/sshd matches that of the official package. Jared Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. sudo make me a sandwich. -- Ionut
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 12:34 PM, Daenyth Blank daenyth+a...@gmail.com wrote: On Tue, Mar 16, 2010 at 13:24, Nilesh Govindarajan li...@itech7.com wrote: Let this thread not be just another Will be nice one. Pacman devs, please start implementing these package verification things. And you're paying them how much that allows you to tell them what to work on? Seriously, patches welcome. Also... don't assume they read the mailing list. Post the feature request on the bug tracker. This is apparently the hardest concept for all these types of threads. Someone - go post it now and paste the link in this thread
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
On Tue, Mar 16, 2010 at 1:22 AM, Joe(theWordy)Philbrook jtw...@ttlc.net wrote: It does look like getting Arch Linux configured the way I need it is going to take a bit more work than I'm used to. But if the rolling release part of what I've read about it means I won't have to recreate my personal user environment (heavily modified keyboard shortcuts etc...) every 6 months or so just to keep up to date, then I figure it'll be more than worth the effort. Welcome aboard and glad you're getting things sorted out. Once you have used a rolling release distro, everything else just seems silly. Reinstall every six months? No thanks!
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
On 15-03-10 20:01, Jeffrey Lynn Parke Jr. wrote: On Mon, Mar 15, 2010 at 12:26 PM, Guus Snijdersgsnijd...@gmail.com wrote: On 15-03-10 14:07, Jeffrey Parke wrote: [installing XFCE, xorg] [...] Actually, you should /remove/ the '#' from the start of that line... ;) that's exactly what I said, just wanted to make sure he new what a comment was. Lol, very good. Sorry for spoiling it, then. mvg, Guus
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
On 03/16/2010 01:58 PM, Thayer Williams wrote: On Tue, Mar 16, 2010 at 1:22 AM, Joe(theWordy)Philbrookjtw...@ttlc.net wrote: It does look like getting Arch Linux configured the way I need it is going to take a bit more work than I'm used to. But if the rolling release part of what I've read about it means I won't have to recreate my personal user environment (heavily modified keyboard shortcuts etc...) every 6 months or so just to keep up to date, then I figure it'll be more than worth the effort. Welcome aboard and glad you're getting things sorted out. Once you have used a rolling release distro, everything else just seems silly. Reinstall every six months? No thanks! +1 When I hear about issues people run into when upgrading to, say, the latest version of Ubuntu, my thinking is usually some combination of: 1) What's an OS upgrade? 2) What's an OS version? 3) If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time. 4) You're still running into *that* bug? That was fixed in Arch *months* ago! It's so much fun to be a smug Arch user. :-) DR
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 10:30 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: Is this a feature request in the bug tracker? Please add it if you want this functionality. That's the only way it will ever happen It's been there for years: http://bugs.archlinux.org/task/11091 I just wanted to point out that the md5sum verification spoken of generally means something different in a security context than what is already being done. Jared
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
On Tue, Mar 16, 2010 at 3:12 PM, David Rosenstrauch dar...@darose.netwrote: 3) If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time. Except when there's a new KDE release then it's easily 100+ packages =P -- Guilherme M. Nogueira Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke
Re: [arch-general] Arch is ummnn different: my 1st installation: tried to install xfce...OOPS!
On Tue, 2010-03-16 at 15:58 -0300, Guilherme M. Nogueira wrote: On Tue, Mar 16, 2010 at 3:12 PM, David Rosenstrauch dar...@darose.netwrote: 3) If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time. Except when there's a new KDE release then it's easily 100+ packages =P Which maxes out to, what... 400 MB? My updates of Ubuntu previously pulled in well over a gigabyte of packages. Painful for the less well-endowed (in connection speed terms) among us.
[arch-general] Package signing (was: Arch Linux security is still poor)
I had already this email draft in my head, but Ananda 'Arch Linux security is still poor' thread, on which the point was also brought up, moved me to really write it. First off, there's an implicit level of trust on the package software, no matter which OS you use. When using Windows, you trust in Microsoft, when using Mac OS, you trust in Apple, when using a Linux distro, you trust the packagers and upstream. Either you do that or trust just whatever came installed and not install anything ever (thus not patching to new vulnerabilities). The problem with Arch current packaging system is not that you must trust people able to write in core not to add a rm -rf / (to name the classical 'attack') nor that you didn't install arch with an infected media. The problem is that every time you do pacman -Syu, you must blindly trust that your dns, network, and mirror are reliable, too. The packages are verified with a md5 from the server list, but should you update from a compromised mirror (or impersonated, eg. arp poisoning, dns spoofing, bofh proxy operator...) you have lost. A pacman -Syu from an open wifi might be enough. A later update may 'clean' it, so you may not even notice that you were once compromised. There are several ways to close the gap: *Always download the package list from ftp.archlinux.org It's the easier solution, but it only protects against the mirror operator. Moreover, it increases load on that server and makes it a single point of failure. *Package lists are signed from a trusted master key. There may be up to a key per repo. Easy to provide, allows backward compatibility. *Packages are automatically signed by ftp.archlinux.org before distributing them. Removes the dependancy over the package list. Packages can be shared securely (eg. getting a downgrade for an untrusted user). *Each developer signs its own packages prior to uploading. Each repository key signs the keys of the developers with write access. Users can blacklist or trust independent developers. Needless to say, the last solution is the one I like most. However, being more complete, it also means more work. :) The package signing could be a simple text file with filenames and hashes (preferably something more secure than md5) signed with gpg, or could be expanded if more fields are needed. Do you think this is a good idea? Which solution do you prefer? And most important, what would be needed to reach there? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [arch-general] on rolling release / reinstallation
On 03/16/10 14:12, David Rosenstrauch wrote: On 03/16/2010 01:58 PM, Thayer Williams wrote: Welcome aboard and glad you're getting things sorted out. Once you have used a rolling release distro, everything else just seems silly. Reinstall every six months? No thanks! I enjoyed the 6-month reinstalls... for a while. They reminded me how my system was set up ; to make backups ; etc. When I hear about issues people run into when upgrading to, say, the latest version of Ubuntu, my thinking is usually some combination of: 1) What's an OS upgrade? 2) What's an OS version? true. and on the occasion that Ubuntu breaks something in a stable upgrade, it's awful (although I'm not sure this ever actually happened to me). I still reckon it's useful to reinstall Arch every few years, as / gets cluttered with old layouts, .pacnew files, miscellaneous stuff from de-installed packages, packages that are accidentally still installed due to upgrade sequences or forgetfulness, enabled daemons that are no longer part of the mainstream Linux stack (e.g. I hear HAL may be slowly going out of fashion), new advice in the Official Install Guide that you haven't checked in ages, new filesystem formats (or at least, making a new filesystem eliminates any fragmentation in the old one), decaying personal knowledge about how Linux works (due to complacency, if it's all still working, or just not having an all-in-one chance to get a big picture)... Just don't delete your old / until a while after the new one is working, if you can manage it. 3) If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time. yes and no. Workarounds are easier, but need to be done more often than once every six months. It was nice to be able to do upgrades during my school-vacation-time rather than when I have a paper due shortly (there's ALWAYS a paper due, or an e-mail to get back to, at my college..) 4) You're still running into *that* bug? That was fixed in Arch *months* ago! :) -Isaac
Re: [arch-general] Package signing (was: Arch Linux security is still poor)
On Tue, Mar 16, 2010 at 20:06, Linas linas...@ymail.com wrote: I had already this email draft in my head, but Ananda 'Arch Linux security is still poor' thread, on which the point was also brought up, moved me to really write it. There's a bug on the tracker about this, please contribute there. There's no point in bringing it up here for the inf++th time.
Re: [arch-general] Package signing (was: Arch Linux security is still poor)
On 17/03/10 10:06, Linas wrote: Do you think this is a good idea? Which solution do you prefer? And most important, what would be needed to reach there? There has been discussions on the pacman-dev mailing list and is even partial implementation for package signing available. You should research those archives if you want to help. We have had lots of people talk but very few ever contributed actual code which is the big bottleneck here. Allan
Re: [arch-general] Arch Linux security is still poor....
On Mon, Mar 15, 2010 at 5:43 PM, Ananda Samaddar ana...@samaddar.co.uk Would there be any enthusiasm for a dedicated security team? I feel strongly enough about it that if something can't be done then I'm switching to another distro. Despite the fact that I really like Arch, it's one deficiency is a pretty glaring one in my opinion. I hope this doesn't turn into a flamefest and my opinions are by no means meant to be a slight on the Arch devs or community. I'm going to chime in and repeat what some of the others have said - I too would like to see some evidence that Arch as a distro has security issues other that those that should be fixed upstream. Since Arch always has the latest versions of software, it should automatically have all the latest security fixes - there's no need to backport patches to old versions of software, like Debian does. Security issues arising from poor default config files should be and are addressed by individual package maintainers. Again, I'm not aware of any cases where a maintainer's poor job resulted in a security issue - probably because each package is a vanilla package and doesn't contain any customized configs (again, Debian comes to mind). Best, Denis.
Re: [arch-general] on rolling release / reinstallation
I've done the ill fated -Syu right before a project deadline. Something in the update broke mdraid and my system wouldn't boot until I booted from livecd to redo the -Syu. I think maybe my mirror was syncing when I was updating and my packages were mismatched. Never update when facing a deadline. On Mar 16, 2010 8:10 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 03/16/10 14:12, David Rosenstrauch wrote: On 03/16/2010 01:58 PM, Thayer Williams wrote: Welcome aboard and glad you're getting things sorted out. Once you have used a rolling release distro, everything else just seems silly. Reinstall every six months? No thanks! I enjoyed the 6-month reinstalls... for a while. They reminded me how my system was set up ; to make backups ; etc. When I hear about issues people run into when upgrading to, say, the latest version of Ubuntu, my thinking is usually some combination of: 1) What's an OS upgrade? 2) What's an OS version? true. and on the occasion that Ubuntu breaks something in a stable upgrade, it's awful (although I'm not sure this ever actually happened to me). I still reckon it's useful to reinstall Arch every few years, as / gets cluttered with old layouts, .pacnew files, miscellaneous stuff from de-installed packages, packages that are accidentally still installed due to upgrade sequences or forgetfulness, enabled daemons that are no longer part of the mainstream Linux stack (e.g. I hear HAL may be slowly going out of fashion), new advice in the Official Install Guide that you haven't checked in ages, new filesystem formats (or at least, making a new filesystem eliminates any fragmentation in the old one), decaying personal knowledge about how Linux works (due to complacency, if it's all still working, or just not having an all-in-one chance to get a big picture)... Just don't delete your old / until a while after the new one is working, if you can manage it. 3) If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time. yes and no. Workarounds are easier, but need to be done more often than once every six months. It was nice to be able to do upgrades during my school-vacation-time rather than when I have a paper due shortly (there's ALWAYS a paper due, or an e-mail to get back to, at my college..) 4) You're still running into *that* bug? That was fixed in Arch *months* ago! :) -Isaac
[arch-general] HAL depreciation
Does anyone know how much of HAL is needed in ArchLinux these days? I'm asking because I've learned that both udev and HAL configure the keymap of input devices nowdays and I wonder what other former HAL features are already implemented in udev. -- damjan
Re: [arch-general] HAL depreciation
the usb mice don't work without hal, or do they now. They didn't used to On Tue, Mar 16, 2010 at 9:06 PM, Damjan Georgievski gdam...@gmail.comwrote: Does anyone know how much of HAL is needed in ArchLinux these days? I'm asking because I've learned that both udev and HAL configure the keymap of input devices nowdays and I wonder what other former HAL features are already implemented in udev. -- damjan
Re: [arch-general] HAL depreciation
On Tue, 16 Mar 2010 21:08:42 -0500 Jeffrey Lynn Parke Jr. jeffrey.pa...@gmail.com wrote: the usb mice don't work without hal, or do they now. They didn't used to On Tue, Mar 16, 2010 at 9:06 PM, Damjan Georgievski gdam...@gmail.comwrote: Does anyone know how much of HAL is needed in ArchLinux these days? I'm asking because I've learned that both udev and HAL configure the keymap of input devices nowdays and I wonder what other former HAL features are already implemented in udev. -- damjan USB mice have worked without hal for a long time. It's just hotplugging that won't work.
Re: [arch-general] HAL depreciation
On Wed, Mar 17, 2010 at 7:50 AM, Ty John ty...@eye-of-odin.com wrote: On Tue, 16 Mar 2010 21:08:42 -0500 Jeffrey Lynn Parke Jr. jeffrey.pa...@gmail.com wrote: the usb mice don't work without hal, or do they now. They didn't used to On Tue, Mar 16, 2010 at 9:06 PM, Damjan Georgievski gdam...@gmail.comwrote: Does anyone know how much of HAL is needed in ArchLinux these days? I'm asking because I've learned that both udev and HAL configure the keymap of input devices nowdays and I wonder what other former HAL features are already implemented in udev. -- damjan USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. -- Nilesh Govindarajan Site Server Administrator www.itech7.com
Re: [arch-general] Arch Linux security is still poor....
I would love to jump into pacman-dev team. But I don't know C or C++ whatever pacman is written in. :( :( :( I can contribute in PHP. -- Nilesh Govindarajan Site Server Administrator www.itech7.com
Re: [arch-general] Arch Linux security is still poor....
On Tue, Mar 16, 2010 at 10:39 PM, Nilesh Govindarajan li...@itech7.com wrote: I would love to jump into pacman-dev team. But I don't know C or C++ whatever pacman is written in. :( :( :( I can contribute in PHP. You might then want to look into helping out the devs of the AUR webapp, if you care about it. They have an aur-dev mailing list, and their code is at http://projects.archlinux.org/aur.git/ . (But I think this is off-topic to this thread.)
Re: [arch-general] Hacking into HAL's mount process
So far, after eliminating flush option, I achieved a speed of 3.9 MB/s which was previously 1-2 MB/s. If I could somehow force the async option, I think speed would increase more. Any ideas ? The async option appears true (configured) in hal-device, but doesn't get mounted with that option. -- Nilesh Govindarajan Site Server Administrator www.itech7.com
Re: [arch-general] HAL depreciation
On Wed, 17 Mar 2010 08:08:22 +0530 Nilesh Govindarajan li...@itech7.com wrote: USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. But did you put it in your xorg.conf file?
Re: [arch-general] HAL depreciation
On Wed, Mar 17, 2010 at 10:16 AM, Ty John ty...@eye-of-odin.com wrote: On Wed, 17 Mar 2010 08:08:22 +0530 Nilesh Govindarajan li...@itech7.com wrote: USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. But did you put it in your xorg.conf file? What to put ? -- Nilesh Govindarajan Site Server Administrator www.itech7.com
Re: [arch-general] HAL depreciation
On Wed, 17 Mar 2010 10:24:54 +0530 Nilesh Govindarajan li...@itech7.com wrote: On Wed, Mar 17, 2010 at 10:16 AM, Ty John ty...@eye-of-odin.com wrote: On Wed, 17 Mar 2010 08:08:22 +0530 Nilesh Govindarajan li...@itech7.com wrote: USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. But did you put it in your xorg.conf file? What to put ? http://wiki.archlinux.org/index.php/Xorg#Configuring
Re: [arch-general] HAL depreciation
On 03/16/2010 10:54 PM, Nilesh Govindarajan wrote: On Wed, Mar 17, 2010 at 10:16 AM, Ty Johnty...@eye-of-odin.com wrote: On Wed, 17 Mar 2010 08:08:22 +0530 Nilesh Govindarajanli...@itech7.com wrote: USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. But did you put it in your xorg.conf file? What to put ? in addition to what Ty posted there is also http://wiki.archlinux.org/index.php/Get_All_Mouse_Buttons_Working that has some pointers
Re: [arch-general] HAL depreciation
On Wed, Mar 17, 2010 at 10:57 AM, jwbirdsong jwbirds...@jwbirdsong.homelinux.com wrote: On 03/16/2010 10:54 PM, Nilesh Govindarajan wrote: On Wed, Mar 17, 2010 at 10:16 AM, Ty Johnty...@eye-of-odin.com wrote: On Wed, 17 Mar 2010 08:08:22 +0530 Nilesh Govindarajanli...@itech7.com wrote: USB mice have worked without hal for a long time. It's just hotplugging that won't work. Well, I recently copied /etc/group.pacnew to /etc/group which didn't have the hal and gdm groups. HAL didn't start, and when I started KDE (xinit startkde) or GDM or KDM, neither keyboard nor mouse worked. After adding hal group, it worked fine, since HAL started succesfully. But did you put it in your xorg.conf file? What to put ? in addition to what Ty posted there is also http://wiki.archlinux.org/index.php/Get_All_Mouse_Buttons_Working that has some pointers I don't have seven mouse buttons. The mouse and keyboard is already configured in xorg.conf using drivers mouse and kbd. If I stop hal, and then start Xorg, it doesn't work. I've to hard reset my box. -- Nilesh Govindarajan Site Server Administrator www.itech7.com
