HN user

bsdimp

111 karma
Posts5
Comments25
View on HN

I yesterday set chatgpt to a coding task. It utterly failed. Its error handling was extensive, but wrong. It didn't know file formats. It couldn't write the code when i told it the format. The structure of the code sucked. The style was worse. I've never had to work so hard for such garbage. I could have knocked it out from scratch faster with higher quality.

PWB Unix was the earliest sources I could find. FreeBSD lists history items for releases going back to the earliest unix release because BSD Unix is derived from AT&T Research Unix and FreeBSD is derived from 4.4BSD...

The tabs file does predate this, and I'll make a note of that (which is what this article is about).

You forgot the following steps: Profile to see what's the slowest thing Make a native version of that. In FreeBSD package builder setup, we also have /bin/sh and a few other heavily used binaries that are native because it shaves hours or days off a package run (itself takes 10 days, even optimized like this).

I know the qemu-bsd-user fork has some hacks for the bsd-user stuff that looks at the binary to be exec'd and does different things based on the target since there's some optimizations you can get out of this if you don't rely on the kernel 100%... Bits of them may even be in my latest patch-set :)

FreeBSD has used this same trick for half a dozen years or so to build arm, mips and riscv binaries using fast Intel servers. The FreeBSD build system can build itself to produce binaries for the target (so the compilers run natively) and qemu handles the rest with user-mode emulation via bsd-user (which I happen to be in the process of upstreaming).

Binary format changes are never fun to go through forwards... This blog entry explains how the 2.11BSD restoration project did it backwards as a step towards creating the boot tapes for the original system...

Git's role would be to record the system incrementally as each patch is applied. I've already worked all the way back to the unpatched system. I assume that if I got it right, then I'll be able to rebuild. I've mostly been able to, and I'm investigating the mostly. Plus, I'm making sure that it's 100% reproducible so anybody can down the TUHS artifacts, run my scripts and have release 0 tapes, and a git repo of all the changes. And historians will be able to see what's definitely original, and my reconstructions of missing changes to programs. Those we'll never know to a higher degree of 'consistent with everything else'

Nobody! There were no copyright notices, and this is a work made before the US adopted the BERN convention. Prior copyright law required copyright notices.

We learned from the ATT vs Regents case that a judge ruled there was a large likelihood that AT&T couldn't establish it had a valid copyright on V32 because they never marked it properly.

They ported because there was a user base that liked the commends and environment and wanted to keep using it. It was a rewrite from scratch to the same design spec.

FreeBSD 10.3 10 years ago

For those numbers, it was around 18 real cores with hyper threading enabled. Crypto is a great workload for hyper threads. These systems are currently being built up and aren't yet in production. These are with last year's CPUs.

https://openconnect.netflix.com/en/hardware/ has the currently deployed system specs.