... is people not really paying attention to the facts.
* This has been repeatedly stated to be an experiment in an alpha (i.e. testing only) release
* Revenue gathering from the choice of search engine is nothing new (it's the main way Firefox generates revenue for Mozilla Corp)
* The data gathered is which of the search boxes you use (the default firefox UI lets you search from the search bar, in the URL bar and the default homepage).
So basically this seems to be an experiment to figure out which of the search methods people are using most.
(disclaimer: I work for Canonical as a sysadmin. I'm not a developer and I don't work on Ubuntu directly, so I was not in any way involved in the planning/implementation of this, and I speak here only for myself as an Ubuntu user who's dismayed at the anger people are unbottling with little information)
Of course, but the prevailing wisdom is that for the parts used on ICH8/ICH9 systems, a more complex series of actions is needed than simply flipping one bit.
It's by no means limited to a SuSE beta. Ubuntu's Alphas of 8.10 (Intrepid) are also using 2.6.27-rc kernels. SuSE are taking the heat because they were first to put out a warning about the issue, but it is not their fault, or specific to them.
the NVM is checksummed. If the checksum fails, the driver refuses to initialise the card. It seems that something is able to write garbage data to the NVM, leaving all of its settings broken.
This isn't some database API where you get to do lots of nice high-level verification, this is twiddling bits in hardware. Of course it should be properly protected, and my discussions with Intel about this suggest that it is, and that something else is at work here, but until they release a fix, we won't know for sure.
Also, their own DOS tools to restore NIC EEPROMs actually break the laptop NICs to the point that they won't enumerate on the PCI bus, so there is literally no hope of recovery unless you happen to have a BIOS update which will rewrite all of the memory the NIC uses.
As I just pointed out elsewhere, that particular comment is not correct. A BIOS update *may* restore the NIC, but it depends purely on the BIOS update including that information. All of the available updates for my laptop do not include that, so the device was not recoverable. ie bricked.
I was given to understand that writing to the NVM on these parts was controlled by a hardware lock bit and so it shouldn't be possible for something to scribble over it?
e1000 and e1000e are separate drivers. Some of the devices which are now supported by e1000e were previously supported by e1000, so it's all a bit confusing.
AIUI, if the part is PCI Express, it's now in e1000e.
Except that that's not true. You *may* be saved by a BIOS update, but only if that update happens to include the LAN option ROM and NVM area. All of the publically available BIOS images for my Thinkpad X300 do *not* include the LAN portions and so were unable to rescue my corrupted NVM. Ironically, Intel do ship rescue tools for this sort of thing, but while they run on Laptop parts, they are not supposed to, so trying to use that actually made things worse and the NIC refused to initialise and didn't even appear on the PCI bus. The only solution (as confirmed to me by Intel) was to RMA the laptop.
Are you talking about the Linux driver? e1000e isn't at all a closed driver, it's in the kernel.org source, which is published under the GPL v2. That's about as un-closed as you can get.
You are assuming that the raw numbers (142886 and 143016) are actual counts of head unparks. they may not be. It is very common for laptop drives to spit out uncalibrated numbers (e.g. my laptop claims to unpark the heads 80,000 times a second, which physically isn't possible and would wear out the disk (if the highly dubious 600,000 figure is correct) in under a minute)
far more useful in SMART are the VALUE WORST THRESH and TYPE columns. Since Load_Cycle_Count is an Old_age value, and the THRESH is 0, it means that it starts at 100 and goes down as the drive ages. When it reaches 0 it means the drive manufacturer believes that is roughly equivalent to the useful duty life of the drive.
Currently yours is on 86, so it's actually only down 14%, which gives you nearly 3 more years of likely life from it. That is about typical of modern laptops afaics.
A far more useful test here would be to run the same test on Ubuntu and Windows on the same hardware (there is a smartctl port at http://hdparm-win32.dyndns.org/hdparm/ ) Given that Ubuntu does not change the disk power management settings in your BIOS and/or hard disk firmware, the only variable here is whether or not Windows overrides those settings with more or less conservative values than the existing defaults (and of course it's possible that your OEM pre-installs with other settings than Windows would natively choose on a vanilla install).
For all of the screaming and wailing about Ubuntu killing disks I have not seen a single post anywhere where anyone has posted any kind of hard data that Ubuntu is behaving in any way differently to other operating systems. Ergo this is still very very much unproven - unless anyone can link to something that says otherwise?
Something worth bearing in mind here is that the raw output of smartctl is not necessarily helpful. By way of an example, this is what I get on my Thinkpad X40:
A rough calculation suggests that, being 14 months old, that claims to be parking/unparking the disk over 80,000 times a second, which is very clearly physically impossible. The value is clearly not always a simple counter.
It is the fault of Fedora in that they have singularly failed to develop and foster a thriving packaging community. Instead the effort is distributed and duplicated across a number of package repositories, the owners of which regularly tread on each others' toes and argue and so on.
When the Fedora/RHEL switch was announced, Fedora was supposed to become a vibrant community project and it could now be enjoying the success and mindshare that Ubuntu is. It's a shame really, I didn't want to leave the RedHat camp especially, but Debian (and now Ubuntu) beat them hands down on software availability.
I fully expect to see Linspire licence these for inclusion if it is at all possible - they already include a bunch of codecs. Binary breakage will only happen if gstreamer changes its ABI during the 0.10 phase (which is entirely possible and I don't think they have made any hard commitments to keep it completely ABI stable) I don't dispute that ffmpeg's implementation is a clean-room reverse engineering, but that doesn't necessarily make its IP legality different, I think.
just because they are able to use it doesn't mean it's in anyway a good solution. mplayer's GUI is a pretty horrible affair, especially when something goes wrong and it spams you with multiple, incomprehensible errors.
it's interesting that things like mplayer and ffmpeg have always focussed purely on playing media with user considerations a long way behind, while gstreamer is building a framework and a community of media applications based on it. Ultimately though people will go where the best support for their media is, so if gstreamer isn't able to reach parity with mplayer/ffmpeg in terms of codec support then it won't be able to replace those projects. That would be a shame because they aren't flexible frameworks and they aren't in any way pretty;)
It's also very important to distros. You won't find ffmpeg with all the patent-problem codecs in any sane distro, but you can drop the fluendo codecs into just about any distro and every gstreamer application can use them. Ok so many of the distros still won't be able to ship them out of the box, but the commercial ones will have the choice and users of the Free-er ones can choose to bolt them on later. I don't at all think it is ideal, but the simple facts of reality are that those formats do exist, users do want to view the media that's encoded in them and not all of those users are prepared to do legally questionable things to do that. I have already bought the full codec pack from Fluendo for two reasons - firstly because I want to have decent, supported codecs (read the README for the win32codec gstreamer plugin - pitfdll - the author confesses that he has no idea how the dll loader works, so I really hope there aren't any bugs in there), secondly I really like the work Fluendo are doing and I want to help support them improve gstreamer. Just like I buy Crossover licences every few years to say thanks to Codeweavers for the great work they have done on WINE. On the other hand I don't give my money to Transgaming because they don't tend to share their work very much. Fluendo release a fair amount of code (and obviously they can't release the codec source for some of these, but look at their mp3 plugin - it's free as in beer and you can have the source, you just can't distribute binaries without an mp3 licence).
Unfortunately there are a lot of HOWTOs and Guides people have written for Ubuntu without really knowing what they are doing, so some highly crackful customisations are out there, as well as poorly produced and unmaintained apt repositories for later versions of various packages. ubuntuguide.org is a perfect example of how not to change things on an Ubuntu install;)
This is a symptom of a long-standing misunderstanding about shell scripting. If you have #!/bin/sh you should be using POSIX shell, which will execute fine in bash, dash or the old sh. People run into problems because they've put #!/bin/sh and then used bash-only syntax - ie they should already have used #!/bin/bash, but didn't because they didn't read any docs and don't know better.
Erm, there are graphical tools for managing software sources, e.g. synaptic (in the default install) and all of this is documented in the help wiki. Also, steps are being taken to try to improve this, such as the commercial repository and more helpful prompts detailing what to do when something that should work, doesn't because of stupid licencing restrictions by vendors
Yep, it's very very reasonable compared to the silly high level load balancers some people want to sell you. Also the company is pretty small and staffed by clued people, which I always appreciate:)
LVS is a pretty damn sweet system and if you are worried about setting it up yourself, or your PHB wants a maintenance contract, I'd recommend talking to loadbalancer.org - we bought a couple of them for some web clustering at work and they are proving to be very reliable and easy to work with:)
Slashdot Mirror
... is people not really paying attention to the facts.
* This has been repeatedly stated to be an experiment in an alpha (i.e. testing only) release
* Revenue gathering from the choice of search engine is nothing new (it's the main way Firefox generates revenue for Mozilla Corp)
* The data gathered is which of the search boxes you use (the default firefox UI lets you search from the search bar, in the URL bar and the default homepage).
So basically this seems to be an experiment to figure out which of the search methods people are using most.
(disclaimer: I work for Canonical as a sysadmin. I'm not a developer and I don't work on Ubuntu directly, so I was not in any way involved in the planning/implementation of this, and I speak here only for myself as an Ubuntu user who's dismayed at the anger people are unbottling with little information)
Of course, but the prevailing wisdom is that for the parts used on ICH8/ICH9 systems, a more complex series of actions is needed than simply flipping one bit.
Most Ethernet drivers expose interfaces for writing to their NVM, specifically for ethtool to do its work.
It's by no means limited to a SuSE beta. Ubuntu's Alphas of 8.10 (Intrepid) are also using 2.6.27-rc kernels.
SuSE are taking the heat because they were first to put out a warning about the issue, but it is not their fault, or specific to them.
the NVM is checksummed. If the checksum fails, the driver refuses to initialise the card.
It seems that something is able to write garbage data to the NVM, leaving all of its settings broken.
This isn't some database API where you get to do lots of nice high-level verification, this is twiddling bits in hardware. Of course it should be properly protected, and my discussions with Intel about this suggest that it is, and that something else is at work here, but until they release a fix, we won't know for sure.
Also, their own DOS tools to restore NIC EEPROMs actually break the laptop NICs to the point that they won't enumerate on the PCI bus, so there is literally no hope of recovery unless you happen to have a BIOS update which will rewrite all of the memory the NIC uses.
As I just pointed out elsewhere, that particular comment is not correct.
A BIOS update *may* restore the NIC, but it depends purely on the BIOS update including that information.
All of the available updates for my laptop do not include that, so the device was not recoverable. ie bricked.
ronch: very interesting.
I was given to understand that writing to the NVM on these parts was controlled by a hardware lock bit and so it shouldn't be possible for something to scribble over it?
Isn't there an option to buy support from Canonical?
(Disclaimer: I work for Canonical, but not in the bits that produce or support Ubuntu)
e1000 and e1000e are separate drivers.
Some of the devices which are now supported by e1000e were previously supported by e1000, so it's all a bit confusing.
AIUI, if the part is PCI Express, it's now in e1000e.
Except that that's not true.
You *may* be saved by a BIOS update, but only if that update happens to include the LAN option ROM and NVM area.
All of the publically available BIOS images for my Thinkpad X300 do *not* include the LAN portions and so were unable to rescue my corrupted NVM.
Ironically, Intel do ship rescue tools for this sort of thing, but while they run on Laptop parts, they are not supposed to, so trying to use that actually made things worse and the NIC refused to initialise and didn't even appear on the PCI bus.
The only solution (as confirmed to me by Intel) was to RMA the laptop.
That's about as bricked as you get.
Are you talking about the Linux driver? e1000e isn't at all a closed driver, it's in the kernel.org source, which is published under the GPL v2. That's about as un-closed as you can get.
Intel do do QA on Linux. One of their engineers reported to the Ubuntu bug about this that they had reproduced it while testing Alphas of Intrepid.
err, what's the point of having firmware if your driver can't talk to it?
Also, this isn't about firmware, it's about Non-volatile memory. The chip uses it to store things like its MAC address.
You fail.
Please post the outputs of your testing to the bug on launchpad so the relevant developers can assess the results.
You are assuming that the raw numbers (142886 and 143016) are actual counts of head unparks. they may not be. It is very common for laptop drives to spit out uncalibrated numbers (e.g. my laptop claims to unpark the heads 80,000 times a second, which physically isn't possible and would wear out the disk (if the highly dubious 600,000 figure is correct) in under a minute)
far more useful in SMART are the VALUE WORST THRESH and TYPE columns. Since Load_Cycle_Count is an Old_age value, and the THRESH is 0, it means that it starts at 100 and goes down as the drive ages. When it reaches 0 it means the drive manufacturer believes that is roughly equivalent to the useful duty life of the drive.
Currently yours is on 86, so it's actually only down 14%, which gives you nearly 3 more years of likely life from it. That is about typical of modern laptops afaics.
A far more useful test here would be to run the same test on Ubuntu and Windows on the same hardware (there is a smartctl port at http://hdparm-win32.dyndns.org/hdparm/ )
Given that Ubuntu does not change the disk power management settings in your BIOS and/or hard disk firmware, the only variable here is whether or not Windows overrides those settings with more or less conservative values than the existing defaults (and of course it's possible that your OEM pre-installs with other settings than Windows would natively choose on a vanilla install).
For all of the screaming and wailing about Ubuntu killing disks I have not seen a single post anywhere where anyone has posted any kind of hard data that Ubuntu is behaving in any way differently to other operating systems. Ergo this is still very very much unproven - unless anyone can link to something that says otherwise?
Cheers,
Something worth bearing in mind here is that the raw output of smartctl is not necessarily helpful. By way of an example, this is what I get on my Thinkpad X40:
193 Load_Cycle_Count 0x0032 071 071 000 Old_age Always - 2956632174724
A rough calculation suggests that, being 14 months old, that claims to be parking/unparking the disk over 80,000 times a second, which is very clearly physically impossible. The value is clearly not always a simple counter.
It is the fault of Fedora in that they have singularly failed to develop and foster a thriving packaging community. Instead the effort is distributed and duplicated across a number of package repositories, the owners of which regularly tread on each others' toes and argue and so on.
When the Fedora/RHEL switch was announced, Fedora was supposed to become a vibrant community project and it could now be enjoying the success and mindshare that Ubuntu is. It's a shame really, I didn't want to leave the RedHat camp especially, but Debian (and now Ubuntu) beat them hands down on software availability.
I fully expect to see Linspire licence these for inclusion if it is at all possible - they already include a bunch of codecs.
Binary breakage will only happen if gstreamer changes its ABI during the 0.10 phase (which is entirely possible and I don't think they have made any hard commitments to keep it completely ABI stable)
I don't dispute that ffmpeg's implementation is a clean-room reverse engineering, but that doesn't necessarily make its IP legality different, I think.
just because they are able to use it doesn't mean it's in anyway a good solution.
;)
mplayer's GUI is a pretty horrible affair, especially when something goes wrong and it spams you with multiple, incomprehensible errors.
it's interesting that things like mplayer and ffmpeg have always focussed purely on playing media with user considerations a long way behind, while gstreamer is building a framework and a community of media applications based on it. Ultimately though people will go where the best support for their media is, so if gstreamer isn't able to reach parity with mplayer/ffmpeg in terms of codec support then it won't be able to replace those projects. That would be a shame because they aren't flexible frameworks and they aren't in any way pretty
It's also very important to distros. You won't find ffmpeg with all the patent-problem codecs in any sane distro, but you can drop the fluendo codecs into just about any distro and every gstreamer application can use them. Ok so many of the distros still won't be able to ship them out of the box, but the commercial ones will have the choice and users of the Free-er ones can choose to bolt them on later.
I don't at all think it is ideal, but the simple facts of reality are that those formats do exist, users do want to view the media that's encoded in them and not all of those users are prepared to do legally questionable things to do that.
I have already bought the full codec pack from Fluendo for two reasons - firstly because I want to have decent, supported codecs (read the README for the win32codec gstreamer plugin - pitfdll - the author confesses that he has no idea how the dll loader works, so I really hope there aren't any bugs in there), secondly I really like the work Fluendo are doing and I want to help support them improve gstreamer. Just like I buy Crossover licences every few years to say thanks to Codeweavers for the great work they have done on WINE. On the other hand I don't give my money to Transgaming because they don't tend to share their work very much. Fluendo release a fair amount of code (and obviously they can't release the codec source for some of these, but look at their mp3 plugin - it's free as in beer and you can have the source, you just can't distribute binaries without an mp3 licence).
Unfortunately there are a lot of HOWTOs and Guides people have written for Ubuntu without really knowing what they are doing, so some highly crackful customisations are out there, as well as poorly produced and unmaintained apt repositories for later versions of various packages. ubuntuguide.org is a perfect example of how not to change things on an Ubuntu install ;)
This is a symptom of a long-standing misunderstanding about shell scripting.
If you have #!/bin/sh you should be using POSIX shell, which will execute fine in bash, dash or the old sh. People run into problems because they've put #!/bin/sh and then used bash-only syntax - ie they should already have used #!/bin/bash, but didn't because they didn't read any docs and don't know better.
Erm, there are graphical tools for managing software sources, e.g. synaptic (in the default install) and all of this is documented in the help wiki.
Also, steps are being taken to try to improve this, such as the commercial repository and more helpful prompts detailing what to do when something that should work, doesn't because of stupid licencing restrictions by vendors
Yep, it's very very reasonable compared to the silly high level load balancers some people want to sell you. :)
Also the company is pretty small and staffed by clued people, which I always appreciate
LVS is a pretty damn sweet system and if you are worried about setting it up yourself, or your PHB wants a maintenance contract, I'd recommend talking to loadbalancer.org - we bought a couple of them for some web clustering at work and they are proving to be very reliable and easy to work with :)