Programming Leftovers
-
GamingOnLinux ☛ Open source non-profit platform Codeberg "suffering from hate campaigns due to far-right forces"
Codeberg are a "non-profit, community-led effort that provides Git hosting and other services for free and open source projects" and they've recently had a major problem from what they say are far-right forces engaging in a hate campaign.
-
The Verge ☛ Open source code repository says ‘far-right forces’ are behind massive spam attacks
On February 12th, some Codeberg users received emails from Codeberg containing abusive content. The site says that this was sent by an abuser who took advantage of the site’s ability to notify up to 100 users at once, generating a notification email each time. Codeberg says that while it has blocked both the accounts and the functionality they used, “a large amount of notification emails” had already been sent, and the site itself experienced brief downtime.
“Your private data was not leaked,” Codeberg reassures users in a statement. “All emails have been generated through Codeberg’s servers using the notification feature and the abusers had no access to your email address directly.”
-
The Register UK ☛ Why are there so many graybeards in FOSS?
Some would-be contributors are very familiar with programming, reading, and writing code, but they may never have opened an issue or sent a pull request. This is a scary first step. Others may have the necessary tech skills, but not the creativity. Where should they you begin? Also, if someone is scared, that can result in impostor syndrome. The fear that people all over the world will see your bad code is a powerful factor reducing the urge to share it.
Another aspect is a general technology issue that's not unique to IT or computing. For instance, cars. It was much easier to fix your own vehicle in the 1980s than it is now. Not only are devices much more complex now, they are also less open to hobbyists. What do you want to try to do, and where do you start – and indeed, why do you start? We create the code and the tools, but we don't create incentives to get in there and start exploring, investigating, and changing it.
-
[Old] binrc ☛ The UNIX Operating System is an IDE
Very frequently people ask me why I don't just use Visual Studio, Jetbrains, Sublime or (not so much recently) Atom. My answer is a mumbling grumble of "nonfree inefficient POSIX noncompliant anti ergonomic webshit". I would like to elaborate on this nonsense and demonstrate how the UNIX operating system is designed to be an integrated development environment.
Every UNIX system comes with all the tools necessary to write, develop, and deploy software. Nearly all systems come with an editor, a compiler, debugger, various scripting languages, automation tools, etc. If the base system does not come with these tools, they will always be trivially installable using a package or ports management system. Choosing to use the terminal as your development environment is the only worthwhile investment. Graphical tools are transient, POSIX is forever.
[...]
The UNIX terminal is an integrated development environment. Every single component necessary for software development is present. Unnecessary anti-features are largely not present in the UNIX terminal. If human brains think in language, why avoid learning a computing interface that allows language based interaction?
Assembling a 'custom' development environment is not a difficult task. Learning how to click buttons is a waste of time. Becoming dependent on autocomplete is lazy. Refusal to read man pages is the way of Microsoft cattle. The UNIX philosophy has worked reliably for nearly 50 years without much change. UNIX is the only type of environment that is sustainable, maintainable, and dependable. Choose freedom, choose the UNIX 'IDE'.
-
Phil Hagelberg ☛ technomancy search
The second part to my approach is to experiment to see what a potential future for the web looks like where we aren't beholden to the interests of tech megacorps. That's what this site is for. It's not the final say in search; it's my first step in one direction. It may turn out to be a misstep as we learn more. The current view of search as something provided by an immense monolithic opaque oracle is so deeply embedded in our consciousness that it's difficult to even imagine what an alternative would look like.
-
Patrick Jordan Bene ☛ Explaining my fast 6502 code generator
To learn how optimizing compilers are made, I built one targeting the 6502 architecture. In a bizarre twist, my compiler generates faster code than GCC, LLVM, and every other compiler I compared it to.
I reckon my compiler isn't doing more when it comes to high-level optimizations, so the gains must be from the code generation side. This makes sense, as most compilers are multi-target, with backends designed for modern RISC-like systems, not the ancient 6502. It doesn't matter how good GCC or LLVM's high-level optimizations are if they falter at the last leg of the race.
Still, my compiler also beats those designed for retro and embedded systems, like VBCC, SDCC, and KickC. For this reason, it seemed like a good idea to write about my technique.
-
[Old] Chiark ☛ The Descent to C
C is quite different, at a fundamental level, from languages like Java and Python. However, well-known books on C (such as the venerable Kernighan & Ritchie) tend to have been written before Java and Python changed everyone's expectations of a programming language, so they might well not stop to explain the fundamental differences in outlook before getting into the nitty-gritty language details. Someone with experience of higher-level languages might therefore suffer a certain amount of culture shock when picking up such a book. My aim is to help prevent that, by warning about the culture shocks in advance.
This article will not actually teach C: I'll show the occasional code snippet for illustration and explain as much as I need to make my points, but I won't explain the language syntax or semantics in any complete or organised way. Instead, my aim is to give an idea of how you should expect C to differ from languages you previously knew about, so that when you do pick up an actual C book, you won't be distracted from the details by the fundamental weirdness.
I'm mostly aiming this article at people who are learning C in order to work with existing C programs. So I'll discuss ways in which things are commonly done, and things you're likely to encounter in real-world code, but not things that are theoretically possible but rare. (I do have other articles describing some of those.)
-
Shell/Bash/Zsh/Ksh
-
Ruben Schade ☛ A terminal survey
I did one of those terminal surveys! As in, a survey about using terminals, not a survey that’s terminal. Some of the answers are below. I didn’t include duplicate questions, or ones where the answer is just a “yes”.
-
Modus Create LLC ☛ Bashfulness
Fast-forward two years and both Topiary and the Tree-sitter Bash grammar have moved on. As the incumbent Bash grammar was beginning to cause downstream problems from bit rot — frustratingly breaking the builds of both Topiary and Nickel — my fellow Topiarist, Nicolas Bacquey, migrated Topiary to the latest version of the Bash grammar and updated our Bash formatting queries to match.
With surprisingly little effort, Nicolas was able to resolve all those outstanding problems. So with that, Bash was elevated to the lofty heights of “supported language” and — with the changes I’ve made from researching this blog post — Bash formatting is now in pretty good shape in Topiary v0.6.
So much so, in fact, let me put my money where my mouth is! Let’s see how Topiary fares against a rival formatter. I’ll do this, first, by taking you down some of the darker alleys of Bash parsing, just to show you what we’re up against.
-
-
Standards/Consortia
-
The Xiph.org Foundation ☛ FLAC - FLAC 1.5.0 released
This release finally makes the encoder multithreaded! Furthermore, the decoder can now handle chained Ogg FLAC files. As always, a lot of things have been fixed and improved.
-