Navigation
Home
Home
RSSGit ServerRainchan ImageboardBrowse Site on Tor
Backups - (Tor) (I2P)
Welcome Image - LargeWelcome Image - SmallNixx's Blog
Welcome to my Magical Realm.
1 2 Next

Imageboard Number 314,107

It's been a while. I thought, rather than create a post for every litte thing, it would be better of me to return each time I had done something of substance, however infrequent that would end up becoming.

So, I made an imageboard

Yes, the title of this article already alludes to what a futile exercise this typically is. Normally this isn't the kind of thing I would have considered doing. I fact, I was just looking for somewhere to talk to my friends, as a collective community, that would make sharing content easy. And of course, without relying on closed-source software or someone else's server.

And in exploring various options such as Mumble, or Tox, options that were federated, distributed, or entirely self-hosted - none of them offered enough features to convince people to move from closed-source platforms. Connecting was more complex, sharing content was more complex, message history was unreachable, and often many of these open-source instant messengers fell short of a key point I was looking for - the idea of a "community". Not messaging one person as an individual, or simply creating a group chat, but actually having a community.

Of course, that's not to say any of the projects I have mentioned are not worthwhile. They have their own merits, and should be promoted as such that more developers work on them, and they are added to, improved upon, and refined. For the use of free, ethical software, that's necessary. But for my use-case, they were not yet enough. And it was at that point that I realised, an imageboard can be open-source, self-hosted, platform-agnostic, and is streamlined for communicating and sharing content.

I won't go into the nitty-gritty of how it was made, as vichan exists, and is documented. Despite complaints of it lacking features or being dated, I've found it to be a somewhat smooth process to work with, most things aside from one or two exceptions have worked as-is without incident.

The point of all this

I'm not seriously intending to 'make it big', or challenge larger, more popular imageboards for their positions. It exists largely for the benefit of me and a few of my close friends, having a pleasant time. But, if you'd like to spectate or join in, you're welcome to.

2021.03.21

2021.03.21Article Page

DIY Thigh Implants

If you hadn't already guessed, I'm referring to the film 'Tetsuo: The Iron Man' (鉄男: The Iron Man). I hope you didn't think I was planning on jamming a metal rod into a wound on my thigh, and are now disappointed.

I've still not entirely established to myself whatever it is I want to talk about on this website, but seeing as I've discussed a variety of things - some of which not belonging to me, such as my post on Qutebrowser or my post on PC-98 era Touhou games, there's no reason I can't talk about a film I really enjoy.

A frame from Tetsuo

There are a couple of reasons I feel like talking about it. I'm interested in a lot of media and various types of art, and you may notice references around my site, but I may not necessarily talk about them: this is generally because they're well-known. I feel Tetsuo is somewhat known, but not nearly as much as it should be.

And I get the feeling, among those following my site, there are many people that would enjoy a low-tech low-life body horror film. Tetsuo is referenced as a "cyberpunk" film, but Eastern and Western conceptualisations of "cyberpunk" wildly differ - Japanese cyberpunk tends to a depiction of industrial, metallic imagery, and a narrative that can lean more or less towards being incomprehensible. A good, better-known example may be the manga series/animated film Akira. Because of Tetsuo's dark and vivid imagery, surreal pacing, and low-budget underground production, I imagine many here would appreciate it. That, and it packs a lot into the space of an hour. I'm sure you can spare an hour.

I'm sure it goes without saying, but this is an adult film, neither for young children or the faint of heart. I mean, come on.

The production also stands as an example of how much you can do on a severely restricted budget. The camera is monochrome. The animation is done with stop-motion. The metal growth was produced by taping discarded electronics to the actors' bodies. And it looks fantastic. The thought put into the lighting, angle, and perspective of the camera shows. Occasionally the film drops into long indulgent footage, scrawling over wiring, metal, and industrial components to the enthralling beat of the original soundtrack by Chu Ishikawa (石川忠). Everything adds up, contributing to the vivid, claustrophobic, unhinged feeling of the film. That being said, it is rumoured that the production was such a painful experience most of the crew aside from the actors had left, and the director - Shinya Tsukamoto (塚本 晋也) - almost burned the negatives.

Animated scene from Tetsuo, of the maggot infested wound

Tetsuo does have an underlying plot - it isn't just a film about metal monstrosities beating each other around (though there's enough of that to taste). The plot itself is fairly straightforward, though requires some attention. I'll give a rough summary of the plot below, skip to avoid spoilers. This summary explains things (as far as I understand them) chronologically, rather than revealing secrets in the same order as the film, so if you've already seen it may help you understand.

