phkamp

I'm not "refusing to add TLS support" I insist that the certificate is safely isolated in a separate process for security reasons. There are many ways to skin that cat.

And before anybody speculates too much about Matthias use of "jail-like":

I think this can make a lot of sense, because there are many situations, in particular in embedded systems, where you can and should confine at a much smaller scale than jails are really convenient for.

It will also be interesting to see if "Cells" can make inroads in the territory the original ACL abandoned, because writing the rules was so complex that it amount to parallel meta-anti-software development.

Hat tip to Matthias from here.

To me that text reads a lot like an affidavit supporting a Qui Tam suit ?

Here is what I submitted:

I am a well known FOSS developer.

At one point code I had written protected half the passwords on the entire Internet, and today around a quarter of all HTTP(S) traffic on the internet goes through software I have written ("Varnish").

That, and the fata morgana of retirement shimmering on my horizon, makes it my considered opinion that FOSS is the gift EU does not deserve, and runs a great risk of destroying on first contact.

However, closed source as we know it, is not compatible with an open, free and fair society, so I am more than aboard with the EU's long overdue recognition of FOSS as the way forward and out of the grubby, greedy claws of "Big Tech" and their endless enshitification of our lives.

The kind of FOSS software relevant to this discussion is usually rock steady and dependable in ways much commercial closed software, precisely because of the secrecy, can never be or become.

But the human communities which produces the FOSS software are fragile, fractious, and as a general rule, composed of people who may be great programmers, but who have absolutely no experience, and no interest, in fostering and stewarding stable human communities.

This is literally why there are who knows how many, different "distributions" of the Linux operating system, "window managers", "web-site frameworks" and programming languages.

Therefore the absolutely most important thing for EU to understand about FOSS, is that it probably is as close to the "ideal market", in the sense of economic theories, as anything will ever come: It literally costs nothing to become a competitor.

But that also means that if the EU member countries were to pick, no matter how fair and competently, a set of FOSS software to standardize on, and pour money into the people behind it, to provide the necessary resources to support and sustain the need for IT systems, for all the administrations in the EU countries, that software would instantly stop being FOSS - no matter what words the license might contain, because it would no longer be part of the market.

In other words: EU cannot "switch to FOSS", it would no longer be FOSS if EU did.

At the most fundamental level, the EU has three options:

1. Pick and bless a set of winners, consisting of:

a) Operating system, portable to any reasonable computer architecture. b) Text-processing, suitable for tasks up to a book. c) Spreadsheet d) Email client. e) Web Browser f) Accounting software, suitable for small organizations.

and fund organizations to maintain, develop and support the software for the future as open source, turning that software into infrastructure like water, power and electricity, free for all, individuals, startups and established companies alike, to use and benefit from.

2. Continuously develop/pick, bless and meticulously enforce open standards of interoperability, and then "let the competition loose".

3. Both. By providing a free baseline and de-facto reference implementations for the open standards, "the market" will be free to innovate, improve and compete, but cannot (re)create walled gardens.

To everybody, me included, option two seems the ideologically "pure" choice, because we have all been brought to believe that "governments should not pick winners".

But governments have always picked winners. Today all of EU has 230VAC electrical grids, because EU picked that as a winner, thereby leveling the market to everybody's benefit.

Therefore I will argue, that the wise choice for EU is option three.

First, it will be incredibly cheap, as in just tens of millions of Euro per year, to provide all EU citizens with a free and trustworthy software platform to run on their computers.

Second, it can be done incredibly fast: From EU makes the decision, the first version can be release in a matter of months, if not weeks.

Third, it will guarantee interoperability of data.

Sincerely,

Poul-Henning Kamp

I huge factor in iAPX432 utter lack of success, were technological restrictions, like pin-count limits, laid down by Intel Top Brass, which forced stupid and silly limitations on the implementation.

That's not to say that iAPX432 would have succeeded under better management, but only to say that you cannot point to some random part of the design and say "That obviously does not work"

All the examples you bring up are from an entirely different time in terms of hardware, a time where one of the major technological limitations were how many pins a chip could have and two-layer PCBs.

Ideas can be good, but fail because they are premature, relative to the technological means we have to implement them. (Electrical vehicles will probably be the future text-book example of this.)

The interesting detail in the R1000's memory model, is that it combines segmentation with pages, removing the need for segments to be contiguous in physical memory, which gets rid of the fragmentation issue, which was a huge issue for the archtectures you mention.

