MdLogGen

Post by Nico Brailovsky @ 2024-02-25 | Permalink | Leave a comment

If you're reading this, you somehow found me at nicolasbrailo.github.io. Maybe you came here from one of my many previous blogs, and you're marveling at the beautiful new design (?). As I alluded to in the "moved again" note, this site is built from a source of md files, using a custom md-to-html enginge. If you're sane, you're probably why I would create an md-to-html engine, instead of using one of the many available options.

MdlogGen: yet another MD site generator

MdlogGen is a simple md-to-static-html, however it supports a few features I wasn't able to find elsewhere: comments, and site-search. MdlogGen depends on Github for these two features (or, rather, depends on the viewer to have a Github account to be able to use these two features).

MdlogGen also supports the exact feature set I need, no more and no less; while using an off-the-shelf generator may have been a better longer term investment, 90% for the raison d'etre of this site is "for fun", and spending a weekend writing hacky code is more fun than spending a weekend trying to figure out how to configure Github deploy rules, and learning to use a third party content generator. I get to write enough code for a living during the week - weekends are for fun code! An alternate reason is that I already had to spend a chunk of time cleaning XML exports from my previous sites to build this one - so MdlogGen is sort of a natural evolution of those scripts. Kind of.

Check out MdlogGen's reamde: while many other md-to-html generators exist, I think this may be one of the simplest feature-complete generators out there.

Bash tip: expand args

Post by Nico Brailovsky @ 2024-02-25 | Permalink | Leave a comment

If you're writing a script and it looks like this

your_bin --arg1 \
         --arg2=123 \
         --arg3=345 \
         --arg4...

It can get pretty ugly to maintain. Instead, try this:

many_args=(
  --arg1
  --arg2=123
  --arg3=345
  --arg4...
)
your_bin "${many_args[@]}"

Fix "slow" Grub

Post by Nico Brailovsky @ 2024-02-23 | Permalink | Leave a comment

Grub tends to be setup-and-forget, so this is a tip that should be useless. Except when things break.

I noticed while fixing a computer that Grub was "slow" - each keystroke would take about half a second to show up on the screen, give or take a hundred ms, and it wouldn't even queue my keystrokes (leading to skipped keys, and even more frustrating sessions of backspace-backspace-backspace, fix-fix-fix, repeat). This seems to be related to Grub running in a very high resolution, which should be entirely unnecessary - I don't care about 4K boot menus, nor about 4K boot splash screens that will be displayed for a second or two.

To fix slow-Grub, it's enough to tell it to stick to a more terminal-friendly resolution. Debian-based example:

Add this to /etc/default/grub

GRUB_GFXMODE=1024x768
GRUB_CMDLINE_LINUX_DEFAULT="nosplash verbose debug nomodeset"

Then run update-grub. Next boot up Grub input should behave in a sane way again.

Extra tip: Increase terminal font size without murking in Grub

If you got past Grub, you're probably booting into 4K mode terminals, and texts that are but a few millimiters high. You can increase your terminal font size, before ever going to a graphical interface:

setfont /usr/share/consolefonts/Uni3-Terminus32x16.psf.gz

Extra extra tip: Kernel arcana

If you're reading this, you're probably looking for debug verbose nomodeset earlyprintk=vga loglevel=7 ignore_loglevel

How to: UEFI shell

Post by Nico Brailovsky @ 2024-02-20 | Permalink | Leave a comment

There are countless "how to use an UEFI shell" notes out there, but this is the cheatsheet I tend to use:

# Set video to 80cols 50 rows, so it's less tiny in a 4k screen
mode 80 50
# Show pci device tree. Eg to find the VGA controller
devtree
# Show all things that have a FS may be bootable
map
# Refresh list of devices, if a new one is connected
map -r
# Show maybe bootable things that look like a usb
map -t cdrom
# Inspect a fs attached to a mapping (eg when looking at fs0, from the output of §map§)
# Case sensitive, uses fwd slashes and not back slashes
ls fs0:
ls fs0:EFI\BOOT\
# Moving around: first select mapped device, eg
fs1:
# Then cd and ls works
cd efi
ls

Eg to boot a Debian live USB on my setup

shell> mode 80 50
shell> map  -t cdrom
shell> FS0:
shell> FS0:
FS0:> cd efi\boot
FS0:\efi\boot> ./grubx64.efi

Move again

Post by Nico Brailovsky @ 2024-02-18 | Permalink | Leave a comment

