Software Development

712 Articles

Open Source Needs A New Mission: Protecting Users

January 10, 2024 by 43 Comments

[Bruce Perens] isn’t very happy with the current state of Free and Open Source Software (FOSS), and an article by [Rupert Goodwins] expounds on this to explain Open Source’s need for a new mission in 2024, and beyond. He suggests a focus shift from software, to data.

The internet as we know it and all the services it runs are built on FOSS architecture and infrastructure. None of the big tech companies would be where they are without FOSS, and certainly none could do without it. But FOSS has its share of what can be thought of as loopholes, and in the years during which the internet has exploded in growth and use, large tech companies have found and exploited all of them. A product doesn’t need to disclose a single line of source code if it’s never actually distributed. And Red Hat (which [Perens] asserts is really just IBM) have simply stopped releasing public distributions of CentOS.

In addition, the inherent weak points of FOSS remain largely the same. These include funding distributions, lack of user-focused design, and the fact that users frankly don’t understand what FOSS offers them, why it’s important, or even that it exists at all.

A change is needed, and it’s suggested that the time has come to move away from a focus on software, and shift that focus instead to data. Expand the inherent transparency of FOSS to ensure that people have control and visibility of their own data.

While the ideals of FOSS remain relevant, this isn’t the first time the changing tech landscape has raised questions about how things are done, like the intersection of bug bounties and FOSS.

What do you think? Let us know in the comments.

FLOSS Weekly Episode 765: That Ship Sailed… And Sank

January 9, 2024 by 5 Comments

This week Jonathan Bennett and Aaron Newcomb talk with Randal Schwartz, the longest running host of FLOSS Weekly, Perl’s biggest cheerleader, and now Dart and Flutter expert. What’s new with Randal since his last FLOSS Weekly episode in May 2020? Why should you look at Dart and Flutter? And how do you avoid becoming a security martyr?

Randal has been busy since handing over the reigns of FLOSS Weekly, adding to his Perl credentials a solid claim to being a Dart Flutter expert. The Dart language has some real appeal, taking the best features from JIT languages like JavaScript, and also offering binary compilation like a real systems language should. Then the Flutter framework lets you write your code once, and literally run it on any screen. Sure, there have been some growing pains along the way, and listen to the episode to hear Randal describe the “45-degree turns” the language/framework duo has taken through the years.

Then as almost a bonus at the end of the episode, Randal quickly covered his now-expunged conviction for “doing his job with too much enthusiasm”, and covered some basic pointers to keep other security researchers out of trouble. This week is a nostalgia trip for long-time listeners, as well as a real treat for everyone else.

Continue reading “FLOSS Weekly Episode 765: That Ship Sailed… And Sank” →

Putting The C In C64

January 8, 2024 by 42 Comments

Older CPUs and some fairly modern microcontrollers are not made to readily support C compilers. Among those are the 1802, some 8-bit PICs, and the 6502 at the heart of the Commodore 64. That’s not to say you can’t make a C compiler for any of them, but the tricks required to handle the odd word sizes, lack of stack manipulation, or whatever other reason C isn’t a good fit tends to make compiled code bloated and possibly slower. [Dr. Mortal Wombat] took a different approach. The oscar64 compiler takes C source code and compiles it to a virtual machine code or native machine code for cases where performance might be important.

Turns out, the penalty for using native code isn’t as much as predicted, at least in some cases, The performance penalty for using the interpreter, however, can be significant in many common cases. The 6502 has a small stack that is hard to address, and indexing into a user-maintained stack is slow. The word size problem also produces lots of code as you have to break 16-bit operations into multiple 8-bit ones. The compiler aims to be C99-compliant, including floating point, recursion, multiple dimensions for arrays, and pointers to structures.

There are a few things left to hammer out. The linker doesn’t support external libraries, and the floating point code doesn’t understand NaN. On the other hand, many C++ features are available, like namespaces, reference types, templates, and more. The compiler can target several Commodore machines from the C128 to the PET. It also works with some Nintendo and Atari systems and can create various cartridge formats.

If you are writing code for any kind of 6502, it is probably worth checking out. Compiling C for the 6502 is no small feat, but then, so it is targeting PowerPoint. Don’t have a C64? Build one.

Image: [MOS6502], CC-BY-SA 3.0

A Journey Through Font Rendering

January 7, 2024 by 8 Comments

In the wide world of programming, there are a few dark corners that many prefer to avoid and instead leverage the well-vetted libraries that are already there. [Phillip Tennen] is not one of those people, and when the urge came to improve font rendering for his hobby OS, axle, he got to work writing a TrueType font renderer.

For almost a decade, the OS used a map table encoding all characters as 8×8 bitmaps. While scaling works fine, nonfractional scaling values are hard to read, and fractional scaling values are jagged and blocky. TrueType and font rendering, in general, are often considered dark magic. Font files (.ttf) are structured similarly to Mach-O (the binary format for macOS), with sections containing tagged tables. The font has the concept of glyphs and characters. Glyphs show up on the screen, and characters are the UTF/Unicode values that get translated into glyphs by the font. Three critical tables are glyf (the set of points forming the shape for each glyph), hmtx (how to space the characters), and cmap (how to turn Unicode code points into glyphs).

