"Personally I felt rather confined in some Eruopean and Japanese 4-door sedans (& my first car was a nissan sentra and I didn't feel that way then) when I last looked at getting a new car."
Try a four door hatchback (I guess they call them "five door"), like the Toyota Echo/Yaris. I'm not sure if they sold those (the hatchback model) in the US or just Canada (where they're the best selling car on the market), but they're pretty comfortable due to the form factor. I remember that my friend had an Echo hatchback and a Ford station wagon a few years ago; the station wagon dwarfed the Echo, but felt cramped with barely any legroom in the back, while the hatchback felt spacious with much more legroom.
I was thinking of the Pontiac Trans Sport, actually, but upon checking wikipedia, it seems it was plastic body panels and not fibreglass. Apparently many of Saturn's cars also used plastic.
You can buy a 50+ MPG sedan today; the Toyota Prius is rated at 50 US MPG by the EPA, and 60.3 US MPG by the UK. It seems to be doing pretty well these days, with sales up at 400k cars a year at this point. I suspect the cost is one of the major things holding back higher sales. If 400k people a year are willing to pay $26k USD for a Prius, imagine how many people would be willing to pay $16k USD for a 50 US MPG car?
It even says that you can store the source and object code on different servers, and that you do not need to require recipients to copy the source along with the object code.
Right, but my point was that the availability of the source wasn't enough if there was no offer. The offer is the crucial part that enables the binaries to be distributed without the source.
I seem to remember some mass market minivan that had a fibreglass body... It's not an insurmountable problem.
Yes, they'll need to spend money to do it, but how is that different from any other R&D to advance your product? There are also other ways to improve efficiency, although they may not necessarily be cheaper. Hybrids, for example. There are also different kinds of hybrids. I believe some pickup truck models were using mechanical storage to recover energy from breaking or going downhill to improve mileage without the large cost of a battery-powered system.
And since this isn't even about improving the efficiency of any one car, but the average of the fleet, the average can be bumped up by discontinuing some of the lowest mileage vehicles. Phasing out huge SUVs like the hummer series helped, for example.
Sure they did (violate the GPL). You're still required to provide an offer of source, and to provide it when requested per that offer. They weren't doing that (providing the source when requested), unintentionally or not. That's copyright infringement.
It also ignores the eShop, where there are many App-store priced games. Of course, most of them seem to be complete crap, but there are some gems in there that cost way less than $30.
The circlepad is probably the best analog control stick that I've seen in any handheld to date. It was a bit stiff at first, but after loosening up, I find it on par in terms of usability with the analog sticks on a PS3 or 360 controller.
I know it doesn't make up for it (the 3DS battery life really does suck), but here's a tip.
The 3DS uses the same power cable as the DSi. It works with DSi to USB power cables (which can be bought from DealExtreme for next to nothing). It can be used with any USB-based cellphone battery pack.
Personally, I've got a Tekkeon MP1550 (4xAA), which works great with my 3DS, but any portable USB power source would do. I'll admit that this was mostly convenient because I *already* carried around the MP1550 for my smartphone, though, so except for a small retractable cable, I didn't really have to carry anything extra around to get more play time out of my 3DS.
Lets be fair, Apple has had third-party developers (1976) six years longer than Nintendo has (1985). I know how popular it is to hate on Apple, but it should be remembered that it wasn't even possible to do "home development" on anything the general public could afford until Woz came up with the Apple I. Sure, there was stuff like the Altair 8800 that was useful for general purpose stuff... But when you include the cost of the relevant hardware and a teletype terminal, you were looking at what would be ~$10k in 2010 dollars.
There are other options. The Sony Ericsson Xperia Play, for example, has a pretty decent set of controls. The play of the buttons is very shallow, but since it's a playstation standard layout, it feels pretty good.
There are also add-ons. Some apps (even ones in the marketplace or iOS app store) support bluetooth game controllers, including the iControlPad, a sort of strap-on control pad for iOS or android smartphones.
Not quite. You basically have two options (simplifying here, and this goes for v2 or v3):
1) Include the source 2) Include an offer to provide the source
Merely publishing the source somewhere isn't enough, and you can't just reactively provide the source when requested. If you don't want to include the source with the binaries, you have to include the offer with the binaries instead.
The damages are lower for unintentional copyright infringement, but yes, they can be sued. Just because you break the law unintentionally doesn't mean you still haven't broken the law.
That's only relevant if KSplice had actually done this for any small distro. They provided it for Red Hat, Cent OS, Debian, Ubuntu, Fedora, and CloudLinux. The only one there that could perhaps be considered small is CloudLinux (doesn't even have a wikipedia article), but it's backed by a company too.
It doesn't sound to me like support is being dropped for any distro that couldn't afford to do this themselves.
We can fix a buggy os, we cannot fix a buggy firmware.
You can't. When you let the SSD's controller take care of it, any OS you might run on it will get a unified interface, and that controller will manage the entire drive. If you want the OS to handle it, you need to have a strict management standard that all operating systems, including those like Windows, equally support. If there's something wrong with the standard or the implementation of the standard for a closed-source OS, you may not even be able to fix the problem in open-source OS for fear of breaking things in other operating systems. It would be a huge mess.
With the myriad of different chipsets having similar but ever so slightly different functions that the linux kernel supports... you think supporting different types of flash will be completely beyond it? seriously?
Of course. What makes more sense for a vendor to do, implement their algorithms in firmware such that all operating systems are supported, or write drivers for every OS under the sun? Linux is virtually irrelevant in the markets that many SSD vendors are targeting.
Not particularly... Foreign banks like the Federal Reserve might have questionable practices that make it important for Americans to know how it works, but the Bank of Canada has given Canadians little cause to bone up on the inner workings of our banking system. It does a pretty good job.
I don't see how the federal reserve could have given out 16 trillion in secret loans when that represents more than five times the total assets of the federal reserve... Am I missing something? The GAO's report never mentions this figure.
Yes, but what matters is how much you write to the drive in general, not one specific partition. My point was that even if your system partition is almost never written to on an SSD, you can still wear out the SSD (and the system partition, since the SSD doesn't have any concept of partitions) by writing data elsewhere.
I get that you're saying that reducing the writes to the system partition benefits the drive in general by reducing writes, I'm just cautioning that the SSD doesn't see it as a reduction in writes to a specific partition but to the entire drive because it spreads writes over the whole drive anyhow.
Yup.. as low as 10,000 cycles for multi-level flash, and 100,000 cycles for single-level flash
10k was for the MLC used in early SSDs. Intel claims 3,000 cycles for their 25nm flash. Toshiba seems to claim 1,400 for their 32nm MLC, but that might be a misinterpretation.
Good thing the Momentus XT isn't an SSD, then. It's a regular disk that uses a small amount of flash for read (and only read) caching. Writes (which are the problem here) aren't even touching the flash.
Buggy OS, buggy controller firmware, the problem isn't going to go away just because you shift the problem from one piece of software to another.
Besides that, flash is too varied for an OS to throw a one-size-fits-all at it. There are many different kinds of flash out there, and even different chips of the same kind can behave pretty differently.
Moreover, the system partition is not written to very often, thus it should take longer to wear out.
That's now how SSDs work. Like most modern flash devices, they do wear leveling. They have no knowledge of the underlying partitions or filesystem structures. There is no physical "beginning" of the disk, data is written to random locations determined by the wear leveling algorithm, and the controller maps between the logical linear block layout to the in practice random data locations.
If you take an empty SSD and you overwrite the same location on the disk over and over and over again, the SSD isn't going to overwrite the same page, it's going to do its damnedest to spread those writes out over the entire disk.
Sure, but the scales are completely different. Current flash chips can maintain information for years before leakage becomes a problem, while DRAM typically refreshes the data every 64ms or less. We're talking about 10 orders of magnitude difference here.
The user who posted about read disturbs and ecc sounds like he's actually read a few journal articles about flash design.
You don't need to read journal articles about flash design to know that write (erase, really) endurance drops every time there's a die shrink. Tech sites like Anandtech already report on that sort of stuff. The only reason it's not causing issues is because, as that user pointed out, we're throwing more and more error correction at it, and the higher densities we get from die shrinks mean writes are often spread out more (capacity tends to increase faster than write load).
Slashdot Mirror
"Personally I felt rather confined in some Eruopean and Japanese 4-door sedans (& my first car was a nissan sentra and I didn't feel that way then) when I last looked at getting a new car."
Try a four door hatchback (I guess they call them "five door"), like the Toyota Echo/Yaris. I'm not sure if they sold those (the hatchback model) in the US or just Canada (where they're the best selling car on the market), but they're pretty comfortable due to the form factor. I remember that my friend had an Echo hatchback and a Ford station wagon a few years ago; the station wagon dwarfed the Echo, but felt cramped with barely any legroom in the back, while the hatchback felt spacious with much more legroom.
I was thinking of the Pontiac Trans Sport, actually, but upon checking wikipedia, it seems it was plastic body panels and not fibreglass. Apparently many of Saturn's cars also used plastic.
You can buy a 50+ MPG sedan today; the Toyota Prius is rated at 50 US MPG by the EPA, and 60.3 US MPG by the UK. It seems to be doing pretty well these days, with sales up at 400k cars a year at this point. I suspect the cost is one of the major things holding back higher sales. If 400k people a year are willing to pay $26k USD for a Prius, imagine how many people would be willing to pay $16k USD for a 50 US MPG car?
It even says that you can store the source and object code on different servers, and that you do not need to require recipients to copy the source along with the object code.
Right, but my point was that the availability of the source wasn't enough if there was no offer. The offer is the crucial part that enables the binaries to be distributed without the source.
I seem to remember some mass market minivan that had a fibreglass body... It's not an insurmountable problem.
Yes, they'll need to spend money to do it, but how is that different from any other R&D to advance your product? There are also other ways to improve efficiency, although they may not necessarily be cheaper. Hybrids, for example. There are also different kinds of hybrids. I believe some pickup truck models were using mechanical storage to recover energy from breaking or going downhill to improve mileage without the large cost of a battery-powered system.
And since this isn't even about improving the efficiency of any one car, but the average of the fleet, the average can be bumped up by discontinuing some of the lowest mileage vehicles. Phasing out huge SUVs like the hummer series helped, for example.
Sure they did (violate the GPL). You're still required to provide an offer of source, and to provide it when requested per that offer. They weren't doing that (providing the source when requested), unintentionally or not. That's copyright infringement.
It also ignores the eShop, where there are many App-store priced games. Of course, most of them seem to be complete crap, but there are some gems in there that cost way less than $30.
The circlepad is probably the best analog control stick that I've seen in any handheld to date. It was a bit stiff at first, but after loosening up, I find it on par in terms of usability with the analog sticks on a PS3 or 360 controller.
I know it doesn't make up for it (the 3DS battery life really does suck), but here's a tip.
The 3DS uses the same power cable as the DSi. It works with DSi to USB power cables (which can be bought from DealExtreme for next to nothing). It can be used with any USB-based cellphone battery pack.
Personally, I've got a Tekkeon MP1550 (4xAA), which works great with my 3DS, but any portable USB power source would do. I'll admit that this was mostly convenient because I *already* carried around the MP1550 for my smartphone, though, so except for a small retractable cable, I didn't really have to carry anything extra around to get more play time out of my 3DS.
Lets be fair, Apple has had third-party developers (1976) six years longer than Nintendo has (1985). I know how popular it is to hate on Apple, but it should be remembered that it wasn't even possible to do "home development" on anything the general public could afford until Woz came up with the Apple I. Sure, there was stuff like the Altair 8800 that was useful for general purpose stuff... But when you include the cost of the relevant hardware and a teletype terminal, you were looking at what would be ~$10k in 2010 dollars.
There are other options. The Sony Ericsson Xperia Play, for example, has a pretty decent set of controls. The play of the buttons is very shallow, but since it's a playstation standard layout, it feels pretty good.
There are also add-ons. Some apps (even ones in the marketplace or iOS app store) support bluetooth game controllers, including the iControlPad, a sort of strap-on control pad for iOS or android smartphones.
Not quite. You basically have two options (simplifying here, and this goes for v2 or v3):
1) Include the source
2) Include an offer to provide the source
Merely publishing the source somewhere isn't enough, and you can't just reactively provide the source when requested. If you don't want to include the source with the binaries, you have to include the offer with the binaries instead.
Can they be sued for this or something?
The damages are lower for unintentional copyright infringement, but yes, they can be sued. Just because you break the law unintentionally doesn't mean you still haven't broken the law.
Conclusion seems to be "light cannot exceed the speed of light"...
That's only relevant if KSplice had actually done this for any small distro. They provided it for Red Hat, Cent OS, Debian, Ubuntu, Fedora, and CloudLinux. The only one there that could perhaps be considered small is CloudLinux (doesn't even have a wikipedia article), but it's backed by a company too.
It doesn't sound to me like support is being dropped for any distro that couldn't afford to do this themselves.
We can fix a buggy os, we cannot fix a buggy firmware.
You can't. When you let the SSD's controller take care of it, any OS you might run on it will get a unified interface, and that controller will manage the entire drive. If you want the OS to handle it, you need to have a strict management standard that all operating systems, including those like Windows, equally support. If there's something wrong with the standard or the implementation of the standard for a closed-source OS, you may not even be able to fix the problem in open-source OS for fear of breaking things in other operating systems. It would be a huge mess.
With the myriad of different chipsets having similar but ever so slightly different functions that the linux kernel supports... you think supporting different types of flash will be completely beyond it? seriously?
Of course. What makes more sense for a vendor to do, implement their algorithms in firmware such that all operating systems are supported, or write drivers for every OS under the sun? Linux is virtually irrelevant in the markets that many SSD vendors are targeting.
Not particularly... Foreign banks like the Federal Reserve might have questionable practices that make it important for Americans to know how it works, but the Bank of Canada has given Canadians little cause to bone up on the inner workings of our banking system. It does a pretty good job.
I don't see how the federal reserve could have given out 16 trillion in secret loans when that represents more than five times the total assets of the federal reserve... Am I missing something? The GAO's report never mentions this figure.
Yes, but what matters is how much you write to the drive in general, not one specific partition. My point was that even if your system partition is almost never written to on an SSD, you can still wear out the SSD (and the system partition, since the SSD doesn't have any concept of partitions) by writing data elsewhere.
I get that you're saying that reducing the writes to the system partition benefits the drive in general by reducing writes, I'm just cautioning that the SSD doesn't see it as a reduction in writes to a specific partition but to the entire drive because it spreads writes over the whole drive anyhow.
Yup.. as low as 10,000 cycles for multi-level flash, and 100,000 cycles for single-level flash
10k was for the MLC used in early SSDs. Intel claims 3,000 cycles for their 25nm flash. Toshiba seems to claim 1,400 for their 32nm MLC, but that might be a misinterpretation.
Good thing the Momentus XT isn't an SSD, then. It's a regular disk that uses a small amount of flash for read (and only read) caching. Writes (which are the problem here) aren't even touching the flash.
Buggy OS, buggy controller firmware, the problem isn't going to go away just because you shift the problem from one piece of software to another.
Besides that, flash is too varied for an OS to throw a one-size-fits-all at it. There are many different kinds of flash out there, and even different chips of the same kind can behave pretty differently.
Moreover, the system partition is not written to very often, thus it should take longer to wear out.
That's now how SSDs work. Like most modern flash devices, they do wear leveling. They have no knowledge of the underlying partitions or filesystem structures. There is no physical "beginning" of the disk, data is written to random locations determined by the wear leveling algorithm, and the controller maps between the logical linear block layout to the in practice random data locations.
If you take an empty SSD and you overwrite the same location on the disk over and over and over again, the SSD isn't going to overwrite the same page, it's going to do its damnedest to spread those writes out over the entire disk.
Sure, but the scales are completely different. Current flash chips can maintain information for years before leakage becomes a problem, while DRAM typically refreshes the data every 64ms or less. We're talking about 10 orders of magnitude difference here.
The user who posted about read disturbs and ecc sounds like he's actually read a few journal articles about flash design.
You don't need to read journal articles about flash design to know that write (erase, really) endurance drops every time there's a die shrink. Tech sites like Anandtech already report on that sort of stuff. The only reason it's not causing issues is because, as that user pointed out, we're throwing more and more error correction at it, and the higher densities we get from die shrinks mean writes are often spread out more (capacity tends to increase faster than write load).