trevor (any/all)

No, I am not running on a disk drive, obviously. I package a major application for Snap and have done extensive testing. I have way more experience with Snaps than I want. It is not dishonest and it is cold starts, meaning initial installation and updates, not just first boot.

And, as I said, when a given Snap autoupdates without making it obvious to the user, it’s gonna appear like it froze for no reason the next time you open it while you’re waiting for it to launch.

Snaps are a bad technology.

Most people hate Snaps because the Snapstore backend is proprietary (which is a valid reason to hate them).

I despise Snaps because their cold start times are dreadful (yes, even with LZMA compression, which Canonical wants you to believe solved this). When a Snap launches after first installation or after an update, you’re looking at anywhere from 15-60 seconds of unresponsiveness while your system appears to fail to launch the application, even though it’s actually because the shitty Snap needs to decompress the disk images and pollute your loopback devices.

Combine the terrible cold start times with the fact that the default behavior of Snaps is to phone home to the Snapstore whenever they want to check for updates and you’re going to create bad experiences for people (especially newbies) that think “Linux is garbage” because Canonical decided this was a great idea to force on people.

They also keep Snapifying core parts of Ubuntu like the kernel itself and GNOME, making them impossible to avoid if you want or need to use Ubuntu.

On the other hand, I feel like many of the headaches of packaging and using packages could have been avoided if static linking were the default. Sure, things like openssl should probably be dynamically linked for more immediate updates when security issues arise, but most of the other third-party libraries for applications should be statically linked.

Otherwise, we end up reinventing static linking for decades, which is what things like Flatpak, AppImages, Snaps (🤢), and presumably Toolpaks exist to solve.

Yes, Flatpaks and Snaps (🤢) also provide application sandboxes, but it would be much better if they could focus more on sandboxing than also having to worry about dependency management for application libraries.

Arguably, if static linking were the default, Toolpaks wouldn’t be necessary either, even for immutable systems, because static binaries can be easily installed to a mutable part of the system.

Honestly for the best lol.

Jokes aside, I don’t see why this would exclude those languages. Just because they need a runtime doesn’t mean the runtime can’t be bundled (even if it is annoying to do so). I would imagine for runtime-dependent tools, they would just make a generic runtime bundle that can be shared between packages, similarly to how it’s done with flatpak.

I think “tools [bundling] all their dependencies” is more likely to mean that you need to ensure that third-party libraries your tool depend on are bundled, which is good. End users, even if they’re developers, shouldn’t need to hunt those down just to use something.

This browser was really cool because, despite being WebKit, it was compatible with Firefox and Chrome extensions. That alone made it more worth trying than any non-FF or non-Chromium browser.

I hope that any other WebKit browsers (like Epiphany/GNOME Web) take that from Orion and adopt it in their own browser. That would make them viable.

Yep. I hate to see it being used as a default license in the Rust ecosystem. Wonderful language, but terrible corporate culture.

Seriously. I had to read that five times to see if I was missing sarcasm. What a fucking awful product.

Riots for just causes like racial equality and anti-fascism are good, actually ☺️

But god damn, you must live in another reality if you somehow believe movements for justice are somehow the biggest disruption to elections and not the jackboot thumbs kidnapping people and sending them to concentration camps. I hope you snap out of it.

It’s a customizable IR receiver, yeah.

Was it harassment to acknowledge your online name?

You’re sadly mistaken if you think the people that rightly don’t like your heinous behaviour are kiwi farmers.

But sure, everyone that doesn’t like you just happens to be bad people from a stinky Nazi forum. Whatever you need to tell yourself.

Also, hi AdmiralPatrick’s alt 🙂

I’ve always found CEC to be insufficient. If you need to access anything more than directional nav, enter, and back, you can’t. I have CEC on my Linux machine, but I leave it off because it just can’t do most of what I need it to.

The Flirc receiver is the best $25 I’ve ever spent. You can use it with basically any TV remote and turn it into a decent PC input device.

You can map any app with decent keyboard navigation support to work with up, down, left, right, enter, etc. and get a pretty seemless TV experience.

I’m currently using Bazzite with Steam’s Big Picture mode, yes. I’d like to switch to Plasma Bigscreen, but I’m not sure it’s ready just yet. I keep trying it on my laptop every few weeks, but there are some crashes I keep running into.

I can’t wait to switch away from Steam Big Picture mode though, as it’s pretty tedious adding shortcuts and having to use a Decky plugin to download art for them. It’s very apparent that Steam isn’t meant to be used this way (even though once you set it up, it’s not bad). Plasma Bigscreen just reads the .desktop entries, which is a lot better.

I use a Linux machine that boots to a big picture interface with these apps:

• Jellyfin Desktop client (pirate everything)
• VacuumTube (YouTube TV interface with adblocking)

And I use a Flirc receiver so I can use a remote for all of it.

deleted by creator

My understanding of gccrs is that it merely provides a way to compile Rust software with GCC instead of LLVM, which is great! But it’s such a small piece of the Rust ecosystem (it’s merely a frontend). Maybe it’d be a good starting point for a more copyleft ecosystem in the future though.

This is a bit of a tangent, so I didn’t include it in the above comment, but I don’t think “open source” is sufficiently anti-capitalist, so the (A)GPL was never going to save us to begin with. “Open source”, as defined by the OSI (a.k.a. a handful of megacorps in a trench coat) and the FSF, prevent “discrimination of use”. So if you want your software to be “open source” or “free software”, you have to accept that your software can be used by for-profit entities to exploit your labor, and potentially to perform heinous acts, such as military or surveillance usage. What we currently call “copyleft” is actually just copylib 😭

No open source license, not even the (A)GPL, allows you to forbid this. Unfortunately, I don’t see an alternative framework being widely adopted anytime soon. It seems that the best you can do for now is use niche licenses like this and just accept that your software can’t be considered “open source” :/

IMO it isn’t in bad faith any speech making that apparent.

I’m not sure I understand what you meant (there may be a typo in there).

The language, as an inanimate object, doesn’t have an ideology, sure. However, people running the show in partnership with the ruling class have.

This, I agree with. It is very concerning that Rust has so much corporate buy-in. And the structure of The Rust Foundation being operated more like a business than something like the Zig Software Foundation does worry me.

But I often feel the need to chime-in and correct the common misconception that Rust rewrite == corpo-relicense. It’s false and I think the conspiratorial coupling of Rust to corporate embrace-extend-extinguish only serves to discourage people from writing better software.

I would love to see a community fork of Rust and its ecosystem one day, but I don’t think we get there by discouraging people from writing or using Rust software.