zirias (on snac)

Dipl.inform., FreeBSD ports committer, musician, C64 fan/coder, hetero cis white male, not proud, no wing, no ally, leaning liberal/ecologist, pro facts/science

Public Key

npub1w96l7dwwzzmd6taq8qzhgh80hdsad2y0shrank8whyrksa2fkwasz99l6c

NIP-05 Address

zirias_at_snac.bsd.cafe@f.sprovoost.nl

Profile Code

nprofile1qqs8za0lxh8ppdka97srspt5tnhmkcwk4z8ct37emrhtjpmgw4ym8wcvt9p3d

Author Public Key

npub1w96l7dwwzzmd6taq8qzhgh80hdsad2y0shrank8whyrksa2fkwasz99l6c

Show more details

Last Notes

2024-10-05 06:15:46

Coding in #C ... sometimes I really enjoy just using what I created a long time ago 😁.
This is the whole change to #Xmoji allowing it to fork into background on startup:
https://github.com/Zirias/xmoji/commit/0ab2d8ed424ebc35aa99e5c2bd15b097a5e74b42
It's the first step to implementing an (optional) single-instance mode, that will only allow one running instance per user and machine. Implementing that will require a local #Unix domain #socket, which is also covered by the same library, #poser 😉.
I designed this library for (simple and small) #networking #daemons, but found it's quite useful for #X11 applications as well. If you want to know more, here are the docs:
https://zirias.github.io/poser/

2024-10-04 14:40:03

- reply

While #Unicode explicitly allows them, it seems #Mastodon doesn't consider #Emojis to be useful in a #hashtag ... and I tend to agree, I mean, these are for indexing, they should be easy to both type and read. 🤷
In the end, I wouldn't mind emojis allowed either. I ran into #snac2 accepting "too much" first when putting a hashtag directly in front of ). Looking for how to fix it, I search mastodon docs, because I think it would be most useful to have the same policies like mastodon. Now just awaiting review of my PR 😉
CC: @npub17uw…5ywz

2024-10-04 12:39:42

- reply

Ok, I can get it to work on #OpenBSD by using TRE as a drop-in replacement for the system's #regex functions:
https://github.com/laurikari/tre/tree/master
CC: @npub17uw…5ywz

2024-10-04 12:17:46

- reply

No good. 😞
Doesn't work on #OpenBSD. Their #regex implementation supports only the ctype.h character classes. I guess they might have some "security" argument against implementing #multibyte character support there 🙄
Back to square one then. Might be possible to optionally use some external #POSIX regex library. Maybe better to aim for a more complete solution though...
CC: @npub17uw…5ywz

2024-10-04 11:13:34

- reply

On the bright side, #mastodon's definition seems to be easily implemented using character classes in #POSIX extended regular expressions, as long as the #locale uses #UTF8. I tested #FreeBSD and #NetBSD so far, let's see how #OpenBSD and #GNU work out...

2024-10-04 11:06:17

- reply

Unfortunately, that's
not supported in your typical libc, so you'd need another library (I guess icu could help)
also not in line with the simple definition from #mastodon docs, where only alphanumeric characters + underscore are allowed and "only digits" are forbidden...
😞

2024-10-04 10:44:11

Entering the rabbit hole, I'm trying to fix the first real issue I ran into using #snac – it accepts far too many characters for hashtags.
You know, #Unicode and #UTF8 can be a major #PITA to work with, and a specification like "a hashtag consists of alphanumeric characters plus underscore", as simple as it sounds, can be quite challenging to "get right"... but so far it looks like there could actually be a somewhat simple fix, still WIP:
https://codeberg.org/grunfink/snac2/pulls/202
I really enjoy using #snac2 so far (thanks @npub17uw…5ywz for offering that instance!), that's why I immediately try to fix stuff 😉

2024-10-04 07:45:05

- reply

Nice, that looks like the way to do it!
"Funny" how it even offers a libc for compatibility ... but I guess this helps getting it some more serious testing 😉

2024-10-04 07:37:37

- reply

