I never did an #introduction, so here goes:
• I like #ObjC and am the developer of @ObjFW
• I'm interested in obscure CPU architectures and *enjoy* writing assembly for them (weirdest in my collection are #Itanium, #PARISC and #SH4 🙂)
• I'm into obscure OSes (e.g. #MorphOS)
• I collect retro hardware
• I am an #XMPP advocate (decentralized & federated like Mastodon!)
• I mostly use #macOS :apple_inc:, @openbsd and #NetBSD :netbsd: as a daily OS
• I am also a @haiku 🍃 developer
What do you think of Matrix?
> " am also a @haiku developer"
Haiku: The FSF's definition of firmware blobs is just severely broken. If I desolder the RAM on hardware into which the firmware is loaded and replace it with a ROM into which the firmware is burned, the FSF is fine with it. It's stupid, though, since you still run the same unauditable, potentially backdoored blob. You just changed the storage medium. And that is really the only thing on which they decide whether something is open HW: The medium on which the FW is stored.
@js @haiku well, they had to identify a hardware/ software boundary and put it somewhere. Note they are called the Free *Software* Foundation. Stallman has written about free hardware designs, which is about trying to address hardware doing the same bad things non-free software does
(I did say don't hurt me ;)
However, if you have to have an FW blob, I don't draw the line on where it's stored. I draw the line where all non-GNU OSes seem to draw it: Does it run code on the main CPU? Or does it only run code on a microprocessor?
E.g. the USB keyboard FW is less of a problem than the FW of the WiFi that's attached via PCIe. Depends on what the blob has access to.
But ideally, I want to have 0 blobs.
Cool.. That's really all I was proposing in that thread, and asking how things are now in relation to that goal. Oh, and I guess a Haiku distro that doesn't bundle any non-free apps and stuff. Had to wade through a power of FUD to get those answers, then the thread wandered off into another topic. Gotta love the 'net ;)
The goal is to have free hardware, but also support the non-free hardware that people want to run it on. That's also about freedom, running it on the hardware you want :)
You're fine with blobs? Ok, use that hardware. We make sure it works.
Don't want blobs? Buy hardware without blobs and Haiku won't load any
@js @haiku does it load the blobs from an external repo? Does it warn me that it's doing it, that they're proprietary, and give me an option not to do it? If so, that meets my standards, although the FSF are more strict, which is why vanilla Debian still isn't on their endorsed list (too easy to install non-free stuff from repos available by default, if I remember their stated reasoning).
It does not give you the option not to load it if it has FW, because you consented into having blobs by buying and using that HW 😉. No need to have a popup for that like for cookies on every web page.
Obviously, I think it would be better if it wasn't.
> you consented into having blobs by buying and using that HW
No, no I didn't. Let's say all my hardware supports free FW except one bit. I might choose to not use that bit with Haiku, so I can have a 100% #FreeCode system. I might just want to test how well Haiku supports my HW with no blobs. There are plenty of reasons to make blobs remote-loaded, and opt-in.
@strypey @haiku The general idea is to be user-friendly here. Meaning to 99% of the users. 99% users want their hardware to work. If you intentionally want to avoid that one part of your motherboard that needs a blob, I recommend you a.) disable it in the BIOS and b.) just remove the firmware from the image. Easy as that 🙂.
But I still think you should just not buy hardware that needs blobs in the first place.
@js @haiku user-friendly, sure, but good #UX is not 'decide everything for the user'. It's more like 'set sane defaults, but give the user information and choices'. Especially when it comes to install procedures they only have to deal with once (per install).
> But I still think you should just not buy hardware that needs blobs in the first place.
Ideally, sure. But this is still vanishingly rare, and you're assuming that people are buying their hardware, rather than making do with cast-offs.
@strypey @haiku I prefer open and free hardware as much as you do. But let's be realistic. 99% of the users who bought unfree hardware bought it because they don't care, and they'd rather have the OS work. They are not going to understand that their HW does not work because it requires unfree firmware - they are going to complain that Haiku sucks and doesn't work.
@js @haiku if you just don't install the blob, and don't inform the user, yeah sure. But I'm struggling to understand why it's hard to have a dialogue that says something like "for all hardware to work as intended, your system requires x, a non-free component. Do you want to install x?" This is what both Debian and Ubuntu do, and the world keeps turning *shrug*
@js @haiku all going well, the number of people who care is increasing, and if people learn through being asked this question that replaceable components require non-free blobs, they might make the effort to replace them with ones that don't. At least they have been informed of the issue, and they have a choice.
@strypey @haiku Here's a real world example (happened to me): You boot Haiku and both your ethernet cards (WiFi and wired) don't work because FUCKING BROADCOM. How do you download firmware now? I would have been happy if Haiku shipped with firmware for either, because a notebook without network is pretty useless.
@js @haiku even when you add all the MUC stuff, and a decent web interface? XMPP is still a cleaner protocol? Anyway, I don't really see Matrix as a replacement for XMPP, so much as a web native, federated-by-default replacement for IRC (or a #FreeCode, federated replacement for #Slack, as you prefer)
@strypey Yeah, I think it's pretty clean. MUC is quite simple. And XML with namespaces allows easy extensibility without getting into a mess like you do with JSON (hello, Matrix!).
@strypey Yes, but ActivityPub is not such a generic protocol like XMPP 😉. I'm still wondering if I should write a XEP for DNS over XMPP, to troll the XMPP over HTTP crowd.
@js sorry, I'm confused, what do you mean by "generic protocol" here? Writing protocol extensions as trolling would certainly take the art to a whole new level ;)
@strypey XMPP is not just a chat protocol - it's the Extensible Messaging and Presence Protocol. That unfortunately is a bad name, because it describes <message> and <presence>, but not <iq>. With iq, it's basically a federation of servers that are able to provide you with any kind of service. Meaning XMPP can be used as a transport protocol for pretty much everything.
@js @strypey hi, I'm catching your conversation in the middle, but it is generic in the sense that it can do everything. We do chat (with optional e2e encryption), blog, forums, events handling, file sharing, remote control, and even tickets/merge requests handling with it. Not mentioning audio/video etc.
conspiracy theory, Sean works for medium
> I'm pretty sure he's working on a replacement
how it works:
make others believe that your product is even used by those that critic it more then you do. Make others feel comfortable using it. You establish the brand within those comunities that could heavily damage it
@tj You mean want to learn it? Which CPU?
@tj I faced the same problem when I started. I’d suggest to read up on the register set and the ABI and then look at gcc -S output. Or you start with 6502, for which plenty of introductions exist from back in the day, but also from today. For example, there is easy6502: https://skilldrick.github.io/easy6502/ There‘s also some introductions in the OS dev communities.
Let me know how that works for you. :)