Tom's Hardware Looks At WinFS
Alizarin Erythrosin writes "Tom's Hardware Guide has an article about the new WinFS file system. The article talks first about some of the problems and advantages with FAT[16|32] and NTFS, then talks briefly about WinFS. Here is the summary: 'Microsoft is breaking new ground with Longhorn, successor to XP. The upcoming WinFS file system will be the first to be context-dependent, and promises to make long search times and wasted memory a thing of the past. Today, THG compares it to FAT and NTFS.' Personally, I still have reservations about using a relational database to keep track of files. Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be."
Now that every Windows user is going to be running a SQL variant on their system, imagine the bugs and holes that are going to be in this. Now THIS will be interesting to see.
Fundamentalism stops a thinking mind.
In any event, Microsoft still has a few years to refine this "Future Storage" file system, so all judgements concerning it's effectiveness are a bit premature on some levels. Then again, it's always good to start planning as early as possible - especially when you consider that it may be introduced into Windows Server 2003 some time during the next 12-18 months. For now, all we can base judegement off of is Microsoft marketing hype and comparisons to existing file systems that operate in a similar way.
A relational database setup should do wonders for file search and access. Most filesystems today weren't designed with 200 Gb drives and millions of files in mind.
I keep thinking back to my Amiga when a 40 Mb hard drive was huge. Hell, I have a keyfob with more storage space now! Can you imagine AmigaDOS (not FFS, the old, slow one) on a 200 Gb drive?
Learning HOW to think is more important than learning WHAT to think.
Haven't they basically been trying to implement this since the days of Cairo? Seems the 'revolutionary new file system' gets announced for every Windows release that is several years away, then vanishes by the time the release takes place.
.technomancer
I'm not so sure about the choice thing. I think they're building a lot of new functionality into using WinFS and you'd lose all that if you didn't use it. Sorta like running XP in 2K mode.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
It sounds interesting, to say the least. Maybe Microsoft has finally come up with something innovative. I'd be interested to try it out and see how it feels, and if it really can do everything they say it can. As usual, though, security could be an issue. A virus could wreak havoc if it found a way into the database.
Also, I'm wondering if they'll finally give up on that stupid drive lettering. I don't see any reason why that ever had to exist, and now that they're doing an overhaul of the whole filesystem, it seems like a good oportunity to get rid of it. You'd think, since they try to be user friendly, that they would want to give devices and partitions names instead of letters. I do still see it in that screenshot, but things could change by the time it's released.
Hey did the person who modded me "Troll" READ THE FUCKING ARTICLE ? DID YOU ? Read it. It's 6 pages of how FAT and NTFS work, along with the classic line that VFAT "was the first system that could write long file names". The LAST PAGE is the only page that talks about WinFS. It's titled "Conclusion: WinFS - The Future". It regurgitates that WinFS is based on the upcoming file system for SQL server, which is *modelled on* a relational database, and gives all the usual hype about how you'll be able to search by content, blah blah. There is not a shred of any information, let alone anything new. The whole fucking article is filler.
In Soviet America the banks rob you!
Yeah, but I bet you it'll be like Windows XP's theoretical ability to use FAT 32 - it can read it, but it won't actually let you format in FAT32 when doing an installation.
And guess what? Its a proprietry file system that other OS's won't read *coughlinuxcough*
So.... that'll be yet another proprietry lock-in technique from M$ then. Anyone surprised? A show of hands please....
An infinite number of monkeys will eventually come up with the complete works of
Looks like I was wrong - or, actually, right all along. Musta been a slow news day?
"Really, there's no difference between the file systems for the normal user!"
Except when FAT munches their registry and the computer won't boot. NTFS is a huge stability enhancement.
Unless they can keep the overhead to a minimum, I can't see it being as efficient as a file system should be.
They may have goals other than efficiency. Security, probably. But probably also security's perverted uncle, DRM. As DRM becomes more common, and we "pirates" look for more innovative ways to get around it, locking us out of our hard drives would seem to be a logical if not downright necessary step. It's pretty obvious that a lot of entities out there would benefit greatly from a model where we don't really OWN our computers, we just lease the right to use them. I mean, look, they're already floating the notion out there, at least for software and entertainment media, that we don't really OWN ANYTHING, and it's not that much of a stretch for that to become literal truth, aside from the hardware, which will be as impervious to meddling as they can possibly make it. (You decide who "THEY" might be, but I have a long list with a lot of familiar names on it.)
How technically difficult would it be for, say Microsoft, to "rent" out portions of your hard drive to various media and software providers, using a combination of hardware and software controls to assure those companies that you and I ABSOLUTELY CANNOT meddle with "their" product while we (temporarily) posess it? A database-driven file system provides exactly the access control and accountability that would be required to successfully implement something like that.
To ensure perfect aim, shoot first and call whatever you hit the target
yeah,
Because these same people will really quickly adapt to a gear or a foot instead of START.
And they really like to call me with questions when they buy a new printer and the install CD doesn't work, and then I find out that it is incompatable.
But their favorite thing is when they decide to make the family tree the family tree maker they buy doesn't run.
Links in Windows (9x anyway) cause all sorts of confuision too, like when copying the whole start menu to a floppy does not allow them to pirate all of their programs to someone else.
No, that just points to the program it is not the real program. Really the easiest thing to do is buy another copy and give it to them (we are talking playing card games, not $300 office packages).
I like and use Linux nearly exclusivly at home (I have SanctionII installed at home on Windows for work reasons), but I do not like to foist it upon my relatives. That is just rude, I like having a huge library of decent slightly less pretty slightly harder to use apps for free (in every sense). Most people like having easier to install (if you don't know anything), cheap and ubiquitose apps and hardware. And I can respect that.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Linux can not safely write to NTFS, not even NTFSv1.2 even though it has been around since 1994. The lack of documentation makes it so that some aspects of updating the metadata and indexes cannot be done safely in all situations.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Thats ok, windows wasn't a real operataing system when it ran on top of DOS. hmmmmm. come to think of it, it still isn't..
Windows95,98,ME debatable...
However, WINNT, Win2k, and WindowsXP are very much their OWN OS, and DO NOT HAVE ANYTHING TO DO WITH DOS. Where have you been?
How can it be that NT is over 10 years old, and people are still think it is based on DOS...
And how come people still think that Windows9x and the NT based Windows variants are even remotely the same after all these years?
Geesh...
It just can't be good. Using MS SQL as a database is bad enough, I couldn't imagine depending on it as a file system.
I've dealt with a lot of bad products from MS, but SQL Server is not one of them. What exactly is wrong with it? It's been rock solid to me, with good features. I suppose the licensing might be brutal, but I don't care so much about that.
That's your problem, not Microsoft's.
Paranoia at its purest. If you were truly paranoid, you'd realize that Microsoft wouldn't go this far just to stop Linux from supporting NTFS. They'd just change a few important things about how NTFS works. They wouldn't throw it out unless there was a good reason to do so. And no, Linux having nearly decent support for NTFS doesn't qualify as a "good reason".
Can't agree more.There is much more info on Paul Thurrotts site;http://www.winsupersite.com/reviews/longhorn_ 4008.asp
written some time ago, I guess. reading Toms Hardware 'review' was a complete waste of time
How do you store, retrive & manipulate META data with find/grep/awk.
Now you can, by storing it as part of the file name, but it would suck.
BeOS did this very well, and MS has had time to copy, it should be pritty good.
Wow, I should not post when knackered.
A Mac desk accessory / extension combination, I believe, that came out in 1990 or so. It allowed you to instantly retrieve lists of file on your hard disk based on name and content (by "instant" I mean the list of matching files changed as you typed your query).
On my IIci it was perfectly fast. Faster than BeOS queries on a dual 603 box.
It took a little time to build your index, but keeping it up-to-date was pretty painless. Apple's developer CDs used to ship with On Location indices on them.
and may I ask, how many people have 1000 40kb files on a hard drive let alone one that is 500MB in size?
Three words...
Internet Temporary Files
A thousand small files is nothing with the default IE cache settings if you have a large drive.
Learning HOW to think is more important than learning WHAT to think.
...MSWindows inches closer to where BeOS was 7 or 8 years ago.
Right, but in general, journaling is a hack. The BSD softupdates concept is both cleaner and faster, and accomplishes nearly the same thing. To be fair, all of NTFS, ext3, reiserfs, BeOS's FS, and the new OSX FS have some advanced journaling features, but the concept itself should be more cleanly handled. Much like databases should be ACID compliant, filesystem writes can and should occur in such a manner that no external journal is required.
--
Use Vobbo for Video Blogs
Of course. Simply put it in a second stream of some other file. Not even MS experts would look there...
Hey did the person who modded me "Troll" READ THE FUCKING ARTICLE ? DID YOU ? Read it. ... The whole fucking article is filler.
;)). Now it looks like the two paragraphs per "article page" are just used to keep the ads from bumping into each other. The whole article could've fit on one page, but I guess that doesn't get very many banner impressions when you know that Slashdot will link to your story, no matter how high the "filler" ratio.
Tom's Hardware must have degenerated while I wasn't looking. The articles used to be full of detail, two printed pages long per "digital article page" (what you see on the screen
Not really. A database FS is one of the few new advances that add real power to systems. If you think about the human thought process, they don't tend to think of things in terms of strict hierarchies. They tend to look at a set of items from multiple viewpoints, possibly creating a hierarchy within a given subset, but rarely subject all items to the same hierarchy. There are lots of places where a hierarchical filesystem doesn't really make sense. Is there any sane method of organizing a documents directory? Whenever I try to do it, I generate huge, complex hierarchies with only a few files in each directory. Organizationally, its elegant, but its a pain to traverse. Instead, if I simply shove all documents into a single store, I can use the database mechanism to view the file set in a way that is most useful for the task at hand. A media file directory is another good example. Its tedious to organize media files into a strict hierarchy, and very limiting to have to deal with that hierarchy every time, especially if you want a different view of the data. For example, usually, I organize music files by artist, then album. But what if I want to quickly access files based on catagory (blues) or period (80's)? Since the artist trait is usually orthogonal to the catagory and period traits, a simple hierarchy fails to adequately describe the situation. This is why jukeboxes like iTunes or MusicMatch are getting so popular: they are very flexible with how songs are presented to the user. The whole idea here is to take the power and efficiency of something like the iTunes interface, and apply it to file management in general. If a simple query language is supported, such a scheme could potentially be very usable via a command line as well.
A deep unwavering belief is a sure sign you're missing something...
I've been reading and contributing responses to Slashdot for years, but this is by far the worst article I've ever seen posted here. I can't believe whoever posted the article on the "front page" of Slashdot actually read the article -- they couldn't have even read the first page.
Right on the first page of the article, the "journalist" who wrote it describes disk storage as "memory". In the "Summary" of the article posted on every page, current file systems are described as wasting "memory". This reminds me of every-day users who confuse their computer running slowly (or literally telling them they don't have enough memory) with the need to delete files from the hard drive -- two completely separate things in most situations. This is all aside from the fact that the article doesn't actually tell you much that anybody who's used computers for more than six months doesn't already know. This guy sounds like some of the kids who come to me interviewing for I.T. positions thinking they've got a leg-up on everyone else because they've got some basic experience with PC's and Windows.
The bottom line is that the guy who wrote this article doesn't have any business writing tech articles without heavy supervision from someone who KNOWS tech, and I don't just mean someone who knows enough to rattle off performance numbers for CPU comparisons (read some other articles on the site). Lastly, Slashdot has no business posting amateurish and misinforming articles like this for the rest of us to waste our time on.
The concept of naming files, and sorting them in directories isn't a very good concept, and the proof of it is looking at how everyone here uses playlists to handle media files.
Another poster mentioned phone numbers. An even better analogy is email addresses. The concept of email addresses and typing them into a TO field isn't a very good concept, and the proof of it is looking at how many people use address books to handle email addresses. Why type in an email address when you can just type in (or select) "tom"?
Thus I have the situation at work where I can't find anyone's email address. I want to send an email to "John Smith" down the hall. But the company exchange server is global, so I have to scroll down an Outlook list poring over 50,000 John Smith entries to make sure I don't accidentally send it to the John Smith in Kuala Lampur instead of the John Smith down the hall. I finally find the right John Smith and I expect to see the email address so I can write it down for later. But no! It's not available! The way my company has Exchange set up there is no actual email to be found. So I can only send email to John Smith from Outlook, because Evolution, KMail, Netscape, etc., keep complaining that "John Smith" isn't a valid address.
If that's the kind of situation you want for my file system, then may I suggest you take a long walk off a short pier. There are valid reasons for file names just as there are valid reasons for email addresses. Just because you use a playlist does not mean that the filenames for your MP3s are irrelevant.
This obviously doesn't require a database filesystem, but I think it's gotten to the point where we *need* some way to assign metadata to files and then deal with files *soley* by metadata.
We (my, myself and the mouse in my pocket) are already dealing with files solely by metadata, because the path of a file is metadata. Maybe it's not metadata that you want or care for, but there's a lot of people that do. I'm all for having a lot of metadata attached to my data. But you haven't explained why we need to eliminate the current metadata in order to get new ones.
p.s. Have you ever seen how the typical Windows user works? There are fifty icons on the desktop in no particular order and every document they create goes into a single "My Documents" directory. What makes people think they won't just shove everything into the same metadata category of "unfiled"? I know if I had to specify four or five different categories every time I had to save some work, I would probably shove a crowbar through my monitor within the first week.
Right now I have the choice of using a file system or a database. Why must this choice be eliminated? Does the concept of a file system offend you so much that you have to eliminate everyone else's use of one? Can't you just go use a database and let the rest of use work the way we want to work?
A Government Is a Body of People, Usually Notably Ungoverned
Usability engineers looked at what users were doing in Windows and they saw that tons of people weren't using the filesystem - at least not directly. They were just putting everything on the desktop. If it was on the desktop, they could find it. They kept folder structures to a minimum and organized things visually (or not at all).
This posed a significant problem, so indexing and searching and abstracting the filesystem was one of the solutions. Instead of having to navigate a filesystem (hard for many users), you just type in what you're looking for and *poof* it appears. Not sure what you're looking for? Start describing it... *poof* it appears.
I'm not saying this is the right solution, but technology is not always about cluster size and performance - especially if the system isn't usable. It will be interesting to see how user friendly this WinFS thing is...
Reread the post again, paying special attention to the word 'when'.
I suspect people confusing DOS kernels and NT kernels is your pet peeve, and it bothers you so much you see it everywhere.
Maybe you should reread your post, you said that it 'still isn't'. - Implying that Windows still isn't an operating system, and with the previous reference to the DOS underpinnings you set yourself up for that interpretation.
Besides, now that we are on the subject, Win9x and its successors also were TRUE Operating Systems, as they handled ALL Input/Output of the OS and the only DOS it relied upon was for compatibility with legacy application or drivers. DOS was basically a 'boot loader' for the Win9x Operating System.
Go look up the terminology of Operting System, and you will find that Win9x easily fits the definition. This is why the Win3.1 box said 'Operating Environment' and Win95 box said 'Operating System'.
Maybe your pet peeve is that some people notice when you make an ass out of yourself when you are so quick to find a reason to bash Windows and yet you still have to find a way to respond.
Geesh...
Actually, in this case, Linux might very well do it first. Reiser4 has all the bits and pieces in there to be a killer DBFS back-end. They're trying to get good file performance out of objects as small as individual XML elements. Throw on a database layer on top (doesn't have to be that featureful for something like this) and you've got yourself a WinFS competitor. I think MS might have done themselves a disservice by throwing these ideas out there this early. Longhorn isn't due out for almost two years. In that time, it may very well be that many of the features touted for Longhorn have been in Linux for months. Remember, this time frame we're talking about is about how long it took the KDE guys to totally rewrite KDE in the 1.0 to 2.0 transition. In the last year, Linux has had several major subsystems totally overhauled. In a year and a half, Linux changes as much as Windows does in a full release cycle (2-3 years). I would not be surprised if Longhorn has some serious competition when it debuts.
A deep unwavering belief is a sure sign you're missing something...
Microsoft loves to create incredibly complicated, undocumented and fragile data structures. Consider word: the internal structure of a word document as itself a filesystem, it has a root, a FAT and a bad block list. If even 1 block is damaged the file is useless. There are few repair tools because the internal layout is secret and undocumented. Access and SQL files are worse. In data recovery we frequently recover 90% of the files from volumes that have thousands of bad blocks or other damage. That wont work with WinFS. Are you going to store you precious digital photos on your $80 WesternDigital 80gb drive with its new 1 year warranty? Microsofts (and WD's) attitude will be that you should have backed it up. How do you easily back-up 80gb anyway?
Much like databases should be ACID compliant, filesystem writes can and should occur in such a manner that no external journal is required.
And how would you propose to achieve that without performance going down the drain?
The guys writing these filesystems are not dumb, and the reasons why journals are used are well considered. Another thing is that ACID compliant databases also use something like a journal to achive the atomicity.
Oh, and forget softupdates, they are _not_ comparable to journaling filesystems, for instance you still need to fsck, it's just faster.
Compare that with one of the funnies manpages I know.
Realistically there isn't any reason why a file system implemented as a transactional database couldn't be as fast as a traditional file system and a whole lot more stable. The only additional overhead that theoretically is built in is file creation/deletion/moving. Reads and writes to disk for most of the better implemented databases tend to be at the cutting edge of what most systems can even push to disk. If they limit the functionality to the few goodies listed in the article it will actually be a joke on MS. This thing has a LOT of potential, ESPECIALLY on low end hardware.
Orthogonal Persistence = leave machine on indefinitely. What happens when errors and/or data corruption occur in core? Planned maintenance involving powering down the machine?
:-)
No it doesn't - it just means that from the perspective of an application, there is no difference between malloc() and open(). You ask for some storage, you get it (unless something goes wrong, of course). You read and write to your bit of storage. At some point it may be in main memory, in some cases it will be on disk. The OS takes care of moving things around, you never see it. In Unix, there are the concepts of main memory, the file cache, the swap space, the file system. On (say) an AS/400 these distinctions simply don't exist outside of the kernel - all disk is swap space, all memory is cache, all memory is allocated from swap, and all cache is flushed when a program exits.
Basically turn everything into memory mappings...and that limits your data size to your address sizes. May not be a problem with 64-bit addressing, but storage is growing exponentially.
64-bit is something new in the PC world, but in the world of professional computing, 64-bit has been around for a long time.
And backups? Seperating data from instructions? Sharing data across heteregeguous systems? Or is the plan EROS everywhere?
IBM solved all of these problems decades ago. I always smirk when Unix people in general and Linux people in particular think they're just inventing something that IBM had back in the 80s
Am I the only one really annoyed at this guys use of "memory" for disk space? I _still_ find customers who can't tell the difference between RAM and HDD, and this guy goes and makes it worse for every twit who thinks they know everything. Yes, I know that one can make a theoretical argument for using the term, but really, in practice, memory is RAM. It's just annoying... I'm surprised to see it at Tom's Hardware...
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
Note that a "relational" or "set theoretic" filesystem does not neeed to mean SQL. SQL is the COBOL of relational systems.
:-( ), and the same file can be in multiple directories, just make the filesystem able to instrospect on a file to determine directory-membership,and perhaps add union, difference and intersection operators on directories (though they could be built in userspace, it'd be more efficient in-filesystem, and e.g. AmigaOS already had union operations.)
Personally, I'd like a set-theoretic FS. You could even do it reasonably easily with a small change to today's technology - just make the (unix-like) filesystem be able to answer, for a given inode, what directories that inode is linked in. Combined with hardlinks (including directory-hardlinks to allow membership of sets by sets to give relational capabilities... i don't buy the "circular reference" argument, one could GC the filesystem.), that instantly gives you a set-theoretic system, where each file can be truly present in a number of "sets" i.e. directories. Consider the statement: "Saying a file has attribute X is equivalent to saying it is a member of the set of all files with attribute X."
If directories are sets (and they are, except they mix in name-assignment too
With "stat -c%i" and "find -inode" in a shell script you can already emulate a lot of this, to a level sufficient to multidimensionally sort your... uh... image library. I might write a k5 story detailing the method, if I can be bothered.
That's a very small amount of metadata. Let's say I've got a picture of mountain that has been digitised and sits on my computer. Here's some meta data I want to store against it:
a) I want to store that it's a jpg file. I am Japanese and see no reason why the file type should be indicated by a small dot shape followed by three symbols left over from the roman empire that stand for some words in a language I don't speak. File name extensions are very archaic technology.
b) I want to record when I took the photograph that this picture represents.
c) I want to record that this photograph is going in my family album
d) I want to record that this is an 'outdoor' photograph
e) I want to record that this photograph is of Mount Fuji
f) I want to record that this particular file is the high-resolution version, suitable for output onto my photo-printer.
g) get the point? I could have a lots of symlinks of this file to folders called 'my photos' and 'outdoor photos' and 'photos taken in July' but that would be a stupid ugly hack. I could call my file:
mount_fuji_july-hi_res-outdoor.jpg
but that would be even more stupid.
Now, at this point someone says "well, if you want all that then just buy a content-management application that sits ontop of the OS and lets you catalog all your stuff."
I think MS has realised that pretty much every file _should_ be in a content management system of some kind. They are simply adding a lightweight CMS to the OS, which seems perfectly sensible to me. That way, other applications can make use of the meta-data the CMS holds. The file open dialogue on all windows apps will, instead of a directory browser have the ability to query the CMS for, say 'most recent versions of my hi res outdoor photos' which seems good to me.
I never fail to be baffled at the degree of inertia in the IT world. I sometimes thing every computer person thinks technology should be frozen at whatever point they got tired of learning new stuff. "File name extensions and symbolic links were good enough for me lad!" It's a weird attitude.
-----
I currently have a 66GB FAT32 partition. I use it to pass data around between XP, Win98 and Linux. Of course, I had to format the thing using Linux, but once I did all was well.
The 32GB limit in XP is done on purpose by MS to 'encourage people to use NTFS'
So does that mean Longhorn will only let you format NTFS partitions to 32GB to 'encourage people to use WinFS'? I shudder at the thought.
Now storing the meta data in a database, which is essentially what WinFS and such are doing, is not as clear a benfit. Personally I can imagine that it would be a very practiacal FS for keeping movies and MP3's on. I don't really see the benefits of running the OS files on that FS though. A lot of unneccesary overhead. (I don't search for files in my OS partition very often.)
BeOS used a metadata enabled fully journaled multithreaded filesystem and it was the bomb.
Mail client? What mail client? You email inbox was a directory in the OS with all the email metadata attributes enabled in the file manager. Mail filters literally became shell scripts. Want to index your MP3s according to artist, album, etc all at the same time? Use the shell scripting and metadata, Luke!
It also does away with the stupid limitation of extensions. When all your data is stored as a datatype in the metadata listing, who needs them?
I think that Microsoft are going a little overboard embedding a database into the filesystem, proper meatdata enabled filesystems are a GOOD thing in my book.
Let's get one thing straight ... many of these features are already available in one form or another and no one uses them.
... I'm not against having an FS that enables you to annotate files outside of the programs that create them. I remember working many years ago with FSs that would allow you to automatically keep the last n revisions, which was very helpful when coding.
How many people click on Properites in M$Word and put in the information?? How many people download files and leave them lying in whatever directory they just happen to fall in.
Don't take me wrong
It's just that I have a hard time getting excited over something that is going to simply bloat a system and the odds are no one will use.
My girlfriend is fairly smart, but she still downloads all her pictures into the default folder, and uses thumbnails to find the ones she wants. She has about 1000 of them, and it only takes here a few minutes to find the ones she wants. It would take here no extra work than what this new FS is suggesting to rename the file and/or store it in another folder
Useful feature, bloatware, Linux beater, or disaster waiting to happen. My guess is all of the above, at one time or another. Some people will use it and spend hours cross-linking files. I'm sure the initial releases will have security or data loss issues until the bugs get worked out. It will take 0.10 minutes for some Linux hacker to reverse engineer the ability to at least read it. And it will probably take up gobs more memory.
It's all a matter of perspective....
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Microsoft can require the bootstrap call routines from a separate DMCA/Patent protected, Microsoft branded, bootstrap ROM, and can control motherboard vendors through licensing for that chip.
Nasty Microsoft if they try that. Someone better get some prior-art out there and QUICK!
--- Nothing clever here: move along now...
Actually The 32 GB limit is purely a microsoft thing to get you to use NTFS. FAT32 can format up to 2 TB. And microsoft will read drives that large it just wont format them that large for you. And there's actually something that will expand that to 4 TB but I can't remember what it is off the top of my head. And no I'm not talking about doublespace or any other compression technologies.
I won't go into the reasons why but I have personally created a 1.2 TB FAT32 partition. Funny thing is that the easiest way I found to format it was in linux.
This idea isn't new... Microsoft as long been trying to nip at the heels of IBM's midrange platforms. The system/38 shipped with a relational-only filesystem over 20 years ago. This filesystem is still alive in the AS/400 and iSeries systems. The advantages really are nice... merging the filesystem and the database, combined with a really smart optimizer, allow you to run a high performance database without having a DBA constantly monitor it. You end up with no tablespaces or any of the rest of the cruft that occurs when you try to build a database using files.
If it were just that, it might be laudable... but what MS is trying to do here is really more nefarious... MS is really trying to rid itself of all non-MS databases on Windows. This is the old IE vs Netscape trick. Why would you buy a real database when you're forced to buy SQL server anyway? Enough people might not know the difference
.... partly..... and barfed.
I know a thing or two about filesystems: I work in the data-recovery business.
This article was written by someone who has some basic details, and has fantasized a lot of incorrect info around it. Bunches of terms are used incorrectly etc. etc.
NTFS is a very well-thought-out filesystem. It can be made to perform well, and has almost no limits. (it does have limits: For example, files are limited to about 16 Billion gigabytes. Something like that....)
I sure hope they don't throw away the good things about NTFS....
Microsoft makes very little "good" software. But the NTFS filesystem generates the impression that it's different. They probably didn't design it themselves.
What happens to Microsoft's stranglehold when you can dual-boot Windows and Linux on the same partition? More people will start installing it - thats what... Obfuscating the file system gets OSS out of the picture. The DOJ needs to require open specs on this new file system.
/., I'd have to disagree. Windows can't read ext3 file systems, and that hasn't prompted much outrage... If Microsoft announced that in a new update for XP, it would support ext2, ext3, reiserfs, etc., would you install Windows XP? I didn't think so...
/usr/bin and take up space.
... /usr/local/src? ... /home? ... nada. ... manual update with a whole lot of clicks and typing. ... zip. (Can anything in Linux play all the formats that WMP can?)
This statement implies that Windows / Microsoft is so successful because its file system isn't interoperable with any other OS. At the very least, it implies that Linux would have a much larger market share than it currently does. At the risk of offending all the *nix lovers on
The problems facing Linux are far worse than a file system developed by a monopoly. Think of it this way: Linux can't easily communicate with Windows 2000/XP (if it's NTFS)... but then again, a whole LOT of Linux programs can't even communicate with other Linux programs unless specifically told how. There's never been a successful "Control Panel" project to centralize administration (although Webmin is pretty nice, it just isn't there yet... I'm looking for something very similar to Windows' Control Panel).
How about standard commands and formats? Just this morning I went to run a script to install a piece of software, and it failed because it couldn't find "uncompress". Another script found "gunzip", and yet another found "tar" and "gz". There's 4 commands that basically do the same thing, but aren't merged. The most basic features and functions have standard commands, like "ls", "cd", and "ps", but almost anything else has 2+ options. There are even several shells that don't need to exist (my opinion). Really, who needs anything besides bash, ksh, and csh? In fact, here's a thought... make bash the standard, and include ksh and csh in whatever program needs to run them... but don't put them in
Microsoft has addressed the basic necessities of an operating system, and made it relatively easy to work with. Linux still has an amazingly long way to go. I would gladly give my time to help in any way I can, but I'm not a programmer (working on it though).
Here's some thoughts to look at when questioning my reasonging:
Microsoft has Program Files. Linux has
Microsoft has Documents and Settings. Linux has
Microsoft has Computer Management. Linux has
Microsoft has Internet Explorer. Linux has Netscape, Mozilla, and Konquerer.
Microsoft has Windows Update with 3 clicks. Linux has
Microsoft has Windows Media Player. Linux has
Microsoft has (*gasp*) setup.exe as a standard install. Linux has configure, make, and make install.
Microsoft has Office. Linux has OpenOffice, KDE Office, and StarOffice.
The bottom line is that Microsoft has a good idea what programs it wants to work and what each program is supposed to do. The Linux community has no central figure leading the charge, so any Joe with an ounce of programming experience can go and create his own Winamp impersonation. I love Linux... but the fact is that it's not easy to use, and there's a lot more work needed than anyone wants to admit.
"It's better to have a gun and not need it than need a gun and not have it." ~ Christian Slater, True Romance