Plot (spoilers, obviously)

The metal fetishist (MF) has a chunk of metal lodged into his brain. The doctor is surprised he is still breathing and has made it to a hospital. This may explain his fascination with implanting metal into his body, or may be a consequence of it. MF is at his hideout, full of rusted scrap metal and pictures of athletes. He rips open his thigh, and thrusts a metal rod inside. Presumably later, he unwraps it, to discover the wound is infested with maggots. Terrified, he runs out onto the road, and is hit by the car of a salaryman and his girlfriend (SM and GF). He dies upon being hit. SM and GF discard the body in a forest, having sex afterwards, in front of his makeshift grave. SM is tormented by daydreams and visions of industrial machinery. A metal spike protrudes from his cheek, which he covers. GF cannot stop thinking about the accident. On SM's way to work, a woman sitting next to him notices an amalgamation of flesh and metal on the ground, pokes it, and quickly becomes a puppet of MF's spirit. SM flees in terror to hide in a toilet, but is able to kill her with his own growing metal powers. SM later dreams of GF sodomising him with a giant metal phallus. SM and GF have sex after he has woken up. They eat a meal, but SM cannot stop thinking about metal, the chewing food sounds like scraping metal. SM's transformation accelerates. His penis has been transformed into a large metal drill. SM hides from GF, afraid to let her see him. GF convinces him to come out. GF is horrified, and her rejection of him after her confidence angers SM, and he attacks her. GF stabs him in the neck with a kitchen knife, and believing to have killed him, commits suicide by impaling herself on his spinning drill. As SM regains consciousness, MF laughs at him. SM has completed his transformation, and now MF is coming to hunt him down. SM tries to commit suicide by electrocution, but in his transformed state it only stimulates him further. SM possesses the body of GF, destroying all metal in his wake. MF easily overpowers SM, and shows him a vision of the "New World" - a world overcome by metal, depicting SM as a human trapped in a pod, then screaming, consumed by metal pipes and wires and stripped of flesh. MF chases SM through the city, beating him around, before MF is incapacitated by a vision from his childhood of being beaten by a vagrant with a metal stick. MF gets up and attempts to attack SM, but SM is now too powerful, and they absorb each other, becoming a single tank-like monstrosity. They claim with the power of their love, they will burn the world and return it to a rusted ball in space.

I found the whole thing weirdly moving, almost sympathetic. If I've not convinced you yet, you should listen to my jam, it's amazing. And if you've already seen and like it, you should find more of Shinya Tsukamoto's works, other films of Kei Fujiwara (不二稿 京) such as 'Organ', and try out some music from Chu Ishikawa.

Neither the image or the animation in this article belongs to me, they are taken from '鉄男: The Iron Man' and credit goes to respective parties.

2020.12.27

2020.12.27Article Page

Making a Mess of an E-mail Host

I made an attempt at making my own e-mail server. I was talked into it by Qorg, who reminded me of the existence of the original emailwiz script by Luke Smith. Seeing as I run an Arch Linux server, rather than a Debian-derivative, I would attempt to port it.

I intended to finish this completely, if only for the sake of credibility when I share my findings regarding the process of setting up an e-mail server, but in the end I have left it 98% finished. For various reasons I'll talk about, it wasn't quite worth finishing for me. But still, nonetheless, I hope what I have learned from it can be of use to someone.

How would this in theory be done?

I have made a port of the script, to Arch Linux, which you can find here. If you use a Debian-derivative you can make use of the original script, but for the other handful of weirdos out there that use Arch as a server OS, this may help you. I've taken the time to test most aspects of the script and iron out bugs caused by the peculiarities between Debian and Arch. The README details much of the prerequisites, and the process involved in set-up.

As I have said, I got 98% of the way there before throwing in the towel, not 100%. I am confident that this script should get you most of the way there. It will not get you all of the way there, there will be debugging to be done, but it should make your set-up process substantially simpler than it would have been otherwise.

Is this a good idea to try?

Eh, maybe. Here's some criteria that may help you make up your mind on whether or not you should try it yourself, if you are interested.

You must be able to set up a PTR record (reverse DNS) to your e-mail host. You may need to negotiate it with your ISP, or your server provider. This also typically means you have a static IP. I suspect this was the stumbling block that made my set-up much more difficult, and without it your e-mail server will be much less useful (large providers will filter you).

You should meet more than half of these criteria:

Debugging is your friend

You will in all likelihood run into issues. Here's some good things to try:

Thoughts on the pros and cons of self-hosting mail

