Comparing on Intel hardware? The other commercial Unixen in the article claim to have support for up to 128GB memory. Definitely not on Intel, I'd say.
Default x86 Linux has 960MB physical memory support and 3GB user address space. A patch exists to up the phys memory support to 2GB, but that reduces the user address space to 2GB.
The reason for this is that all physical memory is constantly mapped by the kernel and therefore can instantly be accessed without modifying the page table. Mapping it only on demand would allow more physical memory, but the consent on the linux-kernel mailing list was that this would suck performance-wise.
It may be possible in the future to use additional (unmapped) phys memory as a ram disk (which can be used as high priority swap).
All this is not an issue for 64-bit platforms as the virtual address space for these is really vast. Although at above 4GB the problem arises that PCI cards without 64-bit addressing won't be able to DMA into/from memory above 4G. The solution is to use memory from below 4G (just as with ISA DMA from below 16M), but there is no kernel support for that yet.
The Celerons are P2s in their core and have the same SMP support. Intel just did not provide the required control pins on the Celerons (and these can be used with the SMP adapters). Therefore, if I'm not wrong, Celerons also support only 2-way SMP just as a P2.
Probably, if the P2 would support more than 2-way in their chips you could probably connect more. But they can't electrically drive a SMP bus with more than 2 nodes, so operation would be either unreliable or unusable.
The APIC bus specs is one thing, what the CPU implements is another. The PIIs only support 2-way SMP. Electrically they can only drive 2-way buses, so even if they could support more in their APIC support, they don't. That's like the UW-SCSI chips which support 16-node setups but can only drive 8.
I heard of a Linux port of SAP R/3 quite some time ago (maybe 5 months), but it was an unofficial, unsupported port then (sort of like Quake1/2). It's just that recently SAP decided to make that an official port with company support (after lots of requests from people who want R/3 on Linux).
"My intent here is not to advocate fraudulent sales from remarking"
Don't worry, the real remarkers are doing batches of thousands and sell them through many nations to be untraceable. This is not about some home remarkers:-)
That would be one of the simpler fakes. Real repackaging is also done, not only overwriting. These are so convincing that even official Intel distributors reportedly sold fakes without knowing.
So far Intel made a good deal by not marking their CPUs with their intended speed. With all the CPU faking going on, they probably managed to sell quite a few more chips - one middle speed CPU to the professional fakers and one high speed CPU to the end customers whose overclocked CPU didn't work properly.
Until now, if the chip did work most of the time (with all the people using Windows, a little instability goes unnoticed), there was no way of telling whether you really got what you paid for when you bought a P-II. Only details e.g. on the L2 cache implementation could be used to distinguish real from faked 300MHz CPUs.
Errm, really, shuttle tanks were chosen just because they would not have to be transported into space - because they are already there. The trick is to keep them there instead of dropping them back to earth.
Probably the tanks would have to be slightly redesigned, but the point is that they are the framework and are stuffed out with hotel stuff. My guess would be that there is not much to be done, as the tanks are just the foundation on (or better in) which the hotels will be built.
How much will this cost?
on
Space Hotel
·
· Score: 1
Current costs don't say much. First, current space travel is a government project. And those projects are not exactly known to be cost effective.
There are actually a few commercial companies trying to establish their own space transport (unmanned, though) and be real cheap compared to governmental space travel.
Bah, just don't start any wm and start your apps full-screen. There you are:-)
MUI had it - only what - 6? years ago ...
on
GNOME 1.0 Released
·
· Score: 1
"Also, a widget's code only ever loaded once - in the whole system. Now thats whay I call a shared library..."
Actually that's just how shared libraries work under most modern Unixes including Linux. And that's how GTK/GNOME works therefore (all widgets in the libraries are only loaded once per system).
Additionally the parts of the library that are not used are not loaded, same with binaries. AmigaOS may be saving resources, but you can save much more with virtual memory.
Those are not comparable. You can compare GTK+ and MUI, however. They are both widget sets (GNOME is much more, it is just based on GTK+), and I don't see why MUI should be better than GTK+ (MUI is of course commercial closed-source software, which makes for crawling slow development, especially on a niche platform like the AmigaOS).
Except that MUI's look could be easily configured through a GUI, but is not as configurable as GTK+ with themes.
It's WM Independent (Not really...)(yes, actually)
on
GNOME 1.0 Released
·
· Score: 1
That "some features" are mainly the Pager/Tasklist and probably a few more things. But nothing that is really required, it's just some nice improvements. You can really use it with any window manager.
PIDs are just sequential numbers, the number of *simultaneous* processes is another thing. This is actually limited by the process table size (which is adjustable at compile time in Linux).
To quote include/linux/tasks.h:
#define NR_TASKS 512/* On x86 Max 4092, or 4090 w/APM configured. */
Another thing: number of/. "users" != number of processes.
here's an idea for perl
on
Unix in Perl
·
· Score: 1
Perl 5.005 is supposed to have some backends to other languages and binary. However, I don't know how good that works.
"AFAIK Linux, while having much better SMP support than the crude approach it had before, still lacks many possible optimizations."
It's a lot better than NT, which will move threads to other processes no matter what (AFAIK) and will therefore suffer from L1 and L2 misses. The Linux scheduler tries to avoid that.
I dont't really know what that guy tried to say. The article is a collection of... whatever. He doesn't even have a point, only random fudding and very strange logic. It is just confused.
... is like stopping to develop cryptographic programs because criminals might use them.
Luckily emulators are not important software (in the sense of being usable for more than fun), but this sucks anyway. I'm not using any emulators myself, but it is still sad to see how those idiots can make people flee from their projects.
The slot protocol will be identical. Whether the CPU is 64 or 32 bit doesn't matter at all (as that's completely internal to the CPU). As for the data path... the protocol will be identical. So probably the K7 will also have 128bit data bus, or the EV7 protocol will make 128bit optional and work with 64bit data.
But you would have to change the BIOS for switching CPUs, I expect.
distributed.net gives you graphical stats for you on your personal stats page. Well, if you don't submit at regular intervals the stat has some spikes, but it's good enough.
If you're new to d.net: go to the main stats page for the current project (for RC5 this is http://rc5stats.distributed.net/) then enter enough of your email in the "individual search" text entry. Click on keyrate history there.
Slashdot Mirror
Comparing on Intel hardware? The other commercial Unixen in the article claim to have support for up to 128GB memory. Definitely not on Intel, I'd say.
Default x86 Linux has 960MB physical memory support and 3GB user address space. A patch exists to up the phys memory support to 2GB, but that reduces the user address space to 2GB.
The reason for this is that all physical memory is constantly mapped by the kernel and therefore can instantly be accessed without modifying the page table. Mapping it only on demand would allow more physical memory, but the consent on the linux-kernel mailing list was that this would suck performance-wise.
It may be possible in the future to use additional (unmapped) phys memory as a ram disk (which can be used as high priority swap).
All this is not an issue for 64-bit platforms as the virtual address space for these is really vast. Although at above 4GB the problem arises that PCI cards without 64-bit addressing won't be able to DMA into/from memory above 4G. The solution is to use memory from below 4G (just as with ISA DMA from below 16M), but there is no kernel support for that yet.
The Celerons are P2s in their core and have the same SMP support. Intel just did not provide the required control pins on the Celerons (and these can be used with the SMP adapters). Therefore, if I'm not wrong, Celerons also support only 2-way SMP just as a P2.
Probably, if the P2 would support more than 2-way in their chips you could probably connect more. But they can't electrically drive a SMP bus with more than 2 nodes, so operation would be either unreliable or unusable.
The APIC bus specs is one thing, what the CPU implements is another. The PIIs only support 2-way SMP. Electrically they can only drive 2-way buses, so even if they could support more in their APIC support, they don't. That's like the UW-SCSI chips which support 16-node setups but can only drive 8.
... or not actually correct, but to give some more data: first rumors of SAP R/3 for Linux were on the newsticker of Heise in october.
+ Linux (German text only)
See http://www.heise.de/newsticker/search.shtml?T=SAP
I heard of a Linux port of SAP R/3 quite some time ago (maybe 5 months), but it was an unofficial, unsupported port then (sort of like Quake1/2). It's just that recently SAP decided to make that an official port with company support (after lots of requests from people who want R/3 on Linux).
"My intent here is not to advocate fraudulent sales from remarking"
:-)
Don't worry, the real remarkers are doing batches of thousands and sell them through many nations to be untraceable. This is not about some home remarkers
That would be one of the simpler fakes. Real repackaging is also done, not only overwriting. These are so convincing that even official Intel distributors reportedly sold fakes without knowing.
So far Intel made a good deal by not marking their CPUs with their intended speed. With all the CPU faking going on, they probably managed to sell quite a few more chips - one middle speed CPU to the professional fakers and one high speed CPU to the end customers whose overclocked CPU didn't work properly.
Until now, if the chip did work most of the time (with all the people using Windows, a little instability goes unnoticed), there was no way of telling whether you really got what you paid for when you bought a P-II. Only details e.g. on the L2 cache implementation could be used to distinguish real from faked 300MHz CPUs.
Errm, really, shuttle tanks were chosen just because they would not have to be transported into space - because they are already there. The trick is to keep them there instead of dropping them back to earth.
Probably the tanks would have to be slightly redesigned, but the point is that they are the framework and are stuffed out with hotel stuff. My guess would be that there is not much to be done, as the tanks are just the foundation on (or better in) which the hotels will be built.
Current costs don't say much. First, current space travel is a government project. And those projects are not exactly known to be cost effective.
There are actually a few commercial companies trying to establish their own space transport (unmanned, though) and be real cheap compared to governmental space travel.
Not that you could even own bought proprietary software. They just grant you a license to use the current version in exchange for money.
Bah, just don't start any wm and start your apps full-screen. There you are :-)
"Also, a widget's code only ever loaded once - in the whole system. Now thats whay I call a shared library ..."
Actually that's just how shared libraries work under most modern Unixes including Linux. And that's how GTK/GNOME works therefore (all widgets in the libraries are only loaded once per system).
Additionally the parts of the library that are not used are not loaded, same with binaries. AmigaOS may be saving resources, but you can save much more with virtual memory.
Those are not comparable. You can compare GTK+ and MUI, however. They are both widget sets (GNOME is much more, it is just based on GTK+), and I don't see why MUI should be better than GTK+ (MUI is of course commercial closed-source software, which makes for crawling slow development, especially on a niche platform like the AmigaOS).
Except that MUI's look could be easily configured through a GUI, but is not as configurable as GTK+ with themes.
SASG homepage with link to MUI
That "some features" are mainly the Pager/Tasklist and probably a few more things. But nothing that is really required, it's just some nice improvements. You can really use it with any window manager.
To quote include/linux/tasks.h:
#define NR_TASKS 512 /* On x86 Max 4092, or 4090 w/APM configured. */
Another thing: number of /. "users" != number of processes.
Perl 5.005 is supposed to have some backends to other languages and binary. However, I don't know how good that works.
"AFAIK Linux, while having much better SMP support than the crude approach it had before, still lacks many possible optimizations."
It's a lot better than NT, which will move threads to other processes no matter what (AFAIK) and will therefore suffer from L1 and L2 misses. The Linux scheduler tries to avoid that.
I dont't really know what that guy tried to say. The article is a collection of ... whatever. He doesn't even have a point, only random fudding and very strange logic. It is just confused.
... is like stopping to develop cryptographic programs because criminals might use them.
Luckily emulators are not important software (in the sense of being usable for more than fun), but this sucks anyway. I'm not using any emulators myself, but it is still sad to see how those idiots can make people flee from their projects.
Open source is still the answer.
The slot protocol will be identical. Whether the CPU is 64 or 32 bit doesn't matter at all (as that's completely internal to the CPU). As for the data path... the protocol will be identical. So probably the K7 will also have 128bit data bus, or the EV7 protocol will make 128bit optional and work with 64bit data.
But you would have to change the BIOS for switching CPUs, I expect.
Thank you, that made me smile :-) Hurhurhur...
distributed.net gives you graphical stats for you on your personal stats page. Well, if you don't submit at regular intervals the stat has some spikes, but it's good enough.
If you're new to d.net: go to the main stats page for the current project (for RC5 this is http://rc5stats.distributed.net/) then enter enough of your email in the "individual search" text entry. Click on keyrate history there.