Then what you want is the Apple I Replica Creation book. The point of the article was that even someone who doesn't know how to solder at the beginning can, with a little help, build a functional replica using the full kit, and therefore learn skills they can later use for a more complicated project while having something cool to show off and feel proud of. If you've got the skills to hack away starting at the PCB instead, that's an option too, but it's a bit unreasonable to expect that beginners to this area (which include just about all the kids who wander past my lawn) are going to start there.
It's ALSA+Jack, but he's using an Olympus LS-10 digital recorder and then moving the recorded files over to the Linux system via a SDHC card. So basically he's avoiding all of the hard problems here altogether--there is no professional digital audio adapter involved. I know people who have more complicated real-time musical workflow requirements for playing Guitar Hero than this guy,
Just because you do pay for something that doesn't mean it's automatically reliable either. Your odds of a hard drive crash in a given year are a few percent; if you're relying on electronic medical information, that will leave you just as vulnerable to not having it available when you need it as if Google's service isn't up for some window of time. Hardware and software fail, files get corrupted, and services become unavailable; all you can do is compare the statistical likelihood of your data not being around at a given time. Whether Google's service is on average more or less reliable than a local one is pretty complicated to determine if you fairly account for all the ways even a locally hosted system can die.
You can't turn fsync into a complete noop just by putting a cache in the middle. A fsync call on the OS side that forces that write out to cache will block if the BBWC is full for example, and if the underlying device can't write fast enough without its own cache being turned on you'll still be in trouble.
While the cache in the middle will improve the situation by coalescing writes into the form the SSD can handle efficiently, the published SSD write IOPS numbers are still quite inflated relative to what you'll actually see. What I was trying to suggest is that the performance gap isn't nearly as large as suggested by the article of TFA once you start building real-world systems around them. After all, regular discs benefit from the write combining to lower seeks you get out of a BBWC, too, even more than the SSDs do.
The other funny thing you discover if you benchmark enough of these things is that a regular hard drive confined to only use as much space as a SSD provides is quite a bit faster too. When you limit a 500GB SATA drive to only use 64GB (a standard bit of short stroking), there's a big improvement in sequential and seek speeds there. If you want to be fair, you should only compare your hard drive's IOPS when it's configured to only provide as much space as the SSD you're comparing against.
There may need to be some minor rethinking of controller throughput for read applications on smaller data sets for SSD. But right now, I regularly saturate the controller or bus when running sequential RW tests against a large number of physical drives in a RAID{1}0 array, so it's not like that's anything new. Using SSD just makes it more likely that will happen even on random workloads.
There are two major problems with this analysis though. The first is that it presumes SSD will be large enough for the sorts of workloads people with RAID controllers encounter. While there are certainly people using such controllers to accelerate small data sets, you'll find just as many people who are using RAID to handle large amounts of data. Right now, if you've got terabytes of stuff, it's just not practical to use SSD yet. For example, I do database work for living, and the only place we're using SSD right now is for holding indexes. None of the data can fit, and the data growth volume is such that I don't even expect SSDs to ever catch up--hard drives are just keeping up with the pace of data growth.
The second problem is that SSDs rely on volatile write caches in order to achieve their stated write performance, which is just plain not acceptable for enterprise applications where honoring fsync is important, like all database ones. You end up with disk corruption if there's a crash, and as you can see in that article once everything was switched to only relying on non-volatile cache the performance of the SSD wasn't that much better than the RAID 10 system under test. The write IOPS claims of Intel's SSD products are garbage if you care about honoring write guarantees, which means it's not that hard to keep with them after all on the write side in a serious application.
The expected value of any given idea is basically zero, because the odds of it turning out to be worth any money is extremely low. The fact that there exist the occasional idea worth real money does not change the odds, just the payout. To say that another way, if only one in ten million ideas is a $10M one like you describe, that still makes the average value of an idea only $1. And the odds of someone who doesn't really understand how things work coming up with a unique idea worth real money are likely far worse than 1 in 10M, which is why "nearly worthless" is the expected value of any random idea.
There are a couple of presentations, perhaps including the one you allude to, as well as other answers to this question all right where you'd expect them to be: pair programming.
The Wii is by far the worst platform for playing Rock Band 2. Just the most obvious points:
Because of the lack of hard drive, can't assimilate content from other RB titles into the game--can't even play the Wii RB1 song
Downloadable content is still a small fraction of what's available for the other platforms, and since there's no bundles available on the Wii it costs far more to purchase a large library of songs from favorite artists.
The instrument compatibility situation is a disaster. Check out the instrument compatibility matrix, and note that for the most part you'll need to a buy a whole second set of instruments if you also want to play the Guitar Hero band games too--the cross-game situations is much better on the other consoles. The compatibility is better for guitars if you have the right ones, complete mess for drums on the Wii no matter what you buy (and those are of course the last thing you want two sets of!)
Video quality is awful, particularly if you have large hi-def TV. You can have three clear instrument tracks on a big screen on the other platforms, there's just not enough resolution for it to look right available on the Wii.
Wii song downloads are more tightly bound to a single console than on other platforms.
If you've already got a Wii, want a fairly cheap solution, and don't plan to buy very much downloadable content, RB2 for the Wii might still make sense for you anyway. But it's a very poor platform if you expect a great RB2 experience.
The problem with building a power supply is that when you make a mistake, things tend to blow up. I speak from high-school experience doing that back in the day. Much safer to build things that run off batteries.
While you don't need smartmontools, they do still work, which can be helpful in a mixed environment where not every system has all 3ware drives in it. In many situations it's easier for me to tie smartmontools into a larger monitoring infrastructure than making a special case for using the 3ware specific tools. This is why Areca's poor support here is particularly unwelcome, on top of their command line tool being a bit shoddy.
All of my server deployments are on Linux, and after suffering for many years with awful Linux drivers from Adaptec I just gave up on them altogether some time ago (around 2002 I banned them altogether from my systems). It looks like they may have recently released products that work OK with that operating system, judging from things like Smartmontools and Adaptec RAID controllers where controllers that have basic SMART support are mentioned as finally available. From the perspective of a Linux admin, I would dispute that Adaptec has been "the way to go for the last 20 years"--there's at least a 5 year period there where Adaptec's Linux drivers were so awful that you had to use alternate vendors like 3ware if you wanted good support.
I have decidedly mixed feelings about Areca's controllers as well. The performance has been good, but the management situation has been awful. I wrote about some of my problems that popped up after the first time I lost a drive on my blog. If you get one of the cards that uses the network management port as the UI for doing things, supposedly that's better than what I went through, but that still makes for a painful monitoring stack. Compare to the 3ware cards I've been using recently, where it only took a couple of minutes to setup smartmontools to watch the drive health and I moved on.
Obviously the only sensible robust solutions to this problem are either LaTeX or Docbook. The main problem with both of those is they're kind of painful to author. What I've switched to for any quick documents I write is reST. It's easy to learn for quick documents, you can edit with just about anything (its rudimentary tables support is best handled with emacs), includes features like footnotes, and is easy to render into HTML and PDF. After a few months of writing docs for some projects I work on in reST, I've found myself even writing all my random notes in that form, so that I can generated nicely printed versions of them at any time.
Btrfs includes support for TRIM on SSD, but that's a secondary addition. The main purpose of Btrfs is to compete against Sun's ZFS in the area of robust fault tolerance. If you look at the original announcement, you can see SSD support wasn't on the radar at all; that's strictly been an afterthought in the design. Btrfs is absolutely designed to work on SATA drives and to compete head to head against ext3/ext4.
You meant pckeyboard.com, which makes you doubly wrong--those keyboard are a sad imitation of a true Model M. Lexmark started decreasing the quality of the parts in their keyboards to cut costs in 1995, and the Unicomp models continue in that sad direction. Nothing you can buy today compares to a 1994 or earlier Model M.
The whole premise that better usability will come out of getting usability designers involved in the free software development process is fundamentally misguided. It's really easy to get such feedback for most open source software. Just look at the forums and mailing list of people using the software, and it's trivial to find out exactly what are the confusing parts and what really needs to be improved. As for motivating improvements, most developers working on open-source software want their software to be better. But what does "better" mean?
The problem is that the developers working on the software don't use it the way everybody else does, which means there will always be a clash between their priorities and tastes and what regular users want. This means the people capable of fixing the usability problem believe many requests are misguided, and therefore don't do anything about them. I see this all the time, in projects big and small. On the open source project I contribute the most to, PostgreSQL, some of this disconnect is warranted. For example, users want the software to be super easy to use out of the box, while developers want it to be secure out of the box; that's a very hard split to reconcile. Sometimes instead you'll see features requested by DBAs that make perfect sense to other DBAs, but are shouted down as a bad idea too. This is because many of the most influential developers are not DBAs of large databases, which you'd expect almost by definition. They don't have the right context to fully appreciate some usability decisions. If the development community is healthy, when enough such requests come in eventually some concessions will get made, even if some of the developers don't quite get the motivating reason fully. Enough people complain about something, you just accept that's what everybody wants and bow to community pressure.
But there are plenty of communities where this doesn't seem to happen, and usually it's due to arrogance on the part of the developer rather than them not having design feedback. A classic example was last year's Pidgin UI disaster. Look at that ticket--the entirety of the user community was lined up against the developers, and the lack of response to that feedback even forced a fork whose tagline was "we work for you" as a noteworthy difference from the original project. Completely ridiculous.
I'm suffering from a similar bit of developer arrogance right now, with the standard GNOME terminal app. A change was made recently, first showing up on a lot of people's desktops via Ubuntu Jaunty, which reduces the ability to overload common function keys (like control-C) to either execute terminal functions (like "copy") and still work as terminal input if no text to copy has been selected. There's been a stack ofbug reporters, and it turns out the only reason for the change was the developer thought it was a bug--there were no user complaints driving the change. The only right response in this situation, which is strictly a UI decision, is to man up, admit the change was wrong and you were wrong for thinking it, and thank your community for pointing it out. As you can see, that's certainly not happening here. (Yes, I can fix it myself. Not, that doesn't matter, because the thing I'm annoyed about is that it's a step backwards on the most popular default terminal people new to Linux use, which hurts the OS as a whole.)
You can collect usability data all day, that's easy. Doesn't take a designer, it just takes listening to your users. From where I'm sitting it looks like the hard problem is getting open-source developers to pay attention to what they're saying.
Slashdot Mirror
Then what you want is the Apple I Replica Creation book. The point of the article was that even someone who doesn't know how to solder at the beginning can, with a little help, build a functional replica using the full kit, and therefore learn skills they can later use for a more complicated project while having something cool to show off and feel proud of. If you've got the skills to hack away starting at the PCB instead, that's an option too, but it's a bit unreasonable to expect that beginners to this area (which include just about all the kids who wander past my lawn) are going to start there.
It's true, there was a news report on it recently.
It's ALSA+Jack, but he's using an Olympus LS-10 digital recorder and then moving the recorded files over to the Linux system via a SDHC card. So basically he's avoiding all of the hard problems here altogether--there is no professional digital audio adapter involved. I know people who have more complicated real-time musical workflow requirements for playing Guitar Hero than this guy,
Just because you do pay for something that doesn't mean it's automatically reliable either. Your odds of a hard drive crash in a given year are a few percent; if you're relying on electronic medical information, that will leave you just as vulnerable to not having it available when you need it as if Google's service isn't up for some window of time. Hardware and software fail, files get corrupted, and services become unavailable; all you can do is compare the statistical likelihood of your data not being around at a given time. Whether Google's service is on average more or less reliable than a local one is pretty complicated to determine if you fairly account for all the ways even a locally hosted system can die.
"How'd I end up in jail that night? That line I needed, it just wouldn't come"
Bug juice has a proud military history and is Disney approved.
Glad to see the blue M&Ms won't be going the way the red ones did in 1976.
You can't turn fsync into a complete noop just by putting a cache in the middle. A fsync call on the OS side that forces that write out to cache will block if the BBWC is full for example, and if the underlying device can't write fast enough without its own cache being turned on you'll still be in trouble.
While the cache in the middle will improve the situation by coalescing writes into the form the SSD can handle efficiently, the published SSD write IOPS numbers are still quite inflated relative to what you'll actually see. What I was trying to suggest is that the performance gap isn't nearly as large as suggested by the article of TFA once you start building real-world systems around them. After all, regular discs benefit from the write combining to lower seeks you get out of a BBWC, too, even more than the SSDs do.
The other funny thing you discover if you benchmark enough of these things is that a regular hard drive confined to only use as much space as a SSD provides is quite a bit faster too. When you limit a 500GB SATA drive to only use 64GB (a standard bit of short stroking), there's a big improvement in sequential and seek speeds there. If you want to be fair, you should only compare your hard drive's IOPS when it's configured to only provide as much space as the SSD you're comparing against.
There may need to be some minor rethinking of controller throughput for read applications on smaller data sets for SSD. But right now, I regularly saturate the controller or bus when running sequential RW tests against a large number of physical drives in a RAID{1}0 array, so it's not like that's anything new. Using SSD just makes it more likely that will happen even on random workloads.
There are two major problems with this analysis though. The first is that it presumes SSD will be large enough for the sorts of workloads people with RAID controllers encounter. While there are certainly people using such controllers to accelerate small data sets, you'll find just as many people who are using RAID to handle large amounts of data. Right now, if you've got terabytes of stuff, it's just not practical to use SSD yet. For example, I do database work for living, and the only place we're using SSD right now is for holding indexes. None of the data can fit, and the data growth volume is such that I don't even expect SSDs to ever catch up--hard drives are just keeping up with the pace of data growth.
The second problem is that SSDs rely on volatile write caches in order to achieve their stated write performance, which is just plain not acceptable for enterprise applications where honoring fsync is important, like all database ones. You end up with disk corruption if there's a crash, and as you can see in that article once everything was switched to only relying on non-volatile cache the performance of the SSD wasn't that much better than the RAID 10 system under test. The write IOPS claims of Intel's SSD products are garbage if you care about honoring write guarantees, which means it's not that hard to keep with them after all on the write side in a serious application.
If he were a real geek, he'd be heating up the hot pockets on his CPU cooler, to leach away some BTUs so he could overclock harder.
The expected value of any given idea is basically zero, because the odds of it turning out to be worth any money is extremely low. The fact that there exist the occasional idea worth real money does not change the odds, just the payout. To say that another way, if only one in ten million ideas is a $10M one like you describe, that still makes the average value of an idea only $1. And the odds of someone who doesn't really understand how things work coming up with a unique idea worth real money are likely far worse than 1 in 10M, which is why "nearly worthless" is the expected value of any random idea.
There are a couple of presentations, perhaps including the one you allude to, as well as other answers to this question all right where you'd expect them to be: pair programming.
That would be very limiting, because you can't write a successful programming language without facial hair
The Wii is by far the worst platform for playing Rock Band 2. Just the most obvious points:
Downloadable content is still a small fraction of what's available for the other platforms, and since there's no bundles available on the Wii it costs far more to purchase a large library of songs from favorite artists.
Video quality is awful, particularly if you have large hi-def TV. You can have three clear instrument tracks on a big screen on the other platforms, there's just not enough resolution for it to look right available on the Wii.
If you've already got a Wii, want a fairly cheap solution, and don't plan to buy very much downloadable content, RB2 for the Wii might still make sense for you anyway. But it's a very poor platform if you expect a great RB2 experience.
The problem with building a power supply is that when you make a mistake, things tend to blow up. I speak from high-school experience doing that back in the day. Much safer to build things that run off batteries.
It seems that the APA is the latest group that needs to do some reading on why security through obscurity just doesn't work.
While you don't need smartmontools, they do still work, which can be helpful in a mixed environment where not every system has all 3ware drives in it. In many situations it's easier for me to tie smartmontools into a larger monitoring infrastructure than making a special case for using the 3ware specific tools. This is why Areca's poor support here is particularly unwelcome, on top of their command line tool being a bit shoddy.
All of my server deployments are on Linux, and after suffering for many years with awful Linux drivers from Adaptec I just gave up on them altogether some time ago (around 2002 I banned them altogether from my systems). It looks like they may have recently released products that work OK with that operating system, judging from things like Smartmontools and Adaptec RAID controllers where controllers that have basic SMART support are mentioned as finally available. From the perspective of a Linux admin, I would dispute that Adaptec has been "the way to go for the last 20 years"--there's at least a 5 year period there where Adaptec's Linux drivers were so awful that you had to use alternate vendors like 3ware if you wanted good support.
I have decidedly mixed feelings about Areca's controllers as well. The performance has been good, but the management situation has been awful. I wrote about some of my problems that popped up after the first time I lost a drive on my blog. If you get one of the cards that uses the network management port as the UI for doing things, supposedly that's better than what I went through, but that still makes for a painful monitoring stack. Compare to the 3ware cards I've been using recently, where it only took a couple of minutes to setup smartmontools to watch the drive health and I moved on.
It's broader than that--90% of everything is crud
Obviously the only sensible robust solutions to this problem are either LaTeX or Docbook. The main problem with both of those is they're kind of painful to author. What I've switched to for any quick documents I write is reST. It's easy to learn for quick documents, you can edit with just about anything (its rudimentary tables support is best handled with emacs), includes features like footnotes, and is easy to render into HTML and PDF. After a few months of writing docs for some projects I work on in reST, I've found myself even writing all my random notes in that form, so that I can generated nicely printed versions of them at any time.
Btrfs includes support for TRIM on SSD, but that's a secondary addition. The main purpose of Btrfs is to compete against Sun's ZFS in the area of robust fault tolerance. If you look at the original announcement, you can see SSD support wasn't on the radar at all; that's strictly been an afterthought in the design. Btrfs is absolutely designed to work on SATA drives and to compete head to head against ext3/ext4.
You meant pckeyboard.com, which makes you doubly wrong--those keyboard are a sad imitation of a true Model M. Lexmark started decreasing the quality of the parts in their keyboards to cut costs in 1995, and the Unicomp models continue in that sad direction. Nothing you can buy today compares to a 1994 or earlier Model M.
Oh, you got to prick yourself, did you? Luxury. We had to taunt someone enough that they stabbed us to get blood to write with.
The whole premise that better usability will come out of getting usability designers involved in the free software development process is fundamentally misguided. It's really easy to get such feedback for most open source software. Just look at the forums and mailing list of people using the software, and it's trivial to find out exactly what are the confusing parts and what really needs to be improved. As for motivating improvements, most developers working on open-source software want their software to be better. But what does "better" mean?
The problem is that the developers working on the software don't use it the way everybody else does, which means there will always be a clash between their priorities and tastes and what regular users want. This means the people capable of fixing the usability problem believe many requests are misguided, and therefore don't do anything about them. I see this all the time, in projects big and small. On the open source project I contribute the most to, PostgreSQL, some of this disconnect is warranted. For example, users want the software to be super easy to use out of the box, while developers want it to be secure out of the box; that's a very hard split to reconcile. Sometimes instead you'll see features requested by DBAs that make perfect sense to other DBAs, but are shouted down as a bad idea too. This is because many of the most influential developers are not DBAs of large databases, which you'd expect almost by definition. They don't have the right context to fully appreciate some usability decisions. If the development community is healthy, when enough such requests come in eventually some concessions will get made, even if some of the developers don't quite get the motivating reason fully. Enough people complain about something, you just accept that's what everybody wants and bow to community pressure.
But there are plenty of communities where this doesn't seem to happen, and usually it's due to arrogance on the part of the developer rather than them not having design feedback. A classic example was last year's Pidgin UI disaster. Look at that ticket--the entirety of the user community was lined up against the developers, and the lack of response to that feedback even forced a fork whose tagline was "we work for you" as a noteworthy difference from the original project. Completely ridiculous.
I'm suffering from a similar bit of developer arrogance right now, with the standard GNOME terminal app. A change was made recently, first showing up on a lot of people's desktops via Ubuntu Jaunty, which reduces the ability to overload common function keys (like control-C) to either execute terminal functions (like "copy") and still work as terminal input if no text to copy has been selected. There's been a stack of bug reporters, and it turns out the only reason for the change was the developer thought it was a bug--there were no user complaints driving the change. The only right response in this situation, which is strictly a UI decision, is to man up, admit the change was wrong and you were wrong for thinking it, and thank your community for pointing it out. As you can see, that's certainly not happening here. (Yes, I can fix it myself. Not, that doesn't matter, because the thing I'm annoyed about is that it's a step backwards on the most popular default terminal people new to Linux use, which hurts the OS as a whole.)
You can collect usability data all day, that's easy. Doesn't take a designer, it just takes listening to your users. From where I'm sitting it looks like the hard problem is getting open-source developers to pay attention to what they're saying.