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.
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.
It seems that 3da4340b7c3367b082cfa2971d2557561484ef1c is the particular commit.
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.
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.
"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.
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.
BSD? Minix?
That is pretty much exactly the opposite of what he said.
VMware isn't great at 3d graphics, although it beats VirtualBox in my experience. I also believe it's still possible to install more than one operating system on a computer. You could save quite a bit of space that way.
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.'"
VMware isn't great at 3d graphics,
I think the latest major release is pretty great, it completely solved a lot of the long-running graphics system bugs that were affecting whether things actually drew correctly, notably in the area of lighting effects. It still makes complex programs which already are not very good at graphics crash more, like say Simcity 4, but all in all it's quite good and even fairly complex games seem reliable when they are not already clearly massively buggy.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
> "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.
No. It's much easier to just start up Steam.
Ditto for dusting off something like Sim City 3000, Kohan, or CivCTP.
A Pirate and a Puritan look the same on a balance sheet.
Systemd folks take note.
Don't break my user space with your selfish ideals of progress.
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.
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.
I do a fairly limited amount of gaming but if I do any I'll do it on my the Linux desktop I built myself.
I have no interest in buying a copy of Windows just for gaming so install on a VM, it's not even a question of principal, I just can't be bothered to go through that much effort for a crappy solution.
I stole this Sig
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
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.'"
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.
Gosh, who woulda thought that Debian Unstable is not stable.
If you don't want to go stable, I suggest you use Debian Testing, which, according to the bug report comments, was not affected.
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
Spoken like a true anonymous coward. I certainly wouldn't want to sign my id alongside that sentiment and mistruth.