finaard

Since I switched to a macbook from a (proper) thinkpad I just carry a trackball with me when I expect to do longer stuff that requires mousing - the track pad isn't bad, but gets annoying over time. That also finalized my switch away from mice - before that I had both a mouse and a trackball on my desk, and while I still have that I can't remember when I last touched the mouse.

Maximum 32GB of RAM, which is a bad joke if you want to use it as developer system nowadays.

TL;DR: Waited for a decade for somebody to make a non-shitty notebook, went for macbook as the least bad option when the old one was falling apart.

Also the modern thinkpad keyboards are crap, and the trackpoint is unusable in the low profile style.

I switched to a macbook pro last year after having some contact with apple hardware in a customer project, from a thinkpad x230 with a x220 keyboard I've kept barely alive over the years. Now _some_ non-Apple notebooks (mostly from framework) can take sensible amount of memory, but at the time of purchase that was the only 14" notebook capable of taking a decent amount of RAM. The only other ones that could take RAM were some xeon workstation type builds - big display, shitty battery runtime, and same or more expensive than a fully specced out macbook.

Apple also seems to have put some effort into keyboards - with the current macbook pro keyboard being one of the best notebook keyboards currently out there. Not as good as the classic thinkpad keyboards, but better than anything lenovo made in over a decade. Dell never was that great, and did a massive step back in their latest model. HP is somewhat close, but still noticeable difference.

> To summarize: the device is riddled with security flaws, originally shipped with default passwords, communicates with servers in China, comes preinstalled with hacking tools, and even includes a built-in microphone

So like pretty much any BMC out there, just with the benefit that an attacker taking over that thing doesn't have direct access to reflash your bios with a backdoored version?

Any halfway sane person deployed any kind of BMC or networked KVM to a access restricted management VLAN for at least a decade now because all of those things are a big mess, and the impact of them getting owned typically is pretty severe.

I think the right way to do this is with snapshots, the way opensuse microos is doing it, for example. You get the best of both worlds that way - you still can easily install packages into the OS to customise it, and you do get painless updates and rollbacks. There's a very narrow use case where you _do_ want images, but for that you'll want to control the complete secure boot chain for attestation, so I'd dismiss it here.

Fun fact, a bit over a decade ago we were probably the first one ever to publish a distribution to rely on btrfs snapshots per default with the Jolla phone. Sadly that did bite us due to reliability of btrfs at the time, and later phones switched to ext4, but with a stable filesystem it's a nice mechanism for handling updates and factory reset.

> almost every line of code I write usually requires some deliberate though

That's probably the worst case for trying to use a LLM for coding.

A lot of the code it'll produce will be incorrect on the first try - so to avoid sitting through iterations of absolute garbage you want the LLM to be able to compile the code. I typically provide a makefile which compiles the code, and then runs a linter with a strict ruleset and warnings set to error, and allow it to run make without prompting - so the first version I get to see compiles, and doesn't cause lint to have a stroke.

Then I typically make it write tests, and include the tests in the build process - for "hey, add tests to this codebase" the LLM is performing no worse than your average cheap code monkey.

Both with the linter and with the tests you'll still need to check what it's doing, though - just like the cheap code monkey it may disable lint on specific lines of code with comments like "the linter is wrong", or may create stub tests - or even disable tests, and then claim the tests were always failing, and it wasn't due to the new code it wrote.

I started getting cassette players working again when I had kids - I had lots of old cassettes with stories still, and after looking into a lot of stuff determined that it is one of the best physical storage formats for that kind of content for kids we currently have. Its major advantage is that it automatically saves state, and the state saving is player-independent. Add to that that players typically have large clunky buttons ideal for kids hands, and you have something even all the dedicated digital kids media players can't compete with.

> and met a complete wall trying to explain why LLMs aren't useful for programming - at least not yet. I argue the code is often of low quality, very unmaintainable, and usually not useful outside quick experimentation.

There are quite a few things they can do reasonably well - but they mostly are useful for experienced programmers/architecs as a time safer. Working with a LLM for that often reminds me of when I had many young, inexperienced Indians to work with - the LLM comes up with the same nonsense, lies and excuses, but unlike the inexperienced humans I can insult it guilt free, which also sometimes gets it back on track.

> They refuse to believe it, even though they do hit a wall with their vibe-coded project after a few months when claude stops generating miracles any more - they lack the experience with code to understand they are hitting maintainability issues.

For having a LLM operate on a complete code base there currently seems to be a hard limit of something like 10k-15k LOC, even with the models with the largest context windows - after that, if you want to continue using a LLM, you'll have to make it work only on a specific subsection of the project, and manually provide the required context.

