💾 Archived View for ebc.li › atom.xml captured on 2022-01-08 at 14:08:10.
View Raw
More Information
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
<id>gemini://ebc.li/</id>
<title>Ecmel Berk Canlıer</title>
<link href="gemini://ebc.li/atom.xml" rel="self"/>
<icon>/favicon.ico</icon>
<rights>Ecmel Berk Canlıer · CC BY-SA 4.0</rights>
<updated>2021-11-23T00:51:39.819838+03:00</updated>
<author>
<name>Ecmel Berk Canlıer</name>
<email>me@ecmelberk.com</email>
</author>
<!-- all time data in this feed are accurate up to date and timezone only, sorry! -->
<entry>
<id>gemini://ebc.li/posts/tired-of-tweaking.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/tired-of-tweaking.gmi"/>
<updated>2021-06-16T00:00:00.000000+03:00</updated>
<title>I am tired of tweaking stuff</title>
<content type="text"># I am tired of tweaking stuff
2021-06-16
I recently re-formatted my system and installed Fedora on it, instead of my usual Arch Linux configuration. Why? Because when I tried Arch, I realized one thing: I no longer have the energy to tweak stuff. I just want my things to work...
I no longer, for example, watch YouTube through MPV (with subscriptions through Nextcloud News). I use the website, because it just works and is convenient.
Recently, I've been thinking of shutting down just about every service I host (except for XMPP which my family relies on and is mostly fire and forget for now, and maybe Nextcloud), maybe replacing them with "more convenient" alternatives. Of course, I won't stop selfhosting entirely, because there are stuff that are both convenient and selfhosting friendly, but I want my stuff to just work now.
That most likely includes this Gemini log thingy too, so if my blog suddenly dissapears, I hope nobody will be left confused.
Maybe I'll set up something like "write freely" and write there, if at all.
=> https://writefreely.org/ write freely
Or I could jump into one of those tildes and do stuff there, but I don't know if that would be easier than just doing stuff on my own server.
Writing this, I realized I don't host many things _anyway_, so I wouldn't lose much if I stopped them all. Maybe I'd lose some old code I no longer care about from Gitea, but that's it, really...
Still not sure on what I should do, or even if I should do anything.</content></entry>
<entry>
<id>gemini://ebc.li/posts/gitserv.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/gitserv.gmi"/>
<updated>2021-05-23T00:00:00.000000+03:00</updated>
<title>gitserv - A simple GitHub Pages-like thing, but selfhosted</title>
<content type="text"># gitserv - A simple GitHub Pages-like thing, but selfhosted
2021-05-23
gitserv is a small Go program that serves the contents of a Git repository (including bare repositories) as a static web site.
The bare repositories part is kinda important considering most Git servers (that I am aware of) drop bare repositories into your drives, instead of non-bare repositories most people are used to. Otherwise you could just point Nginx or something into a folder and call it a day.
I mostly made this for my own use, but decided to release it onto the world as well just in case it gets used by other people too. Check it out if it sounds interesting.
=> https://sr.ht/~admicos/gitserv
(Also, the HTTP version of my site now runs this. Thought it might be interesting to know)
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/wiki/ffmpeg-incantations.gmi</id>
<link rel="alternate" href="gemini://ebc.li/wiki/ffmpeg-incantations.gmi"/>
<updated>2021-05-17T00:00:00.000000+03:00</updated>
<title>FFMPEG incantations I used to do stuff</title>
<content type="text"># FFMPEG incantations I used to do stuff
2021-05-17
This page will be an ever-updating list of FFMPEG incantations I used to do, well, anything involving FFMPEG.
If you have any improvements to these, please let me know.
## Convert 4K video to 720p30
ffmpeg -i input.mp4 -vf "scale=iw/3:ih/3,fps=fps=30" output.mp4
## Convert 4K (non-HEVC) video to 720p30 (HEVC):
ffmpeg -i input.mp4 -vf "scale=iw/3:ih/3,fps=fps=30" -c:v libx265 -vtag hvc1 output.mp4
## Convert video to HEVC:
ffmpeg -i input.mp4 -c:v libx265 -vtag hvc1 output.mp4
Last updated: 2021-05-17
🐺 · CC BY-SA 4.0 · me@ecmelberk.com</content></entry>
<entry>
<id>gemini://ebc.li/joke/stop-scaling-up.gmi</id>
<link rel="alternate" href="gemini://ebc.li/joke/stop-scaling-up.gmi"/>
<updated>2021-05-04T00:00:00.000000+03:00</updated>
<title>STOP SCALING UP</title>
<content type="text"># STOP SCALING UP
2021-05-04
Software are not supposed to scale
YEARS of scaling yet NO real world use found for scaling more than YOUR FAMILY
Wanted to scale more anyway for a laugh? We had a tool for that: It was called "EVERYONE HAVING THEIR OWN SERVERS"
> Yes, please give me 5 Kubernetes Docker Container Pods
> Please replicate my database cluster
Statements dreamed up by the utterly deranged
docker swarm init --advertise-addr 192.168.99.100
docker swarm join --token blablablablablab 192.168.99.100:2377
docker service create --replicas 1 --name helloworld alpine whoami
I would've put Kubernetes things here but holy shit it's too complicated for me to skim through I'd rather not thank you
> Hello I would like to create 10 new VMs with the exact same configuration only for 10 minutes please
They have played us for absolute fools!
🐺 · CC BY-SA 4.0 · me@ecmelberk.com</content></entry>
<entry>
<id>gemini://ebc.li/posts/perfect-is-the-enemy.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/perfect-is-the-enemy.gmi"/>
<updated>2021-05-02T00:00:00.000000+03:00</updated>
<title>Perfect is the enemy of good</title>
<content type="text"># Perfect is the enemy of good
2021-05-02
If you haven't noticed, Moonlander has not had a new commit in 2 weeks. That's because I was working on something else that I am temporarily calling "Valalander", a "re-write" of Moonlander in Vala.
=> https://git.sr.ht/~admicos/moonlander Moonlander
=> https://git.ebc.li/experiments/valalander/ Valalander
Even that is, however, very slowly developed.
Why?
Because I wanted it to be perfect.
Obviously, no software can be perfect. All software is buggy, yada yada, but Moonlander has some very obvious bugs that I did not want to introduce again.
For example, you cannot scroll if your cursor is over to the side of the text, or you can't CTRL+A a page and have the entire page copied (code blocks will not be copied)
More importantly, it is not accessible to screen readers or similar software.
How would one fix these? Well, I think I have three ways of solving these problems:
## Approach 1: Give up and use a web view
This is the easy way out, and is the current approach Valalander takes, though I am still thinking about possibly changing it.
The downsides of a web view is obvious. A huge behemoth of code that does way more than you'll ever need and eats resources like there's no tomorrow.
(WebKit actually doesn't seem to eat all that much so far, but I wish it was, like, NetSurf or something. Do they even have an embeddable GTK widget? I wish!)
The upsides are that, well, it'll probably work, though my current implementation is a bit off as I haven't grasped WebKit2GTK's API yet and am only using it as a dumb HTML viewer.
## Approach 2: Give up on GTK, render and manage things myself
Remember what happened to the original Moonlander? Yeah. I don't think I can manage doing this anytime soon.
It's just a whole bunch of work to re-write literally everything and even then it won't feel as native and as polished as the rest of the UI, so why even bother?
Also, this will most likely make everything _worse_ as I am sure GTK devs have thought a lot more about how things interact than I'd have.
## Approach 3: Give up on caring about all this
I could just stop caring, and put everything in a vertical box and call it a day. This will totally screw up some stuff like text selection, (you won't be able to select more than one paragraph at a time!) but it should be reasonably accessible (assuming Gtk's TextViews are accessible in the first place, they might not be) and reasonably clean in terms of implementation.
## So What?
I don't know what I should do. All approaches have their drawbacks, and while the current Moonlander's approach is just about enough for me, It's not for everyone (for example: anyone who needs accessibility software), and that's not good, and definitely not perfect, in my opinion.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/why-not-automate-systems.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/why-not-automate-systems.gmi"/>
<updated>2021-04-28T00:00:00.000000+03:00</updated>
<title>Why I do not automate setting up my systems</title>
<content type="text"># Why I do not automate setting up my systems
2021-04-28
## I want to try stuff quickly
I want to spend as little as effort as possible, so I can get on with using the thing, instead of configuring and debugging for a day straight beforehand.
## Some software will not want to cooperate
No matter how great your tools are, some software will just not cooperate. And trying to work around that is not fun.
When I tried automating my server previously, I had times where I just gave up and wrote what I did in a separate file to "read later on". I never did, because...
## I frequently start from scratch
I have this thing of very frequently re-formatting and starting from scratch on a lot of my machines. I don't think I had an OS install that went for more than a year since, like, 2015.
And if I start from scratch for basically everything already, why would I _need_ automation?
## So, what do I do?
### Servers
Currently, I use hand-crafted docker-compose files, written directly over SSH, without any meaningful version control (or anything similar).
docker-compose manages to have the right amount of "declarative configuration" vs "quickly getting things working", especially if the thing I am looking to install already has a Docker image ready.
If the thing doesn't have a Docker image, I'll first fall back to distro packages and creating Docker images using those. Building from source is the last thing I'll try, because for most things it's not that fun to debug.
### PCs
I copy paste parts of my configuration from old dotfiles repositories manually. This also helps me get rid of the "cruft" that accumulates of old and unused software.
## Ending
So, do you know of a tool that might be able to work better with how I do things? Do reach out if you do. This kind of automation / infrastructure as code / whatever you call it thing is still a neat topic to me and I still want to learn more even if I might not use it right now.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/shell-is-not-good-automation.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/shell-is-not-good-automation.gmi"/>
<updated>2021-04-23T00:00:00.000000+03:00</updated>
<title>The Linux shell is not a good automation platform</title>
<content type="text"># The Linux shell is not a good automation platform
2021-04-23
If I had the ability to focus on one thing for a long time without giving up, I would make a Linux automation thing. Because the shell isn't enough for any modern workflow.
## The End Goal: Tasker
Now, through this post I will be talking about an Android app named Tasker. If you are fine with proprietary software on your phone, this is the one app you should have. Seriously. Go buy it right now. I bought it twice and do not regret it one bit.
=> https://tasker.joaoapps.com/ Tasker
Tasker is what I would consider the correct way to do automation. It's powerful, but not obscure. It's integrated well, has a great plug-in ecosystem and a great community (which is kinda important for things like this), and even though it's paid, it's not corporate (ahem ahem IFTTT). The only thing making me not rely on it every single day is that it's Android only, and I mainly use a desktop Linux computer for my day-to-day tasks.
## Shell is not discoverable
Let's say I want to do something when I copy something. How would you do this via the Linux shell, or anything like it? I don't know, it would require me to search the internet for a while. And I use Wayland, so I'd need to search even more. I might even need to write code that's more than just the automation glue.
Anyway, how would I do the above thing with Tasker? Keep in mind, I have no idea and will now go try it myself as I write this:
Add > Event > Variable Set > %CLIP (which has a friendly name on the variable dropdown)
Done. I just explained it in a single line, whereas on Linux I have no idea what I'd need to do. Maybe wl-paste? But that's Wayland only, what if I switched to X.org? And do I need to run them in a loop? Is there an event-based way? Do I need to download an obscure CLI utility from someone's GitHub last updated in 2016? I have no idea.
And I can't just go through browsing what options I have. I have to have a project in mind before searching what I can do, instead of browsing through and going "I could make use of this feature".
## Shell is not integrated well
Unless you 100% use command line utilities, it isn't. How easy is it to click on a button in a GUI through the shell? Or type into a specific text field?
While Tasker doesn't have it built-in, the AutoInput plug-in (made by the same developer) allows you to interact with the UI (ab)using the accessibility APIs of Android. Why don't we have an equivalent for Linux? Why can't I go "$ clickbutton Back" or whatever and just let the accessibility APIs take care of finding the position of the button and whatever for me. It's not that hard, is it?
A bonus would be that if a program is accessible, it can be automated, which is a nice thing to get for basically free. WHY AREN'T WE WORKING ON THIS?
## Shell doesn't put all my automation in a single place
Where are my custom key bindings? They're on Sway's config.
Where are my custom commands? They're on ~/bin
Where are my hypothetical mouse gestures? Probably on some mouse gesture specific thing (which ALSO DOESN'T SEEM TO EXIST PROPERLY)
Where are my hypothetical application-specific tweaks?
- Are they hooks the application itself provides?
- Are they on the application's own scripting language?
- Do they just don't exist because the application wasn't designed with automation in mind and you can't do anything about it?
Compare this to Tasker, where everything is inside the Tasker app, organized and categorized nicely. I do not have to leave Tasker to do any automation. Maybe for Termux for the really rare cases I need to do something via SSH or integrate with youtube-dl.
## End
So yeah. That's it. If anybody is interested in making this a reality, please reach out, I'd be interested in trying it out.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/xmpp.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/xmpp.gmi"/>
<updated>2021-04-10T00:00:00.000000+03:00</updated>
<title>First thoughts on XMPP from someone who has no idea what he's doing</title>
<content type="text"># First thoughts on XMPP from someone who has no idea what he's doing
2021-04-10
So, thanks to Signal's recent venture with a random cryptocurrency, which I really don't want to get involved with, I decided to set up an XMPP server for me and my family.
Why XMPP? Well, I wanted to try it out, and a lot of people were mentioning it as an alternative.
Do I regret it? No! (Or at least, not just yet)
## The server setup
I used Prosody as my server of choice, mostly because I heard about it in passing every now and then and the name seems to have stuck on me.
It was packaged on Alpine's repos, so a simple "apk add" and done! It was time to configure it!
Now, I just blindly dove into Prosody's docs, only taking a few peeks at other guides on some random parts, but after a couple hours, I managed to get something up and running, which got around 60% on Conversations' compliance tester.
=> https://prosody.im/ Prosody
=> https://compliance.conversations.im/ Conversations' compliance tester
Just a few hours ago, I got the server to 90%, with the only missing pieces being TURN/STUN, which I am not entirely sure if I need just yet. And it was pretty darn easy to do so! Thanks, Prosody!
### The server resource usage
It's pretty darn light! Even lighter than my instance of Gitea so far, which seems to have a memory leak or something because it's eating ~400MBs of RAM. Prosody? 15MB.
Fifteen. Megabytes.
If you're coming from Matrix and Synapse (which was my previous selfhosted chat adventure), this is LIGHT!
## User experience for your parents
My main use for Signal was to talk with my parents, and if they can't use XMPP, I have no use for it either. So it was nice to see that, with some guidance on the registration process, they had no problems setting it up!
I told them to install the Blabber.im fork of Conversations on the Play Store, as they don't have F-Droid and I don't expect them to pay for it on the Play Store any time soon.
=> https://blabber.im/en/ Blabber.im
The UI is similar, not the same, but not totally different either, which helps for troubleshooting.
The Turkish translation (my native language) is missing in some small areas, which I plan to improve if executive dysfunction doesn't get the best of me, but it's pretty well so far.
### Registration
Because my server doesn't have registrations enabled, I couldn't just tell them to "go register". Instead, I created accounts with temporary passwords and showed them how to change them. This part was a bit handholdy, but I managed to do it over Signal without being face-to-face, so it must've been "friendly" enough that they didn't just tell me to just "do it myself".
Since this is supposed to be done only once, I don't think this is that big of a deal for my use case.
### Usage
The day to day usage seems to be fine. They don't seem to have any problems with messaging me over XMPP.
Messaging them on the other hand was a bit of an hassle initially, as they use Huawei phones, and the horrendous battery saving features mean that the phone kills background apps left right and center, which causes issues with notifications and has to be turned off manually, and even then I am not entirely sure if notifications work for them a hundred percent. (AFAIK Blabber doesn't use FCM, which means it must check for messages manually)
Aside from notifications, it works well! Uploading images and text messages work, both of which are the most common things we do.
I haven't tried voice calls, and I suspect they won't work because I don't have STUN/TURN set up just yet, but we mostly use regular phone calls, so that's not that big of a deal.
Everything is OMEMO encrypted, which is barely noticeable aside from maybe a few multi-client papercuts regarding uploads, but only I do multi-client (phone and computer) so I think I can live with that.
## Finale, and a question
So, in short, XMPP is good enough for my use cases, with a few papercuts that can probably be solved with some effort from client and server devs, and I hope I will be able to remove Signal from my phone in a week or so!
My XMPP migration is not done just yet. I still have to find an iPhone client for a relative, and as I don't have any Apple stuff on hand, I don't know how the clients work there.
So, if anyone here knows of a good iPhone XMPP client for someone who isn't a tech person and has better things to do than deal with clunky software, or if anyone here is an XMPP guru who can tell me any issues I should expect when using XMPP day to day: Do reach out! My contact information is on this site's homepage.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/moonlander_devlog/three.gmi</id>
<link rel="alternate" href="gemini://ebc.li/moonlander_devlog/three.gmi"/>
<updated>2021-04-04T00:00:00.000000+03:00</updated>
<title>Moonlander Dev Log #3: March 29 to April 4</title>
<content type="text"># Moonlander Dev Log #3: March 29 to April 4
2021-04-04
=> two.gmi See Previous Entry
Welcome to the third Moonlander Dev Log! In here I'll try to quickly go over whatever I've done from March 29 to April 4, 2021. There hasn't been that many changes, yet again. ¯\_(ツ)_/¯
Here is a list, in somewhat chronological order:
## Middle click to close tabs
You can now middle click on tab titles to close them. Not much else to say.
## "Go Up" button
There is now a "Go Up" button that will take you one directory above your current URL.
It's particularly useful if the capsule you're viewing has it's URLs structured in a nice way and the server has directory indexes enabled.
=> /images/moonlander-devlog-three/go-up.png Screenshot [3K PNG Image]
## Mouse side buttons
Mouse side buttons now work for back/forward navigation in Gemtext files though. Other file types soon™.
## about:moonlander
There is now an "about:moonlander" page, which is the new default home page of Moonlander. It presents some very basic information, and links to some helpful places to get you started.
The configuration file documentation is available under about:configuration, which is linked on the new homepage.
Your existing configuration will not change.
=> /images/moonlander-devlog-three/about-moonlander.png Screenshot [28K PNG Image]
## Empty line spacing
You can now set the height of the empty lines on Gemtext files.
=> /images/moonlander-devlog-three/line-spacing.png Screenshot [30K PNG Image]
## End
And that's the last week. To follow what I'm doing in real time, follow me on Mastodon, where, aside from almost real-time Moonlander dev updates, I sometimes complain about software I can't bother to (re)make myself.
=> https://mastodon.social/@admicos @admicos@mastodon.social [HTTPS]
And if you aren't using Moonlander yet, you know what to do:
=> https://sr.ht/~admicos/moonlander
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/moonlander_devlog/two.gmi</id>
<link rel="alternate" href="gemini://ebc.li/moonlander_devlog/two.gmi"/>
<updated>2021-03-29T00:00:00.000000+03:00</updated>
<title>Moonlander Dev Log #2: March 22 to 29</title>
<content type="text"># Moonlander Dev Log #2: March 22 to 29
2021-03-29
=> one.gmi See Previous Entry
Welcome to the second Moonlander Dev Log! In here I'll try to quickly go over whatever I've done from March 22 to March 29, 2021. This one is a bit late, but it's just that the "low-hanging fruit" is done, and the things now are a bit harder, or that I don't have much use for them personally, or that I just got lazier. Not entirely sure.
Here is a list, in somewhat chronological order:
## Proper charset support
Gemtext and plaintext files now support decoding charsets/encodings other than UTF-8. I am still not quite sure on my implementation of this, but it seems to work fine enough.
=> /images/moonlander-devlog-two/encoding.png Screenshot [12K PNG Image]
## Download confirmation
You can now prevent downloads from starting. Before this, they just started going when the tab loaded, and closing the tab would crash Moonlander.
## File downloads for everything
There isn't any UI for this yet, but you can now download everything, including things Moonlander can natively view, by changing gemini:// in the URL with download+gemini://.
Moonlander will automatically attempt downloading things it cannot render. This is mostly for the things it can. (Images, for example)
=> /images/moonlander-devlog-two/downloads.png Screenshot [12K PNG Image]
## View source
You can now right click on Gemtext files to view their source. This forces Moonlander into it's plaintext mode when rendering this page.
=> /images/moonlander-devlog-two/view-source.png Screenshot [7K PNG Image]
## Removed unintended extra spacing
The spacing between paragraphs weren't intended to be that large, as Moonlander accidentally put an extra newline after every paragraph. Sorry to anyone who got used to it!
## Client certificates (well, sort of)
Moonlander now supports use of client certificates. This has no UI and requires you to create certificates manually, but it seems to work, and that's what matters at the end of the day, right?
=> /images/moonlander-devlog-two/certificate.png Screenshot [24K PNG Image]
## max_width Can now be disabled
You can now disable max_width and make pages full width if you wish to. The new default configuration makes plaintext files full width, though your existing configuration won't change.
=> /images/moonlander-devlog-two/fullwidth.png Screenshot [51K PNG Image]
## Loading progress indicator
There is now a small progress indicator under the URL bar so you can tell where exactly your request is stuck due to your crappy ISP.
=> /images/moonlander-devlog-two/progress.png Screenshot [5K PNG Image]
## End
And that's the last week. To follow what I'm doing in real time, follow me on Mastodon, where, aside from almost real-time Moonlander dev updates, I have achieved peak lazy by automating a singular light bulb.
=> https://mastodon.social/@admicos @admicos@mastodon.social [HTTPS]
And if you aren't using Moonlander yet, you know what to do:
=> https://sr.ht/~admicos/moonlander
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/moonlander_devlog/one.gmi</id>
<link rel="alternate" href="gemini://ebc.li/moonlander_devlog/one.gmi"/>
<updated>2021-03-22T00:00:00.000000+03:00</updated>
<title>Moonlander Dev Log #1: March 20 to 22</title>
<content type="text"># Moonlander Dev Log #1: March 20 to 22
2021-03-22
Welcome to the first (and hopefully not the only) Moonlander Dev Log! In here I'll try to quickly go over whatever I've done from March 20 to March 22, 2021. Two days might seem like a short time, but I haven't had the time to get bored of Moonlander yet, so there's a lot in here.
Here is a list, in somewhat chronological order:
## Full-Width tabs
This is an early addition, and is default, so your version of Moonlander probably has it already enabled. (You *do* use Moonlander, right?)
This was actually mostly made because I couldn't make the close button with "regular" tabs aligned to the right properly. Try disabling it if you want, it's in the config file.
## Gemini input support
These are the 1x status codes your search engines and whatnot use to ask you for input. Unlike most clients that pop up a dialog, Moonlander instead uses the entire tab view to ask for input, which is mostly because it makes better sense with the internal architecture of the application, but I will claim any usability benefits it has to smart thinking so yeah.
=> /images/moonlander-devlog-one/input.png Screenshot [7 KB PNG Image]
## Tests
This isn't a user visible change, but some components of Moonlander are now automatically tested for each build. Currently, it's the Gemtext parser, Gemini protocol header parser, and the TLS trust-on-first-use implementation, mostly because they were the easiest to do so.
I will not claim these tests (and there are not much) are effective at preventing bugs (though one bug on the Gemtext parser did get fixed while making tests), but they are there, and that's what matters, right?
## UI Logic Rewrite
Here's the thing. Up until now, Moonlander's UI was driven mostly by two files with a combined line count of 900-ish lines, and was barely maintainable. If you ever saw a "moonlander+error:..." URL while using Moonlander, that was one of the reasons why.
This was a risky move that, in my opinion, has already paid off. What I did here was, I disabled the existing code, and just created a new UI, peeking and occasionally copying parts from the older one.
Obviously, doing this has resulted in me not implementing some important parts that are still getting added and there might even be issues I just forgot about (throw some unimplemented!()s and todo!()s and call it a day)
This is why, on the README, there is a link to an older build letting people know that "Hey, if something isn't working now, check this one. If it works there then tell me about it!"
Oh also -- This was another "invisible" change. I changed the logic behind the UI, but the UI itself has stayed the same. Might be confusing, but whatever.
## Styling links by their URL schemes
It might get confusing clicking on a link to see nothing happen (since it loaded in your web browser as it was a HTTP link). To prevent this, I implemented a way to style URLs by their schemes.
The default config has some schemes colored differently, but if you ran Moonlander before this change, your config will NOT be updated to reflect this. Either remove your config and let Moonlander re-generate it, or set them up manually.
Unfortunately, the current implementation relies on a hard-coded list of schemes. Currently, these are "http", "https", "gemini", "gopher". Adding more is mostly a single line change so don't hesitate to yell at me if people actually link to other stuff too.
=> /images/moonlander-devlog-one/link-styling.png Screenshot [31 KB PNG Image]
=> https://git.sr.ht/~admicos/moonlander/tree/HEAD/docs/config.md Moonlander Configuration Documentation [HTTPS]
## Image viewing
Moonlander can now view images! Currently this is limited to full-size images and you have to scroll around to see them in their entirety, but it's better than what it did before, which was to just crash.
I don't have a good screenshot for this, so you'll just have to try it out yourself.
## File downloads (for some file formats)
Moonlander will automatically start downloading files (in memory) if it can't view them. You can either choose to save to an actual file, or close the tab if you don't want to. (Assuming it doesn't crash, I really haven't tested that part)
This is a bit weird to use when coming from just about everything else, but Moonlander currently cannot "decline" any download. Which probably isn't that great but whatever.
Eventually, I'd like to have an option to download every link, but it's just not there yet.
=> /images/moonlander-devlog-one/downloads.png Screenshot [11 KB PNG Image]
## End
And that's the last two days. To follow what I'm doing in real time, follow me on Mastodon, where I've spammed Moonlander dev updates so much I am surprised how people keep following me still...
=> https://mastodon.social/@admicos @admicos@mastodon.social [HTTPS]
And if you aren't using Moonlander yet, you know what to do:
=> https://sr.ht/~admicos/moonlander
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/moonlander-is-back.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/moonlander-is-back.gmi"/>
<updated>2021-03-20T00:00:00.000000+03:00</updated>
<title>"Not that hard, apparently" - Moonlander is back (as an alpha release)</title>
<content type="text"># "Not that hard, apparently" - Moonlander is back (as an alpha release)
2021-03-20
I am glad to announce that Moonlander is back!
Well, it's not _the_ Moonlander, but rather a rewritten version carrying the same name.
Well, it's not "back" as in "proper 1.0 release without any known issues", but it's _mostly_ there.
## So... What happened?
=> /posts/how-hard-can-it-be.gmi On my previous post about Moonlander, (which you should check out if the title confused you,) I said the following:
> If I decide to work on Moonlander though, I will most likely switch to using OS widgets like everyone else. The canvas renderer approach is too much work for little gain, and I am pretty sure I could pull off the fancy-ness of Moonrender with some hacks on top of OS widgets.
Well, I did _just that_. The new Moonlander is entirely GTK 3, without any custom
drawing done whatsoever.
=> /images/moonlander-is-back/moonlander.png And I think I did a pretty good job [41K PNG Image]
(Ironically enough, Moonlander as the time of writing cannot open images)
The new Moonlander can now, compared to the older one, do more:
- It has actual interactivity (select and copy text)
- Tabbed browsing support
- A bookmarks bar
- Proper¹ trust-on-first-use support
- Can deal with TLS v1 certificates some servers (including mine) still use for some reason
- Shows alt text for preformatted blocks and can collapse them entirely
- Can be configured as your default gemini:// handler
There are a few more things planned which you can read about on the README file, but they aren't implemented yet so I am not going to list them for now.
## Where do I get it?
=> https://sr.ht/~admicos/moonlander/#downloads Download instructions for Linux binaries. [HTTP, sourcehut repository].
Currently, Moonlander is Linux-only, though it can *theoretically* run on Windows if someone were to set up a build environment with GTK. There are some pointers in the README to some documentation, but I most likely won't be providing Windows binaries any time soon.
Also, while on the "alpha" stage, every commit will be built as a binary as the codebase is moving too fast to version properly. When things slow down, I'll most likely promote it to beta and start versioning properly.
## Footnotes
¹: There are a few parts I am not completely sure on, but compared to the old Moonlander that just accepted *everything* I think this is an improvement.
=> https://mastodon.social/@admicos/105900350356161202 If you do happend to know how TLS works, maybe help out? [HTTP, Mastodon]
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/rambling/alternative-web.gmi</id>
<link rel="alternate" href="gemini://ebc.li/rambling/alternative-web.gmi"/>
<updated>2021-01-13T00:00:00.000000+03:00</updated>
<title>Rambling: Why most 'alternative web' projects miss the point</title>
<content type="text"># Rambling: Why most 'alternative web' projects miss the point
2021-01-13
I assume most people here are aware of projects aiming to compete with "the web" in one way or another, right? I mean, you are reading this text through one of them.
But no, I am not talking about Gemini. Instead, I'm talking about various other "alternative web" projects. Take for example: Beaker Browser
=> https://beakerbrowser.com/ Beaker Browser
It is certainly not unique in both attempting to replace the web, and in HOW it's trying to do so. There are various other things like Beaker but through different protocols. And some that even involve blockchains (uuuuuuugggggggghhhhhhhhhhhhhhhhhhhhhhhhhh)
I am not here to talk about Beaker's specifics, I only shoved it here because it's the one I've seen most recently and was the "trigger" for this ramble.
Instead, I want to talk about HOW it's trying to replace the web.
See, Beaker and many others like it attempt to replace the protocol under the pages served. Not the pages themselves.
Why is this missing the point? Because the complex part ISN'T HTTP. It's the pages served through HTTP: It's the combo of HTML/CSS/JS.
The majority of the web's problems are caused by the HTML/CSS/JS. NOT by HTTP. You could've easily switched HTTP with something else (even Gemini!), and STILL have basically all the same problems if you don't switch to something simpler than HTML/CSS/JS.
Yes, you might have solved one specific problem about the distribution of pages, but the rest of the problems of how to interpret those pages remain. Of course, you are either not aware, or don't care enough, because you seem to be just using Electron and calling it a day.
You are still chained to the decisions of Google and to a lesser degree Apple and Mozilla. If they say you will have this feature, you must have that feature. You cannot contest with them. You think you're in control of your ecosystem, whereas it's only an illusion, and the parts you have control over don't really matter in the broad state of things.
. . .
Gemini gets this right by not just having Gemini, but also having Gemtext. A standard content type developed in tandem with the protocol itself, just like how HTTP has HTML.
The Gemini community is in full control over what happens in Gemini. We don't have megacorporations working against our interests even inside our sandbox. We can do what we want.
Our browsers do not have the bloat and security holes whatever new "standard" Google haphazardly threw out, intended for a completely different ecosystem, might cause. We do not have to pick up their trash after them.
Also, we have browsers with vastly different features intended for vastly different scenarios. How many Chromium clones do you have?
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/rambling/lightweight.gmi</id>
<link rel="alternate" href="gemini://ebc.li/rambling/lightweight.gmi"/>
<updated>2021-01-11T00:00:00.000000+03:00</updated>
<title>Rambling: Keep your server software light</title>
<content type="text"># Rambling: Keep your server software light
2021-01-11
Matrix, Mastodon, and various other federated (or otherwise "self-hosting friendly") server software developers, listen up!
(This post will focus mainly on federation, but even if that is not your focus you should listen as well)
The weight of your server software matters. If you don't work on keeping it light, you are actively hurting your chances on being successful.
In my mind, the main goal for a federated protocol is to not have a "main" server. Both Mastodon and Matrix fail this goal.
Go ahead and compare the popularity of "matrix.org" against other Matrix servers, and compare the popularity of "mastodon.social + mastodon.online" (both from the main Mastodon dev) against other Mastodon servers.
People that self-host things will most likely self-host multiple things, probably on a small amount of servers (frequently just one). So, if you want to cater to this crowd that can help you with your goal of reducing the network's dependency on you, you should design your server software to be able to play nice with other server software.
Choose your tools carefully and make your software as light on resources as you can.
Try to not force any external service dependencies for as much as you can.
Especially for things like reverse proxies that affect other software.
Make deploying an instance as easy as possible,
But don't force people into curl|bash'ing scripts or onto platforms like Docker.
They are fine to have, but always have a manual install process alongside.
You will never know the specific needs of any server.
Don't expect to be the only thing that will ever be hosted on this system.
Don't generate SSL certificates or anything else other tools can and will do better.
Scaling down is important. Perhaps more important than scaling up, as your network should be able to scale by having more independent servers, rather than having more power behind a single server.
And you really need to plan this from the beginning, trying to retrofit lightness into your software does not work. Just ask Matrix (well, Synapse).
## aside: "But <resource> is cheap!"
(The text below has been copied from something I wrote outside Gemini a few months ago)
This isn't a good assumption to make. As hardware yes, <resource> can be pretty cheap depending on how you look at it.
But when you're talking about servers that should stay online for as long as they can, most people don't have the advantage of being able to host from their own hardware (crap ISPs, crap speeds, no datacenters close by, no spare hardware, etc etc...). So you turn to someone else to host the server for you, and you generally have to pay monthly for this. This is where stuff starts getting expensive.
Now, I pay 5$/mo for my server, which might not be a huge deal at all for you. But remember everyone living in countries that don't use USD, EUR or other "common" currencies most places accept, and you suddenly need to know which currency you're dealing with to be able to make the claim of "<resource> is cheap".
On top of that, add the financial situation or frugal-ness of the person you're talking about, and suddenly <resource> might not be as cheap as you'd expect.
For larger operations like hosting the "main" instance of your software, or even for smaller operations covered by donations and such, <resource> can be cheap compared to income and the rest of the expenses, but for someone hosting a couple things for themselves on a small server with pocket money, that is not always the case.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/rambling/security.gmi</id>
<link rel="alternate" href="gemini://ebc.li/rambling/security.gmi"/>
<updated>2021-01-07T00:00:00.000000+03:00</updated>
<title>Rambling: Security vs. Standards</title>
<content type="text"># Rambling: Security vs. Standards
2021-01-07
On many privacy-oriented communities, you'll see people advocating for Signal, a chat service, praising how secure it is, while not seeming to realize it's yet another walled garden with a single central server, and with developers actively discouraging alternative clients AND distribution of their own clients outside the walled gardens of other big tech corporations. (in the name of security)
=> https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217339450 Moxie of Signal: I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world.
=> https://github.com/signalapp/Signal-Android/issues/127#issuecomment-13335689 Moxie: let me provide a little color on why I've been reluctant to distribute APKs outside of Google Play.
=> https://signal.org/android/apk/ The safest and easiest way to install Signal for Android is through the Google Play Store. Advanced users with special needs can download the Signal APK directly. Most users should not do this under normal circumstances.
Both of these are solveable problems, yet Moxie (and most likely the rest of the team at Signal) seem to not care about it, pushing people towards the proprietary silos of Google and Apple by discouraging downloading Signal outside their stores, and locking in the most important part of a chatting application (the people) to themselves, while throwing some code on GitHub every once in a while to be able to call themselves "open".
(Oh also, the Signal APK you get is not completely "open". The Signal team seem perfectly fine with using proprietary libraries.)
. . .
You'll see people advocating for Tutanota, an e-mail service, while not seeming to realize they don't care about mail standards one bit, and have intentionally NOT been supporting IMAP, SMTP, or any kind of communication protocol that isn't what they are using in their own applications, which are just web pages wrapped in platform-specific embedded browsers.
=> https://old.reddit.com/r/tutanota/search?q=smtp&restrict_sr=on&nsfw=on Reddit search on r/tutanota for "smtp"
=> https://tutanota.com/faq/#imap Tutanota FAQ about IMAP: This is not possible as we could not guarantee end-to-end encryption for your data
Most mails sent to/from Tutanota mail accounts will be in clear text, so there is no extra security in this, given they can always snoop on your mails when they're being sent or received. (And in fact, this is what they seem to be doing in response to legal "stuff")
And for the specific encrypted communication they have, how hard would it be to either make a fancy interface to an already existing standard, or create your own standard and share it with the wider world?
. . .
Have we not learned that walled gardens aren't that nice? They are one of the reasons why "Big Tech" is "big" after all. They are one of the reasons why you /(have struggled|are struggling)/ to get your friends and family to switch off of WhatsApp and Gmail. Do we really want a repeat of this all again?
Yesterday, we sacrificed our freedom in exchange for "usability". Now, do we want to sacrifice our freedom for "security" instead? I believe we can have all three (freedom, usability, AND security), but I don't expect it to come from the types of people behind Tutanota, Signal, and many other similar services I don't currently have in mind.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/scratching-my-own-itch.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/scratching-my-own-itch.gmi"/>
<updated>2020-11-24T00:00:00.000000+03:00</updated>
<title>Scratching my own itch</title>
<content type="text"># Scratching my own itch
2020-11-24
Chatting with a few friends online, I made an offhand remark about how "I only program to solve problems nowadays". Thinking back about it, I realized this might be a double-edged sword. Why?
## The Bad: I don't get many opportunities to code
There are only a finite amount of problems I have that can be solved with code. And only a finite subset of those problems are ones that I am aware of, and "had enough" to pursue trying to solve them.
Currently, I don't have (or at least can't recall off the top of my head) any problems I can solve via programming, which means I don't need to write more code, which is why I am writing this instead.
## The Good: It's a good source of motivation
It really is. If I know how to solve the problem, and am willing to start working on the solution, most of the time I won't stop until I get something that works well enough.
If I don't see the value of the "thing" myself, I generally don't bother with it.
## The Bad: I don't get to learn
If I'm fixing a bug / adding a new feature to an existing code base, I need to use the same language and tools as the original project. Even if I don't know how to deal with them, my only incentive is to solve that specific problem, so there is no reason to learn more than necessary to get in, do the change, and get out. (Which depending on the change is a really tiny piece of work)
Did I have to learn about Android application development to add a few new switches to an existing application? No, I grep'd my way across the settings pages to find something similar, and copy-pasted the code to add the switch. Then I grep'd my way around to find where the logic I needed to modify was, and changed it to check for the new setting I added.
Granted, I know how Java works (enough to make a few Minecraft mods), but the Android ecosystem is something else entirely, with completely different libraries and idioms, but the way I did this change wouldn't be different if I were contributing to a "regular" Java codebase.
=> https://github.com/ccrama/Slide/pull/3285 The specific change I'm talking about, for the curious
If I'm making something new to fix a problem, there isn't any incentive to learn something new there either, because I will most likely already have the tools in hand to patch something together. It won't be as elegant as if I looked for better tools, but my goal isn't to make an elegant and flexible solution, it's to make a solution that works well enough for the specific problem I have.
If you see me releasing some code, there are two main reasons for it:
- Personal backup that happens to be public
- It might just be helpful to someone else (unlikely)
Notice how none of them is "Because I want it to be something people will use". I am not forbidding anyone from using my code, I just don't care enough about it to advertise it on various places, do development logs, whatever people do to draw attention to their stuff.
(This is also why most of my code is permissively licensed, because I don't care what you do with it. If I did, I'd choose something copyleft.)
### More on learning
In the past, almost every line of code I wrote was about learning how to. Learning how to write Java and make Minecraft server plug-ins, learning how to write C# and make games with Unity, same with GDScript and Godot later on, and same with basically everything I know today. Learning was my primary source of motivation, especially since I wasn't as comfortable with programming back then. I never _used_ the things I made. I made them just to learn how to make them.
Now that I know what I can do, what I can look up (and how), learning isn't as motivating as it used to be, because I don't have any use for the things I'd make while learning.
The most recent thing I learned would either be Ansible (to manage my server's configuration), or Grafana/Prometheus (for pretty dashboards).
I learned Ansible (and Docker before it) because they solved a problem (how to keep my server organized) in a way I couldn't with my existing tools, which is why I was able to learn enough to re-create my existing configuration learning and trying for 2-3 days straight.
=> ./server-migration.gmi My post "Server Migration" from a month ago, detailing this.
The "2-3 days straight" part is important, because compared to something more recent, where I tried to make a game because I got bored and wanted to (not exactly good motivation), and it only lasted enough to make a pretty screenshot, trying to add a totally useless detail for 4 hours (that eventually looked out of place so I deleted it), and get lost in an accident involving btrfs.
(I could've recovered it since I had plenty of time to backup. I could still read from the partition without any problems, I just didn't because it wasn't important.)
I am still learning how to use Grafana and Prometheus to make a dashboard about what's going on my server, but because it's not as important (to me, anyway) I frequently see myself getting bored with it, and I totally expect to not even open the page in a few weeks or so, while it still tries to update in the background.
## The Good: I get to contribute to FOSS
Most of the time, my solutions are best made with completely new code, but for (both) times they required modifications to someone else's code, my changes have been accepted upstream, and it just _feels nice_ contributing back.
I definitely expect some projects to be harder to solve problems for, and even harder to get my solutions upstreamed, but thankfully I don't have any problems with those yet.
## The Bad: Sometimes you just can't solve a problem
There is a single problem I can think of that I can solve reasonably easily, but most likely won't get accepted upstream... But that's for Firefox and the combination of the horribly long build times and me using the Nightly builds make that pretty hard to solve reasonably, especially considering it won't make it upstream.
There are also problems where I don't even know where to start troubleshooting, much less fix. One example being somewhere in the Linux audio stack. (I am currently working around that by hacking around in the PulseAudio config using values I got off the internet I don't understand)
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-11-22.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-11-22.gmi"/>
<updated>2020-11-22T00:00:00.000000+03:00</updated>
<title>µLog #7</title>
<content type="text"># µLog #7
2020-11-22
## Look at the date!
It's double digits, twice! What a nice day to come back here after almost exactly a month!
Well, by "come back", I never _left_. I did some slight updates here every now and then, adding a mailing list for comments, and all that good stuff. Also I was lurking reading the fine work of everyone else!
## Subscriptions
=> gemini://gemini.circumlunar.space/docs/companion/subscription.gmi "Subscribing to Gemini pages"
One of these "slight updates" was to update my homepage to be compatible with the new subscription companion standard. Atom isn't going away anywhere, but it's good to let people choose how they should view your content.
Atom gets to have the content _inside_ the feed (so you can read directly from your feed reader), and the new standard removes the burden of parsing XML. Choose whichever you want.
=> /atom.xml My Atom feed in case you weren't aware
## Renaming µLogs
I also went through the previous 6 pages and renamed them to have numbers in place of dates, so the index looks cleaner without two dates on each side of the same link. Hope nobody used the titles to keep track of which pages they read, otherwise they're getting 6 (plus this post, 7) new unread pages. The URLs are still the same, because there isn't any reason to change them.
## Other than that...
...nothing else interesting happened, so I guess It's time for me to go back into my cave yet again. See you all in a month or so!
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/server-migration.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/server-migration.gmi"/>
<updated>2020-10-21T00:00:00.000000+03:00</updated>
<title>Server Migration</title>
<content type="text"># Server Migration
2020-10-21
## 2021 Update
I have messed around with my server again, so this post is now out of date. Might still be interesting to some people, though.
## Original Post
So, I finished re-deploying my server two hours or so ago, and it took ~7 hours.
The main motivation behind "this" was because I wanted a reproducible-ish config behind my server for MONTHS, and just a couple days ago started working on one.
First of all, I did the sensible thing of creating a VM and experimenting on that, which isn't usually what I do, but since I wanted this to be reproducible, testing on a VM and making it work "for real" with the same (or similar) configuration just felt like the best choice.
The VM was originally Debian bullseye, because that's what ISO I had lying around, but a couple days later I switched to Debian buster, because that's what I planned on running on the server. This switch also helped with me testing the configuration again from scratch, making sure it didn't depend on anything I installed by hand on the first VM. It also found a lot of compatibility issues I had to fix, so that's nice.
I scheduled¹ today² to the "migration" and stopped for the day.
## Works on my machine. Let's ship it.
It took ~3 hours for the initial configuration to apply, and for me to migrate the data over from the previous server³. With ~1 hour to fix "Mastodon being Mastodon" and some dumb things I did that didn't get tested beforehand⁴.
After getting Mastodon working, which was my "end goal" because the rest "just works" most of the time, I decided to try out something I didn't really try before, which was "Object Storage"
### Object Storage?
Object storage is basically "really cheap storage". It's actually a little more detailed than that but that's what you're getting from me at 4 AM (UTC+3)
I was mainly interested in trying it out because my server only has 20 GBs of storage, and the old server got to somewhere around 10-13 GBs full. I don't recall any specific "storage hog", but Mastodon's tendency to proxy remote media, it's system folder becoming ~2 GBs⁵, and it being the only service I have running that supports object storage made it the prime candidate to test it out on.
So I did. I enabled the "object storage" service from my VPS provider⁶ and messed around with my Nginx configuration until it worked⁷, and set up Mastodon via the following guide that's still not merged into Mastodon's documentation:
=> https://github.com/tootsuite/documentation/pull/809/files Migrate assets to S3 (tootsuite/documentation#809)
It was running on my Mastodon instance at toot.ebc.li, and hopefully it won't blow up any time soon.
=> https://git.ebc.li/archive/infra-old/ Here is my old Ansible configuration in case you want to look around and email me how terrible it is. Hope I didn't commit any passwords.
## Footnotes
1: Well, I didn't have anything important anyway.
2: 20th of October, which might be considered "yesterday" depending on how you interpret time, also relative to this post's release
3: I didn't keep track of the timeline any more detailed than a now deleted thread, and the migration did happen while I was waiting for other parts of the playbook to run.
4: My testing environment doesn't allow connection from the "outside world", so I couldn't generate SSL certs for it without more hassle than I cared about. This also prevented me from testing Mastodon, because it kept wanting to be served over SSL.
5: I am not entirely sure, but I might have skipped setting up some cron jobs that could have kept it lower than it was. I wish I could check but that server's gone now.
6: It's Linode. I probably could find a cheaper service specifically for that, but I already have all my payment stuff set-up to pay them monthly, so why not?
7: `proxy_pass` does not work properly with a trailing slash and that was probably an hour down the drain.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-10-07.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-10-07.gmi"/>
<updated>2020-10-07T00:00:00.000000+03:00</updated>
<title>µLog #6</title>
<content type="text"># µLog #6
2020-10-07
## The Weird Emoji Issue
So, I _just_ fixed this issue.
On my reasonably exotic setup⁰, I just realized emojis did not display properly. They worked on my terminal (Alacritty) and seemed to work on Qt-based things, but did not work on the ONE place I would expect them to work: Firefox.
After following some essential troubleshooting steps, venting about them a lil' bit, and getting nudged towards Pango, I finally found a Gentoo bug report that seemed to show a very similar issue.
=> https://bugs.gentoo.org/712374 Gentoo bug 712374
The solution was not related to anything I just wrote.
The solution was to disable the "Infinality" fontconfig configuration that Gentoo still provides as an option for some reason, since they are _ancient_. I would've expected them to either keep it updated, or remove it entirely.
=> https://gist.github.com/cryzed/e002e7057435f02cc7894b9e748c5671 This guide on how to migrate away and keep similar font rendering is from January 2017, and this only happened becuase libraries started breaking.
And just like that, emoji started to appear 🎉🎉.
Conclusion: Don't use old software, especially if you know they're old.
## The Compose Key
I finally set up a compose key binding so I didn't have to copy-paste special characters to use them. That seemed to work on everywhere except Alacritty. I was just about to ask _here_ why this might be, when I decided to check on Alacritty's issue tracker again.
The solution was to use `en_US.UTF-8`¹ instead of `C.UTF-8` as the system locale.
## Footnotes
0: (Currently) Gentoo with ALL use flags disabled by default (USE="-*")
1: Or probably any other locale that isn't `C`
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-09-15.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-09-15.gmi"/>
<updated>2020-09-15T00:00:00.000000+03:00</updated>
<title>µLog #5</title>
<content type="text"># µLog #5
2020-09-15
So... It's definitely been a while since I last took a look here, and I was able to catch-up with all of the new posts that interested me in about a couple minutes. Try doing that on the regular web. Ha!
=> /experiments/motd.gmi Just look at how long my MOTD stayed the same!
## Distro Hopping Like an Addicted Bunny
So... I am an avid distro-hopper. If you give me a machine that can run Linux, expect it to go though an average of five distros per month.
Currently I am on my "main" machine, which is a huge beast, and also is the most comfortable setup I have. (Copying dotfiles over to a laptop, for example, just isn't the same)
That's why I'm always reluctant to distro-hop (or even just start fresh with the same distro) on this machine. But just recently my /interesting/ Gentoo USE flag combinations finally broke, and when you have to hold even a single package back for longer than a week, you know something's up.
Originally I planned my next distro to be NixOS, but trying it for a day or so it got me _really_ frustrated, where I would do the exact same thing as shown on every page of documentation, or answer, and it just didn't work. So while the concept is still intriguing to me, I doubt I'll use it any time soon.
So, I decided on using another distro. This time I knew what I was getting into, since I used it every now and then since March or so: KISS Linux
### KISS Linux
=> https://k1ss.org 1: KISS Linux
KISS is a quite neat distro. It's source-based like Gentoo, but unlike Gentoo it's _very_ minimal. The initial rootfs tarball is ~30 MBs, compared to Gentoo's ~200 MBs, and when installed you don't get as much as Gentoo (or any Linux distro, for that matter) would give you. You have Busybox, a C toolchain, a package manager, and a couple other tools should you wish to install them. And all of those are getting more and more stripped-down, removing features that result in additional dependencies.
Of course, because it's so minimal, you might want some extra features enabled. In that case, you will have to copy a package and edit the build script to enable it. Or in some other cases simply rebuilding packages with the required dependencies installed will automatically enable said features¹. And since the package manager is a shell script (did I mention the package manager is written in POSIX sh), you can symlink away the unmodified bits of your packages and pass the actual update checking bit to the original package maintainer, and the system will just deal with it.
Just check it out if you're interested. I quite like it.
## Vim Digraphs
Did you know, that up until today, I always copy-pasted the subscript number characters (⁰¹²...) by hand whenever I wanted to add a footnote? Well, I figured out that there must be a better way to do this, so I searched it up.
In Vim, you can use `<Ctrl-K> <num><Shift-S>` (in insert mode) to insert a superscript <num>. Remove the <Shift> for subscript.
There's also `<C-K> <Shift-M>y` to write the "µ" symbol I use in the titles of these posts, which I just copy-paste from the previous one anyway as a template of sorts.
Use `:dig` to get a list of every one of them. Now I just need a way to use them outside Vim...
## Footnotes
1: And the package manager keeps track of any additional dependencies by ~~black magic~~ checking all binaries with ldd.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/alt-text-proposal.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/alt-text-proposal.gmi"/>
<updated>2020-09-07T00:00:00.000000+03:00</updated>
<title>Yet another proposed scheme for parsing preformatted alt text</title>
<content type="text"># Yet another proposed scheme for parsing preformatted alt text
2020-09-07
I just sent out a response to Luke's proposal for alt text on preformatting blocks in the Gemini mailing list. I will also put the entire mail here, for anyone who doesn't follow the mailing list.
=> gemini://gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi A proposed scheme for parsing preformatted alt text
> I just had this interesting formating idea reading through this thread:
>
> [modifiers...] [type] [:] <description>
>
>
> This format lets the alt text be mostly human-readable while keeping some semantics for machines to parse through.
>
> As an example, all these lines should be valid:
>
> "python code: Code to parse this format"
> "table: Point leaderboard"
> "Description without any machine readable parts"
>
> The [modifiers...] part is a list of adjectives the pre-formatted text has, like a programming language name, type of art (ascii / ansi / unicode / whatever), or whatever else other people can think of. They are all single words separated by spaces.
>
> [type] is the type of the content in the pre-formatted text block. Like "code", "table" or "art"
>
> The [:] is just a separator between the machine-readable part and the description. If a machine reads any ":", it will stop processing, as the continuation of this line is for humans only.
>
> <description> is the human-readable explanation of what's inside the pre-formatted block. It can contain anything, including ":" characters since the machines should stop parsing after the first one.
>
> If a machine has any doubts (any unrecognized modifier or type, or maybe some other heuristic), it should halt parsing and display the entire line as is, to make sure malformed input can still be understood by a human.
>
>
>
> I am not entirely sure how well this would actually work "in production", but I feel like this is definitely something to throw out here.
## Footnotes
=> https://lists.orbitalfox.eu/archives/gemini/2020/002592.html View in the mailing list archives
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-09-02.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-09-02.gmi"/>
<updated>2020-09-02T00:00:00.000000+03:00</updated>
<title>µLog #4</title>
<content type="text"># µLog #4
2020-09-02
## Making gemini:// clickable on Mastodon.
I just patched my private Mastodon instance to make gemini:// links work.
### 2021 Update:
Mastodon versions 3.3.0 and up does this by default :)
## Mastodon's inefficient tooling
The first ever patch I applied to my Mastodon instance was to increase the character length limit. I only found out yesterday it didn't work properly, so I updated the patch to fix the oversight.
And it still didn't work on "production".
I managed to fix it just a couple hours ago, and for that I needed to completely clobber all the generated JS files, and re-generate them from scratch.
The problem? Doing that eats all my server's memory, and then some!
Because of that, I had to stop all Mastodon, Gitea, Postgres and Redis processes until the JS files update, and even then it takes a VERY long time.
Now, Mastodon itself isn't exactly the slimmest thing when running, but it's a LOT better than, say, GitLab, which uses a similar tech stack.
My server has 1 GB's of memory with +2 GB's of swap, a single core and 20 GB's of storage, It's not exactly the best thing, but it's cheap (important, especially with the exchange rates in my country) and still has some room for a thing or two, especially since I try to choose stuff based on the weight of the server.
To anybody who does self-hostable server software, PLEASE think of lower-end servers. Not everybody wants their stuff to scale to tens of servers with everything on a separate box hosting thousands of users. Even if they want to, it's not cheap to do it either.
Thank you.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/biting-more-than-you-can-chew.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/biting-more-than-you-can-chew.gmi"/>
<updated>2020-08-28T00:00:00.000000+03:00</updated>
<title>Biting More Than You Can Chew</title>
<content type="text"># Biting More Than You Can Chew
2020-08-28
> This post has corrections, see the "Corrections" section for more information!
Imagine you checked out the sources of a large software project. You have an idea of what changes you want to do to it. The problem? Where do you start?
No, seriously, where _do_ you start? You have ~50 GB (without Git history) of sources in front of you. Where do you begin adding even the smallest thing?
You might think to yourself that _someone_ must've documented how everything fits together. Nope! The project's own documentation only has API usage and how to work on something _targeting_ it, not on its own source code.
Other third party documentation is either lacking, or _very_ surface level. Explaining the simple things like how to clone & build the software, which doesn't help if you want to modify the software and not just use it.
You _can_ read how the old code works, or look through how others do their changes, but that's way too much effort to apply a change that you don't even plan to upstream or maybe even share. Even if you are _really_ motivated to apply your change, the code is _50 GB_, where do you even look _first_?
You might assume you can just throw stuff onto the wall and see what sticks... Good luck. Even the most trivial changes take *at least* 15 minutes to compile, not to mention the extra hassle to deploy the changes. (Since this code compiles to an external device)
What _can_ you do other than just steal commits off of other people? Genuinely curious...
## Corrections
### It's Actually Not 50 GB
After receiving a reply to this post, that asked which project had 50 GBs of sources, I wanted to make sure my number was accurate.
=> gemini://perplexing.space/2020/re-biting-more-than-you-can-chew.gmi Reply by Nolan of perplexing.space
The raw sources are around 45-50 GBs, but a large part of these are either:
- Pre-built binaries (a very large part at ~25 GB).
- Various binary resources like images, short videos, proprietary blobs from vendors.
- Parts of code that won't be needed for my uses.
Approximating the impact of all these, I would say the parts of the source that get built for my uses are around 5 GBs, maybe lower.
### Unnecessarily Vague
I have no idea why I kept this post unnecessarily vague, but the project in question is Android (specifically, the LineageOS fork, but it doesn't impact the upstream complexity in any meaningful way)
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-08-16.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-08-16.gmi"/>
<updated>2020-08-16T00:00:00.000000+03:00</updated>
<title>µLog #3</title>
<content type="text"># µLog #3
2020-08-16
## From Pleroma to Mastodon
I just recently switched from Pleroma to Mastodon as my fediverse server software of choice, only because of the superior user experience of Mastodon.
Now, my server is really tiny, only about a gig of ram, a single virtual core, and 20 gigs of space. Can Mastodon live on these low resources and not clash with everything else I'm running? Surprisingly for me, maybe!
I always thought of Mastodon as a huge resource hog, and in many cases it can be, but compared to something like GitLab which also uses a similar stack (AFAIK, anyway. I'm not a Ruby guy) it's really light.
Now, I will be keeping my Pleroma instance up for about a day for people to see my "I'm moving" post. But after that, it's gone. The funny thing about this is that currently, while both Mastodon and Pleroma are running side by side (both somewhat idle), only around half of my memory is used, which was the surprising part.
Anyway, there's definitely a post on my mind about selfhosting and lightweight serverside software, but that's for another day. It's 4 AM and a half here and I really want to sleep now :p
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/open-standards-are-simple.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/open-standards-are-simple.gmi"/>
<updated>2020-08-13T00:00:00.000000+03:00</updated>
<title>Open Standards Are Simple</title>
<content type="text"># Open Standards Are Simple
2020-08-13
If you want to create a truly open standard, you _need_ to make it simple.
There are no exceptions to this rule. When a standard becomes harder to fully implement than what your average motivated programmer can do in two months (max!), it _shouldn't_ be considered "open" anymore.
Why?
## Complicated Standards Lead to Implementation Monopolies
Since implementing a complex standard is hard, you will eventually end up with the implementation that started the earliest and maintained since, being the only implementation that is actually usable. And that implementation will most likely be the one created by the standard's creators.
In cases where the standard's creators don't maintain an implementation like "the web"⁰, the only choices are either the standard dying out because of it's complexity, or the actively maintained implementations requiring tons of effort, with (most likely) companies backing said implementations.
## Implementation Monopolies Lead to Extensions
If a big implementation just decides one day that your standard is lacking, they can just extend the parts they want. The two outcomes of this being that:
- The other implementations copy their extensions
- That one implementation getting more users, and eventually, a near monopoly because of a bigger feature set
At that point, the "standard" implemented by said implementations is longer the actual defined standard, but because people will inevitably use the said extensions, any new implementation that wants to be considered usable will eventually need to support said proprietary extensions.
## Too Many Extensions Spoil The Standard
Even if you have an "open" extension system, where implementations can all propose and agree on extensions to the standard, you need to be able to keep those implementations in check, so their extensions don't overcomplicate the standard.
Remember: Having a simple standard with a million extensions is no better than a complex standard with no extensions.
## Examples
Please note that I will be skipping the elephant in the room: "the web", as it has been discussed _to death_.
### Matrix
Matrix is _technically_ an open standard. But because of the complexity it has accumulated over the years, Synapse is the only usable server implementation. Even Dendrite, the new implementation by *the same folk that created the standard*, is barely usable after _years_.
The same applies to Matrix clients, with Element being the only usable client implementation. That space definitely seems healthier than the server space, but the same issues are there.
### Various Programming Languages
I will not be specifying any language, as I might get any specifics incorrect, but a general pattern I have seen is that most programming languages have only a few compiler/interpreter implementations, even though the language is standardized in some form.
This example actually has some interesting reasoning behind this issue on top of the complicated standards:
- Writing a compiler/interpreter can be hard.
- Especially if the current implementations do optimizations or other "clever" tricks.
These issues can devolve into arguments regarding seeing the complexity of these issues as a part of the standard, and other "technology is too complicated in general" arguments, which I will not dive into here.
### X Display Server
The X Display Server standard got so complicated, the people developing it decided to abandon it entirely and create Wayland.
It probably didn't help that most of the standard was no longer being used, and a lot of extensions are required for its use today.
Wayland probably will also suffer the "too many extensions" problem at some point, so I am looking forward to that too...
## Footnotes
0: Well, Google, Mozilla and Apple all had a hand in most of the "modern" parts of the standards...
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-08-10.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-08-10.gmi"/>
<updated>2020-08-10T00:00:00.000000+03:00</updated>
<title>µLog #2</title>
<content type="text"># µLog #2
2020-08-10
## menuconfig tip
If you compile your own Linux kernels very often like me, you might appreciate this tip:
When searching for an option with `/`, you can jump over to where it's defined by just pressing the number next to it.
### Example
Let's say I searched for `wireguard`. This is what will pop up:
Symbol: WIREGUARD [=m]
Type : tristate
Defined at drivers/net/Kconfig:74
Prompt: WireGuard secure network tunnel
Depends on: NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && <...snip...>
Location:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
(1) -> Network core driver support (NET_CORE [=y])
Selects: NET_UDP_TUNNEL [=m] && DST_CACHE [=y] && CRYPTO [=y] && <...snip...>
Symbol: WIREGUARD_DEBUG [=n]
Type : bool
Defined at drivers/net/Kconfig:106
Prompt: Debugging checks and verbose messages
Depends on: NETDEVICES [=y] && NET_CORE [=y] && WIREGUARD [=m]
Location:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Network core driver support (NET_CORE [=y])
(2) -> WireGuard secure network tunnel (WIREGUARD [=m])
In the output above, the numbers next to the lines `Network core driver support` and `WireGuard secure network tunnel` are hotkeys, and if you press `1` or `2` in this page, you will jump to that option.
I've probably messed around with Linux kernel configuration for 2-3 years now, and I just today found out about this, by accident. I am now sad about all the seconds wasted trying to find something nested very deep...
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/replies/solderpunk-keyboard-hegemony.gmi</id>
<link rel="alternate" href="gemini://ebc.li/replies/solderpunk-keyboard-hegemony.gmi"/>
<updated>2020-08-09T00:00:00.000000+03:00</updated>
<title>Re: Keyboard Hegemony</title>
<content type="text"># Re: Keyboard Hegemony
2020-08-09
=> gemini://gemini.circumlunar.space/~solderpunk/gemlog/keyboard-hegemony.gmi This post is a reply to "Keyboard Hegemony" by Solderpunk
As someone who learned how to keyboard with an "exotic" layout (in my case: Turkish QWERTY), I wanted to chime in with some experiences with that layout.
If you don't know the Turkish Q layout, it's basically the regular QWERTY layout, with most of the quirks Solderpunk mentioned on their Finnish layout. The only differences I see are the Nordic letters on his are replaced with Turkish letters like ü, ğ, ş, and ı on mine.
## The two I's
If you paid attention to the previous paragraph, you'll notice that one of the extra letters is 'ı'. That is a dotless i. You'll be familiar with it because it exists in English, too. It's just only in uppercase.
Not in this layout. We have both ı, i, but also, I and İ.
You might think, this is just another letter what's the big deal... But on the Turkish Q keyboard layout, the 'i' key in the topmost row is replaced by the 'ı'. And the regular 'i' is in the second row, two keys left from the Enter key. Now, this isn't that big of a deal since (a) I got used to it, and (b) both keys are relatively close to my fingers to write fast, but this is a problem if you switch to an English layout in a space where you don't have Unicode support, like a Linux TTY. Because you press 'i' and it turns into a garbled mess you cannot delete because it thinks it's two characters so it puts an invisible character and it's just all weird.
Also, since we have two I's that all capitalize separately, some programs like modded Minecraft can get really weirded out if the system locale is set to Turkish, but that's not related to keyboards so I am skipping over that.
Oh also, Linux TTY's don't work with <CAPSLOCK>+<ı>, so you have to do <SHIFT>+<ı>. Which is a really big deal if you capitalized your words using caps lock for ~15 years or so. (I remapped caps lock to escape a month or so ago, working on getting rid of that habit)
## "Dead Keys"
The quirk Solderpunk mentioned with ` and ~, are what's known as "dead keys", where the key is "dead" until you press another key to combine it with. The Turkish layout has that too, but weirdly enough only on Windows. Under Linux, the keys work how I expect them to. I remember seeing a "Turkish with dead keys" layout option on various Linux installers, but I really don't need any of the "interesting" letters, so I never used it.
## How do I put up with this
> I kind of wonder - *do* non-US-layout-native developers typically switch their layout when coding? Or do they actually just put up with stuff like what I'm about to describe
Honestly, for me at least, I've gotten used to all the weird quirks of the layout and it's all became muscle memory now. Whenever I need to use an English QWERTY layout, I become completely lost, especially with the symbol keys like the <SHIFT>+<number row> or the cluster near enter.
However, being used to this isn't all that fine and dandy, since when I'll eventually need a better keyboard than what I've got today, most of the "interesting" options probably don't have any Turkish Q options, so I'll eventually need to face the challenge of switching over, probably.
## What about the Turkish F layout?
I don't want to talk about it. I have nightmares about that from years ago.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/ulogs/2020-08-08.gmi</id>
<link rel="alternate" href="gemini://ebc.li/ulogs/2020-08-08.gmi"/>
<updated>2020-08-08T00:00:00.000000+03:00</updated>
<title>µLog #1</title>
<content type="text"># µLog #1
2020-08-08
## Porting postmarketOS to my ZTE Axon 7
So, I got bored and decided to try something new, and ported postmarketOS to my old phone.
Getting the kernel to compile was the easy part, as I tried this a month prior, and knew the trivial fixes.
Trying to boot the kernel was the actual challenge. The LineageOS 15 kernel I used had some issues with the LCD driver which required some cherry-picks from an unofficial LineageOS 17 kernel, and a weird kernel panic that caused me to downgrade to GCC 6, but after all that, I got a USB connection in the initramfs.
I got into the initramfs, but I couldn't progress further, because the boot system couldn't find the sub-partitions that contained the rest of the system.
This was the issue that stumped me the most, but later I found out that I needed to read the documentation a little harder, and fixed some values with the generated file system's partition table, and it just worked!
Also, before fixing the partitions, I tried flashing a microSD card to see if the initramfs could read it instead, and it did.
I am hoping I can switch to the (close to) mainline kernel for this phone's SoC, but that's for another day, as currently I can't get any useful debugging information out of it.
=> https://gitlab.com/admicos/pmaports/-/commits/zte-axon7 My pmaports zte-axon7 branch
## µLog?????
I am also trying another experiment with these "micro-logs", where I just write about what's happened every interesting day (so, barely never). Let's see how long I keep this up before stopping entirely.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/ebuilds-and-simplicity.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/ebuilds-and-simplicity.gmi"/>
<updated>2020-08-05T00:00:00.000000+03:00</updated>
<title>Ebuilds: Why You Should Have Good Documentation If You Cannot Make It Simple</title>
<content type="text"># Ebuilds: Why You Should Have Good Documentation If You Cannot Make It Simple
2020-08-05
In most Linux distributions, software are built into packages, which the end-user can install via the command line or a graphical interface.
If you are technical enough, you might want to create your own packages for software you created, or just couldn't find in the default repositories.
All distributions have their own tooling for this process. And I want to focus on the tooling of three particular distributions. The distributions I will talk about are Arch, KISS, and Gentoo.
## Arch Linux and PKGBUILDs: Documentation
=> https://www.archlinux.org/ Arch Linux
Arch Linux's PKGBUILD scripts are definitely simple once you get the hang of them (and it's not that hard to do so!), but the point I want to make about them are the quality of the documentation. It's beautiful.
Of course, being the distribution behind the excellent Arch Wiki, that shouldn't be that big of a surprise to anyone familiar with it.
The essential PKGBUILD documentation consists mainly of these two wiki pages, with the other related and linked pages allowing you to dive deeper into what you're trying to accomplish:
=> https://wiki.archlinux.org/index.php/Creating_packages#Creating_a_PKGBUILD Creating Packages - Arch Wiki
=> https://wiki.archlinux.org/index.php/PKGBUILD PKGBUILD - Arch Wiki
With the first page giving you the basic outline of the process, and using the second as a reference, I am pretty sure anyone with just about enough shell scripting knowledge can create a PKGBUILD and have the resulting package installed in about half an hour, probably even less.
## KISS Linux and ./build: Simplicity
=> https://k1ss.org/ KISS Linux
KISS Linux, taking it's name from "Keep It Simple, Stupid", might not have the excellent documentation of the Arch Wiki, but I'd argue that it doesn't need to, because of how simple it's packaging system is.
To create a package in KISS Linux, you create a new folder, write the download links in the sources file, the version in the version file, and just dump all the build instructions in a shell script named build¹. Run a command to generate checksums, and you are done.
=> https://k1ss.org/package-system Package System - KISS
The main point I want to get to, is that KISS doesn't need all the in-depth documentation of PKGBUILDs, because it doesn't have that much to document. And if you're actually using KISS comfortably enough to create your own packages, you probably can understand what you'll need to do for any specific build system.
## Gentoo and ebuilds: What Not to Do
=> https://gentoo.org/ Gentoo Linux
Here is the main part of the article: ebuilds. The opposite of what you should do.
=> https://wiki.gentoo.org/wiki/Basic_guide_to_write_Gentoo_Ebuilds Basic Guide to Write Ebuilds - Gentoo Wiki
=> https://devmanual.gentoo.org/quickstart/ Quickstart Ebuild Guide - Gentoo Development Guide
The Gentoo Wiki has guides on how to start writing Ebuilds, and even some examples to get you started. All good, right?
The problem isn't with the documented parts. It's with the abundance of un-documented parts.
### An Example
As far as I could tell, there is NO documentation on downloading and using files without extracting them.
Doing the obvious thing of just putting download links into the source URL variable will make the package manager yell at you about a missing directory, which it assumes the existence of, because a majority of Gentoo package sources are tar archives. As far as I could tell, there is NO documentation on this behavior.
What I had to do was to tell the package manager to not look for any extracted folders, so I could manually move the files into the correct places it expected them to be in, even before doing the installation, which is essentially moving those files into yet another directory. (The package doesn't need to do any processing at all! It's just a few data files.)
How did I finally make it work in the end? I just jumped into IRC and asked. The existing documentation was little to no use, aside from de-constructing the solution they gave to understand what I needed to do.
### Complexity: eclasses
Gentoo's ebuilds have this feature called "eclasses", which try to abstract away common build script boilerplate to make ebuilds simpler.
Unfortunately, this only adds to the complexity, because it now does things in the background with source code that's very hard to skim through to find what you need and get out.
## Ending
So, if you are making anything, either make it so simple that people will "get it" in a few minutes, or write enough documentation for everybody to understand. Try considering the assumptions you make in your system. Document every assumption your systems have, and how to work around them should it need to be broken.
Why? Because in the sea of all the archives you automatically extract, there will eventually be a regular file, and when that time comes, you don't want people to be left confused, looking for answers.
## Footnotes
1: It doesn't have to be a shell script, anything executable will do. But I don't think anyone uses anything other than shell scripts, because compiling software requires shell commands, and there aren't anything better than shell scripts to execute them.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/automation-fragmentation.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/automation-fragmentation.gmi"/>
<updated>2020-08-04T00:00:00.000000+03:00</updated>
<title>Linux's Automation Fragmentation</title>
<content type="text"># Linux's Automation Fragmentation
2020-08-04
> Note: I don't exactly think this post has that much substance in it as I was pretty distracted while writing, and didn't exactly have the best arguments around. I still think the underlying "concept" is a real thing (and that's why this is still going up), but this exact post might not be the best way to share it.
I recently had to deal with AutoHotkey (shortened to AHK) again, as I decided to reformat my Windows VM to continue my tradition of unnecessarily reformatting stuff when I get bored. My specific problem was I had swapped Caps Lock and Escape on my host Linux system, and got really used to that combo even in this short of a timespan⁰. Unlike Sway, Windows doesn't have that feature built in.
After setting up the mappings, I decided to check out some discussion sites relating to AHK, looking around I had this question in my head: Why does it feel like people do a lot more tweaking with AHK (which, while very powerful, isn't exactly the most pleasant tool to work with) than what most Linux environments can provide with their open-ness?
While it could be that most Linux people just don't talk about how their workflow works, I'm not entirely sure that's the answer.
I also used to use tools like AHK. Specifically one called Tasker. It's a paid "app" for Android that is essentially the de-facto automation tool.
Like AHK, Tasker isn't that intuitive¹, but it is very powerful, and has extensions that make it more powerful than it is by default.
I used it for a LOT. One time I made an entire schedule displayer for my school classes, where it would display the current class, the time left until the break, and all that, copied and pasted for all 5 week days². More recently, since I no longer use my phone all that much as my computer is always around, I've kept it simple only with stuff like alarms that can only be disabled via NFC triggers³.
Now, why am I talking about all this? Because I haven't done anything like these under Linux, ever.
Why? I personally think the problem is this:
## There are too many tools!
There are too many tools with each doing something different. This isn't all that bad and can actually be pretty good because you can compose them however you like. The problems I have in mind however, are:
### There isn't any clear way to compose them all
Yes, you have the shell, and yes, it can do a lot, but most automation works by responding to events, like key presses, or button clicks, or receiving a message.
For custom events, some programs will, if you're lucky, have settings on custom event listeners, which might call external tools.
For key presses, all desktop/window environments have different settings, and global key listener tools like sxhkd might break them if installed on top. Also if you're under Wayland you cannot listen for keys _at all_ unless you use compositor specific settings⁴.
Wayland also has problems⁵ like external programs not being able to interact with other programs, or draw overlays, which also limit what can be done on programs that don't have specific extension capabilities.
Also sometimes you want to do something only if a specific program is in focus. Good luck.
And even if you actually go through the trouble of going through all that and managed to get a program to call your handler...
### All of these tools are another thing to learn
Well, how do you move the mouse on a button? If you're on X, you can use something like `xdotool` to move the mouse, but how do you get where the button is? You'll probably have to use some accessibility APIs to actually find and click the button⁶.
You want to move a window? Now you need to figure out `wmctrl`.
You want to pop up a tiny GUI? Either you use something like dmenu/rofi, or you're going to have a bad time.
### You Cannot Discover Them by Accident
When using Tasker for example, I liked being able to go through the list of triggers or actions to see what I could do. You cannot do that with the current tools, since they are all separate. And that's even if they are installed in your computer to begin with.
## What about AutoKey?
=> https://github.com/autokey/autokey AutoKey
While AutoKey exists, and definitely addresses some issues I talked about, it's main focus is on keyboard macros and shortcuts.
Also it still has the discoverability issue, as most of the interesting things you can do with it are with shell commands.
## Footnotes
0: Assuming I tooted the same day I made the change, it should be exactly a month plus 4 days since then.
1: It's definitely "simpler" than AHK because it's GUI based, but it also has an interesting learning curve.
2: Writing this, I just realized I could've probably just made it fetch data from the calender, would be a LOT easier.
3: Do things that do this already exist? Yes. Could I be bothered to just download one and use them? No.
4: Well, you can _technically_ just read off of evdev via the /dev/input files, but why?
5: Some might call them security improvements, but I don't want that debate.
6: There might be tools that do this for you, I haven't researched that much.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
<entry>
<id>gemini://ebc.li/posts/how-hard-can-it-be.gmi</id>
<link rel="alternate" href="gemini://ebc.li/posts/how-hard-can-it-be.gmi"/>
<updated>2020-08-04T00:00:00.000000+03:00</updated>
<title>Moonlander and the curse of "How hard can it be?"</title>
<content type="text"># Moonlander and the curse of "How hard can it be?"
2020-08-04
If you didn't know, I made a Gemini client called Moonlander back when I first got into Gemini. After 3 days of development, it essentially got abandoned.
=> https://sr.ht/~admicos/moonlander/ Moonlander
It looks pretty and has some styling options my current client, Kristall doesn't have¹, mostly related to the spacing of text. (Maximum width, line/paragraph spacing, etc.)
=> https://github.com/MasterQ32/kristall/ Kristall
Moonlander is also one of the first² (and one of the few) Gemini clients to do something special: It renders text directly into a blank canvas instead of using any OS text widgets.
This decision has the main advantage of not being bound by any of the limitations the OS text widgets have on positioning and styling the text.
However, it comes with some major disadvantages:
- A lot more complicated and requires extra handling for the things the OS widgets give you for granted, like culling scrolled lines to not give too much to the text renderer.
- Accessibility goes out the window.
- Text is _really_ hard to work with.
I'd like to focus on the latter for this specific article.
## Text hates you in general
If you haven't read the following two articles, please do, you'll understand why you probably shouldn't attempt what I tried with Moonlander:
=> https://gankra.github.io/blah/text-hates-you/ Text Rendering Hates You - Alexis Beingessner
=> https://lord.io/blog/2019/text-editing-hates-you-too/ Text Editing Hates You Too - lord.io
The majority of the content in these articles actually aren't that relevant to Moonlander, as I offload all the dirty rendering work to the Pango library, and Moonlander doesn't contain any text editing functions.
=> https://pango.gnome.org/ Pango
The specific part I want to focus on instead, is text selection.
### Text isn't consistent
Let's begin with the simplest part of it all. How do you select a single line plain English text?
If you use a monospaced font, your job is easy. You can find which letter the cursor is on by dividing the cursor's X position with the letter width to get which letter the cursor is on.
If you're using a "normal" (not monospaced) font however, you'll immediately find an issue with that method: How wide is a letter?
You cannot just get the average width and use that, as even an inaccuracy of 5 to 6 pixels (depending of the font size of course) can cause your selection to go off. Or it might just break entirely on lines containing mostly thin or thick letters.
Looping over each letter and measuring them might be enough, but you'll probably have to do a lot of tricks to make that perform well.
### Multiple Lines
Let's say you managed to make a single line work. Now, how do you do multiple lines?
This probably isn't that big of a deal as a single line, since you can mark each line as "completely selected" and it would probably work by itself.
### Culture Shock
Now you get a new issue in your issue tracker. The issue says the user cannot select Arabic text like they are used to on other programs.
Arabic is written left-to-right, so you have to handle that somehow. You might think of just reversing the entire algorithm, but then you'll need to make sure you deal with left-to-right text in the middle of right-to-left text. I also heard Japanese can be written top-to-bottom too, so good luck with that if you want to make that work as well!
### Emoji: Two Children in a Trench Coat
There are some emoji that are actually two (or more?) characters that render as one. Some examples being flags and basically all emoji that also take a skin tone or some other modifier.
=> https://www.youtube.com/watch?v=sTzp76JXsoY Why Do Flag Emoji Count As Two Characters? - Tom Scott
=> https://emojipedia.org/emoji-zwj-sequence/ A list of emoji with zero-width-joiner support.
What would be the best way to handle them within a selection? I don't know. Do you?
## Tying this back to Moonlander
What was all that about text selection and why did I talk about it for half the page?
Well, Moonlander currently doesn't have any support for text selection. Which primarily means you cannot copy text out. The pages are essentially glorified images.
Links do work in text/gemini, as there are no in-line links in the format, so just the height of a line is enough to figure out if a link should be acted upon, and that is already required for various other functionality in the renderer, so it's trivial to find out.
When I started working on Moonlander, I was somewhat aware of all this, but I thought Pango would have the necessary tools to deal with it for me. But it does not. Or I couldn't find them in my research.
This, combined with the fact that even if it did, I would have to reimplement the selection controls like CTRL-A, CTRL-SHIFT-<arrow key> just killed my interest in continuing to work on Moonlander.
### So, It's Dead?
Maybe. Maybe not.
I am not entirely sure if I will continue working on Moonlander, or just contribute to an already existing client.
If I decide to work on Moonlander though, I will most likely switch to using OS widgets like everyone else. The canvas renderer approach is too much work for little gain, and I am pretty sure I could pull off the fancy-ness of Moonrender³ with some hacks on top of OS widgets.
## Footnotes
1: I should probably add them myself some time.
2: Actually, I am not sure. I think there are couple more clients that do this, but which one came the earliest, I have no clue.
3: Moonrender is the name of the rendering component used in Moonlander. It's totally separate from the Moonlander code, so you should be able to yank it off and continue working on it if you wish. The code is available on the same repository as Moonlander.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com
</content></entry>
</feed>