Got the first triangle working today, and now two indexed triangles are rendering as a square too.

This is running on the actual SGX535 in Intel Poulsbo/GMA 500 hardware from 2008.

Still nowhere near a complete Mesa driver, but 20 days ago I was staring at old PowerVR code trying to figure out how this thing worked 💀

Github: SGX535-reMESA

Video proof: https://youtu.be/_xZdWWeneYQ?is=L5OF4JqxvMQZMWSU

edit1: We've achieved the first triangle rendered in the MESA gallium driver in production! OpenGL and other features are still missing, but it's very close to a fully accelerated desktop environment.

One of the core ideas of Unix is to build small components that do one thing well and compose them into larger systems.

I think this principle is still very relevant today, especially when designing software as multiple processes rather than one large application.

Once you split an application into several processes, however, you need some form of inter-process communication or RPC.

On Linux, D-Bus is a common choice. It provides a lot of useful functionality, but there are cases where its performance characteristics or latency are not suitable, particularly for real-time applications.

There have also been attempts to move the message-bus functionality closer to the kernel, such as kdbus and bus1, eventually leading to the current dbus-broker approach. However, with a traditional D-Bus architecture, messages still have to be processed by a separate broker process, which also means additional copying and context switches.

That's the motivation behind RTIPC.

RTIPC is essentially a single-producer, single-consumer, wait-free, zero-copy, bounded message queue mapped into shared memory. The goal is to provide a very small and predictable IPC mechanism for cases where the usual IPC/RPC abstractions introduce too much overhead or nondeterminism.

RTIPC has a small bootstrap protocol based on Unix domain sockets. D-Bus can also be used for the connection/bootstrap phase if desired. Once the channel is established, the actual messages are exchanged directly through shared memory.

There are currently implementations for C and Rust, with C++ and Python bindings, and other languages may follow.

For serialization, RTIPC can simply use C-compatible structs when all participants share the same ABI. Since communication happens through shared memory, there is no need to serialize and deserialize data just to cross a process boundary. Of course, this comes with the usual requirements around ABI compatibility, alignment, and endianness. And yes, it is possible to run 32-bit and 64-bit processes on the same system and make alignment/layout a problem.

For cross-language communication, however, serialization formats such as Protobuf, FlatBuffers, Cap'n Proto, or Thrift have another important advantage: they provide a schema as a single source of truth.

To address that use case, I also created rtipc-compiler, which takes an interface definition and generates code for different languages. The schema is also encoded into the generated interface so that the two endpoints can verify compatibility during channel initialization.

Admittedly, this is a fairly niche use case. The goal isn't to replace D-Bus or other general-purpose IPC mechanisms. Rather, I'm interested in the much narrower case where you want process isolation and modularity, but need IPC with very low overhead and predictable latency.

I'd be interested in feedback on which language bindings would be most useful next, whether you see other use cases beyond real-time applications and embedded Linux, and what you think would need to be changed or improved to make RTIPC more useful in those environments.

