Misinterpretation of Standard Causing USB Disconnects On Resume In Linux

hypnosec writes "According to a new revelation by Sarah Sharp, misinterpretation of the USB 2.0 standard may have been the culprit behind USB disconnects on resume in Linux all along rather than cheap and buggy devices. According to Sharp the USB core is to blame for the disconnections rather than the devices themselves as the core doesn't wait long enough for the devices to transition from a 'resume state to U0.' The USB 2.0 standard states that system software that handles USB must provide for 10ms resume recovery time (TRSMRCY) during which it shouldn't attempt a connection to the device connected to that particular bus segment."

Comments

A bug in Linux?

[Anonymous Coward]

Clearly the whole thing is broken, and we should transition to a newer, more open and transparent system than even open source.

I will call it OPENER Source. You aren't just able to read the source, you're required to read it!

Update

[Anonymous Coward]

"Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. "

linux has bugs?

[Anonymous Coward]

Could have fooled me, I end up spending upwards of 3 months a year fixing bugs in the base os that we ship to run our appliance on. Some of the linux subsystems still read like they were written in someone's basement even after a decade of most of the maintainers being paid a yearly salary to maintain it. God forbid you actually fix some of the crap and post fixes though that are more than ten lines long.. Its a fine way to get blacklisted.

Re:linux has bugs?

[TheGavster]

It's true. Linus has been quite vocal about whose fault it is when a kernel change breaks an application...

Re:linux has bugs?

[LordLimecat]

Im not a software dev, but I have never agreed with this:

If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs.

What happens when some program has been using a privilege escalation bug to get around sudo, and it breaks when the kernel is patched to fix the vulnerability? Is that still "a kernel bug", should they not patch it? It seems to me that, yes, you try not to break applications, but this is why you have an official, supported API, and if bad developers want to rely on buggy kernel behavior for their programs, you have to choose between either screwing them, or screwing everyone else.

If anyone can enlighten me as to why thats wrong, Id appreciate it.

Re:linux has bugs?

[Anonymous Coward]

For all practical purposes there's no way, I repeat, no way to "heat the whole apartment block" to eradicate bed bugs.

So you don't know what you are talking about.

If anyone can enlighten me as to why thats wrong, Id appreciate it.

1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. They change it.
3. ALL SOFTWARE suddenly works *different* and perhaps does not work at all on the modified kernel that uses that syscall vs.older kernel.

Kapish??

Do not change API internals. Fixing undocumented features (ie. bugs, like overflows) is one thing. Modifying documented and established API on a whim is a bad bad bad thing.

If you want to modify it like that, you do the following,

1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. SO MAKE A NEW SYSCALL THAT RETURNS CORRECT! Leave old one as deprecated for removal in some years.
3. ALL SOFTWARE continues to work.

If #2 is too much effort for reward, then do nothing. But above all, do not break userland with kernel changes. Ever.

Re:linux has bugs?

[hedwards]

Basically, the kernel has an Application Binary Interface which is a bit like a contract. If the application gives the kernel something formatted in a specific way, the kernal promises to give it back something in a specific way and the other way around. Any software that is written to respect the contract should never be broken by a change to the kernel as the application has no knowledge of how the kernel performs its obligation.

Changes to the ABI are not supposed to be common events. They're supposed to be changed only when lesser changes can't work. FreeBSD handles it using compatibility libraries which maintain the ABI for various kernel revisions so that applications can continue to use older ones if need be. AFAIK, Linux doesn't do that, and as a result, the kernel maintainer and the developers writing the code have to be even more careful about changes made not messing up the ABI.

Also, because Linux is just a kernel without a userland, a change to the Linux kernel that was permitted to break the ABI could hose all of the distros all at once requiring the rewrite of hundreds of little bits of software that are cobbled together to make the distros function as complete OSes.

There's more to it, but that's basically why Linus takes the stance that the kernel is to blame and not the developer. But, he undoubtedly doesn't consider it to be the kernel's fault if a developer does things that don't comply with the normal ABI specifications.

