So this means that we will see more flashy games with no plot or gameplay. Some of the simplest games are the best (starcraft & warcraft come to mind for one particular genre)... Should we really encourage game developers to spend all of their time on the "next big effect"?
While it may be that the PowerVR2 did not implement it correctly, there is nothing that prevents alpha blending performance much better than immediate mode style rasterizers. Consider it this way:
A game needs to draw 5 opaque polygons, with 3 alpha polygons on top.
An immediate mode rasterizer would have to write all five polygons to memory, including all of the associated texture lookups and lighting calculations. Then, for each alpha polygon, it would have to reread bits from the framebuffer and combine it with the shaded textured alpha polygon. This is a lot of memory traffic.
A tile based renderer, otoh, would not need to do all of this. Obviously it would be able to eliminate all of the overdraw on the opaque polygons, but it would also be able to do the blending in the ON CHIP 24bit tile framebuffer, which is much much much faster than going to off chip memory. This means that instead of having to do read-modify-write off chip memory cycles for each of those alpha blended polygons, it stays on chip.
Now like I said before, I am not familiar with the PowerVR2 chip, and it may be that they do not implement this obvious optimization... I would assume their newer chip would.
My big question is "why not a T&L unit?" It seems like a sever handicap to an otherwise stellar chip. Although somewhat addressed in the article, they didn't really justify it well, and the benchmarks prove it would be handy. Maybe the 175mhz clock is what prevents an effective T&L unit from being added...
While it may be that the PowerVR2 did not implement it correctly, there is nothing that prevents performance much better than immediate mode style rasterizers. Consider it this way:
A game needs to draw 5 opaque polygons, with 3 alpha polygons on top.
An immediate mode rasterizer would have to write all five polygons to memory, including all of the associated texture lookups and lighting calculations. Then, for each alpha polygon, it would have to reread bits from the framebuffer and combine it with the shaded textured alpha polygon. This is a lot of memory traffic.
A tile based renderer, otoh, would not need to do all of this. Obviously it would be able to eliminate all of the overdraw on the opaque polygons, but it would also be able to do the blending in the ON CHIP 24bit tile framebuffer, which is much much much faster than going to off chip memory. This means that instead of having to do read-modify-write off chip memory cycles for each of those alpha blended polygons, it stays on chip.
Now like I said before, I am not familiar with the PowerVR2 chip, and it may be that they do not implement this obvious optimization... I would assume their newer chip would.
My big question is "why not a T&L unit?" It seems like a sever handicap to an otherwise stellar chip. Although somewhat addressed in the article, they didn't really justify it well, and the benchmarks prove it would be handy. Maybe the 175mhz clock is what prevents an effective T&L unit from being added...
Doesn't anyone else feel it's time for a back to basics aproach with computers? Less eye-candy, more functionality, please.
I agree. I never understood why my grandma couldn't figure out how to just flip 32 switches into the right position and hit the "store" button like everyone else... I had to get rid of my poor PDP just 'cause she wanted something pointy and clicky...
"Today, product activation is a simple process that guarantees user privacy and curbs the negative impact of software piracy. Many users have seen the benefits of software activation, such as assurance that the product will include user manuals, product identifications, certificates of authenticity and complete software code. "
Hrm... those manuals sure are nice. I'm glad I registered my software... err.. yah. Also, don't you hate it when someone only burns you half of that office CD? Hrm...
A while back there was mention of using Transmeta's Crusoe processor for server applications like this... It would seem to be a very good solution, because once you start packing servers together this closely, heat and powerconsumption (California redux?:) becomes a major major issue.
Has anyone else heard anything more about this, or has Transmeta stopped pushing this? Wouldn't it be nice to have a 4 way transmeta in a half U space?:)
First of all, there is a lot more that goes into this than what you might first see... I recommend you read some of these links to get a better sense for the interations that go on about the kernel:
For the last 4-5 years or so it has served as a nice repository for documentation on all aspects of OS design, and even hosts open hardware specs. In OS design circles it is pretty widely recommended. I look forward to being able to work with the OpenH people: we seem to overlap on a lot of our goals.
Anyways, I hope that this site is useful to our whole community!:) When the OpenH site is unslashdotted, I look forward to seeing what they have available!
For anyone interested, the enabling technology that makes this work is kORBit. The Corba ORB for the linux kernel (which was mentioned previously on slashdot).
I'd like to encourage people to think more along the lines of "what if" than the "that's ridiculous" attitude...:)
My problem with X isn't performance. Its performance is "good enough". That was precisely my point. Just speeding up something another.5% isn't really very interesting. Instead, lets work on something (berlin was an example), that is radically different and has implications that are farther reaching than "faster X".
Of course, right now I'm typing this in X, so obviously you can't get rid of all things. Like I said before, there is room for more than one technology in town.:)
I'm trying to point out that innovation in neccesary for Linux to not become stagnant. Just like you said, we don't want to copy windows. We want to take the small subset of GOOD ideas from windows and run with them.
I think that linux is doing an awesome job in the realm of simple web/dns/file servers... but that can also be done by a set top box. Lets try doing something interesting, and lets push the envelope a little bit.
A lot of very interesting projects get killed way before their time because they are preceived as being too slow. Hell, with an expodential increase in computing power, do we really need to care about each clock cycle anymore? Isn't it more useful to concentrate on getting INTERESTING things done pretty well, then something BORING done way too well?
Sure sure, you can optimize things all you want, and in many cases optimization is a very good thing. Optimization, however, is best done by computers: for example the compiler level, or done at a very high (Design) level by people. Microoptimizing every detail of a system is not only silly, but it is broken.
Scratching the itch is definately what drives the linux community, but it is also what holds it back in some way. Being driven to fix particular incarnations of problems in software is a wonderful way to limit your thinking to what is "inside of the box". We need people to think outside of "what is accepted" and we need people to listen to them when they do.
I know that I have some fairly excentric views here, but they should be voiced.
But you are missing one exceedingly important point:
Linux != UNIX
In so many ways, from the kernel not implementing all of POSIX (only the "nice" or "clean" stuff), to the user space apps having a distinctively different feel (than say Solaris), Linux is significantly different already.
Linux is different enough to break a lot of stuff that depends on system installs, and each distro is different enough to make packaging a bitch. It is not, however, different in the ways that are valuable. Linux distros are all just variations of a theme.
I hate to say it, but it seems like Darwin of all things is one of the most creative things in the "scene". Hurd is probably close, but it's doomed from the start by being associated with "microkernels" (see my comment about killing/hindering a project by ignoring it). Unfortunately for Hurd, for example, they will not have the neccesary developer base to get the ball rolling and self sustaining for a long time. By that time, Hurd may very well be obsolete.
So here is my battle cry: Lets try new, INTERESTING, things, and lets do them in the Linux context. Lets not break everything by changing something. Lets try providing extensions to Linux, and see how they work out. If they don't work out well (because they are inelegant, not because they are unused), then rip them out. If they work out well, keep them in, and start using them.
There are so many good projects laying around, that are predominately dormant, that would be interesting to pursue. A completely random example that just popped into my head is the ill fated (killed by the fbcon hack) GGI project. Another interesting project is Berlin (http://www.berlin-consortium.org?).
What would happen if these projects had a significant hacker base to draw from? GGI is much more powerful and interesting than fbcon, and we NEED something to take the baton from X.
Oh no, there is definately innovation. That's not the problem.
The problem is that the innovation never gets accepted by the community at large. These innovations may be seen as too "unlinux" or "ununix". Because of that, even though they are better ways of doing things.... they get ignored and eventually die out.
The only way to thoroughly kill an opensource project is to ignore it.
Most likely, the good points of the BeOS architecture would be incorporated into Linux... and some things in Linux would go into BeOS (do to released licensing pressure). This would be a very good thing for linux... but mostly on a usability side.
Unfortunately, a lot of the cool things that BeOS can do are because of the overall architecture. It is highly unlikely that the fundemental unix like architecture of linux will change. Instead, we will have to wait for a preemptible, pageable kernel to get developed. Then wait for filesystems to get far enough along to support "interesting" things.
Linux's main problem (which is also the source of much success...:) is that it doesn't make radical enough changes. Distributions are all so alike, that it's sickening. It would be much more interesting if they tried a fundementally different architecture. Perhaps apple's work could be just another "distro" of Linux (I know they aren't based on linux. The point being that they actually tried a different naming heirarchy... wow.;)
Anyways, one could claim that the Linux community is very good at cloning prior art, but not very receptive to radical developments of it's own.
Just wanted to clear up one thing here... the latency problems are not INTRINSIC to kORBIT, it's just a bug that hasn't been fixed yet. Latency should be much better than user space orbit eventually, because of reduced context switch overhead.:)
Hey all, here's a few responses to the feedback we've received so far, hopefully this will clear up some of the FUD:
NO, we do not expect this to go into any mainstream kernel any time soon.:)
YES, this is an awesome way to play with and prototype kernel functionality in user space.
NO, this does not work with other OS's. Although, there is no fundemental reason why it cannot be ported... again.
YES, this does mean that if it was ported to other OS's that you could trivially write portable drivers.
NO, we are not planning on porting GNOME to the kernel.:)
YES, SOME user space code can do good things in the kernel, particularly network-centric code. Think kHTTPd or kNFS.
NO, at least not without some redesign of GNOME, this will not make GNOME/bonobo faster.
YES, security can definately be improved [err, well, ahh, be implemented?;)]. We have one proposal from Miguel de Icaza on improving
the security to the point of NFS. Other schemes could definately be implemented, we just haven't started thinking about it.
NO, this does not "severely bloat your kernel", it adds about 150k of space when compiled in debug mode. This is still a very alpha version, btw, and there is still a lot to reduce out.
YES, you can now write your device drivers in C++.:)
Anyways, if you have any other questions, feel free to contact us.:)
If you want to learn more about what DjVu actually IS then don't bother reading the marketoid page. Look here. Specifically, on the what is DjVu? page, they say the following:
The commercialization of DjVu is handled by Seattle-based LizardTech Inc. in partnership with AT&T Labs. DjVu is an open standard. The file format specification, as well as an open source implementations of the decoder (and part of the encoder) are available.
Among other claims, they say "Black-and-white pages at 300 DPI typically occupy 5 to 30KB when compressed. "
I have long given up on slashdot reporting the whole truth and nothing but the truth...
"Does any of the money generated by the browser get back to Mozilla? I kinda doubt it."
Let me make a few observations here:
Mozilla is open source. If you would like to make a banner ad filled browser based off of mozilla, and you think people would use it, go ahead and do it.
Netscape is one of the biggest contributors to Mozilla. Every developer that they pay to work on the project costs them money. If nothing else, v6.1 will have more features and more banner ads, but a lot of the features will be funded by netscape (and mozilla will get them by default as well).
Don't forget that if you don't like banner ads and other cruft that netscape put in 6.0, go ahead and use one of the (very stable) recent nightly builds.
Open source/free software is about options, choices, and flexibility. If you aren't happy with netscapes one incarnation of what they did with mozilla, you can make your own.
I'm know I'll get mod'd down for saying this, but...
Whoever posted this must have been having and extremely bad day. Let's review the post (posters notes, not quotations from the article):
"It seems clear to me that Netscape cares a lot more about shopping tabs and similar deadwood": Err, excuze me? Isn't that netscape's primary goal? Bring value to its (aol's *shiver*) stockholders? Are you forgetting all of the good things that it has done? Are you forgetting just how good mozilla really is?
"that bring immediate profit to the Netscape Corporation but absolutely no value to the user": Again, I'm flabergasted. Perhaps slashdot has completely forgotten what that "mozilla" icon represents. Netscape 6 != Mozilla. Mozilla is open source, you can put anything you want into it and take anything away. Maybe "michael" should have a chat with RMS about free software...
"than they do about putting out a decent browser": >reinsert comment about how good mozilla is<
"Personally, I'd recommend beta-testing IE 6": Errm... who are you kidding bucko? Have you forgotten that slashdot is effectively a Linux fan site (not exclusively, but very few avid Windows fans read slashdot). Have you forgotten that IE6 doesn't run on anything except various flavors of windows (ok and mac, and *gag* solaris)...
"since IE not only has won the browser wars, it's clearly a better browser - and will remain so": Hrm... "won" the browser wars? On what platform? Windows? Is windows really the "browser war"? How many settop boxes do you expect to be running windows in the next couple of years? I thought so.
Hrm... perhaps someone ("michael") was:
Having a really bad day, or
Trying to not appear completely anti-microsoft or
Trying to get people riled up and pissed at Netscape, after constantly chastising Netscape for not releasing a product.
Personally I think that slashdot is having serious quality problems. Crap is getting posted all too often, and good stuff is getting refused. Articles like this don't even deserve the bytes they are printed on (err, what a sec here...:)
I remember a slashdot that was run by a single person, and that person ran a quality site. Back then the quality of the site was directly tied to his reputation... now however, things are seeming different.
This seems pretty strange to me, lets consider the situation that Intel is in:
Merced/Itanium has been delayed countless times.
Performance predictions (at least for the first generation or IA64) have been scaled back to the point that it appears that IA32 will be more performant in the same timespace
AMD is going forward with their own 64 bit chip, the sledgehammer. This has the advantage that it will (probably) have a much smaller die and use much less radical design techniques.
IA64 is so tied to compiler technology (that isn't good enough right now) that performance will be a huge problem at least for the near future.
IA64 is, in general, in a state of massive hemmorhaging. (as with most of Intel's near future plans, but that's another story)
Given all of this, I'm inclined to believe that their patents (which I'm sure they will get...:( aren't worth the paper they are printed on.
It seems that the only BAD thing is that Linus started us out on the 2.4.0testXXX series way too early. It got peoples hopes up even when the VM was horribly broken and many kernel features were broken...
I can only see this as a good thing, because when 2.4 hits the streets, it will be used by LOTS of people... and we want it to be as stable and reliable as ever...
Slashdot Mirror
-Chris
While it may be that the PowerVR2 did not implement it correctly, there is nothing that prevents alpha blending performance much better than immediate mode style rasterizers. Consider it this way:
A game needs to draw 5 opaque polygons, with 3 alpha polygons on top.
An immediate mode rasterizer would have to write all five polygons to memory, including all of the associated texture lookups and lighting calculations. Then, for each alpha polygon, it would have to reread bits from the framebuffer and combine it with the shaded textured alpha polygon. This is a lot of memory traffic.
A tile based renderer, otoh, would not need to do all of this. Obviously it would be able to eliminate all of the overdraw on the opaque polygons, but it would also be able to do the blending in the ON CHIP 24bit tile framebuffer, which is much much much faster than going to off chip memory. This means that instead of having to do read-modify-write off chip memory cycles for each of those alpha blended polygons, it stays on chip.
Now like I said before, I am not familiar with the PowerVR2 chip, and it may be that they do not implement this obvious optimization... I would assume their newer chip would.
My big question is "why not a T&L unit?" It seems like a sever handicap to an otherwise stellar chip. Although somewhat addressed in the article, they didn't really justify it well, and the benchmarks prove it would be handy. Maybe the 175mhz clock is what prevents an effective T&L unit from being added...
-Chris
While it may be that the PowerVR2 did not implement it correctly, there is nothing that prevents performance much better than immediate mode style rasterizers. Consider it this way:
A game needs to draw 5 opaque polygons, with 3 alpha polygons on top.
An immediate mode rasterizer would have to write all five polygons to memory, including all of the associated texture lookups and lighting calculations. Then, for each alpha polygon, it would have to reread bits from the framebuffer and combine it with the shaded textured alpha polygon. This is a lot of memory traffic.
A tile based renderer, otoh, would not need to do all of this. Obviously it would be able to eliminate all of the overdraw on the opaque polygons, but it would also be able to do the blending in the ON CHIP 24bit tile framebuffer, which is much much much faster than going to off chip memory. This means that instead of having to do read-modify-write off chip memory cycles for each of those alpha blended polygons, it stays on chip.
Now like I said before, I am not familiar with the PowerVR2 chip, and it may be that they do not implement this obvious optimization... I would assume their newer chip would.
My big question is "why not a T&L unit?" It seems like a sever handicap to an otherwise stellar chip. Although somewhat addressed in the article, they didn't really justify it well, and the benchmarks prove it would be handy. Maybe the 175mhz clock is what prevents an effective T&L unit from being added...
-Chris
I agree. I never understood why my grandma couldn't figure out how to just flip 32 switches into the right position and hit the "store" button like everyone else... I had to get rid of my poor PDP just 'cause she wanted something pointy and clicky...
*sniff*
-Chris
Those damn canadians stole our 5 billion dollar fireworks show that we have all been waiting for!
;)
Imagine a beowulf cluster of those things!
-Chris
"Today, product activation is a simple process that guarantees user privacy and curbs the negative impact of software piracy. Many users have seen the benefits of software activation, such as assurance that the product will include user manuals, product identifications, certificates of authenticity and complete software code. "
Hrm... those manuals sure are nice. I'm glad I registered my software... err.. yah. Also, don't you hate it when someone only burns you half of that office CD? Hrm...
-Chris
Has anyone else heard anything more about this, or has Transmeta stopped pushing this? Wouldn't it be nice to have a 4 way transmeta in a half U space? :)
-Chris
http://kt.linuxcare.com/kernel-traffic/kt20010108_ 101.epl#7, http://kt.linuxcare.com/kernel-traffic/kt20001127_ 95.epl#6
and especially: http://kt.linuxcare.com/kernel-traffic/kt20001002_ 87.epl#3, http://kt.linuxcare.com/kernel-traffic/kt20001010_ 88.epl#7.
Have a good read. KernelTraffic Rocks.
-Chris
http://www.nondot.org/~sabre/os/
For the last 4-5 years or so it has served as a nice repository for documentation on all aspects of OS design, and even hosts open hardware specs. In OS design circles it is pretty widely recommended. I look forward to being able to work with the OpenH people: we seem to overlap on a lot of our goals.
Anyways, I hope that this site is useful to our whole community! :) When the OpenH site is unslashdotted, I look forward to seeing what they have available!
-Chris
I'd like to encourage people to think more along the lines of "what if" than the "that's ridiculous" attitude... :)
-Chris
Heh....
Interesting. McNealy has always been known to be a "character".
I wouldn't say this is a sign of shifting attitudes. I would say this is McNealy's way of making a buck.
-Chris
My problem with X isn't performance. Its performance is "good enough". That was precisely my point. Just speeding up something another .5% isn't really very interesting. Instead, lets work on something (berlin was an example), that is radically different and has implications that are farther reaching than "faster X".
:)
Of course, right now I'm typing this in X, so obviously you can't get rid of all things. Like I said before, there is room for more than one technology in town.
-Chris
Okay, here's another example: http://korbit.sourceforge.net. (disclaimer, I'm a lead developer on the proj).
;)
I'm trying to point out that innovation in neccesary for Linux to not become stagnant. Just like you said, we don't want to copy windows. We want to take the small subset of GOOD ideas from windows and run with them.
I think that linux is doing an awesome job in the realm of simple web/dns/file servers... but that can also be done by a set top box. Lets try doing something interesting, and lets push the envelope a little bit.
A lot of very interesting projects get killed way before their time because they are preceived as being too slow. Hell, with an expodential increase in computing power, do we really need to care about each clock cycle anymore? Isn't it more useful to concentrate on getting INTERESTING things done pretty well, then something BORING done way too well?
Sure sure, you can optimize things all you want, and in many cases optimization is a very good thing. Optimization, however, is best done by computers: for example the compiler level, or done at a very high (Design) level by people. Microoptimizing every detail of a system is not only silly, but it is broken.
Scratching the itch is definately what drives the linux community, but it is also what holds it back in some way. Being driven to fix particular incarnations of problems in software is a wonderful way to limit your thinking to what is "inside of the box". We need people to think outside of "what is accepted" and we need people to listen to them when they do.
I know that I have some fairly excentric views here, but they should be voiced.
Maybe I'm just getting senile in my old age.
-Chris
http://www.nondot.org/~sabre
Of course not. Diversity was the whole point. :)
Linux needs to be stable. It needs to be big. It needs to be small.
It needs to be experimented with.
-Chris
True.
:)
But you are missing one exceedingly important point:
Linux != UNIX
In so many ways, from the kernel not implementing all of POSIX (only the "nice" or "clean" stuff), to the user space apps having a distinctively different feel (than say Solaris), Linux is significantly different already.
Linux is different enough to break a lot of stuff that depends on system installs, and each distro is different enough to make packaging a bitch. It is not, however, different in the ways that are valuable. Linux distros are all just variations of a theme.
I hate to say it, but it seems like Darwin of all things is one of the most creative things in the "scene". Hurd is probably close, but it's doomed from the start by being associated with "microkernels" (see my comment about killing/hindering a project by ignoring it). Unfortunately for Hurd, for example, they will not have the neccesary developer base to get the ball rolling and self sustaining for a long time. By that time, Hurd may very well be obsolete.
So here is my battle cry: Lets try new, INTERESTING, things, and lets do them in the Linux context. Lets not break everything by changing something. Lets try providing extensions to Linux, and see how they work out. If they don't work out well (because they are inelegant, not because they are unused), then rip them out. If they work out well, keep them in, and start using them.
There are so many good projects laying around, that are predominately dormant, that would be interesting to pursue. A completely random example that just popped into my head is the ill fated (killed by the fbcon hack) GGI project. Another interesting project is Berlin (http://www.berlin-consortium.org?).
What would happen if these projects had a significant hacker base to draw from? GGI is much more powerful and interesting than fbcon, and we NEED something to take the baton from X.
Anyways, enuf ranting.
-Chris
Oh no, there is definately innovation. That's not the problem.
The problem is that the innovation never gets accepted by the community at large. These innovations may be seen as too "unlinux" or "ununix". Because of that, even though they are better ways of doing things.... they get ignored and eventually die out.
The only way to thoroughly kill an opensource project is to ignore it.
-Chris
Most likely, the good points of the BeOS architecture would be incorporated into Linux... and some things in Linux would go into BeOS (do to released licensing pressure). This would be a very good thing for linux... but mostly on a usability side.
:) is that it doesn't make radical enough changes. Distributions are all so alike, that it's sickening. It would be much more interesting if they tried a fundementally different architecture. Perhaps apple's work could be just another "distro" of Linux (I know they aren't based on linux. The point being that they actually tried a different naming heirarchy... wow. ;)
Unfortunately, a lot of the cool things that BeOS can do are because of the overall architecture. It is highly unlikely that the fundemental unix like architecture of linux will change. Instead, we will have to wait for a preemptible, pageable kernel to get developed. Then wait for filesystems to get far enough along to support "interesting" things.
Linux's main problem (which is also the source of much success...
Anyways, one could claim that the Linux community is very good at cloning prior art, but not very receptive to radical developments of it's own.
-Chris
-Chris
- NO, we do not expect this to go into any mainstream kernel any time soon.
:)
- YES, this is an awesome way to play with and prototype kernel functionality in user space.
- NO, this does not work with other OS's. Although, there is no fundemental reason why it cannot be ported... again.
- YES, this does mean that if it was ported to other OS's that you could trivially write portable drivers.
- NO, we are not planning on porting GNOME to the kernel.
:)
- YES, SOME user space code can do good things in the kernel, particularly network-centric code. Think kHTTPd or kNFS.
- NO, at least not without some redesign of GNOME, this will not make GNOME/bonobo faster.
- YES, security can definately be improved [err, well, ahh, be implemented?
;)]. We have one proposal from Miguel de Icaza on improving
the security to the point of NFS. Other schemes could definately be implemented, we just haven't started thinking about it.
- NO, this does not "severely bloat your kernel", it adds about 150k of space when compiled in debug mode. This is still a very alpha version, btw, and there is still a lot to reduce out.
- YES, you can now write your device drivers in C++.
:)
Anyways, if you have any other questions, feel free to contact us.-Chris
I have long given up on slashdot reporting the whole truth and nothing but the truth...
-Chris
Let me make a few observations here:
Mozilla is open source. If you would like to make a banner ad filled browser based off of mozilla, and you think people would use it, go ahead and do it.
Netscape is one of the biggest contributors to Mozilla. Every developer that they pay to work on the project costs them money. If nothing else, v6.1 will have more features and more banner ads, but a lot of the features will be funded by netscape (and mozilla will get them by default as well).
Don't forget that if you don't like banner ads and other cruft that netscape put in 6.0, go ahead and use one of the (very stable) recent nightly builds.
Open source/free software is about options, choices, and flexibility. If you aren't happy with netscapes one incarnation of what they did with mozilla, you can make your own.
Stop whining and do something about it.
-Chris
I'm know I'll get mod'd down for saying this, but...
Whoever posted this must have been having and extremely bad day. Let's review the post (posters notes, not quotations from the article):
Hrm... perhaps someone ("michael") was:
Personally I think that slashdot is having serious quality problems. Crap is getting posted all too often, and good stuff is getting refused. Articles like this don't even deserve the bytes they are printed on (err, what a sec here...
I remember a slashdot that was run by a single person, and that person ran a quality site. Back then the quality of the site was directly tied to his reputation... now however, things are seeming different.
-Chris
- Merced/Itanium has been delayed countless times.
- Performance predictions (at least for the first generation or IA64) have been scaled back to the point that it appears that IA32 will be more performant in the same timespace
- AMD is going forward with their own 64 bit chip, the sledgehammer. This has the advantage that it will (probably) have a much smaller die and use much less radical design techniques.
- IA64 is so tied to compiler technology (that isn't good enough right now) that performance will be a huge problem at least for the near future.
- IA64 is, in general, in a state of massive hemmorhaging. (as with most of Intel's near future plans, but that's another story)
Given all of this, I'm inclined to believe that their patents (which I'm sure they will get..."Bring it on Intel"
-Chris
It seems that the only BAD thing is that Linus started us out on the 2.4.0testXXX series way too early. It got peoples hopes up even when the VM was horribly broken and many kernel features were broken...
I can only see this as a good thing, because when 2.4 hits the streets, it will be used by LOTS of people... and we want it to be as stable and reliable as ever...
right?
-Chris
It talks about different OS interfaces, and has a very thorough section on filesystems available under linux, including several other JFS's...
-Chris