Yeah, and none of those VMs have any bugs in them.

One point of a filesystem is to have a consistent state that you can recover from after an errant process stomps on memory, or your machine suffers a kernel panic, or your memory becomes so fragmented that you can't even read a 100mb data source, or any other number of issues that can only be resolved by rebooting or reloading.

Once you've committed to non-volatile memory and ditched files, you're tightrope walking without a safety net, at the mercy of the next system level bug. I'd rather know that my data is safe and double-backed up at multiple physical locations, with recoverable history. Files give me that in a well supported, (mostly) system agnostic manner.

> Consider the case of video - it is better represented as streams of audio, picture and metadata.

Not true. Video components are packaged together because they go together logically. When you want to send the video to another machine or give a copy to a friend, it's entirely logical and useful that the various components are packaged together in some way.

I'm talking about storage, not distribution. They are two different things.

> Traditional operating systems such as Linux and windows are 100% dead when non volatile memory comes along in force

Seems like you were talking about a lot more than just one particular facet of filesystems when you made the futurist proclamation above.

Yes I admit that but for the scope of discussion, it's rather hard to separate the two.

My idea is that communication should be transparent.

Figuring out which function has broke might take a year (literally). Sometimes reboot is just reboot.

bugs happen. sometimes the cheapest bugfix is to reboot.

You don't set your standards very high do you?

I've worked on kit that is never upgraded or rebooted. It's active 24/7 for 365 days a year and is expected to work for 30 years.

I epxect the same thing from a normal computer, epecially considering the engineering budget is larger for them.

You don't use Microsoft products, do you? :-)

I do which makes me want for more :)

>If you use a safe programming language which doesn't piss over memory (I.e. Haskell, Python, Ruby, Lisp etc) you won't need to reboot.

This is a man who's never used Xmonad (which is written in Haskell) for an extended period of time before. If you use it for a long enough time, it gets slower and slower until workspace changes start taking whole seconds.

Eventually you say fuck it and reboot...

...'cept you can't do that without a filesystem with a "base state" to reboot from.

GG

I've had this happen before with xmonad.

It turned out I had a memory leak in my configuration file :(

As someone who's had an sbcl process running for just over a year on one box, I disagree.

xmonad is probably just a turd.

So what, in the future you're relying on everyone to magically start coding well?

Don't we already expect that from kernel contributors? :-P

So we're going to expect this from the entirety of userspace?

No userspace can be wrapped quite nicely:

In fact we don't really need processes, just suitable environments set up for execution of code. For example, stop a lisp definition calling eval:

   (defun no-eval-wrapper (form) 
      (let ((eval nil)) (form)))

I've not tried this btw and it'll probably only work with scheme dialects.