The Open Source implementations of Java are coming along well, and could catch up with a little help.
But not if you're tainted as a developer -- ie: if you've ever seen the source to Sun's JDK or even cracked open the source jar from the JDK, you're tainted. The last thing any of the open source projects needs is tainted developers. Sadly, I am tainted. Back in 1997 I made the mistake of registering for and receiving a source copy of the Sun JDK (long since lost to a hard drive crash). So no matter how much I want to contribute to the GNU Classpath project, the most I can do is write test cases.
Ok, and this is going to help Sun, how? They're going to lose licensing revenue so that what? 1% of 1% of all computer users can install a Java plugin? That doesn't make any sense.
What licensing revenue? Anyone who wants to can download Sun's JRE (Java Runtime Environment) from Sun's website and install it themselves on Windows, Linux, and Solaris at zero cost (other than bandwidth, which is negative revenue to Sun). The problem is that no one else can redistribute the JRE without getting a distribution license from Sun, which will (of course) stipulate that no one else can redistribute the JRE. This doesn't increase Sun's revenues -- it just increases the cost to deploying a Java application in a non-Solaris environment, by increasing the man-hours necessary to install and support something that by all rights should have been installed with the operating system.
The truly stupid thing is that Sun now has included technology into Java 1.4 that will allow the JRE to check for the latest version online and upgrade, automatically... if you have all of the right system permissions and, of course, enough bandwidth to download a 44MB executable. Maybe that works great at large schools, but in corporate america, that's a no-no -- the only software that's allowed to be auto-updated are virus-scanners, and Windows security holes^Wpatches. And of course, if you're building applications that are intended to be used offline (or on a network that's detached from the Internet for security) you're just plain out of luck.
Linux (and *BSD) developers have been begging Sun for years to allow them to preinstall the JRE with their distributions, to no avail. Instead Sun has continued to follow a policy that intentionally reduces their potential marketshare, without any increase in revenue to show for it. Brilliant move, Sun!
It takes great ability to put stuff into a language, and do it right. I'm not talking about doing it wrong.
No, anyone can put stuff into a language. The hard part is identifying the 'good stuff'. The creator's of PL/I did a great job of integrating all of the concepts of Fortran, Algol, and COBOL into a single language. Unfortunately, they put ALL of the concepts into PL/I, not just the good ones. So instead of voting to 'Put all the good stuff into one language', why don't you start identifying the good stuff... and then getting the rest of the programmers to agree with you? Once that's done, it can be put into a language by almost anyone.
Personally, I'm not a single-language fanatic... I've been programming for 25+ years, and I've probably learned more than a eighty languages (I stopped counting years ago, but I learn 3-4 a year). Not one of the languages I've used would have been perfect for ALL purposes, but many of them were damned good for their intended purpose (even COBOL).
I would say that the base application would be an excellent applicant to be OSS as those functions are needed by almost every school. You then can add in local variations (and most are driven by accredidation board they are under and the state), which can also be shared by those who haev similar local needs (ie same accred board, same state, etc).
That might make sense under the right circumstances; I don't think those circumstances will ever exist.
Currently the schools are running software that they've licensed from a vendor. Some of those schools may have paid for a source code license (which would probably restrict their rights to build competing products), others did not. Either way, the vendor owns the code, while some schools own some modifications. With that in mind, suppose you want to create an Open Source replacement system for administering colleges. You'd have to find enough schools that were willing to fund a replacement, identify all of their requirements, and then partition each of the requirements into "core", "federal", "state", and "school-specific". You're going to need a large pool of developers working for several years, and all that time you still have to pay for maintainence on the existing system, because you can't ignore the current system while building the new system. Someone will have to write software to convert all of the historical data from the old system to the replacement, because the school can't just throw away the old data. By the time you're finished, you've ended up building an entire company (even if it's owned and operated by schools)... unlikely to succeed.
Alternately, suppose the vendor decides to Open Source the code (for whatever reason). Now you have several million lines of gobbledegook, probably written with languages and tools that are either (a) prohibitively expensive, or (b) probably unattainable. Hundreds of random programmers have spent the last 25 years hacking and patching the code as it evolved from a server/dumb terminal application through client-server and on towards something vaguely web-based (but with lots of background batch processing). Where do you get people who skilled enough to read through the code, make modifications, and build the end result? You may find that even with the source code, it's easier to rewrite from scratch than maintain that pile of hairy code. [This is the Mozilla scenario.]
(I really don't want to end this here, but I don't have the time to write the rest of this essay. Gotta go back to work to earn my salary.)
Depending on the situation. If you know you're going to die because your tactical computer bluescreened, is it really that much different than not knowing you are going to die because your software is screwed up?
If I know that there's a problem, I can respond to it. Even if the problem leaves me with a miniscule chance of survival, that's still a chance. On the other hand, if I think everything's fine while an undetected threat is approaching, I won't have any chance at all to respond. Some chance is better than no chance, every day.
Yes, all systems should work correctly, all of the time. And when I'm developing systems (oddly enough, military systems), my goal is perfection. But I know that systems fail because nothing in this world is perfect or permanent, and so I plan for failure as well as success.
I would lay good odds that once upon a time I worked for the company that made the software your friend maintains. (There aren't that many companies who do this sort of software, and I worked for one who now has more than 500 colleges as customers.) With that in mind, I think I can offer some explanation for your friend's complaints, and why open source wouldn't work to solve her problem. Let's start with a good rule of thumb:
Trader's Open Source Feasibility Factor: The likelyhood that a piece of software would be a good target for developing, maintaining, and improving as Open Source Software is proportional to the number of active installations, divided by the complexity of the software (measured in Source Lines of Code for lack of a more rigorous measure).
Any number greater than 10 indicates an excellent OSS candidate; numbers less than 0.1 indicate a poor candidate for OSS. As an example, Apache, with 31+ million websites and roughly 285,000 SLOCs would have a rough OSFF of 108; MS Windows with 200+ million users and 20-50 million SLOCs would have a rough OSFF between 4 and 10. Thus the Apache webserver would be a better candidate for OSS than MS Windows.
With that in mind, let's examine the software for administering a typical 4-year college. While much of the software would be recognizable as accounting software: inventory, accounts receiveable, account payable, general ledger, payroll, etc, it will have been customized specifically for the quirks of running a large institution with a continually changing student body. Then add on class scheduling and grade calculation modules, as well as security levels to protect the privacy and security of confidential data, such as financial and health records. Finally, throw in yearly updates for the financial aid software, which has to change to meet new requirements from the US Department of Education every year. At this point you're probably talking about 5-10 million SLOCs, with a user base of 500 customers, or an OSFF of 0.0001 or less.
Another thing to keep in mind is that there are accounting certifications that have to be renewed on a yearly basis, or the college could fail an audit, which could result in its accredidation being suspended. All in all, maintaining this type of software is a very time-consuming and expensive proposition, and we're still only talking about the base package, before customizations.
Customizations can take many forms. Typical customizations are parameter-driven (school name, address, etc.) but many are the result of specific local policies and requirements. You're really talking about separate source code forks for each school. Add up the collective customizations from 500 schools are you might be talking about as much source code as the base software.
That much complexity is hard to manage; its not surprising that the company in question doesn't maintain the customizations for an individual school...
Almost any vertical application for a sufficiently complex business will have the same sort of problem, which is the major reason why Open Source Software will have a great deal of difficulty in displacing proprietary vertical applications. There just aren't enough customers for that type of software to develop the sort of community necessary to support the many man-years necessary to code an OSS competitor.
There's nothing that says that ALL of the elements of a critical system have to be open source (GPL flamewars aside). On the other hand, most of the infrastructure of a modern system (military or otherwise) is the same as any other IT system, except for having stricter reliability requirements (ie: no single-point-of-failure allowed / short recovery times). In fact, these are the same infrastructure requirements that most commercial entities would love to have, but generally can't justify on a cost basis.
Take clustered storage systems -- truly reliable (ie 0.99999 or better uptime) systems require redundant drives and redundant data paths. Proprietary implementations are expensive, but while open source implementations are gradually becoming available (ie: OpenGFS), they still have performance, scalability, and reliability limitations. There should be no reason for a military development program NOT to contribute to OpenGFS, and leverage the results for their infrastructure, even if the rest of their software is classified.
My only concern would be announcing to the world that specific strategic and tactical systems were using specific hardware and specific software -- a studious researcher could use that sort of information to estimate performance limitations. On the other hand, there are plenty of professional and industry journals that publish the same information today, often in more detail (Aviation Week has guys camping in lawn chairs... Janes has their sources too) so I wouldn't worry a whole lot about it.
So I wouldn't necessarily Open Source the data analysis software for an air traffic control system, but I might use an Open Source infrastructure for storing the track data for playback.
Would you really want your military systems to blue screen or dump core right in the middle of a firefight?
There are much worse ways that software can fail. One of the worst is software that looks like it's working, but in fact is not displaying new / updated items -- this leaves the warfighter with the false impression of situational awareness. Another popular failure is software that has time-consuming processing steps that don't have adequate progress indicators -- this leaves the warfighter wondering 'Is it done yet?' when it hangs or fails.
At least with a blue screen or core dump, you know you've got a problem, and you can restart / reboot to resume, with a well known startup time.
I got my 721 last week, and while my wife had some doubts about it initially (the cost), at the end of one day's use, we are both convinced that this is definitely the best thing since sliced stupid people on toast.
Red Hat Professional Workstation is a complete suite of tools for the power desktop user.
Supports up to 2 processor x86 workstations
Includes applications and services power desktop users demand
Bluecurve, Ximian Evolution, OpenOffice.org, Mozilla
Web Server powered by Apache
Samba, NFS, CUPS
GCC 3.2
Includes one year of Red Hat Network updates
Includes 30 days of phone and web installation support
What's NOT Included
Red Hat Professional Workstation is designed for the advanced user
requiring a single Linux desktop deployment with limited support and
management capabilities.
Features not available with Red Hat Professional Workstation (but standard in Red Hat Enterprise Linux) include:
Renewable Subscriptions -- Customers looking for supported environments or
deployments for longer than 1 year should consider Red Hat Enterprise
Linux.
Additional Support options -- Customers needing support beyond basic installation should look to Red Hat Enterprise Linux.
Upgrade paths to Red Hat Enterprise Linux -- Professional Workstation is not a subscription product. We recommend that customers looking for the
benefits of a annually renewable support and maintenance contract look
to Red Hat Enterprise Linux.
Hardware and Software Certifications -- Not available with Professional Workstation. For environments where certified hardware and software functionality are key - Red Hat Enterprise Linux is the recommended solution.
Open Source Architecture Integration -- Red Hat Enterprise Linux provides
the necessary components and support for integration into a managed
corporate desktop infrastructure. Red Hat Enterprise Linux will be the
core platform of the Open Source Architecture.
I think a lot of people are selling Fedora short. I've installed it and am using it as my primary desktop at home (and I expect to be upgrading my servers to it by year's end). Based upon my past experiences with Red Hat Linux (every release from 3.0.3 to 9) Fedora feels just like I would have expected from Red Hat 9.1 (or Red Hat 10). The only difference was that I downloaded ISOs and burned CDRs instead of buying CDROMs in a red box with printed documentation.
I don't know how you characterize professional, but I consider myself a professional software developer (20+ years) and I wouldn't hesitate to deploy Fedora in a small organization or a large enterprise (with adequate testing of course). Perhaps the problem is with the term 'hobbyist'?
For that matter, I don't understand why people feel a need to specialize (after all, Debian and Red Hat have more in common than, say, Solaris and HP-UX)...
The license that comes with RHEL says all the software is GPL, but by subscribing to this license you have to have a valid subscription for every machine that you own. What that basically says to me (IANAL or a Red Hat sales person) is that if you buy one copy and then explicitly tell them that you have no interest in their subscription, you can install it on as many machines as you want.
Why would you bother tho? You can download the SRPMs and recompile those. Or use fedora, an actual, community supported distro. Cause, honestly, there doesn't seem to be a lot of community support for RHEL.
Because what you're buying from Red Hat is corporate support not software. Red Hat is in business to return value to their stockholders; they do this buy selling support contracts for software.
I do not understand what the controversy here is, I really don't. If you want the latest and greatest software, with all of the latest bells, whistles and patches, download and install it yourself. If you want something that's easy to install, and has people actively investigating and fixing bugs for free (ie: as time permits), download and install Fedora Linux. If you want something that's stable and well-supported with a guaranteed, many-year support window, then buy a copy of Red Hat Enterprise Linux, and pay the support costs each year for each of your servers. If you want support for dozens of servers, but you don't want to pay Red Hat's fees, then buy your support from someone else at a price you prefer, if you can. It's not like anyone has a gun to your head requiring you to use Red Hat...
I've been dealing with Red Hat's distribution and their support since 1996, and I have found Red Hat to be an honorable business with a well-thought-out business model. That they're still here after the ups and downs of the dot-com boom/bust speaks highly for their management.
Imagine, if you can, a computer running in 1988 with its memory in one cabinet, its I/O buses in another cabinet, and with 5 CPUs, each in their own separate cabinet, all of it cross-connected with huge cables. There were only a couple of dozen Multics installations world-wide. tops -- not enough volume to justify the custom hardware. On a hardware basis it couldn't compete with top end Unix servers, much less IBM mainframes. The only thing that Multics had going for it was its Orange-book A-level security classification. Hell, the system programming language for Multics was PL/I, which meant a huge amount of the OS was written in assembly.
As I said, it's not that Multics was bad (it was very good at a lot of things); it just cost too damn much to operate, and would cost too damn much to port to modern hardware.
IBM can make money selling Linux, AIX, Unixware, Multics, Windows, whatever.
While most of your post is accurate and informative, I have to dispute one point: nobody could make money selling Multics, or they'd still be selling it today. GE tried and failed, Honeywell tried and failed, and no one else was stupid enough to buy it after that. (I am a former Multician.) Multics was very good at a bunch of things, but it was never designed to be ported to different hardware, and it just cost too damn much to run and maintain.
Two weeks ago the Washington Post did several articles on this topic, and they put together an interactive Guide to Cell Phone Plans. Admittedly the coverage maps focus on the Washington DC area, but the rest of the information should be good nationwide. Click the 'printable' links for PDFs describing all of the plans offered by each of the carriers.
As for me? I'll be dropping SprintPCS (after 7 years) like a hot potato -- in the last 3 months they've gone from excellent to pitiful for my daily commute, which is where I need the phone the most.
Not all Linux distros use SysV init scripts. Slackware uses BSD-style scripts which are a lot easier to get your head around. (They still depend on runlevels, though...)
Non sequitur. I was talking about SysV-style init scripts, not Linux. BSD-style scripts have their own problems, primarily in the area of packaging. And for that matter, if you can't trust someone to create a properly-named symbolic link, how can you trust them to edit a shell script?
As far as "most" sysadmins not understanding run levels, he's out of his mind. Maybe he doesn't get it, but it's a long standing thing that works well. In fact, it works SO well, that Linux adopted it from System V after using the older monolithic rc scripts for a long while.
Sadly, I've met plenty of SysAdmins who didn't "get" SysV-style init scripts. Particularly the in-duh-vidual who thought that "S100weblogic" would start after "S99local". [sigh] Admittedly, I wouldn't let this person administer any of my machines, if I had any say in it (which I don't), but there are plenty of other wannabe-sysadmins out there who are confused by init scripts.
I'm not overly enthralled by this proposal, but I'm interested in the dependencies aspect -- nothing worse than changing the IP address for an interface and then trying to discover which services need to be restarted when you restart the interface. Or (hypothetically) what should start first: sendmail or its milter-daemons? A standard for specifying this type of information could be useful.
One April Fool's day I decided to have some fun with my boss. He had a huge whiteboard (4'x6') that he keep lots of notes on, and never erased. He even had some pictures taped to it. Coincidently, *his* boss also had the same size/style whiteboard that was similarly covered with un-erased notes. So I stayed late the night before... and carefully unscrewed each of the whiteboard's from the wall, and mounted the other one in its place.
When I came in the next day, I stuck my head in his office and said "hi" to see if he'd noticed, which he hadn't... yet. Then I had a quick chat with some of my cow-orkers [sic], and suggested that they have a look at his whiteboard. Pretty soon everyone in the group was having a private chuckle, while he was stewing "... because someone had used his office for a meeting, and written new stuff all over his whiteboard."
Eventually I took pity on him and switched the boards back again...
This just in ... Linus' reply
on
Back To SCO
·
· Score: 3, Informative
There's an article over on Infoworld that includes an Open Letter from Linus Torvalds on the situation. I won't quote the whole article, but here's the letter:
Open letter to Darl McBride -- please grow up.
Dear Darl,
Thank you so much for your letter.
We are happy that you agree that customers need to know that Open Source is legal and stable, and we heartily agree with that sentence of your letter. The others don't seem to make as much sense, but we find the dialogue refreshing.
However, we have to sadly decline taking business model advice from a company that seems to have squandered all its money (that it made off a Linux IPO, I might add, since there's a nice bit of irony there), and now seems to play the US legal system as a lottery. We in the Open Source group continue to believe in technology as a way of driving customer interest and demand.
Also, we find your references to a negotiating table somewhat confusing, since there doesn't seem to be anything to negotiate about. SCO has yet to show any infringing IP in the Open Source domain, but we wait with bated breath for when you will actually care to inform us about what you are blathering about.
All of our source code is out in the open, and we welcome you point to any particular piece you might disagree with.
Until then, please accept our gratitude for your submission,
Yours truly,
Linus Torvalds
Re:IT WILL NOT WORK! Here's technical reason why
on
ESR to Shred SCO Claims?
·
· Score: 3, Informative
Download & read the source. Or just read the documentation.
Comparator has the capability (-w) to ignore whitespace while generating the hash, while at the same time tracking the actual line numbers for purposes of merging and reporting. In my experience, most code-copiers are dumb and/or lazy -- to get past ESR's tool, the code-copier would have to (a) realize that they're violating a license, (b) not care, (c) be smart enough to realize that a pure cut-and-paste might get caught, and (d) energetic enough to munge up the code logic and variables. While I'm sure there are people like that, I would argue that most of them wouldn't be interested in contributing the result to the community, and the code wouldn't get past Linus if they did. The more logical case is some one/company who believe that they have a legitimate right to copy code from one kernel to another (BSD -> Linux / Linux -> SysV / SysV -> Linux) and thus not feeling the need to cover things up. Either of the SCO User Group examples would fit this category.
Slashdot Mirror
But not if you're tainted as a developer -- ie: if you've ever seen the source to Sun's JDK or even cracked open the source jar from the JDK, you're tainted. The last thing any of the open source projects needs is tainted developers. Sadly, I am tainted. Back in 1997 I made the mistake of registering for and receiving a source copy of the Sun JDK (long since lost to a hard drive crash). So no matter how much I want to contribute to the GNU Classpath project, the most I can do is write test cases.
What licensing revenue? Anyone who wants to can download Sun's JRE (Java Runtime Environment) from Sun's website and install it themselves on Windows, Linux, and Solaris at zero cost (other than bandwidth, which is negative revenue to Sun). The problem is that no one else can redistribute the JRE without getting a distribution license from Sun, which will (of course) stipulate that no one else can redistribute the JRE. This doesn't increase Sun's revenues -- it just increases the cost to deploying a Java application in a non-Solaris environment, by increasing the man-hours necessary to install and support something that by all rights should have been installed with the operating system.
The truly stupid thing is that Sun now has included technology into Java 1.4 that will allow the JRE to check for the latest version online and upgrade, automatically ... if you have all of the right system permissions and, of course, enough bandwidth to download a 44MB executable. Maybe that works great at large schools, but in corporate america, that's a no-no -- the only software that's allowed to be auto-updated are virus-scanners, and Windows security holes^Wpatches. And of course, if you're building applications that are intended to be used offline (or on a network that's detached from the Internet for security) you're just plain out of luck.
Linux (and *BSD) developers have been begging Sun for years to allow them to preinstall the JRE with their distributions, to no avail. Instead Sun has continued to follow a policy that intentionally reduces their potential marketshare, without any increase in revenue to show for it. Brilliant move, Sun!
Seriously, this is sad.
Yeah, but you can't mod posts as +1, Sad.
This is not a joke. You can look it up.
I did, and they do. Not in so many words, but read it for yourself.
But did he stay at the Holiday Inn Express last night?
No, anyone can put stuff into a language. The hard part is identifying the 'good stuff'. The creator's of PL/I did a great job of integrating all of the concepts of Fortran, Algol, and COBOL into a single language. Unfortunately, they put ALL of the concepts into PL/I, not just the good ones. So instead of voting to 'Put all the good stuff into one language', why don't you start identifying the good stuff ... and then getting the rest of the programmers to agree with you? Once that's done, it can be put into a language by almost anyone.
Personally, I'm not a single-language fanatic ... I've been programming for 25+ years, and I've probably learned more than a eighty languages (I stopped counting years ago, but I learn 3-4 a year). Not one of the languages I've used would have been perfect for ALL purposes, but many of them were damned good for their intended purpose (even COBOL).
Funny that's what they're doing ... the DishNetwork PVRs run DishLinux.
Been there, done that ... it was called PL/I.
That might make sense under the right circumstances; I don't think those circumstances will ever exist.
Currently the schools are running software that they've licensed from a vendor. Some of those schools may have paid for a source code license (which would probably restrict their rights to build competing products), others did not. Either way, the vendor owns the code, while some schools own some modifications. With that in mind, suppose you want to create an Open Source replacement system for administering colleges. You'd have to find enough schools that were willing to fund a replacement, identify all of their requirements, and then partition each of the requirements into "core", "federal", "state", and "school-specific". You're going to need a large pool of developers working for several years, and all that time you still have to pay for maintainence on the existing system, because you can't ignore the current system while building the new system. Someone will have to write software to convert all of the historical data from the old system to the replacement, because the school can't just throw away the old data. By the time you're finished, you've ended up building an entire company (even if it's owned and operated by schools) ... unlikely to succeed.
Alternately, suppose the vendor decides to Open Source the code (for whatever reason). Now you have several million lines of gobbledegook, probably written with languages and tools that are either (a) prohibitively expensive, or (b) probably unattainable. Hundreds of random programmers have spent the last 25 years hacking and patching the code as it evolved from a server/dumb terminal application through client-server and on towards something vaguely web-based (but with lots of background batch processing). Where do you get people who skilled enough to read through the code, make modifications, and build the end result? You may find that even with the source code, it's easier to rewrite from scratch than maintain that pile of hairy code. [This is the Mozilla scenario.]
(I really don't want to end this here, but I don't have the time to write the rest of this essay. Gotta go back to work to earn my salary.)If I know that there's a problem, I can respond to it. Even if the problem leaves me with a miniscule chance of survival, that's still a chance. On the other hand, if I think everything's fine while an undetected threat is approaching, I won't have any chance at all to respond. Some chance is better than no chance, every day.
Yes, all systems should work correctly, all of the time. And when I'm developing systems (oddly enough, military systems), my goal is perfection. But I know that systems fail because nothing in this world is perfect or permanent, and so I plan for failure as well as success.
I would lay good odds that once upon a time I worked for the company that made the software your friend maintains. (There aren't that many companies who do this sort of software, and I worked for one who now has more than 500 colleges as customers.) With that in mind, I think I can offer some explanation for your friend's complaints, and why open source wouldn't work to solve her problem. Let's start with a good rule of thumb:
With that in mind, let's examine the software for administering a typical 4-year college. While much of the software would be recognizable as accounting software: inventory, accounts receiveable, account payable, general ledger, payroll, etc, it will have been customized specifically for the quirks of running a large institution with a continually changing student body. Then add on class scheduling and grade calculation modules, as well as security levels to protect the privacy and security of confidential data, such as financial and health records. Finally, throw in yearly updates for the financial aid software, which has to change to meet new requirements from the US Department of Education every year. At this point you're probably talking about 5-10 million SLOCs, with a user base of 500 customers, or an OSFF of 0.0001 or less.
Another thing to keep in mind is that there are accounting certifications that have to be renewed on a yearly basis, or the college could fail an audit, which could result in its accredidation being suspended. All in all, maintaining this type of software is a very time-consuming and expensive proposition, and we're still only talking about the base package, before customizations.
Customizations can take many forms. Typical customizations are parameter-driven (school name, address, etc.) but many are the result of specific local policies and requirements. You're really talking about separate source code forks for each school. Add up the collective customizations from 500 schools are you might be talking about as much source code as the base software.
That much complexity is hard to manage; its not surprising that the company in question doesn't maintain the customizations for an individual school...
Almost any vertical application for a sufficiently complex business will have the same sort of problem, which is the major reason why Open Source Software will have a great deal of difficulty in displacing proprietary vertical applications. There just aren't enough customers for that type of software to develop the sort of community necessary to support the many man-years necessary to code an OSS competitor.
There's nothing that says that ALL of the elements of a critical system have to be open source (GPL flamewars aside). On the other hand, most of the infrastructure of a modern system (military or otherwise) is the same as any other IT system, except for having stricter reliability requirements (ie: no single-point-of-failure allowed / short recovery times). In fact, these are the same infrastructure requirements that most commercial entities would love to have, but generally can't justify on a cost basis.
Take clustered storage systems -- truly reliable (ie 0.99999 or better uptime) systems require redundant drives and redundant data paths. Proprietary implementations are expensive, but while open source implementations are gradually becoming available (ie: OpenGFS), they still have performance, scalability, and reliability limitations. There should be no reason for a military development program NOT to contribute to OpenGFS, and leverage the results for their infrastructure, even if the rest of their software is classified.
My only concern would be announcing to the world that specific strategic and tactical systems were using specific hardware and specific software -- a studious researcher could use that sort of information to estimate performance limitations. On the other hand, there are plenty of professional and industry journals that publish the same information today, often in more detail (Aviation Week has guys camping in lawn chairs ... Janes has their sources too) so I wouldn't worry a whole lot about it.
So I wouldn't necessarily Open Source the data analysis software for an air traffic control system, but I might use an Open Source infrastructure for storing the track data for playback.
There are much worse ways that software can fail. One of the worst is software that looks like it's working, but in fact is not displaying new / updated items -- this leaves the warfighter with the false impression of situational awareness. Another popular failure is software that has time-consuming processing steps that don't have adequate progress indicators -- this leaves the warfighter wondering 'Is it done yet?' when it hangs or fails.
At least with a blue screen or core dump, you know you've got a problem, and you can restart / reboot to resume, with a well known startup time.
I got my 721 last week, and while my wife had some doubts about it initially (the cost), at the end of one day's use, we are both convinced that this is definitely the best thing since sliced stupid people on toast.
What about using Red Hat Professional Workstation? Ok, so it isn't a path to their Enterprise line, but it is supported.
I think a lot of people are selling Fedora short. I've installed it and am using it as my primary desktop at home (and I expect to be upgrading my servers to it by year's end). Based upon my past experiences with Red Hat Linux (every release from 3.0.3 to 9) Fedora feels just like I would have expected from Red Hat 9.1 (or Red Hat 10). The only difference was that I downloaded ISOs and burned CDRs instead of buying CDROMs in a red box with printed documentation.
I don't know how you characterize professional, but I consider myself a professional software developer (20+ years) and I wouldn't hesitate to deploy Fedora in a small organization or a large enterprise (with adequate testing of course). Perhaps the problem is with the term 'hobbyist'?
For that matter, I don't understand why people feel a need to specialize (after all, Debian and Red Hat have more in common than, say, Solaris and HP-UX)...
Why would you bother tho? You can download the SRPMs and recompile those. Or use fedora, an actual, community supported distro. Cause, honestly, there doesn't seem to be a lot of community support for RHEL.
Because what you're buying from Red Hat is corporate support not software. Red Hat is in business to return value to their stockholders; they do this buy selling support contracts for software.
I do not understand what the controversy here is, I really don't. If you want the latest and greatest software, with all of the latest bells, whistles and patches, download and install it yourself. If you want something that's easy to install, and has people actively investigating and fixing bugs for free (ie: as time permits), download and install Fedora Linux. If you want something that's stable and well-supported with a guaranteed, many-year support window, then buy a copy of Red Hat Enterprise Linux, and pay the support costs each year for each of your servers. If you want support for dozens of servers, but you don't want to pay Red Hat's fees, then buy your support from someone else at a price you prefer, if you can. It's not like anyone has a gun to your head requiring you to use Red Hat...
I've been dealing with Red Hat's distribution and their support since 1996, and I have found Red Hat to be an honorable business with a well-thought-out business model. That they're still here after the ups and downs of the dot-com boom/bust speaks highly for their management.
Imagine, if you can, a computer running in 1988 with its memory in one cabinet, its I/O buses in another cabinet, and with 5 CPUs, each in their own separate cabinet, all of it cross-connected with huge cables. There were only a couple of dozen Multics installations world-wide. tops -- not enough volume to justify the custom hardware. On a hardware basis it couldn't compete with top end Unix servers, much less IBM mainframes. The only thing that Multics had going for it was its Orange-book A-level security classification. Hell, the system programming language for Multics was PL/I, which meant a huge amount of the OS was written in assembly.
As I said, it's not that Multics was bad (it was very good at a lot of things); it just cost too damn much to operate, and would cost too damn much to port to modern hardware.
While most of your post is accurate and informative, I have to dispute one point: nobody could make money selling Multics, or they'd still be selling it today. GE tried and failed, Honeywell tried and failed, and no one else was stupid enough to buy it after that. (I am a former Multician.) Multics was very good at a bunch of things, but it was never designed to be ported to different hardware, and it just cost too damn much to run and maintain.
Two weeks ago the Washington Post did several articles on this topic, and they put together an interactive Guide to Cell Phone Plans. Admittedly the coverage maps focus on the Washington DC area, but the rest of the information should be good nationwide. Click the 'printable' links for PDFs describing all of the plans offered by each of the carriers.
As for me? I'll be dropping SprintPCS (after 7 years) like a hot potato -- in the last 3 months they've gone from excellent to pitiful for my daily commute, which is where I need the phone the most.
Non sequitur. I was talking about SysV-style init scripts, not Linux. BSD-style scripts have their own problems, primarily in the area of packaging. And for that matter, if you can't trust someone to create a properly-named symbolic link, how can you trust them to edit a shell script?
Sadly, I've met plenty of SysAdmins who didn't "get" SysV-style init scripts. Particularly the in-duh-vidual who thought that "S100weblogic" would start after "S99local". [sigh] Admittedly, I wouldn't let this person administer any of my machines, if I had any say in it (which I don't), but there are plenty of other wannabe-sysadmins out there who are confused by init scripts.
I'm not overly enthralled by this proposal, but I'm interested in the dependencies aspect -- nothing worse than changing the IP address for an interface and then trying to discover which services need to be restarted when you restart the interface. Or (hypothetically) what should start first: sendmail or its milter-daemons? A standard for specifying this type of information could be useful.
One April Fool's day I decided to have some fun with my boss. He had a huge whiteboard (4'x6') that he keep lots of notes on, and never erased. He even had some pictures taped to it. Coincidently, *his* boss also had the same size/style whiteboard that was similarly covered with un-erased notes. So I stayed late the night before ... and carefully unscrewed each of the whiteboard's from the wall, and mounted the other one in its place.
When I came in the next day, I stuck my head in his office and said "hi" to see if he'd noticed, which he hadn't ... yet. Then I had a quick chat with some of my cow-orkers [sic], and suggested that they have a look at his whiteboard. Pretty soon everyone in the group was having a private chuckle, while he was stewing "... because someone had used his office for a meeting, and written new stuff all over his whiteboard."
Eventually I took pity on him and switched the boards back again...
There's an article over on Infoworld that includes an Open Letter from Linus Torvalds on the situation. I won't quote the whole article, but here's the letter:
Download & read the source. Or just read the documentation.
Comparator has the capability (-w) to ignore whitespace while generating the hash, while at the same time tracking the actual line numbers for purposes of merging and reporting. In my experience, most code-copiers are dumb and/or lazy -- to get past ESR's tool, the code-copier would have to (a) realize that they're violating a license, (b) not care, (c) be smart enough to realize that a pure cut-and-paste might get caught, and (d) energetic enough to munge up the code logic and variables. While I'm sure there are people like that, I would argue that most of them wouldn't be interested in contributing the result to the community, and the code wouldn't get past Linus if they did. The more logical case is some one/company who believe that they have a legitimate right to copy code from one kernel to another (BSD -> Linux / Linux -> SysV / SysV -> Linux) and thus not feeling the need to cover things up. Either of the SCO User Group examples would fit this category.