Live data from Hacker News

Expected arrival times for Apple products

arrival.io

51–60 of 123 posts

Re: Expected arrival times for Apple products

#51
post #50

My own personal expected arrival times: • Apple iEyes, stylish head-worn computer: 2016 • Apple MagicMindPad, implantable universal 3D/multitouch pointer device: 2021 • Apple nuRetina, permanent replacement for your biological retina: 2028 (Impulse purchases at the fancy Apple surgical centers are going to be big business in the 2020's.)

I want all of those things.

Re: Expected arrival times for Apple products

#53

Eventually Apple will sell hardware subscriptions, where you just turn in your old gear and get new stuff every year. (Maybe they can give your old ipods to starving kids or something).

Companies have been doing it for decades for personal computers, servers, cars and all kind of equipement. If it’s stuff that ages quickly (either because technology advances or because it wears out) it makes a lot of sense. You pay a fee and you get new equipment every two years and usually free replacements if it breaks in the meantime.

You could say it’s not as good for the environment, and I would agree.

Re: Expected arrival times for Apple products

#54
post #50

My own personal expected arrival times: • Apple iEyes, stylish head-worn computer: 2016 • Apple MagicMindPad, implantable universal 3D/multitouch pointer device: 2021 • Apple nuRetina, permanent replacement for your biological retina: 2028 (Impulse purchases at the fancy Apple surgical centers are going to be big business in the 2020's.)

* Apple iEyes, stylish head-worn computer: 2016

Surely it would be the iPatch: http://www.weylonsmith.com/blog/tag/ipatch

Re: Expected arrival times for Apple products

#55
post #54
post #50

My own personal expected arrival times: • Apple iEyes, stylish head-worn computer: 2016 • Apple MagicMindPad, implantable universal 3D/multitouch pointer device: 2021 • Apple nuRetina, permanent replacement for your biological retina: 2028 (Impulse purchases at the fancy Apple surgical centers are going to be big business in the 2020's.)

* Apple iEyes, stylish head-worn computer: 2016 Surely it would be the iPatch: http://www.weylonsmith.com/blog/tag/ipatch

Or the Eye Pad

Re: Expected arrival times for Apple products

#56

Is this just scraping http://buyersguide.macrumors.com/ ?

I've looked at their data, but I believe I've dropped some things that they consider releases. The whole thing is kind of subjective as to what constitutes a release or not. But no, I didn't just scrape their site. I compiled my own data from a variety of different freely available sources.

Might I ask why you built your own, knowing there was an almost identical offering in place for years? For example, did your different choice of releases cause a statistically significant shift in arrival times? I imagine you've done analysis comparing your approach to theirs.

Re: Expected arrival times for Apple products

#57

This is a great idea, and is especially pertinent to Mac fans who care about the hardware they are using. Since Apple does not discount old hardware (even with 2-3 year old video cards, they charge the same amount as a brand new updated mac the very next week[1]), people buying a Macbook pro at the wrong end of the timeline can get totally shafted on equipment, especially from a price-per-performance view. That feels…

I tell everyone, if you want to know if a new MBP is about to come out, ask me if I've bought one in the last couple of weeks. Both MBP's I've bought were followed soon thereafter by a model refresh :|

Re: Expected arrival times for Apple products

#59
post #21

Earlier quoted context omitted.

I love Firefox, but I am encountering problems like this more and more often. It's a disaster to use with Coursera or Netflix.

"This page is best viewed with Google Explorer" It looks like the page is doing something funny with javascript to render the bars, why not just use good old css?

The problem is that the site is using SVG paint servers to provide a gradient for the progress rect. The gradient is specified in a SVG def element with id barGradient in the HTML file. So far so good. The problem arises because the fill rule is written as "fill: url(#barGradient)" and is placed in an external CSS file. In this case the fragment should be resolved against the stylesheet URL, not the HTML document URL [1]. It appears that Gecko and Opera get this right and WebKit doesn't. However the page relies on the incorrect behaviour here. (I also note that Gecko and Presto do different things after they fail to resolve the paint server; Gecko falls back to "none", Presto to the default fill colour. My reading of SVG 1.2T is that Gecko is correct in this case [2]).

tldr; The page relies on a WebKit bug. The Gecko rendering is correct.

[1] http://www.w3.org/TR/css3-values/#urls [2] http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint

Post reply on HN