That sounds like your answer is: "Yes, global variables".
That may be a perfectly good solution in many embedded environments, but in most other context's global variables are considered bad design or very limiting and impractical.
Even global mutable variables are a problem only because they lend to spaghetti code and messy state handling if you use them in multiple places. But you could just... make a global variable and then handle it like you would a variable init with malloc. No functional issue there.
As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec<u8, MAX_BUFFER_SIZE>, behind a embassy Mutex.
The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.
You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.
So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.
One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?
Not true at all. Swift is a very capable backend language, Apple has open sourced a lot of great libraries to power server software development, and there are projects like Vapor [0] that are used in production.
Ah. You're right, I phrased that ambiguously, sorry.
I meant to point out that there is no apple native cloud solution where you can run swift on apple hardware.
So if your iOS app needs to talk to a backend that you want to develop and host, you need to run that backend on an OS with cloud support, like Linux, some other Unix or windows. But not macOS or some other "Apple cloud" hosting.
For reasons stated above, you might in that case choose Swift.
Ah, gotcha—yes, that is actually a pain point and a strange omission. If you need to run backend code for any reason to support your app, Apple literally offers nothing.
IBM at one point offered Swift "serverless" lambdas/cloud functions, which made me briefly hopeful that Apple could do the same, but that service was deprecated years ago, and Apple has shown no motion there.
That, and it's solid, well supported software most people are familiar with.
From those doing the paperwork with Microsoft procurement for Dutch government I learned there have been legal disputes going on for years about what even constitutes "telemetry". That was a decade ago, and even then there was push to move away from Microsoft in the government. Toward open source, or even Oracle.
I suppose that with the Dutch being Dutch all the lobbying M$ needed was suggesting a discount.
The main problem is that 365 is just far cheaper than the competitors for environments like this, maintaining and supporting an open source alternative would be an incredibly expensive undertaking.
Yes, but to get something nearly as good as 365 would realistically cost 100x as much as just buying from Microsoft.
Who would you even hire to do this? A big consulting firm known for delivering poor quality software, or an unproven startup? What kind of a process could you use to make such a selection in a way that would ensure a good outcome?
It’s the same as the old libreoffice vs. MS office debate. Yeah, you can download libreoffice for free. It sucks. What sucks even more though is how much money you will spend on support, training and all the inevitable productivity losses associated with weird software that approximately nobody you hire will have experience with.
But these are "European Tenders", which in practice usually translates to: race-to-the-bottom. Unless the tender was phrased specifically, from its very first inception, to aim at some polical goal - like open source, sovereignty, innovation, inclusiveness, etc.
Stuff. Indeed it's mostly about stuff we buy (which is mostly from China).
If you want to lower emissions, not flying and not eating meat is important. But stuff we buy - clothes, electronics, cars, furniture, even solar panels: consider if you really need it, for how long will it last, and why can't it wait. Don't click "buy now"
Would you say that lowering the climate goals / increasing emissions could meaningfully alleviate pressure on the housing market, migration, groceries, energy, etc.?
One of the things we (the Netherlands) should do is get to a more average level on EU levels. Not trying to be the best. The costs are too high.
Also energy cost should be as low as possible. A few nuclear plants could be a good solution. (I’m not an energy expert) When you lower energy cost, the cost of all other things can also be lowered.
And that's a big big part of the issue, Germany said "fuck ghg" and closed their nuclear plants.
We also have soaring energy costs in Sweden.. but _only in the south_ close to Germany, in the north we still have plans on using relatively inefficient electrolysis to produce hydrogen to in turn reduce GHG's from steel production, because we have so much power generated from wind (uneven) and waterfalls (even).
Sweden is once again building nuclear plants after 40 years, but we could've started far earlier.
Not an expert either, but commonly nuclear energy tops the list of most expensive sources, even if we ignore cost of mining, waste storage and dismantling of old installations.
There are arguments to be made in favor of nuclear, but I don't think cost is one of them
The costs of nuclear are 80% in managing regulatory burdens, where laws require recertifying a design for every unit constructed and spurious lawsuits postpone beginning construction for a decade etc.
Another data point is to consider the price of nuclear submarines, in the 10s of billions. Admittedly, military spending leaves room for misestimation but the point is that many if not most of regulation around nuclear plants does not apply to marine vessels. Safety still plays a major role, but a very different one. More pragmatic, less regulatory.
Nope. The costs comes from being absolutely enormous civil project.
Construction workers haven’t gotten meaningfully more efficient while the salaries have risen based on industries with efficiency gains.
It seems like nuclear power has an extremely tiny sweet spot in countries development curve where it is only very expensive.
Right where salaries are still low but the knowhow for advanced technology has started to burgeon. For example India and China. Although China has been cutting back their nuclear program in favor of renewables for a while now.
> A few nuclear plants could be a good solution. (I’m not an energy expert)
You should look at the track record of recent nuclear projects in Europe. Olkiluoto and Flamanville both 3x+ over budget in time and money. Sizewell C isn't doing too well either, its very far from cheap.
Another analogy that might prove more apt than 17th century tulip mania is Russian railways at end of 19th / start of 20th century. All the private money going into "sovereign companies" that might be snapped at an instant by respective American/Chinese/Korean/Taiwanese government.
I have really interesting question for you: could you suggest any other transport for so terrestrial country as Russia, country level scale, NOW, even not start of 20th century?
Nothing wrong with building railways. And like tulip bulbs and AI some investment is indeed warranted.
The point is that people sometimes have way too high expectations about ROI and ignore or underestimate the greater (historical) context of the novelty.
Yes, even when you know what you're doing security incidents dan happen. And in those cases, your response to a vulnerable matters most.
The point is there are so many dumb mistakes and worrying design flaws that neglect and incompetence seems ample. Most likely they simply don't grasp what they're doing
> Overall simple security design flaws but it's good to see a company that cares to fix them, even if they didn't take security seriously from the start.
It depends on what you mean by simple security design flaws. I'd rather frame it as, neglect or incompetence.
That isn't the same as malice, of course, and they deserve credits for their relatively professional response as you already pointed out.
But, come on, it reeks of people not understanding what they're doing. Not appreciating the context of a complicated device and delivering a high end service.
If they're not up to it, they should not be doing this.
Yes I meant simple as in "amateur mistakes". From the mistakes (and their excitement and response to the report) they are clueless about security. Which of course is bad. Hopefully they will take security more seriously on the future.
I definitely don't want my traffic light controller to be written using manual memory management if this is at all possible to avoid. Waiting another millisecond for the light to turn green feels like an acceptable cost. But this seems silly: how on earth did you write such a simple program to have so many allocations that the gc significantly impacts performance? Why would a traffic controller need variable memory in the first place? Surely it's just a mix of a state machine (statically allocatable) and I/O.
"Determinism" feels like a very odd pitch for manual memory management when the latter in no way implies the former, and lack of manual memory management in no way implies non-determinism. Generally, any dynamic allocation is non-deterministic. Furthermore, in the HFT context the non-determinism of the network is going to absolutely dwarf any impacts GC has, especially if you have ever heard of arena allocation. Even your OS's scheduler will have larger impacts if you make any efforts to avoid memory churn.
Now, an interrupt handler should never allocate memory and should generally run with a constant number of cycles. But that's an extremely niche interest, and you'd probably want to hand-code those instructions regardless.
(FYI, I work in a support role to a HFT product, among many others, but it runs on the JVM)
That may be a perfectly good solution in many embedded environments, but in most other context's global variables are considered bad design or very limiting and impractical.
reply