5 ms·
At "ultimate", I thought the author was going to aim for consciousness... But what, databases?!
by ridaj 7y ago
At "ultimate", I thought the author was going to aim for consciousness... But what, databases?!
- blablabla123 7y agoActually Microsoft tried this idea themselves with WinFS. It was planned for Vista but eventually the project was stopped because it was too much effort. I could imagine this to be really useful if it was possible to add arbitrary custom attributes.
- echelon 7y agoDoes anyone have the story on why this project was actually halted? It reportedly sounded like it would have been a giant leap at the time, had it actually landed.
- krylon 7y agohttps://www.reddit.com/r/programming/comments/1svf88/why_winfs_died_long/ https://www.reddit.com/r/programming/comments/1svf88/why_win...
- iso-8859-1 7y agoThat discussion doesn't contain any high quality posts, why not link the actual article? http://hal2020.com/2013/02/14/winfs-integratedunified-storage-and-microsoft-part-1/ http://hal2020.com/2013/02/14/winfs-integratedunified-storag...
- otabdeveloper4 7y agoProbably because it was a dumb idea. There's no sense storing videos, baby photos and "quarterly report new (2) backup newest 08.2019_john.xlsx" in a database.
- BlackRing 7y agoIf the filesystem itself was modeled after a database (which it can be argued it is, somewhat), it's not much of a stretch for WinFS to have been a thing. I was looking forward to seeing it in action based on reports of what it was.
- simonh 7y agoFile systems are databases in a small way. They use b-trees and such, but they don't enforce a rigorous global type system, don't enforce a table structure because everything has to have a schema, don't have the overhead of a query language to interpret every file access command, didn't ensure that all file accesses be ACID compliant, etc. WinFS imposed all of those things and the associated overheads and much, much more every time you accessed anything.
- simonh 7y agoIt was very slow and resource hungry, and also very time consuming to develop things on. Imagine if you were only allowed to write or run applications that ran on top of Oracle. Even if you try to write a program that works on text files, those text files are stored as blobs in an Oracle database.
- regularfry 7y agoIsn't that the sort of problem you solve once, though? If you want a "this is just a stream of characters I can do POSIXy things to" interface, that's a library with fread(3) et al in the front, and a query for a single field in the database at the back.
- skissane 7y ago> Even if you try to write a program that works on text files, those text files are stored as blobs in an Oracle database. Ever heard of Oracle Database Filesystem (DBFS)? https://docs.oracle.com/en/database/oracle/oracle-database/19/adlob/introducing-database-file-system.html https://docs.oracle.com/en/database/oracle/oracle-database/1...
- alexisread 7y agoLikewise. TBH this has all been done with NewtonOS: http://preserve.mactech.com/articles/mactech/Vol.09/09.11/NewtonToolkit/index.html http://preserve.mactech.com/articles/mactech/Vol.09/09.11/Ne... It uses soup unions to manage removable storage, and worked really well for the 512k memory available. These days I'd recommend an embedded SQLite database for program configuration and data - somewhat standard, easily recoverable, backups are easy, uniform access from a program's API etc. Lastly, I'd say the ultimate OS would have a bit more than this surely - minimal formally verified TCB, Arrow datastructures, Managed (but not GC'd) memory, native scripting language that blurs the distinction between users and developers, fully scalable auto-generative but skinnable UI, just to name a few. I guess the trick with all of this is a suitable language which forms the OS base (think LISP OSes, Micropython, Squeak, AOS, NewtonOS), you get that correct and the rest can be layered on top.