[-] aspensmonster@lemmygrad.ml 2 points 1 month ago

Dover: it's either a breeze or completely inscrutable.

[-] aspensmonster@lemmygrad.ml 3 points 2 months ago

Turns out they thought ArcGIS cost the same as like Office or Acrobat, and they didn’t budget for it for the fiscal year that started 2 weeks before I started working.

ESRI is in the position that Microsoft and Adobe want to be in, a de-facto monopoly.

[-] aspensmonster@lemmygrad.ml 2 points 2 months ago

Once you’ve eliminated the cause for NATO, then dissolving NATO will make sense.

The cause for NATO was eliminated. NATO didn't dissolve. It grew. Spoiler alert: there are no good guys in a war between imperialists.

[-] aspensmonster@lemmygrad.ml 3 points 2 months ago

What kind of type signature would prove the first block of any directory in an ext4 filesystem image isn’t a hole?

I don't know if the type system proves it's not a hole, but the type system certainly seems to force consumers to contend with the possibility by surfacing the outcomes at the type system level. That's what the Either is doing in the example's return type, is it not?

fn get_or_create_inode(
    &self,
    ino: Ino
) -> Result<Either<ARef<Inode<T>>, inode::New<T>>>
[-] aspensmonster@lemmygrad.ml 3 points 2 months ago

If that were the case Molly FOSS wouldn’t exist

I'm not speaking of hard dependence as in "the app can't work without it." I'm speaking to the default behavior of the Signal application:

  1. It connects to Google
  2. It does not make efforts to anonymize traffic
  3. It does makes efforts to prevent anonymous sign-ups

Molly FOSS choosing different defaults doesn't change the fact that the "Signal" client app, which accounts for the vast majority of clients within the network, is dependent on Google.

And in either case -- using Google's Firebase system, or using Signal's websocket system -- the metadata under discussion is still not protected; the NSA doesn't care if they're wired into Google's data centers or Signal's. They'll be snooping the connections either way. And in either case, the requirement of a phone number is still present.

Perhaps I should restate my claim:

Signal per se is not the mass surveillance tool. Its ~~dependence on Google~~ design choices of (1) not forcing an anonymization overlay, and (2) forcing the use of a phone number, is the mass surveillance tool.

[-] aspensmonster@lemmygrad.ml 3 points 2 months ago

Signal is not dependent on Google.

It literally is though.

[-] aspensmonster@lemmygrad.ml 3 points 8 months ago

Comrade ✊

[-] aspensmonster@lemmygrad.ml 3 points 1 year ago

It’s crazy they politicized emojis 🙄…

Wait until you hear about what they did to language!

[-] aspensmonster@lemmygrad.ml 3 points 1 year ago

My garage is huge compared to my house. It has 2 cars, a laundry, and all of the stuff I don’t use every day.

...

You get all the stuff into the same size house

Sounds like the problem is all the stuff.

[-] aspensmonster@lemmygrad.ml 3 points 1 year ago

Sincerely, leftist pacifist

Why are you a pacifist? All rights are won through violence.

As for your assertion on the origins of rights, that’s absolute bullshit. The vast majority of worker’s and other civil rights have been won via peaceful protest.

The history of society is the history of class struggle. Those rights were earned through struggle, not through asking nicely.

[-] aspensmonster@lemmygrad.ml 3 points 1 year ago

Absolutely not, and this article goes into quite a few reasons why:

https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

Sadly there's reality. The reality is to get away from the evil distributions the Flatpak creators have made... another distribution. It is not a particularly good distribution, it doesn't have a decent package manager. It doesn't have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.

While the developers like to pretend real hard that Flatpak is not a distribution, it's still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it's still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.

If you need a dependency that's not in the runtime there's no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you're also the maintainer of all the dependencies in this semi-distribution you're shipping under the disguise of an application. And one thing is for sure, I don't trust application developers to maintain dependencies.

Even if there weren't so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.

Developers are not supposed to be the ones packaging software so it's not hard at all. It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.

Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works(tm)

view more: ‹ prev next ›

aspensmonster

joined 2 years ago