Two points that nobody AFAICS really commented out. (though "The end of the OS monopoly" subthread got close)
1) Since Linux distros are largely made up of GPL'd software, that means AOL is tapping into a large base of software that Microsoft can never touch nor copy. Microsoft has even made it a point to tell its employees and partners to never look at GPL'd code.
2) What happens if AOL "wins" the OS war, using Linux? Now we are replacing one monopoly with another.
If you think distros are going to proudly avoid LSB compliance(ah, I wish...), you are smoking something. Distros are already making major efforts to be compliant with the LSB. All the major distros have some LSB compliance effort going AFAIK.
It should be noted that LSB is not really a standard, and not really intended as a standard. It is intended as a common practices document, as the LSB mission statement points out.
My personal objections to the LSB are large, and centered around one single fact: The LSB documents as "standard" the GNU C library and command line utilities. This means that every Linux/bin/cat must support odd and non-Unix GNU options like --number-nonblank and --squeeze-blank and --show-nonprinting./bin/cat must support cat -E, which could easily be replaced by a sed script (GNU cat implementor was apparently unaware of sed's existence). This means that, according to the LSB, libc[56] is non-standard because it does not support glibc-specific functions and interface.
So, the net effect is that any system claiming to be Linux-standard [according to the LSB] must support all these wacky, underused, GNU-specific extensions in their commands and C library. Given the proliferation of C libraries under Linux this seems like a mistake of a large order.
These are not surprising results. Even the gcc developers will admit that many general, not-architecture-specific optimizations done by commercial compilers are not performed in gcc. Most new CPUs, not just Intel CPUs, can benefit from a smarter compiler to take advantage of features like data prefetching, instruction bundling and pipelining, profile-based (feedback-based) optimization, data and control speculation, and much more.
The gcc "open projects" page gives people a good idea of what remains to be done on gcc. The minutes of the IA-64 GCC summit are especially interesting and informative, because it gives a good idea of the current state of GCC and also what GCC needs to be a competitive compiler in the future.
Bottom line: Do not be surprised when commercial compilers beat gcc performance. It's catching up, but it's still got a long way to go.
What I gathered from the kernel mailing list, the problem seems to be that VIA has shipped a whole series of different
chipsets with bugs using the same version number. The problem is that there is no way one could make a nice workaround.
Well, not exactly wrong:)
The bigger problem is finding out what exactly is wrong. The only information available so far has been reverse engineered (AFAIK) and posted on the 3rd party site viahardware.com. So far all the information we have is "before BIOS update X" and "after BIOS update X" snapshots of the system setup.
It's pretty easy to figure out real quick which systems are broken. It's tougher to figure out what is broken, and what the right fix is.
My servers will sit tight at 2.4.5 though, there's really no reason to upgrade.
No doubt I am biased, but I disagree.
There are noteworthy VM fixes, buffer I/O deadlock fixes, and vfs fixes.
Plus the usual raft of driver fixes and merges from Alan Cox's tree. See Alan Cox's changelog as a supplement to the official changelog from Linus. Linus compresses many changes from Alan into a single word in the changelog, "merges."
Yes, but... there is such a thing as 'aux power'. Among other solutions, you can always create an adapter that plugs your power supply into your PCI card to guard against power blips on reboot. Some of my current Ethernet cards already support 'aux power', which is defined in the PCI bus specification.
And might it not just be simpler to keep this as a seperate device?
Agreed. The additional complexity needed to guard against host powerloss seems needless when you could build a separate device more easily.
This article at ZDNet says: But sources close to the deal said Red Hat (Nasdaq: RHAT) Linux will be the Linux distribution that will be pre-loaded on Lawson's servers.
Alas, I work for the competition (Mandrake) so I'm not officially allowed to be ecstatic at the news... this is good news for Linux overall.
Actually, Ulrich Weigand has code for an x86 emulator inside WINE; it's existing for quite a while. The big snag porting WINE to other architectures are either endian problems or alignment problems. And fixing those problems make writing the X86 instruction interpreter the easy part.
Seriously, Al Viro is the only one standing up and doing VFS work, and informing Linus of his changes. I don't see anyone else actively hacking on the VFS, and then trying to push their changes through to Linus.
I'm a driver hacker not a VFS hacker so I'm not gonna comment on whether the current changes are good or bad. But I will say that Al Viro is the most active at pushing VFS patches straight to Linus. Further, he does post things on linux-fsdevel describing his ideas and designs. It's little wonder his changes go in.
If that situation needs to be changed, someone has got to sit down, code a better solution, and advocate it with Linus. Not just whine on Slashdot.
Jeff
P.S. I don't want to give the impression that Al Viro is the only one working on VFS. But merely wish to point out that he is the most active at pushing patches to Linus currently.
Seriously, this BIOS stuff has got to go. Nobody uses 16-bit operating systems anymore; why are we still booting 32-bit (and soon 64-bit) operating systems using a 16-bit BIOS?
linuxbios boots into 32-bit protected mode as soon as possible, so that we can write as much code as possible in 32-bit C, compiled with gcc.
I really think that the concept of having a pentium optimied distro really cheats most of the people in the computer world who either don't own a pentium level x86 machine and or don't own an intel machine.
Linux-Mandrake supports: i486, i586, k6 (unreleased), alpha, ultrasparc, and ppc.
A few cameras out there plug directly into an ethernet device, and include a mini-webserver so that you can use HTTP to retrieve the image to your central server.
Slashdot Mirror
The press release nor either of the PS2 web sites appeared to mention source code, as far as I could see. So I asked for a clarification.
Color me impressed. Not only did I receive a reply within minutes, but they are indeed fully abiding by the GPL.
This forum message contains the reply with a bit more info.
Thanks, Sony!
1) Since Linux distros are largely made up of GPL'd software, that means AOL is tapping into a large base of software that Microsoft can never touch nor copy. Microsoft has even made it a point to tell its employees and partners to never look at GPL'd code.
2) What happens if AOL "wins" the OS war, using Linux? Now we are replacing one monopoly with another.
If you think distros are going to proudly avoid LSB compliance(ah, I wish...), you are smoking something. Distros are already making major efforts to be compliant with the LSB. All the major distros have some LSB compliance effort going AFAIK.
My personal objections to the LSB are large, and centered around one single fact: The LSB documents as "standard" the GNU C library and command line utilities. This means that every Linux
So, the net effect is that any system claiming to be Linux-standard [according to the LSB] must support all these wacky, underused, GNU-specific extensions in their commands and C library. Given the proliferation of C libraries under Linux this seems like a mistake of a large order.
The gcc "open projects" page gives people a good idea of what remains to be done on gcc. The minutes of the IA-64 GCC summit are especially interesting and informative, because it gives a good idea of the current state of GCC and also what GCC needs to be a competitive compiler in the future.
Bottom line: Do not be surprised when commercial compilers beat gcc performance. It's catching up, but it's still got a long way to go.
GCC Home Page
This change is present in kernel 2.4.13 (and yes I looked at your corrected link).
The page_launder changes were backed out and then Linus wrote his own fix for the problem. So, no.
Well, not exactly wrong :)
The bigger problem is finding out what exactly is wrong. The only information available so far has been reverse engineered (AFAIK) and posted on the 3rd party site viahardware.com. So far all the information we have is "before BIOS update X" and "after BIOS update X" snapshots of the system setup.
It's pretty easy to figure out real quick which systems are broken. It's tougher to figure out what is broken, and what the right fix is.
No doubt I am biased, but I disagree.
There are noteworthy VM fixes, buffer I/O deadlock fixes, and vfs fixes.
Plus the usual raft of driver fixes and merges from Alan Cox's tree. See Alan Cox's changelog as a supplement to the official changelog from Linus. Linus compresses many changes from Alan into a single word in the changelog, "merges."
We have own our GUI BASIC: GNOME BASIC.
http://www.gnome.org/gb
Mandrake Cooker has Alpha versions of our latest RPMS. The installer has not been updated since 7.1 days, but the packages are recent.
Yes, but... there is such a thing as 'aux power'. Among other solutions, you can always create an adapter that plugs your power supply into your PCI card to guard against power blips on reboot. Some of my current Ethernet cards already support 'aux power', which is defined in the PCI bus specification.
And might it not just be simpler to keep this as a seperate device?
Agreed. The additional complexity needed to guard against host powerloss seems needless when you could build a separate device more easily.
But sources close to the deal said Red Hat (Nasdaq: RHAT) Linux will be the Linux distribution that will be pre-loaded on Lawson's servers.
Alas, I work for the competition (Mandrake) so I'm not officially allowed to be ecstatic at the news... this is good news for Linux overall.
Wine Is Not an Emulator... for now. :)
Seriously, Al Viro is the only one standing up and doing VFS work, and informing Linus of his changes. I don't see anyone else actively hacking on the VFS, and then trying to push their changes through to Linus.
I'm a driver hacker not a VFS hacker so I'm not gonna comment on whether the current changes are good or bad. But I will say that Al Viro is the most active at pushing VFS patches straight to Linus. Further, he does post things on linux-fsdevel describing his ideas and designs. It's little wonder his changes go in.
If that situation needs to be changed, someone has got to sit down, code a better solution, and advocate it with Linus. Not just whine on Slashdot.
P.S. I don't want to give the impression that Al Viro is the only one working on VFS. But merely wish to point out that he is the most active at pushing patches to Linus currently.
linuxbios boots into 32-bit protected mode as soon as possible, so that we can write as much code as possible in 32-bit C, compiled with gcc.
No changelog in linux/ of the tarball
I don't understand why you expect to find a ChangeLog in these places, since none has ever existed there before.
You can grab the changes from a Linux Today search. For example, here are the 2.2.15-pre17 changes, which is pretty close to 2.2.15 proper.
And eventually the changes will also be posted by Alan Cox on the Linux.Org.UK home page along with the other 2.2.x release notes.
Jeff
I really think that the concept of having a pentium optimied distro really cheats most of the people in the computer world who either don't own a pentium level x86 machine and or don't own an intel machine.
Linux-Mandrake supports: i486, i586, k6 (unreleased), alpha, ultrasparc, and ppc.
Guys with big portfolios read vision statements.
A few cameras out there plug directly into an ethernet device, and include a mini-webserver so that you can use HTTP to retrieve the image to your central server.