nrclark

That's around 100k/year if used at the same rate for every workday. So the question becomes: does it make your engineer X% more productive, where X is some multiplier based on their salary? There are some software engineers out for sure who are expensive enough that this is worth it.

I don't see this happening any time in the near future. The extra hardware cost is nontrivial, and there's a software support burden. Cellular bandwidth also isn't free, and probably wouldn't be covered by the value of any ads/telemetry that it carried.

OK, but SpaceX is not printing money out of thin air. And neither does the stock market. Somebody will be left holding the bag eventually.

Children are expensive, but highly subsidized, and just not expensive enough to explain the whole picture.

Highly subsidized? I have to assume you're not talking about America. I pay $3200/mo to send my kids to a very middle-of-the-road preschool. That's almost $40k/year just in childcare costs so that my wife and I can go to work. The difference between a 1-bedroom apartment and a 3-bedroom apartment is an extra $20k/yr or so in my area. Then there's health care premiums, taking them out for activities sometimes, etc.

I can ballpark the cost of having preschoolers in my area as $30k/yr each. And I don't know about you, but I don't exactly see any government subsidies helping me carry that burden.

PEGs are a great replacement for a complicated regex, and can express a lot of things that are hard to do with a regex. But they're also more verbose, and fewer developers are familiar with their usage. PCRE regex is kind of the lingua franca of text-matching, and making it available would be helpful for newcomers imo.

Something I'd observe here: without expressing an opinion about PEGs vs regexes, I'd note that regexes are much more widely used. They're also completely sufficient for an awful lot of text processing tasks. PCRE regexes would be a great inclusion to the stdlib, and would probably be popular.

Tcl is pretty good at functional-programming type stuff, and it can absolutely do anything that you could do with a macro. It isn't Algol-like at all imo, maybe beyond some superficial syntax. It feels a lot more like if LISP and Bash had a baby out of wedlock.

(I've written a lot of Tcl over the years and it'll always have a spot in my heart)

Not the parent, but yes I would/do write that way for effect.

We use a Docker Compose setup for our team's devcontainer. It's defined right in the repo alongside the Dockerfile used to build our image. Our build scripts are all set up to start/stop/use the container automatically. Integration with Vscode's devcontainer system will come next.

It's been a great way for us to make sure that developers and CI/CD get exactly the same build environment, mount-points, paths, network access, permissions, etc.

It's been a super solid tool overall, and I'm pretty happy with it. The only thing that would make our setup better would be if we could figure out how to go rootless/daemonless with it.

Tar doesn't need to imply gzip (or bzip2, or zstd, etc). Tar's default operation produces uncompressed archives.

out of curiosity - any reason not to use it?

You only have to decompress it first if it's compressed (commonly using gzip, which is shown with the .gz suffix).

Otherwise, you can randomly access any file in a .tar as long as: - the file is seekable/range-addressible - you scan through it and build the file index first, either at runtime or in advance.

Uncompressed .tar is a reasonable choice for this application because the tools to read/write tar files are very standard, the file format is simple and well-documented, and it incurs no computational overhead.

This isn't very surprising. Typical US economic policy aims for 2-3% annual inflation. That counter shows an average 2.6% inflation across 26 years, which is kind of right in the range we'd expect.

It's debatable whether this is good longterm policy - but it's been the norm in the US for decades.

If Windows wants to commit to quality and user experience, they can do it by moving closer to the experience that made a generation fall in love with it.

  - Turn Notepad back into a text editor.
  - Remove ads from your operating system. Yes it feels like a license to print money, but it makes your users hate your product. 
  - Stop charging money for Freecell and Minesweeper.
  - Converge your three control panels back into one. The classic control panel was not broken.
  - Drop the mandatory Microsoft User accounts. Nobody wants this except your bean counters.

Not the grandparent, but I've used most of the OpenAI models that have been released in the last year. Out of all of them, o3 was the best at the programming tasks I do. I liked it a lot more than I like GPT 5.2 Thinking/Pro. Overall, I'm not at all convinced that models are making forward progress in general.

I get your point about camera vs lidar. Humans do have other senses in play while driving though. We have touch/vibration (feeling the road surface texture), hearing, proprioception / acceleration sense, etc. These are all involved for me when I drive a car.