Seeing the curtain pulled back from the format itself makes it seem easy. In reality, there are all sorts of gotchas along the way. There are multiple types of glyphs, such as polygons, blanks, or compound glyphs. Sometimes, control points in the glyphs need to be inferred. Curves need to be interpolated. Enclosed parts of the polygon need to be filled in. And this doesn’t even get to the hinting system.

Inside many fonts are tiny programs that run on the TrueType VM. When a font is rendered at low enough resolutions, the default control points will lose their curves and become blobs. E’s become C, and D’s become O’s. So, the hinting system allows the font to nudge the control points to better fit on the grid. Of course, [Phillip] goes into even more quirks and details in a wonderful write-up about his learnings. Ultimately, axle has a much better-looking renderer, we get a great afternoon read, and fonts seem a little less like forbidden magic.

Maybe someday [Phillip] will implement other font rendering techniques, such as SDF-based text renderers. But for now, it’s quite the upgrade. The source code is available on GitHub.

A Look Inside The Smallest Possible PNG File

January 6, 2024 by 19 Comments

What’s inside a PNG file? Graphics, sure. But how is that graphic encoded? [Evan Hahn] shows you what goes into a single black pixel inside a 67-byte file. Why so many bytes? Well, that is exactly what the post is about.

You had to guess there is some overhead, right? There is an 8-byte header. Next up is a 25-byte metadata block. That single pixel takes 22 bytes, and then there is a 12-byte marker for the end of file. Turns out, you could put a bit more in the file, and would still take 67 bytes. The metadata is in a chunk — a block of data with a type, length, and CRC. That’s why it takes 25 bytes to store the dimensions of the image. A chunk has to be at least 12 bytes long. The metadata includes the image dimensions, the bit depth, and so on.

The next chunk, of course, is the data. The data is compressed, but in the case of one pixel, compression is a misnomer. There will be ten data bytes in the data chunk. That doesn’t include the 12 bytes of the chunk overhead so that one pixel takes a whopping 22 bytes.

The end of file marker is another chunk with no data. The total? 67 bytes. However, you can add more than one bit and still wind up with 67 bytes. For all the details, check out the post.

Luckily, it is easy to pronounce PNG. You can even use the format for circuit simulation.

Niklaus Wirth with Personal Computer Lilith that he developed in the 1970ies. (Photo: ETH Zurich)

Remembering Niklaus Wirth: Father Of Pascal And Inspiration To Many

January 5, 2024 by 34 Comments

Although perhaps not as much of a household name as other pioneers of last century’s rapid evolution of computer hardware and the software running on them, Niklaus Wirth’s contributions puts him right along with other giants. Being a very familiar face both in his native Switzerland at the ETH Zurich university – as well as at Stanford and other locations around the world where computer history was written – Niklaus not only gave us Pascal and Modula-2, but also inspired countless other languages as well as their developers.

Sadly, Niklaus Wirth passed away on January 1st, 2024, at the age of 89. Until his death, he continued to work on the Oberon programming language, as well as its associated operating system: Oberon System and the multi-process, SMP-capable A2 (Bluebottle) operating system that runs natively on x86, X86_64 and ARM hardware. Leaving behind a legacy that stretches from the 1960s to today, it’s hard to think of any aspect of modern computing that wasn’t in some way influenced or directly improved by Niklaus.

Continue reading “Remembering Niklaus Wirth: Father Of Pascal And Inspiration To Many” →

The World Of Web Browsers Is In A Bad Way

January 4, 2024 by 115 Comments

There once was a man who invented a means for publishing scientific documents using hypertext. He made his first documents available from his NeXT cube, and a lot of the academics who saw them thought it was a great idea. They took the idea, expanded it, and added graphics, and pretty soon people who weren’t scientists wanted to use it too. It became the Next Big Thing, and technology companies new and old wanted a piece of the pie.

You all know the next chapter of this story. It’s the mid 1990s, and Microsoft, having been caught on the back foot after pursuing The Microsoft Network as a Compuserve and AOL competitor, did an about-turn and set out to conquer the Web. Their tool of choice was Microsoft Internet Explorer 3, which since it shipped with Windows 95 and every computer that mattered back then came with Windows 95, promptly entered a huge battle with Netscape’s Navigator browser. Web standards were in their infancy so the two browsers battled each other by manipulating the underlying technologies on which the Web relied. Microsoft used their “Embrace and extend” strategy to try to Redmondify everything, and Netscape got lost in the wilderness with Netscape 4, a browser on which nightmarish quirks were the norm. By the millennium it was Internet Explorer that had won the battle, and though some of the more proprietary Microsoft web technologies had fallen by the wayside, we entered the new decade in a relative monoculture. Continue reading “The World Of Web Browsers Is In A Bad Way” →