how come html5 youtube app works so much better on nintendo switch than the desktop website does in chromium? is it their tv app being better (i believe it's the same on all consoles and smart tv) or webkit being faster than chromium?

@leip4Ier one reason may be that WebKit is designed to be integrated with the system where it runs, using native functionality. Dunno about Nintendo's port, but for example the WebKit GTK and WPE ports use GStreamer for multimedia, which in turn can load decoding plugins which do decoding in hardware. OTOH on desktop Chromium uses a bundled ffmpeg which does only software based media decoding 🤔

@aperezdc whoa, interesting, i didn't know that. i dislike the way google bundles everything with their browser, although it's understandable that they don't wanna deal with so many different APIs (or wait for operating systems to fix stuff). seems like it not only takes more space on disk and in ram, but also has performance disadvantages.

@leip4Ier @aperezdc
so basically, Chrome is not trying to be a citizen?


@wolf480pl @aperezdc chrome has
- its own copy of ffmpeg
- its own account management system
- its own dns resolver
- its own notifications gui and daemon
- its own app store that included native (um, nacl) apps at some point
- its own update system
- an integrated antivirus
- i think a large part of gui is its own, too, not from a framework

you can see why it's done this way, but yeah, it doesn't use system resources efficiently. chrome os is a natural evolution.

@wolf480pl @aperezdc on windows, it can even write usb flash drives

maybe that's not so fascinating if you compare it to emacs, but well..

btw, i think google was a significant contributor, if not the sole author, to web usb and web bluetooth standards, which give web apps raw access to usb and bluetooth devices. like, i think you could make a clone of balena etcher, but as a browser app and not an electron one?

@wolf480pl @aperezdc they had too many platform-specific apis, while chrome just makes all of their own apis whatwg standards

@leip4Ier @aperezdc
so basically same evil plan, but Chrome has more political power to push it through

@wolf480pl @leip4Ier
@aperezdc yeah they are the Lucky Luciano of the web, instead of proclaiming being the rulers of the web they play the game of the standards and control it silently.

@leip4Ier @wolf480pl …and at the same time the bundled copies of different libraries included in Chrom{e,ium} are difficult or impossible to swap for system-installed versions. The work done by packagers is monumental.

There are reasons one can argue for the “bundle the world” approach being good, like “hey, the testing matrix does not explode”, but thena again if a few people can handle using system libraries in their random big project, Google should be able to as well—they sure have cash!

@leip4Ier @wolf480pl In the end it boils down to either not having a real Free Software/Open Source culture and not knowing how things should be done, so the way things are done inside the company creeping towards the outside; or purposely deciding to bypass the community because there is no real interest in engaging the annoying community and being “open” for the greenwashing.

@aperezdc @leip4Ier
tbh I'm seeing this approach of "bundle all the deps" creeping into broader FOSS community. Look at Docker and Flatpak.

@wolf480pl @aperezdc appimage.. low maintenance packaging for software that knows it isn't important (or open) enough to be included in repos!

well, one could argue that linking binaries statically has significant advantages, but i don't think the chromium executable is linked statically with all its libs. if it isn't, then there're no advantages and the only issue here is google's laziness.

@leip4Ier @aperezdc
well, IIRC one flatpak developer I know claims that distros should serve as a "base system" and refrain from distributing applications. Can't speak of appimage, but I expect at least some of it's proponents to subscribe to that vision.

@wolf480pl @aperezdc it's kinda a flawed idea imo. software shares libraries, and what the heck does "base system" mean? kernel + systemd + flatpak? do we include bash? where is the line? also like, there's glibc for the base system, glibc for chromium, glibc for libreoffice..?

there're fedora silverblue and ubuntu core, i should probably look at how they're designed..

@leip4Ier @aperezdc
Well, BSDs do have a pretty well-defined line of where "base system" ends, but it's not some universal concept. I think it's pretty arbitrary.

And I do appreciate that on most Linux distros, no package gets any special treatment. Kernel is the same kind of package as supertuxkart.

@leip4Ier @wolf480pl while I am not 100% sold on it, I do think in some cases there's value in something like Flatpak (I don't know anything about Snap, so won't comment on it): if you want to provide a system that is essentially immutable and still having a “SDK” for third parties to add applications.

In the case of Flatpak, the GNOME runtime includes practically all the libraries needed by the desktop's core applications, so it's expected that each one of them won't need to bundle much.

@aperezdc @leip4Ier
I think that the concept of providing an immutable platform and an "SDK for third parties to add applications" is against the values of Free Software, and against the way Linux community has functioned so far.

@aperezdc @leip4Ier
or rather:

Letting application developers distribute applications directly to users will work against the values of Free Software.

@wolf480pl @leip4Ier Not really, as long as the users are provided with the four freedoms (run the program as the user wishes for any purpose, study how the program works, redistributing the program, and redistriburing modified version) it's still Free Software, no matter what the *distribution method* is.

Reminder: People used to pay for GNU Emacs and getting tapes delivered (including the source code) by snail mail.

I can buy that Flatpak goes against 20-something years of tradition, though.

@aperezdc @leip4Ier
I'm not saying it isn't Free Software. It doesn't contradict the definition.

But it puts more power in the hands of the developer, at the expense of the user, which I think is against the _spirit_ of Free Software.

I think one of the more important elements of Free Software is making it easier for people to modify the software they run.

Dunno how flatpak et al. stand wrt. that, but apt-source, edit, dpkg-buildpackage are hard to compete with.

@wolf480pl @aperezdc @leip4Ier I always find the idea of having a middleman a little strange when it comes to arguing that it aligns with the idea of Free Software. Not saying the existence of a middleman is a bad idea in of itself, but by the very nature of them, you don't have full access to whatever software you wish to install.

@normandy @leip4Ier @aperezdc
I'd argue that for the software that is packaged by your distro, you have fuller access.

Because you can easily download the distro's source package, edit it, build, and install a version with your modifications. In a standardized way. Without learning lots of different buildsystems.

@normandy @leip4Ier @aperezdc
I think of distros as trade unions.

Maybe things don't always work like this in practice, but I still think if it comes to things where developer's interest conflicts with user's - things like like analytics, auto-updates, respecting user's choices expressed through system-wide configuration, etc. - distros will take the users' side.

@wolf480pl @normandy @aperezdc free software always was about having a lot of different systems for everything. which is one of the reasons why we can't have nice things. e. g. as much as i want this to be true, i can't argue that all graphical software should be written using Qt and no one should ever touch gtk.

@wolf480pl @normandy @leip4Ier It's a matter of tooling. Take GNOME Builder for example: you can enter the URL of a repository, and it will automatically clone it and if it has a Flatpak manifest, also it fetches the SDK and runtime. Building the application is one click away then: The effort to start contributing is close to nil.

Precisely tooling made for distributions makes things more complex, because it adds an intermediate layer of cruft. Often distros patch packages in bad ways, too.

@wolf480pl @normandy @leip4Ier In particular the Debian packaging tools are among the most inescrutable ones, and the organization of their source repositories for packages is tremendously far from obvious 😑️

Good luck explaining to a newbie how it came to be that the build of their modified source file failed because the distro packaging files include patches that don't apply cleanly. And that's if they managed to get to understand the arcane Debian packaging process.

@aperezdc @wolf480pl @normandy remembered the most recent vlc drama, with a cve assigned to them. the issue was ubuntu having an old vulnerable version of a library vlc uses, but everyone just blamed vlc.

(this is a people issue, but still)

@aperezdc @normandy @leip4Ier
Often they patch packages in a good way, too.

Nice to hear flatpak has tools to easily build things from source.

But I don't think distro's tools are any bigger a layer of cruft than flatpak's. Either way, you need to abstract over the upstream's buildsystem (be it autotools, meson, CMake, custom makefile, or a custom configure script) and have a file that specifes how to make a package out of it.

@wolf480pl @aperezdc @normandy didn't archlinux become so popular just bc everyone was tired of debian and ubuntu patching stuff?

@leip4Ier @aperezdc @normandy
can't speak for others, but I for one switched from Mint to Arch not to have newer packages, but to be able to, like, configure things without distro scripts getting in my way.

Paradoxically, the more out-of-the-box a distro is, the more skill, patience, and deep understanding is required to do anything custom with it.

@wolf480pl @aperezdc @normandy that too, but it's related to what i was talking about. ubuntu patches stuff and runs custom scripts for better distro-wide integration. if you wanna do something outside of that integration (suppose you wanna use a custom window manager), things break. that's why you'd wanna have upstream packages.

@leip4Ier @aperezdc @normandy
I'd say these things are orthogonal.

Many things can be hooked up together with scripts without patching the software, and many patches being applied don't affect those scripts.

And even Arch adds many scripts on top of upstream packages, ranging from properly written systemd units to archlinux-java to netctl.

And even Arch patches things when necessary. And it often runs sed on poorly written makefiles to add DESTDIR.

@leip4Ier @wolf480pl @normandy I know many people who ended up on Arch one way or another, many of them (including myself) definitely wanted a “closer to upstream” and/or “simpler tools“ experience.

(Me, I started with SuSE in 1998, then did SuSE → RedHat → Debian → Gentoo → Arch along the years. Also dipped toes on MacOS X when Apple's hardware weren't boring PCs, and since ~2007 almost always had some second machine with a BSD.)

@wolf480pl @normandy @leip4Ier Sure, in general tools used by distros are smaller than an IDE like Builder. The target audiences are different, though!

@wolf480pl @leip4Ier @aperezdc What happens when the software you want isn't in the distro's repositories or is heavily outdated? You end up need to learn how those build systems work anyways. Except now you also need to figure out how to satisfy the packaging system as well.

Granted the difficultly depends on exactly which build system and packaging tools you use. In that respect Arch's PKGBUILD and similar systems do have the upper hand while the likes of Debian's APT fall behind.

@normandy @leip4Ier @wolf480pl Absolutely true. Simpler tooling is possible and Arch packaging tools are definitely a good example (as are Alpine's).

Also Arch as a distro discourages applying patches on top of the sources, which nudges people into getting patches accepted in their original projects instead.

Debian, on the other hand infamously “patched” OpenSSL making it insecure:

@normandy @leip4Ier @aperezdc
wrt. difficulty, I don't think it's APT that makes Debian packaging suck, it's more of debhelper's fault. But yeah, it's awfully complex, if you want tocomplicated do something more than just modifying source code of an existing package.

Wrt. outdated, I agree that it can be a problem if you end up using a "stable" distro by accident. But there are some usecases where people prefer outdated packages with backported bugfixes.

@wolf480pl @aperezdc free software values don't say anything about this, and we've used npm, gem, go get, pathogen/vundle (for vim), .. for a long time already. it's similar, though i don't know how would all these work in a flatpak system.

i think with the current pace of software development, it's hard to do packaging as it used to be done.

@wolf480pl @aperezdc there're ubuntu ppm, arch aur and fedora i don't remember what, but few people are willing to do all the work for their own software, and distro maintainers can't just package everything. so i prefer appimage over nothing.

not flatpak though. i can see how it can be useful, but to me it's just another thing which will break my system, but which i have to install to get that one package exclusive to it. unless the package is v important, not gonna do it.

@leip4Ier @aperezdc
I think npm, gem, go get, pip, etc. are used mostly by developers writing code in a particular language.

Imagine you've never done anything related to, let's say, Haskell. And you want to install pandoc. Which happens to be written in Haskell.

If pandoc wasn't packaged by your distro, would you install cabal (and possibly stack) just to install pandoc and all its dependencies?

@wolf480pl @leip4Ier There “third parties” does not imply that there will more be proprietary software being developed: they can well be other people making Free Sofware—if Flatpak makes it more approachable to write Free Software (it might be, remains to be seen!) then one could argue that in reality it may contribute to make Free Software healthier 🤔️

(Again, a reminder that I am no fan of Flatpak/Docker/virtual machines/etc.—just trying to look at things from a different perspective.)

@leip4Ier @wolf480pl Oh, you would be surprised how much is linked inside the main Chrom{e,ium} binary:

% pacman -Ql google-chrome|grep -E '\.so$'|wc -l

Their main binaries are a 150+ MiB mammoth. Meanwhile, WebKitGTK is half the size, but of course if we count sizes for its dependencies (GStreamer, libsoup, glib-networking, etc) plus a browser (let's say GNOME Web) then the size goas a bit over the 100 MiB mark.

Web engines are incredibly huge these days 😓️

@leip4Ier @wolf480pl Either way, some people inside Google are truly into Free Software and sometimes good things happen. Case example: getting the Brotli ( and WOFF2 ( libraries to be unbundled from Chrom{e,ium} and have actual releases that distributions can use. At some point we had copies in the WebKit source tree, but they are long gone ☺️

Now if we would only manage to convince a few key people to do the same with ANGLE and libwebrtc…

@aperezdc @leip4Ier

these fall under the general umbrella of "codecs and such" and it's obvious that if you design a codec/format/etc. you want _everyone_ to adopt it, and want to make it as easy as possible to do so.

FSF even advises to use permissive licenses for implementations of open-standard codecs and file formats.

@wolf480pl @leip4Ier …yet they were originally bundled and it took some lobbying to get them out of the Chromium tree 🤷️

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.