General Development Archive
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.
Error messages are part of our daily lives online. Every time a server is down or we don’t have internet, or we forget to add some info in a form, we get an error message. “Something went wrong” is the classic. But what went wrong? What happened? And, most importantly, how can I fix it? I really enjoyed this article detailing a massive project at Wix to go through and rephrase every single error message to make them easier to parse and overall less… Useless. A lot of developers can learn from this article.
Perhaps my favourite feature of Guix is guix shell. It is one of those tools that I don’t know how to do without. Even if you are not ready to use Guix as a package manager (or distro), guix shell alone might be a reason to have Guix installed. Why? This article describes a really nifty feature of Guix.
The IVI in the car, like many things these days, is just a computer. My goal was to hack the IVI to get root access and hopefully be able to run my own software on it. Of course, the first step in hacking a device like this is research. This is a story full of twits and turns, and some rally questionable decisions by Hyundai’s developers.
Carbon, the latest programming language to be built within Google, was unveiled today as an experimental successor to C++. To that end, while Carbon has many of the same goals as Rust, such as helping developers to create “performance-critical software,” Carbon is also intended to be fully interoperable with existing C++ code. Additionally, the goal is to make migrating from C++ to Carbon as easy as possible, if desired. This is not my area of expertise, so I’ll leave it to you readers to say more interesting things. The code for Carbon – not entirely sure about the name, but alright – is on github, along with more information.
