this post was submitted on 04 Mar 2025
143 points (98.0% liked)

Linux

50883 readers
764 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
143
Can I ignore flatpak indefinitely? (lemmy.sdf.org)
submitted 2 days ago by krakenfury@lemmy.sdf.org to c/linux@lemmy.ml
87 comments fedilink hide all child comments
 

I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.

I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?

Is it because developers are often using dependencies that are ahead of release versions?

Also, how is it so much better than images for your applications on Docker Hub?

Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.

you are viewing a single comment's thread
view the rest of the comments
[–] cypherpunks@lemmy.ml 2 points 1 day ago* (last edited 1 day ago) (1 children)

I trust Debian developers far more

i definitely agree with you here :)

I think it was poppler or evince that decided they were going to enforce the no-copy-and-paste bit you can set on pdfs. Debian patched it out.

I found the notion of free software implementing PDF DRM rather hilarious, so I had to know more. First I found this help page which confirms that evince does have code which implements PDF restrictions, but it says that its override_restrictions option is enabled by default.

But I wondered: when did this get implemented? and was it ever enabled by default? So, I went digging, and here are the answers:

  • in May 2005, the restrictions were implemented in evince in this commit
  • in September 2005, the override_restrictions option was added in this commit, after discussion in bug #305818
  • in December 2006 bug #382700 was opened, requesting that override_restrictions be enabled by default
  • in January 2008, the default changed in this commit - but only after someone pointed out that the PDF spec does not in fact require the restrictions to be enforced. (The spec says "It is up to the implementors of PDF consumer applications to respect the intent of the document creator by restricting user access") 😂

I don't see any indication that Debian patched this out during the time when evince had it enabled by default, but I'm sure they would have eventually if GNOME hadn't come to their senses :)

I’ve seen Mozilla decide they were going to enforce their trademarks. They carved out special exceptions for various distros but that still would have meant you would have to rename Firefox if you were to fork Debian. Debian had none of it.

In my opinion both sides of the Debian–Mozilla trademark dispute were actually pretty reasonable and certainly grounded in good intentions. Fortunately they resolved it eventually, with Mozilla relaxing their restrictions in 2016 (while still reserving the right to enforce their trademark against derivatives which make modifications they find unreasonable):

Mozilla recognizes that patches applied to Iceweasel/Firefox don't impact the quality of the product.

Patches which should be reported upstream to improve the product always have been forward upstream by the Debian packagers. Mozilla agrees about specific patches to facilitate the support of Iceweasel on architecture supported by Debian or Debian-specific patches.

More generally, Mozilla trusts the Debian packagers to use their best judgment to achieve the same quality as the official Firefox binaries.

In case of derivatives of Debian, Firefox branding can be used as long as the patches applied are in the same category as described above.

[–] gnuhaut@lemmy.ml 3 points 1 day ago (1 children)

https://lwn.net/Articles/335415/

The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.

[–] cypherpunks@lemmy.ml 3 points 1 day ago* (last edited 1 day ago)

I see, here is where Debian patched it out of Xpdf in 2002.

Also lmao @ the fact that Okular's ObeyDRM option still defaults to true today 😂

(Including in Debian, as their KDE maintainer declined to carry a patch to change it.)