Ah yes, let’s skip the social part and get right to the obligatory consumption.

I don’t really care for Halloween, but I don’t actively hate it either. I like seeing kids and parents in cute costumes walking around. To me, the whole point has always been one of social activity, of walking around the neighbourhood and showing off your cool costume and such. You know, the whole “reinforcing horizontal social ties” deal we’ve done since forever.

So if YouTube provided an RSS feed for its channels, all videos would be podcasts because they can be processed as audio-only and are distributed via RSS?

What exactly makes a podcast then?

Probably because there are no sanctions against them that his government is cracking down on? I don’t think he wants to get involved in politics so much as stay out of prison.

I mean, if you asked me something like that about our system’s sales, I’d have an answer for you in a few minutes. But then, I’m BI and not Accounting, so I’m probably more proficient at pulling aggregated data straight from the archive DB.

Is a middle name mandatory for you?

That sounds like a neat option, if it was optional…

I do think that we should continue to encourage developers to create native builds when they can

Yes

My problem is calling people who want Linux native games misguided or wrong. I really don’t think that’s helpful.

I’d prefer games to be compatible natively too, so I definitely count myself among them. I think it’s an issue of visibility, the usual “loud and visible minority”. A thousand calm “I would prefer games were natively compatible” just don’t stick out as much as one aggressive “Fuck every company that doesn’t make their games natively compatible, and fuck you for supporting them by buying their game”.

I just don’t think Proton is the worst thing to happen to Linux Gaming because it allows developers to target alternative platforms without having to actually support them. This is where my personal impression of “misguided” (again, probably a loud minority) native game advocates comes from: Platform Inertia works because people stick with the platforms holding things they like, and the things on those platforms stay there because their prime audience is there. If the extra effort (=cost) of supporting Linux doesn’t match a sufficient uptake (=revenue), profit-controlled companies won’t do it (as they can’t justify it to their shareholders).

This isn’t just an issue with the evil corpos, but with the whole system itself. Screaming at consumers to change their habits won’t make much of a dent either there. Compelling people to change rarely has lasting results, if any. Better to invite them over and make the switch attractive enough to break that inertia. Only then can we meaningfully challenge the status quo.

It comes down to strategy accounting for ideological passion, an understanding of social and economic dynamics and patience. By and large, I think many understand this. Proton may not be what we want, but it’s an ally in achieving our goal. When we get to the point where it’s no longer “Underdog Linux against the near monopoly of Windows”, we can push harder (and honestly, I don’t think Valve would be terribly upset if Proton became obsolete and saved them resources).

We shouldn’t stop asking for native builds, so long as we do it mindfully and respectfully.

I maintain that Proton could be a gateway to open the Linux market and create a sufficient share of revenue that, if and when it is shutdown, it’s lucrative enough to make natively compatible games.

It’s a bit of a deadlock issue: Most Devs will only develop for Linux if they see there’s money to be made there and they can estimate it will be worth the effort. But we need games on Linux for that to happen.

Proton is a stop-gap solution to provide the latter and lower the barrier on both ends: I can play games on Linux and devs have an easier time shipping their games to a Linux audience. I hope long term, the major frameworks will feature defaults that allow devs to easily do so without relying on Steam, but until then, Proton is better than nothing.

deleted by creator

I’ve had to grapple with pipewire. My old pulseaudio config didn’t seem to work and I wanted to migrate to the pw config file format anyway, but I found the pw docs to be highly opaque. You get a thousand solutions for commands online, or tools you can do it visually in, but to apply that config you need to start the tool…

I’m a noob, granted, but there seemed to be a lot of assumed common knowledge that I just don’t have. And if I don’t even know what I’m missing, it’s hard to google for it.

edit: not for sexual purposes

That’s clever, I like it

How was your trip?

Oh you’re still going? Nice. Enjoy your stay!

Can we have both? A concise textual description and a video exemplifying the features?

I stuck with the ~mozillateam PPA for quite a while, regularly trying the snap and reporting bugs to Mozilla

Mad respect. I wouldn’t have had that amount of time or patience due to personal circumstances, nor the ideological drive to see it work well, but it is people like you that compensate for those of us that can’t or don’t want to contribute to that same extent. All other preferences aside, I appreciate that contribution to a better ecosystem.

The alternative (not providing a Firefox deb in their repos any more, resulting in users with the firefox deb suddenly being abandoned) is a whole lot worse.

You’re right, that would have been the worst “solution” - none at all.

What you’re suggesting is, IMO, a move that simply confuses new users. “Firefox updates automatically. Why is it suddenly asking if this update is okay? clicks no, has an unmaintained Firefox”

