A Linux Evening • Hacker News Board

Re: A Linux Evening

#201

Post by mmastrac » Fri, Dec 16, 2022, 6:21 PM UTC

cryptonector wrote: post #200

> > Out of curiosity, how did you come up with this solution? > The author, dkozel, never came back to answer. I imagine they typed the solution on a 40% keyboard featuring unmarked keys and then rolled into the sunset on a Segway for which they had compiled the kernel themselves. Completely oblivious of their awesomeness and of how many people would later find solace in their prose. Here's how I would have started t…

Does this just mean that they added 51 additional bus numbers?

I am curious if the kernel could just bump this number up, especially if Thunderbolt is getting more popular.

Re: A Linux Evening

#202

Post by channel_t » Fri, Dec 16, 2022, 6:27 PM UTC

bombcar wrote: post #149

markus_zhang wrote: post #68

Earlier quoted context omitted.

I think unless one uses Linux on daily basis it's really difficult to sink in the knowledge. I decided to install an Archlinux VM and see what happens. I'm kinda disappointed to myself as I found out I didn't like too much trouble so I'll probably never be a good/great programmer.

Installing Arch is much closer to system administration than programming - they may be related somewhat and attractive to similar people; but you can be a quite successful programmer and barely be able to install Ubuntu. I know people who have written kernel-level Linux drivers who have difficulty upgrading macOS. They're separate skillsets.

I was going to say, I know a lot of programmers, maybe even most, who avoid Linux like the plague because they don't want to waste cognitive cycles on fixing their broken machines. I have found myself in this same place after a solid 12 years or so of Linux use for pretty much everything, home, work, etc. I honestly kinda want to get back into it, but there are other priorities. As long as I have access to some kind of unix-y command line from somewhere I'm good.

Re: A Linux Evening

#203

Post by 1970-01-01 » Fri, Dec 16, 2022, 6:28 PM UTC

bryanlarsen wrote: post #64

This is prototypical of the standard Linux experience, but I'd like to remark on just how much less common this sort of thing is. Modern Linux and modern Linux distributions have a much larger "just work" factor and it's getting better every year in my experience. Slowly and asymptotically, but it is improvement. This was driven home recently by my experience switching to NixOS. NixOS is brilliant in many ways, but b…

I too am 100% burnt from a quarter of a century of random "Linux evenings". I've concluded that GNU Linux will always be a great CLI server OS, however those past 25 years has soured me into calling the Linux Desktop a toy. I'm 100% done investing my time solving issues just like this one. The biggest lesson I've learned is to simply not trust it to be a daily driver.

Re: A Linux Evening

#204

Post by elsjaako » Fri, Dec 16, 2022, 6:31 PM UTC

jodrellblank wrote: post #191

arghwhat wrote: post #185

Earlier quoted context omitted.

While tongue in cheek, the answer is accurate: open source does not mean "free service contract", it means that you can take the code and modify yourself (and preferably upstream the fix). Patches come both from vendors and users experiencing an issue. Vendors take care of most things, but for esoteric problems you might only have a handful of people experiencing it. The vendor is unlikely to care, so if you do not w…

You're doing the same thing, dragging the original conversation off into berating the commentor for not fixing it themselves because you owe them nothing and they shouldn't be so entitled. > " Still better than the competition, where such problems will never be fixed unless it generates sufficient bad PR... " The competition comes under "pay someone else to do it".

What OS are you using where you can get the vendor to implement kernel features to fix obscure driver issues?

I'm sure there's an amount of money you can throw at Microsoft to get something done. I don't know how much it is, but I'm guessing it's more than it would cost to find a vendor to do it for Linux.

The serious answer to " What is the point in having all of the drivers be open sourced and mainlined if we're not willing to fix them to support this?" is "There are many points to this, but one of them is that it's possible to fix them to support it, if someone wants to put in the effort. It's worth something that it's theoretically possible if you really need it, even if no one else has done it yet.".

