you can do whatever you want with it, as long as you don't remove the copyright notices
Or the usage permissions
This includes relicensing it under the GPL
No, you can't really relicense it unless you are the copyright holder. If you make a new derived work that includes the old code from X plus some new code that is under the GPL. The result would only be distributable under the GPL. There's a clause in the X license:
Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.
That appears to conflict with the GPL's "no additional restrictions" clause, but apparently it doesn't, since the clause has no effect (even without the clause you would not be entitled to use the the name of the X Consortium). Somwhat unclear, that part, and many people prefer not to mix X-license and GPL code (it's also rather impolite towards the person who wrote the X-licensed code).
At least the X license doesn't include the obnoxious BSD licensing clause which is a pain in the backside whether or not you want to mix it with the GPL.
I guess I should forgive you for not having a clue, since the link I posted doesn't work today. Try this link instead. In short, not all of the GNU project is written by GNU, some of it is just included because it is good and it is free. And not all the stuff they collected from other places is GPL, though it is all free.
ebay.com is running Apache/1.3.6 (Unix) on Solaris
Yes, but www.buy.com is NT
buy.com is running Microsoft-IIS/4.0 on NT4 or Windows 98
But www.buy.com is using a proxy ( Inktomi Traffic-Server - telnet to port 80 if you don't believe me) to spread the load over several machines and divert traffic from crahsed hosts.
According to Netcraft this is Solaris based. And of course this (and the database) is the part that really needs to be crashproof.
Because it isn't mainstream. Also because of regulatory issues in the USA, as I understand it.
or not that much more bandwith
It's not so much the bandwidth, as the low latency, fast connects and total reliability
IDE isn't that bad. I certainly don't mind being able to add 17 gigs for less then 250.
But if IDE didn't exist you would be able to add 17 gigs of SCSI for less than 250. There's nothing inherently more expensive about SCSI, it's just that the existence of two incompatible standards has enabled the disk manufacturers to overcharge the high-enders, knowing they don't have the option of going to EIDE because limited cable lengths and the low maximum number of units would make it unusable. And the max cable lengths on EIDE are much shorter than people think. That's apart from all the other issues people have because IDE keeps running out of bits every other year.
An alternative might be to somehow dictate open API, protocols and file formats. That way, people would choose software on the basis of performance, price and stability, rather than on the basis of being locked into compatibility with their own data, other users or certain hardware. Instead of interfering with the mechanisms of free competition, you remove some of the monopolistic forces that are preventing them from working.
Enforcing this sort of thing by law is difficult. In the past some progress has been made by putting requirements in bidding conditions for government sales. This is why almost every OS under the sun has a Posix compatibility layer. Not that the NT layer is much use. You can't use it at the same time as the normal API and if you want to be secure you have to remove it.
We would have been better off if 56k and EIDE had never been invented. Then everyone would have gone to ISDN and SCSI after IDE and normal modems ran out of steam.
When I read how 56k was supposed to work, I thought it the most gross hack imaginable, and it seems it is. Almost everyone has to limit the top speed in order to stop it flaking out, dropping the connection at random moments and generally being a piece of analogue technology pushed far too far.
Apparently one of the best places to put a 56k modem is on the analogue port of an ISDN adapter. That way the analogue signal has the shortest distance to travel.
We won't know for sure until the rest of the documentation (for system programming) is out, but the answer is probably no. Eg. in section 3.1.11 the CPUID instruction is described as unpriviledged with no mention of trapping possibilities.
GRIO not in Linux-XFS. What ext3 offers.
on
UK Linux Conf
·
· Score: 4
XFS is a lot more than "just" a journaling FS. One of it's other major components is guaranteed I/O rate partitions
Yes but they are not giving away the guaranteed I/O rate part of it. At least not according to this link though I can't find any mention of that in the news story or the SGI press release.
Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?
Hell, we've got MS helping us by looking for performance bottlenecks for us and that is already starting to bear fruit (I can't seem to link to that article right. Check out the article "Re:Thank you Microsoft!" by petchema. You will need Alt-F to find it.)
Personally, I think ext3 will rock. This isn't Stephen's first file system by a long chalk.
may have a price current purists will not like but will have to accept (ie less than Open Source code licenses
We can't succeed by destroying ourselves, and I don't think the Linux community will try. If XFS weren't Open Source then it would fail to gain any market share against ext3. But it will be Open Source, so it's a moot point.
No large files support; xfs will fix this. Read the press release.
Actually there is a limitation in the VFS (virtual file system) layer that means right now no FS can have more than 2GB files.
It could well be that SGI have patches to address that, but that would be separate to the XFS code as such.
This restriction only applies to 32 bit platforms such as x86, non-Ultra Sparc and PowerPC of course. On Alpha, Ultrapenguin and Merced there is/will be no such limitation.
They are not porting Irix to IA-32 (x86), which was NT only and is now also Linux, but they intend to have all 3 of them on the IA-64 (Merced).
Makes sense. Apparently one of the main reasons that they don't just port IRIX to IA32 is that they want to take advantage of all sorts of 64 bit stuff in IRIX, and porting to a 32 bit platform now would disturb that.
I wouldn't discount IRIX yet. Let's see how it does on IA64/Merced/McKinley. Could well beat Linux, since gcc is likely to suck on IA64.
companies who all have their hands in Microsoft's pockets
I'm sure there are lots of companies who would like to have their hands in MS's pockets, but I don't think anyone does.
Compaq, HP and Sun are hardly MS minions. This just looks like paranoia to me.
And don't give me that, "you can add it to xfree86" crap:) PC's running Linux or *BSD* aren't the only machines on the planet running X.
Xfree86 doesn't just run on PCs, and it doesn't just run on Linux and *bsd*. It should be possible to port it to anything Berlin can be ported to and probably more.
As far as I can see what this all means is that TOG have admitted they are not the right group to run X, so they have made a new organisation for the purpose. It might work better, it might not, but it seems like a good move. And if it fails, the magic of an Open Source license coupled with the strength of Xfree86 will help us keep going.
AFAIK, Intel binary support is available only in the *Intel* ports of *BSD.
Could be, I am not familiar enough with the BSDs
There is *no* way to run Linux/Intel binaries under *BSD/Alpha
Sorry, I messed up. I wrote that the BSDs have Intel binary support. What I meant was that they have Linux support. Clearly the GEM compilers are Linux/Alpha applications, so, what is needed here is a way to run Linux/Alpha (not Linux/x86) binaries under BSD/Alpha.
The idea itself is not new, but most people thought it would be impossible to apply it to the x86 architecture.
Rubbish. Check out this link which is almost three years old, where Alan says it can be done. This isn't some obscure mailing list, this is the Linux kernel development mailing list, read by thousands (I read it first time around).
Really it's just an extension of what FX!32 does, with x86 as the host, and better support for OS-level stuff. A hell of a lot of work, but no surprise that it's possible.
And you can easily add a non-GNU shell, and voila, you have a running Linux based OS without GNU tools.
Sure you could easily add a non-GNU shell. what compiler would you compile it with? Which C library would you compile it with (hint, all versions of libc for Linux are based on GNU libc). Which termcap would you link to?
You seem to think that Linus wrote the kernel, and then there just happened to be available all the free tools necesary to make a free OS. The reason why all the bits were just there as if by magic was that the GNU project had been adding them, filling in the gaps in the available free software until all there was missing (or rather late) was the kernel.
Do you think the GNU people wrote a C library because it was the most exciting free software project they could think of? I'm sure they would have had more fun writing the LISP-based windowing system they originally planned, but if they had done that we would have had two windowing systems (with X) and no C library. Ie we would not have had Linux distributions.
I can quite understand RMS's frustration that everyone thinks the entirety of the Linux system appeared out of nowhere as soon as Linus wrote the kernel. Probably changing the name isn't the way to raise awareness (gets too many people's backs up, and noone can be bothered with as clumsy a name as GNU/Linux) but I don't know what is.
For those old enough to remember the Yggdrasil distribution (my first) it was labelled Linux/GNU/X. Can't quite remember the order, though I still have the CD somewhere.
And of course what all the above means is that noone would want to call the combination of Tru64 and a lot of free stuff GNU/anything. To suggest otherwise (even as a joke) is to misunderstand totally the motivation behind the GNU/Linux name.
the math libraries will be open but the compiler will be a linux only binary.
Should be possible to get it to work on the BSDs, then. They seem to have Intel executable support, so unless the compiler license specifically forbids it (why should it?) there should be no insurmountable problems.
I was talking more about the code, not really about the name. I was using 'Linux' to mean the stuff you usually get in a Linux distro. I have some sympathy for the GNU/Linux stuff, I'm just too lazy to use the phrase myself.
vim is the most non-standardscompliant piece of crap i've ever seen.
What is it about editors that gets everyone so emotional that they forget how to use the shift key?
Personally, I don't care so much about standards in an interactive app like an editor. It feels like vi, only much better, to an old vi fox like myself.
The version of FX!32 they did for Linux (em86) doesn't include the dynamic recompilation technology, it just has the x86 interpreter. That's why it's so slow.
Of course a version that worked with Wine to run x86/NT programs would be cool, but I rather doubt Compaq would want to release their FX!32 technology. They have worked on it for years, and it looks like they are better at it than anyone else. Intel needs something like this for McKinley (according to rumour it has no hardware support for x86 code), and perhaps even for Merced if the rumours of poor x86 performance are true.
I guess they could just rely on a combination of NIH and the GPL to stop Intel using it.
I've been wondering for a while why the big Unix companies don't do something like this. Ship most of a Linux distribution, but with their own compilers and kernel (and whatever else they feel they are good at). It lets them ship a nicer set of tools and GUI than they do at the moment and at the same time they can concentrate on their strengths.
It would save a lot of trouble for people who get new Unix boxes and have to spend a lot of time upgrading the tools to the stuff Linux has as standard. When you are used to Linux, 1000 little things about the big Unixes will irritate you. Like the useless versions of vi that everyone else ships, the bizzare packaging systems (none of them as good as rpm or dpkg) and the fact that that the up key just produces a set of escape codes on the screen in their shells. If it's so difficult to get right, why don't they just ship vim, rpm and bash?
Here at my University they already use rpm for all the commercial Unixes, and it seems to work fine.
the services that it provides that most people need can be increasingly provided via IP QOS w/ overkill ethernet
Doesn't seem very convincing to me. If people are still trying to solve QOS issues with overkill capacity then that's seems like little more than a cludge.
I should be able to do video-conferencing no problem on 10Mbit/s Ethernet (the bandwidth is there), but if the image breaks down whenever there's a burst of activity from the department file server that's a pretty fragile solution.
Overkill capacity is only overkill until someone builds a faster file server, or until you are unlucky and someone accesses a large cached file from a fast Linux machine, saturating your 'overkill' net.
By the way, I know that people keep trying to build RT systems out of NT. I can't imagine why. I even worked on a project that did that, and it was painful.
Actually some of the most respected benchmarks like SPECcpu95 and TPC are done by the vendors themselves. The trick seems to be firstly to have a strong body overseeing the benchmarks (like SPEC) and secondly that everyone benchmarks only their own stuff and never anyone elses.
Slashdot Mirror
you can do whatever you want with it, as long as you don't remove the copyright notices
Or the usage permissions
This includes relicensing it under the GPL
No, you can't really relicense it unless you are the copyright holder. If you make a new derived work that includes the old code from X plus some new code that is under the GPL. The result would only be distributable under the GPL. There's a clause in the X license:
That appears to conflict with the GPL's "no additional restrictions" clause, but apparently it doesn't, since the clause has no effect (even without the clause you would not be entitled to use the the name of the X Consortium). Somwhat unclear, that part, and many people prefer not to mix X-license and GPL code (it's also rather impolite towards the person who wrote the X-licensed code).At least the X license doesn't include the obnoxious BSD licensing clause which is a pain in the backside whether or not you want to mix it with the GPL.
I guess I should forgive you for not having a clue, since the link I posted doesn't work today. Try this link instead. In short, not all of the GNU project is written by GNU, some of it is just included because it is good and it is free. And not all the stuff they collected from other places is GPL, though it is all free.
Sure it is. The GNU system is a collection of software, some of it written by the GNU project to make a complete free Unix clone. check out the 'it all started here' link through this.
I can run XFree86 on Windows NT
Sure, you can run lots of bits of the GNU system on non-GNU systems, but they are still part of the GNU system.
XFree86 is also part of the NetBSD system, and the RedHat system, of course.
I meant www.ebay.com of course. I even previewed it but missed that.
Yes, but www.buy.com is NT
buy.com is running Microsoft-IIS/4.0 on NT4 or Windows 98
But www.buy.com is using a proxy ( Inktomi Traffic-Server - telnet to port 80 if you don't believe me) to spread the load over several machines and divert traffic from crahsed hosts.
According to Netcraft this is Solaris based. And of course this (and the database) is the part that really needs to be crashproof.
Well, ISDN is still a pretty expensive solution
Because it isn't mainstream. Also because of regulatory issues in the USA, as I understand it.
or not that much more bandwith
It's not so much the bandwidth, as the low latency, fast connects and total reliability
IDE isn't that bad. I certainly don't mind being able to add 17 gigs for less then 250.
But if IDE didn't exist you would be able to add 17 gigs of SCSI for less than 250. There's nothing inherently more expensive about SCSI, it's just that the existence of two incompatible standards has enabled the disk manufacturers to overcharge the high-enders, knowing they don't have the option of going to EIDE because limited cable lengths and the low maximum number of units would make it unusable. And the max cable lengths on EIDE are much shorter than people think. That's apart from all the other issues people have because IDE keeps running out of bits every other year.
Enforcing this sort of thing by law is difficult. In the past some progress has been made by putting requirements in bidding conditions for government sales. This is why almost every OS under the sun has a Posix compatibility layer. Not that the NT layer is much use. You can't use it at the same time as the normal API and if you want to be secure you have to remove it.
(Btw. this seminar, which I saw on the Heise newsticker has a few other pearls, like the fact that most firewalls can't tell the difference between a virus and a Windows NT service pack. Nor can I :-)
When I read how 56k was supposed to work, I thought it the most gross hack imaginable, and it seems it is. Almost everyone has to limit the top speed in order to stop it flaking out, dropping the connection at random moments and generally being a piece of analogue technology pushed far too far.
Apparently one of the best places to put a 56k modem is on the analogue port of an ISDN adapter. That way the analogue signal has the shortest distance to travel.
We won't know for sure until the rest of the documentation (for system programming) is out, but the answer is probably no. Eg. in section 3.1.11 the CPUID instruction is described as unpriviledged with no mention of trapping possibilities.
Yes but they are not giving away the guaranteed I/O rate part of it. At least not according to this link though I can't find any mention of that in the news story or the SGI press release.
I haven't seen what EXT3 promises,
It will add journalling (see the white paper Stephen wrote), and probably extent based block lists and btrees by Ted Ts'o will be in there too.
Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it.
SGI are employing kernel hackers and you can start to see some of the stuff they are getting up to
Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?
Hell, we've got MS helping us by looking for performance bottlenecks for us and that is already starting to bear fruit (I can't seem to link to that article right. Check out the article "Re:Thank you Microsoft!" by petchema. You will need Alt-F to find it.)
Personally, I think ext3 will rock. This isn't Stephen's first file system by a long chalk.
may have a price current purists will not like but will have to accept (ie less than Open Source code licenses
We can't succeed by destroying ourselves, and I don't think the Linux community will try. If XFS weren't Open Source then it would fail to gain any market share against ext3. But it will be Open Source, so it's a moot point.
Doesn't sound too good. Are you developing driver software?
Now that we have the most stable OS in the world
Do we? How do you know?
Actually there is a limitation in the VFS (virtual file system) layer that means right now no FS can have more than 2GB files.
It could well be that SGI have patches to address that, but that would be separate to the XFS code as such.
This restriction only applies to 32 bit platforms such as x86, non-Ultra Sparc and PowerPC of course. On Alpha, Ultrapenguin and Merced there is/will be no such limitation.
Rather depends on the License. I don't believe the BSD folks allow GPL software into their kernel.
Makes sense. Apparently one of the main reasons that they don't just port IRIX to IA32 is that they want to take advantage of all sorts of 64 bit stuff in IRIX, and porting to a 32 bit platform now would disturb that.
I wouldn't discount IRIX yet. Let's see how it does on IA64/Merced/McKinley. Could well beat Linux, since gcc is likely to suck on IA64.
I'm sure there are lots of companies who would like to have their hands in MS's pockets, but I don't think anyone does.
Compaq, HP and Sun are hardly MS minions. This just looks like paranoia to me.
And don't give me that, "you can add it to xfree86" crap :) PC's running Linux or *BSD* aren't the only machines on the planet running X.
Xfree86 doesn't just run on PCs, and it doesn't just run on Linux and *bsd*. It should be possible to port it to anything Berlin can be ported to and probably more.
As far as I can see what this all means is that TOG have admitted they are not the right group to run X, so they have made a new organisation for the purpose. It might work better, it might not, but it seems like a good move. And if it fails, the magic of an Open Source license coupled with the strength of Xfree86 will help us keep going.
Could be, I am not familiar enough with the BSDs
There is *no* way to run Linux/Intel binaries under *BSD/Alpha
Sorry, I messed up. I wrote that the BSDs have Intel binary support. What I meant was that they have Linux support. Clearly the GEM compilers are Linux/Alpha applications, so, what is needed here is a way to run Linux/Alpha (not Linux/x86) binaries under BSD/Alpha.
Rubbish. Check out this link which is almost three years old, where Alan says it can be done. This isn't some obscure mailing list, this is the Linux kernel development mailing list, read by thousands (I read it first time around).
Really it's just an extension of what FX!32 does, with x86 as the host, and better support for OS-level stuff. A hell of a lot of work, but no surprise that it's possible.
Sure you could easily add a non-GNU shell. what compiler would you compile it with? Which C library would you compile it with (hint, all versions of libc for Linux are based on GNU libc). Which termcap would you link to?
You seem to think that Linus wrote the kernel, and then there just happened to be available all the free tools necesary to make a free OS. The reason why all the bits were just there as if by magic was that the GNU project had been adding them, filling in the gaps in the available free software until all there was missing (or rather late) was the kernel.
Do you think the GNU people wrote a C library because it was the most exciting free software project they could think of? I'm sure they would have had more fun writing the LISP-based windowing system they originally planned, but if they had done that we would have had two windowing systems (with X) and no C library. Ie we would not have had Linux distributions.
I can quite understand RMS's frustration that everyone thinks the entirety of the Linux system appeared out of nowhere as soon as Linus wrote the kernel. Probably changing the name isn't the way to raise awareness (gets too many people's backs up, and noone can be bothered with as clumsy a name as GNU/Linux) but I don't know what is.
For those old enough to remember the Yggdrasil distribution (my first) it was labelled Linux/GNU/X. Can't quite remember the order, though I still have the CD somewhere.
And of course what all the above means is that noone would want to call the combination of Tru64 and a lot of free stuff GNU/anything. To suggest otherwise (even as a joke) is to misunderstand totally the motivation behind the GNU/Linux name.
Should be possible to get it to work on the BSDs, then. They seem to have Intel executable support, so unless the compiler license specifically forbids it (why should it?) there should be no insurmountable problems.
Not wanting to ruin RMS's decade, or anything
What is it about editors that gets everyone so emotional that they forget how to use the shift key?
Personally, I don't care so much about standards in an interactive app like an editor. It feels like vi, only much better, to an old vi fox like myself.
According to this Deja News article em86 is no longer supported. This seems a pity.
Of course a version that worked with Wine to run x86/NT programs would be cool, but I rather doubt Compaq would want to release their FX!32 technology. They have worked on it for years, and it looks like they are better at it than anyone else. Intel needs something like this for McKinley (according to rumour it has no hardware support for x86 code), and perhaps even for Merced if the rumours of poor x86 performance are true.
I guess they could just rely on a combination of NIH and the GPL to stop Intel using it.
It would save a lot of trouble for people who get new Unix boxes and have to spend a lot of time upgrading the tools to the stuff Linux has as standard. When you are used to Linux, 1000 little things about the big Unixes will irritate you. Like the useless versions of vi that everyone else ships, the bizzare packaging systems (none of them as good as rpm or dpkg) and the fact that that the up key just produces a set of escape codes on the screen in their shells. If it's so difficult to get right, why don't they just ship vim, rpm and bash?
Here at my University they already use rpm for all the commercial Unixes, and it seems to work fine.
Doesn't seem very convincing to me. If people are still trying to solve QOS issues with overkill capacity then that's seems like little more than a cludge.
I should be able to do video-conferencing no problem on 10Mbit/s Ethernet (the bandwidth is there), but if the image breaks down whenever there's a burst of activity from the department file server that's a pretty fragile solution.
Overkill capacity is only overkill until someone builds a faster file server, or until you are unlucky and someone accesses a large cached file from a fast Linux machine, saturating your 'overkill' net.
Sounds to me like the difference between a real RTOS and a timesharing system. Try asking a developer who uses QNX and a 68k for a real-time app whether they would like to switch to Windows NT and an Alpha 21264-500 with overkill processing power. All the processing power/bandwidth isn't going to help you if one app decides to monoplise it.
By the way, I know that people keep trying to build RT systems out of NT. I can't imagine why. I even worked on a project that did that, and it was painful.
Of course, you also need realistic benchmarks.