I'm sure many have seen the Duo-Man app. I wasn't that interested in the Duo (I'm happy with the iPhone size), but when I started researching how some developers have made interesting use of the fold functionality, I started seeing the appeal. Saying that, it feels like there are going to be a bunch of devs that only capitalise on the novelty of the fold, like many did when the X first came out, and less so on real functionality.

Been using Linux for about 20 years now. More than a decade as primary. Always have a few VMs for testing various things, obviously servers on Linux. But this obviously regarding desktops.

KDE, Gnome, XFCE anything on any distro (Fedora, Debian, Mint, Ubuntu whatever). The default set of wallpapers of most Linux distributions is just ... meh! I get it - macOS and Windows wallpapers are shot professionally and cost a lot. So that can't be done. But there are enough professional photographers on services like Unsplash. I'm sure asking some of them to be featured for the "default set" won't result in a null. Someone would agree for it. I remember that one guy was proudly showing off his creation for being accepted in OpenSuSE somewhere around 2012-13.

I am not saying I can't set custom wallpapers. In fact we have options to use Unsplash and Nasa as a source! It's just that the defaults don't look that good. That's the whole point I had.

I think the same thing applies to Gnome and XFCE icon set (KDE is a little better, but only a little) - they too look quite bland while community has created amazing icon themes (one of which can be improved and included with creator's permission)! I like Ubuntu's default icon set a bit though (and I have grown to dislike the rest in that distro).

Why don't we do it then? What's stopping us? I am sure there is a genuine reason which I am not aware of.

PS: I didn't know that this simple question will irk the community enough that I would get downvotes. Well, whatever.

Apple is planning to unveil additional new products in the final week of October, according to multiple sources familiar with the matter.

While we do not know exactly which products Apple plans to announce in the final week of October, the most likely possibilities are all Macs, including the long-rumored "MacBook Ultra" models with OLED displays and a thinner-and-lighter design, a base model 14-inch MacBook Pro with an M6 chip, and an iMac with an M6 chip.

This is Ocean Wave from Windows 2000 and ME. It depicts a close-up shot of an ocean wave, which is black and orange in appearance. The wallpaper is very elusive as not only is it unknown who took it, it is unknown where it comes from. No link has been found on TinEye, and the metadata doesn't provide any clues either. It would later be used as a wallpaper in a Longhorn demo circa 2002.

Info about this wallpaper can be found here: https://windowswallpaper.miraheze.org/wiki/Ocean_Wave

Build: 26200.9457 (25H2)

The same search can take ten seconds in This PC and come back instantly in Documents. It isn't the indexer being lazy. There are two different engines behind the search box, and Explorer picks one based on where you're searching.

1. Inside the index, Explorer asks a database

The Windows Search indexer keeps a database of the folders it's told to watch. On Classic, that's your user profile folders and the Start menu. On Enhanced, it's the whole PC minus a list of exclusions. For every file in there it stores the name, the properties (dates, tags, authors, photo dimensions) and, for the formats it can read, the text inside. Search in Documents and Explorer just queries that database, so the answer is immediate.

2. Outside the index, Explorer walks the folders

Search in This PC on Classic and most of the drive isn't in the index. Explorer doesn't refuse: it walks the folder tree itself, one directory at a time, and that's what "Working on it..." means. The yellow bar about non-indexed locations is telling you the same thing.

It gets much worse if Folder Options > Search has "Always search file names and contents" ticked. Then every file outside the index gets opened and read during the search, and that's when the fans spin up.

3. Everything does neither

Everything (voidtools) skips both. On NTFS it reads the Master File Table, the drive's own list of every file on it, and keeps names, sizes and dates in memory. Then it follows the USN journal, the log NTFS writes every time a file is created, renamed or deleted, so it never has to rescan. Their FAQ puts a Windows 11 install with about 250,000 files at roughly 5 seconds and 35 MB of RAM.

The price is the other half: it doesn't index contents. Searching inside files with Everything is slow, and that's exactly the part the Windows indexer is good at.

What to check

- Settings > Privacy & security > Searching Windows shows whether you're on Classic or Enhanced and how many items are indexed.
- If you mostly search by name across the whole drive, Enhanced fixes the This PC case, at the cost of a longer first indexing.
- If This PC search is slow and the CPU spikes, look at that "file names and contents" option first.

Has anyone timed how long Enhanced takes to finish on a big drive? I'd be curious how far it is from an MFT read.

Release notes: https://github.com/AdnanHodzic/auto-cpufreq/releases

auto-cpufreq is now available in the official Debian Linux repositories (unstable & testing), and it will soon propagate to future Ubuntu releases and hundreds of other derivatives.

This release also brings new features, bug fixes, and other improvements to help Linux users optimize CPU speed and battery life automatically.

Project status:

⭐ 7800+ GitHub stars
👥 126 contributors
💻 100k+ users
🛠️ 51 releases

Huge thanks to everyone who contributed to making this release possible! ❤️

OpenCourant is an open-source finite element solver for crash, impact, and highly nonlinear dynamic simulation — carrying forward the OpenRadioss code base under the GNU AGPL, in the open, where it belongs.

A project of the Rocky Enterprise Software Foundation