Between my experiences with supporting users and corporate lingo, I don’t think so. Provide a concise, maybe slightly propagandised ad about how snap is better and more secure, then provide the users with a highlighted button “Yes, I want to continue automatic security updates” and a subdued “No, I want to maintain it myself” along with a help pop-up for a slightly more technical “What’s the difference”.

Most casual users I know that just want things to work - myself included, in some cases - will just skim it, see the appealing buzzwords, click “Yeah whatever, I don’t care”. The more technical ones would probably google it, read the ensuing arguments and recommendations, and either decide like you did to give it a shot or end up responsible for their own thing (which is both the liberty and the jeopardy of Linux in general: you can do your own thing, but if it breaks, that’s on you).

A Pin-Priority of 1 would have been the “correct” way to do it IMO, as that blocks automatic installation as a dependency, but still allows automatic upgrades if the user manually installs the package. But instead, Linux Mint took a hostile approach of choosing a negative number, which actually tells apt to remove the package even if the user has manually installed it. This is overriding user choice in a way that neither Ubuntu nor KDE Neon did.

I wasn’t aware of that detail (given I never cared about snap anyway, I never would have run into the issue). Paired with the unwillingness to remedy resulting problems, that is indeed a shitty move. I’d consider it on par with suddenly replacing my firefox with a version that worked very poorly*, which also caused me confusion and frustration, but unlike the firefox case, I don’t see any graceful way of handling that transition in a user friendly manner.

*It just occurred to me that some of the issues may have been exacerbated by running on an HDD as opposed to an SSD. Prior to tossing Windows entirely, my SSD held my Win7 installation, while Ubuntu got its own partition on the HDD. I never migrated it to the SSD, instead using its limited 256GB to hold whatever games I was playing at the time.

Re: Linux Mint hostility, apathy about resulting problems, misinformation, paternalism

Those are all good points.

Being hardliners about their philosophy is a common phenomenon in the Linux sphere. While I agree that it’s not particularly user-friendly (and generally value open debate), I also feel that a distributor is within their rights to do what they feel is right rather than caving to users. Conversely, that’s a philosophy I wouldn’t want to endorse either.

The charge of paternalism is one I would level at Canonical too, given the concerns I expressed about pushing towards a monolithic, corporate controlled system. Good intentions notwithstanding, I worry it may pave the path to hell. They’re more subtle about it, but that’s no more of a redeeming quality to me than MS slowly creeping in new bullshit. (I’d gladly be wrong about that, of course - even if I may not want to use it, options are a good thing.)

But misinformation is an problem and I concede that I may well have fallen prey to it myself. I did try to search for info about open source options like what you mention, but my results and interpretations may have been biased, and I didn’t spend enough time for a comprehensive understanding. I could make excuses, but that won’t change the fact of my error.

I’m just elaborating on the one thing since you didn’t seem to get why it’s a problem.

I didn’t. Thank you for taking the time.

There were bugs about a decade ago about unattended upgrades not obeying pins correctly, but those were bugs and, AFAIK, have long since been resolved.

It can’t have been more than a few years ago, given that the snap move happened with 22.04 which released about 2.5y ago and I encountered that error. But I was, for all intents and purposes, a noob, so I can’t exclude the possibility of user error. I’ll take your word that this no longer happens.

nix, immutable distros / building blocks, Android comparison

I’ve never tried either nix or immutable distros. The idea of an immutable base, vetted for compatibility issues between what you refer to as the “building blocks”, seems appealing from a “I don’t want to worry about the details” perspective for casual use.

Android is convenient for another reason where I’m not sure how relevant it is to our context. It offers a unified version with a common set of features and interfaces, allowing app development relying on that version.

Exchangeable blocks can introduce complication in the same way that, for an example I’m familiar with, node package dependencies will feature a whole set of “at least this version” or occasionally “exactly this (major) version” specifications to ensure the individual parts all meet the requirements.

It’s a tradeoff between modularity and reliability, as I see it, and both have their merits. I do tend to favour modularity, which is why I do appreciate the concept of snap as I have now come to understand it. Like I said, my misgivings are with Canonical more than the technology itself.

I’ve enjoyed this conversation with you, because we’re each giving opinions and learning from each other. […] It was, to be entirely honest, entirely different from the type of conversation I was expecting coming into this thread, which began as yet another piling on and telling people not to use snaps specifically because of factoids that are misinformation. Thanks for the very good conversation instead!

Likewise. I’m no fan of the adversarial nature of many conversations in the tech sphere either. Progress thrives on creativity, if tempered by skepticism and scrutiny. If we’re willing to share perspectives, we can catch each other’s blind spots. And if it comes down to personal opinions in the end, at least we can form those consciously and part ways a little wiser than before.

