Net/OpenBSD have a much better MM infrastructure than Linux. Linux MM is still very much tied to a page table based architecture. Anything else must emulate the page table structure.
The old 4d(c?) machines, like the IPX etc don't use a page table based MMU, instead using a TLB based system (I think) which doesn't fit well with the Linux MM scheme.
BSD has a much cleaner seperation of virtual memory management (segment mapping etc) and address translation mechanisms (page tables, TLB, inverted page tables etc.) This seperation allows the MM in BSD (and SVR4) to be more portable.
Linux MM is a hack and needs sorting out.
I really don't buy this 'lower than cost' hardware thing.
At the volume they're made in, using 1995 technology (small dies, cheap chips,) these things can't be that expensive to make.
My guess is that this is marketing spin to make the deal sound more inviting. If someone would like to produce some figures to prove me wrong, I'd be happy to see them.
Wouldn't this be great in solar cell technology? One of the problems of silicon based panels is that the silicon is not transparent, therefore the light penetration to the active cells is limited.
This transparent semiconductor would allow the light to penetrate deeper, allowing potentially several layers of active cells, increasing the efficency of the panels.
Or do I just not know what I'm talking about (I suspect not:) But the prospect of transparent solar panels on my windows powering my house sounds very attractive.
but let's face it: if it weren't for Windows 95 with its built-in Dial-Up Networking feature that included TCP/IP support a LOT less people would be on the Internet right now.
Should read:
but let's face it: if it weren't for UNIX/MacOS/Whatever with its built-in Dial-Up Networking feature that included TCP/IP support a LOT less people would be on the Internet right now. They'd all be using Microsoft's proprietry MSN. No hope of open standards...
Use your brain before posting rot like this. The internet succeeded DESPITE MSs efforts, not because of them.
PS. What ties UNIX to "one of the most user-unfriendly command line interfaces around?" I actually think {ba}sh is very good once you LEARN it. I find it very user friendly. Ever used an Irix machine, BTW?
Are you american? Do you believe in protecting peoples right?
In europe, you can't sign away statutory rights. I would hope that it is the same in america. Not that I know whether you have a statutory right to refuse to work on a project etc. on ethical grounds.
Last I checked, it wasn't a problem linking bash against the non-GPL libc on my solaris box. Nowhere in the bash source or GPL can I see any express permission for bash to be linked against the proprietry libc.
Considering how the Indigo2 was released around 93-94, it's not doing TOO bad. Does your friend Indigo have 1 Meg or 4 Meg of texture RAM? 1 Meg will hurt on anything that overflows the texture RAM.
Plus, the old R4k based machines just can't cut against more up to date x86 processors. I mean, come on, an R4000 (circa 1992?) against even a K6-2 (circa 1998?)
Whether it's written by professionals or not, sometimes other companies do things so badly that you have to comment exactly WHY you are doing something the way you are.
Our code is littered with comments like 'XXX product spec says it does blah, but is in fact full of crap. It appears to do foo, so we have to work around it like this'.
Mentioning names and referenceing documents, often in a less than flattering way, is necassary to highlight where an impementation differs to the specification because the spec is wrong.
I say, name and shame those companies that release useless spec.
So it was nothing to do with the fact that NT was: 1. Slow. That 'modified microkernel' architecture was a dog on slow (fast at the time!) machines. 2. Expensive. Still is now. 3. Bloated. Needed 16 Meg from the outset. A lot for the desktop in '93. 4. Had no native applications. Not even MS could be arsed to port Office to it until Windows95 was released.
I beleive NT was for future investment, waiting for the desktop hardware to catch up. Releasing it in 93 was probably just a token effort to get some mindshare early.
hey were the first to have a machine with the innovative 'data key' method (bent paper clip) for extracting floppy diskettes.
SUNs cheapo Ultra10 (and 5s probably) are the first SUN machines I know of that removed this capability.
Software eject floppies are a brilliant idea, as it allows you to work from a floppy with good save speeds, as the data is cached, and the floppy can't be prematurely ejected, potentially destroying data.
Mechanical eject is a throw back to the dark ages, and unfortunately, PCs continue to show their dark ages roots in still using them.
The problem is, when they do wrong, it's often apthetic incompetance that caused the problem.
How did the mirror on Hubble be designed to be the wrong shape! Incompetence. It was a simple, fundamental error. And while the mission as a whole has redeemed itself in the main, it would still be able to see more clearly if the mirror was the correct shape in the first place.
And mixing up units? I could not believe that NASA would use anything but meters in ANY calculations.
> "UltraSparcs have had integrated caches for quite a while, as far back as SuperSparc I."
Ha? Supersparcs had integrated L1 cache. So did the 486. And remember the old CISC vs RISC debate. Hint: CISC programs tend to be smaller than equivalent RISC programs. Also, 64b pointers tend to take more space than 32b pointers. Bottom line: you don't need as much cache.
A few points: 1. Due to processors like the SPARC having more registers, memory isn't hit as badly as on Intel's woefully inadequate architecture. This may improve cache performance, and certainly helps keep memory bandwidth available. 2. Because RISC processors spend less time juggling variables about between registers and memory, more work can be done in the same number of instructions. And the fixed instruction length improves performance elsewhere in the processor, negating the performance impact of slightly larger avarage instruction length. 3. Code for the UltraSPARC does not HAVE to work with 64b data. Until Solaris 7 came out, Solaris was strictly 32b on any SPARC. And instructions are always still 32b long. 4. If you DO have to work with 64b values, the x86 will have to improvise to handle the data, resulting in more instructions == bigger hit on the cache. With BIG databases, native 64b data handling must surely be a big win when working with large databases.
Besides, when we're talking about the sort of hardware you referenced, we are not talking PC price advantage anymore. The only real benefit of Initel hardware is the low price as a result of huge volume. These machines are definately NOT large volume.
Microsoft could release the fix as a ILOVEYOU like worm, that hunts down and fixes rogue Outlook users. The payload would download the patch (with permission, expaining what it could have done,) then contact everyone in the users address book.
(YOU CAN'T TELL ME THAT SUN DOESN'T PRICE GOUGE ON ITS HARDWARE/SOFTWARE/SUPPORT SOLUTIONS.) You can't tell me that a computer Sparc 5 should retail for 2900.00 while a pc with similar specs and tons more software and features runs for a 3'rd that price.
Economy of scale? Sun machines are not proprietry. There are clones available. It's just the economies of scale for PC components means that SPARCStations just can't compete in price.
But look at build quality, longevity and support, and you'll see why companies choose Sun machines, where the initial purchase cost is small compared to the support/management costs.
All but the newer, cheaper Sun machines are built like rocks. My IPX weighs a ton! My old university until a couple of years ago had a whole lab of Sun 3/50s from ~1986! They were only taken out of commision to make way for new SGI machines (even then, they were snapped up pretty quick.)
A PC from the 80's would not be useable. Not so for Sun machines.
I find it amazing that people continue to give SUN grief, especially over Java.
Java is platform independant. The standard does not contain what you want? Write it yourself! It should work on other Java platforms.
Examples of what Sun has done in the past: 1. Significantly improved UNIX, feeding the improvements back into SVR4. 2. Developed RPC and NFS, then gave them away as open standards. 3. Developed the SPARC processor, then openly licensed the architecture. SPARC is now independant of Sun. 4. Drove the workstation market closer and closer to PCs in terms of price. Still not there yet, due to the sheer volume of the PC market (economies of scale, and all that.) 5. OpenFirmware. Plug in that card. No drivers yet for the OS? No problem, just use the built in openfirmware drivers. No processor dependancies. Cool.
Now, let's look at what microsoft have contributed to the computer industry: 1. Erm, EMS, to allow DOS users to use more than 640k RAM! Wow, fancy that on a 1Meg+ machine. 2. Microsoft mouse protocol, which, erm, allows for only two button mice. 3. Microsoft Office, with it's open, documented file formats. No wait... 4. (Scratch head,) Yeah, the internet. Didn't Win95 bring this previously out of reach inter-network of computers within reach of the common user? 5. Windows Terminal Server. Now several users can use a single machine at once. Fancy that.
???? I thought the T&L engine in GeForce is what SGI terms a geometry engine ie. a matrix cruncher to take the load away from the main CPU. What extensions does this put into OpenGL?
The real-time virtual reality visualisation, of the type used for simulation etc, is much different to games in what sense?
Both try to convey a air of realism to the user.
The only way that OpenGL standards in any way might not make them suitable for games is that an OpenGL compliant driver must produce a minimum level of quality ie. some speed hacks are not allowed if they impair the visual quality.
The many demo games that ship as part of Irix should show that SGI for one have always used OpenGL for games.
So, how is OpenGL falling behind the times? What does D3D provide which OpenGL doesn't.
Slashdot Mirror
Net/OpenBSD have a much better MM infrastructure than Linux. Linux MM is still very much tied to a page table based architecture. Anything else must emulate the page table structure. The old 4d(c?) machines, like the IPX etc don't use a page table based MMU, instead using a TLB based system (I think) which doesn't fit well with the Linux MM scheme. BSD has a much cleaner seperation of virtual memory management (segment mapping etc) and address translation mechanisms (page tables, TLB, inverted page tables etc.) This seperation allows the MM in BSD (and SVR4) to be more portable. Linux MM is a hack and needs sorting out.
I really don't buy this 'lower than cost' hardware thing.
At the volume they're made in, using 1995 technology (small dies, cheap chips,) these things can't be that expensive to make.
My guess is that this is marketing spin to make the deal sound more inviting. If someone would like to produce some figures to prove me wrong, I'd be happy to see them.
Wouldn't this be great in solar cell technology? One of the problems of silicon based panels is that the silicon is not transparent, therefore the light penetration to the active cells is limited.
This transparent semiconductor would allow the light to penetrate deeper, allowing potentially several layers of active cells, increasing the efficency of the panels.
Or do I just not know what I'm talking about (I suspect not:) But the prospect of transparent solar panels on my windows powering my house sounds very attractive.
I believe the clock was actually an RC clock, hence the unstability that others have noted when temperature fluctuated.
Should read:
Use your brain before posting rot like this. The internet succeeded DESPITE MSs efforts, not because of them.
PS. What ties UNIX to "one of the most user-unfriendly command line interfaces around?" I actually think {ba}sh is very good once you LEARN it. I find it very user friendly. Ever used an Irix machine, BTW?
Are you american? Do you believe in protecting peoples right?
In europe, you can't sign away statutory rights. I would hope that it is the same in america. Not that I know whether you have a statutory right to refuse to work on a project etc. on ethical grounds.
This to me only appears to be about source distribution, not about linkage.
It could be argued that libqt is a system library, and therefore part of the OS distribution, just like libc.
... do stuff you're ethically against. For example, if you're a pacifist, I don't believe you could be forced to work on an arms project, for example.
Check your contract and local statutory law about ethical issues.
Certainly in the UK (EU?) you can't be forced to do this sort of thing.
Last I checked, it wasn't a problem linking bash against the non-GPL libc on my solaris box. Nowhere in the bash source or GPL can I see any express permission for bash to be linked against the proprietry libc.
How is libqt any different?
Considering how the Indigo2 was released around 93-94, it's not doing TOO bad. Does your friend Indigo have 1 Meg or 4 Meg of texture RAM? 1 Meg will hurt on anything that overflows the texture RAM.
Plus, the old R4k based machines just can't cut against more up to date x86 processors. I mean, come on, an R4000 (circa 1992?) against even a K6-2 (circa 1998?)
Whether it's written by professionals or not, sometimes other companies do things so badly that you have to comment exactly WHY you are doing something the way you are.
Our code is littered with comments like 'XXX product spec says it does blah, but is in fact full of crap. It appears to do foo, so we have to work around it like this'.
Mentioning names and referenceing documents, often in a less than flattering way, is necassary to highlight where an impementation differs to the specification because the spec is wrong.
I say, name and shame those companies that release useless spec.
So it was nothing to do with the fact that NT was:
1. Slow. That 'modified microkernel' architecture was a dog on slow (fast at the time!) machines.
2. Expensive. Still is now.
3. Bloated. Needed 16 Meg from the outset. A lot for the desktop in '93.
4. Had no native applications. Not even MS could be arsed to port Office to it until Windows95 was released.
I beleive NT was for future investment, waiting for the desktop hardware to catch up. Releasing it in 93 was probably just a token effort to get some mindshare early.
This is Netscape in RH6.2 for sparc.
bash$ uname -a
Linux slapper 2.2.14-5.0 #1 Tue Mar 7 21:50:41 EST 2000 sparc64 unknown
Very easy to take the piss about the war, but the US were on the OTHER side of the atlantic at the time.
The US has never had to go through a modern war on it's own territory.
Think Perl Harbour, with bigger, heavier bombers (thus heavier payload) EVERY night raining bombs down on UK cities.
No precision bombs then. It was indescriminate bombing. Civilian targets etc.
It's understandable that we needed outside help for supplies, afterall, we are an isolated island without the massive natural resourses of the US.
That's a good point.
After all, it was Americans that captured the enigma machine, wasn't it, saving our bacon...
Off course, Africa is still full of, and ruled by, indigenous people. Not the same in america, is it?
Plus, we are under no impression that this was anything but opressive colonialism.
Americans, OTOH, seem to think that 'democracy' and 'freedom' was born in the US, long before you'd finished rounding up native people.
When was the (mainly african) slave trade banned in the US?
hey were the first to have a machine with the innovative 'data key' method (bent paper clip) for extracting floppy diskettes.
SUNs cheapo Ultra10 (and 5s probably) are the first SUN machines I know of that removed this capability.
Software eject floppies are a brilliant idea, as it allows you to work from a floppy with good save speeds, as the data is cached, and the floppy can't be prematurely ejected, potentially destroying data.
Mechanical eject is a throw back to the dark ages, and unfortunately, PCs continue to show their dark ages roots in still using them.
The problem is, when they do wrong, it's often apthetic incompetance that caused the problem.
How did the mirror on Hubble be designed to be the wrong shape! Incompetence. It was a simple, fundamental error. And while the mission as a whole has redeemed itself in the main, it would still be able to see more clearly if the mirror was the correct shape in the first place.
And mixing up units? I could not believe that NASA would use anything but meters in ANY calculations.
> "UltraSparcs have had integrated caches for quite a while, as far back as SuperSparc I."
Ha? Supersparcs had integrated L1 cache. So did the 486. And remember the old CISC vs RISC debate. Hint: CISC programs tend to be smaller than equivalent RISC programs. Also, 64b pointers tend to take more space than 32b pointers. Bottom line:
you don't need as much cache.
A few points:
1. Due to processors like the SPARC having more registers, memory isn't hit as badly as on Intel's woefully inadequate architecture. This may improve cache performance, and certainly helps keep memory bandwidth available.
2. Because RISC processors spend less time juggling variables about between registers and memory, more work can be done in the same number of instructions. And the fixed instruction length improves performance elsewhere in the processor, negating the performance impact of slightly larger avarage instruction length.
3. Code for the UltraSPARC does not HAVE to work with 64b data. Until Solaris 7 came out, Solaris was strictly 32b on any SPARC. And instructions are always still 32b long.
4. If you DO have to work with 64b values, the x86 will have to improvise to handle the data, resulting in more instructions == bigger hit on the cache. With BIG databases, native 64b data handling must surely be a big win when working with large databases.
Besides, when we're talking about the sort of hardware you referenced, we are not talking PC price advantage anymore. The only real benefit of Initel hardware is the low price as a result of huge volume. These machines are definately NOT large volume.
[csmith@erol csmith]$ su - nobody
Password:
su: incorrect password
[csmith@erol csmith]$
Only root can su to nobody, as only root can change their user id.
You also need to be root to use chroot, so a proper sandbox is out as well.
Oh well
Microsoft could release the fix as a ILOVEYOU like worm, that hunts down and fixes rogue Outlook users. The payload would download the patch (with permission, expaining what it could have done,) then contact everyone in the users address book.
Now that's what I call ZAW:)
(YOU CAN'T TELL ME THAT SUN DOESN'T PRICE GOUGE ON ITS HARDWARE/SOFTWARE/SUPPORT SOLUTIONS.) You can't tell me that a computer Sparc 5 should retail for 2900.00 while a pc with similar specs and tons more software and features runs for a 3'rd that price.
Economy of scale? Sun machines are not proprietry. There are clones available. It's just the economies of scale for PC components means that SPARCStations just can't compete in price.
But look at build quality, longevity and support, and you'll see why companies choose Sun machines, where the initial purchase cost is small compared to the support/management costs.
All but the newer, cheaper Sun machines are built like rocks. My IPX weighs a ton! My old university until a couple of years ago had a whole lab of Sun 3/50s from ~1986! They were only taken out of commision to make way for new SGI machines (even then, they were snapped up pretty quick.)
A PC from the 80's would not be useable. Not so for Sun machines.
I find it amazing that people continue to give SUN grief, especially over Java.
...
Java is platform independant. The standard does not contain what you want? Write it yourself! It should work on other Java platforms.
Examples of what Sun has done in the past:
1. Significantly improved UNIX, feeding the improvements back into SVR4.
2. Developed RPC and NFS, then gave them away as open standards.
3. Developed the SPARC processor, then openly licensed the architecture. SPARC is now independant of Sun.
4. Drove the workstation market closer and closer to PCs in terms of price. Still not there yet, due to the sheer volume of the PC market (economies of scale, and all that.)
5. OpenFirmware. Plug in that card. No drivers yet for the OS? No problem, just use the built in openfirmware drivers. No processor dependancies. Cool.
Now, let's look at what microsoft have contributed to the computer industry:
1. Erm, EMS, to allow DOS users to use more than 640k RAM! Wow, fancy that on a 1Meg+ machine.
2. Microsoft mouse protocol, which, erm, allows for only two button mice.
3. Microsoft Office, with it's open, documented file formats. No wait
4. (Scratch head,) Yeah, the internet. Didn't Win95 bring this previously out of reach inter-network of computers within reach of the common user?
5. Windows Terminal Server. Now several users can use a single machine at once. Fancy that.
????
I thought the T&L engine in GeForce is what SGI terms a geometry engine ie. a matrix cruncher to take the load away from the main CPU. What extensions does this put into OpenGL?
The real-time virtual reality visualisation, of the type used for simulation etc, is much different to games in what sense?
Both try to convey a air of realism to the user.
The only way that OpenGL standards in any way might not make them suitable for games is that an OpenGL compliant driver must produce a minimum level of quality ie. some speed hacks are not allowed if they impair the visual quality.
The many demo games that ship as part of Irix should show that SGI for one have always used OpenGL for games.
So, how is OpenGL falling behind the times? What does D3D provide which OpenGL doesn't.