The problem is that they're trying to sell the "print" books for only a slight discount as an e-book.

So you end up with two completely separate sets of books: overpriced e-books, so not very many sales in that format compared to print format; and inexpensive e-books that aren't even available in print because they figure it isn't worth printing them. Of course you're going to get completely different titles selling in the two formats.

I'd get Reamde for Nook but it's too expensive. I'd pay maybe $4-5 at most for something that I can't re-sell and is tied to a device that may not be available in a few years, locked to a company that may go out of business some day. In 50 years, will I be able to pull out my copy of it and say "oh yeah, that was a fun read, maybe I'll read it again." ... ? But they want $15 for it. No way.

It isn't Netflix or Microsoft paying for the higher bandwidth, it's the end user.

It sounds like the API is to allow the program to specify which packets are higher priority since each packet delivered at high priority will cost a bit more. Anyone can build the ability into their programs, and it's the end user who will end up paying more on their bill (which means the program ought to have the higher priority as an option).

I want to see fair queuing algorithms used by ISPs, and stop charging by the amount of data. Give higher priority (without charging extra) for a short burst when there's been little or no traffic from a device for a while (a few minutes), throttle down normal priority traffic only if needed. Throttle to a specific threshold such that around 80% of available bandwidth is being used, and so that anyone using less than that threshold doesn't see any effect at all.

Well, if the firmware upgrade process is looking for a CD or DVD drive, it seems unlikely you can trigger it based on what file system you put on some other device, and it might even work if you had a FAT-32 file system on the CD.

That's why this article doesn't make any sense, why would a format of choice be an ISO file system image? Apple's disk-image format allows for a (optionally compressed and/or encrypted) file system image using any file system the OS supports, so you can mount an ISO, UFS, FAT (of various flavors), HFS (of various flavors) and probably NTFS and a few other formats.

A disk-image file has been the standard way of distributing software for Mac OS X since practically the beginning. Most of them open up a disk window with the application and an alias to the Applications folder, with a folder image with an arrow showing you to drag the application to the Application folder. That's all it takes to install something (and a lot of stuff works just by double-clicking the application ON the mounted disk). Stuff that needs a more complicated install process typically has an installer package, possibly a Readme file.

Practically anything you can do with a real device you can do with a disk image, simply using the standard Disk Utility program, e.g. repartition or repair a file system, restore to or from, etc. All it does is create a loop device and use that.

There's nothing special about an ISO file system, certainly nothing that makes it desirable as an installation method. There's no reason you can't put a standard partition map (of your choice, MBR, GUID, Apple Partition Map) and any file system you want on a CD or DVD, and any reasonable operating system will be happy to mount it (and any reasonable firmware will allow you to boot off of it, including the firmware update process).

The only time that would cause a problem is if the rules for DST change between when you set the alarm and when it goes off (and part of the process of changing the rules would be to go through future date/times and flag ones that would change so someone can determine if they should be modified - they could also be stored with the original time value (i.e. what specific timezone was indicated on entry, whether it was implicit or explicit).

When you set an alarm for a future date, the interpretation of the time zone would be based on the date of the alarm, not on the current time, same for displaying times where the DST state of the future date is different from the current date.

How you display times in different time zones is something for a user preference setting - should they be shown using your own timezone (including DST rules based on the date of the time), or should they be shown as local time for the other time zone. Both make sense for different reasons and circumstances.

Remember, you can always set your default time zone to be UTC if you want to completely eliminate time zones and DST for yourself.

DST really isn't that difficult either. Internally, everything should simply run on UTC, display time is a simple offset from that. Whether that offset is fixed for a specific geographic location or changes by an hour is mostly irrelevant to the issue. The ONLY problem it causes is the one hour that's impossible and the one hour that's ambiguous for any particular time zone at the switch time.

I'd have no problem with DST going away, I think people should just adjust their schedule (e.g. schools can change start times depending on the season, if that's important), and not having everyone go to work from 8AM to 5PM would be a good thing overall. All of the conventions of "lunch hours" and such are fairly arbitrary anyway, few people care when local high noon is for basing when their meals are.

But local time zones are going to always make sense as long as people have circadian rhythms that adjust to the daylight cycle. Calculating that people tend to get up at 4am UTC, have lunch around 9am-11am, and that it's too late to call at 7pm, is no more difficult than figuring out that at 7am your time it's 6pm their time. In fact, without a timezone, you'd still have to identify the time difference somehow. You'd probably call them "time zones".

