General Development Archive
I want to address a controversy that has gripped the Rust community for the past year or so: the choice by the prominent async “runtimes” to default to multi-threaded executors that perform work-stealing to balance work dynamically among their many tasks. Some Rust users are unhappy with this decision, so unhappy that they use language I would characterize as melodramatic. What these people advocate instead is an alternative architecture that they call “thread-per-core.” They promise that this architecture will be simultaneously more performant and easier to implement. In my view, the truth is that it may be one or the other, but not both. A very academic discussion.
The full-featured, high-precision spreadsheet application for the Pico-8 that nobody asked for has finally arrived! PicoCalc is a feature-complete clone of the 1979 classic VisiCalc, which introduced the world to an entirely new category of business application. Steve Jobs said of VisiCalc, it’s “what really drove — propelled — the Apple ][. This is a few years old already, but still an amazing piece of work.
A lot has changed in 20 years. In 2003, the main question was: what encoding is this? In 2023, it’s no longer a question: with a 98% probability, it’s UTF-8. Finally! We can stick our heads in the sand again! The question now becomes: how do we use UTF-8 correctly? Let’s see! Everything you ever wanted to know about how Unicode works, and what UTF-8 does. Plus some annoying website design tricks, for which In apologise, even if it’s obviously not our site we’re linking to.
Caml Light is implemented as a bytecode compiler which made it highly portable. It is possible to create executables using the CAMLC.EXE command, but please be aware that the resulting binaries are not standalone when using the default linking mode, and the runtime system (CAMLRUN.EXE) is required to run them. The latest available release of Caml Light for DOS is version 0.7 released in 1995. Here’s a fun project for the weekend.
Dotfiles are important. We use them every day for storing configuration for all kinds of applications, knowingly or otherwise. You know the ones, hidden in your $HOME directory, ~/.ssh/ for your ssh keys, or ~/.Xauthority (whatever the heck that does). Something you may not know is these are legacy locations for configuration. Please do not copy their behaviour. Your application’s configuration may be the most important thing on a user’s machine. There are now standardised locations on major platforms for applications to store user-specific configuration. Your application should not be dumping random files into an unconfigurable location in the user’s home directory. This speaks to my soul.
On github, there has been an increasing trend of using “Staleness detector bots” that will auto-close issues that have had no activity for X amount of time. In concept, this may sound fine, but the effects this has, and how it poisons the core principles of Open Source, have been damaging and eroding projects for a long time, often unknowingly. I’m not a developer and even I can instantly see such bots would create countless problems. I had no idea such bots were being used.
There’s a certain community in tech that’s very vocal about their preference toward native apps. I share that sentiment, yet sometimes people take this idea too religiously. Unfortunately, the actual choice is about having an app or not, and I’d rather take something over nothing. I mean, sure, but that doesn’t negate the fact that web applications – or, more specifically, Electron and Electron-like applications – are just bad. Any time I see an Electron application offered, I instantly know the developers behind the project do not respect me as a user. They choose their own convenience over my experience as a user, and while that’s a perfectly valid choice they can make, it does mean I’m not going to use your service.
A lot is possible with a zipfile of data and just the programs that are either already installed or a quick brew install/apt install away. I remember how impressed I was when I was first shown this eurofxref-hist.zip by an old hand from foreign exchange when I worked in a bank. It was so simple: the simplest cross-organisation data interchange protocol I had then seen (and probably since). A mere zipfile with a csv in it seems so diminutive, but in fact an enormous mass of financial applications use this particular zipfile every day. I’m pretty sure that’s why they’ve left those commas in – if they removed them now they’d break a lot of code. When open data is made really easily available, it also functions double duty as an open API. After all, for the largeish fraction of APIs in which are less about calling remote functions than about exchanging data, what is the functional difference? I wonder how many of these types of simple, but extremely powerful open datasets that are so relatively easy to use exist.
I love these kinds of investigations.
ObjFW is a portable, lightweight framework for the Objective-C language. It enables you to write an application in Objective-C that will run on any platform supported by ObjFW without having to worry about differences between operating systems or various frameworks you would otherwise need if you want to be portable. It supports all modern Objective-C features when using Clang, but is also compatible with GCC ≥ 4.6 to allow maximum portability. ObjFW version 1.0 has just been released, which is, of course, a major milestone for any project. In this case, it also means ObjFW now has a stable API and ABI. ObjFW is available on a variety of platforms, from macOS and Windows to more exotic ones like the Amiga and Nintendo (3)DS.
I recently released a big update for my Mac ROM SIMM Programmer software which is written using Qt for cross-platform compatibility. As part of the update I wanted to release the Mac build as a universal x86_64/arm64 binary so that M1/M2 Mac users would be able to run it natively. It doesn’t currently compile for Qt 6, although I think I can fix that in the future without too much effort. However, Qt 5.15.9 and later do support creating universal binaries out of the box, so I decided to figure out how to set it all up. Even though I think I have pretty decent Google-fu, it was difficult to piece everything together to accomplish this goal. I’m hoping this post can serve as a reference for people in the future. These instructions are based on Qt 5.15.10 because that is the latest version that is currently open source. I did this on an M2 Mac Mini running macOS 13.5.1 Ventura. Useful information for those that need it. I’m not one of those, but I’m sure some of you are.
That raises an obvious question: when should we expect the Go 2 specification that breaks old Go 1 programs? The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened. There will not be a Go 2 that breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1. I’m not well-versed enough in either programming or the Go programming language, but this seems like good news for Go programmers.
Certain font-related CSS properties will render your site completely inaccessible if their value is declared using pixels even once. Just read it and absorb the information.
Lately I’ve been spending quite a bit of time learning Rust, and as any sane person would do, after writing a few 100 lines programs I’ve decided to take on something a little bit more ambitious: I have written a Java Virtual Machine in Rust. With a lot of originality, I have called it rjvm. The code is available on GitHub. I want to stress that this is a toy JVM, built for learning purposes and not a serious implementation. Toy or not, this is ambitious and impressive.
Using Lotus 1-2-3 in today’s world is a bit of a challenge. The truth is I’m cheating, it does work, but it only supports a few standard text mode resolutions. If your terminal is not exactly 80 columns wide, it just makes a big ugly mess on your screen. There’s a workaround, just type stty cols 80, and it will be confined to a portion of your terminal, looking a bit sad. There is no way to display more columns, and maximizing your terminal will do nothing. …or is there? After a lot of research, reverse-engineering, and hard work, Tavis Ormandy managed to get Lotus 1-2-3 to respect any arbitrary terminal size. Bonkers work.
Butler’s goal is to implement a virtual operating system with a strong focus on concurrency. Butler is not a computer hardware operating system. Instead, Butler is an application environment that runs on top of an existing system. Not exactly an operating system in the classical sense, but it still seems like an interesting project.
And while headlines might indicate the language had fallen into disfavor, the amount of COBOL in use continues to grow, with 800 billion lines running in production systems daily, according to a global survey conducted last year by enterprise software firm Micro Focus. COBOL is considered strategic by 92% of survey respondents, and over half said they expect their organizations to keep running their COBOL applications for at least another 10 years. I feel like COBOL is one of those things that can guarantee you a career. If you know COBOL, you will most likely find a job and have a good career future, but it’s probably not going to be anything sexy or anything that has the (albeit tiny) opportunity of making you filthy rich – but you won’t ever be without a job for long either.
I don’t expect to see any actual Mesa Vulkan drivers in Rust for a few years yet. My current goal is merely to explore the possibility. When the time comes that someone does choose to write a Vulkan driver in Rust, I want us to be ready. This exploration may also be useful for informing the Rust community about language features which would make the task easier. Converting existing Vulkan drivers to Rust is an explicit non-goal at this time. Rust seems everywhere.
Project Mage is an effort to build a power-user environment and a set of applications in Common Lisp. To get an overview, see The Power of Structure. Otherwise, the essays listed below may be read in any order. This goes far beyond my comfort level, but I’m pretty sure quite a few of you will find this project incredibly interesting.
GNU Make 4.4 is here, and it has some interesting – and sad – news for some of the old operating systems we still cover on OSNews. Sadly, support for OS/2 (EMX), AmigaOS, Xenix, and Cray will be dropped from the next release of Make. Now, I’m not entirely sure just how many users of these operating systems even use Make, but for those of you that do – tough cookie right here.
