The only thing that has doubled down here is the marketing of the fact they are contributing to open source. They have both been large users and contributors to open source since the switch to OS X (NeXT acquisition).
Just off the top of my head, projects they have had a large hand in: WebKit & JavaScriptCore, Objective-C, CUPS, LLVM, Clang, Bonjour/Zeroconf, Darwin, launchd, libdispatch, CoreFoundation, dtrace.
And more recently Apple Lossless Encoder, LZFSE compression, and of course Swift.
And this is only a tiny fraction of what they are users of.
It would be nice if some of their contributions were less "throw it over the wall once or twice a year".
It would be nicer still if they stopped thinking their browser only needs to get new features once per year. Safari is rapidly getting a reputation as the new IE6. Fully supporting ES6 means nothing when everything is being transpiled and minified anyway, and the (arguably) dominant mobile browser your (kinda) forced to target doesn't support features that shipped in every other browser years ago, heck many missing features have even stabilised in other browsers years ago. The dev builds on desktop are just a token gesture that further displays how far behind the times WebKit/Safari/MobileSafari are falling.
Here are just a few things not supported in any Apple browser, Including the "Technology Preview" on desktop:
CSS Motion Path;
CSS Device Adaptation;
Client Hints: DPR, Width, Viewport-Width;
inputmode attribute;
MediaRecorder API;
Network Information API;
Web Animations API;
Pointer events;
Web App Manifest;
seamless attribute for iframes;
Payment Request API;
Credential Management API;
Push API;
FIDO U2F API;
Permissions API;
Screen Orientation;
Object RTC (ORTC) API for WebRTC;
Proximity API;
Ambient Light API;
Battery Status API;
Vibration API;
Web MIDI API;
getUserMedia/Stream API;
WebAssembly;
'SameSite' cookie attribute;
Public Key Pinning;
XHTML+SMIL animation;
This looked like a pretty long list of unsupported APIs, so I decided to do some research:
- CSS motion path is not an official standard; it is implemented only in Blink (Chrome/Opera).
- CSS device adaptation is a W3C working draft. It is available prefixed in IE/Edge and Opera Mini, but is unprefixed in 0% of shipping browsers.
- Client Hints: DPR, Width, Viewport-Width is an IETF working draft implemented only in Blink (Chrome/Opera).
- inputmode is supported in 0% of shipping browsers.
- MediaRecorder API is a W3C working draft supported in Blink (Chrome/Opera) and Firefox but not IE/Edge or Safari.
- Network Information API is not an official standard; it is supported only in Chrome for Android.
(Source: caniuse.com)
I stopped going through the list at this point. At least from the top of your list, none of these features are "shipped in every other browser" and some are shipped in no browsers at all. I'm not sure how it shows that Safari is "far behind the times."
If anything, the list seems to show that Chrome implements many non-standard APIs not available elsewhere. Combined with its mindshare (if not marketshare), this suggests that Chrome--not Safari--is in some ways the new IE6.
This is exactly what tons of WebKit/Safari haters do — troll through the literally 100s of proposed standards (admittedly sometimes W3C but still) and rile up comment sections w/this false trope astroturfing for half-baked technologies.
It's usually because they had some pet project / approach relying on the "standard" that they couldn't run right in MobileSafari, even though it had no adoption whatsoever, Cupertino is DESTROYING the web for not including it, battery life, privacy, reasonable userspace restrictions, etc BE DAMNED.
I'd edit my post to remove the items that aren't standard or even working drafts yet, but unfortunately the time window has passed so I can't now.
But I can't agree that Chrome is in any way the new IE6. Chrome is actively participating in the public view in the process of web standards. Apple seems to 'participate' insofar as they are on lists of participating companies. Apple pretty much adds just one batch of features per year, and does so through a completely opaque process that outside developers are almost completely irrelevant to. Chrome at least listens to outside opinions, while one of the defining traits of the IE6 years was having to work under the umbrella of a "we don't care, just use what we gave you" attitude from the IE6 developers.
Also, the fact I had to open chrome in order to post this comment to HN is an amusing addition to this little "how broken is the web" discussion.
I suspect the reason gp included the IE6 comparison at all was in response to yours, after looking into ES6 support across browsers for features you specifically called out, which I think is fair to do.
As for opening Chrome to post your comment, are you having issues with other browsers when you do so? I generally use Safari in Mac OS X and iOS without a problem.
Web Developers use common lowest denominator with is IE8-IE9 for public facing projects and IE11 for internal...
Your Safari will work just fine, but it is still behind Firefox or Chrome [0]. I am not saying that Safari is new IE because we will struggle with IE11 for years to come.
Before Safari 10 ES6 was supported in 54% then in Safari 10 is 100%. This is wrong approach to web, it is the same approach that MS had in the past. Ignore standards and make some improvement with new version for bragging rights.
> Before Safari 10 ES6 was supported in 54% then in Safari 10 is 100%. This is wrong approach to web, it is the same approach that MS had in the past. Ignore standards and make some improvement with new version for bragging rights.
How is implementing some of a standard, and then completing work to implement 100% of that standard "ignoring standards"?
ggp: Also, the fact I had to open chrome in order to post this comment to HN is an amusing addition to this little "how broken is the web" discussion.
gp: As for opening Chrome to post your comment, are you having issues with other browsers when you do so? I generally use Safari in Mac OS X and iOS without a problem.
My comment on using Safari is in response to ggp saying Chrome was necessary to post to HN, not about general use or for development. Or am I misreading ggp?
"Safari is rapidly getting a reputation as the new IE6."
And that is just a ridiculous comparison done by people who have never witnessed that period or are having a different agenda.
One of my first jobs (more then a decade ago) as a young developer was being a web developer for an American/Belgian e-commerce site. One of the things that was very important - because every customer counts - that the site displayed and worked perfectly in any browser (IE6, FF/Mozilla, Safari and Opera at the time)
That was a situation that wasn't a lot of fun because you had standard HTML that more or less worked in any browser with the exception of IE6. There where a lot of moments that I really hated my job because of the frustrations that IE6 often brought to the table. That is in no way comparable with Safari today.
And while I would like to have Apple more rapidly implementing new API's, with IE we could only dream of having an IE version that got new features every year. Years have we have witnessed the fallout of IE6, that will never be the case with Safari to this day.
IE6 was a vehicle to create an internet that only worked with Microsoft standards so that others couldn't be a valid alternative hence the IE6 markup vs the rest. You can't do that by dragging your feet when implementing API's, you only price yourself out of the market in that way.
I have lived through those awful IE6 times and imho Safari is the new PITA of web development. Nowadays you don't have to create workarounds for CSS problems or same JS incompatibilities, Safari sucks at implementing even the most basic HTML5 APIs.
It is like with CSS 10 years ago. This nice new CSS feature (HTML5 API) which would perfectly solve your problem? Sorry you can't use it because IE (Safari) does not support it (maybe never will).
> Safari sucks at implementing even the most basic HTML5 APIs
Would you care to give some examples?
The last time this played out on HN, the list of unsupported things was not HTML5, and many were unfinished/unstable, or listed as in-progress by the WebKit team.
It was never enabled in any of the Apple-owned ports of WebKit, IIRC it was enabled in the GTK and Qt ports, but I could be wrong there. So Apple killing it isn't really true—they're just deleting code that was already gone at compile-time for them.
It would be nicer still if they stopped thinking their browser only needs to get new features once per year. Safari is rapidly getting a reputation as the new IE6.
-----------------
To be fair, they had a 9.1 release this year, which included:
Picture element support
So if they do this again, we're looking more at 6 month cycles.
The whole safari is the new IE6 stuff is hyperbole which I don't actually hear that many developers saying..
IE6 was bad because it didn't follow any standards, not because it updated slower than the competition.
All the ones I listed are the ones where they are significant contributors.
The much larger set of where they are mostly users, like the BSD userland tools, curl, Python, Perl, Tcl, Ruby, and so forth, I omitted. There are just too many.
LLVM/Clang and Grand Central Dispatch comes to mind. The MAC framwork is also a shared effort, but I don't know who is doing the heavy lifting. It's something.
And which of these are actually developed with an open source model instead of merely throwing code over the wall months after the official binaries have been released?
I know from personal experience that at least LLVM, Clang, Swift, and WebKit/JavaScriptCore have daily activity and also include non-Apple commit reviewers.
I also suspect CUPS remains pretty active. CUPS (Common Unix Printing System) started a long time ago and is used by pretty much all the Unix platforms. Apple bought the project in 2007. The license remains GPL2/LGPL2 and all the platforms still use it as far as I know.
The open sourcing of Swift was very beneficial. The project moved extremely fast the last years with lots of outside input and interest. I think this shows when OS works best: When it is not done out of obligation (or ideology), but because it can be useful as a tool.
If they are "doubling down on open source", maybe they could get open source Darwin working again? From what I've heard, while they still release some of the source code, it is no longer in a form in which it can easily be compiled into a usable operating system – e.g. some of the components they release source for can't even be built because they rely on unreleased Apple private header files – basically, things have gone backwards on this front compared to earlier versions of OS X.
(From what I've heard, I don't know how true it is, Apple became less open with Darwin, around the time of the PPC-Intel transition, out of fear it was making life easier for people trying to use OS X on non-Apple hardware easier.)
I can think of one use. Suppose I am developing something non-GUI (e.g. a database, an application server, a compiler or interpreter for some programming language, etc.) While macOS is unlikely to be the production deployment platform, getting it running on macOS will make some developers happier (yes, they can always use a VM or Docker to run the Linux version, but running a native macOS version has its advantages.)
So, now I have a non-GUI app for (among other platforms) macOS, I want a build machine for compilation and automated tests. Ideally just a VM somewhere (maybe even in the cloud). To legally run macOS in such a way, it needs to run on Apple hardware, which adds expense and complexity. However, I could run a Darwin VM legally on any hardware. Now of course, Darwin isn't quite macOS, but for a non-GUI app it might be close enough (depending on exactly which APIs it uses and whether those APIs fall into the open source Darwin subset).
Is that a particularly common use case? Probably not. But there probably are multiple open source projects and maybe even some proprietary software packages for which that use case would exist.
I'm not sure if the problem is Apple or a lack of interest and community.
I'd definitely be up to trying to build it sometime in the future. I'm a little busy at the moment. I'd expect it to take a few days at least based on my experience with Linux from scratch.
But it sends requests to Google servers, always. It's cool that its lightweight, but not like this.
I flagged the post because it downloads a file of obscure, unstandardized format designed to send tracking information to Google.
It should at least have an [AMP] tag like other "non-HTML file format" posts do.
Edit: I'm sorry if my post comes across as needlessly hostile, any hostility is only directed at the AMP situation. AMP seems very much deliberately designed as an attractive way to get webdesigners to let Google to track more consumers. What the hell is with people excusing the fact that each and every AMP page makes requests to Google servers, as defined by the "standard"?
I think it's up to the author to decide where they host. Just curious: Would you complain the same way if it was google sites based, but using author's domain? Why/why not?
Also, I don't think every page makes requests to google. All the ones I see go to a CDN (one designed for AMP, sure). So standard caching applies. But again, author's choice - are other CDNs any better?
This is an attempt to standardize the tracking of users hosted on every site not hosted by Google. I do think its up to the author to decide where they host and this MUST include the page's dependencies!
I don't mean they can't have 3rd party dependencies, but no specific 3rd party should be required, especially if they don't support graceful degradation in the case where the 3rd party is unreachable.
And on the CDN, it's run by Google, just read the whois data:
AMP requires a script loaded from one particular URL and is designed so that it's incompatible with browsers that don't support Javascript, i.e. <img> tags are replaced by <amp-img> and thus images won't work without the AMP script.
It might formally be a subset of HTML but it is one that excludes non-JS-supporting user agents by means of custom tags which are interpreted by "the AMP engine" script.
Most sites already use countless tracking/social integrations so I don't consider this particularly harmful.
At least the AMP link limits my exposure to Google hosted static files instead of the usual (according to uBlock on the "normal" link) Facebook, Twitter, Google Analytics, Optimizely, CNET, Adobe, Taboola, CBS, Tealium, Soasta, Netseer and ShareThrough.
In the case of most sites I can block all that crap.
If it's an AMP page, I can't just block the AMP script because it does not gracefully degrade. It's having a broken page until HyperGoogleTextEngine loads.
Yeah, like many, they pretend they're doing FOSS while dropping the (F)reedom part.
GPLv3 is about stopping TIVO-isation, but TIVO tactics is what Apple specializes in.
Locking people in with other people's (F)ree software.
The sad part is that GPLv3 is just fine for all (F)OSS project. But to them, it's about making sure their project governance can never really be moved to a more neutral foundation if they ever feel the need to put all their energy behind one project and close it down again... The "freedom" to take away freedom from others isn't one.
A bit like how Android 3.x was code-dumped after the fact, when 4 came out... Open you say?
And yes, non-copyleft would work as well, and I have nothing against them a priori, but that's as long as the governance model is built around neutral foundations, proper community management, etc.
What the GPL does, is prevent the imbalance when a company decide it doesn't care about the community around a project because they have the bigger share and run with it.
I would understand more discussions around AGPLv3, but GPLv3 is just fine.
(On a side note, I'm always fascinated by the GPL bashing here... well... I guess it is expected considering money > freedom for some who can't think passed their project's legacy.)
Yeah, this should not be a surprise to anyone who's been paying attention for the last 10 years. GPLv3 was incredibly divisive, both inside and outside the open source community.
Admittedly, for some people this may have been part of its intent- to draw more lines in the sand, to force out those that the FSF deems as having insufficient ideological purity. The FSF doesn't shy away from calling out its enemies- to my eyes, over the decades it has been far more concerned with condemning what it perceives as being evil, rather than promotion of what it perceives as being good.
Oh yeah, it was totally it's goal and I don't begrudge them that.
The problem is that by v3 the GPL was so ingrained as THE OSS license that many projects and devs just used v3 out of habit.
Now for some they may be fine with it, and that's cool, but I think it's telling that we've seen a resurgence of MIT, Apache, Mozilla, LGPL, and BSD licenses.
GPLv3 has been extremely damaging to OSS, intentionally or not, as companies associate OSS with it - which is a shame.
> The problem is that by v3 the GPL was so ingrained as THE OSS license that many projects and devs just used v3 out of habit.
As Stallman would point out, GPL is Free Software, not OSS.
> GPLv3 has been extremely damaging to OSS, intentionally or not, as companies associate OSS with it - which is a shame.
If companies really want to continue shipping crapware locked-down IoT and ARM systems they can pay for the development of the software themselves. Since it is effectively impossible to run your own Linux distribution on the vast majority of Android devices, contributing ARM-related Linux code as a hobbyist is literally working for Google/phone manufacturers for free. Stallman did not start GNU so you could sit on your Macbook writing ad-tech apps to deploy to AWS and the Google Play Store.
I think a lot of this is a result of probably not being able to recruit top talent as easily as companies who have "opened up".
1) Many people at top of the talent pool know that the internet makes it possible for them to not only make huge differences at companies they work for, but they can also (if allowed) make enormous differences to the entire world. If they don't have to compromise their free time in order to do that, it's an enormous benefit.
2) The people a company like Apple wants to hire are interviewing the company just as thoroughly as they are interviewing the candidate. If the candidate has not already seen a large portfolio of their work there's no real guarantee (even if you're Apple) that you can convince them that they'll be working on amazing teams with amazing engineers.
3) When you're at the top of the talent pool your goals and incentive structure are almost certainly not tied directly to compensation. Of course you want to be compensated fairly, but when it comes down to it you're passionate about what you do, and as a consequence you've become great at what you do. You generally don't become the best at something because you believe it will compensate you better.
They could start with making sure atleast major Linux distros work fine on Apple desktop and laptop hardware.
It would most likely be hw specific quirks and drivers given most of the hardware they use is standard and already supported by Linux. (With Intel building in their Wi-Fi chips even Broadcom wireless stuff won't be an issue.)
That project looks dead, but essentially, it would be XNU paired with GNU, operating similarly to Linux (Though you'd still end up with MACH-O binaries instead of ELF). Honestly though, I find the Unix inside Apple to be more than enough for my general needs, and VMs step in where it is not.
Also, iTerm2 is still better than anything I've used in Linux. I work in both Linux and macOS every day, Mac is still a better experience.
Well most of Apple's servers and services run on Linux and there is clearly a demand for Linux laptops from developers. If Apple has to be friendly with OSS supporting Linux will take them a long way - good for developers including Apple's own services/infrastructure folk, broadens up the Workstation market again for Apple etc.
Doubling down on Open Source is not really doubling down if you just continue to dump code on github.
I think your definition of open source is much different than mine. Requiring cooperation or interaction with the community is very GNU / GPL mindset, not BSD. Many of us are perfectly OK with code drops.
Because only Apple knows best about their hardware and there's a market for that. Apple also support Windows via Boot Camp - without that Windows would not be any more functional than say Ubuntu. It isn't like we are talking about full Linux port to their hardware - Apple's hardware deviates from standards for example - Linux people don't really have a way of knowing that. Only Apple could provide the glue required to enable those type of things.
Apple also is about creating new markets. They have so far consistently supported Windows too and that's also a market now - it wasn't so in the beginning.
What? Windows was huge even before macOS so supporting it was a good choice. On other hand how many people will buy MacBook just to install Linux? Where you can literally make the same things on macOS if you don't remember it's still good old UNIX system?
Making changes to support few hundred or fewer users who want Linux in a “nice package” is shooting itself in the foot. From a business perspective it simply does not pay. And what is Apple? Big money-oriented business. If you have a business and want to please everyone you will fall, it's just that simple.
They make money on users who don't even know what Finder is and rest so called “pros” should just don't give a fuck and use it as they usually do...
Let them start supporting free codecs and stop patent aggression, as well as allow FOSS (including other browsers) in their application store. Then we'll see how much they are friends of open source or not.
Oh, and you can add to that support for Vulkan on their platforms.
The problem is that Apple imposes restrictions on the use of apps, even if the app developers themselves don't want to. For example, did you know you can't use your iPhone apps for non-personal, commercials purposes? That means that legally, if you use any app for "any fare, fee, rate, charge or other consideration, or directly or indirectly in connection with any business, or other undertaking intended for profit"[1], you're breaking the Store rules and can have your account terminated.
The GPL doesn't allow the users rights to be restricted in this way, hence the incompatibility.
> Your use of the Services and Content must follow the rules set forth in this section (“Usage Rules”). Any other use of the Services and Content is a material breach of this Agreement. Apple may monitor your use of the Services and Content to ensure that you are following these Usage Rules.
> All Services:
> - You may use the Services and Content only for personal, noncommercial purposes (except as set forth in the App Store Content section below).
[...]
> App Store Content:
> - The term “App” includes apps, iMessage and Apple Watch apps, in-app purchases, extensions (such as keyboards), stickers, and subscriptions made available in an app.
> - You can use Apps on any device that you own or control.
> - Individuals acting on behalf of a commercial enterprise, governmental organization or educational institution (an “Enterprise”) may download and sync Apps for use by either (i) a single individual on one or more devices owned or controlled by an Enterprise; or (ii) multiple individuals on a single shared device owned or controlled by an Enterprise. For the sake of clarity, each device used serially or collectively by multiple users requires a separate license.
Notice how the exception in the last clause only applies to "devices owned or controlled by an Enterprise". What I wrote is that using your iPhone is not allowed, and that's plain from the terms.
I'm pretty sure that rule is saying: you can install an App on multiple devices for one user, or one device for multiple users, but you're not supposed to install a single purchased app on a whole fleet of devices that will be used by multiple people.
> What the gpl claims to do for Users or developers is irrelevant.
Indeed it isn't, we weren't even talking only about GPL. We were discussing that claims about Apple "opening up to FOSS" are bogus, until they'll fix the glaring examples of being hostile to FOSS, like above.
> Is it because of an apple rule or is it because gpl3 says the developer can't do that?
It's clearly caused by Apple's restriction on the store, since there is no problem releasing GPL software from many other stores and repositories.
Just off the top of my head, projects they have had a large hand in: WebKit & JavaScriptCore, Objective-C, CUPS, LLVM, Clang, Bonjour/Zeroconf, Darwin, launchd, libdispatch, CoreFoundation, dtrace.
And more recently Apple Lossless Encoder, LZFSE compression, and of course Swift.
And this is only a tiny fraction of what they are users of.