Kind of reads 25 people's stories about "How I became a parasite". Why not create new things, instead of making a career out of leeching the wealth created by others?

I’ve disputed fraud a couple of times on my Chase cards. It was.. fine? Uneventful and simple.

Interesting, I wonder if this will spike VPN traffic into Vietnam.

Agree. Even asking it can anchor your thinking.

This was a really interesting read. I'd highly recommend it for anybody who's setting up (or currently maintains) a pre-commit workflow for their developers.

I want to add one other note: in any large organization, some developers will use tools in ways nobody can predict. This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.

Instead, put what you want in an optional pre-push hook and also put it into an early CI/CD step for your pull request checker. You'll get the same end result but your fussiest developers will be happier.

fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.

Game theory is a model that's sometimes accurate. Game theorists often forget that humans are bags of thinking meat, and that our thinking is accomplished by goopy electrochemical processes

Brains can and do make straight-up mistakes all the time. Like "there was a transmission error"-type mistakes. They can't be modeled or predicted, and so humans can never truly be rational actors.

Humans also make irrational decisions all the time based on gut feeling and instinct. Sometimes with reasons that a brain backfills, sometimes not.

People can and do act against the own self interest all the time, and not for "oh, but they actually thought X" reasons. Brains make unexplainable mistakes. Have you ever walked into a room and forgotten what you went in there to do? That state isn't modelable with game theory, and it generalizes to every aspect of human behavior.

It's a bummer that the library and utilities are GPLv3 - really limits adoption, because it means that product developers can't build it into the kinds of small embedded Linux systems where it would really shine.

Maybe Ventana's software engineers can also help Qualcomm fix its BSPs.

  .
  .
  .

Fully agree - Ventana's cores are more like Cortex A76 kinds of things, and are on a completely different scale from typical Cortex-M cores.

But switching to RISC-V would shut Qualcomm out from QNX and would limit its Android compatibility. And on the Qualcomm chips that I've seen so far, they're really bought in on both QNX and Android. That's why I think this is probably an aquihire more than a desire to ship Ventana's CPU cores.

I'd be surprised if Qualcomm replaces their application processors (the cores that typically run Android/Linux or QNX) with RISC-V any time soon. Aarch64's ecosystem is huge, and Qualcomm would cut their customers off from it by moving fully to RISC-V.

They're more likely to replace the smaller CPU cores imo.

Most SOCs on the market today have a mix of various CPU cores. It's common to see designs with a few big ARM Cortex-A cores running an OS like Linux or Android, and then some smaller Cortex-M microcontroller cores that do housekeeping things like security checks, power management, realtime features, peripheral management, etc.

If I were to guess, Qualcomm wants to replace its various Cortex-M cores with RISC-V equivalents. This saves them money on licensing, reduces their dependency on ARM, and doesn't break customer-facing compatibility. Ventana is probably more of an aquihire to get their designer team.

"We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile." -Qualcomm, probably

Awesome, that's great to hear. Now if Qualcomm would only relax the walls between their business units, their other customers could benefit as well.

Who benefits from having separate BUs maintain fully separate software stacks? It's duplicated, wasted effort on Qualcomm's part. Maybe it lets them double-charge their customers for this duplicate effort, but that feels short-sighted. It leaves a bad taste in their customers' mouths. And there's certainly no benefit in delivered software quality.

Qualcomm should be making it easy for everybody to buy and use their chips, not artificially segmenting every single customer. They could sweep the market so hard if they were just a little less greedy.

It matters when you're doing custom hardware, or when you're designing a product where boot speed matters, or when you need to implement something special.

A full-featured U-Boot implementation would be fine IMO. But for the generations that I've used, that's not on the table. What we get is a proprietary flow through a proprietary hypervisor into a fork of Android's bootloader (even if vanilla Linux is the target OS). There's no way to control startup boot options, and no way to use KVM, Xen or any hypervisor except the proprietary one that's also part of the boot chain.

This doesn't lend itself to flexible products, or to products that are easy for a company to design or support. That is why things like this happen: https://news.ycombinator.com/item?id=46008156