steven n.

bkkcanuck said:

macplusplus said:

bkkcanuck said:

I disagree with the Federal Court.  

API is just the interface (e.g. add(operand1, operand2) - i.e. no implementation to that - and implementation is basically 99%+ of the code).

Being able to use an API for compatibility purposes is no different than for example Open Office being able to implement the file format for Word.  The need for competition outweighs the argument as an API protected IP.   Google's implementation uses the API (common) and then the implementation code which is probably more than 99% of the code base.  As long as Google did not copy the code itself the API itself should be fair use.  Languages and APIs should not be able to be protected as API.  

The court has already previously ruled that you cannot protect interfaces for hardware for the purposes of locking out the competition on things like printer cartridges etc.  An API is not much different than the software equivalent.  

API is not just the interface, it is everything. You can build some library this way or that way, what distinguishes your IP protected work is how you design your libraries. You are not obligated to replicate the exact libraries Oracle has built; write your own functions and collect them in your own libraries to build your unique IP protected API. That is the whole point of the lawsuit. Oracle is right.

If the API is protectable then there is a whole lot of stuff that is suddenly a violation of IP.  All sorts of emulators, Wine for Linux (which is used in other projects), any applications that translate language and APIs into C or C++ etc.  A language and the standard library API are inseparable.   Maybe I date too far back, but as far as I am concerned this change is really really bad.  One project I know of started with a huge code base in VB and started its life as language translation from VB into Java - this ruling would make the writing of that language translator illegal since the code would be implementing the parsing of protected API and language IP.

bitmod said:

sflocal said:

bitmod said:

Smoke and mirrors. 
The FBI may not have keys - but the NSA has a back door to not only snoop but turn your mic and camera on at any time without you knowing. 
The same backdoor Apple uses to sell your info to advertisers. 

Don't believe me? try it yourself: Without having any phone or iPad on - start talking about a product: "honey, do we have any Tylenol?" "I think we are out of Tylenol", "Who in town sells Tylenol"... then watch as mysteriously your Facebook ads and cookies throw Tylenol ads at you. 

The reason battery life is worse in iOS 11 is because our devices are always listening. 

Try it yourself. We've seen it with 4 random products now - too much to be a coincidence. 
Also, everything and anything you text to someone is read and sold to advertisers. Text someone you are thinking of taking a vacation to Hawaii and watch as your ads start sending you Airbnb for Hawaii. 

The crazy thing is, we are furthest thing from conspiracy theorists - and we set out to prove this wrong... yet the results done lie. 

To think that there are people in real life that think the way you do.  Seriously.  Go get some help.

Hate to shatter the tiny bubble you live in man, but PRISM is real. Patriot Act is real. Obama's blanket surveillance on citizens is real. 

http://appleinsider.com/articles/15/01/21/nsa-leaker-edward-snowden-refuses-to-use-apples-iphone-over-spying-concerns---report
https://theintercept.com/2016/03/08/snowden-fbi-claim-that-only-apple-can-unlock-phone-is-bullshit/
http://www.newsweek.com/edward-snowden-cautions-about-face-data-abuse-664131

This guy has been right about everything so far. Congressional reviews seem to back it all up. 

To think that there are people in real life that deny the truth the way you do. Seriously. Go get some help. 

volcan said:

steven n. said:

It will be great for doing builds. We work on multiple large projects (1 to 5 million SLOC) all compiled using command line tools and we are not allowed to use threaded compiling with the "-j" option in make. A single release might require anywhere from 6-10 unique compiles. While I always have multiple command lines open running the different compiles for each project, It will be great to cut the time in half.

How many cores does your command line compiler use. If it is just one then the regular iMac might be faster than the iMac Pro because the multi-core Xeons are usually clocked slower.

genovelle said:

Soli said:

alandail said:

Soli said:

vukasika said:

Q: Is encryption legal?
A: Yes.
End of discussion.

True, but this isn't that discussion. Apple has been served a warrant so they'll hand over all data they can access, in accordance with the warrant.

if it's encrypted, Apple can't provide without the keys, which they can't access by design.  Making the keys accessible defeats the purpose of encrypting the files in the first place.

That's the device encryption. If they can't can't access it then they just have to make that an official statement to them, but this is also about his iCloud account, which may not have unbreakable account encryption on their servers as this is inherently different from iDevice HW encryption. Even if it is unbreakable, they just need to state that and explain why. It's a warrant, so I'm not sure why you're focused on the legality of encryption but ignoring the legally of warrants.

Also note that Apple tried to assist them right away, so there's no reason to suspect that Apple will not try to assist them now. If his iCloud account was accessible I'm sure they already have the data waiting for them.

Soli said:

alandail said:

Soli said:

vukasika said:

Q: Is encryption legal?
A: Yes.
End of discussion.

True, but this isn't that discussion. Apple has been served a warrant so they'll hand over all data they can access, in accordance with the warrant.

if it's encrypted, Apple can't provide without the keys, which they can't access by design.  Making the keys accessible defeats the purpose of encrypting the files in the first place.

That's the device encryption. If they can't can't access it then they just have to make that an official statement to them, but this is also about his iCloud account, which may not have unbreakable account encryption on their servers as this is inherently different from iDevice HW encryption. Even if it is unbreakable, they just need to state that and explain why. It's a warrant, so I'm not sure why you're focused on the legality of encryption but ignoring the legally of warrants.

Also note that Apple tried to assist them right away, so there's no reason to suspect that Apple will not try to assist them now. If his iCloud account was accessible I'm sure they already have the data waiting for them.

Soli said:

alandail said:

Soli said:

vukasika said:

Q: Is encryption legal?
A: Yes.
End of discussion.

True, but this isn't that discussion. Apple has been served a warrant so they'll hand over all data they can access, in accordance with the warrant.

if it's encrypted, Apple can't provide without the keys, which they can't access by design.  Making the keys accessible defeats the purpose of encrypting the files in the first place.

That's the device encryption. If they can't can't access it then they just have to make that an official statement to them, but this is also about his iCloud account, which may not have unbreakable account encryption on their servers as this is inherently different from iDevice HW encryption. Even if it is unbreakable, they just need to state that and explain why. It's a warrant, so I'm not sure why you're focused on the legality of encryption but ignoring the legally of warrants.

Also note that Apple tried to assist them right away, so there's no reason to suspect that Apple will not try to assist them now. If his iCloud account was accessible I'm sure they already have the data waiting for them.

The warrant makes no sense. It has been well documented and I’m sure Apple told them they can’t access the phone, so why even make such a legal request when it is moot. The only possible reason is deflection.