Run on server, chroot into target environment, configure compiler flags for eventual target, done. It's really just an afternoon of setup and then the problem is solved.
Who actually pays for what and how is so mangled that if you want to reallocate someone to another project (or even just pay them out of a different pool of funds!) often the easiest approach is to rehire them through a contractor, or a different contractor.
This is especially useful when projects are wound down. Let's say you've contracted to an org for support or management on a project that you want to kill, you've already obligated some amount of funds, and you don't really want to make that organization angry by ripping millions away from them (the pool of contractors is not large). What to do? Well, you could take Joe and give him a raise by suggesting he work for the contractor instead of you directly. Money's already spent, anyways. So you save your own money that you can use for your pet projects or whatever, Joe gets a raise, the contractor doesn't get a termination that pisses everyone off. Everyone happy, right? Smh.
There's likely always going to be value in limiting the number of $200k+ SWEs you have to pay. But that's not the interesting case.
What about the $10k/year offshored employees that are getting replaced by AI call centers? If that were the break even, then once you close down the whole building and develop the systems to not need them, then how much would inference costs have to go up before all that gets unwound and handed back to humans? It's more than you think - there's real margin there.
There's a lot of maintenance that is much easier/cheaper to do when the apartment is unoccupied, so the default is "do nothing, then when the tenant moves out in a year or two, do a couple years of maintenance much more affordably."
With your gym, for example, when it's new, you can do all the work you want. Once people are using it every day (especially if it's a 24/7 facility!) how exactly do you get in to do major work without making a bunch of people annoyed that half the gym is out of service for three weeks? You don't, until it gets to the point that people would prefer the downtime ... and this takes a surprising amount of grime.
Uber's situation is exactly the same. OpenAI is offering inference for a bunch of industries at prices that make it more competitive than hiring humans to do the same work.
If the break-even price to actually provide the service wasn't actually economic compared to humans, would there be nearly as much of a market? That's the real question. OpenAI is basically betting that they can live long enough that AI systems get built around them, which creates enough of a lock-in that they still have customers when prices increase by a lot.
One heuristic I use to avoid this exact problem is "minimize the number of places that the next poor soul has to look in order to understand how this code works", where place is loosely defined as about the number of lines of code that fit on a screen or two.
This has given really good results in terms of helping decide whether to extract these helper functions or not - they have to both be memorable enough in name and arguments that the code calling them can understand what's going on without always having to dive in, and also provide a meaningful compression of the logic above so that it can be comprehended without having to jump across many hundreds of lines.
Mobile users (or other locked down devices where adblockers are forbidden) are still a decent chunk of traffic. It's much easier to just read the overview and not click through to the ad infestation, or even use a chatbot of choice as the search engine instead of going to Google, because "websites is how you get spammed with ads".
2. Brand quality went down to equivalent or less of no-name dropshipped goods in order to keep similar dollar prices for goods.
3. Cost of real estate spiked incredibly, putting even more pressure on retail margins.
4. American logistics is seriously good, in cities 24-hour delivery can be common even for small or inexpensive things.
5. Once there wasn't a quality or convenience reason to prefer the shopping mall, many were already struggling quietly, they just hadn't run out of cash yet.
6. The pandemic happened right as all these things converged, accelerated all of them, and wasn't really recoverable.
It allows the code to be fully public domain, so you can use it anywhere, while very strongly discouraging random people from forking it, patching it, etc. Even still, the tests that are most applicable to ensuring that SQLite has been built correctly on a new compiler/architecture/environment are made open source (this is great!) while those that ensure that SQLite has been implemented correctly are proprietary (you only need these if you wanted to extend SQLite's functionality to do something different).
This allows for a business model for the authors to provide contracted support for the product, and keeping SQLite as a product/brand without having to compete with an army of consultants wanting to compete and make money off of their product, startups wanting to fork it, rename it, and sell it to you, etc.
It's pretty smart and has, for a quarter century, resulted in a high quality piece of software that is sustainable to produce and maintain.
My 10hr drives usually have 2 stops at 30mins-1hr each, for food. Unfortunately, stopping at a restaurant for a meal doesn't leave the vehicle in a location that has a charger, for the most part. Other parts of the world may differ, but the infrastructure to "just spend 15 minutes charging" whenever you want is not there.
Something to consider is that in a secure environment like LANL, and especially for a non-standard or one-off process, it's likely that there is no computer system that everyone has access to with all the information.
It would not be unusual for the person being told to write the process document to be brought into a room with a notebook, be shown written or electronic materials in the room, take notes in a provided notebook, have that notebook be handed over after the meeting for a (non-technical) security review, then receive the notebook pages some days/weeks later and have those notes be what is used to develop the document. Security culture is good for security but bad for error-free processes involving people.
Yes, but my junior coworkers also don't reliably do edge case testing for user errors either unless specifically tasked to do so, likely with a checklist of specific kinds of user errors they need to check for.
And it turns out the quality of output you get from both the humans and the models is highly correlated with the quality of the specification you write before you start coding.
Letting a model run amok within the constraints of your spec is actually great for specification development! You get instant feedback of what you wrongly specified or underspecified. On top of this, you learn how to write specifications where critical information that needs to be used together isn't spread across thousands of pages - thinking about context windows when writing documentation is useful for both human and AI consumers.
Of course, you can do this in good conditions. The extremely powerful part that TrueTime brings is how the system degrades when something goes wrong.
If everyone is synced to +/- 20ns, that's great. Then when someone flies over your datacenter with an GPS jammer (purposeful or accidental), this needs to not be a bad day where suddenly database transactions happen out of order, or you have an outage.
The other benefit of building in this uncertainty to the underlying software design is you don't have to have your entire infrastructure on the same hardware stack. If you have one datacenter that's 20yrs old, has no GPS infrastructure, and operates purely on NTP - this can still run the same software, just much more slowly. You might even keep some of this around for testing - and now you have ongoing data showing what will happen to your distributed system if GPS were to go away in a chunk of the world for some sustained period of time.
And in a brighter future, if we're able to synchronize everyone's clocks to +/- 1ns, the intervals just get smaller and we see improved performance without having to rethink the entire design.
Now, try and use two or more libraries that expose data structures with bitfields, and they have all chosen different crates for this (or even the same crate but different, non-ABI-compatible-versions of it).
There's a ton of standardization work that really should be done before these are safe for library APIs. Mostly fine to just write an application that uses one of these crates though.
2. Can modern GPU hardware efficiently make system calls? (if you can do this, you can eventually build just about anything, treating the CPU as just another subordinate processor).
3. At what order-of-magnitude size might being GPU-native break down? (Can CUDA dynamically load new code modules into an existing process? That used to be problematic years ago)
Thinking about what's possible, this looks like an exceptionally fun project. Congrats on working on an idea that seems crazy at first glance but seems more and more possible the more you think about it. Still it's all a gamble of whether it'll perform well enough to be worth writing applications this way.
These things are amazing for maintenance programming on very large codebases (think, 50-100million lines of code or more, the people who wrote the code no longer work there, it's not open source so "just google it or check stack overflow" isn't even an option at all.)
A huge amount of effort goes into just searching for what relevant APIs are meant to be used without reinventing things that already exist in other parts of the codebase. I can send ten different instantiations of an agent off to go find me patterns already in use in code that should be applied to this spot but aren't yet. It can also search through a bug database quite well and look for the exact kinds of mistakes that the last ten years of people just like me made solving problems just like the one I'm currently working on. And it finds a lot.
Is this better than having the engineer who wrote the code and knows it very well? Hell no. But you don't always have that. And at the largest scale you really can't, because it's too large to fit in any one person's memory. So it certainly does devolve to searching and reading and summarizing for a lot of the time.
Good on the Arduino folks for getting acquired, then. They still have a niche and a brand with name recognition, even if that niche might be stable at best, collapsing at worst.
Quite a few radar systems are in the 8-10GHz range and satellite communications just above that. The general idea when using a SDR for these things is to have a separate frequency converter & amplifier at the antenna feed itself, then have an intermediate frequency <6GHz fed via cable to the SDR. Tends to be much easier and cheaper this way.
The threading model is still difficult, and it's still enough slower that thinking you're going to be comparable to custom silicon that's been designed for a particular protocol is silly.
It's great fun for doing signal analysis, but I'd never want to try and implement a full-duplex communication system in production with it.