The mobile market will change this. There is no DirectX on Android or iOS, and both are a massive gaming market right now, and where all the interesting stuff is happening. They're also markets where a single programmer without a multi million dollar budget can make something relatively simple and make some money. Learning OpenGL ES there will give familiarity for programming OpenGL on the desktop.
Conversely, there is no DirectX on Linux, OS X, iOS, Playstation3, Wii, PSP, PS Vita, Android, etc. ALL of those platforms, plus Windows have OpenGL available.
Intel may well make it. The HD3000 performance is not terrible. Sure, it will never win any high end high detail benchmarks at ultra high resolution, but it is capable of playing pretty much any game out there in low detail at the moment. HD4000 and its successors may be the tipping point where it is "good enough" for most.
Hell, if they can make HDx000 work out of the box (and stay working through kernel upgrades, etc) with full 3d support on most distributions that would be a huge start.
I suspect x86/x64 only. I would wager that the number of ARM desktop linux users would be below 1% of the linux market, and that is the extreme fringe of an already fringe market.
It depends. If your card is brand new, good luck. If you upgrade to a new kernel before the driver/sub has been updated, good luck (Linux has no driver ABI). But if you have a supported card and get the drivers working, performance isn't bad, and in most cases is comparable to Windows.
The problem is that we have too many distributions that attempt to package everything on the internet.
Pick a set of core packages, keep them up to date, anything else can be installed from source / pre-compiled binary under/usr/local.
However, doing that would require some sort of direction and choice to be made by someone and the community appears to be averse to that - much spin is given to the fact that you're free to customize everything in an unlimited way.
This is great, but it means there's no real base platform guaranteed to be in place and is guaranteed to not break when package foo is installed. Trying to audit and fix dependencies on 10,000 packages or more is a big problem, and I'm sure most users only have a very tiny subset of those packages installed on all of their machines.
Maybe statically link any "add on" applications to eliminate dependency hell? Disk (and memory) is extremely cheap now.
Given that games are being ported to the mac now (library is still small, but) - which is using OpenGL, OpenAL and OpenCL, then porting to linux if a mac port is already done should be relatively trivial - all those libraries are cross platform.
Don't expect DirectX ports any time soon though, the mac doesn't appear to get them either. But, its a start. Also, the beauty about Steam is that if the game is available on Linux as well as Windows, you can deinstall Windows, install Linux and not have to re-purchase. This works on the Mac at least.
The "barrier to entry" of having to re-purchase all of your software is lessened somewhat.
Exactly. Until the linux crowd stop reinventing the wheel, commit to an API/ABI standard and actually support an upgrade path, this shit will continue to happen.
I even had one kernel upgrade swap the order of NIC detection around on a firewall, so that eth0 (inside) became eth1 (outside) and vice versa due to the internal hardware detection order changing. Nice one. Thus, after that I moved all my NIC drivers out to modules to force them to load in a particular order - but no doubt eventually even that would get broken due to soem genius deciding to scan the PCI bus in a different order or something and 2 NICs of the same chipset would get swapped.
And yes, until they get a stable driver ABI, expecting hardware OEMs to bother trying to keep up support for such a niche platform is a joke. It works both ways kids - don't expect people to write drivers for your OS if you can't provide a stable standard interface.
As someone who was running debian in production on internet facing servers between 1999 and 2005, I'm telling you it isn't always that straightforward.
Could be done just as easily without microsoft's involvement, and without Windows being involved. Government pays/bribes/extorts major CA to give them the private key used by X secure service. Service is then subverted. Whether it is for code signing, HTTPs, etc.
Some people seem to think that PKI is a silver bullet. It's not. However just because it can't protect against 100% of edge cases, doesn't mean that it is worthless. Any slashdotter worth their salt should know that security is built in layers. PKI is just a single layer.
More importantly... compare it to a Linux install from 12 years ago, that you then attempt to upgrade to current security patch level without breaking it without a reinstall.
Because someone having to steal a certificate first, and then get malware to spread significantly before the certificate is revoked is so much less secure than not signing your code at all?
Oh please. Next you'll be saying we shouldn't bother to lock our doors because someone can just throw a brick through the window too, yes?
Because the alterantive is "insecure by default". Which microsoft have taken huge flak for in the past. If you want to run Linux or other, you have 2 options: run linux that is code-signed, or turn code signing off and run it like you would today. This is a NON-ISSUE that will drastically improve security for operating systems which support it.
Use the correct tool for the job. End user devices, apple is good. Servers, use something else. Desktop OS and server OS do not have to be (and in the past never were) the same.
Windows client to Windows server is a relatively recent abberation. desktop and server OS have totally different and conflicting requirements.
Solution: Don't run OS X servers. Apple don't make real servers. Apple don't even use their own servers in-house. Server and desktop do not have to be the same platform. Buy commodity server hardware, run vSphere on it, and present shares, etc to your mac clients using FreeBSD/Linux/etc...
Nah. We run commvault, and have physical media servers (to run our tape libraries) and the management console/database is a VM. Everything is backed up to tape. If you have enterprise+ licensing with VMware you can actually use site recovery manager to keep a set of VMs in sync between two sites - if the primary site goes down you flick to DR site, bring up your backup control VM, bring up your other mission critical VMs and restore the rest from tape.
I haven't used OCZ hardware, but their rep is from cheap consumer grade desktop stuff. Besides, in the enterprise you won't be running cards without some level of RAID style fault tolerance in any case.
Slashdot Mirror
I saw an article somewhere recently, interview with Gabe, they had screenshots of Steam running on Linux.
The mobile market will change this. There is no DirectX on Android or iOS, and both are a massive gaming market right now, and where all the interesting stuff is happening. They're also markets where a single programmer without a multi million dollar budget can make something relatively simple and make some money. Learning OpenGL ES there will give familiarity for programming OpenGL on the desktop.
Conversely, there is no DirectX on Linux, OS X, iOS, Playstation3, Wii, PSP, PS Vita, Android, etc. ALL of those platforms, plus Windows have OpenGL available.
Intel may well make it. The HD3000 performance is not terrible. Sure, it will never win any high end high detail benchmarks at ultra high resolution, but it is capable of playing pretty much any game out there in low detail at the moment. HD4000 and its successors may be the tipping point where it is "good enough" for most.
Hell, if they can make HDx000 work out of the box (and stay working through kernel upgrades, etc) with full 3d support on most distributions that would be a huge start.
It will probably run faster under the linux emulation, as usual :D
I suspect x86/x64 only. I would wager that the number of ARM desktop linux users would be below 1% of the linux market, and that is the extreme fringe of an already fringe market.
It depends. If your card is brand new, good luck. If you upgrade to a new kernel before the driver/sub has been updated, good luck (Linux has no driver ABI). But if you have a supported card and get the drivers working, performance isn't bad, and in most cases is comparable to Windows.
The problem is that we have too many distributions that attempt to package everything on the internet.
Pick a set of core packages, keep them up to date, anything else can be installed from source / pre-compiled binary under /usr/local.
However, doing that would require some sort of direction and choice to be made by someone and the community appears to be averse to that - much spin is given to the fact that you're free to customize everything in an unlimited way.
This is great, but it means there's no real base platform guaranteed to be in place and is guaranteed to not break when package foo is installed. Trying to audit and fix dependencies on 10,000 packages or more is a big problem, and I'm sure most users only have a very tiny subset of those packages installed on all of their machines.
Maybe statically link any "add on" applications to eliminate dependency hell? Disk (and memory) is extremely cheap now.
Given that games are being ported to the mac now (library is still small, but) - which is using OpenGL, OpenAL and OpenCL, then porting to linux if a mac port is already done should be relatively trivial - all those libraries are cross platform.
Don't expect DirectX ports any time soon though, the mac doesn't appear to get them either. But, its a start. Also, the beauty about Steam is that if the game is available on Linux as well as Windows, you can deinstall Windows, install Linux and not have to re-purchase. This works on the Mac at least.
The "barrier to entry" of having to re-purchase all of your software is lessened somewhat.
Fingerprint readers don't work very well under windows either.
Exactly. Until the linux crowd stop reinventing the wheel, commit to an API/ABI standard and actually support an upgrade path, this shit will continue to happen.
I even had one kernel upgrade swap the order of NIC detection around on a firewall, so that eth0 (inside) became eth1 (outside) and vice versa due to the internal hardware detection order changing. Nice one. Thus, after that I moved all my NIC drivers out to modules to force them to load in a particular order - but no doubt eventually even that would get broken due to soem genius deciding to scan the PCI bus in a different order or something and 2 NICs of the same chipset would get swapped.
And yes, until they get a stable driver ABI, expecting hardware OEMs to bother trying to keep up support for such a niche platform is a joke. It works both ways kids - don't expect people to write drivers for your OS if you can't provide a stable standard interface.
As someone who was running debian in production on internet facing servers between 1999 and 2005, I'm telling you it isn't always that straightforward.
Could be done just as easily without microsoft's involvement, and without Windows being involved. Government pays/bribes/extorts major CA to give them the private key used by X secure service. Service is then subverted. Whether it is for code signing, HTTPs, etc.
Some people seem to think that PKI is a silver bullet. It's not. However just because it can't protect against 100% of edge cases, doesn't mean that it is worthless. Any slashdotter worth their salt should know that security is built in layers. PKI is just a single layer.
More importantly... compare it to a Linux install from 12 years ago, that you then attempt to upgrade to current security patch level without breaking it without a reinstall.
Compare it to a Linux install from 12 years ago.
Because someone having to steal a certificate first, and then get malware to spread significantly before the certificate is revoked is so much less secure than not signing your code at all?
Oh please. Next you'll be saying we shouldn't bother to lock our doors because someone can just throw a brick through the window too, yes?
Plus the time to copy it to the new hardware, vs just starting the VM from your VM datastore.
Because the alterantive is "insecure by default". Which microsoft have taken huge flak for in the past. If you want to run Linux or other, you have 2 options: run linux that is code-signed, or turn code signing off and run it like you would today. This is a NON-ISSUE that will drastically improve security for operating systems which support it.
Use the correct tool for the job. End user devices, apple is good. Servers, use something else. Desktop OS and server OS do not have to be (and in the past never were) the same.
Windows client to Windows server is a relatively recent abberation. desktop and server OS have totally different and conflicting requirements.
Solution: Don't run OS X servers. Apple don't make real servers. Apple don't even use their own servers in-house. Server and desktop do not have to be the same platform. Buy commodity server hardware, run vSphere on it, and present shares, etc to your mac clients using FreeBSD/Linux/etc...
You mean intel audio, broadcom nics, nvidia/amd video and intel x64 cpus? yes, they have EFI, but that's no major hassle these days.
Because they both have the same IPC?
Nah. We run commvault, and have physical media servers (to run our tape libraries) and the management console/database is a VM. Everything is backed up to tape. If you have enterprise+ licensing with VMware you can actually use site recovery manager to keep a set of VMs in sync between two sites - if the primary site goes down you flick to DR site, bring up your backup control VM, bring up your other mission critical VMs and restore the rest from tape.
I'm sure some out there are using the PCI-e style SSDs for ZFS cache vdevs. SAN vendors are now also pushing SSD cache as well.
I haven't used OCZ hardware, but their rep is from cheap consumer grade desktop stuff. Besides, in the enterprise you won't be running cards without some level of RAID style fault tolerance in any case.