@Pawlicker Debian's port apparently had an amd64 release recently, but I couldn't get it to install since it doesn't detect the most basic emulated IDE controller. Tried i386 snapshot, worked fine until I decided to upgrade it. Thought that it's just the framebuffer that's corrupted, but couldn't SSH either after reboot.
Bitchin'. OTP 25 in snapshot's repos is fairly fresh, however (unlike the one in haikuports stuck at 20), so if that fails might as well use the prepackaged one, but that's less fun. Screenshot_20240903_035904.png
Apparently there are no source packages in snapshot repos. Anyway, found a patch in source package, applied fine on newer version. Looks like Hurd also isn't Y2K38-compliant. Screenshot_20240903_044146.png
Edited the whole file with #ifndef __GNU__, it compiled but when it came to erlc part assertion error happened. Apparently it was all unneccessary since this could be solved by setting --disable-esock during configure (which I found in the same .deb build rules). Slow as usual since no SMP.
@mint@ryona.agency how long it's been?I thought they finished it 2 years ago when zammit worked on it. You should check latest gnumach or build from git with some --flag
Thanks to some debugging help from a friend, looks like the issue is broken pipe between fasthtml_worker and whatever process pleromer spawns for it. No idea what to do with it. "Hurd of interfaces representing depth" The depth in question -> :marioatse:
https://git.pleroma.social/pleroma/elixir-libraries/fast_html/-/blob/master/CHANGELOG.md?ref_type=heads >[2.0.0] >The worker process now communicates with the node via stdio, instead of TCP, which was known to cause issues on BSD systems Yeah, and now it causes issues on Hurd systems. Either way, downgrading it takes a whole lot less friction than trying to debug the issue somewhere within Erlang on obscure unsupported platform.
@iska Decided to play around with it more. Apparently there is gnumach-smp in non-snapshot port repos, but it immediately crashes with some APIC assertion error unless I change disk type from IDE to SATA (apparently Hurd supports later, that's surprising). But then for whatever reason they has different disk names, sd0 on up kernel and wd0 on smp so it looks like I have to change fstab every time I need to switch between kernels (adding both with errors=continue results in hang on boot). Also framebuffer corruption hasn't gone anywhere, but I at least can manually start ssh by blindly logging in. htop on SMP kernel still shows only 1 CPU, so not sure if it even works.
@iska Actually, Erlang does show more cores than one, but the number appears to be partially wrong (I gave the maching 3 cores with 2 threads per core topology). Screenshot_20240905_151609.png
@mint@ryona.agency@iska@catposter.club Also framebuffer corruption hasn't gone anywhereVery classic. Happens on any recent system or qemu with -cpu host. X11 may still work though iirchtop on SMP kernel still shows only 1 CPU, so not sure if it even works.Just checked the IRC logs. Apparently you need a program called smp to use smp. logs.guix.gnu.org/hurd/2024-03-07.log
>Happens on any recent system or qemu with -cpu host Changed CPU type to kvm32, seemed to work now. Well, for a moment. >Apparently you need a program called smp to use smp. Why the fuck. Pinned cores to the physical ones, it appears when running stress only one of them gets used. With that smp.c thingy, all but the first one. htop still shows only one core. Screenshot_20240905_154438.png
It's ironic when fungus man wrote things in C thinking CL would be too big or slow or whatever. Nowadays, emacs is slow, hurd is less complete than Yandere Simulator, and both have younger CL counterparts better in every way, except that Lem won't do email and Mezzano isn't a POSix.
@iska@mint@BallsackGyroper1488 >Nowadays, emacs is slow, hurd is less complete than Yandere Simulator, The main issue with Hurd are the maintainers and mainly Stallman. I was somewhat involved in Hurd a long long time ago and almost every time some discussion about implementing features or optimization occurred, Stallman stepped in and gist of the conversation was almost always "The way I think it should be done is the only way it should be done." Every discussion got stonewalled by stupid nitpicks and Stallman's sometimes obviously bad opinions about the code.