Notices by linear cannon (linear@nya.social), page 6

netbsd is nice

i just wish i had something to run it on that could drive the monitor on my main desk

i have built a KGDB-enabled NetBSD kernel to put on my xeon phi, and gotten a serial cable hooked up to another machine for remote debugging

let's see if stress-ng is able to trigger the panic

i guess (in part because some of the recent discourse) i've had a renewed realization that i simply do not like GNU/Linux, or more specifically, what it has been evolving into. and i'm tired of trying to split the difference and try to hammer the few distros i can tolerate into a shape i like, or go on fruitless efforts to start my own, especially when the BSDs are right there

somehow it just feels more correct to be SSHing into a NetBSD system than a Linux one

@mirabilos@toot.mirbsd.org "nonlinear" is a matter of perspective imo. if you look at a 286 in protected mode and squint hard enough, it's an architecture with a 32-bit virtual pointer size, 512M/512M user/kernel split of virtual addressing space, and a 64k page size, with the odd quirks of the pages being resizeable and sizeof(int) being 2

i should port sway to netbsd

@SylvieLorxu@chaos.social trying to implement HDMI openly is fraught enough that e.g. in the world of FPGA development, hardware designers will often stick an "hdmi" port on a thing, but call it DDMI, and then fpga cores you load on it will typically only support speaking DVI-D over it (which HDMI is a superset of). i recently did exactly this with an FPGA project i'm working on

i would be much happier if my development board had a DisplayPort output instead, even though it would probably be more work for me to implement, because with my current i-cant-believe-its-not-HDMI setup, i can't drive anything larger than 1920x1200 at 60hz even in theory (and i'm not sure i can actually manage even that in practice), and making it more functional could be risky if i were to cross the HDMI Forum's radar

with DisplayPort 1.2, which is the spec i have handy, i'd in theory be able to run my 3440x1440@120hz monitor at its full resolution and at least fairly close to its full refresh rate (the limiting factor would be the FPGA. the PLL it has might limit me to 108Hz), and i would not need to be fearful of any organizational body

@SylvieLorxu@chaos.social DisplayPort is a VESA standard. they require you to be a VESA member and pay a charge if you want to download the latest specification. they also will certify devices, but that's not actually necessary aiui.

unlike the HDMI forum, they do not charge royalties, and older versions of the spec can be found online easily (older versions used to be available on VESA's site, but now are not. you can still get them elsewhere)

i doubt that AMD would have the same issue with DisplayPort, and AMD also seems to doubt that, since they are also recommending the use of DisplayPort

@drewdevault@fosstodon.org surprisingly i do not have one, though my wife and i both have wanted one for a while

the closest i have would be my 286 with an amber monitor pretending to be one (was using this on my POWER9 box for a while), or the FPGA serial terminal i am currently designing

oops

i accidentally stole my power9's hostname for my vax, somehow

it's honestly kind of incredible that when i close my serial terminal my VAX halts and drops to a firmware ("microcode") prompt and waits until i reconnect and tell it to keep going, and the OS (NetBSD, in this case) is just stopped in the meantime

here goes nothing

okay, i have finally actually dug out the VAX and i am now preparing to install NetBSD 10.0 RC4 on it

there is a type of tool i felt should already exist, even if as a proprietary package, but which as far as i can tell is conspicuously absent from the ecosystem. so i decided to start building it myself. i think the existence of a tool like what i am making would drastically lower the barrier of entry into the world of FPGA/HDL development.

i've seen tools with superficially similar goals to mine, but which i think miss the mark in a very similar way to how "teach kids to code" sorts of things do, in that they are inherently limited, and at best poorly integrate with or map onto real-world workflows. so once you want to take off the training wheels and work on a big girl project, you have to abandon what you've learned from, and learn a completely new mental model of how things work, and there is nothing to help you cross the gap

with any luck i'll be able to convince my employer that it's worth me spending time working on it, and that it should be maintained by us as an open source project

if you've been wondering what i've been up to lately, it's mostly involved these things

i've been diving deep into the realm of FPGA development and building some really neat stuff

i've intentionally been a bit quiet about exactly what i've been doing because i've been doing some of this with resources from my employer, and i suspected they might become Interested, and at this point i think i was correct.

MIPS: way too comfortable exposing microarchitectural/implementation details in a way that affects program behavior. not just talking about things like load/branch delay slots here - see how the multiplier is implemented in mips3, or how they never bothered to specify memory ordering behavior (and implementations range from TSO to anything-goes)

SPARC: register windows kinda suck. we knew this before they made their way into SPARC. why did they use them anyway? don't really have complaints other than that, SPARC seems otherwise sensible to me

ARM: the problem with ARM the architecture is mainly ARM the company, and the state of the ecosystem. there's been technical decisions that did not hold up, but they've been pretty good about deprecating those things and moving forward. it's still a little complex for my taste.

POWER/PowerPC: ok, i love POWER, but cmon. the instruction encoding complexity is bad. the ABI is bad. neither of those things has an apparent reason, and they're bad enough i couldn't blame anyone for not wanting anything to do with this architecture

RISC-V: ok, i know big endian is out of vogue, but would it really hurt to specify an endianness bit, say you can be big endian if you really want, and be done with it? also, i wish that software-managed TLB was an option. but i understand why it isn't and realistically it makes more sense to do that and implement the software in firmware or microcode so that it is transparent to the OS (like Alpha PALcode)

what is it with alpine linux deciding to fuck up my bootloader config

i swear the moment enough time passes between incidents that i no longer feel obligated to manually inspect my grub.cfg after each apk upgrade is the moment it decides "hey, time to brick linear's work laptop!'

it's amazing how stark the usability difference is on my POWER9 box, just from having firefox with working jit and wasm

this computer has gone from a toy that i wish i were actually making proper use of, to an actual daily driver

@lanodan@queer.hacktivis.me i'm using ppc64le, so i don't get the endian issues you'd run into on macppc/ppc64, and i have accelerated graphics

but webkit-gtk isn't exactly great anyway, and firefox works but doesn't have jit on ppc(64)(le) so it's slow as shit and doesn't support wasm

sigh. i want a web browser that actually works on POWER architecture and that also doesn't make me feel like i'm conceding ground to a megacorporation