EINVAL: Valid solutions for invalid problems

Game review: Hard West

Tue, 14 Jul 2020 14:21:09 +0200

A solid clone of the modern XCOM games with a few twists making it fresh.

Hard West takes place in a world based on the wild west with fantastical elements added on top. I enjoyed this setting a lot, especially the lovecraftian mysteries left with no clear explanation.

The main innovation to the gameplay is the way probability works. It’s not random at all! Each character has a specified amount of luck which serves as a health or armor against the probability (sic!). If an enemy has 100 luck (it’s hidden for the enemies but can be guessed) and I have 95% chance to hit, I’ll surely miss but it’ll subtract 95 from their luck, leaving them with 5, allowing me to hit even a 10% shot. Luck regenerates after getting hit: the more unlikely the hit was, the more luck is gained back. I’ll spare you the exact math but I checked and the overall probability distribution seems to be correct. It’s just predictable in this case. This system never feels unfair and allows for some really interesting tactics such as depleting the enemy’s luck with weak accurate weapons and finishing them off with a powerful yet inaccurate weapon.

Luck also serves as a fuel for special abilities forcing us to choose between offense and defense. The abilities are diverse and add flavor to the combat.

Apart from the tactical combat, there is also an overworld map which works very differently in each campaign, keeping it from getting stale to the very end. In one campaign we’re conquering the natives while in another we’re investigating a local mystery while fighting the madness creeping in. All of this with a common overarching story.

For me the best summary of Hard West would be “an arcade XCOM”, and that’s a good thing.

Game review: Return of the Obra Dinn

Tue, 14 Jul 2020 01:18:58 +0200

A great take on the “murder mystery” concept taking action on a ghost ship.

The whole game boils down to deducing two things:

The identity of each character.
The way they died.

It’s done by analyzing the ship documents and witnessing the last moments of each crew member. I find it refreshing that I, the player, am the one conducting the investigation. The game won’t connect the discovered dots for me.

The whole thing is one of the most atmospheric gaming experiences I’ve had. The ship documents look old and authentic. The graphic style is unique and distinctive, personally I liked it, some probably won’t. Despite the simplistic graphics, the environment is very detailed. The music and sound design are fitting and add to the experience.

The story isn’t particularly interesting, it only serves as a background for the investigation. It’s not necessarily a bad thing.

Highly recommended for puzzle game enthusiasts.

Stock Firefox keyboard controls

Sat, 16 May 2020 00:33:38 +0200

Most keyboard aficionados use various keyboard-related addons in their web browsers, such as Vimium. From my observation, one of the most used features of such addons is keyboard-based link selection with so called hints, which usually looks like this (example from Saka Key):

To select a link, one would enter the number shown alongside it. Some addons offer also further filtering of these hints through entering text appearing in the link description.

While useful, I’ve come to often prefer an alternative available in Mozilla Firefox by default. Apart from the well-known Ctrl+F search, there are two “smaller” search modes available with / and '. The former is basically the same as Ctrl+F with more sparse UI. On the other hand, ' searches only in the links, ignoring all the other text. To click a link found this way one would press Enter. If there are multiple similar links, it’s possible to cycle through the narrowed down links with Tab. It’s very similar to the “secondary” link hints feature I mentioned in the previous paragraph, but built-in.

I highly recommend trying it out as it’s a great but often overlooked feature of Mozilla Firefox.

EDIT: I omitted a very important part of using this link search feature. It can be chained. For example it’s possible first to search for an article name, and then for the phrase “comments” to select the comments link under a specific article.

Emacs as a Shell

Thu, 30 Apr 2020 17:08:21 +0200

When I log into a new server, one of the first things I do is install a minimal Emacs package¹. Of course assuming nobody minds if the server is not strictly mine, I’m not a monster.

Emacs serves me as a de facto shell when setting up whatever there is to set up. By “shell” I mean a broader meaning of this word than just a command prompt: it’s the central program I use to interact with the system. Regardless of the system and its current configuration, I can expect Emacs to be predictably the same program suitable for both configuration file editing and advanced file management thanks to the built-in dired module. One could say I use it like many people use Midnight Commander (mc) though I consider it much more powerful for various reasons. Let me show you what it looks like:

Let’s walk through this screenshot slowly as it’s pretty packed. First of all, Emacs can be split freely, both horizontally and vertically. In this case I have 3 splits². The first one contains a config file being edited while the other two show the mentioned file manager called dired. Text editing is pretty self-explanatory while dired is the central piece of my “Emacs as a shell” workflow, so let’s focus on it for now.

