I already saw it in my life: a ban on calculators, a ban on computers. But after a short period of rejection, everybody starts to embrace the new tech. Instead of bans we were getting computer classes in schools.
> after a short period of rejection, everybody starts to embrace the new tech
We’re banning cell phones in school after seeing the evidence, albeit along a class gradient. We’ll probably see something similar with AI. Poor kids get AI in school (and unmonitored at home). Rich kids do not.
I did mathematics, and a fair bit of computer science on the side. This was nearly all on paper, without computers. And I'd go a week or two without a calculator sometimes, mostly employing it when I had a bad hangover.
Do we really need to force technology into everything or are we just used to doing it so see it as necessary?
I did mathematics on paper, and informatics on computers. Some of my peers weren't so lucky, so they had to do informatics on paper only. Needless to say that the magnitude of progress we were getting in informatics had day and night difference, not in the favor of paper.
AI is indeed dangerous. It gives super abilities when in the right hands. Some people don't like it as it creates competition for their mere existence. They start gaslighting campaigns - "AI is bad, dangerous, does not work, consumes too much energy etc". This is luddism of our century, but also a form of psychopathy. When everybody is being gaslit, some of the very same players who spreads false narratives use AI to their own benefit.
It’s a fully centrally controlled technology that reduces your ability and makes you dependent on it to perform all daily and business functions with a huge environmental and economic impact. The economic impact is both the risks imposed by it failing and the risks imposed by it being successful.
Calculators might be allowed sometimes, but i dont think they are ever allowed when you are trying to teach school children how to add and multiply. Which feels like the appropriate comparison.
For what it's worth, RAM encryption belongs to professional SKUs. It's the right business decision that should have been made from from the very beginning.
For most consumer users, RAM encryption primarily adds power consumption and heat generation while providing little practical benefit. They simply don't face many of the threat vectors and attack scenarios that certain industries and enterprise environments must contend with.
I disagree, I play a lot around with enterprise stuff. Its insane that I need to buy enterprise grade hardware that costs 1000x more for lab/experimentation/learning. My only alternative is to wait a few years, and get it from Ebay.
I also believe that a strong reason that Optane pdimm's failed, was that it was only available on enterprise servers so hackers didn't get a chance to play with it and build software that took advantage of this special hardware.
Just look at how specialized Infiniband is, even though its awesome and has some great use cases. If it was a commodity tech, there would be 100x times more applications/software that took advantage of it.
ECC passively benefits everyone, even people who don't know what it is or why it's useful. Anyone can be a victim of random bit flips, it's not a targeted threat.
Memory encryption, on the other hand, provides absolutely no benefit to 99.999% of users. If you consider yourself to be such a high value target that you suspect someone might gain physical access to your hardware without your knowledge and carry out extremely sophisticated hardware attacks to extract your data, you are a tiny minority and it makes sense that such niche protections would require buying specialized hardware. Even then, the odds of such an attack being chosen instead of a far less sophisticated software-based approach are also tiny.
Of course, if the hardware itself supports the feature and AMD simply decided to disable it, that's still a shitty thing to do, but let's not pretend that it is in any way comparable to ECC.
Memory encryption can help mitigate much lower level attacks such as row hammer, these attacks get patched even average consumer devices.
No benefit for 99%? people said the same about FDE. Just as there is not a good enough excuse to not validate integrity and availability of data, it is not for confidentiality when its very much technically possible to do so.
Great, so they just need to create and maintain a completely different method just for consumer instead of the already existing prosumer encryption without the added benefit of security and most likely even performance reduction because encryption has hardware acceleration.
This is an absurd take since the referenced chips in the article are all desktop parts, and the power usage is dwarfed by any “modern” (within the last five years) GPU.
There are many people, myself included who opt to use security features like this. All this does is reduce security for folks without any legitimate reason. “Power consumption” is absolutely not a valid excuse to completely disable it.
I’ve been a fan of AMD for a while now but they’re really jumping the shark these days. It’s a real shit situation we’re all in because of the lack of competition in consumer CPUs. I can only hope things like RISCV take off sooner than later.
Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO.
A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its main purpose of providing easy interoperability between different ecosystems is totally lost.
I do not know why WebAssembly committee thinks that shoving-in CORBA-like monstrosity is even an acceptable idea. Let's keep WebAssembly lean and fast! Anything extra can (and should) be implemented by other technologies.
The component model is what unlocks relatively type-safe interop between modules written in different languages. Given that Wasm is a runtime target for many languages, this is an entirely appropriate and useful goal.
If you have a host system where you want to expose APIs in an language-agnostic way, IDLs are the best way to do that.
You're also conflating the core WebAssembly work with the WASI work. There is some overlap in people, but WASI is developed separately.
There is a wat (s expression) syntax for the component model. The problem with the wat syntax for both Wasm and the component model is they’re a reflection of a binary format, and therefore are terrible for writing by hand. They’re designed to be written by tools, and the text format is just to help you understand the binary format.
I’ve written Wasm and component model wat extensively over the last decade to develop tests for Wasmtime, and even for an expert it’s a bad experience.
Wit syntax is easy to read and write by hand. There are high quality parsers that can transform it to and from the binary or wat format as needed, and code generators for a wide range of languages. It’s a way, way better experience in every way to deal with wit compared to the wat format.
Seconding this. Writing .wast files by hand is kind of fun as a novelty, but it's in no way something I'd want to maintain interfaces in.
Declarative interfaces via the WIT format are so much more readable in comparison; I'm really happy that's the direction we took for the component model.
The present component model is "simple and stable". It is presently providing "interoperability between different ecosystems" and has been for years. It has basically nothing in common with CORBA. All the major problems with the Unix design they ran into that caused them to switch to a component model haven't vanished; the component model is still the best way of solving WASM's major complications that traditional C-based designs don't have. C-based designs, in general, are not better just because they came first; if you were designing systems programming from scratch, you'd want something like WIT (proof: Microsoft has done this twice now).
WASM component model is internal to the WASM project, isn't it? As such, it provides interoperability for one and only ecosystem (WASM), and thus has no chances to be perceived worthy and universal enough for people to care, that's the point.
What are you talking about? The point of WASI is to stabilize WASM's access to OS APIs. It uses the component model to do this, which is bound to by languages that compile to WASM and by runtimes that run WASM. That is the only kind of interoperability that is required for this WASM system for WASM components to do WASM things.
I agree. This is saddening. It seems to often happen in "standard first" scenarios for some reason. I was very happy when CloudABI and POSIX were picked as prior art inspiration.
Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?"
Maybe I am missing something, but are the recent changes something that people requested?
Yes, you missed people asking for years: away to do interop between languages in WASM, a way to interact with browser APIs without JavaScript from WASM.
This problem stems from the lack of a standardized component model. WASM is merely another casualty of that deficiency - one among hundreds of affected technologies.
The alliance is attempting to solve the problem at the wrong level and only for WASM, rather than addressing the root cause in a way that would benefit everyone.
Fair enough. Isn't that another topic more tied to WASM compare to what initially claimed to be a "System Interface" and not a language interface or a browser interface?
Do you know see how components model solves all three?
If WASI decided to keep bespoke runtime capabilities, then you would have whole zoo of:
- this runtime does support WASI
- this runtime does NOT support WASI
- this one supports WASI, but only older spec
- this claims to support WASI, but X/Y/Z capabilities are bugged
I think WASI switching to components was the right move. Sure, tooling right now maybe meh outside of rust (and even rust is still meh), but once things stabilize good tooling is to follow.
Note that wasm is still lean and fast - WASI is not part of core wasm, but layered on top.
That is, it is possible to implement wasm without WASI. That is also true for other wasm proposals like WasmGC. It is very possible that parts of the ecosystem will not implement certain proposals if they don't make sense there (e.g. parts of the embedded ecosystem may never add GC, etc.).
I have seriously attempted to write my own WebAssembly 3.0 implementation recently, and while I did finish the whole thing [1] that left me a bitter taste about WasmGC which turned out to be very annoying to implement. In fact, I originally wanted to avoid GC but spectest assumed that GC is always available and I had no other option but implementing one in order to make use of spectest in the first place.
AIUI, the underlying motivation for the WASM component model is the same as for the early interface types proposal, which has been a planned part of WASM since the very beginning - namely to allow modules written in high-level languages to expose "native" interfaces, without requiring a completely bespoke translation into WASM's lower level facilities. That's a sensible goal, even if achieving this may ultimately involve something that's at least loosely reminiscent of CORBA.
i don't think people calling it CORBA-like are doing it in good faith, but regardless, no we should not do unix apis everywhere for the rest of time please
I think there is a difference between "just copying" and "building upon understood systems and standards".
Also to be fair "just copying" works really really well, especially for standards. The primary goal of standardization is not to invent something new, but to have a target that isn't constantly moving.
If you want to build something new and better do that, and if you are ready to build a standard based of it which is very valid. You can also build them together, and CloudABI which they mention as inspiration in their readme for example did it that way. All valid paths.
But you want to start out simple and something common so that people that make use of the standard have an easy time to implement it. After all having more than one implementation is why you need a standard. Otherwise it's maybe a specification, which again, fair enough.
I can stand behind not copying Unix until the end of time, but "Unix" is a common target that people know how to implement and use. And while not even the authors of Unix claim it's great or even good it is something that people already implement (often enough even when not targeting anything unixy at all) so if your goal is to create a standard that those people can target then abandoning that does seem like a wrong move.
Unix is completely inapplicable to this environment which is inherently managed and intraprocess. Why not send an object saying what you want instead of a plain C struct, or worse a bunch of ints? How do we handle ownership across these boundaries? Why should two high level components be forced to squeeze into a primitive bottleneck between them?
Don't get me wrong: I think C is cute and fills a niche decently well. But that niche is not the one we have here.
The reasons why Unix displaced a bunch of more elegant systems were downward scalability, free distribution, and positioning to take advantage of network effects. Quality was secondary, especially with multiprocessing and networking where a lot had to change, and the designs were not always good.
Even if something lasts due to pure inertia it lasts. And something that lasts is pretty nice if you want a standard to last, or be implemented. The standard usually isn't the thing that you use to proof you can do something better, by being different. Because then everyone will have a harder time adapting it. People implement interfaces they dislike.
Since this is related to Webassembly, Browsers, the Web. The web has a lot of historically baggage, that one might have to work around at times, sometimes more sometimes less. There are good bits and not so good bits and in the end a lot of the time more modern web applications (whether you think they are good or bad) as well as web browsers jump through hoops to do things. For many applications there would be better protocols. But it became the dominant standard, a standard that is actually being used a lot and that is why it has become a success story. It wasn't a hundred times better than everything else. It simply was something that people managed to implement successfully and something where they were willing to deal with shortcomings, because there are great benefits in implementing the same standard as everyone else.
Don't know much about the US constitution, but it seems that it was largely good enough to make people work together that otherwise might have ended up fighting each other. That's what you'd get if everyone had a different idea about what a good constitution is. Maybe things are unclear, and maybe there are uproars because of things, but it doesn't even get to that if people don't agree on a standard or a constitution in first place.
And while over the years I often imagined how great it would be if everyone just used that better standard that has been there for a long time and nobody uses and is completely forgotten, if it ever had any popularity, then everything would be so much better and greater and I wouldn't have to do that senseless thing I am doing now. But if that standard doesn't allow for people to agree with it by implementing it it's essentially worthless (outside of maybe "prior art" consideration).
And like it or not we currently live in a world where designs persist due to pure inertia. But we know that obviously people are willing to implement these which means when a standard comes along that is similar to what already is there then having many people adapting it is realistic. Otherwise it's that super interesting university project that never makes it into anything in the real world.
It clearly hasn't, if you've been paying any attention to security. The Unix security model is that all code that a user runs is 100% trusted. That's absurd in today's world.
The WASI standard is not at 1.0 yet! The people designing WASI are still trying to figure out what people want WASI to be at this point.
This is very likely to involve a lot of major reworking before 1.0, in response to feedback from orgs actually trying to implement WASI-based WebAssembly embeddings into their systems and runtimes. 0.1.x -> 0.2.x was one reworking; 0.2.x -> 0.3.x is another. There may be more of these before an approach is finally settled upon / "locked in" for 1.x.
---
> Let's keep WebAssembly lean and fast!
AFAICT, the entire point of the changes (incl. the more detailed component model) in WASI 0.3 is performance. Not performance of WebAssembly as a black box, though; but rather, performance of the running system as a whole, when a lot of FFI traffic is flowing across the WASI boundary. The richer component model enables lower impedance mismatches and "thinner" FFI-layer implementations.
For example, from the OP:
> WASI 0.2 handed you an output-stream that you wrote into imperatively. WASI 0.3 has you pass in a stream<u8> and get back a future that resolves when the write completes.
For some host languages/runtimes, "imperative blocking write calls" is already how writes against IO descriptors are exposed to the programmer. For those languages, WASI 0.2 made sense.
But in other host languages/runtimes, writes against IO descriptors are inherently non-blocking, returning promises or yielding. For those languages, WASI 0.2 "left performance on the table." WASI 0.2 required such languages to implement a blocking IO write abstraction on top of their non-blocking IO write semantics, in order to pass that blocking-IO-write primitive into the WebAssembly componennt... even if the WebAssembly component was internally concurrent (e.g. compiled from a language like Golang) and so would highly benefit from a non-blocking-IO-write primitive!
Meanwhile, if you require that the host expose a non-blocking-IO-write primitive (as WASI 0.3 does), then for hosts with native non-blocking IO, doing so is free; while for hosts with only blocking IO, non-blocking IO can be "faked" basically for free (i.e. with a global or per-resource linearized write queue on the host side.) And likewise, non-blocking-IO-aware WebAssembly components can freely take advantage of NIO; while WebAssembly components that expect blocking IO only need the tiniest added bit of a codegen shim (`blocking_write(x) => await nonblocking_write(x);`) to fit into a WASI 0.3 world.
In other words, implementing nonblocking IO abstractions on top of blocking IO abstractions costs FFI performance, but implementing blocking IO abstractions on top of nonblocking IO abstractions is "free" (in FFI terms.) Nonblocking IO should therefore be considered the more "primitive" of the two; and so, if you have to choose only BIO or NIO to expose as a capability across a boundary to an unknown peer, NIO should be the one you choose.
---
That being said...
The WASI devs were likely aware of the "FFI optimization opportunities being left on the floor" in WASI 0.2. They likely already wanted to take things in this direction from the beginning. But in WASI 0.2, without async, it was impossible to express the concept of nonblocking IO (i.e. of IO operations returning a promise/future.) They needed to introduce this more "opinionated" (i.e. richer) component model in order to get here.
AFAICT, WASI 0.2 was never intended to be a Release Candidate of the WASI spec. (And WASI 0.3 likely isn't either!)
Rather, WASI 0.2 had areas (like IO) that were purposefully left "under-baked". The WASI team knew people needed some version of these primitives in order for WebAssembly components to usefully integrate into systems at all. But they hadn't yet put in the work on designing how certain aspects of WASI (e.g. async) would work. So they designed WASI 0.2 as a prototype design, based on the limited toolbag of primitives they had already fully agreed upon. Some aspects of WASI turned out to only "want" that limited toolbag of primitives, and so didn't change at all under WASI 0.3 (and might even be in their final shapes.) Other aspects "wanted" things that weren't there, and so experienced over-constrained designs under WASI 0.2, replaced with less-constrained designs under WASI 0.3.
I fully expect there will be more such changes under WASI 0.4. If you don't want to be a guinea pig for major WASI changes, you might want to wait for WASI 1.0. (However long that takes.)
Orbstack is essentially a happy-path-only contraption that quickly breaks once you happen to take a less visited corner of the street. For example, if you happen to have multiple users who needs to work with it... good luck trying to clean up your system afterwards. So, it's a yoke as well. Maybe a better one for some people, but still a yoke.
Exactly this. ISPs are tricky players when it comes to peering. A typical symptom: servers in local region/country can easily saturate the connection, when anything external gets cropped down to 20-50% of a declared full speed.
To improve reliability, you can use multiple services from different vendors and implement automatic roll-over with Mikrotik and the likes. This is something I have been doing back in the day for the enterprise I am still working at.
I did it at home as well. At least 2x more money to pay, but it was worth it because my bread and butter depended on having stable internet connectivity.
For a developer, there is a lot of benefits in having at least 1 Gb/s internet connection. Obviously, downloads of software, docker images take significantly less time than 100 Mb/s connection could ever provide. But the benefits do not end there. Publishing of build artifacts, websites etc. are significantly sped up as well.
And the most important perk: you can self-host certain parts of your infrastructure by keeping VPS or cloud-based facade for SSL termination, while back-channeling all the traffic to the actual worker machine that sits in your basement behind the NAT. By doing so, you can immensely economize on your monthly spend by reducing it N times, where N is typically ranging from 2 to 10.
P.S. Some context: I am a long time internet user who first connected in 1996 and went through every wave of infrastructural changes, starting with dial-up 33 Kb/s, then 56 Kb/s, then dorm ethernet 10 Mb/s, followed by DSL 20 Mb/s, fiber 100 Mb/s, fiber 1 Gb/s.
I've been doing that for years: free tier Oracle VPS purely as an SSL termination+WireGuard endpoint, and all traffic is routed to the server in my home office.
It's really great to have 2.5G all the way through from the VPS to my router to the server.
That's why encountering something like LISP for the first time (by writing a LISP interpreter, for example) creates a big bang event in form of an imminent intellectual catharsis. People who encountered it just once, will never be able to see the world through the old "meaty" lenses afterwards.
reply