As expected, OS X updates finally slowing down.

Posted:
in macOS edited January 2014
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.

Comments

  • Reply 1 of 14
    zapchudzapchud Posts: 844member
    It's happening exactly as I foretold. I say Tiger is released somewhere in between 23rd of January and 25th of March, 2005.



    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.
  • Reply 2 of 14
    johnqjohnq Posts: 2,763member
    Considering all my roommates (3) are on Jaguar still (old versions) and I'm the only one running Panther, this is good news. Now I can talk them into Tiger and be done with it for another 2 years or so. They always come to me for fixit tips and help but I know for sure Panther would fix most of them. $129 ends the conversation. It's simply not an option to them. They buy a Mac and that's it for investing in the OS for them. (Were they PC users they'd still be running '95 no doubt).



    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.
  • Reply 3 of 14
    salmonstksalmonstk Posts: 560member
    Quote:

    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.
  • Reply 4 of 14
    hobbeshobbes Posts: 1,252member
    Quote:

    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.
  • Reply 5 of 14
    tuttletuttle Posts: 301member
    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.



    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.
  • Reply 6 of 14
    hobbeshobbes Posts: 1,252member
    Quote:

    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.
  • Reply 7 of 14
    aquaticaquatic Posts: 5,602member
    I noticed that bug IMMEDIATELY in Panther the first moment I installed it. MAN is that intensely irritating! I'm a List Views guy. Gar!



    Quote:

    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...
  • Reply 8 of 14
    dobbydobby Posts: 794member
    This is good. We can't afford to spend $99 per machine every year on a new OS, plus all the problems the first couple of versions bring. This goes double for servers.



    Dobby.
  • Reply 9 of 14
    buonrottobuonrotto Posts: 6,368member
    This also bodes well for Tiger methinks.
  • Reply 10 of 14
    powerdocpowerdoc Posts: 8,123member
    Your title is excellent as expected . This are exactly my feelings.
  • Reply 11 of 14
    avon b7avon b7 Posts: 3,901member
    Definitely a win, win situation for all involved.



    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 ) might even come with true upgrade pricing.



    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.
  • Reply 12 of 14
    johnqjohnq Posts: 2,763member
    Quote:

    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.
  • Reply 13 of 14
    bartobarto Posts: 2,246member
    The quote from Avie is quite vauge and without much context. Minor updates have already slowed down, then there are the software that is part of Mac OS X and updated (Safari, iApps etc).



    I'll believe it if Apple either annonces it has abandoned their decade old annual OS release strategy or ships Tiger in 2005.



    Barto
  • Reply 14 of 14
    progmacprogmac Posts: 1,850member
    Quote:

    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

    Quote:

    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
Sign In or Register to comment.