Slashdot Mirror
Linus Fixes Kernel Regression Breaking Witcher 2
jones_supa writes There has been quite a debate around the Linux version of The Witcher 2: Assassins of Kings and the fact that it wasn't really a port. A special kind of wrapper was used to make the Windows version of the game run on Linux systems, similar to Wine. The performance on Linux systems took a hit and users felt betrayed because they thought that they would get a native port. However, after the game stopped launching properly at some point, the reason was actually found to be a Linux regression. Linus quickly took care of the issue on an unofficial Witcher 2 issue tracker on GitHub: "It looks like LDT_empty is buggy on 64-bit kernels. I suspect that the behavior was inconsistent before the tightening change and that it's now broken as a result. I'll write a patch. Serves me right for not digging all the way down the mess of macros." This one goes to the bin "don't break userspace". Linus also reminds of QA: "And maybe this is an excuse for somebody in the x86 maintainer team to try a few games on steam. They *are* likely good tests of odd behavior.."
Real gamers use paper, pencils, and dice.
A developer fixes a bug, and writes a comment on github.
Somebody caused that regression! Lay the blame, git is all about the blame.
Real gamers use swords and steam tunnels.
*REAL* gamers emphasize false purity and always seek to exorcize the Other.
Man in charge of kernel fixes kernel when it breaks.
This isn't news. This is what happens.
And if only MS had a similar "never break userspace" rule that applied to even the most unbelievably "casual" of software too.
Hell, I broke four apps just going to 64-bit Windows 8 from... 32-bit Windows 8.
And, I agree. Steam has 1/3rd of my 800 games working on Linux already. If we're not using those as a test-case, then why not? Sure, some will just be multi-platform ports from the same source but likely a lot of code will literally be new ports added just for Linux.
Sad to say, there are probably more games in my Steam library that work natively on Linux now, then there are Windows games on there that'll work under Wine/Crossover/etc.
This, a thousand times this.
The one reason that people like Steve Jobs, Walt Disney, et al made such lasting impacts on not only their companies but the world as well was not because of some great business acumen but because they fixed the problems directly. Sure, they were assholes but ultimately they cared about their products and how customers reacted to them.
Degree milled MBA's don't understand this and would not have given this fix a second thought because a> they couldn't do it and b> the economics didn't make sense because some team would've had to be picked to go out, ascertain the problem, determine the solution which might be a larger fix than a one line change and now you're looking at potentially tens of thousands of dollars expense to fix a bug in a product that isn't even YOURS! It just don't make no economic sense and you'd get dinged and the next stockholders meeting.
You see this in all the industries. Apple after Steve Jobs. Car manufacturers who were eventually run by "businessmen who understood the auto markets" instead of "a car geek who understood business" the entire industry turned into regurgitated pablum with a few occasional bursts of brilliance by a car geek that broke through the red tape. I worked in the consumer electronics industry and have seen first hand how once highly held and coveted products have been turned into cheap commodities by a "fresh executive team" because it's easier to sell to the masses who don't understand the finer details of a product than it is to actually push the envelope and innovate your product into the next generation. Then, when that market dies out completely because the enthusiasts don't want your product because it sucks so the masses don't want it anymore because "it's not cool", the CEOs blame the market for being fickle.
Actually, WIndows programs do not always run on any version of Windows. In some rare cases, older Windows applications may even run better on Linux with Wine than on a new version of Windows. But it is true that backwards compatibility on Linux with old native applications is far from being great.
Linux is a mess. I am trying to run Debian Wheezy (stable!) on "fully supported" laptop without any binary blob in the kernel or X server and the number of glitches and bugs is staggering: in two days of use I found that closing the lid doesn't put the laptop to sleep every time, sometimes usb drives aren't listed by 'lsblk' and of course there's no drive in the userland (gnome) then, display manager (gdm3) does not always lock the screen ... I'm giving up.
Those small glitches were the very reason I switched from Linux to Windows. Linux is amazingly buggy on desktop these days.
Could you give me examples of such programs?
I recently had an issue where Arcanum will run in wine on my 32bit laptop, but not on my 64bit desktop in wine's 32bit mode. Same OS/version, same version of wine.
"And if only MS had a similar "never break userspace" rule that applied to even the most unbelievably "casual" of software too."
I'm not a Windows guy but this statement is bogus. Microsoft's pain is that they care so much about userspace that they'll make design fundamental decisions around keeping userspace ABIs/APIs. This means that I can often (not always, but often) run an older version of a program fine on a newer version of Windows. On the Linux, we can often rebuild the app from source and many do.
Without ye there d nevar evar bee an Unixy kernel for free.
On any version of windows.... but Linux always needs some voodoo and shit?
Because you never hear about the application specific voodoo that is in windows?
I am Slashdot. Are you Slashdot as well?
See my post RIGHT below yours.
Not true.
I run school networks, and we have legacy software going back to the floppy-disk days.
I impose a 5-year limit after the manufacturer was last active because, after that, sometimes it's too much pissing about to run the program, if that's even possible.
Going to Windows 8 64-bit broke FOUR programs that work absolutely fine on Windows 8 32-bit. And I'm using images configured in exactly the same way and thus in a highly reproducible environment.
Some shit breaks on EVERY Windows update. I condemned 10 pieces of our software when we went from 7 to 8. I condemned even more in a previous XP -> 8 move. Fact is, most people just don't care in schools because 10 year old software is ten-years out of date on the curriculum side. But for sure there is NOTHING as simple as you suggest.
Fuck, when I move OS at a site, my rule is "All your software needs to be handed in, with original disks and proof of licence. Anything you want to work on the new network will have to come from those hand-ins AND be subject to testing". Every year, approximately 80% of the school's software estate disappears into the bin never to be seen again - either nobody cares about it after the salesman left the building, or it just plain doesn't work, or it's no longer any use compared to other resources.
But, fuck, "Windows programs just work anywhere"? No. Not even if you have a lot of funds and time to spend getting just one of them to work. I can assure you.
By comparison, Linux software may break briefly and then get diagnosed and pulled back in. But you can pretty much run a 20 year old copy of the primary shell with no problem, if that's what you want to do. You may have to pull in old version of the libc, etc. but it'll work on the modern kernels. There's not much on Linux that's EVER been broken, certainly nothing that a bit of tweaking won't fix.
And yet I can show you a software graveyard in my office of Windows stuff that breaks EVERY year. Fuck, some of the companies STILL SELL IT even though they know it doesn't work on anything past Vista or 7. They don't give a shit and no longer have the programmer on staff to do anything about it.
On one hand, you hear about him flaming out people who break shit in stupid ways.
On the other, you also hear him accepting blame for not checking things properly himself: "Serves me right for not digging all the way down the mess of macros"
Whatever his eccentricities, he sounds quite fair to me.
Not the original poster, but I do have an example. I develop VR applications using World Viz's Vizard software. My startup time for loading all the libraries, models and textures is about half that running under Wine than it is under Windows on my dual boot laptop. The frame rate is quite a bit higher, too. The one thing I can't do under Wine is run the application in OpenGL stereo mode. So, I do all my development under Linux/Wine, and then the final testing under Windows.
Real gamers make the casino rich. /aliquis
Wouldn't it be easier to run Windows 8 in a virtual machine like VM Ware on a Linux computer? Why go through WINE and possible incompatibility issues? Or buy a gaming laptop for gaming on windows? I'm sure you geeks make $30 an hour and can afford two computers.
That is pretty much exactly the opposite of what he said.
They are big Manowar fans.
Going to Windows 8 64-bit broke FOUR programs that work absolutely fine on Windows 8 32-bit. And I'm using images configured in exactly the same way and thus in a highly reproducible environment.
How do you know that is not because those programs are simply poorly written, and use some Windows API in an invalid way (they may depend on undefined behavior or bugs), or have other problems ? Also, since you only require compatibility for the kernel, did you check if there is really a kernel incompatibility, or if it is something that could be worked around with "tweaking" ?
If you haven't read this yet, do so. Old, but still relevant.
http://www.joelonsoftware.com/articles/APIWar.html
GTA4 refuses to run on Windows 8 and 10 for me, but ran just fine in Wine. No wonder it was on steam for just $2 though...
A lot of games that used DirectX 5 were notoriously difficult to get running properly on newer versions of Windows. Balls of Steel and Interstate '76 come to mind. GoG has modified versions that work pretty good, although I76 is still problematic for many people.
Games that used certain types of copy protections also caused compatibility issues. Any game that had the StarForce wrapper applied and wasn't updated to the 64-bit compatible version was toast as soon as you went 64-bit Windows, since that protection used drivers. Splinter Cell: Chaos Theory is one of these. Thankfully there's a cracked version out there that doesn't have this problem.
But for the most part, Microsoft has been very, very good about backwards compatibility. Linux has been more about technological advancement at the expense of backward compatibility.
I've worked as a school sysadmin as well, doing desktop engineering and working with what you are speaking of. It is ridiculous, that kind of approach to making products with no intent or ability to support things. But other companies released products using modern methods -- 10+ years ago. The blame lies partially on the people selecting the software.
However, I must say I don't have the same animosity towards Windows. I've usually figured out a way to get things to work. Windows Updates have never broken something on a monthly basis. Microsoft has tools to help with things like this.
I will say, switching to x64 was probably the worst move you can make. Since a long time ago, it's been the case that x86 is more supportive of older software. http://support.microsoft.com/kb/896458
Really, I wish Microsoft could pull the trigger and eliminate support for the antiquated things completely. It'd make it easier for me if Microsoft could play the bad guy when I came into the office to explain how operating the software just isn't going to be sustainable. There have been times where I've needed to break that news, but otherwise I try and succeed in getting things to run after a lot of effort. Windows is good about supporting an array of software from several generations.
Those small glitches were the very reason I switched from Linux to Windows. Linux is amazingly buggy on desktop these days.
From the tone of your comment it sounds like you've had some serious frustrations. Do you mind if I ask what flavor of Linux you were running, what the desktop(s) were and what were the issues you were getting? I ask because I've been exclusively using Linux for 18+ years and while I've had my share of issues (NVidia binary blobs caused kernel panics for a period of 3 years when enabling OpenGL on my X sessions. As a result it's been 6 years since I've used NVidia hardware.) I'm curious to find out what drove you to use Windows, and also why Windows instead of say one of the BSDs, or even Mac OS X?
Going to Windows 8 64-bit broke FOUR programs that work absolutely fine on Windows 8 32-bit. And I'm using images configured in exactly the same way and thus in a highly reproducible environment.
How do you know that is not because those programs are simply poorly written, and use some Windows API in an invalid way (they may depend on undefined behavior or bugs), or have other problems ?
The reason the programs don't work is both unimportant and irrelevant. The same thing can happen on a Unixlike OS.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Not the original poster, but I do have an example. I develop VR applications using World Viz's Vizard software. My startup time for loading all the libraries, models and textures is about half that running under Wine than it is under Windows on my dual boot laptop. The frame rate is quite a bit higher, too. The one thing I can't do under Wine is run the application in OpenGL stereo mode. So, I do all my development under Linux/Wine, and then the final testing under Windows.
Wine isn't a faithful reimplementation of Windows behavior, it just gets it done. Lots of methods are not implemented or fake it till they make it.
Wine Is Not an Emulator - When you don't care about fidelity, you can skip a whole bunch of stuff and fudge things. That's why a lot of Direct3D stuff has run slightly better under Wine for quite some time. Sounds like it works great for your test environment.
Now startup time is an ENTIRELY different matter. There isn't any magic to loading things from local disk to memory that will make it perform THAT different between the two OSes. Either you're looking at hot cache vs. cold, or Windows is doing some other IO at the same time, maybe page outs, maybe realtime AV, or maybe we're only talking about a few seconds of startup time.
I work with a bunch of systems, they are not fast or slow, just different, unless we're talking about really specific deficiencies.
Fallout 3 crashes for me on Windows 7 (there is even a warning about it on Steam), but it works without major problems with Wine. It could very well be the fault of the game itself, though, as the engine it uses is not famous for its stability.
> "fully supported" laptop without any binary blob
You lost me right there. You're already on a religious crusade here. Getting it to work is clearly a distant goal for you. So anything else you have to say on the matter is somewhat suspect.
A Pirate and a Puritan look the same on a balance sheet.
The reason for this is that in Linux, Kernel and app development goes somewhat in parallel by maintainers who work with the release candidates, while on Windows every app developer needs to have the initiative to create an update for a new version of Windows and the users have to know to download the updates and install them. In Linux, these updates happen most of the time when the kernel gets updated. It sort of goes Kernel --> Drivers --> Libraries --> Applications.
Systemd folks take note.
Don't break my user space with your selfish ideals of progress.
I've used Debian for years now, but its quality is getting really bad these days. Things have gotten particularly bad since the switch to systemd.
Some of the bugs that Debian suffers from now are unbelievable. There was one bug that broke the WINE launch script, for example. It made it impossible to use WINE to run Windows programs.
When I first heard about that bug, I couldn't believe it. How could a bug like that even get through? It was blatantly obvious. Trying to run a Windows program using WINE would have shown it was broken! Didn't the package maintainer try that most basic of tests while preparing the new version?
I don't expect perfection from Debian, but I do expect a minimal level of quality, and that particular bug is just plain inexcusable.
The saddest part of all of this is that Debian is actually one of the better distros out there! The others are often more seriously broken in many other ways.
I applaud Linus for caring so highly about quality, but it does not do much good to have a robust kernel if the distros are broken in idiotic ways.
Do you mind if I ask what flavor of Linux you were running, what the desktop(s) were and what were the issues you were getting?
That is usually followed by "ah yes, that particular distro is known to be broken, no wonder you were having problems". :)
There have been various issues like the GP comment described, but I won't write a long rant about them. Right now, if I sent a letter to Santa Claus and wanted to have just one issue solved, it would be the problem where the laptop brightness goes in multiple steps under Debian-based distros such as Mint and Ubuntu. Apparently this is because there can be multiple listeners to the backlight event (GPU driver, ACPI driver, OS, BIOS...) and they all do the adjustment without consuming the event. Anyone can observe this problem on a laptop. This is so basic stuff that it cannot be consistently broken like this.
Fix the brightness adjustment. Doooo it. No, I won't do the engineering work to fix it. I have other problems to solve than personally fixing my OS bugs. Windows works fine.
It means my hardware, e.g. Atheros wireless, Intel graphics is supported by fully open source drivers included in Debian default 'free' kernel and Xserver. I don't have to load any 'non-free' drivers and still have too many problems.
The same thing can happen on a $ANY_OS_2.
Yes, it *CAN* happen. Ergo, $ANY_OS_2 is just as good as backwards compatibility as $ANY_OS_1. Possibility != Reality. It's quite amazing the shit Linux cheerleaders spew while thinking they're actually saying something meaningful.
The fact is Windows is so far ahead in terms of backwards compatibility that at this point that its not even funny. Not to mention the insane scale of testing against countless buggy apps before every release, patch, fix, update makes you laugh at the "I checked in 10 lines of code into git therefore the patch works everywhere" mentality that open source people have. Lols.. open source wins because the patch is out ! Yay !
Distributing software on Linux basically means building it on EVERY SINGLE FLAVOR and dumping it on some repository using EVERY SINGLE FLAVOR of package management. Static linking? hahaha a cruel, cruel joke.
On Windows, it is __TRIVIAL__ to make it so that you unzip an exe built in 2015 to a folder and run it on pretty much every single x86-based windows flavor since Windows 95.
Real gamers know the odds and work for the casino.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
real gamers own the casino. and other large multinational corporations.
Sleep your way to a whiter smile...date a dentist!
The fix and half the quotes attributed to Linus were from me. Apparently people can't figure out who posted which GitHub comment.
This has been a perpetual problem on my Lenovo W510. In one release, it did multiple steps, in the next one, no backlight control at all. I add some kernel command line options and get a crappy 4 step backlight. In the next release, I have to remove those options because my backlight didn't turn on at all with them. Now no working backlight controls (using the FN+Home/End combo on my laptop keyboard). I poke in the /sys sysfs mount at the backlight control that's registered, and can control the backlight that way. I've been following the ACPI development mailing list and this is a perpetual topic of confrontation.
There are lots of proposed fixes that would just resolve it, but they can't be accepted because they break userspace. The whole problem stems from the Laptop bios. In some cases, the bios will advertise ACPI methods to control the backlight, while the GPU driver exposes the controls as well. Depending on the particular bios version (and sometimes even bios settings), the keypress might, in bios, change the brightness, then report the keypress, or it might report the keypress and depend on the OS to use the ACPI interface to control the backlight, or it might depend on the OS to use the GPU driver interface to control the backlight. On some of the systems, the ACPI interface is sometimes broken, and on some, there are multiple controls (for display port and all the other possible display connections built into the system) with no clear way to determine which one to actually use. Some bioses report to work with 'Windows 2012' but actually completely don't. Some ONLY work with that, but report they work with older ones.
From what I recall of the discussion, Windows 8 deals with this by punting the actual event handling to the GPU drivers, expecting them to know how to handle the hardware.
Similar bugs can be seen in Windows if your run a newer version on hardware designed for a previous version (I saw this running Windows 7 on hardware designed for Windows XP, an old Dell laptop).
I find it kinda crazy that every single other feature of my laptop works perfectly (FIngerprint reader, color calibration, wimax radio {none of which I actually ever use}) while backlight which seems so simple (Press button, change brightness) is in a perpetual state of brokenness.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
lol.. usual slashdot nonsense from linux cheerleaders - ignore the problem and blame the user.
Go take a look on some linux user forums buddy. Are they empty? Countless threads from people wasting hours of their personal time trying to run linux and finding that its buggy as hell.
atleast with windows you can return the laptop and get your money back and then go buy a macbook pro or microsoft signature laptop or something else thats well tested to work with the hardware.
Actually, with VERY few exceptions, you can run very old userspaces with new kernels. There have been a few 'fixes' that broke old userspaces (by exposing bugs in userspace that weren't triggered pre-fix), but there's a very strict, never break userspace rule. Sometimes you have to set the correct kernel build time options, but it's expected of a person doing that to know what they're doing, or to trust their distro to know what they're doing.
Look at the recent Linux Wireless mailing list... A few weeks ago, the ability to use 'Wireless Extension Compatability' to control wireless was made unselectable. They have been marked deprecated for YEARS(2008), and are now causing problems with supporting newer wifi features. This was very firmly 'NACKED' by Linus, and the wireless tree has to continue supporting an old, broken, way to control wireless devices.
There are also options you can configure in the kernel like 'COMPAT_VDSO' which work around 1 released version of GLIBC (2.3.3), which was also backported to OpenSuse 9.
I know that it may not have been until the 2.6 era that this became truly 'written in stone' law, but it's always been a pretty firm 'rule'. Hence I can still run a.out binaries on my 64bit system. 'ELF' binaries were added around 2.0 (15-20 years ago?), and have been the default since some time between then and now. Still, a.out support will always live on, because you don't break the kernel to userspace abi.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
The fact is Windows is so far ahead in terms of backwards compatibility that at this point that its not even funny.
It's clear that you haven't actually tried this little experiment.
Even if it were true, here's something you apparently haven't caught on to: I can completely legally and trivially install the old Linux in a virtual machine under the new Linux, and run as many copies of it as I want. I can't do that with Windows. Oh sure, I run an XP VM under Windows 7 anyway, but I wouldn't want to count on it in a business context.
On Windows, it is __TRIVIAL__ to make it so that you unzip an exe built in 2015 to a folder and run it on pretty much every single x86-based windows flavor since Windows 95.
On Linux, it is trivial to make it so that you run a shar file and run it on any Linux anyone is actually running today. The upgrades are free (or part of your contract, I suppose, in the case of RHEL) so people upgrade, and you don't have to support Windows 95. Meanwhile, lots of software which runs fine on Windows XP won't run on Windows 7, and some of it won't even run in "XP Mode" because Virtual PC is virtually worthless. Most of it runs fine in vmware, though. Sadly, Microsoft isn't actually capable of making VM hosting software which will properly host Windows on windows, let alone arbitrary operating systems, nor buying one.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I can completely legally and trivially install the old Linux in a virtual machine under the new Linux, and run as many copies of it as I want.
I'll try to keep the sentences short. Free software is free. Commercial software is commercial. Got it?
Besides, telling people to randomly spin up VMs to run software? Dude which planet are you on? Trust me, the only VM gradma knows about is voice mail - and she aint gettin any closer to figuring that out either.
On Linux, it is trivial to make it so that you run a shar file a
Now you're just grasping at straws. shar? Seriously? WOW. OK here's an "Application" that runs all the way from DOS 1.0 to Windows 10. It only takes up one line.
echo Hello, World
--------
The upgrades are free
Oh.. I do like free, Is the hardware also free?
Its quite sad really. The open source people have never managed to make anything good that wasn't a clone of some existing successful proprietary software. It started with the kernel which cloned unix, or should I say poorly tried to clone it. I'm sure Microsoft won't mind giving them lessons in how to create a stable binary layer that works for decades.
Give it up, he's been posting similar things since Win98SE was the "gold standard". You'll just get an empty content free evasion decorated with occasional bits and pieces of fluff he's heard of second hand over the last decade and a half.
So would it be fair to say then that this a hardware vendor issue at least in the case of the Lenovo laptop, as it seems that the Microsoft solution is to let just the GPU driver deal with the issue? It seems kind of strange to me though why would the GPU driver have the capability of dealing with the keyboard backlighting feature? Why would the graphics subsystem care about the keyboard? That seems kind of bizarre to me.
I missed the key point of it being keyboard backlight, lol....
Yes, it is very safe to assume that it's the bios vendor (Lenovo in my case, acer, hp, dell, you name it in the other cases). It boils down to there not being a consistent way to control backlights across laptops.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable