𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

No, I didn’t. I don’t use Pis, I have ODroids. Heck, they may sell batteries for ODroids, too.

For me, it wouldn’t have made much difference because I have UPSes around the house serving things like routers, modems, and switches. And I do care about size and energy use. I’m only saying there are advantages to using laptops.

You can get little integrated LCD cases for Pis too, can’t you? And maybe even a little fold-out keyboard. Congratulations! You’ve re-invented the laptop!

Thanks! That’s all great information.

I’d bet there are a bunch of college students involved in the implementation, too. I don’t see ongoing maintenance taking much more manpower than MS; we certainly had dedicated teams for it at my last company, so maybe that will be a budgetary wash, and what they save will be the probably significant licensing.

Thanks. I wonder why both jitsi and Matrix. Someone in the thread said it was too bad Matrix’s video conferencing wasn’t good enough that they had to add an extra software component, but I wonder what, exactly, the evaluation found wrong with it.

I have a lot of issues with Matrix, but the video conferencing didn’t seem worse than the horrible key management.

Every day?

• Herbstluftwm, the window manager. I used i3 for a decade, then bspwm for a few months, then landed on hlwm which I’ve been happily using for over a year. I don’t foresee changing until I’m forced to switch to Wayland. I’ve used almost every window manager and DE available for Linux and Solaris. Hlwm has things I can no longer live without:
  • It’s entirely configuration-file-less, which means the CLI client is the first class citizen for C&C.
  • It’s tiled and keyboard controllable is, again, a first-class citizen
  • It has a sane tree model, with no weird exceptions
  • It’s stable
  • It’s fast and small. You never see it in top, sorting either by CPU or memory
• Zsh, the shell, in which I run 90% of my applications (the regular exceptions being the Luakit browser and Factorio, the game. everything else is CLI or a TUI). Zsh is bash backwards compatible, and it has a bunch of extra convenience syntax that makes scripting more powerful, pushing out the border where switching to a real programming language is necessary. I have lived in sh, bash, and csh over my life, and I’ve tried fish and a number of others; the rich data model for process communication is compelling, but I’ve always discovered it lacking, so on zsh I remain.
• Tmux, the terminal multiplexer, which is (almost) invariably the first child of every terminal (rio -e 'tmux attach -t#'). Because terminals crash, because it survives session restarts, because it lets me log in remotely and continue what I started in my desktop, and because it works over ssh and having a consistent multiplexer environment across machines is nice. I used sceen for years before discovering tmux, and have tried almost every other terminal multiplexer; and none add any significant value for me over tmux.
• Helix, the editor in which I spend most of my time. Because I started with emacs and used it for years before switching to vim. Then I used vim for decades before switching to Kakoune. Then I used Kakoune for about 2 years before switching to helix. Kakoune was too much like Emacs for my taste: heavy on chording, light on modality. Helix is much more like vim: lighter on chording, more mode-driven. Chording aggravates my carpel tunnel, and I’m more comfortable in modal editors. I switched from vim because the plugins necessary to be a competent development environment got insane, and my vim was starting to take as long to start up as emacs, which was unacceptable. Also, LSP integration was super flaky and broke every six months; it’s what initially drove me to Kakoune.

I’m currently using Rio as my terminal. It has bugs, but it’s actively developed and regularly releases will fix one more thing. It has both ligature and sixel support, and it’s wildly fast and far, far less memory intensive than either kitty or ghostty, which are both pretty fat. I am not including it in “the list” because some remaining bugs are pretty big, like randomly crashing when it gets resized or sees some sequence of asci escape codes. It’s not much of an issue because I run everything in tmux, and it crashes less with every release, but I hesitate to recommend it until it’s more stable.

This is, in my mind, one of the benefits of laptops over micro computers: integrated UPS. Even an old, degraded battery will probably get you a couple of hours with the screen off.

IME, power consumption is going to be worse overall, for any laptop likely to be in the recycle bin, it’s probably double the consumption of an ARM SBC. The integrated UPS and usually decent power conditioning of the power supply saves you more money with a laptop. Plus, keyboard and screen for emergencies - I just generally expect that, over there life of a micro I’m going to have to drag out and plug in a spare keyboard, mouse, and monitor because something in a device, or an upgrade, or BIOS flash, is preventing a boot.

There are a lot of good reasons to use laptops instead of SBCs, if you don’t mind the extra power draw and (as she says) don’t have size requirements.

This article is terrible.

In less than three months’ time, almost no civil servant, police officer or judge in Schleswig-Holstein will be using any of Microsoft’s ubiquitous programs at work.

