What severe problems? If your talking about the P4 being slower than a similarly clocked P3, remember that the P2 was slower than a similarly clocked P2. Or that a Pentium was slower than a 486 for most code out at the time. If your talking about heat, remember that the.25 micron Athlons were massive heat-machines, and the even the old P2 300MHz chewed up nearly 40 watts. If your talking about manufacturing, remember that AMD at several points wasn't even able to meet the demand for 2-something million chips. If you can tell me what's so bad about Intel chips, aside from manufacturing glitches common to all companies, then you have a point.
MMX wasn't just marketing. It genuinely sped up 3D. However, Intel didn't count on 3D accelerators coming on. MMX was designed in the days of the ViRGE and fixed-point 3D engines. How would have thought that some day 3D accelerators would have fill-rates in excess of 1.6 gigatexels? Intel certainly didn't, and appropriatly, they designed MMX to speed up integer calculations. However, the design wouldn't allow you to concurrently run floating point, and thus, developers started to use fp/3d acceleration instead of fixed-point/MMX. However. MMX is SIMD and SIMD is a good idea. If you doubt it, please explain why everything from Digital's Alpha to Motorola's G4 has SIMD instructions.
Intel has the power to push a standard. There is nothing wrong with them using that power (remember, AMD has a cross-license with Intel. They could use SSE anytime they wanted). They also make some of the best chips available. For a lot of things, a PIII whoops an Athlon's ass. If it doesn't, don't use it. However, a lot of people find the PIII better and for those people, it is stupid to say that Intel's chips aren't great.
Considering that P4 will probably equal P3 in vector ops/clock (3D stuff) I care about clock rate. Seriously though, a 1.5GHz P4 is probably as fast as a 600MHz Alpha in floating point. I don't care if it's less efficient, it is FASTER.
Sure it might be. Since it's a messaging architecture, it doesn't matter what program handles the messages. However, splitting up BSD was probably too much work for the first release, and UNIX isn't exactly designed to be split up that way (tons of calls inbetween the different layres, which must be replaced by messaging.)
Not really. There is a great deal of work done on making the GUI, and some work on polish stuff like making the file manager easy (like showing app folders as an executable) but the rest of the stuff is simply Quartz, BSD/Mach, OpenGL, and Quicktime. A FreeBSD/Quartz-like-layer would be MacOS X sans GUI, polish touches, and Quicktime.
RAM. You forget that at some point, that code has to be loaded into RAM. During normal usage, I often have regular X, GNOME, KDE, and other toolkits loaded at the same time. I could care less if they take up my harddrive, but at some point, they take up RAM.
1) I prefer the X version because often times make menuconfig on an Xterm flickers and looks weird.
2) Why aren't the man pages distributed preformatted? Sure I can do it myself, but tell that to the average computer user who has groff unneededly on their machine. Saying, "oh, just format it yourself and you can get rid of that program" is making excuses. It would never hold up under a magazine review, where they criticize if the developer splash-screen takes to long to load. I think one thing that is important is that we have to start looking at Linux software as commercial software, and holding it accountable to the same standard of polish that we do commerical software. In the mainstream, the developer has to do EVERYTHING for the user. If they don't, they are being lazy, and the preception of that software's quality is affected.
It seems that the pundits spend most of their time doubting Intel, while Intel becomes the de-facto standard with their new chips. Take the Pentium. Soon, everyone (AMD & Cyrix) moved to the super-scaler design. Intel added MMX, and AMD and Cyrix added 3DNow!. People originally thought that the PII would be a failure (it's slower than a PPro at the same clock-speed) but it became THE high-end standard for years. People thought that the Pentium wouldn't make it because it ran 486 optimized code slower than a 486. Instead, people just reoptimized their code. All these chips had quirks. Just like the P4 has quirks. However, the software industry will work around these quirks, just like they have for all the other Intel chips.
The con would be similar to the cons in Linux systems. People start to assume that you'll have a compiler, and the binary versions have reduced functionality. For example, I keep seeing binary packages that aren't compiled with full, pentium level optimizations. For a lot of software, pentium optimized binaries aren't even availabe. It's partially the fault of Linux and it's "support those 486s!" mentality (seriously though, what idiot would run KDE2 on a 486?) but if compilers are common, the developers can just say, "oh, compile that package yourself." Also, sometimes you get stuff like ALSA, that doesn't even come in binary form except in specific distros (like mandrake).
It seems to me, that all GNU programs are optimized for flexibility. Example
1) All the toolkits present in the average GNU system. Loads 'o bloat. However, very flexible FOR THE PROGRAMMER, NOT THE USER.
2) GNOME. Tons 'o stuff there that nobody really needs. Especiall Sawmill, who gives a damn if you can alter the thing with Lisp. Isn't Lisp SLOW?
3) GCC: Tons of flexibility, huge compiler.
4) The "GNU" in GNU/Linux. Lots of stuff nobody ever uses, but you have to have installed anyway because there is exactly one program you have to run that uses it. I could totally ditch Lesstif, if it wasn't for my midi player. I could get rid of TK if the kernel X config didn't use it, I could get rid of GTK if GIMP didn't use it (I use KDE), I could get rid of Perl if the system didn't use it (none of my programs do), I could get rid of gawk, bison, m4, groff, etc if there wasn't exactly one (like man and groff) program that didn't use it. Is there a reason that the minimal usable Linux install is about 400MB? A minimal usable NT install is about 250MB. A full BeOS install is 200MB, including media files and sample code.
PS> If he did't get modded down for calling GNU stuff bloated and sloppy (which it isn't) I shouldn't get modded down for calling Linux bloated and sloppy;)
They still lose out. They don't get the advantage of kepping the code in different servers seperate (which helps maintainablity.) They also don't get the additionaly stability afforded by keeping servers seperate. For example, if BeOS's servers were lumped together into one big "system server" then the system would be a lot less stable. This is due to the net_server (not the most bullet-proof software in existance, though don't be afriad, it's being replaced soon with BONE, which is in beta testing) crashing every few days. Now, if this had been a big system server, then the whole system would have gone down. Instead, all the is required is the restart of the net_server. The also still incur message-passing overhead. I gather that the bulk of message passing overhead isn't in kernel/server messaging, but in application/server messaging. Mach's messaging system isn't the fastest thing in existance, and I would think that that overhead would add up.
PS> And I'm pissed at Ars Technica (normally a good supporter of BeOS) for neglecting to mention that BeOS (QNX too) runs the servers in user-space. That comment about
"Most modern desktop and server operating systems" was needlessly exclusionary. Of course, maybe I'm just being anal.
You know what would be really cool? If somebody wrote a Quartz-like display layer for FreeBSD (replacing X.) With that and a little work on the GNUStep project, we'd have our own little (probably faster) version of OS X on Intel (and portable to Alpha or whatever.)
1) One thing nobody mentions, is that to a person obsessed with typographics quality (take a look at my machine, all folders are perfectly capitalized and punctuated) those capital "X"'s in from of all the function names are very jarring. The "gl" in front of all the OpenGL function names aren't offensive because they are small. All the B's in from of the BeOS class names aren't offenseive because people are used to seeing capital B's. However, in your daily reading, you almost never come across a capital X in a word, and that is slightly jarring. A small point, but it basically totally ruins X. (Sarcasm) Well, at least they don't have lower-case function names.
2) The programming isn't that hot either. True, I haven't programmed much, but it reminds me an aweful lot of Win32.
3) It's slow. It's really really slow. Even XFree86 4 is slow. Really really slow. You'd think that KDE2 running on XFree86 4.0 and kernel 2.4 (test8) would be fast. But it's not. It's slow. Really really slow. It's so slow, I'm actually glad to be rebooting back into NT. The last time I saw a file manager take as long to load as Konqueror was when I tried Active Desktop on an old 486. Every program seems to have a built in 10-second delay before it shows up, and when resizing programs flicker and rubber-band like mad. It's not KDE's fault (GNOME does it too) and nobody ever said the kernel was slow, so it has to be X. (One day, try resizing Konqueror (on a 300MHz machine) in a folder with a lot of files. Watch the flicker and rubber-banding. Now try the same in WindowsNT. Very little flicker, no rubber-banding. Try it in BeOS. No flicker whatsoever.
4) There are dozens of toolkits for it. What most people (toolkit writers) don't realize is that toolkits take RAM. It is silly that at any one time, I've got over 4 toolkits running concurently on my system. (TK, straight-X, GNOME, KDE, (and GTK and Qt if you count those as seperate, which in terms of size they are))
Actually, I think that the reason that all Classic apps run in the same process space is because that's what the apps expect. It's probably not a limitation, but a requirement to make the apps work.
Plus, you have to note that Quartz is absent from Darwin, (the underlying kernel and servers.) Do you think Apple takes Quartz out of Darwin for each Darwin release?
The only reason that MacOS X uses the BSD on top of microkernel design is because NeXT did. There are far better ways to use a microkernel, namely splitting the servers up into different executables. That gives you one of the primary advantages over macrokernels, the fact that major pieces of code can be overheauled without paying much attention to other pieces of code.
Use the BSD license. At least then you don't have to sue them over it.
Just kidding;) Actually, I'm surprised this hasn't happened sooner. The GPL isn't exactly a bullet-proof license, and as it gets more popular, events like this are going to become more common.
Well, there is some truth to Darwn being monolithic. It's essentially Mach with a BSD system sever. Why you'd do that, I have no clue, since one of the benifets of a microkernel is that severs are independant. With Mach/BSD, you have to problem of system complexity due to the monolithic design, and you have the problem's with overhead that Mach brings with it. Silly really.
Slashdot Mirror
What severe problems? If your talking about the P4 being slower than a similarly clocked P3, remember that the P2 was slower than a similarly clocked P2. Or that a Pentium was slower than a 486 for most code out at the time. If your talking about heat, remember that the .25 micron Athlons were massive heat-machines, and the even the old P2 300MHz chewed up nearly 40 watts. If your talking about manufacturing, remember that AMD at several points wasn't even able to meet the demand for 2-something million chips. If you can tell me what's so bad about Intel chips, aside from manufacturing glitches common to all companies, then you have a point.
MMX wasn't just marketing. It genuinely sped up 3D. However, Intel didn't count on 3D accelerators coming on. MMX was designed in the days of the ViRGE and fixed-point 3D engines. How would have thought that some day 3D accelerators would have fill-rates in excess of 1.6 gigatexels? Intel certainly didn't, and appropriatly, they designed MMX to speed up integer calculations. However, the design wouldn't allow you to concurrently run floating point, and thus, developers started to use fp/3d acceleration instead of fixed-point/MMX. However. MMX is SIMD and SIMD is a good idea. If you doubt it, please explain why everything from Digital's Alpha to Motorola's G4 has SIMD instructions.
Intel has the power to push a standard. There is nothing wrong with them using that power (remember, AMD has a cross-license with Intel. They could use SSE anytime they wanted). They also make some of the best chips available. For a lot of things, a PIII whoops an Athlon's ass. If it doesn't, don't use it. However, a lot of people find the PIII better and for those people, it is stupid to say that Intel's chips aren't great.
Considering that P4 will probably equal P3 in vector ops/clock (3D stuff) I care about clock rate. Seriously though, a 1.5GHz P4 is probably as fast as a 600MHz Alpha in floating point. I don't care if it's less efficient, it is FASTER.
Sure it might be. Since it's a messaging architecture, it doesn't matter what program handles the messages. However, splitting up BSD was probably too much work for the first release, and UNIX isn't exactly designed to be split up that way (tons of calls inbetween the different layres, which must be replaced by messaging.)
Not really. There is a great deal of work done on making the GUI, and some work on polish stuff like making the file manager easy (like showing app folders as an executable) but the rest of the stuff is simply Quartz, BSD/Mach, OpenGL, and Quicktime. A FreeBSD/Quartz-like-layer would be MacOS X sans GUI, polish touches, and Quicktime.
RAM. You forget that at some point, that code has to be loaded into RAM. During normal usage, I often have regular X, GNOME, KDE, and other toolkits loaded at the same time. I could care less if they take up my harddrive, but at some point, they take up RAM.
1) I prefer the X version because often times make menuconfig on an Xterm flickers and looks weird.
2) Why aren't the man pages distributed preformatted? Sure I can do it myself, but tell that to the average computer user who has groff unneededly on their machine. Saying, "oh, just format it yourself and you can get rid of that program" is making excuses. It would never hold up under a magazine review, where they criticize if the developer splash-screen takes to long to load. I think one thing that is important is that we have to start looking at Linux software as commercial software, and holding it accountable to the same standard of polish that we do commerical software. In the mainstream, the developer has to do EVERYTHING for the user. If they don't, they are being lazy, and the preception of that software's quality is affected.
It seems that the pundits spend most of their time doubting Intel, while Intel becomes the de-facto standard with their new chips. Take the Pentium. Soon, everyone (AMD & Cyrix) moved to the super-scaler design. Intel added MMX, and AMD and Cyrix added 3DNow!. People originally thought that the PII would be a failure (it's slower than a PPro at the same clock-speed) but it became THE high-end standard for years. People thought that the Pentium wouldn't make it because it ran 486 optimized code slower than a 486. Instead, people just reoptimized their code. All these chips had quirks. Just like the P4 has quirks. However, the software industry will work around these quirks, just like they have for all the other Intel chips.
Undoubtedly, someone will figure it out. Hell, even Windows has theming.
The con would be similar to the cons in Linux systems. People start to assume that you'll have a compiler, and the binary versions have reduced functionality. For example, I keep seeing binary packages that aren't compiled with full, pentium level optimizations. For a lot of software, pentium optimized binaries aren't even availabe. It's partially the fault of Linux and it's "support those 486s!" mentality (seriously though, what idiot would run KDE2 on a 486?) but if compilers are common, the developers can just say, "oh, compile that package yourself." Also, sometimes you get stuff like ALSA, that doesn't even come in binary form except in specific distros (like mandrake).
That's because FreeBSD uses the BSD-C library.
It seems to me, that all GNU programs are optimized for flexibility. Example
1) All the toolkits present in the average GNU system. Loads 'o bloat. However, very flexible FOR THE PROGRAMMER, NOT THE USER.
2) GNOME. Tons 'o stuff there that nobody really needs. Especiall Sawmill, who gives a damn if you can alter the thing with Lisp. Isn't Lisp SLOW?
3) GCC: Tons of flexibility, huge compiler.
4) The "GNU" in GNU/Linux. Lots of stuff nobody ever uses, but you have to have installed anyway because there is exactly one program you have to run that uses it. I could totally ditch Lesstif, if it wasn't for my midi player. I could get rid of TK if the kernel X config didn't use it, I could get rid of GTK if GIMP didn't use it (I use KDE), I could get rid of Perl if the system didn't use it (none of my programs do), I could get rid of gawk, bison, m4, groff, etc if there wasn't exactly one (like man and groff) program that didn't use it. Is there a reason that the minimal usable Linux install is about 400MB? A minimal usable NT install is about 250MB. A full BeOS install is 200MB, including media files and sample code.
Like Linux?
;)
PS> If he did't get modded down for calling GNU stuff bloated and sloppy (which it isn't) I shouldn't get modded down for calling Linux bloated and sloppy
They still lose out. They don't get the advantage of kepping the code in different servers seperate (which helps maintainablity.) They also don't get the additionaly stability afforded by keeping servers seperate. For example, if BeOS's servers were lumped together into one big "system server" then the system would be a lot less stable. This is due to the net_server (not the most bullet-proof software in existance, though don't be afriad, it's being replaced soon with BONE, which is in beta testing) crashing every few days. Now, if this had been a big system server, then the whole system would have gone down. Instead, all the is required is the restart of the net_server. The also still incur message-passing overhead. I gather that the bulk of message passing overhead isn't in kernel/server messaging, but in application/server messaging. Mach's messaging system isn't the fastest thing in existance, and I would think that that overhead would add up.
PS> And I'm pissed at Ars Technica (normally a good supporter of BeOS) for neglecting to mention that BeOS (QNX too) runs the servers in user-space. That comment about
"Most modern desktop and server operating systems" was needlessly exclusionary. Of course, maybe I'm just being anal.
You know what would be really cool? If somebody wrote a Quartz-like display layer for FreeBSD (replacing X.) With that and a little work on the GNUStep project, we'd have our own little (probably faster) version of OS X on Intel (and portable to Alpha or whatever.)
1) One thing nobody mentions, is that to a person obsessed with typographics quality (take a look at my machine, all folders are perfectly capitalized and punctuated) those capital "X"'s in from of all the function names are very jarring. The "gl" in front of all the OpenGL function names aren't offensive because they are small. All the B's in from of the BeOS class names aren't offenseive because people are used to seeing capital B's. However, in your daily reading, you almost never come across a capital X in a word, and that is slightly jarring. A small point, but it basically totally ruins X. (Sarcasm) Well, at least they don't have lower-case function names.
2) The programming isn't that hot either. True, I haven't programmed much, but it reminds me an aweful lot of Win32.
3) It's slow. It's really really slow. Even XFree86 4 is slow. Really really slow. You'd think that KDE2 running on XFree86 4.0 and kernel 2.4 (test8) would be fast. But it's not. It's slow. Really really slow. It's so slow, I'm actually glad to be rebooting back into NT. The last time I saw a file manager take as long to load as Konqueror was when I tried Active Desktop on an old 486. Every program seems to have a built in 10-second delay before it shows up, and when resizing programs flicker and rubber-band like mad. It's not KDE's fault (GNOME does it too) and nobody ever said the kernel was slow, so it has to be X. (One day, try resizing Konqueror (on a 300MHz machine) in a folder with a lot of files. Watch the flicker and rubber-banding. Now try the same in WindowsNT. Very little flicker, no rubber-banding. Try it in BeOS. No flicker whatsoever.
4) There are dozens of toolkits for it. What most people (toolkit writers) don't realize is that toolkits take RAM. It is silly that at any one time, I've got over 4 toolkits running concurently on my system. (TK, straight-X, GNOME, KDE, (and GTK and Qt if you count those as seperate, which in terms of size they are))
BeOS is doing Java2 as well. In fact, so is Caldera LTP (Linux technology preview.)
Actually, I think that the reason that all Classic apps run in the same process space is because that's what the apps expect. It's probably not a limitation, but a requirement to make the apps work.
However, Win32 is derived from Win16. MacOS and BSD are completely different.
Funny, almost the entire user-land POSIX stuff in BeOS is GPL'ed. Can you point me to the source code?
Quartz=X (more or less)
Aqua=WindowMaker.
Plus, you have to note that Quartz is absent from Darwin, (the underlying kernel and servers.) Do you think Apple takes Quartz out of Darwin for each Darwin release?
The only reason that MacOS X uses the BSD on top of microkernel design is because NeXT did. There are far better ways to use a microkernel, namely splitting the servers up into different executables. That gives you one of the primary advantages over macrokernels, the fact that major pieces of code can be overheauled without paying much attention to other pieces of code.
Use the BSD license. At least then you don't have to sue them over it.
;) Actually, I'm surprised this hasn't happened sooner. The GPL isn't exactly a bullet-proof license, and as it gets more popular, events like this are going to become more common.
Just kidding
Maybe they don't care? There is only one way to guarentee that you won't get ripped of. Use a closed-source license.
GPL: Freedom with provisos.
Well, there is some truth to Darwn being monolithic. It's essentially Mach with a BSD system sever. Why you'd do that, I have no clue, since one of the benifets of a microkernel is that severs are independant. With Mach/BSD, you have to problem of system complexity due to the monolithic design, and you have the problem's with overhead that Mach brings with it. Silly really.
I have no clue how to write a script for CVS (I don't use it.) Isn't stuff like this things that THEY'RE supposed to do?