PorkrollPosadist

REJECT RNAV, RETVRN to VOR/DME

Lemmy.world is part of a network of "generic" Fediverse instances commonly ending with the .world TLD (mastodon.world is another example administered by the same people). They appear to be mostly concerned with growth, essentially following the tech startup model of growth -> ??? -> profit. The admins saw the Reddit Exodus as a good opportunity to expand their small collection of platforms into Lemmy, and by the numbers they were the most successful (though dozens of other instances were launched around the same time).

In the lead-up to the Reddit Exodus, Lemmy dev Nutomic (IIRC) pitched Lemmy as an alternative on Reddit and the thread went viral. As a maturing Free Software alternative to Reddit with real-world use, and an architecture which mitigates many of the shortcomings of previous Reddit alternatives (e.g. Raddle, Voat, Tildes) it checked all of the boxes that tech-bro Redditors could possibly ask for in such a platform. It stood out to them as a viable solution for the same reasons it stood out to us five years ago. Tens of thousands of people created accounts on various instances and got to posting.

Soon after, the Red Scare began. With the number of instances being launched and the number people signing up, people began taking notice. Not just on Reddit and Lemmy, but on other corners of social media as well. In various ways, people began pointing out that the people developing the alternative to monopoly capital social media were (gasp) Communists. This snowballed from curiosity and concern from people who weren't used to seeing open communists developing free software, to a full blown social hysteria - our own little Satanic Panic. Dessalines's thoughtfully written collection of essays transformed into the necronomicon. A collection of works which could be pointed to as proof of his and the project's deceitful nature, while simultaneously being a form of forbidden knowledge which could never be quoted with any amount of context. Thousands of people, including instance administrators, developed the mindset that they had been tricked into using Lemmy, and that rather than its obvious purpose of being a censorship-resistant social media platform which is also structurally resistant to corporate acquisition and consolidation, it is actually a nefarious organ of misinformation aimed at disintegrating the foundations of Western Civilization.

A substantial part of the social media engagement strategy employed on platforms like Reddit is to make the users believe that by posting, they are engaging in an existential battle for civilization. With Liberal Democracy hanging by a thread, the smallest acts like upvoting the good ideas and downvoting the bad ideas can be all the difference it takes to tip the scales. Every day they spend in the posting trenches is a day that fascism is held at bay. Where the beleaguered city on the hill can stand one day longer against the endless hordes of tyranophillic Russians and Chinese. This attitude was carried over here by many of the Reddit converts, and places like Lemmy.world are the result.

When you get to the gas giants these things are so fucking far apart it's crazy.

About one day, as a matter of fact.

Maple bourbon cheesecake was a hit at work today (I baked a test cake to make sure this recipe wasn't inedible AI slop before poisoning my family with it).

if they use spreadsheets there isn’t any serious alternative to excel. Sad but true.

~~Perhaps, but I Will Fucking Dropkick You If You Use That Spreadsheet~~

Edit: It's called PostgreSQL

Edit 2: There really are two separate but overlapping problems. One is the claim that alternatives are not capable of doing what Excel can do. This is one I am skeptical of. Their may not be a single alternative which does everything Excel does, but Excel is used for all sorts of workflows from data entry to data processing to accounting to mathematics to statistics to data visualization to using the cell background colors to create recreations of classic nintendo pixel art, and there are many tools well suited for each of these specific niches.

The other is that, as an individual or organization with complex accounting systems and business processes created on top of Excel, there is no replacement. Excel is a requirement to continue operations under these circumstances. This is certainly true, but I consider it a problem that organizations opt into. Why hire a dev (or even basic IT staff) to build out internal information systems and applications when we can just use Excel? Why hire a DBA to schematize and safeguard decades of essential business records when we can just license this bauble from Koch Industries or Oracle and "put it all in the cloud?" Why should we provide any infrastructure whatsoever for our accounting staff other than a Windows PC with Office? Most companies like this are basically doomed, but if you have the opportunity to think about how you are keeping records and processing data before you create ten years worth of it, there is always a solution that will scale much better and cost a lot less in the long run.

In the latter case, I don't think it is even possible to create an alternative. If you build a system of sufficient complexity, it cannot be moved without essentially re-creating it from scratch. This is just as much the truth for a skyscraper or a car designed with a specific CAD package as it is for a complex business accounting process created with Excel. This is the reason the Social Security Administration is STILL using mainframe computers running COBOL. There is nothing exceptional about Excel in this regard. It is just the foundation that many of these systems were built on (and it will be around just as long as COBOL for that reason).

But they do have the source code in .tar.gz files available. But I have zero knowledge of how to manually compile a program, let alone audit the code...

Yeah that's a whole 'nother rabbit hole. Not to say it is exceptionally difficult or anything (I do it for a couple programs), but it basically goes back to the dependency hell thing where it becomes your responsibility to track down all the dependencies and install them yourself (now including build-time dependencies like compilers, build automation systems, header files, etc), as well as update it manually. It can be worthwhile if you specifically want to try the bleeding edge version of a program, like if the specific bug you're experiencing got fixed last night, or if you want to try an experimental branch someone is working on, or if it is such a small project that nobody has taken the time to package it in any other form. Otherwise, these changes trickle into the stable distribution packages eventually (fairly quickly in Fedora).

AppImages have a couple downsides, but that's all they are - downsides. When weighed against alternatives, they are still often worth it. It isn't like an evil technology or anything. You need to trust whoever you're getting it from, naturally. No surprises there. There is no holistic update mechanism which can update all your AppImages the way your distro package manager can update your entire system - though some apps will implement their own self-update mechanisms. And because they bundle many of their dependencies, the updates applied by your distro package manager don't apply to them. If an AppImage bundles (e.g.) the cURL library and your distro updates its cURL library to a newer version, the AppImage will continue using whatever version of cURL is bundled inside of it. After a long enough period of time, un-patched security vulnerabilities can accumulate this way (basically the same security implications of unzipping and running a program on Windows that you downloaded N years ago).

On the other hand, it is more convenient for a lot of commercial software companies to put together one AppImage rather than build, package, and test their software for a dozen different distributions. Distribution packages for software like this, when they exist, are almost always created by third party volunteers affiliated with the distro rather than that specific software developer.

To provide a little more background, .so files ("shared objects") are the Unix equivalent of .dll files ("dynamically linked libraries") on Windows. They contain a collection of software routines which are shared between various programs (in this case, the ability to embed a browser engine within a GTK application). On a technical level, they provide the benefit that code in a shared object only needs to be stored on the disk and loaded into memory once, regardless of how many programs make use of it. Unlike Windows, these files are versioned (which is why you'll often see numbers after the .so suffix). For the most part, they are stored in /usr/lib or /usr/lib64

When you run a program, a part of the operating system called the dynamic linker will search for all the required libraries (also known as dependencies) as a prerequisite to starting the program. If the dynamic linker fails to find any of the needed dependencies, you get an error message like the one shown above. The circumstance of needing to track down many arbitrary dependencies, many of which may have their own dependencies, is known as "dependency hell." It is the fundamental problem which package managers solve, and can quicky become a burden when working around them.

AppImages are supposed to "solve" this problem as well by bundling all their needed dependencies, but in practice a lot of them still seem to make assumptions about what libraries and utilities are present on your machine. I'm not as well versed in the technical details.

Not left, not right, forward.

The Long Twentieth Century by Giovanni Arrighi

Interpreting this as "Geometric Dimensioning and Tolerancing" and picturing the most grotesque blueprint I've ever seen in my life.

Within a year they will be claiming ivermectin "cures" autism.