Linux HATES Me – Daily Driver CHALLENGE Pt.1

[Jeppes]

But still, why would you choose a rolling release or an Ubuntu fork if you want a nice stable ride? Just run boring lts Ubuntu.

[Arika]

1 minute ago, Jeppes said:

But still, why would you choose a rolling release or an Ubuntu fork if you want a nice stable ride? Just run boring lts Ubuntu.

as has been mentioned multiple times in this thread and in WAN show multiple times.

 

Its what the community said, both the LTT community and Linux Community. a lot tier lists of of "best linux distro for gaming" or "Best linux distro for beginners" have pop OS and/or Manjaro near the top, the poll that was put up asking which distro Linus should use, Manjaro was number 1.

[Jeppes]

2 minutes ago, Arika S said:

as has been mentioned multiple times in this thread and in WAN show multiple times.

 

Its what the community said, both the LTT community and Linux Community. a lot tier lists of of "best linux distro for gaming" or "Best linux distro for beginners" have pop OS and/or Manjaro near the top, the poll that was put up asking which distro Linus should use, Manjaro was number 1.

Mistake number 1. People are stupid and popularity is rarely a good way of making choices.

[Arika]

4 minutes ago, Jeppes said:

Mistake number 1. People are stupid and popularity is rarely a good way of making choices.

LOL, are you serious?

 

how else would a newcomer to Linux have any idea where to start?

[finest feck fips]

tl;dr: system package manager acted like a system package manager is supposed to; only way to ensure that ‘installing X requires uninstalling Y’ ‘never happens’ is to keep people who don't know what they're doing from touching one of those; this is not really a Pop!_OS issue

 

3 hours ago, Arika S said:

Its what the community said, both the LTT community and Linux Community. a lot tier lists of of "best linux distro for gaming" or "Best linux distro for beginners" have pop OS and/or Manjaro near the top, the poll that was put up asking which distro Linus should use, Manjaro was number 1.

 

The idea that ‘it should not be possible for something like installing Steam to uninstall your desktop environment’ is in contradiction with the ideas that this issue was really a bug, or somehow related to distro choice.

Running `apt-get install steam` is not asking APT to ‘just install Steam’. `apt-get` is a tool for managing all of the software installed on your entire system, as a single cohesive unit. When you are running `apt-get install steam`, you are telling APT:

Quote

Add `steam` to the list of everything I want integrated into my operating system, and see if it's possible to meet the requirements of everything on that list afterward. If it's not, offer me some solution(s) that involve modifying the list so that `steam` can be on it and I can meet all the requirements of everything remaining on the list.

This is not a special Steam thing. There's no difference here between your bootloader and your word processor. Any time you install anything with apt-get (or some other frontend built on APT), you are asking APT to reconsider the installation status of every piece of software on your system (as far as it knows).

This is not a special Debian thing. This is true of every distribution's system package manager, except in the case of distributions which are research projects (or overgrown research projects whose current userbases consist mostly of developers). And the package managers on other distros have even less compunction about removing system components; the package manager on Manjaro will cheerfully allow you to uninstall itself, without any kind of special warning at all.
 

This basic arrangement, where one tool manages all software and no software is special software, is actually pretty nice in some ways. It means that you can have a pretty complete system and only ever use only one tool to handle upgrades for everything on it. It means that you can easily and quickly replace your bootloader, your display server, and your system sound mixer with alternatives if you'd rather try other ones, using a tool you're already familiar from its more quotidian uses. It means you are spared the hell of a dozen fucking apps running their own special snowflake self-updaters, with half of them preferring to run in the background at all times. Unfortunately, it also means you have to actually think about what you are doing and how your system fits together. You have to be awake enough to think

Quote

Gee, it seems abnormal for installing one thing to require me to uninstall 90 things, and for my system to shrink afterwards. Perhaps I should figure out what is going on before I push this big red button.

instead of treating the output of your package manager like a EULA.

 