Re:linux has bugs?

[You're All Wrong]

Strange. I'll admit that Linux has some drivers that are full of bugs, but the ones that are most full of bugs seem to be ones thrown over the wall by large hardware vendors. You know the ones - the drivers with 20000-line C files, that create 2000 checkpatch warnings. Those drivers were written by salaried employees, not sitting in their basement.

Re:linux has bugs?

[You're All Wrong]

And Alan Cox resigned as maintainer of the TTY subsystem because of this attitude. (Userspace was clearly broken, and a kernel change made this clear, however, in Linus' eyes, that was "breaking userspace") Just because Linus holds that opinion doesn't mean that it's universally shared to the same extent (everyone agrees to some extent, but not to absolutes).

Re:linux has bugs?

[minus9]

Yet you still choose it as the base OS to run your appliance on. Presumably it's still better than any of the alternatives.

All software has bugs. I'm sure plenty of device drivers written in brightly lit offices by people with smart haircuts and shiny shoes have some absolutely horrific code too. I doubt which floor you work on has any significant effect.

Re:linux has bugs?

[somersault]

it seems as if [Linus is] a petulant child at times. Okay, quite frequently... That's sad because having someone approachable would probably be a good thing for Linux. As for approachability, you have RMS and Linus... Yeah...

As opposed to Ballmer throwing his chairs about? In case you haven't noticed, the people that run all the world's largest companies are even bigger assholes than Linus. Besides, to me Linus just seems opinionated, rather than immature.. and having a strong sense of direction helps when doing something like overseeing the Linux kernel.

Re:linux has bugs?

[Forever Wondering]

The ABI has been changed upon occasion. If a struct passed to a syscall (or ioctl) has some spare option bits (that were reserved [and therefore zero], that can be the way to go (e.g. turning on the bit indicates that the program is aware of the new semantics).

Otherwise, a new syscall (or ioctl) number is assigned. For example, the stat syscall originally had a syscall number of 18. When the "struct stat" was modified [added some new fields and/or expanded the size of others], the syscall number was bumped to 106. Old programs that were not recompiled issued stat with 18 and worked unchanged. If you recompiled, you got syscall 106 and the new semantics.

Re:linux has bugs?

[somersault]

Well, maybe Mauro really needed to STFU and listen to someone more experienced at that point? There's a stage where it's better to stop trying to be polite, and get people to wake up, if you want them to learn.

Re:linux has bugs?

[somersault]

The chair wasn't thrown at anyone in particular. It was thrown because someone else was leaving MS to work at Google and Ballmer decided he was going to "fucking kill Google". He's doing an A1 job so far.

Re:linux has bugs?

[YttriumOxide]

there are some who write gobs of horrid code with sparse comments like // here be dragons.

What really gets to me is when I deal with code that is 70% comments, but it's all along the lines of:

/* The following function increments i and then calls the other function when it matches x */
IncrementAndCheckI() {
i++; /* increments i */
if(i==x) { /* checks if i is now the same as x */
CallOtherFunc(i); /* call the other function with i as a parameter */
}
}

What's most disturbing is that I see this really quite regularly. Damn near every line is commented, and yet none of it tells me ANYTHING useful about what the code is supposed to be doing or why.

I see this FAR more often from university educated programmers than I do from self-taught hackers.

Re:linux has bugs?

[smooth wombat]

I hate to admit it, since I don't use any form of Linux, but I'm beginning to like Linus despite his ego. His words are similar to the ones I would like to tell the multi-billion dollar corporations I have to deal with when I'm trying to figure out why their software works on everyone's machine one day, then on only one the next.

It's quite obviously a programming issue but no, I have to go round and round with people at various levels until they finally admit defeat and say, "Make the user a local admin." As if that solves the underlying problem.

When you hear me get on programmers cases in articles on here, this is why.

Re:linux has bugs?

[Mr. Slippery]

This self taught basement hacker has been writing self documenting code since single digit years...

Anyone who believes in "self documenting code" does not understand computer programming.

Re:linux has bugs?

[iserlohn]

I'm not sure which world you live in, but leading the project which produces the OS kernel that is used in more computing devices than any other - well, that's not a bad result really.

Re:linux has bugs?

[Zan Lynx]

I assume you would like security bugs specially marked so that you can prioritize fixing them and releasing the changes.

Look at the number of bugs found and fixed which have much later been discovered to be security bugs.

So now you didn't push "non-security" bug fixes to your production servers and they get owned by bad guys.

The lesson is that you should treat all bugs as security bugs.

not surprising

[angryargus]

Power Management has worked well on Windows for 15+ years. I'm still waiting for Linux's first year, so problem on Linux are with the kernel and/or the drivers.

Re:not surprising

[Anonymous Coward]

You just said power management worked well on windows 98 and 95.

I am calling you a liar.

Re:not surprising

[TheGavster]

15+ years is a stretch. Even in the 2006-07 era at the end of XP's development, there were brand new machines that couldn't return from sleep correctly. It was particularly vexing since a lot of them were laptops factory configured to sleep when left unattended. I will say that I haven't had any complaints with S3 sleep since the advent of Windows 7, however.

Re:not surprising

[Qzukk]

Spoken like someone who's never had to reboot a computer from coma mode.

Re: not surprising

[Jeremiah Cornelius]

Power management ?

It's worked well for years on Linux. Only problems I ever had were involving nVidia workaround drivers and sleep.

Re:not surprising

[DG]

I've got an XP laptop that instantly BSODs the second you close the lid.

So yeah, myth busted.

DG

Re:not surprising

[jamesh]

My Windows 7 laptop will regularly not come out of sleep, requiring a battery removal to resolve. This occurs more often when I'm packing up and unplug something while it's going to sleep. Typically this happens after about 3 weeks since last reboot, which really sucks because it only has to get to a month and it gets rebooted to install updates anyway.

The other annoying thing it does is when it wakes up it still thinks it has the external monitor attached (the VGA/DVI monitor only - the USB attached ones are fine). To resolve this when i've changed location and have another second screen I have to unplug it, wait a few seconds, then plug it back in again. Worse when I'm somewhere where I don't have a second screen at all and I have to muck around to get Windows to understand I only have the laptop screen

Now it's probably true that the above issues are caused by third party drivers, and not Windows itself, but it still sucks.

Re:not surprising

[philip.paradis]

THe other one is my wife's so it isn't running Linux.

My wife's laptop is running Debian 7. What's up with your wife? :)

Re:not surprising

[angryargus]

There's a big difference between Windows where problems are a corner case, vs. Linux where success is a corner case. But the point still remains that I've used sleep and hibernate on most of my Windows machines without really fearing problems or data loss (I'll still save any progress before initiating it, though thanks to Office 97 I'm in the habit of saving regularly regardless), but I can't think of even bothering to try such a thing on Linux (nor can even of the people I know who love Linux enough to actually enjoy updating to a new distro every few months/years). I probably won't even think of trying to use sleep or hibernate on a Linux box until I see that the Linux kernel has developed drivers models that have some hint of being designed with power management in mind. Heck even the PCI driver model in Linux doesn't fit the spec well. Most Linux drivers I've had to deal with need to mess with the device's PCI configuration space themselves, whereas on Windows that's pretty rare because it's usually handled by the core kernel (which was the intent of the PCI spec based on how it's written).

Re: not surprising

[hedwards]

Which is easy for MS to achieve as they're willing to implement a non-standard ACPI implementation rather than using the Intel implementation that everybody else uses. And write work arounds for buggy implementations rather than kick it back to the manufacturer to do correctly.

Linux doesn't have that luxury, which means that DSDT changes and such have to be done by the end user rather than the developer that should have implemented the standard correctly in the first place.

Re:not surprising

[davester666]

You flipped the switch or hit the power button, it turned on, flip/hit it again, it went off. What didn't work right?

Re:not surprising

[Barsteward]

i've got a laptop that blue screens when you pull out the power cord.

If i remember correctly a lot of the power management problems are due to the manufacturers not implementing the standards correctly, they implemented them to the broken Windows implementation in order to keep WIndows working.

Re: not surprising

[FireFury03]

FWIW, I now have a policy of avoiding Acer like the plague and advising my customers to do the same, owing to their appealing customer support when advised that an entire product line had a bios bug.

http://www.nexusuk.org/~steve/acer.xhtml

TL;DR: one of their lines of laptops has a dsdt bug, I informed them, they weren't interested. I even sent them a patch, still not interested (and decided that completely ignoring my emails was the best approach). To this date they haven't released an updated bios.

Re: not surprising

[garutnivore]

I share the same policy. I bought one and only one Acer in my life. It was the first Acer I bought and is the last. Early on it would not sleep under Linux so I took at look at the BIOS. That thing was so sloppily coded! The batteries that Acer shipped with the laptop also had a manufacturing flaw that caused them to fail prematurely. Batteries degrade over time progressively but these would one day perform at 90% original specs and the next day perform the best brick impression. I owned two Acer-approved batteries for this laptop and both failed in exactly the same way. I also bought an ultra-cheap third-party battery that did not show this problem.

Re:not surprising

[Alsee]

Oh heavens, it must be happening again. I'm obviously experiencing a relapse of those terrible hallucinations that have plagued me for years.
Oh, wait, she's real after all.

Dude, you posted a photo of a laptop sitting on the armrest of an empty couch ;)

-

Re: not surprising

[Muad'Dave]

... stubbornly refuses to sleep with win7. Works fine with Linux.

At least she has some standards.

Maybe not all the disconnects?

[AdamHaun]

Sarah's Google+ post has an update:

Update: Looks like this is an xHCI specific issue, and probably not the cause of the USB device disconnects under EHCI. To everyone who commented with other USB issues (none of which really sounded related), please email the linux-usb mailing list with a description of your issue.

USB sucks

[Skapare]

USB as a whole is already a silly design, having all these silly details and ambiguities. For example, where it has a minimum time (10ms in this case), it should also have a maximum time (for example 50ms). Devices should be able to communicate after that maximum time or they are broken. Actually, there should be a maximum time when powered up ... how is a minimum even useful for anything.

This only needs to specify controller communication, not device function. For example a hard drive might take several seconds to spin up and get in sync. But the controller should be able to do basic communication in 50ms, even if all it can say about the actual hard drive is "spinning up but not ready". USB has a lot of other stuff that is far from the KISS principle.

Re:USB sucks

[skids]

You're pulling your punches. USB was a completely half-ass standard to start with, and then was continually modified with half-ass frankenstein additions to provide features that were already in competing bus technologies, once its designers finally had to admit that those features were actually useful.

Anyway it is not much of a surprise that things can slip in the USB area. There are only a few developers who are both talented enough to work do it right and also have the patience for wasting their talent making the dung sculptures that USB stacks always turn out to be.

(Personally I think the better path would have been to just use CAT5 UTP with ethernet signalling but a frame protocol that would just shut down a port if it detected you plugging normal ethernet into the bus. Then all the ports could have been bios-configurable for either peripheral or network use.)

Re:USB sucks

[TheGratefulNet]

well, you CAN plug a usb male connector into an rj45 jack.

it won't work, but it will fit just fine.

(stupid oversight. the last 15 or so years, cable and connector designers have been pretty idiotic. don't get me started on that rant..)

Re:USB sucks

[FrankSchwab]

In the SPEC, devices are required to treat it as a maximum and the host is required to treat it as a minimum. Any device which isn't ready for communications after 10 ms are broken, and any host that attempts communications before 10 ms is broken. This isn't an area of the spec that's in any way vague.

Re:USB sucks

[You're All Wrong]

Agreed.

Do we think that Sarah will receive some trademarked swearing because of this?
http://news.techeye.net/chips/linus-torvalds-and-intel-woman-in-sweary-spat
http://linux.slashdot.org/story/13/07/15/2316219/kernel-dev-tells-linus-torvalds-to-stop-using-abusive-language

I'm beginning to wonder if Sharp is a MS or Apple plant, sent into linux kernel work to sow seeds of antagonism and self-destruction.

Re:USB sucks

[tlhIngan]

You're pulling your punches. USB was a completely half-ass standard to start with, and then was continually modified with half-ass frankenstein additions to provide features that were already in competing bus technologies, once its designers finally had to admit that those features were actually useful.

Anyway it is not much of a surprise that things can slip in the USB area. There are only a few developers who are both talented enough to work do it right and also have the patience for wasting their talent making the dung sculptures that USB stacks always turn out to be.

Things in USB have generally been quite buggy and will always be that way - it's quite a complex spec and controllers and software never behave the way they should.

Take something like initial enumeration - the initial descriptor you read is 18 bytes long. Neither Linux nor Windows actually does an 18-byte read to get a full descriptor. I suppose it could be a USB test to ensure your controller software can handle an undersized read without screwing up.

Then there was the time I screwed up my USB descriptor (screwed up the type). End result was Linux kept panicking on me - the moment I plug it in, boom panic. (This was years ago. I would assume it's fixed). Windows didn't do anything.

I think part of the problem is basically there hasn't been any USB fuzzing tools, so most USB stacks are buggy and have lots of exploitable flaws. Hell, it was how the PS3 was exploited once.

Re:USB sucks

[localman]

As someone whose computer experience predates the birth of USB by many years, I find all the criticism of USB to be a hoot. I mean, sure, it's a mess compared with an ideal system, but oh my lord it's so much better than the mess we had before I don't even know what to say. When peripheral interconnects are so good that we resort to complaining about USB, it's a better world than I could have dreamed of 25 years ago.

Re:USB sucks

[eddy]

I did that yesterday.

Then I yelled at the phone for not charging.

Misinterpretation *By Linux*

[billstewart]

Unfortunately, the article's referring to the "misinterpretation" passively, not saying directly who the author is asserting misinterpreted the spec, but I think from context it seems to be saying "misinterpreted by Linux", as opposed to "misinterpreted by lots of cheapo USB devices". It's bad that Linux does that, but it's certainly easier to fix in one place in Linux than going out to lots of vendors putting out equipment with very low profit margins and hope they'll all do the right thing.

I was also a bit confused as to when the article was referring to microseconds (s) vs. milliseconds (ms); I found it surprising that it seemed to be saying that most of the devices responded in under a microsecond, while others were over 10ms.

Re:Misinterpretation *By Linux*

[FrankSchwab]

There is no ambiguity in the USB spec, and Sarah has an incorrect interpretation. The spec requires that the host provide at least 10 ms of recovery time coming out of suspend; a device is required to be able to communicate after this minimum time. Any device which isn't ready for communications after 10 ms of resume recovery time is broken. A host is permitted to provide more than this, but isn't required to.

So, yes, it's perfectly valid for the host to blindly attempt to communicate with the device after 10 ms - presuming that the host KNOWS precisely when the recovery period began. If the host requested that the bus resume, set a timer for 10 ms, and then tried talking, the HOST is at fault because it didn't check with the hardware as to when the resume period began. I think the 17 ms that they reference in the article is related to this - there is a delay between the request to resume the bus and the actual time that the hardware does resume the bus, so they were trying to talk with devices before the 10 ms period was up.

The device is perfectly within the spec if it ignores communications prior to 10 ms, or if it responds to them - it has complete flexibility. After 10 ms, however, it MUST be ready to communicate.

Re:Misinterpretation *By Linux*

[smash]

Meanwhile, USB works just fine on my Mac, Windows and FreeBSD hardware. Sounds like someone implemented the spec and someone is blaming everyone else.

Re:Misinterpretation *By Linux*

[localman]

Sorry, but that's not how it works. If you want to say that there's a consensus to operate out of spec, that's fine, but according to the spec 10ms is the minimum amount of time before you can communicate. Which is another way of saying it's the maximum amount of time you have to get ready for communication. The Intel engineer that claimed it meant that they could take longer than that is an idiot - reading the spec that way makes it meaningless.

I think it is probably wise that other systems give a longer delay. In fact it seems a little naive to assume that every device is going to operate on such tight tolerances. There is also a chance, as the previous poster said, it may not really be giving 10ms, depending on how various signals get queued - if that's the case, then Linux was wrong, as opposed to the devices.

Whatever the case, it doesn't have to be an OS pissing match. Linux seems to have implemented the spec with no wiggle room beyond the spec. Other systems left wiggle room beyond the spec, which may have been wise. It's like browsers and quirks mode - rendering tag soup is kind of wrong, but you're not going to get a popular browser if you fail to render a page every time someone mis-nests their tags.

And I'm on a Mac, so this isn't an ego thing for me. I just like to keep the facts straight.

Resume? What's that?

[UltraZelda64]

Back in the mid-1990s to the mid-2000s when I used Windows, I realized sleep mode was a complete joke, unreliable, and just stopped using it by the time I upgraded to Windows XP or shortly after. In Linux, I am still not a fan of waiting for the damn thing to "wake up" for 5-10 seconds before it will even accept my password, so the only component that ever even enters standby on my machines is the moniter (and this has been the case for over a decade, even dating back to my last years in Windows). Windows, Linux--doesn't matter what the OS is, not putting the system into standby makes the whole experience much smoother, faster and hassle-free.

On the other hand, though--it is a good thing this was fixed for those laptop users out there.

Re:Resume? What's that?

[hedwards]

Not true.

Standby is there for when you want to leave your desktop applications open and have the benefits of using less energy while you eat dinner or take a walk. Hibernation is great if you need that 0 watts of draw, but don't want to have to have all your programs closed down and to have to start from scratch.

Re:Resume? What's that?

[jones_supa]

Hibernation is also good for those laptops which blink a LED while on suspend, and when that happens in the dark when you're sleeping, you can see the whole damn room pulsing. Hibernation puts the machine off, and if you pull the power cord off too, you usually are left with no lights. Ahh.

Welcome to EE

[Ignacio]

The 10ms is for the software. The flip side of this is that the hardware has a maximum of 10ms to get its shit together so that it can be connected to. And 10ms is forever in hardware.

Re:Welcome to EE

[jamesh]

The 10ms is for the software. The flip side of this is that the hardware has a maximum of 10ms to get its shit together so that it can be connected to. And 10ms is forever in hardware.

Dear Linux kernel, i'll be ready when my disk is done spinning up. kthanksbye

Re:Welcome to EE

[Ignacio]

The 10ms is for the software. The flip side of this is that the hardware has a maximum of 10ms to get its shit together so that it can be connected to. And 10ms is forever in hardware.

Dear Linux kernel, i'll be ready when my disk is done spinning up. kthanksbye

Dear USB hard drive, that's fine, but don't go and disconnect from the USB bus in the meantime. Forever waiting, Linux kernel.

Re:Welcome to EE

[Alsee]

Atleast with the case of xHCI the 10ms is actually a minimum for both -- the specs do not indicate a maximum for the hardware to resume at all.

That's not how specifications work. Both sides are required to obey the spec for things to work. A minimum for one side is a maximum for the other side.

It's like we have a lunch break specification. The specification says that on a lunch break he must wait a minimum 30 minutes before sending the employee more work to do. This means the employee has a maximum 30 minutes to finish lunch.

What is happening here is that the employer (the computer) is obeying the spec. It's waiting the required minimum time, then sending a message "here's some work to do". The employee (the USB device) is late, still lingering out to lunch (in violation og the lunch rules) when he gets the work message. This employee (device) is responding "I'm not ready, I quit" and goes home (device disconnect).

-

Re:not surprising, since there are few docs

[dltaylor]

Far too many vendors are only willing to provide chip documentation under a Non-Disclosure Agreement (NDA), which prevents a knowlege-, as opposed to empirical-based Linux driver. This allows them to kludge around chip deficiencies in a Windows driver without the user being aware of any issues. Even Intel has started making it harder to get the real manuals for their CPUs and bridges (they used to ALL be published on Intel's FTP and HTTP sites). Frequently, in System-on-Chip (SoC) implementations, even the CHIP vendors don't know anything; they just pass along whatever quick and dirty proof of concept the designers of some feature of the chip provided and call it a "working driver", while it is nothing that would pass even a cursory QA process.

The first Linux code I wrote was a "quirk" handler for a parallel ATA PCI chip that came up programmed to the same default I/O addresses as the South Bridge's internal ports, and a BIOS that didn't properly perform PCI enumeration on it, since it already had PCI addresses.

So I can close my laptop now?

[kriston]

So I can close my laptop now instead of carrying it around like a sort of open pizza box for fear of never having a working mouse until the next reboot? How annoying to start a meeting by rebooting a Linux laptop.

Re:So I can close my laptop now?

[kriston]

That's the obvious solution, but, really, my computer should not lose the ability to be controlled by a USB device just because it went to sleep when the lid was closed. My Windows laptop has done this successfully for, like, fifteen years now?

Re:So I can close my laptop now?

[tlhIngan]

Why do you need a mouse ?

Because most laptops generally have terrible pointing devices. If they have touchpads, they're usually far too tiny to be useful (Apple ones excluded - why can't others put big ass touchpads on their laptops?)

The rubber trackpoint ones are nice for PCs, though the rubber tips wear down way too quickly and you end up with a slippery lump in short order.

And practically all are pathetic at scrolling. Unless it's an Apple trackpad where the double finger scroll works (once you fix the ()#@% scroll direction).

Life's just generally easier with an external pointing device.

Just try to boot from a USB drive that powers off

[ralphaostrander]

Unless the USB is on. It does not wake in time. Craptastic.

It explains a lot!

[gagol]

That is why my laptop sd-card reader is not working when I close the lid... until reboot. F!*$&%" usb...

Re:It explains a lot!

[gagol]

Yeah, laugh all you want, it is the only issue I had with linux in 8 years... I saw much more trouble on Windows PC's at work/friends. Byut you know what? I dont care if you prefer Windows, Linux or even Mac! Not everybody likes playing guitar, not everybody have the same needs. That being said, I prefer a defective sd card reader than running Windows 8 anyday.

Re:Happy Thursday from The Golden Girls!

[jones_supa]

These weird spam/troll messages are part of what makes Slashdot so unique. ;)

Re:linux is atrocious

[_merlin]

Parent is a troll, but s/he has a point. All this talk about sleep mode being useless sounds more than a little silly from the POV of a Mac user. Macs have had fast, reliable sleep/wake since the second generation G3s around 2000. Windows has kinda caught up. You really want this if you actually use a notebook computer. I don't want to have to go saving and closing everything then shutting down when it's time to get on the plane, then having to open it all again and get back to where I was once I'm on my way to Hong Kong. I just want to be able to flip it shut and put it in the bag, then flip it open when I'm in my seat and be right where I was.

pm-suspend-hybrid

[Artemis3]

Try pm-suspend-hybrid, this will initiate a normal hibernate: copy ram to disk as usual, but at the end it won't shutdown, but go into suspend. Result: If you come back, its instant on; but if the power ran out or was unplugged, your state is still saved and you return from hibernation.

People still unplug their stuff or let the batteries run out so don't expect that scenario until a memory technology that keeps its state without power (such as mram) becomes the norm.

The GPL v 4.0

[shiftless]

Anyone desiring to use Linux will be required to print out the entire Linux source code (on an Epson dot matrix printer), read every page, and then initial it to confirm their understanding. This will be mailed in to the FSF to track compliance.

If there are any bugs found then everyone who signed that page gets their license revoked.

I am sure with this fool proof plan the Linux userbase will double in no time!