I'm now at nicolasbrailo.github.io. If I count platform, domain or tech-stack changes as a migration, I've now lost count of how many this site has had. It's the third one in the last few years. I moved away from WP because I wasn't happy with the sponsored content added to my site. I also wasn't happy with Blogger, I never quite like the interface, the way to write posts, or the customization options.

This site now came full circle: it started as a self-hosted php bundle, and it's now a kind-of-self-hosted static html site, generated from .md files in Github. I figured I'm the person who reads this site the most, so I should like it. I'm a nerd, so I like writing code; hence the custom md-to-html converter, about which I should blog some time soon. This is also only meant as a fun project (and a great self-reminder mechanism, persistent through the decades) so why not reinvent the wheel, and create a custom md-to-html renderer for it?

ToDo

Fun stats

Fix Spotify deeplinking in Linux + custom SpotiWeb UI

Post by Nico Brailovsky @ 2023-12-16 | Permalink | Leave a comment

After a recent update I found my custom Spotify UI (*) wasn't working. The way my custom UI works is by generating a simple list of followed artists, and then playing in the native app by using deep-linking. A recent update seems to have broken this in Linux based OSes, so here's my fix:

sudo mv /usr/share/spotify/spotify /usr/share/spotify/spotify.real
sudo echo '/usr/share/spotify/spotify.real --uri="$1"' > /usr/share/spotify/spotify

Seems old versions of spotify would try to open anything as a deeplink, but new versions require a --uri parameter on argv. Surely there is a cleaner way of doing this in xdg-open, but I'm too lazy to read manuals.

In the "reminder to myself" category, as there is zero chance I'll remember this next time I'm setting up a computer.

(*) SpotiWeb: custom Spotify UI

I don't like "recent" changes (recent being the last 3 or 4 years!) to Spotify's UI, so I rolled out my own. It's a plain, boring, unobtrusive view of all your followed artists, grouped by categories. It also runs in any browser and is extremely minimalist (doesn't even have a search function: you can use the browser's search if you need one!)

The app is hosted in github pages, and because it's entirely client side it doesn't need any kind of server side support to run. Check out the source here and either run your own, or check out there's no server side processing involved.

Translated to Chinese!

Post by Nico Brailovsky @ 2023-01-14 | Permalink | Leave a comment

Small celebratory post, because I never expected it:

Someone translated one of my open source projects to Chinese!

Bash script preamble

Post by Nico Brailovsky @ 2021-06-27 | Permalink | Leave a comment

All background Bash scripts should start with this preamble:

set -euo pipefail
exec > ~/log.log 2>&1

There are countless articles explaining why, and the main purpose of this one is a reminder for myself, so I won't go into the details. For reference:

Where is the fun in that?

Post by Nico Brailovsky @ 2021-03-18 | Permalink | Leave a comment

You can always find coders asking why coding isn't fun anymore. I can somewhat relate but I never understood why the answer isn't obvious: coding isn't software engineering. When you go from coding to engineering, the focus changes. A lot of the interesting stuff is there, but there's also not-interesting-stuff in the mix. Maybe testing and documenting isn't your thing, you just want to build something. Maybe the stability from testing and documenting isn't that important to you. Perhaps you know you're the only one who's ever going to read your code. Your future self may be angry at you for a little while if the code breaks... so what? Your experiment crashed? Just reboot it. No problem.

If you're coding-to-sell, you're not writing code for yourself. You write for a team, even if that team is only you and future-you. You write it so it may scale and adapt to new requirements. You write it to survive a bit more than a weekend, and to be stable. You're not writing code to learn new things, that's only a nice side-effect; you are trying to build a product.

Furthermore, you're not investing time to learn something or just to have fun; you're trading time for money (if you learn something in the process, that's good - but probably not why you're being paid a salary as a software engineer).

It's understandable that parts of software engineering are not as fun as it was hacking in a basement while you were a kid. There is still a very big overlap, but it's not just the same activity. Myself, I try to focus on the fun parts and just have discipline to get the boring parts out of the way. I usually work in places where the balance is fairly decent, and it's kept me interested in software development for the last 15 (ish) years. I'm hoping it'll do the trick for much longer than that.

reboot succesful?

Post by Nico Brailovsky @ 2021-03-17 | Permalink | Leave a comment

Since "migrating" from Wordpress to Blogspot:

That went much better than I expected, considering I couldn't set up a proper HTTP301-permanently moved (WP charges you for that, which IMO is slight extortionate for a site I don't want to monetize). Let's see how it goes 10 years from now, when I have to migrate from Blogpost to something else.