Can hierarchical file systems just die already?
>>108229544why ?
>>108229544No.
What's your alternative?
>>108229544Just because the UNIX file system is retarded doesn't mean hierarchical file systems are a bad idea.
>>108229613A relational database of tagged blobs
>>108229544sorry saar. we're too stupid to innovate, so we need to design systems in the worst way as to make the highest number of problems and later perpetually "solve" them until we "solved" all of the problems, and then we will DEPRECATE it, and replace it with a new poorly designed system.This has been going on since the 60's.
what's wrong with it?
>>108229641That's a cool idea. You should implement it.
>>108229544are you continuing the discussion from the syscall thread?
>>108229653Oracle DBFS has existed for fifteen years. Everyone should migrate to that.
>>108229544true
>>108229601>>108229650>if you organize files differently, existing file references stop working>no many-to-many relationships, only one-to-many>each app has to supply its own storage layer (object graph, tags, content addressing) on top of the primitive file system
t. OP Zoomer
>>108229782>no many-to-many relationships, only one-to-manysymlink>each app has to supply its own storage layer (object graph, tags, content addressing) on top of the primitive file systemalternatives all add bloat
>>108229544works on my machine zoomzoom
>>108229794>I have a good solution, guys: symlinks!
>>108229794>a profusion of individual hacks isn’t bloat
>>108229782>if you organize files differentlySo you created a problem and your solution is to get rid of everything because of your problem? Skill issue.
as much as we all don't like ita single long-format file index with ai search strapped on top of it (think apple spotlight on steroids) will be enough for 99% of people in the VERY near futureand I don't think there will be any point in implementing non-hierarchical file systems for any wide-spread enthusiast use case
>>108229544the most zoomer take of 2026 lel
>>108229641what does the user experience look like when using something like this? what if i want multiple files to have the same name?
>>108229938you can make the primary key be name + id, then you can have all the same names you want
>>108229950>name + idid suffices obviouslylearn database normalisation my gay
>>108229950how would i remember which of those files are the correct one without opening all of them to remember the database key?
>>108229978you are correct, that is what I meant I guess
>>108230001>want to have multiple files with the same name>but wants to easily recognize them without openinguhhh, how about you don't name them the same then?
>>108229682Nice try, Larry Ellison.
>>108230021this problem doesn't exist if i have folders separating the files that are named the same
>>108229544so long as people are using computers not purely as toys, i'm afraid this architecture will continue to bother you
>>108229544pretty sure OP just wants a tagging system for for files, top lel
>>108229794>symlinkWorks great only if you never move files.>but hardlinkNow it doesn't work across multiple drives.
>>108229544Can I get a qrd on what each of these is for?
>>108229782I think the issue you're having is that you're able to point out the flaws in the existing paradigm, but not foresee the flaws in a proposed solution.>>108229824>The classic no argument postIt works for the few cases you need such a relationship. I could see an argument for making their creation easier, but otherwise I see no problem.
>>108229782>if you organize files differently, existing file references stop workingdirectory aliases>no many-to-many relationships, only one-to-manyas said before, symlinks>each app has to supply its own storage layer (object graph, tags, content addressing) on top of the primitive file systemyes because each app works within its own ecosystem and rules, of course it has to set things up in a way it understands. that isnt the file system's fault
>>108230198What are the foreseeable flaws in the best solutions?
>>108229782>>if you organize files differently, existing file references stop workingSounds like a YP not a MP. Now if you were going to say:>applications throw files everywhere like they're shitting above a public toiletYou'd have a case, because that shit (even on Windows) is insane and we need the heriarchy to be "respected" enough to put your software files in the proper location (no, your .config does not go in /usr/<account>/home, it goes in /bin/yoursoftware/.config)
>works fine all around for billions, for decades>I NEED TO CHANGE IT!Easier to just take autism medicine, anon.
>>108230414Will my most immediate concern is how you're going to represent this in a file browser of sorts. Will you just create something akin to symlinks by default so that you can visibly sort your files?
What if there were just no hierarchy, no structure, and the filesystem was totally flat?
>>108230523then a program would break if it needs to write a filename that is already taken by a different program
>>108230550good, fuck users
>>108229782>>no many-to-many relationships, only one-to-manyYou mean many-to-one? You already have that.>>each app has to supply its own storage layer (object graph, tags, content addressing) on top of the primitive file systemEach "app" is its own program and has its own needs, and possibility space isn't enumerable. I think what we should be asking ourselves is why are you even using a computer if you clearly don't have need for one?
>>108230553based ebussy
>>108230550what's the usecase for programs?
>>108229782>>108229641do you think the relational model makes reorganization easier? good fucking god
zoomers really went from just being unable to comprehend file systems to outright demanding they get removed altogether
>>108230433I'd prefer the configs to go to the /home/ directory. That's where all my stuff is anyway so it would be a simple task to just back up /home/ and transport it if I need to.But in general yes there should be hard rules on where things go.
>>108230800i should only ever see brainrot and funny tweets you stupid boomer
>>108230553>fuck usersOI! NO MICROSOFT CONTRACTORS ALLOWED IN THIS BOARD!
>>108230704Apps that use relational databases, like photo managers and CMSs, usually let you reorganize things. So it doesn't seem too bad.
>>108230601>Each "app" is its own program and has its own needs, and possibility space isn't enumerable.You seem to imply that the OS shouldn't provide a file system at all, just let programs use raw storage devices.
>>108230800calm down soilennial. we would still be using spinning disks if you had it your way
>>108230977Is your entire system just a singular photo manager?When you have programs utilizing databases where they completely own it, things can be quite simple. They can enforce their own invariants suited to their particular very restricted domains and not bother with the rest of what a relational database actually is. Since nothing else ever touches or moves that data, it's fine. Because their model is so strictly and rigidly defined (and because they own the database and everything about it) they implement their own very limited UI workflows to handle reorganization suited to their own simplistic needs. The fact these things use relational databases is a bit of a meme in and of itself, they don't really NEED to model their data as arbitrary predicate relations over n-tuples.Now let's say I open up one of those databases with another program and start fucking around. I'm changing keys, layouts, deleting whole rows. What do you think happens? This is the reality of a relational database. The moment they are a system-wide resource with multiple hetergeneous consumers, things change. The flexible structure of a first-order predicate calculus bites you in the ass as a simple table reorg invalidates a bunch of foreign key constraints, indices, and query structures. In the best case, some change Program A made to the database tanks the performance of Program B. In the worst case, you kill the whole system. A relational database is 1 arbitrarily recursive construct away from being a (shitty) computer in and of itself.A relatively small system of a 5 or so users of a singular database is already a substantial management problem. Entire people's professional careers are nothing but specializing in database management. 85% of Oracle's business model is selling special tooling to exactly those kinds of professionals.https://docs.oracle.com/cd/A97630_01/em.920/a86647/reorg.htm
>>108230553>good, fuck usersThe funny thing is, I can't tell if you work for Apple, Microsoft, or Linux with this mindset.
