Re:Clever move, but late
on
Palm OS Spinoff
·
· Score: 3, Insightful
Give the handheld a VGA output port and good headphones (maybe even Bluetooth) and all of a sudden PowerPoint and MP3 on a handheld are very attractive to a lot of people.
KDE/Qt Embedded won't fly on Linux handhelds
on
Palm OS Spinoff
·
· Score: 2
The main reason people give for running Qt/Embedded is that it supposedly uses less memory and is faster than X11 on small machines. From the published claims for Qt/Embedded, as well as experience with existing X11 installations on handhelds, this does not seem to be the case. And if X11 can run on a 66MHz/8Mbyte handheld like the AgendaVR, it will be downright fast running on the 200MHz+ ARM chip (faster than many desktop machines just a couple of years ago).
Running Qt/Embedded has all sorts of disadvantages, however:
You can't use X11 remote display for development on/for the handheld anymore. I have done development on Linux handhelds, and this is extremely useful in both directions.
You can't share the handheld screen between applications written in different toolkits anymore.
You are tied to a single toolkit for handheld development.
There are two predominant environments for writing GUI apps on Linux handhelds: FLTK and Java, both using X11 as the display server. I doubt anything else is going to catch on widely.
I'm not sure why you think gcj (now just the Java mdoe of gcc 3.x) is a "crutch".
What I mean is that gcj and other ahead-of-time compilers allow people to continue writing Java code as if they were writing C/C++ code: small, standalone, native-code applications that are composed of a mostly static codebase. In order to achieve that, they sacrifice many of the properties that make Java interesting in the first place.
If you take a single-process, dynamic-compilation approach, Java really shines: you can combine lots of software components at runtime, and the dynamic compiler will optimize and inline everything at runtime. That's not theoretical, it really works. If you keep a single Java process running (rather than starting things up again and again), javac, jedit, and other substantial Java programs are lightning fast.
I agree that gcj is very worthwhile, and I hope its development will continue. Many people (myself included) still want to write small, stand-alone applications some of the time, and being able to use Java is nice for that. Gcj's easy connection with C++ also is a great link to existing codebases.
Nevertheless, for developing a modern desktop, I think the dynamic compilation approach is a much better way to go than ahead-of-time compilation.
I think Java-based desktop should only use a single VM process to do everything that Gnome (minus major applications) does out of the box. The one-process-per-function approach is a holdover from C/C++ days, where you need separate processes to keep components from crashing each other and to make sure memory gets cleaned up. The single VM approach also makes it much, much easier to communicate among different components.
I do agree, however, that a sharable VM and sharable JIT results would be good. Using Java for a Sun-sponsored desktop project would also help improve Swing and any remaining performance bottlenecks.
I think something like gcj is a crutch. It would let you write C/C++-style applications in Java, maybe even using Gtk+. That's better than nothing, and would allow for a smooth transition from something like Gnome to Java, but I think it also means giving up on some of the major advantages of Java.
The volume control wouldn't be 40MB, it would be a few kbytes running inside the same process as most of the other desktop threads. To enable this kind of sharing is why the Java runtime is as big as it is in the first place, and you only see benefits from it if you take advantage of it.
If you go with gcj and separate processes, you lose most of the advantages of Java over C++ (although you still get something that's easier to learn and a bit more robust).
about 30 years behind the times
on
Autonomic Computing
·
· Score: 3, Interesting
Biological metaphors like that were the inspiration and motivation behind Smalltalk and similar systems (read the original papers). It didn't work out that way.
Homeostatsis and self-regulation are not properties that you implement once in some abstract data type and that henceforth works for everything, or that require breakthrough new technology, they are design goals that you need to take into account when you design each and every part of a system. Biological organisms have been forced from day one to deal with these issues. The reason real software systems don't do this is not that people don't know how to, it's that software developers don't bother and aren't trained to do it, and that they can get away with it because there are always smart humans around to help it.
So, next time you write a new piece of software, think about how you can make it more self adapting and less reliant on numerous environment variables and other arguments supplied by the user. The pathsearch library is a simple example of this.
Re:Sun, why not KDE, for the last time?
on
No GNOME For Solaris 9
·
· Score: 4, Insightful
If Sun adopted KDE/Qt, they'd let another company set the cost for any commercial GUI development on Solaris that integrates with the standard desktop. The cost would instantly be much higher than it is now, it would be much higher than competing platforms, and there is no guarantee that it wouldn't go up even further since Sun has no control over TrollTech's pricing or development direction.
GNOME is based on the GTK+ library, which was fine for its day, but is now decidedly outdated.
Yes, and you can say roughly the same thing about KDE/Qt. Sun already has better technology than either Gtk+ or Qt. It's called Java. They should use it and deploy it. The reason they don't is the same bogus internal politics that killed Smalltalk, NeWS, and OpenStep on Solaris.
Sun already has a mature, powerful toolkit and component architecture in Java. Sun should put their money where their mouth is and sponsor the open source development of a desktop environment based on Java.
Unfortunately, Sun's OS group seems blissfully disconnected from their Java side; in fact, their OS group seems stuck in the C-mindset of the traditional BSD/UNIX world. And Sun's Java group seems more focussed on Windows than on adding value to Sun's own product line. Sun's lack of coordination and their lack of in-house and open source application development in Java gives people the impression that Java isn't ready. That may have been true two years ago, but today, Java is more than up to the task of building a zippy desktop with a footprint smaller than either Gnome or KDE.
Of course, Sun can't give up completely on C/C++ toolkits, but they have that pretty well covered with Motif and its C++ wrappers, tools that are still much more widely used among Sun's customers than either Gtk+ or Qt.
Sun always seemed like Sun's worst enemy. They need a little of that Gates/Ballmer top-down coherent management and energy. McNealy barks a lot, but he doesn't seem to bite much.
That would make no commercial sense for Sun.
on
No GNOME For Solaris 9
·
· Score: 4, Insightful
If Sun shipped KDE, they'd be shipping a desktop based on a toolkit that another company has complete commercial control over. Anybody who wants to write commercial software for Sun and fit in with the "standard" desktop would have to pay thousands of dollars to Troll Tech. And if TrollTech wanted to, they could jack up their commercial license fees for Solaris to whatever limit the market will bear. It just doesn't make sense for Sun to place the keys and toll-gate for commercial desktop application development on their platform in the hands of some company they have no control over.
Sun would have to get a transferable binary license for Qt on Solaris, but even then, they'd be the only UNIX vendor standardizing on Qt.
Or, Sun would have to buy TrollTech outright, likely to be an expensive proposition.
Sticking with Motif makes sense: it's very widely used commercially (far more than Qt), there are lots of widgets and tools for it, it is a de-facto standard, and Sun already has rights to it. There are also several C++-based APIs for Motif. (Technically, I think Qt and Motif is a toss-up, but that's another matter.)
If you have an image and you store the encrypted message in the low order bits of the image then they will look too random when compared to typical images.
Yes, that is right. However, that is not the correct way of hiding information in images. What you should rather do is match the distribution of the encrypted data to the noise characteristics of a known, plausible source (e.g., a CCD camera). Alternatively, you just make sure that you encode at a bit rate that is low enough not to change the noise characteristics of the image detectably. Either is easy to do.
Re:sorry, but you don't even get the issues
on
Five Years of KDE
·
· Score: 2
Well, duh, and every time a thread on KDE comes up, people tell us how wonderful it is, how great it is that it is free, and how we should all be using it.
As for C++, which part of my actual argument in the post you replied to don't you understand or disagree with?
Re:sorry, but you don't even get the issues
on
Five Years of KDE
·
· Score: 2
Why don't you tell us what language you would use??? Remember by your own arguments it must be as efficient as C and all the runtime facillities of Java. Good Luck!
Actually, in order to be efficient for programming in the large, efficiency for programming in the small doesn't matter that much, since you can still write tight inner loops in C if it is advantageous to do so.
There are lots of possibilities for languages and runtimes: Java, C#, Eiffel, Oberon, Modula-3, ObjectPascal, even Scheme and OCAML.
Indeed, both the software and hardware on PalmOS are old. And their handhelds are way overpriced for what you get in terms of hardware. But they do what they were designed to, and they do it well. Furthermore, there is a lot of software available for them, both on the device itself and on the desktop. You can develop for PalmOS on different platforms, and all PalmOS data can be accessed from any platform.
What's the alternative? Microsoft's handheld platforms are nowhere near as usable, mature, or efficient as PalmOS. But unlike Palm, the Microsoft handheld platforms also really don't want to talk to anything other than Windows, and you can't develop for them on anything other than Windows.
As far as I'm concerned, PalmOS is still the best game in town for handhelds and phones. Maybe some of the Linux-based devices will make it out the door at some point. Maybe Palm will come out with a decent, modern 32bit OS soon. But I doubt Microsoft ever gets a clue and starts untying their different systems from one another or starts using open, well-documented ways of storing data; and until they do, I think it's foolish to put your data on their devices.
This Samsung phone looks more practical to me in the short term: Palm interface and PalmOS, color, and dual-band. Yes, I wouldn't mind having the keyboard and GPRS of the Treo, but who knows when the Treo will actually be shipping, what the service availability and coverage will be, what kind of surchages they will add, etc.
sorry, but you don't even get the issues
on
Five Years of KDE
·
· Score: 2
Your views of C++ are very misguided. The original implementations of C++ were quite slow, but this is no longer the case. Ten years of development have occurred since you last heard about C++ performance. C++ is now much better for a project such as this (but without exceptions, of course). It makes the code much more maintainable, smaller in size, more modular, and easier to understand and debug.
C++ is very efficient and expressive for "programming in the small": for writing tight inner loops, for writing numerical code, etc. I've been using it for that for about 15 years and continue using it. It's a great language for many problems, and C++, even in cfront days, was never slow if you knew what you were doing.
The problem with C++ comes for programming in the large. C++'s lack of runtime safety means that you often need to use separate processes to isolate components from one another. And C++'s lack of reflection means that programmers often end up duplicating functionality and writing lots of adapter code. I'm not arguing C vs. C++. C is as bad as C++ in these regards.
You will also notice that KDE starts up many processes but that most of those processes are in shared ram (due to the wonderful reused libraries).
I am fully aware of shared memory and shared code. Nevertheless, if you add up all the actual memory used by KDE processes, you still end up with a lot (from memory, 20-30Mbytes for a basic desktop last I checked, but I'm not going to re-install KDE to find out).
If I distribute code using Qt (and just about anything using KDE uses Qt) under the BSD or LGPL license, if a user wants to incorporate my code into their commercial system, they have to buy a commercial license from Troll Tech. That means that I didn't achieve what I presumably wanted to achieve with using a BSD or LGPL license: widespread adoption. For practical purposes, the Qt license forces everything that uses Qt or KDE to either use the GPL or the Troll Tech commercial license. If Qt were the only game in town, I might have to live with it. But it isn't by a long shot.
Yes, which basically means that I have to use the GPL for any open source software I write based on it--that's too restrictive. I want to let people use my open source software under BSD or LGPL licenses.
KDE is replicating an old paradigm--the Windows desktop; I don't think that's where the industry is going.
Huh? XP, OSX, Win2k, all are polishing up their WIMP interfaces. Even task-oriented systems like the PalmOS are being supplanted by general WIMP interfaces as people demand more functionality.
Actually, Microsoft and other systems are increasingly going over to browser-like interfaces, and that's likely where the future lies.
KDE is a great achievement, it works well, and it looks nice. But I'm still not using it, and I'm certainly not developing for it. Why?
C++ is deeply ingrained in the system; I don't believe that's where the future of application programming is going. I also believe that the use of C++ makes KDE slow and resource intensive.
A lot of KDE just duplicates existing functionality, but using the Qt toolkit and KDE libraries, all in the name of KDE integration. But often, the KDE equivalents are less functional.
KDE consumes huge amounts of resources and starts up lots of processes.
The KDE/Qt licenses (GPL/commercial) restrict my ability to create open source software (say, under BSD or LGPL licenses). I think the licenses are also harmful from the point of view of trying to attract more commercial developers to the Linux platform. Toolkits are a commodity these days, and they shouldn't be the major cost when choosing a platform.
KDE is replicating an old paradigm--the Windows desktop; I don't think that's where the industry is going.
KDE has its place in the world--something for people who think Windows is easy to use and want a similar environment for Linux/UNIX. I'm not sure it can compete with Windows, because Windows isn't really about quality, it's about complete, detailed compatibility. But that's for others to decide.
I just hope KDE won't become the predominant Linux/UNIX desktop. In fact, I hope no single desktop will become "predominant" on Linux/UNIX--the strength of Linux/UNIX has been its diversity and flexibility. And I hope the KDE developers are smart enough to realize that they can't produce something that satisfies everybody--that would be the same trap Microsoft has fallen into.
I never really took to Lego
on
Battle Over Blocks
·
· Score: 5, Interesting
For "engineering" applications (building things that do things), Lego always seemed to limited to me. And purely for shape and sculpting, it had all the charm of an Etch-a-Sketch: you spent most of the time trying to get around its oddball rectangular limitations.
If you must use a construction set, there seem to be better ones around than Lego: systems like ErectorSet, FischerTechnik, and others, are a lot more flexible and have a lot more interesting mechanical components in them.
But what is wrong with wooden blocks, woodworking, metal working, clay, real electronic parts, solder, or paint? Why learn something as limited, expensive, and plasticky as Lego when you could learn real skills with the real thing? Start off with clay and paint, move on to cardboard and paper, then to light wood, then, well, you get the point. And if parents actually get involved with their children, they can start supervised woodworking and metal work very early.
This is a shame. Linux would never have gotten off the ground if people had this same feeling about UNIX 10 years ago.
Most people did: SunOS was widely available, with sources, it worked reasonably well, and it ran on good and fairly cheap hardware. Linux took off because nothing quite like it existed for PC hardware.
I agree, though, about Java and the risks inherent in Sun's Java license. But the biggest problem with Java and open source is that Java is used so little in major open source projects. If the open source community used Java widely and developed their own standards (say, an "xAWT" or a "jGTK"), Sun would either become irrelevant or they would be quick to "donate" their libraries. And existing open source Java implementations will only get better if people actually use them.
Incidentally, Intel ORP is an open source and rather efficient Java VM, beating Sun's JVM on many numerical benchmarks.
Enhydra itself was open source at some point. InstantDB may not have been. In either case, I think the lesson is: don't rely on promises. Unless it has an open source license and you have the sources, it isn't open source.
If you do, some kind of microwave system might work. If you don't have line of sight (or can arrange for a series of relays), you are probably out of luck.
If the open source development was carried out under a reasonable open source license, like BSD, GPL, or LGPL, it doesn't matter if the company wants to take further development private: the open source version continues to be open source, and any enhancements made to the open source version, through feedback or contributions, will continue to be open source.
Furthermore, nobody can make source "closed source" if they don't own it. So, if the open source community made valuable contributions and those became a key part of this software, the company can't make it closed source. The fact that they can suggests to me that few such contributions have come in.
Friends can betray you. But in business, and open source is part of the business world, what matters is contracts and licenses. If business partners violate contracts, you take them to court. Otherwise, if you don't like the license under which a piece of open source software is delivered or accepts contributions, don't use it and don't contribute to it. And if there is a possibility that some open source software with an otherwise OK license goes "closed source", you should keep frequent public mirrors of the open source versions so that open source development can continue when the need arises.
There are plenty of pieces of software that are semi-open where I have said "no thanks" (I won't name names, but I have complained about them enough on/.). I suggest others pay a little more attention to licenses as well before investing their time and effort in using or enhancing other people's software.
I think the SGI panels are not the pinnacle of flat panels anymore--it's an older design and actually has less contrast than more modern flat panels. I also don't view the small dot pitch as an advantage--it seems unnecessarily small for normal viewing distances. I think you can get something better and pay less from other vendors now.
Slashdot Mirror
Give the handheld a VGA output port and good headphones (maybe even Bluetooth) and all of a sudden PowerPoint and MP3 on a handheld are very attractive to a lot of people.
Running Qt/Embedded has all sorts of disadvantages, however:
There are two predominant environments for writing GUI apps on Linux handhelds: FLTK and Java, both using X11 as the display server. I doubt anything else is going to catch on widely.
What I mean is that gcj and other ahead-of-time compilers allow people to continue writing Java code as if they were writing C/C++ code: small, standalone, native-code applications that are composed of a mostly static codebase. In order to achieve that, they sacrifice many of the properties that make Java interesting in the first place.
If you take a single-process, dynamic-compilation approach, Java really shines: you can combine lots of software components at runtime, and the dynamic compiler will optimize and inline everything at runtime. That's not theoretical, it really works. If you keep a single Java process running (rather than starting things up again and again), javac, jedit, and other substantial Java programs are lightning fast.
I agree that gcj is very worthwhile, and I hope its development will continue. Many people (myself included) still want to write small, stand-alone applications some of the time, and being able to use Java is nice for that. Gcj's easy connection with C++ also is a great link to existing codebases.
Nevertheless, for developing a modern desktop, I think the dynamic compilation approach is a much better way to go than ahead-of-time compilation.
I do agree, however, that a sharable VM and sharable JIT results would be good. Using Java for a Sun-sponsored desktop project would also help improve Swing and any remaining performance bottlenecks.
I think something like gcj is a crutch. It would let you write C/C++-style applications in Java, maybe even using Gtk+. That's better than nothing, and would allow for a smooth transition from something like Gnome to Java, but I think it also means giving up on some of the major advantages of Java.
If you go with gcj and separate processes, you lose most of the advantages of Java over C++ (although you still get something that's easier to learn and a bit more robust).
Homeostatsis and self-regulation are not properties that you implement once in some abstract data type and that henceforth works for everything, or that require breakthrough new technology, they are design goals that you need to take into account when you design each and every part of a system. Biological organisms have been forced from day one to deal with these issues. The reason real software systems don't do this is not that people don't know how to, it's that software developers don't bother and aren't trained to do it, and that they can get away with it because there are always smart humans around to help it.
So, next time you write a new piece of software, think about how you can make it more self adapting and less reliant on numerous environment variables and other arguments supplied by the user. The pathsearch library is a simple example of this.
If Sun adopted KDE/Qt, they'd let another company set the cost for any commercial GUI development on Solaris that integrates with the standard desktop. The cost would instantly be much higher than it is now, it would be much higher than competing platforms, and there is no guarantee that it wouldn't go up even further since Sun has no control over TrollTech's pricing or development direction.
Yes, and you can say roughly the same thing about KDE/Qt. Sun already has better technology than either Gtk+ or Qt. It's called Java. They should use it and deploy it. The reason they don't is the same bogus internal politics that killed Smalltalk, NeWS, and OpenStep on Solaris.
Unfortunately, Sun's OS group seems blissfully disconnected from their Java side; in fact, their OS group seems stuck in the C-mindset of the traditional BSD/UNIX world. And Sun's Java group seems more focussed on Windows than on adding value to Sun's own product line. Sun's lack of coordination and their lack of in-house and open source application development in Java gives people the impression that Java isn't ready. That may have been true two years ago, but today, Java is more than up to the task of building a zippy desktop with a footprint smaller than either Gnome or KDE.
Of course, Sun can't give up completely on C/C++ toolkits, but they have that pretty well covered with Motif and its C++ wrappers, tools that are still much more widely used among Sun's customers than either Gtk+ or Qt.
Sun always seemed like Sun's worst enemy. They need a little of that Gates/Ballmer top-down coherent management and energy. McNealy barks a lot, but he doesn't seem to bite much.
Sun would have to get a transferable binary license for Qt on Solaris, but even then, they'd be the only UNIX vendor standardizing on Qt. Or, Sun would have to buy TrollTech outright, likely to be an expensive proposition.
Sticking with Motif makes sense: it's very widely used commercially (far more than Qt), there are lots of widgets and tools for it, it is a de-facto standard, and Sun already has rights to it. There are also several C++-based APIs for Motif. (Technically, I think Qt and Motif is a toss-up, but that's another matter.)
Yes, that is right. However, that is not the correct way of hiding information in images. What you should rather do is match the distribution of the encrypted data to the noise characteristics of a known, plausible source (e.g., a CCD camera). Alternatively, you just make sure that you encode at a bit rate that is low enough not to change the noise characteristics of the image detectably. Either is easy to do.
As for C++, which part of my actual argument in the post you replied to don't you understand or disagree with?
Actually, in order to be efficient for programming in the large, efficiency for programming in the small doesn't matter that much, since you can still write tight inner loops in C if it is advantageous to do so.
There are lots of possibilities for languages and runtimes: Java, C#, Eiffel, Oberon, Modula-3, ObjectPascal, even Scheme and OCAML.
What's the alternative? Microsoft's handheld platforms are nowhere near as usable, mature, or efficient as PalmOS. But unlike Palm, the Microsoft handheld platforms also really don't want to talk to anything other than Windows, and you can't develop for them on anything other than Windows.
As far as I'm concerned, PalmOS is still the best game in town for handhelds and phones. Maybe some of the Linux-based devices will make it out the door at some point. Maybe Palm will come out with a decent, modern 32bit OS soon. But I doubt Microsoft ever gets a clue and starts untying their different systems from one another or starts using open, well-documented ways of storing data; and until they do, I think it's foolish to put your data on their devices.
This Samsung phone looks more practical to me in the short term: Palm interface and PalmOS, color, and dual-band. Yes, I wouldn't mind having the keyboard and GPRS of the Treo, but who knows when the Treo will actually be shipping, what the service availability and coverage will be, what kind of surchages they will add, etc.
C++ is very efficient and expressive for "programming in the small": for writing tight inner loops, for writing numerical code, etc. I've been using it for that for about 15 years and continue using it. It's a great language for many problems, and C++, even in cfront days, was never slow if you knew what you were doing.
The problem with C++ comes for programming in the large. C++'s lack of runtime safety means that you often need to use separate processes to isolate components from one another. And C++'s lack of reflection means that programmers often end up duplicating functionality and writing lots of adapter code. I'm not arguing C vs. C++. C is as bad as C++ in these regards.
You will also notice that KDE starts up many processes but that most of those processes are in shared ram (due to the wonderful reused libraries).
I am fully aware of shared memory and shared code. Nevertheless, if you add up all the actual memory used by KDE processes, you still end up with a lot (from memory, 20-30Mbytes for a basic desktop last I checked, but I'm not going to re-install KDE to find out).
If I distribute code using Qt (and just about anything using KDE uses Qt) under the BSD or LGPL license, if a user wants to incorporate my code into their commercial system, they have to buy a commercial license from Troll Tech. That means that I didn't achieve what I presumably wanted to achieve with using a BSD or LGPL license: widespread adoption. For practical purposes, the Qt license forces everything that uses Qt or KDE to either use the GPL or the Troll Tech commercial license. If Qt were the only game in town, I might have to live with it. But it isn't by a long shot.
Yes, which basically means that I have to use the GPL for any open source software I write based on it--that's too restrictive. I want to let people use my open source software under BSD or LGPL licenses.
Actually, Microsoft and other systems are increasingly going over to browser-like interfaces, and that's likely where the future lies.
KDE has its place in the world--something for people who think Windows is easy to use and want a similar environment for Linux/UNIX. I'm not sure it can compete with Windows, because Windows isn't really about quality, it's about complete, detailed compatibility. But that's for others to decide.
I just hope KDE won't become the predominant Linux/UNIX desktop. In fact, I hope no single desktop will become "predominant" on Linux/UNIX--the strength of Linux/UNIX has been its diversity and flexibility. And I hope the KDE developers are smart enough to realize that they can't produce something that satisfies everybody--that would be the same trap Microsoft has fallen into.
If you must use a construction set, there seem to be better ones around than Lego: systems like ErectorSet, FischerTechnik, and others, are a lot more flexible and have a lot more interesting mechanical components in them.
But what is wrong with wooden blocks, woodworking, metal working, clay, real electronic parts, solder, or paint? Why learn something as limited, expensive, and plasticky as Lego when you could learn real skills with the real thing? Start off with clay and paint, move on to cardboard and paper, then to light wood, then, well, you get the point. And if parents actually get involved with their children, they can start supervised woodworking and metal work very early.
Most people did: SunOS was widely available, with sources, it worked reasonably well, and it ran on good and fairly cheap hardware. Linux took off because nothing quite like it existed for PC hardware.
I agree, though, about Java and the risks inherent in Sun's Java license. But the biggest problem with Java and open source is that Java is used so little in major open source projects. If the open source community used Java widely and developed their own standards (say, an "xAWT" or a "jGTK"), Sun would either become irrelevant or they would be quick to "donate" their libraries. And existing open source Java implementations will only get better if people actually use them.
Incidentally, Intel ORP is an open source and rather efficient Java VM, beating Sun's JVM on many numerical benchmarks.
Enhydra itself was open source at some point. InstantDB may not have been. In either case, I think the lesson is: don't rely on promises. Unless it has an open source license and you have the sources, it isn't open source.
If you do, some kind of microwave system might work. If you don't have line of sight (or can arrange for a series of relays), you are probably out of luck.
Furthermore, nobody can make source "closed source" if they don't own it. So, if the open source community made valuable contributions and those became a key part of this software, the company can't make it closed source. The fact that they can suggests to me that few such contributions have come in.
Friends can betray you. But in business, and open source is part of the business world, what matters is contracts and licenses. If business partners violate contracts, you take them to court. Otherwise, if you don't like the license under which a piece of open source software is delivered or accepts contributions, don't use it and don't contribute to it. And if there is a possibility that some open source software with an otherwise OK license goes "closed source", you should keep frequent public mirrors of the open source versions so that open source development can continue when the need arises.
There are plenty of pieces of software that are semi-open where I have said "no thanks" (I won't name names, but I have complained about them enough on /.). I suggest others pay a little more attention to licenses as well before investing their time and effort in using or enhancing other people's software.
I think the SGI panels are not the pinnacle of flat panels anymore--it's an older design and actually has less contrast than more modern flat panels. I also don't view the small dot pitch as an advantage--it seems unnecessarily small for normal viewing distances. I think you can get something better and pay less from other vendors now.