Apple Said to Work on Mac Chip That Would Lessen Intel Role - <AUTHOR> https://www.bloomberg.com/news/articles/2017-02-01/apple-developing-new-mac-chip-in-test-of-intel-independence <comment><USER2> It has been interesting to watch the ARM ecosystem unfold. Sort of like seeing a levy breach where just a trickle of water starts flowing over it and then more and more and more.

Apple has the resources and the motivation to build a "desktop" 64 bit ARM processor. The history here is also interesting. After debuting the Macintosh in 1984, and getting into fights with Motorola over what should be in the next generation chips, they did the unthinkable and adopted an entirely new instruction set architecture, PowerPC.

That relationship ended on a fairly rocky note and Apple did not have the IP rights to continue PowerPC development or the infrastructure access. They switched to Intel's architecture with great fan fare and started using ARM in their mobile offering. Now ARM has reached the point where it is adopting "high end" features faster than Intel can invent new ones. And Apple has both proven to itself that it can design and fab a completely bespoke CPU design without any input from the original owner.

So here we are looking down the barrel of "bespoke chip architecture round II."

It gives Apple some unique advantages that neither Microsoft nor Google can match.

<comment><USER3> It's really interesting how the historical strengths of companies can persist even after decades of evolution. If the people are coming and going, how is this institutionalized success being cultivated and maintained?

<comment><USER2> To be honest I don't know the answer to that. That said, Apple has _always_ had corporate value of being maximally responsible for their own destiny. It's hallmark card wisdom to know the things you can change and accept the things you can't change, but in Apple's case their history has been filled with finding things we can't change and replacing them with something we can. So where one company might say "Well we have to work with what ever the microprocessor company will agree too" Apple wants to say "The microprocessor company will do what ever we require of them." And if they can't find such a company they look at becoming a microprocessor company.

A lot of that thinking was laid out fairly extensively in the lawsuit over manufacturing sapphire they got into. The manufacturer (GT Advanced) complained (reasonably I think) that Apple's contracts were so onerous as to make them employees of the company in everything but name. And that appears to be how Apple likes it, complete control of their destiny when ever possible.

<comment><USER4> So is the lesson taking contracts from Apple is not a good idea?

</comment></comment></comment></comment><comment><USER5> I think that in the long run you'll see a hybrid ARM/x64 Mac sharing the same case in the same way we have hybrid graphics.

If you look at most of the processes running on a Mac, how many of those _need_ to be running on the power-hungrier Intel chip? You could easily offload much of the kernel, Dock, compositor, Twitter desktop, etc to a lower- power ARM. In the case where you aren't running any x64 apps, you could then power that chip down and run solely on ARM.

<comment><USER6> This sounds incredibly kludgey and at odds with Apple's de-investment in macOS. (As in "reduced investment", not "divestment".) Adding massive complexity to eke out another hour or two of battery life seems like a poor choice when there are so many things to be fixed in the OS.

<comment><USER7> Why so? A Mac is a very high ASP item - why not, for example allow iOS apps to run in macOS (using the ARM processor).

Ultimately, the 2016 MBPs are a great example of why Apple needs to divest from Intel. The poor timing for Kaby Lake mobile processors and lack of low- power RAM were both Apple's reasons stated when the topic of "the MBP isn't keeping up with the competition" arises.

And who's to say that macOS.next will be anything similar to the current macOS?

<comment><USER6> _why not, for example allow iOS apps to run in macOS_

That's not what the article is talking about and it's a bad idea for UX reasons (no touchscreen).

 _And who 's to say that macOS.next will be anything similar to the current macOS?_

Don't even go there; a vocal minority of Mac users including me _do not want_ anything like that. And getting back to the article, if the OS is radically different then presumably it doesn't need both Intel and ARM processors.

<comment><USER7> > Don't even go there; a vocal minority of Mac users including me do not want > anything like that.

I'm a Mac user too. Unfortunately, Apple is notorious for doing what they think is right, regardless of their user base. Need I say "lightning headphones" or "no magsafe, just USB-C"?

Both of these strike me as positioning for the future _Apple wants_ despite the concerns the vocal parts of their userbase.

<comment><USER8> Skate where the puck will be, not where it is.

</comment></comment></comment></comment></comment></comment><comment><USER9> Interesting. The article says that Apple is considering an ARM _co_ -processor, not a replacement for the Intel CPU.

I have no doubts at all that Apple have at least had extensive internal discussion and testing about this. In fact, I believe they've probably done extensive internal discussion and testing about replacing the Intel one altogether, but can't get there yet.

It'd give Apple more control over their device design and release schedule, potentially lower power consumption, and straight up more profit via vertical integration.

Like the PowerPC transition, they could come up with a new Rosetta - which was the emulator that ran old PowerPC apps on x86. Microsoft has recently demoed x86 apps on ARM, and I'm sure Apple could do the same.

As far as I know there's no _fundamental_ reason ARM processors can't be as fast as x86 ones, they just haven't been targeted for those kind of devices yet - but I'd be happy to be corrected by any CPU experts. And with Apple's success in the mobile processor space, I have no doubts that if anyone could pull this off, it'd be them.

So what's holding them back? Thunderbolt. They've gone all-in on that already - touting as the future of high speed external devices, and giving the MacBook Pro nothing but four Thunderbolt enabled USB-C ports and a headphone port. But Thunderbolt is an Intel property, only available on their CPUs.

The 12" MacBook already doesn't have Thunderbolt (the MacBook Pro does), but it feels like with software compatibility, this would be an all-or-nothing thing. I don't see Apple continuing to sell both x86 and ARM machines on an ongoing basis. So how would they get Thunderbolt into the MacBook Pro?

Having a co processor to handle PowerNap would allow them to take a small step in that direction without losing Thunderbolt or having to develop a slow x86 emulator. They could even offload other parts of the OS to the ARM cpu, freeing up the main CPU for other software, and to go into low power mode more often.

