1
point
finaard
Joined 336 karma
- I think it's good practise to build something CMS like for fun - as long as you don't expect it to be useful or used, outside of maybe your personal page. It's useful to experiment and learn stuff that might be useful at scale in other projects.
I intentionally made a few interesting choices for my stuff, just to see how far you can push it, and to make sure no sane person would ever use that in production (like, from before Markdown was around, I was wondering how far you can get with doing a simple markup language parsed by using regexp only. Turns out, surprisingly far, but if something doesn't parse as expected later on you have a bit of a problem)
- Almost none of the FPS shooters try to to something creative, though. Duke Nukem 3D is still unbeaten for fun in multiplayer (and we still get it out now and then for that) with simple gimmicks like the holo duke, pipe bombs and laser mines.
Even just looking at "game uses 3D engine" we don't really have many great things. There's portal, and while some of the other stuff have promising ideas (like infinifactory), for all of them the controls tend to get in the way of fun.
For ease of use and fun pretty much all simulations - even as far back as the 90s - just using isometric projection are still unbeaten by attempts to go full 3D.
- gnus had some massive IMAP performance improvements a few years (probably close to a decade now) ago. Before that it was quite painful to use it on large mailboxes without a local imap - I used to sync that with offlineimap. When they had a massive issue moving from python2 to python3, and keeping that running on a modern distro started getting painful I tried it without local imap - and realised those improvements made things fast enough that you can run it on remote mailboxes, and even do so in your main emacs instance.
- Also check out the pull requests on that repo if there's something useful - in my case I've been using eat as single terminal instance for a while now - but for replacing stand alone terminals just opening multiple instances via multi-sh or similar isn't really helping for finding the terminals again. My solution was patching eat to allow buffer renames to the terminal title, and for ssh sessions, initially set the terminal title to the host I'm connecting to. Now I can easily find the terminals when switching buffers.
On top of that I'm using eyebrowse to have multiple workspaces, and some hooks around buffer switching that switch to the workspace a buffer is on instead modifying the current workspace.
- > But, I thought Arduino had become officially evil once it joined Qualcomm.
They have - but for less technical users their IDE is not too bad, and there are way too many bits out there relying on it, including lots of stuff not arduino, plus it's open source. And as it reloads files on changes can be used with a real editor as well. So for the software side I'm inclined to stick with that thing.
For hardware side it's different - but every interesting arduino has shitloads of clones available. In the past I've been buying those only for special use cases where there were no genuine arduinos to support the project - now since they got crazy it's only clones, and whenever I touch any of my old projects I'm updating the list of materials to recommend buying clones. You can still get nano clones for just a bit over 1 EUR each, so for projects where that is enough that's hard to beat value for the money.
- Nowadays there's eat as excellent terminal emulator for emacs, which should replace the need to run external terminals.
I've been using it for a w while, and recently finally got fed up about terminals on my macbook not behaving as nicely as the ones on my linux box with proper tiling window managers, so spent some effort to make SSH into a terminal with completion easy from emacs, and now mostly handle terminals in emacs.
- As a EU citizen: My only complaint is that the fines are not large enough, and enforcement often takes too long.
- > Python was so much easier as it was simple define the regex and then use a function on it. I suppose I should hjave spent a few days to write some wrapper in perl - doing those few days would have saved me time overall.
That's funny. I avoid python whenever possible, but one of the things I hate the most is how it is doing regex. I find the way it works in perl (both for search/replace and in conditionals) just intuitive.
- 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)
A surprising amount of embedded SoCs target the Arduino IDE either as the main IDE, or one of the main ones. And for those the setup is still pretty easy for non technical users - "Download IDE, paste this into the boardmanager, compile the sketch, upload". That's the main reason I'm still using the Arduino IDE for stuff I publish and expect less technical people to use.
The problem with the IDE is that it doesn't offer a gradual path to more advanced usage. You're pretty much stuck with a single file main project. You can split off functionality into libraries, but the way library resolving works is way worse compared to "proper" build systems. There are projects to provide makefiles for Arduino projects, but it's a bit of a pain to set up - I use that for CI on some of my stuff, but it clearly is on the other end of difficulty scale.
And of course the editor is horrible - but thanks to file watching and automatic reloads that isn't much of an issue nowadasy.