fidzu : debian

Yet another maintenance release of the tidyCpp package arrived on CRAN this morning, a mere week and a half after the previous release. It has been built for r2u as well. The package offers a clean C++ layer (as well as one small C++ helper class) on top of the C API for R which aims to make use of this robust (if awkward) C API a little easier and more consistent. See the vignette for motivating examples.

This release, just like the preceding one less than two weeks ago, had its hand forced by an overnight change in R-devel. The breakage this created has since been reverted in R-devel but as the writing is on the wall are now removing the definition involving these accessors preemptively. We were also missing version checks for two newly added alternates.

Changes are summarized in the NEWS entry that follows.

Changes in tidyCpp version 0.0.10 (2026-03-15)

• Hide five accessors as underlying macros removed from Rinternals

• Preemptively hide another accessor

• Ensure two definitions are conditional on R 4.5.0 or later

Thanks to my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

15 Mar 2026 3:37pm GMT

Introduction

With various forms of IM becoming so prevalent and a lot of communication that used to be via email happening via IM I've been thinking about the differences between Email and IM.

I think it's worth comparing them not for the purpose of convincing people to use one or the other (most people will use whatever is necessary to communicate with the people who are important to them) but for the purpose of considering ways to improve them and use them more effectively.

Also I don't think that users of various electronic communications systems have had a free choice in what to use for at least 25 years and possibly much longer depending on how you define a free choice. What you use is determined by who you want to communicate with and by what systems are available in your region. So there's no possibility of an analysis of this issue giving a result of "let's all change what we use" as almost everyone lacks the ability to make a choice.

What the Difference is Not

The name Instant Messaging implies that it is fast, and probably faster than other options. This isn't necessarily the case, when using a federated IM system such as Matrix or Jabber there can be delays while the servers communicate with each other.

Email used to be a slow communication method, in the times of UUCP and Fidonet email there could be multiple days of delay in sending email. In recent times it's expected that email is quite fast, many web sites have options for authenticating an email address which have to be done within 5 minutes so the common expectation seems to be that all email is delivered to the end user in less than 5 minutes.

When an organisation has a mail server on site (which is a common configuration choice for a small company) the mail delivery can be faster than common IM implementations.

The Wikipedia page about Instant Messaging [1] links to the Wikipedia page about Real Time Computing [2] which is incorrect. Most IM systems are obviously designed for minimum average delays at best. For most software it's not a bad thing to design for the highest performance on average and just let users exercise patience when they get an unusual corner case that takes much longer than expected.

If an IM message takes a few minutes to arrive then "that's life on the Internet" - which was the catchphrase of an Australian Internet entrepreneur in the 90s that infuriated some of his customers.

Protocol and Data Format Differences

Data Formats

Email data contains the sender, one or more recipients, some other metadata (time, subject, etc), and the message body. The recipients are typically an arbitrary list of addresses which can only be validated by the destination mail servers. The sender addresses weren't validated in any way and are now only minimally validated as part of anti-spam measures.

IM data is sent through predefined connections called rooms or channels. When an IM message is sent to a room it can tag one or more members of the room to indicate that they may receive a special notification of the message.

In many implementations it's possible to tag a user who isn't in the room which may result in them being invited to the room. But in IM there is no possibility to add a user to the CC list for part of a discussion and then just stop CCing messages to them later on in the discussion.

Protocols

Internet email is a well established system with an extensive user base. Adding new mandatory features to the protocols isn't viable because many old systems won't be updated any time soon. So while it is possible to send mail that's SSL encrypted and has a variety of authentication mechanisms that isn't something that can be mandatory for all email. Most mail servers are configured to use the SSL option if it's available but send in cleartext otherwise, so a hostile party could launch a Man In the Middle (MITM) attack and pretend to be the mail server in question but without SSL support.

Modern IM protocols tend to be based on encryption, even XMPP (Jabber) which is quite an old IM protocol can easily be configured to only support encrypted messaging and it's reasonable to expect that all other servers that will talk to you will at least support SSL. Even for an IM system that is run by a single company the fact that communication with the servers is encrypted by SSL makes it safer than most email. A security model of "this can only be read by you, me, and the staff at an American corporation" isn't the worst type of Internet security.