When the answer to major draw backs with a language is use it better that’s a dead end for me.
Try browsing the list of somewhat recent #CVE rated critical, as I just did to verify. A majority of them is not related to any memory errors. Will you tell all them "just use a different programming language"?
And again with OOP. Why hack it into a language rather than use a language that supports it.
Have you seen existing C code? For anything non-trivial, most code uses some OOP, and it comes quite natural in C, certainly no "hacking". You don't need a class keyword to do that.
If it came out today you’d have an incredibly hard time convincing anyone to use it over other languages.
It doesn't come out today, it's been there for a long time, and it's standardized, proven and stable. Sounds like you seriously misunderstood my points, which were, in a nutshell: For applications and similar, just use whatever suits you; for operating systems do experiments in lab/research projects (as was done with Unix), because existing and established ones are relied upon by lots of software. Just to make that perfectly clear, that doesn't mean they should use C forever, it means they should wait for a potential replacement to reach a similar state of stability with independent standards and competing implementations.

2024-10-04 06:26:07

- reply

I'd say if you're happy with #C, there's no need to choose any second language. 🤷
Before even looking at any alternatives, the question should be "why not C". Some of the typical complaints are:
memory safety – or, more generally, the fact that C is only partially defined, leaving a lot to the dangerous area of undefined behavior. There's no way to reliably detect undefined behavior by static code analysis, and it will often hide well at runtime. Especially errors regarding memory management often directly expose security vulnerabilities. In my experience, the risk can be reduced a lot by some good coding and design practices. Examples are avoiding magic numbers, using sizeof everywhere possible, preferably on expressions instead of type names, defining clear ownership of allocated objects (and, where not possible, add manual reference counting), making ownership explicit by using const where appropriate and naming your functions well, and so on. Given also there's no guarantee alternative languages will safeguard you from all the possible issues and there are also a lot of other ways to create security vulnerabilities, my take on this would be: partially valid.
programming paradigm – you can only program in classic procedural style. Well, that's simply not true. First of all, you can program whatever you want in any turing-complete language, so what we talk about shouldn't be what's directly supported by the constructs of the language, but what's practically usable. In C, using some simple OOP is commonplace. Well, you can apply OOP to assembler programming without too much hassle, so, it's not surprising you can do it in C, as it's a pretty thin abstraction on top of machine code. C helps further with its linkage rules, where everything in a compilation unit is by default inaccessible to other units, and its incomplete types, where only a type name is known, but neither its size nor inner structure, giving you almost perfect information hiding for free. If you want/need polymorphism, it gets a bit more complicated (you have to think about how you identify types and manage virtual tables for them), but still perfectly doable. You'll hit the practical limits of the language when you want to go functional. The very basics are possible through function pointers, but most concepts of functional programming can't be applied to C in a somewhat sane way. Unless that's what you need, my take would be: invalid.
limited standard lib. Indeed, the C standard library misses lots of things that are often needed, for example generic containers like lists, hashtables, queues, etc. It's straight-forward to build them yourself, but then, there are many ways to do that (with pros and cons). You'll find tons of different implementations, many non-trivial libraries bring their own, of course this also increases the risk to run into buggy ones ... I wouldn't consider it a showstopper, but I'd mark this complaint as: valid.
Then, the next question would be: For what purpose are you looking for a second language?
For applications and services, there's already a wide range of languages used, and I'd say do what everyone does and pick what you're most comfortable with and/or think best suits the job. IOW, it makes little sense to ask what would be "the future", there have always been many different languages used, just pick one that's unlikely to quickly disappear again, so you'd have to restart from scratch.
For systems programming "the future" has been C for many decades 😏 ... some people want to change that, actually for good reasons. IMHO, the current push for #Rust (I don't see anything similar regarding #Zig yet?) into established operating systems is dangerous. An operating system is very different from individual apps and services. It's required by these as a reliable and stable (in terms of no breaking changes) platform. It's complex and evolves over an extremely long period of time. It needs to interface with all sorts of hardware using all sorts of machine mechanisms (PIO, DMA, MMIO, etc pp). I conclude it needs a very stable, proven and durable programming language. You'll find C code from the 30 years ago that just still builds and works. IMHO a key factor is that there's an international standard for the C language, governed by a standards body that isn't controlled by any individual group. And correlated to that, there are many different implementations of the language. Before considering any different language in core areas of an established operating system, I'd like to see similar for that new language.
Now, C was developed more or less together with #Unix, so back then, nobody knew it would be such a success, of course there was no standard yet. But then, I think this is the sane way to introduce a new systems programming language: Use it in a new (research?) OS.

2024-10-03 08:55:46

- reply

Thanks for that! Just to clarify, the versioning scheme in the tags is always v<major>.<minor>[-<patchlevel>]. Is this inconvenient for #nix packaging? 🤔

2024-10-03 06:41:49

- reply

