NeatNit

@NeatNit@discuss.tchncs.de

This profile is from a federated server and may be incomplete. Browse more on the original instance.

NeatNit, (edited )

I’ve been looking for info about this for months, as it was obviously a part of the EU’s anti-gatekeeping legislation from last year, but I couldn’t find any info. Specifically I wanted to know which apps would be able to communicate with WhatsApp - Telegram? Signal? Something else?

And now that there’s an article, it’s behind a paywall…

Edit: managed to read it through Firefox’s reader mode. Unfortunately they don’t know, but not for lack of trying:

So far, it is unclear which companies, if any, are planning to connect their services to WhatsApp. WIRED asked 10 owners of messaging or chat services—including Google, Telegram, Viber, and Signal—whether they intend to look at interoperability or had worked with WhatsApp on its plans. The majority of companies didn’t respond to the request for comment. Those that did, Snap and Discord, said they had nothing to add.

The only service they mentioned that definitely will have chat interoperability is Facebook Messenger… Yeah, no fucking thanks.

NeatNit,

Not yet, if I’m reading this right! They will be, because the EU forced them to be I guess?

I am finding it as ridiculous as you are.

NeatNit,

Adium… They named an app ‘the element of advertisement’?

NeatNit,

I didn’t know about that! I always use Ctrl+C of course. I’ll look out for this next time

NeatNit,

F-Droid compiles apps from source by itself, without blindly trusting that the APK provided by the developer actually came from the source code. After independent compilation, one of two things happen:

If the app uses reproducible builds, then F-Droid verifies that its own compiled APK matches byte-for-byte with the APK provided by the developer. If they match, F-Droid distributes the APK signed with the developer’s signing key, same as Play Store does (except Play Store doesn’t verify anything).

Otherwise, F-Droid distributes its own compiled APK signed with F-Droid’s signing key.

In either case, F-Droid guarantees that you get an app that matches the source code exactly.

None of this process should matter to you as a user, and it’s all fairly transparent from a user’s perspective. F-Droid gives you certain guarantees and internally enforces these guarantees, while Play Store does not.

LMDE just rocks (lemmy.ml)

I have been testing for a few weeks Mint, originally started on 21.2 on an old 2012 MacBook Air… the OS was flying! As I was looking at this now 10 years old machine, now back to usable speed again I was pleasantly surprised. On my desktop was still running Fedora that is just a bit more shiny and has the latest “stable”...

NeatNit,

The post says as much. Don’t discount the immense value of that eye candy, not to mention the crucial aspect of great usable defaults and a system that works excellently out of the box for a layman user. Debian alone does not pull that weight. Cinnamon is the easy to spot differential, sure, but LM does a lot more to maintain a really good user experience that you can just install and use painlessly.

An example that comes to mind of the extra effort LM goes to, is that they removed and blocked snap from their Ubuntu-based flavours (i.e. the main one). They point it out in the Release Notes for each release, and link to an explanation of the reasoning behind it (it’s good reasons) and, if you still want to enable it for some reason, instructions to do so.

Mint also has its own tools that reduce or eliminate dependence on terminal interaction.

My interpretation is that Linux Mint does a lot under the surface to maintain an excellent general-purpose distro that anyone can pick up and use.

Edit: even in your meme post, the yacht provides all of the amenities that make the trip a tolerable and enjoyable experience, which the truck doesn’t even try to compete with… So we might be in agreement!

NeatNit,

I like people who are fashionate about their work

NeatNit,

You know, this makes me especially wonder if flies and other flying insects make it to remote islands without human (accidental) aid. Theoretically they can hitch a ride on birds, most likely we eggs, but I wouldn’t know how commonly that would happen. I can’t imagine they’d be able to make the trip themselves, or have any incentive to do it.

NeatNit,

One thing’s for sure, that’s not a girl and it’s not fooling anyone. It’s a grown-ass woman with some perspective or editing trickery.

Making a PDF that’s larger than Germany (alexwlchan.net)

Some version of this has been floating around the Internet since 2007, probably earlier. This tweet is pretty emblematic of posts about this claim: it’s stated as pure fact, with no supporting evidence or explanation. We’re meant to just accept that a single PDF can only cover about half the area of Germany, and we’re not...

NeatNit,

For real! How am I going to make a 1:1 map of Europe like this?!

NeatNit,

The takeaway is that the format doesn’t have any limit, but Adobe Acrobat in particular implements an arbitrary cutoff size. Other readers, such as Firefox’s built-in PDF reader or Mac’s Preview, can handle any arbitrary size. The article ends with a PDF the size of the universe, weighing an unimaginable 549 bytes!

But that limitlessness can come at a cost: according to the article, Preview doesn’t handle UserUnit which should affect page size, while Acrobat (and Firefox) do. I’m guessing (gut feeling) Acrobat probably supports the most features overall, Firefox probably supports the vast majority of those used in practice, and Preview only allows Apple Approved™ PDF features and extensions deemed worthy of Their Appleness’s consideration. Chrome’s PDF reader is probably on the same level as Firefox, I guess.

NeatNit, (edited )
  • Adobe originally had a maximum page size of 45 inches square.
  • In 2001 they increased that to 200 inches
  • And in 2004 Adobe increased it to 15,000,000 inches (a bit larger than Germany) which is still kinda sucky if you want to show a map on a PDF

