I thought reverse engineering the server protocol was perfectly legal.
In theory, yes. In practice, the DMCA can be used to squash interoperable implementations. Look at bnetd, for example. Despite it being a completely separate implementation of the protocol, Blizzard used the DMCA to successfully sue the project maintainers.
Although Apple has never officially acknowledged issues surrounding Yosemite and Wi-Fi connectivity, the company is clearly aware of the problem: Leading off the improvements offered in the update 10.10.2 update released Tuesday was 'resolves an issue that might cause Wi-Fi to disconnect,' according to the release notes.
So basically, you said that Apple haven't acknowledged the problem, then quoted them acknowledging the problem?
It is broke though. Look at the SendFile bug, for example. It's been there for years, it bites a tonne of people who try to virtualise web servers, and there has been seemingly no attempt whatsoever to fix it. Its kernel drivers on OS X and Linux aren't particularly stable either.
the functionality of the devices is about the same
It's very different. On Android, you have to decide whether to grant permission before you've ever run the application, and it's all or nothing. On iOS, you run the application before deciding whether or not to grant it permission. You have the ability to deny permission while still running the application. You can also allow permission for some things but not others.
This functionality is partially available to Android users who root their phones and install the right tools, but that's far from the common case.
It's true that the majority of the profits in App Store sales is focused at the extreme top, but it's not true that 99.999% of the rest make "near 0". This analysis estimates that the top 3,175 applications earn at least the average annual income for a US household per year, and applications that rank about number 6000 still earn $25K/yr.
And that's only counting App Store revenue. I've earned a lot more than average since I started developing for iOS, and most of the applications I've worked on are free. You don't see things like banking applications earn revenue directly, but the developers responsible certainly profit from it. The Facebook application is free, but you don't think its developers are working on it for free do you? I've been paid to built plenty of enterprise applications that will never appear in the App Store.
There is a huge amount of profit in the "app economy" that will never be accounted for merely by looking at App Store profits. The "app economy" is much bigger than the App Store.
It wasn't impossible to write cross platform browser stuff in the late 1990s, when most corporations started this whole "We'll standardize on browser X" policy making, but it required a discipline that had most developers throwing their hands up in the air in disgust.
I had these arguments many times back then. It was laziness more than anything else. We were writing cross-platform web applications without problems at that time. We were trying to convince other developers to follow the same route, but their attitude was mainly "IE has 90%+ market share, why bother?" They didn't believe a time would come when proprietary IE code wouldn't work - even if other browsers caught on, they were expecting them to copy the IEisms. They certainly didn't believe that even later versions of Internet Explorer wouldn't support their crappy code.
- IE4+ was the most standard. Yes, really. Those versions had a relatively complete implementation of CSS.
Let's not overstate things. Netscape bet on JSSS and when the W3C selected CSS as the standard instead, they scrambled to fix Netscape 4 to convert from CSS to JSSS on the fly. So Netscape 4 was exceptionally bad at CSS. Internet Explorer 4 was merely very bad at CSS. Opera was ahead at that time. I don't think you can call IE4 "relatively complete" unless you only compare it to Netscape 4, which was unusually bad.
he doesn't give a single example of any of that. He just makes the unsubstantiated claim.
Because the point of the blog post wasn't to prove that this was the case, but to offer an opinion on how bad it's gotten and why it may be happening. His audience is very familiar with Apple gear, spelling everything out from first principles is unnecessary and a distraction from the meat of the article. Know your audience.
I'm not complaining that you aren't being charitable. I'm pointing out that you misspoke then blamed me for it. If you misspoke, then own your words and just say "whoops, I didn't mean those guys" instead of looking for somebody else to shift blame to.
I'm talking about Facebook and Google, two of the companies explicitly listed in the article. You did RTFA right? Or are you one of those tards who manufactures the least charitable interpretation of what someone says and goes to town on them with a straw man?
The title of this submission: Google and Apple. The summary: Google and Apple. The article: Adobe, Apple, Facebook, Google and Yahoo. You said "both companies". Only two companies were singled out, Google and Apple. So yeah, to a reasonable person, it looks very much like you started off talking about Google and Apple, then expanded your point by talking about Facebook, and then to the other companies. Don't call me a "tard" because you fucked up what you were saying and I interpreted it in the most reasonable manner.
They are like google
The two companies have entirely different business models. Analytics is central to Google's business model. It's barely a blip on Apple's radar, and is insignificant compared with the way they use it as a differentiator.
Sure, Apple has business lines that generate income from hardware sales
That's so understated it's downright misrepresentative. They make billions of dollars a quarter from hardware sales. Even the amount of money they could theoretically make from analytics would be a drop in the bucket compared with that, let alone any earnings they might actually have. The potential chilling effect on their real business is far more relevant than any theoretical profits there. And you mention it like "oh yeah, they make money from hardware too"? Come on.
Both company's entire business models are 100% predicated on tracking people.
What are you talking about? Apple's business model revolves around selling people hardware. They've just launched a digital payment scheme with privacy being a major differentiator. If you think that Apple's business model is "100% predicated on tracking people", you don't know the first thing about their business model.
There is simply no way these companies will ever agree to not track anyone when there is that kind of money on the line.
Apple are positioning themselves to use privacy as a selling point. Their business model is entirely different to Google's and they can make more money by going in the opposite direction.
How is he throwing them under the bus? This isn't something they contest. They have already told the court they did this, because they were contractually obliged to do so by the record labels. All he's doing is supporting their version of events.
Apple does not want you to own and store your own music/media.
Take off your Apple blinders and think about this rationally. What you are saying doesn't resemble reality in the slightest. Apple have been the world's largest music retailer for years. They have been selling DRM-free music for years. They make billions of dollars a year doing this. They are clearly very, very happy to sell you music and they make a hell of a lot of money doing what you claim they don't want to do.
The proof will be in the pudding -- I wonder how usable it will be as a day to day tool for app developers and coding houses, especially with multiple people doing check-ins and such.
It's already in wide-scale use. Most Android developers I know have been using it for a while; it surpassed Eclipse a long time ago. It was unstable, sure, but Eclipse was a pain in the arse. Android Studio was purpose-built for Android development, and it really shows.
That's not to say it's perfect - it's slow in a lot of places, and the emulator is excruciatingly slow. But it's been quite a bit better than most of the alternatives for a while now.
what's the problem with the loss of the voting franchise?
Aside from the fact that it's fundamentally incompatible with democracy, wasn't a huge part of the American revolution the idea that there should be no taxation without representation? Those felons are taxpayers, aren't they?
even in cases where the extra length clarifies what's going on, you can do the same thing in other languages, i.e. every language supports use of meaningful names.
But Objective-C is very unusual in that it interleaves method parameters with the method name. The best alternative to that is using named parameters, and hardly anybody uses those all the time, so developers end up having to memorise the arguments and their order for every method if they want to be able to read code quickly.
Can you seriously argue that concatenating a string in Objective C is elegant?
No, but it is consistent, and that's very important to readability and maintainability too. If you knew nothing about NSString, but you were familiar with the rest of Objective-C, then you could easily guess how to concatenate strings.
The only substantial way of improving on string concatenation in Objective-C would be to introduce custom operators, and that brings its own set of issues. The other alternatives sacrifice consistency.
You don't have to be a fanboy to like Objective-C. It's a great language for its age and use cases. Yes, it's verbose, but a lot of that verbosity actually aids readability and maintainability.
A computer scientist can implement any algorithm in any language.
Just because it's possible, it doesn't mean it's effective. Developers could write applications with Brainfuck or Whitespace, but they'd take far longer, have a lot more bugs, and be incredibly unhappy.
There's a lot of variation between programming languages, and it makes a big difference in how productive programmers are. Better programming languages are valuable.
Why are these companies using their own languages?
Because they saw an opportunity to provide better tools for their developers. Take a look at the bridges between Objective-C and other languages. They are pretty clumsy. Apple designed Swift with Objective-C interoperability in mind, and this means using the system libraries is easier with Swift than other languages.
Work a few years at XYZ company working on their proprietary algorithms in their ABC programming language?
Good luck getting another job.
All of the decent developers I know can make those kinds of leaps without a problem.
There are always transferrable skills and there are always non-transferrable skills. Using one language doesn't lock developers into that language in the future, and using a common language doesn't avoid lock in. If iOS developers used Java, they'd still struggle with Android development at first because the majority of the knowledge you need relates to the platform, not the language. And likewise, just because iOS developers work with Objective-C, it doesn't mean they can't make the leap to Android.
Oh stop being so overdramatic. If you don't want an application to know your location, then tap "No" when you are asked for your permission. Or simply don't install the application. Applications can't access your location without your explicit consent. Nothing nefarious is happening here.
Are you willing to let Starbucks decide how much they can peek at your location data without even knowing if/when it's happening?
iOS doesn't let you do that. It differentiates between looking up the user's location when the application is in the foreground (i.e. what this application needs to find your nearest store when preordering), and tracking the user's location when it's running in the background. The user has to explicitly grant permission to the application to do each of these things.
I'm actually working on a similar application for one of their competitors right now. Yes, we ask for the user's location. Yes, it's to find the nearest store. No we can't track you. And to be frank, it's ridiculous to think that we would care enough to do this. The people who commission these applications want to sell you coffee, not stalk you.
would you resist the temptation and never once peek at other times?
Except it's not a case of "peeking". You've actually got to build a considerable amount of infrastructure to track people. Even if they ask for and obtain the user's permission to track them in the background, that doesn't magically create servers to record this data and user interfaces to look people up. Do you expect the marketing manager to convince her bosses to drop another 100K on building this functionality because she's nosy? There has to be a business case for it to be built.
You can't realistically do iOS development without knowing Objective-C; its just no feasible since all Apples frameworks are written in it, all the open source libraries use it, and all of the stackflow answers are for it.
This isn't the case. It doesn't matter whether a framework is written in Objective-C or Swift, you can use it from either language regardless. You can write an application from start to finish in Swift without needing to know anything about Objective-C. Sure, if you do know it, then it may be easier, but not so much easier that it will outweigh trying to learn two languages at once.
No, when people hire iOS developers, the first question they ask is if you have any applications in the App Store, then they want to know where you've worked, then they want to see your code, and if you haven't got anything else, then a degree is the last resort you have. Spending your time building applications and putting them on the App Store is far more effective for getting a job than spending that time getting formal education in computer science. Even when you come across the rare organisation that demands a degree, they usually don't care about what subject it was in.
As far as I can tell, Swift is just a new front-end to the Objective-C object system.
No, that's not true. Swift interoperates with Objective-C, but it's not any kind of front-end to it, it works perfectly fine by itself.
most of the libraries and frameworks you will be working with are Objective-C
Most of the libraries and frameworks you will be working with are system components where you don't see the source code. Whether they are implemented in Objective-C or Swift is an implementation detail you don't need to care about.
Slashdot Mirror
In theory, yes. In practice, the DMCA can be used to squash interoperable implementations. Look at bnetd, for example. Despite it being a completely separate implementation of the protocol, Blizzard used the DMCA to successfully sue the project maintainers.
So basically, you said that Apple haven't acknowledged the problem, then quoted them acknowledging the problem?
It is broke though. Look at the SendFile bug, for example. It's been there for years, it bites a tonne of people who try to virtualise web servers, and there has been seemingly no attempt whatsoever to fix it. Its kernel drivers on OS X and Linux aren't particularly stable either.
It's very different. On Android, you have to decide whether to grant permission before you've ever run the application, and it's all or nothing. On iOS, you run the application before deciding whether or not to grant it permission. You have the ability to deny permission while still running the application. You can also allow permission for some things but not others.
This functionality is partially available to Android users who root their phones and install the right tools, but that's far from the common case.
It's true that the majority of the profits in App Store sales is focused at the extreme top, but it's not true that 99.999% of the rest make "near 0". This analysis estimates that the top 3,175 applications earn at least the average annual income for a US household per year, and applications that rank about number 6000 still earn $25K/yr.
And that's only counting App Store revenue. I've earned a lot more than average since I started developing for iOS, and most of the applications I've worked on are free. You don't see things like banking applications earn revenue directly, but the developers responsible certainly profit from it. The Facebook application is free, but you don't think its developers are working on it for free do you? I've been paid to built plenty of enterprise applications that will never appear in the App Store.
There is a huge amount of profit in the "app economy" that will never be accounted for merely by looking at App Store profits. The "app economy" is much bigger than the App Store.
I had these arguments many times back then. It was laziness more than anything else. We were writing cross-platform web applications without problems at that time. We were trying to convince other developers to follow the same route, but their attitude was mainly "IE has 90%+ market share, why bother?" They didn't believe a time would come when proprietary IE code wouldn't work - even if other browsers caught on, they were expecting them to copy the IEisms. They certainly didn't believe that even later versions of Internet Explorer wouldn't support their crappy code.
Let's not overstate things. Netscape bet on JSSS and when the W3C selected CSS as the standard instead, they scrambled to fix Netscape 4 to convert from CSS to JSSS on the fly. So Netscape 4 was exceptionally bad at CSS. Internet Explorer 4 was merely very bad at CSS. Opera was ahead at that time. I don't think you can call IE4 "relatively complete" unless you only compare it to Netscape 4, which was unusually bad.
Just because reverse engineering is legal, it doesn't mean WhatsApp are legally obligated to provide their services to third-party clients.
The legal matter here is the blatant trademark infringement by WhatsApp Plus.
It's already widespread. Several billion iMessages are sent per day.
Because the point of the blog post wasn't to prove that this was the case, but to offer an opinion on how bad it's gotten and why it may be happening. His audience is very familiar with Apple gear, spelling everything out from first principles is unnecessary and a distraction from the meat of the article. Know your audience.
This isn't true. This was a bug that has already been fixed.
I'm not complaining that you aren't being charitable. I'm pointing out that you misspoke then blamed me for it. If you misspoke, then own your words and just say "whoops, I didn't mean those guys" instead of looking for somebody else to shift blame to.
The title of this submission: Google and Apple. The summary: Google and Apple. The article: Adobe, Apple, Facebook, Google and Yahoo. You said "both companies". Only two companies were singled out, Google and Apple. So yeah, to a reasonable person, it looks very much like you started off talking about Google and Apple, then expanded your point by talking about Facebook, and then to the other companies. Don't call me a "tard" because you fucked up what you were saying and I interpreted it in the most reasonable manner.
The two companies have entirely different business models. Analytics is central to Google's business model. It's barely a blip on Apple's radar, and is insignificant compared with the way they use it as a differentiator.
That's so understated it's downright misrepresentative. They make billions of dollars a quarter from hardware sales. Even the amount of money they could theoretically make from analytics would be a drop in the bucket compared with that, let alone any earnings they might actually have. The potential chilling effect on their real business is far more relevant than any theoretical profits there. And you mention it like "oh yeah, they make money from hardware too"? Come on.
What are you talking about? Apple's business model revolves around selling people hardware. They've just launched a digital payment scheme with privacy being a major differentiator. If you think that Apple's business model is "100% predicated on tracking people", you don't know the first thing about their business model.
Apple are positioning themselves to use privacy as a selling point. Their business model is entirely different to Google's and they can make more money by going in the opposite direction.
How is he throwing them under the bus? This isn't something they contest. They have already told the court they did this, because they were contractually obliged to do so by the record labels. All he's doing is supporting their version of events.
Take off your Apple blinders and think about this rationally. What you are saying doesn't resemble reality in the slightest. Apple have been the world's largest music retailer for years. They have been selling DRM-free music for years. They make billions of dollars a year doing this. They are clearly very, very happy to sell you music and they make a hell of a lot of money doing what you claim they don't want to do.
It's already in wide-scale use. Most Android developers I know have been using it for a while; it surpassed Eclipse a long time ago. It was unstable, sure, but Eclipse was a pain in the arse. Android Studio was purpose-built for Android development, and it really shows.
That's not to say it's perfect - it's slow in a lot of places, and the emulator is excruciatingly slow. But it's been quite a bit better than most of the alternatives for a while now.
Aside from the fact that it's fundamentally incompatible with democracy, wasn't a huge part of the American revolution the idea that there should be no taxation without representation? Those felons are taxpayers, aren't they?
But Objective-C is very unusual in that it interleaves method parameters with the method name. The best alternative to that is using named parameters, and hardly anybody uses those all the time, so developers end up having to memorise the arguments and their order for every method if they want to be able to read code quickly.
No, but it is consistent, and that's very important to readability and maintainability too. If you knew nothing about NSString, but you were familiar with the rest of Objective-C, then you could easily guess how to concatenate strings.
The only substantial way of improving on string concatenation in Objective-C would be to introduce custom operators, and that brings its own set of issues. The other alternatives sacrifice consistency.
You don't have to be a fanboy to like Objective-C. It's a great language for its age and use cases. Yes, it's verbose, but a lot of that verbosity actually aids readability and maintainability.
Just because it's possible, it doesn't mean it's effective. Developers could write applications with Brainfuck or Whitespace, but they'd take far longer, have a lot more bugs, and be incredibly unhappy.
There's a lot of variation between programming languages, and it makes a big difference in how productive programmers are. Better programming languages are valuable.
Because they saw an opportunity to provide better tools for their developers. Take a look at the bridges between Objective-C and other languages. They are pretty clumsy. Apple designed Swift with Objective-C interoperability in mind, and this means using the system libraries is easier with Swift than other languages.
All of the decent developers I know can make those kinds of leaps without a problem. There are always transferrable skills and there are always non-transferrable skills. Using one language doesn't lock developers into that language in the future, and using a common language doesn't avoid lock in. If iOS developers used Java, they'd still struggle with Android development at first because the majority of the knowledge you need relates to the platform, not the language. And likewise, just because iOS developers work with Objective-C, it doesn't mean they can't make the leap to Android.
The whole point of this is that you place your order before you arrive at the store. The user wouldn't normally be in range of the Wi-Fi network.
Oh stop being so overdramatic. If you don't want an application to know your location, then tap "No" when you are asked for your permission. Or simply don't install the application. Applications can't access your location without your explicit consent. Nothing nefarious is happening here.
iOS doesn't let you do that. It differentiates between looking up the user's location when the application is in the foreground (i.e. what this application needs to find your nearest store when preordering), and tracking the user's location when it's running in the background. The user has to explicitly grant permission to the application to do each of these things.
I'm actually working on a similar application for one of their competitors right now. Yes, we ask for the user's location. Yes, it's to find the nearest store. No we can't track you. And to be frank, it's ridiculous to think that we would care enough to do this. The people who commission these applications want to sell you coffee, not stalk you.
Except it's not a case of "peeking". You've actually got to build a considerable amount of infrastructure to track people. Even if they ask for and obtain the user's permission to track them in the background, that doesn't magically create servers to record this data and user interfaces to look people up. Do you expect the marketing manager to convince her bosses to drop another 100K on building this functionality because she's nosy? There has to be a business case for it to be built.
This isn't the case. It doesn't matter whether a framework is written in Objective-C or Swift, you can use it from either language regardless. You can write an application from start to finish in Swift without needing to know anything about Objective-C. Sure, if you do know it, then it may be easier, but not so much easier that it will outweigh trying to learn two languages at once.
No, when people hire iOS developers, the first question they ask is if you have any applications in the App Store, then they want to know where you've worked, then they want to see your code, and if you haven't got anything else, then a degree is the last resort you have. Spending your time building applications and putting them on the App Store is far more effective for getting a job than spending that time getting formal education in computer science. Even when you come across the rare organisation that demands a degree, they usually don't care about what subject it was in.
As far as I can tell, Swift is just a new front-end to the Objective-C object system.
No, that's not true. Swift interoperates with Objective-C, but it's not any kind of front-end to it, it works perfectly fine by itself.
Most of the libraries and frameworks you will be working with are system components where you don't see the source code. Whether they are implemented in Objective-C or Swift is an implementation detail you don't need to care about.