Keeping Safari a secret(donmelton.com)
donmelton.com
Keeping Safari a secret
http://donmelton.com/2013/01/03/keeping-safari-a-secret/
17 comments
Don, would you be willing to share a bit in future posts about how you grew the team, how you organised yourselves and how that changed over the course of the project? Also, what thought process did you go through in the decision of how much to include in V1.0 vs leave to later releases? As a team lead/product manager I'm always interested in hearing other people's experiences, and your experience and writing style put you in a better place than many to do that. It is the thought processes and the dynamics of interacting with others in an organisation that make software development stories interesting.
This blog is revealing more interesting tidbits from inside Apple than the official biographer of Steve Jobs. How sad is that?
Quite sad, but not honestly surprising. That was a biography made to be mainstream, to tell the general public how glorious Steve supposedly was.
I take it you didn't read it.
This seems like an insane waste of resources just to keep a secret.
Did this get you in any programming troubles in the long term?
Did this get you in any programming troubles in the long term?
This still makes me think that Ninjas work at Apple. How other can they evade such a public part of the interwebs? http://www.askaninja.com/ I guess.
What a nicely transparent spam post.
[deleted]
[deleted]
> We couldn’t ship with the real Safari user agent string disabled, but we came up with the next best thing — automatically enabling it after a certain date.
Does that mean that if you set the date of your computer back before 2003, the user agent will become Internet Explorer?
Does that mean that if you set the date of your computer back before 2003, the user agent will become Internet Explorer?
If you were able to run a copy of Safari version 48, it would probably look like a Gecko-based browser before this date.
But he seems to be saying that the code that enables this is still in Safari.
I suggest you look at the author of the comment to which you replied, and compare his name to the author of the article…
Does anyone know why Apple stopped doing this(or stopped doing it as thoroughly)? With the possible exception of the original, sites have consistently reported visits from iOS/iPhone:iPad user agents (and claimed that the ip originated within apple) well before launch.
Recent example: http://thenextweb.com/apple/2013/01/01/developers-begin-seei...
I'm guessing it's not a secret or surprise to anyone that Apple would work on a new version of their operating system, nor that such operating system would include a browser.
Safari, on the other hand, was unexpected.
Safari, on the other hand, was unexpected.
Also, what were the chances that someone would even notice "Safari" in their log files had it of slipped out, vs some stats company who only work on iPhones noticing a new iPhone version.
Apple 10 years ago < Apple now
Apple 10 years ago < Apple now
Apple was big news in the tech industry even at its nadir. To quote (roughly from memory) BYTE in 1994 -- the history of the computer industry over the last ten years has consisted of following Apple.
That Apple makes the iPhone and iPad is not a secret. The article you link to is talking about stats that apps are reporting over the internet... the apps have to know what kind of device they are running on, and have to be able to handle differences between the devices (eg: the screen difference between the iPhone 4S and iPhone 5).
No real information is released with these hardware model numbers that's not already reasonably known.
The only exception is for devices that people might think are end of life, or unlikely to get a refresh soon.
For instance, the Mac Pro may start showing up in logs, and that would be news, because it is so rarely updated... or it would be news if Tim Cook hadn't said that they planned to release an update (in 2013? not sure when he said it would be.)
So, knowing that iOS 7 (8, 9, etc.) are under development doesn't give away any of the secrets-- eg: what the special features of those OSes will be.
No real information is released with these hardware model numbers that's not already reasonably known.
The only exception is for devices that people might think are end of life, or unlikely to get a refresh soon.
For instance, the Mac Pro may start showing up in logs, and that would be news, because it is so rarely updated... or it would be news if Tim Cook hadn't said that they planned to release an update (in 2013? not sure when he said it would be.)
So, knowing that iOS 7 (8, 9, etc.) are under development doesn't give away any of the secrets-- eg: what the special features of those OSes will be.
Well, you can get some real secrets by combining user agents with other data. For example: screen resolution.
TLDR: for whatever reasons it was a very top-secret project, so they spoofed the user agent, the end.
Sometimes the backstory makes for a fun read. Looking for the cliff notes version all the time makes life boring.
Well said.
Definitely a case where it wasn't the destination so much as the journey that was interesting. :)
Definitely a case where it wasn't the destination so much as the journey that was interesting. :)
Looking for the cliff notes version all the time makes life boring.
Not for me, I prefer doing stuff (like typing this inane comment right here) to hearing about trivial things others did. In this case, even the cliff's notes are kinda "meh".
Not for me, I prefer doing stuff (like typing this inane comment right here) to hearing about trivial things others did. In this case, even the cliff's notes are kinda "meh".
WebKit and Safari are hardly "trivial", are they.
*Edited for the benefit of Alfred.
*Edited for the benefit of Alfred.
WekKit also isn't Safari, is it. I was referring to the reasons to keep bespoke Safari "secret" and the ways to do so... as in, to the actual fucking article, not "Apple success porn" in general, or whatever "sensibilities" I might have offended here.
Safari is a subset of WebKit.
Wow.
Ok. I was responding to you rather arrogant assertion that Don's interesting article was "meh". I'd argue that neither WebKit or Safari are trivial. WebKit is arguably the biggest HTML renderer out there and a heck of a lot of people access the internet using Safari. It's fine that you didn't find it interesting, really, that's ok, just don't be a dick about it.
Oh get off it. Yeah, it's perfectly fine for me to find something "meh", how fantastic of you to notice; especially after someone said not reading the in-depth details of it would have made my life more boring; I took exception to be included in that; the nerve of now crying!
Geez. This may come as a shock to you, but the fact that a lot of people use Apple, Microsoft, Google, Facebook or whatever doesn't mean squat to me when it comes to find things "fascinating"; sometimes big isn't beautiful, sometimes it just means someone can't stop pushing people into their pie hole, and that some people actually stand for that. I don't fucking care if either of those parties understand or like my comments, and your "being a dick" is my "not being one".
Sure, WebKit is a nice rendering engine in parts, it's prefix-infested bullshit in others; but when it comes to browser UI and options, Safari isn't even mediocre. Even if it was the best it would be that way for selfish, needy reasons. It's kinda like I don't even care how IE10 is going to be, I won't use it nor develop for it. The awesome thing about convictions is that you don't need the approval of people who don't share them.
Geez. This may come as a shock to you, but the fact that a lot of people use Apple, Microsoft, Google, Facebook or whatever doesn't mean squat to me when it comes to find things "fascinating"; sometimes big isn't beautiful, sometimes it just means someone can't stop pushing people into their pie hole, and that some people actually stand for that. I don't fucking care if either of those parties understand or like my comments, and your "being a dick" is my "not being one".
Sure, WebKit is a nice rendering engine in parts, it's prefix-infested bullshit in others; but when it comes to browser UI and options, Safari isn't even mediocre. Even if it was the best it would be that way for selfish, needy reasons. It's kinda like I don't even care how IE10 is going to be, I won't use it nor develop for it. The awesome thing about convictions is that you don't need the approval of people who don't share them.
So instead of making asinine or pointless comments, say nothing. Judging by your post though, it seems that you are far too narcissistic to remain quite.
Why does that not apply to that schmuck and their ideas about what makes life interesting? Someone helpfully summarized the article and got a dumb fucking comment in response; I reacted to that, and why wouldn't I. Just like you guys are entitled to your whining, or whatever the fuck that is.
"Someone helpfully summarized the article and got a dumb fucking comment in response" No, they didn't. They got a reasonable disagreement. You reacted to it arrogantly. I jovially suggested that your assertion was wrong and you went super nova! The whole thread is there for all to see. You need to work on you people and communication skills. Some free advice. Lose the attitude. Like it or not, that 'schmuck' has contributed significantly to the world of computing. What he has to say is interesting. It's also an interesting insight into a secretive company that has seen unparalleled success until very recently. So those combined, if you are a young entrepreneurial developer, you should listen. You might even learn something.
Thank you. That was my whole reason for writing it. :)
What are your thoughts on the present and future for Safari? It appears Safari for Windows is all but dead, with no mention of it on Apple's website. Meanwhile Chrome's adoption has been stellar. http://www.w3schools.com/browsers/browsers_stats.asp
I'm not going to comment on the present and future of Safari and WebKit. I'm retired. I have no business doing that. And it would disrespect the fine people at Apple -- my friends -- who are still working on both.
You are lucky no one changed their system clock for testing before launch!
Then again it doesn't seem Apple do that very often, cough Do not disturb cough ;)
Then again it doesn't seem Apple do that very often, cough Do not disturb cough ;)
The interesting story is Apple. We're hearing about it now.
"Which explains why the Safari user agent string has so much extra information in it, e.g. KHTML, like Gecko — the names of other browser engines."
Wasn't Safari/WebKit largely based on KHTML in the beginning? This doesn't say it wasn't, but seems to imply that there was a separation of the two that was more complete than it really was.
I realize the OP is in a better position than I to know exactly what the reasoning here was, but it seems like reporting yourself as KHTML when you are largely based on the KHTML rendering engine would just be a sensible and practical thing to do outside of all this cloak and dagger stuff.
(Granted, I doubt there were very many websites, if any at all, that gave a rat's ass about special cases for KHTML compatibility).
Wasn't Safari/WebKit largely based on KHTML in the beginning? This doesn't say it wasn't, but seems to imply that there was a separation of the two that was more complete than it really was.
I realize the OP is in a better position than I to know exactly what the reasoning here was, but it seems like reporting yourself as KHTML when you are largely based on the KHTML rendering engine would just be a sensible and practical thing to do outside of all this cloak and dagger stuff.
(Granted, I doubt there were very many websites, if any at all, that gave a rat's ass about special cases for KHTML compatibility).
Yes, WebKit was based on KHTML and KJS. Even in the beginning, we made a few fundamental changes. Some of those were folded back in, but eventually those differences grew much, much larger.
There actually were some sites (in Europe, as I recall) that behaved a bit better when "KHTML" was in the user agent string.
I also included it as a nod to the original project. I wanted to show respect for the fine work of Lars Knoll and the other contributors.
There actually were some sites (in Europe, as I recall) that behaved a bit better when "KHTML" was in the user agent string.
I also included it as a nod to the original project. I wanted to show respect for the fine work of Lars Knoll and the other contributors.
well yeah, because you guys were sending huge blobs of text back instead of proper formatted patches. didn't make you the most welcome forkers out there.
That's quite the story, and it's great that you'd keep a reference to a products origins (even if you didn't have to).
On a side note, is it still true that Apple has an entire /8 block of IP addresses? I know that a variety of companies where given them, but I was under the impression that large portions of most had been bought back/given back for use elsewhere?
On a side note, is it still true that Apple has an entire /8 block of IP addresses? I know that a variety of companies where given them, but I was under the impression that large portions of most had been bought back/given back for use elsewhere?
Apple still has it. You can see the official allocations here: http://www.iana.org/assignments/ipv4-address-space/ipv4-addr...
The only people to return /8's have been Stanford, the DoD, and a few defense contractors (BBN and Boeing).
The only people to return /8's have been Stanford, the DoD, and a few defense contractors (BBN and Boeing).
I don't know whether the Apple IP addresses were reallocated. I do know that Stanford returned most of its Class A allocation.
Apple still owns and uses the entirety of 17.0.0.0/8.
At the time, Microsoft's hegemony over the web browser market was at its peak. Firefox was the only real competitor. If web pages checked the user agent, they probably only accounted for these two browsers. Anything else fell back to legacy behavior, disabling DHTML (later called Web 2.0). This made Gmail suck.
KHTML had almost no market share - it only ran on KDE, and most KDE users used Firefox. Nothing recognized its user agent string, so reporting "KHTML" would have been as ineffectual as reporting "Safari" or "WebKit".
KHTML had almost no market share - it only ran on KDE, and most KDE users used Firefox. Nothing recognized its user agent string, so reporting "KHTML" would have been as ineffectual as reporting "Safari" or "WebKit".
"At the time, Microsoft's hegemony over the web browser market was at its peak. Firefox was the only real competitor."
Actually at the time this is referencing Firefox didn't exist (Gecko did, but Firefox didn't). I'm well aware of the history and why browsers trick out their user agents. If you want to go one level deeper, look no further than the fact that IE still pretends to be Mozilla because of the early days when they were late to the party.
Actually at the time this is referencing Firefox didn't exist (Gecko did, but Firefox didn't). I'm well aware of the history and why browsers trick out their user agents. If you want to go one level deeper, look no further than the fact that IE still pretends to be Mozilla because of the early days when they were late to the party.
Firefox wasn't a big factor when Safari debuted. And the project was still called "Phoenix" back then. I believe that other Mozilla and Gecko-based browsers were more widely used at that time.
> KHTML had almost no market share - it only ran on KDE, and most KDE users used Firefox.
As mentioned before, Firefox didn't even exist at this point. And KHTML itself actually predates Linux Gecko by a few months as well.
Don Melton forked KHTML/KJS internally in 2001, and announced the work to KDE at the beginning of 2003... GMail wasn't released until 2004!
As mentioned before, Firefox didn't even exist at this point. And KHTML itself actually predates Linux Gecko by a few months as well.
Don Melton forked KHTML/KJS internally in 2001, and announced the work to KDE at the beginning of 2003... GMail wasn't released until 2004!
[deleted]
That is exactly what he is saying. They added KHTML to the user agent string to improve compatibility with servers, since Webkit was essentially KHTML anyway, not to try to hide the actual user agent. Internet Explorer is what they used when hiding the user agent.
If he is trying to say that, then he has my sincere apologies, but it doesn't read like that, at least to me.
eg. he says "the names of other browser engines", not "the name of the browser engine our code was originally based on".
The "like Gecko" part is a bit of a red herring here and mostly irrelevant, as that is simply what KHTML/Konquerer used in its own UA ("KHTML, like Gecko").
eg. he says "the names of other browser engines", not "the name of the browser engine our code was originally based on".
The "like Gecko" part is a bit of a red herring here and mostly irrelevant, as that is simply what KHTML/Konquerer used in its own UA ("KHTML, like Gecko").
The full quote is:
"That allowed me to tweak the string for maximum compatibility with the websites of that time. Which explains why the Safari user agent string has so much extra information in it, e.g. KHTML, like Gecko — the names of other browser engines."
I interpret that as KHTML and Gecko are names of other browser engines that are listed in Safari's user agent string for compatibility purposes.
"That allowed me to tweak the string for maximum compatibility with the websites of that time. Which explains why the Safari user agent string has so much extra information in it, e.g. KHTML, like Gecko — the names of other browser engines."
I interpret that as KHTML and Gecko are names of other browser engines that are listed in Safari's user agent string for compatibility purposes.
Fair enough, I'm not trying to suggest this is some grand conspiracy, it just struck me as a funny phrasing given the shared history of the two layout engines.
I'll be clarifying that shared history in a later post. Specifically, what made me select KHTML/KJS over Gecko and other engines.
Will be fascinated to read that. I remember during the keynote when Safari was announced thinking it was bizarre (not to mention risky) that Gecko wasn't used, but, I knew you all must've had your reasons. As a regular user of Safari and/or WebKit on at least five different platforms, I'm rather happy with how it turned out.
If they were worried about server admins correlating Apple's IP addresses with a new User-Agent string, the team could have VPN'd to a non-Apple network to access the web.
I guess they were worried both about having recognizable IP addresses AND having the name of their new browser appear in logs all around the world.
The user agent was something like "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; sv-se) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5", which people would have quickly correlated to Apple, not matter what IP it came from.
The user agent was something like "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; sv-se) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5", which people would have quickly correlated to Apple, not matter what IP it came from.
The string was originally just contained "WebKit." When it became "AppleWebKit" in mid-December (as I recall) then, yes, it was more likely to be discovered. But I felt that a 17.x.x.x address would be the clincher and the secret would be out.
I distinctly remember how the web dev world (myself included) groaned at the prospect of supporting another rendering engine. Gecko was clearly the best browser at the time, and the choice of KHTML seemed bizarre, to say the least.
Even the intention of Apple building it's own web browser seemed weird, Apple had failed at a previous homebrewed browser (Cyberdog), why not just build on top of what Mozilla had already done?
I remember Apple stating that Konqueror's code was much more leaner, faster and modern. I've always wondered if the birth of Safari was an early sign that Apple was interested in developing the pieces missing for an internet device. Safari seemed like a godsend foresight from Apple when they released the iPhone, but I can't help wonder if it was planned this way all along.
Even the intention of Apple building it's own web browser seemed weird, Apple had failed at a previous homebrewed browser (Cyberdog), why not just build on top of what Mozilla had already done?
I remember Apple stating that Konqueror's code was much more leaner, faster and modern. I've always wondered if the birth of Safari was an early sign that Apple was interested in developing the pieces missing for an internet device. Safari seemed like a godsend foresight from Apple when they released the iPhone, but I can't help wonder if it was planned this way all along.
Amusingly, before Chrome, Google used to contribute a lot of engineers to Firefox/Mozilla. They decided to do their own after deciding they weren't happy with it. I don't quite recall the main reason, might have had something to do with some sort of mess for cross compiling or variable sizes or something mainly.
I would not call Cyberdog a failure. Yes, it wasn't fast and it didn't have a great rendering engine, but frankly, neither did the competition, and I found its look and feel so good that I kept using it for a long time (with IE as a backup for pages it did not handle, IIRC)
OpenDoc, on which it was built, failed, but even that, I would not call a complete failure. It may have just been bad timing (of the Newton vs iPhone kind). If you are looking for a large hobby project: I would love to see something OpenDoc-like today running in a browser. Require viewers to be freely downloadable from e.g. GitHub, but allow developers to sell their editors, and see where it gets.
OpenDoc, on which it was built, failed, but even that, I would not call a complete failure. It may have just been bad timing (of the Newton vs iPhone kind). If you are looking for a large hobby project: I would love to see something OpenDoc-like today running in a browser. Require viewers to be freely downloadable from e.g. GitHub, but allow developers to sell their editors, and see where it gets.
Agreed — Cyberdog was the best thing about OpenDoc.
I would love to claim the foresight of planning for the iPhone all along. Alas, that was not the case. :) For any of us.
We built our own browser because we didn't want to depend on another company for a critical application.
We built our own browser engine because we wanted to use the technology in more things than a browser.
We built that engine small and fast because Bertrand Serlet would have shot me if I had done otherwise. :)
You have to remember that Mac OS X itself was smaller in those days. Not iOS small, but considerably smaller that it is now.
After the initial success of Mac Safari, there was a time when I was second-guessed by some for choosing KHTML and KJS as the basis for WebKit. When we decided to do the iPhone, I was suddenly a genius again. :)
That's just the way it works in the real world.
We built our own browser because we didn't want to depend on another company for a critical application.
We built our own browser engine because we wanted to use the technology in more things than a browser.
We built that engine small and fast because Bertrand Serlet would have shot me if I had done otherwise. :)
You have to remember that Mac OS X itself was smaller in those days. Not iOS small, but considerably smaller that it is now.
After the initial success of Mac Safari, there was a time when I was second-guessed by some for choosing KHTML and KJS as the basis for WebKit. When we decided to do the iPhone, I was suddenly a genius again. :)
That's just the way it works in the real world.
It is probably just the dumb luck of having started the same day as you and Maciej (and thus going through orientation at the same time), but it was completely obvious to me that you were building a browser team, at least once you stopped working on Mail.app bugs during the Puma crunch and he moved over to your team a few weeks later ;-)
To drive home Don's point about how secret Alexander was: I was given official access to Marklar months before Alexander. Since there was no Rosetta at that time the Intel builds of OS X had no bundled web browser (and porting Chimera or Mozilla were clearly nowhere on that team's priority list at the time, for obvious reasons). I was eventually given access to Alexander largely because I was doing enough Intel related work that it was necessary to have access to a browser on my Intel machines.
To drive home Don's point about how secret Alexander was: I was given official access to Marklar months before Alexander. Since there was no Rosetta at that time the Intel builds of OS X had no bundled web browser (and porting Chimera or Mozilla were clearly nowhere on that team's priority list at the time, for obvious reasons). I was eventually given access to Alexander largely because I was doing enough Intel related work that it was necessary to have access to a browser on my Intel machines.
>We built our own [map app] because we didn't want to depend on another company for a critical application.
I believe, in retrospect, Apple's Maps.app will be considered in the same league as Safari. It may have had a rougher start than Safari, but I think it's a great program.
I believe, in retrospect, Apple's Maps.app will be considered in the same league as Safari. It may have had a rougher start than Safari, but I think it's a great program.
But it's different for maps, it's not the programming that was at fault, it's the cartographic data.
And to continue the parallel, it would have probably been better for apple and everyone else if apple had just used the gecko engine for their browser.
And to continue the parallel, it would have probably been better for apple and everyone else if apple had just used the gecko engine for their browser.
> And to continue the parallel, it would have probably been better for apple and everyone else if apple had just used the gecko engine for their browser.
In what way?
WebKit seems to have enjoyed some success since then... since Chrome toppled both Internet Explorer and Firefox.
In what way?
WebKit seems to have enjoyed some success since then... since Chrome toppled both Internet Explorer and Firefox.
It might have been better at the time to use gecko, but apparently building a new rendering engine had enough advantages that Apple decided it was worth it. In hindsight, WebKit was the right call. It's powerful enough to run advanced desktop browsers, yet lightweight enough to power (almost) the entire mobile web.
I thought that WebKit was based upon KHTML. Was it different enough upon initial release that you would consider it "building a new rendering engine"?
Mozilla was a bridge to step away from IE and "Made for IE" sites.
It's goal was "bug-for-bug compatability with IE" so that you could run Mozilla / Netscape on websites that weren't updated / weren't ever going to be updated.
KHTML / Konqueror was effectively "strict-mode-only" not caring (as much) if sites broke, but implementing things "as sanely as possible".
Firefox was Mozilla with a sane UI on top of it.
Mozilla UI was trash because goofballs in suits kept ruining it by pushing for "site-specific-themes paid for by advertisers" which caused the "chrome" to be incredibly buggy / slow / etc.
WebKit / Safari was Apple delicately picking up KHTML, making the "hard" decisions to implement some things poorly / hackily / different / more quickly than the "purist" open source KHTML volunteer developers had envisioned.
They actually handled it overall quite well, as opposed to their other forays into open-source land (kernel / darwin, cups, etc).
WebKit is excellent now because it didn't have to start with that bridge step, and had speed / correctness / isolation as a focus from the start. So even though WebKit is the current "leader", it owes a lot to Mozilla for doing the hard grunt-work that allowed it to take cover behind the big lumbering dinosaur and come out unscathed on the other side.
It's goal was "bug-for-bug compatability with IE" so that you could run Mozilla / Netscape on websites that weren't updated / weren't ever going to be updated.
KHTML / Konqueror was effectively "strict-mode-only" not caring (as much) if sites broke, but implementing things "as sanely as possible".
Firefox was Mozilla with a sane UI on top of it.
Mozilla UI was trash because goofballs in suits kept ruining it by pushing for "site-specific-themes paid for by advertisers" which caused the "chrome" to be incredibly buggy / slow / etc.
WebKit / Safari was Apple delicately picking up KHTML, making the "hard" decisions to implement some things poorly / hackily / different / more quickly than the "purist" open source KHTML volunteer developers had envisioned.
They actually handled it overall quite well, as opposed to their other forays into open-source land (kernel / darwin, cups, etc).
WebKit is excellent now because it didn't have to start with that bridge step, and had speed / correctness / isolation as a focus from the start. So even though WebKit is the current "leader", it owes a lot to Mozilla for doing the hard grunt-work that allowed it to take cover behind the big lumbering dinosaur and come out unscathed on the other side.
I remember using KHTML back before Safari was out, and it was wayyy behind Firefox. I'd bet that KHTML was mostly just a sane starting point that needed a significant amount of work to complete with IE/Firefox.
Safari pre-dated Firefox, so something about your recollection is a bit off here. Perhaps you're thinking of SeaMonkey or Phoenix as the point of comparison?
Either way according to Wikipedia, Don had forked KHTML/KJS in 2001 (which pre-dated the first public release of Phoenix by a year or so), so his choices were to hack SeaMonkey into something suitable or to start from somewhere else.
Either way according to Wikipedia, Don had forked KHTML/KJS in 2001 (which pre-dated the first public release of Phoenix by a year or so), so his choices were to hack SeaMonkey into something suitable or to start from somewhere else.
I think you're right about using SeaMonkey. Either, I remember using some Mozilla based browser that was way ahead of KHTML that is still used
I honestly have no idea. I'm not a developer. :)
Presumably, by your logic, Google and Adobe were wrong to adopt webkit instead of Gecko too.
That's twice you mentioned 'being shot' for failure. Sounds like a real culture of fear. I get the excitement for a chance to innovate the future of computing, but I sometimes get a sense of real Stockholm Syndrome from people at Apple. I personally don't want to work at a place where people are so afraid of failure. Look at Forstall's recent exit. All those years changing the world through computing, and at the end he gets a disgraceful boot out the door.
You can change the world from a growing startup without having to fear for your career at every turn. You can have fun without being afraid. Imagine that!
You can change the world from a growing startup without having to fear for your career at every turn. You can have fun without being afraid. Imagine that!
I suspect the reason for choosing KHTML over Gecko may have been more political than anything else. Since Mozilla was the dominant non-IE browser at the time, it would be hard to justify any fork to the community without meaningfully given back. For example, Apple could go off into a cave and add touch handling support with momentum scrolling and GPU acceleration, and the Mozilla community would be absolutely furious with Apple for creating effectively unusable work, assuming they did the work over several months/years in secret. The last thing Apple wants is a large group of loud people complaining about itself.
By comparison, KHTML was not really a serious project. It had a few developers, but nowhere near the scale of what Mozilla had. Thus, when they forked it to do their work in secret, only a couple people complained.
By comparison, KHTML was not really a serious project. It had a few developers, but nowhere near the scale of what Mozilla had. Thus, when they forked it to do their work in secret, only a couple people complained.
> By comparison, KHTML was not really a serious project. It had a few developers, but nowhere near the scale of what Mozilla had.
You'd be surprised at the negative impact that a large number of developers can have on the quality of a software project.
You'd be surprised at the negative impact that a large number of developers can have on the quality of a software project.
When Safari came out, I happened to just have looked at the Mozilla code. A significant part of the "scale of what Mozilla had" was due to the design decision to couple the major browser components using a home-grown (and, hence, included with the sources) clone of Microsoft's COM.
To make matters worse, unlike Microsoft's version, the Mozilla version needed to support multiple OSes and multiple compilers.
Because of that, I believe Apple's claim that the choice for KHTML was on technical grounds.
(I don't remember whether Mozilla already used XUL at the time. If so, that could have been another argument for choosing KHTML)
To make matters worse, unlike Microsoft's version, the Mozilla version needed to support multiple OSes and multiple compilers.
Because of that, I believe Apple's claim that the choice for KHTML was on technical grounds.
(I don't remember whether Mozilla already used XUL at the time. If so, that could have been another argument for choosing KHTML)
Konqueror was by some distance the best browser available at the time (even today there is Konqueror 3.2 functionality that I can't find in anything else), and the fact that they were able to keep it that way with about 5 devs total spoke to the quality of the code.
Agree. I used KHTML (later known as Konqueror) as my primary browser (as a webdev!) since early days of KDE until I switched to Mac in 2006. Konqueror always felt right on KDE, just like Safari feels right on OS X (native feel, integration, etc).
A little feature I still miss was that you could navigate up in URL hierarchy by alt+up, just like in file-browsing mode (not sure if it's still supported by today's Konqueror).
A little feature I still miss was that you could navigate up in URL hierarchy by alt+up, just like in file-browsing mode (not sure if it's still supported by today's Konqueror).
Try command-clicking the Safari title bar sometime (when you're at a page with a URL that goes several levels deep) if you haven't before.
That's nice one! )Although not nearby as intuitive as <cmd/ctrl>+up.)
Not sure I agree — its standard for OS X documents to show their hierarchy when their title bar is command-clicked; cmd-up arrow is much less broadly used.
It's not only standard Mac OS X behavior, but Mac OS in general. I learned this trick in System 7, and I believe it was around for some time before then.
It's Ctrl(or Cmd)-Backspace in Opera.
Interesting, I wonder if it would be possible to start a rumour by having a number of people spoof their user-agent string?
Sure , they wouldn't route back to an Apple IP address but then who's to say Apple doesn't browse via proxy/vpn somewhere?
Sure , they wouldn't route back to an Apple IP address but then who's to say Apple doesn't browse via proxy/vpn somewhere?
No-one would credit rumors that Apple was wasting its time creating a new browser.
>Back around 1990, some forward-thinking IT person secured for Apple an entire Class A network of IP addresses.
I found that fact to be the most interesting part of the article. The list of other Class A holders is also interesting: http://www.aturtschi.com/whois/neta1.html
I found that fact to be the most interesting part of the article. The list of other Class A holders is also interesting: http://www.aturtschi.com/whois/neta1.html
Back around 1990, some forward-thinking IT person secured for Apple an entire Class A network of IP addresses.
Pixar has a large block too... I wonder if Steve had something to do with it?
Pixar has a large block too... I wonder if Steve had something to do with it?
Indeed -- also interesting are the results of an RDNS query on the first IP address listed in the article (17.149.160.49).
I knew that going in, but only because of this: http://xkcd.com/195/
[deleted]
must have been easier to use an ip filter and base the identifier on ip... duh..
A device behind a router might be unable to reliably determine its outward-facing IP.