I never did an , so here goes:

• I like and am the developer of @ObjFW
• I'm interested in obscure CPU architectures and *enjoy* writing assembly for them (weirdest in my collection are , and 🙂)
• I'm into obscure OSes (e.g. )
• I collect retro hardware
• I am an :xmpp: advocate (decentralized & federated like Mastodon!)
• I mostly use :apple_inc:, @openbsd :openbsd: and :netbsd: as a daily OS
• I am also a @haiku 🍃 developer

@js @haiku
> "I am an #XMPP :xmpp: advocate"

What do you think of Matrix?

> " am also a @haiku developer"

Don't hurt me

@strypey @haiku

Matrix: IMHO it's "We don't like XML, so we reinvent the wheel and eventually notice that there was a reason for namespaces in XML". IMHO XMPP is a much cleaner protocol, so the idea of having a new clean protocol kinda failed.

@strypey @haiku

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 ;)

@strypey @haiku I'm fully in favor of free HW. That means any FW blob is unacceptable.

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.

@js @haiku
> 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 ;)

@strypey @haiku There shouldn't be any closed source stuff on the default image. There is closed source stuff you can install on 32 bit Haiku, but I don't think any is shipped by default

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).

@strypey @haiku It depends on the license. If the FW can be shipped, it is. But not a lot of FW can be shipped.

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.

@js @haiku
> "If the FW can be shipped, it is."

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 ok, so I guess ethernet FW would need to be downloaded with the image, in case of that eventuality, but I would still want to be given the information, and the choice to install. You have to admit this is an edge case though :)

@strypey @haiku It’s not really an edge case, though. Most firmware is actually for networking HW, WiFi in particular, making it the most common case.

@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!).

@js hmm. #ActivityPub makes some heavy use of #JSON, and Mike has moved Zot6 onto making more use of it too, if I remember rightly from the spec I read. So ...

@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.

@Goffi @js I wonder if @deadsuperhero would be interested in doing a #WeDistribute article on #Salut-à-Toi using #XMPP for social federation? Might be interesting to do a contrast and compare with the way #ActivityPub, #Diaspora, and #Zot are being used.

@strypey @js @deadsuperhero I don't know "WeDistribute", but I'm always available to discuss and answer questions if people are interested.

@Goffi @js
We Distribute is a great series of blog pieces on federated web technologies by @deadsuperhero (yes, he's aware of the irony of publishing these on Medium, I'm pretty sure he's working on a replacement ;)

conspiracy theory, Sean works for medium 

@js I guess I am not sure what I want. Introductory Tutorials for architectures are dime a doze.

Maybe, doing things in assembly? I know to look up op codes and instructions, but how do large constructs work?

@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: skilldrick.github.io/easy6502/ There‘s also some introductions in the OS dev communities.

Let me know how that works for you. :)

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!