phkamp

No, that is actually not what the Flash Adaptation Layer does.

The FAL's primary job is to make the Flash array look like a disk, despite the fact that individual "sectors" are not individually rewriteable.

To do this, the FAL implements which is for all practical purposes a filesystem, where the files are all a single sector long and where the filename is the sector number exposed by the "disk".

In other words: Now we have two filesystems on top of each other, one lying to the other, which does a lot of unnecessary work, because it is being lied to.

I think that is a false dictomy.

CHERI has shown that this kind of fundamental architectural improvements can happen with very little impact to running code.

That is actually the R1000's raison d'etre:

Rational built a truly semantic IDE, and the result of that is that if you change a line of source-code somewhere in a huge complicated project, it will know precisely what the consequences of that change are.

Ultimately, this allows it often just recompile that single line.

Yes, and I dont (quite) buy that argument, but I understand where it comes from.

The problem starts when you, quite sensibly implement something like SHA256 in hardware. It is a perfect example of something hardware does better than software.

But Dennis, Ken and Brian didn't think about cryptographic hash-algorithms when they created UNIX, and because UNIX no longer have a recognized architectural authority, nobody provides a timely architecture for such new features, and instead we end up with all sorts of hackery, some in kernels, some in libraries and some in applications.

SHA256 should be a standard library API, and if the CPU has a HW implementation, the platforms library should spot that and use that, no need to get the kernel involved, it's just a fancy XOR on purely userland data.

But SHA256 being a good example does not mean that we should throw out the baby with the bath-water.

Things like file-systems are incredibly ill-suited for userland implementations.

What they dont say in the article is that they will need monolithic "libraries" for things like filesystems, and to implement things like locking, atomicity, these libraries will have to coordinate amongst the processes which use the filesystem, and must do so without the control and power available to the kernel.

There are ways to do that, see for instance MACH or the original MINIX. It transpires there are disadvantages.

And that's what I mean by "archtectural radicalism": Try to use the right tool for the job, and sometimes the kernel is the right tool (filesystems) and sometimes it is not (SHA256).

More interesting than you can imagine :-)

When you reverse engineer "normal" code, you know the CPU can handle integers of X, 2X, 4X bit widths, you know it wants things aligned this way or that way etc.

The R1000 is bit addressed, and integers can be any width from 1 to 64 bits, structures can be "variant" (See: Ada) so reverse engineering the storage layout is ... not an accomplished feat yet.

Since the primary task for the R1000 was Ada program development, and since there were a standardized semantic representation of Ada programs ("DIANA"), one of the fundamental hardware/microcode data-types is "DianaTree", which is, I think a pretty generic CS tree of some kind.

These "DianaTree" types seem to also have been used for other stuff, like directories in the object store etc.

I'm not a fan of any archtectural radicalism, and tend to think that there are things best done in both hardware, kernel and libraries and applications :-)

That is not to say that the boundaries should be cast in stone, they should obviously be flexible enough that you do not need a complete multi-user management system in a single-service jail or container nor a full-blown journaled COW storage-manager on a small embedded system.

In other words: I am firmly for the "Software Tools" paradigm.

You are right that there is no lessons for "modern machines" as we build them now.

But that is precisely my point: Maybe there are better ways to build them ?

The entire address space (64 address bits, addressing bits, so "only" 61 bit addresses for bytes, but also 3 "kind" bits, separating code/data/control etc.) were available at all times.

The crucial point is that the RAM wasn't laid out as a linear array, but as a page-cache.

In a flat memory space, to allocate a single page far away from all others, you will need four additional pages (the fifth level is always present) for the page-tables, and four memory accesses to look them up before you get to the data.

In the R1000, you present the address you want on the bus, the memory board (think: DIMM) looks that address up in its tag-ram to see if it is present, completes the transaction or generates a memory fault, all in one single memory cycle, always taking the same time.

One of the original brains behind the R1000 has mentioned that the B5500 was one of the inspirations, but my personal impression is that he was talking more about the stack-based (vs. register-based) instruction set, than the memory management.

About Flat vs. Object stores

I wrote this piece, frustrated by, what looks to me, like the entire semiconductor industry is only exploring one single computer storage organization, despite the fact that recent inventions like flash practically begs for innovation.

For instance few people realize that the Flash Adaptation Layer in the SSD devices means that we literally run two filesystems on top of each other, because nobody has seriously tried to get rid of the "a disk is an array of individually rewritable sectors" despite this literally being untrue both for modern disks and in particular for Flash based storage.

Similarly, the "flat physical/flat virtual" MMU model is a relic from the days of IBM 360 and VAX 11/780 and utterly inefficient and unsuitable for what we do in userland these days.

As Robert has shown with CHERI, there is plenty of space to innovate without breaking existing code.

And yes, C can be object oriented, all you have to do is keep your hands from the primitives which are necessary to access hardware directly.

Architectually GPU's are a superoptimized distraction, like the vector-units on Cray and Convex computers were 40-50 years ago, but those too can function in a non-flat address-space.

But even C in OO-mode, and C++, Go, Rust, PHP and for that matter LISP and SmallTalk, would benefit from an HW/MMU architecture which focused on delivering fast object service, rather than flat address-spaces which software must then convert into objects.

But to innovate, we must first realize that we are currently stuck in a box, and dare to look outside it.

Hi everybody!

About the R1000:

We have pretty comprehensive user-side documentation of the R1000, but very, very little from the system/vendor side, so lots of things we simply do not know yet.

We have digitized everything we have here:

https://datamuseum.dk/wiki/Bits:Keyword/RATIONAL_1000

And our top-level wiki-page for the project is here:

https://datamuseum.dk/wiki/Rational/R1000s400

