Two words:AIX and MacOSX both based on Mach kernels and both excellent and fast operating systems.
MacOS X, clearly, but AIX? I believe you are mistaken about AIX being a Mach derivative. It sure as hell doesn't look anything like Mach to me. My guess would be "SysIII derivative". That seems most likely since AIX predated OSF/1 and SysV. This opinion appears to be supported by information exposed in the SCO/IBM lawsuit.
I think the only other commercial Mach derivative currently in production is Tru64, aka Digital Unix, aka OSF/1.
Microsoft has no problem with open source, HPFS and their TCP stack were both derived from BSD, and Bill only knows what else. What they don't like is the GPL because it doesn't give them the ability to modify the code in proprietary ways, as BSD's license does.
In any case the technique is not rocket science; any remotely competant filesystem implementor could make their own version pretty easily. I've seen several implementations layered on top of UFS, for instance, and of course HPFS doesn't use the original BSD technique.
Thanks for the defense:-). The thing that I think is funny is that intra-track reads are so much faster now, what with the ability to read sectors back-to-back, twice the rotational speed, and four times the number of sectors on a single track. What used to be about a factor of fifteen difference between intra-track read performance and inter-track performance is upwards of a hundred now. If it weren't for hyper-aggressive caching NTFS would positively suck.
Anyway, the other guy claimed that NTFS was not a derivative of HPFS. That is not my understanding; I would have learned about the etymology in either the NTFS internals book or Showstopper!, both of which were from Microsoft, but a bit of work with Google shows that the belief is widespread (for whatever reason). In any case HPFS is a very direct descendent of FFS; really the only significant thing they did was simplify the block allocator so they didn't need to know the disk geometry.
So no matter how I look at it, Microsoft knew about the technique no later than 1989. Too bad the only thing they put it in was OS/2, which nobody used.
A drive is not one dimensional, it is three dimensional: Rotation, platter, track. It is this geometry that BSD FFS takes advantage of to avoid large fragmentation-related delays, since while there may only be one "optimal" sector to use there are quite a few that are "nearby" in terms of rotation, seek, or platter.
Consider an average eide hard drive: 10ms seek rate, ata100 interface.
If you need to save a 100kb file, it will take 10ms (1/100th of a second) to seek to the first block, and then, assuming everything is perfect, it will take 100MB/sec / 100kb = 1/1000th of a second to write the file... so, seeking to the start of the file took 10 times as long as writing it!
This gross simplification actually trivializes the real effect. The 10ms seek figure is an average track-to-track seek delay between adjacent tracks. The farther apart the tracks are the longer a seek takes (it's more or less linear although there is a per-seek overhead). You also don't deal with the fact that you're going to have to perform seeks on larger files no matter what.
I note that there is a similar latency issue with head switches.
There is a big difference between the delay necessary to pull a sector off of a track adjacent to where the heads currently are and one 1000 tracks away -- the delay can be an appreciable fraction of a second just for that single seek.
The problem with simplistic filesystem block allocators is they do not weight their block allocations according to seek time. Usually they just pick whatever's first in the free list. This results, over time, to random block placement and therefore seek times that will on average approach 50% of worst case. I'd have to look closely to give a good figure with today's drives, but order-of-magnitude degredation is certainly possible. What you would prefer is blocks placed such that they're within a few percent of best case if at all possible.
This is not hard to do, and to my knowledge BSD FFS was the first to attempt it -- and it was wildly successful at it.
As an aside, I've never seen a fragmentation analysis program that took noncontiguous-but-well-placed into account. It's entirely possible to create a block layout that those programs think is awful that is within 90% of optimum. I think, actually, that BSD FFS would typically show up that way although I never investigated.
I also note that smart block allocation makes a defragmenter's job a heck of a lot easier.
You may find that the fact that fragmentation doesn't seem to be so bad these days, on Windows systems at least, is that they're doing extensive caching and pre-reading of disk blocks. If there were a way to tune down the size of the filesystem cache to mid-1980s levels (say, 8k:-) you'd be a little more cognizant of it. I dunno about you, but my Windows systems tend to have a couple hundred megabytes of filesystem cache... enough to hide a lot of sins. Use a "constrained" XP system with like 128M (it bugs me that that's now considered small) and ho boy will you feel it.
No, FFS does not do after-the-fact defragmentation. It attempts to allocate blocks that have low seek latency as files are extended. For the most part this avoids the problem entirely.
If you ever wondered why there is a "soft limit" on FFS filesystems, the reason why is that its allocator's effectiveness breaks down at about the point where the filesystem is 90% full. So they sacrifice 10% of the filesystem space so that they can avoid fragmentation problems. It's not a bad tradeoff, particularly these days.
I didn't know that HFS+ used an after-the-fact defragmentation system, but they've been around for awhile too. Significant research was done into such things as part of log-based filesystem research in the early 1990s (reference BSF LFS and Sprite). You had to have a "cleaner" process with those filesystems anyway (to pick up abandoned fragments of the log and return them to the free pool) so it made sense to have it also perform some optimization features.
Ok, we have this filesystem fragmentation buggaboo that's been plaguing MS-DOS and Windows for more than twenty years. We've got a whole industry built around building tools to fix it.
That would be well and good if the problem were otherwise insurmountable. But, it turns out, we've known how to minimize, if not entirely eliminate, filesystem fragmentation for twenty years now - since the introduction of the BSD Fast File System.
It doesn't take expensive (in time, if not in money) tools. All it takes is a moderately clever block allocation algorithm - one that tries to allocate a block close in seek time to the previous one, rather than just picking one at random.
The fundamental insight that the authors of FFS had was that while there may only be one "optimal" block to pick for the next one in a file, there are tens of blocks that are "almost optimal" and hundreds that are "pretty darn good." This is because a filesystem is not a long linear row of storage bins, one after another, as it is treated by many simplistic filesystems. The bins are stacked on top of each other, and beside each other. While the bin right next to you might be "best", the one right next to that, or in another row beside the one you're on, or in another row above or below, is almost as good.
The BSD folk decided to group nearby bins into collections and try to allocate from within collections. This organization is known as "cylinder groups" because of the appearance of the group on the disk as a cylinder. Free blocks are managed within cylinder groups rather than across the whole disk.
It's a trivial concept, but very effective; fragmentation related delays on FFS systems are typically within 10% of optimum.
This kind of effectiveness is, unfortunately, difficult to achieve when the geometry of the disk is unknown -- and with many modern disk systems the actual disk geometry is falsely reported (usually to work around limits or bugs in older controller software). There has been some research into auto-detecting geometry but an acceptable alternative is to simply group some number of adjacent blocks into an allocation cluster. In any case, many modern filesystems do something like this to minimize fragmentation-related latency.
The gist of this is that Microsoft could have dramatically reduced the tendency towards fragmentation of any or all of their filesystems by doing nothing else but dropping in an improved block allocator, and done so with 100% backward compatibility (since there is no change to the on-disk format).
Maybe it was reasonable for them to not bother to so extravagantly waste a few days of their developers' time with MS-DOS and FAT, seeing as they only milked that without significant improvement for eight or nine years, but it's hard to explain the omission when it came to Windows NT. NTFS is a derivative of HPFS which is a derivative of FFS. They had to have known about cylinder group optimizations.
So the fact that, in 2004, we're still seeing problems with filesystem fragmentation absolutely pisses me off. There's no reason for it, and Microsoft in particular ought to be ashamed of themselves. It's ridiculous that I have to go and degragment my WinXP box every few months (which takes like 18 hours) when the FreeBSD box in the basement continues to run like a well-oiled machine despite the fact that it works with small files 24 hours a day, 365 days a year.
Hey Microsoft: You guys have like fifty billion bucks in the bank (well, ok, 46 or 47 billion after all the antitrust suits) and yet you can't even duplicate the efforts of some hippy Berkeleyite some twenty years after the fact? What's up with that?
(I mean "hippy Berkeleyite" in an affectionate way, Kirk.:-)
no PDAs in the lower price range can even come close to the screens on the Zauruses.
I'm not sure that's really true (and several follow-up articles claim otherwise) but even if it is the most important technical attribute of an ebook is not necessarily its screen resolution. I would argue instead that battery life is more imporant in an ebook, at least once screen size (more than resolution) gets to the point of "good enough."
The old monochrome Palms had excellent battery life, more than good enough for ebooks. Their problem was that the screen was so small and had such poor resolution that they could display very little per page. Even so, I read a lot of books on my Palm 5000... then Palm V... then Visor Edge.
I much prefer the reading experience on my Clie NR70; the long screen puts a reasonable amount of text up at a time, and its resolution is easily good enough to be extremely readable. I rather wish, though, that I could sacrifice color for improved battery life: 8 hours is about the best I manage, and that's just not enough while travelling. I end up dragging along a recharger, and even that doesn't help on airplanes.
But even more important than battery life and screen size/quality is simply software availability. If you can't get readers for DRMed formats you're locked out of most of the ebooks on the market, and virtually all of the contemporary stuff. DRMed documents are widely available in only four formats: Adobe, Microsoft, Mobipocket, and PalmReader. Adobe's format sucks rocks in every way possible (poor quality software, poor pagination, long conversion times before you can download to the PDA, poor use of screen real-estate, totally inflexible DRM). I haven't used Microsoft's. Mobipocket has the best reader ergonomics of anything I've used, and its DRM is not egregious although I don't like the four device limit. PalmReader gives the best overall experience of any DRMed format -- very usable reader and the DRM is unlocked by typing in a credit card number; no device lock at all, and yet I'm not real inclined to hand out that number to many people.
In my mind, and in my experience with the 5000L, the Zaurus loses right out of the gate because of its lack of DRMed ebook reader software -- easily the most important trait if you want to read ebooks on your device. Without that you can't get content, and without content you don't really have an ebook. Additionally the 5000L had pretty poor battery life, but perhaps that improved with later models (the screen readability certainly did, the 5000L was pretty dark). The 8 hours my Clie gives me is bare minimum for battery life. I'd really like to see at least 20 hours.
So I say "skip the Zaurus" at least as an ebook reader. It's expensive and it just doesn't have the software you need for the job. That's too bad, because other than that it's a pretty nice platform.
I used an Edge for a couple of years. Its form factor and excellent battery life were big pluses, but its screen doesn't hold a candle to the likes of the Sony PEG-NR70 I use now. But the thing that was a killer was that the Edge was just not very durable. I broke two of them in a year in day-to-day use; they'd just stop turning on reliably.
Now, I'm not exactly nice to my PDAs, but I've never had any other PDA give me that problem. That includes the original Palm (back in 1997), the Palm V I replaced it with, the Zaurus 5000L, and my current Clie.
I believe the issue was that the package was just too flexible. Stress it a bit and it would flex and mess up the internals. I never did it enough to crack the screen, but clearly the electronics weren't very happy with what I was doing to it. But I could be wrong about the cause, maybe it just couldn't deal with getting banged around a bit.
If you're going to go with monochrome for better battery life you'll be better off going with one of the Sony devices (I think the SJ20 was the best of that generation). They are extremely well built.
Probably. I'm not sure, since I rarely used a web browser even when I had one on my Handspring. The basic issue is that the Palm devices are rarely connected to the internet, making web browsing more a matter of web clipping. Since there is excellent PalmOS web clipping software out there, like Plucker, it's difficult for me to consider this a crippling problem.
I have yet to meet anyone who uses a PalmOS device for anything outside of traditional PDA functions,
Maybe you should read some more of this thread. It seems a lot of people are using them for ebook readers too. I certainly am, and have been since 1999. I have worked with other platforms (notably the Zaurus 5500L) but despite vastly superior basic functionality (especially networking, no other PDA I've used networked as well as the Zaurus) it was a loser in day-to-day use (generally poor organizer applications, even if you pay for aftermarket stuff) and even more of one when it came to ebooks because of its inability to read any of the commercial (DRMed) formats.
Many here may disagree that inability to work with DRM is an issue, but I want contemporary novels and there's just no way to get a broad selection of them without DRM -- and more specifically, without either Microsoft Reader or Palm Reader.
That limits the useful ebook readers to PocketPC and Palm, but I find the Palm devices to be much better values than PocketPC -- they work more smoothly, they have better battery life, they have more applications, and they are quite a bit less expensive.
The e-ink devices look like they will be much better for reading text than a traditional LCD on a PDA or e-book reader.
Yes, they do. Moreover the low power requirements of e-ink should improve battery life by one to two orders of magnitude over the high-quality LCD displays. And, really, battery life is the primary limitation of most of these things.
It's been a long time coming but the new Sony ebook proves that the technology is very close. I think that one will be a loser (too much money for too little capability) but as soon as we see that display move onto PDAs it's going to change everything in portable computing.
4-5 hours is about right with the backlight at full intensity. You can about double that (~8hrs) by dropping it to lowest intensity; this hurts readability in bright light, but it is fine for indoors.
I solved the battery life issue with my PEG-NR70 by buying a power converter that I use when I'm reading in bed or when I take trips. I can still run it flat when on long multileg airplane flights, but it's quite usable.
...and have tried out an array of these devices, everything from the original Palm to the beta Zaurus.
Skip the Zaurus, you won't be able to get readers for the locked formats. I presume the many other flaws I found with my Zaurus have been smoothed over since then, but it just doesn't matter if you can't get a decent reader.
You're pretty much left with PocketPC and Palm devices. I'm not a fan of the PPC devices because they have poor battery life and a difficult to use interface and cost more than anything else, but since you can get all of the maintream readers for them they may be worth a look. I can't say I like their screens that much but they're a lot better than a low-end Palm.
My personal choice, the one I've read dozens of books on, is a Clie PEG-NR70 (the flip-screen dragonball one). I don't believe this, or even its follow-on PEG-NX70 with the ARM chip, is still available but its big, sharp screen is the best I've seen on a palmtop. Sony has really done a knock-down job on screen quality.
If I were to buy one right now, and I'm thinking about it because my NR70 has been beat to death, I'd probably get PEG-TH55. It seems to have the same screen, or at least a similar one, but I like the form factor better than the NR70.
Palm's Tungsten T3 is very interesting, and I really like the way it collapses, but fails for me because there's no lid to keep you from smashing the screen -- you have to get one of those awful bulky armor cases.
As always YMMV, but as I said I've been exceptionally pleased with the Sony device. At $400 it's not cheap, but at least it's not a dedicated ebook:-).
About ebook readers: I haven't used Microsoft's reader at all so I have no comment about it. Adobe's palmtop ebook reader is total junk, the least usable most irritating ebook reader I've ever seen. It paginates strangely despite forcing you to spend a long time "formatting for your device" and has the worst DRM of any of them. Mobipocket is my favorite reader in terms of interface, but its DRM is mildly restrictive, allowing only 4 devices for any locked ebook. The PalmReader offers the best DRM flexibility (it's key is your credit card number; you probably don't want to give that away) and a clean, usable interface. When I am reading locked books I opt for Palm format whenever possible for DRM flexibility, but with unlocked books I prefer Mobipocket.
So far I've had excellent luck finding ebooks in Palm and Mobipocket formats. www.fictionwise.com has the greatest format flexibility of the ebook providers I've tried.
It would be great if Sun GPLed Solaris; whatever version!
I'm not sure that at this point I'd care. It would have been more interesting circa 1994. Today what would that really get us? We have two completely open source OSs already and one of them has continued to mature. Why not just use what we've got?
The whole idea of Sun GPLing Solaris is laughable. They cannot do that, they're based on SVR4 and most likely have a contract similar to that of IBM (you know, the one they're being sued over right now). So don't believe it.
I'm not sure I would use Photoshop versus Gimp as a general indication of the quality of professional versus OSS applications. Gimp is more or less typical of OSS (kind of a mismash of things, not too great of a UI, but generally gets the job done) but Photoshop is one of the best commercial applications on the planet.
I've used Gimp for years but had a pretty hard time getting it to run on the Mac. (On Linux it was easy, of course.) As a result of having moved to a Mac for my day-to-day use I was actively looking around for a Mac-native alternative. Photoshop was obvious but at $600 there was little chance of me buying it.
When I bought a new camera it came with Elements which, for many operations, was a lot easier to use than Gimp and generally did what I needed. What Elements lacked -- 16-bit support, support for RAW format images, support for macros -- seemed more a matter of convenience than anything else. Gimp didn't have these things either and I survived. After using Elements I had a hard time believing that Photoshop CS was worth a $500 price premium, much less the $600 premium over Gimp.
But I'm here to tell you that it is, and it's not just for those features. Gimp is good, but CS is great, probably the single best software package I've ever used. It's not always intuitive but then again what it's trying to do is really complicated.
I bought CS through a local photography school at a significant discount ("only" $260) or I might never have taken the plunge. But, having done so, I can see how Adobe gets away with charging that much: The product really is that good, that much better than anything else like it. They'll get their full license fee if or when I go professional and I will smile when I write the check.
I'm a great fan of paying for good software; being a software jockey myself I know how hard it is to write and how valuable it is once written. Unfortunately of late I've been paying a lot of money for what I consider pretty mediocre software. Moreover an increasing amount of that goes to Microsoft despite my ever-shrinking numbers of Microsoft systems and significant reduction in purchase of Microsoft tools from when NT was my primary development system. As their competition evaporated their software got substantially more expensive, way out of line with actual improvements. That bugs me and that has a lot to do with why I run a lot of OSS software. In large part I'd forgotten that commercial software can be very good.
MacOS X, for instance, is not only the best version of MacOS I've ever used, but perhaps the best general-use operating system I've ever used. They've done an astounding job of taking the power of UNIX and grafting a good UI to it without breaking it. From 1997 to 2002 I had slowly replaced most of my NT systems with Linux, which worked better for many things I wanted to do. But over the course of the last couple of years my household went from not having had a Mac since 1994 (when I started using NT) to having three.
That happened despite Apple's price premium, and despite the fact that every new release of Linux improves its strength and usability. It happened not because Linux fell out of my favor, but because MacOS X was that much better. I certainly wouldn't have said that of MacOS 9.
Apple, like Adobe, charges a price premium. But like Adobe the premium is worth it, especially for laptops.
In contrast it's hard to stomach paying Microsoft hundreds of dollars for XP, which is really only marginally better than the NT they've been selling for more than a decade. It's a little fancier looking and they finally put disk defragmenting software in the box, but really it's not that much better and it sure does use a lot of memory doing what it's doing. XP is a very nice version of Windows but they're dragging you over a barrel at the prices they charge for the quality you get. I might not even mind that much, given that it's a pretty robust system in general, but this wh
The principal issue Windows has with security that most of the other OSs don't is that it fails to compartmentalize administration spaces from user spaces. There is effectively no security on applications or the filesystem; they run fully privileged all the time.
As a result anything that wants to break down security has no barriers to it beyond whatever the application provides. That is insane.
You can vastly improve security by separating these spaces, making applications run in the user spaces as much as possible, and requiring authentication to bridge the spaces.
UNIXen have done this for decades. You might argue that "UNIX is hard to use." That has generally been the case, but not universally. MacOS X does a pretty good job of providing a smooth interface on top of UNIX and does so without breaking down the UNIX security structure. Users do not run applications in privileged mode without authentication, for instance. If you want to install new capabilities, you must authenticate to do it. Thus it is difficult for viruses and malware to insinuate themselves.
If the application and OS data is not writable by normal users, and they must somehow authenticate to get write privileges, viruses have a much harder time propagating.
It is for this reason that more and more UNIX software that used to run in the old days (e.g. ftp) now runs as an unprivileged user now. You can break in through flaws in the application, perhaps, but the damage you can do is limited. This was a good security practice that became mainstream back in the 1980s.
Getting back to "user friendly" systems, the Mac is not even the best example of a nice user-friendly UNIX box. I'd argue that some of the network appliances are much better at it. I had a Cobalt box, for instance, that had a fine point-and-click web interface to UNIX system management. It was really easy to use; you didn't have to know squat about UNIX, or even that the box was running UNIX. And it required authentication for every change request. This was mediated by the browser so it wasn't even noticed by the user.
Or just look at the Tivo. Is Tivo easy to use? Oh yea. How many security problems have you heard of with Tivo boxes? None, because getting unauthorized software onto that box is a bitch. Hmm. Maybe it's possible to be both easy to use and very secure.
I note that you can set up a Windows box to be pretty secure if you want to. I used to do it as a matter of course. The problem with doing that is that there is no easy way to run an application as a different user, which means you have to bounce back and forth between the Administrator login and your user login. This was a royal pain in the neck in NT and 2K, although in XP it's pretty easy (but not nearly as sweet as it is on MacOS!).
Unfortunately Microsoft has never promoted this configuration as best practice. In fact, they've implicitly discouraged it by making it hard to create a system that separates administrator and user spaces. There is no installation system that takes authentication into account, much less tries to enforce it. And they've actively promoted wide-open systems by shipping them that way by default.
Because Microsoft does not even try to ship systems configured relatively securely it's no surprise that many applications do not operate correctly if installed on a fully secured system. That is unforgivable now that they've had Windows with security out there for eleven years. They should have steadily increased default security to force application vendors to use best practices.
When my daughter's account has to have administration privileges to run her Winnie The Pooh game, it really is not a surprise that there are a lot of these problems. And that is blame we can lay squarely on bad configuration practices promulgated by Microsoft more than any requirement to make the software easy to use.
If Microsoft really were interested in security then the next OS release would ship
I bought a copy of WP8 on Linux. It produced very nice looking documents (beat the tar out of StarOffice at the time, and Applix was just all around bad) but it was the worst thing out there in terms of actual interface.
Oh, the interface itself wasn't too horrible, but it had loads of very irritating screen repaint problems.
I hope they do better this time, although Open Office and others have progressed to the point where it's kind of hard to see why you'd pay money for an office suite -- especially for Linux.
Napster2 hasn't been in business long enough to know if it's going to fail or not. I think you ought to give them a year, at least.
And even if it does fail, that need not be indicative of the viability (or lack thereof) of the whole market. It might just be that they have a bad business model.
Apple's iTunes and iPod provide synergy with each other but iTunes limits itself to only those with iPods (or effectively does, since converting from AAC to MP3 to use with other players is a pain). Nice for them in the niche market, but a limiter in the absolute sense.
I think Napster2's problem, and what will limit iTunes even within the iPod market, is simply how much the stuff costs relative to physical media. I know that many people, myself included, aren't really willing to pay $10+ for only the bits when the (higher quality) physical media is similarly priced. That's just a bad deal, and that's why of the 700+ albums I have in MP3 format every single one of them came from a CD. If you want to give me less, you have to charge less; think $.50 a track, $5 an album. I'd do that.
I don't really think the WMA format is limiting them, seeing as the only player currently on the market that doesn't support that is the iPod (excepting, of course, the first generation MP3 players; they all did by the 2nd generation, quite a coup for Microsoft if you ask me). Though, honestly, I'd prefer not to use either AAC or WMA -- unless, again, they give me even more of a price break for providing the stuff in a locked format. At $.25 a track, $2.50 an album, I'd do that. At those prices I can afford to buy again to migrate.
But I don't see those prices coming down until the record industry screws up CD media to the point where most people won't buy it. Moreover, the record industry may kill their own online sales by offering CDs with both raw tracks and WMA encoded tracks, something they appear to be doing.
I suppose if you're using Linux for idealistic reasons there might be some reason to feel guilty, but my primary reason for using Linux was that it was a very cost-effective way to run UNIX rather than Windows.
OS X gives me a nice solid UNIX with a much nicer interface and better vendor support (both software and hardware). Thank You Very Much.
Besides, Apple's laptops are Really Nice and I haven't yet had anything like the same number of little annoying problems that I've had with both Windows and Linux on laptops. (This may well be related to generally superior hardware than you find from PC vendors who are engaged in cutthroat competition, but whatever.)
I actually bought our household's first Mac for my wife because I got rather tired of reinstalling Windows (and all her apps) for her every 3 months when it puked all over itself. I wanted something that wouldn't require a lot of admin effort on my part, but that was still easy enough to use and with enough software that she wouldn't pull her hair out.
It worked, although there were some teething pains as we both learned to use it and dug up the applications she needed.
I ended up liking her laptop so much that when it came time to replace my Linux laptop I went with a Mac for myself too. The silly things work well.
Well, that would have been an interesting idea if we'd thought of it at the time, but we didn't. In the end we just needed it to work for a few months until they replaced the whole phone system anyway. It was the very best 1950s technology... in 1986.
Slashdot Mirror
It wouldn't be very Microsoftish to not try to make money with it :-).
MacOS X, clearly, but AIX? I believe you are mistaken about AIX being a Mach derivative. It sure as hell doesn't look anything like Mach to me. My guess would be "SysIII derivative". That seems most likely since AIX predated OSF/1 and SysV. This opinion appears to be supported by information exposed in the SCO/IBM lawsuit.
I think the only other commercial Mach derivative currently in production is Tru64, aka Digital Unix, aka OSF/1.
proprietary adj. something that is used, produced, or marketed under exclusive legal right of the inventor or maker
I submit that it's not "proprietary" if you have to give it to everyone else :-).
In any case the technique is not rocket science; any remotely competant filesystem implementor could make their own version pretty easily. I've seen several implementations layered on top of UFS, for instance, and of course HPFS doesn't use the original BSD technique.
Anyway, the other guy claimed that NTFS was not a derivative of HPFS. That is not my understanding; I would have learned about the etymology in either the NTFS internals book or Showstopper!, both of which were from Microsoft, but a bit of work with Google shows that the belief is widespread (for whatever reason). In any case HPFS is a very direct descendent of FFS; really the only significant thing they did was simplify the block allocator so they didn't need to know the disk geometry.
So no matter how I look at it, Microsoft knew about the technique no later than 1989. Too bad the only thing they put it in was OS/2, which nobody used.
A drive is not one dimensional, it is three dimensional: Rotation, platter, track. It is this geometry that BSD FFS takes advantage of to avoid large fragmentation-related delays, since while there may only be one "optimal" sector to use there are quite a few that are "nearby" in terms of rotation, seek, or platter.
If you need to save a 100kb file, it will take 10ms (1/100th of a second) to seek to the first block, and then, assuming everything is perfect, it will take 100MB/sec / 100kb = 1/1000th of a second to write the file... so, seeking to the start of the file took 10 times as long as writing it!
This gross simplification actually trivializes the real effect. The 10ms seek figure is an average track-to-track seek delay between adjacent tracks. The farther apart the tracks are the longer a seek takes (it's more or less linear although there is a per-seek overhead). You also don't deal with the fact that you're going to have to perform seeks on larger files no matter what.
I note that there is a similar latency issue with head switches.
There is a big difference between the delay necessary to pull a sector off of a track adjacent to where the heads currently are and one 1000 tracks away -- the delay can be an appreciable fraction of a second just for that single seek.
The problem with simplistic filesystem block allocators is they do not weight their block allocations according to seek time. Usually they just pick whatever's first in the free list. This results, over time, to random block placement and therefore seek times that will on average approach 50% of worst case. I'd have to look closely to give a good figure with today's drives, but order-of-magnitude degredation is certainly possible. What you would prefer is blocks placed such that they're within a few percent of best case if at all possible.
This is not hard to do, and to my knowledge BSD FFS was the first to attempt it -- and it was wildly successful at it.
As an aside, I've never seen a fragmentation analysis program that took noncontiguous-but-well-placed into account. It's entirely possible to create a block layout that those programs think is awful that is within 90% of optimum. I think, actually, that BSD FFS would typically show up that way although I never investigated.
I also note that smart block allocation makes a defragmenter's job a heck of a lot easier.
If you ever wondered why there is a "soft limit" on FFS filesystems, the reason why is that its allocator's effectiveness breaks down at about the point where the filesystem is 90% full. So they sacrifice 10% of the filesystem space so that they can avoid fragmentation problems. It's not a bad tradeoff, particularly these days.
I didn't know that HFS+ used an after-the-fact defragmentation system, but they've been around for awhile too. Significant research was done into such things as part of log-based filesystem research in the early 1990s (reference BSF LFS and Sprite). You had to have a "cleaner" process with those filesystems anyway (to pick up abandoned fragments of the log and return them to the free pool) so it made sense to have it also perform some optimization features.
That would be well and good if the problem were otherwise insurmountable. But, it turns out, we've known how to minimize, if not entirely eliminate, filesystem fragmentation for twenty years now - since the introduction of the BSD Fast File System.
It doesn't take expensive (in time, if not in money) tools. All it takes is a moderately clever block allocation algorithm - one that tries to allocate a block close in seek time to the previous one, rather than just picking one at random.
The fundamental insight that the authors of FFS had was that while there may only be one "optimal" block to pick for the next one in a file, there are tens of blocks that are "almost optimal" and hundreds that are "pretty darn good." This is because a filesystem is not a long linear row of storage bins, one after another, as it is treated by many simplistic filesystems. The bins are stacked on top of each other, and beside each other. While the bin right next to you might be "best", the one right next to that, or in another row beside the one you're on, or in another row above or below, is almost as good.
The BSD folk decided to group nearby bins into collections and try to allocate from within collections. This organization is known as "cylinder groups" because of the appearance of the group on the disk as a cylinder. Free blocks are managed within cylinder groups rather than across the whole disk.
It's a trivial concept, but very effective; fragmentation related delays on FFS systems are typically within 10% of optimum.
This kind of effectiveness is, unfortunately, difficult to achieve when the geometry of the disk is unknown -- and with many modern disk systems the actual disk geometry is falsely reported (usually to work around limits or bugs in older controller software). There has been some research into auto-detecting geometry but an acceptable alternative is to simply group some number of adjacent blocks into an allocation cluster. In any case, many modern filesystems do something like this to minimize fragmentation-related latency.
The gist of this is that Microsoft could have dramatically reduced the tendency towards fragmentation of any or all of their filesystems by doing nothing else but dropping in an improved block allocator, and done so with 100% backward compatibility (since there is no change to the on-disk format).
Maybe it was reasonable for them to not bother to so extravagantly waste a few days of their developers' time with MS-DOS and FAT, seeing as they only milked that without significant improvement for eight or nine years, but it's hard to explain the omission when it came to Windows NT. NTFS is a derivative of HPFS which is a derivative of FFS. They had to have known about cylinder group optimizations.
So the fact that, in 2004, we're still seeing problems with filesystem fragmentation absolutely pisses me off. There's no reason for it, and Microsoft in particular ought to be ashamed of themselves. It's ridiculous that I have to go and degragment my WinXP box every few months (which takes like 18 hours) when the FreeBSD box in the basement continues to run like a well-oiled machine despite the fact that it works with small files 24 hours a day, 365 days a year.
Hey Microsoft: You guys have like fifty billion bucks in the bank (well, ok, 46 or 47 billion after all the antitrust suits) and yet you can't even duplicate the efforts of some hippy Berkeleyite some twenty years after the fact? What's up with that?
(I mean "hippy Berkeleyite" in an affectionate way, Kirk. :-)
I'm not sure that's really true (and several follow-up articles claim otherwise) but even if it is the most important technical attribute of an ebook is not necessarily its screen resolution. I would argue instead that battery life is more imporant in an ebook, at least once screen size (more than resolution) gets to the point of "good enough."
The old monochrome Palms had excellent battery life, more than good enough for ebooks. Their problem was that the screen was so small and had such poor resolution that they could display very little per page. Even so, I read a lot of books on my Palm 5000 ... then Palm V ... then Visor Edge.
I much prefer the reading experience on my Clie NR70; the long screen puts a reasonable amount of text up at a time, and its resolution is easily good enough to be extremely readable. I rather wish, though, that I could sacrifice color for improved battery life: 8 hours is about the best I manage, and that's just not enough while travelling. I end up dragging along a recharger, and even that doesn't help on airplanes.
But even more important than battery life and screen size/quality is simply software availability. If you can't get readers for DRMed formats you're locked out of most of the ebooks on the market, and virtually all of the contemporary stuff. DRMed documents are widely available in only four formats: Adobe, Microsoft, Mobipocket, and PalmReader. Adobe's format sucks rocks in every way possible (poor quality software, poor pagination, long conversion times before you can download to the PDA, poor use of screen real-estate, totally inflexible DRM). I haven't used Microsoft's. Mobipocket has the best reader ergonomics of anything I've used, and its DRM is not egregious although I don't like the four device limit. PalmReader gives the best overall experience of any DRMed format -- very usable reader and the DRM is unlocked by typing in a credit card number; no device lock at all, and yet I'm not real inclined to hand out that number to many people.
In my mind, and in my experience with the 5000L, the Zaurus loses right out of the gate because of its lack of DRMed ebook reader software -- easily the most important trait if you want to read ebooks on your device. Without that you can't get content, and without content you don't really have an ebook. Additionally the 5000L had pretty poor battery life, but perhaps that improved with later models (the screen readability certainly did, the 5000L was pretty dark). The 8 hours my Clie gives me is bare minimum for battery life. I'd really like to see at least 20 hours.
So I say "skip the Zaurus" at least as an ebook reader. It's expensive and it just doesn't have the software you need for the job. That's too bad, because other than that it's a pretty nice platform.
Now, I'm not exactly nice to my PDAs, but I've never had any other PDA give me that problem. That includes the original Palm (back in 1997), the Palm V I replaced it with, the Zaurus 5000L, and my current Clie.
I believe the issue was that the package was just too flexible. Stress it a bit and it would flex and mess up the internals. I never did it enough to crack the screen, but clearly the electronics weren't very happy with what I was doing to it. But I could be wrong about the cause, maybe it just couldn't deal with getting banged around a bit.
If you're going to go with monochrome for better battery life you'll be better off going with one of the Sony devices (I think the SJ20 was the best of that generation). They are extremely well built.
Probably. I'm not sure, since I rarely used a web browser even when I had one on my Handspring. The basic issue is that the Palm devices are rarely connected to the internet, making web browsing more a matter of web clipping. Since there is excellent PalmOS web clipping software out there, like Plucker, it's difficult for me to consider this a crippling problem.
I have yet to meet anyone who uses a PalmOS device for anything outside of traditional PDA functions,
Maybe you should read some more of this thread. It seems a lot of people are using them for ebook readers too. I certainly am, and have been since 1999. I have worked with other platforms (notably the Zaurus 5500L) but despite vastly superior basic functionality (especially networking, no other PDA I've used networked as well as the Zaurus) it was a loser in day-to-day use (generally poor organizer applications, even if you pay for aftermarket stuff) and even more of one when it came to ebooks because of its inability to read any of the commercial (DRMed) formats.
Many here may disagree that inability to work with DRM is an issue, but I want contemporary novels and there's just no way to get a broad selection of them without DRM -- and more specifically, without either Microsoft Reader or Palm Reader.
That limits the useful ebook readers to PocketPC and Palm, but I find the Palm devices to be much better values than PocketPC -- they work more smoothly, they have better battery life, they have more applications, and they are quite a bit less expensive.
Yes, they do. Moreover the low power requirements of e-ink should improve battery life by one to two orders of magnitude over the high-quality LCD displays. And, really, battery life is the primary limitation of most of these things.
It's been a long time coming but the new Sony ebook proves that the technology is very close. I think that one will be a loser (too much money for too little capability) but as soon as we see that display move onto PDAs it's going to change everything in portable computing.
I solved the battery life issue with my PEG-NR70 by buying a power converter that I use when I'm reading in bed or when I take trips. I can still run it flat when on long multileg airplane flights, but it's quite usable.
Skip the Zaurus, you won't be able to get readers for the locked formats. I presume the many other flaws I found with my Zaurus have been smoothed over since then, but it just doesn't matter if you can't get a decent reader.
You're pretty much left with PocketPC and Palm devices. I'm not a fan of the PPC devices because they have poor battery life and a difficult to use interface and cost more than anything else, but since you can get all of the maintream readers for them they may be worth a look. I can't say I like their screens that much but they're a lot better than a low-end Palm.
My personal choice, the one I've read dozens of books on, is a Clie PEG-NR70 (the flip-screen dragonball one). I don't believe this, or even its follow-on PEG-NX70 with the ARM chip, is still available but its big, sharp screen is the best I've seen on a palmtop. Sony has really done a knock-down job on screen quality.
If I were to buy one right now, and I'm thinking about it because my NR70 has been beat to death, I'd probably get PEG-TH55. It seems to have the same screen, or at least a similar one, but I like the form factor better than the NR70.
Palm's Tungsten T3 is very interesting, and I really like the way it collapses, but fails for me because there's no lid to keep you from smashing the screen -- you have to get one of those awful bulky armor cases.
As always YMMV, but as I said I've been exceptionally pleased with the Sony device. At $400 it's not cheap, but at least it's not a dedicated ebook :-).
About ebook readers: I haven't used Microsoft's reader at all so I have no comment about it. Adobe's palmtop ebook reader is total junk, the least usable most irritating ebook reader I've ever seen. It paginates strangely despite forcing you to spend a long time "formatting for your device" and has the worst DRM of any of them. Mobipocket is my favorite reader in terms of interface, but its DRM is mildly restrictive, allowing only 4 devices for any locked ebook. The PalmReader offers the best DRM flexibility (it's key is your credit card number; you probably don't want to give that away) and a clean, usable interface. When I am reading locked books I opt for Palm format whenever possible for DRM flexibility, but with unlocked books I prefer Mobipocket.
So far I've had excellent luck finding ebooks in Palm and Mobipocket formats. www.fictionwise.com has the greatest format flexibility of the ebook providers I've tried.
Enjoy,
I'm not sure that at this point I'd care. It would have been more interesting circa 1994. Today what would that really get us? We have two completely open source OSs already and one of them has continued to mature. Why not just use what we've got?
The whole idea of Sun GPLing Solaris is laughable. They cannot do that, they're based on SVR4 and most likely have a contract similar to that of IBM (you know, the one they're being sued over right now). So don't believe it.
I've used Gimp for years but had a pretty hard time getting it to run on the Mac. (On Linux it was easy, of course.) As a result of having moved to a Mac for my day-to-day use I was actively looking around for a Mac-native alternative. Photoshop was obvious but at $600 there was little chance of me buying it.
When I bought a new camera it came with Elements which, for many operations, was a lot easier to use than Gimp and generally did what I needed. What Elements lacked -- 16-bit support, support for RAW format images, support for macros -- seemed more a matter of convenience than anything else. Gimp didn't have these things either and I survived. After using Elements I had a hard time believing that Photoshop CS was worth a $500 price premium, much less the $600 premium over Gimp.
But I'm here to tell you that it is, and it's not just for those features. Gimp is good, but CS is great, probably the single best software package I've ever used. It's not always intuitive but then again what it's trying to do is really complicated.
I bought CS through a local photography school at a significant discount ("only" $260) or I might never have taken the plunge. But, having done so, I can see how Adobe gets away with charging that much: The product really is that good, that much better than anything else like it. They'll get their full license fee if or when I go professional and I will smile when I write the check.
I'm a great fan of paying for good software; being a software jockey myself I know how hard it is to write and how valuable it is once written. Unfortunately of late I've been paying a lot of money for what I consider pretty mediocre software. Moreover an increasing amount of that goes to Microsoft despite my ever-shrinking numbers of Microsoft systems and significant reduction in purchase of Microsoft tools from when NT was my primary development system. As their competition evaporated their software got substantially more expensive, way out of line with actual improvements. That bugs me and that has a lot to do with why I run a lot of OSS software. In large part I'd forgotten that commercial software can be very good.
MacOS X, for instance, is not only the best version of MacOS I've ever used, but perhaps the best general-use operating system I've ever used. They've done an astounding job of taking the power of UNIX and grafting a good UI to it without breaking it. From 1997 to 2002 I had slowly replaced most of my NT systems with Linux, which worked better for many things I wanted to do. But over the course of the last couple of years my household went from not having had a Mac since 1994 (when I started using NT) to having three.
That happened despite Apple's price premium, and despite the fact that every new release of Linux improves its strength and usability. It happened not because Linux fell out of my favor, but because MacOS X was that much better. I certainly wouldn't have said that of MacOS 9.
Apple, like Adobe, charges a price premium. But like Adobe the premium is worth it, especially for laptops.
In contrast it's hard to stomach paying Microsoft hundreds of dollars for XP, which is really only marginally better than the NT they've been selling for more than a decade. It's a little fancier looking and they finally put disk defragmenting software in the box, but really it's not that much better and it sure does use a lot of memory doing what it's doing. XP is a very nice version of Windows but they're dragging you over a barrel at the prices they charge for the quality you get. I might not even mind that much, given that it's a pretty robust system in general, but this wh
As a result anything that wants to break down security has no barriers to it beyond whatever the application provides. That is insane.
You can vastly improve security by separating these spaces, making applications run in the user spaces as much as possible, and requiring authentication to bridge the spaces.
UNIXen have done this for decades. You might argue that "UNIX is hard to use." That has generally been the case, but not universally. MacOS X does a pretty good job of providing a smooth interface on top of UNIX and does so without breaking down the UNIX security structure. Users do not run applications in privileged mode without authentication, for instance. If you want to install new capabilities, you must authenticate to do it. Thus it is difficult for viruses and malware to insinuate themselves.
If the application and OS data is not writable by normal users, and they must somehow authenticate to get write privileges, viruses have a much harder time propagating.
It is for this reason that more and more UNIX software that used to run in the old days (e.g. ftp) now runs as an unprivileged user now. You can break in through flaws in the application, perhaps, but the damage you can do is limited. This was a good security practice that became mainstream back in the 1980s.
Getting back to "user friendly" systems, the Mac is not even the best example of a nice user-friendly UNIX box. I'd argue that some of the network appliances are much better at it. I had a Cobalt box, for instance, that had a fine point-and-click web interface to UNIX system management. It was really easy to use; you didn't have to know squat about UNIX, or even that the box was running UNIX. And it required authentication for every change request. This was mediated by the browser so it wasn't even noticed by the user.
Or just look at the Tivo. Is Tivo easy to use? Oh yea. How many security problems have you heard of with Tivo boxes? None, because getting unauthorized software onto that box is a bitch. Hmm. Maybe it's possible to be both easy to use and very secure.
I note that you can set up a Windows box to be pretty secure if you want to. I used to do it as a matter of course. The problem with doing that is that there is no easy way to run an application as a different user, which means you have to bounce back and forth between the Administrator login and your user login. This was a royal pain in the neck in NT and 2K, although in XP it's pretty easy (but not nearly as sweet as it is on MacOS!).
Unfortunately Microsoft has never promoted this configuration as best practice. In fact, they've implicitly discouraged it by making it hard to create a system that separates administrator and user spaces. There is no installation system that takes authentication into account, much less tries to enforce it. And they've actively promoted wide-open systems by shipping them that way by default.
Because Microsoft does not even try to ship systems configured relatively securely it's no surprise that many applications do not operate correctly if installed on a fully secured system. That is unforgivable now that they've had Windows with security out there for eleven years. They should have steadily increased default security to force application vendors to use best practices.
When my daughter's account has to have administration privileges to run her Winnie The Pooh game, it really is not a surprise that there are a lot of these problems. And that is blame we can lay squarely on bad configuration practices promulgated by Microsoft more than any requirement to make the software easy to use.
If Microsoft really were interested in security then the next OS release would ship
Oh, the interface itself wasn't too horrible, but it had loads of very irritating screen repaint problems.
I hope they do better this time, although Open Office and others have progressed to the point where it's kind of hard to see why you'd pay money for an office suite -- especially for Linux.
And even if it does fail, that need not be indicative of the viability (or lack thereof) of the whole market. It might just be that they have a bad business model.
Apple's iTunes and iPod provide synergy with each other but iTunes limits itself to only those with iPods (or effectively does, since converting from AAC to MP3 to use with other players is a pain). Nice for them in the niche market, but a limiter in the absolute sense.
I think Napster2's problem, and what will limit iTunes even within the iPod market, is simply how much the stuff costs relative to physical media. I know that many people, myself included, aren't really willing to pay $10+ for only the bits when the (higher quality) physical media is similarly priced. That's just a bad deal, and that's why of the 700+ albums I have in MP3 format every single one of them came from a CD. If you want to give me less, you have to charge less; think $.50 a track, $5 an album. I'd do that.
I don't really think the WMA format is limiting them, seeing as the only player currently on the market that doesn't support that is the iPod (excepting, of course, the first generation MP3 players; they all did by the 2nd generation, quite a coup for Microsoft if you ask me). Though, honestly, I'd prefer not to use either AAC or WMA -- unless, again, they give me even more of a price break for providing the stuff in a locked format. At $.25 a track, $2.50 an album, I'd do that. At those prices I can afford to buy again to migrate.
But I don't see those prices coming down until the record industry screws up CD media to the point where most people won't buy it. Moreover, the record industry may kill their own online sales by offering CDs with both raw tracks and WMA encoded tracks, something they appear to be doing.
OS X gives me a nice solid UNIX with a much nicer interface and better vendor support (both software and hardware). Thank You Very Much.
Besides, Apple's laptops are Really Nice and I haven't yet had anything like the same number of little annoying problems that I've had with both Windows and Linux on laptops. (This may well be related to generally superior hardware than you find from PC vendors who are engaged in cutthroat competition, but whatever.)
I actually bought our household's first Mac for my wife because I got rather tired of reinstalling Windows (and all her apps) for her every 3 months when it puked all over itself. I wanted something that wouldn't require a lot of admin effort on my part, but that was still easy enough to use and with enough software that she wouldn't pull her hair out.
It worked, although there were some teething pains as we both learned to use it and dug up the applications she needed.
I ended up liking her laptop so much that when it came time to replace my Linux laptop I went with a Mac for myself too. The silly things work well.
Well, that would have been an interesting idea if we'd thought of it at the time, but we didn't. In the end we just needed it to work for a few months until they replaced the whole phone system anyway. It was the very best 1950s technology ... in 1986.