If you think time zones and DST are confusing, wait until we have interplanetary travel. Just HOPE we don't ever get instantaneous communications, the different day and year cycles alone will drive everyone crazy.

That's why Best Buy sells it as a bundle, with the software pre-loaded onto a microSD card. If you're clued in, you could buy the raw device, buy the storage cards, download the software and save yourself $100. Otherwise Best Buy makes an extra $50 or so.

There are plenty of Linux distributions that have essentially automatic software updating mechanisms, as well as managing what software you want on it (including automatic download/install of the ones you want to add). Someone could probably make some money selling inexpensive subscriptions to a store/update service for people who don't want to bother learning about other sources.

I don't think a loss-leader hardware platform is going to work at this point, unless it's so cheap it's practically free ( $50), or the supplied software is absolutely fantastic and locked to the hardware.

I don't think the touchpads would have flown off the shelves as fast if they couldn't have other software loaded on them. With no support from HP, no one is going to buy something with no support, no upgrades, no bug fixes, unless they're pretty confident they can put something else on it fairly easily.

Give me a tablet with GPS, compass, gyroscope, accelerometer, camera, multi-touch hi-res screen, 802.11n, bluetooth, perhaps an infrared interface, a dock/USB connector for anything else (perhaps including external video), a microSD slot for boot/system software, and two standard SD slots (one for user data, including all settings; the other for importing data (e.g. camera card) or doing backups). No built-in storage, microSD stores all the system software plus whatever apps you want to put there. I guarantee you that there will be software to put on it if you sell the raw device (only firmware needed is what's necessary for initial boot off of the microSD card).

If you can sell the raw device for $200 or less, with no software development, no software support costs, I think it will sell like crazy. You'll be able to buy a microSD card pre-loaded with a system for it, add in another SD card and you're ready to go - Best Buy could sell it as a package for $300, make money off of it, and still sell tons of them.

The idea that by making it more difficult to pirate a game you'll get more people to buy it is flawed. Not many people who pirate stuff hardcore (as in, never buy the game, as opposed to those who try out a game, then buy it if they like it) will break down and buy it simply because they put in on-line validation requirements.

Those people who do try out a game using less-than-legitimate versions, then buy it if they like it, are much LESS likely to try it - and people who are inconvenienced by obtrusive DRM like this are also going to shy away from it in the future. Even though free Wi-Fi connections at restaurants, coffee shops, airports, etc. are becoming more widespread, there are still plenty of places where you might want to play something for a while without a network connection.

Anti-piracy measures affect sales of legitimate copies and proliferation of illegitimate copies. When they only decrease the latter, but don't increase the former, they're worthless, and if they negatively impact the legitimate sales, then they're worse than useless.

Actually, there are people who go in for the full simulation, including filing flight plans, talking to ATC (real people, running ATC simulators), fuel and weather issues, waiting for traffic, etc.

I'd say that flight simulators are an example where maximum realism (in visualization, physics and controls) can be good as a game.

They aren't patenting mixing hashes and linked lists. They have several references to using such data structures (including Knuth).

The "innovation" is to delete expired records while accessing the records, either adding new records or searching for existing ones, plus the additional "innovation" of dynamically configuring the maximum number of records to delete on each access request.

In other words, you look up the hash, go to the first record in a linked list. You check to see if it's expired, if so you delete it from the linked list, recycling the storage. You then move on to the next record. If it isn't expired, you check to see if it's the one you want. If not, rinse and repeat. Once you've deleted a configured number of records, you stop trying to delete them and just search for the one you want.

Of course, just doing this doesn't remove the need to sweep the entire database for expired records; they could be sitting in hash chains that you haven't accessed, so the storage space hasn't been recycled. Doing it this way may also incur additional overhead from needing to lock the database as you delete records (hence my suggestion to mark it as invalid using a lightweight sync, but allow anything currently using the record to continue on - sort of like RCU does).

A better way to invalidate the patent might be to attack it on utility - since it purports to be useful for large databases that have to be online at all times (as if the only way to expire records is to take everything down for a maintenance period), it seems pretty worthless since it doesn't show how to handle read and write locks, which any dynamic database would seem to need in some fashion (for instance, some process is in the middle of using the record that you're trying to delete - do you block (thus delaying the current query) until the other process has finished with the record?).