Hehe. The very minimalistic #snac implements some basic #markdown and also allows some specific #HTML tags. And the original #mastodon still does not (but at least accepts a basic subset of HTML for incoming toots...). It's kind of ridiculous 😂

2024-10-03 05:40:53

Party time! 🥳🍻
#Xmoji just reached 100 stars on Github 😁. Yes, I'm really happy to see people like the software, thanks for showing that!
As a little reminder, I'm still looking for help, especially for translating it to other languages. https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md should get you started. 😉
It would also be nice to have more official packages available. So far, I just know about #FreeBSD (done by myself), #NetBSD's pksrc and a #NixOS package that was outdated last time I checked... 🤔
https://github.com/Zirias/xmoji
#X11 #emoji #keyboard
https://snac.bsd.cafe/zirias/s/1e866fe434950dd221b31e0779c6c957.png

2024-10-03 05:32:32

- reply

Sure, that's yet another aspect. #Javascript (#ECMAscript to be precise) evolved a lot. Where we came from was a very limited standard and browsers doing their own incompatible thing, also adding "random" bugs, which btw triggered development of #jQuery, back then an extremely helpful thing, nowadays more or less obsolete. I'm sure writing a well-working #SPA with nothing but vanilla JS is perfectly possible these days, it just requires some planning and design, you'd probably end up with a (minimal and tailored to your needs) "framework" as part of your project. But from my experience, most "frontend devs" are indoctrinated into a strong belief you absolutely need super-fat frameworks for everything.
What I was talking about is that these you mentioned (React, Angular) are designed with nothing but SPA in mind. So, everything will end up being an SPA, which just makes no sense for 95% of "web apps". There's a nice set of architecture guidelines for web apps called #ROCA, which is in line with the initial design of #http and the web in general: https://roca-style.org/ -- and then, you decided in your organization to follow that, you have the need for some enhanced UI components in JS, and these frontend guys basically keep telling you "we need our awesome framework here". Oh boy. 🤦
In the end, I see the resident set of my local browser and have no questions left...

2024-10-02 17:48:57

- reply

Try #Tusky, seems to work fine for me with one slightly annoying glitch, a new notification causes lots of previous ones to reappear (probably some issue with an offset in a feed not working as expected by the client ...)
CC: @npub17uw…5ywz

2024-10-02 17:43:17

- reply

Side note, it's not so much React, Angular, Vue or whatever that sucks, it's the concept behind: #SPA. Or, more precisely, that concept used not in a niche where it belongs, but for every damn web site, or classic form-based web app. I remember getting into some very weird arguments with "frontend devs" over a simple demo class I wrote in vanilla JS to "enhance" a standard browser control (so, it still worked without a script). This class was pretty short and clean. Still they insisted it would be "hard" to program like that. It seems they can't do the simplest things any more without the help of their massive shitloads of "frameworks". And then, everything is a stupid SPA in the end, completely breaking the logical design of the web.
Ok, back to admiring the pure elegance of #C, sorry 😂
CC: @npub1fqc…u0q0 @npub1egd…fksn

2024-10-02 16:38:23

- reply

Ah, nice. I just deprecated #qXmoji, now that #Xmoji has all the "important" features (and more). Didn't even know someone packaged it for AUR.
In general, I've seen very mixed quality in AUR, unfortunately. If #Xmoji appears there, I should notice (thanks to #repology) and review what was done 😁

2024-10-02 16:23:42

- reply

Thanks a lot! 😃
I'm curious, on which OS did you test it?

2024-10-02 11:42:51

You might have noticed development of #Xmoji slowed down a bit. My time is currently very limited, but another reason is slowly closing in on a version 1.0, and I want to give it some time for proper testing.
I need your help, please! 😁
Xmoji 0.8 introduced an important part for #i18n, translations. But I'm not exactly fluent in many languages. Please, if you can, help me translate! The process is documented in TRANSLATE.md" target="_blank">https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md">TRANSLATE.md. If there are any issues with these instructions, please let me know.
Xmoji aims to be the "best" tool to input emojis with "pure" X11:
Written in plain #C, with minimal dependencies
Uses #Xrender for its UI, communicates with the X server using #xcb
Offers two methods for input: Faked keyboard events or the "primary selection"
Has a search tab and a list of recently used emojis
Customizable appearance using X resources
Several options to configure key injection and the search method
Roadmap to V1.0:
Optional single-instance mode
Optional tray icon
#X11 #emoji #keyboard
https://snac.bsd.cafe/zirias/s/091a55eadb43e62f4d9016fe00ab14c3.png

