Many of us may use our cars for in-town trips much of the time but we still want them to be able to go on long distance journeys a few times a year for family holidays. This, plus the current cost, are the only reasons we've not gone electric.
For most people, it isn't just a few times a year. The national average commute to work is about 16 miles, or a 32-mile round trip. The worst case range on a Nissan leaf is only 47 miles. So if you have to make an extra stop across town to drop your kid off at school or pick up groceries, then even a driver with an average commute under worst-case conditions might not make it home without a charge. So for about half of all drivers (assuming the median is probably near the mean), electric cars aren't practical or are just barely practical when brand new.
Oh, but it gets worse. The older the battery gets, the less capacity it has. By the time a car is ten years old, I would expect it to have about half as much range as it did when it was new. Thus, the range of a 10-year-old EV is likely to be inadequate for the overwhelming majority of drivers in their day-to-day activities.
The magic number is 200 miles for the worst-case range. This ensures that when the vehicle is a few years old, its range will likely still be enough to handle the majority of owners' commutes. This translates to about a 300 mile average range. In other words, the batteries on existing EVs are undersized by more than a factor of 4 from what I would consider to be a usable vehicle. They're simply nowhere close to being ready for prime time.
It's not us who set the policy or prescriptions. A doctor gave me a long rant when I asked him about why the antibiotic prescription he gave me was for just 3 days.
IMO, such a short round of antibiotics is a great way to cause antibiotic resistance. Where a longer round might have killed off all of a particular variety of bacteria, a short round means that the bacteria that are most resistant to it are the only ones that live to become a constant, low-grade infection. Repeat that enough times, and such a policy seems likely to cause the very problem that it was presumably intended to prevent.
Because that would not cause the underlying flash page to be erased, which means it would not improve performance later, when the flash controller runs out of pre-erased pages and has to start erasing pages on the fly during the write operation.
Quick terminology note: Flash storage is divided into large blocks, commonly called pages (to avoid confusion with disk blocks). Each page contains many disk blocks.
Flash storage has an interesting property in that you can change individual bits in only a single direction (either from 0 to 1 or 1 to 0, depending on the flash type). To change it in the other direction, you must wipe an entire flash page, which means rewriting the contents of a large number of blocks. To avoid a high risk of a power failure causing the loss of data that wasn't even changing at the time, the flash controller does not do the erase and rewrite in place. Instead, it rewrites the entire page in a different physical location (with an updated copy of the changed block or blocks), and then atomically changes the block or page mapping so that the blocks are now associated with the new physical page. It then erases the original page so that it can be reused during a subsequent write operation.
This need to erase and rewrite has a side effect, however. As the flash drive gets more and more full, it eventually runs low on pages that can be erased ahead of time, because eventually every block on the disk has had something written to it at some point in the past, even if that block is no longer actively being used by any actual file. The disk does keep some spare pages around, but that only goes so far towards fixing this problem. This means erasing pages during the write operation itself, which is a much slower operation than writing to a pre-erased page. Many of those pages, however, may contain only data that is no longer relevant—blocks from files that were deleted a long time ago. Therefore, if the flash controller could somehow know that it is safe to pre-erase those pages ahead of time, they could be ready to go when you need to write data to them.
Unfortunately, it isn't practical for a flash controller to understand every possible file system, which makes that somewhat difficult. To solve this problem, they added a new ATA command, called TRIM. The operating system sends a TRIM command to tell the flash controller that the blocks within a certain range are no longer in use by the filesystem, which means that the flash pages that contain those blocks can be pre-erased for fast reuse.
As I understand it, the extra time (it's only two hours for international flights) is mainly because those flights have more people on them than (most) domestic flights, and on top of that, people are much more likely to bring checked luggage, so they need more time to properly screen all of it, not to mention that you'll spend extra time waiting in line at the counter to check in the bags.
Except for some international flights at airports with a separate international terminal, planes don't usually arrive at the gate until less than an hour before takeoff, so clearly they don't load the bags onto them an hour before departure (unless they have a giant trebuchet that launches them into the air and stunt pilots to catch them mid-flight, which while awesomely cool in principle, is probably not very practical).
I recently purchased several items from KlearGear.com. Their purchase agreement prohibits negative comments, so here is my review:
The can of SPAM® was greatly appreciated. It makes a much better doorstop than the one I ordered, because the metal shards really dig into the rug. Even better, unlike the boxes of SPAM® you buy at the grocery store, this one came with a large hole in the side, so I didn't even have to find a can opener before sucking out the meaty goodness.
The packaging was in impeccable condition, having only been run over by three UPS trucks—a far cry from the usual twelve. And their customer service can't be beaten. I only had to call 150 times over the course of a three month period to reach someone who helpfully pointed out that I could step on the can of SPAM® I received and use it as a doorstop. And the agents' language was truly amazing. I learned over a hundred new swear words in five languages.
In short, I cannot recommend this business more highly if you enjoy surprise delivery of products that do not resemble what you ordered and learning how to say f*** off in Swahili while talking to a customer service representative in Tanzania. I know I sure do.
No one can claim that this is a negative review.:-D
First, it's not clear a contract was established. And even if it was, unilateral changes generally are unenforceable. And even if it were there when the attempted purchase was attempted, this is an unconscionable contract clause, against public policy (1st amendment, etc) and should be thrown out.
Yeah, I was about to post pretty much the same thing, but I'd go one step further. I would argue that such a contract term would be unconscionable and illegal even without the first amendment issue, because a restraint of only negative reviews is contrary to the public interest, creating a false positive impression of a business that is unjustified by its actions. Such a contract effectively constitutes a fraudulent act of false and misleading advertising by the business via its customers, and as such, the contract term is illegal. An illegal contract term is unenforceable per se.
Make no mistake. It is perfectly legitimate for a contract to say that you cannot write any reviews of the business. It is not legitimate for a contract to dictate that only positive reviews are allowed. There is no question whatsoever that this woman will win in court handily unless her lawyer is completely incompetent unless the business also makes similar threats against anyone who writes a positive review.
That said, before she even calls a lawyer, this should be brought to the attention of the anti-fraud division in her state's AG's office for possible criminal prosecution of the site's owners and management, under "conspiracy to commit fraud".
...and thereby allow using that proxy card to empty out all the other accounts in one grand gesture.
Actually, no, quite the opposite. Because the proxy card I described would do preauthorizations for every transaction against your default card, it would not be possible for a thief to exceed the credit limit of your default card unless you were stupid enough to then log in online and redirect some of those charges to a different card after your card got stolen. Thus, the proxy card solution would significantly reduce the amount of damage that a thief could do when compared with carrying around the individual cards.
In fact, because you would be in control over what the proxy card did and did not authorize, you could even ostensibly configure the proxy card with a typical spending limit of $30 per day, and only open it up temporarily with your cell phone right before making a large purchase, which would pretty dramatically reduce fraud if used in that way. Of course, if the credit card companies actually cared about fraud, they would stop using a pseudo-secret number as their sole means of authentication and authorization....
By contrast, the device described in this article would allow somebody to empty out all eight accounts in one grand gesture, unless I'm missing something (assuming the thief also stole your phone and popped out the SIM card so that it would never go out of range but would not be trackable). And that would also be equally true if you were carrying around all eight physical cards.
Amazon already lets you choose different payment methods, as do most big online stores.
Um, we're not talking about online purchases here. There's no good reason to use something like this for online payments. That would be pretty silly, because online merchants usually store your credit card information anyway, so you don't need the actual card or even the card number when you're shopping. Devices like these are for brick-and-mortar purchases, so that you don't have to carry around multiple cards.
This would be a great thing for cloning all those obnoxious loyalty cards that clog your billfold, if it could clone those, but I'm guessing it is only for credit cards.
IMO, the right solution for credit cards is entirely different. What someone needs to do is work with Visa/MC/Amex to create a card that serves as a proxy card for multiple cards. It should have its own number, and each charge is treated as a preauthorization on your default card. Then, at any time before midnight on the day you make a purchase (possibly longer), you should be able to route the actual charge to the card of your choice.
Because the proxying would be handled by a real server with real compute power, you could even specify that, for example, all purchases made at a gas station during the months of May, June, and July should be routed to your Chase card (for example) because that's the bonus category for that period. You could automatically make Amazon purchases go to your Amazon card, make Amtrak purchases go to your Amtrak card, make air travel purchases go to your airline miles card, etc.
And because it would be a real card in its own right instead of a clone of an existing card, it could even have its own chip (or even chip and pin). You could assign an arbitrary billing ZIP code to make it far less likely for anyone to be able to use it to make significant purchases if it gets stolen. You could instantly cancel it from your mobile phone if it gets stolen without causing you to lose access to any actual credit. And so on.
Not just lawyers. I have an absolute closed door policy on AGPL. I won't even use AGPL-licensed software for personal use. Its restrictions are the absolute antithesis of freedom in my world view.
Indeed, virologists announced earlier this week that a camel owned by a victim of MERS also had the disease, the first evidence of this kind of transmission so far. So if you don’t own a pet camel, you’re probably safe.
Sorry, Drommy. Guess I'm gonna have to put you down.
I think the green versus not green covers that. IMO, anybody who doesn't have an EV certificate probably doesn't really need a TLS certificate. For everybody else, storing the public key (preferably not a fingerprint—disk space is too cheap to cut corners like that) upon the user's first visit is sufficient security.
Of course, such a scheme would bankrupt the bloated SSL cert industry and their extortion racket, but I would argue that such an outcome would be progress.
By my math, that's only enough water for about 60 people (assuming average usage). That might be enough water for a tiny mining community, but it is an inconsequential amount of water in the context of even your average small town, much less a city of any size. Like I said, I'm not sure you'd ever get the evaporation rate up high enough to be viable.
"Ignorance of the law is no excuse" is only valid when the laws are available.
Not even then. It's only valid when either all the laws are common sense or the number of laws is sufficiently small that a reasonable person can avoid being ignorant of them.
Without those limits on the law, you end up in a society where lawyers run the world, and everybody is constantly having to run everything by their lawyers before they even have a simple conversation in public. We're rapidly approaching that point, assuming we aren't already way past it.
Hmmm, facts that voter ID laws don't suppress turnout don't fit your close-minded notions?
Neither you nor the article provide any such facts. The facts merely show that the number of people who voted is greater, not that there was no increase in the percentage of legitimate voters who were turned away and gave up on voting. Any claim that the former proves the latter is a non sequitur (unless 100% of the public attempts to vote). To actually prove that suppression did not occur, you would need, at minimum:
The total number of votes
The number of people turned away who did not later come back to vote (possibly at a different polling place) even though they were legally eligible to vote
It is remarkably hard to gather that second piece of information accurately, but without it, any claims that voter suppression did not happen are nothing more than ordinary opinions with no factual support whatsoever.
Put another way, your argument based on totals is equivalent to saying that the population of the United States is increasing, so the percentage of people who die in any given year must have gone down. While the latter is probably true because people are living longer, it does not follow from the first statement. The population can also grow if more people choose to have kids, if people choose to have more kids, or if more immigrants are allowed into this country. In fact, the population could grow even if the annual death rate increases, so long as the number of additional kids exceeds the additional death rate.
Similarly, an increase in the number of voters just means that more people chose to vote. If there are a hundred voters and five are dissuaded from voting by the hassle, then 5% of voters were suppressed, but 95 people voted. If in the following election, 150 people decide to vote, but stricter laws make it more of a hassle, and fifteen are dissuaded, then 10% of voters were suppressed, but 135 people voted. We would say that voter suppression increased even though the number of total voters also increased. The two statements are not contradictory.
But to get back on topic, I don't have a lot of sympathy for the DOD and the rest of the federal government. The decline of Blackberry has been steady and consistent for the past several years. If this is coming as a surprise to them—if they have not already taken steps to encourage adoption of other platforms—then they are incredibly shortsighted, and deserve whatever pain the transition causes them.
That's exactly what I was wondering. I've always thought it would be cool to build a giant floating greenhouse, with water running down the sloped ceiling sections into catch basins that slowly slope downhill towards shore and eventually become pipes flowing downhill to a fully enclosed reservoir with a pumping station—a completely passive desalinization plant. I'm not sure you'd ever get the evaporation rate up high enough to be viable, but it would look awesome.:-)
USB floppy drives should work just fine, assuming they comply with the UFI spec. Those drives won't read Apple 3.5" disks, though, because AFAIK none of the USB floppy drives support GCR.
Except the kernel contains all its drivers within its source tree.
Not at all. I've built and installed drivers that aren't part of the kernel source tree on several occasions. The entire driver stack has to be part of the kernel, by necessity, but not the drivers themselves.
IMO, the Linux kernel should pull all of the drivers out of the kernel source tree and into separate projects so that they can be separately maintained. The "everything in the kernel project" model means that every fix to every driver is dependent upon the upstream maintainers taking the changes. That's a maintenance nightmare.
The next phase is almost always to replace the technology or some portion thereof with something that does the same thing, but in a better or easier to use way.
With TeX, the logical next step is HTML/CSS typesetting. I'm pretty sure you could replicate most of the interesting parts of LaTeX in only a few thousand lines of JavaScript, assuming you had a browser that supports most of CSS3, but you'd also get lots of stuff that LaTeX can't handle.
With Linux as a whole, the logical next step is to repeatedly shoot X11 in the head until it stays down, then build something modern to replace it. Possibly replace it with Wayland—hard to say.
Down at the kernel level, the next logical step is to reduce the over-reliance on unreliable device names. Compared with OS X, the hot plug configuration story seems downright miserable to me. Device node names in the filesystem change, Ethernet interface names change depending on what order stuff gets plugged in, and so on, and the only way to fix this involves creating cryptic configuration files that try to pin devices in position. Blech. Those names shouldn't matter; if they do, you're doing it wrong.
Basically, Linux needs to do something similar to OS X's kextd and I/O Kit frameworks. Start by working up a standard API for walking the device tree, searching for devices that match against specific criteria, and returning a usable reference to that device (e.g. an open file descriptor). Then, create network configuration tools that use that matching system to identify the interface and configure it appropriately using a configuration dictionary. Then the next logical step is to load drivers based on those matching dictionaries. And then you have something approaching a usable driver loading system.
Slashdot Mirror
For most people, it isn't just a few times a year. The national average commute to work is about 16 miles, or a 32-mile round trip. The worst case range on a Nissan leaf is only 47 miles. So if you have to make an extra stop across town to drop your kid off at school or pick up groceries, then even a driver with an average commute under worst-case conditions might not make it home without a charge. So for about half of all drivers (assuming the median is probably near the mean), electric cars aren't practical or are just barely practical when brand new.
Oh, but it gets worse. The older the battery gets, the less capacity it has. By the time a car is ten years old, I would expect it to have about half as much range as it did when it was new. Thus, the range of a 10-year-old EV is likely to be inadequate for the overwhelming majority of drivers in their day-to-day activities.
The magic number is 200 miles for the worst-case range. This ensures that when the vehicle is a few years old, its range will likely still be enough to handle the majority of owners' commutes. This translates to about a 300 mile average range. In other words, the batteries on existing EVs are undersized by more than a factor of 4 from what I would consider to be a usable vehicle. They're simply nowhere close to being ready for prime time.
IMO, such a short round of antibiotics is a great way to cause antibiotic resistance. Where a longer round might have killed off all of a particular variety of bacteria, a short round means that the bacteria that are most resistant to it are the only ones that live to become a constant, low-grade infection. Repeat that enough times, and such a policy seems likely to cause the very problem that it was presumably intended to prevent.
Because that would not cause the underlying flash page to be erased, which means it would not improve performance later, when the flash controller runs out of pre-erased pages and has to start erasing pages on the fly during the write operation.
Quick terminology note: Flash storage is divided into large blocks, commonly called pages (to avoid confusion with disk blocks). Each page contains many disk blocks.
Flash storage has an interesting property in that you can change individual bits in only a single direction (either from 0 to 1 or 1 to 0, depending on the flash type). To change it in the other direction, you must wipe an entire flash page, which means rewriting the contents of a large number of blocks. To avoid a high risk of a power failure causing the loss of data that wasn't even changing at the time, the flash controller does not do the erase and rewrite in place. Instead, it rewrites the entire page in a different physical location (with an updated copy of the changed block or blocks), and then atomically changes the block or page mapping so that the blocks are now associated with the new physical page. It then erases the original page so that it can be reused during a subsequent write operation.
This need to erase and rewrite has a side effect, however. As the flash drive gets more and more full, it eventually runs low on pages that can be erased ahead of time, because eventually every block on the disk has had something written to it at some point in the past, even if that block is no longer actively being used by any actual file. The disk does keep some spare pages around, but that only goes so far towards fixing this problem. This means erasing pages during the write operation itself, which is a much slower operation than writing to a pre-erased page. Many of those pages, however, may contain only data that is no longer relevant—blocks from files that were deleted a long time ago. Therefore, if the flash controller could somehow know that it is safe to pre-erase those pages ahead of time, they could be ready to go when you need to write data to them.
Unfortunately, it isn't practical for a flash controller to understand every possible file system, which makes that somewhat difficult. To solve this problem, they added a new ATA command, called TRIM. The operating system sends a TRIM command to tell the flash controller that the blocks within a certain range are no longer in use by the filesystem, which means that the flash pages that contain those blocks can be pre-erased for fast reuse.
FTFY.
As I understand it, the extra time (it's only two hours for international flights) is mainly because those flights have more people on them than (most) domestic flights, and on top of that, people are much more likely to bring checked luggage, so they need more time to properly screen all of it, not to mention that you'll spend extra time waiting in line at the counter to check in the bags.
Except for some international flights at airports with a separate international terminal, planes don't usually arrive at the gate until less than an hour before takeoff, so clearly they don't load the bags onto them an hour before departure (unless they have a giant trebuchet that launches them into the air and stunt pilots to catch them mid-flight, which while awesomely cool in principle, is probably not very practical).
Oh, I'm sure you can do better than that.
No one can claim that this is a negative review. :-D
Yeah, I was about to post pretty much the same thing, but I'd go one step further. I would argue that such a contract term would be unconscionable and illegal even without the first amendment issue, because a restraint of only negative reviews is contrary to the public interest, creating a false positive impression of a business that is unjustified by its actions. Such a contract effectively constitutes a fraudulent act of false and misleading advertising by the business via its customers, and as such, the contract term is illegal. An illegal contract term is unenforceable per se.
Make no mistake. It is perfectly legitimate for a contract to say that you cannot write any reviews of the business. It is not legitimate for a contract to dictate that only positive reviews are allowed. There is no question whatsoever that this woman will win in court handily unless her lawyer is completely incompetent unless the business also makes similar threats against anyone who writes a positive review.
That said, before she even calls a lawyer, this should be brought to the attention of the anti-fraud division in her state's AG's office for possible criminal prosecution of the site's owners and management, under "conspiracy to commit fraud".
Actually, no, quite the opposite. Because the proxy card I described would do preauthorizations for every transaction against your default card, it would not be possible for a thief to exceed the credit limit of your default card unless you were stupid enough to then log in online and redirect some of those charges to a different card after your card got stolen. Thus, the proxy card solution would significantly reduce the amount of damage that a thief could do when compared with carrying around the individual cards.
In fact, because you would be in control over what the proxy card did and did not authorize, you could even ostensibly configure the proxy card with a typical spending limit of $30 per day, and only open it up temporarily with your cell phone right before making a large purchase, which would pretty dramatically reduce fraud if used in that way. Of course, if the credit card companies actually cared about fraud, they would stop using a pseudo-secret number as their sole means of authentication and authorization....
By contrast, the device described in this article would allow somebody to empty out all eight accounts in one grand gesture, unless I'm missing something (assuming the thief also stole your phone and popped out the SIM card so that it would never go out of range but would not be trackable). And that would also be equally true if you were carrying around all eight physical cards.
Um, we're not talking about online purchases here. There's no good reason to use something like this for online payments. That would be pretty silly, because online merchants usually store your credit card information anyway, so you don't need the actual card or even the card number when you're shopping. Devices like these are for brick-and-mortar purchases, so that you don't have to carry around multiple cards.
I don't use GPLv3 code if I can help it. I'll put up with GPLv2.
This would be a great thing for cloning all those obnoxious loyalty cards that clog your billfold, if it could clone those, but I'm guessing it is only for credit cards.
IMO, the right solution for credit cards is entirely different. What someone needs to do is work with Visa/MC/Amex to create a card that serves as a proxy card for multiple cards. It should have its own number, and each charge is treated as a preauthorization on your default card. Then, at any time before midnight on the day you make a purchase (possibly longer), you should be able to route the actual charge to the card of your choice.
Because the proxying would be handled by a real server with real compute power, you could even specify that, for example, all purchases made at a gas station during the months of May, June, and July should be routed to your Chase card (for example) because that's the bonus category for that period. You could automatically make Amazon purchases go to your Amazon card, make Amtrak purchases go to your Amtrak card, make air travel purchases go to your airline miles card, etc.
And because it would be a real card in its own right instead of a clone of an existing card, it could even have its own chip (or even chip and pin). You could assign an arbitrary billing ZIP code to make it far less likely for anyone to be able to use it to make significant purchases if it gets stolen. You could instantly cancel it from your mobile phone if it gets stolen without causing you to lose access to any actual credit. And so on.
Not just lawyers. I have an absolute closed door policy on AGPL. I won't even use AGPL-licensed software for personal use. Its restrictions are the absolute antithesis of freedom in my world view.
From the article:
Sorry, Drommy. Guess I'm gonna have to put you down.
You wouldn't download a car. You wouldn't download a handbag. ...
Wow, this thread just took a turn for the disturbing.
We could start a political movement. Call it the Key Party.
I think the green versus not green covers that. IMO, anybody who doesn't have an EV certificate probably doesn't really need a TLS certificate. For everybody else, storing the public key (preferably not a fingerprint—disk space is too cheap to cut corners like that) upon the user's first visit is sufficient security.
Of course, such a scheme would bankrupt the bloated SSL cert industry and their extortion racket, but I would argue that such an outcome would be progress.
By my math, that's only enough water for about 60 people (assuming average usage). That might be enough water for a tiny mining community, but it is an inconsequential amount of water in the context of even your average small town, much less a city of any size. Like I said, I'm not sure you'd ever get the evaporation rate up high enough to be viable.
Not even then. It's only valid when either all the laws are common sense or the number of laws is sufficiently small that a reasonable person can avoid being ignorant of them.
Without those limits on the law, you end up in a society where lawyers run the world, and everybody is constantly having to run everything by their lawyers before they even have a simple conversation in public. We're rapidly approaching that point, assuming we aren't already way past it.
Neither you nor the article provide any such facts. The facts merely show that the number of people who voted is greater, not that there was no increase in the percentage of legitimate voters who were turned away and gave up on voting. Any claim that the former proves the latter is a non sequitur (unless 100% of the public attempts to vote). To actually prove that suppression did not occur, you would need, at minimum:
It is remarkably hard to gather that second piece of information accurately, but without it, any claims that voter suppression did not happen are nothing more than ordinary opinions with no factual support whatsoever.
Put another way, your argument based on totals is equivalent to saying that the population of the United States is increasing, so the percentage of people who die in any given year must have gone down. While the latter is probably true because people are living longer, it does not follow from the first statement. The population can also grow if more people choose to have kids, if people choose to have more kids, or if more immigrants are allowed into this country. In fact, the population could grow even if the annual death rate increases, so long as the number of additional kids exceeds the additional death rate.
Similarly, an increase in the number of voters just means that more people chose to vote. If there are a hundred voters and five are dissuaded from voting by the hassle, then 5% of voters were suppressed, but 95 people voted. If in the following election, 150 people decide to vote, but stricter laws make it more of a hassle, and fifteen are dissuaded, then 10% of voters were suppressed, but 135 people voted. We would say that voter suppression increased even though the number of total voters also increased. The two statements are not contradictory.
But to get back on topic, I don't have a lot of sympathy for the DOD and the rest of the federal government. The decline of Blackberry has been steady and consistent for the past several years. If this is coming as a surprise to them—if they have not already taken steps to encourage adoption of other platforms—then they are incredibly shortsighted, and deserve whatever pain the transition causes them.
That's exactly what I was wondering. I've always thought it would be cool to build a giant floating greenhouse, with water running down the sloped ceiling sections into catch basins that slowly slope downhill towards shore and eventually become pipes flowing downhill to a fully enclosed reservoir with a pumping station—a completely passive desalinization plant. I'm not sure you'd ever get the evaporation rate up high enough to be viable, but it would look awesome. :-)
And by Apple 3.5" disks, I mean 400k or 800k. The 1.44 MB format was the same as it is on PCs.
USB floppy drives should work just fine, assuming they comply with the UFI spec. Those drives won't read Apple 3.5" disks, though, because AFAIK none of the USB floppy drives support GCR.
Not at all. I've built and installed drivers that aren't part of the kernel source tree on several occasions. The entire driver stack has to be part of the kernel, by necessity, but not the drivers themselves.
IMO, the Linux kernel should pull all of the drivers out of the kernel source tree and into separate projects so that they can be separately maintained. The "everything in the kernel project" model means that every fix to every driver is dependent upon the upstream maintainers taking the changes. That's a maintenance nightmare.
The next phase is almost always to replace the technology or some portion thereof with something that does the same thing, but in a better or easier to use way.
With TeX, the logical next step is HTML/CSS typesetting. I'm pretty sure you could replicate most of the interesting parts of LaTeX in only a few thousand lines of JavaScript, assuming you had a browser that supports most of CSS3, but you'd also get lots of stuff that LaTeX can't handle.
With Linux as a whole, the logical next step is to repeatedly shoot X11 in the head until it stays down, then build something modern to replace it. Possibly replace it with Wayland—hard to say.
Down at the kernel level, the next logical step is to reduce the over-reliance on unreliable device names. Compared with OS X, the hot plug configuration story seems downright miserable to me. Device node names in the filesystem change, Ethernet interface names change depending on what order stuff gets plugged in, and so on, and the only way to fix this involves creating cryptic configuration files that try to pin devices in position. Blech. Those names shouldn't matter; if they do, you're doing it wrong.
Basically, Linux needs to do something similar to OS X's kextd and I/O Kit frameworks. Start by working up a standard API for walking the device tree, searching for devices that match against specific criteria, and returning a usable reference to that device (e.g. an open file descriptor). Then, create network configuration tools that use that matching system to identify the interface and configure it appropriately using a configuration dictionary. Then the next logical step is to load drivers based on those matching dictionaries. And then you have something approaching a usable driver loading system.