Little bits of thought; irregular, unstructured, unedited.
Re: https://lake.computer/blog/help-wanted/
Depressing to see all the havoc AI is wreaking in the world of free software. I can't imagine what it's like trying to stay sane while maintaining any substantial project in public right now.
Will this cause projects to move to a model in which trust between contributors has to be established through other (possible offline) channels? Because how can you trust that someone who is sending you code is actually a human and not a clanker?
I've switched back to bash a couple of weeks now after years of using fish and it's been pretty good so far. I wanted to leave fish for a while because using a POSIX incompatible shell is just kind of annoying and I never really vibed with some of fish's design decisions (like universal variables). I was hesitant to make the switch because I didn't want to miss out on fish's excellent auto-suggestions and fuzzy tab-completion. But while I do miss them, it's not been as bad and I think I'll stay with bash for now. (Insert obligatory "until i write my own shell" comment; but seriously though: I've started doing that some time ago and boy does it suck to implement shell syntax!)
Two short posts that made the top of HN today about the frustrations of dealing with modern software:
I recently wanted to regain access to some outlook.com email accounts after all my clients had been logged out. Turns out, Microsoft disabled username-password authentication over IMAP and expects clients to use an OAUTH access token instead. Question is: How do you get one? There is nothing in the web interface on outlook.com that gives you any clue on what to do.
Eventually I did find Microsoft's documentation on this topic, wrote myself a script that automates it, and put a little write-up on my homepage.
I'm not happy though. This whole scheme feels overengineered, but more importantly it is not communicated to users how to do it. The documentation is extremely developer-centered; but I'm not a developer (in relation to the service provided by outlook.com), I'm just a user who wants to read his fucking mail.
Compare that to how e.g. Sourcehut handles OAUTH tokens. You need these
to interact with some Sourcehut HTTP APIs like uploading content to
Sourcehut Pages. When you're logged in on the website you just go to
your account page, go to the "OAUTH" tab and generate a token there.
That's easy! Microsoft chose to not do it this way and instead require
you to do a little dance.
They seems to assume that all users of their service interact with it
through an email client whose developers already know what to do about
the authentation change (although even with some of those clients I had
to completely remove and re-add these accounts before they could access
my inboxes again). I don't know if I can precisely articulate what
bothers me about this quite yet, but it has something to do with the
strong distinction between dumb users who can not be asked to understand
anything technical, and the elite circle of developers at whose mercy
the poor souls of mere mortals lie. This infantilizes users and makes
them get used to being powerless, being left to pick up the crumbs of
bread that those in the know feed them. I know, I'm being dramatic
here, but I do think that decisions like how to design and communicate
systems and changes like these, are shaped by underlying assumptions and
conceptions about how humans are expected to interact with computers.
And it worries me that increasingly, users are treated like peasants in
the feudal kingdoms of the corporate tech-overlords (to use the very apt
language of Cory Doctorow on this topic).
Re: https://www.muppetlabs.com/~breadbox/txt/mopb.html
Turns out, its quite possible to add support for your own custom binary
file format to Linux. Tried it and it just works (the article above is slightly
outdated, flush_old_exec doesn't seem to exist anymore, but the kernel
has a begin_new_exec function that seems to be doing something
similar). Pretty cool stuff!
Re: Smuggling arbitrary data through an emoji
It really fuels my Unicode-skepticism to see these examples of silly design. We need something better!
Re: https://lkml.org/lkml/2025/2/7/9
Regarding the actual issue being discussed in the relevant thread (https://lore.kernel.org/rust-for-linux/20250108122825.136021-1-abdiel.janulgue@gmail.com/) I don't have a strong opinion. I can understand the annoyance that kernel maintainers feel by the Rust for Linux project making things more complicated for everyone, and the danger that patches could take longer to get merged because their authors might need to wait for Rust programmers to fix things that broke in a non-Rust patch. But I also think it's a valid proposal to keep the wrapper code in one central place for all Rust drivers to use. Why Hector Marten chose to stop contributing upstream over this is not clear to me, but I don't know enough here. It's fine to vent frustration, but suggesting to keep public lists of people who are unpleasant to work with is not a proper way to do this.
But what I found most revealing and repulsive is this paragraph from Hector in the thread linked above:
Rust folks: Please don't waste your time and mental cycles on drama like this. It's not worth your time. Either Linus likes it, or he doesn't. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.
Exterminatory rhetoric like this is just so off-putting to me and probably many others who feel like the Rust community does a bad job (over-) evangelizing. Appealing to the forces of history (as if history just happened), the idea that you had to pick sides, that "the world [is] moving forward towards memory-safe languages" and that anyone who disagreed or doesn't want to participate is a "saboteur" who tries to "demoralize you"... that is cult-like speech. This us-versus-them thinking and putting yourself on the side of progress and the inevitable forces of history is very reminiscent of old-school socialist language and equally problematic.
I have to admit that I wasn't aware of the fact that on unixoids you can pass file descriptors between processes over a socket. I think I had a suspicion that it was possible, but never bothered to check; turns out, it is.
You do it by set up "control messages" that you pass to sendmsg(2) and receive with recvmsg(2). The interface is not very pretty, but it works. Neat.
Re: On Tech Debt 0
and
Re: Build It Yourself 1
Good example of some of the craziness that can arise in ecosystems that rely too heavily on dependencies for everything. The most baffling part of this is this "security" advisory databse putting an package on its list because it is not actively maintained anymore: There doesn't seem to be an actual security concern here (at least no on is being referenced in the relevant thread over on GitHub).
People being mad that a (unmaintained) package has a desireably name in the one true canonical package repository is also strange. Don't rely on central repositories for your whole ecosystem then...
So the RTX5090 is ballpark 25% faster than the 4090 while consuming 25% more power and costing 25% more? Where's the progress in that?
A follow-up to my last bit regarding the use of LLMs to assist coding: The article I was commenting on linked a video of Andreas Kling writing a JavaScript JIT engine with the help of some AI model. Having now watched the video it is indeed astonishing how quickly he progresses!
But I have to point out that the AI doesn't seem to actually be the deciding factor here: Andreas is working in a domain he knows very well, and has a clear understanding of how to solve the problem at hand. He would be able to work just as fast without the model interjecting constantly.
Secondly, what is more baffling to me is how quickly Andreas decides whether to keep the AI suggestion or discard it. Even in a domain I feel comfortable in, I would have to spend much more time on trying to understand the model's suggested code. It probably goes to show how skillful of a programmer Andreas is!
What the model does really well in this example and I think that is a great use case for it here is that it can quickly generate code that follows an easily recognized pattern. Having to write out the same code multiple time with slight variations is indeed a situation in which programmers are limited by their typing speed. Stuff like code handling alternatives of tagged unions is often fairly repetitive and seems to be well-enough understood by models today.
So, yeah, the most impressive thing about that video was not how helpful the AI was, but how good a programmer Andreas is, which surprised no one.
Re: They all use it 0
Since I'm mostly skeptical of the benefits of AI for most use-cases, I feel comfortable answering the author's question:
How can you see them all use it and not think that, okay, maybe it's not all bullshit, maybe something's there, I need to figure out what it is?
If we're talking specifically about using LLMs to generate code, I simply don't see what problem that solves. Reading other people's code is hard and I'd much rather come up with my own solutions instead of trying to understand what others have written. Especially when I already know that the output of an LLM is even more random and inconsistent than human-written code. When reading code you usually try and understand what the author meant to do and why he chose to do it a particular way. Now AI does not mean to do anything: It's pointless to try and reason about the author's intent if there was no intent to begin with.
I also don't think we as an industry have the problem that there is not enough code being written. The problem is that nobody understands that code, it doesn't solve the problems it's supposed to solve, it runs slow, is insecure, hard to maintain. How are random draws from the bullshit-generator going to help us with that?
The same way that copy-pasting code from the internet in general (and StackOverflow in particular) has a bad rep, copy-pasting stuff from your friendly neighborhood LLM should be equally frowned upon. Sure, if that's the best you can do, go ahead. But it should be a measure of last resort and not the main modus operandi. (And I'd rather copy stuff that a human wrote than what an LLM dreamt up).
It's understandable that beginner programmers rave over LLMs because
they allow them to get started quickly and make them feel like they
accomplished something. If you don't even know where to start, any help
to get your feet off the ground is appreciated. That is okay and not a
bad thing perse, but as a programmer you want to overcome that stage!
As to why experienced programmers would want to use something like
code-generating AI (as TFA notes and takes as its main premise), I truly
don't know. It may be that they are just so much better at reading code
than I am, that they can more quickly determine whether an AI suggestion
is something they need or not or which parts of it are salvageable.
Anyway... I fail to see how having LLMs spit out random code snippets that I then have to try and make sense of is in any way easier (let alone more fun) than writing the code myself.
The discussion of this article on lobste.rs 1 contains a surprising number of great comments that I recommend reading.
Re: Risky Biz News: The EU will make vendors liable for bugs 0
This is such a terrible idea! Forcing software developers to accept
liability for all software defects is very likely to hurt innovation.
For many vendors, the risks of distributing software under such a regime
will outweigh the potential benefits.
This is the type of legislation that is just going to affect the small guys. Companies that are big enough will not change their software development practices or security procedures, but instead invest more into their legal departments to thwart any liability claims.
And while the policy does contain exceptions for free software, who knows how effective they will actually prove to be. They don't apply to free software that is distributed in a "commercial" setting which can mean any number of things.
There are ways to improve the security of software that are ultimately
about giving users more control over their systems and making the whole
software stack easier to understand: Use free software, trim down the
complexity of software, reduce dependencies, ban the sale of locked-down
hardware, improve protections for whistleblowers, and likely more.
Things that actually strengthen security...
Re: wrestling the web from corporate control requires making it boring again 0
It's always great to realize that you're not alone. Seems like more and more people are coming to the conclusion that lots of our software and the processes that create it suck.
Re: Why bother with argv0 0
Weird article. Complains about a very normal thing without really presenting any arguments.
It's about the fact that a process's argv0 can be whatever and doesn't necessarily need to be the path of the executable from which the process was created. According to the author:
This seems like a questionable design decision. Should a program be allowed to behave differently based on its name? From a 2020s standpoint, this seems highly undesirable, as it makes software less predictable and goes against modern design principles. From a 1970s/1980s standpoint, a time when computer resources were scarce, it seems less unreasonable to attempt to minimise any form of duplication and redundancy. Today however, disk space is no longer considered an issue;
But why though?
This seems like a questionable design decision.
Why? In what way is this questionable?
Should a program be allowed to behave differently based on its name?
Yeah, why not? It changes its behavior based on other elements in argv as well, so why not argv0?
From a 2020s standpoint, this seems highly undesirable [...]
It doesn't. Seems fine.
[...] and goes against modern design principles.
Which design principles?
From a 1970s/1980s standpoint, a time when computer resources were scarce, it seems less unreasonable to attempt to minimise any form of duplication and redundancy. Today however, disk space is no longer considered an issue;
A very common, yet very idiotic thing to say. This logic is what makes us have to buy new computers regularly, because software keeps getting less and less efficient. This is costing people actual money!
Well, he eventually tries to back up his ominous remarks about reliability and security (which is always great to scare people) by giving examples.
The one he links, but doesn't explain 1 describes a vulnerability that seems to stem from extreme recklessness on the side of the programmer (an suid program reading config from an untrusted path) but has easy workarounds.
Another example concerns Windows Defender filtering/monitoring programs by their argv0, but why would a tool like an AV do that? Use the appropriate interface to monitor processes' actual file path, whatever that might be on Windows (on Linux you would use procfs).
I have to admit, after that point I only skimmed through the rest of the article, because there didn't seem to be anything to substantiate the opinion that argv0 not always containing the executable's file path was somehow problematic.
It bothers me so much when people make vague remarks about some piece of tech being old and something, something, security, something, and whoa, everybody is wrong! I guess that is what people call FUD.
Re: Micro-Libraries need to die already! 0
Well articulated explanation of the downsides of libraries. Weird that stuff like this even needs to be said, but looking at some of the comments on certain forums it sure seems some people refuse to understand this.
Re: ``Privacy-Perserving'' Attribution: Mozilla Disappoints Us Yet Again 0
Why is Mozilla trying so hard to make Firefox terrible? I don't get it?
Why do they hate their users?
Microsoft has been heavily critized recently for the announcement of their Recall feature, which periodically takes screenshots or a windows desktop and feeds them to an AI that the user can then query for information. Now, I don't think the outrage over this feature is quite justified. Of course I wouldn't enable it if I was using Windows, but that's mostly because I consider Windows itself to be malware, and I don't trust Microsoft to keep my data secure and I don't trust them to not exfiltrate it and send it back to their servers. Honestly, I'm baffled by the blatant user-hostility of current Windows versions and I don't understand why people keep using this pile of garbage.
But the feature in and of itself isn't too outlandish, is it? I mean, my shell history contains much of what I do with my computer and I consider it a great asset! It's incredibly convenient to hit C-r and search for that arcane ffmpeg-command that I used two years ago. Even mundane things like compile-and-run are usually just a "C-p, C-p, Enter, C-p, C-p, Enter"-sequence away. Windows' Recall feature goes further than that, but it's conceptually similar.
So, while I understand why people don't trust Microsoft to implement this in a way that doesn't suck, the idea behind the feature doesn't seem so outrageously bad.
And if somebody implemented a feature like this in a way that respects user freedom (i.e. as Free Software and for a Free operating system), it would not be considered overly problematic (aside from the inefficiency of using AI of course). So maybe the (justified) negative sentiment towards AI and Microsoft's (equally justified) bad reputation in general made people overreact to the announcement of this Windows Recall feature.
Not responding to, just inspired by:
Re: Why SCIP matters 0
As much as I still want to learn LISP, I just don't buy the idea that a higher level of abstraction in reasoning about code is actually a good thing. It ignores the reality that code is meant to be executed by a processor, and writing it is an activity that should not be thought of in terms of expressing abstract mathematical ideas, but as instructing a machine to do something. Independent of whether the abstract model is easier to understand or not (which I highly doubt, but it probably depends on one's level of experience as well as on the probem at hand), the code we write will be run by a real computer with a specific semantic model.
A counter-argument would be that the ISAs that CPU manufacturers expose to us programmers are just a bunch of lies and that we are stuck with them purely for legacy reasons. They are a semantic bottleneck, programmers actually think in terms of much higher level concepts, and CPU manufacturers know that and try to infer these concepts from the semantically narrower instruction stream the CPU sees. So instead of subscribing to the illusion of being to able to understand what actually goes on inside a CPU, just write your code in the level of abstraction that is most natural to you, with no regards to any "real" computer it at some point as to run on.
That is not an unreasonable argument, but it doesn't convince me.
First, because it assumes that a higher level description of an
algorithm is always easier to reason about than a lower level one, which
does not seem clear to me why that should be universally true. And
second, because I generally dislike perspectives that include the idea
that you should not understand something. "Oh, it's too complicated,
don't worry about it!", always rubs me the wrong way. If you express
your code in a very high level language but want to actually execute it
on a real computer, you have to rely on the compiler and runtime and CPU
frontend to magically do the right thing to make it run efficiently. We
shouldn't rely on magic and we shouldn't rely on not being able to peak
behind the curtain. "The ISA is a lie anyway", or "the compiler is much
smarter than you are anyway", seem like excuses to be lazy and not put
in the effort to try and understand how things work.
It has been 0 days since the last time a Python program broke for no apparent reason.
Will they ever fix their horrible dependency- and packaging situation?!
Re: Heat Death of the Internet 0
Depressingly accurate.
Re: A Generation Lost in the Bazaar 0
Mixed feelings about this one... The author is right in criticizing the absurdity of unreadable configure scripts, testing the system for pointless properties, and of the ridiculous numbers of dependencies that software packages rely on.
But apart from the fact that he makes contradictory claims about the prevalence and adequacy of code reuse, he more importantly fails to relate any of that to the Bazaar style of software development. I'm not saying there is no way to make that argument that the Bazaar is at fault here, but he doesn't present such an argument. He also attacks "a clueless generation of IT 'professionals'" that entered the field during the dotcom era, right after saying that configure scripts were already a bad idea in the 80s.
Oh, and trying to shoehorn the Peter Principle into his line of
argumentation is also unconvincing; the analogy just doesn't work here.
Really leaves the taste of referencing random Wikipedia-knowledge to
sound smart. If you want to mention a general concept to illustrate
your point, you have to show how that relates to what your saying!
To a more fruitful line of discussion: I think he's wrong in talking about "the beautiful cathederal of Unix". It might be cathederal-like in that it was created by a small group of people and exhibits a clean and simple design. But more importantly, I'd argue that this design lends itself to Bazaar-style software development! The Unix philosophy is about composition over integration, so instead of building a cathederal, its authors laid the foundation on which we could set up our bazaar.
Re: Leaving Rust Gamedev 0
Interesting field report from a gamedev on using Rust. I can't comment on the Rust-specific things since I don't know anything about it, but I think we should write way more of these kinds of reports: Sharing actual experience with a technology after having used it for multiple years and trying to be honest about the advantages and disadvantages; not trying to sell something, not trashing it, just telling others or your younger self, what you have learned.
Also a great quote that applies to so many niches of software development today:
The way [it] generally works is whichever project can make the most amount of promises, shows the best website/readme, has the flashiest gifs, and most importantly appeals to the right abstract values, gets widely praised, regardless of the usability of said project. Then there are other projects which are often under the radar, because they're not sexy and are not promising undeliverable features, but instead are just trying to do a thing in a way that works, and those end up almost never being mentioned, or when they are they're mentioned as second class choices.
Read an article about problems with Passkeys and struggle to find good technical documentation 0. There's lots of marketing speech that leaves it unclear whether Passkeys are about how a device authenticates to a website or how a user authenticates to his own device; it seems they do both, but those things should be separated from each other.
Using public keys to authenticate is nothing new, we have been doing this with SSH for a long time now, and for the web this has already been solved by SQRL1, which sadly didn't catch on, but seems like a better version of what Passkeys tries to be.
There's a very concerning smell of big companies trying to lock in users into specific ecosystems. And when contributors to the spec start to threaten open source projects with being "blocked by relying parties" using some seriously user-hostile logic 2... that is not a good look for this technology. What I want to know is how "relying parties" could even block individual implementations?! That being possible at all does not instill confidence.
Re: Why we can't have nice software 0
Read this post from Andrew Kelley yesterday and whole-heartedly agree with the frustration he expresses.
Software churn, change for change's sake, and greed, cause some technology to deteriorate iun quality.
Technology exists to serve us humans and make our lives better; when it's used to make our lives worse, we must call it out and try to correct it. That's not an anti-technology stance, but a pro-human one.
Re: RFC: banning "AI"-backed contributions to Gentoo 0
Very reasonable position here from the Gentoo maintainers, their concerns are completely valid.
Also, the linked thread on Github 1 is hilarious! Has some very sketchy/dystopian vibes to with a bot answering concerns about AI generated content. Impossible to trust such a project. What a grift...!
Re: https://rachelbythebay.com/w/2024/04/02/autoconf/
I'm with her on this. As much as portability across different OSes and their derivatives and flavors is a good thing, autoconf seems like an inelegant solution. Why the things that configure tests for aren't stored in a global cache is somewhat beyond me.
Across all the systems that constantly rebuild software and rerun configure scripts (which sometimes take longer to run than the actual compilation) how much computing time and energy has been wasted by this?!
Dedicated meta-build tools are not a bad idea perse and I'd much prefer them over the recent trend of putting the whole toolchain into one or two programming language-specific binaries. But surely we can come up with better solutions than autotools!
While the discussions about the xz backdoor inside the Linux, Free Software and greater tech communities were interesting and touching lots of deep technical and other issues, the mainstream tech press failed to adequately represent the topic in their reporting. There was a surprising lack of technical detail and imprecisions around the kinds of systems that were or could be affected by the backdoor. The most egregious phrasings were the ones that made this whole thing out to be a Linux backdoor, or the takes that interpret this story as showing the "fragility of open source" as one outlet put it. The open source community found the backdoor, which is evidence to the robustness of "open source". And it's utterly naive to think that non-free software doesn't contain backdoors---the difference is that we won't find those.
As a consequence of the xz affair last weekend, the community is now discussing the adequacy of source tarballs as a release artifact. That is a reasonable response as there is relatively little else to be learned from the whole story, but I'm not sure I quite agree with the enthusiasm to get rid of release tarballs.
The reason for release tarballs to differ from version control checkouts is that they contain generated files like build scripts. If we were to do away with the kinds of tarballs, there would be two alternatives to deal with generated files:
Check them into version control. This is commonly regarded as bad practice and rightfully so. Generated files should never be checked into version control! Not only do they cause enormous diffs that nobody reads and that don't correspond to the work that was actually being done. They also add another source of truth for the content of these files; it creates uncertainty about whether the generated files are up-to-date and if they can be safely re-generated or not. If I see files that are typically generated being checked into version control, I have to assume they were manually modified and can not be discarded and regenerated.
With respect to the xz story I also don't think that checking in these files would have helped discover the backdoor earlier. Yes, you can easily inspect the diff between two versions of a configure script that are checked into version control. But it seems very plausible for an attacker to come up with an excuse to regenerate the file in a way that creates a large enough diff that nobody is really going to inspect it for malicious changes. It would be just as easy to hide stuff in there as it is inside a release tarball.
Have users/distros check out version control snapshots and regenerate
the intermediate files themselves. This is better than checking in
generated files into vc, but it's not great either. The reason it's
traditionally not done this way is because it requires anyone
compiling the software to not only have the compiler and build tool
installed and working (and additionally any headers and libraries the
software links against), but also the tools for building the
intermediate files. In the worst case these tools might not even be
available on the platform the user is compiling the software on.
Even if it is, that increases the number of dependencies a user has
to install. I've seen people describe this as a legacy problem that
doesn't hold water today, but I don't see why that would be true.
Sure, it might be less of an issue in terms of storage space to be
able to have lots of development tools installed, but so what?
Users, or whoever builds the software for them, shouldn't need to
have these tools installed. Some of them might be pretty standard
like GNU autotools, but others might be more obscure and less
universally used.
Option 1) is really bad practice and does little to nothing to solve the security considerations brought up by the xz incident. Option 2) is more fit to mitigate them, but makes another set of tradeoffs, the severity of which seems to be a topic of much contention.
This xz-story fascinates me enormously. It has some serious thriller vibes to it, seeing the net of accounts trying to push the vulnerable version, and all that. Super interesting to see a story like this develop.
Technically, it seems like an odd mix of a pretty sophisticated backdoor, with some clumsy bits that ultimately lead to it being discovered relatively early. I say clumsy because there is no plausible deniability: It's not a mistake, it's very clearly a deliberate attempt to insert a backdoor. But sophisticated in the amount of complexity they wrangled to make this work.
The biggest lesson here however ---besides the obvious fact that more code, more complex systems, make it easier to hide stuff like this---is, that software is a people-problem and security is much more about processes and trust than we sometimes think.
Re: Drowning in Code 0
This piece by Liam Proven touches on much of what troubles me with today's software landscape.
A few days ago I started implementing a terminal emulator, which I've never done before. I don't really need one, but I wanted to see how far I would get in a reasonable amount of time. The answer is: Quite far actually. It's not up to the point where I can use it daily (because it doesn't support everything that tmux needs), but it's basically functional. One aspect that I found interesting to think about was performance and here's why:
You often see people online comparing terminal performance by cat'ing
out some huge file and measuring how long it takes for the terminal to
read, parse and render it all. So obviously I wanted to measure my
terminal like this. Turned out, my drawing is incredibly slow taking
around 10ms to draw a frame on the CPU. (That is probably mostly due to
the fact that I use Xft and draw every cell individually.) But I'd
argue, there is no point in drawing a new frame as soon as possible
while there is still data left to be read from the terminal device.
When you cat out a huge file you won't be able to read what's on the
screen anyway since the characters are swooshing by way too quickly
(especially if the terminal renders at a high framerate). So in order
to speed up this case, I decided not to draw a frame as soon as possible
but wait until I've read more data. And because the drawing code is the
slowest part of my terminal emulator, drawing less dramatically reduces
the time it takes to cat out a huge file.
In any case: Measuring how long a huge data dump into the terminal takes
is a stupid benchmark. It's not how people normally operate their
terminal. Sure, you can do it, but it mostly happens on accident and
is not how you spend most of your time interacting with the terminal.
Most of the time, nothing happens, followed by very short bursts of
input/output. I think the only reason why people use this metric to
compare terminal emulators is that it's easy to measure, but it's not
really meaningful.
This is such a difficult topic: On the one hand, I believe that nobody
has the right to tell me what software I'm allowed to run on my
computer, so obviously it is a good thing for laws to acknowledge that.
But on the other hand are the likely consequences of this who nobody
wants either: Google and Amazon, maybe Facebook, might see this as an
opportunity to launch competing app stores on iOS and pull their stuff
from the Apple-curated one. That would suck because users would then be
pressured into installing these and suffering from apps that are
potentially even more egregious in their violation of privacy.
It's a tough conflict and it doesn't necessarily seem obvious which policy can provide the most freedom for users. Then there's the issue of whether it is legitimate to force Apple to write their software a certain way. In an ideal world, we wouldn't need to force them to do so, because we could just install any software on our devices, but Apple wrongfully believes that users don't have that right. So I guess they brought this on themselves...
But while these changes could potentially hurt users' interests, the press statement from Apple is just incredibly cringe-worthy. Framing the freedom to run software not obtained through their app store as a security risk is absolutely disgusting! It's not a security risk because it doesn't in-and-of-itself affect security in any way: The ability to install malware doesn't make a system insecure---actually installing malware does. Big difference.
Apple's statement pretty much reads like "We, your dictators, were forced to allow some democracy in this land. That's bad, because there are other dictators in other lands and they might be a danger to our citizens. So you all need the protection from us dictators against the other dictators." Well, those aren't the only options, are they? What about we just topple all of these dictatorships?
The privcay and security concern here does not stem from the user's
ability to install whatever software he wants on his device, but from
the fact that now instead of one company abusing its power to force
their software on users' devices, we have to deal with multiple
companies abusing their powers to fuck over their users. The problem
isn't the freedom to run any software, the problem is the imbalance of
power between those who make the software and those who use it.
Sidenote: Calling it now, that Apple will try to make using these alternative app stores as terrible of an experience as possible. They will do things like throttling downloads from other stores, or showering the user with popup dialogs when installing something from an alternative store.
This year's Advent of Coreutils was an interesting project and even though I only did 21 out of 24 days, I'm moderately happy. Sure, the resulting suite of utilities is neither complete nor especially competent, but it contains usable and understandable implementations of a bunch of everyday-tools.
The most important part of this exercise was of course the learning experience and I do think that this whole thing was successful in that regard. Interacting with utmp entries and /proc/mounts was new to me and studying in detail the manpages for the utilities I implemented was interesting as well.
Whether I will continue to work on my set of coreutils, I haven't decided yet, but I don't have any concrete plans to do so in the coming weeks.
After using time(1) quite a bit while working on cat and ls, it occurred to me that I might as well write my own time(1). That was today's coreutils, and possibly the last. Advent is not entirely over, but I don't expect to find time over the remaining three days to get any programming done.
Re: https://marc.info/?l=openbsd-tech&m=170205367232026&w=2
In the context of these hardening techniques developed by the OpenBSD
team, I noticed that some people on the internet were criticizing them
for building these features without specifying a clear threat model.
That was new to me, but apparently it's been a line of criticism 0
towards the OpenBSD project and I think independent of whether this is
justified in this particular case, it's an interesting question.
Does it make sense to put up defenses against as of yet unknown attack vectors? Some people seem to think it doesn't, and I even saw the term 'security-theater' being used. A counter-argument would be that if you only ever fixes issues after they have been shown to be exploitable, you're simply reacting and playing catch-up instead of being proactive with your defensive measures.
Both positions sound plausible to me...
Today I revisited ls because the version I wrote last weekend was too barebones. I added sorted output, which is a pretty basic feature. The hard part about doing stuff like this in C is that you have to write your own growable data structures and I didn't have anything handy that I could just plug in.
Instead, I chose to use a sorted tree to store the entries before outputting them. That can theoretically be pretty inefficient because the tree could degenerate into a linked-list, but I was in the mood for a good ol' tree. If I can find a directory that's large enough to actually get measurably bad performance out of that sorted tree, I will replace it with something else. But the largest directory I can find on my system has 24k files in it and my ls is still faster than GNU's so I guess the tree is working just fine.
Sadly, this was the first day I didn't actually finish my daily core
util. I did get some of the functionality of chmod to work, but
parsing the mode string you can give it was a bit more finicky than I
expected. So while my chmod does support modes of the form
[ugoa][-+=][rwxst], it doesn't accept the very common octal format.
I'm not too upset though since:
I expect the numerical mode string to be easier to support than the symbolic one, and
I was able to implement the mode parsing in a way that is more
efficient than what I saw in busybox: With chmod you can add, delete,
and set permissions, and a way to implement this is to take a file's
current modemask and change that accordingly (or, and-not, equals).
But then you would need to parse the mode string for every file,
because you have to start with the mask and modify it; that's what
busybox does. I wanted to compute a new mask only once,
independent of the current file mode, and that wasn't too hard: I
use two masks, initializing one of them with 0, the other with
all 1's, and then modifying these masks (or'ing the zero mask,
and-notting the one mask) I can later set the new mask for each file
with 'file and ones or zero' (where the masks 'ones' and 'zero' have
been modified during argument parsing). It's a small thing and I
don't think it'll have a measurable impact, but the 'parsing' code is
pretty jumpy so I didn't want that to be executed more than once.
Re: https://lwn.net/SubscriberLink/953797/7222cd75661fb888/
Sad to hear about political troubles in the OpenPGP community. Also really hard to get a sense for what the actual disagreement is even about, or whether it's mainly about the question whether to introduce breaking changes or not.
Even sadder are the snarky comments by people who trashtalk PGP without mentioning a viable alternative. I get that crypto people dislike PGP's outdated design, but we currently don't have anything to replace it with: Signal is not federated and doesn't to BYOC (which are total dealbreakers), XMPP+OTR seems pretty janky, and Matrix is still being actively developed and appears to solve way too many problems for my taste. Email+PGP is bad, but at least it's the devil we know...
Yesterday's mount(1) was a lot of fun, though I wasn't able to implement support for /etc/fstab in the 2h window that I try to stick to during this daily Advent of Coreutils.
Today was more frustrating. The simplest case for mkdir(1) is ... very simple: It's a very thin wrapper around a syscall. But while that was done in 1-2min, the option to create parent directories -p took almost two hours. The result isn't even that complicated, but constructing the paths correctly was tedious. I really need to invest some time into writing a small string-manipulation library that I can rely on for these kinds of purposes.
After having not much time on the weekend and doing only the bare minimum, I was able to write something more interesting with today's Adent of Coreutils tool df. The code is relatively similar to how ls works, but I hadn't previously looked into how df works, so that was interesting. The APIs involved are surprisingly simple: getmntent to iterate over mounted filesystems, and statvfs to retrieve filesystem stats.
The annoying part was getting the numbers rights: Looking at the stats reported by my system's df, I struggled to figure out how they came up with these figures based on the information returned by statvfs.
Implementing tons of options complicates the code quite quickly, so I only did -T and -h. With options controlling a command's output format, the number of combinations grows exponentially, necessitating additional abstraction. That is an issue in many of these utilities and I don't know if there is one general strategy of dealing with that explosion of option permutations.
The first tool in my Advent of Coreutils was the all-important cat.
I'm pleased with the code even though it doesn't have any extra
features. An open question is, how to best test some of the error
conditions that need to be handled: E.g. how to cause interrupts during
syscalls.
The initial project setup took a bit longer than expected, because I wanted to be able to build all the tools as standalone executables but also as one multi-call binary like busybox does it. After a bunch of fiddling around, the Makefile ended up pretty small, and I used linker scripts to rename the main function's name (standalone tools need a main function but the box build requires them to all have different names).
So overall, I'd say I'm off to a good start.
I'm hereby committing to actually doing an Advent of Code project this year! This needs to be written down somewhere, or else I'm not going to stick with it.
But instead of doing the Advent of Code, I will work on something different: I will build a collection of UNIX coreutils; one a day (roughly).
My problems with the puzzles in the Advent of Code 0 that most people do, are that they are very unusual code that is very puzzle-like and not akin to anything you really ever write in practice. My second issue is that they are completely useless: I have a large number of outstanding coding projects queued up, that it would be absolutely wasteful to spend time on some puzzle just for fun.
So: Coreutils. I have a rough plan which tools I will implement on what day of advent, but that is not set in stone. The most important part is to get something done every day. Obviously I'm not going to implement every option and feature flag that e.g. GNU coreutils have, but instead stick to the main use-case and basic feature set.
The code will be posted to 1 as soon as I get that repo up.
Re: https://www.evanjones.ca/setenv-is-not-thread-safe.html
Interesting point, but I---unsurprisingly---don't think this is a big issue. Now I generally agree that the improvements he suggests represent better API design than what is in the standard, but when it comes to setenv/getenv I don't really see the problem.
What is the reason to call setenv at all, let alone in a multi-threaded context? The environment exists to get settings into your program, but once there, you have other means of passing around data. OP mentions libraries that can be configured via environment variables to avoid the application having to pass along configuration settings from the user to the library; that might be a valid use case, but only for getenv! You shouldn't need to use setenv because:
libraries should give you a way to pass in configuration values directly, overriding whatever is in the environment, and
if you have to use setenv (even though I don't see why), there's a chance you would only need to do it at program startup, before you create any threads.
So, yeah, it's not a good API, but why is that a problem?
Played around with redbean 0 yesterday. Even without any Lua skills it was very easy to whip up some basic routing in order for a web client to be able to access sqlite.
The whole thing feels well thought out: Every time I wondered how to do something, it turned out there was a feature with that exact purpose.
I really like this combination of simple yet powerful technologies.
Having it all bundled up as a self-contained web app could enable some
interesting use-cases.
What's missing to make this into a real GUI app, is having the browser bundled (which would almost certainly not work cross-platform from the same "ape" 1) or figure out how to call into existing web views on the platform.
Yesterday I took some time to refactor the code for generating my
website a little and I'm now quite a bit happier with how things are set
up. The whole contraption is based on Make, M4 and some shellscripts.
When building this I originally tried to have as much of the code inside
the Makefile because I thought it would be hard to keep track of what
random shellscripts are doing. But to my surprise I found that moving
logic into shellscripts not only offered more flexibility (that part was
not the surprising one) but that the whole setup is actually easier to
reason about.
That seems counterintuitive to me since scripts can do anything, while the Makefile is more structured, more declarative, and thus supposedly easier to understand or predict.
I should probably put up some of the code somewhere to be able to explain what's happening in this setup and why I like it.
I was watching Primeagen react to some professor react to Primeagen react to "Function is not better than OOP" (yea, that's weird), and apart from mostly agreeing with Prime there was this "definition" of OOP that came up in the original video: The aspects that characterize OOP were given as:
Abstraction
Inheritance
Polymorphism
Encapsulation
and they perfectly illustrate why I am so fed up with OOP discourse. Because this definition is completely fucking useless! Abstraction and Encapsulation? Are you serious?! Those are so utterly generic properties of every single programming language that they completely fail to define one specific paradigm. Writing a fucking macro in your assembler is a form of abstraction! Separating out source code into multiple files is encapsulation.
Now Inheritance and Polymorphism are a little more specific, but not nearly enough to adequately define what counts and what doesn't count as OO!
That's why it is basically impossible to even argue about these terms, because everyone will make up their own bullshit definitions to the point where none of them mean anything anymore.
Re: https://marc.info/?l=openbsd-tech&m=169841790407370&w=2
I have no idea whether this whole effort really improves security, I'll let others determine that. But I saw some pretty shit takes on this that claim this was somehow making things less secure because so-called safe languages now have to go through libc. That is obviously bullshit, because if you consider C unsafe then boy do I have bad news for you regarding assembler code! Because that is the alternative! Going through libc can do some sanity checks for you that you wouldn't have with raw syscalls. In any case you are calling into foreign code and beyond this event horizon you get no invariants that your type-checker can verify for you (you would have to write wrappers in your 'safe' language, but you can do that regardless of whether you are wrapping a raw syscall from assembly or a libc syscall interface). That certainly doesn't harm security and despite what all the anti-C propaganda wants you to believe, calling a kernel API through a thin C wrapper does not magically make your program less secure.
So regardless of whether this whole idea about restricting syscalls to known pages (at which libc resides) and forcing everyone to go through that, is actually more secure or not, the scare-mongering that's going on is absolutely ridiculous.
It seems to me that lots of times a piece of software seems overly complicated, it's not due to its developers being incompetent, but because they were trying to solve problems that I either don't know about and don't understand, solve problems that I don't deem worth solving, or solve problems in a very particular way that offers some benefits at the cost of additional complexity.
It is important that we communicate properly about what the problems we're trying to solve actually are, and why we chose any particular way of solving them.
Re: https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref
Not knowing anything about WASM this was still an interesting read. It neatly illustrates how much complexity lurks in so many corners of any software stack. I suspect too many programmers would deem representing strings in a VM to be a benign issue, but boy-oh-boy is that a can of worms...
The Pareto Principle states --- if my memory is correct --- that about
20% of factors cause 80% of outcomes. I strongly believe that this
applies to software as well and that you can build 80% of the features a
piece of software should or could have with only 20% of the code.
Implementing the remaining 20% of features requires the other 80% of
time/lines of code.
(Maybe the ratio is more like 90-10, maybe 70-30, that's really hard to say and kind of besides the point).
Because of that, I feel my time is best spent, working on the first 20% of the code and considering the rest of the features, that one could imagine, as out of scope.
Some views regarding programming languages, their compilers, toolchains and enviroments, that are apparently controversial:
Package management should be out of scope for your compiler. You will get it wrong, it conflicts with the system's package management, and it promotes the excessive use of dependencies.
Build tools exist. `Make' exists. Build tooling should be out of scope for your compiler. People already know how to use existing build systems, and tying the idiosyncrasies of your preferred solution (because all build systems are idiosyncratic) to the language is a bad idea.
Shared libraries are not a bad thing. Their implementation might have some rough spots, but the idea is reasonable and they are a reality on most end-user systems, so deal with it.
Build Once, Run Anywhere(tm) is not a worthwhile goal. Distribution of software should not be in scope for your compiler. Let distribution repository maintainers figure out how to make the software run on their distribution; all other models of software distribution are worse for the end-user over the long term.
Supporting nonfree OSs or nonfree applications is not a worthwhile goal. Nonfree software is inherently user-hostile, because it disrespects the end-user's rights to do with his own property (the computer) as he pleases. If supporting these freedom-hostile use-cases makes things technically difficult as well, why even bother?
At the end of the day, I think I'm against CLAs just like (what feels like) the majority of people these days. But I think there are valid reasons for wanting them:
License Changes. Let's say there's a court case involving some dispute that concerns the license you chose for your project. Now if the judge interprets the license in a way that does not match your understanding or intention of license. To plug the loophole that was torn into your license by some legal misinterpretation, you now want to fix that by changing your project's license. Problem is you can't do that if you are not the sole author! Code that was contributed by other people is done under the license that they gave you (which is usually implicitly the license of the whole project). Depending on the specifics of that license, permission, you are not allowed to relicense their code without permission. This is certainly true under the GPL. So now you would have to get every individual contributors permission or replace their code in a way that is unoffensive in terms of copyright. Good luck with that!
Enforcement. As far as I know, enforcement of software license is in a bad place right now: That's because most authors of Free Software can't afford the costs that enforcement of their license would entail, but big companies have deep coffers of legal budget they can throw at you. This is survival of the richest, not rule of law. But let's say you are determined to go after someone violating a license that you gave out, and you happen to find a lawyer who understands this stuff and is willing to work on contingency. I have heard --- and this might be wrong, I don't know too much about this stuff --- that for the defendant, an easy way to get a lawsuit thrown out is to question standing: Does the plaintiff have any right to sue in this case? The argument that the defendant will make is that you are only one of many contributors to the software and that you may not represent all of them; after all, some of them might not find their license to be violated. Even if you could track down all of your contributors, I wouldn't put it past some companies to buy off one or more of the licensors and have them contradict the plaintiff's standing. Sure, part of the problem here might be the laws that make it hard for you to establish standing; but you wouldn't want to wait for them to be improved, you want to be proactive.
To sum up: Having a CLA can allow you to plug holes that were poked into your license by some clueless judge. It can also help you establish standing in case you want to pursue legal action against some infringing party (even if you don't plan on doing that, just being able to, might be a deterrence to potential infringers).
These are real problems and if you want to protect end-user freedom, they are part of the puzzle (in addition to choosing an appropriate license like the GPL). I don't see how we could address these issue adequately using any other tool than CLAs.
That said, I don't like CLAs in that they a) are more legalese that nobody wants to deal with, and, more importantly are b) morally questionable. I can understand why they are necessary in the current legal framework around software licenses and their enforcement, but to me it seems that the framework is the problem.
Re: https://trust-in-soft.com/blog/2020/04/06/gcc-always-assumes-aligned-pointer-accesses/
I find this one interesting, because the unaligned pointer kind of "masks" the aliasing issue. Because --- and maybe I'm just stupid here, but --- the real issue comes down to aliasing and not unaligned pointers? He uses an unaligned pointer to get the alias, which GCC doesn't expect because it's UB. But the different return values are due to aliasing.
I had tried Stable Diffusion a while ago, but I've recently spent some more time with it and want to write down some of my thoughts on how well it works.
Good experiences:
With some models it's quite easy to generate amazing images right from the initial prompt. Back when I first used SD1.5 the results were pretty janky, but checkpoints like EpicRealism create beautiful images that are almost photo-real (depending on the prompt obviously).
ControlNet is great! One of the more magical experiences with Stable
Diffusion to me, was seeing dozens of images with the exact same
composition or pose but in different styles and with varying details.
The consistency between images created with ControlNet is just amazing!
Some aspects of an images are just incredibly easy to change to the
point where it still feels like magic. Changing people's hair color,
swapping backgrounds, relighting a scene, these all work really well.
I'm especially amazed when the model gets things like shadows and
reflections to look right on its own --- it seems not at all obvious
that this would be something that is easily learned from training data
(especially given how some other things like human hands still seem to
be major problems for the model to get right).
It's really convenient to run batches with different combinations of parameters (called X/Y/Z plots in Automatic1111). The result is a great way to build up an intuition of how these parameters affect the generated image.
Not so good experiences (these might be more specific to Automatic1111 as I haven't so far used any other SD UI):
Once I'm happy with parts of an image, it's not always easy to keep that part while changing the rest. It seems like the best workflow is to first build up the overall composition and dial in the details later with inpainting. But if you already like a specific detail, it's sometimes hard to preserve that.
I fail to get good style transfers while still retaining detail (esp. in faces). Even putting the source image into both img2img and ControlNet, adding the style only in the prompt, SD immediately (i.e. with low denoising strength) changes the face to be no longer the same person.
Automatic1111 is conceptually easy to use (ComfyUI looks more intimidating), but has its rough edges. In some parts of the UI you can directly send a generated image to another processing step, but in other parts you can't, and instead have to use a file browser to select the image from your output folder. There is no clear separation between settings used to generate an image (Sampler, Steps, etc.) that are also embedded as metadata in the image files, and the settings controlling the job or run that was last launched (Batches, X/Y/Z plots). On top of that the inpainting canvas is buggy, and the whole UI is overall slow.
One super annoying (but currently probably unavoidable) thing about working with Stable Diffusion is that you constantly have to wait! And what's worse is that you often have to wait only for thirty seconds or so. That is long enough to change focus to something else and prevents me from getting into a kind of flow. If you don't have some kind of attention deficit syndrom already, you will develop it here!
Really nice to see Baldur's Gate III being received so positively. I'm happy for the developers to have that kind of success and for gamers to get a AAA-game that's actually good once in a while. And with good I mean not having in-game purchases or being tremendously buggy and unoptimized.
Not sure, I will play it though... Played a bit of Divinity: Original Sin a couple of years ago and while I really enjoyed the writing, the fights were so boring that I just dropped it. I want to either be immersed in a well-told world and story, or I want to be challenged and think about the game as a game --- not both! This also annoyed me in Witcher III where the fights were just annoying busy-work to get through in between the fun parts.
Re: https://www.makeworld.space/2023/08/bye_gemini.html
Interesting to see someone like makeworld leave Gemini, but I have to say I get it. As much as I want something like it to exist and succeed, I agree with him on several points:
Gemini doesn't offer anything the web doesn't. This is by design, but it also makes it unappealing to enter.
The lack of expressibility with respect to structure and styling (also by design) is a bit too restrictive.
This is not so much about Gemini, but still true: Reading long prose in a monospace font sucks. That's why terminal-based browsers aren't super usable and dedicated graphical document viewers are needed.
Great Mindscape episode! I used to be really interested in philosophy some years ago, but somehow stopped engaging with it. But this discussion on metaphysics actually scratched that deep-thinking itch and makes me want to get my philosophical toes wet again.
Wow, this hit me unexpectedly hard. As someone who uses Vim every day it feels very weird to know its author is dead.
For me, learning about Unix, spending more and more time inside a terminal, and using Vim all tied into each other. I don't know whether I would have stuck with a mostly terminal-centered workflow if I didn't have Vim as an editor. I also don't want to use anything else...
Good thing is, there are lots of people getting upset at this Google proposal to make your own device work against you. See 0, 1, 2, and further down in 3, which is a great read overall.
Re: https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md
Just read an explainer on Google's "Web Environment Integrity" and holy fuck is that ever antithetical to the idea of an open internet. The whole concept of "trustworthy" devices is inherently user-hostile (and impossible to solve if users truly own their device and the software its running, so this will only work with locked down devices afaict).
Even if it might not be a privacy issue perse (although I suspect Google will find a way to turn it into a tracking apparatus), the identifiability of these tokens depends entirely on what the attester chooses to put into the payload; reasonable to assume that some websites would then only accept attestations from an attester that provides high-entropy fingerprints, regardless of what the spec says.
The whole thing reminds me of the FLoC debacle. Google is waging war on the open web!
Re: https://lock.cmpxchg8b.com/zenbleed.html
Another scoop by Tavis Ormandy!
I should really read up on vector instructions...
Having now seen both Barbie and Oppenheimer, I'm unsure how to ultimately feel about either of them. Barbie has its ups and downs with parts that are really fun and others that are ... not. The film is self-aware in a good way (a rare occurrence) and handles the predicament of telling a story about dolls quite well. Sadly, the characters learn the wrong lesson from their story, which is irritating in a film that is so concerned with its message.
Oppenheimer is at a consistent level for the whole 3h runtime. That level is good, but not great. For a film about a scientist there is laughably little science happening. Instead we get a lot of politics with commissions and hearings and debates, which were interesting to watch, but felt ancillary to the main plot. The incredibly star-studded cast does great work as does the cinematography (even though it doesn't leave me as much in awe as in some of Nolan's other films). I'm torn on the editing: The constant flash-forwards establish a decent pacing, but they are otherwise unmotivated and make the whole film feel more like a montage, which takes away from any individual scene's intensity.
Re: https://github.com/ziglang/zig/issues/16270
Puzzles me that people are mad at Zig for getting serious about dropping LLVM...
It was communicated a long time ago that they were planning to do this, so not a surprising change.
What is so important about Zig being able to compile C++? Using different compilers for different languages is the most normal thing ever!
I'm aware that I'm just screaming into the void here, but it's somehow somewhat therapeutic. Some people write a journal, so I guess it's not too weird.
Can we please stop using terrible metaphors to explain computer science concepts? The compiler book I'm currently reading explains state machines using the metaphor of a vending machine and it drives me crazy!
First of all, why would you even explain such a fundamental concept in a compiler book? That doesn't make sense to me.
Secondly, it is a useless metaphor at best and confusing at worst. It's substantially worse in German because both state machines and vending machines are called 'Automat'.
Sure, you can model a vending machine's state transitions for when the user inserts coins or selects a drink, but that is not the main thing about vending machines! State machines are an abstract concept, not a physical device, and using the metaphor of something that incidentally has the same name is not helping at all! Teaching such simple concepts using needlessly confusing metaphors and examples is a good way to turn people away from computer science.
Watched a Noah Baumbach double feature with White Noise and Meyerowitz Stories. The first one left me kind of confused: Was he just trying to do as many different genres in one film as possible? It was simultaneously comedy, family drama, desaster movie, thriller, and to top it all off it ended with a musical scene. I also have to admit that I didn't understand the whole talk about the lives of Hitler and Elvis...
Meyerowitz Stories was just great though. Such good writing! Really felt Woody Allenesque but in the best way possible. I also generally like seeing Ben Stiller and Adam Sandler in these types of less clowny films (funny, but not silly).
Implementing expansions for my shell is driving me insane. It is not difficult to achieve perse, but the code is a mess and I can't figure out how to make it simpler. Especially brace expansions tricky to retrofit into the code that already did variables, subshells, and quotes. Quoting in general is the source of all this evil, since when you visit an AST node that corresponds to some expansion you don't know whether that piece of the line was quoted or not.
The parsing side is also janky, but that's just due to the shell's rules. E.g. you don't know whether something is going to be brace-expanded until you have finished parsing the whole braced group: '{a,b}' is a group that is supposed to be expanded, but '{a,b' is not, it's a literal string. So go lookahead! Meh!
Something that often bugs me about people trying to be "helpful" on web forums or other places online, is that they often don't answer the question asked, but an alternative question that in their opinion should have been asked.
They justify that like described in the X-Y problem 0 in which the
author argues that it is common for question askers to ask the wrong
question. They want to solve problem X and believe that in order to
accomplish that, they have to first solve problem Y. So they ask online
for how to do Y, which may not actually solve their original problem X.
It is thus assumed that commenters should try to guess what problem X
the inquirer might have and try to help him with that.
I vehemently disagree! So often have I searched for the solution to a problem, found an online discussion about it, and was then frustrated that commenters told the inquirer that they should not be doing that or they should be doing it a different way. Just answer the fucking question! I know what I want to do, and if it turns out I'm wrong about it, then let me get to that realization myself! If the question seems confused about how things work or is unusually specific, sure, mention that you suspect they are trying to do things the wrong way. But please answer the question!
If I see a thread like that it might even be that the OP had some problem X and asked for Y. But when that gets cleared up in the thread, I notice that I have a different X. Knowing the answer to Y would then allow me to at least make progress on my problem (even if it turns out that Y is not a solution to X). That's why it is so frustrating to find these questions unanswered only because commenters where smug about it and refused to answer the question.
Respect your peers by assuming they mean what they say!
Just chased a bug for 2h that could only ever have happened in C. My window manager kept closing down with no error message nor segfault, no indication what went wrong. git bisect led me to the commit and it smelled like an out-of-bounds write; it was a function that I sloppily threw together because I was annoyed at having to do the thing it was supposed to do (related to character encoding of window attributes in X).
Anyway, I couldn't figure out where exactly the bad write happened,
because it didn't segfault, but just did a "normal" shutdown. Until I
realized what memory was being written: The window title that I wanted
to set using the bad function was followed by my 'is_running' variable.
The out-of-bounds write wrote the null-terminator into this state
variable and caused the program to shutdown with no fuss.
This has to be the C'est of all C mistakes I've ever made. It's exciting that the language let's me do shit like this, I love it!
One of the amazing things about computers is that they operate deterministically. Software --- maybe we should start calling this non-AI realm of software "classical" or something like that --- generally speaking turns inputs to outputs in a predictable way. Most algorithms we use are deterministic and it's instead a special distinguishing feature if some algorithm runs non-deterministically.
AI on the other hand is, for all practical intents and purposes from the user's point of view, non-deterministic. That in and of itself might be a big factor that allows it to do come up with solutions to complex problems quickly.
But for most problems, I would argue, a deterministic algorithm is what we want because that gives us a predictable user experience and explainability of results. Computers were invented to do simple math and that'd better be deterministic! It's what allowed us to do so many amazing things with these devices, so let's not through this important property away thoughtlessly!
Recent events caused me to delete my Twitter account. I just don't want to support centralized platforms generally and even less so if they are ran by ... questionable people. The whole thing got me thinking about potential alternatives and how something like Mastodon is maybe overengineered. That thinking led me nowehere...
But the other day I stumbled upon this article 0 that motivated me to start adding RSS feeds to my site.
In addition to the feeds for slightly longer form texts and some technical how-to's, I thought I'd set up this one as a feed of tweet-sized bits. This stuff is low-effort, spur-of-the-moment output, but what's more twitter-like than that, am I right?