Re: [arch-general] A question about Arch Sixty Four
On 24/05/10 02:32 PM, Keith Hinton wrote: Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? I have an Intel 2 core dule T9600 2.80 GHZ, 4 Gb of RAM installed, with a 320 Gb hard-drive installed in my laptop. I tend to put a lot of RAM aside for virtual machines specifically. At present due to some requirements, I'm using Arch virtually on top of a Windows Seven host. I want to put this setup later on to Linux, and for now am doing fine with this virtual stuff. However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64? I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible? Thanks! Regards, --Keith Skype: skypedude1234 MSN Messenger: keithin...@hotmail.com Yahoo messenger /AIM: keithint1234 It is barely noticeable. I wouldn't give it a second thought.
Re: [arch-general] Fwd: AIF through proxy
i now tested this many times on VM (vbox) http://wiki.archlinux.org/index.php/Package_Proxy_Cache everything seems to work ok. but i found some other issues with custom AIF profiles (in automatic mode) # aif -d ... gives me the aif usage info # aif ... -d runs aif but doesn't do any /var/log/aif/debug.log but whats more annoying, the base packages get downloaded in 5 seconds, but adding like xorg to TARGET_GROUPS or TARGET_PACKAGES, those packages take like 15 minutes to download, even when all come from the proxy cache... (would be nice to know if this is like that on other systems, or is it just so in my setup) and i also wonder whats the difference between TARGET_GROUPS and TARGET_PACKAGES ? but other than that, i'm really happy to got this far :) cheers .andre ps. please do video record this ;) http://www.archlinux.ca/archcon2010/?p=67
Re: [arch-general] Burning From Command Line
On Sun, May 23, 2010 at 12:41 PM, Rasmus Steinke r...@xssn.at wrote: Jörg has a point. While of course being biased about his pet cdrtools, cdrkit is not on par with cdrtools in any way. Those updates you mention more or less only consist of small fixes, no progess at all in that package. The ONLY reason cdrkit is used in many distributions is the license of cdrtools. Jörg mentions on his website that suns lawyers have analyzed the legal issues. Unfortunately there is no link to that analysis which makes this a pure claim. Jorg also mentioned that Eben Moglen approved the original software : http://mailman.archlinux.org/pipermail/arch-general/2010-January/010380.html which was proved to be wrong from Eben Moglen himself : http://mailman.archlinux.org/pipermail/arch-general/2010-February/010989.html This doesnt change the fact that cdrtools is clearly superior to cdrkit. (Just check arch's bugtracker) Rasi If this wasn't the case, the situation wouldn't suck as much. Everyone would just use cdrkit without second thoughts. But when a project is forked by external (non-involved) people simply for fixing the license rather than fixing real technical problems, I wouldn't expect great progress being made. Anyway let's stop talking about all this non-sense BS. I am very happy with how the wiki (http://wiki.archlinux.org/index.php/CD_Burning) presents things by staying very practical. Install packaged cdrkit, and if it doesn't work for you, install cdrtools from AUR.
[arch-general] Script to check monitor blank state
Hello everyone, i would like to write a little script, that suspends my computer if a few circumstances are met. One should be, that my screen should be blanked. I already did a google search on this, but i only found howtos of getting it to work / disable it. It looks like xset q does not print the actual state. Maybe there is a hook for screen blanking? I know this is not a arch specific question, but maybe someone can help me. Markus
Re: [arch-general] A question about Arch Sixty Four
Dne Po 24. května 2010 15:36:37 Keith Hinton at arch-general- requ...@archlinux.org napsal(a): Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? I have an Intel 2 core dule T9600 2.80 GHZ, 4 Gb of RAM installed, with a 320 Gb hard-drive installed in my laptop. I tend to put a lot of RAM aside for virtual machines specifically. At present due to some requirements, I'm using Arch virtually on top of a Windows Seven host. I want to put this setup later on to Linux, and for now am doing fine with this virtual stuff. However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64? I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible? Thanks! Regards, --Keith Skype: skypedude1234 MSN Messenger: keithin...@hotmail.com Yahoo messenger /AIM: keithint1234 Hi, I have experimentally found out, that 64 bit Linux distro uses like 40 -- 80 % more of RAM than 32 bit. Now it seemed to be both aplication and distro dependant, with Arch being on the better side. Though I've got to say again, it was not a benchmark, just my personal experiment. As for me, if I had a machine with plenty RAM (that is from my perspective ~GB), than I would choose 64 bit. If I had like 1 -- 2 GB, than I would definitely go 32 bit. Hope I did understand your question right. -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)
Re: [arch-general] Strange suspend behaviour
I've set up my system so that when I close the laptop lid the computer goes into suspend mode. However, when I wake it up by pressing the power button the system starts, and after 3-5 sec it goes into suspend mode again. If I then press the power button again, it starts and stays on. Suggestions? Explain what DE you are running and how and what did you set up. -- damjan
Re: [arch-general] Strange suspend behaviour
On 24.05.2010 20:08, Damjan Georgievski wrote: I've set up my system so that when I close the laptop lid the computer goes into suspend mode. However, when I wake it up by pressing the power button the system starts, and after 3-5 sec it goes into suspend mode again. If I then press the power button again, it starts and stays on. Suggestions? Explain what DE you are running and how and what did you set up. Sounds like he's running KDE. The problem that he described is with powerdevil and has already been fixed upstream (but I don't think the current release contains it yet). -- Sven-Hendrik
[arch-general] Running Mozilla Prism?
Has anyone managed to get Mozilla Prism to run properly? The behaviour I see is that a .desktop file and a file in ~/.webapps are created. Both look all right to my untrained eye. The behaviour when double-clicking the .desktop file is as expected though. I never end up where I intended, but always at the default startpage (http://www.google.com/firefox). You can find a screenshot of what I got after creating a webapp for youtube (URL http://www.youtube.com/) and ran it for the first time here[1]. Has anyone had any success with it? /M [1]: http://therning.org/magnus_files/prism.png -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature
[arch-general] regression in nouveau ?
Hello all, over the past few months I have installed Arch on a number of systems, all of them used for quite intensive audio work (think of systems with 1000 jack ports). All of them have worked flawlessly, no latency problems even with the standard kernel. Today I installed one more, on exactly the same HW as the previous one which was something like 6 weeks ago. Main difference is probably kernel 2.6.33 instead of 32. This system is completely unusable: almost anything 'graphical' - opening or closing windows, changing workspaces, etc. will generate showers of xruns. Using nouveau's 'no_accel' option solves the xruns, audio is as stable as it has ever been. But the system is again useless - just scrolling an xterm up one line takes a second or so. Nor has using this option been necessary before (all of the previous installs use nouveau). So has anything changed in nouveau that can explain this ? Any solutions ? TIA, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] Off-topic: Good laptop to run Arch on?
On 05/22/2010 11:33 AM, Magnus Therning wrote: What laptops should I have a look at? Is there some brand (Dell, HP, ...) that is more Linux friendly than others? My work laptop, a Dell Precision M4400, runs Arch fine. Had to install a few extra kernel modules (e.g., broadcom-wl), but everything else got picked up automagically. HTH, DR
Re: [arch-general] Running Mozilla Prism?
On 05/24/10 at 08:58pm, Magnus Therning wrote: Has anyone managed to get Mozilla Prism to run properly? The behaviour I see is that a .desktop file and a file in ~/.webapps are created. Both look all right to my untrained eye. The behaviour when double-clicking the .desktop file is as expected though. I never end up where I intended, but always at the default startpage (http://www.google.com/firefox). You can find a screenshot of what I got after creating a webapp for youtube (URL http://www.youtube.com/) and ran it for the first time here[1]. Has anyone had any success with it? /M [1]: http://therning.org/magnus_files/prism.png -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe Works fine for me... been using it since it was first released. --
Re: [arch-general] A mirror question
On 05/20/2010 07:38 PM, Keith Hinton wrote: Hi, I was wondering what the best mirror would be for someone living ni Ohio? The rit.edu mirror is in Western NY - probably not too far from you. I've used that one for a number of years and found it to generally be a reliable mirror. HTH, DR
Re: [arch-general] regression in nouveau ?
On Mon, May 24, 2010 at 11:00 PM, f...@kokkinizita.net wrote: Hello all, over the past few months I have installed Arch on a number of systems, all of them used for quite intensive audio work (think of systems with 1000 jack ports). All of them have worked flawlessly, no latency problems even with the standard kernel. Today I installed one more, on exactly the same HW as the previous one which was something like 6 weeks ago. Main difference is probably kernel 2.6.33 instead of 32. This system is completely unusable: almost anything 'graphical' - opening or closing windows, changing workspaces, etc. will generate showers of xruns. Using nouveau's 'no_accel' option solves the xruns, audio is as stable as it has ever been. But the system is again useless - just scrolling an xterm up one line takes a second or so. Nor has using this option been necessary before (all of the previous installs use nouveau). So has anything changed in nouveau that can explain this ? Any solutions ? Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ? If you still have the same problems with git, you should ask upstream (irc freenode #nouveau or ML http://lists.freedesktop.org/mailman/listinfo/nouveau) http://nouveau.freedesktop.org/wiki/FrontPage But it would help to have as much precision as possible about what is the latest version of each nouveau component that worked, and what is the first that is bad, i.e. minimizing the regression window. Also note the first item about latency on this page : http://nouveau.freedesktop.org/wiki/ToDo
Re: [arch-general] A question about Arch Sixty Four
Le lundi 24 à 0:29, C Anthony Risinger a écrit : On Mon, May 24, 2010 at 12:02 AM, Keith Hinton keithint1...@gmail.com wrote: I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-) On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred signature.asc Description: PGP signature
Re: [arch-general] A question about Arch Sixty Four
On Mon, 2010-05-24 at 23:48 +0200, Frédéric Perrin wrote: Le lundi 24 à 0:29, C Anthony Risinger a écrit : On Mon, May 24, 2010 at 12:02 AM, Keith Hinton keithint1...@gmail.com wrote: I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-) On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. This is really strange. I am running a 64 bit system and after a fresh start (Including gnome, pulseaudio, dropbox, rhythmbox,uget,transmission) it consumes between 700 and 800MB ram. I never noticed any increase in ram usage between 32bit and 64bit (Have been running a 32bit version of another distro before). Therefore I would suggest you using 64bit. Greetings Benedikt
Re: [arch-general] Script to check monitor blank state
On Mon, May 24, 2010 at 8:36 AM, Markus mar...@hackfleischeis.de wrote: Hello everyone, i would like to write a little script, that suspends my computer if a few circumstances are met. One should be, that my screen should be blanked. I already did a google search on this, but i only found howtos of getting it to work / disable it. It looks like xset q does not print the actual state. Maybe there is a hook for screen blanking? I know this is not a arch specific question, but maybe someone can help me. If this is X specific, you might want to drop to the C level - write an app that uses a normal Xlib event loop, and catches all input events (keyboard and mouse events). After a given timeout with no input events, do your blanking / suspend
Re: [arch-general] A question about Arch Sixty Four
2010/5/24 Frédéric Perrin frederic.per...@resel.fr: On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred Well, heres something vaguely empirical. Just downloaded the two latest netinstall medias and threw them on a usb stick. I ran precisely four commands after logging in as root on each netinstall arch: 1) mkdir /mnt/tmp 2) mount /dev/sda3 /mnt/tmp #my home partition 3) uname -a /mnt/tmp/gary/memcomp 4) free -m /mnt/tmp/gary/memcomp results to be seen here: http://aur.pastebin.com/YwTJA6cR short story: ~29 MB more used on x86_64... or about 30 percent. But when installing a whole system, many more variables come into play. It might have just been my dumb luck that ram usage ended up within 1-2 mb of eachother. Gary
Re: [arch-general] A question about Arch Sixty Four
This is actually normal. 64 bits systems uses 64bits per memory address, by default. That alone would make 64bits systems eat twice as much memory than a 32bit systems. Of course you can program can be coded to use 32bit variables, but hey, isn't the larger number representation one of the 64bits advantage? Also, if you want 64bit systems, you may want huge quantities of memory. More than 3GB, which makes most of the memory consumption somewhat useless. 2010/5/24 Dan McGee dpmc...@gmail.com: On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrigg...@gmail.com wrote: 2010/5/24 Frédéric Perrin frederic.per...@resel.fr: On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred Well, heres something vaguely empirical. Just downloaded the two latest netinstall medias and threw them on a usb stick. I ran precisely four commands after logging in as root on each netinstall arch: 1) mkdir /mnt/tmp 2) mount /dev/sda3 /mnt/tmp #my home partition 3) uname -a /mnt/tmp/gary/memcomp 4) free -m /mnt/tmp/gary/memcomp results to be seen here: http://aur.pastebin.com/YwTJA6cR short story: ~29 MB more used on x86_64... or about 30 percent. But when installing a whole system, many more variables come into play. It might have just been my dumb luck that ram usage ended up within 1-2 mb of eachother. 47 MB - 21 MB (for a difference of 26 MB) is what you want to be looking at and nothing else. Throw buffers and cache out the window. Of course, that now skews the percentage a lot higher than what you stated to (47 - 21) / 21 = 123%. I'm not buying those numbers though as you didn't capture near enough information and not all that much was running. More useful are probably things like pmap comparison of the same binaries, etc. after doing as close to identical operations. I'm not sure even that would help, see the following pastebin to see those deceiving results: http://aur.pastebin.com/GzjTZYMe -Dan
Re: [arch-general] A question about Arch Sixty Four
Need to revise my text next time. Hope it's legible. 2010/5/25 Adriano Moura adriano.l...@gmail.com: This is actually normal. 64 bits systems uses 64bits per memory address, by default. That alone would make 64bits systems eat twice as much memory than a 32bit systems. Of course you can program can be coded to use 32bit variables, but hey, isn't the larger number representation one of the 64bits advantage? Also, if you want 64bit systems, you may want huge quantities of memory. More than 3GB, which makes most of the memory consumption somewhat useless. 2010/5/24 Dan McGee dpmc...@gmail.com: On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrigg...@gmail.com wrote: 2010/5/24 Frédéric Perrin frederic.per...@resel.fr: On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred Well, heres something vaguely empirical. Just downloaded the two latest netinstall medias and threw them on a usb stick. I ran precisely four commands after logging in as root on each netinstall arch: 1) mkdir /mnt/tmp 2) mount /dev/sda3 /mnt/tmp #my home partition 3) uname -a /mnt/tmp/gary/memcomp 4) free -m /mnt/tmp/gary/memcomp results to be seen here: http://aur.pastebin.com/YwTJA6cR short story: ~29 MB more used on x86_64... or about 30 percent. But when installing a whole system, many more variables come into play. It might have just been my dumb luck that ram usage ended up within 1-2 mb of eachother. 47 MB - 21 MB (for a difference of 26 MB) is what you want to be looking at and nothing else. Throw buffers and cache out the window. Of course, that now skews the percentage a lot higher than what you stated to (47 - 21) / 21 = 123%. I'm not buying those numbers though as you didn't capture near enough information and not all that much was running. More useful are probably things like pmap comparison of the same binaries, etc. after doing as close to identical operations. I'm not sure even that would help, see the following pastebin to see those deceiving results: http://aur.pastebin.com/GzjTZYMe -Dan
Re: [arch-general] A question about Arch Sixty Four
On 05/24/10 23:48, Adriano Moura wrote: This is actually normal. 64 bits systems uses 64bits per memory address, by default. That alone would make 64bits systems eat twice as much memory than a 32bit systems. Only for the memory-address part of the data (a.k.a. pointers). UTF-8 text will still take up the usual number of bytes for any given piece of text. Integer values will frequently take up the same amount of space. (Programmers *can*, if they're crazy, make any differences they want in their program depending on number of bits, but typically don't.) According to this logic (which is mostly correct), programs should use somewhere between 1x and 2x as much memory depending what fraction of their data is addresses. (Probably never as much as 2x because malloc() keeps some bookkeeping data that probably isn't all addresses; because executable code isn't made of addresses; because any external data such as on the disk or the Web won't be made of addresses; and so on.) Of course you can program can be coded to use 32bit variables, not possible for memory addresses under 64-bit binary ABI, as far as I know.. but hey, isn't the larger number representation one of the 64bits advantage? not really, not for integers. The advantage for integers is that operations are faster on integers that can hold values up to about 2^64. Integers that hold up to about 2^32 are the same speed. (Compilers can emulate 64-bit ints with 32-bit ints.) I don't see the point of C's volatile-size integers like long sometimes being 32bits and sometimes 64bits (except for the purpose of being exactly the same size as an address, essentially in order to hold an address... silly programs...), because people have to write their code to be correct at all possible integer sizes, which basically means constraining possible legitimate values to the lower size anyway. The address space advantage of 64-bits is that your program can address more than 4 virtual GB of information at once (per executable, RAM+swap used = data+code+miscellaneous). If you have less than three or four gigabytes of RAM, this 32-bit limitation is unlikely to be of importance. Well, it affects 'mmap' of several-gigabyte-large files... (there are always obscure effects :-) On x86 architectures, the 64-bit code also has access to more CPU registers, which tends to make code run faster (although code can suffer when you use all your RAM, or if bigger data fills up CPU caches quicker). There are other little differences like this too. Also, if you want 64bit systems, you may want huge quantities of memory. More than 3GB, which makes most of the memory consumption somewhat useless. No 3 GB doesn't make memory consumption useless. Web browser with 100 tabs eats RAM. Video editing application eats RAM. Heck, even Amarok eats 80 MB RAM, and uses some CPU when it's not even playing music, these days. Also check out 'df /'. However many gigabytes you're currently using for installed software, if you were using your software all at once, well it can make your system faster for software to remain cached in RAM... But if your system is fast enough for you, don't waste time tweaking it, because if you do, it will *still* be fast enough for you! Personally, I've went back and forth between 64bit and 32bit systems several times on my 2 GB machine, and I don't think there's a very detectable performance difference. Maybe 64bit uses a bit more RAM yet uses the CPU a bit more efficiently. On the other hand, there is a binary compatibility effect (proprietary code and viruses might work a bit better on 32bit x86, I dunno, I don't try them much). 2010/5/24 Dan McGeedpmc...@gmail.com: On Mon, May 24, 2010 at 8:13 PM, Gary Wrightwrigg...@gmail.com wrote: 2010/5/24 Frédéric Perrinfrederic.per...@resel.fr: On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred Well, heres something vaguely empirical. Just downloaded the two latest netinstall medias and threw them on a usb stick. I ran precisely four commands after logging in as root on each netinstall arch: 1) mkdir /mnt/tmp 2) mount /dev/sda3 /mnt/tmp #my home partition 3) uname -a /mnt/tmp/gary/memcomp 4) free -m /mnt/tmp/gary/memcomp results to be seen here: http://aur.pastebin.com/YwTJA6cR short story: ~29 MB more used on x86_64... or about 30 percent. But when installing a whole system, many more variables come into play. It might have just been my dumb luck that ram usage ended up within 1-2 mb of eachother. 47