2024-10-02 10:00:43

- reply

Ok, simplified and improved my script a bit, now looks like this, including a hack to prevent the default style from showing:
// ==UserScript==
// @name snaccss
// @namespace http://tampermonkey.net/
// @version 2024-10-02
// @description custom snac styling
// @author zirias
// @match https://snac.bsd.cafe/*
// @icon https://www.google.com/s2/favicons?sz=64&domain=bsd.cafe
// @grant GM_xmlhttpRequest
// @connect codeberg.org
// @run-at document-start
// ==/UserScript==
(function() {
document.getElementsByTagName("body")[0].style.display = "none";
GM.xmlHttpRequest({
method: "GET",
url: "https://codeberg.org/voron/snac-style/raw/branch/master/next.css",
onload: function(response) {
if (response.readyState == 4 && response.status == 200) {
document.getElementsByTagName("style")[0].innerHTML = response.responseText;
document.getElementsByTagName("body")[0].style.display = "inherit";
}
}
});
})();
I found I prefer the "next" theme 🙂 It features media-selectors for dark/light ...
CC: @npub1kp9…6zu2 @npub17uw…5ywz @npub18x6…uph7
https://snac.bsd.cafe/zirias/s/4b2deaefeea700be630f6bc1d59e5ba3.png

2024-10-02 09:30:40

- reply

Sure. I've now scripted a bit for #tampermonkey, achieving similar:
GM.xmlHttpRequest({
method: 'GET',
url: 'https://codeberg.org/voron/snac-style/raw/branch/master/modern-dark.css',
onload: function(response) {
if (response.readyState == 4 && response.status == 200) {
var style = document.createElement('style');
style.type = 'text/css';
style.innerHTML = response.responseText;
document.getElementsByTagName('style')[0].replaceWith(style);
}
}
});
But that's more of a workaround. E.g. I don't always have "my" browser with me 😉
CC: @npub17uw…5ywz @npub18x6…uph7 @npub10th…wqra

2024-10-02 07:27:17

- reply

As we have only two active users on that instance (you and @modev ), just tell me which you prefer and I'll install it.
Ok, theming support is nice, letting the user pick one of the installed themes would be even nicer 😉
CC: @npub1kp9…6zu2 @npub18x6…uph7 @npub10th…wqra

2024-10-02 07:16:50

- reply

After a bit of experimentation, I'm starting to form an opinion:
Yes, I do like this web interface for being clean and simple and following the original design of the web and http: You have addressable resources, you have verbs on them.
I still think there's room for improvement:
- It would be nice to have resources for local copies of toots. It seems there's just a link to their original location right now.
- Some custom styling would be nice as well (e.g. I don't like the monospace font everywhere and would prefer to have it only for code blocks). Could be as simple as an optional CSS snippet in your local account settings.
- A little bit of progressive enhancement (using the APIs already there, see also ROCA) wouldn't hurt, e.g. to optionally improve the search and similar, as long as the basic structure and script-free functionality remains.
Also, unrelated to the web UI, it seems #snac doesn't allow following hashtags, that's something I miss :(
CC: @npub17uw…5ywz @npub18x6…uph7

2024-10-02 05:06:12

- reply

Is this an abandoned project? 🤔 the Github project shows "archived"...
CC: @npub18x6…uph7

2024-10-01 19:05:09

- reply

@npub1kp9…6zu2 @npub17uw…5ywz @npub18x6…uph7 looks perfectly suitable for a hidden service as well ...

2024-10-01 18:58:08

- reply

@npub1w96…9l6c @npub17uw…5ywz @npub18x6…uph7 nice, #Tusky can login as well!

2024-10-01 18:46:02

Hehe. Following people on #snac, the lazy way ✅
for actor in $(sed -e 's:,.*::' -e 's:@:%40:' </tmp/following_accounts.csv); do
curl -v "https://snac.bsd.cafe/zirias/admin/action" \
-H 'Authorization: Basic XXXXXXXXXXXXXXXXXXXX' \
--data-raw "actor=${actor}&action=Follow"
done
CC @npub17uw…5ywz @npub18x6…uph7

2024-10-01 17:59:35

Testing #snac, looking at the manuals ...
.Ss Message Formatting
Message notes respect the entered new line breaks rigurously.
A special subset of Markdown is allowed, including:
.Bl -tag -width tenletters
.It bold
**text between two pairs of asterisks**
seriously? Awesome! 🤩