Sony's PlayStation 4 Is Running Modified FreeBSD 9

[Ericg]

Khronos said at some point that they will create a new API which will break compatibility. That one was supposed to be OpenGL 2.0 from what I remember. Of course, they backed down and ended up being something only incremental instead of revolutionary.

It was supposed to be OpenGL 3.0, google "OpenGL Longs Peak", but Khronos backed down due to "issues" and instead of breaking Backwards compatibility they "depreciated" the OpenGL 1 and 2 shit they didnt like and then 3.1 officially "removed it." Thats the whole thing with a Core and Compatibility contexts, it decides what parts of what versions you can and can't get access to.

[Guest]

Evidence? Just check the logs for FreeBSD 9, Apple contributing some tech back was a big deal for that release.

Sorry, but this is ridiculous. There are companies which support Linux all the time and some bits coming to bsd from time to time sounds like a joke.

[Ericg]

PS3 was on a modified BSD too, wasn't it?
Will be interesting to see how emulators work out this time around since the code will be for x86, I wonder if there will be a native-esque BSD/Linux emulator.

edit:
anyone saying they chose BSD because "it's a better platform" is fooling themselves, they just wanted to steal someone's hard work without giving any credit.
Not to mention Linux already has the Steambox on the way anyways... Valve has already helped the Linux community a lot(improved drivers, working directly with canonical, etc), what has Sony given to the BSD community?

Again... Not stealing. The BSD License says

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3) Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

BSD Developers knowingly and willfully choose the BSD License because they want the code in the hands of as many people as humanly possible regardless of the project in question. They just want their code out there being used. Enough of this "If you're not with us*, you're against us."

*Us being GPL supporters...or more specifically in this case, zealots. You're zealots plain and simple, you can't even respect the choices of OTHER people because if you COULD you wouldn't be jumping down their throats about them choosing the BSD License.

[peppercats]

Again... Not stealing. The BSD License says



BSD Developers knowingly and willfully choose the BSD License because they want the code in the hands of as many people as humanly possible regardless of the project in question. They just want their code out there being used. Enough of this "If you're not with us*, you're against us."

*Us being GPL supporters...or more specifically in this case, zealots. You're zealots plain and simple, you can't even respect the choices of OTHER people because if you COULD you wouldn't be jumping down their throats about them choosing the BSD License.

I like how you already resorted to calling me a "GPL zealot" when you don't even know me.
If I see someone take another person's hard work just to profit off of it, even if he's giving it away for free for some retarded reason, I will forever call it stealing. There is no mental gymnastics you can do to stop me, sorry.

[Ericg]

Sorry, but this is ridiculous. There are companies which support Linux all the time and some bits coming to bsd from time to time sounds like a joke.

Keep in mind, there's nothing demanding in the GPL that you submit your modifications back upstream. It just demands that you make them available IF you distribute binaries.

Google ran modified Ubuntu installations on their desktops and servers for a long time, probably making some pretty serious performance improvements that netted them A LOT of cash in the end and didn't contribute all or any of those changes back to Upstream.

Why can they do this? Because they kept them internal, as long as you don't distribute your changes outside of yourself (which would be to say: you dont willfully distribute binaries outside of your company) the GPL basically IS the BSD license.

[Ericg]

Wrong, you are the zealots! BSD zealots! We are not. We just have common sense while you are nothing more then freedom and Linux hates who have lost touch of reality just like the shitty BSD devs.

BSD devs don't want their code to be use. They want to see proprietary software succeed. They are proprietary sluts as what the venerable kraftman said. You should listen to kraftman because he doesn't talk bullshit like you. He speaks wisdom.

Yeah...I'm a BSD zealot... thats why I'm currently running Fedora (GPL) using KDE (LGPL), using FOSS drivers (MIT). And my preferred license of choice..is the LGPL

Just because I'm a reasonable, well mannered, practical, human being doesn't make me a zealot.

[mrugiero]

I like how you already resorted to calling me a "GPL zealot" when you don't even know me.
If I see someone take another person's hard work just to profit off of it, even if he's giving it away for free for some retarded reason, I will forever call it stealing. There is no mental gymnastics you can do to stop me, sorry.

And that's why he's calling you a zealot. In your mind, the concept of gift doesn't seem to exist, even when the whole idea of the GPL is sharing.
Some people like to share with similar minded individuals (i.e., other people that like sharing, too), and they use specially restrictive licenses to allow sharing but to deny hoarding.
Other people like to share disregarding if the people who receives it will share what they build on top or if they choose to keep it for themselves, and they use liberal licenses, so anyone can do what they please with their gift.

