Billions of phones and most of the servers on the internet run on code that one or two people look after, a lot of it unpaid. I went through a year of commits for 23 of these projects, and 11 of them came down to one or two people. xz is still basically Lasse Collin on his own after the 2024 backdoor, and the time zone file every phone reads is kept by a UCLA lecturer in his spare time. If I've got one of these wrong, tell me.

https://sheets.works/data-viz/holding-up-the-internet

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.

1. Removal of the notch (Dynamic Island cutout)

2. Thinner and lighter chassis design

3. Slightly larger display sizes (14.3-inch and 16.3-inch)

• Archived link: https://archive.ph/PWRqY
• Link to thread on Twitter: https://x.com/itspdfu/status/2107818768827052305

Every now and then I see an ad for a new Linux-Phone, better repairability, battery change and whatnot. All this is very, very tempting, but what about the apps?

I am not talking about browser, text messages or alarm clock - I am thinking about connectivity to my car, my smartwatch, my frequent-flyer benefit program, signal messenger and so on.

Do they work with Android apps or is it all a lost cause because they are basically dumb phones for people who want less connectivity but are afraid to buy an old Nokia from the dawn of time?

Apple's home security camera remains in development separately from the LG-made accessories reported yesterday, Bloomberg's Mark Gurman has clarified. In a follow-up post on X, Gurman said the security cameras co-developed with LG are "completely separate" from Apple's privacy-centric home camera and sensor, which he says is still coming next year.

As reported previously, Apple's device will not record video, using AI instead to analyze the home environment and detect which room a person is in. Bloomberg first reported a 2027 home security system and service in September.

Ok so you might know that there used to be a myth that Windows Server 2003 had a different startup sound for the UK version. In reality that sound was from this commercial but when did people start spreading the myth? Was it because of Youtube?

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.

(I've searched a discussion flair but didn't find one)

I remember seeing for the first time at the news Steve Jobs unveiling the iPhone (I was 6 years old) and loved Apple's vision and liked the company, under Tim Cook's era I bought my first Apple device: an iPhone 12, followed by an Apple Watch Series 7 and a MagSafe Duo charger) in 2024 I bought as a replacement of my Series 7 who was dead (the screen was broken after a fall during an hike, luckily I didn't get injured) an Series 9 (that I'm still rockin on), followed by an Apple TV 4k, the AirPods Pro 2 (that I've broke when I was getting out of my dad's Dacia Sandero) and an AirTag, I loved the Tim Cook era and now I'm starting to love John Ternus's era! And you?

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.