General Development Archive

No more stale bots!

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.

Web apps are better than no apps

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.

Why my favourite API is a zipfile on the European Central Bank’s website

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 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.

ObjFW 1.0 released

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.

How to create a Qt 5 ARM/Intel universal binary for Mac

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.

Backward compatibility, Go 1.21, and Go 2

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.

I have written a JVM in Rust

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.

Lotus 1-2-3 and arbitrary terminal sizes

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.

COBOL: You’re thinking about it wrong

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.

Exploring Rust for Vulkan drivers

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.

GNU Make to drop support for OS/2, AmigaOS, Xenix

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.

When life gives you lemons, write better error messages

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.

How I hacked my car

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, a new programming language from Google, aims to be C++ successor

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.

What happened to Perl 7?

When we last heard from Perl, Perl 6 was going off on its own becoming Raku, Perl 5 was going to continue until version 5.36 which would serve as the basis for Perl NG, and Perl NG would be known as Perl 7 because Raku burned the Perl 6 namespace. No one saw the humor in “not that Perl 6, the other Perl 6”. Anyway, the Perl Steering Committee (PSC) decided to write a blog post about the future of Perl and Perl 7. The first PSC was elected in late 2020, and one of our first tasks was to create a plan for the future of Perl, and to put that in motion. A lot of discussion and iteration followed, but the strategy we agreed is: 1. Existing sensibly-written Perl 5 code should continue to run under future releases of Perl. Sometimes this won’t be possible, for example if a security bug requires a change that breaks backward compatibility. 2. We want to drive the language forwards, increasing the rate at which new features are introduced. This resulted in the introduction of the RFC process, which anyone can use to propose language changes. 3. We want to make it easy for people to use these new features, and want to do what we can to encourage their adoption. At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. So basically, nothing is going to change. Perl 5 will continue on into infinity adding features as it has been doing.