It’s unclear why Acrobat has to have a limitation at all, since other PDF programs have no such limitation. More importantly, Acrobat only supports up to 200.00 x 200.00 in (5.08 x 5.08 m) using the standard MediaBox setting - any higher than that and you get a warning. The only way to push past that is to also set a UserUnit value, which essentially acts as a multiplier. This is all detailed in the article.

But Apple’s Preview doesn’t support UserUnit, meaning a PDF larger than 200 x 200 in can’t be displayed correctly in both Acrobat and Preview. If you set it higher using just MediaBox, then Preview will show it fine but Acrobat will truncate it. If you set MediaBox to the highest values Acrobat accepts and use UserUnit as a multiplier, then Acrobat will show it fine but Preview would not (I don’t know if it would truncate it or show it scaled down). So when it comes to PDFs larger than 200 x 200 in, you can choose either up to 15,000,000.00 x 15,000,000.00 in in Acrobat or as large as you like in Preview - you can’t have both.

As for “Their Appleness’s consideration” they generally use floating point numbers for coordinates and sizes. Which is how, as it says in the OP’s article, it’s able to handle a PDF trillions of light years in size. A double precision floating point number can be really big.

More important though, it means you can process it with hardware accelerated floating point operations which are incredibly fast. And Apple’s PDF renderer needed to be fast because for years PDF was the data format used by the window manager for pretty much all screen drawing operations. They weren’t doing that on modern fast hardware either, they were doing it decades ago on slow hardware. With decent performance.

If there are features missing it’s probably because they would slow things down too much.

All interesting and some things I didn’t know, but this is completely irrelevant. A PDF-reading app (i.e. Preview) does not have to use, and almost certainly does not use the same PDF rendering engine as the desktop rendering one you described. An obvious relevant example is pages - the desktop renderer doesn’t need to know about or render pages at any point. It doesn’t deal with the size of a page, the existence of multiple pages, or pages of different sizes. It has only one canvas to draw in. A PDF viewer app OTOH obviously has to be able to handle all of these things, and render them into a format that can be pushed to the system’s graphics API.

See this StackExchange answer, which quotes this paragraph from Ars Technica (emphasis mine):

it is important to understand that Core Graphics Services deals with more or less “ready-to-display” data sent to it from higher layers in the graphics system. It is a pixel pusher, not a graphics creator

It doesn’t deal with any features, whereas a reader app must deal with many features. So discussing it is irrelevant for the Preview app.

Edit: and I was only poking fun at Apple’s policies in general. Their current crusade against anything that isn’t 100% under their totalitarian control on iOS in Europe is most telling. I think in this case the only reason they don’t support UserUnit is that it’s basically never used in practice and they never realized it’s missing.

NeatNit,
NeatNit,

it stands for Mars (A Remote Satellite (of the sun))

NeatNit,

Now I want to see a video of a giraffe actually tripping over a rock. It has to have happened at some point, animals aren’t immune to tripping!

NeatNit,

it does explain why they wouldn’t want the government to be more transparent.

NeatNit,

This is all correct but it’s missing freshly-squeezed orange juice over in A tier

NeatNit,

When you’re so poor the airline prefers to spend more money on fuel than they charge you (due to worse aerodynamics) just so the other passengers don’t need to share air with you

drakenblackknight, to newpipe
@drakenblackknight@mastodon.online avatar

Still seeing posts from Lemmy about how @fdroidorg doesn't have @newpipe in sync.

They have an official repo. That will fix the problem.

NeatNit,

They have an official repo. That will fix the problem.

Correct me if this is wrong, but from my understanding switching to their repo means no longer being behind F-Droid’s source code match guarantee, or seeing anti-features and all that stuff. Granted, I already gave that up for Bitwarden so I admit it’s a bit hypocritical, but much of the value of a centralized F-Droid is the main repo’s curation process - circumventing it is a workaround, not a solution.

Edit: I also worry about the possibility - however remote - of downloading new apps thinking they’re from the F-Droid repository, when they are in fact from some alternate repository I’m using. I already worry about this with Bitwarden, and each repo I add is another potential vector for this. Perhaps I’m overthinking this, but I’m thinking if too many popular apps make their own F-Droid repos, this might become a real threat.

NeatNit,

gotta trust someone at some point

NeatNit,

In the general case: because placing all your trust in one place leaves no one else to check their work. You have to place some trust in the app developer (this is always true) but having a middleman can have benefits. For example, if an app starts using proprietary blobs - either deliberately or without realising - then F-Droid’s pipeline and/or maintainers would likely catch it and have it resolved. If there’s no one else to check such nitty-gritty details, that leaves more room for error.

In the specific case of Newpipe: it’s probably fine, but I’d prefer not to make a habit of it.

NeatNit,

This is just another benefit of a centralised repo: I can’t keep track of all the news about all the companies whose apps I use. A strong community of repo maintainers will do a much better job of blocking updates or removing apps entirely when they go rogue than each user fending for themselves could ever do.

NeatNit,

I didn’t realise this was old until you brought it up. I got here from the sub, which I got to by misclicking on the sub portion of a post when I just wanted to see its comments.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • rosin
  • ngwrru68w68
  • osvaldo12
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • thenastyranch
  • Youngstown
  • khanakhh
  • everett
  • slotface
  • tacticalgear
  • kavyap
  • JUstTest
  • normalnudes
  • Leos
  • GTA5RPClips
  • ethstaker
  • InstantRegret
  • cubers
  • modclub
  • Durango
  • provamag3
  • cisconetworking
  • tester
  • anitta
  • lostlight
  • All magazines