Someone Copied the SNAP Source Code to Github Before Sony Pulled it Down(github.com)
github.com
Someone Copied the SNAP Source Code to Github Before Sony Pulled it Down
https://github.com/deliciousrobots/gnustep-gui-sony
37 comments
Does anyone know why the source was pulled?
Perhaps Sony forgot to remove code [0] that leaks new technology [1].
[0] http://blog.deliciousrobots.com/2010/11/27/sonys-changes-to-...
[1] http://www.engadget.com/2010/11/28/sony-fires-barrage-of-tou...
[0] http://blog.deliciousrobots.com/2010/11/27/sonys-changes-to-...
[1] http://www.engadget.com/2010/11/28/sony-fires-barrage-of-tou...
I’m guessing somebody leaned on Sony, as this was stated to be an all-in thing for their upcoming product lines, not an "experimental R&D project" as listed now.
There’s a couple of major players, namely Microsoft and Oracle; I wouldn’t be surprised if Apple was unhappy with this and moved to keep their skill-bank walled in.
Other than that, maybe a pointy-haired boss wanted something like .NET because it sounded more internet-y.
There’s a couple of major players, namely Microsoft and Oracle; I wouldn’t be surprised if Apple was unhappy with this and moved to keep their skill-bank walled in.
Other than that, maybe a pointy-haired boss wanted something like .NET because it sounded more internet-y.
> I wouldn’t be surprised if Apple was unhappy with this and moved to keep their skill-bank walled in.
I would find this surprising: more companies using obj-c means more people using obj-c means more people able to code on Apple platforms, which use obj-c nigh-exclusively.
I would find this surprising: more companies using obj-c means more people using obj-c means more people able to code on Apple platforms, which use obj-c nigh-exclusively.
Apple has no problem when people write software for their platforms, as long as it's not portable to other, competing, platforms.
If this effort went through, GNUStep could eventually be used to port Mac software to other platforms (Windows included) or to run it against controlled environments that would render iTunes DRM useless, and that's something Apple won't let happen.
If this effort went through, GNUStep could eventually be used to port Mac software to other platforms (Windows included) or to run it against controlled environments that would render iTunes DRM useless, and that's something Apple won't let happen.
Nobody is currently preventing this from happening and I doubt there is much Apple could do to stop it. That is to say, Openstep is an open API that anyone is free to develop an implementation of.
Of course, this isn't the same as if, for example, Sony directly circumvented or undermined Apple's security or certification technology.
Of course, this isn't the same as if, for example, Sony directly circumvented or undermined Apple's security or certification technology.
> I doubt there is much Apple could do to stop it. That is to say, Openstep is an open API that anyone is free to develop an implementation of.
I am not so sure. OpenStep (the spec) is probably safe, but that doesn't make sure the rest of Cocoa (which implements a superset of OpenStep) is immune from a patent or IP-related offensive.
I am not so sure. OpenStep (the spec) is probably safe, but that doesn't make sure the rest of Cocoa (which implements a superset of OpenStep) is immune from a patent or IP-related offensive.
Are you joking? Cocoa / GNUStep applications have been around for years and Apple has in no way attempted to punish anybody for making them.
GNUstep has already been tracking Apple's Cocoa for years without Apple complaining.
If you had any sort of evidence to support your wild theory I would be all ears.
GNUstep has already been tracking Apple's Cocoa for years without Apple complaining.
If you had any sort of evidence to support your wild theory I would be all ears.
GNUStep is not a viable alternative for developing cross-platform software that is competitive with the tools you use to build Mac-only software. I seriously doubt most software I use on my Mac is just a simple recompile away from my Linux notebook. If you have some evidence to support that, please, enlighten me.
If enough momentum is built behind GNUStep and it becomes a superset of Cocoa, it would be rather trivial to build a Wine-like environment for running OSX software on other OSs and that, I am sure, Apple would strongly oppose.
If enough momentum is built behind GNUStep and it becomes a superset of Cocoa, it would be rather trivial to build a Wine-like environment for running OSX software on other OSs and that, I am sure, Apple would strongly oppose.
Obviously Apple's Cocoa and Cocoa Touch libraries are a moving target and GNUstep is tracking those as best it can.
There are already people releasing software for both:
http://en.wikipedia.org/wiki/GNUstep#Ported_from_NeXTSTEP.2C...
Regardless of whether or not they are exactly compatible (some tweaking is necessary) I wonder where you get the idea that Apple would attack the GNUstep folks. Sounds like standard-grade FUD to me.
There are already people releasing software for both:
http://en.wikipedia.org/wiki/GNUstep#Ported_from_NeXTSTEP.2C...
Regardless of whether or not they are exactly compatible (some tweaking is necessary) I wonder where you get the idea that Apple would attack the GNUstep folks. Sounds like standard-grade FUD to me.
> Sounds like standard-grade FUD to me.
It's not FUD: it's just sane business strategy. If and when Apple sees GNUStep as a competitive threat (i.e. if a product based on it robs some market share), they'll attack it with whatever weapons they find most effective at the time. As it is now, it's not threatening them and Apple may even benefit from it, so, they'll leave GNUStep alone for the time being.
At least that's what I would do in their shoes.
As for why Sony halted its project, my bet would be the implicit patent grant in LGPLv2.1. That may feel uncomfortable for someone who needs to cross-license IP.
It's not FUD: it's just sane business strategy. If and when Apple sees GNUStep as a competitive threat (i.e. if a product based on it robs some market share), they'll attack it with whatever weapons they find most effective at the time. As it is now, it's not threatening them and Apple may even benefit from it, so, they'll leave GNUStep alone for the time being.
At least that's what I would do in their shoes.
As for why Sony halted its project, my bet would be the implicit patent grant in LGPLv2.1. That may feel uncomfortable for someone who needs to cross-license IP.
It is FUD. Why hasn't Apple attacked Google for using Webkit in Chrome? This isn't too terribly dissimilar than what you are suggesting.
One could make up doomsday scenarios all day, but the fact is that Apple has nothing to lose by wider adoption of Objective-C and similar libraries.
One could make up doomsday scenarios all day, but the fact is that Apple has nothing to lose by wider adoption of Objective-C and similar libraries.
> This isn't too terribly dissimilar than what you are suggesting.
Is Chrome in any way critical or considered a competitive advantage for Apple?
Is Chrome in any way critical or considered a competitive advantage for Apple?
PR stunt maybe?
They are afraid of being hit with a lawsuit on multitouch. since apple is suing everyone with two fingers.
I'm surprised that in discussions I've seen that nobody has mentioned Google TV. As a next gen TV framework SNAP would compete directly with it. It could even be seen as a less resource intensive & closer to the metal response to the Google TV strategy.
I think it's far more likely that it was shelved due to internal politics or pressure from Google than any other theory.
I think it's far more likely that it was shelved due to internal politics or pressure from Google than any other theory.
Is there a reason you'd want this? It seems if Sony pulled SNAP that the "next gen platform" it was to be intended for may not materialize, or may use another framework? What good could come out of this SDK if there's isn't a device/platform to use it on? /newbie question
I love "next gen platforms" based on technology from 1986. At least it doesn't use punch cards, I guess.
Much of the cutting edge today is based on Unix which has been continuously evolving since 1969... if you solve problems well from the outset, you often don't have to re-solve them over and over.
Which would be a valid point if Objective-C had evolved since 1986. The C family has evolved since then, C++, Java, C# v1 - C# v4. Objective-C gained properties in v2 and a host of ways to break encapsulation but its hardly evolved. The tools are even worse. XCode Fanbois rejoice at "new features" that I've had in SlickEdit since 1993.
You've hit the nail on the head with regard to my complaint.
You've hit the nail on the head with regard to my complaint.
As a corollary to this, see also all the articles on HN about people rediscovering vi 30 years after it was created.
How many editors out there lack regex and multiple clipboards, both of which have been around forever in vi?
Know the past or you may accidentally reimplement a solution to a problem that has already solved in a better way.
How many editors out there lack regex and multiple clipboards, both of which have been around forever in vi?
Know the past or you may accidentally reimplement a solution to a problem that has already solved in a better way.
There are few problems for which unchecked pointer arithmetic is a good solution, and even fewer at the application level. Computers are hundreds of times faster than they were in the NeXTstep days. We no longer need to risk undefined behavior just to get a GUI to keep up with a human. Hell, Eclipse is probably the most bloated Java IDE you could find, and it's only sometimes intolerable on a six-year-old laptop.
ObjC is basically Smalltalk weakened by some dangerous efficiency hacks we haven't needed for a decade.
ObjC is basically Smalltalk weakened by some dangerous efficiency hacks we haven't needed for a decade.
You know: my heart agrees with this, but over and over I see 'managed' systems exhibiting substantially longer startup times, unexpected and sometimes-long freezes, and often visibly lower performance.
Similarly, virtual memory backed by paging to a swapfile is the beautiful, "right" solution to me intuitively for a memory architecture that is made of several storage classes of highly different access times; yet, I have to admit that hourglasses/beachballs aren't a part of most "mobile" systems but often are — frustratingly — part of the desktop OS experience.
In actual practice, there's very little unchecked pointer arithmetic in a Cocoa [Touch] app — you don't access the elements of an NSDictionary via direct (to you) pointer arithmetic but through well-tested methods that fail similarly to how to out-of-bounds collection access fails in managed systems.
Anyway, it's unfortunate that such things are essentially non-comparable in a scientific way to my knowledge; but my experience of ObjC apps is not that they tend to be more crashy or likely to corrupt my data than the Java/C# apps that I also use day-to-day.
Similarly, virtual memory backed by paging to a swapfile is the beautiful, "right" solution to me intuitively for a memory architecture that is made of several storage classes of highly different access times; yet, I have to admit that hourglasses/beachballs aren't a part of most "mobile" systems but often are — frustratingly — part of the desktop OS experience.
In actual practice, there's very little unchecked pointer arithmetic in a Cocoa [Touch] app — you don't access the elements of an NSDictionary via direct (to you) pointer arithmetic but through well-tested methods that fail similarly to how to out-of-bounds collection access fails in managed systems.
Anyway, it's unfortunate that such things are essentially non-comparable in a scientific way to my knowledge; but my experience of ObjC apps is not that they tend to be more crashy or likely to corrupt my data than the Java/C# apps that I also use day-to-day.
we haven't needed for a decade.
Unfortunately, Smalltalk is basically dead to mainstream programmers (and the image concept never played well with others anyway), so their choice is between safety (Java) and better method dispatch (ObjC).
Reports of Smalltalk's demise are greatly exaggerated. Check out RoarVM - Squeak Smalltalk and it's derivatives now run on Tilera.
IBM and others are actively working on bringing Smalltalk into the future.
IBM and others are actively working on bringing Smalltalk into the future.
Why make such a comment? Being so short you can hardly add to the discussion. Being so sarcastic you add no more than a negation. To make a contribution whose tone is negative is both easy and galling. Strive, instead, to find the things which are worth saying.
Because it needs to be said. PHBs look at the iPhone and its success, and see that it uses ObjectiveC, and jump on the bandwagon. Someone who has actually used ObjectiveC and other languages needs to point out that Emperor Steve's new clothes were just stolen from a pantomime wardrobe in 1986.
You can make the same argument without detracting from it by adding unnecessary sarcasm. Your original comments says less than you imagine it did and is easily dismissed without consideration on the part of the reader.
Right, because sarcasm is soooo unnecessary.
http://blog.deliciousrobots.com/2010/11/27/sonys-changes-to-...