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.."
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.
Unless Apple, Microsoft and Sony employees, who regularly break applications due to OS or kernel bugs, then the company pretends it doesn't happen, and if you're really lucky, it'll be secretly patched six months later.
The reality is Torvalds is the most famous active developer on the planet. Don't like it? You're welcome to fuck off elsewhere.
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.