Also known as @VeeSilverball

  • 0 Posts
  • 4 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle
  • Arch is always “latest and greatest” for every package, including the kernel. It lets you tinker, and it’s always up to date. However, a rolling release introduces more ways to break your system - things start conflicting under the hood in ways that you weren’t aware of, configurations that worked don’t any longer, etc.

    This is in contrast to everything built on Debian, which Mint is one example of - Mint adds a bunch of conveniences on top, but the underlying “how it all fits together” is still Debian. What Debian does is to set a target for stable releases and ship a complete set of known-stable packages. This makes it great for set and forget uses, servers that you want to just work and such. And it was very important back in the 90’s when it was hard to get Internet connectivity. But it also means that it stays behind the curve with application software releases, by periods of months to a year+. And the original workaround to that is “just add this other package repository” which, like Arch, can eventually break your system by accident.

    But neither disadvantage is as much of a problem now as it used to be. More of the software is relatively stable, and the stuff you need to have the absolute latest for, you can often find as a flatpak, snap, or appimage - formats that are more self-contained and don’t rely on the dependencies that you have installed, just “download and run.”

    Most popular distros now are Arch or Debian flavored - same system, different veneer. Debian itself has become a better option for desktop in recent years just because of improvements to the installer.

    I’ve been using Solus 4.4 lately, which has its own rolling-release package system. Less software, but the experience is tightly designed for desktop, and doesn’t push me to open terminals to do things like the more classical Unix designs that guide Arch and Debian. The problem both of those face as desktops is that they assume up-front that you may only have a terminal, so the “correct way” of doing everything tends to start and end with the terminal, and the desktop is kind of glued on and works for some things but not others.


  • I have no plans to support p92 precisely because it’s going to “push” users together as a commodity. What Meta has jurisdiction over is not its communities but rows of data - in the same way that Reddit’s admins have conflicted with its mods, it is inherently not organized in such a way that it can properly represent any specific community or their actions.

    So the cost-benefit from the side of extant fedi is very poor: it won’t operate in a standard way, because it can’t, and the quality of each additional user won’t be particularly worth the pain - most of them will just be confused by being presented with a new space, and if the nature of it is hidden from them it will become an endless misunderstanding.

    If a community using a siloed platform wants to federate, that should be a self-determined thing and they should front the effort to remain on a similar footing to other federated communities. The idea that either side here inherently wants to connect and just “needs a helping hand” is just wrong.


  • Mastodon’s export portability mostly focuses on the local social-graph aspects(follows, blocks, etc.) and while it has an archive function, people frequently lament losing their old posts and that graph relationship when they move.

    Identity attestment is solvable in a legible fashion with any external mechanism that links back to report “yes, account at xyz.social is real”, and this is already being done by some Mastodon users - it could be through a corporate web site, a self-hosted server or something going across a distributed system(IPFS, Tor, blockchains…) There are many ways to describe identity beyond that, though, and for example, provide a kind of landing page service like linktree to ease browsing different facets of identity or describe “following” in more than local terms.

    I would consider these all high-effort problems to work on since a lot of it has to do with interfaces, UX and privacy tradeoffs. If we aim to archive everything then we have to make an omniscient distributed system, which besides presenting a scaling issue, conflicts with privacy and control over one’s data - so that is probably not the goal. But asking everyone to just make a lot of backups, republish stuff by hand, and set up their own identity service is not right either.