I find it interesting to note the number of things Loki has released to the community. Sure, they may be sell closed source products, but they've contributed several things under the LGPL (their installer, their smpeg library) as well as contributing to the SDL project (a video/audio library which they use in their products). Even though I don't like the idea of this installer, it's cool that they released it. I think Loki sets a great example for how a company can sell closed-source products in (and even contribute to) a free software world.
This is interesting, this group had a chip called the Pyramid3D a few years ago that never made it onto the market because its performance wasn't competative (although it did have a few neat features like antialiasing). Anyway, they say it won't be shipping until the first half of 2000, which could mean at least 6 months from now and likely more, and by then the performance their claimed 3x current performance may not seem as great, as TNT3 and who knows what else will be out before then. It could be another case of too little, too late.
Interestingly, they are using embedded DRAM, the same technology Rendition is supposedly using in their next-generation chip (if they ever release one).
Anyway, it looks like a cool chip, provided it has a robust OpenGL implementation for X.
We already can do this. There are programs that let you change the EPA logo the BIOS normally displays to something else. My system displays an "Evil Inside" logo when it boots, mocking Intel. It's cool.
Re:Top X "Digital" Shows on PBS This Fall
on
PBS Goes Digital
·
· Score: 1
>2) Digital Red Dwarf: After being frozen in space >for three million years, David Lister wakes up to >find that Holly's Intel chip has corrupted, >leaving it with an IQ of 60.
That's okay, they can just overclock Holly and fix everything back up! They actually did that in an episode, funny. Increased intelligence, decreased lifespan.
Other that X's occasionally shitty video performance (at least on my machine), I see no reason my Linux couldn't do this. Copying from a CD takes very little CPU, neither does playing an mp3, so as long as xanim can keep up you should be good to go.
ICD stands for Installable Client Driver. Basically, Microsoft's opengl32.dll provides a full software path and is what all apps are linked against, but if an ICD is installed the MS dll switches over to the ICD, which provides accelerated rendering for whatever chipset you have installed.
People emphasize ICD because there is also such a thing as an MCD (mini-client driver, I think), which is much easier to write than an ICD since it plugs into an existing framework rather than having to handle the entire OpenGL pipeline itself. These are only available on NT, and MS doesn't seem to support them any more, presumably because they wanted to see GL die a quick death. Since they don't work on 95/98, they aren't really an option for IHVs anymore.
A little less than a year ago I was working in Borland C++ 5 on a 486DX2/66 with 40 megs of ram and Win95 doing OpenGL graphics... of course that was only hobbyist work. If you go back another year, I was using basically the same software, but with only 12 megs of ram. It took 30+ seconds to compile and link *anything*. Ugh.
Interestingly, on the same hardware (486/66 12MB ram), Borland C++ 4.0 was very fast.
This is cool. What's really neat about it is that you could even use it to enter characters on a normal 8-direction gamepad - much better than one of those horrible onscreen keyboards. I have an 8- direction pad-button-scroller-thingy on my mouse, but have no clue how to make it work in Linux (maybe I should write a driver for it) - this would be a good use for it .
This really makes me wish I could afford a PalmPilot.
WORLOK: You are a disturbed person. You should probably seek profession help (better yet, kill yourself, please). Such a lack of respect for individual freedom and your fellow human beings is absolutely disgusting. It's a shame you were born into this world, I'm sure you would be much happier living in a totalitarian regime such as that of Hitler.
Really, the bandwidth would be the rate you could transport at if you had a continuous stream of trucks unloading, which would be MUCH higher.
Interestingly, the time it takes to load/unload the truck would have an impact on both bandwidth and latency, which is a different case than with computers - it doesn't take hardly any time for the kernel to ready a packet, so it can send a practically unlimited number of them (enough to saturate the network), and this time has no significant impact on latency. In this case, if it takes an hour to load/unload 50,000 tapes, the delay will add 2 hours latency (constituting 10% of the total latency). The bandwidth will be limited because you will only be able to send a maxiumum of 1 truck per hour - making the peak bandwidth 8x what you predicted. Or, if it took no time to load/unload the tapes, the bandwidth would instead be limited by the number of trucks you could cram on the road (A LOT), kind of like packets on a slow modem.
Well, I thought that was interesting, at least. =)
I think your comparison of Glide vs. DirectX (or Direct3D) is a little unfair. Think about the ioctl's. In comparison to them, glide and DirectX both appear "thick", since they are higher level APIs that talk to the hardware driver itself. I think that's what is really important in defining something as "thick" as opposed to "thin" - where the interface is implemented, rather than what it represents. DirectX may abstract the hardward while Glide better represents the hardware architecture, but they are both higher level, programmer-oriented interfaces. You'd never see the Glide interface implemented in the kernel as sys-calls, which is the point Linus is trying to make.
Slashdot Mirror
I find it interesting to note the number of things Loki has released to the community. Sure, they may be sell closed source products, but they've contributed several things under the LGPL (their installer, their smpeg library) as well as contributing to the SDL project (a video/audio library which they use in their products). Even though I don't like the idea of this installer, it's cool that they released it. I think Loki sets a great example for how a company can sell closed-source products in (and even contribute to) a free software world.
>dude. shut the hell up until you have something
>intelligent to say rather than posting 20 some
>responses to an article.
Yeah, seriously. If I have to read this guy's !$%#!%$ stupid sig one more time I'm going to throw up.
This is interesting, this group had a chip called the Pyramid3D a few years ago that never made it onto the market because its performance wasn't competative (although it did have a few neat features like antialiasing). Anyway, they say it won't be shipping until the first half of 2000, which could mean at least 6 months from now and likely more, and by then the performance their claimed 3x current performance may not seem as great, as TNT3 and who knows what else will be out before then. It could be another case of too little, too late.
Interestingly, they are using embedded DRAM, the same technology Rendition is supposedly using in their next-generation chip (if they ever release one).
Anyway, it looks like a cool chip, provided it has a robust OpenGL implementation for X.
I always thought MMCs were the mapper chips that NES cartridges used to bank-select their memory. =)
We already can do this. There are programs that let you change the EPA logo the BIOS normally displays to something else. My system displays an "Evil Inside" logo when it boots, mocking Intel. It's cool.
>2) Digital Red Dwarf: After being frozen in space
>for three million years, David Lister wakes up to
>find that Holly's Intel chip has corrupted,
>leaving it with an IQ of 60.
That's okay, they can just overclock Holly and fix everything back up! They actually did that in an episode, funny. Increased intelligence, decreased lifespan.
No no, that's niggas', not "niggers". Theres an important difference.
Other that X's occasionally shitty video performance (at least on my machine), I see no reason my Linux couldn't do this. Copying from a CD takes very little CPU, neither does playing an mp3, so as long as xanim can keep up you should be good to go.
ICD stands for Installable Client Driver. Basically, Microsoft's opengl32.dll provides a full software path and is what all apps are linked against, but if an ICD is installed the MS dll switches over to the ICD, which provides accelerated rendering for whatever chipset you have installed.
People emphasize ICD because there is also such a thing as an MCD (mini-client driver, I think), which is much easier to write than an ICD since it plugs into an existing framework rather than having to handle the entire OpenGL pipeline itself. These are only available on NT, and MS doesn't seem to support them any more, presumably because they wanted to see GL die a quick death. Since they don't work on 95/98, they aren't really an option for IHVs anymore.
A little less than a year ago I was working in Borland C++ 5 on a 486DX2/66 with 40 megs of ram and Win95 doing OpenGL graphics... of course that was only hobbyist work. If you go back another year, I was using basically the same software, but with only 12 megs of ram. It took 30+ seconds to compile and link *anything*. Ugh.
Interestingly, on the same hardware (486/66 12MB ram), Borland C++ 4.0 was very fast.
This is cool. What's really neat about it is that you could even use it to enter characters on a normal 8-direction gamepad - much better than one of those horrible onscreen keyboards. I have an 8- direction pad-button-scroller-thingy on my mouse, but have no clue how to make it work in Linux (maybe I should write a driver for it) - this would be a good use for it .
This really makes me wish I could afford a PalmPilot.
WORLOK:
You are a disturbed person. You should probably seek profession help (better yet, kill yourself, please). Such a lack of respect for individual freedom and your fellow human beings is absolutely disgusting. It's a shame you were born into this world, I'm sure you would be much happier living in a totalitarian regime such as that of Hitler.
No no no, it's Gnome, KDE, CDE, UDE, and GNUstep. And probably a few more.
No no no, it's Gnome, KDE, CDE, UDE, and GNUstep. And probably more.
As much as I love Linux, I guess I'll have to play this game under Win95, unless NVidia ever releases an accelerated OpenGL for Linux.
Still, I plan on buying the Linux boxed version and simply downloading the Win32 EXEs from the net. Anyone else planning to do the same?
Really, the bandwidth would be the rate you could transport at if you had a continuous stream of trucks unloading, which would be MUCH higher.
Interestingly, the time it takes to load/unload the truck would have an impact on both bandwidth and latency, which is a different case than with computers - it doesn't take hardly any time for the kernel to ready a packet, so it can send a practically unlimited number of them (enough to saturate the network), and this time has no significant impact on latency. In this case, if it takes an hour to load/unload 50,000 tapes, the delay will add 2 hours latency (constituting 10% of the total latency). The bandwidth will be limited because you will only be able to send a maxiumum of 1 truck per hour - making the peak bandwidth 8x what you predicted. Or, if it took no time to load/unload the tapes, the bandwidth would instead be limited by the number of trucks you could cram on the road (A LOT), kind of like packets on a slow modem.
Well, I thought that was interesting, at least. =)
I think your comparison of Glide vs. DirectX (or Direct3D) is a little unfair. Think about the ioctl's. In comparison to them, glide and DirectX both appear "thick", since they are higher level APIs that talk to the hardware driver itself. I think that's what is really important in defining something as "thick" as opposed to "thin" - where the interface is implemented, rather than what it represents. DirectX may abstract the hardward while Glide better represents the hardware architecture, but they are both higher level, programmer-oriented interfaces. You'd never see the Glide interface implemented in the kernel as sys-calls, which is the point Linus is trying to make.
Great article. =)