As expected, OS X updates finally slowing down.
http://news.com.com/2100-1045_3-5215281.html
Not a big surprise here?the development schedule for OS X has been growing longer with every release. As OS X matures, development will naturally take more time. (And people do seem to be getting a little irritated paying every year.)
Still, it's official now. Straight from Avie's mouth.
Not a big surprise here?the development schedule for OS X has been growing longer with every release. As OS X matures, development will naturally take more time. (And people do seem to be getting a little irritated paying every year.)
Still, it's official now. Straight from Avie's mouth.
Comments
This is excellent, really. Now that OS X is a mature and good OS in general, they can calm down, and release much more polished updates with larger intervals. A win-win for consumers and Apple.
I won't install my copy on their machines 1. because I think they should just buy it, 2. I don't give things to people, it makes false friends, 3. if anything goes wrong i'll eternally be to blame...
A longer release period is highly welcomed.
Originally posted by johnq
I know for sure Panther would fix most of them. $129 ends the conversation. It's simply not an option to them.
I won't install my copy on their machines 1. because I think they should just buy it, 2. I don't give things to people, it makes false friends, 3. if anything goes wrong i'll eternally be to blame...
A longer release period is highly welcomed.
Oh come on, give them the software. Reason 1 is no good you are friend, reason 2- hell yeah buy friends, just make sure they pay you back in other ways... i.e. free beer. and reason 3, thats just silly.
Originally posted by salmonstk
Oh come on, give them the software. Reason 1 is no good you are friend, reason 2- hell yeah buy friends, just make sure they pay you back in other ways... i.e. free beer. and reason 3, thats just silly.
Free beer indeed.
So, fair to say that it's looking reasonable to expect Tiger in early 2005, and Tiger's successor to go roughly head-to-head vs. Longhorn somewhere around mid-2006...?
Apple has more than measured up to OS 9, proven they can innovate quickly, and that OS X is a platform that's capable of growing in leaps and bounds... Now's the time to get off the insanely rapid development wheel, and spend more time figuring out the Next Great Thing behind tinted windows?instead out in the open, under MS's watchful gaze.
It seems like there are a lot of bugs or quirks leftover from the 9->X transition that I don't think people at Apple are aware of. Like they never used the original Mac OS or it has been so long since anyone has used a classic Mac system they don't notice the quirks.
Little things, like not being able to select drag upward in list views in Finder windows.
Originally posted by Tuttle
Little things, like not being able to select drag upward in list views in Finder windows.
Oh weird. Never noticed that one.
I wish Apple would have some sort of public 'top 100 bugs/quirks' that everyone could vote on for them to fix now that the race to add features is slowing down.
That's a brilliant idea! Off to e-mail Apple...
Dobby.
I hope Tiger gets released when it's truly ready and not when marketing/accounting dictates. That said though, Apple's past record makes me think Tiger will definitely be on the shelves come Christmas so it could well be another case of 'coming, ready or not'.
With longer development cycles more people will probably upgrade and the upgrades (yes, upgrades - for the doubters
As more people consider themselves potential upgraders it should even be possible to make 'the sale' on under-the-hood improvements and reduce the need for dubious, flashy or half-baked features that look good on promotional material but just are not useful in real life.
Originally posted by Aquatic
"I wish Apple would have some sort of public 'top 100 bugs/quirks' that everyone could vote on for them to fix now that the race to add features is slowing down"
That's a brilliant idea! Off to e-mail Apple...
Right but unfortunately this conflicts with Apple's apparent policy of saving face. (Are they secretly a Japanese company?
They simply will never, ever, publicly admit anything is wrong with the OS. They will issue updates and fixes for certain things but that's about it.
(Edit: You can dig deep and get on some Apple Developer Mailing Lists and perhaps Mac newsgroups and get in contact with Apple developers to various extents. But none of it is all that official.)
It takes forever to get them to even admit to hardware issues. OS issues you can forget about, short of critical security flaws.
The bug poll described would only work for a company like OMNI or maybe Panic or somesuch.
The guy that develops Safari, Dave Hyatt, is a notable exception (and a glimmer of hope I suppose) for taking the discussion to the web (a blog no less, how modern!) as opposed to under-the-rock, dark, musty mailing lists.
Would that the OS development team could discuss things so publicly.
I'll believe it if Apple either annonces it has abandoned their decade old annual OS release strategy or ships Tiger in 2005.
Barto
Originally posted by johnq
The guy that develops Safari, Dave Hyatt, is a notable exception (and a glimmer of hope I suppose) for taking the discussion to the web (a blog no less, how modern!) as opposed to under-the-rock, dark, musty mailing lists.
Would that the OS development team could discuss things so publicly.
this was a very interesting read, i found the following the most interesting
A naive approach might be to simply remove all delays and show the page as soon as you get the first chunk of data. However, there are drawbacks to showing a page immediately. Sure, you could try to switch to a new page immediately, but if you don't have anything meaningful to show, you'll end up with a "flashy" feeling, as the old page disappears and is replaced by a blank white canvas, and only later does the real page content come in. Ideally transitions between pages should be smooth, with one page not being replaced by another until you can know reliably that the new page will be reasonably far along in its life cycle.
In Safari 1.2 and in Mozilla-based browsers, the heuristic for this is quite simple. Both browsers use a time delay, and are unwilling to switch to the new page until that time threshold has been exceeded. This setting is configurable in both browsers (in the former using WebKit preferences and in the latter using about:config).
When I implemented this algorithm (called "paint suppression" in Mozilla parlance) in Mozilla I originally used a delay of 1 second, but this led to the perception that Mozilla was slow, since you frequently didnt see a page until it was completely finished. Imagine for example that a page is completely done except for images at the 50ms mark, but that because you're a modem user or DSL user, the images aren't finished until the 1 second mark. Despite the fact that all the readable content could have been shown at the 50ms mark, this delay of 1 second in Mozilla caused you to wait 950 more ms before showing anything at all.
One of the first things I did when working on Chimera (now Camino) was lower this delay in Gecko to 250ms. When I worked on Firefox I made the same change. Although this negatively impacts page load time, it makes the browser feel substantially faster, since the user clicks a link and sees the browser react within 250ms (which to most users is within a threshold of immediacy, i.e., it makes them feel like the browser reacted more or less instantly to their command).
Firefox and Camino still use this heuristic in their latest releases. Safari actually uses a delay of one second like older Mozilla builds used to, and so although it is typically faster than Mozilla-based browsers on overall page load, it will typically feel much slower than Firefox or Camino on network connections like cable modem/modem/DSL.
However, there is also a problem with the straight-up time heuristic. Suppose that you hit the 250ms mark but all the stylesheets haven't loaded or you haven't even received all the data for a page. Right now Firefox and Camino don't care and will happily show you what they have so far anyway. This leads to the "white flash" problem, where the browser gets flashy as it shows you a blank white canvas (because it doesn't yet know what the real background color for the page is going to be, it just fills in with white).
So what I wanted to achieve in Safari was to replicate the rapid response feel of Firefox/Camino, but to temper that rapid response when it would lead to gratuitous flashing. Here's what I did.
(1) Create two constants, cMinimumLayoutThreshold and cTimedLayoutDelay. At the moment the settings for these constants are 250ms and 1000ms respectively.
(2) Don't allow layouts/paints at all if the stylesheets haven't loaded and if you're not over the minimum layout threshold (250ms).
(3) When all data is received for the main document, immediately try to parse as much as possible. When you have consumed all the data, you will either have finished parsing or you'll be stuck in a blocked mode waiting on an external script.
If you've finished parsing or if you at least have the body element ready and if all the stylesheets have loaded, immediately lay out and schedule a paint for as soon as possible, but only if you're over the minimum threshold (250ms).
(4) If stylesheets load after all data has been received, then they should schedule a layout for as soon as possible (if you're below the minimum layout threshold, then schedule the timer to fire at the threshold).
(5) If you haven't received all the data for the document, then whenever a layout is scheduled, you set it to the nearest multiple of the timed layout delay time (so 1000ms, 2000ms, etc.).
(6) When the onload fires, perform a layout immediately after the onload executes.
This algorithm completely transforms the feel of Safari over DSL and modem connections. Page content usually comes screaming in at the 250ms mark, and if the page isn't quite ready at the 250ms, it's usually ready shortly after (at the 300-500ms mark). In the rare cases where you have nothing to display, you wait until the 1 second mark still. This algorithm makes "white flashing" quite rare (you'll typically only see it on a very slow site that is taking a long time to give you data), and it makes Safari feel orders of magnitude faster on slower network connections.
Because Safari waits for a minimum threshold (and waits to schedule until the threshold is exceeded, benchmarks won't be adversely affected as long as you typically beat the minimum threshold. Otherwise the overall page load speed will degrade slightly in real-world usage, but I believe that to be well-worth the decrease in the time required to show displayable content.
it seems like we can expect future safari releases to feel a lot faster. i have noticed that camino feels, to some extent, faster than safari. i also remember first trying the wonderful mozilla and thinking, "eh?? this is slower than IE"
good stuff