If Bill Gates had said "Hey, this Netscape thing is pretty cool. Let's license it and bundle it with Windows 95 Release 2," he would have saved himself from the trial and the financial losses there entailed.
If Bill Gates had said "Hey, this Real Audio player is pretty cool. Let's license it and bundle it with Windows 98," he would have saved himself from the trial and the financial losses there entailed.
If Bill Gates had said "Hey, this GNU software is pretty cool. Let's bundle it with Windows 2000," he would have saved himself from the trial and the financial losses there entailed.
If you remember, the economic downturn started when Judge Pensfield Jackson announced the verdict of the anti-trust trial. Indirectly, Bill Gates' hubris plunged the world into a recession.
Debian is working on a release that replaces the Linux kernel with NetBSD.
RedHat retains nominal control over RPM, the packaging format for most commercial distributions.
Gentoo goes forward in bringing BSD practices to Linux.
We need a single organization, not tied to a specific distribution, to handle these issues. UnitedLinux was too commercial, the LSB too weak, but just imagine Linux and NetBSD kernels in standard configurations, with both GNU and BSD userlands, established as standards (which the BSD people would promptly ignore, but what the hey...).
While I have not read the letter from SCO disparaging the GPL (after all, this is Slashdot), let's discuss for a moment what the proprietary software market has done.
When you purchase Microsoft Office, your check for $350 goes to Redmond, Washington. Ditto for everyone else in your state who buys a Microsoft product.
When you pay a consultant to install OpenOffice for you, your money (probably) stays in your state.
If you would like your constituents' money to remain in your state, then you should support the GPL.
If you are a Senator/Representative from the state of Washington, well, tough luck.
Due to the change from a.out to ELF binary format in OpenBSD 3.4,
upgrades can be a complex, delicate process. The best solution, whenever
possible, is to backup your data and reinstall from scratch... In all cases, once you start the upgrade you MUST complete it. If the
upgrade process fails or is abandoned before it completes you will almost
certainly be left with a non-functional system... Finally, you cannot use the bsd.rd kernel to upgrade the system. The
existing bootblocks on your system cannot boot the 3.4 bsd.rd.
I jumped from RH62 to OpenBSD3.3 some time ago. I have to admit that I've applied a lot fewer patches, security is much better, and the firewall is very powerful. In all, I'm happier.
However, I don't like:
Any version of the csh. Its faults as a scripting language are well known. I realize that BSD has an attachment of nostalgia to csh, but Bill Joy's original csh code isn't even open. All of the/etc/rc* scripts are written in pdksh, but root's shell is tcsh. Go figure.
pdksh configuration. ksh is installed as an afterthought. There is no/etc/profile, which is unfathomable to me. Using chsh to select ksh will make you grumble because nothing is set up. There should be at least functional parity between default csh and ksh configuration.
BSD inits are not runlevel friendly for reasons of nostalgia.
OpenBSD does not have methods to easily start/stop services (i.e. redhat "service network restart") for reasons of nostalgia. FreeBSD is somewhat more forward-thinking in this. OpenBSD could theoretically put a big case statement in/etc/rc to support this behavior, but pdksh does not currently support a case statement. The free ksh93 does, but it probably can't be bundled due to licensing.
Under OpenBSD, you have to upgrade a lot - at least once a year. They try to release every six months, and they only support the last two releases. Whiteboxlinux looks more attractive all the time.
Upgrading from 3.3 to 3.4 is extremely difficult since the binary format went from a.out to elf. It is usually preferable to reformat.
If errata are issued against the OpenBSD's Base Operating System, it is source only - you must recompile. If errata are issued against compiled packages, they include binaries. There is no automatic update agent. Patching in general is cryptic, the process isn't uniform, and the documentation in this area is not very good.
However, it would seem to me that what is needed is a packaging system that accomodates both binary distributions and source in a way that resolves dependencies.
There should be a hard line drawn between the source and binary environments.
The packaging system must encompass the entire Base Operating System (granted that most UNIX distributions transfer a "mini-system" at some point in the install). For example, patching the Base Operating System on OpenBSD is entirely different than applying updated packages. This inconsistency would be unacceptable for a major commercial user; the interface must be consistent.
Assuming that such a consistent packaging format could be developed, it should then be the goal to convert one of the old school UNIX players (HP and SGI might be the most receptive - there were rumors that Tru64 was going to RPM some time back; Solaris never changes anything in userland).
Until one of these packaging formats manages to win over a major UNIX player, the strife will continue.
This has probably been discussed ad infinitum, but let's compare Java to awk and perl.
awk is a fun little language, very portable. awk was supplanted by perl, however, mainly because perl allowed access to a much larger subset of the kernel API than did awk.
I don't use Java much, but it seems to me that Java's great failing it that it doesn't allow (easy) access to system calls. If I want to stat a file, open a fifo, etc., I am forced to either link in C code with JNI, or use something like system(). Perl had no problem in being a little more platform-dependent, and I think it served them well.
I wonder if this aspect of Java will ever change, and we might see kernel-specific sections of their standard library. But then again, I don't keep up with Java as I should, so perhaps we have this already.
Why can't the production of metalic vs. semiconducting nanotubes be controlled?
Are the metallic nanotubes at all useful?
Why are the semiconducting nanotubes useful?
Do the semiconducting nanotubes need uniform impurity concentrations (doping) to be useful as memory storage devices?
The major benefit of this device is that it can identify semiconducting nanotubes in an automated manner. Does this hardware actually do anything with the nanotubes once they are classified? If not, what potentially can be done?
The old TIS FWTK had a http-gw proxy that could filter out all activex and javascript. It probably wouldn't be too hard to patch the code to filter only the open() call.
I read today that Win98 is nearly 25% of the desktop clients on the internet.
If Win98 were open, somebody would be stepping in to support it as Microsoft bowed out.
Win98 is not open, and now everyone who drank the coolaid is beginning to feel the effects of the arsenic.
Commercial software is always a ring in your nose. The GPL can also be a ring, but it is lighter and the developing entity generally does not hold the chain as tightly.
...for reduced ability in India that many westerners don't realize.
India is a caste-based society. In recent times, the lower castes have been throwing their weight around in their legislature.
Of particular concern is that they have implemented a "graduated" admissions policy in their universities. An upper caste member might not be able to get into a school with a 90% score on the entrance exams, but a lower caste member may be assured admission with a 70% score.
Because of this type of (reverse)discrimination, many upper caste individuals of means leave the country to obtain education and work elsewhere. While India is a big country, the trend is concerning, and western outsourcers should be aware of it.
Many dual-cpu boards tie all the memory to one cpu, slowing down the other one.
Various versions of the AMD64 architecture are unreasonably expensive.
I've heard rumors of Linux incompatibility with various boards and bioses.
AMD is also in the act of outsourcing it's IT staff to India. While Intel undoubtedly does the same, AMD's action is more recent and this sort of thing shouldn't be rewarded.
AMD's planning with Microsoft Win64 release was also obviously lackluster if Intel was able to delay it.
For all of the hype, there are plenty of reasons to sit tight on your wallet for a (rather long) while.
...the only two major computer system manufacturers who have elected to rely upon the Itanium are HP and SGI.
HP is manufacturing a number of different Itanium systems and winning performance awards with them. The largest is the "Superdome" which I believe will hold 64 CPUs. The Superdome is interesting in that it can accept either the old (soon to be discontinued) PA-RISC processors or the newer Itanium chips (hopefully Sun will do something similar with Sparc and Opteron in a revision of the e10k line).
SGI also makes a Linux Itanium NUMA supercomputer called "Altix" that is far more scalable than Superdome.
Both of these companies are going to be royally shafted if Intel produces a chip using the Opteron/Athlon64 instruction set. Intel has been incredibly unwise in not dropping the cost of the Itanium below the Opteron. Itanium has flaws, but it does have some incredible floating point performance.
HP is probably of the greatest concern. They ported their enterprise UNIX (HP-UX) to Itanium some time ago, and they are nearing a stable port of the OpenVMS operating system to Itanium. These operating systems have large, dedicated followings and they are technically quite advanced (far more so than Linux in many respects).
If the Itanium fails, it will be a bloodbath for HP enterprise systems.
How about a patch to sendmail that includes various blacklists as part of the HELO?
The blacklists could be compressed with gzip/bzip2 and signed by Spamhaus (or whatever blacklist we trust these days) and automatically transferred when a higher version number is detected. Spamhaus would just have to seed a single high-traffic sendmail instance anywhere on the internet to flush the whole global network with a new list.
Sendmail, Inc. could put an end to Spamhaus' bandwidth requirements.
I'm not saything that there should be any binary emulation (i.e. in the style of iBCS). However, just having things laid out the same way is sometimes a huge help.
For example, under most SYSV-type Linux and HP-UX, the rcN.d directories have soft links to scripts in init.d - but in Solaris, hard links are used, meaning that you have to use inode numbers to track things down if they get messed up. Another good example is that filesystem journaling isn't enabled by default. Since Solaris userland never changes, these "flaws" will never be fixed. GNU/Solaris would be a good way of escaping what I perceive as problems.
GNU/Solaris will/would probably need more than the kernel and libc - kernel module utilities, filesystem tools (I can't see moving away from UFS), and tools for/proc will be required. However, the efficacy of GNU/Solaris seems to be similar to GNU/NetBSD, which is in beta, but it runs.
Sun will begin work on the e20k, which will support both Fujitsu Sparc and Opteron CPUs in the same box. Sun will announce that the e30k will also support Power(PC) and perhaps Itanium in addition to the above mentioned processor architectures. IBM may prove reluctant to provide Power, and Sun may turn to Motorola. Sun high end systems will render the proprietary competetion obsolete.
Sun will revive the PowerPC and Itanium ports of Solaris for the above systems.
Sun will wrap a GNU userland around the Solaris kernel and (perhaps, if licensing allows) libc. Richard Stallman will publicly embrace this distribution in an effort to differentiate FSF/GNU from Linux. Hurd development may slow. Linux adoption may slow.
Sun will also create a Solaris flavor of the Java desktop system.
SCO will go bankrupt, and Microsoft will purchase the rights to UNIX. All UNIX vendors will be under some pressure to expunge SYSV from their codebases. Elements of SYSV will migrate into the Win32 codebases at an accelerated pace.
Five more major governments will dump Microsoft Windows. Several more will dump Office. Millions of desktops will shift to Sun products (or their derivatives).
For as irrelevant as some claim that Sun has become, they could do a real number on the competetion if they get their act together.
Some people like Solaris because of this. Migration is easier when few things change... I disagree. I don't want them to do this because you can do it yourself - that's man/hour's that would be better spent on *real* solaris dev:-)
You might want to rethink your position for a few reasons:
I've never used partitions on an e10k or other machines that support it (I'm really an HP-UX admin; my Solaris experience is [mostly] confined to x86), but if a specific partition could run a Solaris kernel with a Red Hat or Debian (GNU) userland, it would a) ease porting from GNU environments, and b) probably evoke a great show of emotion from the FSF and greater open source community (Sun's reputation is not perfect; this would help). As you must realize, Stallman is not pleased with the usurping effect of the Linux kernel, and GNU/Solaris would allow him to (further) differentiate the role of the FSF - he would be pleased to add you to NetBSD for this purpose, which may work to your benefit in the end.
Sun is looking to push Solaris into new markets (Opteron). It is easier to push a new product into a new market than an old, crusty product, regardless of how scalable.
Sun seems to be on SCO's good side (for the moment), but the future of the SYSV codebase is in doubt. What if Microsoft buys it or otherwise obtains control of it? What if IBM, HP, or some other (potential) abuser obtains it in a SCO bankrupcy? I realize that Sun's license is extensive, but developing a version of Solaris that is free of SYSV would be prudent.
For these reasons, and a few more, an unsupported release of GNU/Solaris (to compliment Solaris/Classic) would be of great benefit to Sun, and work on it should be commenced as soon as reasonably possible. Debian is probably to be preferred.
Sun is no longer the UNIX market leader, nor are they the SPARC performance leader (being dethroned by Fujitsu). Sun needs to throw out a few new products to regain the lead. GNU/Solaris may become an integral part of Sun's survival (or it could be a white elephant - you might be right).
p.s. Just imagine the fun that Sun could have with "uname -a" under GNU/Solaris!
Why doesn't Sun integrate this stuff into Solaris?
on
Sun Opens Cobalt Code
·
· Score: 3, Insightful
Aside from Genome integration, Solaris userland has been static for many, many years (far too long IMHO - Sun relies upon sunfreeware.com far too much).
Why would the Cobalt code not be useful as part of the base install?
Actually, what I'd like to see is Sun pick the best GNU distribution and wrap the Solaris kernel and libc around it. Sun releasing GNU/Solaris would prove that there is life in the old girl yet.
Slashdot Mirror
If Bill Gates had said "Hey, this Netscape thing is pretty cool. Let's license it and bundle it with Windows 95 Release 2," he would have saved himself from the trial and the financial losses there entailed.
If Bill Gates had said "Hey, this Real Audio player is pretty cool. Let's license it and bundle it with Windows 98," he would have saved himself from the trial and the financial losses there entailed.
If Bill Gates had said "Hey, this GNU software is pretty cool. Let's bundle it with Windows 2000," he would have saved himself from the trial and the financial losses there entailed.
If you remember, the economic downturn started when Judge Pensfield Jackson announced the verdict of the anti-trust trial. Indirectly, Bill Gates' hubris plunged the world into a recession.
I say we hang him.
Debian is working on a release that replaces the Linux kernel with NetBSD.
RedHat retains nominal control over RPM, the packaging format for most commercial distributions.
Gentoo goes forward in bringing BSD practices to Linux.
We need a single organization, not tied to a specific distribution, to handle these issues. UnitedLinux was too commercial, the LSB too weak, but just imagine Linux and NetBSD kernels in standard configurations, with both GNU and BSD userlands, established as standards (which the BSD people would promptly ignore, but what the hey...).
Dear Senator/Representative:
While I have not read the letter from SCO disparaging the GPL (after all, this is Slashdot), let's discuss for a moment what the proprietary software market has done.
When you purchase Microsoft Office, your check for $350 goes to Redmond, Washington. Ditto for everyone else in your state who buys a Microsoft product.
When you pay a consultant to install OpenOffice for you, your money (probably) stays in your state.
If you would like your constituents' money to remain in your state, then you should support the GPL.
If you are a Senator/Representative from the state of Washington, well, tough luck.
ksh93 supports the ";&" syntax for case fallthroughs - it is this functionality that pdksh lacks. I added it as a feature request some time ago.
3.3 doesn't have case. If you find it in more recent versions of pdksh, it's because I opened the ticket requesting it.
The problems seem pretty cut and dry.
Due to the change from a.out to ELF binary format in OpenBSD 3.4, upgrades can be a complex, delicate process. The best solution, whenever possible, is to backup your data and reinstall from scratch... In all cases, once you start the upgrade you MUST complete it. If the upgrade process fails or is abandoned before it completes you will almost certainly be left with a non-functional system... Finally, you cannot use the bsd.rd kernel to upgrade the system. The existing bootblocks on your system cannot boot the 3.4 bsd.rd.
Pardon me for reading the instructions.
I jumped from RH62 to OpenBSD3.3 some time ago. I have to admit that I've applied a lot fewer patches, security is much better, and the firewall is very powerful. In all, I'm happier.
However, I don't like:
And let's not even get started on Mac OS X.
As you can see.
My ISP charges for extra IP addresses ($5/month).
I will still hide multiple systems behind a single address to avoid these costs.
Look, I'm only familiar with RPM.
However, it would seem to me that what is needed is a packaging system that accomodates both binary distributions and source in a way that resolves dependencies.
There should be a hard line drawn between the source and binary environments.
The packaging system must encompass the entire Base Operating System (granted that most UNIX distributions transfer a "mini-system" at some point in the install). For example, patching the Base Operating System on OpenBSD is entirely different than applying updated packages. This inconsistency would be unacceptable for a major commercial user; the interface must be consistent.
Assuming that such a consistent packaging format could be developed, it should then be the goal to convert one of the old school UNIX players (HP and SGI might be the most receptive - there were rumors that Tru64 was going to RPM some time back; Solaris never changes anything in userland).
Until one of these packaging formats manages to win over a major UNIX player, the strife will continue.
This has probably been discussed ad infinitum, but let's compare Java to awk and perl.
awk is a fun little language, very portable. awk was supplanted by perl, however, mainly because perl allowed access to a much larger subset of the kernel API than did awk.
I don't use Java much, but it seems to me that Java's great failing it that it doesn't allow (easy) access to system calls. If I want to stat a file, open a fifo, etc., I am forced to either link in C code with JNI, or use something like system(). Perl had no problem in being a little more platform-dependent, and I think it served them well.
I wonder if this aspect of Java will ever change, and we might see kernel-specific sections of their standard library. But then again, I don't keep up with Java as I should, so perhaps we have this already.
The old TIS FWTK had a http-gw proxy that could filter out all activex and javascript. It probably wouldn't be too hard to patch the code to filter only the open() call.
I think that this letter was sent to UNIX source licensees, not OpenServer/UnixWare customers.
This is aimed at SGI, perhaps Cray, HP, etc.
Well, you did flame more than a bit.
Just ask some BSD people... there are obvious problems with the GPL. However, the Win98 example is a perfect illistration of what's right.
I read today that Win98 is nearly 25% of the desktop clients on the internet.
If Win98 were open, somebody would be stepping in to support it as Microsoft bowed out.
Win98 is not open, and now everyone who drank the coolaid is beginning to feel the effects of the arsenic.
Commercial software is always a ring in your nose. The GPL can also be a ring, but it is lighter and the developing entity generally does not hold the chain as tightly.
...for reduced ability in India that many westerners don't realize.
India is a caste-based society. In recent times, the lower castes have been throwing their weight around in their legislature.
Of particular concern is that they have implemented a "graduated" admissions policy in their universities. An upper caste member might not be able to get into a school with a 90% score on the entrance exams, but a lower caste member may be assured admission with a 70% score.
Because of this type of (reverse)discrimination, many upper caste individuals of means leave the country to obtain education and work elsewhere. While India is a big country, the trend is concerning, and western outsourcers should be aware of it.
Apple is pretty much dipping their toe in the pond at this point. Sun has been immersed for some time.
Let's just review a few facts:
For all of the hype, there are plenty of reasons to sit tight on your wallet for a (rather long) while.
...the only two major computer system manufacturers who have elected to rely upon the Itanium are HP and SGI.
HP is manufacturing a number of different Itanium systems and winning performance awards with them. The largest is the "Superdome" which I believe will hold 64 CPUs. The Superdome is interesting in that it can accept either the old (soon to be discontinued) PA-RISC processors or the newer Itanium chips (hopefully Sun will do something similar with Sparc and Opteron in a revision of the e10k line).
SGI also makes a Linux Itanium NUMA supercomputer called "Altix" that is far more scalable than Superdome.
Both of these companies are going to be royally shafted if Intel produces a chip using the Opteron/Athlon64 instruction set. Intel has been incredibly unwise in not dropping the cost of the Itanium below the Opteron. Itanium has flaws, but it does have some incredible floating point performance.
HP is probably of the greatest concern. They ported their enterprise UNIX (HP-UX) to Itanium some time ago, and they are nearing a stable port of the OpenVMS operating system to Itanium. These operating systems have large, dedicated followings and they are technically quite advanced (far more so than Linux in many respects).
If the Itanium fails, it will be a bloodbath for HP enterprise systems.
How about a patch to sendmail that includes various blacklists as part of the HELO?
The blacklists could be compressed with gzip/bzip2 and signed by Spamhaus (or whatever blacklist we trust these days) and automatically transferred when a higher version number is detected. Spamhaus would just have to seed a single high-traffic sendmail instance anywhere on the internet to flush the whole global network with a new list.
Sendmail, Inc. could put an end to Spamhaus' bandwidth requirements.
I'm not saything that there should be any binary emulation (i.e. in the style of iBCS). However, just having things laid out the same way is sometimes a huge help.
For example, under most SYSV-type Linux and HP-UX, the rcN.d directories have soft links to scripts in init.d - but in Solaris, hard links are used, meaning that you have to use inode numbers to track things down if they get messed up. Another good example is that filesystem journaling isn't enabled by default. Since Solaris userland never changes, these "flaws" will never be fixed. GNU/Solaris would be a good way of escaping what I perceive as problems.
GNU/Solaris will/would probably need more than the kernel and libc - kernel module utilities, filesystem tools (I can't see moving away from UFS), and tools for /proc will be required. However, the efficacy of GNU/Solaris seems to be similar to GNU/NetBSD, which is in beta, but it runs.
...that:
For as irrelevant as some claim that Sun has become, they could do a real number on the competetion if they get their act together.
You might want to rethink your position for a few reasons:
For these reasons, and a few more, an unsupported release of GNU/Solaris (to compliment Solaris/Classic) would be of great benefit to Sun, and work on it should be commenced as soon as reasonably possible. Debian is probably to be preferred.
Sun is no longer the UNIX market leader, nor are they the SPARC performance leader (being dethroned by Fujitsu). Sun needs to throw out a few new products to regain the lead. GNU/Solaris may become an integral part of Sun's survival (or it could be a white elephant - you might be right).
p.s. Just imagine the fun that Sun could have with "uname -a" under GNU/Solaris!
Aside from Genome integration, Solaris userland has been static for many, many years (far too long IMHO - Sun relies upon sunfreeware.com far too much).
Why would the Cobalt code not be useful as part of the base install?
Actually, what I'd like to see is Sun pick the best GNU distribution and wrap the Solaris kernel and libc around it. Sun releasing GNU/Solaris would prove that there is life in the old girl yet.