structural

1. Americans got a bit poorer due to inflation.

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.

1. What does it mean to be a GPU-native process?

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.

Is this a EU-specific thing? In North America I've never installed a banking app, don't even know if my institution even has one.

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.

The more fine-grained you make a capability system, the more you have an explosion of the number of permissions required by an application, and the chance that some combination of permissions grants more access than intended.

It also requires rewriting all your apps.

It also might require hardware support to not be significantly slower.

"Just sandbox each app" has much fewer barriers to entry, so people have been doing that instead.

And systems like Android have been working with discrete permissions / capabilities, because they were able to start from scratch in a lot of ways, and didn't need to be compatible with 50 years of applications.

LLMs are approximately your employees on their first day of work, if they didn't care about being fired and there were no penalties for anything they did. Some percentage of humans would just pull the nearest fire alarm for fun, or worse.

A good simplification of what's going on is this little loop:

1. LLM runs using the system prompt + your input as context.

2. Initial output looks like "I need more information, I need to run <tool>"

3. Piece of code runs that looks for tool tags and performs the API calls via MCP.

4. Output of the tool call gets appended as additional context just as if you'd typed it yourself as part of your initial request.

5. Go back to step 1, run the LLM again.

So you can see here that there is no difference between "content" and "prompt". It's all equivalent input to the LLM, which is calling itself in a loop with input that it generated/fetched for itself.

A lot of safety here happens at step #3, trying to look at the LLM's output and go "should I actually perform the tool call the LLM asked for?". In some cases, this is just spitting the tool call at the user and asking them to click Approve/Deny... and after a hundred times the user just blindly presses Approve on everything, including the tool call called "bash(sudo rm -rf /)". Pwned.

1. If you want to advance the state of the art as quickly as possible (or have many, many experiments to run), being able to iterate quickly is the primary concern.

2. If you are publishing research, any time spent beyond what's necessary for the paper is a net loss, because you could be working on the next advancement instead of doing all the work of making the code more portable and reusable.

3. If you're trying to use that research in an internal effort, you'll take the next step to "make it work on my cloud", and any effort beyond that is also a net loss for your team.

4. If the amount of work necessary to prototype something that you can write a paper with is 1x, the amount of work necessary to scale that on one specific machine configuration is something like >= 10x, and the amount of work to make that a reusable library that can build and run anywhere is more like 100x.

So it really comes down to - who is going to do the majority of this work? How is it funded? How is it organized?

This can be compared to other human endeavours, too. Take the nuclear industry and its development as a parallel. The actual physics of nuclear fission is understood at this point and can be taught to lots of people. But to get from there to building a functional prototype reactor is a larger project (10x scale), and then scaling that to an entire powerplant complex that can be built in a variety of physical locations and run safely for decades is again orders of magnitude larger.

Where it really has value is if what you work on is like 33% extremely difficult and 66% boilerplate/tedious. Being able to offload the tedious bits can make more senior engineers 2-3x more productive without the coordination effort of "find a junior engineer to do this, schedule their time, assign the work, follow up on it".

(The problem of course is you still need these junior engineers to exist in order to have the next generatino of senior engineers, so we must now also think about what our junior folks should be doing to be valuable AND learn).

There really isn't a great solution here. The notice that a vulnerability has been discovered puts even more pressure on the fix to be deployed as close to instantly as possible, throughout the entire supply chain.

Why is this? Especially for smaller or more stable open-source projects, the number of commits in a 90-day period that have the possibility to be security-relevant are likely to be quite low, perhaps as low as single digits. So the specific commit that fixes the reported security issue is highly likely to be identified immediately, and now there's a race to develop and use an exploit.

As one example, a stable project that's been the target of significant security hardening and analysis is the libpng decoder. Over the past 3 months (May 1 - Jul 29), its main branch has seen 41 total commits. Of those, at least 25 were non-code changes, involving documentation updates, release engineering activities, and build system / cross-platform support. If Project Zero had announced a vulnerability in this project on May 1 with a disclosure embargo of today, there would be at most 16 commits to inspect over 3 months to find the bug. That's not a lot of work for a dedicated team.

So now, do we delay publishing security fixes to public repos and try and maintain private infrastructure and testing for all of this? And then try and get a release made, propagated to multiple layers of downstream vendors, have them make releases, etc... all within a day or two? That's pretty hard, just organizationally. No great answers here.

Would be interesting to see a compare and contrast between this and Typst, which has gotten a lot of attention recently.

Kinda surprising that it isn't mentioned in their feature comparison matrix at all.

1. The initial price of the ticket serves as advertisement to get more people interested in the event than if it was advertised at the scalped price. Some fraction of the people will end up paying the higher price anyways, even if it was more than they intended to spend. The chance of "getting lucky" and getting a ticket at the low initial price is a powerful draw, especially if each buyer gets lucky a few times.

2. Are you sure the scalpers and the agency selling the original tickets are independent? Even if they are on paper, in many locations there is evidence of a local cartel.

3. The initial sales provide revenue up front to pay for the costs of the event, vendors, etc. This reduces the amount of cash reserves the seller needs, sometimes very dramatically.

4. Many scalped sales (used to be, not as much anymore) were cash transactions. This used to be used as a pretty significant tax dodge: Sell tickets for $50 face value to your affiliated scalper, pay tax on this sale, scalper sells tickets for $200 and does not pay tax on this secondary sale, or underreports the number of secondary tickets sold. Lots of shenanigans here to make your profitable scalping business look like it's making a small loss on paper.

