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.
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.
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.
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.
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.
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.
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.
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.
Nightmares? Compared to other things we can encounter, .NET custom attributes are like a mild ocean breeze on a sunny day. Yes, their binary serialization depends on a functioning type system, and yes, type reference storage is not terribly efficient. But it rarely if ever poses problems in real projects.
For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...
Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.
Deno rules, I write some tiny and mid-size web services using it. Works like a Swiss clock, the project ideology is well aligned with the Unix sprit.
In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.
What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.
We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.
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.