The Internet mail infrastructure makes no attempt to send mail in order and the design of the Simple Mail Transfer Protocol (SMTP) means that a network problem after a message has been sent but before the recipient has confirmed receipt will mean that the message is duplicated and this is not considered to be a problem.

The IM protocols are designed to support reliable ordered transfer of messages and Matrix (the most recently designed IM protocol) has cryptographic connections between users.

Forgery

For most email systems there is no common implementation that prevents forging email. For Internet email transferred via SMTP it's possible to use technologies like SPF and DKIM/DMARC to make recipients aware of attempts at forgery, but many recipient systems will still allow email that fails such checks to be delivered. The default configuration tends to be permitting everything and all of the measures to prevent forgery require extra configuration work and often trade-offs as some users desire features that go against security. The default configuration of most mail servers doesn't even prevent trivial forgeries of email from the domain(s) owned by that server.

For evidence check the SPF records of some domains that you communicate with and see if they end with "-all" (to block email from bad sources), "~all" (to allow email from bad sources through after possibly logging an error), "?all" (to be "neutral" on mail from unknown sources, or just lack a SPF record entirely. The below shows that of the the top four mail servers in the world only outlook.com has a policy to reject mail from bad sources.

# dig -t txt _spf.google.com|grep spf1
_spf.google.com.        300     IN      TXT     "v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
# dig -t txt outlook.com|grep spf1
outlook.com.            126     IN      TXT     "v=spf1 include:spf2.outlook.com -all"
# dig -t txt _spf.mail.yahoo.com|grep spf1
_spf.mail.yahoo.com.    1800    IN      TXT     "v=spf1 ptr:yahoo.com ptr:yahoo.net ip4:34.2.71.64/26 ip4:34.2.75.0/26 ip4:34.2.84.64/26 ip4:34.2.85.64/26 ip4:34.2.64.0/22 ip4:34.2.68.0/23 ip4:34.2.70.0/23 ip4:34.2.72.0/22 ip4:34.2.78.0/23 ip4:34.2.80.0/23 ip4:34.2.82.0/23 ip4:34.2.84.0/24 ip4:34.2.86.0" "/23 ip4:34.2.88.0/23 ip4:34.2.90.0/23 ip4:34.2.92.0/23 ip4:34.2.85.0/24 ip4:34.2.94.0/23 ?all"
# dig -t txt icloud.com|grep spf1
icloud.com.             3586    IN      TXT     "v=spf1 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.142.0.0/15 ip4:17.57.155.0/24 ip4:17.57.156.0/24 ip4:144.178.36.0/24 ip4:144.178.38.0/24 ip4:112.19.199.64/29 ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29" " ip4:106.39.212.64/29 ip4:123.126.78.64/29 ip4:183.240.219.64/29 ip4:39.156.163.64/29 ip4:57.103.64.0/18" " ip6:2a01:b747:3000:200::/56 ip6:2a01:b747:3001:200::/56 ip6:2a01:b747:3002:200::/56 ip6:2a01:b747:3003:200::/56 ip6:2a01:b747:3004:200::/56 ip6:2a01:b747:3005:200::/56 ip6:2a01:b747:3006:200::/56 ~all"

In most IM systems there is a strong connection between people who communicate. If I send you two direct messages they will appear in the same room, and if someone else tries forging messages from me (EG by replacing the 'c' and 'e' letters in my address with Cyrillic letters that look like them or by mis-spelling my name) a separate room will be created and it will be obvious that something unexpected is happening. Protecting against the same attacks in email requires the user carefully reading the message, given that it's not uncommon for someone to start a message to me with "Hi Russel" (being unable to correctly copy my name from the To: field of the message they are writing) it's obvious that any security measure relying on such careful reading will fail.

The IM protections against casual forgery also apply to rooms with multiple users, a new user can join a room for the purpose of spamming but they can't send a casual message impersonating a member of the room. A user can join a Matrix room I'm in with the name "Russell" from another server but the potential for confusion will be minimised by a message notifying everyone that another Russell has joined the room and the list of users will show two Russells. For email the protections against forgery when sending to a list server are no different than those when sending to an individual directly - which means very weak protections.

Authenticating the conversation context once as done with IM is easier and more reliable than authenticating each message independently.

Is Email Sucking the Main Technical Difference?

It seems that the problems with forgery, spam, and general confusion when using email are a large part of the difference between email and IM.

But in terms of technical issues the fact that email has significantly more users (if only because you need an email account to sign up for an IM system) is a major difference.

Internet email is currently a universal system (apart from when it breaks from spam) and it has historically been used to gateway to other email systems like Fidonet, Uucp, and others. The lack of tight connection between parties that exchange messages in email makes it easier to bridge between protocols but harder to authenticate communication.

Most of the problems with Internet email are not problems for everyone at all times, they are technical trade-offs that work well for some situations and for some times. Unfortunately many of those trade-offs are for things that worked well 25+ years ago.

The GUI

From a user perspective there doesn't have to be a great difference between email and IM. Email is usually delivered quickly enough to be in the same range as IM. The differences in layout between IM client software and email client software is cosmetic, someone could write an email client that organises messages in the same way as Slack or another popular IM system such that the less technical users wouldn't necessarily know the difference.

The significant difference in the GUI for email and IM software was a design choice.

Conversation Organisation

The most significant difference in the operation of email and IM at the transport level is the establishment of connections in IM. Another difference is the fact that there are no standards implemented for the common IM implementations to interoperate which is an issue of big corporations creating IM systems and deliberately making them incompatible.

The methods for managing email need to be improved. Having an "inbox" that's an unsorted mess of mail isn't useful if you want to track one discussion, breaking it out into different sub folders for common senders (similar to IM folders for DMs) as a standard feature without having to setup rules for each sender would be nice. Someone could design an email program with multiple layouts, one being the traditional form (which seems to be copied from Eudora [3]) and one with the inbox (or other folders) split up into conversations. There are email clients that support managing email threads which can be handy in some situations but often isn't the best option for quickly responding to messages that arrived recently.

Archiving

Most IM systems have no method for selectively archiving messages, there's a request open for a bookmark function in Matrix and there's nothing stopping a user from manually copying a message. But there's nothing like the convenient ability to move email to an archive folder in most IM systems.

Without good archiving IM is a transient medium. This is OK for conversations but not good for determining the solutions to technical problems unless there is a Wiki or other result which can be used without relying on archives.

Composing Messages

In a modern email client when sending a message it prompts you for things that it considers complete, so if you don't enter a Subject or have the word "attached" in the message body but no file is attached to the message then it will prompt you to confirm that you aren't making a mistake. In an IM client the default is usually that pressing ENTER sends the message so every paragraph is a new message. IM clients are programmed to encourage lots of short messages while email clients are programmed to encourage more complete messages.

Social Issues

Quality

The way people think about IM and email is very different, as one example there was never a need for a site like nohello.net for email.

The idea that it's acceptable to use even lower quality writing in IM than people tend to use in email seems to be a major difference between the communication systems.

It can be a good thing to have a chatty environment with messages that are regarded as transient for socialising, but that doesn't seem ideal for business use.

Ownership

Email is generally regarded as being comparable to physical letters. It is illegal and widely considered to be socially wrong to steal a letter from someone's letterbox if you regret sending it. In email the only unsend function I'm aware of is that in Microsoft software which is documented to only work within the same organisation, and that only works if the recipient hasn't read the message. The message is considered to be owned by the recipient.

But for IM it's a widely supported and socially acceptable function to delete or edit messages that have been sent. The message is regarded as permanently the property of the sender.

What Should We Do?

Community Creators

When creating a community (and I use this in the broadest sense including companies) you should consider what types of communication will work well.

When I started the Flounder group [4] I made a deliberate decision that non-free communication systems go against the aim of the group, I started it with a mailing list and then created a Matrix room which became very popular. Now the list hardly gets any use. It seems that most of the communication in the group is fairly informal and works better with IM.

Does it make sense to use both?

Should IM systems be supplemented with other systems that facilitate more detail such as a Wiki or a Lemmy room/instance [5] to cover the lack of long form communication? I have created a Lemmy room for Flounder but it hasn't got much interest so far.

It seems that almost no-one makes a strategic decision about such issues.

Software Developers

It would be good to have the same options for archiving IM as there are for email. Also some options to encourage quality in IM communication similar to the way email clients want confirmation before sending messages without a subject or that might be missing an attachment.

It would also be good to have better options for managing conversations in email. The Inbox as currently used is good for some things but a button to switch between that and a conversation view would be good. There are email clients that allow selecting message sort order and aggregation (kmail has a good selection of options) but they are designed for choosing a single setup that you like not between multiple views based on the task you are doing.

It would be good to have links between different communication systems, if users had the option of putting their email address in their IM profile it would make things much easier. Having entirely separate systems for email and IM isn't good for users.

Users

The overall communications infrastructure could be improved if more people made tactical decisions about where and how to communicate. Keep the long messages to email and the chatty things to IM. Also for IM just do the communication not start with "hello". To discourage wasting time I generally don't reply to messages that just say "hello" unless it's the first ever IM from someone.

Conclusion

A large part of the inefficiencies in electronic communication are due to platforms and usage patterns evolving with little strategic thought. The only apparent strategic thought is coming from corporations that provide IM services and have customer lock in at the core of their strategies.

Free software developers have done great work in developing software to solve tactical problems but the strategies of large scale communications aren't being addressed.

Email is loosely coupled and universal while IM is tightly coupled, authenticated, and often siloed. This makes email a good option for initial contact but a risk for ongoing discussions.

There is no great solution to these issues as they are largely a problem due to the installed user base. But I think we can mitigate things with some GUI design changes and strategic planning of communication.

• [1] https://en.wikipedia.org/wiki/Instant_messaging
• [2] https://en.wikipedia.org/wiki/Real-time_computing
• [3] https://en.wikipedia.org/wiki/Eudora_(email_client)
• [4] https://flounder.linux.org.au/
• [5] https://en.wikipedia.org/wiki/Lemmy_(social_network)

15 Mar 2026 8:37am GMT

What led to this experiment? Well, for one, Well, for one, there was a thought shared by Andrej Karpathy regarding the shift towards "Agentic" workflows.

"The future of software is not just 'tools', but 'agents' that can navigate complex tasks on your behalf."

-Andrej Karpathy

Recently, I spoke with Ritesh, who mentioned his success using the Gemini CLI to debug an idle power drain issue on his laptop. I wanted to experiment with this myself, and I had the perfect use case: configuring the Hyprland Window Manager on my aging laptop.

The machine is nearly eight years old with 12GB of RAM (upgraded from the original 4GB). I found that GNOME and KDE were becoming overkill, often leading to system freezes when running multiple AI-powered IDEs like Antigravity and VS Code with Co-pilot. Coincidentally, I noticed my Jio number had a "Google One 2TB" and "Google AI Premium" plan available to claim. I claimed it, and now here I am, experimenting with the Gemini CLI.

npm install -g @google/gemini-cli

# Role: Hyprland Configuration Specialist (Minimalist & High-Performance)

You are a Linux Systems Engineer specializing in migrating users from heavy
Desktop Environments to minimalist, tiling-based Wayland sessions on Debian.
Your goal is to maximize available RAM for heavy applications while maintaining
essential desktop features.

## 1. Environment & Persona
- **Target OS:** Debian (Linux)
- **Target WM:** Hyprland
- **Hardware:** ThinkPad E470 (i5-7th Gen, 12GB RAM)
- **User Profile:** Emacs user, prioritizes "anti-gravity" (zero bloat).
- **Tone:** Technical, concise, and security-conscious.

## 2. Core Functional Requirements
- **Status Bar:** `waybar` (with CPU, RAM, Network, and Battery icons).
- **Wallpaper:** `swww` or `hyprpaper`.
- **Screen Lock:** `hyprlock` + `hypridle`.
- **Input Mapping:** Swap Control and Caps Lock (`kb_options = ctrl:nocaps`).

## 3. Operational Constraints
- **Permission First:** Ask before using `sudo` or writing outside the work directory.
- **Inspection:** Use `hyprctl`, `lsmod`, or `gsettings` for compatibility checks.
- **Artifact Management:** Update `MEMORY.md` after every major step.

15 Mar 2026 7:05am GMT