Re: SSD TBW

... how do you think most features and utilities specified in IEEE

And clearly you dislike the Software Tools approach and insist on discussing it in a completely irrelevant thread like this one.

Have you seen the AS/400? You might like the general approach, where everything is a database. Everything. I see the appeal for commercial data processing but it's kind of hard to extend.

--scott

This is USENET. There are no rules as to relevancy controlling where the thread goes. If you object to a particular direction, then you can stop participating or stop reading. That's entirely under YOUR control, not one of a moderator. If you want things to stay strictly on-topic, find a suitable (user-moderated) forum.

I have no problem with tools, *building* tools to add specific functionality, extending tools, chaining tools, etc. I have no problem PAYING for tools, either (unlike some who see FOSS tools as a cheap way out)

Requiring a user (or administrator) to carry around information about particular system objects is just silly; machines track information far better than humans, for all but trivial things. The fact that a Makefile has a different internal structure than a hosts(5) or networks(5) file relies on managing such details.

That depends on how you want to extend it and if there is a *need* to do so.

I have no filesystem in my current project. The persistent store is implemented in an RDBMS. Because all of the persistent objects have specific structures and the RDBMS can enforce and protect those. Regardless of the sizes and datatypes of the individual components.

If you want to store a text file -- or, an executable -- it's likely a LARGE, monolithic object (BLOB), possibly augmented with other meta data associated with that "record".

And, other than access control and persistence, there's nothing the RDBMS can add in terms of value. Just like a filesystem.

But, I don't have a need to store text files.

Most of a *system* consists of structured data encapsulated in objects of differing types -- whether active or passive objects. There, the RDBMS can add value by ensuring that each of those component parts adhere to the rules for their presence, values, relationships with other entities, etc. "No, this object is not valid for use as an executable image for a particular service; but THESE are..."

"That's not a valid MAC address (not enough octets)."

"That's an invalid hostname (you'll discover that when you try to use it)"

So, every bit of code that wants to interact with a particular object doesn't need to be able to *parse* the object AND verify its type and integrity (as well as its permission to access said object and perform specific actions on them).

There's a different approach to "everything is a database" I recently came across.

I pointed self closure at every ELF binary on this system's PATH: 723 executables, which pull in 400 distinct shared libraries. 1,123 objects, 346,386 symbols, 3,808 dependency edges, all as one SQLite file.

Turns out when you do that, the database is much smaller than you would expect.

Elijah

------ "strip" is new a couple of "DELETE" statements, and other tricks

And SQLite is just one exemplar of a DBMS. The issue is one of assigning structure to the "collections of bits" that tend to be scattered around a store that we call a filesystem.

Because you don't need the arbitrary structure of the filesystem and the metadata that *it* considers important. Bind a unique identifier to each object/entry point and there is no need for filenames and other human-centric identifiers (you can preserve those OFFLINE in your build environment but there's no need to carry them into the deployed product, beyond inertia: "That's the way we've 'always' (for some small value of 'always') done it!"

You can include versioning in such a database so that a binding can know which version of an object to access ("dereference").

And, if you delay binding, that decision can happen each time you re-bind!

Furthermore, if you place objects in isolated containers, you can re-bind WHILE objects are in use instead of having to restart or (gag!) reBOOT!

But, as the author quietly laments: "I explored the idea during my PhD thesis but found feedback from others unmotivating. Radical ideas are hard to sell, as you are working against the inertia of the established solution." The Masses are rarely known to create new ideas (or facilitate their creation).

It’s an extensible scheme, fit for creating a UNIX for the 21st century.

How does Apple do it? The old OSType mechanism was 4 bytes each for type/creator, and that was it.

Didn't Apple have a forked file system? Seems to me that Apple could preserve OS/2's extended attributes (xttr's) over the LAN. As an aside, OS/2 started supporting extended attributes with the release of the HPFS file system in 1988 (also supported in FAT) and used them a lot in OS/2 v2+. Dave

I was quite impressed by the quality of his trolling. I've seen similar styles by 1 or 2 others, "rudy meisner" springs to mind. I'd not been following the thread for a while and was impressed to see the scale of activity when I looked today. He's in the virtual *plink*-list at the moment but yet to migrate to fully *plinked*.

Microsoft did try to go further. Back in the 1990s, I think, they had something called “project Cairo”, which turned the entire filesystem into a database. This later morphed into “WinFS”, which was one of three major deliverables promised for Windows Vista.

None of the three made it to shipping.

Yes. Apple had two forks, resource and data, so metadata was kept separately.

When OS X came out, they started out using a "named fork" mechanism under HFS+ but then later they moved to multiple different ways that atttributes were stored and it all became messy and confusing because there were multiple legacy methods all being used.

The more I work with stuff like this, the more I like the Unix world where everything is flat. VMS had a lot of very fancy filesystem features that were great in a commercial data processing environment but were nothing but frustrating in a scientific computing environment.

--scott

The old MacOS did, not sure about the current one.

There’s no standard for such things across different OSes, though.

I gather that NTFS in Windows NT generalizes Apple’s original two-fork concept to allow for multiple forks (called “streams”, I think). Not much software actually makes use of this, though.

On the Linux side, the Reiser4 filesystem was going to generalize this concept even further, by unifying the concepts of files and directories into one. So every filesystem item could be treated as a conventional file containing bytes of data with no predetermined structure, and also as a directory containing further filesystem items, which could be in their turn be accessed as both files and directories, and so on.

It is subtle and skillfully done. Subtle enough that a great many on sci.electronics.design fall for it again and again, like moths to a flame. They keep the troll fully fed, so it keeps returning for more.

I've had the troll fully plonked for a while. Sadly, when the others who fall for its trolling respond to its rants, then I still end up having to wade through some of its trolling output in the quotes in their replies.