I’d be curious to hear about your other misgivings some time, but this conversation has been going on a while now and I may not have much time to read or respond the next few days. In any event, thanks for taking the time!

I don’t think you trust

For me the Linux Mint developers’ hostility to snaps (which in my experience tend to be the best trade-offs for my needs) is one of the many reasons I won’t use or suggest Mint.

I mean, analogous to firefox example you supplied, you could just delete nosnap.pref and be on your way.

Also, snapd keeps a snapshot of your per-revision configuration from an app for a while after you remove it. You can run snap saved to see all the current snapshots. It doesn’t remove your $SNAP_USER_COMMON directory for that snap (which is where the Firefox snap stores its profiles), so moving from the snapped Firefox to the version from apt is just a matter of moving the .mozilla directory out of ~/snap/firefox/common to ~/

I could have sworn I checked that, but I was a lot less familiar with these things at the time, so maybe I missed it.

I don’t think snaps are a bad thing on principle, my own bad experiences with them notwithstanding. I could also live with a for-profit operating its own curated package repository as part of its service. I’d personally prefer not to use a client locked into one particular package provider, but if that’s the tradeoff for that provider’s security guarantee that your packages are all Canonical-certified safe, I’d accept that. If it were preinstalled with an OS, that’s fine. If they make it the default Software Store, we’re on par with the Microsoft Store and other App Stores and those too provide a utility and convenience, particularly for those less technically minded. The ship on “don’t bundle your browser with your OS because that’s monopoly grabbing” has sailed long ago anyway.

All of these are things I’m fine with, even if I personally would choose not to use them. If that was all, I’d still recommend Ubuntu as a beginner distro, because it was my intro to Linux too and I found it good at the time.

The thing that irks me is when they’re being dishonest about it. You no longer wanna support a deb package in your repos? Fine, let me know, offer me a one-click migration option for installing the snap instead and moving my data over, give me the whole marketing routine of telling me how much better your new solution is, but make it my choice.

Having a transition package for a name change or breaking up a larger project into modular packages is one thing. Using it to instead run an entirely different package manager pulling from a proprietary repo?

Worse still, if you had trouble with one app so you went and found a non-snap repo, you pinned it with higher priority, reinstalled it from the new source and thought you were in the clear because that worked as expected.
But you forgot or didn’t know to also put a negative priority on the snap source because pin priorities seem intuitive enough, only for unattended upgrades to look at the pins and say “That sign can’t stop me, because I can’t read” (pins from repos I don’t know) and reinstall the snap…
I get that automatic upgrades don’t pull from all repos by default for security reasons, but at least look at the priorities and realise “Ope, not gonna touch that, I’ll notify the user to do it manually if they trust the update”.

And that, for me, is the part that takes it from apathy to disdain; the part that goes beyond “each distro has its own preferences, no big deal”; the part that reeks of a profit-oriented company aiming for vendor lock-in.

To close the topic out: All of this is just explaining my stance; I’m not telling anyone what to do or not to do. You gave your point, I gave mine. By all means, if it works best for you, I’m not getting in your way. I just wish there was a better option.

Thanks for that correction then. I wasn’t conscious of that detail.

In any case, the issue remains that, if the vendor’s default repositories push for a type of package I don’t want, I either have to manually find and vet third party repositories I trust or find someone else to rely on for defaults I’m fine with.

The difference between “I want a different source for a single package, so I’ll manually select a different source for that one” and “I don’t trust Canonical to select sources I agree with anymore” is one of scale. I’m fine with manually pinning the transitional package, uninstalling it and the snap (hopefully remembering to back up my profile before realising that it also deletes user data) adding a ppa, reinstalling it and reimporting my profiles just for firefox.

But if I feel like I have to fight my distro vendor over not using their preferred package distribution system, it’s probably better to jump ship - other vendors have beautiful distros too.

(Also, “you can just use a different source” is part of the reason people prefer not to use snap, where you can’t do that)

Correct me there, but wasn’t the “select source” thing intended to be about different deb sources?

The issue is that what you expect to be a deb package manager ends up redirecting to snap anyway. It’s not a different source, it’s a different system. If I have to manually take steps to avoid using the distro vendor’s default sources because they just redirect to a system I don’t want to use, I might as well look for a different vendor.

And so I did

IIRC, the issue was that - unless you take steps to explicitly prevent it - Ubuntu would occasionally reinstall the snap version. I don’t remember the details, been a while since I had to dance that dance, but I recall it being one of the things that put me off snap in particular, Ubuntu in general and sparked my search for a different distro.

I’m now on Nobara, a Fedora-based gaming-oriented distro maintained by GloriousEgroll (who also maintains the popular Proton-GE)