Posts by millihertz@oldbytes.space
 (DIR) Post #B4YRR6PiWbAfS5jhuS by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       re LB: not even a particularly obscure microcontroller - an AT91SAM9G20, a 400MHZ ARM926ej-S, presumably taking advantage of the Jazelle extension... which is almost entirely undocumented; from the Jazelle Wikipedia entry:ARM has not released details on the exact execution environment details; the documentation provided with Sun's HotSpot Java Virtual Machine goes as far as to state: "For the avoidance of doubt, distribution of products containing software code to exercise the BXJ instruction and enable the use of the ARM Jazelle architecture extension without [..] agreement from ARM is expressly forbidden."
       
 (DIR) Post #B4anp1Zsk8xEi9DrZA by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       re LB: like i said a few days ago, "i don't do cults" has become the single most apposite answer to anyone asking why you didn't wrote your project in Rustthe assumption embedded in this bit, in particular, annoys this piss out of me:it has gotten to a point where people have told me that i should… stop because “you are making the world worse by writing insecure code”C code is not automatically insecure! in fact, anyone assuming that Rust is automagically preventing them from writing insecure code should frankly step away from their keyboard, turn off their computer, and go and find a hobby they can cut themselves on. then they might learn a thing or two about the complex interrelationship between tools and personal responsibility.i can see why that accusation would wreck an autistic person. it's one of those "you aren't even making it to the level of being wrong" category errors. it's impossible to sensibly argue against, because it's nonsense! but how on earth does one effectively counter nonsense...?
       
 (DIR) Post #B4t3qyH55jIb9oepPc by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       @alilly why choose? go back to Windows 2000 Server and the COM scripting engine lets you use them interchangeably....i wish i didn't know this :-/
       
 (DIR) Post #B517R9KZJeZL02uXYW by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       something just occurred to me.so for a couple of decades now, x86 CPUs have employed a specialised call/ret predictor to speed up subroutine predictions. the critical bit is the RET predictor, which takes the prediction off the CPU's internal stack that was left there by CALL and starts executing code there.fortunately, i doubt it uses a whole lot of silicon real estate. i say fortunately, because frankly, you might as well completely ignore it and rely instead of the x86's unparallelled ability to predict indirect jumps instead. (is that what compilers do these days? i don't know...)because while most of the time it will work as advertised, immediately after a context switch every single prediction it retuns will be wrong. in a way that the indirect predictor just won't be. and while the innermost subroutines might return quickly, that pretty much accounts for the bottom two or three layers. the rest of them? pointless... unless the core is running single threaded code, with no context switches at all.which, of course, doesn't happen a whole lot on modern computers...
       
 (DIR) Post #B517dcCTo0Oy0o4Ulc by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       @Rairii even kernel code has to context switch
       
 (DIR) Post #B5PsYNtEwU6rox7O4m by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       *sigh* i mean, i get why every new kernel released by anyone is POSIX compliant and can compile all their favourite programs. recreating the corpus of software everyone relies on these days, especially for internet connectivity, is a literally terrifying prospect. and of course computers are useless without internet connectivity, aren't they? ;-) but it's killed the field of OS research - especially hobby OS research - stone dead. nobody's doing anything that departs from the "kernel in C implementing POSIX" model, even though literally every other seam is all but untapped.froggey's Mezzano is an honourable exception, and one i really need to install on a respectable machine - it's just, i also need to learn Common Lisp and emacs, and that's a lot, all at once! but if it can work well on one of the (um, ten) Wyse 3040s i ended up with, then i might well have a permanent little ersatz Lisp machine in the corner
       
 (DIR) Post #B5Quiq61JzlVGMAXXk by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       more and more, i want to hear about software that FOSS evangelists sneer at because its licence contains clauses like "no fascism" or "no warmongering"
       
 (DIR) Post #B64A5aWsROMa7YTQwq by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       i asked this over on my other account. but honestly, it still shocked me. i know linux distributions tend to grow exponentially over time - even Slitaz has escaped its 50MB constraint now! - but the difference between alpine-standard-3.22.4-x86.iso (212MB) and alpine-standard-3.23.4-x86.iso (772MB!) is shockingly colossal - and seems unique to x86, too; the difference between alpine-standard-3.22.4-x86.iso (270MB) and alpine-standard-3.23.4-x86.iso (347MB) is far less pronouncedwhat gives, mountaineers?
       
 (DIR) Post #B64A5aobNUXd0WlaZk by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       never mind, i worked it out...nvidia's fucking firmware.literally four times the size in 3.23 as in 3.22linus' advice nvidia clearly retains its relevanceseriously, who's even using alpine on their nvidia-based gaming rig in the first place...?
       
 (DIR) Post #B64AQtpJt91y3IGJay by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       @Rairii oh, right... of course :-(
       
 (DIR) Post #B64AQu5cuW4grrtL0q by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       @Rairii but that's the thing. surely anything that needs nvidia GPU with no G performance wouldn't be running on a 32-bit OS anyway?
       
 (DIR) Post #B6Bo09YGfi1jHCo5bc by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       i'm sure zig will be a great language when it's finished.it's just... i remember when languages were designed before the compilers were written for them
       
 (DIR) Post #B6EVbw3A0Ia6kcRGd6 by millihertz@oldbytes.space
       1 likes, 1 repeats
       
       oh for FUCK'S SAKEhttps://codeberg.org/small-hack/open-slopwareSvarDOS all the way, then, i guess
       
 (DIR) Post #B6EVbx6O5ml00uxMIa by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       the one reservation i have is their characterisation of NetBSD as having "an ambiguous policy". in fairness, NetBSD's policy does sound like it was drawn up by a judge: it takes the quickest, narrowest route to a position (LLM'd code is presumed tainted) and kicks the can as far down the road as possible ("LLM'd code must not be submitted without written permission from core", but as far as i can see there is no documented process by which one could obtain written permission, nor any indication of how once might convince core that your interactions with the giant plagiarism machines were unique and special) without actually taking a position on LLM'd code itself.but to call it ambiguous appears to misunderstand the way judges tend to avoid ruling on any more than they have to. in practice the NetBSD position is more than sufficient to keep LLM'd code out of it for the foreseeable future, regardless of future legal developments. the presumption of taint is going to be more or less impossible to meaningfully overcome, and without a process for seeking permission for an exception, it seems highly unlikely that any such permission would be granted - especially given that the appearance of such permission would essentially act as a canary for those of us who care about such things.put it this why. i think my position on slopware is quite clear, but i'm entirely comfortable with NetBSD's policy. in practice, it's a ban - it's just couched in terms that would be difficult for anyone to actually argue with.
       
 (DIR) Post #B6EVbxcIBAHHbrsq1o by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       in fact, it turns out that QEMU's policy is more or less the same as NetBSD's - except it includes a rider that the policy may change in future, which is a rider NetBSD's policy doesn't require (the "written permission" bit covers it) - and yet NetBSD's policy is described as "ambiguous", while QEMU is endorsed as a project that "does not accept slop contributions"
       
 (DIR) Post #B6fDlfKkw30hG5pNTc by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       ...and that's that for SBCL, i guess.https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/20260227155122.1f2c07d6cf1ecf561d38cf3b%40coiloptic.org/
       
 (DIR) Post #B6fDlglNcXtvgxI9c8 by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       i'm holding out hope for Chez Schemebut also preparing to be disappointed
       
 (DIR) Post #B6fDlhFrnCHtDVYV8K by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       perhaps the best way forward is to make Mezzano self-regenerating? it can't be too far off already
       
 (DIR) Post #B6qoyZnAgU4WsXhIRs by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       quick question:has anyone ever made a tiny MP3 decoder / player, in a similar vein to kjmp2?:boostOK:
       
 (DIR) Post #B6qp9msAOK1adINbE0 by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       @Rairii it does, but it also tells me that i completely forgot that KeyJ had followed kjmp2 with minimp3!