I have a feeling Edge always rated games on a scale of 1 to 10 (but it's been years since I read issue 1) so I suspect you are thinking of another magazine. I can't see Bubsy3D in the table of Edge reviews either...
If you distribute changed GPL binaries you have to provide the source (with the changes already in it) with it (or on request). If you distribute unmodified GPL binaries you still have to provide the source code (for the unmodified binary) along with it or on request. Even if you are "just" distributing a Linux kernel/busybox compiled by someone elseyou have to provide the source for it (or a written offer for it)*.
The whole not having to GPL (and thus distribute the source) for any/every userland programs which are running on the Linux kernel issue is clarified in the license file that comes with the Linux kernel. As someone said - just because the kernel is GPL userland programs do not have to be. That doesn't get you off the hook for providing the source for the kernel if you distribute binaries though. If you are additionally distributing userland programs that have you received under GPL (like busybox) you will have to provide the source for those too (but you would have had to have done the later regardless of which license the kernel was under).
As mentioned in previous posts the GPL FAQ covers this and many issues and it is worth reading the GPL itself too to give yourself firsthand knowledge of it. The issue you seem to be thinking of is probably covered by the GPL FAQ entry about unchanged/unmodified binaries.
* There is a bit more to it than this but it's well explained in in the GPL FAQ if you missed it when reading the GPL itself.
The bug you pointed to only mentions AFP (and in fact I've run Firefox3 without the behaviour described in that bug on NFS shares for months without observing this problem). You aren't going to catch an issue like that when testing on Linux or Windows environments as they very rarely use AFP for file shares. This is only going to show up in certain OSX environments (and not all of them as some will be using NFS/Samba/Local filesystems for home directories).
I can well believe that this could be a showstopper but if you want to know that this stuff to work well in your environment it really pays to test it and report the issues early on (there have been Firefox 3 nightlies for over a year) so they can be fixed well before release. As it is, it sounds like the bug you linked to won't be fixed until a Firefox 3 update...
For years I had heard claims and counterclaims regarding whether you only had to give source to customers who had the binaries. Your post seems to clear this up well - it's not already being distributed with source code and if it's commercially sold you must give the source code to anyone who asks (not just those who bought the binaries).
However do projects have to have paid devs to succeed? If there is the manpower perhaps paid people are not so key?
How long is your bug reporting experience?
on
The State of X.Org
·
· Score: 1
Yes, some bugs do go unfixed (and basically remain open) forever. However my experience is that well described bugs are fixed more often than not. Here's a list of bugs in Ubuntu reported by me (Sitsofe Wheeler). Many of these bugs have been fixed (I've reported bugs elsewhere too, that was just a handy example).
It is worth noting that there are different types of bugs. Some are design decision suggestions ("you should move this to the left because it adheres to this style guide"). Some are requests for improvements ("You should implement this feature"). What happens with these styles of bugs varies from project to project and I can well believe that they may not be fixed (but they may well be resolved by closing them).
Paper discussing X network performance
on
The State of X.Org
·
· Score: 1
KeithP and and Jim Gettys wrote a paper on X network performance and the bottlenecks being seen a few years ago. Unfortunately I can't currently find a document discussing what the overhead of X's network transparency is (but I have a feeling it wasn't excessively high).
If you are on the latest release of your distro and the problem is reproducible please report it to your distros bug database. People only fix things that they know are broken...
The proposed outcome is for there to be increased opportunities to switch between programs/kernel or to run multiple things at the same time.
For those who enable the option this should reduce the chance of a hardware's buffer not being filled in time (so audio is less likely to skip in demanding environments). If you are an audio recording person or need VERY (less than hundredths of seconds) fast responses all the time your experience should improve. If you run VERY big workloads that have lots of pieces that can happen simultaneously on computers with 2-1024 CPUs, your experience (increase in work finished per second say) should improve. Typical desktop performance may improve a little if you have multiple CPUs/cores but one would guess not enough to be noticeable without careful measurement.
The trade off is increased risk of system hangs / data corruption due to the programming being trickier although instances of this happening should fall over time with popular hardware.
It's hard to test whether you've broken a driver when you don't have the hardware to test with. Perhaps the future will be Qemu emulation of all the different hardware in your system : )
This is not to say that there need to be tests for things that can be caught at compile time or run time regardless of hardware but there is only so far you can take it.
It's not like the kernel doesn't have any testing done on it though. There's the Linux Test Project which seems to test new kernel's nightly. If you ever look in the kernel hacking menu of the kernel configuration you will see tests ranging from Ingo Molnar's lock dependency tester (which checks to see locks are taken in the right order at run time), memory poisoning, spurious IRQ at un/registration time, rcu torture testing, softlockup testing, stack overflow checking, marking parts of the kernel readonly, changing page attributes every 30 seconds... Couple that with people like Coverity reporting static analysis checks on the code. Tools like sparse have been developed to try and so some of the static checks on kernel developer machines while they are building the code.
But this is not enough. Bugs STILL get through and there are still no go areas of code. If you've got the skills to write tests for the Linux kernel PLEASE do! Even having more people testing and reporting issues with the latest releases of the kernel would also help. It's only going to get more buggy without help...
I imagine a kernel will come out that just has uses the BKL far less (I don't think it will be a compilation option). There is a risk of instability (especially if you are using SMP/preemption) while overlooked code that need locking is sorted out (this could lead to deadlocks or in an extreme case memory corruption). Over time this risk should decrease.
This work won't go into 2.6.26 (it's too late). It may not even go into 2.6.27 (it's been done outside of the mainline tree). This may mean that until it is done kernel from 2.6.25 may have better "worse case" latencies than following kernels until this work goes in. Once it does go in that kernel may have even better "worse case" latencies than 2.6.25.
For folks not doing audio recording (listening to your MP3s doesn't count) and without the need for hard realtime the worse latencies in 2.6.26 are too small to matter.
However if you can afford to risk your machine testing this experimental work will result in issues being found and fixed quicker and a better end result for people without old hardware that few people still have.
As the the BKL is no longer be preemptible it is now a big source of latency (since it could no longer be interrupted). People still want low latencies (that's why they made the BKL preemptible in the first place) so they took the only option left and started work to get rid of the BKL.
(Bah half a dozen other people have replied in the time it's taken me to edit and redit this. Oh well...)
...because it didn't sell well in the past and the margins weren't there. I don't know that I'd go so far to say as they've completely abandoned the desktop though (at least not the corporate one). They've helped develop things like NetworkManager and other things like pulseaudio. I can't see how those are server/multi-user orientated pieces of software.
It's about not having haemorrhage money through royalties. Fraunhofer can and DO go after companies that don't licence their codec. They won't go after you as a an end user but if you are a commercial Linux vendor with some money and wide distribution...
I think the best that can be done (for those distros that want to bundle binary only stuff) would be to incorporate the Fluendo MP3 codec which has been licensed. As for creating MP3 files and DVDs, well that's another kettle of fish.
The Ubuntu provided NVIDIA binary drivers are NOT automatically copied into initrd/initramfs and to the best of my knowledge never have been (it is possible to manually specify to happen but why would you? This is not a driver needed to load the kernel from the harddisk). It IS true that there is a script that runs early on (but long after the ram disk has been disposed of) that often means that the Ubuntu provided driver is loaded before manually compiled ones. How to stop this happening is covered in the Ubuntu NVIDIA manual install doc though.
They employ folks like Ben Collins and Tim Gardner on their kernel team. In the past they have employed folks who now work in Red Hat's kernel teams. However their main objective seems to be stabilisation, security and integration of 3rd party drivers not yet in mainline tree rather than brand new developments.
selinux shipped in a fashion where it only protects services. As such most policies are set to allow a service access to its usual files/sockets and needed syscalls .
A service that was protected with selinux would probably not "stop" this exploit unless it did very little (a cursory glance suggests it is uses mmap and vmsplice to do perform the deed which could well be things a webserver needs to do). However what might happen is mitigation - a service protected by selinux might struggle in running the exploit in the first place (e.g. by blocking the ability to make an HTTP connection to a server or write to the/tmp directory or call exec on the binary). Assuming you could get it to run under such an selinux protected service you might then struggle to provide a shell or gain root privileges etc.
However selinux will NOT (at least at present) protect you from yourself. Unless you have a very tough policy it won't stop you compiling code and using a shell as a user logged in over ssh. It also doesn't protect common programs like Firefox - currently it only targets services that are ideally running as their own user.
I've had very little luck trying to make a BSD use NAT on site local packets (which are explicitly defined as not being internet routable). However given how big the typical ipv6 subnet seems to be this issue falls by the wayside the moment you get one.
Your point still stands though - ipv6 is trying to do away with NAT and rightly so. If you don't have an address squeeze it seems horrible that you would use NAT - better to use a decent firewall...
Google used MySQL for Adwords...
on
Sun Buys MySQL
·
· Score: 1
Certainly at some point in the past Google DID use for AdWords which suggests money might have been involved. What they are using now I do not know - you will need to find an appropriate current employee of Google to tell you.
I think you've chosen a bad example there. The TCP/IP stack is a very speed critical part of current kernels. At gigabit (or faster) speeds a very large number packets will arrive so that is code that is executed an awful lot (especially if you are running a stateful firewall). You don't want gettimeofday to be slow because it is called so many times. The same goes for your TCP/IP stack - you want it to be fast AND robust.
I'm not too sure about using strlen in a loop like that. C strings are NULL terminated so each time you are going through that loop and doing your test you are also having to iterate over foo to find its length (unless foo is const variable and the compiler notices etc).
It's not that you can't do the same regexs in Python. It's that the syntax for doing is different and more OOPy in Python. man perlre and look at how Perl uses them...
Slashdot Mirror
I have a feeling Edge always rated games on a scale of 1 to 10 (but it's been years since I read issue 1) so I suspect you are thinking of another magazine. I can't see Bubsy3D in the table of Edge reviews either...
If you distribute changed GPL binaries you have to provide the source (with the changes already in it) with it (or on request). If you distribute unmodified GPL binaries you still have to provide the source code (for the unmodified binary) along with it or on request. Even if you are "just" distributing a Linux kernel/busybox compiled by someone else you have to provide the source for it (or a written offer for it)*.
The whole not having to GPL (and thus distribute the source) for any/every userland programs which are running on the Linux kernel issue is clarified in the license file that comes with the Linux kernel. As someone said - just because the kernel is GPL userland programs do not have to be. That doesn't get you off the hook for providing the source for the kernel if you distribute binaries though. If you are additionally distributing userland programs that have you received under GPL (like busybox) you will have to provide the source for those too (but you would have had to have done the later regardless of which license the kernel was under).
As mentioned in previous posts the GPL FAQ covers this and many issues and it is worth reading the GPL itself too to give yourself firsthand knowledge of it. The issue you seem to be thinking of is probably covered by the GPL FAQ entry about unchanged/unmodified binaries.
* There is a bit more to it than this but it's well explained in in the GPL FAQ if you missed it when reading the GPL itself.
The bug you pointed to only mentions AFP (and in fact I've run Firefox3 without the behaviour described in that bug on NFS shares for months without observing this problem). You aren't going to catch an issue like that when testing on Linux or Windows environments as they very rarely use AFP for file shares. This is only going to show up in certain OSX environments (and not all of them as some will be using NFS/Samba/Local filesystems for home directories).
I can well believe that this could be a showstopper but if you want to know that this stuff to work well in your environment it really pays to test it and report the issues early on (there have been Firefox 3 nightlies for over a year) so they can be fixed well before release. As it is, it sounds like the bug you linked to won't be fixed until a Firefox 3 update...
For years I had heard claims and counterclaims regarding whether you only had to give source to customers who had the binaries. Your post seems to clear this up well - it's not already being distributed with source code and if it's commercially sold you must give the source code to anyone who asks (not just those who bought the binaries).
But it sounds like some of them are seemingly so well known. You've mentioned Dave Airlied and Keith Packard but what about Eric Anholt (Intel), Carl Worth (Red Hat), Daniel Stone (Nokia), Adam Jackson (Red Hat), David Reveman (Novell), Matthias Hopf (Novell), Alex Deucher (AMD), Ian Romanick (IBM), Alan Coopersmith (Sun). I believe that Tungsten Graphics also employ people who work on X (or X related infrastructure).
However do projects have to have paid devs to succeed? If there is the manpower perhaps paid people are not so key?
Yes, some bugs do go unfixed (and basically remain open) forever. However my experience is that well described bugs are fixed more often than not. Here's a list of bugs in Ubuntu reported by me (Sitsofe Wheeler). Many of these bugs have been fixed (I've reported bugs elsewhere too, that was just a handy example).
It is worth noting that there are different types of bugs. Some are design decision suggestions ("you should move this to the left because it adheres to this style guide"). Some are requests for improvements ("You should implement this feature"). What happens with these styles of bugs varies from project to project and I can well believe that they may not be fixed (but they may well be resolved by closing them).
KeithP and and Jim Gettys wrote a paper on X network performance and the bottlenecks being seen a few years ago. Unfortunately I can't currently find a document discussing what the overhead of X's network transparency is (but I have a feeling it wasn't excessively high).
If you are on the latest release of your distro and the problem is reproducible please report it to your distros bug database. People only fix things that they know are broken...
The proposed outcome is for there to be increased opportunities to switch between programs/kernel or to run multiple things at the same time.
For those who enable the option this should reduce the chance of a hardware's buffer not being filled in time (so audio is less likely to skip in demanding environments). If you are an audio recording person or need VERY (less than hundredths of seconds) fast responses all the time your experience should improve. If you run VERY big workloads that have lots of pieces that can happen simultaneously on computers with 2-1024 CPUs, your experience (increase in work finished per second say) should improve. Typical desktop performance may improve a little if you have multiple CPUs/cores but one would guess not enough to be noticeable without careful measurement.
The trade off is increased risk of system hangs / data corruption due to the programming being trickier although instances of this happening should fall over time with popular hardware.
It's hard to test whether you've broken a driver when you don't have the hardware to test with. Perhaps the future will be Qemu emulation of all the different hardware in your system : )
This is not to say that there need to be tests for things that can be caught at compile time or run time regardless of hardware but there is only so far you can take it.
It's not like the kernel doesn't have any testing done on it though. There's the Linux Test Project which seems to test new kernel's nightly. If you ever look in the kernel hacking menu of the kernel configuration you will see tests ranging from Ingo Molnar's lock dependency tester (which checks to see locks are taken in the right order at run time), memory poisoning, spurious IRQ at un/registration time, rcu torture testing, softlockup testing, stack overflow checking, marking parts of the kernel readonly, changing page attributes every 30 seconds... Couple that with people like Coverity reporting static analysis checks on the code. Tools like sparse have been developed to try and so some of the static checks on kernel developer machines while they are building the code.
But this is not enough. Bugs STILL get through and there are still no go areas of code. If you've got the skills to write tests for the Linux kernel PLEASE do! Even having more people testing and reporting issues with the latest releases of the kernel would also help. It's only going to get more buggy without help...
I imagine a kernel will come out that just has uses the BKL far less (I don't think it will be a compilation option). There is a risk of instability (especially if you are using SMP/preemption) while overlooked code that need locking is sorted out (this could lead to deadlocks or in an extreme case memory corruption). Over time this risk should decrease.
This work won't go into 2.6.26 (it's too late). It may not even go into 2.6.27 (it's been done outside of the mainline tree). This may mean that until it is done kernel from 2.6.25 may have better "worse case" latencies than following kernels until this work goes in. Once it does go in that kernel may have even better "worse case" latencies than 2.6.25.
For folks not doing audio recording (listening to your MP3s doesn't count) and without the need for hard realtime the worse latencies in 2.6.26 are too small to matter.
However if you can afford to risk your machine testing this experimental work will result in issues being found and fixed quicker and a better end result for people without old hardware that few people still have.
Matthew Wilcox replaced the per platform semaphore code with a generic implementation because it was likely to be less buggy, reduced code size and most places that are performance critical should be using mutexes now.
Unfortunately this caused a 40% regression in the AIM7 benchmark. The BKL was now a (slower) semaphore and the high lock contention on it was made worse by its ability to be preempted. As the ability to build a kernel without BKL preemption had been removed Linus decided that the BKL preemption would go. Ingo suggested semaphore gymnastics to try and recover performance but Linus didn't like this idea.
As the the BKL is no longer be preemptible it is now a big source of latency (since it could no longer be interrupted). People still want low latencies (that's why they made the BKL preemptible in the first place) so they took the only option left and started work to get rid of the BKL.
(Bah half a dozen other people have replied in the time it's taken me to edit and redit this. Oh well...)
FVWM on Ubuntu Linux. Emacs with special modes using a homemade bitmap font. Mac OSX for Illustrator and Photoshop...
Now that's breadth AND depth.
...because it didn't sell well in the past and the margins weren't there. I don't know that I'd go so far to say as they've completely abandoned the desktop though (at least not the corporate one). They've helped develop things like NetworkManager and other things like pulseaudio. I can't see how those are server/multi-user orientated pieces of software.
It's about not having haemorrhage money through royalties. Fraunhofer can and DO go after companies that don't licence their codec. They won't go after you as a an end user but if you are a commercial Linux vendor with some money and wide distribution...
I think the best that can be done (for those distros that want to bundle binary only stuff) would be to incorporate the Fluendo MP3 codec which has been licensed. As for creating MP3 files and DVDs, well that's another kettle of fish.
The Ubuntu provided NVIDIA binary drivers are NOT automatically copied into initrd/initramfs and to the best of my knowledge never have been (it is possible to manually specify to happen but why would you? This is not a driver needed to load the kernel from the harddisk). It IS true that there is a script that runs early on (but long after the ram disk has been disposed of) that often means that the Ubuntu provided driver is loaded before manually compiled ones. How to stop this happening is covered in the Ubuntu NVIDIA manual install doc though.
They employ folks like Ben Collins and Tim Gardner on their kernel team. In the past they have employed folks who now work in Red Hat's kernel teams. However their main objective seems to be stabilisation, security and integration of 3rd party drivers not yet in mainline tree rather than brand new developments.
Minix 3 has a BSD style license so it does not preclude looking and using the source. Versions released prior to 2000 were under a more restrictive license (personal copying only, no redistribution with your changes already merged in, non-commercial use and so on).
I would not consider Singularity to be under an Open Source license myself though. It is more in the vain of pre-2000 Minix (educational/academic use). However the technology in it is interesting and Google's Mike Hearn has a good series of blog entires giving an overview of the ideas within Singularity.
Yoy might be thinking of Raymond Chen's The Old New Thing blog. The shims that keep popular old programs with dubious behavior going are party why Windows is so popular. Here's an article about a decoy control panel window...
selinux shipped in a fashion where it only protects services. As such most policies are set to allow a service access to its usual files/sockets and needed syscalls .
/tmp directory or call exec on the binary). Assuming you could get it to run under such an selinux protected service you might then struggle to provide a shell or gain root privileges etc.
A service that was protected with selinux would probably not "stop" this exploit unless it did very little (a cursory glance suggests it is uses mmap and vmsplice to do perform the deed which could well be things a webserver needs to do). However what might happen is mitigation - a service protected by selinux might struggle in running the exploit in the first place (e.g. by blocking the ability to make an HTTP connection to a server or write to the
However selinux will NOT (at least at present) protect you from yourself. Unless you have a very tough policy it won't stop you compiling code and using a shell as a user logged in over ssh. It also doesn't protect common programs like Firefox - currently it only targets services that are ideally running as their own user.
I've had very little luck trying to make a BSD use NAT on site local packets (which are explicitly defined as not being internet routable). However given how big the typical ipv6 subnet seems to be this issue falls by the wayside the moment you get one.
Your point still stands though - ipv6 is trying to do away with NAT and rightly so. If you don't have an address squeeze it seems horrible that you would use NAT - better to use a decent firewall...
Certainly at some point in the past Google DID use for AdWords which suggests money might have been involved. What they are using now I do not know - you will need to find an appropriate current employee of Google to tell you.
I think you've chosen a bad example there. The TCP/IP stack is a very speed critical part of current kernels. At gigabit (or faster) speeds a very large number packets will arrive so that is code that is executed an awful lot (especially if you are running a stateful firewall). You don't want gettimeofday to be slow because it is called so many times. The same goes for your TCP/IP stack - you want it to be fast AND robust.
I'm not too sure about using strlen in a loop like that. C strings are NULL terminated so each time you are going through that loop and doing your test you are also having to iterate over foo to find its length (unless foo is const variable and the compiler notices etc).
I'm not so sure about the "you forgot to terminate your string constants" bit. My understanding is that string constants are NULL terminated in C. I would be a bit cautious about assigning a string constant to a fixed sized array though (it feels wrong... If copying happened there's potential for wasted/too little memory, questions over whether you are actually throwing a pointer to rewritable memory away, are you trying to change read only memory later etc). Whether more memory is zeroed before use depends on your platform, libraries, how the memory allocation was done and your compiler (e.g. on Linux the glibc malloc function switches between brk and mmaped memory allocations depending on size and mmaped memory is zeroed by the kernel before being passed to your program).
It's not that you can't do the same regexs in Python. It's that the syntax for doing is different and more OOPy in Python. man perlre and look at how Perl uses them...