@foone introduced in the 186 IIRC. The 8086 didn't have it.

@ariadne does it have bunny ears perhaps?

(Seriously though, I thought thar LinkedIn being “hook-up social media for CEOs and wannabes” was a myth. Can't say I'm surprised to find out it's not )

The turtle and the hare
https://mastodon.social/@martoiu/113576958474190141

@box464 I believe @mia may have a few pointers

@kohan @davidruffner @smallcircles check if can find more people relevant to your interests using something like MastoVue
https://mastovue.glitch.me/
to browse relevant tags from larger instances

Just discovered that the #SteamDeck left touchpad scroll gesture is CIRCULAR. I was going crazy trying to understand why it would change scroll direction for what I *thought* was the same gesture.

@jon imagine ActivityPub had happened before/during Opera Unite.

(I wrote about it some time ago, this <http://wok.oblomov.eu/tecnologia/opera-requiem-3/> may be interesting for you —beware of typos though ;-))

@riley @foone U+0364?

@foone you also wouldn't have posted about fading the palette to blackness being the same function as fading the palette to blackness (I assume one of those was supposed to be whiteness and/or a from?)

So, #CastleRisk in Italian is known as #RisikoPiu but from reading online the Castle Risk rules there are slight differences from the ones in my Risiko!Più box? In my manual:

* after all territories are occupied, in turn each player places 5 armies in ONE territory
* supplemental armies are added at the beginning of the turn, like in classical Risk
* You can move armies at the end of the turn from one territory to an adjacent one.

Anybody ever seen both ruleset?

#boardgames #askFedi

@trwnh oh good point, so if it's done by GET it *must* include the query parameters in the URL. And yeah, now I can see better why POST would be a better choice.

@trwnh hm I'm not convinced. The main issue is that neither POST nor PUT are conceptually appropriate. Among the methods defined by HTTP, GET is the one that's conceptually closest. OTOH, those *are* problems with using a query string. Maybe they could be reduced by other means, such as additional headers or body payload (GET *can* have a payload)

@trwnh doesn't that kind of depend on the type of form? Classically for a something like a search GET would be a more appropriate method than POST or PUT …

@jdp23 @djsundog @Eris

no, even if Mastodon was the only AP server software, it still wouldn't be centralized. It is, however, a monoculture, with all the downsides of monocultures, and that is actually one of the most important things that need to be changed. But this requires helping people discover the reality of the Fediverse beyond Mastodon.

@jdp23 @djsundog @Eris other implementations going forward without waiting for Mastodon is good, but it's not enough (case in point, Quote Boosts; nobody cared that other platforms had them). Part of that is a general misconception of what the Fediverse is and how it operates (and one of the reasons I insist on speaking about the Fediverse rather than Mastodon alone), but part of it is that practically the biggest player in town not supporting something *is* a problem. Monocultures are bad.

@Eris @mekkaokereke (For the changes, I mean something like: a user can ask to be added to a public list in a similar way to how they can ask to follow someone with a locked profile, and similar they could ask to be removed from a list; some of these action could be automatic, but with care: for example, you can remove yourself from a starter list, but not from a public block list)

@Eris @mekkaokereke
so one way this could be implemented is that in addition to my “private” lists that I use to manage my follows, I could have public lists, and anyone browsing my profile could see them and one-click add its members to their follows, or block them (for a block list)? (This doesn't solve the problem of users having to find *me* in the first place, but it would help past that point.)

I guess changes to these lists could come through federation similar to follow requests.

@Eris @mekkaokereke
and that's before even getting into how much of a social problem these are *before* being technical problems. And they are a social problem because of federation (simplifying: “who federates with whom”, which maps also to “who takes recommendation from whom”), but also because of the social interactions involved in the software development itself (there has been recent discussions you probably have come across about how certain thought-out PRs are being disregarded).

2/2

@Eris @mekkaokereke oh yes the ideas are nice, but the problem is, nice ideas have the tendency of not scaling that nicely when decentralization is involved. Consider for example the starter lists idea: where does the server fetch them from to present them to the user? Who manages addition and removal of entries from the list? How do changes to it propagate?
We already have something like that for the “reference blocklist”, and even that essentially relies on a centralized service (Oliphant) 1/2

@Eris @mekkaokereke Mastodon has a lot of room for improvements UX wise (and there's a lot of effort that is going underway even though it's, shall we say, not as considered as it should by those with merge rights), but I'm skeptical about how much BS can be an inspiration for those improvements. How much of the “UX improvements” in BS are a direct consequence of it being a centralized system above anything else? (One example for all: you don't need to choose a server because there's only one.)