You can be one or the other, or maybe even none, but when you don't respect other's choice, you are being a zealot.
And I say this as a pro GPL I am. I'm not very happy with Sony's choice because they probably aren't contributing back, but again, BSD folks are free to give their code the way they want. It was them putting the hard work, not us, so is not to us to judge if they did right, is to them.

[elanthis]

I second that. This GL bashing sounded more like a rant, than something real.

Some key points.

* GL's object handles are super error-prone. All objects are identified by an int. Easy to fail to understand what to pass in to what. Furthemore, there is a requirement for a level of indirection between client-side API objects and handles, since you can't stuff a 64-bit pointer into a 32-bit int and there are rules about the IDs being generated sequentially in some cases any, which you can't do with a pointer-cast-to-an-int.

* The GL latch/state system is and poorly specified. Some GL|ES vendors implement it differently, all within spec. The latch system is wher you don't just modify an object, but instead set an object with one API call and then modify the bound object with a second. In some cases, what happens when you unbind objects varies wildly, like VAOs on different hardware vendors. Larger game engines need to worry about significant work-arounds to deal with a variety of devices and vendors.

* The GL API was originally released in 1991 for rasterization acceleration hardware. It has been extended - poorly - to keep up with modern hardware, usually years late, and way behind D3D. Many parts of the 3.0 GL API were design around what people "thought" hardware would be, and they guessed wrong. Many of those assumptions were not worked aorund in the API until 4.3, and some still remain. For back-compat reasons, those assumptions are still present, it's usually harder to do things the "right" way than the wrong way, and inexperience users are constantly doing things wrong because out-dated tutorials and the highly redundant GL API lead them astray. D3D on the other hand rather sensibly just releases a new version of the API when things have changed enough to warrant it, as well as to fix old mistakes.

* GL tries to hold your hand more often than D3D. This results in some "GL is easier to use" comments from beginners, but actually squeezing out performance of GL is a complicated process compared to D3D. You have to use obtuse, rdundant APIs in non-obvious ways to get the best performance. Using GL|ES or GL Core Profile is about as much work as D3D11, but most novices don't deal with those.

* GL Core Profile / Compatibility Profile was a misguided attempt to solve the crufty API problem. Of course, the only things they did was disable old redundant APIs without replacing some of the existint dual-usage APIs that could stand for a refresh. Given the lack of a test suite, most drivers were (still are) buggy as hell when in Core Profile mode. This has resulted in everyone everywhere still writing Compatibility Profile code, except on OSX where you can't get GL 3+ without enabling Core Profile. This causes a lot more portability problems than necessary. API cleanups have been abandoned by Khronos because they think their idiotic attempt at "profiles" is the only way to do API cleanups.

* Dekstop GL drivers are buggy and incomplete. Both NVIDIA and AMD have yet to deliver bug-free fully-compatible GL 4.3 implementation almost a full year after release. The drivers are barely used. Khronos provides no test suite. Games using GL on the desktop typically have much higher support costs than D3D games due almost entirely to the GL drivers. This is not super relevant to the API itself, of course, but is a huge deal to developers shipping actual games - they can't write GL versions of the game if they want to target the PC.

* The GL tools and debugging facilities are under-featured. Finding out why any particular GL call fails is an exercise in maximum frustration. Tools have gotten better in recent years, but the d3d tools have improved even further. Part of this is an API issue; the GL error reporting facilities are weak and the API prone to far more errors in the first place.

* Parts of the API are overloaded and awkward. glVertexAttribPointer takes a void* as the final argument... but in all modern GL usage, you're actually passing in an integer here. Likewise, glTexImage2d and friends have redundant, pointless parameters that still must be set just right (and different than most existing documentation will state) to work properly.

* GLSL does not reflect how the shader pipeline actually works up until GLSL 4.30... which again, you can't actually use in real life. Even then, assuming a console "does it right," the syntax in GLSL to deal with doing things properly is incredibly cumbersome compared to doing it wrong, since back-compat was kept to keep some mythical CAD folks who might want to use 4.3 and currently use 2.x happy.

* Despite years of clamoring from some of the biggest GL proponents and even NVIDIA, Khronos rejects many API improvements like "direct state access" into the core API.

* Extensions are a huge pain in the ass. You can't just write a GL app. You have to write slightly-different-for-each-hardware-vendor GL path in your code in order to make things work well. Consoles require this anyway, of course, but on the desktop space this matters.

* EGL is not really a thing except for GL|ES. Many of the features provided by DirectX's DXGI are unsupported without EGL and even with EGL some bits are missing.

* Did I mention what a terrible error-prone pain in the ass using the API is?

* Hardware features that you should rely on are treated as "potential optimizations" in the GL API. This is especially harmful to newer users. It's still common here in 2013 to see people asking whether they should use vertex buffers or not.