<comment><USER10> That's actually a interesting point - I wonder if it's possible to license the Thunderbolt tech in some way, and have it hooked up to the ARM Chip; something like what Asus does to give AMD thunderbolt: [http://www.eteknix.com/asus- give-am3-boards-thunderbolt-supp...](http://www.eteknix.com/asus-give- am3-boards-thunderbolt-support/)

Saying that - and I hope someone corrects me here if I'm wrong, I was under the impression that Apple & Intel jointly created Thunderbolt (or perhaps it is an Intel only tech), which means Apple may have some sway here.

Just thinking about it more - Thunderbolt is just a protocol driven over USB-C now, so I'm fairly certain USB (3/C) might eventually be able to cover everything Thunderbolt does, or apple takes their "lightning" protocol to replace Thunderbolt, and use that over USB instead of Thunderbolt over USB.

Just musing but it is a very under appreciated aspect to all of this as well!

<comment><USER9> I almost posted that link too, but according to this comment, that product was cancelled and never released because Intel refused: [https://www.reddit.com/r/Amd/comments/539kvq/will_amd_cpusmo...](https://www.reddit.com/r/Amd/comments/539kvq/will_amd_cpusmotherboards_have_thunderbolt/dab2g3n/)

There's still a mention of an expansion card on their site:

[https://www.asus.com/us/Motherboard- Accessory/ThunderboltEX-...](https://www.asus.com/us/Motherboard- Accessory/ThunderboltEX-3/)

But it's only compatible with ASUS motherboards that already have Thunderbolt. So I'm not sure what the point of it is (just to upgrade from ThunderBolt 2.0 to 3.0 maybe?), and as far as I can tell... still requires intel.

So as far as I'm aware, no product has ever released with Thunderbolt that doesn't use an Intel CPU (and even then, only higher-end ones).

Licensing aside, it may be a technical issue - ThunderBolt is an extension of PCI-express, which just isn't part of the ARM design. I'm not sure how feasible it would be to add it.

<comment><USER6> Plenty of ARMs have PCIe, maybe even the A9.

<comment><USER9> Any examples?

<comment><USER6> Nvidia Tegra, all server ARMs, all Wi-Fi APs, higher-end embedded SoCs (e.g. Marvell), etc.

<comment><USER9> Interesting. I didn't know that.

However, that still doesn't mean Intel will certify anything for Thunderbolt that doesn't use their processors. I still haven't seen any evidence of a certified Thunderbolt host device existing that doesn't have an Intel CPU.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> There is only one piece of "news" (possibly speculation) in this article: that they may offload some processing to the ARM coprocessor as a transitional step. Interesting idea!

But the idea that they have the Mac OS running on their own ARM chips -- Apple shareholders should be annoyed if the company _weren 't_ doing this.

OS X was running for a long time on Intel before anyone decided to make Intel based Macs.

<comment><USER12> ... _or_ iOS will be graduating up to be the new OS across both mobile and desktop platforms?

Earlier today via HN....

[http://www.macworld.com/article/3163248/ios/the-future-of- io...](http://www.macworld.com/article/3163248/ios/the-future-of-ios- is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html)

<comment><USER13> People have been saying this since the inception of iOS; given the trajectory of Cocoa vs UIKit, I don't see much sign of this.

<comment><USER14> Cocoa over the last few years has made a lot of cleanup/progress on its api's. Making a Mac app in Swift 3 is almost as painless as making an iOS app nowadays. I feel like there has been a _big_ difference in just the last few years. Swift is a big part of this, but also, I'm sure Federighi's group is the real reason.

<comment><USER15> This is one of the big reasons why I don't buy the whole narrative in these parts around Apple abandoning the Mac. They are spending far too much time on improving Cocoa APIs as you mention to be working towards abandoning or deprecating it.

</comment></comment></comment></comment></comment><comment><USER16> There's always a hedge afoot. Apple had OS 7 running on Intel as early as 1992.

[https://en.wikipedia.org/wiki/Star_Trek_project](https://en.wikipedia.org/wiki/Star_Trek_project)

<comment><USER17> NeXT had an Intel version as a hedge as well. Seems those two projects were destined to merge together.

<comment><USER18> That was actually their product rather than a 'hedge' for a while.

<comment><USER17> It started out as a hedge against their own hardware being an impediment to sales, then ended up being their entire business. I guess it was a good hedge to have!

<comment><USER19> Considering they had NeXTSTEP release versions running on x86, PA-RISC, SPARC, and its original home 68000, they did pretty well. I do wonder why the MIPS chips were ignored.

<comment><USER20> Maybe SGI didn't want to play ball...

<comment><USER19> Probably, but it just seems rather odd since MIPS had an open system spec and Windows NT had been ported to it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> It's finally happening! The increase in competition in both the foundry and architectural spaces is exactly what we need to push us past this stagnation of Moore's Law.

Intel needs to sacrifice Microsoft and make x86 a legacy architecture. There are huge parts of their processor designs that no one at the company modifies (or even understands) from one generation to the next, but which they cannot remove for backwards compatibility purposes. It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology.

<comment><USER22> > It's time to start fresh with a new architecture if they want to maintain > their reputation of having the most powerful technology.

They tried that, though. It was called Itanium and it went nowhere. Now, Itanium had all kinds of other problems and I wouldn't call its failure incontrovertible evidence against "Intel should make a new architecture", but I can understand why the company isn't eager to try that again.

Backwards compatibility exerts an powerful gravitational pull that is extremely difficult to break away from if you're not started a new platform ex nihilo (which Apple did for the iPhone).

<comment><USER21> > It was called Itanium and it went nowhere.

It was popular in its intended niche (HPC) for a while, but the value proposition was not sufficient. It dropped some x86 baggage but it didn't add anything fundamentally superior on top of it -- the ILP could easily be attained by having more cores on x86. To be honest I actually really like what they did with Itanium, but it wasn't a good enough innovation to break off the family line of backwards compatibility.

<comment><USER23> It wasn't intended to be a niche product. That was just how it ended up....

</comment></comment></comment></comment><comment><USER24> I have read multiple article but i have yet to see anyone mention it.

Isn't this about Security more then anything else?

IF it is about power, Intel SoC uses very little power during Power NAP. And any saving by switching to ARM should be negligible, when you consider the memory and I/O needed during Power NAP.

If it is about cost, Apple could have worked with AMD on Mac. I am pretty sure Ryzen and Vega works better on dollar / performance / Power. Especially on the Desktop Mac. Considering AMD has done special chip with console, I dont see why Apple couldn't use this model as well.

Since Intel's CPU has IME which Apple has no control, would that be a reason? Apple taking security in their own hands.

</comment><comment><USER25> This has been rumored for some time. I believe it's true, but then again, Apple kills off most projects before they see the light of day. Whether this ever makes it to consumers is the important question.

That being said, I've seen a number of comments about running iOS apps on Macs, or "convertible" Macs/iPads, and so on. I think those are off base given the supposed purity that Apple always talks about.

However, there is one thing I've never seen mentioned - a combined Mac/iOS binary. Similar to the old Universal binary for PPC/Intel, this could be a single app that just has different UX depending on the device it's run on.

I'm not sure why nobody has talked about that option, as it seems most likely to me, and gives more weight to the ARM everywhere strategy.

One "app", and it would be native, with native UI on whichever device it's running on (Mac/iOS/TV/Watch/etc.). Given Apple's investment into a streamlined complier that they rolled out with Watch, many if not most of the pieces are already in place for this.

It would not surprise me if that is the big announcement for this summer (or next at the latest).

<comment><USER26> I feel like they've been doing this to osX, starting with 10.9 it seems like a lot of the visual flair of iOS has filtered into the macOS environment.

I fear that this will dumb it down too much for the power users, and conversely over-complicate it for the average iOS user. I'd love to be wrong...

<comment><USER25> Yes, but this is not specifically what I'm talking about.

Think of something like MS Outlook - it's a big, complex app with lots of features. Now imagine that you only write the app once, but design two interfaces for it - one set for the Mac, and the other for the iPad. You compile through XCode, and upload to the App store. Apple notes that their are interfaces for both iPad and Mac, and posts it in both app stores.

Obviously the mechanics would not be exactly like this (I presume a manifest of some kind), but it should be pretty close.

For Apple, this would bring more developers onto their tooling (yes, even many of those that complain about XCode), and allow more developers to target multiple platforms with little extra effort.

In fact, one of the more interesting things is that Apple could even create new platforms that just require some interface additions and an updated manifest.

Have a bug in your code? One fix. One upload. One code review.

<comment><USER27> One basic problem - macOS has many, many more features than iOS.

There would be a lot more involved than redesigning the UI. The two platforms have fundamentally different class trees all the way from the view and user event classes down to core OS hooks.

There's some limited overlap, but not as much as you might expect.

Merging the two platforms and creating a UI-level split wouldn't be impossible, but it would be a huge job and would effectively mean a rewrite of both OSs - and probably of WatchOS and TvOS too.

It's not obvious this would be a good thing to do. MS tried it, and that was pretty much a disaster.

<comment><USER23> _> MS tried it, and that was pretty much a disaster._

Do you mean the Windows Runtime subsystem? How is it a disaster?

</comment></comment></comment></comment></comment><comment><USER28> Good news for Apple and overall progress, but sad news for those of us in the Hackintosh community. Apple's support for Intel CPUs is really what enabled the whole movement to get traction. I really prefer to see Apple moving toward standardized vs proprietary hardware options.

<comment><USER29> And inversely, I wonder how this news is for Linux on Mac hardware....

</comment></comment><comment><USER30> Sounds similar to big.LITTLE where by big are Intel cores for performance and power nap and maybe in the future less power intensive tasks are handled by LITTLE (ARM part).

</comment><comment><USER31> I think the problem is while ARM is good at lower power the moment you need sustained performance the power requirements shoot up and throttling begins.

The flagship ARM A72 and A73 are not adequate for true desktop class performance, somewhat catching up to Intel's low end core u laptop chips. It's increasingly looking like to get x86 level performance ARM would lose its low power advantages.

The AMD Zen on the other hand appears to be extremely efficient. I fiddled with ARM boards on and off for over 3 years excited by the possibilities of tiny form factor desktop class computing at laughably minimal costs with ARM SOCs. The reality is the extremely poor to non existent driver support and the 'effectively closed' ARM ecosystem is a deal breaker that left me disillusioned and strangely relieved with the the open PC ecosystem.

<comment><USER32> Oddly, ARM is eating the PC architecture from the inside. What's on your raid card? An arm. What's in your usb devices? An arm. What's in your SSD? An arm. A PC is beginning to look like a network of arms with an intel driving. How long will the intel core last?

<comment><USER33> Intel margins in that single chip are probably a few orders of magnitude of ARM royalties on all those embedded CPUs combined. Intel has little to fear from those chips.

On the other hand, Apple does seem to have the capability to design competitive desktop class CPUs, so who knows.

<comment><USER34> The absurd margins are in fact the reason why Intel need to fear ARM. It gives an incentive to lower the costs by designing them out of systems, even if it means sacrificing peak performance.

</comment></comment></comment></comment><comment><USER35> As long as it's still x86/AMD64 we're good. I really don't want to see PPC/Intel fragmentation again.

<comment> some-guy I thought it was mostly painless. Vast majority of applications provided an Intel binary right away without many issues. Rosetta wasn't _too_ terrible for simple tasks for the rest of them.

<comment><USER36> Rosetta was mostly painless because the raw performance of the Intel chips were multiples of the G4 chips in the macs (especially considering most systems doubled the available core count). Even so Creative Suite was slower as high performance plugins used altivec which was not emulated. This wasn't an issue for compatibility as the G3's never had it, so almost every app had non altivec code paths.

The overhead was mostly acceptable because the performance boost from the chip change hid a lot of it. Not to mention the CISC vs RISC thing worked in Apple's Favour. There are few PPC instructions that were required to be supported that couldn't be covered with a small number of x86 instructions.

There is not a publicly available ARM chip that has single thread performance anywhere near the i5 / i7 chips being used. Add to this the complexity of converting SSE to equivalent instructions and the overheads dealing with edge cases, I am not sure there is much chance of equivalent performance.

The one thing going for Apple with an intel -> arm switch is that almost all major apps a built using Xcode. When PPC -> x86 happened, the apps that lagged the most were the ones stuck on CodeWarrior and other 3rd party IDEs that apple never gave sufficient notice to port in advance of the general announcement (however I will concede that codewarrior was owned by Motorola so it may not have made the jump anyway).

I think if Apple does release ARM based macs, it will be with apps specifically recompiled, not using an emulation layer.

<comment><USER37> Performance per watt is pretty good on ARM. Most performance these days is about IO. How fast is the memory subsystem?

There are intel chips with 400 gigs per second memory subsystems. But the cores run at around 1.4ghz. Even a single thread with that much memory bandwidth can be much faster. Likewise with cache. If you have 32MB of cache, you can do quite a lot more processing in cache, and be lots faster for many things.

Considering that macbookpro laptops haven't really gotten better single thread performance in years - the things that really matter are IO, and performance within the power/heat budget.

ARM is competitive now within the macbook power requirements. The A10 chip is 75% as fast as the i7-6600U in some single core benchmarks. At a much lower power budget.

Within the chromebook space, where ARM and Intel laptops are currently competing - Intel often produces faster laptops. However, they are also often more expensive. Lots of people in many-many reviews say their ARM based chomebooks are too slow.

Having been through the raspberrypi 1,2,3 performance leaps, I can say that the latest one is quite usable as a desktop machine for word processing, web browsing and media playing.

The Samsung Chromebook plus with ARM is shipping, and the one with Intel isn't yet. The ARM one is cheaper, and the intel one is apparently more performant. Both have a similar battery life. The ARM one has better support of android apps. GUI app development is now 10x more active on ARM compared to intel, and the apps are optimized more for ARM.

GPU performance is improving faster on mobile chipsets than Intel is improving. Because of the demand from mobile VR applications. Some are predicting performance will be faster than laptops in a mobile power budget this year (see ARM Mali-G71). It's even faster than some nvidia discrete mobile chipsets. Since many apps are performance limited by the GPU, and not the CPU, I'd say ARM chipsets will win for many users low-mid users this year.

ARM is already taking over the low end laptop market. I won't be at all surprised if they take the mid range market by the end of the year. Especially as the market for chromebooks, and the low end laptops picks up. Because then more laptop class ARM based chips will go into production.

I think the demand will be there, as the android using market also want to use laptops that sync better with their apps.

[ED: add note about high performance ARM chips coming] High performance ARM chips are coming to super computers. The Post-K super computer by Fujitsu is expected to be one of the fastest computers in the entire world. If not the fastest. Will ARM take the super computer performance crown? I think so.

<comment><USER23> There will certainly be ARM-based laptops running Windows 10. Have you looked into that?

They are different from the Surface RT (Windows on ARM) machines because the also run traditional x86 apps (not just a port of Office).

<comment><USER37> Yes, good point. It will be interesting to see how popular they are this year. I also wonder if Office performance will be good enough for most people. I'm pretty sure MS know what they are doing with that, and the answer will be yes.

<comment><USER23> I'll buy one if they are cheap and include a sim slot. It would basically be a smartphone with Windows desktop software (mostly Office in my case) running on an 11.6-inch screen...

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> I often wonder why Apple doesn't purchase something like AMD. They could design their own x64 chips and GPU's.

<comment><USER39> AMD's license for the parts of x64 owned by Intel is conditioned on AMD not getting sold. The license wouldn't be transferrable to the buyer.

(So, yeah, AMD _could_ do their own slightly-different chip, using just the bits and bobs that are strictly theirs.)

<comment><USER40> I thought that deal goes both ways, AMD also licensing important parts of AMD64/x86_64 to Intel, so both sides would have a strong interest in keeping it alive in some form.

</comment></comment></comment><comment><USER41> This sounds weird. Are they going to have two versions of every executable? One arm and one intel? Or would this low power/power nap mode only support a tiny subset of functionality that apple chooses to include in their OS release?

<comment><USER42> You make it sound like they've never done that before (Universal binaries).

<comment><USER41> But those weren't both loaded into memory at the same time.

Thinking about this I've convinced myself that what will happen is the ARM core will periodically check for various statuses (i.e. connect to your imap/pop server and see if there is new mail) and turn on an indicator or perhaps wake the intel cores. Which is to say that the powernap/low power functionality will be restricted to either things apple delivers ootb or to a special API. Not as something that automatically migrates whatever workload is running on the powerful intel cores into a slow motion version of the same thing running on the ARM cores.

<comment><USER43> Yes, "power nap" is an existing feature that only does specific OS/apple specific operations (syncing, notifications, mail, calendar, indexing).

</comment></comment></comment></comment><comment><USER44> Apple should just buy AMD. It would only cost them about 15 Billion or so and they would get an x86 license. If they really want to control their own destiny this would be the way to go.

<comment><USER45> IIRC AMD's cross-licensing deals with Intel over certain key patents are null and void if AMD is bought, which puts a real damper on the main reason anyone would consider purchasing the company.

<comment><USER46> I believe this is the agreement you're referring to and it looks like it applies even to a change in ownership of 50% of the company:

[https://www.sec.gov/Archives/edgar/data/2488/000119312509236...](https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm)

<comment><USER44> Does Apple even need to own a majority ownership to control the company? Couldn't they just purchase 49.9% of the company and set up the board of directors in their favor? With that much stake getting the company to do what you want it to do wouldn't be that difficult it seems.

</comment></comment></comment></comment><comment><USER47> Totally expected, because they need to increase performance and lower battery consumption. Now the extent of taking job from main Intel's CPU and spectrum of possibilities of ARM coprocessors are yet to be seen. I can see it doing some hardware related tasks that do not interfere with actual higher stack of macOS and x86 space. But this is all pretty common. This title looks little clickbaity imho.

<comment><USER48> I expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either.

(1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only exist in separation: eg. IBM TIMI allows to move applications across physical processor ISAs, while various clustered virtualization implementations can move live VMs across distinct hosts.

<comment><USER34> bit.LITTLE isn't a mixing of architectures, it's a mixing of micro- architectures. And the fact that big.LITTLE designs are commonly used now, and even Apple adopting their own version of it in their latest SoC is a validation of its benefits.

<comment><USER48> Prior approaches to mixing architectures in one system (and actually moving applications at runtime dynamically, as in big.LITTLE,) were ...

</comment></comment></comment></comment><comment><USER49> I consider this a mostly tactical move to get better prices out of Intel.

Sure, the plan as presented might work, but the migration will take years, be messy, and lead to lots of unhappy customers due to poor emulation performance, dropping legacy app support, bugs in a new architecture etc.

</comment><comment><USER50> This is interesting given Microsoft's move to full windows-on-arm (and not that travesty that was Windows RT). Something I'm certainly looking forward to—if not only for the devices that it creates, but a chance for more open mobile computing.

(Sh|C)ould this be a concern for Intel?

</comment><comment><USER32> Can you just imagine how long the battery would last on an arm based macbook? Days?!

<comment><USER51> It is actually quite difficult to beat Intel on power efficiency once you start talking about laptop class CPUs. The combination of Intel's advanced fabrication tech and their highly efficient core family of microarchitectures gives them a significant advantage outside of the ultra-low-power space.

<comment><USER32> I don't think that's true. Arm chips just don't clock as high as intels can, and no one* cares about clock speed any more. That ship has sailed. Multiprocess web browsers will drive the sales of massively multicore arms (with tons of ram!), and intel will be sunk.

<comment><USER51> It's not just about clock speed. While Intel Core CPUs don't scale down to power budgets as low as ARM cores, they are impressively efficient on a perf/watt basis. Smart phones achieve high battery life mostly by being very aggressive about reducing CPU load in software (see iOS killing apps the moment they go into the background). General purpose operating systems don't work like that so there's more reliance on the hardware to keep power draw down.

<comment><USER52> _they are impressively efficient on a perf /watt basis_

Is that true? I thought people were trying out ARM rack servers because of the power efficiency vs perf.

<comment><USER51> The key word there is "trying". ARM servers have had a tough time gaining traction in no small part because the hoped for power efficiency gains have not been realized.

</comment></comment></comment></comment></comment></comment><comment><USER53> Anyone knows how far is Apple from getting the following desktop system as one SoC?

\- 4GHz 12-core 64-bit ARM OooE with 256KiB L2 cache per core

\- 12MiB of L3 cache

\- Integrated graphics with 128MB eDRAM

\- PCI-Express buses

\- 35 GB/s DDR4 memory controller

\- 5-65W power usage

<comment><USER6> 4GHz 12-core in 65W isn't going to happen. (Intel is currently at 2.1GHz: [http://ark.intel.com/products/93356/Intel-Xeon- Processor-D-1...](http://ark.intel.com/products/93356/Intel-Xeon- Processor-D-1567-18M-Cache-2_10-GHz) )

Hurricane could probably run at 3GHz but to get to 4GHz might require serious work. Apple hasn't used eDRAM but in theory they could adopt it. The rest looks like no big deal.

</comment></comment><comment><USER54> I'd always be open to Apple putting a supercharged ARM chip in a prosumer laptop. We could always run a variant of linux on the laptop if OS X were too buggy.

<comment><USER55> Assuming the bootloader isn't locked down

<comment><USER54> There's always that risk: they'll do some sort of jail like they do with iOS.

</comment></comment></comment><comment><USER56> About two weeks ago I commented on a post here (a concept design for a new mac pro) joking that the next mac pro would probably run and arm CPU and have the ram soldered on.

Looks like I was on to something

</comment><comment><USER57> >Is it IBM compatible though?

Man, I hated hearing that question. It was so utterly retarded, but trying to explain to the person who asked why it was a retarded thing to say always came off as damage control.

>Yep, not IBM compatible. Not interested.

Maybe Apple can get away with their own chips now. It sounds like they just want to take more R&D away from Mac though. "Just stick an A10 in it."

<comment><USER58> iOS applications are now compiled to an intermediate representation which is then translated to the target CPU instruction at install time.

macOS applications could similarly be built to run on multiple instruction sets with basically no effort from the developers.

Perhaps initially it might be restricted to first-party apps, or maybe AppStore apps, but having fat binaries is something macOS developers are used to doing ...

The difficult bit would be the runtime migration from x86 to ARM and back. For processes that can restarted, it's easy. For running, stateful applications it would be more difficult.

But I think things like Mail.app already use a backend daemon to manage their datastore: you could suspend the UI process and restart the backend daemon on the low-power CPU fairly simply ...

<comment><USER59> From what I understand bitcode is still somewhat architecture dependent and wouldn't work well for ARM<=>x86 translation.</comment></comment></comment>


Google's SVP of Knowledge, Alan Eustace, Is Leaving - <AUTHOR> http://techcrunch.com/2015/02/03/alan-eustace-google/

<comment><USER2> Xoogler here. One of the things I remember (and respected) most about Alan was his promotion of the Unconscious Bias at Work training. I found it to be HUGELY valuable, and would recommend it for anyone hiring or managing at a business of any size... startup to corporate.

You can see a public version of the Unconscious Bias training on the Google Ventures video library: [https://www.gv.com/lib/unconscious-bias-at- work](https://www.gv.com/lib/unconscious-bias-at-work)

<comment><USER3> Alan has also been a great supporter of Women Techmakers, both in terms of internal support and physically going to all the events; I've seen him more at women-in-tech events since leaving Google than I ever did while working there!

</comment></comment><comment><USER4> Interesting. I always thought Alan was one of the most quietly effective executives I've worked under. I wonder what the new culture & executive structure of Google will look like after this shake-up.

</comment><comment><USER5> Well, I guess he was effectively demoted after Sundar's takeover of core products. You would expect some folks leaving after that reorg.

<comment><USER6> Alan is extremely well respected at Google. I seriously doubt Sundar had anything to do with it. Alan has effectively been retired for several years now (ever since he took a hiatus to work on the stratosphere jump).

<comment><USER5> I don't disagree with your point. To clarify, I was stating that it's expected to hear people leaving following a decrease in responsibility; I was not trying to imply that such change has been necessarily involuntary. It could very well be the other way around, in fact, i.e. a reorg happens as a result of one's intent to retire in the near future.

<comment><USER6> Yeah. That makes sense. I guess demotion makes it seem like it wasn't his choice. I would slightly change your statement to say "he had effectively resigned ever since he took his initial leave of absence."

</comment></comment></comment></comment><comment><USER7> nice knowin' ya, Alan.</comment>


Instagram kept deleted photos and messages on its servers for more than a year - <AUTHOR> https://www.theverge.com/2020/8/14/21368602/instagram-kept-deleted-photos-messages-on-servers-year-bug-fixed <comment><USER2> Whenever someone publishes an article like this, I want them to find out what its like when you reach the threshold of 100000 individual delete requests per second which ends up being five million actual deletes when you factor in all of the associated references to the item being deleted and its metadata. Then I want them to find out what happens when you have to propagate those deletes across geographically distributed data centers, clear a geographically distribute cache and do it in a way that minimizes user facing errors and guarantees consistency. Finally you have to also ensure that deletions don't effect any business facing applications since ad revenue and metrics are all generated from certain types of data.

These people imagine you just rm -rf a file and run a few SQL queries, you literally can't just delete data. I've worked at the scale of Instagram before. Literally nothing works like that at that scale, the person who wrote that article should have called up someone from Instagram and had them explain at a really high level how complicated deleting data is at large scale.

<comment><USER3> Hi. I also work at this scale. It doesn't take a year to delete the data. Be upfront with your users:

'Your delete request is being processed. No one will be able to see this item though it may take up to three days for the data to be completely removed from our servers'

This is not a technical challenge, it's an issue of priorities and Facebook doesn't prioritize privacy. They were able to release a TikTok clone in a few months, but can't solve deleting data?

<comment><USER4> >It doesn't take a year to delete the data

It does if you have cold backups that take a year to cycle out. They're often offsite, compressed, and incrementally hashed so finding individual items and removing them is really hard -- you're much better off just waiting for them to expire, and a year isn't an unreasonable amount of time.

<comment><USER5> The article specifically states this data was downloaded using the "Download Your Information tool on Instagram". The undeleted data wasn't from a cold backup or any backup, it was still on production systems.

<comment><USER4> If this is a GDPR "right to access" request, which most "download your information" tools are, then backups are included. See [https://law.stackexchange.com/questions/27625/gdpr- complianc...](https://law.stackexchange.com/questions/27625/gdpr-compliance- does-it-extend-to-database-backups-and-archived-records)

<comment><USER5> Doesn't that link show that the how backups related to GDPR is still up for debate? The accepted answer that says they are included has 3 upvotes and there is an answer that says no they aren't included that has 2 upvotes. Either way, the legal requirement is a separate issue from what Instagram is actually doing. If that download tool is automated, I am rather confident in saying that it isn't combing through year old backups to get data.

<comment><USER4> Ever wonder why "download my data" usually takes a few hours/days on most services before you receive the download link in your email? I promise you compiling the production data doesn't take that long.

Backups are covered under GDPR, although when a user requests erasure you can say "your data will be rotated out in X months/years". Not sure how this applies to access, but I assume it's similar: [https://ico.org.uk/for- organisations/guide-to-data-protectio...](https://ico.org.uk/for- organisations/guide-to-data-protection/guide-to-the-general-data-protection- regulation-gdpr/individual-rights/right-to-erasure/#ib5)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> > "The researcher reported an issue where someone's deleted Instagram images > and messages would be included in a copy of their information (...) We've > fixed the issue"

This makes it sound like they consider "you could see it" the issue, not "we were still keeping it". In other words, the fix was to hide it, not to delete it.

If I were the Irish DPA (and actually wanted to do my job and had the resources to, instead of being intentionally lazy/crippled to attract tech firm headquarters), I'd definitely be asking for retention plans and evidence that the data is now being removed in a timely manner, and start issuing fines (small ones for past transgressions, big ones if they keep doing it or don't have a decent plan how to make sure to get rid of data they shouldn't be having).

For comparison: Deutsche Wohnen (large real estate) got slapped [1] with a 14.5 million EUR fine for over-retaining sensitive tenant data and not having an automated system to delete it.

[1] [https://www.dataprotectionreport.com/2019/11/first-multi- mil...](https://www.dataprotectionreport.com/2019/11/first-multi-million-gdpr- fine-in-germany-e14-5-million-for-not-having-a-proper-data-retention-schedule- in-place/)

<comment><USER7> Why small fines initially? I'd like to see privacy fines being used to make lots of money like traffic fines are used today. It's a way to tax tech companies in your jurisdiction with the added benefit of improving privacy.

<comment><USER8> Because the goal is compliance, not to put companies out of business. When the laws were first enacted everybody was screaming that it was just to put companies out of business. Now they are wondering why the small initial fines.

It's simple: change your ways and use the initial fines as a wake up call. If you then do not wake up and persist the fines will get heavier and heavier until you _will_ pay attention.

A Dutch hospital managed to get to the third round of fines and they weren't all that happy afterwards. 460K Euro fine for a _single_ instance of ignoring the regulators on a _single_ individual.

Believe me when I tell you they have understood now.

The initial fine was zero, just a warning to improve.

The case revolved around a very minor dutch celebrity whose data was reviewed by hospital employees that should not have had that access.

<comment><USER9> > Because the goal is compliance, not to put companies out of business.

There's middle ground between "we take 100% of your revenue" and "we take 0.001% of your revenue". Given that we're not this lenient with private citizens and small companies, why should we be with international corporations?

<comment><USER10> It's not 100%. The fine can get up to 4% global revenue or 20 million Euro, whichever is higher.

<comment><USER8> There is still some unclarity as to whether or not multiple fines can be issued for different transgressions, there hasn't been such a case yet and nobody has gotten close to the limit so for now this is still grey. But I think that once fined at that level no sane CEO is going to risk getting a second such fine in the same year or even at all.

</comment></comment></comment></comment></comment></comment><comment><USER8> This sort of practice is not limited to just Instagram. Plenty of places that do soft deletes when they should be doing hard deletes. Data life-cycles are about the poorest understood subject in startup land. Ingestion is usually top notch, friction free and heavily automated. Deletion - assuming it even exists - is semi automatic or even manual, full of friction and usually incomplete or broken.

You see a similar pattern with respect to signups vs account cancellation.

The weird thing to me is that it is usually the _marketing_ department and not the legal or the compliance department that has the upper hand in these data retention discussions. Fortunately thanks to the GDPR this is now changing and slowly companies are coming around on this.

<comment><USER11> I think just about everything should be a soft delete, however you need a time limit where you sweep those. Ideally you would even give the user an option to accelerate that (as much as technically possible) if they really want something gone.

<comment><USER12> "If we tell people that we're going to delete their data then we need to do that." \-- Chairman Zuckerberg

I understand the user utility of a brief soft-delete period, but that hard- delete sweep should be performed on a fairly tight delay.

</comment></comment></comment><comment><USER13> > When you delete something from Instagram you expect it to be gone for good

Ohh do I have some bad news for you.

Seemingly everyone in this industry can't or won't design databases and applications to actually allow for data to be deleted.

<comment><USER14> Deletion is effectively a failure mode, and engineering tends to focus on the happy path.

<comment><USER13> Only if you treat it like one.

Arguably a well designed system should be built to handle having certain user data deleted without interrupting or breaking anything.

</comment></comment></comment><comment><USER15> We know that HN is visited by a fair share of Facebook employees.

Can some of you weigh in (anonymously?) on this topic? Do you guys do hard deletes of user data instead of just soft deletes? If so, are logs or backups kept? For how long?

In other words: if I'm a user of $POPULAR_SERVICE and I delete my account at time t0, is there a t1 > t0 after which every trace of my data is gone from the platform?

My (cynical) guess is no, but I hope I'm wrong :)

<comment><USER16> DELETED=TRUE

<comment><USER17> This is how most services work at scale. It's much cheaper to set a flag than actually delete an entry in a database. The data can then be scrubbed by some periodic maintenance process.

<comment><USER8> Only that doesn't typically happen. It just sits there, for _years_ or until the company goes bust.

The typical reasoning is that marketing wants to hold on to the data, they will never ever say 'ok, enough, you may delete it' because there is this infinitely small chance that they can re-activate an account, market to it for some other product (no matter that that is against the GDPR) or to sell the data to some third party if there ever is a cash crunch or panic. They see data as having positive value no matter what, whereas data that you shouldn't be holding on to is actually a liability.

</comment></comment></comment></comment><comment><USER18> Based on the conversation here, it would seem like deleting data is an unsolved problem in CS, or some of you just make it overly complex. Every system I have built had deletes, because it is the right thing to do... No team I've been on got away with not doing the right thing because it was hard. We put our heads down and got it done. Smh.

Some of the engineers at these companies forgot their morals as soon as something got hard I guess.

</comment><comment><USER19> Oh they fully delete those? I didn't actually expect messages to be erased when we un-send it.

<comment><USER20> I genuinely laughed at this - I thought the same thing!

If you ever downloaded your own account data, I think OP and other concerned posters would understand how much data companies retain and this wouldn't come off as a surprise.

Snapchat data for example, has chat logs, snap history, what accounts you've added/requested as a friend, and friends that have added you all retained. I bring this up as an example because the idea behind this application was to send a message that would disappear after a variable amount of time :)

<comment><USER19> I did download it. Before deleting my account. Just put it in a hard drive since it had all messages, photos.

Time to dig into it.

</comment></comment></comment><comment><USER21> > Pokharel discovered the bug in October last year and says it was fixed > earlier this month (2020, august)

Shouldn't there be fines for this?

Took almost an year _after_ being reported.

<comment><USER22> A fine for what? Not fixing a minor bug in a timely fashion? That's not a road we want to travel down.

<comment><USER8> This is not a 'minor bug'. This is a major oversight and possibly a regulatory issue. The user owns the data. The user has rights.

<comment><USER19> Instagram doesnt use the word 'delete'. It uses 'unsent' for messages.

So removed from other person's chat. Still associated with your account

I have my account data from last year. Time to dig into it and sue instagram.

Oh wait. I'm not in the EU. I'm in India, where they can even sell my info. So they definitely didn't delete it

<comment><USER8> Pulling linguistic tricks typically does not amuse regulators.

<comment><USER22> I'm curious what regulatory issue you think is in play here?

<comment><USER23> Gdpr has a right to deletion within 30 days. Companies have been fined for failing to do so.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> I assume all companies except may be Apple and google never delete the data even if they provide the delete option. For example, I still keep getting emails from mint saying that my credit score has changed even though I deleted all my info from my account.

</comment><comment><USER22> Some real (understandable) ignorance about how the tech industry works in this article. There should be _no_ expectation that Instagram ever deletes anything permanently from their servers.

The bug was showing users photos that were internally marked as deleted. Not that the photos were not in fact removed from Instagrams servers.

<comment><USER25> > There should be no expectation that Instagram ever deletes anything > permanently from their servers.

No, there should be this expectation. If I have a photo of myself that I'm not comfortable being saved somewhere, there should be an expectation that when I delete this from a service, that service will actually delete it.

The expectation should be that the service will do what it said, not that it hid everything very well.

<comment><USER26> Unfortunately this isn't how computer storahe works. This is why the military have acid baths for their disk drives.

<comment><USER27> In this particular case they are actively not attempting to delete the image at all, a big difference.

</comment></comment></comment></comment><comment><USER28> And then run facial recognition on them? Nice way to capture our biometric data on the cloud :D

</comment><comment><USER29> What is not revealed is that the actual bug was that an end user found the deleted data, not that the data wasn't deleted. Should be no surprise that Instagram would have similar data retention policies as its parent company.

</comment><comment><USER30> Maybe you shouldn't share that info in the first place? Even if the provider(Instagram in this case) acts in good faith and deletes the data, 3rd parties would still own it(i.e US sec agencies, various crawlers etc)

</comment><comment><USER31> And here I am dreaming of a world where companies do real deletions of data when a user requests (and also deleting older transactional data that has outlived its utility, including regulatory requirements) and storage prices being lower with a slightly smaller (steady) market for it from the major companies.

On the other hand, storage prices seem to be low enough for all these companies with bulk, long term contracts that developers wouldn't bother doing real deletes of data.

<comment><USER32> > storage prices being lower with a slightly smaller (steady) market for it > from the major companies.

I suspect that big companies in the market help justify manufacturer R&D into larger and faster and helps justify production capacity. I think we'd have smaller, slower, and slightly more expensive drives without their demand. But, speculation only.

</comment></comment><comment><USER33> I'm surprised Social Media networks don't convey when your data is actually 'deleted'. This approach seems a little more evident in the "archive" status on Instagram.

A flag to mark data for deletion makes sense at scale.. given the number of other automated processes that run more often than a few times a year.. the user should be in control of their information and intent.

</comment><comment><USER34> Few months ago I requested my data from Discord. Interestingly enough, it didn't include my messages from server that was deleted some time before that.

<comment><USER35> Internal sources at Discord confirmed to me (a few months ago, so may be outdated) that deleted messages are fully gone from the servers within hours of deletion.

Deleted files hang out longer but are gone within a month.

</comment></comment><comment><USER36> I don't know how many times this is going to have to happen before people understand this: when you put something online, assume it is essentially public. Forever. If you don't want it to be public forever, don't put it online.

<comment><USER37> This is victim blaming and only reinforces the status quo. The way things are isn't the way things have to be. We can change the rules if we work together. Or we can give up and blame the victims.

<comment><USER38> You can have Instagram delete that photo when you change your mind, but how about the friend who saw it and saved it, or the already-illegal bot that crawled the site and archived it?

"Changing the rules" can reduce data availability, probably well enough for most purposes, and that's good. But it's simply strictly true that once you publish something, you cannot assure it's unpublished. And everyone should know this and act that way.

</comment></comment></comment><comment><USER39> I want to know if the photos are securely deleted. It's not enough that the mere reference to a file is gone. I want everything overwritten with zeroes, and the photo made properly irrecoverable.

<comment><USER40> Always encrypt the data at rest, and delete by deleting the key is likely how this would be done. This way you can also delete e.g. tape backups without actually loading the tape and re-writing the whole thing with certain portions deleted, which is not really practical.

<comment><USER39> Yes, and you could also _queue_ files for deletion at a later stage by throwing away the encryption key for a large batch of files which have been queued for deletion.

</comment></comment></comment><comment><USER41> Ok. I need help recovering photos on Instagram

</comment><comment><USER42> Data that I wanted to delete isn't necessary for the functioning of the service, so doesn't that mean the GDPR requires it to be hard-deleted within a reasonable time?

</comment><comment><USER43> And if they delete it faster another vocal faction will start to whine that they enable racists, sexists etc to abuse.

Tomorrow at slate "How instagram permanent delete perpetuates white supremacy"

There is no policy that could satisfy all.</comment>


Tell HN: Chicago HN meetup Thursday, May 7 @Hopleaf - <AUTHOR>

There was talk last week of a Chicago Hacker News meetup this Thursday at Hopleaf.  Vote up the time that works best for you. <comment><AUTHOR> 7pm

</comment><comment><AUTHOR> 6pm.

</comment><comment><AUTHOR> 5pm.

</comment><comment><AUTHOR> 9pm

</comment><comment><AUTHOR> 8pm</comment>


Blood Sweat and Pixels: The Turbulent Stories Behind How Video Games Are Made - <AUTHOR> https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234/ref=sr_1_1?ie=UTF8&qid=1523239830&sr=8-1&keywords=blood+sweat+and+pixels <comment><AUTHOR> I have no affiliation with the author, but I bought this as I love the 'Split Screen' podcast from Kotaku and this is written by one of the podcasters. It is a very insightful look into how video games are made, which is worth a read by anyone who is interested in the video game industry.</comment>


Equifax had 'admin' as login and password in Argentina - <AUTHOR> http://www.bbc.com/news/technology-41257576 <comment><USER2> Discussion from yesterday: [https://news.ycombinator.com/item?id=15233399](https://news.ycombinator.com/item?id=15233399)

</comment><comment><USER3> And funny enough these guys boast so much internal and external audit with bunch of iso standards and certifications!

</comment><comment><USER4> One thing that struck me about Equifax, and a lot of other companies, is the complete patsy types that get hired into executive CIO positions. It seems to me that the CIO should be a highly technical, tactical, hands-on type of person that knows the ins and outs of every system in use. But companies focus too much on hiring "executive level" people that just look good externally. They might communicate well but their technical knowledge is so far gone that they are simply a face. BTW, it has nothing to do with age as I've seen 65+ CIOs with extremely sharp technical skills. Companies need to do a better job of grooming their own highly competent staff to be good executors, not just hiring somebody who "can lead a global team of IT professionals delivering the technology strategy".

<comment><USER5> > Companies need to do a better job of grooming their own highly competent > staff to be good executors

Given that Equifax is unlikely to face any meaningful punishment over this ... why? Until the laws change to deincentivize this type of behavior, market forces have decided that a good face is the best choice for a company's profit margins. Corporations will always game for maximum profits, so it's up to us to set the parameters so that they work in a way that is healthy for society.

</comment></comment><comment><USER6> It seems that Equifax needs to be sued out of existence...no settling.

This would send a message that companies need to protect sensitive data or face severe consequences.

</comment><comment><USER7> This is amazing; a couple years ago, I was denied a job at Equifax due to "inexperience".

Maybe I was inexperienced, but I kind of learned that you don't stick with the default passwords for everything pretty early on.

</comment><comment><USER8> [https://www.youtube.com/watch?v=JSZTPuJ14Ro](https://www.youtube.com/watch?v=JSZTPuJ14Ro)

</comment><comment><USER9> Glad to know my home router defaults have better security than the company responsible for half the country's SSNs...

</comment><comment><USER10> "Its researchers explored the portal and within found a list of more 100 Argentina-based employees, the blogger disclosed.

Using this list they were able to uncover the workers' company usernames and passwords, which turned out to be matching words in each instance."

Unreal. So it wasn't just one admin, it was everyone.</comment>


Android is the new Win32, the new Java and the new Flash - <AUTHOR> http://blog.neonto.com/?p=291

<comment><USER2> If you told me my product was the new Win32, the new Java, and the new Flash, I'd immediately apologize and kill it.

It's like being labeled "a young Justin Bieber".

<comment><AUTHOR> If you were a CEO and your product had Win32-like traction, how would the board react when you told them that you want to kill the product because it's too popular? :)

Android certainly doesn't have hipster credibility. It's often pretty clunky.

Then again, software runtimes are not indie bands: there's no reward for being exclusive.</comment></comment>


SoftBank's Arm Fired Its China CEO – But That Doesn't Mean He's Leaving - <AUTHOR> https://www.bloomberg.com/news/articles/2020-06-20/softbank-s-arm-fired-china-ceo-wu-for-starting-competing-fund <comment><AUTHOR> For those who have trouble with the link:

[https://outline.com/hdA8aJ](https://outline.com/hdA8aJ)</comment>


Are the new Macbook Pros i5 & i7 vPro's Quad Core? - <AUTHOR> I wanted to know if the new Macbook Pro's (April 2010) are quad core or dual core processors? I've poked around on the intel.com site and I can't tell. Thanks! <comment><USER2> Below are some notes-to-self that I made back in January when I was researching laptop purchases for friends and family. It includes the best information I found; unfortunately, the non-HN links in the below are in German.

Summarizing the linked content: It's been a while, but my impression of the best choice was the 520M. The 540M gave a bit more performance, but depending on price bump wouldn't be worth it. The 620M actually degrades when running 3D rendering on the integrated graphics (maybe not an issue in the new Macbooks with their dedicated graphics switchover); speculation was that it was hitting its thermal envelope and stepping down.

Integrated graphics on the 3xx are significantly slower. IG on the 4xx are a bit slower. However, it's only at the 5xx level that hardware support for 256 bit AES, and a few other things, get turned on.

This is from memory; I may have mis-remembered something.

Also, speculation was that the next revision would be out in summer and that there was a good deal of room for improvement in efficiency / power reduction. (I think this last may have been speculated at anandtech.com (or maybe elsewhere), in an article I don't have linked below.)

\----

1/21/2010 1:14:27 PM

[http://www.notebookcheck.com/Test-Intel- Core-i3-i5-i7-Prozes...](http://www.notebookcheck.com/Test-Intel- Core-i3-i5-i7-Prozessoren-Arrandale.25078.0.html)

via

<http://news.ycombinator.com/item?id=1066938>

1/24/2010 12:54:01 PM

The notebookcheck article cites these further articles:

NBC vor Ort: Intel stellt neues Prozessoren-Line-up vor [http://www.notebookcheck.com/NBC-vor-Ort-Intel-stellt- neues-...](http://www.notebookcheck.com/NBC-vor-Ort-Intel-stellt-neues- Prozessoren-Line-up-vor.24048.0.html)

Test Dell Studio 1558 Notebook [http://www.notebookcheck.com/Test-Dell- Studio-1558-Notebook....](http://www.notebookcheck.com/Test-Dell- Studio-1558-Notebook.24437.0.html)

</comment><comment><USER3> dual core.

the wikipedia article on the i5's show that the mobile i5's are dual core while the desktop i5's are quad.

<http://en.wikipedia.org/wiki/Intel_i5>

<comment><USER3> did some more research.

all the i5/i7 macbooks seem to be running on the Arrandale line, so that would make them all dual core.

it looks like the top i7 macbook is using the Intel Core i7-620M processor. the two i5 models are the Intel Core i5-520M (2.4GHz) and the Intel Core i5-540M (2.53GHz).

<comment><AUTHOR> Any chance the 15" i7 has quad core? I know battery life is precious but I wish they would put one hardcore laptop out and price it high if needed.

<comment><AUTHOR> I found the answer. Sorry. Dual core on the 15" i7. <http://ark.intel.com/Product.aspx?id=43560></comment></comment></comment></comment>


Nginx now supports Websockets - <AUTHOR> http://nginx.com/news/nginx-websockets.html <comment><USER2> What nginx needs to become the ultimate platform, in my opinion, is to provide an API for interacting with WebSockets by transient processes (such as PHP). That way it acts as a surrogate pub-sub handler, whether or not your instance stays as a running process.

That'd be a dream for what I want to do. At best, we have to use Node.js as a WebSocket provider and tie it in with the PHP sessions, etc. Not as simple as I'd like.

<comment><USER3> You mean like <https://github.com/wandenberg/nginx-push-stream-module>? :)

<comment><USER2> That does look intriguing. I'll have to do some research to see if its suitable to my use case. Thanks Martin.

</comment></comment></comment><comment><USER4> This is great. At dotCloud we've reluctantly ported our distributed routing layer (<http://github.com/dotcloud/hipache>) from Nginx to Node + node-http- proxy, because we needed 1) high-volume dynamic configuration and 2) websocket support.

Problem 1 can already be addressed by combining a Redis backend and Nginx's awesome Lua scripting engine (<https://github.com/samalba/hipache-nginx>). Now that problem 2 is solved as well, we might be able to port Hipache back to Nginx in the future :)

Go Nginx!

</comment><comment><USER5> Earlier discussion: <http://news.ycombinator.com/item?id=5240356>

</comment><comment><USER6> This announcement is a little light on details. What does Nginx supporting WebSockets even mean? Isn't it just looking for ws:// and proxy-passing that on to your application?

<comment><USER7> It's looking for the upgrade header in HTTP, and then, yes, proxying that connection.

<comment><USER8> Yup, nice to have this built in rather than relying on an additional layer (Varnish, HAProxy, 3rd party module, etc.)

</comment></comment></comment><comment><USER9> Wow, realtime upvoting/downvoting for everyone now :-)

</comment><comment><USER10> So in practical terms how does one setup backends to use WebSockets. For example, suppose you have nginx in front of a bunch of Unicorn or Rainbow processes and there are two clients that have made websocket connections. Consider a chat application. One of them sends a websocket message and the backend that receives it needs to push the message along the other websocket connection. But how does it know which backend to forward to? What is the intended idiomatic way of maintaining the necessary state?

<comment><USER11> Think of it like an HTTP request, except a two-way and very long-lived. Not too unlike Comet except with a secure-by-design approach. <http://en.wikipedia.org/wiki/Comet_(programming)>

<comment><USER10> I've never dealt with Comet. I need the long detailed answer for complete noobs.

<comment><USER12> The old version of that wikipedia article had a bit more background explanation: [http://en.wikipedia.org/w/index.php?title=Comet_%28programmi...](http://en.wikipedia.org/w/index.php?title=Comet_%28programming%29&oldid=215165715)

<comment><USER10> If I am understanding correctly the suggestion is to have a distributed hash table that any backend can lookup to find the other backend it should forward to. And since the distributed hash table is critically important persistent data I'm assuming that using something like Memcached is not a good idea? What would be advisable instead?

</comment></comment></comment></comment></comment><comment><USER13> So hopefully heroku will soon be able to support Web Sockets instead of only xhr-polling

[https://devcenter.heroku.com/articles/http- routing#websocket...](https://devcenter.heroku.com/articles/http- routing#websockets)

[https://devcenter.heroku.com/articles/using-socket-io- with-n...](https://devcenter.heroku.com/articles/using-socket-io-with-node-js- on-heroku)

<comment><USER14> They are busy trying to be able to support Rails apps for now.

</comment></comment><comment><USER15> Does the backend which nginx talks to have to speak the Websocket protocol?

If this is the case, and you're running a pure TCP application like IRC, you still need a separate Websocket-to-TCP bridge application running on the server to sit between nginx and your IRC server. How is this an improvement from the status quo? ("IRC" is just an example, you can feel free to replace it with your favorite protocol.)

Granted, this change makes life a little easier for users behind outbound- restricting firewalls, since you can now multiplex both HTTP and IRC on port 80. But IMHO it would be more logical to just have nginx directly proxy the IRC server to the client-side JS over Websocket.

Then again, maybe this patch is as close as it's possible to get without major revisions to the Websocket protocol: With Websocket's non-optional framing "feature," you might need IRC-specific knowledge to translate an IRC stream into frames in a way that won't break anything.

Any Websocket experts are welcome to weigh in!

<comment><USER16> > Does the backend which nginx talks to have to speak the Websocket protocol?

Isn't that what the "supporting websockets for the proxying layer" statement means? I don't even know why you'd expect anything else to happen.

> it would be more logical to just have nginx directly proxy the IRC server to > the client-side JS over Websocket.

Again, I don't see the logic there at all. There is a TCP proxy external module you can compile in (and that was how you'd get it to proxy websocket connection before). But you want nginx to proxy and arbitrarily translate between some random protocol and transport of your choice.

> With Websocket's non-optional framing "feature," you might need IRC-specific > knowledge to translate an IRC stream into frames in a way that won't break > anything.

Yes framing is a feature. Why are you including in quotes sarcastically implying it is a bad feature.

It sounds like you just need a firewall with some rules, if you just want plain TCP connections to be forwarded to your backend, why involve a nginx at all then?

<comment><USER15> I was thinking that a prominent use-case for JS websockets would be writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL is some TCP-based protocol like IRC that was developed years before websockets existed.

> Why are you including in quotes sarcastically

Because framing means the websocket spec can't easily support this use case.

> if you just want plain TCP connections to be forwarded to your backend

That's exactly what I want -- _from a Javascript client in an unmodified browser_.

AFAIK I can't get such connections in JS clients; I can only get the Websocket protocol.

I was thinking some cool hacks become possible if you _could_ talk to an arbitrary TCP server from JS, using nginx as the middleman (with all its scalable non-blocking goodness).

Too bad Java is going the way of the dodo; Java applets could do TCP connections to the same origin back in the '90s.

<comment><USER16> > writing a JS client for $PROTOCOL which runs in the browser, where $PROTOCOL > is some TCP-based protocol like IRC that was developed years before > websockets existed.

Yes that would be cool. Websockets make it doable. Framing is not as big of an issue. Most TCP based protocols (save for file streaming) already have some messaging at a higher level. In IRC you can think of the line as a message.

Almost every protocol I built on top of the TCP transport had to have framing and I had to mess with buffers, message headers, terminators, partially filled messages.

> I can only get the Websocket protocol.

One cool new feature is WebRTC it should support a datachannel connections and peer-to-peer (now you can make the web server a peer as well). So there it seems would be another case of streaming binary data to the server.

> I was thinking some cool hacks become possible if you could talk to an > arbitrary TCP server from JS,

Yeah that would be cool. JS code would instead have to dealt with websockets or WebRTC data channels. It wouldn't open a TCP, socket, bind, listen, connect all those things. Now on the server side you can anything you want. For example I like the web STOMP adopter that RabbitMQ people have. You can effectively send and receive MQ (STOMP) messages from a browswer to an exchange. That is cool. There are VNC viewers built with websockets and canvas. So it is doable but I don't think its place is to put in nginx as a standard compiled in features. These all can be plugins.

</comment></comment></comment></comment><comment><USER17> What's the difference between this new support and the nginx-push-stream module? <https://github.com/wandenberg/nginx-push-stream-module>

<comment><USER18> nginx-push-stream handles the websocket connections itself and exposes a pubsub channel, so that your backend app doesn't have to worry about holding connections open. Whereas I believe the new websocket functionality allows you to proxy to websocket-enabled backend apps.

<comment><USER17> Good comparison. Thanks.

</comment></comment></comment><comment><USER19> Is there any documentation on usage?

<comment><USER20> Not really, but I used this link: <http://trac.nginx.org/nginx/changeset/5073/nginx> to set up this config: <https://gist.github.com/octaflop/4991052> for this server: <https://gist.github.com/octaflop/4991187> hosted on this site: <https://legionofevil.org/>

Hope that helps! (IRC is also quite handy today)

</comment></comment><comment><USER21> Excellent!

Now all we need is WebRTC.

<comment><USER22> And for most corporations like mine to stop blocking websockets. What do you mean let some odd port through the firewall?

<comment><USER23> How about serving it using SSL on port 443?

<comment><USER24> WebSockets over SSL (wss://) work just fine. Faris Chebib provided a nginx config file in #nginx earlier today. <https://gist.github.com/octaflop/4991052>

</comment></comment></comment></comment><comment><USER25> Now how to interact with their support, and hopefully some tutorial on integration with the multitude of different languages.

<comment><USER26> This has nothing to do with languages. Nginx can now proxy WebSockets to arbitrary servers.

</comment></comment><comment><USER27> What were people using previously? Just plopping their node.js or whatever straight on the network?

<comment><USER28> I've had good results so far with node-http-proxy:

<https://github.com/nodejitsu/node-http-proxy/>

Easy to set up, and has the benefit of reducing the number of processes I need to maintain (my node server and my proxy server are the same).

<comment><USER29> Hey... saw your comment here <http://news.ycombinator.com/item?id=5172775> about the work you did on unrolling arrays in mongo_fdw. Any chance you can email me about it (that thread is closed). username @ gmail.com

</comment></comment></comment><comment><USER30> Any ETA on SPDY support being included (instead of requiring a patch)?

<comment><USER31> Looks like the next release.

<http://trac.nginx.org/nginx/roadmap>

It's only SPDY/2 for now although SPDY/3 eventually.

</comment></comment><comment><USER32> This day has finally come!

</comment><comment><USER33> Great news!

</comment><comment><USER34> Good news, finally, not just need to wait couple of months until they solve all the initial bugs to migrate our existing apps! ;)</comment>


Bill Gates Urges Young Scientists to Consider the "Needs of the Poorest" - <AUTHOR> http://www.scientificamerican.com/blog/post.cfm?id=bill-gates-urges-young-scientists-t-2011-06-26

<comment><USER2> I disagree. A research, when begins is independent of its beneficiary. That's why scientific progress cannot be charted. It's surprising that came from Bill Gates. Scientists work to solve problems, to unearth secrets of nature, to create things, not to solve needs of the poor. That is the consequence of their research.</comment>


Why is a database table called a "table"? - <AUTHOR> http://stackoverflow.com/questions/10689792/why-is-a-database-table-called-a-table

<comment><USER2> Not mentioned in the linked discussion is that both a (furniture) table and a (flat-database) table are rectilinear entities -- a flat-database table is often displayed as rows of equal length, creating a rectangle.</comment>


Tech IPOs: They're back! - <AUTHOR> http://money.cnn.com/magazines/business2/business2_archive/2007/03/01/8401021/index.htm?section=money_topstories <comment><USER2> It shouldn't be a problem as long as they have a business model this time around. :)

Good article, thanks.</comment>


CityMapper Raises $10MM - <AUTHOR> http://techcrunch.com/2014/04/17/citymapper-10m/

<comment><USER2> Even the article refers to it as "$10M".

Please stop adding extra M's :(

<comment><USER3> I like the double Ms. It reduces the ambiguity. Nobody thinks of 10MM as anything other than 10 million. 10M can be 10 million or 10 thousand. I've been in situations where the ambiguity has caused problems.

<comment><USER2> For me (UK, not US) it _increases_ it.

Nobody outside the financial sector uses it here, at all. And 10M is always understood to mean 10 million, never 10 thousand (that's 10k).

</comment></comment></comment><comment><USER4> Good, this is an excellent app and their success is much deserved. I look forward to what is to come from them.</comment>


Show HN: Hyperactiv – A super small JavaScript reactive library - <AUTHOR> https://github.com/elbywan/hyperactiv <comment><AUTHOR> This week I made hyperactiv, a super small reactive library written in less than 120 lines of code.

Basically hyperactiv observes object mutations and computes functions depending on those changes.

The key point is that the library is smart enough to remember the dependencies, meaning that you never have to specifiy which function depends on which observed property.

A typical use case would be to create a smart reactive store which re-renders your web framework components when needed. For React, a small wrapper takes only 18 additional lines of code.

Feedback is appreciated !

More details @github : [https://github.com/elbywan/hyperactiv](https://github.com/elbywan/hyperactiv)</comment>


Secret surveillance of 'suspicious' blacks in one of DC's poshest neighborhoods - <AUTHOR> https://www.washingtonpost.com/local/social-issues/the-secret-surveillance-of-suspicious-blacks-in-one-of-the-nations-poshest-neighborhoods/2015/10/13/2e47236c-6c4d-11e5-b31c-d80d62b53e28_story.html <comment><USER2> One of the shopkeepers quoted in the article: "Shoplifting has always been an issue and as long as there's stores, lower-income people are going to have a higher tendency to steal."

Beyond the obvious offense of profiling, the danger of relying on stereotypes is that they lead you to be suspicious of the wrong persons. According to a large CDC study[1]: "Shoplifting occurred across all sociodemographic strata. However, it was more common among those with higher education and income, suggesting that financial considerations are unlikely to be the main motivator for shoplifting in most cases. It was also more common among Native Americans and non-Hispanic whites, possibly indicating a racial/cultural dimension not previously documented."

[1] [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4104590/](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4104590/)

<comment><USER3> There are two more problems:

1) Most importantly, responsibility and justice must be on an individual level: An individual has absolutely no responsibility for the actions of others who happen share some characteristics with them. If I'm short, I'm not responsible for what other short people do and shouldn't suffer any consequences from it.

2) Profiling leads to many false-positive errors. Consider that even the disparity is so large that 1% of group A and only 0.1% of group B is criminal:

* If your customers are 99% group B, you will see ~10 times as many group B criminals as group A.

* If you suspect everyone in group A, you'll be wrong and harassing innocent people 99% of the time.

The real problem, returning to my first point, is objectifying people: Seeing them as merely threats to your store - like a 2-dimensional character in an action movie - instead of real people with their own lives, feelings and interests. It's much easier to do with people you are unfamiliar with, such as other cultures, races, economic classes, etc.

</comment></comment><comment><USER4> I'm constantly surprised by the casual racism displayed on DC's ubiquitous neighborhood mailing lists and discussion forums. But at this point maybe that says more about me than my neighbors :/

Beyond the terrible impact of racism itself, I think racially profiling people with dark skin is unlikely to address rising crime in a city that is majority black.

<comment><USER5> I always thought of DC as such a multi-racial/ethnic town and that it would be much more welcoming-to-all than it is.

<comment><USER4> I still think it's a good city and that the vast majority of residents are good people... but yeah, there are definitely (still) racial issues beneath the surface.

<comment><USER5> Oh I didn't mean that it isn't. It's a great city but I've been caught off balance with the sometimes blatant racism.

</comment></comment></comment></comment><comment><USER6> Comments concentrated by location == bad. See also: college, high-school chat apps.</comment>


Ask HN: Are there any lesser know open source projects that need contributors? - <AUTHOR>

Hi all,
Are you working on open source project that needs contributors and isn't getting any ?<p>please post about your project here. <comment><USER2> The average open source project has less then 4 maintainers. Really every project is undermanned and in need of help. Normally find a tool, library, framework that you like and support them either financially, bug reports, or pull requests.

</comment><comment><USER3> Title doesn't reflect the intent of the post as it can simply be answered: 'Yes'. Are you offering help or just want to start a list?</comment>


China Confirms Deployment of Online Army - <AUTHOR> http://www.chinadaily.com.cn/china/2011-05/26/content_12583698.htm

<comment><AUTHOR> Here's the original report from the Beijing News (translated to English from Chinese by Google): [http://translate.google.com/translate?hl=en&rurl=transla...](http://translate.google.com/translate?hl=en&rurl=translate.google.com&sl=zh- CN&u=http://news.bjnews.com.cn/2011/0526/119679.shtml)</comment>


Beanstalk launches Mercurial support  - <AUTHOR> http://blog.beanstalkapp.com/post/21854530710/introducing-mercurial-repositories-and-svn-1-7-coming

<comment><AUTHOR> As of today we have native support for SVN, Git, and Hg.

We've also open sourced the Ruby API we wrote for Mercuiral: <https://github.com/isabanin/mercurial-ruby>

Enjoy!</comment>


Show HN: Rap about sales saying yes before talking to devs - <AUTHOR> https://www.youtube.com/watch?v=nVWjcudK-2w <comment><USER2> Oh man, I can relate to every song on the whole channel. Good job!

</comment><comment><USER3> Keep up the good work dude, I love all your songs ! Always having a good laugh ! I'd be more than happy to collab with you !</comment>