But short of picking up a hammer and nailing everything down in favor of a different mechanism for distributing end-user applications (this is the approach of Fedora Silverblue, or something like Android) or making radical, paradigmatic changes to system-level package management (à la Nix, Guix, Luet, and Distri), there's no sane way to ensure that it's ‘just not possible’ for end users to discover that installing a package may involve changes to their operating system.

 

There are a few insane things you could combine in order to approximate that state of affairs, though. You could:

• (if you're a downstream distro) completely fork your upstream distribution (this is what all of the relatively stable downstreams of Arch Linux have to do) so that you can (sort of) control the state of the package lists on every user's system,
• disable the ability to add third party repositories to your system-level package manager (or be so niche that nobody bothers to make any),
• set up an extremely onerous automated QA or CI system on what amounts to a supercomputing cluster (some distros actually do this, with varying degrees of success),
• put up a shitload of baby gates into your system-level package manager, which will require you to fork it if you have an upstream.

 

Bear in mind that a ground total of like 5 people have ever worked on Pop!_OS. (And fwiw, they've already committed to doing the latter two items there, in some form.)

If distros want to attract and serve users like Linus Sebastian, something needs to change. But what we're looking at is not a bug, or some obvious ‘oopsies, I forgot’ on the part of any distro developer.

 

If you think that this is an issue which should never, in principle, be possible, then we're talking about a problem shared by every Linux distribution Linus might have tried. If you think instead that things like this will always be possible, but distro developers should put up another set of bumpers, warning signs, and gates every time something like this happens, then you have room to criticize Pop!_OS or System76 in particular. And if you don't understand why that is, you don't know enough about how any of this works to be spouting off about which distros are ‘better’ than one another and why, or ‘diagnosing’ the cause of Linus' woes.

[Arika]

13 minutes ago, finest feck fips said:

Snip

None of this is relevant to what you quoted from me, or anything else I have said previously.

 

I know how apt works, I don't need the tech lesson.

[finest feck fips]

18 minutes ago, Arika S said:

None of this is relevant to what you quoted from me, or anything else I have said previously.

 

I know how apt works, I don't need the tech lesson.

That's true. All of my uses of ‘you’ were the Americanized, general-purpose second-person. I only quoted you because as the most recent poster who got sucked into the always boring ‘no it was the wrong distro discourse’, your post reminded me of a pet peeve I have about Linux discussions and put me in why-the-fuck-are-we-having-this-conversation mode.

Sorry that I did a poor job of communicating that. I thought about going back and deleting the blockquote after my post turned into what it is, and clearly I should have.

[leadeater]

36 minutes ago, Arika S said:

None of this is relevant to what you quoted from me, or anything else I have said previously.

 

I know how apt works, I don't need the tech lesson.

Broken packages should never be released in to and available in a repo like that, as you said. The fact that it happened demonstrates an issue with the release workflow. Now of course similar crap happens in Windows too with Windows Updates but a problem shared is still a problem. Nobody likes it when Windows toasts itself due to a Windows Update and nobody likes it when a supposedly curated and verified repo toasts your Linux system. The only saving grace and additional factor was that Apt correctly said "Hey bro this will remove a bunch of shit, you sure mate?", problem is an lay person entering in to Linux will naturally say "Yes of course, I'm installing X software so yes I want to do this".

 

Sure Apt is telling you it's going to uninstall a bunch of stuff but the problem there is since you are installing something there is an expectation that well maybe the thing I am installing is installing it's own or newer things of these, why else is it removing them 

 

Thought processes here is pretty much "what's the worst that can happen, screw it yes".

 

Broken things shouldn't be released in to upstream channels, it happens but it shouldn't. We should be able to trust these repos, every time there is a problem that hurts the trust of them, and subsequently the Linux distro someone was trying to learn.

[Managor]

I’m really curious if Linus’ audio problems could easily be mended by using `pipewire` and `pipewire-pulse`

[finest feck fips]

3 minutes ago, leadeater said:

Broken packages should never be released in to and available in a repo like that, as you said.

The brokenness here was a conflict between multiple packages. Dependency conflicts aren't features of individual packages. ‘Keep broken packages out’ is not an answer to this problem, because there was no one ‘broken package’.

 

6 minutes ago, leadeater said:

[This] demonstrates an issue with the release workflow.

Yes. Whose release workflow? Steam's? Debian? Ubuntu's? Pop's? As long as a downstream distro directly includes the repositories of upstream in its configuration, upstream can introduce packages which are just fine for upstream, but incompatible only with packages in the downstream distribution. And testing the impact on packages outside the distribution is out of scope for those upstreams.

 

21 minutes ago, leadeater said:

a supposedly curated and verified repo

Pop!_OS users have the Ubuntu repos directly in their APT sources, and the Ubuntu repos are a moving target separate from the Pop!_OS repos. Even if this particular issue did not involve any Pop-specific packages, this kind of problem is not entirely eliminable as long as the former is true. Pop!_OS developers can curate their repos to high heaven, and Ubuntu can always still make changes that introduce conflicts with packages in Pop!_OS.

[leadeater]

1 hour ago, finest feck fips said:

The brokenness here was a conflict between multiple packages. Dependency conflicts aren't features of individual packages. ‘Keep broken packages out’ is not an answer to this problem, because there was no one ‘broken package’.

A package is broken if you release it in to a channel that it's not compatible with, a package in a repo that has dependency conflicts with the package versions contained in the channel is still a broken package. Anything with a flaw that will cause a system issue is by definition broken even if it's possible to have met whatever dependencies, such is only possible manually and outside the standard scope of the release channel.

 

1 hour ago, finest feck fips said:

Yes. Whose release workflow? Steam's? Debian? Ubuntu's? Pop's? As long as a downstream distro directly includes the repositories of upstream in its configuration, upstream can introduce packages which are just fine for upstream, but incompatible only with packages in the downstream distribution. And testing the impact on packages outside the distribution is out of scope for those upstreams.

Anyone who releases a package in to a repo is responsible for ensuring it's compatibility with it and anything associated with it. It is also the repo maintainers responsibility and it's up to them to define and enforce this process. If you are a distribution maintainer and have direct control of them then it is you, if you are reliant on and use upstream then you are reliant on them. If it becomes a problem then it's on you, the downstream to either consider solving it or living with it.

 

Trying to figure out who's problem is near as much irrelevant in this context, an unmodified distribution was broken due to the provided repos and standard system operating of using them. User error was a contributing factor but not the root cause of the issue. Blame shifting makes no difference, Pop!_OS bares this responsibility. One of the huge and ongoing problems in the Linux community is blame shifting, nobody wants to accept any responsibility for any issue because it's possible in some way to shift it to somebody else simply because of the way Linux is. Note this is largely a community issue not a developer or maintainer issue who do understand and accept these problems, they just aren't easily solved long term.

 

Try this approach in a corporate environment, watch just how not accepted it is.

 

Everything above is literally why Red Hat Server and Red Hat Satellite exists and locally controlled repos with defined processes in updating them through predev, dev, test, prod environments etc, or equivalent for other distributions and chosen methods of control.

[finest feck fips]

1 hour ago, leadeater said:

A package is broken if you release it in to a channel that it's not compatible with

Okay, so the brokenness depends not only on the package but its context. That means it's not a property of the package alone. To call it a ‘broken package’ is at best a sloppy shorthand and at worst a misleading way to think about the problem. This is like saying a canoe is broken if you set it on the ground instead of into water, or saying a magnet is ‘pully’ if you put it next to something that it pulls. Whether the canoe glides smoothly is not a feature of the canoe; it's a feature of the canoe and it's environment. Whether a magnet pulls or pushes is not a feature of the magnet; it's a feature of the magnet and a particular object with a particular charge.

 

1 hour ago, leadeater said:

Anyone who releases a package in to a repo is responsible for ensuring it's compatibility with it and anything associated with it.

What does ‘associated with’ mean? If I create a downstream repository based on Debian and an installer USB image that includes it tomorrow, is Debian now ‘associated’ with my new distro? Is the maintainer for the Debian package for Chromium now ‘responsible’ for ensuring that package's compatibility with my distro?

 

1 hour ago, leadeater said:

If you are a distribution maintainer and have direct control of them then it is you, if you are reliant on and use upstream then you are reliant on them. If [this reliance] becomes a problem then it's on you, the downstream to either consider solving it or living with it.

Right. I described what ‘solving it’, in this context, would look like right here:

 

Spoiler

3 hours ago, finest feck fips said:

There are a few insane things you could combine in order to approximate that state of affairs, though. You could:

• (if you're a downstream distro) completely fork your upstream distribution (this is what all of the relatively stable downstreams of Arch Linux have to do) so that you can (sort of) control the state of the package lists on every user's system,
• disable the ability to add third party repositories to your system-level package manager (or be so niche that nobody bothers to make any),

 

But that doesn't resemble looking at individual packages and asking if they are ‘broken’.

 

1 hour ago, leadeater said:

Try [shifting blame] in a corporate environment, watch just how not accepted it is.

I so badly wish that were the case. But blame shifting, blindly referring people to other departments, saying that things that are possible but require deep change are simply impossible, etc., are in fact extremely common in corporate environments.

 

1 hour ago, leadeater said:

Everything above is literally why Red Hat Server and Red Hat Satellite exists and locally controlled repos with defined processes in updating them through predev, dev, test, prod environments etc, or equivalent for other distributions and chosen methods of control.

This is a bizarre non-sequitur. Red Hat Satellite comes way later than the root causes of any of this, and even if it was a relevant solution, it would be totally untenable for Pop!_OS to say to users:

 

Quote

Welcome! To make sure your Pop!_OS experience is stable, we have ensured that we have remote access to your computer at all times, and can control what software is installed and when.

It would defeat the point of migrating to Linux for a ton of people who are considering it, and it would be absolute suicide for the distro, not to mention the totally untenable support expense for System76, which is a company of < 50 people.

 

1 hour ago, leadeater said:

Blame shifting makes no difference, Pop!_OS [bears] this responsibility.

Sure. And they've acted on that responsibility in a few ways. But none of the measures they've taken can really ensure that ‘installing X requires removing Y’ is impossible.

There are distros where that kind of issue is genuinely, categorically impossible. But none of the distros anyone in this thread has mentioned as alternatives to Pop!_OS (and probably none of the distros any Linux user dunking on Pop!_OS in this thread is running) have that property. Which is why ‘Pop!_OS is especially bad and other normie distros are better’ is an ill-informed conclusion.

[Gork]

lol 14 pages....and still  going... c'm on you can do better!  we need to yeet this up to 100 pages of rants and raves!

[gaesgesa]

2 hours ago, leadeater said:

 Now of course similar crap happens in Windows too with Windows Updates

Yet people conveniently forget that fact when they're talking about Linux.

Yes, even Linus himself.

[Gimmick21]

6 hours ago, Arika S said:

Doubt it, we've already seen that only after 1 part, the Linux community has and is already blaming all the problems on Linus.

Just to differentiate: Not everyone in "THE Linux community" is salty and not everyone blaming Linus is automatically part of "THE Linux community".

The reaction I would expect from everyone in such a situation is: "F...I should not have done that".

Best thing so far: The video teached a lot people what "Yes, Do as I say" means, the "average newcomer" is already better than before

6 hours ago, Arika S said:

I would blame Microsoft if the same thing happen with an app on the microsoft store, i would blame apple for the same thing on the app store (iOS or MacOS), i would blame google for the same thing on the play store.

And because they don't want to take responsibility for all programs, those programs have no access to the file system. And because they don't have access to the file system, there are discussions about "does the user still own his 'own' PC/iPhone/blub?"  

 

Do you blame Steam if a game on Steam breaks something?

24 minutes ago, leadeater said:

Everything above is literally why Red Hat Server and Red Hat Satellite exists and locally controlled repos with defined processes in updating them through predev, dev, test, prod environments etc, or equivalent for other distributions and chosen methods of control.

Yep, but when it comes to IT: people want the shiny new stuff and not the supervised workstation environment

Do I take risks on my PC at home? Yep! Overclocking, newest updates, editing config files... what could go wrong?

 

From my perspective: A PC is still a PC. it's an unmanageable complex thing and you should be able to do with it what ever you want. If no Linux distro fits 'the average joe' that's a totally fine result. But that doesn't mean Linux is bad and has to change. Maybe the average joe has to change

[Gork]

lol all you people with your fancy linux's! let me tell you about suck...when it don't work: the fucking BSD kernal: sit down because uncle gork is up with a mild dayquil buzz and fixing to get to back to bed in just a sec:

It goes kind of like this. waaaaaaaaaaaaaaay back in the stone age. around the time when actual internet was coming to to be a thing. I worked for a now dead, dead, dead, and...infamous company. Nothing special. just the skunk works of Sun Microsystems where they had a place called Sunquinton. It looked and was built like a gd prison. I don't know who's idiot idea that was. but at any rate. Work handed me a laptop with stupidly exotic parts in it. Because ooh sure we'll fix the world with a unified hardware, but first make sure the OS works. 

Well CHRP failed, miserably. But I was stuck with this laptop with janky mix of intell processor and god only knows what kind of audio card and...woe woe waaaait yes their is a point. sort of.  It had these things called a PCMIA slot. which I think was a computers maker way of saying: we're to dumb to make a ethernet and modem card on board. Pure hilarity? it used to be able run ("run") Windows 96 IIRC. to this day I don't know why that failed to keep working. so for bonus levels of pain: get crate of netscape navigator disks (3.5 inch kinds) crate you say? half the fucking time the GD things wouldn't work.

Now go try to over a litteral mountain of disks re-install 1. disk. at. a .time. windows (I had a report do in 5 days) sufficed to say windows failed, slackware was a fucking nightmare, SusE worked(ish) sort of..well I meen I would start... just chunked to one side in some comically small font size. oh right I forgot! the "fun" of xorgconfig, find the fucking asci code for your keyboard, then try to work through a fucking awful ncurses screen. Oh that was "fun" . do aaaaaal that gd stuff get login terminal. start x --now. fingers crossed. and ...FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU....kbddemon has caused a sys core dump 

sufficed to say somehow...that finding out about FreeBSD,  having it work. then finding out I had to compile over god knows how long the entire god dam os to include ALSA audio and some strange version of a linksys kernal mod.

 

now that  was painful.  I was so glad the thing didn't crash and burn because I was on the testing branch which was the one that would work with my alien level of exotic hardware. 

 

[Gork]

what is frustrating is that years, decades, after xserver  and xorg got upgraded to just X and 9 petillion DE's? the UX is still so...patchworked..

[Gork]

17 minutes ago, gaesgesa said:

Yet people conveniently forget that fact when they're talking about Linux.

Yes, even Linus himself.

LOL Linus has..issues. So does Linus...no reely he keeps publishing Linux Monthly online and called Nvidia a bunch of loud c**** .  why he mains fedora I dodn't know lol.

[gaesgesa]

3 minutes ago, Gork said:

LOL Linus has..issues. So does Linus...no reely he keeps publishing Linux Monthly online and called Nvidia a bunch of loud c**** .  why he mains fedora I dodn't know lol.

If the memes are true then he mains fedora because he couldn't figure out how to install debian, the superior distro 

[Gork]

Just now, gaesgesa said:

If the memes are true then he mains fedora because he couldn't figure out how to install debian, the superior distro 

and he also had a meltdown about SVN didn't he? something about  because he coudn't get kernel and harware modprobe patches to have different well managed branches... LOL and I could hug you about now! yes yes yes yes. I used Fedora....twice both times were just a massive migrane. lol like why would you do this to yourself? I guess not as bad as PSCLOS.

LOL I wonder how long it'll take for Linus to have a meltdown about stystemd vs init. or LILO vs GRUB.

 

 

well now that I've asked. that might be part 6: Linus goes to the loony bin. Why because do dorks suggested he ask about systemd vs init and lilo vs grub and vi vs vim vs emac no contest pico or nano FTW  Now I do like both bash and zsh. commond completion and history? yes please!  but...sh and bash for going old school.

[LAwLz]

By the way, for everyone going "the Linux community is so toxic", the Windows community is not exactly showing how friendly and loving it is in this thread either. 

The Pop_OS! Dev has put his Twitter on private so that he stops getting harassed by LTT viewers. 

[Arika]

1 hour ago, Gimmick21 said:

Do you blame Steam if a game on Steam breaks something?

If it breaks my OS, absolutely I would. The distributor is responsible for what the programs on their store do to their customer's systems. If the game just breaks itself and is unplayable, no, that's on the dev.

 

49 minutes ago, LAwLz said:

The Pop_OS! Dev has put his Twitter on private so that he stops getting harassed by LTT viewers.

Wtf is wrong with people............ raise your concerns publicly with generality if you have an issue, don't go after the devs. 

[Gimmick21]

2 minutes ago, Arika S said:

If it breaks my OS, absolutely I would. The distributor is responsible for what the programs on their store do to their customer's systems. If the game just breaks itself and is unplayable, no, that's on the dev.

One step furthor: You buy that game as physical copy on Amazon or in a 'real' store. Do you think the store is responsible in such a case, too?

I don't think the question about who is responsible for what is easy to answer. (store sells faulty product -> who is to blame? Store and/or manufacturer? Is a store able to guarantee that all products [food, pastic toys, software, ...] are free from defects? I guess not. )

 

This leads to a simple consequence: It's not possible to guarantee nothing will happen + user is not self-responsible = reduce freedom. If someone wants to increase his freedom he has to increase the self-responsibility

Or in software terminology: Use flatpack/MS store/... as often as possible. And DRM cheats the system

[Arika]

1 minute ago, Gimmick21 said:

One step furthor: You buy that game as physical copy on Amazon or in a 'real' store. Do you think the store is responsible in such a case, too?

Is a store able to guarantee that all products [food, pastic toys, software, ...] are free from defects? I guess not. )

Yes a store is responsible for what they sell. Simple as that. That's why consumer guarantees exist

 

https://www.accc.gov.au/consumers/consumer-rights-guarantees/consumer-guarantees

Quote

What products and services are guaranteed?

Businesses must guarantee products and services they sell, hire or lease for:

• under $100,000
• over $100,000 that are normally bought for personal or household use.

Quote

Consumer guarantees on products and services

Since 1 January 2011, the following consumer guarantees on products and services apply.

Products must be of acceptable quality, that is:

• safe, lasting, with no faults
• look acceptable
• do all the things someone would normally expect them to do.

Acceptable quality takes into account what would normally be expected for the type of product and cost.

6 minutes ago, Gimmick21 said:

This leads to a simple consequence: It's not possible to guarantee nothing will happen + user is not self-responsible = reduce freedom. If someone wants to increase his freedom he has to increase the self-responsibility

 

Maybe you missed the part where i said the blame is put on both linus for not understanding the error and the distro/debian for allowing such a broken package to be included in the official repository.

[Gimmick21]

10 minutes ago, Arika S said:

Yes a store is responsible for what they sell. Simple as that. That's why consumer guarantees exist

 

Maybe you missed the part where i said the blame is put on both linus for not understanding the error and the distro/debian for allowing such a broken package to be included in the official repository.

Nope, didn't miss it. It was just a thought about what's possible or not and what the consequences are.

 

In germany we have a consumer guarantee, too, but:

Nevertheless, the law provides for the seller to be liable to pay compensation if the seller (at least partly) caused the damage to the buyer, for example if he knew or could have recognized the defect in the product.

 

So if your app store contains like 5 programs -> you are doomed, if it contains multiple thousend you are ok