Re: perspectives on 32 bit vs 64 bit
Adam Skutt wrote: Helge Hafting wrote: Adam Skutt wrote: Helge Hafting wrote: You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. How? In protected-mode, they're in use as segement descriptor selectors. Certain bits have specific meanings you cannot override, as they're part of the memory protection mechanism. Yes, so? That means it's logically impossible to have a 48-bit pointer, at all period. You are right that this isn't a true 48-bit pointer. The upper 16 bit of such a pointer is not a numerical part that can be incremented the ordinary way. But it _is_ a way that lets you have more than 32 bits of address space, although this way is so cumbersome that nobody sane would bother implement it. (Pointer arithmetic no longer being simple add/subtract, precisely due to the descriptors, invoking the _swapper_ whenever we reference a pointer to another 4G area . . .) Sigh. All mechanisms that lets the os support more than 4GB for several processes, can be used to support more than 4GB for a single process as well. That is trivial, although also less efficient than only supporting 4GB. Yes, but it's obvious now you didn't understand what I said. You /cannot/ have more than 32-bits of virtual address space. Period. There is no way to do it. What you can do is remap the same virtual space to different physical addresses. Which is different from having extra v.a.s. Whenever the app reloads a segment register, (i.e. trying to use a 48-bit pointer where the segment descriptor differs from the last pointer used) This isn't a 48-bit pointer, because descriptor selectors aren't pointers. Not a true 48 bit pointer, it doesn't give you 48 bits of address space. But it gives you more than 32 bit, thats my point. And I called it a 48-bit pointer because storing such a pointer indeed takes 48 bit for the selector offset. And it won't work anyway. How do I get a base offset higher than 0x? And if I add to it, what behavior is yielded? You don't get a higher base offset than that - but I never said so either. Your compiler have to support a segment switch whenever you cross a 4GB boundary. Needless to say, this makes all pointer arithmetic slow. Not what is desired, to say the least. Nobody desires this way of programming - but it is possible. I never claimed it was useful - get a 64-bit processor instead I said. You can't have more than 32-bit v.a.s. Anytricks to get around that don't really get around that, they just have the same addresses the user-space code sees point to different physical addresses. I really don't see how this is possible leafing through the IA-32 System Programming Guide so links or text would be preferred. No guide will tell you how, they'll guide you towards something saner. It is all there in the specs though, and is easier to understand if you compare to a similiar situation in the 1980's: Nobody ever used the 48-bit pointer system, but a 32-bit pointer system (16-bit selector + 16-bit offset) was widely used to support more than 1MB on the 80286 processor. Of course this wasn't true 32-bit pointers either, they needed 32 bits of storage space but merely allowed a 24-bit address space. Pointer arithmetic was highly nontrivial due to the selector part of the pointer, but it worked. The compilers did support data structures bigger than 64kB (and bigger than 1MB), even though you couldn't have an offset bigger than 64kB. They supported this by changing the segment selector when necessary. Such pointer arithmetic was time-consuming and slow - and programmers laughed at it because true 32-bit processors were available at the time. But those didn't run microsoft windows. At least two operating systems used this programming model- windows 3.0 and os/2 v.1.3. The 80286 was popular, unfortunately. Using 48-bit pointers (16-bit selector + 32-bit offset) works much of the same way, but with an added problem: Where the 80286 created a 24-bit address from a 32-bit segmented pointer, the 80386 creates a 32-bit pointer from a 48-bit segmented pointer. This is the only extra problem that we get, other problems, such as the offset not being greater than 32-bit is solved the same way as 80286 programmers solved the problem of the offset not being more than 16 bit. The offset limitation don't stop us, it is merely a performance problem. The 32-bit address problem is solved by having only one segment selector marked present at any time. Accessing any other selector will then give a segment not present trap, similiar to a page fault. The os can then resolve the problem by changing the PAE-extended page tables, mapping a different 32-bit address space, marking the new selector present (and marking the previously used one not-present) and then restart the instruction. This step makes 48-bit segmented pointers even slower than the 32-bit
Re: perspectives on 32 bit vs 64 bit
On Friday 14 October 2005 18:53, Lennart Sorensen wrote: On Fri, Oct 14, 2005 at 12:18:50PM -0400, Adam Skutt wrote: That means it's logically impossible to have a 48-bit pointer, at all period. Sure. You have 32bit pointers. Yes, but it's obvious now you didn't understand what I said. You /cannot/ have more than 32-bits of virtual address space. Period. There is no way to do it. That is true. However you could have an OS that provided overlay style replacements of blocks of data or code at the request of the application. This of course requires custom applications to take advantage of such a feature. Not entirely true. You can (theoretically) use the high bits of segment registers to give an application 45 bit pointers[*]. This requires OS support and recompiling the application. It does not require explicit bank switching/overlay support in the application. ie. Well written protable applications should require no source level changes. As someone else said, performance is probably going to suck in the general case but may be reasonable if an application has good data locality. This may be acceptable if your application really needs a larger virtual address space on a 32-bit x86 cpu. With the advent of cheap 64-bit cpus this is all fairly academic. Paul [*] The bottom two bits are the DPL, so can't be used. The third bit selects between GDT/LDT, so you can get 2^46 - 2^35 bytes of useable application address space. However you'd need to sacrifice at least 1 address bit to allow efficient simultaneous access to logically discontiguous memory areas. One bit allows code and data to be far apart, more bits mean you can access multiple far-away data areas without incurring the fault overhead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Adam Skutt wrote: Helge Hafting wrote: You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. How? In protected-mode, they're in use as segement descriptor selectors. Certain bits have specific meanings you cannot override, as they're part of the memory protection mechanism. Yes, so? Simply have all but one segment not present and rely on the os to trap access and remap the page tables whenever the code switch segments. Remap the tables to what? The address used for the lookup with a PTE is 32-bit. Sigh. All mechanisms that lets the os support more than 4GB for several processes, can be used to support more than 4GB for a single process as well. That is trivial, although also less efficient than only supporting 4GB. History: 8086: 16-bit adressing, limited to 64kB. But segments allowed addressing of up to 1MB. 80286 protected mode: Still 16-bit adressing. The segment registers are turned into segment descriptor selectors. Now you can address up to 16 MB. 80386 32-bit mode without extensions: 32-bit addressing, limited to 4GB. there is also a set of page tables, so that virtual and physical addresses may be different. Physical addresses still limited to 32-bit. 80386 with PAE extensions: Still 32-bit addressing, but the page table can remap the 32-bit virtual addresses into a bigger address space. The _simple_ use of this is to support more than 4GB, but only 4GB per process. If you want more than 4GB for a _single_ process, then you need to change page table mappings as needed as the process runs. This can be done two ways: 1. The process explicitly calls into the memory management systems to do this. That means accessing more than 4GB isn't transparent, you have to code this explicitly - it isn't transparent to the programmer. 2. Use the segment descriptors. Now, each segment still can't map more than 4GB, but the os can mark most segments as not present. Whenever the app reloads a segment register, (i.e. trying to use a 48-bit pointer where the segment descriptor differs from the last pointer used) then the OS get a trap similiar to a page fault. The os can then look up which segment descriptor the app loaded, change the page tables accordingly, mark the segment present, and let the code continue.Performance may be reasonable for code that stay inside the same 4GB most of the time. Code that moves all over the place will take a very big performance hit as every memory operation page faults and incur the same overhead as a context switch. Still, this mode of operation is transparent to the programmer. I.e. you can recompile ordinary portable code (assuming you have a compiler supporting this memory model) and have it work without change. (Assuming the code makes no assumptions about the size or layout of a pointer, they are 48-bit and cannot be incremented with simple arithmetic only.) This is why I said you don't want to do this. Doable, but hard and not efficient. amd 64 mode: real 64-bit addressing, which is much easier to work with. It is better than 80386 PAE in the same way as 80386 32-bit was better than 80286 protexted mode. Addressing more than 4GB is now trivial. No tricks at all, as pointers are 64-bit. Old code that don't make assumptions about pointer size may be compiled without change. Helge Hafting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 13, 2005 at 09:43:51PM -0400, Jonathan Lewis wrote: I've been wondering this myself while watching the whole debate about memory lol Especially after a quick search shows up 1gig sticks as the largest out there now... So someone would need a board with 32 memory slots right now? (or 64 for the 64gig limit i suppose?) heh Unless I'm missing something here that seems like a LOT of memory sticks to cram on a mobo Which makes me wonder about the whole debate. Can any actually TEST the issue? I know I can't afford to TRY lmao http://www.tyan.com/products/html/vx50b4881.html 8 Opterons and up to 128GB ram. It has 4 memory sockets per cpu. I guess that means they think you can get 4GB dimms. Of course they have only tested 2GB dimms so far it would appear. I guess 4GB comes later if ever. As for who can afford that? I have no idea. Of course NUMA machines often have much more, but at the same time they probably don't manage their memory in quite the same way since the physical memory is less than 64GB per node I suspect and hence can be addressed fairly normally and memory on other nodes has to go through something else anyhow. Having never worked on one I am not quite sure how they manage all that. :) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Helge Hafting wrote: Adam Skutt wrote: Helge Hafting wrote: You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. How? In protected-mode, they're in use as segement descriptor selectors. Certain bits have specific meanings you cannot override, as they're part of the memory protection mechanism. Yes, so? That means it's logically impossible to have a 48-bit pointer, at all period. Sigh. All mechanisms that lets the os support more than 4GB for several processes, can be used to support more than 4GB for a single process as well. That is trivial, although also less efficient than only supporting 4GB. Yes, but it's obvious now you didn't understand what I said. You /cannot/ have more than 32-bits of virtual address space. Period. There is no way to do it. What you can do is remap the same virtual space to different physical addresses. Which is different from having extra v.a.s. Whenever the app reloads a segment register, (i.e. trying to use a 48-bit pointer where the segment descriptor differs from the last pointer used) This isn't a 48-bit pointer, because descriptor selectors aren't pointers. And it won't work anyway. How do I get a base offset higher than 0x? And if I add to it, what behavior is yielded? Not what is desired, to say the least. You can't have more than 32-bit v.a.s. Anytricks to get around that don't really get around that, they just have the same addresses the user-space code sees point to different physical addresses. I really don't see how this is possible leafing through the IA-32 System Programming Guide so links or text would be preferred. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Fri, Oct 14, 2005 at 12:18:50PM -0400, Adam Skutt wrote: That means it's logically impossible to have a 48-bit pointer, at all period. Sure. You have 32bit pointers. Yes, but it's obvious now you didn't understand what I said. You /cannot/ have more than 32-bits of virtual address space. Period. There is no way to do it. That is true. However you could have an OS that provided overlay style replacements of blocks of data or code at the request of the application. This of course requires custom applications to take advantage of such a feature. What you can do is remap the same virtual space to different physical addresses. Which is different from having extra v.a.s. Certainly. This isn't a 48-bit pointer, because descriptor selectors aren't pointers. And it won't work anyway. How do I get a base offset higher than 0x? And if I add to it, what behavior is yielded? Not what is desired, to say the least. You can't have more than 32-bit v.a.s. Anytricks to get around that don't really get around that, they just have the same addresses the user-space code sees point to different physical addresses. I really don't see how this is possible leafing through the IA-32 System Programming Guide so links or text would be preferred. Certianly no more possible than using more than 640k on an 8086 without swapping out code using overlays and loading different code in the same memory space and continuing there. It worked, but it was a pain the, and given we now have 64bit capable x86 cpu's, lets not even contemplate implementing such a mess. :) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Lennart Sorensen wrote: That is true. However you could have an OS that provided overlay style replacements of blocks of data or code at the request of the application. This of course requires custom applications to take advantage of such a feature. Right, which is what Windows does with AWE, which I mentioned originally. And AWE is used by only a precious few applications (SQL Server probably being the most widely known) has serious performance and VM drawbacks (1GB at a time, memory cannot be paged out, it's all wired in) and isn't practical for a lot of things. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Adam Skutt [EMAIL PROTECTED] writes: Helge Hafting wrote: You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. How? In protected-mode, they're in use as segement descriptor selectors. Certain bits have specific meanings you cannot override, as they're part of the memory protection mechanism. Intel has some extension that allows to address up to 64GB ram and linux supports that. But I'm not sure if that is also supported in 32bit mode on em64t. Wouldn't think so. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 13, 2005 at 03:09:57PM +0200, Goswin von Brederlow wrote: Intel has some extension that allows to address up to 64GB ram and linux supports that. But I'm not sure if that is also supported in 32bit mode on em64t. Wouldn't think so. It is. x86_64 architecture supports everything a P4 supports including PAE, SSE, SSE2 (and SSE3 in newer versions). After all who would build a chip that runs x86 and is destined for servers that does not support existing methods of allowing more than 4GB ram for 32bit OSs? If you look at /proc/cpuinfo you will see the pae flag mentioned on all amd64 systems. That means it can do 64 rather than just 4GB ram in 32bit mode, if the OS supports PAE. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Thu, Oct 13, 2005 at 03:09:57PM +0200, Goswin von Brederlow wrote: Intel has some extension that allows to address up to 64GB ram and linux supports that. But I'm not sure if that is also supported in 32bit mode on em64t. Wouldn't think so. It is. x86_64 architecture supports everything a P4 supports including PAE, SSE, SSE2 (and SSE3 in newer versions). The question is wether linux supports it too in that mode. It has to remap the 64bit page tables into the strange 64GB address setup. After all who would build a chip that runs x86 and is destined for servers that does not support existing methods of allowing more than 4GB ram for 32bit OSs? If you look at /proc/cpuinfo you will see the pae flag mentioned on all amd64 systems. That means it can do 64 rather than just 4GB ram in 32bit mode, if the OS supports PAE. IF. That is the big question. Len Sorensen MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 13, 2005 at 04:50:09PM +0200, Goswin von Brederlow wrote: The question is wether linux supports it too in that mode. It has to remap the 64bit page tables into the strange 64GB address setup. I meant the chip supports 64GB in 32bit mode. It is entirely an OS thing and does nothing whatsoever for the application, so in 64bit mode it has no meaning. PAE never helps an application have more than 4GB of address space. So in 64bit mode, 32bit applications still have the same 4GB limit they do in 32bit mode (both with and without PAE). The only difference is to allow 64GB in 32bit mode for the OS to address. IF. That is the big question. In 64bit mode the OS doesn't need PAE to address more than 4GB ram, so it has no meaning. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Goswin von Brederlow wrote: Intel has some extension that allows to address up to 64GB ram and linux supports that. Yes, PAE, for 64 GiB of physical, not /virtual/ RAM. Helege was trying to suggest you can get 48-bits of virtual addressing space, which isn't possible. In PAE, 32-bit virtual addresses are translated to 36-bit physical ones. The process still only sees 32-bit of space (and can only use 3G) but that memory could physically be located anywhere in a 64GB range now, instead of a 4G one. But I'm not sure if that is also supported in 32bit mode on em64t. Wouldn't think so. You mean, before entering long mode, or when running 32-bit apps in long mode. The answers I beleive are yes and no, respectively. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
just wondering, but do any of us here even *have* that much RAM? I count myself obscenely lucky to have 512 megs, much less a whole gig, or 32!!! the only boards that I know of that support that much memory are multi-processor boards, anyways, made by Tyan. Imagine a 4-CPU board with 32 gigs or so of RAM decked out with four witheringly-fast AMD dual-core Opteron 64s? That's also many hundreds (perhaps thousands) of times more than I can afford, but you've got to admit, AMD does have poor little Intel beat by a rather impressive margin. This also means, in a more on-topic point, that any linux OS that could actually *use* the 32 gigs would need to be a multi-cpu/multi-core distro, since there are no boards (to my knowledge) that support a whole 32 gigs for *one* CPU. -- === GCB v3.1 === GCS d-(+) s+:- a? C+() UL+++() P L++(+++) E- W+(+++) N++ w--- M++ PS-- PE Y+ PGP- t++(+++) 5? X? R !tv-- b++ DI+++ D-- G !e h(*) !r x--- === EGCB v3.1 ===
Re: perspectives on 32 bit vs 64 bit
On 10/13/05, lordSauron [EMAIL PROTECTED] wrote: just wondering, but do any of us here even *have* that much RAM?Icount myself obscenely lucky to have 512 megs, much less a whole gig,or 32!!!the only boards that I know of that support that much memoryare multi-processor boards, anyways, made by Tyan.Imagine a 4-CPU board with 32 gigs or so of RAM decked out with four witheringly-fastAMD dual-core Opteron 64s?That's also many hundreds (perhapsthousands) of times more than I can afford, but you've got to admit,AMD does have poor little Intel beat by a rather impressive margin. This also means, in a more on-topic point, that any linux OS thatcould actually *use* the 32 gigs would need to be amulti-cpu/multi-core distro, since there are no boards (to myknowledge) that support a whole 32 gigs for *one* CPU. --=== GCB v3.1 ===GCS d-(+) s+:- a? C+() UL+++() P L++(+++)E- W+(+++) N++ w--- M++ PS-- PE Y+ PGP- t++(+++) 5?X? R !tv-- b++ DI+++ D-- G !e h(*) !r x---=== EGCB v3.1 ===I've been wondering this myself while watching the whole debate about memory lol Especially after a quick search shows up 1gig sticks as the largest out there now... So someone would need a board with 32 memory slots right now? (or 64 for the 64gig limit i suppose?) heh Unless I'm missing something here that seems like a LOT of memory sticks to cram on a mobo Which makes me wonder about the whole debate. Can any actually TEST the issue? I know I can't afford to TRY lmao-- Passwords are like bubble gum, strongest when fresh, should never beused by groups and create a sticky mess when left laying around-anon
Re: perspectives on 32 bit vs 64 bit
Jonathan Lewis wrote: I've been wondering this myself while watching the whole debate about memory lol Especially after a quick search shows up 1gig sticks as the largest out there now... You can get 2GB and even 4GB sticks, if you know how. So someone would need a board with 32 memory slots right now? (or 64 for the 64gig limit i suppose?) Dual-socket Opteron motherboards support 16GB ram on 8 slots. Boards that support more are custom, and expensive. Can any actually TEST the issue? I know I can't afford to TRY lmao Yes, how do you suppose the kernel developers add the support? IBM sells 8-way Xeon boxes that support 32GB+ RAM. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Goswin von Brederlow wrote: The question is wether linux supports it too in that mode. It has to remap the 64bit page tables into the strange 64GB address setup. I think you're still confusing things here. When a x86_64 process is not in long-mode (i.e., 64-bit virtual addressing), it is a IA-32 processor. That includes supporting PAE. There is no 64-bit remapping to be done, because the PTEs are still 32bits. Whne it's in long mode (i.e., 64-bit virtual addressing), it has 48bits of physical addressing space to begin with. That totally precludes the need for PAE, so it doesn't need it. Remember, PAE is a physical addressing trick, to allow mapping of 32-bit virtual addresses to a 36-bit physical address space. In long mode, such tricks aren't needed, as the addressing is 64-bit virtual and 48-bit physical. IF. That is the big question. It does. Because you wouldn't be booting a x86_64 kernel, but a plain x86 one. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Faheem Mitha [EMAIL PROTECTED] writes: Hi, Thanks for your comments. On Fri, 30 Sep 2005, Lennart Sorensen wrote: On Fri, Sep 30, 2005 at 03:19:33PM -0400, Faheem Mitha wrote: What is the 4 Gig limit for 32 bit processors that people talk about? Does this mean that each process/thread can only get a limit of 4 Gig? Is there any workaround for this? Well given a 32bit program only has 32bit pointers, there isn't any clean simple way to gain more memory. I believe right now applications can have up to 2GB, although some kernel patches/settings allow up to 3 or 3.5GB/application by shrinking the kernel's piece. Normaly a 32bit i386 kernel supports only 1GB physical memory and has iirc a 2G:2G split between user and kernel space for virtual memory. With different options you get 4GB physical ram and a 3G:1G split at the expense of an extra level for the virtual memory mappings. The reason for splitting the address space is to have distinct addresses for user and kernel resources. I'm using the stock Debian AMD64 SMP kernel. Do you know what the memory value per application is for that? I don't understand why so much of the memory is taken by the kernel. If each application is 4GB, then why is the kernel taking as much as 2GB? Does that mean that the application only gets 1/2 the memory that the operating system has allocated to it? What is the other half being used for? The amd64 kernel has 64bit addresses and locates itself above the 4GB limit of 32bit processes. That means that all of the lowest 4GB can be used by the process without causing overlaps with the kernel. So in effect all artificial limits are removed and only the limit imposted by 32bit addresses remains. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Oct 03, 2005 at 02:04:43AM -0400, Faheem Mitha wrote: One option is to run a 64 system with a 32 bit chroot. I think there should be no problem with this. However, I was wondering if people has any idea whether it was possible to use the regular /home from inside the chroot. Also, is it possible to have X forwarding working from inside the chroot (assuming one is logging into the regular system)? Yes and yes. You can use a bind mount to make /home available in the chroot. X works if you keep $DISPLAY and have access to $HOME/.Xauthority. If you use dchroot, then the -d switch keeps the environment and X just works. The amd64 FAQ has lots about this. One more question is whether there is any problem sharing a home directory between a 32 and 64 bit Debian system on an amd64 (assuming one is dual-booting)? I'm just talking about ascii here, I know that binaries would need to be recompiled. No, that is fine. Except when it isn't. Gnome and kde apps seem to have problems when you use the 32bit binary with 64bit files or vice versa. But they frequently have problems using an older versions file too so this isn't overly unexpected. Hamish MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Helge Hafting wrote: You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. How? In protected-mode, they're in use as segement descriptor selectors. Certain bits have specific meanings you cannot override, as they're part of the memory protection mechanism. Simply have all but one segment not present and rely on the os to trap access and remap the page tables whenever the code switch segments. Remap the tables to what? The address used for the lookup with a PTE is 32-bit. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Adam Skutt wrote: Helge Hafting wrote: The limit is 4GB. No, wrong. The limit is 64 GiB physical RAM, period. PAE has been part of the ISA for pratically forever now, so it's silly to say it's anything else. Well, correct. However, practically, Linux can only use 16 GiB physical RAM without special patches, because of how the virtual memory is split by default (1GiB/3GiB). Windows is subject to the same limitation. Fully getting around this requires a 4G/4G patch, which is a terrible performance penalty because it requires a full TLB flush on every context switch. (Well, you can theoretically address more, but you definitely don't want to do the work necessary to do that. No, you cannot. One process cannot address more than 4 GiB virtual memory at a time, period. You can address more than 4GiB by using the always-unpopular segment registers found on intel processors. That means 48-bit pointers, which certainly can address more than 4G. And yes, I know that the segmentation mechanism creates a 32-bit address from the 48-bit pointer, but that can be worked around. Simply have all but one segment not present and rely on the os to trap access and remap the page tables whenever the code switch segments. It is ugly and bad for performance, which is why I said you don't want to do it. But doable - certainly. Helge Hafting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: perspectives on 32 bit vs 64 bit
Hamish Moffat wrote : And you might want to give Ubuntu a try. The amd64 version is quite How nice of you to say so on the debian-amd64 list! More like how insulting... Dear Hamish, I am not a total newbie in using Linux or Debian (I must still have e set of floppies bearing ham, in the same box where lies my treasured two-floppies linux 0.12 lies...). Nonwhistanding this experience, I have to tell that, when I made a very serious effort to install debian-amd64 on a new shiny laptop, I had the hardest time Debian gave me since the time some idiot messed with PAM modules in unstable, locking hundreds of unstable users out of their machines... In detail The debian-amd64 netboot disk installs a kernel (2.6.8) that does not support my hard disk controller, failing back to IDE PIO mode, of all things ! I had to first install development packages, kernel sources, a decent editor and recompile and install a new kernel. At PIO rates, I'll let you guess how much time I needed... Icing on the cake : the old kernel did not support keyboard properly, and I had to hack something at boot time. The curent tasksel insists on an X version that does not support my hardware either (ATI X700). I had no choice but to install XFree, *then* upgrading to xorg. Then it turned out that my new, shiny kernel did support my touchpad, but only when unloaded then reloaded. Yent another hack to do (playing with modules == yet another kernel...). Then, and only then, I hade a useable system ... with no openoffice. I had to install a chroot and grab a $#-+load of ia32 packages to do that. All of this took me two days. And require a load of previous Linux and Debian knowledge. Yet, all of this was deemed as obvious by the Debian Ordained Developers (TM). In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and installing took me one hour (two to get some fine-tuning working)... The one thing I had to sweat on was Wine (I still have to read some .mdb databases, inf*cluding forms and reports) : I had to install a chroot. Since I am interested in *USING* a computer (biostatistics and stats algorithms development + desktop apps overhead), I decided to keep Ubuntu for the time being... So, while Debian remains my tool of choice, its current amd64 incarnation *CANNOT* be given to Linux newbies. Ubuntu almost can. [ Donning asbestos longjohns... ] I'd like to add a general comment on Debian : while it is, IMHO, the best Free Software distribution available, its useability is somewhat spoiled by two factors : - Die-hard hackers, who seem unable to understand that recompiling a kernel is *not* something the average end-user (or even the average engineer more interested in engineering than tuning his tool) will do if it can be avoided at all... Ditto for xorg.conf hacking, ditto for cdrecord anomaly, ditto for ... (well, I won't make the list). - Holier than Stallman Free Software bigots, who object at anything not GPL, unable to understand the value of a temporary compromise... (e. g. refusing to provide a pointer to libdvdcss in totem or xine docs) While the latter factor seem to dwindle a bit these days (their latter effort to have non-free removed from Debian servers seems to have failed for good), the first one still remains a problem. Not much, I agree, but those quirks are irritating. [ Off longjohns. Pfew ... ] So the point made by T. Steffens seems quite valid to me. I tend to think that, if something is insulting, it is the currend usability of Debian-AMD64 on modern hardware by newbies/end-users/non-hackers... Emmanuel Charpentier Steaming off... -- Emmanuel Charpentier[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 10:17:14AM +0200, Emmanuel Charpentier wrote: Hamish Moffat wrote : And you might want to give Ubuntu a try. The amd64 version is quite How nice of you to say so on the debian-amd64 list! More like how insulting... I am not a total newbie in using Linux or Debian (I must still have e set of floppies bearing ham, in the same box where lies my treasured two-floppies linux 0.12 lies...). Nonwhistanding this experience, I have to tell that, when I made a very serious effort to install debian-amd64 on a new shiny laptop, I had the hardest time Debian gave me since the [...] So, while Debian remains my tool of choice, its current amd64 incarnation *CANNOT* be given to Linux newbies. Ubuntu almost can. Emmanuel, I understand that you had problems installing on your laptop. However I don't think you can conclude that all users will have trouble with debian-amd64 because it wouldn't install on your laptop. I don't think lack of DMA on the disk was the end of the world either, at install time. I have an nForce3-based Athlon64 desktop system and the installation was perfect. I suspect my scenario is far more common than yours. Then, and only then, I hade a useable system ... with no openoffice. I had to install a chroot and grab a $#-+load of ia32 packages to do that. Yes. This will be addressed in Debian in the future, through one of (or probably both) amd64 packages for Oo.org, and/or multi-arch. In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and installing took me one hour (two to get some fine-tuning working)... The Right. So its kernel supported your hardware better. I expect there are cases where the opposite is true. So the point made by T. Steffens seems quite valid to me. I tend to think that, if something is insulting, it is the currend usability of Debian-AMD64 on modern hardware by newbies/end-users/non-hackers... I think your sample size of 1 is unhelpful. There are plenty of other successful users of Debian-AMD64. Your rant about DDs is misplaced. There are plenty of people who do care about getting the stock kernel as useful as possible. They're doing a great job; pretty soon I'll have no systems at all running custom kernels. My real point was though that your Ubuntu advocacy is misplaced. I don't care if you use Ubuntu, but this is a Debian list. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Hamish Moffatt wrote: On Tue, Oct 04, 2005 at 03:26:12PM +0200, Thomas Steffen wrote: And you might want to give Ubuntu a try. The amd64 version is quite How nice of you to say so on the debian-amd64 list! More like how insulting... There is no need to take offense. We all know what distro ubuntu is based on, where would they be without debian? Now, ubuntu may have a few nice addons not in debian - if that is a problem, just grab include them. Ubuntu has benefitted from debian, nothing stops us from going the other way. I believe hw detection stuff in ubuntu is free stuff. . . Helge Hafting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: perspectives on 32 bit vs 64 bit
On 10/6/05, Hamish Moffatt [EMAIL PROTECTED] wrote: On Thu, Oct 06, 2005 at 10:17:14AM +0200, Emmanuel Charpentier wrote: ... Nonwhistanding this experience, I have to tell that, when I made a very serious effort to install debian-amd64 on a new shiny laptop, I had the hardest time Debian gave me since the[...] I have an nForce3-based Athlon64 desktop system and the installation wasperfect. I suspect my scenario is far more common than yours. I do not thing that blaming the user is a helpful approach. Anyway, this thread and others show that Debian amd64 is not currently suitable for newbies: the risk of encountering serious installation issues is just too high. In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and installing took me one hour (two to get some fine-tuning working)... Same experience here, on several systems (both i386 and amd64). My real point was though that your Ubuntu advocacy is misplaced.I don't care if you use Ubuntu, but this is a Debian list. This thead is not about Ubuntu advocacy, it is about problems users have with Debian amd64. If Ubuntu works better, than maybe it points toward the solution? I agree with Helge here: just as Ubuntu benefits tremendously from Debian, this could also go the other way round. Thomas
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 11:49:33AM +0200, Helge Hafting wrote: There is no need to take offense. We all know what distro ubuntu is based on, where would they be without debian? Now, ubuntu may have a few nice addons not in debian - if that is a problem, just grab include them. Ubuntu has benefitted from debian, nothing stops us from going the other way. I believe hw detection stuff in ubuntu is free stuff. . . Some stuff is going back and forth. Some of the stuff going in to d-i seems to be borrowed from ubuntu. Of course many of the developers work on both ubuntu and debian, and some packages even have changelogs for both debian and ubuntu intermigled now. Cooporation is a good thing. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 03:21:25PM +0200, Thomas Steffen wrote: I do not thing that blaming the user is a helpful approach. Anyway, this thread and others show that Debian amd64 is not currently suitable for newbies: the risk of encountering serious installation issues is just too high. Now it tells them that Debian Sarge is not appropriate for hardware not supported by 2.4.27 and 2.6.8 kernels. I doubt Redhat 9 would run any better on their hardware. Some people still try to install that on a brand new machine. Heck you can't even install windows XP on a brand new SATA based machine without a floppy drive to load extra drivers for the controller. This thead is not about Ubuntu advocacy, it is about problems users have with Debian amd64. If Ubuntu works better, than maybe it points toward the solution? I agree with Helge here: just as Ubuntu benefits tremendously from Debian, this could also go the other way round. Yes the solution being use an installer with a newer kernel. That is why I made a Sarge amd64 2.6.12 kernel install cd. It has helped quite a few people install on hardware not supported by 2.6.8. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 10:17:14AM +0200, Emmanuel Charpentier wrote: I am not a total newbie in using Linux or Debian (I must still have e set of floppies bearing ham, in the same box where lies my treasured two-floppies linux 0.12 lies...). Nonwhistanding this experience, I have to tell that, when I made a very serious effort to install debian-amd64 on a new shiny laptop, I had the hardest time Debian gave me since the time some idiot messed with PAM modules in unstable, locking hundreds of unstable users out of their machines... In detail Laptops love proprietary hardware. New laptop implies new chips, which of course require a newer than that kernel to support. The kernel in sarge hardly qaulifies for that. The debian-amd64 netboot disk installs a kernel (2.6.8) that does not support my hard disk controller, failing back to IDE PIO mode, of all things ! I had to first install development packages, kernel sources, a decent editor and recompile and install a new kernel. At PIO rates, I'll let you guess how much time I needed... Icing on the cake : the old kernel did not support keyboard properly, and I had to hack something at boot time. At least you got a fall back to pio mode. Many people don't even get that. The curent tasksel insists on an X version that does not support my hardware either (ATI X700). I had no choice but to install XFree, *then* upgrading to xorg. Hmm, you bought something with an ATI. Well you deserve the trouble that causes then. :) Then it turned out that my new, shiny kernel did support my touchpad, but only when unloaded then reloaded. Yent another hack to do (playing with modules == yet another kernel...). Also fixed in a newer kernel. So are many acpi problems. 2.6.8 isn't that good a kernel really, but 2.6.10 (the other option sarge had) had some other worse problems. 2.6.12 looks to be a kernel that would have been great for sarge, had it been around when sarge needed a kernel. Then, and only then, I hade a useable system ... with no openoffice. I had to install a chroot and grab a $#-+load of ia32 packages to do that. So openoffice was coded by peopel that didn't code things cleanly. So it doesn't work in 64bit (for 1.x releases that is). So ubuntu does the 32/64bit mix for you, and debian amd64 aims at being a pure 64bit system. Different goal, different result. All of this took me two days. And require a load of previous Linux and Debian knowledge. Yet, all of this was deemed as obvious by the Debian Ordained Developers (TM). I wouldn't know, I am not one. It does seem obvious to me that installing software older than your hardware should result in problems. In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and installing took me one hour (two to get some fine-tuning working)... The one thing I had to sweat on was Wine (I still have to read some .mdb databases, inf*cluding forms and reports) : I had to install a chroot. And what kernel does that version of ubuntu use and when was it released? I suspect the latest testing/unstable installer would work fine too (if it's not one of its broken days). Of course I have heard ubuntu has some very nice laptop support by default that debian doesn't do. Since I am interested in *USING* a computer (biostatistics and stats algorithms development + desktop apps overhead), I decided to keep Ubuntu for the time being... Makes pretty good sense. They can mostly share packages anyhow. So, while Debian remains my tool of choice, its current amd64 incarnation *CANNOT* be given to Linux newbies. Ubuntu almost can. i386 would have given you almost exactly the same problems (except OO.o, but that's a different issue). [ Donning asbestos longjohns... ] I'd like to add a general comment on Debian : while it is, IMHO, the best Free Software distribution available, its useability is somewhat spoiled by two factors : - Die-hard hackers, who seem unable to understand that recompiling a kernel is *not* something the average end-user (or even the average engineer more interested in engineering than tuning his tool) will do if it can be avoided at all... Ditto for xorg.conf hacking, ditto for cdrecord anomaly, ditto for ... (well, I won't make the list). Does any other distribution include a tool to help you do that (kernel-package)? Does debian tell you you need to compile a new kernel? (No it doesn't). It even has a tool to compile modules from source for your debian provided kernel (module-assistant) or even against your own kernel build should you choose to make one. - Holier than Stallman Free Software bigots, who object at anything not GPL, unable to understand the value of a temporary compromise... (e. g. refusing to provide a pointer to libdvdcss in totem or xine docs) While the latter factor seem to dwindle a bit these days (their latter effort to have non-free removed from Debian servers seems to have
Re: Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 03:21:25PM +0200, Thomas Steffen wrote: On 10/6/05, Hamish Moffatt [EMAIL PROTECTED] wrote: I have an nForce3-based Athlon64 desktop system and the installation was perfect. I suspect my scenario is far more common than yours. I do not thing that blaming the user is a helpful approach. Anyway, this That wasn't my intention. Only to point out that his system is not typical and to conclude that Debian-amd64 is not suitable for any newbie based on that experience is wrong. My real point was though that your Ubuntu advocacy is misplaced. I don't care if you use Ubuntu, but this is a Debian list. This thead is not about Ubuntu advocacy, it is about problems users have with Debian amd64. If Ubuntu works better, than maybe it points toward the solution? The solution is to improve Debian, not to switch to Ubuntu. Perhaps that's what you meant. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Dear Lennart, dear list, Didn't want to start a shouting contest ... So a fast answer with lots of [ Snips ... ] : Lennart Sorensen wrote: [ Snip... ] Laptops love proprietary hardware. New laptop implies new chips, which of course require a newer than that kernel to support. The kernel in sarge hardly qaulifies for that. Which was *precisely* my point ... [ ... ] The curent tasksel insists on an X version that does not support my hardware either (ATI X700). I had no choice but to install XFree, *then* upgrading to xorg. Hmm, you bought something with an ATI. Well you deserve the trouble that causes then. :) No choice nowadays when you buy a laptop. At least, this one can be used with free drivers (fbdev, ati, radeon ...), which is more than one can say of most laptop video hardware. And yes, I checked that point before buying. And no, I do *not* deserve that : this is what I call Holier than Stallman attitude. It reeks of self-righteousness. Ooops : there was a smiley at the end... [ re-re-Snip ... ] So openoffice was coded by peopel that didn't code things cleanly. So it doesn't work in 64bit (for 1.x releases that is). So ubuntu does the 32/64bit mix for you, and debian amd64 aims at being a pure 64bit system. Different goal, different result. As a developper, I could agree. As an user, I couldn't care less. What I see is one pure-amd-64, which might be a 32-bits-library virgin (holier than thou attitude, again...) but is unable to use a very useful tool (many people have to cope with M$-formatted documents for now : not every institution is (yet) as wies as the Massachussets (sp ?) state...) without requiring work largely exceeeding the average end-user knowledge ; the other made practical compromises : it cannot boast 32-bits purity, but is usable by the average John Doe (which I tend to be, as far as systems go ...). Is the goal of Debian to be a hackers-only distribution ? That's not my reading of the Social Contract... All of this took me two days. And require a load of previous Linux and Debian knowledge. Yet, all of this was deemed as obvious by the Debian Ordained Developers (TM). I wouldn't know, I am not one. It does seem obvious to me that installing software older than your hardware should result in problems. (Semi-) correct (most modern hardware seem to be useable with older Micro$oft crocks), but irrelevant. In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and installing took me one hour (two to get some fine-tuning working)... The one thing I had to sweat on was Wine (I still have to read some .mdb databases, inf*cluding forms and reports) : I had to install a chroot. And what kernel does that version of ubuntu use and when was it released? 2.6.12... I suspect the latest testing/unstable installer would work fine too (if it's not one of its broken days). Hah ! I tried that. and bit my fingers up to the elbows... [ re-re-re-Snip ... ] i386 would have given you almost exactly the same problems (except OO.o, but that's a different issue). My point, again ... It seems to be a Debian problem (see below). [ Donning asbestos longjohns... ] I'd like to add a general comment on Debian : while it is, IMHO, the best Free Software distribution available, its useability is somewhat spoiled by two factors : - Die-hard hackers, who seem unable to understand that recompiling a kernel is *not* something the average end-user (or even the average engineer more interested in engineering than tuning his tool) will do if it can be avoided at all... Ditto for xorg.conf hacking, ditto for cdrecord anomaly, ditto for ... (well, I won't make the list). Does any other distribution include a tool to help you do that (kernel-package)? Does debian tell you you need to compile a new kernel? (No it doesn't). It even has a tool to compile modules from source for your debian provided kernel (module-assistant) or even against your own kernel build should you choose to make one. While I agree that kernel-package is a great tool, my feeble attempts at module-assistant failed miserably : at least in unstable, module-assistant complains about kernel-tree not being this or that in terms so obscure that it seemed simpler to configure and compile a new kernel. - Holier than Stallman Free Software bigots, who object at anything not GPL, unable to understand the value of a temporary compromise... (e. g. refusing to provide a pointer to libdvdcss in totem or xine docs) While the latter factor seem to dwindle a bit these days (their latter effort to have non-free removed from Debian servers seems to have failed for good), the first one still remains a problem. Not much, I agree, but those quirks are irritating. Actually many of the debian developers aren't too pleased by the GPL, and especially are worried what the FSF will come up with for GPLv3 given what they did for the documentation license. I have
Debian based distros was Re: perspectives on 32 bit vs 64 bit
Helge Hafting wrote: Hamish Moffatt wrote: On Tue, Oct 04, 2005 at 03:26:12PM +0200, Thomas Steffen wrote: And you might want to give Ubuntu a try. The amd64 version is quite How nice of you to say so on the debian-amd64 list! More like how insulting... There is no need to take offense. We all know what distro ubuntu is based on, where would they be without debian? Now, ubuntu may have a few nice addons not in debian - if that is a problem, just grab include them. Ubuntu has benefitted from debian, nothing stops us from going the other way. I believe hw detection stuff in ubuntu is free stuff. . . Helge Hafting Surely folks that use Ubuntu, Kubuntu or Kanotix (64 bit systems) etc. can still benefit from the superior knowledge of this list (where it applies to things Debian rather than other distro specifics). I actually run Kanotix purely because it had all the stuff out_of_the_box to run my newish hardware. I won't be singing the praises of other distros but will from time_to_time ask or answer some questions (if I can) which will benefit the other users of this list. We are actually all Debian users at heart so, so long as we *speak* Debian then we should be able to help each other. Please let's not be too quick to judge someone else's use of a Debian derivative that was easier to install than *pure* Debian; it is Debian really - just has a different wrapper. Let's help as many folks as we can Blessings, Nigel -- It's not a problem -- it's a learning opportunity. -- I AM Bible Studies and Resources http://www.i-amfaithweb.net Messianic E-Cards.com http://www.messianicecards.com OliveRoot Ministries http://www.oliveroot.net PrayingForIsrael.net http://www.prayingforisrael.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 06:37:26PM +0200, Emmanuel Charpentier wrote: No choice nowadays when you buy a laptop. At least, this one can be used with free drivers (fbdev, ati, radeon ...), which is more than one can say of most laptop video hardware. And yes, I checked that point before buying. And no, I do *not* deserve that : this is what I call Holier than Stallman attitude. It reeks of self-righteousness. Ooops : there was a smiley at the end... Do you want a laptop that uses only free open source drivers? Buy a centrino based system. intel does seem to actually support open source. Do not buy ATI, they haven't really offered anything for open source for probably 3 or 4 years now (at least it seems to take that long before any of their cards work with open source drivers). At least nvidia offers closed source drivers for _all_ their chips as soon as they offer windows support for them, including mobile chips. And it seems open source 2d support happens very quickly too for nvidia. So yes I am quite sure ati chips are your worst choice for open source drivers. Many laptops have intel or nvidia chips in them and are much easier to get to work. As a developper, I could agree. As an user, I couldn't care less. What I see is one pure-amd-64, which might be a 32-bits-library virgin (holier than thou attitude, again...) but is unable to use a very useful tool (many people have to cope with M$-formatted documents for now : not every institution is (yet) as wies as the Massachussets (sp ?) state...) without requiring work largely exceeeding the average end-user knowledge ; the other made practical compromises : it cannot boast 32-bits purity, but is usable by the average John Doe (which I tend to be, as far as systems go ...). If you have a 2 or 3 year old system, installing debian is usually quite simple, if you pick one of the completely supported architectures. amd64 isn't even officially a debian architecture yet, partially because it isn't fully supporting everything yet, and it is so new. Is the goal of Debian to be a hackers-only distribution ? That's not my reading of the Social Contract... Well the goal of amd64 was to make a 64bit pure debian for x86_64 systems. They did that. Some programs may not compile for 64bit systems yet, but that still doesn't mean the goal is failing. It just takes time. ubuntu's goal for amd64 was a complete working system with everything, including both 64bit programs for most things, and 32bit program support. Redhat did the same thing with their (somewhat hackish) biarch support. (Semi-) correct (most modern hardware seem to be useable with older Micro$oft crocks), but irrelevant. I tried to install winxp on a new amd64 server I bought, just to see if it could run on it, and eventually gave up due to the sata controller needing a driver loaded and I didn't have a floppy drive in the system. Debian installed without any problems using the kernels in sarge. Does this mean windows xp is unusuable by your average user? It means your average user can't install windows themselves (or any other os for that matter). That is generally true, and I don't think installing and configuring a system is supposed to be done by your average user. Of microsoft can't do it with their resources how could anyone else? :) 2.6.12... Excactly. 2.6.12 actually has some support for ati chipsets, which earlier kernels didn't. Hah ! I tried that. and bit my fingers up to the elbows... Well there have been many 'broken' days lately. Oh well. My point, again ... It seems to be a Debian problem (see below). Any distribution with 2.6.8 kernel would have the same problem on your laptop. That does not make it a debian problem, it makes it a problem of trying to use software on unsupported hardware (unsupported by that particular software version). While I agree that kernel-package is a great tool, my feeble attempts at module-assistant failed miserably : at least in unstable, module-assistant complains about kernel-tree not being this or that in terms so obscure that it seemed simpler to configure and compile a new kernel. Hmm, I always found it rather easy to use (especially using debian provided kernels). m-a -t prepare m-a -t a-i nvidia ipw2200 etc I have mixed views on this (documentation license) : I think tat neither DFDGuidelines nor GPL doc license answer essential requirements, but I am not sure that those essential documenrs are mutually compatible... Therefore, I'll refrain taking sides until I understand better the issues at hand. Sensible position to have I think so far. I don't fully understand what the issue with the documentation license is myself. Agreed for stable. But that's also a problem with testing and unstable. Cuirrent testing and unstable disks are unusable : this can be forgiven for unstable, less so with testing ... Well the debian installer is being improved with some major
Re: perspectives on 32 bit vs 64 bit
Helge Hafting wrote: The limit is 4GB. No, wrong. The limit is 64 GiB physical RAM, period. PAE has been part of the ISA for pratically forever now, so it's silly to say it's anything else. However, practically, Linux can only use 16 GiB physical RAM without special patches, because of how the virtual memory is split by default (1GiB/3GiB). Windows is subject to the same limitation. Fully getting around this requires a 4G/4G patch, which is a terrible performance penalty because it requires a full TLB flush on every context switch. (Well, you can theoretically address more, but you definitely don't want to do the work necessary to do that. No, you cannot. One process cannot address more than 4 GiB virtual memory at a time, period. The only way to give more physical addressing is via mapping techniques, which is what Windows does with AWE. In eitehr case, you only have 4 GiB of virtual memory available at once. But the gain of that was questionable when it was first implemented in Windows, and is even more so now. See: http://blogs.msdn.com/oldnewthing/archive/2004/08/18/216492.aspx Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Thu, Oct 06, 2005 at 06:37:26PM +0200, Emmanuel Charpentier wrote: In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and And what kernel does that version of ubuntu use and when was it released? 2.6.12... Please compare apples with apples. You used a pre-release Ubuntu CD and compare it with a Debian version released months ago. Debian has kernel 2.6.12 now (though perhaps not in an installer image yet) which may fix your problems also. Ubuntu seems to have *one* goal lacking in Debian (while present in the Social Contract) : useability by end-users. That's also an insult. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Hamish Moffatt wrote: On Thu, Oct 06, 2005 at 06:37:26PM +0200, Emmanuel Charpentier wrote: In contrast, putting an Ubuntu (amd64 5.10 preview) CD in the drive and And what kernel does that version of ubuntu use and when was it released? 2.6.12... Please compare apples with apples. You used a pre-release Ubuntu CD and compare it with a Debian version released months ago. Debian has kernel 2.6.12 now (though perhaps not in an installer image yet) which may fix your problems also. Ubuntu seems to have *one* goal lacking in Debian (while present in the Social Contract) : useability by end-users. That's also an insult. It's worth keeping in mind that Ubuntu is built on and refines Debian, syncs with it before a new release, and could not possibly succeed without Debian. It's not an alternative distribution, more like a new flavor. On the other hand, the extra work they put into making the distribution user-friendly should not be denied and opens up Debian to a larger number of users. Their six-month release cycle ensures that people can rely on an updated yet reasonably bugtested release, filling the hole that has long existed between stable and unstable. Still, it's interesting to consider Ubuntu's effect on the Debian project. There may be some negatives; at least so far, the bugreporting in Debian is far superior, but that doesn't mean the bugs get fixed. A tighter coordination where Ubuntu really was an official flavor might be better. I get the feeling the Debian project has become so large that the systems put in place to ensure quality and universality end up less sensitive to parts of the user base, notably non-developer desktop users that need a recent but still stable installation. This is hopefully a rapidly growing segment of Debian users and Ubuntu is helping in spades. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On (06/10/05 16:36), David Liontooth wrote: Hamish Moffatt wrote: On Thu, Oct 06, 2005 at 06:37:26PM +0200, Emmanuel Charpentier wrote: It's worth keeping in mind that Ubuntu is built on and refines Debian, syncs with it before a new release, and could not possibly succeed without Debian. It's not an alternative distribution, more like a new flavor. On the other hand, the extra work they put into making the distribution user-friendly should not be denied and opens up Debian to a larger number of users. Their six-month release cycle ensures that people can rely on an updated yet reasonably bugtested release, filling the hole that has long existed between stable and unstable. Still, it's interesting to consider Ubuntu's effect on the Debian project. There may be some negatives; at least so far, the bugreporting in Debian is far superior, but that doesn't mean the bugs get fixed. A tighter coordination where Ubuntu really was an official flavor might be better. I get the feeling the Debian project has become so large that the systems put in place to ensure quality and universality end up less sensitive to parts of the user base, notably non-developer desktop users that need a recent but still stable installation. This is hopefully a rapidly growing segment of Debian users and Ubuntu is helping in spades. There've been a few posts on the Ubuntu/Debian debate .. I found this enlightening: https://wiki.ubuntu.com/MarkShuttleworth?highlight=%28debian%29%7C%28mark%29%7C%28shuttleworth%29 Regards Clive -- www.clivemenzies.co.uk ... ...strategies for business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Emmanuel Charpentier wrote: - Holier than Stallman Free Software bigots, who object at anything not GPL, unable to understand the value of a temporary compromise... (e. g. refusing to provide a pointer to libdvdcss in totem or xine docs) Ummm, totem and xine docs not mentioning it (if that's really the case, haven't checked) is probably a bug. As far as distributing lidvdcss, we don't do that because there is a reasonable chance that doing so is a *felony.* You can blame Congress for that. Oh, and: $ cat /usr/share/doc/libdvdread3/README.Debian libdvdread for Debian - Many DVDs use css. To play these discs, a special library is needed to decode them, libdvdcss. Due to legal problems, Debian cannot distribute libdvdcss, but it is available on other places on the internet. If it is legal for you to use css, you can run '/usr/share/doc/libdvdread3/examples/install-css.sh' at any time to download and install it. -- Mikael Hedin [EMAIL PROTECTED], Tue Jul 13 14:14:08 2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Faheem Mitha wrote: Dear People, I have an Opteron server, on which I am running the AMD64 Debian port. For various reasons, I'm contemplating going back to 32 bit. The major reason is that aside from the packages in the AMD64 Debian archive, it is not always easy to find Debian packages for AMD64, since i386 is still very much the default. Also, not all software compiles with AMD64. There should be no need to go back to 32-bit for this reason. Please note that the opteron, in 64-bit mode with a 64-bit kernel running and all the 64-bit software you can get, is still capable of running the odd 32-bit program just fine. I am aware that 64 bit computing has considerable advantages as well. Indeed, so get the best of both worlds: * 64-bit performance for all software that _is_ ported, which is most of it, * and 32-bit software for those few programs who either are proprietary or proved surprisingly hard to port. I'm looking for perspectives from people who have experience with both, and what their feelings about this are. I run both kinds of software on my home machine. Almost everything 64-bit, but a 32-bit chroot so I can run a 32-bit webbrowser in order to use 32-bit java/flash plugins. (There is as yet no good 64-bit java webbrowser plugin, although there is a 64-bit java.) Specifically, I was looking for clarifications about memory issues. I have looked at stuff on the web, but am still confused. What is the 4 Gig limit for 32 bit processors that people talk about? Does this mean that each process/thread can only get a limit of 4 Gig? Is there any workaround for this? 32-bit programs cannot address more than 4GB, because that's all you can address in a 32-bit pointer. Various trickery exists that lets 32-bit intel machines access more than 4GB _in total_ (but still limited to 4GB per process), but these tricks robs you of some performance! There are no such problems with 64 bit. Of course there is a limit, but it is at 17179869184 GB. Nothing to worry about today. :-) What are the other limits? I read elsewhere that a 32 bit Linux system has an effective limit of 16 Gig usable memory total. The limit is 4GB. Intel has various tricks to up this limit a bit, all with some performance impact and limitations. The main limitation of course, is that one _single_ process won't get more than 4GB anyway. (Well, you can theoretically address more, but you definitely don't want to do the work necessary to do that. (First, make a compiler to make such code, then port the kernel to use 48-bit segmented pointers, by the time you're finished all 32-bit hw is obsolete and people will be worrying more about the Y10K problem. :-) It is so much easier to just go 64-bit, and then 2GB or 4GB isn't special numbers at all any more. A single process can use billions of GB, if you can afford a machine that big. A single data structure can be bigger than 4GB . . . Helge Hafting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On 9/30/05, Faheem Mitha [EMAIL PROTECTED] wrote: I have an Opteron server, on which I am running the AMD64 Debian port. Forvarious reasons, I'm contemplating going back to 32 bit. I feel with you. As much as I like a native 64bit system, it is just too much of a pain to get all the stuff together. Even for something as simple as Acrobat Reader it takes hours of configuration before it works without a chroot. I did the conversion back to 32bit for Windows XP. XP x64 offers no obvious advantages, and a lot of headache, even though most legacy applications install just fine. So if you think you want to got back, I think you should just do it. You can still run a 64bit kernel and have a 64bit chroot for the cases where it makes a difference. For most everyday tasks I cannot see any obvious difference, though. The major reason is that aside from the packages in the AMD64 Debianarchive, it is not always easy to find Debian packages for AMD64, since i386 is still very much the default. Also, not all software compiles withAMD64. Also even common packages seem to have a lot more bugs when compiled as 64bit application compared to the 32bit binary. What is the 4 Gig limit for 32 bit processors that people talk about? Doesthis mean that each process/thread can only get a limit of 4 Gig? Is there any workaround for this? No. Each 32bit application is limited to about 3 GB of linear address space. The application can implement its own memory management scheme with overlays, paging etc, but that is more pain than it is worth. Anyway, how many applications do you have that want more than 3 GB of memory? What are the other limits? I read elsewhere that a 32 bit Linux system hasan effective limit of 16 Gig usable memory total. That is only true for a 32bit kernel, which is not necessary for a 32bit userland. Anyway, how much memory do you have? And you might want to give Ubuntu a try. The amd64 version is quite polished, and the compatibility libraries are imho in a better state. You can also run the i386 version with added amd64 compatibilities libraries. In any case try the beta for 5.10, it should have some nice improvements over 5.4 (which is already pretty useful). Thomas
Re: perspectives on 32 bit vs 64 bit
On Tue, Oct 04, 2005 at 03:26:12PM +0200, Thomas Steffen wrote: I feel with you. As much as I like a native 64bit system, it is just too much of a pain to get all the stuff together. Even for something as simple as Acrobat Reader it takes hours of configuration before it works without a chroot. Why would you care about Acrobat? xpdf, gpdf, gv, evince etc are all replacements. And you might want to give Ubuntu a try. The amd64 version is quite How nice of you to say so on the debian-amd64 list! More like how insulting... Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Mon, Oct 03, 2005 at 02:04:43AM -0400, Faheem Mitha wrote: I don't understand why so much of the memory is taken by the kernel. If each application is 4GB, then why is the kernel taking as much as 2GB? Does that mean that the application only gets 1/2 the memory that the operating system has allocated to it? What is the other half being used for? The kernel is taking 2Gb of address space, not memory. You can have multiple applications using 2Gb each. An application can only have 2Gb allocated to it. The kernel uses its space for PCI devices etc. One option is to run a 64 system with a 32 bit chroot. I think there should be no problem with this. However, I was wondering if people has any idea whether it was possible to use the regular /home from inside the chroot. Also, is it possible to have X forwarding working from inside the chroot (assuming one is logging into the regular system)? Yes and yes. You can use a bind mount to make /home available in the chroot. X works if you keep $DISPLAY and have access to $HOME/.Xauthority. If you use dchroot, then the -d switch keeps the environment and X just works. One more question is whether there is any problem sharing a home directory between a 32 and 64 bit Debian system on an amd64 (assuming one is dual-booting)? I'm just talking about ascii here, I know that binaries would need to be recompiled. No, that is fine. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Mon, 3 Oct 2005 17:49:06 +1000, Hamish Moffatt [EMAIL PROTECTED] wrote: On Mon, Oct 03, 2005 at 02:04:43AM -0400, Faheem Mitha wrote: I don't understand why so much of the memory is taken by the kernel. If each application is 4GB, then why is the kernel taking as much as 2GB? Does that mean that the application only gets 1/2 the memory that the operating system has allocated to it? What is the other half being used for? The kernel is taking 2Gb of address space, not memory. You can have multiple applications using 2Gb each. An application can only have 2Gb allocated to it. The kernel uses its space for PCI devices etc. Hmm. Thanks, that's very informative. That makes it much less likely we will be switching back to 32 bit. One option is to run a 64 system with a 32 bit chroot. I think there should be no problem with this. However, I was wondering if people has any idea whether it was possible to use the regular /home from inside the chroot. Also, is it possible to have X forwarding working from inside the chroot (assuming one is logging into the regular system)? Yes and yes. You can use a bind mount to make /home available in the chroot. Yes, I thought that might be possible. X works if you keep $DISPLAY and have access to $HOME/.Xauthority. If you use dchroot, then the -d switch keeps the environment and X just works. Can you point me to a good reference to this kind of stuff? There is lots of info on the net, but I don't know what is the best. One more question is whether there is any problem sharing a home directory between a 32 and 64 bit Debian system on an amd64 (assuming one is dual-booting)? I'm just talking about ascii here, I know that binaries would need to be recompiled. No, that is fine. Thanks. That's very helpful. Faheem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
[EMAIL PROTECTED] (Lennart Sorensen) writes: A 64bit application has 64bit memory pointers, I thought opteron memory was less than 64 bit wide. I'm remembering reading somewhere (here?) it was 40 bits. so it can address much more than 4GB of memory. True in either case. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Pointers are 64-bits in 64-bit mode. The current generation AMD64 MMUs can only handle 64-bit pointers in which the high-order 17 bits are all the same (40 bits of information). Software won't have to be re-written when AMD64 chips get larger MMUs, though. (Of course, if the software is hard-coded to limit itself to 1/2 TB user-space memory, it will still be limiting itself.) -Karl On 9/30/05, Brett Viren [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Lennart Sorensen) writes: A 64bit application has 64bit memory pointers, I thought opteron memory was less than 64 bit wide. I'm remembering reading somewhere (here?) it was 40 bits. so it can address much more than 4GB of memory. True in either case. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
On Fri, Sep 30, 2005 at 04:56:41PM -0400, Brett Viren wrote: [EMAIL PROTECTED] (Lennart Sorensen) writes: A 64bit application has 64bit memory pointers, I thought opteron memory was less than 64 bit wide. I'm remembering reading somewhere (here?) it was 40 bits. Current opteron's may have that as a physical limit on address pins. The architecture supports 64bit memory space because it has 64bit pointers, and future opterons are certainly going to have memory controllers that can go past 40 or 48bit or whatever the current limit is. Software has no need to know about this limit since to the user software it all just looks like memory somewhere in a 64bit memory space. so it can address much more than 4GB of memory. True in either case. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: perspectives on 32 bit vs 64 bit
Lennart Sorensen wrote: No 64GB max is the limit on inte's memory extensions on i386. If linux limits it to less than that, I am not aware of it. Of course I have never had a machine with that much memory either. AFAIK, 16 GiB is still the practical limit due to the way/where the page_mem array must be stored. This was certainly the case in 2.4. The only easy way around it is to remove the memory split entirely (i.e., both userspace and kernelspace have 4G all the time), but this carries a terrible performance hit as the entire TLB cache would be flushed on context switch. RH carried the patch in some of their enterprise kernels, at least in the past. I don't know if they still do for 2.6. FWIW, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
