But then they MUST offer the modified source to anyone they distribute a binary to. They also get to field all of the support issues since the kernel maintainers won't touch a bug report if the kernel is tainted by a non-free module (for good reason).
Seems a non-issue. If the bug is not in their code it could be replicated in the pristine kernel and reported to maintainers. Since the forked kernel would be used at the core of one of their virtual machines they would be the natural contact point. From the customer's perspective VMware failed, not some embedded kernel that they don't know or care about.
The deciding factor is whether or not it is using the defined API. If so, it is mere use and not derivation. If the kernel has to be modified to add an API, there would be a clear violation.
That is simply a fork of the kernel. If the forked kernel source is published there would seem to be no violation.
For example virtual functions require an extra level of indirection over C function calls.
You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.
If you're not using inheritance then you won't use a virtual function. (Did you read what I wrote?)
Yes, I'm rejecting the notion that C++ code inherently involves inheritance. Note my reference to minor use classes and templates being quite useful and not performance hindering.
You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++.
Portable libraries. It makes no fucking difference whether the library was written within the same conglomerate.
It however does disprove you claim that C++ isn't being used to a large degree.
Plus you are doubly wrong again since people also use C++ in Apple targets for portability.
Are you hard of thinking? That was the one exception I made. Using portable libraries. However if the library intended to be portable starts on OSX, then it's virtually always written in C.
I'm not referring to libraries, I'm referring to the app's core code itself.
Also many libraries are merely C for legacy reasons. For new code, refer to Google's use of C++ again.
It is a popular misrepresentation of fascism to say that it is a partnership between state and corporations.
The actual definition of fascism involves syndicalism. Syndicates not corporations control industry, and more importantly syndicates are controlled by workers. This is somewhat socialist in nature. Additionally the syndicalism has a strong nationalist flavor. It kind of replaces the socialistic class conflict with a national/regional conflict. Fascism is a fusion of elements of the far right and the far left.
Fascist Italy recognized both the owners and the workers as distinct groups however the workers were empowered through syndicates and both the owners and syndicates were expected to cooperate as necessary to serve the needs of the state. The state put restrictions on both the owners and worker syndicates. They considered this model an alternative to both capitalism and marxism.
Militarism was central to Mussolini's beliefs. He viewed Fascist Italy as the heir to the Roman Empire spiritually and wanted to "restore" some of that old glory via military conquest and colonization. And that on an individual level it was the military and combat that helped a "man" to reach his full potential. This predates the rise of the Nazis. Matter of fact Hitler was Mussolini's understudy in the early days, Hitler looking up to him as a role model.
Mussolini was also racist, though a more moderate form than exhibited by the Nazis. He thought the aryan mediterranean "race" and culture superior. However he differed from the Nazis in that he didn't believe in strict biological definitions. He believed a certain amount of assimilation was possible, somewhat consistent with old school Rome where allies and conquered peoples could eventually become full Romans by adopting Roman culture and demonstrating fealty to Rome. That said, he absolutely made claims of white racial "superiority" as part of his justification for Italian colonies in Africa.
The fact that it is not altruistic, service yields a reward albeit at some risk, does not change its voluntary nature. Neither does its necessity. As long as there are sufficient volunteers this necessary task can accomplished. Now if there were insufficient volunteers then the model they based their society on would fail.
And you get to determine what constitute needs and wants, right?
No, I get to elect the people who make that determination. The libertarians advocate electing people who are more modest in those determination, who provide for actual needs of citizens, who don't provide mere wants as a mechanism to win favor and re-election.
Heinlein also used the basic income model in many of his stories. Its not all libertarian, its a balance between a social safety net and libertarian capitalism.
Not all libertarians are against a safety net and basic services like police, fire/rescue and the military. Its more about keeping gov't to an absolute minimum. To match, limit and scale gov't to a clear definable needs, not to have gov't engage in "well meaning" wants.
The fascism was largely a creation of the movie's director, Verhoeven. He had his own agenda that he thought the movie would be a good vehicle for. He even admits not reading the book.
As you point out the book is quite different. I would like to emphasize that the book is quite clear that federal service is not necessarily military service. That the federal service required hardship and a risk of severe bodily injury or death, for example construction in harsh environments (asteroids, space, etc). In fascism the military and combat is held above all else, mere laborers even doing hazardous construction would never be considered to have equivalent service.
You can't claim authority here. I was programming assembler as far back as 1983.
Me too, 6502 (Apple II, C64) and PDP-11. 68K too via Apple II coprocessor boards, maybe that was '84. Its how we did our earliest Mac development, couldn't afford a Lisa. Eventually 68K on Mac once native development was an option. And a ton of x86 throughout the late 80s and 90s, less so in the 2000s. A little bit of PowerPC in the 2000s too. Recent years just doing it for fun or looking at the generated code from compilers.
Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's.
What you mean by "misused" here is using the C++ parts of C++. Because if you do, you will almost certainly be slower than C. For example virtual functions require an extra level of indirection over C function calls.
You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.
(2) If you need the abstraction/indirection then you are simply doing your own indirection manually in C code. Been there, done that, in the late 80s when C++ was too new and object oriented methodologies would greatly benefit the application at hand.
**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer.
And when it doesn't matter then no need to stray from Obj-c. There's no reason to have 2 OO languages in a project.
I've proven this wrong already. Read past posts regarding portability, ex MS Dev Studio.
Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects."
Shut the fuck up. I've already said more than once that the only reason people use C++ in iOS or OSX projects is when they are leveraging a library that's in C++.
You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++. Plus you are doubly wrong again since people also use C++ in Apple targets for portability.
Straw man, the question is Obj-C v C++ not C++ v C. And for nearly any practical sense you are mistaken, its rare to find an environment that has C support but not C++.
Or as efficient.
Speaking as an assembly language programmer, you have been misinformed. Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's. Can an STL class be overkill, yes, but the STL is about convenience and correctness not performance, and a programmer's misuse of such a library is another programmer's error.
**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer. To be honest when dealing with extremely time critical code if C++ is going to be replaced I will replace it with assembly.
Limiting your options to C in the non-time critical portions of you code is completely unnecessary. You can write the C'ish code I mentioned above or you can write pure C code if you with for the minor amount of code that is time critical.
There really is no downside to using C++ in core code rather than Obj-C.
But there are downsides to using it in this capacity rather than C. Which is why few do so.
Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects."
http://google-styleguide.googl...
No one is advocating the notion that there is a secret team. Merely that various pieces of code are likely being tested separately from the simulators. For example unit testing, regression testing, etc. Furthermore it is likely that such testing takes place on multiple architectures. What I would add is that such multi-architecture testing would occur even for code currently targeting only a single architecture. It greatly facilitates debugging and ensures code is portable.
Familiarize yourself with Xcode and Mac OS X Server and you'll find quite a bit of support for automating such testing.
Untrue. As far as my C++ code goes its kind of "light" on the use of templates, classes, etc. I don't use them because they are available, I use them when they make sense. My code is sort of C'ish in this respect.
If you're wanting objects at the expense of speed, then you wouldn't stray from Obj-C in the first place.
Untrue. Obj-C is not as portable as C++. Even when not targeting MS Windows I like to compile the core code and run regression tests using MS Dev Studio. Yet another set of warnings, yet another code generator to help spot bugs. Plus I also tend to write code so that someone else can eventually maintain it. Obj-C is a niche language, C++ has a much broader user base.
There really is no downside to using C++ in core code rather than Obj-C.
You lose a lot by shifting between paradigms and being unable to pass objects around between different layers.
That is not my experience. It feels quite natural and automatic to think Obj-C when doing UI code and think C++ when doing core code. Plus passing objects around seems a non-issue. One can use C++ structures and classes in Obj-C code and Obj-C objects tend to be those interfacing with the UI code, objects of no interest to the core code. And if an Obj-C object is input from the user its trivial to convert to an ordinary UTF8 string, int, etc.
Most likely Apple's iTunes for Windows is written in Objective-C and it works for them.
That assumes one uses the gnu toolchain. When I write portable code I like to build it in Apple Xcode, MS Dev Studio and with GNU. Different warning can be useful and well as running regression tests on output from these three different code generators.
Perhaps my SF example created some confusion but my comment about gas leaks was independent from earthquakes, notice "happens all the time every day". I'll add that I am basing this on decades of maintenance experience (grandfather worked for gas company) from a region not prone to earthquakes, US North East.
I'll also add that gas leaks are only one of many possible sources of fires. Having worked in a warehouse fire was considered a major hazard. Far more hazardous than a home fire given limited egress points and the toxic by products of burning inventory. And this was in a warehouse serving department stores, not specialty chemicals and such.
SF was mentioned as an example of what a fire can do to a city when there is no active firefighting. I.e. huge sections of the city can burn.
There's not a lot of reason to pick up Objective C unless you plan on targeting Apple.
C++ is also important when targeting Apple. Objective-C is the language of the Cocoa API (Mac OS X and iOS), however there is no need to use it beyond code that makes Cocoa based system calls. And getting C++ and Objective-C code to call each other is trivial.
Personally I recommend separating UI and platform (OS) specific code from an app's core functionality and implementing the UI/platform-specific code in whatever the native language for the platform is and implementing the core code in C/C++. This leaves the core code portable, ready to target other platforms. I have iOS apps where the core code can be compiled in a console Linux environment and exercised by various scripts (regression testing) and in a random manner (fuzzing).
IANAL, but it looks like distributing the source code to "end users" of a compiled program is not allowed
Untrue. I am also not a lawyer and I only skimmed the agreement so perhaps I am misunderstanding it but I believe you can distribute the source code to your game.
What you cannot distribute is Epic's game engine source code and binary tools. However your customer can download these at no charge from Epic just like you did. So it seems a customer can get everything they need to rebuild the game themselves. They just need to download game code from you and engine code/tools from Epic.
Zombies don't need to be realistic, merely being entertaining is sufficient. They can be quite useful to bring up the topic of disaster preparedness. A super-flu, ebola, etc is not necessary for crisis. A "mundane" storm or earthquake that knocks out the power to millions and shuts down the supermarkets is sufficient. Anything that might spark a conversation or some thought about having a weeks worth of unrefrigerated food and water at home is a good idea. OK some plastic trash bags, baby wipes, and purell might also be a good idea for your in-home campout.
Similar story for those survivalist/prepper shows.
Not a good metaphor. Zombie converts have a very reliable loyalty. While social/political/religious converts are more prone to be reliable only as long as the evangelist with the gun/sword/knife/money is standing nearby.:-)
One smart human with 30 minutes to prepare makes a spear and scares off a lion, wolf, or even a bear.
Maybe in the movies. In reality a solo human is almost certainly at the mercy of the bear once things get to spear range. If you survive its because the bear was motivated by dominance / threat removal not predation. Wolves, you won't be against one, and while one gets your attention another will dash in and out for a quick bite to the leg to get you bleeding, to start the process where you become too weak to fight. Lions, well in North America that will be the mountain lion that you never saw and never raised your spear against.
Why? Because we are some sneaky, devious, son's of bitches that outwit enemies.
Not really. The most important factor is the social factor, the extended family / tribal behavior. Solo sneaky toolmaker -- highly vulnerable. Tribal sneaky toolmakers -- very dangerous.
Highly vulnerable to fires. Without maintenance (ex: gas company crews fixing leaks -- happens all the time every day) and firefighting you are at risk and still need to be ready to bug out and be mobile. Think of the fires that followed the 1906 San Francisco earthquake.
, this isn't something surprising nor some secretive thing. You do realize that the iOS simulator runs x86(_64) compiled code, right? That's how it's always worked.
Yeah, I realized this just as I typed the word "simulated" in another post.:-)
However I still expect that much iOS specific code is run in regression tests completely separate from the various device simulators.
But then I'm biased. Giving all the porting I've done I'm a little "enthusiastic" about separating core code from UI code and other platform specific code. Windows apps, Mac OS apps, iOS apps, Android apps, etc... I've tended to have core code runnable in a console environment for testing on the headless Linux box in the closet. Regression, fuzzing, etc.
I'm referring to much more than Darwin. Possibly iOS in its entirety. At a minimum various iOS specific frameworks in a regression test environment. Including some hardware specific frameworks where inputs are simulated.
Wait, speaking of "simulated", we have the Mac OS X based iOS device simulators used during development. Doh!
{ Oops, forgot to log in, didn't mean to post AC }
While tides are predictable that are also predictably different than electricity demand curves. Storage is still needed to shift production to meet demand. Predictability is not dispatchability. Add the cost of storage need to shift production to demand and the cost is much higher.
Its not that simple. Tidal generation can also be used to temporarily reduce fossil fuel based generation. Throttle down the fossil fuel based plants during tidal generation, it predictable and schedule-able after all. Power generation can remain constant yet less fossil fuels are used.
It just takes a dev or two building and testing the code on x86 just to make sure its cross platform.
Such an effort can pay for itself simply through the bugs it will find. What is a very subtle and sometimes currently unnoticed bug on one platform may become a highly visible bug on another platform. Bugs sometimes manifest differently on different platforms. I've been on several teams over time where we moved good "working" code to a new platform and watched it crash spectacularly over and over again. Each time the original devs who thought their code was in great shape were shaking their heads wonder how it ever ran on the original platform. Lucky values in uninitialized variables and such.
So yes, someone is probably building and testing iOS on x86 but it has little to nothing to do with any plans regarding using x86 on any devices. Sort of similar to the Microsoft's efforts to internally build and test Windows on a non-x86 platform after it gave up on shipping MIPS, PowerPC and Alpha binaries. Its more about testing and future proofing a core asset than any short term plans.
And if I were running Intel I would be supplying the engineers to do so if Apple was not doing it on their own initiative.
Slashdot Mirror
But then they MUST offer the modified source to anyone they distribute a binary to. They also get to field all of the support issues since the kernel maintainers won't touch a bug report if the kernel is tainted by a non-free module (for good reason).
Seems a non-issue. If the bug is not in their code it could be replicated in the pristine kernel and reported to maintainers. Since the forked kernel would be used at the core of one of their virtual machines they would be the natural contact point. From the customer's perspective VMware failed, not some embedded kernel that they don't know or care about.
The deciding factor is whether or not it is using the defined API. If so, it is mere use and not derivation. If the kernel has to be modified to add an API, there would be a clear violation.
That is simply a fork of the kernel. If the forked kernel source is published there would seem to be no violation.
For example virtual functions require an extra level of indirection over C function calls.
You are wrong, doubly wrong actually. (1) If the class is not using inheritance you don't get the indirection.
If you're not using inheritance then you won't use a virtual function. (Did you read what I wrote?)
Yes, I'm rejecting the notion that C++ code inherently involves inheritance. Note my reference to minor use classes and templates being quite useful and not performance hindering.
You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++.
Portable libraries. It makes no fucking difference whether the library was written within the same conglomerate.
It however does disprove you claim that C++ isn't being used to a large degree.
Plus you are doubly wrong again since people also use C++ in Apple targets for portability.
Are you hard of thinking? That was the one exception I made. Using portable libraries. However if the library intended to be portable starts on OSX, then it's virtually always written in C.
I'm not referring to libraries, I'm referring to the app's core code itself.
Also many libraries are merely C for legacy reasons. For new code, refer to Google's use of C++ again.
It is a popular misrepresentation of fascism to say that it is a partnership between state and corporations.
The actual definition of fascism involves syndicalism. Syndicates not corporations control industry, and more importantly syndicates are controlled by workers. This is somewhat socialist in nature. Additionally the syndicalism has a strong nationalist flavor. It kind of replaces the socialistic class conflict with a national/regional conflict. Fascism is a fusion of elements of the far right and the far left.
Fascist Italy recognized both the owners and the workers as distinct groups however the workers were empowered through syndicates and both the owners and syndicates were expected to cooperate as necessary to serve the needs of the state. The state put restrictions on both the owners and worker syndicates. They considered this model an alternative to both capitalism and marxism.
Militarism was central to Mussolini's beliefs. He viewed Fascist Italy as the heir to the Roman Empire spiritually and wanted to "restore" some of that old glory via military conquest and colonization. And that on an individual level it was the military and combat that helped a "man" to reach his full potential. This predates the rise of the Nazis. Matter of fact Hitler was Mussolini's understudy in the early days, Hitler looking up to him as a role model.
Mussolini was also racist, though a more moderate form than exhibited by the Nazis. He thought the aryan mediterranean "race" and culture superior. However he differed from the Nazis in that he didn't believe in strict biological definitions. He believed a certain amount of assimilation was possible, somewhat consistent with old school Rome where allies and conquered peoples could eventually become full Romans by adopting Roman culture and demonstrating fealty to Rome. That said, he absolutely made claims of white racial "superiority" as part of his justification for Italian colonies in Africa.
The fact that it is not altruistic, service yields a reward albeit at some risk, does not change its voluntary nature. Neither does its necessity. As long as there are sufficient volunteers this necessary task can accomplished. Now if there were insufficient volunteers then the model they based their society on would fail.
And you get to determine what constitute needs and wants, right?
No, I get to elect the people who make that determination. The libertarians advocate electing people who are more modest in those determination, who provide for actual needs of citizens, who don't provide mere wants as a mechanism to win favor and re-election.
Heinlein also used the basic income model in many of his stories. Its not all libertarian, its a balance between a social safety net and libertarian capitalism.
Not all libertarians are against a safety net and basic services like police, fire/rescue and the military. Its more about keeping gov't to an absolute minimum. To match, limit and scale gov't to a clear definable needs, not to have gov't engage in "well meaning" wants.
The fascism was largely a creation of the movie's director, Verhoeven. He had his own agenda that he thought the movie would be a good vehicle for. He even admits not reading the book.
As you point out the book is quite different. I would like to emphasize that the book is quite clear that federal service is not necessarily military service. That the federal service required hardship and a risk of severe bodily injury or death, for example construction in harsh environments (asteroids, space, etc). In fascism the military and combat is held above all else, mere laborers even doing hazardous construction would never be considered to have equivalent service.
Speaking as an assembly language programmer
You can't claim authority here. I was programming assembler as far back as 1983.
Me too, 6502 (Apple II, C64) and PDP-11. 68K too via Apple II coprocessor boards, maybe that was '84. Its how we did our earliest Mac development, couldn't afford a Lisa. Eventually 68K on Mac once native development was an option. And a ton of x86 throughout the late 80s and 90s, less so in the 2000s. A little bit of PowerPC in the 2000s too. Recent years just doing it for fun or looking at the generated code from compilers.
Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's.
What you mean by "misused" here is using the C++ parts of C++. Because if you do, you will almost certainly be slower than C. For example virtual functions require an extra level of indirection over C function calls.
You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.
(2) If you need the abstraction/indirection then you are simply doing your own indirection manually in C code. Been there, done that, in the late 80s when C++ was too new and object oriented methodologies would greatly benefit the application at hand.
**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer.
And when it doesn't matter then no need to stray from Obj-c. There's no reason to have 2 OO languages in a project.
I've proven this wrong already. Read past posts regarding portability, ex MS Dev Studio.
Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects."
Shut the fuck up. I've already said more than once that the only reason people use C++ in iOS or OSX projects is when they are leveraging a library that's in C++.
You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++. Plus you are doubly wrong again since people also use C++ in Apple targets for portability.
Obj-C is not as portable as C++
And C++ isn't as portable as C.
Straw man, the question is Obj-C v C++ not C++ v C. And for nearly any practical sense you are mistaken, its rare to find an environment that has C support but not C++.
Or as efficient.
Speaking as an assembly language programmer, you have been misinformed. Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's. Can an STL class be overkill, yes, but the STL is about convenience and correctness not performance, and a programmer's misuse of such a library is another programmer's error.
**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer. To be honest when dealing with extremely time critical code if C++ is going to be replaced I will replace it with assembly.
Limiting your options to C in the non-time critical portions of you code is completely unnecessary. You can write the C'ish code I mentioned above or you can write pure C code if you with for the minor amount of code that is time critical.
There really is no downside to using C++ in core code rather than Obj-C.
But there are downsides to using it in this capacity rather than C. Which is why few do so.
Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects." http://google-styleguide.googl...
No one is advocating the notion that there is a secret team. Merely that various pieces of code are likely being tested separately from the simulators. For example unit testing, regression testing, etc. Furthermore it is likely that such testing takes place on multiple architectures. What I would add is that such multi-architecture testing would occur even for code currently targeting only a single architecture. It greatly facilitates debugging and ensures code is portable.
Familiarize yourself with Xcode and Mac OS X Server and you'll find quite a bit of support for automating such testing.
All these things are usually best served by C.
Untrue. As far as my C++ code goes its kind of "light" on the use of templates, classes, etc. I don't use them because they are available, I use them when they make sense. My code is sort of C'ish in this respect.
If you're wanting objects at the expense of speed, then you wouldn't stray from Obj-C in the first place.
Untrue. Obj-C is not as portable as C++. Even when not targeting MS Windows I like to compile the core code and run regression tests using MS Dev Studio. Yet another set of warnings, yet another code generator to help spot bugs. Plus I also tend to write code so that someone else can eventually maintain it. Obj-C is a niche language, C++ has a much broader user base.
There really is no downside to using C++ in core code rather than Obj-C.
You lose a lot by shifting between paradigms and being unable to pass objects around between different layers.
That is not my experience. It feels quite natural and automatic to think Obj-C when doing UI code and think C++ when doing core code. Plus passing objects around seems a non-issue. One can use C++ structures and classes in Obj-C code and Obj-C objects tend to be those interfacing with the UI code, objects of no interest to the core code. And if an Obj-C object is input from the user its trivial to convert to an ordinary UTF8 string, int, etc.
Most likely Apple's iTunes for Windows is written in Objective-C and it works for them.
That assumes one uses the gnu toolchain. When I write portable code I like to build it in Apple Xcode, MS Dev Studio and with GNU. Different warning can be useful and well as running regression tests on output from these three different code generators.
Perhaps my SF example created some confusion but my comment about gas leaks was independent from earthquakes, notice "happens all the time every day". I'll add that I am basing this on decades of maintenance experience (grandfather worked for gas company) from a region not prone to earthquakes, US North East.
I'll also add that gas leaks are only one of many possible sources of fires. Having worked in a warehouse fire was considered a major hazard. Far more hazardous than a home fire given limited egress points and the toxic by products of burning inventory. And this was in a warehouse serving department stores, not specialty chemicals and such.
SF was mentioned as an example of what a fire can do to a city when there is no active firefighting. I.e. huge sections of the city can burn.
There's not a lot of reason to pick up Objective C unless you plan on targeting Apple.
C++ is also important when targeting Apple. Objective-C is the language of the Cocoa API (Mac OS X and iOS), however there is no need to use it beyond code that makes Cocoa based system calls. And getting C++ and Objective-C code to call each other is trivial.
Personally I recommend separating UI and platform (OS) specific code from an app's core functionality and implementing the UI/platform-specific code in whatever the native language for the platform is and implementing the core code in C/C++. This leaves the core code portable, ready to target other platforms. I have iOS apps where the core code can be compiled in a console Linux environment and exercised by various scripts (regression testing) and in a random manner (fuzzing).
IANAL, but it looks like distributing the source code to "end users" of a compiled program is not allowed
Untrue. I am also not a lawyer and I only skimmed the agreement so perhaps I am misunderstanding it but I believe you can distribute the source code to your game.
What you cannot distribute is Epic's game engine source code and binary tools. However your customer can download these at no charge from Epic just like you did. So it seems a customer can get everything they need to rebuild the game themselves. They just need to download game code from you and engine code/tools from Epic.
Of course it does. Most of the iOS code is simply Darwin.
No. For example the frameworks account for a lot of code and some differ between Mac OS and iOS and some are unique to iOS.
Zombies don't need to be realistic, merely being entertaining is sufficient. They can be quite useful to bring up the topic of disaster preparedness. A super-flu, ebola, etc is not necessary for crisis. A "mundane" storm or earthquake that knocks out the power to millions and shuts down the supermarkets is sufficient. Anything that might spark a conversation or some thought about having a weeks worth of unrefrigerated food and water at home is a good idea. OK some plastic trash bags, baby wipes, and purell might also be a good idea for your in-home campout.
Similar story for those survivalist/prepper shows.
Not a good metaphor. Zombie converts have a very reliable loyalty. While social/political/religious converts are more prone to be reliable only as long as the evangelist with the gun/sword/knife/money is standing nearby. :-)
One smart human with 30 minutes to prepare makes a spear and scares off a lion, wolf, or even a bear.
Maybe in the movies. In reality a solo human is almost certainly at the mercy of the bear once things get to spear range. If you survive its because the bear was motivated by dominance / threat removal not predation. Wolves, you won't be against one, and while one gets your attention another will dash in and out for a quick bite to the leg to get you bleeding, to start the process where you become too weak to fight. Lions, well in North America that will be the mountain lion that you never saw and never raised your spear against.
Why? Because we are some sneaky, devious, son's of bitches that outwit enemies.
Not really. The most important factor is the social factor, the extended family / tribal behavior. Solo sneaky toolmaker -- highly vulnerable. Tribal sneaky toolmakers -- very dangerous.
Highly vulnerable to fires. Without maintenance (ex: gas company crews fixing leaks -- happens all the time every day) and firefighting you are at risk and still need to be ready to bug out and be mobile. Think of the fires that followed the 1906 San Francisco earthquake.
, this isn't something surprising nor some secretive thing. You do realize that the iOS simulator runs x86(_64) compiled code, right? That's how it's always worked.
Yeah, I realized this just as I typed the word "simulated" in another post. :-)
... I've tended to have core code runnable in a console environment for testing on the headless Linux box in the closet. Regression, fuzzing, etc.
However I still expect that much iOS specific code is run in regression tests completely separate from the various device simulators.
But then I'm biased. Giving all the porting I've done I'm a little "enthusiastic" about separating core code from UI code and other platform specific code. Windows apps, Mac OS apps, iOS apps, Android apps, etc
I'm referring to much more than Darwin. Possibly iOS in its entirety. At a minimum various iOS specific frameworks in a regression test environment. Including some hardware specific frameworks where inputs are simulated.
Wait, speaking of "simulated", we have the Mac OS X based iOS device simulators used during development. Doh!
{ Oops, forgot to log in, didn't mean to post AC }
While tides are predictable that are also predictably different than electricity demand curves. Storage is still needed to shift production to meet demand. Predictability is not dispatchability. Add the cost of storage need to shift production to demand and the cost is much higher.
Its not that simple. Tidal generation can also be used to temporarily reduce fossil fuel based generation. Throttle down the fossil fuel based plants during tidal generation, it predictable and schedule-able after all. Power generation can remain constant yet less fossil fuels are used.
It just takes a dev or two building and testing the code on x86 just to make sure its cross platform.
Such an effort can pay for itself simply through the bugs it will find. What is a very subtle and sometimes currently unnoticed bug on one platform may become a highly visible bug on another platform. Bugs sometimes manifest differently on different platforms. I've been on several teams over time where we moved good "working" code to a new platform and watched it crash spectacularly over and over again. Each time the original devs who thought their code was in great shape were shaking their heads wonder how it ever ran on the original platform. Lucky values in uninitialized variables and such.
So yes, someone is probably building and testing iOS on x86 but it has little to nothing to do with any plans regarding using x86 on any devices. Sort of similar to the Microsoft's efforts to internally build and test Windows on a non-x86 platform after it gave up on shipping MIPS, PowerPC and Alpha binaries. Its more about testing and future proofing a core asset than any short term plans.
And if I were running Intel I would be supplying the engineers to do so if Apple was not doing it on their own initiative.