ReactOS Is Going Places, With More Stable AMD64, SMP, And Multi-Monitor Support

August 8, 2021 by Jenny List 54 Comments

In the crowd of GNU/Linux and BSD users that throng our community, it’s easy to forget that those two families are not the only games in the open-source operating system town. One we’ve casually kept an eye on for years is ReactOS, the long-running open-source Windows-compatible operating system that is doing its best to reach a stable Windows XP-like experience. Their most recent update has a few significant advances mentioned in it that hold the promise of it moving from curiosity to contender, so is definitely worth a second look.

ReactOS has had 64-bit builds for a long time now, but it appears they’ve made some strides in both making them a lot more stable, and moving away from the MSVC compiler to GCC. Sadly this doesn’t seem to mean that this now does the job of a 64-bit Windows API, but it should at least take advantage internally of the 64-bit processors. In addition they have updated their support for the Intel APIC that is paving the way for ongoing work on multiprocessor support where their previous APIC driver couldn’t escape the single processor constraint of an original Intel 8259.

Aside from these its new-found support for multiple monitors should delight more productive users, and its improved support for ISA plug-and-play cards will be of interest to retro enthusiasts.

We took a close look at the current ReactOS release when it came out last year, and concluded that its niche lay in becoming a supported and secure replacement for the many legacy Windows XP machines that are still hanging on years after that OS faded away. We look forward to these and other enhancements in their next release, which can’t be far away.

Knowing The Bits And Bytes That Make Images Live In Memory

August 5, 2021 by Mike Szczys 16 Comments

We know we’re living in the future because there’s hi-resolution, full color images plastered on every high-density screen in sight. Of course this comes at a cost, one that’s been hidden away by the myriad improvements in the way we digitally represent those pretty pixels and how we push them to the screens. Nobody thinks about this, except those who are working behind the screen to store and light up those pixels. And hey, chances are that’ll be you some day. Time to learn a bit more about image encoding!

Test renders illustrate the time savings from premultiplied alpha formats

[Scott W Harden] put together a succinct primer on representing images in memory. It focuses on the basics of how images are stored: generally with the B before the G, sometimes including an alpha (transparent) channel, and with a number of different bit depths. Having these at the front of your mind is crucial for microcontroller projects, where deciding what types of images to support is often limited by the amount of memory available for frame buffers, and the capabilities of the screen chosen as the device’s display.

Speaking of display specifics, [Scott] shares some detail about mapping the memory to the dimensions of your screen. If the byte count of pixel data doesn’t line up nicely with the dimensions of the screen, padding the rows out may help in the processing overhead it takes to get those pixels onto the screen. He also has some tips about “premultiplied alpha” which makes the transparency calculation a part of the image itself, rather than demanding this be done when trying to update the screen. Running a test in C# on one million frame renders shows the type of savings you can expect.

Decades of trial and error landed us with these schemes. Looking back is literally an archaeology project, as one hacker discovered when trying to get a set of digital images off of a floppy from a 1990s photo processing service.

GitHub Copilot And The Unfulfilled Promises Of An Artificial Intelligence Future

August 2, 2021 by Maya Posch 36 Comments

In late June of 2021, GitHub launched a ‘technical preview’ of what they termed GitHub Copilot, described as an ‘AI pair programmer which helps you write better code’. Quite predictably, responses to this announcement varied from glee at the glorious arrival of our code-generating AI overlords, to dismay and predictions of doom and gloom as before long companies would be firing software developers en-masse.

As is usually the case with such controversial topics, neither of these extremes are even remotely close to the truth. In fact, the OpenAI Codex machine learning model which underlies GitHub’s Copilot is derived from OpenAI’s GPT-3 natural language model, and features many of the same stumbles and gaffes which GTP-3 has. So if Codex and with it Copilot isn’t everything it’s cracked up to be, what is the big deal, and why show it at all?

Continue reading “GitHub Copilot And The Unfulfilled Promises Of An Artificial Intelligence Future” →

New Privacy Policy Gets Audacity Back On Track

July 23, 2021 by Tom Nardi 29 Comments

Regular readers will likely be aware of the considerable debate over changes being made to the free and open source audio editor Audacity by the project’s new owners, Muse Group. The company says their goal is to modernize the 20 year old GPLv2 program and bring it to a larger audience, but many in the community have questioned whether the new managers really understand the free software ethos. An already precarious situation has only been made worse by a series of PR blunders Muse Group has made over the last several months.

But for a change, it seems things might be moving in the right direction. In a recent post to Audacity’s GitHub repository, Muse Group unveiled the revised version of their much maligned Privacy Policy. The announcement also came with an admission that many of the key elements from the draft version of the Privacy Policy were poorly worded and confusing. It seems much of the problem can be attributed to an over-analysis of the situation; with the company inserting provocative boilerplate protections (such as a clause saying users must be over the age of 13) that simply weren’t necessary.

