Office of Signal Integrity? For vague yet disturbing bureaucracy names, that's almost as good as Ministry of Truth! I'm guessing that these are the folks responsible for all the black helicopters I've been seeing.
I use the rc shell, originally from the Plan 9 operating system, for my personal systems. The minimalist philosophy and syntax makes scripting simple (modulo some awkward syntax for if/else logic), and the nestable backquoting syntax combined with GNU readline (optional) makes it simple to iteratively hack up nested 3-level-deep pipelines on the fly. One minor drawback for interactive use is that working with file or directory names containing spaces is not that smooth.
When on other people's Unix systems, whether for interactive work or scripting, bash is the shell of choice. It's almost always there (and if it isn't, it's easy to build a local copy, it runs on virtually any system). The filename completion is fantastic, and compatibility with vanilla sh makes scripts portable (just avoid the bash specific features).
For Windows, I use Cygwin+bash. That combination turns my Win2k PC at work into something usable.
All a hoax? It's almost a disappointment. The article was much like many other crank articles I've read (it's a little vice I have), except better researched. No doubt a quote like "Infinite recursion like this is a sure sign of a flaw in a theory" in an article promoting creationism should have been a tip-off. Well, my hat's off to the perpatrators.
You're saying that letting every programmer choose "a unique development environment, using his/her own set of tools" will compromise "the coherence and ultimate success of the development project". Eh, a tiny bit of common sense will reveal that for some tools, it doesn't matter in the slightest while for some, it's extremely important. I use emacs, my team lead likes the MS Visual Studio editor, our other developer prefers (God knows why) vi. So? As long as the important things are agreed on - which compilers and libraries including version numbers, etc. - it doesn't make the slightest difference.
For that matter, I can develop my app all day with emacs + javac on a Linux box while my teammate develops in JBuilder on an NT box, and integrate our code with no problems, as long as we have a basic understanding of the Java versions being used and any quirks in the respective tools (never ran into any though). Or develop Perl apps on Linux to deploy on AIX. No anarchy, no chaos, no problem. Sure, it's important to test the software before deploying it just to make sure there aren't any integration problems, but you would do that even if everyone developed on identical locked-down platforms, and in 4 years I only got bit by development environment differences once (different directory location in AIX vs. Linux).
Of course all parties need to agree on compiler versions and the like. Of course testing needs to take place on a non-developer machine. And of course the software shouldn't have any dependencies on local or undocumented paths or other configuration. But to claim that "developers must use a consistent, managed environment" (italics mine) is just excessive. It is the "managed" aspect of your argument that worries me.
That always impplies that someone else will be doing all the managing - somone else will be building and maintaining all the development machines to some predefined standard. In reality, when all parties agree on the important aspects, while throwing caution to the wind in areas of personal preference not affecting the success of the project, things work just fine.
There's another argument against requiring locked down systems for
developers. This assumes you are in a situation where you have free
reign to build / configure your machine - for me it was a tiny Linux
enclave in a mostly Windows and mainframe organization ("you break it,
you fix it - don't bug us, and we won't bug you"), and I was
developing internal software tools and Web applications on free
software (Linux, Apache, Perl, etc.).
The great advantage (for me) of this setup, other than simple ability
to function at my job, was doing the admin work taught me a *hell* of
a lot that was useful to me as a developer. Building, installing, and
*configuring* the kernels (including occasional oddball device drivers
cobbled together off of the net), compilers, libraries, Web servers,
databases, etc. that I used to develop with, having to do my own
networking setup, keeping up with security patches, etc. gave me huge
amounts of experience that I wouldn't have gotten just programming on
a box that someone else set up.
With this experience and exposure, when my boss would wander by my
cube to ask what it would take to design and build some new system to
do X, Y, and Z whether as an internal app or to deploy on our public
Web server, I could usually give her an accurate estimate on the spot
of the effort involved, how much we could use free software for vs.
how much we had to build [funny... there was no problem buying
proprietary software when needed but it rarely was], what could go on
Unix vs. Windows and the size of hardware needed, etc. I never knew
any of that stuff when I used to be a pure code monkey working on
standardized boxes - it was someone else's problem then. So while you
may argue that developers don't need full control over their machine,
I guarantee that they will either learn from it, or go back to letting
someone else admin the machine.
Working with two other developers with the same approach was great
also. I used Slackware Linux preferring to develop in Perl, my team
lead ran Windows NT with a Red Hat box on the side, developing mostly
in Java, and our junior team member ran Red Hat and programmed in
both. By having to share code in an environment like that, you were
pretty much required to use good source code control, keep track of
runtime requirements (libraries paths etc.), and write portable code,
or you would always be pissing off your coworkers.
I can't speak for all government agencies, but I worked at a U.S. federal agency for about 4 years until this spring, and the policy there was "sure, go on, install your weird Linux box, just don't come crying to us when you break it." Worked great. My personal, dev, and test machines were set up to perfection by me, and the IT department didn't have me bugging them 5 times a day to install new tools, upgrade libraries and compilers, or install security patches. The only downside was that I always had to prove that DNS and web proxy problems were theirs, not mine, before they would try to fix them. After a while even that stopped when they realized that I never bothered them with bogus problems. Life was good.
MPAA: You are now the proud owner of a license to view some content.
You: Uh-oh, the dog ate my DVD.
MPAA: Did we say you have a license to view content? What we meant was, you are now the proud owner of a shiny plastic disk with some bite marks. If you had a license to view content, we would have to let you download another copy at no cost (being a licensee of the content and all), or at least recognize that you could have made a backup copy in case of the media breaking, and that would be silly. Sucker!
You claim that people will make an informed choice about whether they want to give up privacy for functionality, but do you honestly think that Sun, Motorola, Gillete and all the rest intend to let you have a choice about it? Once this technology hits Wal-Mart, your choice will be between buying products that track your every move, and not buying products, period.
The guy was a cartoon genius. I think I still have, stashed away in a folder somewhere, several pages of "Mad Don Martin's Sound Effect Stickers" from when I was a kid in the 70's. These things were fantastic. You could really *hear* them - PWANG!, a frying pan in the face. POIT!, a breast popping out of a too-tight corset. SPLADAP!, someone smacked with a fish. GASHPLUCT!, a farmer walking through a muddy field. SHTOONK!, a metal rod poking someone's eye. GLING!, a fly going through a fan.* There were a million of them. All illustrated in a goofily original style in which the victims appeared more bemused than actually hurt.
His straight cartoons were always a riot as well. I particularly loved the befuddled surgeons - wondering how to begin a brain operation, not noticing "Insert thumb into slot A and pull" notation on the patient's neatly perforated skull. Or when an organ flies out of the patient's body - "better save that, we might need it later."
And, who could forget his portrayal of Elvis, "Shmelvis Parsley in 'Singing Wings'"? The list goes on and on - it's no wonder I turned out the way I did, thanks in part to this man's warped sense of humor. Don was truly brilliant, he will be greatly missed.
* Disclaimer: I may have spelled a couple of these wrong, it's been years after all.
Slashdot Mirror
Office of Signal Integrity? For vague yet disturbing bureaucracy names, that's almost as good as Ministry of Truth! I'm guessing that these are the folks responsible for all the black helicopters I've been seeing.
I use the rc shell, originally from the Plan 9 operating system, for my personal systems. The minimalist philosophy and syntax makes scripting simple (modulo some awkward syntax for if/else logic), and the nestable backquoting syntax combined with GNU readline (optional) makes it simple to iteratively hack up nested 3-level-deep pipelines on the fly. One minor drawback for interactive use is that working with file or directory names containing spaces is not that smooth.
When on other people's Unix systems, whether for interactive work or scripting, bash is the shell of choice. It's almost always there (and if it isn't, it's easy to build a local copy, it runs on virtually any system). The filename completion is fantastic, and compatibility with vanilla sh makes scripts portable (just avoid the bash specific features).
For Windows, I use Cygwin+bash. That combination turns my Win2k PC at work into something usable.
All a hoax? It's almost a disappointment. The article was much like many other crank articles I've read (it's a little vice I have), except better researched. No doubt a quote like "Infinite recursion like this is a sure sign of a flaw in a theory" in an article promoting creationism should have been a tip-off. Well, my hat's off to the perpatrators.
For that matter, I can develop my app all day with emacs + javac on a Linux box while my teammate develops in JBuilder on an NT box, and integrate our code with no problems, as long as we have a basic understanding of the Java versions being used and any quirks in the respective tools (never ran into any though). Or develop Perl apps on Linux to deploy on AIX. No anarchy, no chaos, no problem. Sure, it's important to test the software before deploying it just to make sure there aren't any integration problems, but you would do that even if everyone developed on identical locked-down platforms, and in 4 years I only got bit by development environment differences once (different directory location in AIX vs. Linux).
Of course all parties need to agree on compiler versions and the like. Of course testing needs to take place on a non-developer machine. And of course the software shouldn't have any dependencies on local or undocumented paths or other configuration. But to claim that "developers must use a consistent, managed environment" (italics mine) is just excessive. It is the "managed" aspect of your argument that worries me. That always impplies that someone else will be doing all the managing - somone else will be building and maintaining all the development machines to some predefined standard. In reality, when all parties agree on the important aspects, while throwing caution to the wind in areas of personal preference not affecting the success of the project, things work just fine.
You have to be a "power user" to change your screen colors? <> That's unnatural, man!
There's another argument against requiring locked down systems for
developers. This assumes you are in a situation where you have free
reign to build / configure your machine - for me it was a tiny Linux
enclave in a mostly Windows and mainframe organization ("you break it,
you fix it - don't bug us, and we won't bug you"), and I was
developing internal software tools and Web applications on free
software (Linux, Apache, Perl, etc.).
The great advantage (for me) of this setup, other than simple ability
to function at my job, was doing the admin work taught me a *hell* of
a lot that was useful to me as a developer. Building, installing, and
*configuring* the kernels (including occasional oddball device drivers
cobbled together off of the net), compilers, libraries, Web servers,
databases, etc. that I used to develop with, having to do my own
networking setup, keeping up with security patches, etc. gave me huge
amounts of experience that I wouldn't have gotten just programming on
a box that someone else set up.
With this experience and exposure, when my boss would wander by my
cube to ask what it would take to design and build some new system to
do X, Y, and Z whether as an internal app or to deploy on our public
Web server, I could usually give her an accurate estimate on the spot
of the effort involved, how much we could use free software for vs.
how much we had to build [funny... there was no problem buying
proprietary software when needed but it rarely was], what could go on
Unix vs. Windows and the size of hardware needed, etc. I never knew
any of that stuff when I used to be a pure code monkey working on
standardized boxes - it was someone else's problem then. So while you
may argue that developers don't need full control over their machine,
I guarantee that they will either learn from it, or go back to letting
someone else admin the machine.
Working with two other developers with the same approach was great
also. I used Slackware Linux preferring to develop in Perl, my team
lead ran Windows NT with a Red Hat box on the side, developing mostly
in Java, and our junior team member ran Red Hat and programmed in
both. By having to share code in an environment like that, you were
pretty much required to use good source code control, keep track of
runtime requirements (libraries paths etc.), and write portable code,
or you would always be pissing off your coworkers.
I can't speak for all government agencies, but I worked at a U.S. federal agency for about 4 years until this spring, and the policy there was "sure, go on, install your weird Linux box, just don't come crying to us when you break it." Worked great. My personal, dev, and test machines were set up to perfection by me, and the IT department didn't have me bugging them 5 times a day to install new tools, upgrade libraries and compilers, or install security patches. The only downside was that I always had to prove that DNS and web proxy problems were theirs, not mine, before they would try to fix them. After a while even that stopped when they realized that I never bothered them with bogus problems. Life was good.
My uncle has a country place
That no-one knows about
He says it used to be a farm
Before the Motor Laws
On Sundays I eluede the Eyes
And hop the turbine freight
To far outside the wire where my white-haired uncle waits...
:-(
(To paraphrase what some /.er said long ago)
MPAA: You are now the proud owner of a license to view some content.
You: Uh-oh, the dog ate my DVD.
MPAA: Did we say you have a license to view content? What we meant was, you are now the proud owner of a shiny plastic disk with some bite marks. If you had a license to view content, we would have to let you download another copy at no cost (being a licensee of the content and all), or at least recognize that you could have made a backup copy in case of the media breaking, and that would be silly. Sucker!
The program itself is pretty awesome, but even more so is his use of -w. Now that takes guts.
You claim that people will make an informed choice about whether they want to give up privacy for functionality, but do you honestly think that Sun, Motorola, Gillete and all the rest intend to let you have a choice about it? Once this technology hits Wal-Mart, your choice will be between buying products that track your every move, and not buying products, period.
Slavery is freedom!
-- 1984
> ...detonate a nuke above the stratosphere and subject the US to an EMP surge
Hey, if that's what it takes, I'm all for it.
"Alder Hey" - search at BBC News or try this article. This will turn your stomach... at least if you have children.
Just imagine what the RIAA and MPAA could do with this idea. Hope they don't read /....
The guy was a cartoon genius. I think I still have, stashed away in a folder somewhere, several pages of "Mad Don Martin's Sound Effect Stickers" from when I was a kid in the 70's. These things were fantastic. You could really *hear* them - PWANG!, a frying pan in the face. POIT!, a breast popping out of a too-tight corset. SPLADAP!, someone smacked with a fish. GASHPLUCT!, a farmer walking through a muddy field. SHTOONK!, a metal rod poking someone's eye. GLING!, a fly going through a fan.* There were a million of them. All illustrated in a goofily original style in which the victims appeared more bemused than actually hurt.
His straight cartoons were always a riot as well. I particularly loved the befuddled surgeons - wondering how to begin a brain operation, not noticing "Insert thumb into slot A and pull" notation on the patient's neatly perforated skull. Or when an organ flies out of the patient's body - "better save that, we might need it later."
And, who could forget his portrayal of Elvis, "Shmelvis Parsley in 'Singing Wings'"? The list goes on and on - it's no wonder I turned out the way I did, thanks in part to this man's warped sense of humor. Don was truly brilliant, he will be greatly missed.
* Disclaimer: I may have spelled a couple of these wrong, it's been years after all.
--Indigo