As you may want to follow along, to open dired press C-x d (i.e. ctrl+x followed by d; not ctrl+d!) and enter a path to open.

Viewing files with dired

This dired window shows two files; to be specific, symlinks along with their targets. The rest of it look very similar to the familiar ls(1) output and for a good reason: dired uses it as the source of this data. We can leverage this fact and customize the ls(1) --switches used by pressing C-u s:

By default dired uses -al. Let’s add -L to make it show the symlink targets in place of symlinks (though admittedly it already shows after an arrow).

The symlinks are now resolved completely, we can now see the metadata of files themselves and so on. We could also instead add some switch affecting the file sorting order like -t. I’ll leave it as an exercise for the reader.

This is one of the things about Emacs I appreciate the most: it often doesn’t try to hide the complexity behind its workings. It embraces it, enriches it and exposes it to the user in an accessible manner. If I said dired is like ls(1) on some wild Emacs-flavored steroids, I wouldn’t be far from the truth.

Managing files with dired

Okay, listing files is easy but I mentioned managing files, not just listing. Let’s start with renaming: the best way to rename a file in dired is to press C-x C-q (which toggles the read-only mode in most contexts in Emacs) which enables us to… edit the file listing like a text file. Considering Emacs is a text editor after all, we can use all its text editing goodness here.

There it is, I’ve changed “blog” into “blargh”. To save the changes, C-x C-s can be used which is once again a general Emacs keybinding for saving whatever we’re editing. There are more nice details about this editable mode but it’s a topic for another whole blog post.

For more complex file operations dired uses various, usually capital, letters:

C for copying
R for an alternate way of moving/renaming
S for creating symlinks (and Y for relative symlinks)
D for deleting
x for secondary deleting of specially marked files (“flagged” in the dired lingo)

We can either operate on the currently focused file or mark more of them with m:

There are two types of marks in here: the “regular marks” and “flags”. They are differentiated by the letter on the left³: “*” or “D”. The “*” marks are used for most of the operations I listed before while “D” are used by the mentioned x deletion operation.

Okay, so we’ve marked some files we want to move elsewhere, what now? Let’s press R:

Now we need to enter the target path. But we already have a second dired window open just beside this one, why won’t it guess we want to move the files there? The answer is surprisingly simple: because we didn’t ask it to guess. Let’s press the down arrow. A little of context: up arrow would navigate the history of previous inputs, Bash-style. Using the down arrow can be seen as guessing the future input.

It’s essentially an on-demand version of mc-style dual-pane file management with some added flexibility.

The same trick may also be used to summon the current permissions when using the equivalent of chmod, chown and chgrp (M, O and G respectively).

Shelling out

File management aside, sometimes I need to perform a file operation not provided by dired and need to run an external command instead. Luckily dired has a very robust facility run with the ! key. The manual describes it really well but to summarize, let’s assume we’ve got three files marked, “foo”, “bar” and “baz”.

Entering echo or echo ? would run echo foo; echo bar; echo baz.
Entering echo * would run echo foo bar baz.
There are also various additional modifiers controlling how the commands will be run, for example & or ;, but I use them rarely.

So one can use * or ? to control how and where the marked files will be placed in the command. It’s a very terse but expressive way to run commands on files and one of my first “wow moments” with dired.

For commands not run with files as arguments I either use a non-dired variant of this command (it’s bound to M-!) or eshell which is a simple shell command prompt built into Emacs.

For long running commands I still use a regular shell, possibly in tmux. Mostly because Emacs is still a single-threaded program and while it has some async capabilities, I still prefer to keep such commands separate.

Summary

So that would be it. My workflow and reasons for using Emacs as my home away from home. What I’ve shown works out of the box, without any Emacs configuration and only with minimal Emacs knowledge. I highly recommend to give it a try as it saved me a lot of time over the years.

PS: A note for Emacs veterans: Yes, I am aware of TRAMP and use it extensively but there are times when I prefer to work directly on a remote host, for instance when I’d need multiple hops to reach the intended machine as the intended user as they tend to slow things down (2 hops is the most I’m usually willing to do). It’s also much harder to recommend using it to a beginner.

