I love the KISS launcher. Do you know if Odyssey ever resolved being able to play opus files? My quick read through their repo suggests not.

Not just bloat and complexity, but also general wrong-headedness.

Also, Void is interesting and innovative - involving a new package manager, using LibreSSL (rather than OpenSSL) by default and having a musl libc variant available, amongst other things.

This specific study is Nightly only. In general I’d expect and hope that similar studies would only be run against Nightly for various reasons. However, as far as I can tell the current Mozilla privacy policy makes no difference between Nightly and Beta, and therefore Mozilla could consider themselves to have permission to run these opt-out studies on Beta, just as they have with Nightly. Mozilla may clarify this in the future.

On a pragmatic level, doing something like this with Beta would probably be much more visible and produce many more annoyed people and bad publicity, so I think Mozilla probably has good reasons to avoid it unless they have a study that they consider really important. Beta also has enough visibility that news about such an opt-in study would probably be widely distributed and well know, so you’d hear of it enough in advance to do something.

(I’m the author of the article.)

Good bittorrent daemons are hard to find. rTorrent is common but it tacks on this difficult curses interface you have to deal with. Transmission is okay but it tends to get buggy and break down at scale. Deluge is buggy as hell. btpd is too bare bones, a lot of important features are missing. All of these options also have really poor RPC protocols that use a lot of network, are annoying to write clients for, and don’t scale.

synapse focuses only on being a good daemon and delivers only that. The UIs are offloaded to separate projects. If that doesn’t seem like much, that’s because it’s not - but surprisingly this is not easy to find. We made it because there were no good options.

My experience with Pandoc was not excellent to convert Markdown to LaTeX. Pandoc is a bit complicated to extend as well.

What I did was use a Markdown parser(1) producing an AST(2), plugging into the parsing to extend Markdown syntax to support for instance the glossary use case(3), then write a LaTeX stringifier(4) for this AST. (In this Markdown AST -> LaTeX stringifier I only support standard Markdown syntax, this abbr plugin I wrote gets stringified through yet another plugins package(5) I wrote. It’s straightforward: 6.) Then I simply put the latex doc into some sort of latex template using a custom class, in the latex template you’d have your tableofcontents, glossaries, etc.

I had a bunch of lecture slides written up in org that I was dumping to LaTeX, which was always a bit fragile, and then a change in org-mode broke everything. In the end I wasted more time fixing everything than if I’d just written LaTeX to start with.

I think the best thing is to leverage smart editing (e.g. AUCTeX) as much as possible, and not deal with trying to convert from something else into LaTeX.

Having worked on a 1,200 page book I am going to concur. I started out using markdown+Pandoc and it became a time loss pretty quickly.

If email is that important to you (100% uptime requirement), then what’s your backup plan for a situation where Google locks your account for whatever reason?

Email does have the nifty feature that (legit) mail servers will keep retrying SMTP connections to you if you’re down for a bit, so you don’t really need 100% uptime.

Source: ran a mail server for my business for years on a single EC2 instance; sometimes it went down, but it was never a real problem.

If you need 100% delivery, then you can just list multiple MX records. If your primary MX goes down (ISP outage, whatever), then your mail will just get delivered to the backup. My DNS registrar / provider offers backup MX service, and I have them configured to just forward everything to gmail. So when my self hosted email is unavailable, email starts showing up via gmail until the primary MX is back online. Provides peace of mind when the power goes out or my ISP has outages, or we’re moving house and everything is torn apart.

Note that email resending works. If your server is unreachable, the sending mail server will actually try the secondary MX server, and if both are down, it will retry half an hour later, then a few more times up to 24 hours later, 48 hours if you are lucky. The sender will usually receive a noification if the initial attempts fail (and a second one when the sending server gives up)

On the other hand, if your GMail spam filter randomly decides without a good reason that a reply to your email is too dangerous even to put into the spam folder, neither you nor the sender will be notified.

Right, but this does seem to compound over time, and thus gets worse.

Also, NIH is more prevalent in certain Linux developers/communities than others. systemd adoption/rejection I think is at least somewhat representative of this issue (since one of the issues of systemd is that it is not very portable, requiring glibc [rather like proprietary software….], and integration of, for instance, GNOME with certain subcomponents of systemd creates a dependency of GNOME on systemd – which is currently able to be worked around, creating issues both for any portable to BSDs and also issues for non-systemd Linux distros and for non-glibc distros [Alpine, some Void]).

They are, it’s quite saddening actually.

I don’t quite understand the rational behind this? Why should one perfer vi-editing when, for example, writing prose? It would seem like all you’d get would be typing i before you start writing, and pressing the escape button when you’re done, plus maybe a more preferable color theme?

• dis deletes a sentence
• '' reverses your last jump
• Search highlights show if you overused a word
• c is great for editing and revisions
• Visual blocks help with adding formatting
• Move by paragraph and move by sentence

I don’t quite understand the rational behind this? Why should one perfer vi-editing when, for example, writing prose? ….

I’m not a vi-user, as you might guess, but I can say that a proper text editor is a real boon for writing any sort of text, whether code or light fiction. Word processors are such hostile environments for real production of anything, in my experience.

You say you generally use Emacs - don’t you prefer it for non-code things too? I assume vi(m)-people must feel similarly about their paradigm.

(now deprecated) btrfs

Link to deprecation notice? I was under the impression that it was still under active development.

SuSE still uses btrfs by default, AFAIR, so it’s not deprecated as such, but it also doesn’t have a lot to recommend it……

There is bcachefs, still in development; but even if it is successful, I would assume it would be at least a decade before it would be a real competitor for even present-day ZFS (which presumably would not stand still).

The author seems to be thinking that the Smalltalk programme had some merits that the current PLT programme doesn’t, which I find unthinkable. So it delivered as far as I’m concerned.

Most tantalizing question was:

..when and why did we start calling programming languages “languages”?

Nothing that extreme, no, but I’d say it delivers on questioning rarely-questioned assumptions.

How would you know? Maybe you simply failed to think it.

Did you know abut the song?

“Lennart explains that he thinks BSD support is holding back a lot of Free Software development”

I can think of something else which is holding back a lot of Free Software development.

Poettering’s approach to software development seems to make it clear that he doesn’t see any value in the continued existence of the BSDs. I think that they are an important part of the larger open *Nix world/ecosystem and that Linux benefits from their existence so long as there remains some degree of compatibility. I will say that I think the BSDs’ use of a permissive rather than reciprocal licence I think had been bad for them in the long run.