Ultimately, the new Privacy Policy bears little resemblance to the earlier draft. Which objectively, is a good thing. But it’s still difficult to understand why Muse Group publicly posted such a poorly constructed version of the document in the first place. Project lead Martin Keary, better known online as Tantacrul, says the team had to consult with various legal teams before they could release the revised policy. That sounds reasonable enough, but why where these same teams not consulted before releasing such a spectacularly ill-conceived draft?

The new Privacy Policy makes it clear that Audacity won’t be collecting any user data, and what little personally identifiable information Muse Group gets from the application when it automatically checks for an update (namely, the client’s IP address) isn’t being stored. It’s further explained in the GitHub post that the automatic update feature only applies to official binary builds of Audacity, meaning it will be disabled for Linux users who install it through their distribution’s package repository. The clause about working with unnamed law enforcement agencies has been deleted, as has the particularly troubling age requirement.

Credit where credit is due. Muse Group promised to revise their plans for adding telemetry to Audacity, and judging by the new Privacy Policy, it seems they’ve done an admirable job of addressing all of the issues brought up by the community. Those worried their FOSS audio editor of choice would start spying on them can rest easy. Unfortunately the issue of Audacity’s inflammatory Contributor License Agreement (CLA) has yet to be resolved, meaning recently christened forks of the audio editor dedicated to preserving its GPLv2 lineage are unlikely to stand down anytime soon.

The Newlib Embedded C Standard Library And How To Use It

July 19, 2021 by Maya Posch 4 Comments

When writing code for a new hardware platform, the last thing you want to do is bother with the minutiae of I/O routines, string handling and other similarly tedious details that have nothing to do with the actual project. On bigger systems, this is where the C standard library would traditionally come into play.

For small embedded platforms like microcontrollers, resources are often tight enough that a full-blown stdlib won’t fit, which is why Newlib exists: to bring the portability benefits of a standard library to microcontrollers.

Whether you use C, C++ or MicroPython to program an MCU, Newlib is likely there under the hood. Yet how exactly does it integrate with the hardware, and how are system calls (syscalls) for e.g. file and input/output handling implemented? Continue reading “The Newlib Embedded C Standard Library And How To Use It” →

Open Source Is Choice

July 17, 2021 by Elliot Williams 79 Comments

If you haven’t been following along with the licensing kerfuffle surrounding the open-source Audacity audio editing software, take a sec to read Tom Nardi’s piece and get up to speed. The short version is that a for-profit company has bought the trademark and the software, has announced plans to introduce telemetry where there was none, made ominous changes to the privacy policy that preclude people under the age of consent from using the software, and requested that all previous developers acquiesce to a change in the open-source license under which it is published. All the while, the company, Muse, says that it will keep the software open, and has walked back and forth on the telemetry issue.

What will happen to “Audacity”? Who knows. But also, who cares? At least one fork of the codebase has been made, with the telemetry removed and the old open licenses in place. The nicest thing about open source is that I don’t care one bit if my software is named Audacity or Tenacity, and this is software I use every week for production of our podcast. But because I haven’t paid any license fees, it costs me absolutely nothing to download the same software, minus some anti-features, under a different name. If the development community moves over to Tenacity, it’ll all be fine.

Tom thinks that the Audacity brand is too big to fail, and that Muse will have a hit on their hands. Especially if they start implementing new, must-have features, they could justify whatever plans they have in store, even if they’re only available as a “freemium” Audacity Pro, with telemetry, under a more restrictive license. When that does happen, I’ll have to make the choice between those features and the costs, but I won’t be left out in the cold as long as the Tenacity fork gets enough eyes on it. So that’s just more choice for the end-user, right? That’s cool.

Compare this with closed source software. There, when the owner makes an unpopular decision, you simply have to take it or make the leap to an entirely different software package. This can be costly if you’ve gotten good at using that software, and between licenses and learning, there’s a lot of disincentive to switching. Not so in this case. If I don’t want to be tracked while editing audio offline, I don’t have to be. Woot.

The elephant in the room is of course the development and debugging community, and it’s way too early to be making predictions there. However, the same rules apply for devs and users: switching between two virtually identical codebases is as easy as git remote add origin or apt get install tenacity. (Unpaid) developers are free to choose among forks because they like the terms and conditions, because one group of people is more pleasant to work with, or because they like the color of one logo more than the other. Users are just as free to choose.

Time will tell if Audacity ends up like the zombie OpenOffice, which is downloaded in spite of the much superior LibreOffice just because of the former’s name recognition. I know this split riles some people up, especially in the LibreOffice development community, and it does seem unfair that the better software somehow enjoys less reputation. But for those of us in the know, it’s just more choice. And that’s good, right?

Interpreters In Scala

July 16, 2021 by Al Williams 15 Comments

You might think of interpreters as only good for writing programs. Many people learned programming on some kind of interpreter — like BASIC — because you get immediate feedback and don’t have to deal with the complexities of a compiler. But interpreters can have other uses like parsing configuration files, for example. [Sakib] has a very complete tutorial about writing an interpreter in Scala, but even if you use another language, you might find the tutorial useful.

We were impressed because the tutorial uses formal parsing using a lexer and a parser. This is how you’d be taught to do it in a computer science class, but not how everyone does it.

Continue reading “Interpreters In Scala” →