People often read newest first, thus, when they got to yours, they've seen so much belly acheing about Sun (who, by the way is not claiming that Solaris is Open Source(TM), but simply that they are opening the source) that they decide to take out their agression on you.
You do realize that these days, Linux + X + GNOME is only slightly less bloated than Win2K? It is certainly more bloated than NT4. That's best case. The nominal case is Linux + X + Mozilla + KDE + GNOME. Why? Well, first, Mozilla because the 33M line count in Win2K includes IE. Second, GNOME because I use the GIMP. Third, KDE because I need KDevelop. Both these apps are critical, and unfortuneately, I often have to run them at the same time. With these loaded, Linux easily clocks in at 35+ million lines, being MORE bloated than W2K.
Thanks also for pointing out the fact that Linux + Mozilla + X + GNOME + Apache (which is comparable to Windows 2000 which includes IE and IIS) is just as bloated as Windows 2000. Do the math Kernel - 3 Million lines Mozilla - 3.5 Million lines. XF86 -1 12! million lines GNOME (including ORB, window manager, etc.) ~10 million. Add all this together and you get ~ 28 million lines. Not that far away from Win2K and its 33 million lines. In comparison BeOS has 1.5 million lines. True, it doesn't compare at all to the above two OSs in terms of features, but still. Notice something else. Linux is really selvete if you don't add in X (bloated) and GNOME (bloated.) I think Linux running with a simple windowing system/window manager (maybe embedded KDE?) would clock in at a managable 10 million lines or so.
You know what I'd like to see from IRIX? The 3D pipe! Though DRI is as yet untested in major 3D applications, I'm pretty sure whatever SGI's got is 50X better. (Afterall, they've been working on it for a decade now.)
I don't think you are in the position to decree it "unacceptible" just because it doesn't meet your ideals. Sun has already said that Solaris is not "Open Source." They are simply opening the source. In better days, this would be considered open source, but in these days of fanatical OSS people, saying something is Open Source essentially means it is usable in other people's projects. They are not opening it for YOUR benifet. They are opening it for the benifet of Solaris users who can now work on making it better. This justifys them not opening it all at once because, A) They have legal problems which prevent them from opening the whole thing, B) They don't need to. They release the parts that they own and the ones that need working on. They are not opening this for the benifit of the OSS community, and they never made a claim they did. They are simply opening pieces to allow people who want to see the code (not steal it!) easier access to it.
Has anybody used Solaris x86 was a workstation machine? I was thinking about getting the Free Binary License, but was put of by the reports of Solaris 7 on intel being slow. However, I hear Solaris 8 is much faster on Intel, so would like to know how it performs. I'm not doing any server work, just playing around with it on the workstation.
As much as I like AMD, I have to saw that this processor is utterly useless for a desktop at this time. The reason is, that it serves no purpose to the desktop user. The only forseeable advantage is the increased memory address space, but at the current rate, 4GB will be enough for another 10 years or so (assuming memory usage doubles every 2 years and right now is 128 meg.) The general notion is that 64 bit processors are faster. This is entirely untrue. 64 bit processors are no faster than 32 bit ones for 32 bit operations. And desktop software is still essentially a 32bit regime. Anything using the integer units rarely deal with speed critical code that need 64 bits, and the vast majority of FPU (video, 3D, etc) intensive apps still use single precision (32bit) floating point, even though Pentium has an 80 bit FPU. Thus, I really don't see much of a benifet. What is a much cooler technology, in my opinion, is the double-pumping that Intel is doing. I can guarantee you that a 32 bit 1.5 GHz proc that is running its ALUs at 3GHz will beat the hell out of a 64 bit CPU.
No, a 3D game is just about the most stressing thing you can do to the computer. A) A GeForce2 GTS can render a hell of a lot more triangles than the proc (even a 1GHz) can feed it. Sure the geometry acceleration helps out a bit, but most games don't use it yet. Thus this racing game (no racing games that I know of use the geomtery engine in D3D or OpenGL) is definately a good indicator of the performance. B) The kernel compile is a crappy benchmark. Given the fact that the source tree is some 75 megs, and the fact that it does nothing with the FPU, and the fact that it is much more dependant on bus bandwidth due to the nature of the operation, it doesn't make for a very good benchmark. But in the end, all that matters in a benchmark is how well it does what YOU'RE doing. If you want to test raw proc speed, you'll use a synthetic benchmark that just does math ops. If you compile all day, then the kernel compile is a perfectly valid benchmark. If you run 3D games, then the 3D game is a great benchmark.
Wow. Switch the mode to threaded highest score first. That top guy most hold some kind of record for most responses to a single comment. Wonderfully, all 478 comments on this page seem to be about naming. As for the processesor itself, it is the biggest leap since the Pentium Pro. The Pentium 4 is an entierly new architecture (dumb as hell naming scheme. If a PII with extra cache deserves the Xeon moniker, this should atleast beo Pentium Rangers in Space! But I digress.) The PIV uses a new technique that Intel calls "double pumping." It is essentially the same technology used in AGP and DDR-SDRAM to achive high clockspeeds, the data units work on both the rising and falling edges of the clock. Thus, the bus is quad pumped (I think 100MHz clock transferrng 4X per clock) and the ALU's are double pumped, so a 1.5GHz PIV will have math units crunching at 3GHz! Also, there are a bevy of other changes such as deeper pipelines and better caching. What's certain is that Athlon is not going to hold AMD on top anymore. Sure, clock for clock the Athlon might be more efficient, but nothing is argueing with an effective 3GHz clockspeed. This is especially important for stuff like 3D graphics since the geometry doesn't use up that much bus bandwidth, so the processor can crunch at the full 3GHz without having to wait for the bus.
Opps. Disregard my previous comment. I was listening to the topic instead of reading the article. You're right about everything. I'm sorry. Forgive me.;)
It's not just the new drivers from nVidia. What nVidia does is DXTC (DirectX texture compression) which is a form of S3TC (S3 texture compression.) 3DFx is doing this to with FXT1 (I think that's right)
This really has nothing to do with disk caching, it compresses memory, not disk space. And it WILL increase latency because a section of memory must be decompressed before it can be sent. Even with dedicated hardware it will still take a few clocks.
The problem is, they could care less if non-windows users can access it or not. The exe is the most convenient format to send it in, and has no drawbacks as far as they are concerned. Also, they've officially abandoned NT on Alpha, so I'm not surprised that they've done this. Marketing also plays a part in this. They ARE Microsoft, and even little plugs like this are not below them.
The exe wrapped doc file was a self extracting.zip. Since there are more people without winzip than there are Linux users, and the fact that (statistically) everyone is running Windows, they chose to save it as a self extracting zip file.
BSD doesn't smoke Linux in all areas. (Hey, I use BeOS mainly, so I have no preference for either.) In terms of usage, I'd give the upper hand to BSD because it is a much more coherent system, and the ports system absolutely rocks. As for performance, it all depends on what you're gauging. Under low load single proc systems doing network stuff, Linux has a slight edge. However, BSD handles high load MUCH better than Linux does. Also, the MM in BSD is better, but the multimedia subsystems (sound, graphics, etc) are better under Linux. As for NT, NT smokes both Linux and BSD when it comes to certain gauges of performance. It wins for raw throughput through the network, for raw disk I/O speed, an has insanely better multimedia capabilities. (Courtesy DirectX and a very mature OpenGL.) However, you have to look at its performance in real world terms. NT makes a lot of sacrifices to achieve these raw benchmarks. First, it has small in kernel bufers for I/O and stuff. That makes it faster, but mucks up the system and increases non-pagable memory use. Then there is graphics. The Win2K HAL integrates DirectX calls, again messing with the cleanliness of the system, increasing the code size of a very low level layer, and introducing a major source of bugs into the HAL. Also, all system servers run in kernel mode, so they do not enjoy the protectedness inherent in micokernel designs. By running stuff like graphics in the kernel and running the server in kernel mode, it becomes a lot faster, but at the cost of stability, memory use etc. Also, NT has problems under heavy load, so when comparing a FreeBSD and an NT machine, the FreeBSD machine will wipe the floor with NT, even though NT has the raw throughput advantage.
Hey, there's FreeBSD! IMO, if FreeBSD would run the Linux kernel, it would be the very best distribution available. It's port collection is unmatched. Simple total system upgrades by typing a few words.
>>>> Are you serious? If FreeBSD ran the Linux kernel, it would not be a BSD anymore now would it? Also, I hope you understand that FreeBSD is not a "distro." What would be nifty, however, is to bring the ports system to Linux.
Actually, Mach is a microkernel so it doesn't actually expose the system interface. The MacOS X system is kind of like NeXT. It has a Mach microkernel, on top of which is a modified FreeBSD 3.2 system server. There is a great deal more BSD in there then just "bits and pieces."
It's kind of like Linux durning the early 2.2 releases. 2.3 was considered development (5.0-current) 2.2 was considered stable, but still experimiental (4.0) and 2.0.x was considered the one to use if you absolutely needed a well tested stable version (3.x-stable)
The problem with doing that for the RPM database is two fold. 1) RPM is complex enough already. Adding the extra overhead of having to write to a text database makes it more complex than I'm willing to put up with. (More complexity==more bugs) 2) The RPM database doesn't need to be user editable. Anything that you can do with a text file, you can do through RPM. Additionally, if the database gets corrupted, the average RPM user will not know how to fix it anyway. The problem is that RPM was aimed at you. While it is a decent package format, it wasn't meant for the advanced user when it was designed.
Maybe because binary works better for some things? Maybe because a binary file is easier to edit from a program than a text file? Just because it is the way windows does it, doesn't mean its not the best way.
Slashdot Mirror
People often read newest first, thus, when they got to yours, they've seen so much belly acheing about Sun (who, by the way is not claiming that Solaris is Open Source(TM), but simply that they are opening the source) that they decide to take out their agression on you.
You do realize that these days, Linux + X + GNOME is only slightly less bloated than Win2K? It is certainly more bloated than NT4. That's best case. The nominal case is Linux + X + Mozilla + KDE + GNOME. Why? Well, first, Mozilla because the 33M line count in Win2K includes IE. Second, GNOME because I use the GIMP. Third, KDE because I need KDevelop. Both these apps are critical, and unfortuneately, I often have to run them at the same time. With these loaded, Linux easily clocks in at 35+ million lines, being MORE bloated than W2K.
Thanks also for pointing out the fact that Linux + Mozilla + X + GNOME + Apache (which is comparable to Windows 2000 which includes IE and IIS) is just as bloated as Windows 2000. Do the math
Kernel - 3 Million lines
Mozilla - 3.5 Million lines.
XF86 -1 12! million lines
GNOME (including ORB, window manager, etc.) ~10 million.
Add all this together and you get ~ 28 million lines. Not that far away from Win2K and its 33 million lines.
In comparison BeOS has 1.5 million lines. True, it doesn't compare at all to the above two OSs in terms of features, but still. Notice something else. Linux is really selvete if you don't add in X (bloated) and GNOME (bloated.) I think Linux running with a simple windowing system/window manager (maybe embedded KDE?) would clock in at a managable 10 million lines or so.
You know what I'd like to see from IRIX? The 3D pipe! Though DRI is as yet untested in major 3D applications, I'm pretty sure whatever SGI's got is 50X better. (Afterall, they've been working on it for a decade now.)
I don't think you are in the position to decree it "unacceptible" just because it doesn't meet your ideals. Sun has already said that Solaris is not "Open Source." They are simply opening the source. In better days, this would be considered open source, but in these days of fanatical OSS people, saying something is Open Source essentially means it is usable in other people's projects. They are not opening it for YOUR benifet. They are opening it for the benifet of Solaris users who can now work on making it better. This justifys them not opening it all at once because,
A) They have legal problems which prevent them from opening the whole thing,
B) They don't need to. They release the parts that they own and the ones that need working on.
They are not opening this for the benifit of the OSS community, and they never made a claim they did. They are simply opening pieces to allow people who want to see the code (not steal it!) easier access to it.
Neither FreeBSD nor Linux are good SMP OSs. For that try Solaris x86, BeOS (obligatory plug :), or (gasp!) WinNT.
Has anybody used Solaris x86 was a workstation machine? I was thinking about getting the Free Binary License, but was put of by the reports of Solaris 7 on intel being slow. However, I hear Solaris 8 is much faster on Intel, so would like to know how it performs. I'm not doing any server work, just playing around with it on the workstation.
As much as I like AMD, I have to saw that this processor is utterly useless for a desktop at this time. The reason is, that it serves no purpose to the desktop user. The only forseeable advantage is the increased memory address space, but at the current rate, 4GB will be enough for another 10 years or so (assuming memory usage doubles every 2 years and right now is 128 meg.) The general notion is that 64 bit processors are faster. This is entirely untrue. 64 bit processors are no faster than 32 bit ones for 32 bit operations. And desktop software is still essentially a 32bit regime. Anything using the integer units rarely deal with speed critical code that need 64 bits, and the vast majority of FPU (video, 3D, etc) intensive apps still use single precision (32bit) floating point, even though Pentium has an 80 bit FPU. Thus, I really don't see much of a benifet. What is a much cooler technology, in my opinion, is the double-pumping that Intel is doing. I can guarantee you that a 32 bit 1.5 GHz proc that is running its ALUs at 3GHz will beat the hell out of a 64 bit CPU.
No, a 3D game is just about the most stressing thing you can do to the computer.
A) A GeForce2 GTS can render a hell of a lot more triangles than the proc (even a 1GHz) can feed it. Sure the geometry acceleration helps out a bit, but most games don't use it yet. Thus this racing game (no racing games that I know of use the geomtery engine in D3D or OpenGL) is definately a good indicator of the performance.
B) The kernel compile is a crappy benchmark. Given the fact that the source tree is some 75 megs, and the fact that it does nothing with the FPU, and the fact that it is much more dependant on bus bandwidth due to the nature of the operation, it doesn't make for a very good benchmark.
But in the end, all that matters in a benchmark is how well it does what YOU'RE doing. If you want to test raw proc speed, you'll use a synthetic benchmark that just does math ops. If you compile all day, then the kernel compile is a perfectly valid benchmark. If you run 3D games, then the 3D game is a great benchmark.
Not only that, but the POWER chips are WAY WAY faster than the latest MIPS.
It's really not that hard to upgrade these suckers. Intel has already upgraded the Intel/Sandia machine to use PIII Xeons.
With these computers, you can test nukes without having to actually blow them up.
Wow. Switch the mode to threaded highest score first. That top guy most hold some kind of record for most responses to a single comment. Wonderfully, all 478 comments on this page seem to be about naming. As for the processesor itself, it is the biggest leap since the Pentium Pro. The Pentium 4 is an entierly new architecture (dumb as hell naming scheme. If a PII with extra cache deserves the Xeon moniker, this should atleast beo Pentium Rangers in Space! But I digress.) The PIV uses a new technique that Intel calls "double pumping." It is essentially the same technology used in AGP and DDR-SDRAM to achive high clockspeeds, the data units work on both the rising and falling edges of the clock. Thus, the bus is quad pumped (I think 100MHz clock transferrng 4X per clock) and the ALU's are double pumped, so a 1.5GHz PIV will have math units crunching at 3GHz! Also, there are a bevy of other changes such as deeper pipelines and better caching. What's certain is that Athlon is not going to hold AMD on top anymore. Sure, clock for clock the Athlon might be more efficient, but nothing is argueing with an effective 3GHz clockspeed. This is especially important for stuff like 3D graphics since the geometry doesn't use up that much bus bandwidth, so the processor can crunch at the full 3GHz without having to wait for the bus.
Opps. Disregard my previous comment. I was listening to the topic instead of reading the article. You're right about everything. I'm sorry. Forgive me. ;)
It's not just the new drivers from nVidia. What nVidia does is DXTC (DirectX texture compression) which is a form of S3TC (S3 texture compression.) 3DFx is doing this to with FXT1 (I think that's right)
This really has nothing to do with disk caching, it compresses memory, not disk space. And it WILL increase latency because a section of memory must be decompressed before it can be sent. Even with dedicated hardware it will still take a few clocks.
The problem is, they could care less if non-windows
users can access it or not. The exe is the most
convenient format to send it in, and has no
drawbacks as far as they are concerned. Also,
they've officially abandoned NT on Alpha, so I'm
not surprised that they've done this. Marketing
also plays a part in this. They ARE Microsoft, and
even little plugs like this are not below them.
The exe wrapped doc file was a self extracting .zip. Since there are more people without winzip than there are Linux users, and the fact that (statistically) everyone is running Windows, they chose to save it as a self extracting zip file.
BSD doesn't smoke Linux in all areas. (Hey, I use BeOS mainly, so I have no preference for either.) In terms of usage, I'd give the upper hand to BSD because it is a much more coherent system, and the ports system absolutely rocks. As for performance, it all depends on what you're gauging. Under low load single proc systems doing network stuff, Linux has a slight edge. However, BSD handles high load MUCH better than Linux does. Also, the MM in BSD is better, but the multimedia subsystems (sound, graphics, etc) are better under Linux. As for NT, NT smokes both Linux and BSD when it comes to certain gauges of performance. It wins for raw throughput through the network, for raw disk I/O speed, an has insanely better multimedia capabilities. (Courtesy DirectX and a very mature OpenGL.) However, you have to look at its performance in real world terms. NT makes a lot of sacrifices to achieve these raw benchmarks. First, it has small in kernel bufers for I/O and stuff. That makes it faster, but mucks up the system and increases non-pagable memory use. Then there is graphics. The Win2K HAL integrates DirectX calls, again messing with the cleanliness of the system, increasing the code size of a very low level layer, and introducing a major source of bugs into the HAL. Also, all system servers run in kernel mode, so they do not enjoy the protectedness inherent in micokernel designs. By running stuff like graphics in the kernel and running the server in kernel mode, it becomes a lot faster, but at the cost of stability, memory use etc. Also, NT has problems under heavy load, so when comparing a FreeBSD and an NT machine, the FreeBSD machine will wipe the floor with NT, even though NT has the raw throughput advantage.
FreeBSD does have SMP support, but it sucks. No fear, though, SMP is being rewritten for the 5.0 release (I think.)
Hey, there's FreeBSD! IMO, if FreeBSD would run the Linux kernel, it would be the very best distribution available. It's port collection is unmatched. Simple total system upgrades by typing a few words.
>>>>
Are you serious? If FreeBSD ran the Linux kernel, it would not be a BSD anymore now would it? Also, I hope you understand that FreeBSD is not a "distro." What would be nifty, however, is to bring the ports system to Linux.
Actually, Mach is a microkernel so it doesn't actually expose the system interface. The MacOS X system is kind of like NeXT. It has a Mach microkernel, on top of which is a modified FreeBSD 3.2 system server. There is a great deal more BSD in there then just "bits and pieces."
It's kind of like Linux durning the early 2.2 releases. 2.3 was considered development (5.0-current) 2.2 was considered stable, but still experimiental (4.0) and 2.0.x was considered the one to use if you absolutely needed a well tested stable version (3.x-stable)
The problem with doing that for the RPM database is two fold.
1) RPM is complex enough already. Adding the extra overhead of having to write to a text database makes it more complex than I'm willing to put up with. (More complexity==more bugs)
2) The RPM database doesn't need to be user editable. Anything that you can do with a text file, you can do through RPM. Additionally, if the database gets corrupted, the average RPM user will not know how to fix it anyway. The problem is that RPM was aimed at you. While it is a decent package format, it wasn't meant for the advanced user when it was designed.
Maybe because binary works better for some things? Maybe because a binary file is easier to edit from a program than a text file? Just because it is the way windows does it, doesn't mean its not the best way.