* Some GL interfaces do not reflect how the hardware works, even in 4.3. Vertex Array Objects are kinda sorta like ID3D11InputLayout except they also specify buffer bindings, which are dealt with separately on hardware. Likewise, FrameBuffer Objects do not reflect how render targets are bound on the hardware. It's difficult to minimize state changes and have you to hope that the driver does the right thing (completely unacceptable on consoles where you really, really need direct control).

* GL misses some features found in hardware, like DXT texture compression, in the name of patents. That's great for Mesa and FOSS but shitty for people who need to make actual products that actually use the expensive graphics hardware fully. Kind of a wash as D3D is missing some texture modes and such that GL has (not ones you really need, but still, I've heard noises from a developer at Microsoft that they want to fix this in a future update).

* GL does not support any kind of multi-threaded object management or command list generation. The old Display List functionality is deprecated and not equivalent in any case (if you send a draw call with a VBO to a display list, the VBO contents are copied, rather than merely recording the VBO handle). You can with some vendor-specific work-arounds do object management on multiple cores but this also creates a full rendering context (bad!) and again doesn't handle command list generation.

* GL's global states mentioned previously don't just make the API more complex, but also cause frequent bugs, and don't reflect hardware. Real hardware has state blocks. D3D mirrors these. Granted, D3D11 is a little out of date in this regard as its concept of state blocks do not match 100% modern hardware, but this will most likely be corrected in D3D12. It will probably never be dealt with in GL, ever.

* GL binds its output surface/rendering context to its concept of a device handle. Recreating a rendering surface implies regenerating the whole context.

* GL is managed-resources only... sometimes. Don't want a buffer you upload kept in both GPU and CPU space? Up to the driver, not you. Necessary because...

* There is no proper "surface lost" or "device lost" signal for GL. Implementing proper display adapter switching or efficient hardware resets on GL is impossible without some new can't-be-integrated-properly extension that doesn't yet exist. This is part of why the previous point exists. Of cousre, GPU-only objects will still be lost.

* GL's API is designed for the days before compositing. On the desktop, D3D10+ assumes compositing. On a console, you can assume you might have overlays but not that you will be forced to share a single framebuffer with other processes. GL still maintains the concept of "pixel ownership" and this whole legacy cruft imposes some API nastiness that could be done away with.

* GL is slow to update. Microsoft works with hardware vendors during the definition of new hardware and APIs, acting as a liason between the development community's requests for D3D features and hardware vendors. Microsoft ensures that their API supports the common functionality on hardware and helps push vendors towards progress. GL languishes in a pit until well after a D3D update is released and then vendors scramble to define new extensions and combinations of old vendor-specific ones to get a half-assed spec out the door. It usually takes multiple version to "get it right." GL 3.x was the worst; it's gotten better, but not enough. GL 3.0 was released years after D3D 10 and didn't hit "almost" feature parity until GL3.3 even later. Likewise it took until 4.3 to catch up _mostly_ to D3D 11, minus the raft of features missing still. If you're releasing a new cutting-edge platform, using GL as a basis means your API will be years behind your hardware.

* Numerous other small API warts, missing features, and a disconnect with hardware.

I used to be a pro-GL bigot too back before I had any clue what the hell I was talking about. when I first moved to the games industry and was forced to Windows from Linux I came kicking and screaming. I still recall some of the long debates I had trying to arguing pro-GL merits to a variety of developers. After having every single point refuted, the sole two advantages I could keep for GL were "some platforms require it and it also works in Windows so it's 'more portable'" and "extensions give you early access to some vendor-specific features." Not much.

[Ericg]

You don't get the point

No, I'm pretty sure YOU'RE not getting the point...

No one is forcing you to run BSD Software, no one has a gun to your head telling you to run FreeBSD or they are going to kill you, no one is threatening to break your fingers if you don't license your software as GPL.

People make choices. You can disagree with them all you want, but in the end they are their choices. The developers who chose the BSD license for specific projects do so because for one reason or another they are doing so. Maybe their employer has a clause in their workman's contract that says any open source work has to be BSD, maybe they just want their code in the hands of as many people as possible, maybe they just don't care, or maybe its a throw-a-way project that they don't think could EVER be useful, but if SOME company SOME TIME finds a use for it..good for them. Or maybe its one of literally an INFINITE number of other reasons.

If you don't like BSD code, then don't touch ANY project with ANY BSD code in (thats probably going to be pretty damn hard...), never release ANY of your stuff out under BSD, thats all fine. Its your choices.

[johnc]

There are a lot of kooky people in the Linux world.

And I'm not even talking fanboys. Windows has A LOT of fanboys. As does Apple. I can deal with that.

But a lot of the Linux people are just plain wacky.