In the Debian family called emacs-nox for “no X11”. ↩︎
Technically speaking in Emacs lingo they are called “windows” while the GUI windows are called “frames” but that’s not relevant here. ↩︎
Technically one can mark a file with any character but it’s uncommon. ↩︎

Amazing Crap

Sun, 14 Jul 2019 03:30:00 +0000

…or should I say “Amazon Crap” as I’d like to talk about Amazon Fire HD 8. I have been using this tablet for about a year now and at this point I can say it is absolutely crap …and I love it!

First of all, I’m not a tablet person and I never planned to use my tablet a lot. I was looking for a cheapish device between a laptop and a smartphone. I didn’t need it to be beefy, I mostly wanted a highly portable device with a screen bigger than my phone’s to comfortably read things on it.

Fire HD 8 caught my attention due to its relatively low price and supposedly being good enough for light usage as apparently many very cheap tablets are bad even as paperweights. Importing it to Poland was a bit of a hassle but a friend abroad gave me a hand (thanks again!).

This tablet runs a heavily modified and locked down Android variation called Fire OS, not even connected to Google services by default as Amazon intends it to be used with their own ecosystem. I think this is the most crappy part of Fire HD 8 which ironically makes it so great. Since the OS is so locked down (being unable to change my launcher with no heavy hacks was the most painful thing), it limits my innate need to improve and tinker in things. I am almost certain if it would be a regular Android tablet, I would fill it with applications I don’t need, customize the hell out of it and ultimately make it slow down to a crawl, as is tradition on Android devices when you tinker with them too much. Additionally it limits my urge to connect it to too many services, so even if I were to lose it, it’s no real security concern as I have virtually no credentials there.

I’m speaking from experience: a few years ago I used to have a more powerful tablet at my disposal for a few months. I quickly got confused over what I was “supposed” to do on it and what on my smartphone. Since Fire OS is so annoying, it keeps me from overusing my tablet. It rules out any significant overlap between my phone and tablet usage and so also any need for configuration synchronization between them. Once again, less is more!

I use my Fire HD 8 as a big handheld screen for dumb stuff. Sketching, reading content unfriendly to a Kindle, sometimes watching movies or playing some games on the go (nothing too heavy but Baldur’s Gate works more than fine). Browsing the web is tolerable but the performance clearly encourages me to use a real computer instead, which I prefer anyway but might otherwise endure due to sheer laziness.

Apart from the screen size, there is one more clear benefit over using a smartphone here: a separate battery. I can carelessly use up all the battery in this non-critical device while keeping my phone operational. In the hindsight, this is the biggest benefit of a tablet for me.

Amazon Fire HD 8 is absolutely crap …and I wouldn’t have it any other way!

EDIT: For clarification, it is very possible to install Google Services onto a Fire, they just aren’t there out of the box.

One year with Notmuch

Fri, 14 Jun 2019 16:22:00 +0000

Email… One of the last bastions of non-proprietary communication with the freedom to choose both service providers and clients alike. Some call it archaic but none can avoid using it to some degree. For years I struggled to find an email client I actually liked. I tried all the usual suspects: Mozilla Thunderbird, mutt, alpine, and others. Even mu4e didn't scratch that itch.

I've spent the last few years on Thunderbird as I made a point that even if everything else is failing, email must work, so I tried to avoid any unnecessary hackery. In the end my nature got better of me: about one year ago I switched to Notmuch and now I think I'm ready to write down my experience.

Spoilers

I'm not switching back, Notmuch is great.

Notmuch is at its core an email search engine. It indexes the mails and allows to query the resulting database. That's all it does, there is no fetching and sending email or the UI apart from the CLI tool. For these things I needed separate tools.

I chose isync to fetch my email and msmtp to send it. At first glance it seems more complex than simply clicking away the settings in Thunderbird but I actually like it better. They are configured with plaintext and there is a very clear separation of concerns. The config files look like this:

~/.msmtprc

defaults
port 587
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

account HomeAccount
host smtp.example.com
from vifon@example.com
auth on
user vifon@example.com
passwordeval pass mail/vifon@example.com

account WorkAccount
host mail.workplace.example.com
port 465
from vifon@workplace.example.com
auth on
tls_starttls off
user vifon@workplace.example.com
passwordeval pass mail/vifon@workplace.example.com

account Gmail
host smtp.gmail.com
from vifon@gmail.com
auth on
user vifon@gmail.com
passwordeval pass mail/vifon@gmail.com

account default : HomeAccount

~/.mbsyncrc

