A One Line Kernel Patch Appears To Solve The Recent Linux + Steam Networking Regression

[Volta]

birdie

Who are you trying to cheat, pathetic Windows troll? You got a simple question to answer and you failed. Such dumb working at IT. Git bisect is very easy actually, so another birdie post another bullshit.

[wizard69]

Honestly I think Steam is making a big mistake here. Eventually in the computing world you have to break with the past, 64 bit hardware has been a thing now for a decade, it is time to leave 32 bit apps behind.

Hell steam could go all go all the way back to a Commodore Vic 20 for support but nobody would think that that is reasonable.

Valve is currently looking for a new distro around which to focus their Linux desktop gaming efforts. Currently they focus their testing and support around Ubuntu, but it will be dropped in favour of something else.

https://twitter.com/Plagman2/status/1142262103106973698

Quite a lot of options for them to choose from. They should pick something which uses fairly up-to-date kernels.

https://cdn.discordapp.com/attachmen...622_053640.png

[Xaero_Vincent]

Honestly I think Steam is making a big mistake here. Eventually in the computing world you have to break with the past, 64 bit hardware has been a thing now for a decade, it is time to leave 32 bit apps behind.

Hell steam could go all go all the way back to a Commodore Vic 20 for support but nobody would think that that is reasonable.

Maybe people would still like to play some of their pre-2015 era games that still require 32-bit and wont get recompiled because support was dropped?

Because PC is an open-platform, it's perfectly acceptable for people to want to play VIC 20 and C64 games and they do with VICE. Steam has MS-DOS games that use DOSBox. Flatpak is a possible solution but not everyone wants to have multiple copies of the same 32-bit libs for every 32-bit game packaged in it.

[Wojcian]

Wow, looks like there's a cult of people here who hit like on each post which is contradicting what I say. Amazing!

People don't agree with your trolling? Amazing.

Meanwhile I work in IT and we do employ extensive unit tests and other methods to guarantee that our product will work for our customers despite using agile development. We've never had major f ups like the ones which keep on happening in the Linux kernel and which have already led to data loss on several occasions.

Probably because you're working on some easy crap.

"Do you even know what you're talking about?" - and that's pretty much it. I'm glad both of you are trying to look smug while at the same time having absolutely nothing to say. Quite typical (open source) trolls.

You didn't answer my question regarding example of another kernel developed out of tree of operating system. For example, FreeBSD developers know exactly what components versions will be chosen. It leads to less bugs, but also less bugs are being ironed out same time. Distribution developers should be doing such job. They know exactly what kernel and userspace they'll take. You rather won't find such bullshit with RHEL, Oracle and so on. If Ubuntu doesn't care blame it. It's such simple.

Stop BS'ing me. The latest bug in the kernel which led to data loss took two months to be fixed.

The kernel bugzilla contains literally hundreds of open regressions some of which are already several years old.

You must be f-ing out of your mind to believe that regressions are instantly/quickly solved in the kernel.

Some of them indeed do: very high profile ones. Like the one which is being discussed. But that's the exception, not the rule.

Which isn't any different to others. There are sometimes rare cases which are hard to examine and it's hard to find repeatable test case.

Bloody Linux fan attics who have never filed or debugged a single issue in the Linux kernel. Do you even know what git bisect is? Have you ever run it? Can you even imagine how difficult it is to debug the kernel and find the source of regressions in it?

This proves you're loosing your mind. Do you really think you're some kind of miracle and kernel bisect is ability reserved for super humans? I'm testing kernels since rc2 and when there's regression I'm bisecting it. Last time I was hit by some problem with EFI and it led to unbootable system. It was resolved during rc period.

[Wojcian]

I will take a break from these forums for a while because it's cringe-worthy to read all the comments from the people who've decided that Linux is perfect, Ubuntu makes no mistakes, the Linux desktop is good everyone.

What at least few people were saying Ubuntu is far from perfect, so I treat your comment as another example of mental breakdown or some kind of illness. Or perhaps just strawman or astroturfing.

[azdaha]

AFAIK, Arch has testing repos for this very purpose. Additionally, they adhere to upstream code release, which ensures that regressions and bugs are fixed upstream for other distros and projects as well. Consequently, I renew my opinion that Valve should focus on supporting or recommending Arch instead of Ubuntu. FWIW, the relevant github issue does show Arch users involved in reporting this. I am not sure if/when the regression was pushed into stable releases in various distros; however, using testing repos for kernel releases for a specified amount of time would, for the most part, satisfy Valve's criticisms regarding desktop distros, among other things.

[birdie]

People don't agree with your trolling? Amazing.



Probably because you're working on some easy crap.



You didn't answer my question regarding example of another kernel developed out of tree of operating system. For example, FreeBSD developers know exactly what components versions will be chosen. It leads to less bugs, but also less bugs are being ironed out same time. Distribution developers should be doing such job. They know exactly what kernel and userspace they'll take. You rather won't find such bullshit with RHEL, Oracle and so on. If Ubuntu doesn't care blame it. It's such simple.



Which isn't any different to others. There are sometimes rare cases which are hard to examine and repeatable test case.



This proves you're loosing your mind. Do you really think you're some kind of miracle and kernel bisect is ability reserved for super humans? I'm testing kernels since rc2 and when there's regression I'm bisecting it. Last time I was hit by some problem with EFI and it led to unbootable system. It was resolved during rc period.

I've been using Linux exclusively for over 20 years now.

I've helped resolve numerous bugs in the kernel, GCC, wine, Xorg, MC, KDE and other open source projects.

If you believe I'm trolling then go fück off and never reply to my posts again. Really, do me a favour. Thank you.

[Wojcian]

I've been using Linux exclusively for over 20 years now.

I've helped resolve numerous bugs in the kernel, GCC, wine, Xorg, MC, KDE and other open source projects.

If you believe I'm trolling then go fück off and never reply to my posts again. Really, do me a favour. Thank you.

You want me to read your posts again. Ok, I've done so, but there's neither logic nor sense. You're saying you've been using Linux exclusively for over 20 years now and you claim it's hard to do a kernel bisect? Oh, Gods.. Furthermore, you were always giving Windows as example even if it couldn't stand against reality. Strange for someone who's using Linux exclusively for over 20 years. Next to possibility of trolling I mentioned other possibilities as well.