What sort of performance metrics do you have to show that shared interrupts are the source of your problem? My current laptop has damn near everything on interrupt 9 (as have most machines I've seen lately), and I've not noticed any performance problems at all. Smooth mouse, smooth video, DVDs play just fine without dropping frames, transfers over fast ethernet at >8M/s etc.
Most video capture problems are caused by disk latency or hitting a page fault at the wrong time, not interrupt latency. The average interrupt latency on most systems in somewhere under 1ms - if you are capturing at more than that rate then I suggest you need dedicated hardware. What model SCSI controller are you using? In many cases IDE is actually better value than SCSI - you can capture easily to an IDE drive at ATA/33 or better.
If you really want to know the largest cause of bottlenecks then I suggest you look at register spilling on the CPU. The x86 is horribly register starved and therefore hits the cache a LOT. If that's not where you want to look, check out things like the actual transfer rate to your drives, where the CPU time is going (system or user space), how loaded your I/O busses are, what bandwidth you have between North and South bridges etc. Shared interrupts really haven't been a problem for a long time, especially on "proper" operating systems like Linux.
If you don't know much about hardware then you probably won't want the "bleeding edge" technology. Stick with PC133, even though the RAM is the same price, the mobos that support it are more expensive.
ASUS is a good brand. I've had a number of them and they've always been rock solid with heaps of good features. They aren't the cheapest, but IMHO they are worth it.
Where do people get this idea you need "billions in the bank" to get a response from MS? For my part (and I assure you I don't have billions in the bank), I've had timely responses from Microsoft on a number of developer issues including a few bugs I've found in the OS here and there.
Of course, who am I to dispel people's beliefs that MS is an evil company and never listens to developers...
Agreed. What this will do for benchmarks like STREAM is cut the memory latency by a huge amount. The chipset prefetch will have the right data sitting in its high-speed cache to return to the CPU on the next bus cycle, rather than having to wait the 4 or 5 bus cycles for the memory access to go through. Once it has figured the pattern, it will be prefetching far enough ahead (with it's higher bandwidth) that the right data should always be in the "L3" cache ready for the CPU at the next bus cycle.
Honestly, I'd believe the 20% performance improvement. Sounds about right for removing memory latency from non-random access. Gotta keep those three pipes in the Athlon filled!!
The number of IRQs really isn't going to affect your performance. Remember most CPUs (x86 included) actually have only a single interrupt line going into them and they then handshake with an APIC to figure out what interrupt actually happened.
If you are worried about interrupt chaining, then there still isn't much time lag there. Handling an interrupt is usually a matter of just determining if your device caused the interrupt, saving the state of the device and firing off a backgroud operation to actually deal with the data. The only delay is running down the drivers chained off the interrupt to find the one that actually caused it - usually a matter of each one simply checking a single PCI register (ie 20 clocks).
Face it, the 'shared IRQ' is simply a non-issue any more (unless you have shitty drivers written by someone who learned to code in GW-BASIC and never read a design manual). Most RISC machines work happily with very few lines and the "16 Interrupts" idea is what is supported by the APIC and not the CPU anyhow, so get over it.
The reason they are using a GF2 and not a GF3 is simple really - if you want a GF3 then you have to buy it from nVidia and they get to make more money. If you don't want a GF3 then they've sold you a GF2 already which will keep you from spending money at their competitor.
Remember the GF3 driver is likely to be included in the unified driver they are going to be shipping, but if you go with the competitor then you have to worry about driver issues. Looks like nVidia is set to become the Microsoft of the chipset/hardware industry!
It's simple really. The chipset has a much higher bandwidth to the memory than the CPU does so it can interleave the memory fetches with normal data access. If the CPU is also using a prefetch then the chipset has a lot better chance of figuring out what the pattern is and fetching the correct data.
Remember that the CPU is running at 1066M/s to the chipset but the chipset has 4200M/s to RAM.
Re:Wanna build a bomb? Look at the FAQ!!
on
Duct Tape
·
· Score: 2
I wonder whose reach I come under then as a legal alien? Probably the FBI/DOE until I leave the country. Maybe I'm ok because they'd have to (heaven forbid) cooperate with each other.
Wanna build a bomb? Look at the FAQ!!
on
Duct Tape
·
· Score: 2
It's actually harder than it looks to build a nuclear device. You can get some fairly detailed instructions (short of the actual neutron flow mathematics) from the Nuclear Weapons FAQ (http://www.scifig.com/milnet/nukeweap/Nfaq0.html) .
The DoD conducted a trial in 1967 by getting 3 physics grads to design a device. They succeeded in less than a year!! Now, with the internet, a 15 year old can probably design one themselves.
Basically, as mentioned before, the easy bit is finding the raw materials and refining them to weapons grade munitions. The difficult bits (in what I see as order of difficulty) are:
i) Shaping the charge exactly right to form a perfectly spherical shock wave around the fissile material.
ii) Shaping the material properly to implode spherically.
iii) Doing all this in such a manner as not to arouse suspicion - you need some fairly specialised tools to accomplish it - a pocket knife and a home lathe probably aren't enough.
As soon as you order the materials in a non-secure manner, the CIA are probably going to have your number on a 'watch' list. If it comes up a couple of times then expect a visit at some stage. Hell - I'm probably flagged from mentioning all this in a public forum.
Any argument of forking is going to end up with Microsoft coming out above Unix whichever way you go, especially now they are retiring the Win9x line and going with the single NT kernel for everything.
Actually, have you every used MSDN? The documentation there is a hell of a lot better than you'll find for any version of Linux - even with the source code provided on Linux.
I've yet to find any vendor that provides as good developer documentation as Microsoft does. Access to the source code does NOT mean you have the best possible documentation. There is a massive difference.
Granted, some raw protocols or file formats are not disclosed, but guess what? If you are developing for a Microsoft system you don't need them. If you want to access a Word file you just use the COM interfaces provided by Word itself. If you want to talk SMB then you use the whole swag of WNet APIs. Comparing the source code to proper documentation is stupid - a properly documented interface would win every time.
You can either argue that neither Linux or Windows has forked, or you can argue that both have forked. I personally see a fork as something where two separate codebases exist and no syncronization is done between them. This is not the case in any of the Windows or Linux lines.
Win95, Win98, WinNT, Win2000, WinXP are forks? I don't think so. This is pretty much the same as saying:
FreeBSD 3.0, FreeBSD 4.0, Linux 2.0, Linux 2.2 and Linux 2.4 are forks. If you are going to respond to him then you could at least get YOUR facts straight!!
Win9x has never been a fork on the NT project. While the FreeBSD analogy above is a little out, Win9x is really a version of Win3.0 with a whole stack of 32 bit junk tacked in wherever possible. You'd be much closer calling Warp and NT forks of each other, or even OpenVMS and NT forks. Hell, even Linux+Wine is probably closer to NT/2000/XP than Win9x is!!!
In Australia, the ACCC (the equivalent of the FTC in the USA) has taken issue with the region coding as an unfair restriction of trade. My guess is that it is highly likely they will win (going by the fact they are fairly conservative and rarely take a case to court that they stand a chance of losing) and hence result in:
i) Region free players being available in Australia, and
ii) Making it illegal for a movie studio to restrict any non-region 4 DVD from being played in Australia if it can be legally imported.
or, the removal of DVDs from the Australian market (not likely).
Of course, this pretty much smashes the whole idea of region coding which requires every country in the world to participate or it won't work for anyone.
In fact, it is actually the region coding that is the primary weapon against the copyright infringement as it prevents the bitwise copies from being made and exported from SE Asia (which has a region all to itself).
That sounds all very patriotic and all, but if you want to draw historical parallels I think you would be much better looking towards the student's revolution in France (which the book and musical Les Miserables was based on).
The students rose up against the unfairness of the laws and oppression of the ruling class at the time, but unfortunately for them they failed to gather the support of the common people before they rose.
I'm not suggesting that this is how the Linux "Revolution" will end, but it is certainly a warning that if you do not study history then you are doomed to repeat it.
The American Revolution (as with most wars) was more about economics and trade restrictions than it was about personal freedoms. Sheesh, soon they'll have you believing that the Americal Civil War was actually about slavery and not the economic differences between the North and South... oh, yeah - you probably do believe that.
How many would still live if the project lead lost interest, decided to work on something else, or had no time for the project any more.
My guess is not many.
This is exactly the question people face with XFS (though to a lesser extent because it has probably reached a critical mass) - if SGI doesn't support development any more, who will? Will it just stagnate now, remain at v1.0 forever and never make the kernel proper?
Once the dev kernel gets forked off, the kernel releases become much more like service packs. I know if you are running anything less than 2.2.16, most people will suggest you upgrade.
In the early numbers however, it is probably worthwhile upgrading now and again to get rid of those bugs that surface up in the major version change.
It would be even nicer if you could vary any or all of the following independantly and get the results:
i) Packet loss
ii) Ping as reported by the client (while holding the actual packet delay constant)
iii) Actual packet delay (while holding the ping reported by the client constant)
The second and third options may not be possible - it involves delaying specific packets and not others.
Also, to get a good feel you should also be measuring the performance of the players (ie does a low ping actually correlate with the number of frags), and by selectively delaying certain players you should be able to remove the skew given by the fact that better players will be willing to pay for a better connection.
Further studies could involve examining correlation between the length of time people spend on your server compared to their ping and packet loss (again selectively varied to avoid the skew mentioned above).
Many of these studies would have to be very carefully done to avoid any external factors. For example, showing that better players have low ping times doesn't mean that a low ping helps you play - it may just mean that the better players have DSL because they spend a lot of time on the net, while casual players are more likely to have a modem.
Getting accurate stats and results is a difficult subject - far more difficult than presented in the original report, which does nothing more than profile the internet connections of the players on his Quake server.
I don't follow how he got the measure of 150ms as what people prefer. What the data really shows is that most people who connected to his quake server had a ping time of under 150ms (which actually covers most of the US from the plots he drew).
Let's think about this a little more:
i) He's on a T1 and possibly advertises the fact.
ii) Serious MP Quake players will have a fast connection (DSL/Cable) and not a modem.
iii) Quake players will *choose* the lowest ping because it seems like a good idea - they won't reject a server over 150ms, just prefer one below it.
Looking at the results, the best he can say is that most people that play on his server are from the US, which for the most part keeps their ping under 150ms. You can't draw any assumptions about what people "prefer" from that data.
Reading the GPL and taking into account the context of it being written in 1984, it seems that RMS was wanting to allow "standalone" component software which was GPL'd to be called from a non-GPL program (by the example given in the license of piping and capturing stdout).
From this you could make a pretty convincing legal argument that a COM/KOM/CORBA/Whatever component is separate from it's calling program for the purposes of the GPL. As a quick example, many non-free tools may break if sed and awk are not available on the system because they use them as components in their processing line - note that they are not optional but necessary for the nonfree program to run.
In a similar way if I pipe the output of an MP3 from my proprietary program through a command line mp3dec to get the audio stream out the other end then I am not breaking the GPL. The mp3dec program is just a component in my system.
Now if I use different middleware (COM) instead of pipes then I'm doing effectively the same thing - separate processes, no break of GPL.
Of course the real question now is where do you draw the line. If COM decided to load the component in the same process as my proprietary application then my INTENT is exactly the same: I'm simply using the features of the program in the same way a dev tool uses sed and awk. The technicalities are different, but I'd be surprised to see it being different in a legal sense - in both cases one set of code is simply using (and critically depends on) features of another set of code. The free code could be replaced by non-free code if required with NO modification to the original (not even a recompile) and so it would be hard to assert the proprietary code being a derivative work.
What does this mean? Ultimately it could mean that linking through middleware is ok, hence linking via COM is ok, hence running in the same process is ok, which effectively reduces the GPL to the LGPL.
THAT is scary. As many people have pointed out, what really matters is the INTENT and not the technical details. This may indeed be the downfall of the GPL!
[Of course IANAL and in the end, I am often prone to attacks of stupidity so slap me down if I need it]
Did a full install on my Mac G3. Ran just great. Motion is smooth, haven't run across any bugs yet, sound is beautiful and movies are crystal clear.
In fact, I think Michael's machine may be slightly screwy - I tried renaming my Exile CD to 'J:' and it told me it was read only and I couldn't do that. Perhaps he should reinstall OS 9?;-)
God help us all if this is the case. If RMS believes that separating the processes is enough then in the Win32 world of COM/DCOM things become very complex.
I could start with a simple COM DLL that I place under the GPL (not the LGPL). Now four different proprietary programs invoke this DLL:
i) A program that loads the DLL inproc (Using CLS_INPROC_SERVER).
ii) A program that loads the DLL outproc (Using CLS_LOCAL_SERVER), forcing it to be run in a different process but loaded by rundll32.exe (or possibly svchost.exe)
iii) A program that loads the DLL on a remote machine directly through DCOM.
iv) A program that loads the DLL on a remote machine indirectly through MTS and COM+ (hence the Microsoft middleware is actually loading and executing the methods of my DLL).
In the four cases, (i) above is a violation according to the "same memory space" theory, but all four processes don't actually know or care (thanks to the magic of COM) where the DLL is being run and if it is inproc or not.
Hell!!
Assume for the sake of argument that my DLL has a very application specific interface that would not be easily rewritten without access to the original work in the first place.
As far as I can see in this scenario, the GPL is not specific enough to say what the licensing issues are and how they apply. I don't think RMS took into account the complexities of component software when drafting GPL 2.0, and I'm beginning to think GPL 3.0 is going to be such a monstrosity it will be years before anyone understands it fully.
I'm pretty sure your argument about memory spaces is false. If this were the case, the simple conversion from GPL to LGPL would be to write a GPL'd front end which takes parameters on stdin and sends the results to stdout.
I believe you are thinking too technically about the law. The real test is the intent (I think - IANAL).
I believe the case will be very interesting because if Vidomi actually win then there is a significant hole in the GPL which effectively reduces it to LGPL. That would cause hellish problems with "Free Software" everywhere.
Most countries in the world (including the US) have some form of VAT - either at a state level (ie the US) or at a federal level. Taking a wide survey will find that a country's economy dies after GST only if a recession hits at the same time, or other external factors come into play.
Bankruptcy being up 36% this year is a pretty common figure all over the world. Perhaps you haven't noticed the layoffs in San Jose and hiring freezes in just about every US company?
The biggest reason the Australian dollar has dropped (and the bankruptcies) is not the GST but the mismanagement of the economy by the Reserve Bank. Interest rates never should have been pushed as high as they were and now people are going broke as they can't afford to repay the loans. The effect of GST compared to this was negligible.
Howard should indeed be running scared though - Labor is gonna put up one hell of a FUD campaign (as usual) and probably win with no real future vision or policies (again).
Red Hat likely to turn a profit?
on
Mundie Responds
·
· Score: 1
If you read the RH filings with the SEC, Red Hat themselves don't know when or even *IF* they are going to turn a profit. I don't understand how you can assert it is likely they will if they don't believe they will themselves.
From their 10k filing:
"We expect to incur substantial losses on a GAAP basis for the foreseeable future."
"We have incurred operating losses in six of our previous seven fiscal years, including our most recent fiscal year ended February 28, 2001. We expect to incur significant losses for the foreseeable future, as we substantially increase our sales and marketing, research and development and administrative expenses. In addition, we are investing considerable resources in our Red Hat Network initiative and to expand our professional services offerings. As a result, we cannot be certain when or if we will achieve sustained profitability. Failure to become and remain profitable may adversely affect the market price of our common stock and our ability to raise capital and continue operations."
My take on this is that it is rather unrealistic to expect Red Hat to return a profit to its shareholders in the next five years, perhaps if ever!
Slashdot Mirror
What sort of performance metrics do you have to show that shared interrupts are the source of your problem? My current laptop has damn near everything on interrupt 9 (as have most machines I've seen lately), and I've not noticed any performance problems at all. Smooth mouse, smooth video, DVDs play just fine without dropping frames, transfers over fast ethernet at >8M/s etc.
Most video capture problems are caused by disk latency or hitting a page fault at the wrong time, not interrupt latency. The average interrupt latency on most systems in somewhere under 1ms - if you are capturing at more than that rate then I suggest you need dedicated hardware. What model SCSI controller are you using? In many cases IDE is actually better value than SCSI - you can capture easily to an IDE drive at ATA/33 or better.
If you really want to know the largest cause of bottlenecks then I suggest you look at register spilling on the CPU. The x86 is horribly register starved and therefore hits the cache a LOT. If that's not where you want to look, check out things like the actual transfer rate to your drives, where the CPU time is going (system or user space), how loaded your I/O busses are, what bandwidth you have between North and South bridges etc. Shared interrupts really haven't been a problem for a long time, especially on "proper" operating systems like Linux.
If you don't know much about hardware then you probably won't want the "bleeding edge" technology. Stick with PC133, even though the RAM is the same price, the mobos that support it are more expensive.
ASUS is a good brand. I've had a number of them and they've always been rock solid with heaps of good features. They aren't the cheapest, but IMHO they are worth it.
Where do people get this idea you need "billions in the bank" to get a response from MS? For my part (and I assure you I don't have billions in the bank), I've had timely responses from Microsoft on a number of developer issues including a few bugs I've found in the OS here and there.
Of course, who am I to dispel people's beliefs that MS is an evil company and never listens to developers...
Agreed. What this will do for benchmarks like STREAM is cut the memory latency by a huge amount. The chipset prefetch will have the right data sitting in its high-speed cache to return to the CPU on the next bus cycle, rather than having to wait the 4 or 5 bus cycles for the memory access to go through. Once it has figured the pattern, it will be prefetching far enough ahead (with it's higher bandwidth) that the right data should always be in the "L3" cache ready for the CPU at the next bus cycle.
Honestly, I'd believe the 20% performance improvement. Sounds about right for removing memory latency from non-random access. Gotta keep those three pipes in the Athlon filled!!
The number of IRQs really isn't going to affect your performance. Remember most CPUs (x86 included) actually have only a single interrupt line going into them and they then handshake with an APIC to figure out what interrupt actually happened.
If you are worried about interrupt chaining, then there still isn't much time lag there. Handling an interrupt is usually a matter of just determining if your device caused the interrupt, saving the state of the device and firing off a backgroud operation to actually deal with the data. The only delay is running down the drivers chained off the interrupt to find the one that actually caused it - usually a matter of each one simply checking a single PCI register (ie 20 clocks).
Face it, the 'shared IRQ' is simply a non-issue any more (unless you have shitty drivers written by someone who learned to code in GW-BASIC and never read a design manual). Most RISC machines work happily with very few lines and the "16 Interrupts" idea is what is supported by the APIC and not the CPU anyhow, so get over it.
The reason they are using a GF2 and not a GF3 is simple really - if you want a GF3 then you have to buy it from nVidia and they get to make more money. If you don't want a GF3 then they've sold you a GF2 already which will keep you from spending money at their competitor.
Remember the GF3 driver is likely to be included in the unified driver they are going to be shipping, but if you go with the competitor then you have to worry about driver issues. Looks like nVidia is set to become the Microsoft of the chipset/hardware industry!
It's simple really. The chipset has a much higher bandwidth to the memory than the CPU does so it can interleave the memory fetches with normal data access. If the CPU is also using a prefetch then the chipset has a lot better chance of figuring out what the pattern is and fetching the correct data.
Remember that the CPU is running at 1066M/s to the chipset but the chipset has 4200M/s to RAM.
I wonder whose reach I come under then as a legal alien? Probably the FBI/DOE until I leave the country. Maybe I'm ok because they'd have to (heaven forbid) cooperate with each other.
It's actually harder than it looks to build a nuclear device. You can get some fairly detailed instructions (short of the actual neutron flow mathematics) from the Nuclear Weapons FAQ (http://www.scifig.com/milnet/nukeweap/Nfaq0.html) .
The DoD conducted a trial in 1967 by getting 3 physics grads to design a device. They succeeded in less than a year!! Now, with the internet, a 15 year old can probably design one themselves.
Basically, as mentioned before, the easy bit is finding the raw materials and refining them to weapons grade munitions. The difficult bits (in what I see as order of difficulty) are:
i) Shaping the charge exactly right to form a perfectly spherical shock wave around the fissile material.
ii) Shaping the material properly to implode spherically.
iii) Doing all this in such a manner as not to arouse suspicion - you need some fairly specialised tools to accomplish it - a pocket knife and a home lathe probably aren't enough.
As soon as you order the materials in a non-secure manner, the CIA are probably going to have your number on a 'watch' list. If it comes up a couple of times then expect a visit at some stage. Hell - I'm probably flagged from mentioning all this in a public forum.
Umm... and Unix doesn't?
Any argument of forking is going to end up with Microsoft coming out above Unix whichever way you go, especially now they are retiring the Win9x line and going with the single NT kernel for everything.
Actually, have you every used MSDN? The documentation there is a hell of a lot better than you'll find for any version of Linux - even with the source code provided on Linux.
I've yet to find any vendor that provides as good developer documentation as Microsoft does. Access to the source code does NOT mean you have the best possible documentation. There is a massive difference.
Granted, some raw protocols or file formats are not disclosed, but guess what? If you are developing for a Microsoft system you don't need them. If you want to access a Word file you just use the COM interfaces provided by Word itself. If you want to talk SMB then you use the whole swag of WNet APIs. Comparing the source code to proper documentation is stupid - a properly documented interface would win every time.
You can either argue that neither Linux or Windows has forked, or you can argue that both have forked. I personally see a fork as something where two separate codebases exist and no syncronization is done between them. This is not the case in any of the Windows or Linux lines.
Win95, Win98, WinNT, Win2000, WinXP are forks? I don't think so. This is pretty much the same as saying:
FreeBSD 3.0, FreeBSD 4.0, Linux 2.0, Linux 2.2 and Linux 2.4 are forks. If you are going to respond to him then you could at least get YOUR facts straight!!
Win9x has never been a fork on the NT project. While the FreeBSD analogy above is a little out, Win9x is really a version of Win3.0 with a whole stack of 32 bit junk tacked in wherever possible. You'd be much closer calling Warp and NT forks of each other, or even OpenVMS and NT forks. Hell, even Linux+Wine is probably closer to NT/2000/XP than Win9x is!!!
In Australia, the ACCC (the equivalent of the FTC in the USA) has taken issue with the region coding as an unfair restriction of trade. My guess is that it is highly likely they will win (going by the fact they are fairly conservative and rarely take a case to court that they stand a chance of losing) and hence result in:
i) Region free players being available in Australia, and
ii) Making it illegal for a movie studio to restrict any non-region 4 DVD from being played in Australia if it can be legally imported.
or, the removal of DVDs from the Australian market (not likely).
Of course, this pretty much smashes the whole idea of region coding which requires every country in the world to participate or it won't work for anyone.
In fact, it is actually the region coding that is the primary weapon against the copyright infringement as it prevents the bitwise copies from being made and exported from SE Asia (which has a region all to itself).
That sounds all very patriotic and all, but if you want to draw historical parallels I think you would be much better looking towards the student's revolution in France (which the book and musical Les Miserables was based on).
The students rose up against the unfairness of the laws and oppression of the ruling class at the time, but unfortunately for them they failed to gather the support of the common people before they rose.
I'm not suggesting that this is how the Linux "Revolution" will end, but it is certainly a warning that if you do not study history then you are doomed to repeat it.
The American Revolution (as with most wars) was more about economics and trade restrictions than it was about personal freedoms. Sheesh, soon they'll have you believing that the Americal Civil War was actually about slavery and not the economic differences between the North and South... oh, yeah - you probably do believe that.
You forgot the more vital question:
How many would still live if the project lead lost interest, decided to work on something else, or had no time for the project any more.
My guess is not many.
This is exactly the question people face with XFS (though to a lesser extent because it has probably reached a critical mass) - if SGI doesn't support development any more, who will? Will it just stagnate now, remain at v1.0 forever and never make the kernel proper?
Once the dev kernel gets forked off, the kernel releases become much more like service packs. I know if you are running anything less than 2.2.16, most people will suggest you upgrade.
In the early numbers however, it is probably worthwhile upgrading now and again to get rid of those bugs that surface up in the major version change.
It would be even nicer if you could vary any or all of the following independantly and get the results:
i) Packet loss
ii) Ping as reported by the client (while holding the actual packet delay constant)
iii) Actual packet delay (while holding the ping reported by the client constant)
The second and third options may not be possible - it involves delaying specific packets and not others.
Also, to get a good feel you should also be measuring the performance of the players (ie does a low ping actually correlate with the number of frags), and by selectively delaying certain players you should be able to remove the skew given by the fact that better players will be willing to pay for a better connection.
Further studies could involve examining correlation between the length of time people spend on your server compared to their ping and packet loss (again selectively varied to avoid the skew mentioned above).
Many of these studies would have to be very carefully done to avoid any external factors. For example, showing that better players have low ping times doesn't mean that a low ping helps you play - it may just mean that the better players have DSL because they spend a lot of time on the net, while casual players are more likely to have a modem.
Getting accurate stats and results is a difficult subject - far more difficult than presented in the original report, which does nothing more than profile the internet connections of the players on his Quake server.
I don't follow how he got the measure of 150ms as what people prefer. What the data really shows is that most people who connected to his quake server had a ping time of under 150ms (which actually covers most of the US from the plots he drew).
Let's think about this a little more:
i) He's on a T1 and possibly advertises the fact.
ii) Serious MP Quake players will have a fast connection (DSL/Cable) and not a modem.
iii) Quake players will *choose* the lowest ping because it seems like a good idea - they won't reject a server over 150ms, just prefer one below it.
Looking at the results, the best he can say is that most people that play on his server are from the US, which for the most part keeps their ping under 150ms. You can't draw any assumptions about what people "prefer" from that data.
Reading the GPL and taking into account the context of it being written in 1984, it seems that RMS was wanting to allow "standalone" component software which was GPL'd to be called from a non-GPL program (by the example given in the license of piping and capturing stdout).
From this you could make a pretty convincing legal argument that a COM/KOM/CORBA/Whatever component is separate from it's calling program for the purposes of the GPL. As a quick example, many non-free tools may break if sed and awk are not available on the system because they use them as components in their processing line - note that they are not optional but necessary for the nonfree program to run.
In a similar way if I pipe the output of an MP3 from my proprietary program through a command line mp3dec to get the audio stream out the other end then I am not breaking the GPL. The mp3dec program is just a component in my system.
Now if I use different middleware (COM) instead of pipes then I'm doing effectively the same thing - separate processes, no break of GPL.
Of course the real question now is where do you draw the line. If COM decided to load the component in the same process as my proprietary application then my INTENT is exactly the same: I'm simply using the features of the program in the same way a dev tool uses sed and awk. The technicalities are different, but I'd be surprised to see it being different in a legal sense - in both cases one set of code is simply using (and critically depends on) features of another set of code. The free code could be replaced by non-free code if required with NO modification to the original (not even a recompile) and so it would be hard to assert the proprietary code being a derivative work.
What does this mean? Ultimately it could mean that linking through middleware is ok, hence linking via COM is ok, hence running in the same process is ok, which effectively reduces the GPL to the LGPL.
THAT is scary. As many people have pointed out, what really matters is the INTENT and not the technical details. This may indeed be the downfall of the GPL!
[Of course IANAL and in the end, I am often prone to attacks of stupidity so slap me down if I need it]
Did a full install on my Mac G3. Ran just great. Motion is smooth, haven't run across any bugs yet, sound is beautiful and movies are crystal clear.
;-)
In fact, I think Michael's machine may be slightly screwy - I tried renaming my Exile CD to 'J:' and it told me it was read only and I couldn't do that. Perhaps he should reinstall OS 9?
God help us all if this is the case. If RMS believes that separating the processes is enough then in the Win32 world of COM/DCOM things become very complex.
I could start with a simple COM DLL that I place under the GPL (not the LGPL). Now four different proprietary programs invoke this DLL:
i) A program that loads the DLL inproc (Using CLS_INPROC_SERVER).
ii) A program that loads the DLL outproc (Using CLS_LOCAL_SERVER), forcing it to be run in a different process but loaded by rundll32.exe (or possibly svchost.exe)
iii) A program that loads the DLL on a remote machine directly through DCOM.
iv) A program that loads the DLL on a remote machine indirectly through MTS and COM+ (hence the Microsoft middleware is actually loading and executing the methods of my DLL).
In the four cases, (i) above is a violation according to the "same memory space" theory, but all four processes don't actually know or care (thanks to the magic of COM) where the DLL is being run and if it is inproc or not.
Hell!!
Assume for the sake of argument that my DLL has a very application specific interface that would not be easily rewritten without access to the original work in the first place.
As far as I can see in this scenario, the GPL is not specific enough to say what the licensing issues are and how they apply. I don't think RMS took into account the complexities of component software when drafting GPL 2.0, and I'm beginning to think GPL 3.0 is going to be such a monstrosity it will be years before anyone understands it fully.
I'm pretty sure your argument about memory spaces is false. If this were the case, the simple conversion from GPL to LGPL would be to write a GPL'd front end which takes parameters on stdin and sends the results to stdout.
I believe you are thinking too technically about the law. The real test is the intent (I think - IANAL).
I believe the case will be very interesting because if Vidomi actually win then there is a significant hole in the GPL which effectively reduces it to LGPL. That would cause hellish problems with "Free Software" everywhere.
Most countries in the world (including the US) have some form of VAT - either at a state level (ie the US) or at a federal level. Taking a wide survey will find that a country's economy dies after GST only if a recession hits at the same time, or other external factors come into play.
Bankruptcy being up 36% this year is a pretty common figure all over the world. Perhaps you haven't noticed the layoffs in San Jose and hiring freezes in just about every US company?
The biggest reason the Australian dollar has dropped (and the bankruptcies) is not the GST but the mismanagement of the economy by the Reserve Bank. Interest rates never should have been pushed as high as they were and now people are going broke as they can't afford to repay the loans. The effect of GST compared to this was negligible.
Howard should indeed be running scared though - Labor is gonna put up one hell of a FUD campaign (as usual) and probably win with no real future vision or policies (again).
If you read the RH filings with the SEC, Red Hat themselves don't know when or even *IF* they are going to turn a profit. I don't understand how you can assert it is likely they will if they don't believe they will themselves.
From their 10k filing:
"We expect to incur substantial losses on a GAAP basis for the foreseeable future."
"We have incurred operating losses in six of our previous seven fiscal years, including our most recent fiscal year ended February 28, 2001. We expect to incur significant losses for the foreseeable future, as we substantially increase our sales and marketing, research and development and administrative expenses. In addition, we are investing considerable resources in our Red Hat Network initiative and to expand our professional services offerings. As a result, we cannot be certain when or if we will achieve sustained profitability. Failure to become and remain profitable may adversely affect the market price of our common stock and our ability to raise capital and continue operations."
My take on this is that it is rather unrealistic to expect Red Hat to return a profit to its shareholders in the next five years, perhaps if ever!