3 ms·

Well, that, plus the fact that it was resource-heavy. This was compounded by the fact that a lot of hardware was sold as being 'Vista-ready' while in reality be

Well, that, plus the fact that it was resource-heavy. This was compounded by the fact that a lot of hardware was sold as being 'Vista-ready' while in reality being incapable of running the overly-fancy graphics-heavy 'glass' shell. It also had a number of performance problems (e.g. slow file copy) which only got sorted out in Windows 7. Oh, let's not forget the fact that Vista was supposed to be Longhorn, the OS of the future with a database file system and all sorts of fancy stuff which was either dropped due to performance problems or never left the lab in the first place.

kbenson 7y ago
> Oh, let's not forget the fact that Vista was supposed to be Longhorn, the OS of the future with a database file system This sounded interesting when I first heard about it, long before Vista came out. Now when I see it I wonder what they were trying to do. A file system is a database, with a well understood user API. So what were they going to add? Tagging? Application level views of the system? None of t hat seems like something that would require anything more than an extension that handled additional metadata.
- kayfox 7y ago
  Lots of file systems at the time were hierarchical databases, but the file-system Microsoft was working on was to be more a hybrid with the ability to find files based on specific criteria right away, rather than having a search process walk the tree looking for something.
- bobbylarrybobby 7y ago
  The point of a database is probably to index via arbitrary columns, allowing for fast lookups and filters of files. The current model is to find something you more or less have to walk the directory tree.
- stickfigure 7y ago
  A file system is a database, with a well understood user API. Yes, a terrible API which works poorly for most home use cases. You probably have music on your computer. In your hierarchical filesystem, do you organize it by Genre/Artist/Album or Artist/Album? Do music videos live in the same Artist directory or in a separate "video" folder? Chances are you don't know/care because you're using an app like iTunes that builds a custom database on top of the filesystem. And something like Photos that reinvents a totally different custom database. And more database reinventions for email, ebooks, games, karaoke files, voice memos, calendar appointments, etc... all proprietary file formats without published APIs. Data doesn't want to be organized in a single static hierarchy.
  - 72deluxe 7y ago
    "Data doesn't want to be organized in a single static hierarchy." Data has no feelings. In the case of file system, it makes perfect sense to be stored in a single static hierarchy because that perfectly reflects the concept of a paper file in a filing cabinet, in a little binder. Even a relational database system that lets you query tables for data based on set ordering has a single method of storing the data on disk - that's a clustered index. You can't get away from having that, despite being able to support additional nonclustered indexes. In that case, the table and its rows really is organised in a static hierarchy too. As it stands, NTFS has plenty of features that lets you attach a secondary data stream to a file anyway, and all manner of metadata. The Windows Internals book on NTFS is very informative on this. These features don't exist on APFS though, as it's not as good despite being brand new, it seems!
  - kbenson 7y ago
    I take it you missed the part where I said " None of t hat seems like something that would require anything more than an extension that handled additional metadata"? I'm not saying don't add additional data that can be fast indexed and trackable, I'm just not sure why it requires a rewrite from the ground up and isn't additional data that is tracked tacked onto the file metadata. I mean, what is that not going to be able to support that just the new metadata would? The difference is whether you also have a hierarchical location stored or not. The only thing that comes to mind is ACL tracking and it getting a bit complex from different access types, but I can think of a few options to work with that already.
    - stickfigure 7y ago
      So you want to take existing filesystem technology, and build additional indexing and query capabilities so that it can handle nonhierarchical data? Sounds like a great idea. Let's call it "Longhorn".
      - kbenson 7y ago
        I think you mean WinFS. Longhorn is a whole release codename, which encompassed many new features. Given that a beta WinFS eventually was made available as a separate download years after even it's beta was slated to be released[1], I suspect they did what I outlined above - eventually. Otherwise, I'm not sure why a bolt on component to the system would require so long and miss deadlines like it did. 1: https://en.wikipedia.org/wiki/WinFS#Development https://en.wikipedia.org/wiki/WinFS#Development

kbenson 7y ago

> Oh, let's not forget the fact that Vista was supposed to be Longhorn, the OS of the future with a database file system This sounded interesting when I first heard about it, long before Vista came out. Now when I see it I wonder what they were trying to do. A file system is a database, with a well understood user API. So what were they going to add? Tagging? Application level views of the system? None of t hat seems like something that would require anything more than an extension that handled additional metadata.

kayfox 7y ago
Lots of file systems at the time were hierarchical databases, but the file-system Microsoft was working on was to be more a hybrid with the ability to find files based on specific criteria right away, rather than having a search process walk the tree looking for something.
bobbylarrybobby 7y ago
The point of a database is probably to index via arbitrary columns, allowing for fast lookups and filters of files. The current model is to find something you more or less have to walk the directory tree.
stickfigure 7y ago
A file system is a database, with a well understood user API. Yes, a terrible API which works poorly for most home use cases. You probably have music on your computer. In your hierarchical filesystem, do you organize it by Genre/Artist/Album or Artist/Album? Do music videos live in the same Artist directory or in a separate "video" folder? Chances are you don't know/care because you're using an app like iTunes that builds a custom database on top of the filesystem. And something like Photos that reinvents a totally different custom database. And more database reinventions for email, ebooks, games, karaoke files, voice memos, calendar appointments, etc... all proprietary file formats without published APIs. Data doesn't want to be organized in a single static hierarchy.
- 72deluxe 7y ago
  "Data doesn't want to be organized in a single static hierarchy." Data has no feelings. In the case of file system, it makes perfect sense to be stored in a single static hierarchy because that perfectly reflects the concept of a paper file in a filing cabinet, in a little binder. Even a relational database system that lets you query tables for data based on set ordering has a single method of storing the data on disk - that's a clustered index. You can't get away from having that, despite being able to support additional nonclustered indexes. In that case, the table and its rows really is organised in a static hierarchy too. As it stands, NTFS has plenty of features that lets you attach a secondary data stream to a file anyway, and all manner of metadata. The Windows Internals book on NTFS is very informative on this. These features don't exist on APFS though, as it's not as good despite being brand new, it seems!
- kbenson 7y ago
  I take it you missed the part where I said " None of t hat seems like something that would require anything more than an extension that handled additional metadata"? I'm not saying don't add additional data that can be fast indexed and trackable, I'm just not sure why it requires a rewrite from the ground up and isn't additional data that is tracked tacked onto the file metadata. I mean, what is that not going to be able to support that just the new metadata would? The difference is whether you also have a hierarchical location stored or not. The only thing that comes to mind is ACL tracking and it getting a bit complex from different access types, but I can think of a few options to work with that already.
  - stickfigure 7y ago
    So you want to take existing filesystem technology, and build additional indexing and query capabilities so that it can handle nonhierarchical data? Sounds like a great idea. Let's call it "Longhorn".
    - kbenson 7y ago
      I think you mean WinFS. Longhorn is a whole release codename, which encompassed many new features. Given that a beta WinFS eventually was made available as a separate download years after even it's beta was slated to be released[1], I suspect they did what I outlined above - eventually. Otherwise, I'm not sure why a bolt on component to the system would require so long and miss deadlines like it did. 1: https://en.wikipedia.org/wiki/WinFS#Development https://en.wikipedia.org/wiki/WinFS#Development