http://en.wikipedia.org/wiki/S-VHS
Quote from wikipedia: "Despite its designation as the logical successor to VHS, S-VHS did not come close to replacing VHS. In the home market, S-VHS failed to gain significant market share; for various reasons, consumers were not interested in paying more for an improved picture. Likewise, S-VHS rentals and movie sales did very poorly."
I think what the industry failed to learn from S-VHS was that you need a true quantum leap to lure consumers away from an established standard media (be that DVD or VHS). Alternatively, if you can make it both compatible and equal in price or cheaper, people may eventually upgrade.
When Apple's Copland plans failed, they looked for outside help. Jean-Louis Gassée's Be Inc. was one of those possible sources. Steve Jobs was the one they eventually chose.
BeOS would have been more lightweight and probably more efficient, but OS X is maturing into something quite useable. The UNIX roots of OS X have helped lure new developers and new types of users to the platform. Having more developers is never a bad thing.
BeOS would also have been a cleaner start. It's difficult to say how much (or if) UNIX is holding back MacOS X. I find OS X somewhat bloated, especially in terms of the number of files that it is comprised of. I wish it took less time to make a backup.
BeOS is/was also advanced in terms of file meta data. That situation is still quite messy in MacOS X.
My 1GHz PowerMac boots into MacOS X in 17 seconds, so even "low end" machines now should be able to boot in around 15 seconds.
With that said, I do think that 15 seconds is "fast enough". That machine of mine had a "sleep disorder" due to a processor upgrade (it started out as a 500MHz machine) and I had to shut down and boot it instead of letting sleep. 17 seconds was actually still in the comfortable range.
I agree...It's really nice to see that at least someone seems to be headed in the right direction.
So, what if they made the first season of a show free, if broadcast in a regular "scheduled" way. If you don't want to bother with recording a scheduled show or you missed the first few episodes, you could buy what you missed for 25 cents/episode.
Then, start charging a bit more money for the second season and onwards and stop doing the free broadcasts (or do them a year later with commercials).
Finally, sell advertising space on the program guide/download catalog pages...and allow people to opt out of advertising by paying a monthly fee.
I hope they will understand "fair use", but I'm not too optimistic.
If old episodes are cheap and fast enough to download, would you bother with DVD-burning (except to take a few shows with you when you go camping or whatever)?
You are on the right track, but as you suspect, it's not quite that easy.
You can losslessly transform JPEGs with open source software from IJG so that the Huffman tables are optimized. I incorporated this into a Mac photography utility that I wrote, so I'm quite familiar with the effects.
Optimizing the Huffman tables for each image yields relatively small gains. The JPEG still decodes as fast as the original, so this is essentially a free lunch and worth doing every time you write a JPEG.
What's interesting is that a JPEG converted to progressive scan order will practically always be smaller than the non-progressive version. The downside is that decoding is slower (at least with the IJG decoder).
I think the Stuffit discovery is to do something fairly similar to the progressive scan trick. If you reorder the data cleverly, you'll find patterns that algorithms like LZW can compress or the set of values will be small enough so that you can improve on the Huffman compression ratios.
Here's an example using 2x2 blocks with values from 0-9 instead of the 8x8 (just to simplify things):
52 53 42 52 11 22 22 31
Reorder this to: 5545 2322 1223 1221
So each stream of coefficients looks more boring than the data in the original 2x2 blocks. To get better compression, you could simply use a new adaptive Huffman table for each stream.
The above example is just off the top of my head, so your actual mileage may vary.
In practice because I know that non-progressive JPEG draws a lot faster than progressive, I always ocnvert all my JPEGs into non-progressive versions. It's a lossless process though, so I would use this trick (along with the optimized Huffman tables) to fit a set of JPEGs into a limited amount of space (or to reduce bandwidth requirements).
As far as hard disk space is concerned, using progressive JPEG is not worth the extra CPU time to decode.
I think the "Technical Writing" part on that site is extremely valuable. It explains how the Inside Macintosh books were written and how that process affected the development of the MacOS APIs.
As far as technical documentation is concerned, the original Inside Macintosh books are still some of the best that I have ever read.
Each E-mail sent can optionally contain a micropayment, cryptographically tied to the receiver's E-mail address and the contents of the E-mail.
When I receive E-mails, I can choose to ignore or simply spam-filter any E-mails with a value of less than X (I decide what X is).
The default action is to return the micropayment to the sender, if nothing is done within a week (or a few days) of sending the E-mail. This way, sending payments to someone who is not part of the system will effectively be a no-op.
The receiver has several possibilities:
Ignore the payment (the sender eventually gets his deposit back)
Return the payment immediately
Collect the payment
The way I would use this would be to collect the payment on any unsolicited commercial E-mails that I read (thus making sending SPAM cost money) and return/ignore all the payments from friends & other valid sources.
You could still send E-mails with no monetary value, but they would be subject to strict filtering.
I would probably set a filter limit of 5-10 cents/E-mail and only collect the money (if any) on real spam.
The system would provide income to those who run the banking, because they would get the interest on the deposits made by E-mail users.
At first, implementing something like this would have little impact on our E-mailing, because only a few people would be using the system. If it ever became widely adapted, we would have an E-mail system where sending spam is too expensive to be worthwhile and where regular E-mail would still be free (except for the loss of interest on the deposit made to send micropaid E-mails).
While most of the articles on./ have concentrated on how evil RF tags can be, I think there are obviously good uses for them as well.
I hope that in the future I'll be able to buy an inexpensive RF tag scanner that has an adjustable range from maybe two meters to tens of centimeters. Also, I'll be able to buy generic RF tags with unique IDs and tag and catalog any items that I may want to find some day.
A database on my computer would allow me to search for stuff that I don't even remember getting and once I had a list of items I want to look for, I could load it up into the scanner and start walking around the house to find the items.
The advantage of this system is that you can pack things very tight into boxes and you don't open those boxes until you know that what you want is in there.
One step further from that, you'll have "room tags" in various places, so that when you do your search, the scanner also notes those and can update the "last known location" for all the items close to the room tag. So, if you carry that box with all the SDRAM DIMMs into the basement and you have your scanner with you (or built into your cell phone), the next time you look for those on your computer, your computer will know that they are in the basement.
Slashdot Mirror
http://en.wikipedia.org/wiki/S-VHS Quote from wikipedia: "Despite its designation as the logical successor to VHS, S-VHS did not come close to replacing VHS. In the home market, S-VHS failed to gain significant market share; for various reasons, consumers were not interested in paying more for an improved picture. Likewise, S-VHS rentals and movie sales did very poorly." I think what the industry failed to learn from S-VHS was that you need a true quantum leap to lure consumers away from an established standard media (be that DVD or VHS). Alternatively, if you can make it both compatible and equal in price or cheaper, people may eventually upgrade.
When Apple's Copland plans failed, they looked for outside help. Jean-Louis Gassée's Be Inc. was one of those possible sources. Steve Jobs was the one they eventually chose.
BeOS would have been more lightweight and probably more efficient, but OS X is maturing into something quite useable. The UNIX roots of OS X have helped lure new developers and new types of users to the platform. Having more developers is never a bad thing.
BeOS would also have been a cleaner start. It's difficult to say how much (or if) UNIX is holding back MacOS X. I find OS X somewhat bloated, especially in terms of the number of files that it is comprised of. I wish it took less time to make a backup.
BeOS is/was also advanced in terms of file meta data. That situation is still quite messy in MacOS X.
My 1GHz PowerMac boots into MacOS X in 17 seconds, so even "low end" machines now should be able to boot in around 15 seconds.
With that said, I do think that 15 seconds is "fast enough". That machine of mine had a "sleep disorder" due to a processor upgrade (it started out as a 500MHz machine) and I had to shut down and boot it instead of letting sleep. 17 seconds was actually still in the comfortable range.
I agree...It's really nice to see that at least someone seems to be headed in the right direction.
So, what if they made the first season of a show free, if broadcast in a regular "scheduled" way. If you don't want to bother with recording a scheduled show or you missed the first few episodes, you could buy what you missed for 25 cents/episode.
Then, start charging a bit more money for the second season and onwards and stop doing the free broadcasts (or do them a year later with commercials).
Finally, sell advertising space on the program guide/download catalog pages...and allow people to opt out of advertising by paying a monthly fee.
I hope they will understand "fair use", but I'm not too optimistic.
If old episodes are cheap and fast enough to download, would you bother with DVD-burning (except to take a few shows with you when you go camping or whatever)?
You are on the right track, but as you suspect, it's not quite that easy.
You can losslessly transform JPEGs with open source software from IJG so that the Huffman tables are optimized. I incorporated this into a Mac photography utility that I wrote, so I'm quite familiar with the effects.
Optimizing the Huffman tables for each image yields relatively small gains. The JPEG still decodes as fast as the original, so this is essentially a free lunch and worth doing every time you write a JPEG.
What's interesting is that a JPEG converted to progressive scan order will practically always be smaller than the non-progressive version. The downside is that decoding is slower (at least with the IJG decoder).
I think the Stuffit discovery is to do something fairly similar to the progressive scan trick. If you reorder the data cleverly, you'll find patterns that algorithms like LZW can compress or the set of values will be small enough so that you can improve on the Huffman compression ratios.
Here's an example using 2x2 blocks with values from 0-9 instead of the 8x8 (just to simplify things):
52 53 42 52
11 22 22 31
Reorder this to: 5545 2322 1223 1221
So each stream of coefficients looks more boring than the data in the original 2x2 blocks. To get better compression, you could simply use a new adaptive Huffman table for each stream.
The above example is just off the top of my head, so your actual mileage may vary.
In practice because I know that non-progressive JPEG draws a lot faster than progressive, I always ocnvert all my JPEGs into non-progressive versions. It's a lossless process though, so I would use this trick (along with the optimized Huffman tables) to fit a set of JPEGs into a limited amount of space (or to reduce bandwidth requirements).
As far as hard disk space is concerned, using progressive JPEG is not worth the extra CPU time to decode.
The folklore.org site is mentioned in the interview...
There's another site with a lot of excellent content on the making of the Macintosh:
http://library.stanford.edu/mac/
I think the "Technical Writing" part on that site is extremely valuable. It explains how the Inside Macintosh books were written and how that process affected the development of the MacOS APIs.
As far as technical documentation is concerned, the original Inside Macintosh books are still some of the best that I have ever read.
I don't know if people are already doing this (haven't checked eMule), but I think hosting the torrent files on eMule would work quite well.
More people sharing a torrent file would mean that the file is valid. You can attach reviews and comments to the torrent file.
You still need a BT tracker though.
Here's one system that I think could work:
Each E-mail sent can optionally contain a micropayment, cryptographically tied to the receiver's E-mail address and the contents of the E-mail.
When I receive E-mails, I can choose to ignore or simply spam-filter any E-mails with a value of less than X (I decide what X is).
The default action is to return the micropayment to the sender, if nothing is done within a week (or a few days) of sending the E-mail. This way, sending payments to someone who is not part of the system will effectively be a no-op.
The receiver has several possibilities:
Ignore the payment (the sender eventually gets his deposit back)
Return the payment immediately
Collect the payment
The way I would use this would be to collect the payment on any unsolicited commercial E-mails that I read (thus making sending SPAM cost money) and return/ignore all the payments from friends & other valid sources.
You could still send E-mails with no monetary value, but they would be subject to strict filtering.
I would probably set a filter limit of 5-10 cents/E-mail and only collect the money (if any) on real spam.
The system would provide income to those who run the banking, because they would get the interest on the deposits made by E-mail users.
At first, implementing something like this would have little impact on our E-mailing, because only a few people would be using the system. If it ever became widely adapted, we would have an E-mail system where sending spam is too expensive to be worthwhile and where regular E-mail would still be free (except for the loss of interest on the deposit made to send micropaid E-mails).
While most of the articles on ./ have concentrated on how evil RF tags can be, I think there are obviously good uses for them as well.
I hope that in the future I'll be able to buy an inexpensive RF tag scanner that has an adjustable range from maybe two meters to tens of centimeters. Also, I'll be able to buy generic RF tags with unique IDs and tag and catalog any items that I may want to find some day.
A database on my computer would allow me to search for stuff that I don't even remember getting and once I had a list of items I want to look for, I could load it up into the scanner and start walking around the house to find the items.
The advantage of this system is that you can pack things very tight into boxes and you don't open those boxes until you know that what you want is in there.
One step further from that, you'll have "room tags" in various places, so that when you do your search, the scanner also notes those and can update the "last known location" for all the items close to the room tag. So, if you carry that box with all the SDRAM DIMMs into the basement and you have your scanner with you (or built into your cell phone), the next time you look for those on your computer, your computer will know that they are in the basement.