Not All Linux Users Want To Toke On LLVMpipe
Phoronix: Not All Linux Users Want To Toke On LLVMpipe
OpenGL support is becoming an increasing hard requirement on the Linux desktop. Even if your hardware comes up short, more desktops are requiring GL support, which means falling back to the CPU-based LLVMpipe Gallium3D driver...
This is probably the best headline ever to appear on Phoronix.
I have no further comments.
With VMware Workstation 9 and Player 5, 3D doesn't seem to work with guests on Linux hosts using Intel graphics. The usual installation of S2TC libraries or just enabling the reporting of S3TC support doesn't work anymore. VMware tech support tells me to disable 3D support or use Workstation 8. I certainly don't want to use software rendering of 3D effects in my Linux guests, if I can't make use of 3D in my Linux guests.
"Users running old hardware won't get modern features"
Next thing the self-entitled free-loading whiners are going to complain about is that their 1963 Corvettes doesn't have modern electronic conveniences and fuel economy. Or that their old Walkman can't play movies, browse the Internet, or do phone calls. Or that their Crosley Model 158 doesn't pick up digital stations. Or that their old NES can't play Gamecube games. Or that the slab of steak they bought three weeks ago went bad and isn't edible even after "installing" a dose of fresh A-1 sauce. Or how their 18 year old fit and trim figure is irrevocably gone and been replaced with 50 flabby pounds after a decade of sitting all day in front of a computer eating Cheetohs and pounding Mountain Dew while bitching online about the Free OS they downloaded for no cost and never contributed anything meaningful to.
If you have ancient hardware, the ancient software made for that hardware still exists. Use that. It still works. If you want modern software, you're going to need something approaching the hardware it was designed for. That may cost some money. Suck it up and pay it. Or just stop using a computer and go do something else with your time (really, it's okay, you don't need to be on the Internet 24/7 and play the latest games and have the latest tech toys and see all the newest Youtube videos just to survive and have a good life, I promise).
Complaints about ARM support and VMs are still valid. I don't agree that the desktop should be held back, though. Either someone needs to get their ass in gear and fix the problems there, or those use cases should just be honestly cast aside as unsupported. Obviously fixing the problems is the better solution, but if the FOSS community and its theoretical millions of contributors don't care enough to fix it, then there's not much more to say on the topic. The primary use cases of Linux in VMs and on ARM are still supported (servers that don't need graphics and mobile appliances that use specialized graphics stacks), and oddball use cases need to give away to more common use cases when there is a conflict (e.g., modern graphics features for most people vs weird desktop environments for a few people).
I would like to subscribe to your newsletter, elanthis!
He has missed one point in why you do not want LLVM on a server: if you really care about security, you really do not want in-memory code that is changeable and executable unless hard restricted in other ways. Which the current Mesa/swrast-over-LLVM needs without being very restricted. Which is one of the reasons you can hit problems with it on hardened/pax.
That said: you really want to run X as it currently runs as *root* on a server anyway?
It's not even that. It's more like, "Users running old hardware should get off the Gnome/Unity train and switch to a desktop with more accommodating devs (xfce/lxde/kde)."
Originally Posted by elanthis
I didn't quite get it from the article: do modern servers ship with (very) old graphics cards like Matrox?
My understanding is that most servers ship with barely enough of a graphics chipset to get the BIOS to POST, and that's it.
Yes, and the good intel HD GPU is not a part of Xeon E5 nor E7.
Originally Posted by MaxToTheMax