Privacy

Naturally, self-hosting will always be better from a privacy standpoint. The number of components you need to trust is smaller. Any other mail provider will be able to read your e-mails if they want to. Even if they offer server-side encryption in the event of a possible attack, this doesn't mean they can't decrypt it themselves.

Client-side encryption will to a degree somewhat level the playing field here. With client-side encryption, any mail you send is illegible to anyone par the sender and the recipient, provided your keys do not become compromised, no matter what e-mail provider you are using. Of course, if your e-mail provider has things like your real name, your phone number, and so on as part of registration, you are screwed anyway.

Security

This one will probably go to larger e-mail providers, rather than to small individual projects. Unless you really think you know security and administration better than teams of people serving thousands - if you do, I have no idea how you got here and why you're reading this. In most cases you will need to thoroughly educate yourself to be able to utilise a comparable level of security - although, it can be argued that a mail client serving a single individual or a few people is also a smaller and less enticing target for attacks.

Reliability

This could go either way. If you can guarantee the physical safety of your server, the lack of network traffic, you may find it to be more reliable and faster than a large provider. Or you may not. It really depends on your server, which you should know better than anyone.

Why have I left the e-mail server unfinished?

Mainly because it would not be worth it to me. As I mentioned, I cannot get a PTR record as I do not have a static IP address, so no reverse DNS lookups. This would make my e-mail less useful, as the e-mail I would send to large providers would be silently dropped and never reach their destination. I planned to finish this largely for the credibility in what I'm talking about. But, I decided to cut this short, because I'm beginning to build up a backlog of other things I'd like to do and things I would prefer to talk about.

My thoughts on some e-mail providers

If you've read all of the above, and would prefer to find a better, more privacy-respecting provider, but without going as far as making your own server, I have experience with some.

Cock.li

Their privacy policy is not bad, you can see for yourself. You can use your own clients. You can sign up via Tor (Cock.li additionally has a Tor address), there are no Captchas last I checked, no personal information is required, and there are no mandatory fees.

Note however that Cock.li is fairly honest about the fact that it's entirely possible to read your e-mails. They are transparent about this on their home page:

Cock.li doesn't parse your E-mail to provide you with targeted ads, nor does cock.li read E-mail contents unless it's for a legal court order. However, it is 100% possible for me to read E-mail, and IMAP/SMTP doesn't provide user-side/client-side encryption, so you're just going to have to take my word for it. Any encryption implementation would still technically allow me to read E-mail, too. This was true for Lavabit as well -- while your E-mail was stored encrypted (only if you were a paid member, which most people forget), E-mail could still technically be intercepted while being received / sent (SMTP), or while being read by your mail client (IMAP). For privacy, we recommend encrypting your E-mails using PGP using a mail client add-on like Enigmail, or downloading your mail locally with POP and regularly deleting your mail from our server.

With the lack of sign-up requirements and the ability to use your own clients - and when combined with use of client-side encryption - I find Cock.li works well for my use case. It sells itself as a joke service, but there are a few serious-sounding domains. People complain that it goes down, but in my experience that has been a number of times I could count on my hand in the last year, for a few hours at most.

Dismail.de

Dismail supports alternative mail clients, you may sign up with Tor without filling a Captcha, and it requires no personal information. The process of signing up requires you to respond to an automated message over XMPP, which in my experience I was waiting an hour or so.

Their terms of service do not sound ideal, and give the impression there are many ways in which you could be banned. One example is below:

sending of messages with the aim of harming or destroying, violate privacy, infringe the intellectual property, to issue statements offensive, fraudulent, obscene, racist, xenophobic, discriminatory, or any other form of content prohibited by law.

Why not Disroot/RiseUp/other privacy-respecting mail service?

As I said, I have tried many, and I found trying to apply to them impractical. RiseUp is an insider-invite-only service, and Disroot has a large list of potential offences you could fall under. Additionally, when signing up to Disroot, I was told to wait because it was the weekend. I came back during the week, and I was told to wait because it was the weekend. I try to balance maximising my privacy with ensuring actual practicality.

2020.11.07

2020.11.07Article Page

YouTube Ecosystem Wholly in a Terminal

There's a reason for which I sudden got really into RSS as a format. This all started when quite recently, the 'primary' web mirror for the software Invidious, was going down - that being, invidio.us (now hosts a list of other instances). Of course, this didn't mean the other instances would be going down, so I thought little of it. I preferred to use Invidious rather than the normal YouTube front-end, for various reasons related to internet privacy:

