dezgeg

What a weird take, "millions of lines of code, written over decades" applies to quite many C (or C++) codebases where using a high-level language is not a possibility (and companies that do have such codebases are pretty conservative and don't even talk about Rust no matter how great fit it would be).

That's not a nice workflow from pipelines/CI point of view.

Let's take for example a service 'foobar' that depends on in-house library 'libfoo'. And now you need to add a feature to foobar that needs some changes to libfoo at same time (and for extra fun let's say those changes will break some other users of libfoo). Of course during development you want to run pipelines for both libfoo and foobar.

In such 'super module' system it gets pretty annoying to push changes for testing in CI when every change to either libfoo or foobar needs to be followed by a commit to the super repo.

In a monorepo that's just another Tuesday.

> Take your monorepo, split it into n repos by directory at certain depth from root, write very a rudimentary VCS wrapper script to sync all the repos in tandem and you have already solved a lot of pain points.

Then you lose the capability to atomically make a commit that crosses repoes. I'm not sure if there is any forge that allows that, except Gerrit might with its topics feature (I've not gotten the opportunity to try that).

> Every time I've been monorepos compares with polyrepos it's always "monorepo plus millions of dollars of custom tool engineering" vs "stock polyrepo"

The costs of the infra/build/CI work are of course more visible when there is a dedicated team doing it. If there is no such central team, the cost is just invisibly split between all the teams. In my experience this is more costly overall, due to every team rolling their own thing and requiring them to be jack-of-all-trades in rolling their own infra/build/CI.

> And I don't see how discovery changes significantly from browsing through loads of repositories instead of loads of directories in a repository

If repository permissions aren't set centrally but every team gets to micromanage them, then they usually end up too restrictive and you don't get even read-only access.

Is the controller really going to be that much simpler on a HDD? On HDD you still have things like command queuing, caching, checksumming and bad block remapping just as with SSD. Sure you don't have the flash translation layer, but I'd expect processing of the analog signal going to/from the heads to be a processing headache too. I wouldn't be surprised if they have to do temperature compensation and factory and/or runtime calibration of the analog path. Of course much of that will be done in fixed-function custom hardware blocks, but almost certainly so would a SSD for eg. ECC calculations.

https://spritesmods.com/?art=hddhack&page=3 has some data points on a 10+ year old HDD - 3 ARM9 feroceon cores + Cortex-M3 core. Doesn't sound too simple.

Better analogy is std::string_view vs std::string

git request-pull is.

What architectures that are missing from LLVM are commercially relevant today and not on well-earned retirement?

Maybe 320KB is the size of the bootrom? Although I don't see why that would be worth mentioning.

Usually in secure systems you can't read out all of the data from the old chip.

It looks extremely expensive piece of hardware. I have to wonder how much profit this made for Namco or the arcades.

autotools would like a word with you

It's also a detriment to some extent, as Claude's now believing things that apply only to later generations of the game (doesn't help that those beliefs would apply to the FireRed remake). Also it made Claude try to perform quests out of order and waste lots of time trying to do things he could only do later in the game (the thirsty guards blocking some routes-sidequest).

autoconf itself doesn't need xz, but in Nixpkgs xz is part of the stdenv, meaning essentially every package has a build-time dependency on xz.

For the case of xz not using the upstream-generated configure would probably be doable with some effort but doing the same for glibc, gcc, gnumake etc. would be much more difficult.

Yocto cross compiles. I don't think Gentoo can do that?

Try following your favourite distro's bug tracker during GCC upgrade. Practically every update breaks some packages, sometimes less, sometimes more (esp. when GCC changes their default flags).

Here's one example of workarounds in ~100 packages that broke when upgrading to GCC 10: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs%20fcommon...

Rust compiler upgrades being backwards incompatible has nothing to do whatsoever with keeping userspace ABI compatible.

GCC also occassionally breaks compability with the kernel, btw.

By accidentally writing out uninitialized memory contents to the file with the game still working. It's even worse in DOS era where there is no memory protection so uninitialized memory can contain data used by other processes, so for example parts of source code can get leaked that way. There's a big list of those in https://tcrf.net/Category:Games_with_uncompiled_source_code

5G basestations are on dedicated silicon already.

Are there other SBCs / SoMs that are as widely used with SD cards though? That's certainly a source of bias.

You can have pipelines trigger child pipelines in gitlab, but usability of them is pretty bad, viewing logs/results of those always needs extra clicking.

I'm not sure if there's a monorepo vs polyrepo difference; just that anything complex is pretty painful in gitlab. YAML "programming" just doesn't scale.

Cross compilation is much less tested so it's not uncommon to have hidden bugs in the package's build system that break cross compilation. Or that developers straight up disregard cross compilation if they're e.g. hand-rolling Makefiles.

According to his Mastodon, stage 4 colon cancer

The 'tup' build system also works this way.

Holy hell

Usually as in "most of the time regardless of the game", yes.

Seems like a sibling comment explained this already in much more detail: https://news.ycombinator.com/item?id=42082420

Usually the timing rules aren't the same for TAS and RTA, as TAS timing always starts at console power-on while RTA usually when 'new game' is selected from the menu.

> I don't see what point you tried to make. So A breaks when someone breaks B. That's ok. You spot the error the moment you try to update A, well before you commit any code. You file a low-priority ticket and go on with your life because A is still good in production.

What inevitably happens is that A hasn't been updating their version of B in weeks/months, but some recently landed bug fix in B is now needed RightAway(tm). And now if something accidental breakage happened between now and weeks/months ago, it'll be much more annoying to triage.

> Not really, it's the easiest part of the whole thing and a non-issue. If you manage a package this does not even register as a problem.

Well, where I'm at we have semi-regularly teams we have never heard of using our libraries. How can I know what things such people are using?

Bugs can and will happen, eg. when A depends on B and some developer accidentally makes a change to B that will pass B's tests but only break in A's use case. In monorepo case such bug can be noticed before the broken code hits master. In versioned case it might take long time (until B releases, and A takes the release into use).

Knowing when no one uses older versions is also hard (especially when you can no longer grep for them, unlike a monorepo) so some people get into defensive mode and never delete or fix any interfaces because "someone might still be using it".