Not knowing the actor and how the actor will approach the character, are they going with black as in African American, or are they going with black as in West Indian British (after Red Dwarf)? I think that West Indian British would really work well -- Arthur is definitely a Brit and Ford seems like his alter ego.
Zaphod, on the other hand, has to be an American. I always thought that Zaphod was a British take on American assertiveness.
I suppose Hitchhiker could be read and understood at a number of different levels, but I thought it worked best at the level of social satire. I mean really, that Earth was colonized by the passengers of the B-Ark, the hair dressers and telephone sanitizers of some planet, only there was no A-Ark or C-Ark for the leadership and working classes because the whole thing was just a ruse to rid society of the B-Ark people, only the whole planet died out from a plague virus spread on telephone receivers.
Now how are the suits at Disney (B-Ark people, at best) supposed to understand any of this to convey it in the movie. It is just going to be one grand adventure like their take on Inspector Gadget and all of the satire will be lost in translation.
SUN's philosophy is a little bit like "One language to run them all, one language to bind them, one language to link them all . .." It is kind of like you go whole hog with Java or not at all, and part of the reasoning is that if you link it to other stuff you create platform dependencies.
But Matlab has a cool way of using Java objects, and Java objects have a less-fuss connection to Matlab than MEX-C++. And for tight loops in pure numerical code, Java oddly enough is actually pretty efficient.
JNI also lets you create and operate on Java objects just like Matlab does -- you have to load a VM into your process, but hey, that is what invoking "java myclass" at the command line does. As a vehicle for creating plugins for a C++ program, Java.class files are much more compact than.dll files which tend to link in so much extra . . . stuff.
The JNI is really meant for Java calling into C/C++ to get at some low-level system stuff, but it allows C++ to call Java -- it has to have this capability for the low-level C++ system routine to get stuff back from the Java environment.
Does Mono support C++ calling a C# module? I know there is a MS/VS.NET solution for this, and it is a lot cleaner than JNI. All you need to do is use VS.NET to build an "unmanaged" (i.e. ordinary Windows app) C++ program, and then you need to use some kind of GCHandle template class to take care of the reference into managed code, and then you just invoke methods off that handle as if it were managed C++.
Given that the Mono project doesn't quite have the ambition to make everyone use C# everywhere for every last thing, and given cross-language development (Python-C++, etc) is getting a lot of attention, is there a Mono solution to this? You know, if you could call C# from C++, you could just as well call C# from Python by having a C++ module in the middle. Is there any interest in this capability?
I think what is going on is that you will get a list class for each separate value type and then one list class that will hold all the reference types (the value type is sort of like pointer).
I mean, how many value types are there already? So you get a couple instantiatians of the class instead of one. And if you are really worried about footprint, you can use only reference types in your list.
Some 14 years ago we had this huge recycling initiative called PRIDE (People Recycling in Defense of the Earth -- yeah, right). Every morning we have two garbage trucks come by -- the green recycling truck and the brown garbage truck.
We are supposed to recycle -- under penalty of law, but the most serious penalty I have seen is that the city workers are "empowered" to slap a bright orange stickers on piles of cardboard left by students at the U during moving day if they didn't bundle such piles to the satisfaction of the city workers. We have to recycle aluminum, glass, newspapers, cardboard, and number 1 and number 2 plastic, although there is a list as long as your arm of non-acceptable number 1 and number 2 containers. Oh, and we have to recycle tin cans.
Mr. Recycleman (not his real name, but ironically close to it), the city dude in charge of garbage, got on the TV to mention the benefits of recycling, including that all those tin cans are made into new cars.
Is this the real deal or one of those enviro-fibs? I thought that steelmaking for cars, or at least what the Japanese were doing, was almost as fussy in its control over trace impurities and alloy levels as semiconductors, because they were making a very low carbon steel that they could bond with zinc rustproofing and then stamp or otherwise form into very thin and curved sections that make up modern lightweight, fuel efficient, crash resistant, rust resistant cars. I thought the only thing tin can scrap was good for was rebar -- you could make the road the cars ride on but certainly not the cars themselves.
So why do we have to recycle tin cans? They are a PITA to get clean enough to stockpile enough to set out for recycling (the stuff that comes in them turns into very rank garbage if not cleaned up -- spaghetti sauce, canned soup, and so on). If they were really so valuable, couldn't they be picked out of the garbage stream with a magnet?
I heard that the only thing that makes money recycling is the aluminum can, and we wouldn't need the second green garage truck, it would pay to take them to a drop off center for cash. It was also suggested that the reason for recycling this other stuff was to get homeowners in the habit in case some kind of other markets developed. I think the other than aluminum recycling is a big scam, but I suppose I could be educated if someone has some other insights on this.
I just love that title "Chief Software Architect" for Bill Gates. It reminds me of the title "Chief Designer" for S. P. Korolev in the early days of the Soviet space program. Chief Designer indeed -- Korolev was the lead architect of the rocket booster and space probe designs, and he was roaming the shop floors to see what was going on, and he was tending to hiring and retention issues: trying to get the best grads, trying to get them apartments in times when apartments weren't to be had.
Don't know if there was anyone like that in NASA. Max Faget has been called the American Korolev, but I don't think we was anything like a "Chief Designer" in terms of the scope and breadth of jobs he had to take on -- I always thought NASA had a layer of management and administration even on top of their most gifted technical people so those technical people wouldn't get bogged down.
Maybe the closest to an American Chief Designer would have been Clarence "Kelly" Johnsons of Skunk Works fame.
I am a Windows user, but it seems ironic now that it was Word for Mac that got me switched to Word. Our U used to be pretty much a Word Perfect-on-Windows shop except for those renegades running Macs.
When one of my colleagues, one of those "stinkin' Mac users" from the famous Dilbert cartoon, started sending me Word docs, I had to beg or borrow a copy of Word and get used to it fast. At the time Word Perfect was a lot better in many ways -- figure layout was much less brain dead.
What sealed the deal and sealed the fate of Word Perfect was that our U became part of a statewide Microsoft site license. Funny thing, the site license was only with MS, but all kinds of talk about going around "auditing" faculty computers kind of disappeared after that.
In 2003, the U and the State decided not to renew the deal because MS started getting greedy. I am trying to get used to Star Office -- heck if I used Word Perfect, switched to MS Office, what is the big deal running Star Office? But our lawyers tell us we can still run "legacy" versions of MS stuff at work -- just no upgrades without paying for individual licenses -- so it may be awhile before Star Office gets traction.
Matlab is to the academic-scientific-engineering world what Visual Basic is to the accounting-business-data processing world.
Your EE or ME or ChemE full professor as a grad student could have written a FORTRAN program to compute some stuff and write output to a numeric text file or perhaps draw some plots using a subroutine library. You are probably thinking that anyone who can't sling together C programs using VI to draw graphics straight to X is a luser, but I am talking about pretty technically savy people who don't have time to spend on this stuff and who employ armies of Engineering majors from foreign lands who are not up on this stuff either.
My own take is that if a particular numerical calculation can be easily programmed by some package, it must not be on the cutting edge of research because someone has already done it. Besides, if your software package is really deep, most of the effort goes into the architecture and the data flows and into graphics, and the RAD bit is only simplifying a tiny part of what you are spending your time. A high-power scientific data visualization is really a video game, and how many video games are implemented in Matlab?
But what Perl is to text processing, Python is to collections, and VB is to slinging together a GUI, Matlab is to numerics (what used to be FORTRAN libraries) -- it may not have the best algorithms, but it has a lot of algorithms -- it has a semi-decent scripting language, and it has some facility with producing plots from your computations and other data.
Now that's the thing -- if you are doing matrix operations or using some canned function (most likely C under the hood), Matlab is as fast as fast can be. The minute you start looping in Matlab, it is interpreted and the speeds are in the Python range.
Before you knock it completely, it has very good integration with Java modules -- more seamless than with C modules. While Java may be pokey for its GUI, for tight numeric loops the JIT is almost as fast as C -- no joke, a person should consider writing numeric extensions to Matlab in Java of all things, especially on Windows where they tweaked up Java 1.4.2_03. And how many scripting languages (OK, Jython) have this level of Java integration?
But as a scripting language, Matlab has its shortcomings. It started out as a matrix calculator and has had features grafted on in a hodge-podge Visual Basic 6.0 kind of way. In terms of its data type restrictions and fubar scoping rules and brain-dead object extensions, I don't think, as they say, it scales very well.
My other peeve is that it is proprietary, and while Math Works is not Microsoft, I worry if engineering schools, emphasizing use of "commercial packages students will use in the real world when they graduate" (as opposed to professors dinking around with their homebrew software for use in instruction), are becoming trade schools shilling for the big software houses. I don't have a lot of experience with it, but in place of Matlab we should be using stuff like Python and the Python NumPy extension -- Open Source alternative, comparable performance, C extensions for speed, but much more Turing complete, consistent, and scalable.
And where is Matlab 6.5 using Java internally? Try doing a Files Open to start editing a Matlab script (M-file) with the Matlab editor window. One potato, two potato, three potato, and the window comes up. Now what language has that kind of GUI lag, I wonder what it could be?
A lot of the discussion has centered around Grandma or Uncle Fred finding Linux friendly enough to do e-mail/Web browsing/images from digital camera kind of stuff. What about developers, big and small? A lot of the usefulness of Windows is that you have developers big (MS Word) to small (some guy in Texas selling me a program written in Visual Basic that allows me to use a laptop to read the "service engine soon" trouble codes from the OBDC-II plug under the dash of my Taurus).
I got into developing for Windows by way of DOS, and my interest is in acquiring lab measurements from A/D converters and displaying results in real time or near real time. What I am doing is a tiny, tiny niche, but the PC accomodated many of these tiny niches to add up to a big whole.
DOS and PC's were definitely the way to go -- they were the PDP-11's of the 80's and 90's -- you had A/D cards for the PC bus available from several manufacturers, and as far as drivers, what drivers? Here are the I/O ports that control the card, and hey, with Turbo Pascal or with Quick Basic, you could poke and peek those ports and you were in business.
The switch to Windows was a natural progression, although DOS is much better for real time of any sort because you have control over all of the interrupts. His Billness made a big, big push to bring the DOS game development community over to Windows with WinG followed by DirectX. A real time lab data display program is kind of like a video game, and some of the obscure Windows and later DirectX calls meant to support certain types of games (ScrollWindowEx(), IDirectDraw::WaitForVerticalBlank()) helped a lot for what I was doing. As for the A/D converter I/O ports, those became a thing of the past because any A/D card company wanting to serve the Windows market provided Windows drivers.
So in going from DOS to Windows, one went to a higher level of abstraction, trading I/O ports for some hardware manufacturer's drivers, trading direct writing to the VGA frame buffer for GDI and DirectX. But the abstractions provided by Windows were far from easy to use, and a great deal of effort went into understanding them, working around the bugs in them, and burrowing into the Windows API to wring out performance.
So I am interested in programming for Linux. A/D and graphics is also handled by abstractions here, a lot of these abstractions are different from what I am used to, and the abstractions are a patchwork (Qt, GTK, STL -- I am in buzzword mode because I haven't used any of these, but I get the sense there is a lot of figuring out in terms of what to even invest development effort in).
So I am thinking, I could bet on Linux as the Next Best Thing and learn API's at the level that I know Windows API's, or I could, hey, go to another level of abstraction and go for something like Java, Python with wxPython plus C++ modules for speed tuning, or perhaps something else. Just as going from DOS to Windows left ports and frame buffers behind, I am thinking that the next step is to leave OS-specific abstractions behind, whether they are Windows API's or Linux API's.
My point is this: WINE is pointed to as a non-solution to Linux ascendency as all the interesting apps will still also run under WIndows. Isn't platform independent (as with Java or wxWindows or wxPython) also a non-solution? If I am to write for Linux and use Linux APIs to build more powerful programs than what the lowest-common denominator platform-independent stuff is capable, what are the Linux equivalents to ScrollWindowEx() and IDirectDraw:WaitForVerticalBlank()? Or does Linux even have such calls as they are only part of Windows as part of an MS initiative to pry game developers from Windows? What API goodies does Linux have to pry game developers from Windows?
I heard a similar thing was responsible for famine in the early days of Mao's China. There, the commissars (or whatever they were called in Chinese Socialism), who wanted to get promoted, kept making inflated promises about production, and they shipped food to meet those quotas, stripping the countryside of the food to keep people from starving. The people at the top were only getting filtered reports while the people at the bottom starved.
Yeah, so Brooks tells us "prepare to throw one away", that your first system is a prototype that gets scrapped when you do the real system. But then he says people get cocky that they know how to live life over and not make the same mistakes the second time around, and second systems are overwrought. Dunno.
Part of the power of C (as in Kernighan's "Why Pascal is not my favorite language") is the duality between pointer and array and the frequent lack of compile time restrictions on the array length. With a little pointer arithmetic, you can easily access subsections of arrays with whatever offset and length you feel like.
Since we are on the subject of tags, putting a tag on every scalar datum seems like a waste of memory and address space, but putting a few tags on an array doesn't seem like a big deal. Instead of an array being , an array could be , and this triple could be set 1) when you dynamically allocate an array, and 2) when you "cast" the array by taking a subslice of it. The bounds checking can be coded efficiently by an optimizer that knows about loop variables and such.
I suppose you could do something like this in C++ with a template class and the proper inlining and such (is an STL vector reasonably efficient?), but I don't know if the compiler can optimize out the bounds checks. I would think you would have to make this kind of array a language feature rather than a template-class implemented language extension to get best efficiency.
Most of what they have in.NET is just repackaging of J++. J++ languished because true Java dudes didn't want to be polluted by it and VBers had little interest in it. But J++ was everything VB is in terms of RAD development and the so-called Visual C++ is not, and it was a C-syntax language with a JITed interpreter to boot.
But if.NET really catches on (yeah, yeah Longhorn, but to echo a familiar refrain, where are the shrink-wrap apps? When is MS going to eat their own dogfood on this one?), someone should run a copy of J++ in a museum exhibit somewhere (it is perhaps like the Lisa to the Mac that finally caught on).
That's the point -- the time slice on Windows can be quite coarse grained (10's of ms), and if you depend on preemption, you won't get any kind of smooth screen updates or not-dropping of packets or whatever is required. Even though it is a preemptive multi-tasking system, you end up using it as a cooperative multi-tasking system where threads yield to other threads -- you use synchronization primitives as an efficient way of dispatching among multiple threads in coroutine fashion.
If you invoke a synchronization primitive that blocks, of course you are going to yield to another thread, whether it is on another processor or not. If you do Sleep(1) (I mispoke calling it Wait() -- it is called Sleep()), that blocks because you have to wait 1 ms. If you do Sleep(0), that is supposed to block for the remainder of the time slice, but it doesn't on SMP/hyperthreaded systems, and I wonder how many people out there have also lost hours of sleep because MS wouldn't document this.
I presented 5 teams and 7 languages as a strawman argument. I am advocating that I develop applications or applications as a collection of software modules in the language I work with best, and I offer clients developing extensions using those modules the option of using whatever (one) language they work with best. It seems every time I advocate this approach people, come back at me with the "5 teams and 7 languages" as a bad way to develop systems -- that is not why I want multi-language.
SUN and Java is in the one language is all you need for anything camp. Python is perhaps in the 2-language camp -- use Python for scripting, extensions, and even for major parts of the system, use C/C++ for core modules.
.NET is sort of in the multi-language camp -- I would argue that VB.NET is a peace offer to the PHBs. I am not a VBer apart from having used it to see that my ActiveX widgets work in VB OK. But I know some VBers, and there is a remarkable lack of enthusiasm to upgrade to VB.NET. If you have ever seen Java, C# is no big deal, but VB.NET is an enormous shift, and it is not just that VBers don't want to learn new tricks -- I told that some features of VB 6 are no longer there.
When Borland came out with their Kylix/C++ Builder IDE's for Windows/Linux, for whatever reason they went with Qt+ instead of GTK. So what they had to do was write this massive procedural front end to Qt+ so they could get at it from Object Pascal -- object references are not passable over the divide so they had to turn everything back to handles and function calls.
Oh, and the IDE runs under WINE.
For a variety of technical and cultural reasons it seems that Kylix hasn't caught on. On the cultural side, I suppose there aren't many Linux/UNIX programmers craving a Pascal IDE and on the Windows side, there are not that many Delphi developers hankering to use Linux. On the technical end, it seems that Borland is using Java to make their IDE's portable (the X-series -- C++ Builder X, JBuilder X -- are Java Swing IDEs), and there is some hint that they are looking at wxWindows for GUI app portability (they have a toe in the water with some "preview" level of wxWindows support in C++ Builder X).
OK, you are doing all this calculation in another thread, but you have to somehow synchronize with the GUI thread (PostMessage under Windows). If your calculation thread were to run faster than your GUI thread (GUI doing a lot of screen updating), you would get these PostMessages clogging up your GUI thread message queue because WM_PAINT is of very low priority (so frequent paints don't lock out key and mouse clicks).
In the old single-processor days, your calc thread could do a Wait(0) -- according to the Windows docs, this yields all of the calc thread's remaining time slice to blocked threads, like the GUI thread holding WM_PAINT in its queue. In these modern hyperthreaded times (I imagine true SMP works the same way), Wait(0) does nothing because the calc thread does not block when the GUI thread is on another virtual or real processor, and the screen updates gum up and get all blocky.
The solution I use is that when the GUI thread services a PostMessage from the Calc thread, it runs the message pump to check for and dispatch WM_PAINTs -- a kludge to give the PostMessage from the calc thread lower priority than WM_PAINT. But in the mean time I am cursing a blue streak that MSDN cannot document that Wait(0) is essentially meaningless with more than one processor and I have spend two weeks tearing my hair out about what is going on.
Multi-language capability gets slammed with the argument that 5 different programming teams within an organization are going to write in 7 different languages, and how do you maintain that mess. To me, multi-language means I write the app in whatever language suits me, and users of my app write scripts and extensions in whatever language suits them.
COM/ActiveX works swimmingly in this regard in that you have a choice of languages for both producing and consuming COM/ActiveX components, and COM allows you to pass object references across the barrier while ActiveX allows you to work with GUI widgets in this way. And it is true multi-language, not the fake multi-language of the.NET languages.
On the other hand, COM/ActiveX pretty much limits you to Windows, you have to be careful of the lowest-common-denominator effect of which COM data types work in which languages (the more restrictive set of "Automation" types compared to the wider set of C-compatible types and a more restrictive situation for scripting languages and Web browsers than with Visual Basic 6). Also, COM/ActiveX can get ugly in some environments (C++ and MFC/ATL -- you are really stuck taking the Wizard-generated code at face value unless you really know what you are doing), and as a component developer you have to pick up some IDL basics.
Is there anything out there that even comes close? With the Python/C-C++ meld, you are pretty much restricted to Python on one end and C++ on the other hand, and the C++ end is, shall we say, a bit lower level than the Python end, although there are things like SWIG that look amazingly like, hey, IDL and Visual Studio Wizard code.
Another thing I have looked into is the Matlab-Java meld -- a lot of academic engineer and scientists use Matlab as their all-purpose scripting tool, but I wouldn't want to develop high power apps in it. The Matlab-Java meld is surprisingly clean, the Java side can be a Swing app and it runs in its own Swing windows. Again, you are restricted to Matlab on the scripting side, Java on the custom app side, but the interesting thing is that it is pointedly the sort of thing SUN isn't interested in. According to the SUN world view, Java is everything you would ever need and the idea of scripting Java from anything else doesn't enter into their universe.
Is there anything else out there that scripts Java? I suppose there is Jython. Anything else?
I'll leave HIV/AIDS skepticism for another time -- I want to talk Gilbert Levin.
I find Gilbert Levin topical on account of the Spirit Mars Rover and what kind of experiments are not on it and what kind of experiments were on Beagle 2 (I am hoping some British dude announces recovery of that lander and says "I'm not quite dead yet!")
Levin started his career as an environmental engineer (i.e. sewage plant specialist). One of the things you need to do to properly operate a sewage treatment plant is rapidly determine what kind of bugs you have in the system and what kind of bugs you have in the effluent discharge. The conventional approach is to have some kind of growth medium (like agar plus nutrients), to "streak" a growth plate with a wire dipped in the water you want to assay for bacteria, and then wait a couple days and count bacteria colonies.
All of that takes time. Gilbert Levin's engineering contribution was to use a radioactive growth medium, and to use a Geiger counter to count the radioactive tiny bubbles given off when the bugs metabolize the food and fart CO2 or other gasses. The technique was a breakthrough because it can assay bacteria counts very fast and at very low levels -- you don't have to wait for colonies to form, and you can detect ridiculously low levels of the metabolized radioactive gas. He formed a company called Biospherics (now Spherix) to market this invention.
Anyway, when NASA got in the business of finding life on Mars, Levin had some engineer friends who introduced him to the right people, and his technology for detecting very low levels of life got NASA people interested in his method. Along the way he went back to grad school to get a PhD -- his union card to be PI on one of the Viking life detection experiments.
Well, both Vikings landed and each lander ran three life detection experiment. You all can correct me, but I believe one experiment was a mass spec to detect carbon compounds, one was a robot version of streaking plates, and the third was Gilbert Levins Labeled Release (LR). Two of the experiments came up zilch, but Levin's experiment detected life according to the previously agreed upon protocols.
The scientific consensus that emerged was that life was not detected and the LR result was a fluke, the result of chemical compounds mimicing a life signature. If there was life, it was at extremely low levels that LR could pick up but that the other two methods would not. Levin originally was resigned to this conclusion, but some years later he had a change of heart and has been lobbying NASA to run another LR experiment, this time with chiral (you know, like left handed sugar makes you fat, right handed sugar goes right through you) growth medium. NASA has been ignoring him all these years and pointedly not putting any life detection equipment on any Mars mission, and they are making a big deal that they are searching this time for water before they fly another life experiment.
The real case against life is the Gaia Hypothesis. The idea is that if there were life on Mars, it wouldn't be hanging on by its fingernails, rather, it would modify its environment so it would be present in abundance and wouldn't be hard to find at all. That the surface of Mars is bathed in ultraviolet light that would clean sterilize and Earth organisms and that a mass spec can't find any carbon compounds to radio home about suggests that Mars life is not modifying the atmosphere to protect itself and is far from abundant if it exists at all.
The counter to the Gaia hypothesis is that life is being discovered on Earth, deep in rocks, on the Antarctic ices, and suspended in water otherwise regarded as pure, and techniques such as LR make such detections possible -- there are ecological niches where life exists on Earth in low concentrations under harsh conditions and hanging on by the fingernails. Anyway, Levin convinced the Russians to fly the chiral LR experiment on Mars 2, which ended up in the Pacific Ocean when the Proton rocket
Five taboo hypotheses in science
on
What You Can't Say
·
· Score: 2, Interesting
1) We will not run out of oil within the 21st century,
2) human activity is not and will not under current trends measureably change global climate,
3) dietary fat is not a leading cause of cardio-vascular disease,
4) there is life on Mars and Gilbert Levin discovered it with the LR experiment on the Viking lander,
and
5) HIV does not cause AIDS.
I mention these five ideas because there is a broad-based scientific consensus that each of these ideas is false but there are a small number of persons who are not frauds or crackpots who present arguments for each of these ideas, but anyone arguing any of those positions is pretty well marginalized by the scientific establishment.
Not only that, advocating any of these above ideas will not lead to any reasoned discourse but will result in a ratcheting of emotions and people starting to rant, sputter, leaflet, shout down speakers. I left out UFOs, ESP, and cold fusion because there was a time when science was actually open-minded about each of those topics, but UFOs, ESP, and cold fusion have gotten shot down on the evidence so many times that they are now in the realm of faith for their believers.
The five topics I have mentioned haven't been played out yet (we haven't run out of economic oil yet, the putative anthropormorphic global warming is still small, we don't yet have Mars samples in Earth laboratories). Also, there has to be some sense of doubt in the pleaders for the scientific consensus positions on each of the five topics, otherwise they wouldn't be using the language of taboo around these topics (the notion that taboos form around topics of which we are certain, but not so solidly certain).
Of course, if I am moderated Troll or Flamebait, or if replies to this post call me names, I will have evidence supporting my hypothesis. Each of the five statements is by itself a hypothesis and will be eventually proved or disproved (whether we make it 100 years without exhausting oil or not), and there are arguments to be marshalled on both sides of each of the statements.
I am with a university lab that started out with a VAX controlling our main experiment and made the transition to SUN 2 (and later SUN 3) and Unix. The Unix world was mainly C and C source code compatibility, and the way you looked at data collected from your experiment was to hire programmers to write your own display and data crunching software for X-Windows. We bought SUNs from Motorola through Intel and stopped short of SPARC. Then the bottom dropped out of our funding (can you say Gramm-Rudman-Hollings? I thought you could!).
What got chopped from the budget were programmers -- they cost 2-3 times more than scientists because you didn't need to support the scientists 100 percent because the scientists could hold faculty jobs and teach courses. We couldn't upgrade to SPARC because we could afford the boxes, but we couldn't afford the people who knew how to recompile the sources. Our data visualization/analysis stuff all went over to PCs and Windows.
There is this other lab on campus doing physics experiments. Here are all these high-power magnets people, EM fields people, plasmas people. When they power up their experiment, it is like Mission Control -- they have a whole bunch of computer stations tended by grad students: each grad student is monitoring some separate variable or measurement.
The experiment is pulsed, so every time they do a "shot", they collect a burst of data with multi-channel A/D's, and what are these work stations running? They are all PCs running Windows running Matlab, and each grad student has written their own Matlab scripts to visualize the data burst they are responsible for. Just like Mission Control, the grad students are polled about how the run went, and the fire the next shot and collect another data burst.
Yeah, yeah, you can get Matlab for various Unix systems, but the point of this is the big success of PCs and later Windows is that they are binary standards running binary-distributed commercial software, and the cost of the commercial licenses is peanuts compared to the cost of paying people who would know how to compile stuff from source let enough roll your own software these days.
Oh, and back at our lab, our engineer guys (yeah, we laid off the programmers, and the engineers are just as costly, but the engineer guys keep the experiment hardware running and configure PC systems and write VB software on the side -- they do multiple jobs while the software guys seem to have some kind of union about what they can do), anyway, our engineer guys thought they would bring up Linux on a spare PC. The idea was that if the grant melted down, the engineer guys could put Linux on their resumes in looking for jobs.
Remember, we were once a Unix shop that went to PCs in pursuit of the commercial software packages. The Linux experience didn't go anywhere over, yup, the driver issue. We sent two of our guys to a Linux short course, they got Linux up alright, but they never got it connected to the network. Oh, and the engineer guys had all this other stuff they were supposed to be doing and never got back to this Linux business.
I am responding positively to your post -- you don't need convincing, but I don't have my flame-resistant suit if I responded negatively to one of your critics. I mean, here we are discussing whether the market penetration of Linux is stalled, you say it is because of driver API's, and a bunch of guys pile on with this business of Open Source purity.
A person can have Open Source purity up to here, but even if you had the source, a lot of your customers don't want to deal with building from source, and your critics would call the guys who don't know their way past Windows to a Unix command line lusers (around here we call them Professor and these are the guys who write the proposals that bring in the funding), and the fact that you got jumped on for suggesting something as basic as a stable API for binary distribution of drivers suggest that Cringely and other crystal ball gazers are spot on about the Linux revolution being stalled.
Yes, I am a believer in defensive programming, but I am not sure that defensive programming is the golden hammer. Verity Stob made a remark about taking a sick program and filling it with try-catch blocks to try to recover from every possible error condition -- I believe she called it "nailing a corpse on a tree" or some such thing. And her other remark was "the only place we seem to get exceptions is in destructors, so what's the point?" That had me on the ground in tears of laughter because destructors (freeing up resource in the right order) is one of the hardest things to get right.
Ok, every last subroutine validates every last input. Then what do you do? Suppose an input is invalid -- do you halt? Throw and exception? Patch the input and keep going? Keep going but make an entry in a log file?
It is excellent policy to be ultra paranoid about user input and to put "firewalls" between major program modules. But for every last subroutine to have its own error checks -- what if you have a top level subroutine that performs error checks and than passes validated results to helper subroutines? Do the helper subroutines need to repeat the checks?
I think there has to be some analysis of the data flows and designation of raw and filtered data flows, who does the filtering, and what assumptions or assertions can be made about filtered flows, and assignment of responsibility to do the checking.
In summary 1) defensive programming is not a substitute for good overall design, 2) there is a place for delegating responsibility for error checking and not chronically worrying about checked data.
Why is the heck would the Russians want smallpox or any other bioweapon on an ICBM (I heard Ken Alibek on TV suggesting that it was for ICBM's)? I can understand a nuke because besides killing people, a nuke can take out fortified sites and infrastructure and impair the ability to fight back. Also, a modern ICBM has a high speed pointy-end forward reentry vehicle, unlike the blunt RV's of early RV's. The blunt body RV has less of a heat shield requirement, but its rapid deceleration and slow entry hurts accuracy and makes it vulnerable to anti-missile defense. So if you have a high speed RV, how the heck do you even dispense a biologic agent that it does much harm?
Also, a biologic agent takes hours if not days to act, allowing for retaliatory strikes, so a biologic ICBM is clearly a kind of Doomsday Machine -- what is to say that the smallbox doesn't spread back to Russia. And you have such a Doomsday Machines, in the words of Peter Sellers, why don't you advertise it to the whole world? What good is a Doomsday Machine that you keep secret?
Slashdot Mirror
Zaphod, on the other hand, has to be an American. I always thought that Zaphod was a British take on American assertiveness.
Now how are the suits at Disney (B-Ark people, at best) supposed to understand any of this to convey it in the movie. It is just going to be one grand adventure like their take on Inspector Gadget and all of the satire will be lost in translation.
But Matlab has a cool way of using Java objects, and Java objects have a less-fuss connection to Matlab than MEX-C++. And for tight loops in pure numerical code, Java oddly enough is actually pretty efficient.
JNI also lets you create and operate on Java objects just like Matlab does -- you have to load a VM into your process, but hey, that is what invoking "java myclass" at the command line does. As a vehicle for creating plugins for a C++ program, Java .class files are much more compact than .dll files which tend to link in so much extra . . . stuff.
The JNI is really meant for Java calling into C/C++ to get at some low-level system stuff, but it allows C++ to call Java -- it has to have this capability for the low-level C++ system routine to get stuff back from the Java environment.
Does Mono support C++ calling a C# module? I know there is a MS/VS.NET solution for this, and it is a lot cleaner than JNI. All you need to do is use VS.NET to build an "unmanaged" (i.e. ordinary Windows app) C++ program, and then you need to use some kind of GCHandle template class to take care of the reference into managed code, and then you just invoke methods off that handle as if it were managed C++.
Given that the Mono project doesn't quite have the ambition to make everyone use C# everywhere for every last thing, and given cross-language development (Python-C++, etc) is getting a lot of attention, is there a Mono solution to this? You know, if you could call C# from C++, you could just as well call C# from Python by having a C++ module in the middle. Is there any interest in this capability?
I mean, how many value types are there already? So you get a couple instantiatians of the class instead of one. And if you are really worried about footprint, you can use only reference types in your list.
We are supposed to recycle -- under penalty of law, but the most serious penalty I have seen is that the city workers are "empowered" to slap a bright orange stickers on piles of cardboard left by students at the U during moving day if they didn't bundle such piles to the satisfaction of the city workers. We have to recycle aluminum, glass, newspapers, cardboard, and number 1 and number 2 plastic, although there is a list as long as your arm of non-acceptable number 1 and number 2 containers. Oh, and we have to recycle tin cans.
Mr. Recycleman (not his real name, but ironically close to it), the city dude in charge of garbage, got on the TV to mention the benefits of recycling, including that all those tin cans are made into new cars.
Is this the real deal or one of those enviro-fibs? I thought that steelmaking for cars, or at least what the Japanese were doing, was almost as fussy in its control over trace impurities and alloy levels as semiconductors, because they were making a very low carbon steel that they could bond with zinc rustproofing and then stamp or otherwise form into very thin and curved sections that make up modern lightweight, fuel efficient, crash resistant, rust resistant cars. I thought the only thing tin can scrap was good for was rebar -- you could make the road the cars ride on but certainly not the cars themselves.
So why do we have to recycle tin cans? They are a PITA to get clean enough to stockpile enough to set out for recycling (the stuff that comes in them turns into very rank garbage if not cleaned up -- spaghetti sauce, canned soup, and so on). If they were really so valuable, couldn't they be picked out of the garbage stream with a magnet?
I heard that the only thing that makes money recycling is the aluminum can, and we wouldn't need the second green garage truck, it would pay to take them to a drop off center for cash. It was also suggested that the reason for recycling this other stuff was to get homeowners in the habit in case some kind of other markets developed. I think the other than aluminum recycling is a big scam, but I suppose I could be educated if someone has some other insights on this.
Don't know if there was anyone like that in NASA. Max Faget has been called the American Korolev, but I don't think we was anything like a "Chief Designer" in terms of the scope and breadth of jobs he had to take on -- I always thought NASA had a layer of management and administration even on top of their most gifted technical people so those technical people wouldn't get bogged down.
Maybe the closest to an American Chief Designer would have been Clarence "Kelly" Johnsons of Skunk Works fame.
When one of my colleagues, one of those "stinkin' Mac users" from the famous Dilbert cartoon, started sending me Word docs, I had to beg or borrow a copy of Word and get used to it fast. At the time Word Perfect was a lot better in many ways -- figure layout was much less brain dead.
What sealed the deal and sealed the fate of Word Perfect was that our U became part of a statewide Microsoft site license. Funny thing, the site license was only with MS, but all kinds of talk about going around "auditing" faculty computers kind of disappeared after that.
In 2003, the U and the State decided not to renew the deal because MS started getting greedy. I am trying to get used to Star Office -- heck if I used Word Perfect, switched to MS Office, what is the big deal running Star Office? But our lawyers tell us we can still run "legacy" versions of MS stuff at work -- just no upgrades without paying for individual licenses -- so it may be awhile before Star Office gets traction.
Your EE or ME or ChemE full professor as a grad student could have written a FORTRAN program to compute some stuff and write output to a numeric text file or perhaps draw some plots using a subroutine library. You are probably thinking that anyone who can't sling together C programs using VI to draw graphics straight to X is a luser, but I am talking about pretty technically savy people who don't have time to spend on this stuff and who employ armies of Engineering majors from foreign lands who are not up on this stuff either.
My own take is that if a particular numerical calculation can be easily programmed by some package, it must not be on the cutting edge of research because someone has already done it. Besides, if your software package is really deep, most of the effort goes into the architecture and the data flows and into graphics, and the RAD bit is only simplifying a tiny part of what you are spending your time. A high-power scientific data visualization is really a video game, and how many video games are implemented in Matlab?
But what Perl is to text processing, Python is to collections, and VB is to slinging together a GUI, Matlab is to numerics (what used to be FORTRAN libraries) -- it may not have the best algorithms, but it has a lot of algorithms -- it has a semi-decent scripting language, and it has some facility with producing plots from your computations and other data.
Now that's the thing -- if you are doing matrix operations or using some canned function (most likely C under the hood), Matlab is as fast as fast can be. The minute you start looping in Matlab, it is interpreted and the speeds are in the Python range.
Before you knock it completely, it has very good integration with Java modules -- more seamless than with C modules. While Java may be pokey for its GUI, for tight numeric loops the JIT is almost as fast as C -- no joke, a person should consider writing numeric extensions to Matlab in Java of all things, especially on Windows where they tweaked up Java 1.4.2_03. And how many scripting languages (OK, Jython) have this level of Java integration?
But as a scripting language, Matlab has its shortcomings. It started out as a matrix calculator and has had features grafted on in a hodge-podge Visual Basic 6.0 kind of way. In terms of its data type restrictions and fubar scoping rules and brain-dead object extensions, I don't think, as they say, it scales very well.
My other peeve is that it is proprietary, and while Math Works is not Microsoft, I worry if engineering schools, emphasizing use of "commercial packages students will use in the real world when they graduate" (as opposed to professors dinking around with their homebrew software for use in instruction), are becoming trade schools shilling for the big software houses. I don't have a lot of experience with it, but in place of Matlab we should be using stuff like Python and the Python NumPy extension -- Open Source alternative, comparable performance, C extensions for speed, but much more Turing complete, consistent, and scalable.
And where is Matlab 6.5 using Java internally? Try doing a Files Open to start editing a Matlab script (M-file) with the Matlab editor window. One potato, two potato, three potato, and the window comes up. Now what language has that kind of GUI lag, I wonder what it could be?
I got into developing for Windows by way of DOS, and my interest is in acquiring lab measurements from A/D converters and displaying results in real time or near real time. What I am doing is a tiny, tiny niche, but the PC accomodated many of these tiny niches to add up to a big whole.
DOS and PC's were definitely the way to go -- they were the PDP-11's of the 80's and 90's -- you had A/D cards for the PC bus available from several manufacturers, and as far as drivers, what drivers? Here are the I/O ports that control the card, and hey, with Turbo Pascal or with Quick Basic, you could poke and peek those ports and you were in business.
The switch to Windows was a natural progression, although DOS is much better for real time of any sort because you have control over all of the interrupts. His Billness made a big, big push to bring the DOS game development community over to Windows with WinG followed by DirectX. A real time lab data display program is kind of like a video game, and some of the obscure Windows and later DirectX calls meant to support certain types of games (ScrollWindowEx(), IDirectDraw::WaitForVerticalBlank()) helped a lot for what I was doing. As for the A/D converter I/O ports, those became a thing of the past because any A/D card company wanting to serve the Windows market provided Windows drivers.
So in going from DOS to Windows, one went to a higher level of abstraction, trading I/O ports for some hardware manufacturer's drivers, trading direct writing to the VGA frame buffer for GDI and DirectX. But the abstractions provided by Windows were far from easy to use, and a great deal of effort went into understanding them, working around the bugs in them, and burrowing into the Windows API to wring out performance.
So I am interested in programming for Linux. A/D and graphics is also handled by abstractions here, a lot of these abstractions are different from what I am used to, and the abstractions are a patchwork (Qt, GTK, STL -- I am in buzzword mode because I haven't used any of these, but I get the sense there is a lot of figuring out in terms of what to even invest development effort in).
So I am thinking, I could bet on Linux as the Next Best Thing and learn API's at the level that I know Windows API's, or I could, hey, go to another level of abstraction and go for something like Java, Python with wxPython plus C++ modules for speed tuning, or perhaps something else. Just as going from DOS to Windows left ports and frame buffers behind, I am thinking that the next step is to leave OS-specific abstractions behind, whether they are Windows API's or Linux API's.
My point is this: WINE is pointed to as a non-solution to Linux ascendency as all the interesting apps will still also run under WIndows. Isn't platform independent (as with Java or wxWindows or wxPython) also a non-solution? If I am to write for Linux and use Linux APIs to build more powerful programs than what the lowest-common denominator platform-independent stuff is capable, what are the Linux equivalents to ScrollWindowEx() and IDirectDraw:WaitForVerticalBlank()? Or does Linux even have such calls as they are only part of Windows as part of an MS initiative to pry game developers from Windows? What API goodies does Linux have to pry game developers from Windows?
I heard a similar thing was responsible for famine in the early days of Mao's China. There, the commissars (or whatever they were called in Chinese Socialism), who wanted to get promoted, kept making inflated promises about production, and they shipped food to meet those quotas, stripping the countryside of the food to keep people from starving. The people at the top were only getting filtered reports while the people at the bottom starved.
Yeah, so Brooks tells us "prepare to throw one away", that your first system is a prototype that gets scrapped when you do the real system. But then he says people get cocky that they know how to live life over and not make the same mistakes the second time around, and second systems are overwrought. Dunno.
Since we are on the subject of tags, putting a tag on every scalar datum seems like a waste of memory and address space, but putting a few tags on an array doesn't seem like a big deal. Instead of an array being , an array could be , and this triple could be set 1) when you dynamically allocate an array, and 2) when you "cast" the array by taking a subslice of it. The bounds checking can be coded efficiently by an optimizer that knows about loop variables and such.
I suppose you could do something like this in C++ with a template class and the proper inlining and such (is an STL vector reasonably efficient?), but I don't know if the compiler can optimize out the bounds checks. I would think you would have to make this kind of array a language feature rather than a template-class implemented language extension to get best efficiency.
I think the post was an oblique reference to the movie Total Recall, where there was a 3-breasted mutant.
But if .NET really catches on (yeah, yeah Longhorn, but to echo a familiar refrain, where are the shrink-wrap apps? When is MS going to eat their own dogfood on this one?), someone should run a copy of J++ in a museum exhibit somewhere (it is perhaps like the Lisa to the Mac that finally caught on).
If you invoke a synchronization primitive that blocks, of course you are going to yield to another thread, whether it is on another processor or not. If you do Sleep(1) (I mispoke calling it Wait() -- it is called Sleep()), that blocks because you have to wait 1 ms. If you do Sleep(0), that is supposed to block for the remainder of the time slice, but it doesn't on SMP/hyperthreaded systems, and I wonder how many people out there have also lost hours of sleep because MS wouldn't document this.
SUN and Java is in the one language is all you need for anything camp. Python is perhaps in the 2-language camp -- use Python for scripting, extensions, and even for major parts of the system, use C/C++ for core modules.
Oh, and the IDE runs under WINE.
For a variety of technical and cultural reasons it seems that Kylix hasn't caught on. On the cultural side, I suppose there aren't many Linux/UNIX programmers craving a Pascal IDE and on the Windows side, there are not that many Delphi developers hankering to use Linux. On the technical end, it seems that Borland is using Java to make their IDE's portable (the X-series -- C++ Builder X, JBuilder X -- are Java Swing IDEs), and there is some hint that they are looking at wxWindows for GUI app portability (they have a toe in the water with some "preview" level of wxWindows support in C++ Builder X).
In the old single-processor days, your calc thread could do a Wait(0) -- according to the Windows docs, this yields all of the calc thread's remaining time slice to blocked threads, like the GUI thread holding WM_PAINT in its queue. In these modern hyperthreaded times (I imagine true SMP works the same way), Wait(0) does nothing because the calc thread does not block when the GUI thread is on another virtual or real processor, and the screen updates gum up and get all blocky.
The solution I use is that when the GUI thread services a PostMessage from the Calc thread, it runs the message pump to check for and dispatch WM_PAINTs -- a kludge to give the PostMessage from the calc thread lower priority than WM_PAINT. But in the mean time I am cursing a blue streak that MSDN cannot document that Wait(0) is essentially meaningless with more than one processor and I have spend two weeks tearing my hair out about what is going on.
COM/ActiveX works swimmingly in this regard in that you have a choice of languages for both producing and consuming COM/ActiveX components, and COM allows you to pass object references across the barrier while ActiveX allows you to work with GUI widgets in this way. And it is true multi-language, not the fake multi-language of the .NET languages.
On the other hand, COM/ActiveX pretty much limits you to Windows, you have to be careful of the lowest-common-denominator effect of which COM data types work in which languages (the more restrictive set of "Automation" types compared to the wider set of C-compatible types and a more restrictive situation for scripting languages and Web browsers than with Visual Basic 6). Also, COM/ActiveX can get ugly in some environments (C++ and MFC/ATL -- you are really stuck taking the Wizard-generated code at face value unless you really know what you are doing), and as a component developer you have to pick up some IDL basics.
Is there anything out there that even comes close? With the Python/C-C++ meld, you are pretty much restricted to Python on one end and C++ on the other hand, and the C++ end is, shall we say, a bit lower level than the Python end, although there are things like SWIG that look amazingly like, hey, IDL and Visual Studio Wizard code.
Another thing I have looked into is the Matlab-Java meld -- a lot of academic engineer and scientists use Matlab as their all-purpose scripting tool, but I wouldn't want to develop high power apps in it. The Matlab-Java meld is surprisingly clean, the Java side can be a Swing app and it runs in its own Swing windows. Again, you are restricted to Matlab on the scripting side, Java on the custom app side, but the interesting thing is that it is pointedly the sort of thing SUN isn't interested in. According to the SUN world view, Java is everything you would ever need and the idea of scripting Java from anything else doesn't enter into their universe.
Is there anything else out there that scripts Java? I suppose there is Jython. Anything else?
I find Gilbert Levin topical on account of the Spirit Mars Rover and what kind of experiments are not on it and what kind of experiments were on Beagle 2 (I am hoping some British dude announces recovery of that lander and says "I'm not quite dead yet!")
Levin started his career as an environmental engineer (i.e. sewage plant specialist). One of the things you need to do to properly operate a sewage treatment plant is rapidly determine what kind of bugs you have in the system and what kind of bugs you have in the effluent discharge. The conventional approach is to have some kind of growth medium (like agar plus nutrients), to "streak" a growth plate with a wire dipped in the water you want to assay for bacteria, and then wait a couple days and count bacteria colonies.
All of that takes time. Gilbert Levin's engineering contribution was to use a radioactive growth medium, and to use a Geiger counter to count the radioactive tiny bubbles given off when the bugs metabolize the food and fart CO2 or other gasses. The technique was a breakthrough because it can assay bacteria counts very fast and at very low levels -- you don't have to wait for colonies to form, and you can detect ridiculously low levels of the metabolized radioactive gas. He formed a company called Biospherics (now Spherix) to market this invention.
Anyway, when NASA got in the business of finding life on Mars, Levin had some engineer friends who introduced him to the right people, and his technology for detecting very low levels of life got NASA people interested in his method. Along the way he went back to grad school to get a PhD -- his union card to be PI on one of the Viking life detection experiments.
Well, both Vikings landed and each lander ran three life detection experiment. You all can correct me, but I believe one experiment was a mass spec to detect carbon compounds, one was a robot version of streaking plates, and the third was Gilbert Levins Labeled Release (LR). Two of the experiments came up zilch, but Levin's experiment detected life according to the previously agreed upon protocols.
The scientific consensus that emerged was that life was not detected and the LR result was a fluke, the result of chemical compounds mimicing a life signature. If there was life, it was at extremely low levels that LR could pick up but that the other two methods would not. Levin originally was resigned to this conclusion, but some years later he had a change of heart and has been lobbying NASA to run another LR experiment, this time with chiral (you know, like left handed sugar makes you fat, right handed sugar goes right through you) growth medium. NASA has been ignoring him all these years and pointedly not putting any life detection equipment on any Mars mission, and they are making a big deal that they are searching this time for water before they fly another life experiment.
The real case against life is the Gaia Hypothesis. The idea is that if there were life on Mars, it wouldn't be hanging on by its fingernails, rather, it would modify its environment so it would be present in abundance and wouldn't be hard to find at all. That the surface of Mars is bathed in ultraviolet light that would clean sterilize and Earth organisms and that a mass spec can't find any carbon compounds to radio home about suggests that Mars life is not modifying the atmosphere to protect itself and is far from abundant if it exists at all.
The counter to the Gaia hypothesis is that life is being discovered on Earth, deep in rocks, on the Antarctic ices, and suspended in water otherwise regarded as pure, and techniques such as LR make such detections possible -- there are ecological niches where life exists on Earth in low concentrations under harsh conditions and hanging on by the fingernails. Anyway, Levin convinced the Russians to fly the chiral LR experiment on Mars 2, which ended up in the Pacific Ocean when the Proton rocket
Not only that, advocating any of these above ideas will not lead to any reasoned discourse but will result in a ratcheting of emotions and people starting to rant, sputter, leaflet, shout down speakers. I left out UFOs, ESP, and cold fusion because there was a time when science was actually open-minded about each of those topics, but UFOs, ESP, and cold fusion have gotten shot down on the evidence so many times that they are now in the realm of faith for their believers.
The five topics I have mentioned haven't been played out yet (we haven't run out of economic oil yet, the putative anthropormorphic global warming is still small, we don't yet have Mars samples in Earth laboratories). Also, there has to be some sense of doubt in the pleaders for the scientific consensus positions on each of the five topics, otherwise they wouldn't be using the language of taboo around these topics (the notion that taboos form around topics of which we are certain, but not so solidly certain).
Of course, if I am moderated Troll or Flamebait, or if replies to this post call me names, I will have evidence supporting my hypothesis. Each of the five statements is by itself a hypothesis and will be eventually proved or disproved (whether we make it 100 years without exhausting oil or not), and there are arguments to be marshalled on both sides of each of the statements.
What got chopped from the budget were programmers -- they cost 2-3 times more than scientists because you didn't need to support the scientists 100 percent because the scientists could hold faculty jobs and teach courses. We couldn't upgrade to SPARC because we could afford the boxes, but we couldn't afford the people who knew how to recompile the sources. Our data visualization/analysis stuff all went over to PCs and Windows.
There is this other lab on campus doing physics experiments. Here are all these high-power magnets people, EM fields people, plasmas people. When they power up their experiment, it is like Mission Control -- they have a whole bunch of computer stations tended by grad students: each grad student is monitoring some separate variable or measurement.
The experiment is pulsed, so every time they do a "shot", they collect a burst of data with multi-channel A/D's, and what are these work stations running? They are all PCs running Windows running Matlab, and each grad student has written their own Matlab scripts to visualize the data burst they are responsible for. Just like Mission Control, the grad students are polled about how the run went, and the fire the next shot and collect another data burst.
Yeah, yeah, you can get Matlab for various Unix systems, but the point of this is the big success of PCs and later Windows is that they are binary standards running binary-distributed commercial software, and the cost of the commercial licenses is peanuts compared to the cost of paying people who would know how to compile stuff from source let enough roll your own software these days.
Oh, and back at our lab, our engineer guys (yeah, we laid off the programmers, and the engineers are just as costly, but the engineer guys keep the experiment hardware running and configure PC systems and write VB software on the side -- they do multiple jobs while the software guys seem to have some kind of union about what they can do), anyway, our engineer guys thought they would bring up Linux on a spare PC. The idea was that if the grant melted down, the engineer guys could put Linux on their resumes in looking for jobs.
Remember, we were once a Unix shop that went to PCs in pursuit of the commercial software packages. The Linux experience didn't go anywhere over, yup, the driver issue. We sent two of our guys to a Linux short course, they got Linux up alright, but they never got it connected to the network. Oh, and the engineer guys had all this other stuff they were supposed to be doing and never got back to this Linux business.
I am responding positively to your post -- you don't need convincing, but I don't have my flame-resistant suit if I responded negatively to one of your critics. I mean, here we are discussing whether the market penetration of Linux is stalled, you say it is because of driver API's, and a bunch of guys pile on with this business of Open Source purity.
A person can have Open Source purity up to here, but even if you had the source, a lot of your customers don't want to deal with building from source, and your critics would call the guys who don't know their way past Windows to a Unix command line lusers (around here we call them Professor and these are the guys who write the proposals that bring in the funding), and the fact that you got jumped on for suggesting something as basic as a stable API for binary distribution of drivers suggest that Cringely and other crystal ball gazers are spot on about the Linux revolution being stalled.
Don't you mean power density (watts per cubic inch)? I would love to have a battery with the energy density of a nuclear reactor.
Ok, every last subroutine validates every last input. Then what do you do? Suppose an input is invalid -- do you halt? Throw and exception? Patch the input and keep going? Keep going but make an entry in a log file?
It is excellent policy to be ultra paranoid about user input and to put "firewalls" between major program modules. But for every last subroutine to have its own error checks -- what if you have a top level subroutine that performs error checks and than passes validated results to helper subroutines? Do the helper subroutines need to repeat the checks?
I think there has to be some analysis of the data flows and designation of raw and filtered data flows, who does the filtering, and what assumptions or assertions can be made about filtered flows, and assignment of responsibility to do the checking.
In summary 1) defensive programming is not a substitute for good overall design, 2) there is a place for delegating responsibility for error checking and not chronically worrying about checked data.
Also, a biologic agent takes hours if not days to act, allowing for retaliatory strikes, so a biologic ICBM is clearly a kind of Doomsday Machine -- what is to say that the smallbox doesn't spread back to Russia. And you have such a Doomsday Machines, in the words of Peter Sellers, why don't you advertise it to the whole world? What good is a Doomsday Machine that you keep secret?