Alongside the fact that the default YouTube front-end is an unnecessarily bloated CPU-eater. I believe they have removed the legacy front-end now, though I've not checked in a long time.

Invidious was convenient, as rather than use a Google account for subscriptions - it is effectively just a GUI front-end for an RSS feed. It can also play videos without the need for JavaScript.

But Invidious has its own problems. Hosting tends to be highly unreliable. I can't tell how how easy or difficult it is to host an Invidious instance as I've never done it, but particularly in offshoot instances, they tend to break often and are generally unreliable, and sometimes inaccessible.

Returning to the Original Story

So, before long, invidio.us went 'down', as expected. But I noticed something strange begin to happen. As I used other instances instead, it seemed like they were breaking even more often. If that were true, it would be highly conspicuous - it would imply that in some way, these offshoot instances depended on the primary instance, and were now running into problems. That's quite troublesome design. Of course, I can't statistically prove that is true without taking a serious look at the codebase, which I don't plan to - it certainly could just be cognitive bias. But it got the ball rolling to make me begin to consider my alternatives.

YouTube offers an RSS feed to channels by default. You can in fact subscribe to YouTube channels in an RSS feed reader - this is exactly how Invidious works. There are RSS feed readers - such as newsboat - where you can read RSS feeds from a terminal. Put 2 and 2 together - I can see my YouTube subscriptions from the terminal.

So I went ahead with that

It all worked perfectly well. I added a few macros, which you can run via ",<key>" in newsboat, to do things such as - play audio, play video, download audio, download video, and open in Qutebrowser. You can see what I've done below:

macro v set browser "mpv --ytdl-format=22\/18 --ytdl %u" ; open-in-browser ; set browser "lynx %u"
macro V set browser "youtube-dl --add-metadata -f 22/18 %u" ; open-in-browser ; set browser "lynx %u"
macro a set browser "mpv --ytdl-format bestaudio --ytdl %u" ; open-in-browser ; set browser "lynx %u"
macro A set browser "youtube-dl --add-metadata -x --audio-format mp3 %u" ; open-in-browser ; set browser "lynx %u"
macro q set browser "qutebrowser %u" ; open-in-browser ; set browser "lynx %u"

This was great. And then I wanted to search for a song I didn't have a copy of, and didn't quite remember the name of. And then I thought, "Wait, how am I supposed to search?"

A TUI client for YouTube

The first thing I did, rather than reinvent the wheel, was to look to see what else others had done. But it was all pretty poor.

Generally they were written in Python. Almost all of the time they didn't work. The few that did 'work' packaged a bunch of other things I didn't need - like a video player, when I already had mpv. I just needed the ability to query.

And so, I wrote my own

The program, 'ytsearch', offers you this functionality in selecting queried videos:

Data showed in search queries:

Actions on selected videos:

Preferences which can be set as parameters or in a config file:

Beyond a standard GNU/Linux system with coreutils - this program depends on mpv, youtube-dl, and to a minor extent on xclip (which makes video sharing more convenient - no functionality is broken by editing it out).

At first, I tried to use the functionality packaged with youtube-dl - 'ytsearch' - which can be used to get one result, 5 (ytsearch5), or however many you can (ytsearchall). But I found this to be an extremely slow process, that was difficult to format and work with. I also think it is 'unfriendly' to YouTube, as it makes many video requests in formatting a single list of search results. This led to me getting banned very quickly.

