Another way to make XML awesome (especially for config files and the like) is to completely avoid CDATA i.e. no <config><key>value</key><key2>value2</key2></config> but rather: <config key="value" key2="value2"/> -- simple constructions can then do with just a root element. Of course this pattern only pays off if you need the XML parser for other parts of the application, too...
I liked the content of the article enough to read it to the end, but I did have a hard time due to inflation with LLM-isms. Then again I am not a native so how would I know if this is good English? I can only tell that to me, it is hard to read despite interesting content.
After some search for programming languages which promise to reduce the number of bugs, I decided to give Ada (2012) a try.
I like it better than C and C++ and the compiler is included in Debian in a reasonably recent version that it can compile the code that I need.
Ada is particularly nice for programming RPI 2040 microcontrollers because for my needs I didn't need additional libraries. For both of my RPI 2040 projects (one of which is online here: https://masysma.net/37/dcf77_vfd_raspi_clock.xhtml), my code had fewer bugs than I had anticipated.
For general purpose systems programming the lack of free software libraries is still a concern e.g. while working on a custom backup restore program I had to write my own LZ4 extractor and Blake3 hash function implementation because there wasn't any existing libraries that I could find for the purpose.
In my experience it is trivial to call out to C libraries from Ada. You run a tool to convert the header file to Ada syntax, you link in the C library, and then you call the C code as if it were Ada code.
That's probably why you don't find LZ4 and Blake3 libraries. You forgot to look for the C libraries, which many Ada users would use.
> - Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.
In general it is already in the license. Even permissive licenses like Expat have (in ALL CAPS no less)
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO [...]
There is zero need to indicate anything about CONTRIBUTING whatsoever because already it is clear that the developer already indicates that nothing can be taken for granted.
Of course it helps to be open about expectations.
I for instance don't put CONTRIBUTING instructions online but so far all of my stuff gets so little attention that I have received almost no feedback about my free software at all.
To me, this is perfectly OK and in line with the expectation that I for instance put my code online mostly for my own benefit. If it helps anyone else, all the better. But don't derive any more expectations from it because it's free...?
My exposure and usage of “AI” has been very limited so far. Hence that is what I am and have been doing all the time: Read the text mostly irrespective of origin.
I do note that recently, I wonder what was the point the author wanted to make more often only to then note that there are a lot of what seems to be the agreed on standard telltale signs of excessive AI usage.
Effectively there was a lot of spam before already hence in general I don't mind so much. It is interesting to see, though, that the “new spam” often gets some traction and interesting comments on HN which used to not be the case.
It also means that behind the spam layer there is possibly some interesting info the writer wanted to share and for that purpose, I imagine I'd prefer to read the unpolished/prompt input variant over the outcome. So far, I haven't seen any posts where both versions were shared to test whether this would indeed be any better, though.
This is a powerful technique that has helped me a lot in the past as well, especially for those projects where I rarely progressed on (mostly private stuff, the work topics are more streamlined).
Nowdays in my private projects I often use a combination of the git commit messages and comments left in the code to indicate where to continue. Of course, this is not useful for work, either.
For work I like to use the ticket system and a separate text file and a paper notebook each to a slightly different effect.
The text file is the log what was done and is done per day grouped by ticket, typically ~10 lines for a day. The notebook contains meeting notes, design thoughts, general notes etc. and is very verbose (often six or mor pages per day, A4 paper) but sometimes helps to identify how/why/when a given decision was taken. The ticket contains what might also benefit others such as technical insights, meeting summaries (derived and summarized after the meeting from the paper notebook), summaries of important (design or product) decisions etc.
UNIX provides the Makefile as go-to tool if a simple pipeline is not enough. GNUmake makes this even more powerful by being able to generate rules on-the-fly.
If the tool of interest works with files (like the UNIX tools do) it fits very well.
If the tool doesn't work with single files I have had some success in using Makefiles for generic processing tasks by creating a marker file that a given task was complete as part of the target.
I wonder if this is due to Linux being harder to work on or because it is possible to fix some errors which would be catastrophic on other OSes?
Back when I used Windows a lot (Windwos XP times...) I also had the "long, scarring evening of frustation" rather often. It was usually solved by a reinstall.
In recent times, the “standard” seems to be smartphones (I use Android). The logic of smartphones it: It works or it dosen't and if it doesn't there is nothing you can do about it. Like ... not supporting some docking station because its network interface is called usb0 rather than eth0 ... no bypass, no solution, buy another docking station.
Of course this is faster than debugging the issue and maybe fixing it for good or maybe waste the evening on it.
Effectively Linux giving you the option to do something about errors doesn't mean the workarounds from other OSes like “reinstall”, “buy a new one”, “use a friend's system because it doesn't work here” are still readily available?
If only this were the whole story, but my Windows gaming desktop has been running more or less without issue (barring hardware failure), no reinstalls, since 2019. I tried so hard to use Linux on my laptop for two years but eventually gave up; i reinstalled Ubuntu three times in those two years.
Now, my Ubuntu server has also been running continuously since 2019. Linux can be that solid for the right use case. I've got a Linux HTPC that's pretty worry free, too.
Linux just legitimately has some hard-if-not-impossible problems on random specific consumer hardware, sadly. Until manufacturers start actually supporting it, that'll always be the case. Manufacturers have gotten better about it too, though, and I'm hoping valve continues making official Linux support more appealing for device manufacturers.
I guess all I'm saying is, some things on Linux still actually just can't be fixed, and every platform is gonna give you a night of extreme frustration from time to time.
> but my Windows gaming desktop has been running more or less without issue (barring hardware failure), no reinstalls, since 2019
This also describes my Linux desktop.
> I tried so hard to use Linux on my laptop
Unfortunately comparing a laptop to a desktop is not a fair comparison. Things are better than they were in 2019 but display and battery are constant issues (especially if you have a laptop with an nvidia graphics card).[0]
I'm not trying to say Linux doesn't have issues, but I do need to point out that your logic has a strong bias to it. I'll also add that while I have no problems gaming on my Linux desktop (thanks Valve!!), I don't usually play online games or MMOs but my understanding is that this is problematic for Linux systems as anticheat is a pain.
[0] My friend has a Framework laptop which has PopOS on it and he's said he's had no issues with it. He's used other Linux laptops before and has expressed this has been a very different experience. I think it helps that they're more aware of the hardware and can do more robust testing on that hardware.
reply