101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

496
active users

I think we need to mirror OSSP before it goes offline forever

@mirabilos you're old so you probably love CVS. do you have a favourite CVS-to-git importer?

150 Opening BINARY mode data connection for IAFA-DESCRIPT (220 bytes)
Description:
This site is the official Internet FTP server of the OSSP project.
Its location is Munich, Germany (Longitude 48 16 N / Latitude 11 26 E)
Internet connection is provided by a 10Mbit/s link.

10Mbps 🥺 (ls (which, despite this being FTP, looks like actual ls -l lol), says May 30 2000)

this is the flakiest FTP server on the planet. im gonna fucking die

i can semi-consistently get one request out of it, unless it's ls then it's a quarter

okay, lftp gets one solid request per connection, and its mirror command works so far..... and it died while writing this

active-mode FTP from my router works through a dozen EADDRINUSE retries per file. amazing stuff

$ git -C ossp-uuid.git/ log
commit e83b6b64d1d9215bc38f12798cc1aad41dd33559 (HEAD -> master)
Author: rse <>
Date: Sat Jul 5 12:58:24 2008 +0000

remove OSSP uuid from CVS -- it is now versioned controlled in a Monotone repository
$ git -C ossp-uuid.git/ ls-tree HEAD
$

yes he removed everything and didn't link the monotone repo. naturally monotone.ca has been unchanged for like a decade, and package removed since buster

monotone.camonotone

dont worry they also made an actual hell

OSSP due - Dynamic User Environment
OSSP due is a unified and dynamic GNU Bash shell and Vim editor user
environment providing reusable functionalities which proofed to be
useful in practice.
git.sr.ht/~nabijaczleweli/ossp

I had to read through all of these to come up with repository descriptions, so here's some more ones i liked:
OSSP sugar -- The Markup Language With Invisible Syntactic Sugar
OSSP sugar is a markup language and corresponding processing tool for
writing technical documentation that uses a mostly invisible markup
language (so-called "syntactic sugar" in compiler construction folk
terminology).
bro WHAT are you TALKING about (this actually appears to be an early markdown/rST-style system: git.sr.ht/~nabijaczleweli/ossp)

OSSP svs - Stupid/Silly/Simple Versioning System
its incredible what mfs did to themselves before they had git, also
case "$cmd" in
v|vi|vim | e|em|ema|emac|emacs )
always execs ${EDITOR-vi} (git.sr.ht/~nabijaczleweli/ossp)

OSSP val - Value Access
OSSP val is a flexible name to value mapping library for ISO-C
variables. It allows one to access ISO-C variables through name
strings, [...]
what the fuck is an "ISO C variable" (this is actually a std::map<string, any>, but not very good git.sr.ht/~nabijaczleweli/ossp)

OSSP cfg is a ISO-C library for parsing arbitrary C/C++-style configuration files
...parsing what? this appears to actually be a grammar compiler, unclear how this is configuration-related git.sr.ht/~nabijaczleweli/ossp

this also makes me the upstream for src:eperl, src:iselect, and src:osspsa. 4/54 after 20 years is pretty good though

this user is

of COURSE this shit is not UTF-8 lol

i have the usual Jörg, of course, but the remark on 81 (cvs.ossp.org/tktview?tn=81,4) expresses '—' as 0x97 somehow?

cvs.ossp.orgOSSP: CVS Repository: Ticket #81

lol, file(1) guesses ISO-8859 but this website is somehow CP1252 💀

aand i've done more upstream development than anyone in the past 15 years lol todo.sr.ht/~nabijaczleweli/oss

I've instrumented the shart list importer

Error ("<20020828091907.W2689@canonware.com>") reading In-Reply-To: mail: missing '<' in msg-id
Error ("<20020730130258.A71796@canonware.com>") reading In-Reply-To: mail: missing '<' in msg-id
<20020703134036.GC1464@dt4.dev.de.cw.net> unknown charset: unknown charset: message: unhandled charset "iso-8859-1"
Error ("<20020523115704.D22880@dev14.dev.de.cw.net>") reading In-Reply-To: mail: missing '<' in msg-id

and indeed,
> In-Reply-To: <3D6BE829.CEEA7B8C@packetdesign.com>; from archie@packetdesign.com on Tue, Aug 27, 2002 at 01:59:21PM -0700

bruh.

the ISO8859 encoding thing is much worse because it doesn't affect like 5 mails and i can edit the spool manually to turn "; from" into "(from)", it affects 5000

amazing, anonymously importing "github.com/emersion/go-message/charset" automatically decodes non-UTF-8 mails

and it seems like the listssrht api program already does this(?)

i think i was hitting some internal timeouts with the big ossp-cvs spools, current status: csplit /^From / {*}; for f in *; do curl .../import -F spool=$f 💀

if hut(1) exposed an endpoint that posted the spool i'd be using it. alas! "copy as curl" to the rescue

i may be the first and only power-user of SourceHut, the everything app

time to install alpine and sourcehut (meta and lists): 60 minutes (this is my third time (they keep breaking my old VMs))

had to do this because i managed to import /most/ of these, but not /all/

log says

2024/09/05 01:25:59 "POST http://127.0.0.1:5106/query HTTP/1.0" from 127.0.0.1 - 200 40B in 19.380792ms
2024/09/05 01:25:59 Error importing message: pq: invalid byte sequence for encoding "UTF8": 0xe4 0xf6 0xfc
2024/09/05 01:25:59 Attempt 1/1 failed (panic: pq: Could not complete operation in a failed transaction), retrying in 2m0s

and log.Printf("envelope=%q", hex.EncodeToString([]byte(envelope.String()))) says that the envelope itself has raw ISO-8859-1 äöüß, instead of =AF escaping them. so yeah that's a sane take

mm mm delicious unix mmm

i should've just iconv -f iso-8859-1 | s/iso-8859-1/utf-8/. ah well. already imported :) lists.sr.ht/~nabijaczleweli/os

gamers... what the fuck is shtool versioning. no okay i get "what" it is (shtool manufactures a header file, then the build system constantly runs shtool to parse it back instead of defining the version in autohell). but why is it. git.sr.ht/~nabijaczleweli/ossp

hee hee hee 🙈
[trunk 814fa05] Replace inline MD5 and SHA1 implementations with libmd
9 files changed, 42 insertions(+), 1119 deletions(-)
delete mode 100644 uuid_md5.c
delete mode 100644 uuid_md5.h
delete mode 100644 uuid_sha1.c
delete mode 100644 uuid_sha1.h

who up prein on their print (sorry sorry im trying to delete it)

$ git diff UUID_1_6_2 --stat
54 files changed, 1520 insertions(+), 5924 deletions(-)

by my count, bugs.debian.org/757278, bugs.debian.org/864530, bugs.debian.org/881000, and bugs.debian.org/1041542, and like 3 different bugs I would consider Bad™️ and also UUID v6/v7/max implementation and a general unfucking (i fall asleep before hitting enter yesterday)

bugs.debian.org#757278 - libossp-uuid-dev: arch-dependent file in "Multi-Arch: same" package - Debian Bug report logs

uuid clone(); is "crash (or produce a broken UUID if it doesn’t)" because it runs the const void* constructor, which reads 16 bytes from *this (and uuid is pointer-sized)

the work of a true colour theorist and artist, clearly