But how is this not automated? You download a.src.rpm, do an "rpm -i" on it, modify the spec file in/usr/src/redhat/SPECS. And then you just do an "rpm -bb" to build a binary package, or an "rpm -bs" to create a modified source rpm, or "rpm -ba" to do both. The spec file isn't any harder to change than a FreeBSD ports Makefile.
The only difference is you have to download the source ahead of time for rpm's. But any changes you make to a FreeBSD ports Makefile will need to be redone when the package gets updated anyways.
There's such a thing as a source rpm. Every binary rpm must have a corresponding source rpm. If you want to build something yourself, all you need to do is download the.src.rpm, install it, and modify the spec file. It's pretty easy to locate the configuration options. And after you modify the spec file, you can build a new source rpm from it. Then you can install your modified binary package on several other computers without having to recompile on each one.
But 3dfx only "came to the table" once they were getting their asses kicked by Nvidia. Do you remember how they were in the days of the Voodoo 2? They were worse than Nvidia has ever been. They coaxed game developers to use their proprietary Glide API, so that games would only run on their cards. And back then it was even illegal to make your own clean room implementation of Glide. They cracked down hard on people making Glide wrappers. At least Nvidia has played fairly. Nvidia supported open APIs like DirectX and OpenGL. They were successful because they had a better performing product.
3dfx never gave a rat's ass about the Linux community when they were on top. Sure, they allowed closed source port of Glide under an NDA, but that didn't involve any 3dfx resources. Nvidia had at least been devoting their own resources to help the Linux community. Once Nvidia surpassed 3dfx, there was no longer a reason for 3dfx to keep their documentation closed. Nobody wanted their technology anymore. There were no longer any risks. They could open up Glide because they could no longer convince people to program in it exclusively.
Hell, there are plenty of places in even Silicon Valley (in San Jose even) where you still can't get either DSL or cable modem. TCI (silicon valley's cable service) did a pathetic job with cable modem. In the first 3 years or so they had next to no expansion out of their testing area in Fremont, and their coverage is still very small. And Pacific Bell has been pathetic about DSL too. There are a lot of people that have remained a mere 300 yards out of range of their central office for a long long time.
But in the U.S. we also don't have to any per-minute charges on local phone calls. I don't know anything about Norway, but there are a lot of places in Europe (the UK I think?) where you do have to pay per-minute charges. That means we can access the Internet over a modem and just pay for a monthly ISP charge. And long distance landline costs lots cheaper here than cellular/PCS. For example, it would be between 5 cents/min and 10 cents/min for a long distance call to someone else in the U.S. Prepaid minutes on a PCS phone are like 35 cents/minute. You pay like double or triple the cost for the luxury of using a cellular phone. So it isn't something the average person would be willing to pay for.
There are a few basic parts of X. There are the X libraries that are used by X client software. And then there is the X server. The X server is what talks to your display hardware. The clients talk to the Xserver using the X protocol. X.org's job is to develop those libraries, and define the protocols and most of the extensions to the X server. X.org maintains some X servers for testing purposes.
XFree86's job is essentially to write an Xserver that can talk to PC video cards. And workstation venders write X servers for their own OS's. But the hardware independant part of the Xserver code is provided by X.org . The X libraries we use are almost unchanged from that provided by X.org . That's how there is compatibility between Sun and Linux X programs. However, XFree86 does incorporate additional patches because X.org takes too long to do anything. And XFree86 does write new X extensions and is in the process of redoing the rendering model. In theory, X.org should have been the ones to do that. But the Open Group lacks the ability and/or will to innovate. Graphics innovation is now driven by the PC market, so it is PC UNIX developers that advance the GUI for UNIX.
What you call flaming and bashing, others call free expression. I haven't seen many comments claiming Trolltech is a tyrannical company for charging for their software. Trolltech has a right to do what they want as a company. But people also have a right to express their distaste for the QT license.
To some people, it's all about technical merits. I won't doubt that KDE and Qt are more developed and more stable than GNOME. But for other people, the extra freedom that GNOME provides is more important.
Trolltech has a right to be adamant about their QPL license, and slashdot posters have a right to express their disapproval of it. And as often as they want to. That's what free speech and slashdot are about.
And, I don't think such "flames" turn developers away from Linux. Trolltech, and other companies, are there to make a living for their employees. They're not there are as a charity organization surviving on good will emanating from slashdot.
Trolltech knows that the set of slashdot commenters doesn't equate with the linux community. Do you think Windows and Mac users don't express their negative opinions on their boards? Anybody can post a comment on slashdot, and that doesn't mean that person's comment is worth anything. Companies know that.
At least Trolltech is being made to know what the negative opinions are. It's better than them hearing nothing bad, and then wondering why their acceptance isn't as high as they expect it to be.
Even before Motif was open sourced, you could pay around $150 or less for a developer edition which would let you develop applications with no licensing fees. If you run Solaris or HP/UX or any other commercial UNIX with built-in CDE, you don't pay anything other than the cost of the OS. Trolltech charges $1550 for a single closed-source developer Qt/UNIX license, with the price dropping to around $1000 per developer en masse. Using GNOME and GTK+ costs nothing.
I won't argue whether Trolltech should charge money or not. They have a right to support themselves. I'm just saying that GNOME is advantageous in this respect. The workstation venders probably feel that the weaknesses of GNOME can be overcome.
You don't have to use Enlightenment, for example. Sawfish is now the new window manager of choice for GNOME. It performs better and has tighter integration.
And perhaps they're paranoid having to defer control of the Qt standard to another corporation. If all UNIX venders standardized on Qt, Trolltech would be a very powerful company indeed. Though the OSF controls Motif and CDE, the OSF itself is made up of the workstation venders.
Also, you have to also have to pay a license fee to develop a commercial closed source application with Qt (and therefore KDE). That isn't something that Sun and HP require today. You don't have to pay a license fee for developing CDE applications. You might decide to pay for a commercial compiler, but you certainly don't have to. All GNOME libraries are LGPL'd, so they are free for use for open or closed source purposes. And another thing is that Qt is controlled by one company: Trolltech. But GNOME is not owned by any corporation, so the workstation venders would have some influence in its development. I bet these factors were enough to drive the "big boys" away from KDE.
It's not a gimmick. SIMD worked pretty darn well on the Cray, and is heavily used in DSPs in the form of multiplier-accumulators. The only problem is that you need code that actually uses it. It works great for matrix multiplication. You can tell a processor to multiple a row of a matrix by a constant, and it can then perform it as a parallel operation. Without it, you'd have to hope that the processor realizes that it can perform the multiplications in parallel. And image processing and 3D graphics software do a lot of matrix multiplications.
The reason we don't see much benefit on Intel processors is because the implementation is seriously limited. MMX shares the same registers as the FPU because expanding the register set forces all operating systems to be updated to save extra registers on a context switch. Microsoft would have had to release new versions of Windows, and Intel didn't want to go that route. And the x86 FPU unit is stack based, which makes it hard to optimize in the first place. The only decent implementations were on processors with little software support to begin with, except for the G4. The only evidence we have of SIMD's advantages on the desktop is from Mac OS X. But that isn't released yet, so we don't all have first hand evidence.
And the reason that someone is backing away is because they can't manufacture their chip properly. In a situation like that, a company would rather say the feature is not that important than say their design was a failure.
But MMX, SSE, and 3DNow! are hard to use in the first place. All that sharing of registers and register switching crap cripples the performance of SIMD. There's a tradeoff involved, and you may end up reducing performance if you aren't careful. Altivec involves a completely independant register set, so you can only really gain in performance. Of course, this is all a theoretical point if Motorola can't produce the chips with decent yield. And they certainly aren't!
I don't understand why there is so much trouble with Altivec. The UltraSPARC, HP PA-RISC, Alpha, and MIPS processors all have SIMD units. Even the cheap embedded processors like the SH4 have integer and fp SIMD. I think Motorola was actually the last to add support. I doubt there's an inherent problem with Altivec. It's probably that Motorola's G4 design doesn't fabricate well.
Motorola has had a lot of trouble in the past with their designs. Many of their 64 bit designs (the 620 and 640) were scrapped because of manufacturing problems. I believe that the only surviving member, the 630, is what IBM calls the Power 4.
BTW, IBM doesn't use the G5 at all right now. It doesn't really exist yet. They use the Power 4. The G5 is Motorola's new 64 bit design.
There's one big problem with this idea. And it's something that a lot of Linux end users don't seem to realize. When you develop a piece of software for X windows, you have to make a big choice as to what toolkit you're going to use. We didn't have Motif for Linux, so we couldn't accept that was a standard. Now we have GNOME in the form of gtk and KDE in the form of qt. The APIs are very different. If you're a software developer, you forced to make a decision what API to use. This isn't all that big a deal, for example, if you're writing a random irc client for the fun of it.
But if you're trying to make a commercial product, it's very disconcerting when you have to make a choice between two very popular APIs on the SAME platform. You automatically lose half your possible market share. What happens if a user only wants to install KDE or GNOME? A developer can't rely on being able to use a given CORBA/component model to interact with the desktop. And the user might not even install the libraries for both toolkits. And if they did, they could complain of unreasonable memory usages because both libraries are memory resident. And suppose you picked wrong, and ended up choosing the toolkit/environment that people don't like anymore?
Problems like these are what kept developers away from UNIX in the first place. The OpenLook/Motif war killed prospects in the past, and a continuing GNOME/KDE war would do the same. And it was because we couldn't rely on any proper toolkit foundation that we're forced to play catch up to Microsoft in componentization and application interoperability.
It's a good thing that the workstation venders have given up their proprietary CDE, which is too limited and hard to develop in. The choice was simple. Qt requires license fees for the development of a commercial application, while GNOME/gtk is completely free. And even by standardizing on gtk and the Bonobo component model, there is still plenty of software choice available. Even the KDE people have been considering merging with Bonobo, because there is to gain in standardizing on a component model.
Because if it was only under the GPL, Netscape wouldn't be allowed to make the code part of a proprietary product. With the MPL they can do that. They want to be able to have a Netscape 6 that's based on Mozilla but can include their own proprietary changes. But I believe that the MPL doesn't allow other companies to take the code and make it part of their own proprietary product. The BSD license would have allowed that as well.
Berkeley called it IRAM (for Intelligent RAM). Inferring to the fact that since the DRAM has more transisters than a processor core, it would be more like you have RAM with a processor inside rather than a CPU with RAM inside. I don't think it's that great of an idea now for general purpose CPUs. DRAM latency isn't decreased all that much, and you're stuck with whatever amount of DRAM your processor has built in. You could of course add more offchip as a second level RAM. But if you use the onchip memory as a cache for the offchip memory, the latency to offchip RAM is increases as a result of the additional miss penalty from the onchip memory. This would be more significant than a SRAM cache miss, because SRAM is so much faster than DRAM the miss penalty is almost unnoticed.
DRAM latency is just too slow. The performance gap between processors and DRAM has been widening exponentially. Pretty soon, processors would be spending thousands of clock cycles waiting for DRAM accesses. Increasing memory bandwidth doesn't solve that. Programs often need to read from some memory location before they know where to read/write next or what to calculate next. You'll inevitably be waiting on successive short reads and writes. Prediction, speculation, and parallization can't go far enough to hide DRAM's poor latency. The shortcomings are already very noticeable. Doubling clock rate doesn't make Win2k boot or run near twice as fast. Office applications aren't really getting any faster. We really need a memory technology that can keep pace with processor speeds, if such a thing is even possible.
Slashdot Mirror
But how is this not automated? You download a .src.rpm, do an "rpm -i" on it, modify the spec file in /usr/src/redhat/SPECS. And then you just do an "rpm -bb" to build a binary package, or an "rpm -bs" to create a modified source rpm, or "rpm -ba" to do both. The spec file isn't any harder to change than a FreeBSD ports Makefile.
The only difference is you have to download the source ahead of time for rpm's. But any changes you make to a FreeBSD ports Makefile will need to be redone when the package gets updated anyways.
There's such a thing as a source rpm. Every binary rpm must have a corresponding source rpm. If you want to build something yourself, all you need to do is download the .src.rpm, install it, and modify the spec file. It's pretty easy to locate the configuration options. And after you modify the spec file, you can build a new source rpm from it. Then you can install your modified binary package on several other computers without having to recompile on each one.
But 3dfx only "came to the table" once they were getting their asses kicked by Nvidia. Do you remember how they were in the days of the Voodoo 2? They were worse than Nvidia has ever been. They coaxed game developers to use their proprietary Glide API, so that games would only run on their cards. And back then it was even illegal to make your own clean room implementation of Glide. They cracked down hard on people making Glide wrappers. At least Nvidia has played fairly. Nvidia supported open APIs like DirectX and OpenGL. They were successful because they had a better performing product.
3dfx never gave a rat's ass about the Linux community when they were on top. Sure, they allowed closed source port of Glide under an NDA, but that didn't involve any 3dfx resources. Nvidia had at least been devoting their own resources to help the Linux community. Once Nvidia surpassed 3dfx, there was no longer a reason for 3dfx to keep their documentation closed. Nobody wanted their technology anymore. There were no longer any risks. They could open up Glide because they could no longer convince people to program in it exclusively.
Hell, there are plenty of places in even Silicon Valley (in San Jose even) where you still can't get either DSL or cable modem. TCI (silicon valley's cable service) did a pathetic job with cable modem. In the first 3 years or so they had next to no expansion out of their testing area in Fremont, and their coverage is still very small. And Pacific Bell has been pathetic about DSL too. There are a lot of people that have remained a mere 300 yards out of range of their central office for a long long time.
But in the U.S. we also don't have to any per-minute charges on local phone calls. I don't know anything about Norway, but there are a lot of places in Europe (the UK I think?) where you do have to pay per-minute charges. That means we can access the Internet over a modem and just pay for a monthly ISP charge. And long distance landline costs lots cheaper here than cellular/PCS. For example, it would be between 5 cents/min and 10 cents/min for a long distance call to someone else in the U.S. Prepaid minutes on a PCS phone are like 35 cents/minute. You pay like double or triple the cost for the luxury of using a cellular phone. So it isn't something the average person would be willing to pay for.
There are a few basic parts of X. There are the X libraries that are used by X client software. And then there is the X server. The X server is what talks to your display hardware. The clients talk to the Xserver using the X protocol. X.org's job is to develop those libraries, and define the protocols and most of the extensions to the X server. X.org maintains some X servers for testing purposes.
XFree86's job is essentially to write an Xserver that can talk to PC video cards. And workstation venders write X servers for their own OS's. But the hardware independant part of the Xserver code is provided by X.org . The X libraries we use are almost unchanged from that provided by X.org . That's how there is compatibility between Sun and Linux X programs. However, XFree86 does incorporate additional patches because X.org takes too long to do anything. And XFree86 does write new X extensions and is in the process of redoing the rendering model. In theory, X.org should have been the ones to do that. But the Open Group lacks the ability and/or will to innovate. Graphics innovation is now driven by the PC market, so it is PC UNIX developers that advance the GUI for UNIX.
What you call flaming and bashing, others call free expression. I haven't seen many comments claiming Trolltech is a tyrannical company for charging for their software. Trolltech has a right to do what they want as a company. But people also have a right to express their distaste for the QT license.
To some people, it's all about technical merits. I won't doubt that KDE and Qt are more developed and more stable than GNOME. But for other people, the extra freedom that GNOME provides is more important.
Trolltech has a right to be adamant about their QPL license, and slashdot posters have a right to express their disapproval of it. And as often as they want to. That's what free speech and slashdot are about.
And, I don't think such "flames" turn developers away from Linux. Trolltech, and other companies, are there to make a living for their employees. They're not there are as a charity organization surviving on good will emanating from slashdot.
Trolltech knows that the set of slashdot commenters doesn't equate with the linux community. Do you think Windows and Mac users don't express their negative opinions on their boards? Anybody can post a comment on slashdot, and that doesn't mean that person's comment is worth anything. Companies know that.
At least Trolltech is being made to know what the negative opinions are. It's better than them hearing nothing bad, and then wondering why their acceptance isn't as high as they expect it to be.
Even before Motif was open sourced, you could pay around $150 or less for a developer edition which would let you develop applications with no licensing fees. If you run Solaris or HP/UX or any other commercial UNIX with built-in CDE, you don't pay anything other than the cost of the OS. Trolltech charges $1550 for a single closed-source developer Qt/UNIX license, with the price dropping to around $1000 per developer en masse. Using GNOME and GTK+ costs nothing.
I won't argue whether Trolltech should charge money or not. They have a right to support themselves. I'm just saying that GNOME is advantageous in this respect. The workstation venders probably feel that the weaknesses of GNOME can be overcome.
You don't have to use Enlightenment, for example. Sawfish is now the new window manager of choice for GNOME. It performs better and has tighter integration.
And perhaps they're paranoid having to defer control of the Qt standard to another corporation. If all UNIX venders standardized on Qt, Trolltech would be a very powerful company indeed. Though the OSF controls Motif and CDE, the OSF itself is made up of the workstation venders.
Also, you have to also have to pay a license fee to develop a commercial closed source application with Qt (and therefore KDE). That isn't something that Sun and HP require today. You don't have to pay a license fee for developing CDE applications. You might decide to pay for a commercial compiler, but you certainly don't have to. All GNOME libraries are LGPL'd, so they are free for use for open or closed source purposes. And another thing is that Qt is controlled by one company: Trolltech. But GNOME is not owned by any corporation, so the workstation venders would have some influence in its development. I bet these factors were enough to drive the "big boys" away from KDE.
It's not a gimmick. SIMD worked pretty darn well on the Cray, and is heavily used in DSPs in the form of multiplier-accumulators. The only problem is that you need code that actually uses it. It works great for matrix multiplication. You can tell a processor to multiple a row of a matrix by a constant, and it can then perform it as a parallel operation. Without it, you'd have to hope that the processor realizes that it can perform the multiplications in parallel. And image processing and 3D graphics software do a lot of matrix multiplications.
The reason we don't see much benefit on Intel processors is because the implementation is seriously limited. MMX shares the same registers as the FPU because expanding the register set forces all operating systems to be updated to save extra registers on a context switch. Microsoft would have had to release new versions of Windows, and Intel didn't want to go that route. And the x86 FPU unit is stack based, which makes it hard to optimize in the first place. The only decent implementations were on processors with little software support to begin with, except for the G4. The only evidence we have of SIMD's advantages on the desktop is from Mac OS X. But that isn't released yet, so we don't all have first hand evidence.
And the reason that someone is backing away is because they can't manufacture their chip properly. In a situation like that, a company would rather say the feature is not that important than say their design was a failure.
Whoops, correction: the PowerPC 630 actually became the Power 3, I believe. The Power 4 is a new thing.
But MMX, SSE, and 3DNow! are hard to use in the first place. All that sharing of registers and register switching crap cripples the performance of SIMD. There's a tradeoff involved, and you may end up reducing performance if you aren't careful. Altivec involves a completely independant register set, so you can only really gain in performance. Of course, this is all a theoretical point if Motorola can't produce the chips with decent yield. And they certainly aren't!
I don't understand why there is so much trouble with Altivec. The UltraSPARC, HP PA-RISC, Alpha, and MIPS processors all have SIMD units. Even the cheap embedded processors like the SH4 have integer and fp SIMD. I think Motorola was actually the last to add support. I doubt there's an inherent problem with Altivec. It's probably that Motorola's G4 design doesn't fabricate well.
Motorola has had a lot of trouble in the past with their designs. Many of their 64 bit designs (the 620 and 640) were scrapped because of manufacturing problems. I believe that the only surviving member, the 630, is what IBM calls the Power 4.
BTW, IBM doesn't use the G5 at all right now. It doesn't really exist yet. They use the Power 4. The G5 is Motorola's new 64 bit design.
There's one big problem with this idea. And it's something that a lot of Linux end users don't seem to realize. When you develop a piece of software for X windows, you have to make a big choice as to what toolkit you're going to use. We didn't have Motif for Linux, so we couldn't accept that was a standard. Now we have GNOME in the form of gtk and KDE in the form of qt. The APIs are very different. If you're a software developer, you forced to make a decision what API to use. This isn't all that big a deal, for example, if you're writing a random irc client for the fun of it.
But if you're trying to make a commercial product, it's very disconcerting when you have to make a choice between two very popular APIs on the SAME platform. You automatically lose half your possible market share. What happens if a user only wants to install KDE or GNOME? A developer can't rely on being able to use a given CORBA/component model to interact with the desktop. And the user might not even install the libraries for both toolkits. And if they did, they could complain of unreasonable memory usages because both libraries are memory resident. And suppose you picked wrong, and ended up choosing the toolkit/environment that people don't like anymore?
Problems like these are what kept developers away from UNIX in the first place. The OpenLook/Motif war killed prospects in the past, and a continuing GNOME/KDE war would do the same. And it was because we couldn't rely on any proper toolkit foundation that we're forced to play catch up to Microsoft in componentization and application interoperability.
It's a good thing that the workstation venders have given up their proprietary CDE, which is too limited and hard to develop in. The choice was simple. Qt requires license fees for the development of a commercial application, while GNOME/gtk is completely free. And even by standardizing on gtk and the Bonobo component model, there is still plenty of software choice available. Even the KDE people have been considering merging with Bonobo, because there is to gain in standardizing on a component model.
Because if it was only under the GPL, Netscape wouldn't be allowed to make the code part of a proprietary product. With the MPL they can do that. They want to be able to have a Netscape 6 that's based on Mozilla but can include their own proprietary changes. But I believe that the MPL doesn't allow other companies to take the code and make it part of their own proprietary product. The BSD license would have allowed that as well.
Berkeley called it IRAM (for Intelligent RAM). Inferring to the fact that since the DRAM has more transisters than a processor core, it would be more like you have RAM with a processor inside rather than a CPU with RAM inside. I don't think it's that great of an idea now for general purpose CPUs. DRAM latency isn't decreased all that much, and you're stuck with whatever amount of DRAM your processor has built in. You could of course add more offchip as a second level RAM. But if you use the onchip memory as a cache for the offchip memory, the latency to offchip RAM is increases as a result of the additional miss penalty from the onchip memory. This would be more significant than a SRAM cache miss, because SRAM is so much faster than DRAM the miss penalty is almost unnoticed.
DRAM latency is just too slow. The performance gap between processors and DRAM has been widening exponentially. Pretty soon, processors would be spending thousands of clock cycles waiting for DRAM accesses. Increasing memory bandwidth doesn't solve that. Programs often need to read from some memory location before they know where to read/write next or what to calculate next. You'll inevitably be waiting on successive short reads and writes. Prediction, speculation, and parallization can't go far enough to hide DRAM's poor latency. The shortcomings are already very noticeable. Doubling clock rate doesn't make Win2k boot or run near twice as fast. Office applications aren't really getting any faster. We really need a memory technology that can keep pace with processor speeds, if such a thing is even possible.