All the doc we have about the hardware type/object stuff and instruction set is in these course-slides:

https://datamuseum.dk/bits/30000916

If you are into data-archaeology and lack for challenges, we have several good outstanding questions for research. For instance the layout of the object-store/filesystem.

If you want to see a R1000 running, and experience the worlds first truly semantic IDE, come to Datamuseum.dk just outside Copenhagen, because we have the only approx 1.83 running R1000 computers.

(We also just started fundraisning for a new permanent building for our huge collection, we are at €113K of €3M goal. See top right corner or homepage or email.)

We know of only four surviving computers, we have two, one is privately owned in NZ and IBM donated one to CHM. The rest have been shredded because of classified mil-spec workload.

If you are local to/affiliated with CHM, and are interested/allowed, we would love to know more about their machine, and if possible, assist to get that running too.

PS: Here is a piece of Ada source code:

http://datamuseum.dk/aa/r1k_backup/13/1329b5ea7.html

And this may be what it compiles into:

http://datamuseum.dk/aa/r1k_backup/85/85b414c73.html

We have a picture of the s100 backplane here:

https://datamuseum.dk/wiki/Fil:R1000_s100_Backplane_2.jpg

The metal blocks at the bottom is where the welding cables from the PSUs connect.

To read more about the R1000, start here:

https://datamuseum.dk/wiki/Rational/R1000s400

The type descriptions contain much more than that, for instance valid range for integers, field layout for structures and so on. Also privacy information.

This has a name: "Audio-homoepathy"

The basic idea is that the sound gets better the more money you dilute it with.

I hope they have anti-sloshing-baffles in their design, because liquid hydrogen has low viscosity, and you really do not want it sloshing around without energy dissipation, in particular not during take-of or landing.

That's pretty much how a modern Danish mass-produced house is built, modulus some form language details.

At the time at least one 128 bit computer had been on the market for several years: The Rational R1000.

A great example of "surveillance too cheap to meter"

https://queue.acm.org/detail.cfm?id=3511661

All that info and not a single word about hydrogen bombs ?

There's a book called "Zen and the Art of Motorcycle Maintenance" that this guy need to read...

In terms of computer security, this is revolutionary.

Ohh, one of the hard questions :-)

Personally, I think the cache oblivious thing was oversold, all the algorithms I have seen are horribly complex and thus only an improvement if your N is so big as to overshadow the constant terms in O(...) we usually ignore. Patenting and expecting to become stinking filthy rich on the licensing fees, was another good way to prevent them from being used.

I think the best we can do is probably still making sure we know what we are trying to do, and what we are not going to do, and then architect accordingly.

That is of course really just a fancy way of saying "it depends", but I'm OK with that: Magic silver bullets are not a thing.

This post does seem to pop up here every other year, doesn't it ?

"he" in this case being me :-)

I think the threshold question will always be "Does software X make my life better?" and if it does not, you should ditch it if you can.

There is always a huge bias in reporting: People are eager to tell you why they started using your software, but they always forget the "exit-interview" when they drop it again.

The reason I hear most often for people dropping Varnish is that they have cleaned up the mess of legacy web-services, or at least transitioned it all to the New Fantastic Platform.

Other people drop Varnish for other versions of "this is now surplus to requirements" and I am totally fine with that: I dont want people to run Varnish if it doesn't make their life better.

Varnish has a pretty big market-share as "the intelligent HTTP-router" which can be used to sort traffic to piles of legacy webservers etc, and also be the central clearing-house for detecting and fixing trouble.

Surveys such as builtwith, despite their hard work, can often not "see through the sandwich" and spot if there is a Varnish in it.

Also, I dont know about you, but from a "I want the world to keep working" reliability point of view, I do not like it when any single piece of software, FOSS or non-FOSS, becomes too dominant.

See for instance how dysfunctional the GCC-monopoly was until LLVM gave them competition.

So taking builtwith at their numbers, I'm actually fine with Varnish having "stagnated" at a market share of one fifth of the worlds top 10K websites: That keeps me humble about my code quality, but does not keep me awake at night.

On the other hand: Count the CVE's.

An increasingly popular high-rel setup has two different SSL/TLS handlers in front of Varnish, each using a different SSL/TLS implementation.

That way a "ohh shit CVE" against either of those two implementations allow you to turn those of, and keep your site running.

If We bolted any particular TLS/SSL implementation into Varnish, you'd be down when that one got hit.

All you need to know about unicode, is that they thought they could "unify" all the asian glyphs into one alphabet.

That said, given the origins of writing, I dont think there are any much cleaner solutions.

Their biggest mistake is probably not insisting on a mandatory vector representation which could be used to generate a "font-of-last-resort"

My personal pet-peeve is that unicode have not yet assigned 128 code points and two modifiers to cove all possible combinations of 7-segment LEDs :-)

Far from, if anything the opposite.

I mainly write this kind of stuff to make people think about what they would not otherwise have thought about, with the secondary goal getting at chuckle or two along the way.

This particular one have been discussed on HN previously and every time the "beause ASCII == keyboard" argument have come up.

...and been slapped down by people from the rest of the world, who have two or even three keystroke sequences to reach [\]{|} etc, because more important national characters, like æøåÆØÅ lives on the "usual" keys.

If I managed to get people to think about that, I've done my job.

As for C:

I think the C lanuage has been mismanaged, why did we need yet a threading API, while we still dont have explicit struct packing, including per struct or per field endianess specification ?

The ISO-C Group is incredibly conservative, which is plain wrong: A finite amount of C code have already been written, but there is a potentially infinite amount yet to be written. They should focus on the larger oeuvre.

I wrote this, and I'm here if you have questions.

The correct description for that kind of operation is not "news stations" but "propaganda outlets".