Really started to like Woodpecker :-) Nicest CI experience so far...

In #kernel QA test applications made with #Rust is one of the better ideas for some time.

Cargo is almost like Docker in this context. I can just compile #BuildRoot image with #cargo baked in, and once the image boots up it can install test apps from cargo.

Super nice approach for doing something more complex than kselftest but going to podman would be over the top...

#rustlang

after a bit of adaptation i feel at home with #woodpecker #ci :-) #codeberg

Using #Storj and local #Nextcloud (one per machine) is actually quite easy:

!/usr/bin/env bash
# Taken from https://fedoramagazine.org/nextcloud-20-on-fedora-linux-with-podman/.

podman network create nextcloud-net
podman volume create nextcloud-app
podman volume create nextcloud-data
podman volume create nextcloud-db

# MariaDB
podman run --detach \
           --env MYSQL_DATABASE=nextcloud \
           --env MYSQL_USER=nextcloud \
           --env MYSQL_PASSWORD=DB_USER_PASSWORD \
           --env MYSQL_ROOT_PASSWORD=DB_ROOT_PASSWORD \
           --volume nextcloud-db:/var/lib/mysql \
           --network nextcloud-net \
           --restart on-failure \
           --name nextcloud-db \
           docker.io/library/mariadb:10

# Nextcloud
podman run --detach \
           --env MYSQL_HOST=nextcloud-db.dns.podman \
           --env MYSQL_DATABASE=nextcloud \
           --env MYSQL_USER=nextcloud \
           --env MYSQL_PASSWORD=DB_USER_PASSWORD \
           --env NEXTCLOUD_ADMIN_USER=NC_ADMIN \
           --env NEXTCLOUD_ADMIN_PASSWORD=NC_PASSWORD \
           --volume nextcloud-app:/var/www/html \
           --volume nextcloud-data:/var/www/html/data \
           --network nextcloud-net \
           --restart on-failure \
           --name nextcloud \
           --publish 8080:80 \
           docker.io/library/nextcloud:20

So no need to use Oracle cloud for this. And instances do not really need to necessarily to sync up given the user count.

I published source code for my #resume here, which is entirely made with Typst:

https://codeberg.org/jarkko/resume

I tried to take extra care properly cover everything with CC-BY-NC-SA-4.0 before publishing it.

The reason why I posted is however this nice small script that I did:

❯ cat scripts/license-photo.sh 
#!/usr/bin/env sh

exiftool \
  -XMP-xmpRights:UsageTerms="CC-BY-NC-SA-4.0" \
  -XMP-xmpRights:WebStatement="https://creativecommons.org/licenses/by-nc-sa/4.0/" \
  images/photo.jpg
exiftool images/photo.jpg | grep -E "^Usage Terms|^Web Statement"

The script injects CC-BY-NC-SA-4.0 as part of the EXIF metadata embedded to the image.

Not doing this would have caused my weird OCD symptoms and sleepless nights ;-)

Ya, and also in this my Git starts with a “merkle commit”:

❯ git log --oneline      
21f8497 (HEAD -> main, origin/main, origin/HEAD) Initial commit
a79299e 

I.e. “the empty set” is public domain and not enforced by CC-BY-NC-SA-4.0 ;-) I like licensing and security borders that are clear and visible…

Alacritty upstream NAK’d my install script so I created a repository for it:

https://codeberg.org/jarkko/alacritty-install

I also modified it to install the icon and desktop file by default with the perfix ~/.local .

Usage:

alacritty-install -h
usage: alacritty-install [-bhp]
-b <wayland|x11> select the rendering backend
-h               usage information
-p <prefix>      select the installation prefix (defaults to '/usr/local')

Just a convenient way to get the bleeding edge binary, which is convenient because typical Rust app is a single fat binary.

for my and your convenience: https://github.com/alacritty/alacritty/pull/8052

#alacritty #upstream #x11 #wayland