5. Especially in the context of a local or regional cartel, each ticket sale represents the opportunity to move capital between entities. Physical tickets can be an effective vehicle for small-medium scale money laundering: Dirty money/entity buys the tickets, clean entity resells them.

Basically as soon as you drop the assumption that the ticket sellers and scalpers aren't related in some way, there are a lot more profitable reasons for the ticket sellers to "leave money on the table".

I was just looking for something very similar, this is neat!

I think even moreso I can understand the sense of Rust feeling too large not because the language itself is, but because there are SO many of these neat tricks and little utility functions that are necessary to express what you want, and it's quite impossible to remember each and every one and how to go back and find them later.

One major difference is that while indexing, you're generating an internal data structure that represents that site. Once done, if the site doesn't change, you don't have any need to revisit it, and in fact, fetching the site multiple times just increases your own costs.

On the other hand, an unsupervised AI training algorithm may just need raw text, and as much of it as possible. It doesn't know what site it came from or much care, and it's not building any index that links the content back to its original source. So fetching the site on each training epoch might actually be viable: why bother storing the entire internet when you can just fetch -> transform -> ingest into your model? If your crawler is distributed enough, it won't be the bottleneck, either.

If this is the architecture some companies are using, this also means that these crawlers won't ever stop, because they are finetuning some model by constantly updating over time based on the "current" internet, whatever that might mean.

The underlying issue is that many sites aren't going to get feedback from the real people they've blocked, so their operators won't actually know that tuning is required (also, the more strict the system, the higher percentage of requests will be marked as bots, which might lead an operator to want things to be even more strict...)

Good connectors are expensive. All-plastic connectors like these are extremely cheap. Here's an example of a connector style as used in internal PC power cabling:

https://www.digikey.com/en/products/detail/amphenol-icc-fci/...

This is $0.20/ea in bulk from a distributor, after import into the US, and after distributor markup. Probably $0.10-0.15 or even less at he scale board manufacturers are working at. You have 4 of these kind of connectors in your system (1 on the GPU, one on the power supply, and two on the cable). So still <$1 total in volume.

A quality d-sub power connector that has a metal housing and screws in place is going to be about $10/each. That's $40 just in connector parts, just to power your GPU, not including every other power cable in the unit, and not including all the herding cats you need to do to get the entire PC industry to shift over to using your new connector.

So, yes, you could do this, but you'd probably double the cost of a PC power supply (if all connectors used were upgraded to the same standard) and increase the cost of every GPU by $100-200, minimum.

People are already complaining that modern GPUs cost too much, so businesses making parts have assessed that it hasn't been worth it to spend this kind of money on connectors. Now, this may change at 600+W... clearly something has to change soon, as we're seeing the limits of what the existing standards can do.

Interesting, we're using a completely different module (Xavier NX). And the same, disgustingly hacky, fix, of forcing a reset until it works.

Mind sharing what board/Jetson module you've seen this on? I've seen this exact symptom very intermittently on a custom board and we've wondered for a long time if was an issue with a specific type of module (or manufacturing lot of modules).

> the point of all those processes is to help you make things more efficiently

I think this viewpoint -- that these processes somehow could increase efficiency if only they were good -- has a lot to do with why engineers dislike systems like Jira, because they will never see the increased efficiency they are looking for.

Let me restate it in a way that I think is a little more nuanced:

The point of systems/processes is to lessen the amount of inefficiency in a group of people working together as that group a) gets larger, and b) experiences turnover.

Nothing's ever going to be as efficient as a single engineer that can build everything with all the details in their head at that very moment. But there's a limitation on size of problems you can solve doing that! So many people working on large problems hate their processes, because each individual person is doing less than if they were in a tiny, stable team, and they can feel this, even if the organization is making great progress.

(And then, at the largest sizes of organization, it's almost impossible to stop the org from crumbling from the weight of its own complexity. People do spend an awful lot of effort trying, though).

This is not universally true, and it's pretty common to hear people who moved out to the suburbs hate it, but they needed the third or even second bedroom! Slightly larger condos simply didn't exist on the market, or were priced at astronomic rates (double the $/sqft compared to a 1bd unit).

Looked at a dozen midrise buildings this year across DC/Phila/NYC markets, some new/recent construction, some office conversions. Most buildings had zero 3bd units except for maybe a single penthouse, a 2bd unit every other floor, and the entire rest of the building evenly divided between studios and 1bd units in the 400-600sqft range. The competition for the 2bd units was unreal, in several cases people were offering the entire year's lease upfront, in cash, to secure an apartment.

It really is that competitive and the demand is there, the supply is not.

The "airlines" that are using something like FlyCASS are themselves smaller operations and typically running on razor thin margins (if not just unprofitable and wishfully thinking that money will suddenly appear and make their business viable). Literally everything on their backend is held together with more duct tape than the average small business.

You could be an "airline" by purchasing a couple of older airliners and converting them to cargo use. Is it valuable for new airlines to get started? Should we force them out of business because they don't already have the systems in place that take years to decades to build out? Should they pay $$$ for boutique systems designed for a large passenger airline when they have 2 aircraft flying 1 route between nowhere and nowhere?

Requirements and audits really aren't the answer here. The fundamental design problem is that the TSA has used authentication "airline XXX says you're an employee" with a very large blanket authorization "you're allowed to bypass all security checks at any airport nationwide" without even the basic step of "does your airline even operate here?"