Oh does that bring back a few memories. I was doing wiring for dumb terminals in an accountant's office. This was generally pretty easy, we were running the wires above the drop ceiling in most places.
Except for the receptionist's desk. Her desk was right outside the computer room, which had a big glass fishbowl so people coming in could see the massive hunk of technology that was the System/32. So for her desk we ran the cable under the raised floor and I drilled through the wall to get the wire right under her desk.
Which was all well and good except that the phone company had left several feet of 50-plus conductor wire (we're talking two inches in diameter) for the receptionist's phone coiled on the floor inside that wall. And I drilled right through it.
I spent most of the next two days crunched under her desk soldering every freakin' wire that I'd severed with the drill back together.
Haha, RPG. I remember doing RPG (motto: "everything has a column, everything in its column"). But we didn't have terminals to work with, just the one System/32 with its built-in 6-line (by 32 character I think) display.
I used to code it all up on those little paper sheets and then, when the machine wasn't being used for production work, type it all in. (Or use the "punch terminal" which allowed you to type -- get this -- directly onto 8" floppies.) Compilation of some of those programs took 4+ hours, pretty much had to be done overnight or on weekends.
Not that that was a bad job, mind you. I can't really say I've had any bad jobs. But I don't miss RPG at all.
There doesn't seem to be a benefit to them in keeping silent unless their claims aren't strong or are easily refutable.
They say that if this information were public it would damage the value of their IP by revealing confidential code.
You and I and anyone else in UNIX-land knows that that's a crock of you-know-what, given how widely published SysV information and even code has been, but it's one of those legal myths they have to try to preserve if, indeed, their case has any value at all. Of course the fact that this makes it impossible for the Linux folk to verify the claims themselves, or fix them if they're true, is just a happy side-effect for them -- right?
There was similar vacuous baloney in the DeCSS case. The algorithm was massively published but still considered "trade secret." It apparently doesn't have to make sense.
My personal guess is that they're about two inches from having the case thrown out due to lack of merit. I think they expected this to get drawn out for at least several years, during which they could repeatedly threaten people into paying them money, or sue them and get settlements since almost nobody is going to be interested in the effort and expense of a fight over code they don't even own. So, even if they lost, they figured they'd make a bunch of money.
It's looking more and more like they're going to lose this one bad. Even if there were infringement, they don't seem to have clear title to the code in the first place (something they should have learned from the BSD lawsuit, and that was before Novell sold it off and muddled it even further). Moreover it is exceptionally likely that IBM is going to find a lot more Linux code in their stuff than the other way around, again just like in the BSD case.
So I figure it gets thrown out. I just hope the SEC hauls them in since they've definitely been doing a bit of pump-and-dump.
When somebody demonstrates that we have the technology for the cable, I'll concede it's a possibility. At the moment about the best thing you can say about it is that there has been a lot of science fiction written about the technology (reference Heinlein's Friday and Robinson's Red Mars). In any case it's clear that such a technology will have extremely high capital costs -- likely more than any engineering project in history. As such I think it's safe to say that it's not happening any time soon.
Someone else later says that rockets are our only viable choice. I disagree, at least partially. With current technology we could easily build a railgun launching mechanism, or at least use such a mechanism for the first stage of launch. This would decouple the bulk of the lifting system from the payload and dramatically reduce per-launch energy costs.
If I recall correctly such a launch system was discussed in Barnes' Mother of Storms. If I'm remembering correctly the design he was thinking of used an evacuated tube with an iris at the end, the idea being that you accelerate in vaccuum and open the iris at the last minute. I think that such a design would be impractical due to the shock of entering the atmosphere at high velocity. But I see nothing wrong with using an open cradle design; you have to fight air resistance the whole way, but that works in your favor in terms of stability and cost of construction.
There are, however, a number of practical considerations with any such launch system. One of the first is that you're probably going to want to build it up the slope of a mountain, and properly situated mountains may be hard to come by. Another is that you want it at a low lattitude and eastward-facing to take advantage of the earth's rotational velocity (particularly good if you're trying for a geosynchronous orbit). You want it to fire out over the ocean to make failed launches safer and to avoid societal issues with sonic booms (although I think that it may be possible to alleviate most of the booms using baffles). In combination these things make a launch facility location a little difficult.
I note, however, that the the low lattitude and eastward-facing issues are not especially debilitating. You could launch on a polar orbit almost anywhere, you'll simply need a longer/more expensive launcher. Doing so will make equatorial orbits a lot more expensive to reach, of course. Still, if you did that I think a nearly ideal location for such a launch mechanism if it were based in the U.S. might be in Alaska.
Anyway, keep this in mind the next time you're trying to think of a way to make space exploration more affordable. These systems will not solve the issue of how to make a cost and time effective long-range propulsion system, necessary if we want to make visiting other planets or mining asteriods fairly practical, but a primary barrier to space right now is simply the cost of escaping Earth's gravity well. I think that cost has been historically much larger than it should be on account of our penchant for building lift systems that have to lift their energy source with them. Maybe we should try to split the effort.
I understand that they requested that the response be kept private, and the request was granted. I don't know how much information IBM will be able to give out about it, but for sure you're not going to get it from court records.
I don't think that's a secret. BSD was a research project to advance UNIX and was under a licence to allow AT&T to merge code back in.
Anyone can utilize BSD code, based on its license. There was nothing special about AT&T's rights in that respect.
I thought the real problem was that UC's copyrights weren't maintained.
Right-o. They copied wholesale and removed the copyrights. It was so extensive as to make them look like fools for complaining about a few files that BSD had supposedly copied. But they were also negligent in that the BSD folk had repeatedly asked them to vett code so that they could release it, and AT&T refused.
In this case I don't think there will be anything so blatant, however they're starting from a much stronger position than the BSD folk in that Linux was clearly independently developed whereas BSD started out as a derivative.
Anyway it probably won't look too good in court when IBM shows that SCO's idea of infringing code is any code that has "IBM" in it. But I wonder if they even care if they win, or if they care if it makes it to court.
Consider the scenario as it exists today. They made the case very high profile by suing IBM, but have to know they're going to lose that suit. If SGI isn't worried about defending themselves, and SGI's name is all over the code they've shown to date that was supposedly copied, IBM should be in fine shape. But that suit is probably going to take years to work its way through. Meanwhile they're planning to sue Linux users who will be literally unable to defend the Linux copyrights and, arguably, uninterested in a drawn out case to do so. What will the best course of action be for those companies? Probably to settle. In the short term SCO will likely make some money off of this even if they are wholly in the wrong.
Surely IBM has inspected the code! IBM and it's lawyers have acted completely clever in this case until now, do you really think they would forget the obvious?
It may be an obvious thing to try from our point of view, but it may not be obvious that it would help them from their point of view. They might not even be able to do so without discovery because AIX is based on a version of UNIX older than Linux. In order to find such problems they'd need an up-to-date version, and a x86 version at that. Perhaps they have access to that, perhaps not.
In any case, it's not a foregone conclusion that SCO infringing on Linux in general would help IBM in any way. (Actually I'd argue that it doesn't, although it would reflect on the character of SCO.) If they did it it'd be more of a gift to the Linux community. This isn't like the BSD case where BSD had a single clear owner who was already involved in the suit; IBM owns very little of Linux and probably none of the part of it that SCO would have used.
Rumors are that part of the sealed evidence showed the much of Unix was actually lifted from BSD.
I think the quote was, "as much as 50%." There is a hell of a lot of BSD in SVR4. That certainly seems to have pushed them to a fast settlement (and they got off cheap!) but there were a variety of other things that probably would have shot them down too -- many of which are still going to be true in a case against Linux.
One of the primary issues, not decided by the judge but hinted strongly at, is that 32V may actually be in the public domain. In that light the decision to put it out under a BSD license was a kind of damage control; if it's out under a loose license then most likely no one will test the validity of the original copyright in court.
This case may well reopen that can of worms seeing as the only case of obvious copying they've pointed out is rooted in 32V.
I rather hope that IBM is doing/has done its own code commonality inspections because it seems highly likely that there is GPLed code in SCO's product (that's the easy way to compatibility you know). If so that would tarnish their case badly, although it's not very likely to be as damning as it was in the BSD case.
One of the things I find most amusing about their claims of open source being lax on IP protection is that it's been my experience that code pilfering is quite common in closed source projects. Certainly we know it happened at least twice in the history of SysV -- once wholesale in SVR4, and again in R5. And I would suspect it happened again when Caldera implemented Linux compatibility.
I kind of hope IBM or some other SCO source licensee does their own code analysis. My bet is that there are many more lines of code pilfered from open source in SCO stuff than vice versa. SCO is really only getting huge infringement numbers by counting whole subsystems as infringing, using theories of "derivative" that are unlikely to hold up.
Go take a look at the BSD lawsuit papers (various links posted around the net). The judge's opinion where he denied the preliminary injunction against BSDI is really quite remarkable.
Hah, I remember letter bombs. They became so frequent when I was in college that I prefiltered my mail spool to remove control character sequences. Who knew I'd still be doing mail spool filtering fifteen years later?
We used to also blast control sequences straight to the terminal (since the default in BSD 4.2 and 4.3 was to allow anyone to write to any terminal). The one that we used a lot was the "hard reset" sequence of the vt220, which dropped the RS232 line and triggered a logout, but people rapidly reconfigured the terminals to ignore that. My favorite was to send a lot of nulls since that was more or less invisible but effectively locked up their terminal.
Of course people dealt with this by adding commands to their.login to disable public writeability of their terminal, so the way I dealt with that was to try to grab a descriptor to their tty between the start of login and when the.login script executed (these were the days of the vax, that was a reasonably large window) and just hang onto it in case I wanted to bomb them later.
Probably a decade ago I was involved in a discussion about the etymology of computer viruses.
I didn't know who wrote the first one, but I'd written one in I believe the fall of 1984 (could have been that winter). Not that I thought I was first, but it was at least pretty early. Nobody had heard the words "computer virus" before, and I certainly didn't use them. I called it a "self-replicating program." In my version I hooked the command interpreter for Apple DOS's "catalog" command and made it copy itself in place on whatever disk it was looking at. Simple and effective -- and benign, since all it did was replicate (although a few variants did more amusing things like change the catalog output subtly).
I knew that was pretty early, but it turned out that there were at least two earlier viruses on the Apple -- both done at colleges circa 1982. The only one I remember was done at I think Texas A&M, and IIRC theirs were substantially more sophisticated than mine.
In the eyes "Mikey the Musician", letting five people download his song(s) to sell one is great. Especially if those five people live, I donno maybe, -halfway across the country-!
If the musician wants people to do it, that's one thing. Many do; remember Janis Ian? She's using this as a marketing system, and it's apparently working very well for her (album sales up 300% or so last I heard).
But there is a big difference between the musician giving you permission to hand these things out as a marketing campaign and, say, me putting my entire 700 album collection spanning 500 artists online for everyone to just take as they please.
Isn't there?
I concur that there are some cases where illegally copying the stuff is the only way you're going to get it. The only time I've ever used Napster or Kazaa, for instance, was to try to locate a copy of Weird Al Yankovitch's _Peter and the Wolf_ which has been off the market for more than a decade. I've offered up to $80 for a legal copy of this disc and still been unable to buy it. If they refuse to sell it to me I don't have a whole lot of problem with copying it illegally. (Not that it helped, I couldn't find more than one track of that CD even using Kazaa, so I gave up and my whole MP3 collection is still legal.)
But hey, if you go look at what people are really downloading lots of, and who is downloading it, by and large you're talking popular music and urban US residents. In other words, songs that these people could get easily even if we ignore internet retailers like Amazon. It's not some guy in Idaho trying to download songs by Francine! (Local Boston band, check 'em out.)
Still, as I said elsewhere, the number of people doing wholesale downloading is pretty small at the moment, largely because those with the time and bandwidth to do it are an exceedingly small part of the population. It doesn't make it right, though, and I still fail to see why these people ought to be immune to prosecution. What they're doing is illegal after all.
Depending on which RIAA madness you're talking about, I might not care that I'm funding it.
I think, for instance, that there's every reason that the RIAA should go after people for bulk distribution of music owned by their members. It's illegal, you know. If their members want you to pass the stuff around for marketing purposes, they'll release it that way (and many bands and some labels do exactly that).
That means that if the RIAA is beating on you for illegal music swapping, I support that action. What other technique do they have to get people from doing this?
If you mean funding the people that rip off musicians, that's another thing -- but that's not the RIAA, that's the labels. I am a fan of the smaller labels, and try to buy product directly from the band where possible (since although the label still gets their share, the band gets part of what the retailer would have gotten).
Record companies PAY big bucks to "Give" songs away for free. It is called RADIO. They do this because getting songs for free increases interest AND sells records.
There are several very substantial differences between mp3 sharing and radio. For instance, radio broadcasts are ephemeral. The listener can't go back and listen to the song again unless they record it. And recording songs wholesale off the radio is difficult both because it must happen in realtime and because the music industry regulates preannouncement of tracks. Radio listening and recording is, therefore, not a significant loss of revenue for the music seller.
Broadcast is traditional marketing, no question about it. You can argue, and I would agree, that P2P allows viral marketing that was difficult with old media, and I'll talk more about that in a minute. Regardless, the fact remains that there are people who are not treating mp3 file trading as a sampling system but as an acquisition system. And when it crosses that line it crosses over between beneficial to the artist to being detrimental.
I am of the opinion that the people who have been doing this have had at best marginal impact on music sales, largely because the domain of people who can possibly download substantial quantities of music is quite small. It requires, for instance, a lot of bandwidth to download a single album in better than real time. Today that kind of bandwidth is still relatively rare, along the lines of 3% of the total population. As such, it's ridiculous for the RIAA to claim that downloading has killed sales to the tune of 10% or more; there just aren't enough people with the time and capability to download that much music to have that much effect.
I'll not disagree that RIAA members are concerned with loss of control over music distribution, although I would be rather surprised if they were as worried about that as you might think. It's been the case for years and years that artists could make and distribute there own albums, even do so cheaply, and yet the music industry managed to survive. The fact of the matter is that the primary limitation of growth of an artist's market is not the distribution system but rather market awareness. It is the very rare case when viral marketing of the sort that P2P provides boosts an unknown artist to superstardom. I would be surprised if you could point out even one case of that ever happening, particularly since at some point the artist will have to get his stuff played on the radio, and in these days of Clear Channel this is an expensive proposition. There is, therefore, a natural limit to how far artists will be able to go without the help of a major label who can fund broadcast-based marketing.
It's difficult to prove, but my opinion in the matter is that the only reason music sales fell by as little as they did in a tough economy, with tough competition from alternatives like DVDs, and with the industry raising prices in the face of those, is because MP3s have made music so much more accessible that many people have gone out and bought more. I know I have.
But that's today. What if we extrapolate out what is likely to happen as broadband penetration increases to the saturation point? That small percentage of people who just go out and download whatever they want rather than buying it will almost certainly grow with it and become much more than a marginal impact.
And that's what the RIAA has to be afraid of. It's not control of the artists because so long as they're a big money pool they will win the marketing game versus person-to-person marketing because broadcast is much more effective.
It's not that downloading is costing them much in the way of money right now, no matter what they're saying in public. It's that if they don't slow down the leakage somehow it'll become a torrent as broadband penetration grows to the point where the average person can do this.
That's not the RIAA talking, that's just a straightforward projec
As an amateur musician I'm sad to read that.
What he said. I'll grant that P2P has probably improved the sales of many musicians' music; for sure the easy mobility of MP3s has allowed my friends and I to more easily sample music, and I've bought more (and much more eclectic!) music as a result of that.
But it's worth remembering that there is a difference between sharing a clip and wholesale downloading. At some point in scale it stops being reasonable at starts being serious theft. When you've got people out there sharing tens of thousands of songs it's hard for me to see that as anything but a big rip-off and very hard for me to see why the RIAA should leave them alone.
I don't envy the RIAA their position, because this technology is going to be very hard for them to stop. And I agree with people who think that if they'd taken a softer stance on internet distribution earlier that they might have been able to leverage the technology rather than fighting it.
As for the musician's compensation, I think it would be very interesting to see if any of the money from these settlements actually made it to a musician. I know which way I would bet. If the musicians benefit from this at all, it's going to be from reduced wholesale copying, and really that's likely to benefit only the most popular musicians.
My Powerbook has Bluetooth. The thing is, not one device other than my Powerbook has it. The only device I'm even thinking of getting that could have it is a new cellphone.
I'd like to have some sort of connection between the laptop and phone for doing internet connectivity and, perhaps most importantly, managing the phone's contact list. But a USB wire would do the trick just fine, as it does for my Palm.
And, since it interferes with 802.11 which I use nearly 100% of the time, I'm certainly not motivated to use it for anything other than intermittent device communication.
I think I'd rather just have 802.11 devices, seeing as those are getting pretty ubiquitous.
My only significant issue with 802.11 is that it is much too difficult to manage if you don't want to leave the thing open to the world. I'm thinking of two scenarios I've run into:
Inconsistent behavior. I have a couple of wireless bridges in my house. The Linksys bridges work pretty much as I expect, wherein the MAC address of the bridge is the one that I have to put in the "allowed MAC address" list on the AP. But I bought a D-Link AP/bridge and couldn't get anything on the far side of the bridge to talk. Turns out that it forwards the MACs for its connected devices rather than using its own, so I had to list the MAC of every device that was a client of the bridge. Of course nothing in the documentation mentioned this particular behavior.
Debugging connectivity problems is hard. You're adding a new device, and it's not talking. Why not? Could be wrong SIID, but probably it's the wrong WEP settings. Sometimes I have to enter the keys as ASCII, sometimes hex, sometimes hex padded with some zeros. But it could also be that I misread the MAC address of the client (that had me stymied for hours once; turned out that B was actually an 8).
What I would like to see is an evolution of 802.11 client software such that they can self-organize with checks. For instance, I would really like to be able to have my AP notify me that a new client wants to join, identify the device as best possible, and allow me to say "yes" or "no." If I approve it, I'd like the client to be configured properly by the server.
In this way configuration would be nothing more complicated than picking the SIID from a drop down or typing one in.
While I'm thinking of 802.11 enhancements, there's no reason that consumer-oriented APs cannot do a better job of actively notifying you of something. Some of them support syslog, which is not really much help to Windows people and a bit arcane for a lot of Linux people. Why not use SMTP to send notifications via email? I'd love to be notified whenever someone tries to join my AP....
I knew you all would bash me for that:-). I don't recall Apple qualifying "first" with "consumer," although that certainly does seem to be implied. As for "personal computer," the Alpha I played with ran Windows, and that made it a PC in my book. A really, really fast PC:-).
Which doesn't make the G5/Opteron/etc any less cool, just not really "first." I'd take any one of them....
I have been terribly amused by Apple's claims to be the first 64-bit desktop. I dunno about you all, but I used an Alpha desktop in, oh, 1994. It even ran Windows (not that I considered that an advantage).
I knew something had to be wrong with that $38M number; 600 Dell servers, good ones, should run in the ballpark of $3M, not $30M. Even with the high-performance interconnect you'd need you ought to be able to do it for under $5M.
So I hit Dell's website and at educational pricing the servers they bought run around $4k apiece. Which means that this solution should be very price/performance competitive with the VT cluster.
I hit the UT page and found that the $38M number came from a press release about their investment in quite a bit of stuff, including the "Institute for Computational Engineering and Sciences (ICES), a new center for interdisciplinary research and graduate study in the computational sciences." I.e. at least one new building.
So far I've only been reading public domain or Baen free library books. Maybe I'll try dipping my toe in the pool of DRM.
When I got my Zaurus, which didn't have a PalmReader, I hit Baen for books. The HTML format books were barely readable. I ended up finding a program that could read the PalmDoc format and just stuck with books that weren't encrypted. There are a lot of them out there available from Fictionwise.com, although not usually mainstream stuff.
I haven't tried Mobipocket yet, so I can't compare that to the PalmReader experience. Soon, though.
Frankly, I don't much care if the books have DRM or not, but if it does have DRM I think the PalmReader approach is a very nice compromise. I can "lend" a book to someone by beaming it to them and unlocking it with my credit card. But they can't do the same thing unless I give them the card number, which I won't. So you retain some of the flexibility of the paper book, but rampant copying is not possible.
Brave New World? Read it sometime - it's not all good news! (as I suspect you know, to be honest)
Indeed, that statement was intended to pack some irony. One of my favorite books (perhaps the only one they forced me to read in high school that I actually thought was worth reading and re-reading).
He makes several good points, but not all of them are on target. Particularly portability; ebooks are a lot more portable than paper books. What's the densitity of digital information storage these days? Something like a gigabyte per square centimeter. That's a whole damn library. And that matters because what we're talking about there is the effective elimination of warehouses.
But it's true even at the individual level. I routinely carry ten ebooks around in my palmtop. The palmtop I carry anyway for it's organization features. I'd need a big backpack and a strength building program to carry ten paper books.
As for minimum technology for maximum interaction, how have newspapers done against TV?
Answer: TV practically destroyed them. Newspapers still exist, but they have nowhere near the ubiquity and penetration they had prior to TV. Yet TV is a lot of technology for something that gives very little interaction. Moreover, TV proves the points that people don't really care so much for the paper experience that they wouldn't switch, and that they'll pay money (even a lot of money) for a viewer.
Nor is that the only example of people moving from paper to electronic. Have you used the web lately? Did you know that even a decade ago the only way to get timely information was paper journals? That product information was mailed to you in paper pamphlets?
The web demolished entire printing industries. And yet the web has all the same downsides that Asimov pointed out.
Someone will say, "yea, but the web improved immediacy." That's true, but that wasn't the only reason, nor even the primary reason. It won, largely, because of economics. Let's illustrate.
Someone here earlier said that a paperback cost about $1.20 to print, so there wasn't much savings in ebooks. He forgot about warehousing and shipping and such, but let's just call it $1.20 and presume the new costs of ebooks are a wash (they aren't, it's not even close, but we'll presume that anyway). If the publisher can sell the ebook for the same money as a regular book, that means they pull in another $1.20 per book. That represents a very substantial jump in profit.
Trust me, if they can figure out a way to get us to buy ebooks they will do it. There's more money to be made. And with DRM, they can substantially close the borrow and resell hole.
To go mainstream they'll have to subsidize the readers (or palmtops will have to be more ubiquitous) but ebook-capable devices can currently be produced for under $20 if they care to do it... and the price drops every year. There is an inflection point coming; it will almost certainly happen before 2010.
The economics of paper books will become noncompetitive with ebooks within the next decade. And when that happens, the market will flip.
It's already happened in a bunch of cases. I don't know about you, but I used to have a bookshelf full of references so I could get my work done. Today I have only a couple of books, and they're more tutorial-style than reference. I get virtually all reference material from electronic stuff. Virtually all help material from electronic stuff too. In fact, most software publishers provide practically no paper documentation these days.
In many respects I consider this a step down in usability, but distribution costs dominated the equation from the point of view of the producers, and since we didn't have a choice in the matter we got these things rammed down our throats.
You will have to use ebooks whether you like it or not. It won't happen this year, or next, but by the middle of the next decade it will be difficult to find many texts in paper format.
This change is going to have some really widespread impacts. Consider what this is going to do to the bookstore, for instance. We probably won't have "bookstores" so much as "book kiosks." Not the same buying experience, and a big step down IMO, but those kiosks would be able to sell you almost any book that has ever been published and cost vastly less than a big storefront.
It's not really right to give ebooks such a hard time for not living up to the hype. There was a lot of hype.
People are making too much of B&N's dropping of ebooks. Of course they didn't sell very many of them - they started out offering nothing but Microsoft stuff. Who wants to read books on a PC? Short battery life on laptops (if you have one) and a lot of bulk makes that a terrible experience. And Microsoft's palmtops don't have enough market to give much of a market to sell to. That was a losing proposition from day one.
The only viable "ebook" readers out there are palmtops. The form factor is the closest to a real book. And if you're talking about palmtops, the biggest market by far is PalmOS devices. It's like seven times bigger than the nearest competitor. Yet B&N didn't really even try to support them.
Eventually they also started offering stuff in Adobe format. DRM issues aside, have you tried to use the Adobe reader on a Palm? It's a complete piece of junk. First you've got to download a bunch of software on the PC side so it can format the book for you. Ok, fair enough. It took 20 minutes (!) to format the last book I bought -- this on a very nice Athlon 1900+ box. 20 minutes! That's ridiculous. And when it got done it had done page breaks right in the middle of words. If you're going to spend that much time formatting stuff to look good on my device, you can at least get word breaks right! On top of that their reader on the palm device poorly uses screen real-estate, doesn't make use of the larger screen of my Clie either, and for some moronic reason the "pages" it shows are larger than the physical screen so every two or three page-downs you do you get half a screen of text.
The user experience for the Adobe reader blows so bad that I will actively avoid that format in the future. Whoever thought that was acceptable should not only be fired, they should be locked up so they can never be involved in technology again.
I contrast that to using the PalmReader. I've been using it since 1998, back when it was the PeanutReader. This is a simple little reader that makes excellent use of screen real-estate, including enhanced displays like my Clie. It's fast. The books are just normal PRC files on the palm so it's really easy to get them on there. It has DRM too, in the form of typing the credit card # you used to purchase the book, but this is not terribly intrusive.
I keep buying PalmReader books. And two of the companies that are selling them, Palm Digital Media and Fictionwise, are managing substantial year-over-year growth.
Maybe that's because they offer a pretty good user experience.
For all the faults of ebooks, there are some really nice things about them. Key among them for me is that since I already carry my palmtop almost everywhere, I always have a book in hand. That means I can read something I like rather than the Enquirer standing in line at the grocery store, for instance. Since I can easily load half a dozen novels onto even a small PalmOS device I can pick and choose my reading material according to mood rather than availability, and I don't get stuck being bored on the train because I finished one. And with backlighting I can read the things in bed without the light bugging my wife.
I'd like a little bit larger screen. I'd like to not have to worry about battery life (a significant issue on the Clie, less so on the old monochrome Palms). I suspect we'll have good solutions to both of these as electronic paper hits the streets over the next couple of years.
But if you want me to go out and pay $300 for an ebook reader, or you want to force the books down my throat in some gawdawfully difficult to use format, then you can forget it.
Ebooks are going to win in the long term, that's simple economics. It's going to be cheaper, a lot cheaper, for the publishers to subsidize the readers and save on warehousing and shipping and recycling the physical books.
This is just a rehashing of an april fool's joke that went around on USENET some 15+ years ago. They were talking about using the UUCP transmission delay for archiving. I spent a few minutes trying to track down the original on deja.com, unsuccessfully, but trust me... I remember it.
It's also interesting that way back in the dawn of computing equipment they did use propagation delay as a way of doing storage. Mercury delay lines in particular. Not only that, the people that used them noticed that the tubes made noise and found ways to play tunes by saving the appropriate data. Google "mercury delay lines" and you'll find a few notes about the technology.
Grand-parent, please note what he says above: a dozen a week.
I actually might be overstating that, that's all of the package update messages I get (typically one or two a day), and I think only a subset of those are for security issues. I'm on two different notification lists so it'd be easy to confuse the two.
But even if most of them are security issues there are two things you should remember about the things that are being reported. The first is that almost all of those are in applications, not in the OS proper or even in its core set of features (typical shell programs and servers). These would be the kinds of issues you'd get with add-on applications in Windows, which are never reported in Windows vulnerability reports. The second is that almost none of these issues are significant security concerns. I don't really care very much if some little-used user program has a buffer overflow; I care a lot if sshd, my MTA, or apache has been compromised.
Not that we haven't seen a few of those big ones, mind you: sendmail and bind have been particularly problematic (which is why I run an alternative MTA and don't expose DNS services externally). Even so, I spend way less time keeping my BSD and Linux servers patched up than Windows; the latter seems to have two critical patches a week on average, and every $%&^^# one of them requires a system reboot.
Slashdot Mirror
Except for the receptionist's desk. Her desk was right outside the computer room, which had a big glass fishbowl so people coming in could see the massive hunk of technology that was the System/32. So for her desk we ran the cable under the raised floor and I drilled through the wall to get the wire right under her desk.
Which was all well and good except that the phone company had left several feet of 50-plus conductor wire (we're talking two inches in diameter) for the receptionist's phone coiled on the floor inside that wall. And I drilled right through it.
I spent most of the next two days crunched under her desk soldering every freakin' wire that I'd severed with the drill back together.
I used to code it all up on those little paper sheets and then, when the machine wasn't being used for production work, type it all in. (Or use the "punch terminal" which allowed you to type -- get this -- directly onto 8" floppies.) Compilation of some of those programs took 4+ hours, pretty much had to be done overnight or on weekends.
Not that that was a bad job, mind you. I can't really say I've had any bad jobs. But I don't miss RPG at all.
They say that if this information were public it would damage the value of their IP by revealing confidential code.
You and I and anyone else in UNIX-land knows that that's a crock of you-know-what, given how widely published SysV information and even code has been, but it's one of those legal myths they have to try to preserve if, indeed, their case has any value at all. Of course the fact that this makes it impossible for the Linux folk to verify the claims themselves, or fix them if they're true, is just a happy side-effect for them -- right?
There was similar vacuous baloney in the DeCSS case. The algorithm was massively published but still considered "trade secret." It apparently doesn't have to make sense.
My personal guess is that they're about two inches from having the case thrown out due to lack of merit. I think they expected this to get drawn out for at least several years, during which they could repeatedly threaten people into paying them money, or sue them and get settlements since almost nobody is going to be interested in the effort and expense of a fight over code they don't even own. So, even if they lost, they figured they'd make a bunch of money.
It's looking more and more like they're going to lose this one bad. Even if there were infringement, they don't seem to have clear title to the code in the first place (something they should have learned from the BSD lawsuit, and that was before Novell sold it off and muddled it even further). Moreover it is exceptionally likely that IBM is going to find a lot more Linux code in their stuff than the other way around, again just like in the BSD case.
So I figure it gets thrown out. I just hope the SEC hauls them in since they've definitely been doing a bit of pump-and-dump.
Someone else later says that rockets are our only viable choice. I disagree, at least partially. With current technology we could easily build a railgun launching mechanism, or at least use such a mechanism for the first stage of launch. This would decouple the bulk of the lifting system from the payload and dramatically reduce per-launch energy costs.
If I recall correctly such a launch system was discussed in Barnes' Mother of Storms. If I'm remembering correctly the design he was thinking of used an evacuated tube with an iris at the end, the idea being that you accelerate in vaccuum and open the iris at the last minute. I think that such a design would be impractical due to the shock of entering the atmosphere at high velocity. But I see nothing wrong with using an open cradle design; you have to fight air resistance the whole way, but that works in your favor in terms of stability and cost of construction.
There are, however, a number of practical considerations with any such launch system. One of the first is that you're probably going to want to build it up the slope of a mountain, and properly situated mountains may be hard to come by. Another is that you want it at a low lattitude and eastward-facing to take advantage of the earth's rotational velocity (particularly good if you're trying for a geosynchronous orbit). You want it to fire out over the ocean to make failed launches safer and to avoid societal issues with sonic booms (although I think that it may be possible to alleviate most of the booms using baffles). In combination these things make a launch facility location a little difficult.
I note, however, that the the low lattitude and eastward-facing issues are not especially debilitating. You could launch on a polar orbit almost anywhere, you'll simply need a longer/more expensive launcher. Doing so will make equatorial orbits a lot more expensive to reach, of course. Still, if you did that I think a nearly ideal location for such a launch mechanism if it were based in the U.S. might be in Alaska.
Anyway, keep this in mind the next time you're trying to think of a way to make space exploration more affordable. These systems will not solve the issue of how to make a cost and time effective long-range propulsion system, necessary if we want to make visiting other planets or mining asteriods fairly practical, but a primary barrier to space right now is simply the cost of escaping Earth's gravity well. I think that cost has been historically much larger than it should be on account of our penchant for building lift systems that have to lift their energy source with them. Maybe we should try to split the effort.
Here is the groklaw story.
Anyone can utilize BSD code, based on its license. There was nothing special about AT&T's rights in that respect.
I thought the real problem was that UC's copyrights weren't maintained.
Right-o. They copied wholesale and removed the copyrights. It was so extensive as to make them look like fools for complaining about a few files that BSD had supposedly copied. But they were also negligent in that the BSD folk had repeatedly asked them to vett code so that they could release it, and AT&T refused.
In this case I don't think there will be anything so blatant, however they're starting from a much stronger position than the BSD folk in that Linux was clearly independently developed whereas BSD started out as a derivative.
Anyway it probably won't look too good in court when IBM shows that SCO's idea of infringing code is any code that has "IBM" in it. But I wonder if they even care if they win, or if they care if it makes it to court.
Consider the scenario as it exists today. They made the case very high profile by suing IBM, but have to know they're going to lose that suit. If SGI isn't worried about defending themselves, and SGI's name is all over the code they've shown to date that was supposedly copied, IBM should be in fine shape. But that suit is probably going to take years to work its way through. Meanwhile they're planning to sue Linux users who will be literally unable to defend the Linux copyrights and, arguably, uninterested in a drawn out case to do so. What will the best course of action be for those companies? Probably to settle. In the short term SCO will likely make some money off of this even if they are wholly in the wrong.
It may be an obvious thing to try from our point of view, but it may not be obvious that it would help them from their point of view. They might not even be able to do so without discovery because AIX is based on a version of UNIX older than Linux. In order to find such problems they'd need an up-to-date version, and a x86 version at that. Perhaps they have access to that, perhaps not.
In any case, it's not a foregone conclusion that SCO infringing on Linux in general would help IBM in any way. (Actually I'd argue that it doesn't, although it would reflect on the character of SCO.) If they did it it'd be more of a gift to the Linux community. This isn't like the BSD case where BSD had a single clear owner who was already involved in the suit; IBM owns very little of Linux and probably none of the part of it that SCO would have used.
It's one of those things I'd like to see is all.
I think the quote was, "as much as 50%." There is a hell of a lot of BSD in SVR4. That certainly seems to have pushed them to a fast settlement (and they got off cheap!) but there were a variety of other things that probably would have shot them down too -- many of which are still going to be true in a case against Linux.
One of the primary issues, not decided by the judge but hinted strongly at, is that 32V may actually be in the public domain. In that light the decision to put it out under a BSD license was a kind of damage control; if it's out under a loose license then most likely no one will test the validity of the original copyright in court.
This case may well reopen that can of worms seeing as the only case of obvious copying they've pointed out is rooted in 32V.
I rather hope that IBM is doing/has done its own code commonality inspections because it seems highly likely that there is GPLed code in SCO's product (that's the easy way to compatibility you know). If so that would tarnish their case badly, although it's not very likely to be as damning as it was in the BSD case.
One of the things I find most amusing about their claims of open source being lax on IP protection is that it's been my experience that code pilfering is quite common in closed source projects. Certainly we know it happened at least twice in the history of SysV -- once wholesale in SVR4, and again in R5. And I would suspect it happened again when Caldera implemented Linux compatibility.
I kind of hope IBM or some other SCO source licensee does their own code analysis. My bet is that there are many more lines of code pilfered from open source in SCO stuff than vice versa. SCO is really only getting huge infringement numbers by counting whole subsystems as infringing, using theories of "derivative" that are unlikely to hold up.
Go take a look at the BSD lawsuit papers (various links posted around the net). The judge's opinion where he denied the preliminary injunction against BSDI is really quite remarkable.
We used to also blast control sequences straight to the terminal (since the default in BSD 4.2 and 4.3 was to allow anyone to write to any terminal). The one that we used a lot was the "hard reset" sequence of the vt220, which dropped the RS232 line and triggered a logout, but people rapidly reconfigured the terminals to ignore that. My favorite was to send a lot of nulls since that was more or less invisible but effectively locked up their terminal.
Of course people dealt with this by adding commands to their .login to disable public writeability of their terminal, so the way I dealt with that was to try to grab a descriptor to their tty between the start of login and when the .login script executed (these were the days of the vax, that was a reasonably large window) and just hang onto it in case I wanted to bomb them later.
Oh, the days of having that much free time.
I didn't know who wrote the first one, but I'd written one in I believe the fall of 1984 (could have been that winter). Not that I thought I was first, but it was at least pretty early. Nobody had heard the words "computer virus" before, and I certainly didn't use them. I called it a "self-replicating program." In my version I hooked the command interpreter for Apple DOS's "catalog" command and made it copy itself in place on whatever disk it was looking at. Simple and effective -- and benign, since all it did was replicate (although a few variants did more amusing things like change the catalog output subtly).
I knew that was pretty early, but it turned out that there were at least two earlier viruses on the Apple -- both done at colleges circa 1982. The only one I remember was done at I think Texas A&M, and IIRC theirs were substantially more sophisticated than mine.
Oh look, Google even knows about the Texas virus:
http://yarchive.net/risks/early_virus.html
If the musician wants people to do it, that's one thing. Many do; remember Janis Ian? She's using this as a marketing system, and it's apparently working very well for her (album sales up 300% or so last I heard).
But there is a big difference between the musician giving you permission to hand these things out as a marketing campaign and, say, me putting my entire 700 album collection spanning 500 artists online for everyone to just take as they please.
Isn't there?
I concur that there are some cases where illegally copying the stuff is the only way you're going to get it. The only time I've ever used Napster or Kazaa, for instance, was to try to locate a copy of Weird Al Yankovitch's _Peter and the Wolf_ which has been off the market for more than a decade. I've offered up to $80 for a legal copy of this disc and still been unable to buy it. If they refuse to sell it to me I don't have a whole lot of problem with copying it illegally. (Not that it helped, I couldn't find more than one track of that CD even using Kazaa, so I gave up and my whole MP3 collection is still legal.)
But hey, if you go look at what people are really downloading lots of, and who is downloading it, by and large you're talking popular music and urban US residents. In other words, songs that these people could get easily even if we ignore internet retailers like Amazon. It's not some guy in Idaho trying to download songs by Francine! (Local Boston band, check 'em out.)
Still, as I said elsewhere, the number of people doing wholesale downloading is pretty small at the moment, largely because those with the time and bandwidth to do it are an exceedingly small part of the population. It doesn't make it right, though, and I still fail to see why these people ought to be immune to prosecution. What they're doing is illegal after all.
I think, for instance, that there's every reason that the RIAA should go after people for bulk distribution of music owned by their members. It's illegal, you know. If their members want you to pass the stuff around for marketing purposes, they'll release it that way (and many bands and some labels do exactly that). That means that if the RIAA is beating on you for illegal music swapping, I support that action. What other technique do they have to get people from doing this?
If you mean funding the people that rip off musicians, that's another thing -- but that's not the RIAA, that's the labels. I am a fan of the smaller labels, and try to buy product directly from the band where possible (since although the label still gets their share, the band gets part of what the retailer would have gotten).
There are several very substantial differences between mp3 sharing and radio. For instance, radio broadcasts are ephemeral. The listener can't go back and listen to the song again unless they record it. And recording songs wholesale off the radio is difficult both because it must happen in realtime and because the music industry regulates preannouncement of tracks. Radio listening and recording is, therefore, not a significant loss of revenue for the music seller.
Broadcast is traditional marketing, no question about it. You can argue, and I would agree, that P2P allows viral marketing that was difficult with old media, and I'll talk more about that in a minute. Regardless, the fact remains that there are people who are not treating mp3 file trading as a sampling system but as an acquisition system. And when it crosses that line it crosses over between beneficial to the artist to being detrimental.
I am of the opinion that the people who have been doing this have had at best marginal impact on music sales, largely because the domain of people who can possibly download substantial quantities of music is quite small. It requires, for instance, a lot of bandwidth to download a single album in better than real time. Today that kind of bandwidth is still relatively rare, along the lines of 3% of the total population. As such, it's ridiculous for the RIAA to claim that downloading has killed sales to the tune of 10% or more; there just aren't enough people with the time and capability to download that much music to have that much effect.
I'll not disagree that RIAA members are concerned with loss of control over music distribution, although I would be rather surprised if they were as worried about that as you might think. It's been the case for years and years that artists could make and distribute there own albums, even do so cheaply, and yet the music industry managed to survive. The fact of the matter is that the primary limitation of growth of an artist's market is not the distribution system but rather market awareness. It is the very rare case when viral marketing of the sort that P2P provides boosts an unknown artist to superstardom. I would be surprised if you could point out even one case of that ever happening, particularly since at some point the artist will have to get his stuff played on the radio, and in these days of Clear Channel this is an expensive proposition. There is, therefore, a natural limit to how far artists will be able to go without the help of a major label who can fund broadcast-based marketing.
It's difficult to prove, but my opinion in the matter is that the only reason music sales fell by as little as they did in a tough economy, with tough competition from alternatives like DVDs, and with the industry raising prices in the face of those, is because MP3s have made music so much more accessible that many people have gone out and bought more. I know I have.
But that's today. What if we extrapolate out what is likely to happen as broadband penetration increases to the saturation point? That small percentage of people who just go out and download whatever they want rather than buying it will almost certainly grow with it and become much more than a marginal impact.
And that's what the RIAA has to be afraid of. It's not control of the artists because so long as they're a big money pool they will win the marketing game versus person-to-person marketing because broadcast is much more effective.
It's not that downloading is costing them much in the way of money right now, no matter what they're saying in public. It's that if they don't slow down the leakage somehow it'll become a torrent as broadband penetration grows to the point where the average person can do this.
That's not the RIAA talking, that's just a straightforward projec
"You can call a woman a kitten, but never a cat."
In my mind, you're just arguing semantics with that statement, although I'm with you on all the rest of it.
But it's worth remembering that there is a difference between sharing a clip and wholesale downloading. At some point in scale it stops being reasonable at starts being serious theft. When you've got people out there sharing tens of thousands of songs it's hard for me to see that as anything but a big rip-off and very hard for me to see why the RIAA should leave them alone.
I don't envy the RIAA their position, because this technology is going to be very hard for them to stop. And I agree with people who think that if they'd taken a softer stance on internet distribution earlier that they might have been able to leverage the technology rather than fighting it.
As for the musician's compensation, I think it would be very interesting to see if any of the money from these settlements actually made it to a musician. I know which way I would bet. If the musicians benefit from this at all, it's going to be from reduced wholesale copying, and really that's likely to benefit only the most popular musicians.
I'd like to have some sort of connection between the laptop and phone for doing internet connectivity and, perhaps most importantly, managing the phone's contact list. But a USB wire would do the trick just fine, as it does for my Palm.
And, since it interferes with 802.11 which I use nearly 100% of the time, I'm certainly not motivated to use it for anything other than intermittent device communication.
I think I'd rather just have 802.11 devices, seeing as those are getting pretty ubiquitous.
My only significant issue with 802.11 is that it is much too difficult to manage if you don't want to leave the thing open to the world. I'm thinking of two scenarios I've run into:
- Inconsistent behavior. I have a couple of wireless bridges in my house. The Linksys bridges work pretty much as I expect, wherein the MAC address of the bridge is the one that I have to put in the "allowed MAC address" list on the AP. But I bought a D-Link AP/bridge and couldn't get anything on the far side of the bridge to talk. Turns out that it forwards the MACs for its connected devices rather than using its own, so I had to list the MAC of every device that was a client of the bridge. Of course nothing in the documentation mentioned this particular behavior.
- Debugging connectivity problems is hard. You're adding a new device, and it's not talking. Why not? Could be wrong SIID, but probably it's the wrong WEP settings. Sometimes I have to enter the keys as ASCII, sometimes hex, sometimes hex padded with some zeros. But it could also be that I misread the MAC address of the client (that had me stymied for hours once; turned out that B was actually an 8).
What I would like to see is an evolution of 802.11 client software such that they can self-organize with checks. For instance, I would really like to be able to have my AP notify me that a new client wants to join, identify the device as best possible, and allow me to say "yes" or "no." If I approve it, I'd like the client to be configured properly by the server.In this way configuration would be nothing more complicated than picking the SIID from a drop down or typing one in.
While I'm thinking of 802.11 enhancements, there's no reason that consumer-oriented APs cannot do a better job of actively notifying you of something. Some of them support syslog, which is not really much help to Windows people and a bit arcane for a lot of Linux people. Why not use SMTP to send notifications via email? I'd love to be notified whenever someone tries to join my AP....
Which doesn't make the G5/Opteron/etc any less cool, just not really "first." I'd take any one of them....
So I hit Dell's website and at educational pricing the servers they bought run around $4k apiece. Which means that this solution should be very price/performance competitive with the VT cluster.
I hit the UT page and found that the $38M number came from a press release about their investment in quite a bit of stuff, including the "Institute for Computational Engineering and Sciences (ICES), a new center for interdisciplinary research and graduate study in the computational sciences." I.e. at least one new building.
When I got my Zaurus, which didn't have a PalmReader, I hit Baen for books. The HTML format books were barely readable. I ended up finding a program that could read the PalmDoc format and just stuck with books that weren't encrypted. There are a lot of them out there available from Fictionwise.com, although not usually mainstream stuff.
I haven't tried Mobipocket yet, so I can't compare that to the PalmReader experience. Soon, though.
Frankly, I don't much care if the books have DRM or not, but if it does have DRM I think the PalmReader approach is a very nice compromise. I can "lend" a book to someone by beaming it to them and unlocking it with my credit card. But they can't do the same thing unless I give them the card number, which I won't. So you retain some of the flexibility of the paper book, but rampant copying is not possible.
Smart. Very smart.
Indeed, that statement was intended to pack some irony. One of my favorite books (perhaps the only one they forced me to read in high school that I actually thought was worth reading and re-reading).
But it's true even at the individual level. I routinely carry ten ebooks around in my palmtop. The palmtop I carry anyway for it's organization features. I'd need a big backpack and a strength building program to carry ten paper books.
As for minimum technology for maximum interaction, how have newspapers done against TV?
Answer: TV practically destroyed them. Newspapers still exist, but they have nowhere near the ubiquity and penetration they had prior to TV. Yet TV is a lot of technology for something that gives very little interaction. Moreover, TV proves the points that people don't really care so much for the paper experience that they wouldn't switch, and that they'll pay money (even a lot of money) for a viewer.
Nor is that the only example of people moving from paper to electronic. Have you used the web lately? Did you know that even a decade ago the only way to get timely information was paper journals? That product information was mailed to you in paper pamphlets?
The web demolished entire printing industries. And yet the web has all the same downsides that Asimov pointed out.
Someone will say, "yea, but the web improved immediacy." That's true, but that wasn't the only reason, nor even the primary reason. It won, largely, because of economics. Let's illustrate.
Someone here earlier said that a paperback cost about $1.20 to print, so there wasn't much savings in ebooks. He forgot about warehousing and shipping and such, but let's just call it $1.20 and presume the new costs of ebooks are a wash (they aren't, it's not even close, but we'll presume that anyway). If the publisher can sell the ebook for the same money as a regular book, that means they pull in another $1.20 per book. That represents a very substantial jump in profit.
Trust me, if they can figure out a way to get us to buy ebooks they will do it. There's more money to be made. And with DRM, they can substantially close the borrow and resell hole.
To go mainstream they'll have to subsidize the readers (or palmtops will have to be more ubiquitous) but ebook-capable devices can currently be produced for under $20 if they care to do it ... and the price drops every year. There is an inflection point coming; it will almost certainly happen before 2010.
The economics of paper books will become noncompetitive with ebooks within the next decade. And when that happens, the market will flip.
It's already happened in a bunch of cases. I don't know about you, but I used to have a bookshelf full of references so I could get my work done. Today I have only a couple of books, and they're more tutorial-style than reference. I get virtually all reference material from electronic stuff. Virtually all help material from electronic stuff too. In fact, most software publishers provide practically no paper documentation these days.
In many respects I consider this a step down in usability, but distribution costs dominated the equation from the point of view of the producers, and since we didn't have a choice in the matter we got these things rammed down our throats.
You will have to use ebooks whether you like it or not. It won't happen this year, or next, but by the middle of the next decade it will be difficult to find many texts in paper format.
This change is going to have some really widespread impacts. Consider what this is going to do to the bookstore, for instance. We probably won't have "bookstores" so much as "book kiosks." Not the same buying experience, and a big step down IMO, but those kiosks would be able to sell you almost any book that has ever been published and cost vastly less than a big storefront.
It's a brave new world.
People are making too much of B&N's dropping of ebooks. Of course they didn't sell very many of them - they started out offering nothing but Microsoft stuff. Who wants to read books on a PC? Short battery life on laptops (if you have one) and a lot of bulk makes that a terrible experience. And Microsoft's palmtops don't have enough market to give much of a market to sell to. That was a losing proposition from day one.
The only viable "ebook" readers out there are palmtops. The form factor is the closest to a real book. And if you're talking about palmtops, the biggest market by far is PalmOS devices. It's like seven times bigger than the nearest competitor. Yet B&N didn't really even try to support them.
Eventually they also started offering stuff in Adobe format. DRM issues aside, have you tried to use the Adobe reader on a Palm? It's a complete piece of junk. First you've got to download a bunch of software on the PC side so it can format the book for you. Ok, fair enough. It took 20 minutes (!) to format the last book I bought -- this on a very nice Athlon 1900+ box. 20 minutes! That's ridiculous. And when it got done it had done page breaks right in the middle of words. If you're going to spend that much time formatting stuff to look good on my device, you can at least get word breaks right! On top of that their reader on the palm device poorly uses screen real-estate, doesn't make use of the larger screen of my Clie either, and for some moronic reason the "pages" it shows are larger than the physical screen so every two or three page-downs you do you get half a screen of text.
The user experience for the Adobe reader blows so bad that I will actively avoid that format in the future. Whoever thought that was acceptable should not only be fired, they should be locked up so they can never be involved in technology again.
I contrast that to using the PalmReader. I've been using it since 1998, back when it was the PeanutReader. This is a simple little reader that makes excellent use of screen real-estate, including enhanced displays like my Clie. It's fast. The books are just normal PRC files on the palm so it's really easy to get them on there. It has DRM too, in the form of typing the credit card # you used to purchase the book, but this is not terribly intrusive.
I keep buying PalmReader books. And two of the companies that are selling them, Palm Digital Media and Fictionwise, are managing substantial year-over-year growth.
Maybe that's because they offer a pretty good user experience.
For all the faults of ebooks, there are some really nice things about them. Key among them for me is that since I already carry my palmtop almost everywhere, I always have a book in hand. That means I can read something I like rather than the Enquirer standing in line at the grocery store, for instance. Since I can easily load half a dozen novels onto even a small PalmOS device I can pick and choose my reading material according to mood rather than availability, and I don't get stuck being bored on the train because I finished one. And with backlighting I can read the things in bed without the light bugging my wife.
I'd like a little bit larger screen. I'd like to not have to worry about battery life (a significant issue on the Clie, less so on the old monochrome Palms). I suspect we'll have good solutions to both of these as electronic paper hits the streets over the next couple of years.
But if you want me to go out and pay $300 for an ebook reader, or you want to force the books down my throat in some gawdawfully difficult to use format, then you can forget it.
Ebooks are going to win in the long term, that's simple economics. It's going to be cheaper, a lot cheaper, for the publishers to subsidize the readers and save on warehousing and shipping and recycling the physical books.
It's also interesting that way back in the dawn of computing equipment they did use propagation delay as a way of doing storage. Mercury delay lines in particular. Not only that, the people that used them noticed that the tubes made noise and found ways to play tunes by saving the appropriate data. Google "mercury delay lines" and you'll find a few notes about the technology.
I actually might be overstating that, that's all of the package update messages I get (typically one or two a day), and I think only a subset of those are for security issues. I'm on two different notification lists so it'd be easy to confuse the two.
But even if most of them are security issues there are two things you should remember about the things that are being reported. The first is that almost all of those are in applications, not in the OS proper or even in its core set of features (typical shell programs and servers). These would be the kinds of issues you'd get with add-on applications in Windows, which are never reported in Windows vulnerability reports. The second is that almost none of these issues are significant security concerns. I don't really care very much if some little-used user program has a buffer overflow; I care a lot if sshd, my MTA, or apache has been compromised.
Not that we haven't seen a few of those big ones, mind you: sendmail and bind have been particularly problematic (which is why I run an alternative MTA and don't expose DNS services externally). Even so, I spend way less time keeping my BSD and Linux servers patched up than Windows; the latter seems to have two critical patches a week on average, and every $%&^^# one of them requires a system reboot.