A true time saver ;-)

git-init-linux () {
  git config sendemail.envelopeSender "jarkko@kernel.org"
  git config sendemail.from "Jarkko Sakkinen <jarkko@kernel.org>"
  git config sendemail.sendmailCmd "/usr/bin/env msmtp"
}

Given that, I don’t want to keep this in the #global #git config.

#linux #kernel

Moved my test suite to Codeberg: https://lore.kernel.org/linux-integrity/20240618133556.105604-1-jarkko@kernel.org/

#linux #kernel #gitlab #codeberg

My life at the free town of Codeberg (Germany) has started: https://codeberg.org/ticho/irssi-matrix/pulls/8

N=1 in PR's :-)

#codeberg #irssi

apparently also #irssi is hosted at #codeberg: https://codeberg.org/irssi/ #irc

#Wikipedia has a great coverage on what #Codeberg is all about:

https://en.wikipedia.org/wiki/Codeberg

I'd like to see actors like EU and Linux Foundation give some donations/funding/hosting for the sake of providing non-profit but still easy to use and competitive Git hosting for the open source ecosystem (but that is not up to me).

Migrating my stuff from #Github and #Gitlab to #Codeberg. The first successful CI run done. And seems to generate legit results: https://jarkko.codeberg.page/ #Woodpecker #CI

Installed gh (cli.github.com) for the sake of convenience of being able to do this:

gh release download v2.6.0 -R woodpecker-ci/woodpecker

#github #cli

Zbus looks cool: https://dbus2.github.io/zbus/

Early potatoes, herring and egg dip 😛

A typical #TUI #Rust application has usually about ~600 dependencies or similar figure.

A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.

And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷

What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.

Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.

Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...

#rustlang #gcc #llvm #toolchain

I want to my own so called wallet and looking at options of hardware incorporation:

1. TPM2: not feasible since does not handle P256K1 (only P256R1).
2. Hardware crypto wallets (from companies like Ledger): in my opinion worst inventions done during past 20 years. We need open and application agnostic keystore backends, not pollution like these.
3. FIDO2: Yubikey very compelling collection of crypto algorithms and ECC curves, including popular ones for blockchains.

So the choice is somewhat obvious based on this quick feasibility study: I want a FIDO2 wallet.

The next issue. I found this really nice FIDO2 wallet in C++: https://github.com/hoytech/defido2

My next question would be tho does anyone know is the choice of implementation language in this driven by “passion” or something actually preventing to do this using W3C API’s for FIDO2?

Does W3C API e.g. block some ECC curve types that my Yubikey might support?

#blockchain #wallet #w3c #fido2 #ethereum

Since I switched from #Dropbox to #Storj, I’ve been almost solely using rclone.

Now I’ve started to feel that t it would be nice to have also an ownCloud instance and point out its storage to my #S3 bucket at Storj.

After looking through cloud options, I think got with ARM Ampere A1 VM: that #Oracle offers:

“Up to 4 instances of ARM Ampere A1 Compute with 3,000 OCPU hours and 18,000 GB hours per month”

Should scale a to my personal ownCloud with storage backend at Storj. The amount of OCPU hours nailed this really…

Just paid 40 EUR annual bill for my Kapsi SSH account. It is the center piece of my digital life :-)

Kapsi has a IMAP inbox for my personal email and kernel.org mail (the same inbox is shared via RFC 5233 sub-addressing ), IRC screen (tmux), sometimes bots (tmux), exposing files via https URL’s (sometimes more feasible than e.g. dropbox shared links). It also provides for each user 50 GiB of backed up quota (with self-restore) and 500 GiB of space “in your own responsibility”.

Servers are hardened with quite reasonable standards and some of the people at Kapsi maintaining the backend actually know what they are doing when it comes to #infosec ;-)

It just continues to amaze me how dirt cheap this service is… and how awesome it is :-)

#Kapsi #Oulu #Finland

-