Instead, the northern state will turn to [an unnamed, gaping information hole] open-source software to “take back control” over data storage and ensure “digital sovereignty”, its digitalisation minister, Dirk Schroedter, told AFP.

“We’re done with Teams!” he said, referring to Microsoft’s messaging and collaboration tool and speaking on a video call – via an [unnamed, gaping information hole] open-source German program, of course.

What will they use instead? Who the fuck knows! The article omits this crucial piece of information.

And don’t say it’s TBD; they’re not going to say they’re “done with Teams” without knowing what they’re switching to. Or, even if they haven’t put the final nail in the decision, they have a short list.

Mint eschews all of the Snap crap, though, doesn’t it?

Jesus, please tell me it does. I’ve been recommending it to beginners. I thought it was sanitized.

Void is rolling release IIRC

That’s what I thought, but the main website says Void focuses on stability over being cutting edge, which would imply some sort of release cycle. Or, maybe they just update packages less frequently.

I still hold Debian in higher regard since it’s slightly easier for a novice to get used to

It’s hard to beat Mint as a novice distro, for sure.

(I’m replying to you twice b/c totally different topics)

Tell me more about your Void experience. I’ve been meaning to give it a shot, except I don’t get as much enjoyment out of fussing with distros as I used to. What are the pain points? Under Artix, I used dinit which I really liked, but I tried s6 first and absolutely hated it. I didn’t try runit; how is it?

What I’m most interested in is xbps, because IMO it’s the package manager that makes or breaks a system. I’m quite fond of pacman and have encountered far fewer dependency hell situations than I did with either rpm or deb, and rolling release is a must. xbps looks kind of like a rolling stable release?

I feel the same way about Artix. I had it on my laptop for a while, and it was a regular PITA. I think I may have made it harder on myself, because while getting rid of systemd was fine, I was also trying to do without NetworkManager and on a laptop that wasn’t a great idea. I never did find a good, reliable set-up that managed access point hopping as well as nm.

Really, thinking back, Artix was fine; it really was just the roaming WiFi handling that gave me grief, and I did that to myself.

The screen shot is because they were proving a point.

Your other points are valid. Chrome? Logged in to Google? Google search?

Although, I will say that with as shitty as Google search has become, it returning the answer as the first result only underscores their point.

I had the similar comment about PKGBUILD/templates. The package definition is far less likely to do something malicious than the software you’re installing; it’s indeed a vector - a hypothetical AUR “git-plus” package could install git and a virus at the same time - but frankly I’m more concerned about upstream.

Are you running on btrfs? If not, why not? If so, install snapper and grub-snap or refind-btrfs, or whatever, and go wild.

Sounds like you might also be missing backups, but snapper you can have run every 10 minutes at almost no overhead. Then it won’t matter if you delete something; you can always grab it out of a snapshot.

Yeah, there are a dozen “trash” commands. Honestly, I think changing muscle memory would be safer, but they could just install one of the trash commands and set up an alias as you say.

I don’t do this thing, so it’s a real question. If I were doing it from scratch, my instinct would be to go with the partition.

I don’t think you’d even have to make your own image, although you’d be mounting /home by hand every time if you didn’t. Hm. If you built your own image, you could mount everything as an overlayfs, and persist even application installs.

Can’t you just partition the SD card and mount the second partition as your persistent storage? Why do you have to unmount anything?

Did you read the same thread I did?

Safely changing history

How exactly does Mercurial manage to keep you from getting in trouble while changing history?

Mercurial actually keeps track of something called phases. Every time you push changesets to another repository, Mercurial analyses the phases for those changesets and adapts them if necessary.

There are three phases, each resulting in different behaviour:

• secret: This phase indicates that a changeset should not be shared with others. If someone else pulls from your repository, or you push to another repository, these changesets will not be pushed along.
• draft: This is the default phase for any new changeset you create. It indicates that the changeset has not yet been pushed to another repository. Pushing this changeset to another repository will change its phase to public.
• public: This phase indicates that a changeset was already shared with others. This means changing history should not be allowed if it includes this changeset.

Mercurial uses this information to determine which changesets are allowed to be changed. It also determines how to select changes to rebase or histedit automatically. For example: using histedit without any arguments will only show draft and secret changesets for you to change.

You can not change history for any published changes - like I said, doing so makes your repository incompatible with any other clone.

Good resource, thanks

Read the thread. The Kernel maintainers use b4, which rewrites history.

Mercurial does not work like git, and history is immutable: there are no commands for changing history.