IMAPAccount HomeAccount
Host imap.example.com
User vifon@example.com
PassCmd "pass mail/vifon@example.com"
SSLType IMAPS

IMAPStore HomeAccount-remote
Account HomeAccount

MaildirStore HomeAccount-local
Subfolders Verbatim
Path ~/Mail/vifon@example.com/
Inbox ~/Mail/vifon@example.com/Inbox

Channel HomeAccount
Master :HomeAccount-remote:
Slave :HomeAccount-local:
Patterns *
Create Both
Expunge Both
SyncState *


IMAPAccount WorkAccount
Host mail.workplace.example.com
User vifon@workplace.example.com
PassCmd "pass mail/vifon@workplace.example.com"
SSLType IMAPS

IMAPStore WorkAccount-remote
Account WorkAccount

MaildirStore WorkAccount-local
Subfolders Verbatim
Path ~/Mail/vifon@workplace.example.com/
Inbox ~/Mail/vifon@workplace.example.com/Inbox

Channel WorkAccount
Master :WorkAccount-remote:
Slave :WorkAccount-local:
Patterns *
Create Both
Expunge Both
SyncState *


IMAPAccount Gmail
Host imap.gmail.com
User vifon@gmail.com
PassCmd "pass mail/vifon@gmail.com"
SSLType IMAPS

IMAPStore gmail-remote
Account Gmail

MaildirStore gmail-local
Subfolders Verbatim
Path ~/Mail/vifon@gmail.com/
Inbox ~/Mail/vifon@gmail.com/Inbox

Channel Gmail
Master :gmail-remote:
Slave :gmail-local:
Patterns *
Create Both
Expunge Both
SyncState *

If you don't like the syntax (it's not great but it does its job), don't worry, there is little need to touch these files after the initial setup, unless you need to add or remove an account.

In both cases, I'm using pass(1) for the password storage instead of putting my passwords in plaintext there. I find pass excellent for automated access like this.

Summarizing: After fetching my inbox using isync, I have a full offline copy of all my mails at ~/Mail. Notmuch can then index it.

OK, we're done with the internals. As for the UI, I chose notmuch.el. It's based on GNU Emacs, so it's right up my alley. There are other alternatives, including using Notmuch from mutt/neomutt or dedicated frontends like alot.

If you're using Notmuch as a search engine for a "regular" email client like mutt, that's about it. But I was going to use a client centered around Notmuch so the fun only begins. First of all, since it's essentially a database, Notmuch has no concept of folders. Instead it makes extensive use of tags, similar to the ones known from Gmail but with a few very important differences. I didn't like the Gmail tags because they wanted to be both tags and folders simultaneously. What do I mean? You needed to create them (one way or another) and they still existed even when empty. For me it felt like a pretty big cognitive overhead to create a new tag as it would linger for probably too long and pollute the namespace. In Notmuch the tag exists only as long as there are messages with this tag. The tags are inherently bound to messages and don't exist as a separate concept. These are the main tags I use:

