Both of those "deficiencies" are plusses on a corporate desktop. There you do not want users installing random software apps and libraries (licensing issues aside, which are less relevant with OSS) -- it makes desktop support a nightmare.
You also don't need CD burning software. Most of those corporate desktop machines won't even have a CD burner installed, and you don't really want most employees burning random discs at work (of what? copied commercial CDs? confidential corporate data?).
The few employees that need that stuff -- e.g. developers in your IT department or people that need to burn the occasional presentation onto a disc -- can either install extra software themselves or are few enough in number for IT support to set up for them. (Or just install SUSE instead.)
Well sir, I guess I have to retract the part of my earlier comment where I said I didn't think anybody had ever flowcharted code down to the statement level.
Let me guess, you are/were either a COBOL and/or IBM Assembler programmer. (I don't think I've ever seen anyone else go to that level of detail -- hmm, maybe Fortran IV programmers too.)
(As for me, if I had to do a formal flowchart, I'd write the code first and run it through a flowchart generating program. But all that was decades ago. Not counting UML activity diagrams, of course.)
UML, but that is a long stretch from code flowcharting.
So, what's the difference between a UML activity diagram and a flowchart? Almost none at all, modulo minor tweaks to the symbology. Statechart diagrams are almost unchanged from traditional state transition diagrams (perhaps they didn't like the unfortunate acronym STD). Class diagrams are pretty much ERDs (entity relationship diagrams) from DB design. The only thing missing is DFDs (data flow diagrams) although collaboration diagrams are pretty close.
UML didn't replace flowcharting, it just formalized the notation and enlarged it to handle OO concepts.
Mind, I don't think I ever actually used my IBM Standard Flowchart Template (a plastic stencil of flowchart symbols), only ever sketched flowcharts on a whiteboard as part of process analysis. (And no, beyond ancient textbook examples, I don't think anybody ever flowcharted code down to the statement level.)
For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries.
This is similar to a technique used by the Burroughs MCP some 30 years ago. Wasn't so much signed binaries as binaries tagged as executable -- and only a compiler could set that tag. And, of course, only the kernel (MCP) -- via a console command (and this being a mainframe, the console was special) -- could mark an executable as a compiler.
(I did figure out an exploit involving intimate knowledge of the format of Burroughs backup tapes and access to a non-Burroughs machine to create a modified tape. The systems programmers I described it to agreed it'd probably work if you could manage to create a correctly formatted tape on a different machine (a Burroughs wouldn't let you) but it was too much work to actually implement, although I had access to an IBM to create the tape. Moral of that story is never trust what's on removable media, unless you can know that it hasn't been tampered with (eg digital signatures).)
if you've been employed for a decent amount of time in a relevant job, you wouldn't need the certs afterward either,
That's the catch, especially in the current job market. If you've been in the field for a few years, and you're interested in it, you can probably do a variety of jobs that may not exactly match your current job title or job description. See my other post -- I'm primarily a software developer but I've got plenty of sysadmin experience. Ditto with various programming languages and systems.
Now, for old farts like us (who may tend to have a tougher time anyway getting a new job), the choices are either submit a 10-page resume to make sure everything is covered (not a good idea, it won't be read), or carefully custom tailor a resume for each position applied for (not a bad idea, but a lot of work and it may not adequately convey just how much you know), or go get certs in the stuff you know but isn't reflected well by your resume.
I did the latter, and had two resumes -- one for software development and one for systems admin.
Depends whether you need the training or just the cert test -- although granted some tests cost more than others.
I'd been unemployed for a while when I put out the $300 or so for the two tests for a Solaris sysadmin cert. I'm primarily a developer, not a sysadmin, but I've been working with Unix for 20 years, and with Sun gear since the Sun 3 series, and lord knows I've had to admin enough systems! (And I've been an operator on big iron back in the day.) That didn't land me the sysadmin job I'd heard about through a friend, but it did get me (a few months later) the sysadmin job I have now. (Total cost of training: $50 for a book with test-yourself CD, $100 for a spare box to mess with Solaris on, connect time to download Solaris -- plus of course the 20 years working with 'nix systems and the several years of running a Linux-based server room on the side.)
Yeah $450 (total) is a chunk of change when you're unemployed, but it paid for itself real fast once I got a job.
(On the flip side, the $150 I spent to write the Java Programmer cert test hasn't paid itself back yet. Maybe I'll spring for the J2EE Architect cert. Two exams plus a project. What fun.)
The problem with using chemical names for minerals is that, typically, mineral compositions are so messy. Sure, they start off as a simple e.g. metal silicate or carbonate or sulfide, but then you get all sorts of substitutions thrown in of varying proportions.
Besides, the chemical name doesn't tell the whole story. Allotropes aside (do we really want to call both graphite and diamond just 'carbon'?), trace contaminants and variations in crystal growth make a difference. Quartz is 'just' silicon dioxide -- but 'amethyst', 'citrine', 'rock crystal', and 'cairngorm' distinguish the types (let alone 'agate', 'flint', 'sardonyx', 'jasper' and 'chalcedony', to name just a few kinds of contaminated cryptocrystalline silicon dioxide).
Sure, the names aren't particularly meaningful in themselves, any more than are the names of, say, programming languages (although 'C', 'C++' and 'C#' suggest some similarities -- but 'PERL', 'PL/I' and 'APL' are utterly dissimilar), or any other jargon. But to someone who knows them they encapsulate a lot of information in a single word.
I have to thank you. This discussion over the last couple of days led me to take another look at some code from a couple of years ago where I'd been thrashing over getting pseudocolor to work right.
And you know what? PseudoColor (and DirectColor) does work in XFree86. I'm going to give myself the benefit of the doubt and say that a change of video card and a couple of releases of XFree86 made the difference. (The original version of the code is long gone, so I'll never know for sure.) I can now draw in blinking ink (and I may just add three-way color cycling to simulate motion, as in flow direction along a path (pipe, etc) for example).
Oh, yeah, you have to create the X Server instance with the appropriate depth to magically get the set of visuals you need (fortunately with Linux's virtual consoles I can have multiple X servers running multiple virtual displays simultaneously -- although KDE and Gnome get confused if you try to run more than one copy of either at time (so I just run twm on display:1). And colormaps are still are PITA in DirectColor mode (whole screen colormap changes depending on the visual of the active window -- as you alluded to above).
I think we both agree that the design (API) is fundamentally broken, we just disagree on the usefulness of dynamic colormaps.
You are seriously deluded about how much computing power is needed to change the pixels on the screen.
Not at all. Just that it's more power than is needed to toggle a value in a LUT.
A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Sure, and it's doing quite a bit of that in the graphics hardware (GPU), not the CPU. And very little of that ever has to go over a network (the big advantage of X, remember?).
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
Of course, as I said in my earlier message. Programmatically, though, it's a pain in the butt. If the card manufactures want to simulate colormaps this way, that'd be fine. Or even if the XFree86 folks had decided to emulate them in software to make X Visuals work on hardware that didn't support them, that'd be great too. If I've got to emulate it myself, its a truckload of programming that I shouldn't have to do given the X definition.
Basically I have to maintain my own image buffer, and either emulate X writes to it or blt the pixels from the X server to keep it in synch, manipulate the pixels myself, then blt the whole thing back to the X server. Bleah! What kind of crap is that?
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color.
This was correct behaviour. Method, not policy. If the hardware couldn't support truecolor it was up to the program to deal with appropriately, not for X to guess at it. But colormaps and truecolor are not mutually exclusive.
Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays.
Thereby guaranteeing that there were plenty of incorrect pixels without letting the application know about it. Perhaps X should have implemented this as an option (plenty of apps that don't care if every pixel is perfect) but with some apps you really do care if a pixel is illuminated to a value because it really represents something or just because it happened to dither to that value.
The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings,
What in the world are you talking about? "every" program? Games and paint programs perhaps. Ever done anything with serious visual analysis of real-world data?
It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken. Which is what really sucks. If it just reported a single visual available, a program would know not to even try messing with visuals. Instead it reports them there but ignores colormap changes. The program lies about its capabilties.
Fine point. The United States could have militarily defeated the Viet-cong easily. This is true.
And in fact, is what happened. The Viet Cong were soundly defeated after a couple of disasterous (for them) offensives that got the kind of publicity stateside that some of the current incidents in Iraq are getting (ie, distorted).
South Vietnam was defeated -- after most of the US forces had been pulled out and military aid severely cut back -- by the regular North Vietnamese Army (not the guerilla Viet Cong) backed by one of the largest tank assaults in the (until then) history of warfare (thanks to external suppliers).
You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard
Ooh. Never mind.
Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color.
Actually, I take that "never mind" back. You seem to be defining "modern graphics" as that subset of computer display graphics that concerns itself with making images and graphic layouts look "correct" so that what you see on the screen is what you'll get on the page when it's printed (or TV or theatre screen when it's rendered to media for those).
Like I said, that's a subset of what people use graphic computer displays for. Aside from the pretty picture industry, the computer display is a communication tool to present information in the computer to a human user in the most rapidly undestandable manner. An air traffic controller doesn't want photorealistic pictures of aircraft flitting over the screen, that's too distracting, he just wants a symbolic representation of the specific information he's interested in. A GIS analyst doesn't care if the mixed raster and vector image he's looking at matches what the ground outside really looks like, or even what a printed copy would look like (and while a cartographer might care about the latter, he's only going to want to use a small color palette). The GIS guy does care if the 4,327 features his query selected are going to highlight quickly, and whether or not he'll be able to distinguish them from the various other colored features on the display (this is the advantage of blinking).
Colormaps were a serious detriment to advancement of graphics.
Your particular branch of graphics, perhaps, but not that of countless others. Changing a colormap value can be simulated by redrawing all the relevant pixels in a different color, but at what a senseless waste of CPU cycles and memory bandwidth.
Sun was forced to add several bits to each pixel of their full-color display just to store "which color map"
A nicer approach than just letting the windows with a different color map look strange, but not the only way they could have done it. But bits are cheap. Another megabyte of RAM? BFD.
most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
Not gone, not by a long shot. Just not ported to Linux, at least not without requiring a commercial X11 package.
Okay, I may be unique in that I still do some open source development with Motif (mostly wrapped in C++ classes...), but he also calls the Tk toolkit obsolete.
Eh? Perl/Tk, Python/Tk and (let us not forget) Tcl/Tk are obsolete? Not dead yet, I'd say, although perhaps GTK+ is starting to replace it in favor. What say you?
(And I guess I can finally throw out my old PEXlib and OpenLook books. Sigh. Anyone got a graphics API they want rendered obsolete? I'll just go study up on it, that should do it...)
never achieved widespread acceptance (as in the X Color management part of the API)
Perhaps that never achieve widespread acceptance because the XFree86 implementation (or perhaps just every graphics card I ever tried it on) sucked big time.
I wasted far too many hours trying to implement some things using this (that I'd done before with commercial X implementations on dedicated Unix hardware) before giving up in disgust because it just couldn't be done.
What kind of things? Stuff like a vector graphics program where the selected object(s) blink by repainting them in "blinking ink" -- a designated color number whose colormap entry is regularly toggled by another process. Or doing vector-over-raster by selectively allocating and masking the pixel planes.
Yeah, there are other ways to do it, but it's just so much easier with the access to colormaps and different (eg PseudoColor) visuals.
(Except that the legal standard for treason is quite a bit higher than that in this country, otherwise some folks from Loral-Hughes would probably be doing jail time now over certain launcher technologies. Hmm, maybe there's something in the PATRIOT Act we can throw at Microsoft?)
I don't recall the names of either of the sites now, but several years ago there were at least two 'free software bounty' web sites, with slightly different models. One provided for people to propose projects and have others bid (promises of) money on the solution (increasing the pool for high-demand projects), the other (as I seem to recall) was a little more structured and the project requests were submitted with a predefined bonus by the submitter.
I guess it never caught on very well, I haven't heard of either of these in a couple of years.
In Canada people don't even lock their front doors (at least the one's interviewed by Michael Moore in "Bowling for Columbine")
One more thing not to believe Michael Moore about. I lived in Canada for more than 25 years, everyone I knew locked their doors. (Well, may have been one or two exceptions.)
Of course, "Bowling for Columbine" was a work of twisted fantasy masquerading as a documentary anyway. (I live in the Columbine HS school district, some of my neighbors' kids are students there.)
then why the hell is my cam not supported by Redhat?
Because Redhat is not a (consumer) desktop distro. It's primarily a server distro, with a token nod to the corporate desktop. Redhat's dropping of shrinkwrapped distribution is further evidence of that.
Consumer-friendly distros like SUSE and Mandrake have always been way ahead of Redhat in supporting stuff like this.
It's just as well RedHat won't be showing up on the shelves at Best Buy and CompUSA anymore, it gave desktop Linux a bad name.
If we don't want it to happen again, yes we do. It was more than one box, which points to something more systemic than a random hardware glitch or failure.
More importantly, people should have the right to distribute disposable appliances whose innards are sealed against user modification or repair if they want to. The FSF shouldn't come in and use copyright law to try to stop them.
Name one thing -- that FSF doesn't own rights to -- that it has tried to stop anyone from distributing.
FSF has never stopped anyone from distributing software without source, unless that software's copyrights were owned (at least in part) by FSF itself. He who writes the code picks the license. If you don't like the GPL terms, don't copy GPL code -- it's not yours. The FSF merely wants to ensure that if you do copy it and pass it on, you also pass on all the permissions that FSF granted to you.
I have the full source code to a lot of software which I have absolutely no clue how to repair.
So now it's all about you? Shall we amend the GPL to say "but you don't have to distribute sourcecode to Anthony Dipierro"? You are at least free to ask anyone to help you fix it or repair it for you. Try that if you don't have the source. I don't have all the tools to fix certain problems with my car, either, but I don't have to go to an authorized GM dealer to get them fixed.
It may have been a Unix box that crashed, but I've seen and heard of cases where a 'nix box crashed because of the high network load of a Windows-based worm/virus epidemic. Was this the case here?
(There should have been better firewalling in place if so, of course.)
Doesn't the FSF deny people the right to copy and distribute software, unless they agree to the GPL?
No.
OK. So I can distribute linux binaries without distributing the source, then?
Don't confuse what the law denies you with something the FSF does or doesn't do. It is against copyright law to copy and distribute software without explicit permission.
The GPL grants you that permission, with the proviso that you in turn do not withhold that permission from others.
(As for copying and distributing software without source code -- software without source code is relatively useless. Oh, it might be temporarily useful on some subset of architectures and OSs for a limited time, but it's like a disposable appliance whose innards are sealed against user modification or repair. The GPL ensures that the user always has that access to modify or repair.)
I know the history, but it still seems strange to this old-timer (who was involved in the decision to buy one of the first 11/780s for a college lab) to see VMS referred to in the context of HP operating systems.
We've even got GIS databases (eg: GRASS and PostGRASS)
GRASS isn't a GIS database, it's a GIS system. The 'A' stands for "Analysis". And I think you mean "PostGIS" -- a package of GIS extensions for PostgreSQL.
though not much for PostgreSQL
There's a Tcl/Tk based WYSIWYG for PostgreSQL that has been shipping for some time. Not half bad, although last time I looked (about a year ago) it still had some rough edges.
Of course, if you'd RTFA you'd know that Rekall is a RAD tool for existing database products.
Slashdot Mirror
Both of those "deficiencies" are plusses on a corporate desktop. There you do not want users installing random software apps and libraries (licensing issues aside, which are less relevant with OSS) -- it makes desktop support a nightmare.
You also don't need CD burning software. Most of those corporate desktop machines won't even have a CD burner installed, and you don't really want most employees burning random discs at work (of what? copied commercial CDs? confidential corporate data?).
The few employees that need that stuff -- e.g. developers in your IT department or people that need to burn the occasional presentation onto a disc -- can either install extra software themselves or are few enough in number for IT support to set up for them. (Or just install SUSE instead.)
Well sir, I guess I have to retract the part of my earlier comment where I said I didn't think anybody had ever flowcharted code down to the statement level.
Let me guess, you are/were either a COBOL and/or IBM Assembler programmer. (I don't think I've ever seen anyone else go to that level of detail -- hmm, maybe Fortran IV programmers too.)
(As for me, if I had to do a formal flowchart, I'd write the code first and run it through a flowchart generating program. But all that was decades ago. Not counting UML activity diagrams, of course.)
UML, but that is a long stretch from code flowcharting.
So, what's the difference between a UML activity diagram and a flowchart? Almost none at all, modulo minor tweaks to the symbology. Statechart diagrams are almost unchanged from traditional state transition diagrams (perhaps they didn't like the unfortunate acronym STD). Class diagrams are pretty much ERDs (entity relationship diagrams) from DB design. The only thing missing is DFDs (data flow diagrams) although collaboration diagrams are pretty close.
UML didn't replace flowcharting, it just formalized the notation and enlarged it to handle OO concepts.
Mind, I don't think I ever actually used my IBM Standard Flowchart Template (a plastic stencil of flowchart symbols), only ever sketched flowcharts on a whiteboard as part of process analysis. (And no, beyond ancient textbook examples, I don't think anybody ever flowcharted code down to the statement level.)
What ever happened to Scrappy Doo?
You need to watch the recent (well, couple years now I guess) Scooby Doo live-action/CGI movie. It explains all.
(And my excuse is that I have kids -- I rented the DVD for them. That's my story and I'm sticking to it.)
For example, if the kernel verifies the binaries it runs using digital signatures, then it can refuse to run unsigned binaries.
This is similar to a technique used by the Burroughs MCP some 30 years ago. Wasn't so much signed binaries as binaries tagged as executable -- and only a compiler could set that tag. And, of course, only the kernel (MCP) -- via a console command (and this being a mainframe, the console was special) -- could mark an executable as a compiler.
(I did figure out an exploit involving intimate knowledge of the format of Burroughs backup tapes and access to a non-Burroughs machine to create a modified tape. The systems programmers I described it to agreed it'd probably work if you could manage to create a correctly formatted tape on a different machine (a Burroughs wouldn't let you) but it was too much work to actually implement, although I had access to an IBM to create the tape. Moral of that story is never trust what's on removable media, unless you can know that it hasn't been tampered with (eg digital signatures).)
if you've been employed for a decent amount of time in a relevant job, you wouldn't need the certs afterward either,
That's the catch, especially in the current job market. If you've been in the field for a few years, and you're interested in it, you can probably do a variety of jobs that may not exactly match your current job title or job description. See my other post -- I'm primarily a software developer but I've got plenty of sysadmin experience. Ditto with various programming languages and systems.
Now, for old farts like us (who may tend to have a tougher time anyway getting a new job), the choices are either submit a 10-page resume to make sure everything is covered (not a good idea, it won't be read), or carefully custom tailor a resume for each position applied for (not a bad idea, but a lot of work and it may not adequately convey just how much you know), or go get certs in the stuff you know but isn't reflected well by your resume.
I did the latter, and had two resumes -- one for software development and one for systems admin.
when unemployed they are not affordable..
Depends whether you need the training or just the cert test -- although granted some tests cost more than others.
I'd been unemployed for a while when I put out the $300 or so for the two tests for a Solaris sysadmin cert. I'm primarily a developer, not a sysadmin, but I've been working with Unix for 20 years, and with Sun gear since the Sun 3 series, and lord knows I've had to admin enough systems! (And I've been an operator on big iron back in the day.) That didn't land me the sysadmin job I'd heard about through a friend, but it did get me (a few months later) the sysadmin job I have now. (Total cost of training: $50 for a book with test-yourself CD, $100 for a spare box to mess with Solaris on, connect time to download Solaris -- plus of course the 20 years working with 'nix systems and the several years of running a Linux-based server room on the side.)
Yeah $450 (total) is a chunk of change when you're unemployed, but it paid for itself real fast once I got a job.
(On the flip side, the $150 I spent to write the Java Programmer cert test hasn't paid itself back yet. Maybe I'll spring for the J2EE Architect cert. Two exams plus a project. What fun.)
The problem with using chemical names for minerals is that, typically, mineral compositions are so messy. Sure, they start off as a simple e.g. metal silicate or carbonate or sulfide, but then you get all sorts of substitutions thrown in of varying proportions.
Besides, the chemical name doesn't tell the whole story. Allotropes aside (do we really want to call both graphite and diamond just 'carbon'?), trace contaminants and variations in crystal growth make a difference. Quartz is 'just' silicon dioxide -- but 'amethyst', 'citrine', 'rock crystal', and 'cairngorm' distinguish the types (let alone 'agate', 'flint', 'sardonyx', 'jasper' and 'chalcedony', to name just a few kinds of contaminated cryptocrystalline silicon dioxide).
Sure, the names aren't particularly meaningful in themselves, any more than are the names of, say, programming languages (although 'C', 'C++' and 'C#' suggest some similarities -- but 'PERL', 'PL/I' and 'APL' are utterly dissimilar), or any other jargon. But to someone who knows them they encapsulate a lot of information in a single word.
I have to thank you. This discussion over the last couple of days led me to take another look at some code from a couple of years ago where I'd been thrashing over getting pseudocolor to work right.
:1). And colormaps are still are PITA in DirectColor mode (whole screen colormap changes depending on the visual of the active window -- as you alluded to above).
And you know what? PseudoColor (and DirectColor) does work in XFree86. I'm going to give myself the benefit of the doubt and say that a change of video card and a couple of releases of XFree86 made the difference. (The original version of the code is long gone, so I'll never know for sure.) I can now draw in blinking ink (and I may just add three-way color cycling to simulate motion, as in flow direction along a path (pipe, etc) for example).
Oh, yeah, you have to create the X Server instance with the appropriate depth to magically get the set of visuals you need (fortunately with Linux's virtual consoles I can have multiple X servers running multiple virtual displays simultaneously -- although KDE and Gnome get confused if you try to run more than one copy of either at time (so I just run twm on display
I think we both agree that the design (API) is fundamentally broken, we just disagree on the usefulness of dynamic colormaps.
You are seriously deluded about how much computing power is needed to change the pixels on the screen.
Not at all. Just that it's more power than is needed to toggle a value in a LUT.
A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Sure, and it's doing quite a bit of that in the graphics hardware (GPU), not the CPU. And very little of that ever has to go over a network (the big advantage of X, remember?).
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
Of course, as I said in my earlier message. Programmatically, though, it's a pain in the butt. If the card manufactures want to simulate colormaps this way, that'd be fine. Or even if the XFree86 folks had decided to emulate them in software to make X Visuals work on hardware that didn't support them, that'd be great too. If I've got to emulate it myself, its a truckload of programming that I shouldn't have to do given the X definition.
Basically I have to maintain my own image buffer, and either emulate X writes to it or blt the pixels from the X server to keep it in synch, manipulate the pixels myself, then blt the whole thing back to the X server. Bleah! What kind of crap is that?
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color.
This was correct behaviour. Method, not policy. If the hardware couldn't support truecolor it was up to the program to deal with appropriately, not for X to guess at it. But colormaps and truecolor are not mutually exclusive.
Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays.
Thereby guaranteeing that there were plenty of incorrect pixels without letting the application know about it. Perhaps X should have implemented this as an option (plenty of apps that don't care if every pixel is perfect) but with some apps you really do care if a pixel is illuminated to a value because it really represents something or just because it happened to dither to that value.
The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings,
What in the world are you talking about? "every" program? Games and paint programs perhaps. Ever done anything with serious visual analysis of real-world data?
It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken. Which is what really sucks. If it just reported a single visual available, a program would know not to even try messing with visuals. Instead it reports them there but ignores colormap changes. The program lies about its capabilties.
Fine point. The United States could have militarily defeated the Viet-cong easily. This is true.
And in fact, is what happened. The Viet Cong were soundly defeated after a couple of disasterous (for them) offensives that got the kind of publicity stateside that some of the current incidents in Iraq are getting (ie, distorted).
South Vietnam was defeated -- after most of the US forces had been pulled out and military aid severely cut back -- by the regular North Vietnamese Army (not the guerilla Viet Cong) backed by one of the largest tank assaults in the (until then) history of warfare (thanks to external suppliers).
You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard
Ooh. Never mind.
Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color.
Actually, I take that "never mind" back. You seem to be defining "modern graphics" as that subset of computer display graphics that concerns itself with making images and graphic layouts look "correct" so that what you see on the screen is what you'll get on the page when it's printed (or TV or theatre screen when it's rendered to media for those).
Like I said, that's a subset of what people use graphic computer displays for. Aside from the pretty picture industry, the computer display is a communication tool to present information in the computer to a human user in the most rapidly undestandable manner. An air traffic controller doesn't want photorealistic pictures of aircraft flitting over the screen, that's too distracting, he just wants a symbolic representation of the specific information he's interested in. A GIS analyst doesn't care if the mixed raster and vector image he's looking at matches what the ground outside really looks like, or even what a printed copy would look like (and while a cartographer might care about the latter, he's only going to want to use a small color palette). The GIS guy does care if the 4,327 features his query selected are going to highlight quickly, and whether or not he'll be able to distinguish them from the various other colored features on the display (this is the advantage of blinking).
Colormaps were a serious detriment to advancement of graphics.
Your particular branch of graphics, perhaps, but not that of countless others. Changing a colormap value can be simulated by redrawing all the relevant pixels in a different color, but at what a senseless waste of CPU cycles and memory bandwidth.
Sun was forced to add several bits to each pixel of their full-color display just to store "which color map"
A nicer approach than just letting the windows with a different color map look strange, but not the only way they could have done it. But bits are cheap. Another megabyte of RAM? BFD.
most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
Not gone, not by a long shot. Just not ported to Linux, at least not without requiring a commercial X11 package.
Okay, I may be unique in that I still do some open source development with Motif (mostly wrapped in C++ classes...), but he also calls the Tk toolkit obsolete.
Eh? Perl/Tk, Python/Tk and (let us not forget) Tcl/Tk are obsolete? Not dead yet, I'd say, although perhaps GTK+ is starting to replace it in favor. What say you?
(And I guess I can finally throw out my old PEXlib and OpenLook books. Sigh. Anyone got a graphics API they want rendered obsolete? I'll just go study up on it, that should do it...)
never achieved widespread acceptance (as in the X Color management part of the API)
Perhaps that never achieve widespread acceptance because the XFree86 implementation (or perhaps just every graphics card I ever tried it on) sucked big time.
I wasted far too many hours trying to implement some things using this (that I'd done before with commercial X implementations on dedicated Unix hardware) before giving up in disgust because it just couldn't be done.
What kind of things? Stuff like a vector graphics program where the selected object(s) blink by repainting them in "blinking ink" -- a designated color number whose colormap entry is regularly toggled by another process. Or doing vector-over-raster by selectively allocating and masking the pixel planes.
Yeah, there are other ways to do it, but it's just so much easier with the access to colormaps and different (eg PseudoColor) visuals.
Isn't that perjury?
Well, either that or treason.
(Except that the legal standard for treason is quite a bit higher than that in this country, otherwise some folks from Loral-Hughes would probably be doing jail time now over certain launcher technologies. Hmm, maybe there's something in the PATRIOT Act we can throw at Microsoft?)
It's been done. Twice.
I don't recall the names of either of the sites now, but several years ago there were at least two 'free software bounty' web sites, with slightly different models. One provided for people to propose projects and have others bid (promises of) money on the solution (increasing the pool for high-demand projects), the other (as I seem to recall) was a little more structured and the project requests were submitted with a predefined bonus by the submitter.
I guess it never caught on very well, I haven't heard of either of these in a couple of years.
In Canada people don't even lock their front doors (at least the one's interviewed by Michael Moore in "Bowling for Columbine")
One more thing not to believe Michael Moore about. I lived in Canada for more than 25 years, everyone I knew locked their doors. (Well, may have been one or two exceptions.)
Of course, "Bowling for Columbine" was a work of twisted fantasy masquerading as a documentary anyway. (I live in the Columbine HS school district, some of my neighbors' kids are students there.)
then why the hell is my cam not supported by Redhat?
Because Redhat is not a (consumer) desktop distro. It's primarily a server distro, with a token nod to the corporate desktop. Redhat's dropping of shrinkwrapped distribution is further evidence of that.
Consumer-friendly distros like SUSE and Mandrake have always been way ahead of Redhat in supporting stuff like this.
It's just as well RedHat won't be showing up on the shelves at Best Buy and CompUSA anymore, it gave desktop Linux a bad name.
Do we really care how the box crashed?
If we don't want it to happen again, yes we do. It was more than one box, which points to something more systemic than a random hardware glitch or failure.
More importantly, people should have the right to distribute disposable appliances whose innards are sealed against user modification or repair if they want to. The FSF shouldn't come in and use copyright law to try to stop them.
Name one thing -- that FSF doesn't own rights to -- that it has tried to stop anyone from distributing.
FSF has never stopped anyone from distributing software without source, unless that software's copyrights were owned (at least in part) by FSF itself. He who writes the code picks the license. If you don't like the GPL terms, don't copy GPL code -- it's not yours. The FSF merely wants to ensure that if you do copy it and pass it on, you also pass on all the permissions that FSF granted to you.
I have the full source code to a lot of software which I have absolutely no clue how to repair.
So now it's all about you? Shall we amend the GPL to say "but you don't have to distribute sourcecode to Anthony Dipierro"? You are at least free to ask anyone to help you fix it or repair it for you. Try that if you don't have the source. I don't have all the tools to fix certain problems with my car, either, but I don't have to go to an authorized GM dealer to get them fixed.
It may have been a Unix box that crashed, but I've seen and heard of cases where a 'nix box crashed because of the high network load of a Windows-based worm/virus epidemic. Was this the case here?
(There should have been better firewalling in place if so, of course.)
Doesn't the FSF deny people the right to copy and distribute software, unless they agree to the GPL?
No.
OK. So I can distribute linux binaries without distributing the source, then?
Don't confuse what the law denies you with something the FSF does or doesn't do. It is against copyright law to copy and distribute software without explicit permission.
The GPL grants you that permission, with the proviso that you in turn do not withhold that permission from others.
(As for copying and distributing software without source code -- software without source code is relatively useless. Oh, it might be temporarily useful on some subset of architectures and OSs for a limited time, but it's like a disposable appliance whose innards are sealed against user modification or repair. The GPL ensures that the user always has that access to modify or repair.)
I know the history, but it still seems strange to this old-timer (who was involved in the decision to buy one of the first 11/780s for a college lab) to see VMS referred to in the context of HP operating systems.
There's a Tcl/Tk based WYSIWYG for PostgreSQL
Which is called pgAccess which on viewing the new screenshots is looking much slicker than it used to.
We've even got GIS databases (eg: GRASS and PostGRASS)
GRASS isn't a GIS database, it's a GIS system. The 'A' stands for "Analysis". And I think you mean "PostGIS" -- a package of GIS extensions for PostgreSQL.
though not much for PostgreSQL
There's a Tcl/Tk based WYSIWYG for PostgreSQL that has been shipping for some time. Not half bad, although last time I looked (about a year ago) it still had some rough edges.
Of course, if you'd RTFA you'd know that Rekall is a RAD tool for existing database products.