The answer "You can do it yourself" is meant to help them understand "Anyone can do it, someone needs to step up to the plate. But it's also true that it costs resources. If you're wondering why no one else has done it yet, it's the same reason you haven't done it yet".

Re: A Linux Evening

#205

Post by nektro » Fri, Dec 16, 2022, 6:31 PM UTC

nicoco wrote: post #33

> I spent several hours fixing a problem and I learned next to nothing in the process. This is probably true for this specific case here, but my experience with fixing stuff in Linux is actually the opposite. I learnt a lot doing so, and learnt stuff that turned out to be later useful in very unexpected spots. Back when I was a teen and using Windows, I've spent countless hours fiddling in stuff in regedit and other…

and this article will now be much more higher in Google results for the next person searching :)

Re: A Linux Evening

#206

Post by LAC-Tech » Fri, Dec 16, 2022, 6:34 PM UTC

I had a couple of years stint with windows, and I had a couple of these "evenings" as well. Maybe Mac OS is immune, but windows never was and isn't now.

Re: A Linux Evening

#207

Post by l1k » Fri, Dec 16, 2022, 6:34 PM UTC

nneonneo wrote: post #54

l1k wrote: post #15

Thunderbolt devices appear in the OS as a PCIe switch, so you need two additional bus numbers (one for the Switch Upstream Port and one for the Switch Downstream Port). If the device is hotplugged to a port which has run out of bus numbers, you'll get this error message. Mika Westerberg is constantly fine-tuning the allocation of PCI resources in the Linux kernel to avoid such scenarios. Some recent patches: https://…

It sounds like the pause/unpause might be the way to fix this properly, since trying to be heuristically smarter sounds like a recipe for never-ending corner case bugs like the OP’s issue. The patch for pausing and unpausing seems quite reasonable, except that it does require driver support (unsurprising - you’re literally reallocating the resources used by the driver!). I suppose if you had at least a few movable de…

The PCI resource allocation code is fairly intricate and everyone is scared that changing it may cause regressions. Sergei's patch set is quite intrusive and it would be necessary to somehow break it up into smaller pieces that are slowly fed into mainline over several release cycles, always watching out for regression reports. So, the problem is known, but the engineers working on PCI code in the kernel are given higher priority stuff to work on by their employers, hence the issue hasn't gotten the attention it deserves.

Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.

Re: A Linux Evening

#208

Post by mechanical_bear » Fri, Dec 16, 2022, 6:43 PM UTC

kingboss wrote: post #129

quijoteuniv wrote: post #53

Earlier quoted context omitted.

1 - I wonder what OS do you use. 2 - Have you actually tried Linux?

I have. It's still inferior to Windows and it's trying to be a discount version of MacOS. And it's doing a bad job at it.

Inferior how?

My KDE Plasma setup is nothing like MacOS.

Re: A Linux Evening

#209

Post by kyrofa » Fri, Dec 16, 2022, 6:43 PM UTC

> I spent several hours fixing a problem and I learned next to nothing in the process.

This seems like the wrong attitude to me. It's the perfect opportunity to dig into what those kernel params do! Understand _why_ that fixed the problem.

Re: A Linux Evening

#210

Post by bradwood » Fri, Dec 16, 2022, 6:45 PM UTC

ronjouch wrote: post #174

freeplay wrote: post #147

Earlier quoted context omitted.

Out of curiosity, what distro do you use and what is your distro of choice for the old ladies?

Not OP, but chiming in nevertheless, as I do also "set up Linux for computer-illiterate old ladies" . They all roll Debian stable with unattended_upgrades and it's an absolute joy of stability. Not that I would use Debian stable for my personal machines: I want the latest shiniest and I want to be close to upstream to report bugs when they're fresh and easy to fix by the maintainer (yes, "I use arch btw" indeed), but…

what about Fedora workstation for the old-lady use case? I'm about to give my 12 year old non-technical daughter a linux laptop, and wondering on distro. I'm thinking Fedora but open to be convinced otherwise?