But there obviously always will be a tension between how much info you stick into whatever goes for a "pointer" and how big it becomes (ie: "Fat pointers") but I think we can safely say that CHERI has documented that fat pointers is well worth their cost, and how we are just discussing what's in them.

The important bit here is "their failed approach", just because Intel made a mess of it, doesn't mean that the entire concept is flawed.

(Intel is objectively the most lucky semiconductor company, in particular if one considers how utterly incompetent their own "green-field" designs have been.

Think for a moment how luck a company has to be, to have the major competitor they have tried to kill with all means available, legal and illegal, save your company, when you bet the entire farm on Itanic ?)

Author here.

This is one of those things, where 99.999% of all IT people have never even heard or imagined that things can be different than "how we have always done it." (Obligatory Douglas Adams quote goes here.)

This makes a certain kind of people, self-secure in their own knowledge, burst out words like "clueless", "fail miserably" etc. based on insufficient depth of actual knowledge. To them I can only say: Study harder, this is so much more technologically interesting, than you can imagine.

And yes, neither the iAPX432, nor for that matter Z8000, fared well with their segmented memory models, but it is important to remember that they primarily failed for entirely different reasons, mostly out of touch top-management, so we cannot, and should not, conclude from that, that all such memory models cannot possibly work.

There are several interesting memory models, which never really got a fair chance, because they came too early to benefit from VLSI technology, and it would be stupid to ignore a good idea, just because it was untimely. (Obligatory "Mother of all demos" reference goes here.)

CHERI is one such memory model, and probably the one we will end up with, at least in critical applications: Stick with the linear physical memory, but cabin the pointers.

In many applications, that can allow you to disable all the Virtual Memory hardware entirely. (I think the "CHERIot" project does this ?)

The R1000 model is different, but as far as I can tell equally valid, but it suffers from a much harder "getting from A to B" problem than CHERI does, yet I can see several kinds of applications where it would totally scream around any other memory model.

But if people have never even heard about it, or think that just because computers look a certain way today, every other idea we tried must be definition have been worse, nobody will ever do the back-of-the-napkin math, to see if would make sense to try it out (again).

I'm sure there are also other memory concepts, even I have not heard about. (Yes, I've worked with IBM S/38)

But what we have right now, huge flat memory spaces, physical and virtual, with a horribly expensive translation mechanism between them, and no pointer safety, is literally the worst of all imaginable memory models, for the kind of computing we do, and the kind of security challenges we face.

There are other similar "we have always done it that way" mental blocks we need to reexamine, and I will answer one tiny question below, by giving an example:

Imagine you sit somewhere in a corner of a HUGE project, like a major commercial operating system with al the bells and whistles, the integrated air-traffic control system for a continent or the software for a state-of-the-art military gadget.

You maintain this library, which exports this function, which has a parameter which defaults to three.

For sound and sane reasons, you need to change the default to four now.

The compiler wont notice.

The linker wont notice.

People will need to know.

Who do you call ?

In the "Rational Environment" on the R1000 computer, you change 3 to 4 and, when you attempt to save your change, the semantic IDE refuses, informing you that it would change the semantics of the following three modules, which call your function without specifying that parameter explicitly - even if you do not have read permission to the source code of those modules.

The Rational Environment did that 40 years ago, can your IDE do that for you today ?

Some developers get a bit upset about that when we demo that in Datamuseum.dk :-)

The difference is that all modern IDEs regard each individual source file as "ground truth", but has nothing even remotely like an overview, or conceptual understanding, of the entire software project.

Yeah, sure, it knows what include files/declaration/exports things depend on, and which source files to link into which modules/packages/libraries, but it does not know what any of it actually means.

And sure, grep(1) is wonderful, but it only tells you what source code you need to read - provided you have the permission to do so.

In the Rational Environment ground truth is the parse tree, and what can best be described as a "preliminary symbol resolution", which is why it knows exactly which lines of code, in the entire project, call your function, with or without what parameters.

Not all ideas are good.

Not all good ideas are lucky.

Not all forgotten ideas should be ignored.

Just think how many people the new owners can spy on, now that they control the backend-servers ?

Bandwidth is the only limit...

And that's precisely it.

Your right to encrypted communication, if there is such a thing, ends well before it is used to stage a coup or plan a bank robbery.

And now you overlooked article 52 ?

It's really very simple: NO human rights are absolute.

Which is /precisely/ what is going on right now:

ChatControl is a proposed new law, in compliance with the EU Treaty.

... Unless the EU courts find the law unconstitutionally broad.