Maybe they host it on Gaia-X, the failed attempt to compete with AWS and other US cloud providers. Money burns quickly when you give it to EU megacorps that are experienced getting EU subsidies.
In the end, even if there is some moderate success, the EU won't be able to keep the AI researchers because the high tax rates hit hard when you earn top salaries.
Because people in Europe are generally scared of a free market without strong social security, but believe in government oversight (no matter how often it fails).
In the usual contract, you pay an price of 40 cent per kWh, no matter when you use it. But that price is based on a year-round average. Actually, sometimes electricity is super cheap for the utility company, like when the sun is shining in summer and electricity prices go negative. And sometimes it is very expensive, like on dark winter days without sun and wind, when prices are >1 EUR/kWh.
What you can do with balcony solar is skip the cheap summer sun prices (which cost the utility nothing, but they still charge you 40ct), and you still buy at expensive times for 40ct, when it's actually worth much more.
In short term I think it is workable strategy. But in long term I expect the pricing to move more towards market price direction. Either by purely market or some strange adjustments based on consumption timing. And ofc transfer will go up...
I want to, at least if I get the same kind of severance package that people got in the last round of layoffs.
Stuck in this job at a senior level with >25 years of experience, in part because there is no plan/budget for promotions to principal engineer and in part because only few engineers are left in this country. Working from Europe in a global remote team of a well-known US company in rapid decline. Still profitable though. When interested in an open management position, I have been told that I am too technical for the role - which is kind of right, but I have worked as a tech lead and other people told me to that it would be a good fit for me. I'd just quit, but 100% remote is important because of my current family situation; the work itself is fine; I have a good reputation and am always put into the most interesting projects; it's quite relaxed (no overtime, no on-call) and the salary is ok'ish. The looming severance package in the next round of layoffs, which seems inevitable, would also offer financial security to start a new career, like freelancing. Unfortunately I seem to be too valuable to fire so far, but maybe they just end software development at this location.
I am not sure the author really knows what they're talking about when comparing today's web development with earlier systems.
First of all, the reason for useEffect() is not directly asynchronicity. It's mostly an optimization to give React control over what code it needs to run when the state changes. This is because with React, you basically re-render a document with every state change, and in order to speed this up, React needs to know what code depends on what part of the state. Admittedly not pretty, but all of the more automated MVC-like systems have mechanisms to detect or handle model changes.
They are completely wrong about asynchronicity. Since the 80s GUIs have been using event loops. Windows 3.x did this, and even really old UIs like GEM did. When using an event loop, you must execute operations asynchronously or the event loop will block. That's not new at all. What's new is that, these days, applications are interacting a lot with the network, and these are blocking operations. They require asynchronicity in an event loop. This wasn't really the case back in the days before the internet, when everything was local. And for longer computations you had to call functions like yield() to give time to the UI.
He mentions threads, but they didn't really became a thing before the early 2000s. And threads never worked very well with most UIs (except the good old BeOS?).
It's easy to complain about issues with today's development frameworks and easy to overlook the limitations in the past. UI development was always a pain, especially for applications that are larger than the typical demo app. I have worked on apps using GEM, MFC, QT, GTK, TCL/TK, AWT, Swing, JavaFX... it doesn't matter. It always sucks one way or the other.
Today's web-based UIs and their dev tools are a marvel in many ways. Like you can easily update them without going from computer to computer, or let user run install programs. They easily adapt to all kinds of screen resolutions and screen orientations. You can easily debug them in the browser, even on an enduser's computer. You have package managers that make it easy to add and later update libraries. Certainly not everything is perfect, I still kind of hate UI development, but it's a huge improvement over everything we had in the past.
Hard agree. They also glossed over JS using a single threaded model precisely to avoid the huge mental overhead of dealing with multi-threaded models (I'm saying this is why it happened and this is the problem they aimed to solve, not advocating either way).
The other thing they've missed in why people moved to react in droves is so simple it's possible we've just forgotten it because it's become such a de-facto approach: co-location of declaration, behaviour and styling.
React took us out of the "X belongs with all the X things" mental model and allowed us to create isolated "X does this and looks like this" things that require far less mental overhead to drop into while making changes to a potential foreign codebase.
This is _exactly why_ Facebook preferred React to the status quo. Engineers changing one thing in one place with predictable effects is wonderful for teams operating at wide/deep scales.
Again, I'm not advocating for any of this, I just don't think skipping over history or twisting it into an unrecognisable ball gives any forward momentum to conversations about the evolution of UI/UX.
...but still, if the user space process is broken, MacOS will fail as well. Maybe it's a bit easier to recover, but any broken process with non-trivial privileges can interrupt the whole system.
It's certainly not supposed to work like that. In the kernel, a crash brings down the entire system by design. But in userspace, failed services can be restarted and continued without affecting other services.
If a failure in a userspace service can crash the entire system, that's a bug.
It's kind of inevitable that a security system can crash the system. It just needs to claim than one essential binary is infected with malware, and the system won't run.
Let's say MS does not allow third party drivers at all. Then they would have a monopoly over software drivers and system software like security systems. I doubt regulators would want that.
Can you name examples that you believe should not be cut?