But not a omment on the release...
on
KDE Strikes Back
·
· Score: 1
It's really sad that a beta preview release announcement on Slashdot has not one comment that I could find about anyone's impression on the usability of the code. Every single comment is about the Gnome/KDE holy war. A dark portend for the Open Source community, we are more interested in bickering about trivialities than how anything benefits the end user.
Yes, the later Alliant systems (FX2800) were also based off of this chip. They were extremely fast, but nearly imp[ossible to write good compilers for. The instruction pipeline had a push architecture, whereby you had to actually feed an instruction in to get one out. It was very hard to keep the pipeline fed and thus very hard to realize maximum performance IIRC. I thought that SGI may have also used them in some of the original Reality Engine graphics as the geometry processor, possibly because you could keep the pipe fed with matrice operations if you handcoded it right, but I'm really vague on that one....
I did some Inventor programming at SGI under version 1.0 before GL was Open GL. In simplest terms, it is a higher level toolkit that abstracts away vertices, viewing transforms, etc much in the same way GTK and Qt abstarct away underlying X11 Intrinsics. It is very useful for rapid prototyping. You could very easily build a viewer to look at your data becuse it had simple means for inserting your data in a scene graph and then attaching a viewer to it. It took no time at all, very quick and easy. The viewer object had UI controls for pan, rotate, zoom allowing the programmer to concentrate more on their data or their app than dealing with mundane issues of how
do picking and rotate handles. It was also built with the intention of providing the fastest possible path through GL. It would use triangle strips where it could, try not to use modes that were slow, etc. The.iv formta was a great way to portablely store geometry data as well and proved to be the basis of VRML. The toolkit was also extensible, you could subclass and create new geometry types, new viewers and controls as needed.
On the down side, it tried to be all things to all people so it was (at the 1.0 level anyway) very large. It had a huge number of methods and a gigantic symbol table (link times were a little slow.) Also, because it implemented a scene graph to enable fast drawing and abstracting the data rep away from you, it often meant that you ended up with 2 copies of our scene data unless you built the app to use Inventor specifically from the begining. i.e. I was asked to attach an Inventor viewer to an existing app. I would have to take the data structures from that app and pass them into Inventor's Scene Graph via the Inventor api, where this data was duplicated in Inventor's internal data structures. Even freeing the external apps data rep meant that the memory was still around, just ready to be used for the next malloc, which either lead to fragmentation of high memory use.
All of these observations are based off of 1.0, not sure what it looks like now. I'd use it again, but if I were building an app aroudnd it, I'd make sure that I designed the data structures to mesh with Inventor well.
By what measure is it "inferior"? I admittedly have not done much GTK programming, though I have done some Qt. I am not a C++ purist, actually it frustrates me from a bloat/startup efficiency standpoint because it can encourage creation of "elegant" but fat, slow code. But that is another discourse. GTK on my older Aptiva 166 is noticably slower than Qt, I can watch the menus draw in GTK, they are instant in Qt. On my 333, there is still a percievable difference. From a users point of view, relative speed, how snappy a toolkit feels, would seem to dictate which toolkit is better. Qt wins this hands down. And this doesn't even address themes, I was refering to unthemed GTK in my example. QT seems to suffer little to no performance degradation from themes, pixmaped or otherwise.
From a programming point of view, "inferiority" becomes harder to decide. Which toolkit allows you to develop faster? Which allows you to re-use more code? Which is more human readable? Debuggable? Stable? A lot of these depend upon the person coding, some people prefer C, others C++. The greatest division among which is inferior probably falls into these subjective lines.
Lastly, it seems (especially in Linux Land) a lot of people lable something "inferior" when they don't like the license. Too many people are willing to forgo a better technology because it doesn't have their favorite license pasted all over it. This is just plain silly and juvenile. If the code is good, it is open, people can see it, use it and modify it, there is not reason to go with lesser technology because someone prefers a different license. It's like Beta vs. VHS or IBM/DOS vs. Apple all over again.
Alright, here I go starting the holy toolkit wars. Does anyone know which toolkit they will be using on Linux? I believe they use SGI look and feel Motif on IRIX, I wonder if this means they will be using Motif on Linux (I sure hope not, it would look ugly.) Or are they using GTK or QT? Would be nice if it integrated with the Desktop Environments. Just wondering if anyone is in the know.
Sgi started with a GL (the thing that came before OpenGL for those of you too young to remember) based windowing environment called Mex. I don't have any idea what it stood for, but it was in existence around 1987 on their 3130 series of workstations. About that time Sun had their Postscript based NeWS (NEtwok Windowing System) out and Sgi later switched to this model. I can't remember the exact date, but I think they switched around 1988. NeWS was starting to see some acceptance in the minsupercpmputer market as Alliant Computer Systems used it in a distributed model to talk to sun workstations and later as the basis for their Raster technolgies based graphics subsytem. Competing windows systems from Apollo, Intergraph, and DEC (as seen on the microVax workstations) also existed, but remained proprietary and not network transparent as X and NeWS were. Sgi's NeWS server also incorporated an X11 interpretter which allowed it to accept X11 connections, although the performance was less than stellar. Around 1991, Sgi switched entirely to X11 and added dgl (distributed GL) to the mix allowing GL to run over the network in a similar way that X11 did. The dates are best guesses for memory, so I may be off a bit.
I've got GTK and QT on a 166Mhz Pentium. GTK has no theme on it and I can still watch it draw the menus in slow motion. Qt on the other hand is quite fast and responsive by comparison. I wouldn't have too much against GTK, but the speed and lack of double buffering are a huge drawback.
Has anyone been able to get this to install via FTP or NFS after booting from a floppy? It was never able to conect to a server for me. I was able to do this under 6, but no more. I don't have a CD burner so I am bumming a bit...
Slashdot Mirror
It's really sad that a beta preview release announcement on Slashdot has not one comment that I could find about anyone's impression on the usability of the code. Every single comment is about the Gnome/KDE holy war. A dark portend for the Open Source community, we are more interested in bickering about trivialities than how anything benefits the end user.
Sad.
Yes, the later Alliant systems (FX2800) were also based off of this chip. They were extremely fast, but nearly imp[ossible to write good compilers for. The instruction pipeline had a push architecture, whereby you had to actually feed an instruction in to get one out. It was very hard to keep the pipeline fed and thus very hard to realize maximum performance IIRC. I thought that SGI may have also used them in some of the original Reality Engine graphics as the geometry processor, possibly because you could keep the pipe fed with matrice operations if you handcoded it right, but I'm really vague on that one....
On the down side, it tried to be all things to all people so it was (at the 1.0 level anyway) very large. It had a huge number of methods and a gigantic symbol table (link times were a little slow.) Also, because it implemented a scene graph to enable fast drawing and abstracting the data rep away from you, it often meant that you ended up with 2 copies of our scene data unless you built the app to use Inventor specifically from the begining. i.e. I was asked to attach an Inventor viewer to an existing app. I would have to take the data structures from that app and pass them into Inventor's Scene Graph via the Inventor api, where this data was duplicated in Inventor's internal data structures. Even freeing the external apps data rep meant that the memory was still around, just ready to be used for the next malloc, which either lead to fragmentation of high memory use.
All of these observations are based off of 1.0, not sure what it looks like now. I'd use it again, but if I were building an app aroudnd it, I'd make sure that I designed the data structures to mesh with Inventor well.
By what measure is it "inferior"? I admittedly have not done much GTK programming, though I have done some Qt. I am not a C++ purist, actually it frustrates me from a bloat/startup efficiency standpoint because it can encourage creation of "elegant" but fat, slow code. But that is another discourse. GTK on my older Aptiva 166 is noticably slower than Qt, I can watch the menus draw in GTK, they are instant in Qt. On my 333, there is still a percievable difference. From a users point of view, relative speed, how snappy a toolkit feels, would seem to dictate which toolkit is better. Qt wins this hands down. And this doesn't even address themes, I was refering to unthemed GTK in my example. QT seems to suffer little to no performance degradation from themes, pixmaped or otherwise.
From a programming point of view, "inferiority" becomes harder to decide. Which toolkit allows you to develop faster? Which allows you to re-use more code? Which is more human readable? Debuggable? Stable? A lot of these depend upon the person coding, some people prefer C, others C++. The greatest division among which is inferior probably falls into these subjective lines.
Lastly, it seems (especially in Linux Land) a lot of people lable something "inferior" when they don't like the license. Too many people are willing to forgo a better technology because it doesn't have their favorite license pasted all over it. This is just plain silly and juvenile. If the code is good, it is open, people can see it, use it and modify it, there is not reason to go with lesser technology because someone prefers a different license. It's like Beta vs. VHS or IBM/DOS vs. Apple all over again.
Alright, here I go starting the holy toolkit wars. Does anyone know which toolkit they will be using on Linux? I believe they use SGI look and feel Motif on IRIX, I wonder if this means they will be using Motif on Linux (I sure hope not, it would look ugly.) Or are they using GTK or QT? Would be nice if it integrated with the Desktop Environments. Just wondering if anyone is in the know.
Wow, this sure dates the age of the average Slashdot reader. No knowledge of Core Memory, Cray SSD drives...
I feel old.
Sgi started with a GL (the thing that came before OpenGL for those of you too young to remember) based windowing environment called Mex. I don't have any idea what it stood for, but it was in existence around 1987 on their 3130 series of workstations. About that time Sun had their Postscript based NeWS (NEtwok Windowing System) out and Sgi later switched to this model. I can't remember the exact date, but I think they switched around 1988. NeWS was starting to see some acceptance in the minsupercpmputer market as Alliant Computer Systems used it in a distributed model to talk to sun workstations and later as the basis for their Raster technolgies based graphics subsytem. Competing windows systems from Apollo, Intergraph, and DEC (as seen on the microVax workstations) also existed, but remained proprietary and not network transparent as X and NeWS were. Sgi's NeWS server also incorporated an X11 interpretter which allowed it to accept X11 connections, although the performance was less than stellar. Around 1991, Sgi switched entirely to X11 and added dgl (distributed GL) to the mix allowing GL to run over the network in a similar way that X11 did. The dates are best guesses for memory, so I may be off a bit.
I've got GTK and QT on a 166Mhz Pentium. GTK
has no theme on it and I can still watch it draw
the menus in slow motion. Qt on the other hand
is quite fast and responsive by comparison.
I wouldn't have too much against GTK, but the
speed and lack of double buffering are a huge
drawback.
Has anyone been able to get this to install via
FTP or NFS after booting from a floppy? It was never able to conect to a server for me. I was able to do this under 6, but no more. I don't
have a CD burner so I am bumming a bit...