So I pretty quickly ditched that idea. I couldn't curl YouTube either though - their results don't appear without JavaScript enabled. So, I settled for curling Invidious instances for links (their format is pretty universal across instances, I've not noticed any problems yet), and then passing those links to download/stream from YouTube itself. This method is much 'friendlier', and by far much faster to query - even for playlists with hundreds of videos (which are displayed in pages you can scroll through).

Drawbacks and Concessions

It has some drawbacks, of course. It is very scrappy scripting - this program evolved as I needed it to - and as such the code is an absolute shambles. It at least does work. Naturally, it's not even close to POSIX compliant, and depends heavily on Bash. I could likely have made a better program if I bothered learning ncurses, but I don't use YouTube often enough to justify that kind of effort.

It also only works as well as your Invidious instance works - if the instance has problems, so will the script. To mitigate this, I've made it very easy to test and change instances via parameters and config files. It reports reasonably well on what the issue could be if it fails to fetch videos.

Companion Programs

'ytsearch' has two companion programs - 'ytformat' and 'ytchannel'.

'ytformat' just takes links pointing to an Invidious instance, and makes them a YouTube link, if you are looking to share them as such. Fairly straightforward.

'ytchannel' is a fairly hacky script, that downloads and deletes a low-quality audio copy of a video, in order to get the YouTube channel it belongs to and to give you it in RSS feed compatible format. Thus, with the 3 programs, it is entirely possible to run the full YouTube 'ecosystem' from a terminal, and to never need to leave a terminal, and still have advanced search features and channel subscriptions.

Getting the Scripts

You can find all of the aforementioned scripts on my Git server, in a repository of their own, here. I hope they work for you. I'd also love to see - if anyone is interested in it - improvements to it, and probably written in something better than Bash.

2020.09.25

2020.09.25Article Page

My Bad ASCII Art

This is going to be another "I have nowhere else to dump these, so rather than lose them to the eventual abyss I may as well dump them here" post, but this edition comes with a shell script included at the back, so it may (or may not) be worth reading. I have little to show for myself at the moment (as of writing this - at Mon 31 Aug 2020 17:23) also, so it's probable this will be added to at some point in the future.

ASCII art involves the effort of creating images with just the 128 (7-bit - 2^7) range of characters as defined in the ASCII standard. Although, I think this does vary from country to country, and as time has gone on 'ASCII art' has become a looser and looser definition anyway. You may also see similar art made with Japanese characters, in places such as text boards and old 2chan - this is Shift_JIS art, referring to the Japanese Industrial Standards character set, and a fairly similar concept. I prefer Shift_JIS, but ASCII is much more universal among machines when not running a graphical interface.

ASCII art was more common in the past, where GUIs though present were hardly universal on operating systems. Particularly when internet browsing was done much more often on BBSes (Bulletin Board Systems) and Usenet groups, and using graphics to display a welcoming banner on a BBS or TUI newsreader would have not been possible, and wouldn't be for some time. I could also imagine someone dealing with Xorg in the late 90s on Linux just opting to stay in a TTY instead.

Creating ASCII art takes a level of time commitment and obsession (particularly for more substantial pieces) that is hardly reasonable, especially now that access to actual images is readily available, and "ASCII art converters" exist. Nonetheless, I'm the perfect type of weirdo to foster pointless obsessions. It's fun to fill my time with. You can use them in your /etc/issue or /etc/motd (before login - useful for showing system information, and after login, respectively). "motd" refers to "message of the day", a relic of system administrators giving their users messages in a more convenient format than via e-mail, for example, to declare rules, and is executed before the login shell. ASCII art can also be used in your system information fetch program of choice - I've written my own, I'll probably post it when I port it to C (it's a mess).

Anyway, enough chatter.

$ cat cat

 
        nn/|__/|
       / / o  -|       .--. 
______/ _\   w |_     / /\ \
XXXXX(___ `````\ \___/ /  \ \
      || \      ) )  _/____\ \
      ||  \____/ />_________uuu>
______||_______uuu______________

          |\
          | \__________
          |            |
          |  HEY BABY  |
          |            |
	  ^^^^^^^^^^^^^^
Download

A Meme-y MOTD

Download

Some Art to Lain your Non-graphical OS

I've also included some links to versions I can use in my fetch program. I think they are mostly neofetch-compatible, no promises.

/etc/issue

This shows the relevant system information on your login screen:

Download
Download for *fetch

/etc/motd

Download
Download for *fetch

As an aside mention, figlet is very useful for making a variety of stylised ASCII fonts, that I've made some use of here.

At last, the promised script

I recently made a script for the purpose of conveniently as possible making coloured art on a text terminal, without making any use of GUI. I say "conveniently as possible" for a reason, because it's hardly 'convenient', just more convenient.

I can't yet think of a smart way of writing coloured ASCII characters from the terminal, in any legible way. Just look at the "Awoo Systems Ltd" source, and you'll see what I mean. To make it convenient to write, in a way that you can see your work as you write it, would probably require a full-blown editor (completely possible, but beyond the scope of 'I was bored, so I made this' scripts).

I did however realise that the 8 "background" colours available in my TTY could be designated the numbers 0 to 7, and that they could act as coloured pixels to create simple sprites (I have a maximum of 50 rows and 160 columns to work with). The convenience of this method, is that you can see the shape of the image you are making as you write it. I have an example here.


You can download Erdrick below:

Download

And here's my script:

message () {
cat << EOF
colour:
-------
Colorise output based on numbers 1 - 7.
The output file can be displayed with cat.

usage: colours <inputfile>

0 - black
1 - red
2 - green
3 - yellow
4 - blue
5 - purple
6 - cyan
7 - white
EOF
}

[[ $# != 1 ]] && message && exit 1

in=$1
tmp=$(mktemp)
out="${1}.cout"
char=" "
count=0
max=7

find $out > /dev/null 2>&1; [[ $? == 0 ]] && read -p "Output file \"${out}\" already exists. Overwrite? [Y/n]: " write
[[ $write != "y" && $write != "Y" && -n $write ]] && echo Exit. && exit 0

cp $in $tmp
while [ $count -le $max ]; do
	sed -i "s/$count/^[[${count}m${char}/g" $tmp
	((count+=1))
done
count=0

while [ $count -le $max ]; do
	if [[ $count != 3 ]]; then
		sed -i "s/$count/;3${count}/g" $tmp
	fi
	((count+=1))
done
	
sed -i "s/3m/;33m/g" $tmp
sed -i "s/;/7;/g" $tmp
sed -i "s/m /m ^[[0m/g" $tmp
cp $tmp $out
rm $tmp
printf "^[[0m" >> $out
echo "./${out} created."

exit 0

You can get it here. I've recently made a Git repository for the shell scripts I mention on this site, and it's probably best to fetch them from there, as I'll change them often. Recently I had to change the ban script because I wasn't 100% confident in it. It's also because I got around to dealing with the fact that my code blocks look terrible on text-based browers, they're illegible - they look much better on my Git front-end. Hopefully both will look good from this article onwards. I use Lynx.

Anyway, that's it for now. Nixx out.

As of: Aug 31 2020 18:20


A few additions since I was last here

I enjoy this kind of thing. I made a few of my girlfriend too, but I'll keep those ones to myself - as much as it pains me to do so, as those ones I put by far the most effort into. Anyway, take some more.

Ed

Download

Lain

Download

Longcat - RIP

Download

Some random girl

Download

2021.04.12: I have a repo on my Git server for whenever I decide I feel like making more ASCII art, you should check it out.

2020.09.0X

2020.09.0XArticle Page

Why I Like Qutebrowser

I've used Qutebrowser for quite a long time now - get it here. This is going to be a post from the perspective of a fan, rather than for something I've worked on myself, so I've given it a new section of its own. Generally, I don't like to repeat myself, or to repeat what others have already said. That's the reason why, although there are plenty of programs I love to work with, I may not talk about them in great excess because the reasons I like them are much the same as those already stated by others elsewhere.

But I feel like Qutebrowser, as a web browser, is an extremely undersold program, and although its claim to fame (Vim-like keybindings) is for good reason, there's so much more to it that I've never heard nor seen anyone speak about. As someone that has had exposure to many over many years (including more obscure ones like Waterfox, IceCat, and Pale Moon - I still have a little fondness for the latter two), I couldn't imagine using anything else at this point. So, I thought I'd do some missionary work.

Firstly: Vim-like Keybindings

This is the main focus of anyone speaking about it, so I suppose I have to speak about it too. And it is a great feature, but, as aforementioned, just not all there is to this browser.

Why would someone want to use a browser structured like Vim?

There's the obvious speed benefit involved. This is the first thing that comes to mind for anyone approaching Qutebrowser for the first time. Having your movement keys as h, j, k, and l on the home row (presuming you use a QWERTY keyboard - if you don't e.g. DVORAK, you can absolutely change these settings) leads for far faster movements when you get used to it. Of course, there's nothing to stop you using the arrow keys, but that's for plebs, right?

Then, of course, you can use J and K to move between tabs, gl and gr to move tabs, and so on. Every action you can think of making on any standard, fully-featured web browser is available here, largely on the home row. But "you can do most things from the home row" massively undersells the 'point' of Vim, and likewise, of Qutebrowser.

Bulk actions and macros

This is where the power of Vim, and of Qutebrowser, actually begins to show. Naturally there are many more keybindings on Qutebrowser, but for the sake of example, I'll use the "gl" command from earlier - this moves your current tab one tab to the left in amidst the other tabs. But it can also be run as a bulk action - say you have 5 tabs open, and your highlighted tab is at position 5. You can run "g3l" and your tab moves to position 2, and the tabs from positions 2 to 4 move up by one. These bulk actions can be applied to most actions available, where doing it multiple times would make sense. To get a feeling for the amount of power this can give you in complex actions, take a look below:

Of course, you don't need to remember all of those, so don't feel intimidated. You'll quickly and naturally find yourself able to recall those that are of use to you often. But for these complex bulk actions, perhaps there's a very complex one particular to your exact use case, that's going to be hard to remember. Like Vim, this is where inbuilt macros come in.

These can be accessed within Qutebrowser's 'command line' with :record-macro, and :run-macro. More conveniently however, by default they can be reached with q and @, much like Vim. Press q to begin a macro, press a key to bind that macro to, and then you can make whatever action you want, however long and complex it is. Hit q again to finish recording. Then, play it again with @. These functionalities make Qutebrowser more powerful and convenient than any other browser. For your extremely weird, specific command, particular to you and only you, you can easily make it happen instantly with something like @k - two key presses.

Hints and Follow

A key component to how Qutebrowser functions as an almost entirely keyboard based browser (you can use clicks, if you really want to), are 'hints', and 'follow'. The 'f' key is used to follow links - because of course, the point of hypertext is to be able to quickly follow 'links', jumping from one information source to the next. But how does it cope, if there are, for example, 200 links on the screen? Do you just type 'f157' and are expected to know what link is 157th on page?

Contrary, the way Qutebrowser handles links is fairly intelligent - this is where 'hints' come in. Rather than '157', if the page has 9 links or less, they will be found on the home row - 'asdfghjkl'. So, you can type 'f s' to go to link 's'. If there are dozens, links may be designated with a second 'digit', for example you may type 'f jk'. If there are hundreds, a third 'digit' - 'f skl'. You never leave the home row (of course, you can again, change the default keys), and the enumeration of links never gets out of hand. But, how do you know which link is which?

Hints are an essential part of Qutebrowser's GUI. Upon typing 'f', you are in 'follow hint' mode. All links appearing within the window will appear by default with a highlighted letter, or letters, beside them. As you type, in the case of multiple letters, the hints appearing on screen will be narrowed down (e.g. upon typing 'f g' only links appearing as 'g*' will still be present). It makes following links easier than doing so by the mouse. I'll show an example below, of course, bearing in mind I've slightly configured the appearance of my Qutebrowser install:

Incidentally, I've actually altered some of the quirks on my website to work well with Qutebrowser. Browsing this site on Qutebrowser is a dream, it's great.

And of course, as an aside mention, Qutebrowser has history, tab-completion, and bookmarks, like any other good browser. It also has 'quickmarks', allowing you to bind a URL to a shorter term to 'o'pen more quickly. It also has a console, inspect element, and most things you would generally like to see.

Minimalist GUI saves space on your screen and your disk

Qutebrowser's minimalist GUI takes up very little real estate on your screen, which is another bonus, especially if like mine your screen is about 11 inches in size. Upon 'o'pening a URL, loading a quickmark, so on, Qutebrowser will open a completion window, which takes up half the screen - this takes the appearance of a simple list, and can be configured to be smaller - I prefer to keep it at about a third of the screen. Essentially, everything is only as complex as it needs to be, and is generally out of the way.

This has another benefit - that Qutebrowser is far more lightweight than many other browsers (even despite being Chromium based), and has a small install size (if you forgive the dependencies on Qt4 and Python - which you probably already have installed for something else anyway). Let me show you:

~ $ pacman -Qi firefox | grep 'Installed Size'
Installed Size  : 205.47 MiB
~ $ pacman -Qi chromium | grep 'Installed Size'
Installed Size  : 201.36 MiB
~ $ pacman -Qi qutebrowser | grep 'Installed Size'
Installed Size  : 7.58 MiB

That is such a stark difference I wouldn't blame you if you didn't believe me at first. And despite its small size, if you want JavaScript, WebRTC, and whatever else supported, it's there.

Configurability

Another great point of Qutebrowser, whether you're some kind of 'ricer' or just extremely particular, is its configurability - there are almost definitely more options to configure the look, feel, and keyboard interaction with Qutebrowser than you could ever possibly need. There are a variety of places it can be set.

'ss'

Type 'ss' and you will immediately open the :set command at the prompt, and you'll be given a well thought-out and organised alphabetical list of everything you can change within Qutebrowser. Start typing, and you can narrow it down into sections and further subsections. When you've tab-completed or moved to an option, e.g. "colors.completion.fg", it will bring up a prompt to enter a new value, including listing its default value to switch back to. The best part about this is that everything changes instantaneously at runtime, and you can see the effects of your changes immediately.

qute://settings/

This includes a GUI menu in plain HTML of all of the settings listed above, to effect changes. I consider it inferior to the above method, but it's there if you want it, or just to get a feel for how huge your list of options are.

autoconfig.yml and config.py

Somewhere on your machine, Qutebrowser will have a configuration file, controlled by the GUI setting editor. This is called autoconfig.yml, and for me it can be found under .config/qutebrowser/ under my $HOME. Additionally however, you can overwrite these settings by creating a file in that directory, called 'config.py'. Importantly, make sure to run the function config.load_autoconfig() on the first line, otherwise it will not load the defaults as set in autoconfig.yml, and will just overwrite all of them.

The settings you change in the GUI are already permanent thanks to autoconfig.yml - so that isn't really the purpose of config.py. There is something it is incredibly useful for, however - scripting. The contents of config.py can be controlled by various scripts, to achieve different functionalities. And by running :config-source, you can see your changes take effect immediately.

To give some examples, I have two main scripts handling config.py for me. One sets 'browser modes'. Say for example, I want to have my browser completely locked down - proxy over Tor, no JS, no WebRTC, no nothing. I can do that immediately, by the script writing to config.py, and sourcing config.py. And the same script can go and revert all those changes again, instantly. Much less arduous than writing out dozens of lines for different settings. And for the ricers, I have another script handling colour schemes - it can read from .Xresources, and change the colours of various GUI elements to match, as just one example.

Qutebrowser also sets a variety of helpful environment variables for use in userscripts (generally found in $HOME/.local/share/qutebrowser/userscripts, and made executable), such as writing commands straight to Qutebrowser's FIFO (the completion prompt), parsing the HTML page, the current URL, the URL selected via 'hints', and so on.

Long story short - the thing I appreciate most about Qutebrowser isn't the Vim keybindings - it's scripting.

Privacy - Pros and Cons

Because Qutebrowser isn't a direct copy of one of the "big two" - Chrome and Firefox - it is lacking in a component for add-ons. It also doesn't have the graphical components necessary to display add-ons which are based on menus. For many people that use a variety of privacy enhancing add-ons, this is a downgrade, an inconvenience. Although you can implement some of the same functions via userscripts, it's going to be less convenient to do so. It's something to be aware of going into this browser. Let's talk about some of the positives again now.

Ad-blocking

You may be under the impression that without add-ons, Qutebrowser can't block ads - in fact, ad-blocking is inbuilt, regularly updated, and uses an /etc/hosts style format - which runs much quicker than a standard bloated ad-blocker. I have not once seen an ad while using this browser. Just run :adblock-update.

Selectively disabling JavaScript

JS can be handled on a host-by-host basis, thanks to config.py. If you would like to keep it off as a general default, but need it in a few select places, you can add URLs to your config.py like so:

config.set('content.javascript.enabled', True, '*://jisho.org/*')
Be sure to turn off JavaScript on my website ;3c (I have none).

Handling WebRTC

By default, WebRTC works the same as it does in any browser. If you'd rather you didn't leak your IP address over Tor or a VPN though, completely neutering it is a fairly straightforward process.

The below can be set in the GUI (via 'qt.args' and 'content.webrtc...'), or alternatively in config.py like so:

c.qt.args = ["force-webrtc-ip-handling-policy=disable_non_proxied_udp"]
c.content.webrtc_ip_handling_policy = 'disable-non-proxied-udp'

Proxying over Tor via SOCKS

I mentioned earlier I use Qutebrowser over Tor, this is also a surprisingly straightforward process, built-into the functionality of the browser. All you need to do is :set content.proxy.

Integrating hints with scripting

As I've mentioned both hints and scripting earlier, another useful thing to mention is that both can be integrated. These most famous example being 'hint links spawn mpv --ytdl {hint-url}' - this goes into 'follow hint' mode, and spawns mpv with the value of the URL you choose in follow mode (the only real way to watch videos). Likewise, you can simply use 'spawn mpv --ytdl {url}' to spawn mpv for the current page without going into follow mode. This has far more uses beyond just mpv however - you can bind your own scripts in your $PATH, with :bindings-commands, to pass URLs to your own scripts.

Perhaps you want to keep a list of certain URLs and add to it in a convenient way without copying URLs and going back and forth between a text file. Or you're on an onion mirror (as I often am), and would like to paste a link to someone not using Tor - pass it to the script, format the URL to it's clearnet mirror, and xclip output. For a great range of use cases, you can integrate following hints with your own scripts, while only using a few key presses and never leaving Qutebrowser.

And done

Another long rambling article. In short: I like Qutebrowser because it's highly configurable, and highly scriptable. Vim keybindings are just a bonus. For a better reference of information, go to the source, here. Hope you enjoyed whatever this was.

2020.09.02

2020.09.02Article Page
Search All Posts
1 2 Next

Part of the Lainchan Webring.


Visit a random site:
ClearnetOnion

Send me something interesting: nixx@firemail.cc