Now the "getting to 10k LOC" _can_ be sped up significantly by using a LLM. Ideally refactor stupid along the way already - which can be made a bit easier by building in sensible steps (which again requires experience). From my experiments once you've finished that initial step you'll then spend roughly 4-5 times the amount of time you just spent with the LLM to make the code base actually maintainable. For my test projects, I roughly spent one day building it up, rest of the week getting it maintainable. Fully manual would've taken me 2-3 weeks, so it saved time - but only because I do have experience with what I'm doing.

The Opensuse Build System. It's pretty good at figuring out if something needs rebuilding, so in some cases violating it and making it do stuff it's not supposed to is a sensible choice.

We're using OBS for building stuff (and heavily abuse it for the Linux side already) - a few things (like reverse dependency builds) make that more useful that most of the other stuff out there on complex projects. So when the requirement for some Windows builds came along (which are tiny compared to all the other stuff we're doing) we just ended up using WSL to have Windows workers in OBS. Also has some other advantages with how our cmake builds work (short version, developers can do their own bit in visual studio, and then a bit more checks run on CI where we can reuse the usual stuff without caring about Windows)

That'd mean we have a different compiler in CI than what the developers use on their workstations - which is not a good thing. And wouldn't be tolerated there anyway - people already had some doubts when we were wrapping IAR with wine and a bit of shell to look like a standard UNIX toolchain.

