Post

he's based now. the operating system of the future will use a capability restricted database instead of a traditional file system

this is how winfs can still win en.wikipedia.org/wiki/WinFS

en.wikipedia.orgWinFS - Wikipedia

this would be so based with powershell

James Brundage | MVP

@mrpowershell.com

Wait, are you saying you would want a database-like filesystem in PowerShell ? If so, are you already familiar with PowerShell providers?

i was not, and they seem like an extremely good idea

James Brundage | MVP

@mrpowershell.com

Yeah they are one of the undersung extension points of PowerShell. And I keep meaning to write an "object provider". Does this sound cool to you? CD into properties and subproperties? Invoke-item into methods?

27/12/25, 8:51 pm0 reposts1 like

i'm not very familiar with the internals of .net or powershell, but wouldn't that break parts of the interface like Set-Item, Remove-Item, New-Item? the idea of providers generically is nice though. i currently use nushell, but its concept of $env.PWD is somewhat coupled to a file tree

James Brundage | MVP

@mrpowershell.com

You can also use providers in variable assignment, for example: $function:hello = {"hello world"} Hello

James Brundage | MVP

@mrpowershell.com

Btw just paying the compliment... #NuShell is pretty cool stuff, and if they ever figure out a true object pipeline they'll become my second favorite language.

James Brundage | MVP

@mrpowershell.com

Nope, it wouldn't break them. Providers are designed to provide a file-system like experience atop of an arbitrary data store. Multiple ones run side by side. On Linux, you'll have one for filesystem, variables, environment variables, functions, and aliases.

James Brundage | MVP

@mrpowershell.com

On Windows there's also the registry provider ( which, admittedly, works in somewhat funky ways ). If you ever have to deal with #IIS - first, I'm sorry, and second, the IIS provider is your friend. There are a few community providers as well ( but way more cmdlets )