Forwarded the link to a HAM buddy of mine (we recently did Field Day at Mt. Hood), and he sent an interesting reply...
(editted for brevity)
Now if you want to see a really cool portable station, check this out.... I e-mailed... to let him know how cool I thought this was. He replied it was photos of a guy he had known back in the 50's. The
trailer behind the car is a generator to power all the tube equipment. He
was running full power out of the car, 2,000 watts in those days. The
antenna was on a pneumatic mast that pushed up to 30 feet. The guy had added
extra leafs to the springs to support all the gear in the back of the car.
How cool is that?
The GPL motivates development because DEVELOPERS are enticed by the idea that derivatives of their code will REMAIN open, and that their projects will flourish.
It may be a retarded question, but not for the reasons you describe.
I've seen GPL projects that die because they target a commercial audience that won't touch a GPL. The GPL, in and of itself, is not going to spur development. And neither is the BSD.
BTW: theres a lot of non-GPL OSS out there
to choose from these days. I, for one, try
to avoid using GPL'd source as much as possible, simply to limit my exposure to its potential "virulent" impact. I develop truly free OSS (usually under a Common Public License, or an
Artistic License), as well as proprietary solutions.
I think the ultimate difference is the notion of truly free software, vs. the appearance of freedom. If you develop open source with the notion that a license is somehow going to cause your project to succeed by forcing those that want to use your code to keep the derivatives open, I'm afraid you're sadly mistaken. The scrupulous are likely to take a pass (there are usually nonGPL'd
solutions to most problems these days), while the unscrupulous don't care what license you use.
Tyranny, regardless whether monarchy, oligarchy, or communist dictatorship, is still tyranny.
Bottom line: if you want control, keep it closed, and don't call if "free". If you genuinely want to make a contribution, use some other license to eliminate liability, and learn to just let go.
To me, this is very telling about those engineers' beliefs and attitudes about their own code
I'd like to suggest that all those throwing stones
here take a reality and gut check.
Development at MSFT is a pressure cooker. Schedules tend to be pushed to the limits by low level mgmt whose own genitals are resting on the chopping block pretty much 24x7. So it shouldn't be terribly surprising that MSFT has quality issues. Code either gets pushed out the door, or people (and esp. managers) get fired. (Rumors are already circulating RE: the heads that have rolled due to the Longhorn debacle)
So if you were "treated" to the exersize of having someone waltz in and prove that your code is vulnerable, after you've been pushed to the wall for an extended period, I suspect you'd likewise feel more anger than shame, and probably a lot of
frustration, too. After all, most of us don't intend to write bad code, but when the gating QA factor is an overly aggressive date on a calendar, you'll have little opportunity to be concerned about hacks outside the acceptance test suite.
Most of the posts seem to suggest a big bang approach (diving into analog). While analog is
the interesting side, I'd suggest starting with a handful of simple logic chips, work up to a mux/demux, maybe build a little digital clock
(assuming old fashioned LED's can still be got).
The nice thing about digital is its predictability: when things don't work,
you can usually just review your schematic
and find the gate you didn't wire properly.
Analog can be a bitch goddess: variations in resistive, capacitive, and inductive tolerances for cheap components can lead to very different behaviors, and can lead to misbehaviors that are very frustrating to diagnose unless you have several $1000's worth of equipment at your disposal. If/when you get to that level, it can be very rewarding, but its the deep end of the pool, and the life preserver is pretty expensive.
As someone who has supported multiplatform s/w
that's hosted on
Win32
Linux (various, incl. PPC)
Solaris
AIX
HPUX
OS X
FreeBSD
MVS
OS/400
multiple other "minor" Un*x platforms
a Zaurus
a PocketPC
some routers running a proprietary kernel
...I call BULLSHIT!
The bugs one finds on "minor" platforms
usually end up being bugs on the "major" platforms
you just haven't found before. Of course, for those of you still intent on/forced to write code in C/C++, you're likely getting your just desserts.
Summer is upon us, Seattle's best time of the year,
sunny, warm, and green. If you're so hung up w/ that damn laptop that you can't shut it off, kick back with a tall iced sweet tea, and enjoy the weekend,
you shouldn't be allowed to enter the cafe, much less bogart the wifi.
More power to 'em. In fact, I'd suggest that anyone
entering w/ any electronic info device
(yes, including cellphones) on the weekend
be shown the exit and visited with a hail of derisive boos and laughter.
This "paper" (wasn't there one a couple weeks from some Microsoft dude, which was equally useless?)
I suspect you mean
this article by (the highly regarded) Jim Gray, whose opinion I'm much more inclined to seriously consider than the ramblings of the subject article's author (someone who, based on his company's product, apparently considers a B-Tree to be an innovative solution).
But I admit I found Gray's article equally disconcerting (perhaps he's been spending too much time on the sailboat in the SF Bay, and MSFT needed a shill to push their "XML Uber Alles" and
Longhorn vision?).
SQL has managed to overcome a lot of derision over the years, and, tho the language has often been a bit slow on the uptake, it has managed to adapt admirably to abstract datatypes, recursive queries, OLAP, etc. Perhaps as importantly, the 90's left us with empirical evidence that the
O-R juggernaut may have been ill conceived, with the failures of GemStone (which has since re-invented itself), and the disasterous impact of Informix's Illustra (nee Postgres) adventure.
Let's face it, SQL just works. Most people I've met who complain about SQL usually
(a) don't know how to tune a database and/or
(b) don't know how to properly use SQL and/or
(c) are stuck using a half-assed DBMS
There may be an inherent beauty/advantage to a declarative language, in that it can adapt to change by adding a few nouns, some adjectives and/or adverbs, and, as a last resort, one or two new verbs, rather than forcing a redefinition
of the entire language (C -> C++, COBOL -> ObjectCOBOL, etc.).
So, to paraphrase Twain, "The rumors of SQL's death have been greatly exaggerated."
Let's see, increasing prices in a dying industry. That makes a lot of sense, right?
One can only surmise that, given the usual bias
of NYT, they, like their DNC brethren, probably think the best way out of a recession is to raise taxes. I'm sure it makes perfect sense to the regular readers of their op-eds.
Thanks to all for the pointers, guess I need to
use better google search terms...
As to the purpose of the box, I can't say too much,
except its intended as a sortof main-memory database cache
solution (ala TimesTen)
to serve a potentially very large user base, with a lot of
cached images associated with the cached data.
I also considered a piecemeal commodity approach, e.g., filling
racks with cheap 4 gig RAM 1U's running Linux, but
then I'd have to come up with s/w that can coordinate
those systems (basically, a head-end to hash
the requests to the right 1U). memcached looks intriguing,
but I'm still concerned about interconnect latencies.
Based on my cocktail napkin
estimates, the h/w cost of a big RAM system (if it can be got)
would probably be about 2x the cost of the piecemeal system,
but hopefully signifcantly reduce interconnect latency, and
use simpler s/w (assuming I can get Linux to config a ramdisk
that big).
Since latency is the prime concern, solidstate disks using
the usual HD interconnects just didn't seem an acceptable
solution, esp since the cost reduction doesn't seem that significant.
As for failure recovery, my thoughts were just a couple fast
HDs that would ping-pong taking snapshots of the ramdisk;
hopefully, the ramdisk recovery would never lose more than an
hour's data (the lost data wouldn't be critical, and would be
recoverable from other sources...its really the delivery
speed thats essential)
But I may need to go back to my napkin and do some more
queueing analysis to see if there are better commodity
solutions.
When I first saw those ads, I had no idea it was for HGTG until they slammed the title in my face. It looks like a drug runner needed to launder a big chunk of cash and knew someone in the effects biz. And, in reality, the story shouldn't even need much in effects!
The BBC series did an admirable job with bad costumes and little or no budget. Only Hollywood could take perfect dialog and a great story and piles of cash and crank out a disaster.
Why so damned many complicated wrappers just to hide from SQL?
In my experience, the SQLphobia seems to derive from the following:
Using developers that simply don't know SQL, and aren't interested in learning (guess its not kewl anymore)
Using a DBMS w/ a half-assed SQL implementation
Developers that were raised on procedural languages, and just don't "get" declarative,
set-theoretic programming
Misapplication of SQL databases. Many of the SQLphobic applications really just need an indexed, journaled filesystem to temporarily save web form data. <insert favorite DBMS> just happened to be the solution at hand.
Case in point: I recently saw a post in another forum in which the OP opined they couldn't produce the actual SQL that the OR wrapper de jure was generating, which they needed to show the DBA in order to get an explanation as to
why the SQL was running forever. Of course, suggesting they just write the damn SQL was an unacceptable answer.
In addition, if apps used more robust SQL implementations, much of the processing would be executed in the DBMS via SQL, which could be a career-limiting move to the army of J2EE hackers out there.
Another case in point: another thread in this topic attempts to point out how verbose/ugly SQL is with 3 or 4 joins compared to some Hibernate shorthand...conveniently overlooking the fact that, in robust DBMS's, most of the example query would be buried in a nicely maintained view in the DBMS.
Even if nothing ever comes to light from IP/patent problems, it can ( and is ) keeping some companies away from adoption of anything open source out of fear of lawsuits.
GOOD!
While the rest of the known universe will deploy, profit from, and advance as a result of OSS, the meek will inherit whatever Mr. Softee decides to spoon feed them. Their choice, their loss. As numerous recent newsbits have shown, the practice of throwing enough shit at the USPTO until something sticks is becoming a bit problematic: the progenitors are in fear their own young shall be eaten...or eat them.
I have no doubt things will worsen before they improve, but it's become increasingly evident that any attempt to kill OSS on the pretense of IP is destined to fail...if for no other reason than the increasing (albeit often surreptitious) use of F/OSS by various gov't agencies (US or otherwise) (and increasing steadily, if my weblogs are any indication).
Perhaps most interesting (esp in comparison to MySQL) is the number of large scale datawarehouse startups embracing Pg (Netezza,
Metapa, among others). While they may have a way to go to play with the big boys, the fact they chose Pg should be of interest to any IT dept. making a decision about which OSS DBMS to commit to.
Had the (dis)pleasure of installing Solaris 10
on my SunBlade 100 recently (a prior power failure had zapped the filesystem, so it was a ground-up install). Not an experience I'd enjoy repeating again. On the upside, it only took *3* attempts.
I recall the same pain on the initial install of Solaris 8. I'd think by now they'd realize its tough to supplant the other major OS's if only certified Solaris Installation Engineers can get the damn thing up and running.
Since I can just drop my Fedora Core3's into a CD drive, boot, and get on about my life, I doubt I'll be switching to Solaris 10 for anything except compatibility testing any time soon.
How do you find the asteroid worth mining without the 10 billion dollar eyepiece?
With $10,000,000 eyepiece here on good old terra firma. Thats how most asteroid detection is done these days anyway.
The reality is that there is absolutely no economic benefit to living, working, or retrieving materials from space.
We don't know that. And the reason we don't know that is that NASA has been circle-jerking for 30 years.
If you want McSpace, you have to invent the SpaceMac.
Precisely. We need the SpaceMac, but we're spending our time/wealth on $10B disposable cameras.
I didn't mean to imply space exploration was easy. But its hard to put another Hubble up so we can snap more pretty pictures, and its hard to put a propulsion testbed up so we can start getting places faster,
and its hard to put lunar mining operations in place. They're all difficult; I'm just suggesting we try to getter a better bang for our bucks.
Have you ever seen the mockups of the Apollo modules ? I'd wager there's more/better/cheaper electronics in your average iPod Shuffle today than in the Apollo 11. That was an era when "crew as cargo", and human losses were accetpable. Time to move along...
..we did Skylab..
You must be f*ckin kidding...Skylab was, by NASA's own admission some years later, basically a PR stunt. "Let's see how big a semi truck we can drop into orbit, eh? I mean, we got these spare Saturn V's just layin around, and Congress(TM), (a wholey owned subsidiary of Exxon, Boeing, and Ford Motor Corp.) won't give us money to actually do anything, so lets just shoot our wad at the moon!
...we did Hubble,...
You do recall that Hubble was originally slated
for launch on the Shuttle right after Challenger ?
(circa 1986) Yes, I know they did some upgrades while it sat on the ground, but still.. And yet they even managed to screw that up, if you recall the first rescue mission to Hubble...
And the Shuttle ? Sweet Tap Dancin Keeerist, what a ridiculous contraption. Take a bull elephant, strap 2 pieces of 4x8 plywood to its back, and stuff its ass with dynamite. Yep, quite a technological wonder.
Let's face it, since the Apollo years, NASA has been the red-headed step child of gov't programs.
Frankly, the shuttle should never have been allowed to lift off, Hubble could've waited for an unmanned mission, and the US "participation in" aka picking up the tab for the ISS was a monumental waste of money.
Yes, we need space exploration, but for a purpose and with serious intent, So long
as used car salesmen and ambulance chaser's (aka the US Congress) are titular heads of the world's space exploration, we'll continue to end up with
Captain Cargo (see also John Glenn's recent expedition)
a Space Shuttle that only works about 1/3 of the time, with disasterous consequences the other 2/3
nerds whining about the gov't not pissing away enough money on half-assed space projects
We're adults now (in "xeno" terms), its time to stop fucking around, pretending we're throwing humans off this rock for a purpose, and actually do something interesting out there.
There are lots of projects: lunar mining, asteroid detection/diversion/mining, serious propulsion experiments...terraforming experiments on Mars...
Let's face it, we can easily see where we need to go next, spending another $10,000,000,000 on a new (or even 20 year old) eyepiece ain't neccesary.
I may be particularly dense, but I've concluded that Eclipse isn't the answer (otherwise, why was Penumbra developed ? (careful, thats pdf)
It takes way too long to start itself up
Add just an extra plugin or 2 and see how
quickly you get lost
try writing a non-trivial plugin (hope you
don't have carpal tunnel, you'll be typing a lot
of java and xml)
stick it in front of a non-tech user (as the parent was developing for), and you'll get looks of amazement all right...followed by looks of anger, confusion, and anxiety
While I appreciate IBM's contribution to FOSS, and its an OK Java IDE, morphing it into a general purpose UI for general users is probably expecting too much.
I'd start with a set of simple web pages, and maybe upgrade to either VB, python/tkinter, or Perl/Tk (maybe wxPython if you must have that fancy chrome) only if you can't convey the functionality in some simple HTML + CSS + JavaScript.
I'd only pick a one nit w/ Mssr. Torvalds...F/OSS is not something to be pursued "for fun", i.e, as a lark. It's not just about passion. Its about 'I've got this damn hairbrained idea in my head and it won't go away no matter how many joints/drinks/ampules I ingest!"
When you find yourself tossing/turning at night cuz some crazy notion won't leave you alone until you get it down on a hard drive somewhere, *then* you stand a shot at an OSS career.
Of course, you also stand a shot at personal financial ruin, emotional estrangement, and physical disability. But at least its outta your
head.
And for the record: Just cuz you use OSS, doesn't mean you've "chosen open source as a career path". Whipping up a little website with PHP and Postgres ain't the same as creating a new piece of F/OSS software from scratch.
Having worked in such situations, my experience is that such "promotions" usually end up being bad for the company, the promoted employee, and the poor bastards who get assigned to the new manager.
Please refer to the
Peter Principle and its corollary, the
Dilbert Principle.
Most good s/w engineer types seem to have poor personnel management skills, probably due to careers of deeply detailed, logic driven work. Managing people means delegating (i.e, ignore
the details), and handling illogical behavior (i.e., people). Conversely, some of the best managers I've worked for were abysmal software developers.
However, one alternative is
project management. While it does require some
people skills, its usually a couple degrees of separation away from the crap personnel managers have to deal with, and exploits the detail-level discipline us s/w types seem good at. And its a great way to leverage the offshoring trend.
While it maybe kewl (hmm, unintended pun...),
its waaaayyy overbuilt, and definitely violates the Homebrewers Prime Directive: "Relax, Don't Worry, Have a Homebrew" aka. RDWHHB.
For a simpler (albeit less sexy/techie) solution
check here
Works fine for me, but only during warm temps, since
it only turns the fridge off/on, and doesn't control a heat source.
And as for "open source" beer, there are recipes aplenty freely available on the 'net (e.g.,
HBD). All you need is a couple buckets with spigots, an airlock, a kettle, some malt, and some yeast. Far less difficult, and much more rewarding, than open source s/w!
Slashdot Mirror
(editted for brevity)
It may be a retarded question, but not for the reasons you describe.
I've seen GPL projects that die because they target a commercial audience that won't touch a GPL. The GPL, in and of itself, is not going to spur development. And neither is the BSD.
BTW: theres a lot of non-GPL OSS out there to choose from these days. I, for one, try to avoid using GPL'd source as much as possible, simply to limit my exposure to its potential "virulent" impact. I develop truly free OSS (usually under a Common Public License, or an Artistic License), as well as proprietary solutions.
I think the ultimate difference is the notion of truly free software, vs. the appearance of freedom. If you develop open source with the notion that a license is somehow going to cause your project to succeed by forcing those that want to use your code to keep the derivatives open, I'm afraid you're sadly mistaken. The scrupulous are likely to take a pass (there are usually nonGPL'd solutions to most problems these days), while the unscrupulous don't care what license you use.
Tyranny, regardless whether monarchy, oligarchy, or communist dictatorship, is still tyranny. Bottom line: if you want control, keep it closed, and don't call if "free". If you genuinely want to make a contribution, use some other license to eliminate liability, and learn to just let go.
I'd like to suggest that all those throwing stones here take a reality and gut check.
Development at MSFT is a pressure cooker. Schedules tend to be pushed to the limits by low level mgmt whose own genitals are resting on the chopping block pretty much 24x7. So it shouldn't be terribly surprising that MSFT has quality issues. Code either gets pushed out the door, or people (and esp. managers) get fired. (Rumors are already circulating RE: the heads that have rolled due to the Longhorn debacle)
So if you were "treated" to the exersize of having someone waltz in and prove that your code is vulnerable, after you've been pushed to the wall for an extended period, I suspect you'd likewise feel more anger than shame, and probably a lot of frustration, too. After all, most of us don't intend to write bad code, but when the gating QA factor is an overly aggressive date on a calendar, you'll have little opportunity to be concerned about hacks outside the acceptance test suite.
Analog can be a bitch goddess: variations in resistive, capacitive, and inductive tolerances for cheap components can lead to very different behaviors, and can lead to misbehaviors that are very frustrating to diagnose unless you have several $1000's worth of equipment at your disposal. If/when you get to that level, it can be very rewarding, but its the deep end of the pool, and the life preserver is pretty expensive.
The bugs one finds on "minor" platforms usually end up being bugs on the "major" platforms you just haven't found before. Of course, for those of you still intent on/forced to write code in C/C++, you're likely getting your just desserts.
More power to 'em. In fact, I'd suggest that anyone entering w/ any electronic info device (yes, including cellphones) on the weekend be shown the exit and visited with a hail of derisive boos and laughter.
I suspect you mean this article by (the highly regarded) Jim Gray, whose opinion I'm much more inclined to seriously consider than the ramblings of the subject article's author (someone who, based on his company's product, apparently considers a B-Tree to be an innovative solution).
But I admit I found Gray's article equally disconcerting (perhaps he's been spending too much time on the sailboat in the SF Bay, and MSFT needed a shill to push their "XML Uber Alles" and Longhorn vision?).
SQL has managed to overcome a lot of derision over the years, and, tho the language has often been a bit slow on the uptake, it has managed to adapt admirably to abstract datatypes, recursive queries, OLAP, etc. Perhaps as importantly, the 90's left us with empirical evidence that the O-R juggernaut may have been ill conceived, with the failures of GemStone (which has since re-invented itself), and the disasterous impact of Informix's Illustra (nee Postgres) adventure.
Let's face it, SQL just works. Most people I've met who complain about SQL usually
- (a) don't know how to tune a database and/or
- (b) don't know how to properly use SQL and/or
- (c) are stuck using a half-assed DBMS
There may be an inherent beauty/advantage to a declarative language, in that it can adapt to change by adding a few nouns, some adjectives and/or adverbs, and, as a last resort, one or two new verbs, rather than forcing a redefinition of the entire language (C -> C++, COBOL -> ObjectCOBOL, etc.).So, to paraphrase Twain, "The rumors of SQL's death have been greatly exaggerated."
- Always spend at least 5% more than your budget (so you'll get more next budget cycle).
- Never underspend your budget (or they'll trim your budget in the next budget cycle!)
- The department director with the biggest budget wins.
Nuff said.Actually, I'd think
would be more appropriate ?
As to the purpose of the box, I can't say too much, except its intended as a sortof main-memory database cache solution (ala TimesTen ) to serve a potentially very large user base, with a lot of cached images associated with the cached data.
I also considered a piecemeal commodity approach, e.g., filling racks with cheap 4 gig RAM 1U's running Linux, but then I'd have to come up with s/w that can coordinate those systems (basically, a head-end to hash the requests to the right 1U). memcached looks intriguing, but I'm still concerned about interconnect latencies.
Based on my cocktail napkin estimates, the h/w cost of a big RAM system (if it can be got) would probably be about 2x the cost of the piecemeal system, but hopefully signifcantly reduce interconnect latency, and use simpler s/w (assuming I can get Linux to config a ramdisk that big).
Since latency is the prime concern, solidstate disks using the usual HD interconnects just didn't seem an acceptable solution, esp since the cost reduction doesn't seem that significant.
As for failure recovery, my thoughts were just a couple fast HDs that would ping-pong taking snapshots of the ramdisk; hopefully, the ramdisk recovery would never lose more than an hour's data (the lost data wouldn't be critical, and would be recoverable from other sources...its really the delivery speed thats essential)
But I may need to go back to my napkin and do some more queueing analysis to see if there are better commodity solutions.
Tho that effects flick was actually kinda kewl....
The BBC series did an admirable job with bad costumes and little or no budget. Only Hollywood could take perfect dialog and a great story and piles of cash and crank out a disaster.
Thank god they haven't discovered Heinlein yet...
At least they got something right: Who is Bob Dobbs ?
In my experience, the SQLphobia seems to derive from the following:
Case in point: I recently saw a post in another forum in which the OP opined they couldn't produce the actual SQL that the OR wrapper de jure was generating, which they needed to show the DBA in order to get an explanation as to why the SQL was running forever. Of course, suggesting they just write the damn SQL was an unacceptable answer.
In addition, if apps used more robust SQL implementations, much of the processing would be executed in the DBMS via SQL, which could be a career-limiting move to the army of J2EE hackers out there.
Another case in point: another thread in this topic attempts to point out how verbose/ugly SQL is with 3 or 4 joins compared to some Hibernate shorthand...conveniently overlooking the fact that, in robust DBMS's, most of the example query would be buried in a nicely maintained view in the DBMS.
While the rest of the known universe will deploy, profit from, and advance as a result of OSS, the meek will inherit whatever Mr. Softee decides to spoon feed them. Their choice, their loss. As numerous recent newsbits have shown, the practice of throwing enough shit at the USPTO until something sticks is becoming a bit problematic: the progenitors are in fear their own young shall be eaten...or eat them.
I have no doubt things will worsen before they improve, but it's become increasingly evident that any attempt to kill OSS on the pretense of IP is destined to fail...if for no other reason than the increasing (albeit often surreptitious) use of F/OSS by various gov't agencies (US or otherwise) (and increasing steadily, if my weblogs are any indication).
Perhaps most interesting (esp in comparison to MySQL) is the number of large scale datawarehouse startups embracing Pg (Netezza, Metapa, among others). While they may have a way to go to play with the big boys, the fact they chose Pg should be of interest to any IT dept. making a decision about which OSS DBMS to commit to.
I recall the same pain on the initial install of Solaris 8. I'd think by now they'd realize its tough to supplant the other major OS's if only certified Solaris Installation Engineers can get the damn thing up and running.
Since I can just drop my Fedora Core3's into a CD drive, boot, and get on about my life, I doubt I'll be switching to Solaris 10 for anything except compatibility testing any time soon.
How company can make money, if freely available its products are ?'
With $10,000,000 eyepiece here on good old terra firma. Thats how most asteroid detection is done these days anyway.
The reality is that there is absolutely no economic benefit to living, working, or retrieving materials from space.
We don't know that. And the reason we don't know that is that NASA has been circle-jerking for 30 years.
If you want McSpace, you have to invent the SpaceMac.
Precisely. We need the SpaceMac, but we're spending our time/wealth on $10B disposable cameras.
I didn't mean to imply space exploration was easy. But its hard to put another Hubble up so we can snap more pretty pictures, and its hard to put a propulsion testbed up so we can start getting places faster, and its hard to put lunar mining operations in place. They're all difficult; I'm just suggesting we try to getter a better bang for our bucks.
Have you ever seen the mockups of the Apollo modules ? I'd wager there's more/better/cheaper electronics in your average iPod Shuffle today than in the Apollo 11. That was an era when "crew as cargo", and human losses were accetpable. Time to move along...
You must be f*ckin kidding...Skylab was, by NASA's own admission some years later, basically a PR stunt. "Let's see how big a semi truck we can drop into orbit, eh? I mean, we got these spare Saturn V's just layin around, and Congress(TM), (a wholey owned subsidiary of Exxon, Boeing, and Ford Motor Corp.) won't give us money to actually do anything, so lets just shoot our wad at the moon!
You do recall that Hubble was originally slated for launch on the Shuttle right after Challenger ? (circa 1986) Yes, I know they did some upgrades while it sat on the ground, but still.. And yet they even managed to screw that up, if you recall the first rescue mission to Hubble...
And the Shuttle ? Sweet Tap Dancin Keeerist, what a ridiculous contraption. Take a bull elephant, strap 2 pieces of 4x8 plywood to its back, and stuff its ass with dynamite. Yep, quite a technological wonder.
Let's face it, since the Apollo years, NASA has been the red-headed step child of gov't programs. Frankly, the shuttle should never have been allowed to lift off, Hubble could've waited for an unmanned mission, and the US "participation in" aka picking up the tab for the ISS was a monumental waste of money.
Yes, we need space exploration, but for a purpose and with serious intent, So long as used car salesmen and ambulance chaser's (aka the US Congress) are titular heads of the world's space exploration, we'll continue to end up with
- Captain Cargo (see also John Glenn's recent expedition)
- a Space Shuttle that only works about 1/3 of the time, with disasterous consequences the other 2/3
- nerds whining about the gov't not pissing away enough money on half-assed space projects
We're adults now (in "xeno" terms), its time to stop fucking around, pretending we're throwing humans off this rock for a purpose, and actually do something interesting out there.There are lots of projects: lunar mining, asteroid detection/diversion/mining, serious propulsion experiments...terraforming experiments on Mars...
Let's face it, we can easily see where we need to go next, spending another $10,000,000,000 on a new (or even 20 year old) eyepiece ain't neccesary.
I may be particularly dense, but I've concluded that Eclipse isn't the answer (otherwise, why was Penumbra developed ? (careful, thats pdf)
While I appreciate IBM's contribution to FOSS, and its an OK Java IDE, morphing it into a general purpose UI for general users is probably expecting too much.
I'd start with a set of simple web pages, and maybe upgrade to either VB, python/tkinter, or Perl/Tk (maybe wxPython if you must have that fancy chrome) only if you can't convey the functionality in some simple HTML + CSS + JavaScript.
When you find yourself tossing/turning at night cuz some crazy notion won't leave you alone until you get it down on a hard drive somewhere, *then* you stand a shot at an OSS career. Of course, you also stand a shot at personal financial ruin, emotional estrangement, and physical disability. But at least its outta your head.
And for the record: Just cuz you use OSS, doesn't mean you've "chosen open source as a career path". Whipping up a little website with PHP and Postgres ain't the same as creating a new piece of F/OSS software from scratch.
Having worked in such situations, my experience is that such "promotions" usually end up being bad for the company, the promoted employee, and the poor bastards who get assigned to the new manager. Please refer to the Peter Principle and its corollary, the Dilbert Principle.
Most good s/w engineer types seem to have poor personnel management skills, probably due to careers of deeply detailed, logic driven work. Managing people means delegating (i.e, ignore the details), and handling illogical behavior (i.e., people). Conversely, some of the best managers I've worked for were abysmal software developers.
However, one alternative is project management. While it does require some people skills, its usually a couple degrees of separation away from the crap personnel managers have to deal with, and exploits the detail-level discipline us s/w types seem good at. And its a great way to leverage the offshoring trend.
For a simpler (albeit less sexy/techie) solution check here
Works fine for me, but only during warm temps, since it only turns the fridge off/on, and doesn't control a heat source.
And as for "open source" beer, there are recipes aplenty freely available on the 'net (e.g., HBD). All you need is a couple buckets with spigots, an airlock, a kettle, some malt, and some yeast. Far less difficult, and much more rewarding, than open source s/w!