OpenCYC.org project Sourceforge CVS repository has not beent updated since October 22nd 2003. I hope some of that DARPA money will go a little way towards completeting the 1.0 release.
On
Windows, most of the viruses are e-mail borne. On the Linux side, today
and in the future, viruses are network-aware, and [they] take advantage
of vulnerabilities in networks or systems to infect machines. The
Slapper worm, for example, attacked vulnerabilities in OpenSSL and
Apache.
I have deployed Linux on the desktop (RH8+Ximian to RH9+StarOffice) in
an enterprise and they do not suffer from such problems for long.
1) The only network service the desktop systems expose is OpenSSH and
the Iptables limit access from only three addresses.( We use a custom
script with ssh to keep the systems rpms uptodate from a private
mirror).
2) The iptables are configured to allow the desktops client services to connect only to the specified server.
3) The/usr partions are mounted read only and the/tmp,/home,/var directories are mounted non executable.
4) None of the users have, or need, root access. They have access to printer setting etc via Webmin's Usermin which runs on a dedicated server.
5) Mounting the users home directory required shares etc ( we use Samba
for domain, file and print services ) is performed by script when the
user logs in.
6) We update all the desktops within minutes of a updated RPM package
becoming available. The window of opportunity for any disclosed
vulnerability is very small.
7) We schedule Tripwire to check the intergrity of the desktops a couple time a day.
Microsoft's desktop security issues stem from its reliance on the Antivirus industries "Infect-Scan-Remove" approach.
In comparison, right from the outset, open source desktop platforms and applications have relied almost wholly on closing the infectable vectors, the exploited vulnerabilities used by malware, as quickly as possible.
Read the following Usenet thread from 2000 that covers the argument in detail. David Harley and Robert Moir are two Anitvirus industry leaders. It also includes the prediction that Microsoft would eventually get into the antivirus industry.
If you have a spare hour, listen to Dr Dobbs' technetcast:
Dr. Blaine Burnham, Director, Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA), gives an overview of current encryption and security technologies and outlines possible strategies for future defense. 9th USENIX Security Symposium, KeynoteMP3 [2000-10-09] (57min)
Pre-Trillian IA-64 Linux
Contributions
* Feb '98: IA-64 Linux work begins at HP
* Oct '98: HP toolchain complete
* Jan '99: Kernel boots on processor simulator at HP
* Mar '99: First Public demo of IA-64 Linux on HP
simulator
* Mar '99: Linux boots on Itanium(TM) processor logic
model at Intel
* Apr '99: CERN joins HP development effort for C library
* Apr '99: IA-64 Linux work begins at VA Linux Systems
* May '99: Trillian Project Founded
HP donates initial toolchain and foundation kernel source code Intel and VA Linux Systems provide platform source code
From Jun 2003 So, how did Linux become so capable of scaling beyond the heights of
the old UNIXs. More importantly, who helped put what where?
As with the marketing of cars and TVs, it is the vendor's high end
leading edge models which sells the standard models, from which most of
the sales and profit is made. For the enterprise server market today,
that high end is multi-headed 64-bit SMP
systems, never mind the fact that single 32-bit processors provide more
than enough power to do most jobs. For all intents and purposes, it is
the ability of the core OS to scale on 64-bit SMP systems that defines
"enterprise scalability". Other enterprise feature are effectively just
add-ons, which in the case of Linux, have been freely contributed from
many vendors and developers.
Since version 2.0, Linux was more than just a 32-bit x86
operating
system. With the insistence and assistance of Jon "Maddog" Hall, Linux
was already ported to the 64-bit Alpha processor, which delivered great
performance and stability. Just like the traditional AT&T UNIX
source base, the ownership of the Alpha chipset passed though many
hands, suffering the same fate of a thousand cutbacks. Even Alpha's
"native" OS, VMS, has been ported to Itanium by HP/Compaq.
Since 1997, Intel has been promoting the Itanium line as the
inevitable successor for every other server processor on the market.
Despite the early vaporware status, Intel has been very successful, at
least in terms of marketing. With the exception of its mainframe
systems, even IBM ships Itanium systems that directly compete with
their own Power processors.
For what The SCO Group has to offer with SCO Unixware 7,the
Itanium line is the only 64-bit option. The problem for The SCO Group
is that modern Linux can compete so well in that same market that the
value of Unixware is rapid deteriorating to a historical curiosity. I
suspect that The SCO Group (at that time called Caldera) executives
were well aware of this before they acquired the server part of Old SCO
in August 2000, or they would have known, if they spoken to the right
executives and technical staff.
So how did Linux get scale on Itanium? The SCO Group would have
you
believe it was all IBM's doing, which isn't as interesting as the real
story. The web of history weaves to encircle and entangle a much more
diverse group of conspirators, including many of The SCO Group,
Caldera, and old SCO's own former executives and other employees.
In October 1998, IBM, Old SCO and Sequent teamed up to
collectively develop parts of Unixware and AIX into scalable
64-bit-ready ports for IBM's Power processors and Intel's AI64, or
Itanium, under the banner of Project Monterey. But by then, it was
already too late.
In February 1998, well before even the first prototype IA-64
chips were available, a skunkworks team at HP, with some assistance
from Intel, began the work toward porting Linux to IA-64. By October
1998, around the same time that IBM, Old SCO and Sequent had finished
negotiations, HP had completed the build toolchain. By January 1999,
the Linux kernel was booting on an IA-64 processor simulator, months
before the actual Itanium processor was available. In March 1999, at
Intel, Linux was booting on the actual Intel Itanium processor. In
April 1999, CERN joined the project for the port of the GNU C library
and VA Linux Systems joined the project and rapidly improved the
stability and performance.
In May 1999, the Trillian Project was founded and HP, VA Linux and
Intel collectively provided their source patches to the Linux kernel for the Itanium port under the GNU general public license.
A bootable kernel alone however does not make an OS make. HP
supplied the patches for the toolchain (initial GCC C/C++ compiler, gas
assembler, ld linker). Intel supplied the test platforms, apache, EFI,
FPSWA, SCSI, SMP, libm (the old Linux C libraries). VA Linux ported E,
E-Term, XFree86, utilities
Having been involved in a couple of in house enterprise projects
and having spoken to dozens of local developers on the subject of
failed and successful projects, IMHO the three major reasons for large
in house software project failure are: 1) Starting a project from scratch staffed by only inadequately experienced developers; 2) Changing members ( managment and programmers ) in projects that have failed to fully document the project; 3) The Vendor Dependent Death March : When in house projects are
dependent on proprietary vendor specific APIs/functionality then the
project is almost guaranteed to fail when dependent vendors either
fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside
factors for the failure of large software projects. In most cases, in
house development teams just cannot keep up with the vendor
brand-new-innovative-reason-to-upgrade "features" of each release.
Larger
in-house projects take around one to three years to mature, and need
around a seven year window to recover the ROI. Porting existing
software to the vendors new system often takes more effort than the
development of the original software ( pity the Visual Basic coders who
have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon
stable vendor independent foundations, augmented with open sourced
software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX
. Linux and all of the Unix based systems implement
native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source
licensed software, by being rebuilt in house so that it runs from
subdirectories of the project (/opt/[organization]/[project]/[package]
). The distribution/OS Vendor can then ship conflicting versions of
dependent packages without it breaking the project code. The in house
developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the
braking point for many failed in house projects. The solution is to
build client/server code that uses a standard browser interface or use a standard GUI networked interface that has
remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting
behind an internal firewall and it will run productively for over a
decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When
interfacing with any changeable or vendor specific system , build a
connecting system that runs as standalone binary ( or plugin DDL ) that
sits between the project code and the application/library. Future
developers can quickly hack the independent module without touching the
base project source code. This strategy has saved my sanity a number of
times.
If at all possible ( subject to NDAs ) develop as much of
the code as possible as an open source project. Even if only a couple
of other individuals or organizations end up deploying software from
the same base, it will give your developer and managers feedback from
outside developers who often more free of the inside office politics to
give a more honest opinion on the quality of the source code.
1 Gb Ram runs from $150 to $200 US Retail. I assume that Apple purchasing in bulk should be able to get a much better deal than that.Sans the HD, DVD and IDE/SATA interfaces, it should be quite do-able from Apple.
At least in terms of reliability, a multi RAID server + Gig ethernet setup is better than imaging drives across each client system. The Mac Mini has athe slower 2 1/2" Hard drives, I think that a common shared RAID array could deliver better performance as well.
I have been looking at a friend's Mac Mini, and if it has 512 Meg of memory installed, it is a suitable replacement for Win9x/NT/Win2K and XP for a business desktop for the next five to seven year hardware upgrade cycle. However, IT management wise, there is no real signifcant advantage to deploying Mac Mini as networked desktops in bulk, incomparison to switching most the existing hardware over to a combination of diskless thin and slim ( running most programs on the client ) systems running Linux.
If Apple were to introduce a Mini like diskless slim client, it would probably blow both Windows and Linux away. The diskless Mac "Metro" clients would connect via Gigabit ethernet to a Mac
"Metro" Station, the latter performing the role of a raided iSCSI/Fileserver with an inbuilt network switch to directly connect each client.
Sample Mac "Metro" client specs:
Using the Mac Mini as a starting point
Ditch the DVD and Hard drives,
Make one to two Gigabtyes memory as standard,
Upgrade the 100/10 Mib network to 1Gig,
Boot using PXE,
Run all programs on the client in ram, using iSCSI read only access for a common system partition, and dedicated zones server side for each client for swap and read write disk space,
Cheap price, these diskless systems should be well under $100 US
Mac "Metro" "Station" specs:
Combination fileserver and high speed network switch,
Sell four, eight to forty eight ( plus one/two uplink ) port variants, each can support the same number of Metro clients that connect to their own dedicated port,
Raid array as standard, scaled to the number of clients supported,
Filesystem versioning ( Revision tracking and control ) as standard for all document directories and intergrity checking for all filesystems,
A DVD R/W ( or better ) drive for upgrade nd backups.
At a low/suitable per client price, such a system could blow Microsoft out of the business
desktop market.
Having been involved in a couple of in house enterprise projects and having spoken to dozens of local developers on the subject of failed and successful projects, IMHO the three major reasons for large in house software project failure are: 1) Starting a project from scratch staffed by only inadequately experienced developers; 2) Changing members ( managment and programmers ) in projects that have failed to fully document the project; 3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project (/opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
Both above vendors require per seat licensing, and can lock the enterprise in at the IT management level. But both also offer many of the same advantages of Linux on the desktop for a fraction of the effort and inside knowledge required.
In the last six years information technology vendors have adopted techniques and resources from two existing movements geared toward the construction of software. The newer open source movement, represented by the non-profit Open Source Initiative (OSI) corporation, emphasizes the licensing of software in a manner which encourages its collaborative development in an open environment. The older free software movement, represented by the non-profit Free Software Foundation (FSF), focuses on the ethical issues surrounding the licensing of software. The free software movement emphasizes freedoms which are often taken for granted outside of the field of software: the freedom to use, study how something works, improve or adapt it and redistribute.
The Free Software Foundation offers two software license schemes which are compatible with their own goals and those of the Open Source Initiative: The GNU General Public License (GPL) and the GNU Library General Public License (LGPL). Essentially, the GPL and LGPL licenses grant the recipient extra rights than that granted by copyright law. Both licenses insure that a contributer or distributer of a GPL or LGPL licensed work may not further impede downstream recipients the rights granted by the same license. Many developing software in an open source manner have realized that this benefit offered by the GPL and LGPL licenses outweigh any potential losses. The licensing also insures that no contributing or distributing vendor or group of vendors could potentially monopolize the market, insuring that real market competition dictates price. Just as the automotive industry can commonize on standards for the production of the mechanisms of seats, instrument panels and doors while providing brand and regional differentiation across a wide array of models, the information technology community can collaboratively develop works under free licenses. Both vendors and consumers benefit from the resulting development cost reductions and competition from use of the resulting commons.
Just as early twentieth century motor racing pushed the development of the automobile, the world desperately needs a world wide racing series for hybrid electric cars.
The fantastic acceleration that in line wheel electric drive can potentialy deliver would make for some very exciting racing.
One more advantage of a Virtualised Standard platform, would be the ability to do development and stress testing on third party servers. Full on stress testing is something that most organizations cannot afford to do on the currently deployed hardware.
First of all, it all depends on what are the bottlenecks in the proccessing of the transactions. That is dictated by the combination of the hardware and network bandwidth and overall design of the existing software system. The worst cases are bottlenecks in the design of the software, where all transactions have to pass some/all data through a single proccess/proccessor. If the problem is just hardware scaleabilty or reliability is the problem then grid/cluster computing can help.
If you choose a standardized virtualized platform then you need not be limited to using in house clusters. Check out ActiveGrid(TM) info page, it includes support for third party distributed hosting provider such as Akamai, . Other providers in the future, will provide massively scaleable systems such as Cray's Red Storm Cluster. All running Linux.
Up to 27 gigabytes of compressed Open Source source code and binaries in a live file system.
Don't worry about distribution - they will just send it to everybody as an email attachment.
opps, should be "third chapter of Foundation"
on
Emergence
·
· Score: 1
Digging in my book boxes to find Foundation and empire.
Psychohistory (fictional) emerging?
on
Emergence
·
· Score: 1
This sound like the precursor science to Isaac Asimov's fictional Psychohistory.
BTW has anybody else noticed the analogies between Asimov's original Foundation series and the adoption of Open Source/Free Licensed Software. We are about heading towards the second Stallman crises : The Merchant Princes.
"So by the same reasoning which make me sure that the Korellians will revolt in favor of prosperty, I am sure
we will not revolt against it. The game will be played out to it's end.
Trader Mallow from The Merchant Princes, second chapter of Foundation by Isaac Asimov
Slashdot Mirror
OpenCYC.org project Sourceforge CVS repository has not beent updated since October 22nd 2003. I hope some of that DARPA money will go a little way towards completeting the 1.0 release.
Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA
Trusted Build Agents are the final twelth step in my Twelve Step TrustABLE IT blog entry.
Also is already possible to secure Linux desktops the "right way"
In comparison, right from the outset, open source desktop platforms and applications have relied almost wholly on closing the infectable vectors, the exploited vulnerabilities used by malware, as quickly as possible.
Read the following Usenet thread from 2000 that covers the argument in detail. David Harley and Robert Moir are two Anitvirus industry leaders. It also includes the prediction that Microsoft would eventually get into the antivirus industry.
If you have a spare hour, listen to Dr Dobbs' technetcast:
Intel had prototype Itanium chips by early April/March.
So, how did Linux become so capable of scaling beyond the heights of the old UNIXs. More importantly, who helped put what where?
As with the marketing of cars and TVs, it is the vendor's high end leading edge models which sells the standard models, from which most of the sales and profit is made. For the enterprise server market today, that high end is multi-headed 64-bit SMP systems, never mind the fact that single 32-bit processors provide more than enough power to do most jobs. For all intents and purposes, it is the ability of the core OS to scale on 64-bit SMP systems that defines "enterprise scalability". Other enterprise feature are effectively just add-ons, which in the case of Linux, have been freely contributed from many vendors and developers.
Since version 2.0, Linux was more than just a 32-bit x86 operating system. With the insistence and assistance of Jon "Maddog" Hall, Linux was already ported to the 64-bit Alpha processor, which delivered great performance and stability. Just like the traditional AT&T UNIX source base, the ownership of the Alpha chipset passed though many hands, suffering the same fate of a thousand cutbacks. Even Alpha's "native" OS, VMS, has been ported to Itanium by HP/Compaq.
Since 1997, Intel has been promoting the Itanium line as the inevitable successor for every other server processor on the market. Despite the early vaporware status, Intel has been very successful, at least in terms of marketing. With the exception of its mainframe systems, even IBM ships Itanium systems that directly compete with their own Power processors.
For what The SCO Group has to offer with SCO Unixware 7,the Itanium line is the only 64-bit option. The problem for The SCO Group is that modern Linux can compete so well in that same market that the value of Unixware is rapid deteriorating to a historical curiosity. I suspect that The SCO Group (at that time called Caldera) executives were well aware of this before they acquired the server part of Old SCO in August 2000, or they would have known, if they spoken to the right executives and technical staff.
So how did Linux get scale on Itanium? The SCO Group would have you believe it was all IBM's doing, which isn't as interesting as the real story. The web of history weaves to encircle and entangle a much more diverse group of conspirators, including many of The SCO Group, Caldera, and old SCO's own former executives and other employees.
In October 1998, IBM, Old SCO and Sequent teamed up to collectively develop parts of Unixware and AIX into scalable 64-bit-ready ports for IBM's Power processors and Intel's AI64, or Itanium, under the banner of Project Monterey. But by then, it was already too late.
In February 1998, well before even the first prototype IA-64 chips were available, a skunkworks team at HP, with some assistance from Intel, began the work toward porting Linux to IA-64. By October 1998, around the same time that IBM, Old SCO and Sequent had finished negotiations, HP had completed the build toolchain. By January 1999, the Linux kernel was booting on an IA-64 processor simulator, months before the actual Itanium processor was available. In March 1999, at Intel, Linux was booting on the actual Intel Itanium processor. In April 1999, CERN joined the project for the port of the GNU C library and VA Linux Systems joined the project and rapidly improved the stability and performance.
In May 1999, the Trillian Project was founded and HP, VA Linux and Intel collectively provided their source patches to the Linux kernel for the Itanium port under the GNU general public license.
A bootable kernel alone however does not make an OS make. HP supplied the patches for the toolchain (initial GCC C/C++ compiler, gas assembler, ld linker). Intel supplied the test platforms, apache, EFI, FPSWA, SCSI, SMP, libm (the old Linux C libraries). VA Linux ported E, E-Term, XFree86, utilities
1) Starting a project from scratch staffed by only inadequately experienced developers;
2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package]
). The distribution/OS Vendor can then ship conflicting versions of
dependent packages without it breaking the project code. The in house
developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
Repost
1 Gb Ram runs from $150 to $200 US Retail. I assume that Apple purchasing in bulk should be able to get a much better deal than that.Sans the HD, DVD and IDE/SATA interfaces, it should be quite do-able from Apple.
At least in terms of reliability, a multi RAID server + Gig ethernet setup is better than imaging drives across each client system. The Mac Mini has athe slower 2 1/2" Hard drives, I think that a common shared RAID array could deliver better performance as well.
Yes, NZheretic is David Mohring.
If Apple were to introduce a Mini like diskless slim client, it would probably blow both Windows and Linux away. The diskless Mac "Metro" clients would connect via Gigabit ethernet to a Mac "Metro" Station, the latter performing the role of a raided iSCSI/Fileserver with an inbuilt network switch to directly connect each client.
Sample Mac "Metro" client specs:
Using the Mac Mini as a starting point
Ditch the DVD and Hard drives,
Make one to two Gigabtyes memory as standard,
Upgrade the 100/10 Mib network to 1Gig,
Boot using PXE,
Run all programs on the client in ram, using iSCSI read only access for a common system partition, and dedicated zones server side for each client for swap and read write disk space,
Cheap price, these diskless systems should be well under $100 US
Mac "Metro" "Station" specs:
Combination fileserver and high speed network switch,
Sell four, eight to forty eight ( plus one/two uplink ) port variants, each can support the same number of Metro clients that connect to their own dedicated port,
Raid array as standard, scaled to the number of clients supported,
Filesystem versioning ( Revision tracking and control ) as standard for all document directories and intergrity checking for all filesystems,
A DVD R/W ( or better ) drive for upgrade nd backups.
At a low/suitable per client price, such a system could blow Microsoft out of the business desktop market.
1) Starting a project from scratch staffed by only inadequately experienced developers;
2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
Combining Cujo with Pet Sematary.
The fantastic acceleration that in line wheel electric drive can potentialy deliver would make for some very exciting racing.
One more advantage of a Virtualised Standard platform, would be the ability to do development and stress testing on third party servers. Full on stress testing is something that most organizations cannot afford to do on the currently deployed hardware.
Was it the design of the software or the limitations of the hardware? See my post on Scalability on demand and third party servers.
If you choose a standardized virtualized platform then you need not be limited to using in house clusters. Check out ActiveGrid(TM) info page, it includes support for third party distributed hosting provider such as Akamai, . Other providers in the future, will provide massively scaleable systems such as Cray's Red Storm Cluster. All running Linux.
Sounds like Comair could have used a little virtualized scalability and third party audited builds.
See Twelve Step TrustABLE IT : VLSBs in VDNZs From TBAs.
and also The ActiveGrid(TM) Grid Application Server and Grid Computing in general.
Linux expands beyond the office into the home.
Don't worry about distribution - they will just send it to everybody as an email attachment.
Digging in my book boxes to find Foundation and empire.
BTW has anybody else noticed the analogies between Asimov's original Foundation series and the adoption of Open Source/Free Licensed Software. We are about heading towards the second Stallman crises : The Merchant Princes.