(Shout-out to IAR, though. I still think they're overpriced and you don't really need them - but if you're stuck with them their support is excellent. When an update broke license handling in our setup they didn't tell us to go away like any other vendor would've done for that kind of wildly unsupported use case, but actually made it work again in the next release. They also got us access to native Linux binaries way before they even were talking in public about working on that to play around with for our CI)

As WSL1 runs on the same kernel I have stuff like named pipes available. I can fully mix processes from both worlds in one workflow. _Some_ of that works with WSL2 as well, but as it's processes on two different kernels requires hidden workarounds to make that work - and not everything is working (and may be even possible).

While I understand _why_ they did WSL2 it's pretty sad that they at the same time they just dropped any WSL1 development.

We're using a lot of WSL in CI - we're mostly Linux based, but for some stuff toolchains came up which didn't work nicely with wine (like MSVC). So for us we want a Linux system that seamlessly can execute Windows stuff in a Linux based build process. WSL1 can do that, WSL2 can be kicked into working somewhat, but needs quite a few ugly workaround as they're not sharing a process namespace or file descriptors. While the faster IO would be nice that's pretty much the only thing we'd care about - and wouldn't work here, as we need shared access to the files. And while we could access the WSL2 files from Windows side that's even slower than just using WSL1.

> Then again maybe for stuff like actions and in general CI/CD it's not all that bad,

CI/CD on github has the npm problem - a lot of tiny stuff gets wrapped in actions people pull in from all over the place. Github does relatively fast deprecations, so actions need to be rewritten and updated even though there's no need for you - in this context I'd argue if it's not a security issue there's no need. So you end up with a lot of work just keeping the existing actions working - and overall would have less effort if you'd have just written your own actions - but not doing that is one of the selling points for github.

I might be biased as I've been doing complex CI/CD for close to two decades now - but github workflows _very_ quickly show their limits when you start seriously using them.

The trick is to only search for topics where there are no answers, or only one answer leading to that blog post you wrote 10 years ago and forgot about.

There will be many LLM-generated functions doing the same thing, in the same project, unless the human pays attention.

I've been playing a lot recently with various models, lately with the expensive claude models (API, for the large context windows), and in every attempt things are really impressive at the beginning, and start going south once the codebase reaches about 10k to 15k lines of code. Even with tools split out into a separate library and separate documentation at that point it has a tendency to generate tool functions again in the module it's currently working on over taking the already defined one in the helper library.

It used to be faster than Linux for that, but that's been a while ago.

I moved some stuff away from OpenBSD when the release of Linux 2.4 implemented all missing firewall functionality - but kept others still due to the early issues with the 2.4 kernel. But by the time 2.5 was getting decent - roughly a year before the 2.6 release - in most cases just using Linux with a custom 2.5 kernel was the better option.

Reminds me of a project from two decades ago which also had a somewhat tricky part.

We needed to do a nightly transfer of data. We had a variable amount of data to transfer, but typically in the range of one to two TB. We had a 1GBit link between the data centres housing the two systems, but it wasn't an exclusive link - backups and other stuff would be running during the night as well, so if we hog all bandwidth we'd have to deal with unhappy people. Hard deadline for the transfer was start of the work day.

Now the data does compress easily - but the data is only available for compression at the beginning of our sync window. We definitely need to compress some of the data to sync everything in time, and keep other users of the line happy. But: If we spend too much time on the compressing we might not have enough time left to send the data, plus we're not alone on the systems - other people will be unhappy about their nightly jobs failing if we hog all the available CPU time.

So we needed to find the right balance of data compression and bandwidth utilisation, taking into account all those factors, to make things work in the amount of time we had available.

Thanks to AMD nowadays we'd just throw more CPUs at the problem, but back then the 8 CPU server we were using was already quite expensive.

That's fine, some of those also have kernels that are EOL for almost 10 years.

For a long time I did a lot of Arduino stuff because you could get Nano clones for less than 1 EUR - which pretty much makes them throwaway, if you mess up.

I recently was doing a few projects with the Arduino Every, which is a nice board - but it's just too expensive. I did fry a few - so now I'm just using them as development board (the additional UARTs help a lot there), and for the actual project still use Nanos where I no longer care about the serial debug output, and therefore am fine with just the one serial port.

The two big problems are shitty mail clients, and people not knowing how to quote (which gets enabled by the shitty mail clients).

If someone gets CC'd later than typically because the discussion got to a point where the input is needed for the current question - and in a mail thread with proper quoting surprisingly often the quoted email is sufficient context for the added guy to jump in.

What makes a big mess out of things is the nested list of fully quoted emails with top answers at the bottom I now have to go through when getting added to figure out what the fuck they want from me.

That's karma for all the times the guy running that site had to deal with entitled emails.

I had my fair share of those as well - a bit over 2 decades ago I've added a CGI script to perform various DNS queries to my website - main purpose at that time was being able to show my customers DNS issues from their Windows boxes tied to corporate DNS.

Eventually some others added it to their documentation, with the most prominent one being OVH - they had a description on how to use my web site in various languages in their domain troubleshooting pages for many years.

I received a fair share of emails of people who were not able to figure out that I'm _not_ working for OVH, and I'm neither interested nor capable in solving their domain hosting issues with them.

They eventually built their own frontend, and by now it's mainly one guy from the Netherlands that now and then demands that I urgently add a new feature to the script.

West Germany

You don't really want that. I'm keeping my sanity there just because my small company is running their CI and testing as contractor.

They indeed are quite spoiled - and that's not necessarily a good thing. Part of the issue is that our CI was good and fast enough that at some point a lot of the new hires never bothered to figure out how to build the code - so for quite a few the workflow is "commit to a branch, push it, wait for CI, repeat". And as they often just work on a single problem the "wait" is time lost for them, which leads to the unhappiness if we are too slow.

Same as the one earlier in the thread: Build servers, nicely loaded. A build generates a ridiculous amount of writes for stuff that just gets thrown out after the build.

We actually did try with SSDs about 15 years ago, and had a lot of dead SSDs in a very short time. After that we went for estimating data written, it's cheaper. While SSD durability increased a lot since then everything else got faster as well - so we'd have SSDs last a bit longer now (back then it was a weekly thing), but still nowhere near where it'd be a sensible thing to do.

> As for why you didn't see similar constructions in other cities, this was definitely an unusually large telephone office for the time

For some perspective here - it took until the mid-80s for most of Germany to be connected to a phone line. That is, the 1980s.

I recently talked about that with my father after I found a postcard from one of my uncles from the early 80s confirming meeting and dinner plans. While I remember them always having a phone they were one of the households only connected in the mid 80s - which in retrospect explains some of the things I've found odd about them when talking to them by phone. It was a new thing for them.

(My parents got connected early on - my mother used to work for the post office in the phone exchange, and one of the perks of the job was priority for getting a phone line. Which also explained why we had an old grey phone, while pretty much all my friends had a relatively modern - for the time - one: they all only somewhat recently got phones)

I can recommend Kyocera - my current one has been going strong for 15 years now. I had problems with paper transport about two years ago - but that's expected after that many prints, and was solved with a reasonably priced field maintenance kit.

As far as I know they're still not doing any nonsense to force you to use their toner - but even if they did I probably wouldn't care as the original toner is cheap enough that I just can't be arsed to figure out good compatible ones.

I'm running the same setup - our larger builders have 2 32-core epycs with 2TB RAM. We were doing that type of setup already almost two decades ago in a different company, and in that one for over a decade now - back then that was the only option for speed.

Nowadays nvmes might indeed be able to get close - but we'd probably need to still span over multiple SSDs (reducing the cost savings), and the developers there are incredible sensitive to build times. If a 5 minute build suddenly takes 30 seconds more we have some unhappy developers.

Another reason is that it'd eat SSDs like candy. Current enterprise SSDs have something like a 10000 TBW rating, which we'd exceed in the first month. So we'd either get cheap consumer SSDs and replace them every few days, or enterprise SSDs and replace them every few months - or stick with the RAM setup, which over the live of the build system will be cheaper than constantly buying SSDs.

> Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board.

That's one reason why I prefer "fresh out of college" for juniors - if they seem bright enough that way they only have to learn, not also forget whatever nonsense they learned somewhere else.

But that wasn't really a thing that was an issue with SSH.

Host *.internal.example.com

  ProxyCommand ssh -q -W %h:%p hop.internal.example.com

in the SSH client config would make everything in that domain hop over that hop server. It's one extra connection - but with everything correctly configured that should be barely noticeable. Auth is also proxied through.

Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.