inbox (for non-archived mail, archiving consists on only removing this tag),
new (for the mail that appeared in the latest fetch and weren't there before),
sent,
unread,
flagged,
actionable,
many less interesting ones.

Some of them are directly tied to the server-side flags (like unread or flagged), others exist solely in the Notmuch index and I assign them using the pre- and post-hooks that are being run before and after I refresh the mail index respectively. For instance, my pre-hook consists of:

#!/bin/bash -e
notmuch tag -new -- tag:new
mbsync -a || true

…so first I remove all the new tags from the previous run and then Notmuch runs mbsync for me to fetch all the new mail. I assign the new tags by specifying this option in ~/.notmuch-config:

[new]
    tags=unread;inbox;new;

My post-hook is much more personalized, so there's little point in posting it whole here, but that's the place where one would add various automated tagging rules. I have there rules like this, that make my work more organized:

notmuch tag +flagged -- tag:new and query:work and '"Assignee: Wojciech Siewierski"'

In notmuch.el tagging is done by pressing +sometag to add some tag or -sometag to remove it. Yes, just a plus or minus and the tag. It can be "chained" before confirming with Enter like this: -inbox -unread +actionable -flagged. It feels really natural and doesn't get in the way.

Considering Notmuch.el runs inside GNU Emacs, it allows to use all its text processing capabilities when composing mail. It really makes a difference for the Emacs power users and that alone is a major argument for using Notmuch for me. It utilizes the Emacs message-mode with some additions so most generic info about composing email in Emacs found online applies here. GPG signing, composing complex mail (like composing HTML mail with Markdown) or attaching files is pretty easy thanks to that. For instance it's possible to use gnus-dired-mode created for the Gnus mail client (also Emacs-based) to select the attachments directly with the dired file manager (yes, you guessed), it doesn't even need to know anything about Notmuch, it just knows about message-mode. What really surprised me, message-mode handles a regular drag'n'drop of the attachments from traditional graphical file managers, so if you're leaning that way, more power to you!

I really came to like the way notmuch.el handles the HTML email. By default it prefers showing the plaintext version of email but if none is available or the user requests the HTML version it manually, it half-renders it. It's good enough to handle the links and formatting but usually not complete enough to allow all the usual crap HTML mail are infamous for in some communities. But if I do need to render it fully, notmuch.el can save the HTML part of the mail in a temporary directory and open it with a web browser. At first it felt inconvenient but I came to prefer it to the regular approach: I'll probably need to open a web browser to open some links in this mail either way, so I get a head start here.

When it comes to the regular email UI elements, notmuch.el is more than competent. It can display the mail list both as threads (one thread == one list element) and as trees (one thread == one tree, one mail == one tree node) and the thread navigation is top tier.

Is Notmuch + notmuch.el perfect? Of course not. My main "complaint" is the disconnect between the abstract tags system and the actual mailbox structure. I can include the mail folder hierarchy in a Notmuch search query but that's it. When I want to know the actual way my mail are stored, I either inspect the ~/Mail directory manually or just start Thunderbird which I'm still keeping as my fallback (remember? Email must work!). Additionally, the way I use email is very centralized. The Notmuch metadata is stored locally, so using it on more than one device is tricky. I have a single machine I run Notmuch on so I didn't have a chance to try muchsync but it's definitely more work than just logging in via IMAP and being done with it. I have a few rules to handle the Gmail mail I archived on my mobile devices:

notmuch tag -inbox -- tag:inbox and not folder:/Inbox/ and path:/@gmail.com/

…and I don't bother making Gmail aware of mail being archived in Notmuch.

Many will miss the lack of automatic mail checking out of the box but for me it's an improvement. I prefer to check my mail on my own schedule, not run to check it just because a notification came.

That's roughly how I've been using Notmuch for the last year. All in all, it's a trade-off I'm willing to accept but it's not for everyone. I don't see myself switching mail clients anytime soon. Notmuch is the best way I found to organize and search my mail, and it allows me to utilize my editor of choice. Even if you're not a fan of Emacs, it's worth a try with one of the other frontends, I know some happy users that did.

less can do even more

Fri, 14 Sep 2018 02:50:00 +0000

After writing my last post I took my own advice and reread the less(1) manpage. Surprisingly I found some new really handy tricks that were very helpful not even an hour later!

First of all, the pair matching. If the topmost displayed line (that’s the important part!) contains an opening bracket {, we can press this very key to find the matching closing bracket (}). It is displayed by placing the line with the matching } at the bottom. Similarly now we can press } to find the matching { to the closing bracket in the bottom line, and it gets shown as the topmost line. At first it feels strange and confusing but it makes sense after trying it out. I used {} in my example but the same “trick” works for () and []. We can also match a custom pair (sadly, only single-character) by pressing ctrl+alt+f followed by the opening character and then the closing character, to go to the closing character and ctrl+alt+b followed by the same thing to go back to the opening character. So even though there is no key for matching <> we can use ctrl+alt+f < > to match them.

I mentioned I found it useful in real life. It was when browsing logs that contained a JSON-like structured data. When coding I usually run my tests with ./test-suite |& less, so using the stuff built into less was much simpler than opening the same log in a “real text editor”. Nota bene, I could have easily done so by typing g|$vim - to go back to the top of the log file (g) and pipe (|) everything up to the end of the viewed text ($) with vim (vim - to make vim read its stdin). I could have omitted g and replaced $ with . to pipe just the visible portion of the log into vim if that’s the only part I needed at this time.

I also find the search (/) flags useful often, for example /^R treats the query as a plain text, with no regular expressions, while /^K only highlights the matches without changing the current position in file. I’ll leave learning the rest of the flags as an exercise to the reader.

less can do more

Sun, 09 Sep 2018 14:20:00 +0000

less is probably one of the most used programs in the UNIX world. It’s so ubiquitous we usually barely notice it. For clarity, I mean this less, not this one. Despite its ubiquity, very few people actually take time to learn its less obvious but still very useful features. Let’s change that!

First of all, the & key. It prompts for a search pattern and then acts like a filter, showing only the matching lines, not unlike grep. Unlike grep though, you can change this filter without closing less and it’s generally very useful if you need to filter the content as an afterthought, if you decide you really could use a filter only after producing copious amounts of output.

Another useful thing is toggling the commandline -options in a running less, once again without restarting it. For example you can press -S to toggle wrapping the long lines or -J to mark the lines matching the search pattern with an asterisk. It’s worth to keep in mind that every commandline option can be toggled this way, though obviously some are more useful this way than the others.

Last but not least, the marks known from Vim (among the others). By pressing m followed by almost any other key, you can save the current position in a text and then return to it by pressing ' followed by the same key. For instance you can save two distant places in a file with ma and mb and then cross-reference them by jumping between them with 'a and 'b. Considering less is very often used for reading lenghty manpages with lots of “See SOME OTHER SECTION for details”, it’s a godsend.

In general, every user of UNIX-like systems should at least skim the less keybindings, as even in such a simple tool there is much to learn. Press h to display them and have a good time reading through them! I know I had!

Part Two

My experience with Firefox Quantum

Tue, 21 Nov 2017 01:20:00 +0000

About three months ago, after many years of using Chromium exclusively, I came back to Mozilla Firefox. Actually I was forced to switch because the hardware acceleration in Chromium was crashing my GPU driver (don’t even ask…) but after a few days I was perfectly happy with this forced change.

When I switched to Firefox, it was already much snappier than I remembered from my last time. I was really impressed with what the Firefox Quantum team did but up until this point it was still just a good replacement for Chromium. Even a great replacement but still not a clear improvement. Not anymore! Alluding to its original name—Phoenix—Firefox was reborn from its ashes and is better than ever.

WHAT I LIKE

Firefox 57—or Firefox Quantum—starts a new era of Mozilla Firefox, a truly modern browser. These are my favorite features that make me feel good I chose Firefox again. Actually most of them were there already for a few months but now they got polished.

1. The screenshot tool

The screenshot tool that allows for the easy selection of the webpage element to share and then to upload that screenshot to the Mozilla servers (it gets removed after 14 days). Personally I already have a set of scripts for screenshot sharing but now it’s available for everyone.

It’s fast, it’s simple and—most importantly—it works. I like it!

2. “Send Tab to Device”

I never liked the synchronization of the open tabs in Chromium — I usually need to share a single tab from my mobile to desktop or vice versa, never the whole set. Mozilla gets it — it’s possible to send a single tab to the selected device with just a few clicks. No other 3rd party software needed (e.g. Pushbullet). Sometimes some delays may be experienced but otherwise it works pretty great.

The browsing on multiple devices feels interconnected yet not intrusive or overwhelming.

3. The buttons on the right side of the address bar

Related to (1) and (2): I really like the idea of using the address bar for some page-related actions like screenshotting, bookmarking, tab-sending or the reader-mode. Separating them from the regular addons makes the whole experience fluid and pleasant. Did I mention it’s customizable? Now I did.

4. Freedom

It’s not as much of a feature as a fact about the company — Mozilla itself.

The browser market is currently divided between Mozilla, Google, Microsoft and Apple. Among these companies only Mozilla may be considered “independent” and “pro-user”. There are no hidden agendas, no profiting off the users’ data. The browser is free (as in freedom) and open with no proprietary components. Mozilla has proven on numerous occasions that it values its users’ privacy. I feel much more confident using the Mozilla cloud services (like the screenshot hosting) than choosing the services of their competitors. I know I can trust them, that I am a user, not a product.

5. Better incognito mode

I use the incognito mode pretty extensively, mostly out of habit. In Chromium it was always annoying me that I cannot restore a closed tab in the incognito window. In my opinion it should be possible for as long as the whole window still exists. Well—good news!—this is exactly how it works in Firefox, how it always was ever since Firefox 3.5! I missed it!

Additonally Firefox now treats the incognito windows in a special way: it tries to block the tracking elements on the visited webpages. Actually I dislike the fact that incognito is treated in a special way because it will reinforce the notion that incognito is a security feature and not a convenience feature. I suspect Mozilla decided the webpages would start blocking Firefox if it did block the trackers by default. It’s trivial to enable this feature in the non-incognito mode, so I think it’s still a good move in the long run.

6. Redesigned UI & the amazing performace

Last but not least: The redesigned user interface is gorgeous. It’s filled with beautiful yet not distracting animations, polished icons and dozens of little tweaks and changes.

What’s even more important, the new Firefox feels at least as responsive as Chromium. It’s blazing fast and surprisingly memory-efficient.

WHAT I STILL MISS

Is Firefox better than Chromium in every way? Not exactly.

1. Multiple tabs selection

Chromium has an obscure feature making it possible to act on multiple tabs at the same time. By Ctrl+clicking (or Shift+clicking for a slightly different behavior) the tabs, we can select all the clicked tabs and then close or move them all at once!

EDIT: Added in Firefox 64.

2. Profile management

I use multiple browser profiles heavily. I use them to separate my work stuff from home stuff or to test things on a clean setup.

While Firefox have supported multiple profiles since forever, switching between them is still far from seamless. In Chromium it’s done with a button in the upper right corner (or Ctrl+Shift+M). In Firefox I have a bunch of scripts running firefox -P <PROFILE-NAME>. While I like it for the added control (I found no way to script the Chromium profiles), it felt awkward at first and I’m sure it feels the same for many other users.

On the other hand, Chromium aggressively encourages the user to log into the Google services which effectively change the local browser profiles into the online Google accounts negating all the privacy benefits.

At the end of the day I think I prefer the Firefox profiles but only because of Google being Google.

Addons?

You might have noticed that I still didn’t mention the hot topic of the legacy Firefox addons that were deprecated in favor of the new so-called WebExtensions. I did so on purpose. It’s arguably the most brave change in Firefox Quantum and while I will miss one or two legacy addons, I understand this decision and I agree it was necessary. Let the past be the past.

Personally I consider Firefox Quantum a new bright era of modern Firefox, a worthy browser for a truly free person.

Secondary login credentials

Sun, 20 Nov 2016 01:53:00 +0000

Sometimes I need to access my files on my servers using SSH/SCP from an untrusted device and/or application. Usually I would create a new SSH key pair so that I can easily revoke these credentials later if such need arises. But what if the used application doesn’t support SSH keys or we do not want to use them for some reason?

There is a trick supposedly used by sysadmins in the olden days, before sudo was around. I assume you’re at least aware of the /etc/passwd file that contains the basic information about all the system users. Information such as the username, historically hash of the password¹, the user and group ID (UID and GID). It looks like this:

vifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh

The trick is to create a second line for your user — with the same UID but a different username.

vifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh
alsovifon:x:1000:1000:Wojciech Siewierski,,,:/home/vifon:/bin/zsh

Such user has a separate password (among other things) but once you log in, it functions almost the same as your regular user.

What do we gain this way? The most important part to me is that in case the credentials get compromised, only the password to the secondary username needs to be changed.

Are there any other differences between our twin users? The following ones come to my mind:

Groups: Groups in /etc/group are assigned to usernames, not UIDs. Usually our user after a login with a secondary username belongs only to its main group (defined by GID specified in /etc/passwd). Seemingly as an added benefit the compromised credentials cannot be used for instance to manage Docker even if normally the user would be privileged to do so. I said seemingly… Well, nothing stops the user from using newgrp(1) to change their group to any group associated with our primary username.
Login shell: Login shell may be changed separately for each username. I didn’t find it particularly useful but maybe you will.
Home directory: The home directory also may be changed separately. Once again, might come useful but I didn’t use it.

I definitely do not recommend using this technique on important servers but it’s a workaround that comes in handy here and there.

These days usually x is placed in this field which means “the actual hash is in /etc/shadow”. ↩︎

About

Mon, 01 Jan 0001 00:00:00 +0000

Hi. My name is Wojciech Siewierski, sometimes known as vifon. I am a software engineer and a UNIX sysadmin from Warsaw, Poland.

On this blog I’m going to write about various useful/funny/surprising/obscure ways to get things done. Or anything I will find particularly interesting, really.

If you’d like to contact me, I can usually be found on irc.freenode.net as vifon.

My PGP key fingerprint: BAD7 861E F3EF 053F F08D 9D5F 00AC 06C0 8900 29F6
My older PGP key that’s sometimes still in use: 3019 3C49 CB39 CD27 0082 46AD E590 2A52 B247 B8DE