No. The open source code is still out there. I'm merely able to charge for the product that includes my modifications without releasing them. if someone wants to develop a new product or use the open source version it is still there.
As per the AC, you are hopelessly incorrect. There have been major ABI changes in BSD with major releases, changes between XP64 and Vista/7 x64, etc.
And the fact that FreeBSD can support NDIS windows network card drivers also proves that providing compatibility for a driver ABI whilst making changes is possible via a software shim.
So the whole "we'll be tied to an ABI forever!!" is complete and utter bollocks.
If I take BSD licensed code and incorporate it into my commercial product, and don't release the source, it is NOT stealing. It is totally within the requirements of the license. The BSD folk want (and this is what the GPL peeps DON'T get) ANY project to have a library of well tested, standards compliant code available for use as the project author sees fit. We DON'T want to force people to reinvent the wheel to circumvent licensing restrictions if they decide they want to build a closed source project (for whatever reason).
Closed source software will always exist - because there are jobs that need to be done that are not fun, require secrecy or whatever. I/BSD project people would MUCH rather that closed source application developers spend their time writing code that doesn't already exist, rather than spending development time and money to write/debug and maintain new code to solve a problem that has already been solved.
but a stable kernel ABI means committing to a particular behavior forever
No... it means you commit to making an interface available for as long as it is supported.
Windows, OS X, BSD, etc have gone through different ABIs. This is the sort of change major version numbers are for - not simply version number inflation because the maintainer is bored with major version 2, etc.
The mac offerings are still extremely limited. 1+ years on - and they're also available elsewhere for the most part. Steam being available does not automatically port the game library as some people seem to believe.
See this is the problem: As an end user I don't care WHY software isn't available for a particular platform. It doesn't matter. If it isn't available, and I need to use it (or rather, amount of pain to not have it exceeds the pain involved in paying for the other OS platform) then I don't switch platforms.
For most people the OS platform is not a religious issue. The OS is a platform to run the apps we want to run. If the apps aren't available - for whatever reason - the platform is of little use.
And a lot more people need/desire raw image support than photo labs. Any noob with a DSLR camera is going to want RAW image support.
Telling people "oh it's not linux's fault" doesn't make the problem go away.
I haven't played X3, but ditto for Eve. Elite is SIMPLE to pick up and get started with (it's a bit like wing commander with trading). Eve really does have a vertical learning curve.
You need an encyclopedia for the skills and how they complement each other. You need to sink massive amounts of time into it and join a player run corp to get anywhere.
How so? You're buying new hardware anyway, presumably. If your enterprise is on volume licensing, then the licenses already exist and are transferrable...
They likely know what SAMBA is. Its just not on the roadmap. Pulling out all the windows DCs and replacing, re-writing internal documentation, re-training/re-hiring SAMBA competent staff and giving up the ability to call Microsoft (or any vendor) when it breaks are all significant costs. For what? 10% performance improvement, IF samba is configured properly? Never mind having an uncertain future, if MS decide to extend AD in a way that the Samba team are unable to re-implement promptly.
Cost/Risk vs reward, for the enterprise it is a total no-brainer. I'm a unix admin since 1995, a Windows admin since 1996, and if you were to suggest replacing my DCs with Samba (as the new guy) you'd get laughed out of a job.
Rollback facility for the entire domain? You employing muppets? I've administered the AD here for 9 years out of the past 12, and have never needed to do a rollback. Delegate control properly, secure your shit and AD is fine.
If you want active directory, run active directory - and when you're chasing down some wierd behaviour between client and server you can go to a single source for support.
If you don't want active directory, run something else.
It was a conversation point, jackass. Given there were holes you could drive a truck through in the Windows 9x TCP/IP stack, I would bet my house that there were also similar sized holes in the 16 bit Windows 3.1 TCP/IP stack shipped with the IEAK for 16 bit IE, and also trumpet winsock of the day as well.
And as per my original post - ANY exploit in ANY software for Windows 3.1 would result in full privileges, as there was no multi-user security model.
So far we've found them to be pretty durable and pain free. We were previously a dell shop and we had massive, massive problems with the latitude E series (65xx in particular). We were getting 30% failure rate within 12 months and i was actually shipping out old D series machines to remote sites for improved reliability (this was say, 2008-2009).
Failure rate on the Elitebooks is back down to 2-3% over 12 months, so we're a lot happier.
The softpaq management software is a lot easier to use to keep our SOE current with new drivers, etc too.
Slashdot Mirror
For fucks sake. The BSD license does not consider it to be "stealing". Using BSD in your closed source project is ENCOURAGED.
No. The open source code is still out there. I'm merely able to charge for the product that includes my modifications without releasing them. if someone wants to develop a new product or use the open source version it is still there.
As per the AC, you are hopelessly incorrect. There have been major ABI changes in BSD with major releases, changes between XP64 and Vista/7 x64, etc.
And the fact that FreeBSD can support NDIS windows network card drivers also proves that providing compatibility for a driver ABI whilst making changes is possible via a software shim.
So the whole "we'll be tied to an ABI forever!!" is complete and utter bollocks.
If I take BSD licensed code and incorporate it into my commercial product, and don't release the source, it is NOT stealing. It is totally within the requirements of the license. The BSD folk want (and this is what the GPL peeps DON'T get) ANY project to have a library of well tested, standards compliant code available for use as the project author sees fit. We DON'T want to force people to reinvent the wheel to circumvent licensing restrictions if they decide they want to build a closed source project (for whatever reason).
Closed source software will always exist - because there are jobs that need to be done that are not fun, require secrecy or whatever. I/BSD project people would MUCH rather that closed source application developers spend their time writing code that doesn't already exist, rather than spending development time and money to write/debug and maintain new code to solve a problem that has already been solved.
Oh really. Just keep telling yourself that.
No... it means you commit to making an interface available for as long as it is supported.
Windows, OS X, BSD, etc have gone through different ABIs. This is the sort of change major version numbers are for - not simply version number inflation because the maintainer is bored with major version 2, etc.
Mod down? Lol. It is a simple FACT that if you run vSphere, Windows is the only supported platform for the virtual infrastructure client.
My point is this: STEAM on any platform is not an instant massive games library. Some people seem to believe it is.
Not going to happen because even though STEAM is ported, the library of games isn't.
Yeah all those 64 bit installs back in 2005 really sucked for performance.
The mac offerings are still extremely limited. 1+ years on - and they're also available elsewhere for the most part. Steam being available does not automatically port the game library as some people seem to believe.
See this is the problem: As an end user I don't care WHY software isn't available for a particular platform. It doesn't matter. If it isn't available, and I need to use it (or rather, amount of pain to not have it exceeds the pain involved in paying for the other OS platform) then I don't switch platforms.
For most people the OS platform is not a religious issue. The OS is a platform to run the apps we want to run. If the apps aren't available - for whatever reason - the platform is of little use.
And a lot more people need/desire raw image support than photo labs. Any noob with a DSLR camera is going to want RAW image support.
Telling people "oh it's not linux's fault" doesn't make the problem go away.
Until there's a version of vSphere's virtual infrastructure manager for Linux (or OS X), there's no way I can give up Windows for work.
As any steam using Mac owner will tell you - steam on linux won't bring the entire game library.
Uh... no.
Elite is arcade game first, trading game second. There's no arcade element to Eve at all.
I haven't played X3, but ditto for Eve. Elite is SIMPLE to pick up and get started with (it's a bit like wing commander with trading). Eve really does have a vertical learning curve.
You need an encyclopedia for the skills and how they complement each other. You need to sink massive amounts of time into it and join a player run corp to get anywhere.
PC-BSD.
Good luck with third party application support.
How so? You're buying new hardware anyway, presumably. If your enterprise is on volume licensing, then the licenses already exist and are transferrable...
They likely know what SAMBA is. Its just not on the roadmap. Pulling out all the windows DCs and replacing, re-writing internal documentation, re-training/re-hiring SAMBA competent staff and giving up the ability to call Microsoft (or any vendor) when it breaks are all significant costs. For what? 10% performance improvement, IF samba is configured properly? Never mind having an uncertain future, if MS decide to extend AD in a way that the Samba team are unable to re-implement promptly.
Cost/Risk vs reward, for the enterprise it is a total no-brainer. I'm a unix admin since 1995, a Windows admin since 1996, and if you were to suggest replacing my DCs with Samba (as the new guy) you'd get laughed out of a job.
Rollback facility for the entire domain? You employing muppets? I've administered the AD here for 9 years out of the past 12, and have never needed to do a rollback. Delegate control properly, secure your shit and AD is fine.
LOL. I has a hammer. Everything I see is a nail!
Use the right tool for the job. For AD services, that's a proper Windows DC.
Just like I wouldn't run IIS as an internet facing webserver, or Microsoft TMG as an edge firewall - I won't run SAMBA for core AD infrastructure.
If you want active directory, run active directory - and when you're chasing down some wierd behaviour between client and server you can go to a single source for support.
If you don't want active directory, run something else.
It was a conversation point, jackass. Given there were holes you could drive a truck through in the Windows 9x TCP/IP stack, I would bet my house that there were also similar sized holes in the 16 bit Windows 3.1 TCP/IP stack shipped with the IEAK for 16 bit IE, and also trumpet winsock of the day as well.
And as per my original post - ANY exploit in ANY software for Windows 3.1 would result in full privileges, as there was no multi-user security model.
So far we've found them to be pretty durable and pain free. We were previously a dell shop and we had massive, massive problems with the latitude E series (65xx in particular). We were getting 30% failure rate within 12 months and i was actually shipping out old D series machines to remote sites for improved reliability (this was say, 2008-2009).
Failure rate on the Elitebooks is back down to 2-3% over 12 months, so we're a lot happier.
The softpaq management software is a lot easier to use to keep our SOE current with new drivers, etc too.