zirias

zirias, 13 days ago

@jhx Makes sense to me 😉 I guess I couldn't really fall for that because I started exploring "alternative" x86-PC operating systems in a time before internet at home was a common thing, let alone with a speed suitable for downloading larger software distributions 😁 (plus getting some "Linux distribution" to work correctly on your machine was a lot more work, e.g. no way to do this without manually editing a monolithic config file for #XFree86 if you wanted a GUI). So you were thinking twice before "starting over" 😅

I started with some old #SUSE, because that came bundled on a 💿(!) with some magazine. Soon I wasn't happy how its "yast" tool fought over changing all sorts of config files etc ...

Also found #Debian first on some magazine disc (2.1 "slink") and managed to install this as a server offering a few services. For the desktop, I tried #Mandrake for a while, back then it was one of the few with largely working and sane auto-configurations... but as #Debian just felt better (simple and powerful management tools you could understand, so they didn't interfer with your manual configurations), I finally got that on the desktop as well. Stayed with that for a long time until it grew in complexity and I had hard to solve issues (also related to #systemd when it was first introduced in Debian), so looking for alternative, I figured it was time to say goodbye to Linux. Tried #FreeBSD and this worked awesome for me! For some software, you need Linux, and when I do, Debian is still my choice...

In general, I developed a habit of never changing stuff "just for the sake of it", only when I can name things I'm unhappy with. So for example, I use neomutt instead of mutt now (lots of added features I like that were only available as unofficial patches for mutt), but when people tell my I should try neovim, I just ask myself, why? After all, I'm perfectly happy with vim.

So I also never tried #wayland so far, because I see no need for my usecase, as #Xorg works perfectly fine for me. Currently even experimenting with programming #X11 "directly" (using #xcb) instead of using some UI toolkit. 🙈 Of course, in C only -- there's little you can't do in that veteran language 😎

zirias, 13 days ago

@jhx I already discovered a strange "fact" (probably better called bug): If you render some color glyphs to a 32bit (ARGB) offscreen pixmap and then use this pixmap as a source for alpha-blending the same glyphs to a 24bit window surface, you get a random number of randomly sized undrawn rectangles in the result. 😖 Of course, no idea where this bug is located (core Xorg, XRender, DRI, maybe even my GPU driver, ...?). XRender seems most likely though ... a shame development stopped in 2009 at XRender 0.11 😕

I can avoid that by just using a 24bit pixmap (without alpha channel). I don't need one as long as the glyphs themselves don't need to look translucent 😂

zirias, 1 month ago

@txt_file Didn't you know, to build software you absolutely need npm, cargo, nuget, pip, .... and MAKE SURE to always specify EXACT VERSIONS, you can easily deploy all that stuff with snap, appimage, flatpak, or better play it safe and just deploy docker images!!!!

Ladies&Gentlemen: #softwarecrisis #reloaded

zirias, 1 month ago

Let's start with my most recent opensource dev-project:

#qXmoji is an #X11 #emoji #keyboard. Although it uses #Qt for its GUI, the mechanism to "type" emojis is pure X11. This means any X11 client can receive them (whether that client can correctly display them is an entirely different issue 🙈) ... not even #XIM awarenesss is needed.

The mechanism to inject fake "emoji keyboard events" is quite hacky and dirty, but it works!

https://github.com/Zirias/qxmoji

Not sure whether I should add it to #FreeBSD ports, but if you want to try it, here's a patch for the ports tree:
https://people.freebsd.org/~zirias/patches/0001-x11-qxmoji-Add-new-port.patch

zirias, 1 month ago

Also quite recent: #dos2ansi. This is a very versatile converter for #MSDOS #ansiart (and other "text") files to a format using #Unicode and only standard #ANSI #SGR escape sequences, so, suitable for today's terminals like #xterm. It includes an ansiart viewer which is "just" a shellscript, leveraging dos2ansi, xterm, less and some nice original #IBM fonts to do its job. So, maybe something for the #retrocomputing fans.

https://github.com/Zirias/dos2ansi

Docs (manpages) are here:
https://zirias.github.io/dos2ansi/

As there was some interest, a #FreeBSD port is available: https://www.freshports.org/converters/dos2ansi

zirias, 1 month ago

Fun fact, if you're a #FreeBSD #desktop user, chances are you're already using the arguably tiniest of my opensource projects: unix-selfauth-helper 😎

https://github.com/Zirias/unix-selfauth-helper

It's needed for quite some popular "screen lockers" that just assume a (IMHO pretty dirty) #Linux (LinuxPAM) solution to be available.

zirias, 1 month ago

Jumping to something completely different:

Unfortunately this project is stalled, I hope to find the time to continue it. Here's a #C64 conversion of an old #Amiga type-in game found in some german magazine (AmigaBASIC). It's pure #mos6502 #assembly and actually adds lots of features to the original (like a score, like music, like fast scrolling and fast movements ... btw the sound/music code is also hand-written, no tracker used).

So, here's #stoneage64, preview-2:
https://csdb.dk/release/?id=228828

video/mp4

zirias, 1 month ago

One of my "dream projects" (maybe after retirement 🙈😁) would be to create yet another :commodore: #C64 OS. One that works on a vanilla unextended machine.

There are quite a few around of course. To make something meaningful, you have to think about what could give #retrocomputing enthusiasts an excuse to use their breadbin once in a while 😏

I think it should just support very basic #Internet service clients, like Email, IRC, BBS (via TCP), ... of course this means to require one hardware extension (apart from your obligatory floppy drive): Some #ethernet (or wifi) hardware. There are a few around, so "drivers" for those would be needed.

This sets the baseline of features required. Multitasking will probably be unavoidable (clients need to be able to do stuff "in the background", like e.g. respond to IRC PING messages). There's already a LOT of complexity attached to that requirement. You'll need an executable format with relocation info, and a program loader doing the relocation on startup of a new process. You'll need a concept how to deal with the tiny hardware stack (partition it, relying on apps not to overflow? copy it around on each context switch?). You'll need a concept how to dynamically allocate memory (probably just page-wise). And so on.

A windowing system IMHO makes no sense at all on that machine. The UI should focus on text (maybe a set of virtual consoles?). Support for GUI apps might be possible, but then only "full-screen". 🤔

Well, just some thoughts, dreaming along 😄