If you are posting the seminal Trusting Trust, you should also post Countering Trusting Trust to balance it. It is possible to escape the trojaned compiler problem through the use of double diverse compilation.
There's a page of the bugs I looked at http://tinyurl.com/6ek4zu (although if you edit the filter then it will find more bugs I touched.). My username is Sitsofe Wheeler and if you're logged in you can dig up my email address on bugzilla from my previous link...
For some reason, your name sounds familiar... Was mpt around back then too?
Do you feel that things like the unconfirmed and verified states are helpful in bug trackers that see high traffic?
How do you feel about really old bugs that are difficult to fix (perhaps they are feature requests?) being used as ammunition against a project? Is this a problem worth solving? If you have those surely bugs less than a few years old aren't so bad?
What are your thoughts on auto reminders to auto close bugs? What do you see as the tradeoff (if there is one)?
If you feel this will be solved with enough manpower, how much man power do you think that would be? What do you think should be the maximum effort expended to get that manpower?
What do you think would be the effect of spending more time closing bug reports?
Hopefully you'll see this and if you reply, thanks in advance.
Basically, bugs have a lifecycle - they may start out UNCOnfirmed, move to confirmed, then in progress, then resolved and finally rest in verified.
I used to do volunteer triage for Mozilla back in 2000 (folks like Gerv, Timeless and Asa probably don't remember me though;). I even have an old out of date page called kill-unco.
However the reality is that there a lot of people filing bugs at a rate that is very high. Generally speaking there are not enough people to look at bugs at the best of times and this leads to a never ending amount of work. Bugs that poorly written, bugs that need to be followed up, bugs that are feature requests, bugs that are old and really difficult to fix and so on all take up vast amounts of time.
To handle this, people looking at bugs need to spend less time (or magically grow in number) in order to handle the ever increasing load. However being terse can lead to its own problems and the inevitable fall out occurs. The person in this blog post seems to be saying "Triagers are people too! We need more people doing triage full time" but the reality is this situation has existed since the beginning. Triage is a thankless, unfashionable task and the better you do it the more work you attract. It does teach how to write a really good bug report though:)
Hopefully some of the older or famous commenter will pop in to say goodbye. It feels like there's a need for someone to post a history of big events on Slashdot to recap the history (ideally in separate posts so they can be modded up separately)
It's been fun reading the stories on the website (well and community) you created with your friends and I wish you good luck on what you move to next!
...it's the external drivers - as you point out in your post it was a kernel module that caused you massive grief. Most applications don't depend on out-of-tree with kernel drivers and thus are insulated from the kernel changes (this is why you can often get away with running a hand rolled modern kernel on "old" distributions).
However, the moment you have touch out-of-tree drivers your experience is going to be ongoing pain and it generally doesn't matter which out-of-tree driver you are using. If you are ever lucky enough to use a system that doesn't need out-of-tree drivers (i.e. you don't need the fastest graphics, you don't use Virtualbox/VMWare, you aren't using ndiswrapper for your network card, you aren't using certain virus checkers, etc) you will see a reasonable kernel experience.
A stable kernel API won't help the Linux compatibility matrix issue (wrt to the kernel) either - in addition to a stable API you would also need a stable ABI (otherwise you have to rebuild the driver for each distro anyway). To get either of these you need someone to do the work of writing and maintaining glue layers and that (like all work) is thankless, expensive, never ending work which people want if someone else is doing it but do not want to pay the price for.
Of course! The point is that anyone who asks must be able to get the GPL'd source of what you built. Bear in mind that shipping the source to someone on CD is almost as difficult for the vendor (imagine the requester turns round and says the CD doesn't work) as ANYONE can ask for said the source and send in their cheques in currency that needs to be converted etc. Failing to get the source to them could result in your products being blocked so it's probably not worth being difficult about it.
For what it's worth, most Android companies seem to be taking releasing the kernel source seriously but only after delaying for as long as possible (coupled with the kernel binary driver gray area).
This does not refute your point that Apple did _not_ fork the project closed after they obtained the copyright (CUPS always required copyright assignment so it was always possible for people to negotiate for it to be provided under terms other than the GPL).
Does that mean ASUS had to/has to licence this patent for Bootbooster too? Caching the results from the last boot seems a sensible idea when some modern BIOSes take an age to finish...
There is a rumour that this is a "Chrome on Windows 7" feature (see http://www.youtube.com/watch?v=YAEN_BDR6ao for a video of the feature). You can apparently get extensions that offer something close but not quite the same. For what it's worth the split view feature seems to be broken if you have your tabs down the left hand side in Chrome...
The problem is "keyless" (no password or secret bits needed) encryption doesn't actually add any real security because the passwords have to be accessed without being "unlocked" first.
What do I mean? Imagine you protect the password database with a single password (e.g. the unlock code). Now swiping the password database wins me nothing because it still needs unlocking. Now imagine I have a desktop with password-less autologin - my choices are now complicated. I must either
Prompt the user the moment I need to access the password database
Store the users password in a form that it can be derived using information on the filesystem
Store the database unencrypted
The first one is unweildly for a phone (does an unlock code really provide enough bits to securely lock the database?). The second and the third are effectively the same. In fact the second case reminds me of the old password database from Netscape where if you swiped the password database and a key file you could find out the real passwords.
When I log into GNOME I don't have to have the same volume as the last user who logged into GNOME- it's restored on a per user basis
Simplified volume interface. Pulseuadio multiplexes things like the Master volume and the PCM volume into a single control thus allowing better granularity than the Master volume alone
When I plug a USB webcam in, pulseaudio now remembers that I prefer it as my default microphone and applications switch to using it rather than the built in one without forcing programs to be reconfigured
The per app volumes are also useful - sometimes a Flash app in the browser doesn't have a volume control but I can use pulseaudio to make it quieter
Easier to apply volume boost (artificially making quiet audio "louder")
Easier to switch between audio setups (e.g. from stereo to 5.1)
There were introductory issues too:
When it was introduced most programs didn't use pulseaudio directly. Some programs still wanted to use OSS. Pulseuadio can emulate a subset ALSA but some programs were using more than that subset
Not all distributions enabled ALSA emulation when they first enabled pulseaudio. This created fights between ALSA using programs and pulseaudio using ones
Bugs in audio drivers were uncovered. Like a tree falling in a forest with no one around to hear it, you can create a philosophical debate as to whether a bug is a bug if no one hits it. Regardless, the result was pain for some users.
Bugs in the userland audio stack. Bugs in gstreamer and pulseaudio have caused issues like the volume going to 0 every time a track was changed or huge CPU usage that caused pulseaudio to be killed off.
Choice of audio mixing methods which make use of floating point
These issues seem to have been mostly solved with time but caused a lot of heartache along the way. The problem is whether it was a chicken and the egg issue where these issues wouldn't have been uncovered until people started testing these things but you can never get enough testers so...
Then there are issues that are still with us. If you have a creative sound card your life is going to be difficult. Pulseaudio doesn't make use of hardware mixing so if you have such a card, you may have noticeably higher CPU usage than ALSA alone (even though the audio mixing is no better). Two steps forward, one step back?
ALSA was never going to be able to introduce all the features mentioned in the first part of this mega post, mainly because it is too low level. Even OSS on the BSDs doesn't present an easy GUI for all those features (it does do mixing and per program volumes) yet Windows and OS X have many of these features. The big picture is that I can do things that I couldn't before and sometimes a lot simpler (remember esd and artsd?) but there was a cost. You may not find the cost was worth it but my feeling is that it will be around on "big" Linux (e.g. machines similar in power to desktops) for the next 10 years.
64 bit support from open source software has been ready for a few years in terms on the Linux distributions. Someone who has been only using open source stuff will tell you "it's been ready for years! How could you not know?".
Most Linux 64 bit problems stem from closed source pieces. Things like closed drivers, closed browser plugins, closed source communications software, closed source software for reading certain documents, closed source electronics software, certain enterprise software etc. Those sometimes come in 32 bit only versions necessitating the need for 32 bit versions libraries to be available (in addition to the 64 bit libraries that were already installed). People will tell you different things on this depending on how early they made the 64 bit switch, which distro they were using, how much of this software they had to get working etc. Responses range from "it was easy to install the 32 bit libraries - they only take up 100Mbytes extra" to "it was a nightmare having to set up a 32 bit chroot" or "I couldn't get my device to work because there was no driver available".
If you don't have 4Gbytes or more of memory don't stress that you're not 64 bit - you're not missing much. If you DO have 4GBytes or more memory, it sounds like you are serious user who really should face the (lessening) growing pains of 64 bit so as to better utilise their machine.
The problem was that Flash was using overlapping memory areas on memcpy. This was a hidden problem in Flash but it was exposed by a glibc change on certain architectures (as noted at length in the bug you linked to). The glibc change was not wrong as far as the spec goes but it was definitely unhelpful to end users. In the end, the glibc devs made a change that means the different memcpy only kicks in for programs linked against newer versions glibc which seems a defensible stance.
This is what MS were forced to do with IE and it causes major issues because it encourages people to write to particular versions. It means people are inclined to do things like only target one browser ("your browser is unknown because it is too new"), it gives them another reason to only support old versions of code ("well my users can use compat view") rather than update their code and it makes browsers harder to write because you can't drop old code and potentially have to keep adding more and more engines to support all the old quirks. I gather this is one of the reasons why HTML5 no forces authors to signal which version of HTML they are targeting...
You make a good overall point though - the previous product was EOL'd too quickly and the target market was poorly communicated. I remember people were complaining about changes to iMovie at one stage and more recently missing features from a new version of iPhoto but those weren't pro products. You've got to get products to market and aren't software developers always being told the way to do this is by cutting features if you aren't going to make the schedule?
Slashdot Mirror
Thanks for correcting me!
If you are posting the seminal Trusting Trust, you should also post Countering Trusting Trust to balance it. It is possible to escape the trojaned compiler problem through the use of double diverse compilation.
Hi Jesse!
There's a page of the bugs I looked at http://tinyurl.com/6ek4zu (although if you edit the filter then it will find more bugs I touched.). My username is Sitsofe Wheeler and if you're logged in you can dig up my email address on bugzilla from my previous link...
For some reason, your name sounds familiar... Was mpt around back then too?
Hey Tyler,
I have some questions:
Hopefully you'll see this and if you reply, thanks in advance.
Basically, bugs have a lifecycle - they may start out UNCOnfirmed, move to confirmed, then in progress, then resolved and finally rest in verified.
I used to do volunteer triage for Mozilla back in 2000 (folks like Gerv, Timeless and Asa probably don't remember me though ;). I even have an old out of date page called kill-unco.
However the reality is that there a lot of people filing bugs at a rate that is very high. Generally speaking there are not enough people to look at bugs at the best of times and this leads to a never ending amount of work. Bugs that poorly written, bugs that need to be followed up, bugs that are feature requests, bugs that are old and really difficult to fix and so on all take up vast amounts of time.
To handle this, people looking at bugs need to spend less time (or magically grow in number) in order to handle the ever increasing load. However being terse can lead to its own problems and the inevitable fall out occurs. The person in this blog post seems to be saying "Triagers are people too! We need more people doing triage full time" but the reality is this situation has existed since the beginning. Triage is a thankless, unfashionable task and the better you do it the more work you attract. It does teach how to write a really good bug report though :)
It is well known in time synchronization circles that by default Windows stores the time in the BIOS/RTC in the local time zone but there is a registry hack for Vista and above to make Windows use UTC in BIOS/RTC. However Windows uses UTC internally.
Hopefully some of the older or famous commenter will pop in to say goodbye. It feels like there's a need for someone to post a history of big events on Slashdot to recap the history (ideally in separate posts so they can be modded up separately)
It's been fun reading the stories on the website (well and community) you created with your friends and I wish you good luck on what you move to next!
You're right - it wasn't contradictory or wrong just an unusual way to highlight it :).
...it's the external drivers - as you point out in your post it was a kernel module that caused you massive grief. Most applications don't depend on out-of-tree with kernel drivers and thus are insulated from the kernel changes (this is why you can often get away with running a hand rolled modern kernel on "old" distributions).
However, the moment you have touch out-of-tree drivers your experience is going to be ongoing pain and it generally doesn't matter which out-of-tree driver you are using. If you are ever lucky enough to use a system that doesn't need out-of-tree drivers (i.e. you don't need the fastest graphics, you don't use Virtualbox/VMWare, you aren't using ndiswrapper for your network card, you aren't using certain virus checkers, etc) you will see a reasonable kernel experience.
A stable kernel API won't help the Linux compatibility matrix issue (wrt to the kernel) either - in addition to a stable API you would also need a stable ABI (otherwise you have to rebuild the driver for each distro anyway). To get either of these you need someone to do the work of writing and maintaining glue layers and that (like all work) is thankless, expensive, never ending work which people want if someone else is doing it but do not want to pay the price for.
Why does the summary say "then at SuSE"? Greg's still working for SUSE/Novell as a Linux kernel developer fellow right?
Of course! The point is that anyone who asks must be able to get the GPL'd source of what you built. Bear in mind that shipping the source to someone on CD is almost as difficult for the vendor (imagine the requester turns round and says the CD doesn't work) as ANYONE can ask for said the source and send in their cheques in currency that needs to be converted etc. Failing to get the source to them could result in your products being blocked so it's probably not worth being difficult about it.
Another point is that if you provide GPL binaries on a network server you also have to provide the sources on the network server. This may be difficult to avoid because various people may need the binaries for flashing purposes and once you give out a link...
It doesn't matter that you didn't modify the source you still have to distribute source yourself if you distribute the binaries. This has come up before in the context of Linux distribution - it is not sufficient to point to someone else's source when distributing GPL licensed binaries.
For what it's worth, most Android companies seem to be taking releasing the kernel source seriously but only after delaying for as long as possible (coupled with the kernel binary driver gray area).
There's a an old Joel on Software article called Fire and Motion and in the second half he talks about a similar phenomenon:
For what it's worth, I don't think Mozilla are quite in this situation as they are producing new features too...
I'm not quite sure where the "BSD licensed CUPS" myth started... The very early beta releases (back in 1999) of CUPS were under the Aladdin Free Public License (you can read about Michael Sweet talking about the AFPL license choice in a comment) , a licence that is more similar to the GPL than to a BSD-esque licence. However, in version 1.0b3, CUPS switched from the AFPL to the GPL and has been distributed under the GPL ever since (and you can read Michael Sweet saying the CUPS API is under the GPL but perhaps this changed later?).
This does not refute your point that Apple did _not_ fork the project closed after they obtained the copyright (CUPS always required copyright assignment so it was always possible for people to negotiate for it to be provided under terms other than the GPL).
Does that mean ASUS had to/has to licence this patent for Bootbooster too? Caching the results from the last boot seems a sensible idea when some modern BIOSes take an age to finish...
Other parts of Oracle are donating Openoffice to Apache...
There is a rumour that this is a "Chrome on Windows 7" feature (see http://www.youtube.com/watch?v=YAEN_BDR6ao for a video of the feature). You can apparently get extensions that offer something close but not quite the same. For what it's worth the split view feature seems to be broken if you have your tabs down the left hand side in Chrome...
The problem is "keyless" (no password or secret bits needed) encryption doesn't actually add any real security because the passwords have to be accessed without being "unlocked" first.
What do I mean? Imagine you protect the password database with a single password (e.g. the unlock code). Now swiping the password database wins me nothing because it still needs unlocking. Now imagine I have a desktop with password-less autologin - my choices are now complicated. I must either
The first one is unweildly for a phone (does an unlock code really provide enough bits to securely lock the database?). The second and the third are effectively the same. In fact the second case reminds me of the old password database from Netscape where if you swiped the password database and a key file you could find out the real passwords.
Many of the things that pulseaudio provides:
There were introductory issues too:
These issues seem to have been mostly solved with time but caused a lot of heartache along the way. The problem is whether it was a chicken and the egg issue where these issues wouldn't have been uncovered until people started testing these things but you can never get enough testers so...
Then there are issues that are still with us. If you have a creative sound card your life is going to be difficult. Pulseaudio doesn't make use of hardware mixing so if you have such a card, you may have noticeably higher CPU usage than ALSA alone (even though the audio mixing is no better). Two steps forward, one step back?
ALSA was never going to be able to introduce all the features mentioned in the first part of this mega post, mainly because it is too low level. Even OSS on the BSDs doesn't present an easy GUI for all those features (it does do mixing and per program volumes) yet Windows and OS X have many of these features. The big picture is that I can do things that I couldn't before and sometimes a lot simpler (remember esd and artsd?) but there was a cost. You may not find the cost was worth it but my feeling is that it will be around on "big" Linux (e.g. machines similar in power to desktops) for the next 10 years.
64 bit support from open source software has been ready for a few years in terms on the Linux distributions. Someone who has been only using open source stuff will tell you "it's been ready for years! How could you not know?".
Most Linux 64 bit problems stem from closed source pieces. Things like closed drivers, closed browser plugins, closed source communications software, closed source software for reading certain documents, closed source electronics software, certain enterprise software etc. Those sometimes come in 32 bit only versions necessitating the need for 32 bit versions libraries to be available (in addition to the 64 bit libraries that were already installed). People will tell you different things on this depending on how early they made the 64 bit switch, which distro they were using, how much of this software they had to get working etc. Responses range from "it was easy to install the 32 bit libraries - they only take up 100Mbytes extra" to "it was a nightmare having to set up a 32 bit chroot" or "I couldn't get my device to work because there was no driver available".
If you don't have 4Gbytes or more of memory don't stress that you're not 64 bit - you're not missing much. If you DO have 4GBytes or more memory, it sounds like you are serious user who really should face the (lessening) growing pains of 64 bit so as to better utilise their machine.
The problem was that Flash was using overlapping memory areas on memcpy. This was a hidden problem in Flash but it was exposed by a glibc change on certain architectures (as noted at length in the bug you linked to). The glibc change was not wrong as far as the spec goes but it was definitely unhelpful to end users. In the end, the glibc devs made a change that means the different memcpy only kicks in for programs linked against newer versions glibc which seems a defensible stance.
This is what MS were forced to do with IE and it causes major issues because it encourages people to write to particular versions. It means people are inclined to do things like only target one browser ("your browser is unknown because it is too new"), it gives them another reason to only support old versions of code ("well my users can use compat view") rather than update their code and it makes browsers harder to write because you can't drop old code and potentially have to keep adding more and more engines to support all the old quirks. I gather this is one of the reasons why HTML5 no forces authors to signal which version of HTML they are targeting...
The last official version of Firefox 3.6 to support PowerPC Mozilla has not supported PowerPC (or 10.4) since Firefox 3.6.
LWN has a good article talking about the policies some Linux distros are taking on Firefox updates.
Just for the record OS X Lion server is going to be an App Store download to regular Lion. It looks like you can upgrade Lion to Lion server but you'll be charged for the extra pieces.
You make a good overall point though - the previous product was EOL'd too quickly and the target market was poorly communicated. I remember people were complaining about changes to iMovie at one stage and more recently missing features from a new version of iPhoto but those weren't pro products. You've got to get products to market and aren't software developers always being told the way to do this is by cutting features if you aren't going to make the schedule?
I'm going to parrot what ds2horner said on LWN - there needs to be evidence that the prefetching is still a benefit to somebody. If not enough people come forward with this then it's a maintenance burden for an uncertain benefit (for what it's worth it is apparently a win to keep PREFETCH on K7s).