Osborning the Mac, or not - <AUTHOR> https://mondaynote.com/osborning-the-mac-or-not-f0bbf4c319f0 <comment><USER2> Everyone here is very positive that the transition will go smoothly based on their last few transitions being fairly successful.

I'm a bit more skeptical.

Back then, their desktop/laptop business line was much more important to them. They needed it to go well. They were also a niche player and couldn't afford to lose more market share to PCs/Windows.

But now, they barely care about their desktop/laptop revenue (being only 10% of their revenue) and they don't seem to care much about their marketshare either because they don't seem to be doing much to expand it. They care a lot more about their iDevices now.

Also, if the transition from 32 to 64 bit is any indication, they don't care nearly as much about backwards compatibility as they used to. When they did the hardware transitions, they had a compatibility layer (Rosetta) that was supported for _5 years_ after the transition. But with the 32 bit change, the announced that it would no longer be supported in 2017, and dropped support in 2019, just _2 years later_.

I can no longer use a lot of my favorite apps because they were games written years ago with no current support, so they were not updated. Or they're things like the old Microsoft Office, which works perfectly well for me, but I can no longer run. And Apple provided no emulation environment or official way to do so.

So now my choice is to keep an old computer around just to run old apps (which could be a security issue if it's on the network), or buy something like Parallels, which is a ton of overhead for a single app at a time.

It would have been nice if they had provided a Rosetta for the 32/64 conversion. The fact that they didn't does not bode will for this transition.

<comment><USER3> This is ridiculous. Mac revenue was roughly $25 BILLION dollars in 2019. The idea that they don't care about it is simply wrong. Same with the idea that they don't care about marketshare.

Of course they care more about iDevices than the Mac. It brings in roughly 5x as much money as the Mac. But Apple can chew gum and walk at the same time.

<comment><USER4> This was my argument for why Apple shouldn't have killed Aperture. Sure, it was a tiny percentage of Apple's business, but it was beloved by customers _and_ independently profitable—more profitable than plenty of entire businesses.

Apple still killed it.

<comment><USER5> I never understood why they killed that but kept Filemaker. I guess they really did think the update to Photos was good enough.

<comment><USER4> Filemaker is different, it's not an Apple product anymore. Claris was spun off into a separate company.

<comment><USER5> I think Claris are still owned by Apple though?

<comment><USER4> Nope, they were fully spun off. [https://en.wikipedia.org/wiki/Claris](https://en.wikipedia.org/wiki/Claris)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> There shouldn't be too much of an Osbourne effect with ARM macs. If anything, the sensible approach is the opposite: get in there quickly and get yourself an x86 mac while you still can.

ARM macs make sense long-term, but the experience is likely to pretty rough at first while software support catches up.

<comment><USER7> As a very, very long time Mac user, the transition from 68k to PPC, then Mac OS 9 to OS X, then PPC to x86 was fairly smooth for the most part. Apple's relatively firm iron grip on their ecosystem due to their vertical integration gives them a lot of latitude to make moves like this be minimally disruptive to their user base. Now this is of course often annoying and disruptive to its developer base, and I've been on that side of it too. But, Apple knows how to pull this off about as cleanly as one could expect for such a significant overhaul.

<comment><USER8> Apple has never pulled off a transition like this before. None of your examples involved going from a popular architecture with broad software support to a less-popular architecture.

Transitioning to x86 brought additional customers who prefer Mac but also need to run Windows or Linux or who do x86 development. Transitioning away from it may lose them.

<comment><USER9> > None of your examples involved going from a popular architecture with broad > software support to a less-popular architecture.

Not sure how unique this architecture will be, but by device count, ARM architectures dwarf all others significantly. Calling it 'less-popular' is wrong.

<comment><USER10> Less popular by count of non-mobile software. Which is likely a lot of business software. Still, Mac software seems to generally keep up to date with Apple's changes. Drivers on the other hand... not so much

</comment></comment></comment></comment></comment><comment><USER11> I don't think the switch is about Apple providing better performance, thermal efficiency or anything like that. I think it's simply cost control. Consumer Intel chips haven't improved much better in a long time but they still command an enormous profit margin. And since Apple controls the compiler toolchain along with the OS and much of the other hardware, it can make the switch without the consumers it cares about the most noticing.

<comment><USER5> Apple have often suffered when it comes to external dependencies. That might have been when IBM failed to keep PowerPC competitive, Microsoft Office lagged on the Mac or now when Intel are struggling. The rumours are that several Mac releases have been delayed because of supply problems, the newly released 13" MacBook is shipping with previous revision chips in the low end models.

When you take this into account it's easy to see why dumping Intel is attractive to them.

</comment></comment><comment><USER12> I'm pretty convinced Apple's transition strategy for existing software will be "Recompile, retest, republish":

 _No built-in emulation or other support for x64 binaries._

In the past transitions they had to have a strong compatibility story. But I think that's not nearly as important anymore.

For software that is being actively developed, releasing fat ARM/x64 (or maybe fat bitcode/x64) binaries can be worked into a release over the upcoming months.

Software that is not being actively released... was pretty much mostly kicked to the side of the road due to the completion of the transition to x64 (if not sooner -- death by a thousand small transition cuts).

There will certainly be casualties to this approach, but I'm guessing Apple will prefer to reap the benefits of a much simpler and straight-forward transition. They may also see it as no great loss. E.g., software that is no longer being recompiled is also no longer receiving security updates.

If this happens, the big kicker will be dependencies. Your hyper-maintained, always-updated app will probably contain at least a few dependencies that stopped moving a long time ago, and you'll be forced to find alternatives.

Also: x64 emulation (slow though it will be) will happen in any case. But from third parties. VMWare Fusion, etc. I think there will probably be a market for some kind of x64 container that "shrink-wraps" an x64 app or library with an emulation core as an alternative when recompiling can't happen (there's a lot of existing tech to build this on top of, so I think it will come pretty quick -- actually, in different forms for different migration scenarios. Because of the performance/resource penalty, you'll want to wrap as little as possible)

edit: I meant to add: It will be funny to come back to this after Apple's ARM announcements and see how bad (or good?) my speculations are...

<comment><USER13> > But I think that's not nearly as important anymore

I used Macs during Classic to OSX and PPC to Intel transitions but I'd argue it's actually way more important this time.

Back during previous transitions fully native apps were really the only option but now...

Almost all modern actively developed software on Macs is just electron wrappers Only a few exceptions of actively developed cocoa apps come to mind, Sketch, Omni Group, etc.

The other half of the Mac ecosystem is exist outside of electron apps or cocoa good citizens and that's old but essential power user applications the Adobe suite, 3d software, science software and audio software which all have extensive custom Intel code and all the plugin infrastructure runs on Intel.

To bring After Effects, for example to ARM is going to be an insane amount of work and a lot of it is going to sit outside of Adobe's control because so much of the application relies on plugins which all have to be recompiled too.

I feel Apple might have lost the plot here a bit and has convinced themselves that this functionality vacuum is going to be filled with catalyst iPad ports, reality is if the computer can't run these apps people require for their jobs then they'll just buy windows machines.

<comment><USER14> > it's actually way more important this time.

How so? All the old legacy apps that nobody wants to (or can) recompile were just jettisoned in the 64 bit transition, as TFA duly noted.

"In retrospect, the move to 64-bit software may have been made not just for its own sake, but in contemplation of the ARM transition."

<comment><USER13> 32 bit is going back a lot longer, although my machine which I haven't upgraded to Catalina still has a few 32bit applications kicking around on it including one that I was using in my professional work only 6 months ago.

Plenty of 64 bit software exists that isn't being updated often or at all anymore.

<comment><USER14> I didn't say there was _no_ 64 bit legacy software. I just don't see it as being a "bigger" problem, due to the cutting off of the 32 bit legacy.

</comment></comment></comment></comment></comment><comment><USER15> I buy iMacs for my personal use, as they spend the majority of the time running Windows 10 for gaming. Sure I could build/buy a dedicated gaming machine, but I like the hardware (Great monitor, quiet, sleek, mostly trouble- free) and my iMac can play any game at 1080p. Without bootcamp support, I'm going to abandon the Mac hardware for personal, and then for business use. There's no way an ARM processor is going to be able to emulate x86 to run windows and my steam library at anything close to usable performance.

<comment><USER16> My prediction of Apple's moves here are far less dire. These are just predictions mind you, but the point is Apple could do this without ruining the platform for enthusiasts.

1\. They're going to have some kind of breakthrough with x86 emulation where the Apple ARM CPU has a translator, or an accelerator, or a co-processor, or something that will make x86 run at decent speeds.

2\. Apple will move to a long term two-CPU strategy with ARM on economy and low power SKUs, and Intel chips for the "Pro" SKUs.

3\. As an alternative to 1 and 2, the direction might just be a killer next- gen iPad Pro and new iPadOS which substantially raises the bar for multitasking, trackpad, etc on that platform. I wouldn't even dismiss the possibility of an "iPadBook" for want of a better name.

<comment><USER4> > 2\. Apple will move to a long term two-CPU strategy with ARM on economy and > low power SKUs, and Intel chips for the "Pro" SKUs.

How is this going to work for developers or Apple? For how many years will everyone need to test and ship universal binaries?

<comment><USER16> I see no issue with developers shipping universal binaries indefinitely. I don't see what the issue would be with that, for most devs it's just part of the Xcode build process. I suppose it would double the compile time for release builds.

Testing is a legitimate concern but I don't think it's as consequential as you imply. (For most developers.)

</comment></comment></comment></comment><comment><USER17> I've been pretty unenthusiastic about the idea of replacing my Macbook Pro after they removed the MagSafe connector and HDMI ports. However, if the ARM laptops run cool enough to actually use on your lap, it might be worth it.

Knowing today's Apple, though, they'll make it super thin and it will still run hot.

<comment><USER18> Neither my 16" MBP or my iPad Pro are too hot for lap use. Yes - the 5+ year old laptops you are clinging to were saddled with some occasionally hot intel CPUs but they've come a long way.

<comment><USER19> My 16" MBP gets pretty warm when I game. Think that's unavoidable in any laptop where the body is part of the heat sink.

</comment></comment></comment><comment><USER20> It's actually a brilliant move by Apple.

After the new machines are released, all Mac app store apps will just magically work because they were recompiled behind the scenes by Apple to run on ARM. Only independent releases (stuff not in the app store) will have to deal with the shit show, which will also push more developers to the Apple tax.

For regular Mac users (who are already using the app store for everything), there will be no difference, and nobody will care what's actually under the hood. All of their software will work just fine whether it's x64 or ARM. There's nothing to wait for because these ARM machines aren't going to be so much better that people delay their purchase. It would be like holding off on the 2.2L engine variant of a car because the new model with the 2.4L engine with 5% better acceleration is around the corner.

Of course the reality will be that some apps will break, but the majority will just work, and Apple will be working behind the scenes with the biggest fish to make sure their stuff transitions smoothly.

<comment><USER21> > After the new machines are released, all Mac app store apps will just > magically work because they were recompiled behind the scenes by Apple to > run on ARM.

That would be _really_ magical; this is essentially impossible.

<comment><USER22> It's not though; when submitting a native app to the app store, at least for iOS you're sending them an intermediate version; a version that can be compiled and repackaged by Apple for a specific CPU, e.g. 32 or 64 bits. They will also grab the assets intended for that platform, e.g. regular images for small screens, 2x images for retina and 3x images for iPad screens.

See also: [https://en.wikipedia.org/wiki/Intermediate_representation](https://en.wikipedia.org/wiki/Intermediate_representation)

<comment><USER23> Chris Lattner:

 _Bitcode is not a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn't something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that's something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable._

[https://atp.fm/205-chris-lattner-interview- transcript](https://atp.fm/205-chris-lattner-interview-transcript)

</comment></comment></comment></comment><comment><USER24> Does the underlying CPU platform matter anymore for most people? If they have some non-standard proprietary apps then for sure that's a big issue. But if most OS apps are recompiled, then you have iCloud apps too, the bigger hitters being onboard is key (Microsoft, Adobe). If you pretty much hit those key points then it begins to look like it'll be relatively straightforward. ARM Macs will increase Apple's profit per unit shipped as they get the CPU for free. No longer beholden to Intel's erratic road map and failure to deliver.

<comment><USER25> It's unlikely Adobe will be on board. Porting their apps to ARM, even with a virtualization layer, is going to be hell. They dragged their feet last time around, I bet they will do that 1000x now.

MS might decide that "the web is good enough" and just drop native Mac apps for the time being.

<comment><USER26> Considering that Adobe has been actively porting creative cloud programs to iPad, I'd say the opposite.

They've already been optimizing the existing code base for ARM, maybe with a heads up from Apple that this would be a good preparation for changes coming down the pipe on Mac...

<comment><USER25> "Porting" is a big word, in my limited experience. The i-apps from Adobe are nowhere near their desktop counterparts.

<comment><USER18> Adobe is on record that those _are_ ports - the core of the app is ported, but individual features don't all make it over, or make sense on a touch device so you u e a feature disparity.

</comment></comment></comment></comment></comment><comment><USER27> I would be surprised if apple transitions all of their macs to ARM at once. Consumer-level macs (macbook air, mac mini, iMac) would go ARM now, while keeping the macbook pros, imac pro, and mac pro x86 for at least a few years. This could happen tacitly with the latter computers being sold in their current form (maybe with minor spec bumps). This allows Apple to make the transition without abandoning their creative pro users, and the makers of pro apps will be incentivized over time to port their software to access the growing ARM-only mac user base. That, or apple has already been working with (and probably paying) Adobe, Avid, Autodesk and other makers of marquee pro apps to port their code to ARM so that Apple can claim that their ARM macs will be pro ready from day one.

</comment><comment><USER9> It seems like the de jour solution to the Osborne Effect is to create the consumer expectation of significant price increases. People still buy last gen hardware nowadays well after the new hotness is out, because the new generation often costs 50%-100% more for a year or two.

If Osborne had said "The next versions will be even better, and only cost $5000 more!" people would have kept buying the Osborne 1.

<comment><USER28> There will be a bigger backlash if they mislead customers on the price.

<comment><USER9> I really doubt there would be a major backlash if a company like Apple said "Due to <nonsense manufacturing related excuse>, we are able to offer the new iPhone for $XXX dollars less than we expected!"

Consumers rarely complain about lower prices than they expect.

Hell, tons of companies offer their products at an MSRP that drops massively within _weeks_.

</comment></comment></comment><comment><USER29> I'm just real glad that my personal upgrade cycle is at the point where I won't be looking for a new computer until at _least_ the second year of ARM Macs, when most show-stopping bugs should be ironed out of the OS and the Adobe tools I spend most of my work time in.

I was an early adopter of PPC and OSX, I'm not gonna sit there trying to get work done via the old-cpu emulation again.

<comment><USER29> Also:

 _On a desktop machine, there's no benefit in lower power dissipation and slimmer bodies_

If you're in a hot climate then every little bit helps. Lower your power bill due both to lower consumption on the part of your computer and due to the AC coming on that much less. Run the computers fan less. Maybe even have a Mini that does a surprising amount of what you'd buy a Pro for. Make the iMac that much more of a flat screen.

<comment><USER30> I read that paragraph and had a completely orthogonal thought. Intel mobile CPUs compare favorably to all established competition (AMD) and the iPad with Magic Keyboard is almost a laptop anyway. Why start with a mobile device?

Intel desktop CPUs are where they have problems and you would assume that this is where Apple has the most frustration with Intel. That's where I'd start.

Also, by keeping ARM and Intel around simultaneously for a few years (both as first-class citizens) forces developers to maintain portable code. If you are using Swift in the manner that they want you to use it, this is already the case. If you're using some other language/approach then you have to either think about adopting Swift or putting in more work.

<comment><USER31> The thing is, the majority of Macs sold are laptops. It doesn't make sense for them as a business to build a strategy around what's best for desktop machines.

<comment><USER30> Yes, if their plan was to keep both platforms forever it wouldn't make much sense. But if they have a 2-3 year transition plan, it might make more sense to start with something for which low sales is still a success.

</comment></comment></comment></comment></comment><comment><AUTHOR> The author mentions Nokia as an example, I didn't follow the transition closely. Was everyone really waiting for the Windows Nokia phones or did Nokia just lose mindshare (as I remember it)?

Any other good examples for Osborne Effect? Wikipedia does list SEGA's transition from Mega Drive/Genesis to 32X and Saturn and I can see how this confused potential customers but I guess there must be more (better?) examples.

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

<comment><USER32> In 2011 Nokia had several OSs.

Symbian was the cash cow, successful in a number of markets. But not up to par with where Android and iOS were leading the industry. The prevailing wisdom seemed to be it needed some modernization or replacement.

Maemo/Meego was their previous replacement candidate, based on Linux and Qt. Personally I liked this one. They never really allowed it to be on a path to cannibalize Symbian. It was always like an experimental project.

Switching to Windows Phone killed both of those.

Less talked about is s40, the low end feature phone-ish platform that continued to sell well in emerging markets long into the Windows Phone era.

<comment><USER4> > Maemo/Meego was their previous replacement candidate, based on Linux and Qt. > Personally I liked this one.

Meego—and the Nokia N9 it ran on—was _so damn good_. I can still remember the _feeling_ of using it; it felt so good!

I am still pissed off that they killed it. For Windows Phone, of all things!

<comment><USER33> Sweetheart deals with ex-Microsoft Executives leading the company. In my opinion: This is a cautionary tale of career executives.

There was, however, an anecdote banded about the Helsinki R&D Nokia offices: "We have, easily, the most expensive clock application ever made, it's been rewritten so many times". So maybe the inefficiency was always going to kill it.

That said, Nokia was betting on Meego replacing Symbian, symbian was so crazy optimised for low end hardware though.

<comment><USER34> The N9 clock app was a work of art though, super easy to use. I'm still sad that Meego didn't take off. It was the most intuitive, polished mobile OS I've ever used.

</comment></comment></comment></comment></comment><comment><USER35> 1\. Apple designed chips are already faster per-core than a top-end MacBook Pro.

2\. There's no reason dedicated ASIC modules for specialized tasks (like video rendering) can't be connected by Thunderbolt 3 just as external video/compute modules are now.

3\. There's no reason a dedicated x86-64 dongle can't be sold for ARM-powered Macs that need to run software that hasn't been ported yet. It would be a spectacular coup if those x86-64 dongles had chips made by AMD but I digress...

<comment><USER36> When it's a laptop, I'm quite the fan of having as much as possible built into the machine as a single unit. That's the point of the form factor, after all.

I think the last thing the MacBooks need are more dongles.

<comment><USER37> Dongles for vital functions every user will have an ongoing need for are a problem.

Dongles for legacy functions in the process of deprecation that some users may not want/need seems sensible.

<comment><USER36> I suppose it depends on how quickly they go from "Apple says this legacy" to actual legacy tech.

</comment></comment></comment></comment><comment><USER38> It's quite amusing that there is nothing official about this from Apple, but so many blogs & vlogs talking like it's inevitable.

Maybe they just transition to AMD CPUs and nearly nothing changes at all :)

</comment><comment><USER39> I'd worry more about Apple iOSing the Mac.

<comment><USER40> There is likely to be yet more convergence towards iOS constraints. This seems inevitable, especially if Catalyst is central to how Apple carry out any ARM transition. It's very clear that Apple aren't catering to developers in macOS to the extent that drove OS X growth from 2004.

For a time, many developers couldn't find fault with OS X and Mac hardware. I wonder how much more correction we'll see from Apple, now that they've gone back on keyboards to a degree. I'm not counting on too much, I know a lot of people aren't as happy as they could be.

<comment> yoz-y I really hope Catalyst is a dead end and only exists because they somehow started working on it before realizing SwiftUI was the way forward. I've yet to see a Catalyst app that does not feel like a quickly hacked beta.

<comment><USER41> A Catalyst app can be implemented with SwiftUI though, I don't see your point

<comment> yoz-y Once you have a SwiftUI app you don't need catalyst to make it work on macOS. You can tweak the SwiftUI code specifically and the final user experience will be better. Catalyst only exists because UIKit does not work on macOS.

</comment></comment></comment></comment></comment><comment><USER42> What are the possible reasons why they haven't done it already?

1\. The power savings just isn't there. I find this hard to believe.

2\. The performance of the chips just isn't there. This is very possible.

3\. Not enough software is compatible yet. What are the crucial pieces?

4\. Xcode isn't up to snuff running on ARM yet.

<comment><USER43> It's a combination of development in CPU performance. The peak performance levels of the Apple's ARM architectures have reached peak Intel/AMD levels around the Apple A12, so they haven't been at this level for that long. In addition, Intel has not been good at iterating on their hardware since Skylake in 2015 and don't look to be making great strides in the short term.

It's like the PowerPC->Intel story all over again. Intel was not at PowerPC levels that long before 2005 (PowerPC had substantial advantages from 1994 to 2002), and IBM was not showing evidence of improving the situation beyond 2005.

I think before 2018 it was unclear whether an ARM Mac would be superior in terms of performance/heat/power, but I think given Intel's lull and Apple's continued improvements I think the best decision is clear [if you think it is worth the transition, which is the most debatable item].

</comment></comment><comment><USER44> > _Mac revenue today represents only 10% of total sales; in 2006, it was 38%_

Wait... what?

The Mac was only 38% of Apple's revenue in 2006?

<comment><USER2> The iPod already represented significant revenue in 2006.

<comment><USER44> Yes, certainly.

In fact I actually checked their Q4 2005 results and the iPod generated 1,212 M and the Mac 1,611M.

I knew the iPod was popular at the time (I had one) but never expected it to be that much.

[https://www.apple.com/newsroom/pdfs/q405data_sum.pdf](https://www.apple.com/newsroom/pdfs/q405data_sum.pdf)

<comment><USER4> I feel like popular is an understatement—they were _everywhere_. They basically _were_ the MP3 player market, and that was in turn how just about _everyone_ listened to music. I can't say that today about the iPhone.

</comment></comment></comment></comment><comment><USER45> To me, moving the Macs to ARM or perhaps just the laptop models to ARM could be a win for Apple. Thinner, lighter, lower-power and better software integration with the iPhone/iPad could result in happier consumers and more reluctance of users to jump to Windows based machines.

The risk is that there will be enough difference between the ARM machines and the previous ones that consumers will be reluctant to buy the new machines. I know that the keyboard problems on recent laptop models caused me to buy some windows laptops for the rest of my family.

There is a way for Apple to facilitate this move to ARM. Make the ARM machines noticeably less expensive than Apple's previous Macs. I've been disappointed during the last few years by the cost of Apple's Macs, the mini, the iMac Pro, the Mac Pro, and high end configurations of the laptops seem overpriced now. Perhaps this is is a longer term strategy for Apple. Maybe they have priced the recent machines higher so that adoption of ARM based machines can, in comparison to previous models, look more attractive. Apple could also lower the margins on the new ARM machines, at least until there is enough buy-in by consumers to raise the margins back to be comparable with Apples pre-ARM products. My prediction is that the new ARM machines will be priced very competitively when they are announced. In a few years, their prices will rise.

</comment><comment><USER46> I'm rather happy about buying the recently updated 13" MBP and basically skipping ARM Macs. My last one lasted 8 years, so I expect this one to last roughly as long. By then they'll _definitely_ have ARM figured out, and in the meantime I can continue enjoying x86 compatibility and VMWare. For the fairly small segment of the market that we devs represent, I suspect I'm not the only one here implementing a _reverse_ Osborne Effect. Get your x86 Mac while you still can!

</comment><comment><USER47> The biggest questions many of us have around this transition include:

a) Will this change be smooth and offer native enough app support (or emulation) at launch?

b) Will the performance and price be acceptable?

c) What will the ripple effect be throughout the existing Apple dev community?

d) Is this move going to do well for Apple, or the opposite.

I'm finding it tough to speculate on this one, but I've seen a lot of Apple misfires since 2013 when it comes to price, functionality and quality (should I dare say, "the butterfly effect"?).

In short, Apple's direction hasn't been great recently. Given this, I think it more likely that the negatives will outweigh the positives.

<comment><USER48> I agree that the Mac trajectory wasn't that great during the last decade with a lot of misfires. However, the most recent Mac picture is much more positive: Nearly the whole lineup is up to date, they butterly keyboard is out, many questionable design decisions were rolled back.

I get that after nearly a decade of disappointment that's not enough to rebuild trust completely and there is still more than enough to be critical of, however the most recent positive moves to make me cautiously optimistic.

Plus: Apple has managed these transitions extremely well in the past. That's something they are (or at least were) good at.

Here they could also be helped by the fact that these transition times usually put any other extreme experiments on pause. I don't expect Apple to switch out the CPU and also offer up a radical redesign (where they can make many wrong decisions), at least not across the product line.

They also didn't do that for the Intel transition.

</comment></comment><comment><USER49> Somewhat off-topic, but what a strange image to feature in the article: a composite of the Apple logo over the Sony PlayTV [1] logo, a PlayStation 3 accessory for watching television.

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

</comment><comment><USER50> > "Today we discuss"...

Meaning, today I write. Because what I say is necessary. Can't just be silent.

When is he gonna give up the ghost? He's not at Apple for a reason. Yet he's obsessed with them.

No one at Apple sought him out before going in any direction. He's been a non- entity there for two decades. Yet he can't stop trying to tell us all how to think about everything they do.

Gruber is at least a little more attached to Apple.

But the two of them sound like two old cranks: one consistently fawning over all Apple decisions, the other fretting.

I don't know what it's like to devote one's life to discussing a single corporation, even one as wildly successful and entertaining as Apple.

I always wonder if these guys ever wake up and think, "Maybe today I'll just delete my blog, stop reading press releases and tech news about Apple, and go build that cabin or walk a trail".

Maybe they're terrified no one would miss them? Or maybe they'll find that life is better and that they wasted the last few decades of their very precious and limited life?

I don't know. Maybe they are so enmeshed it just never occurs to them. It just always makes me sad to see their posts. Maybe that says more about me in some sad way than it does about them. Don't know.</comment>


Netflix are hiring professional binge-watchers to rate and review their shows - <AUTHOR> https://www.mirror.co.uk/news/weird-news/netflix-hiring-professional-binge-watchers-12303047 <comment><USER2> Amazing considering they reset the ratings of all the millions of binge watchers they already had. That stupid thumbs up, and thumbs down nonsense wouldn't have been bad if it retroactively gave a thumbs up to anything you rate 3 or higher. Yet here I am, re-rating movies/shows I've already done.

<comment><USER3> But I think that's the point asking people to rate with stars, they behave differently than asking if they liked/didn't.

People are more likely to highly rate a high brow period piece they didn't enjoy than give it a thumbs up. So there is no translating old data to new. Hence why they need fresh ratings.

They want the thumbs ups for low brow tv shows or comedies that people enjoy.

<comment><USER2> Thing is, the ratings weren't just a number of stars. They were clearly categorized in a way that made sense when you based it on the language, and not just a number value.

1\. Hated it

2\. Didn't like it

3\. Liked it

4\. Really Like it

5\. Loved it

Now I have to decide whether I loved it or hated it. Which is rare to be at either extreme.

<comment><USER4> The problem with star ratings, and this has plagued star rating systems since their introduction, is different people have different rules. There's the 1/5-crowd where they either love it or hate it, and the 3-everything crowd where everything's just meh.

There's also those that "save" their 5s for their absolute favourites, and only hand out 4s save for special occasions.

If they had a system like "like/dislike" for preference data plus an additional "I hate this, do not show anything like it ever again" and another akin to "I love this, I will cancel my subscription if you don't renew it" you'd get better data.

Some rating systems have a "super like" which you could dole out in limited quantities. Maybe Netflix needs one!

<comment><USER2> I don't see that as a problem, since the rating system was tailoring content for YOU. So whatever your rule set you decided to use for your rating, you would continue to do so in the future, and it would recommend based on that. That star rating you used to see for a movie, that was what Netflix determined YOU would rate the movie if you saw it. Not what everyone else cumulatively rated it.

<comment><USER4> The problem is normalizing rating data that's all wonky like this to try and tease out any meaningful patterns.

</comment></comment></comment></comment></comment></comment><comment><USER5> I hope they make their ratings better with this, b/c all the ratings on Netflix are so bad at predicting what I like. I usually end up searching by title or going with what's popular.

</comment><comment><USER6> > The streaming giant have some highly-anticipated new releases coming out in > April, including Jaws, Knocked Up and The Blues Brothers .

I guess 40-year-old movies are considered "new releases"

<comment><USER7> Well, if (re)mastered in 4K HDR, otherwise not so much.

</comment></comment><comment> xkcd-sucks When alcoholics rate booze, 40s and bumwine come out on top</comment>


Blekko Tries to Best Google's Search Engine - <AUTHOR> http://www.nytimes.com/2011/05/08/technology/08ping.html?partner=rss&emc=rss <comment><USER2> The thing I love most about Blekko is its /date slashtag. But on the other side, it's one of the only clear advantages it has over other search engines; its general slashtags include too few sites. There are some rare occasions where its scarce list of sites comes in handy - such as when you need a rough timeline with /date, and where a single story is parroted, such as Reuters, AP, US Weekly, and People Magazine.

DDG is generally a nice alternative to Google, and its bang commands are invaluable, but it falls short when it comes to delivering relevant hits to my queries.

DDG is my default search engine in browsers, but most of my general queries begin with "!g".

None of the three are mutually exclusive, and I'm glad to have all of them. You shouldn't dismiss any of them nor use them exclusively.

<comment><USER3> The completeness of our slashtags depends on the slashtag. Do you think /health has too few sites? Among the technical slashtags, /perl and /python are pretty complete, and the rest of the them are currently getting some love from the Stack Overflow community. It takes time for slashtags to mature, similar to how Wikipedia was less useful on launch day verses now.

By the way, there's a /google and /bing on blekko.

</comment></comment><comment><USER4> Welcome to the original Yahoo model. What's old is new again, even for Yahoo:

[http://www.readwriteweb.com/archives/yahoo_to_come_full_circ...](http://www.readwriteweb.com/archives/yahoo_to_come_full_circle_with_news_link_curation.php)

</comment><comment><USER5> I like Blekko. The question shareholders should ask Steve Ballmer is why this small team is out innovating the Bing guys with a tiny, tiny fraction of the money they've spent. Just aiming to recreate Google's search isn't going to win the race.

</comment><comment><USER6> Has anyone ever heard of <http://duckduckgo.com> ?

</comment><comment><USER7> I like what they're trying to do, but I just don't see them doing a good job of it. We changed our domain name in August of last year, but Blekko is still surfacing our old name.

When you search for "credit card processing" we aren't in the top 100 on Blekko (though we're 2nd page on goog) but there are several sites that have NOTHING to do with credit card processing that are near the top of the list...

I think their crawling just takes a LOT of time/resources and I don't see them getting there anytime soon. Another issue is that their engine requires tags to use effectively and the layman won't learn the tags.

More: [http://feefighters.com/blog/blekko-banned-1-1-million- spammy...](http://feefighters.com/blog/blekko-banned-1-1-million-spammy- domains-but-still-shows-our-old-domain-changed-8-months-ago/)

</comment><comment><USER8> Never ever had a visitor from blekko on a fairly popular site... #justsayin</comment>


US 'wants Twitter details of Wikileaks activist' - <AUTHOR> http://www.bbc.co.uk/news/world-us-canada-12141530

<comment><USER2> Her tweestream at <http://twitter.com/birgittaj> has more, but the short version is that the DoJ is subpoena'ing her "personal details" as well as all her tweets. She's talking with Iceland's Minister of Justice.</comment>


The Cognitive Style of PowerPoint (2003) [pdf] - <AUTHOR> http://users.ha.uth.gr/tgd/pt0501/09/Tufte.pdf <comment><USER2> I published a paper on an alternative ZUI interface students used instead of PowerPoint [http://ecologylab.net/research/publications/mache_present.pd...](http://ecologylab.net/research/publications/mache_present.pdf) .

I particularly enjoy Tufte's take on Miller's 7+-2. The idea is that smart contextualization can extend short term memory, not just that we are stuck with what we know.</comment>


Trollala – Fight patent trolls by banding together confidentially - <AUTHOR> http://trollala.com <comment><USER2> This is great. Would like to see more of these kinds of efforts.

Just watched The Patent Scam video by Austin Meyer (developer of X-Plane flight sim who was sued by patent trolls).

[https://www.youtube.com/watch?v=sG9UMMq2dz4](https://www.youtube.com/watch?v=sG9UMMq2dz4)

That kind of stuff makes my blood boil.

<comment><AUTHOR> Thanks. It makes our blood boil too.

</comment></comment><comment><USER3> Are you working with Newegg on this? Lee Cheng could be a powerful ally [https://twitter.com/leechcheng](https://twitter.com/leechcheng)

<comment><AUTHOR> Good idea. We'll reach out.

</comment></comment><comment><USER4> What's to stop the troll from submitting their own letter and joining and/or influencing the defense group?

<comment><AUTHOR> Trolls might very well try this. We will carefully screen people who sign up to make sure this doesn't happen. We have several ways in mind to do this, happy to discuss if you're interested. If trolls stoop to fraud or bribery to infiltrate the group, there's not much we can do - this is true of regular joint defense groups too. If they do infiltrate, they can make things difficult, but they can't completely destroy the utility of it. Our tools would still make small businesses more powerful than they were alone.

<comment> premium-concern Plus, it would look very poorly in court if trolls would be caught doing this. So maybe instead of not letting them join, show them that they "joined", but don't show them any relevant information?

</comment></comment></comment><comment><USER5> Just wondering, is this a weekend 'throw up a template' project or a serious effort from someone in the industry? I would have some hesitation submitting without a sense for who is behind it.

<comment><AUTHOR> Appreciate the concern. This is a collaboration between ideaphore (the co- invention platform and service) and hard-ip.net (patent agent firm). Both companies were founded by people who are passionate about innovation and putting an end to predatory patent trolling. We're committed to making this work if people really want it. We'll do our best to protect your personal information.

</comment></comment><comment><USER6> Good idea. But definitely need

\- A FAQ. Trust is a big deal here. Why trust you?

\- HTTPS

\- An overview of options for your target customer. The reason someone will need your service is because they've just received a letter claiming patent infringement. A basic tutorial on "what you can do when you get a patent infringement letter" would be pretty useful.

<comment><AUTHOR> FAQ added, SSL added, resources and guides coming later today. Thanks again for your input.

</comment></comment><comment><USER7> How's this any better than [https://trollingeffects.org/](https://trollingeffects.org/)

<comment><AUTHOR> On trolling effects, uploaded demand letters are displayed publicly. Small business owners (targets) are worried that the trolls will retaliate if they find out the target is looking to fight back. We will not post your demand letters, but will instead confidentially match you with others who have received similar letters. Also, we will provide a private collaboration environment where all participants sign an NDA and fundraising tools.

<comment><USER8> In what manner could trolls retaliate if they find out the target wants to fight the case? Couldn't the trolls just pretend like they got a lawsuit on this site, and then be matched with the confidential other parties?

<comment><AUTHOR> When trolls send demand letters, they make it sound like it's in your best interests to settle for a license fee quickly before they start suing people. Don't ask too many questions, just fork over some cash. And it might well be in your best interests, you won't know until you know what others who received the letter are doing. But if you tell a troll that you are thinking of fighting their patent, they tend to become irate, raise the settlement figure, threaten to sue, or file suit. We think that this is why there have not been many submissions on trollingeffects. We will do our best to screen members to make sure that they are from bona fide companies that received a letter. I gave a bit more detail on this in a question above.

<comment><USER8> If you're going to fight, why does it matter what their settlement figure is?

<comment><AUTHOR> It's good to leave that option open, where possible. We would not want anyone to abandon it. For instance, if an IPR fails to invalidate a patent, the fight becomes much harder. And not all demand letters are unfair assertions of patent rights, some are legitimate. It's important to find out what other similarly situated businesses plan to do, but that doesn't mean you won't end up settling.

</comment></comment></comment></comment></comment></comment><comment><USER9> I don't want to pick nits too much, but no https?

<comment><AUTHOR> On it. Will switch over.

</comment></comment><comment><USER10> Joint defense groups are great for saving money on these things.

Having been in several, I've noticed a few areas to navigate carefully. It's worth making sure that everyone is comfortable with the strategy. Assuming the group tries to kill the patent, the acts of the group may limit what the individuals can do later in their defense, e.g., a weak group effort could prevent an individual from later asserting certain invalidity grounds. See e.g., part e of [https://www.law.cornell.edu/uscode/text/35/315](https://www.law.cornell.edu/uscode/text/35/315). On the other hand, often some group members don't want to pay their share for a gold-plated attack, e.g., those on a tighter budget or with less exposure.

I wouldn't let that deter me, though, from seeking a joint defense group. This seems like a great idea.

<comment><AUTHOR> That's sage advice right there. Would love to chat more, if you have the time. You know where to find us.

</comment></comment><comment><USER11> This looks like a great product. Perhaps there's a lot of potential for add-on services, that might reduce the hefty 2million$ cost of litigation.

<comment><AUTHOR> Indeed. In fact, filing an inter-partes review, something our partner Hard-IP is very good at, is significantly cheaper than litigation in federal court. Also, with a large enough joint defense group, we may be able to negotiate arbitration or mediation (we would recommend baseball style mediation).

</comment></comment><comment><USER12> Nice, should make one of these for bittorrent swarms too!

If you haven't didn't seed, or didn't seed the whole file, it would be easy to tear apart the case. One federal court circuit created "contributory copyright infringement", which is not a creature of the legislation at all, but even that is on weak legs, assuming you ever got to court.

<comment><AUTHOR> That's an interesting idea. But it doesn't quite translate because each individual copyright infringement case has its own facts, you either did it or not. With patent infringement, the validity of the patent affects every potential plaintiff the same way. But it's something to consider in the future. Thanks.

</comment></comment><comment><USER13> Is this idea patented? It might be a trap.

<comment><AUTHOR> Admiral Ackbar? Is that you?</comment></comment>


Ever wonder what your dog is thinking? - <AUTHOR> https://pursuit.unimelb.edu.au/articles/ever-wondered-what-your-pet-is-thinking <comment> W-Stool One of the things I like about my cat (Eleanor Roosevelt, a one eyed Maine Coon that sat in the local SPCA for 8 months) is that I don't try to understand her. She does her thing, mostly involving naps and head scratches, and I just admire her calm and general contentment. Whatever your dog or cat is thinking, I would suggest you just leave it alone and appreciate the life those animals live that seem so contented. Who wouldn't want that?

<comment><USER2> I'll disagree, for my dog at least. It is fun to watch the gears turn in his head, sometimes I see the conclusion he'll get to before he gets there. And sometimes, since I know him so well, I know where his 'dog logic' will take him with his flawed world view. It makes a kind of internal sense, when you don't see the big picture. It's fun and made me realise how far AI is from even replicating a dog's language-less thought process.

It also makes me think of alien species who might view us the same way.

It has a practical side too, our guy usually slinks off to the couch for naptime after dinner but a few months back he walked to the office and just stood in the doorway staring at us. We could instantly tell by his expression that something was wrong. He turned out to have a grass seed lodged in his armpit (Which the vet did not find! I had to remove it myself the next day).

It is fun to just watch him sleep and dream, though.

</comment></comment><comment><USER3> > In the future, we have talked about analysing a pet's body in addition to > its face in order to improve the accuracy.

I think that's vital. Most of "Dog language" and even more of "Cat language" consists of body language. Things like pose and tension in relation to the rest of the things in the area at the moment. Dogs and cats are gifted with the ability to "speak human" enough to be understood tolerably well, but their language is demonstrably more complicated.

<comment><USER2> And many emotional displays are transient, like stress induced yawns in dogs (I note stress isn't in their top 5 list but it's common during training and learning new things).

</comment></comment><comment><USER4> I get that this is mostly for fun, but isn't there a huge problem here, in that training the algorithm first requires human interpretation of the animal's emotions? Which is a huge uncertainty in the first place?

<comment><USER5> Ah yes, I am sure the authors are aware of it. And i am sure they tried to ask animals first and then settled on human interpretation as second best option.

</comment></comment><comment><USER6> I woke up my dog to take a picture of her and see how this AI does. It ranked her as Unsettled (100%). Yep.

<comment><USER7> My poodle and I are both in the process of waking up. I got her attention to snap a pic, and it labeled her "Unsettled" too. Yeah, that's about what I feel before coffee, or in her case, fetch.

</comment></comment><comment><USER8> Tried this on a few photos of my dog - one of her half asleep, lying on her back and clearly very relaxed.

It said she was angry.

To be fair, it mis-identified her, and she is also a mixed-breed Asian dog so I'm not entirely surprised.

But it brings up questions for the future - what happens when AI is wrong but used as proof of something?

<comment><USER9> > But it brings up questions for the future - what happens when AI is wrong > but used as proof of something?

You bring up a fair point, but I don't think AI is special in this regard. Imperfect sources of information synthesis (humans, naive algorithms, etc) are used all the time. Hopefully, AI should simply add one more data point from which to understand a given situation.

<comment><USER8> People, presently seem much less willing to challenge what a computer says however.

I'm wondering if Little Britain's "computer says no"[1] sketch is somewhat foreshadowing here. It's certainly a situation I've ran in to in several banks (globally).

[1] [https://www.youtube.com/watch?v=0n_Ty_72Qds](https://www.youtube.com/watch?v=0n_Ty_72Qds)

</comment></comment></comment><comment><USER10> So an app on your phone, looking out through a camera on your glasses, could issue a security alert for very angry or scared people or animals in view. It seems a natural for Chinese style surveillance nets. Or it could be a learning tool or a prosthetic for the autistic. Real time AI assisted seduction/sales/politics/negotiation might become practical. How about an app for "reading the room".

People with the skills to read the subtleties of others' emotions have a great advantage. This tech could make some of that skill downloadable from the app store. Using it to tell if your cat is mad at you seems like the least of it.</comment>


Show HN: I Built a Spreadsheet of Productized Services - <AUTHOR> Hey HN,
This weekend I built an excel spreadsheet so that you can come up with your next (scalable) service idea.
If you are a consultant / agency and are looking to move from to build a scalable business / valuable asset, this is for you!
WHY I built this:
- Many people want to start their business but can't find an idea - Many people build stuff / services that nobody want - Ideas are great but execution is what matters: See what others have done successfully, get inspired, and do your own thing!
The framework is called the Productized Service Matrix. ---
It features in total:
- 75 companies (making as low as a few thousand USD $/month to $50m/year) - 21 verticals/industries - 13 different business models
The list is here: http://www.productizematrix.co
I also run a productized service (see in my profile) and have been really interested in this space for the last months. <comment><USER2> Thanks for this. I'm halfway though the book you wrote in 24 hours at the moment :-)

<comment><AUTHOR> Thanks, hope you enjoyed the book!

</comment></comment><comment><AUTHOR> Here is the link of the spreadsheet: [http://www.productizematrix.co](http://www.productizematrix.co)</comment>


Bourgeoisie don't know the value of the culture. They only know to make profit. - <AUTHOR> http://www.youtube.com/watch?v=bKQ8u_i3KsA

<comment><AUTHOR> [https://www.facebook.com/photo.php?fbid=432589146833957&...](https://www.facebook.com/photo.php?fbid=432589146833957&set=a.364172747008931.83902.363403937085812&type=1&ref=nf)</comment>


ASK HN: How does mosh shell use UDP but provide reliability like TCP? - <AUTHOR> https://mosh.org/#about <comment><USER2> They wrote a paper about it for Usenix, at [https://mosh.org/mosh- paper.pdf](https://mosh.org/mosh-paper.pdf) .

In general, it's always possible to put your own reliability layer on top of UDP. Other protocols do it too. g, [https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)</comment>


Baseball statistician tries politics and bats almost one thousand - <AUTHOR> http://www.nytimes.com/2008/11/10/business/media/10silver.html?pagewanted=all

<comment><USER2> This is hilariously awesome:

 _When we took him to preschool one time, we dropped him off, and he announced, 'Today, I'm a numbers machine,' and started counting, Brian Silver said. When we picked him up two and a half hours later, he was 'Two thousand one hundred and twenty-two, two thousand one hundred and twenty-three...'_

<comment><USER3> Sounds like an early sign of autism...

<comment><USER2> My second thought (after the laughter) - but then I think it shows how much we want to ascribe "problems" to kids. It's obvious he turned out okay and it's sad to think that under other parents he may have been diagnosed rather than encouraged.

<comment><USER4> Yeah. It surprises me, when I hear stories about parents overreacting about kids doing weird things. They're kids. They love experimenting with weird stuff like that. Hell, some people keep doing it when they get older - they're the fun sorts of people.

Can anybody here honestly say they didn't do anything weird as a kid? I remember reciting numbers from the Guinness Book of World Records into a tape recorder, in the belief that any number I said was the money I'd make. (I also think I did that with computer pixels on a low-res screen, for that matter.) I'm sure almost everybody here did strange stuff as a kid.

</comment></comment></comment></comment><comment><USER5> Silver predicts White Sox lose 90 games. Is ridiculed in baseball circles. Vindicated when they end up sucking.

Silver predicts Rays win 88 games. Is ridiculed further. Rays win 97 games and go to the World Series. Absolute vindication.

That said, I hate his player projection systems. You can't predict baseball (though he comes about as close as you can).

<comment><USER6> Why don't you like player projection systems? While it's impossible to accurately predict almost anything as complex as baseball consistently, players projections are an awesome tool.

<comment><USER5> I can understand why people like them. I don't say they suck and they're of no use. I just don't like them personally. Not really sure why. I think it's because the line "you can't predict baseball" keeps running through my head. PECOTA is as accurate as they come, though.

</comment></comment></comment><comment><USER7> Thanks for posting this. A very enjoyable article that demonstrates how the broader application of entrepreneurial behaviors to a problem, that Nate clearly has a passion for, can blow the incumbents clean out of the water.

I doubt we've heard the last of Nate Silver.

</comment><comment><USER8> _By the end of [election] night, Mr. Silver had predicted the popular vote within one percentage point, predicted 49 of 50 states' results correctly, and predicted all of the resolved Senate races correctly._

From his posted predictions back in March? W-o-w.

<comment><USER9> No, his site maintained an updated assessment of the current probability. I'm not really sure what the article means when it says he 'called it' in March. He was probably just showing Obama with a greater chance of winning.

<comment><USER4> He showed Obama with a higher percentage except for immediately after Palin, and then he explained that it was a bump that promised to diminish.

What impressed me about his site isn't just his predictions, but how good he was at predicting how his model would change in the future. He could predict how his model would change every day for a week in advance, and he was almost always right as to how the "market" would react.

</comment></comment></comment><comment><USER10> Um, I (and the whole world) called it for Obama before 10pm that night. It seemed clear to me that the "incumbents" must have been legally required (or something) to wait till the polls closed on the west coast before they could make it official.

And lots of people called the election months before too. I followed <http://electoral-vote.com/> just because I followed them the last two elections. The job of prediction they did was comparable. Though FiveThirtyEight.com did seem to have more/better features.

<comment><USER4> Yeah, but he had it predicted back in March, and by two weeks before the election he had nearly every state accurately predicted.

<comment><USER10> I was mostly commenting on the fluff at the start of the article about calling the election at 9:48 EST.

<comment><USER4> Agreed. That _was_ silly.

</comment></comment></comment></comment><comment><USER11> Does Nate Silver invest on Intrade (or another prediction market) and make money off of his predictions? If not, why not?

<comment><USER12> There's not really a whole lot of liquidity on the majority of the state markets. Difficult to make money when the bid-ask spreads are so large.</comment></comment>


Event-Driven Architecture - <AUTHOR> https://pradeeploganathan.com/architecture/event-driven-architecture/ <comment><USER3> There's something about event driven architectures that captures our engineering minds and makes our imaginations run wild. At face value it seems like the Grand Unifying Theory of software engineering, a Grand Unifying Architecture. Everything is perfectly decoupled and only reads and writes to an event bus. Perfect uniformity, everything just reads and writes events. Perfect open-closed semantics, I can completely add new functionality without touching any existing components just by having it read from the event bus.

However, like the grand unifying theories of physics so far, it just doesn't match reality. I have yet to witness a system that fully embraces event driven architecture that isn't a complete nightmare to read, understand, debug and modify. Yet we seem unable to shake the idea that it is a panacea. It captures the minds of each new generation of engineers and gets implemented in the technology of the era. For me it was applying the observable pattern to everything in Java. Now it's setting up a bunch of microservices that only communicate through Kafka. Maybe I'm just not a true Scotsman but this pattern has anecdotally never worked well in anything I've had to work with. I would think very hard before applying it as a pattern in my code let alone as the driving force of my architecture. That's just my experience and 2 cents.

<comment><USER4> In my experience it's a bit the opposite; the domains I've worked in have always have events, whether given that name or not, and the systems for handling these events are usually coded much more optimistically and naively at first before people break down and start migrating parts of the system to run in event-driven style for performance and reliability reasons. People who are aware of event-driven architecture tend to make a smoother transition and create systems that make sense and are easier to work with. People who get there accidentally, forced every inch by successive performance and reliability bugs, end up with a hodge-podge that in retrospect is a poorly designed event-driven system.

But that's just what I've seen in my experience. I've seen damage from people being ignorant of event-driven architecture or being in denial about how their systems are evolving; you've seen damage from people being overeager to use it. Probably in your shoes I would have seen the same things you have.

One thing I've given up on seeing is the content of the linked article.

<comment> safety-third In my experience, much more damage has been done by people who implement EDA and fancy cloud architecture in general. Something like 95% of applications are simple CRUD with a minuscule amount of custom domain logic. Doing anything beyond a sanely laid out monolith for these is resume padding and potentially project killing. I think people just don't want to admit that their job is validation, presentation, and shuffling data in and out of a database.

<comment><USER4> Yeah, but very quickly in my experience the simple REST-based CRUD service starts waking up every 15 minutes to post a batch of rows from the database to a different REST-based CRUD service (or to itself if you have a monolith), and when that gets slow it gets scaled by increasing the wake-up frequency, and then someone starts writing batching logic and trying to scale it horizontally. Then external services start getting mixed in (and, if you're doing B2B, customer services) and you have to deal with their performance and reliability issues. Or maybe not; maybe you're Reddit and can get huge while still being essentially a CRUD app with a couple of UI front ends.

</comment></comment></comment></comment><comment><USER5> It seems like the post on event driven architecture couldn't handle the click event load from Hacker News and is throwing a "Database Error".

<comment><USER6> Yup, the pipelines are down and CQRS is suffering :D

<comment><USER7> That's a saga for another time.

</comment></comment></comment><comment><USER8> Here is a cached version of the article: [https://webcache.googleusercontent.com/search?q=cache:https:...](https://webcache.googleusercontent.com/search?q=cache:https://pradeeploganathan.com/architecture/event- driven-architecture/)

</comment><comment><USER9> I'm consistently surprised at the negative comments on EDA on Hacker News because there are so many examples of major organizations successfully implementing and running EDA at scale. Here are a few examples:

Uber:

\- [https://eng.uber.com/ureplicator/](https://eng.uber.com/ureplicator/)

\- [https://eng.uber.com/reliable- reprocessing/](https://eng.uber.com/reliable-reprocessing/)

Google:

\- [https://cloud.google.com/blog/products/gcp/implementing- an-e...](https://cloud.google.com/blog/products/gcp/implementing-an-event- driven-architecture-on-serverless-the-smart-parking-story)

Twilio:

\- [https://signal.twilio.com/2017/sf/sessions/18530/building- ro...](https://signal.twilio.com/2017/sf/sessions/18530/building-robust-and- scalable-data-pipelines-with-kafka)

Stripe:

\- [https://stripe.com/blog/canonical-log- lines](https://stripe.com/blog/canonical-log-lines)

My hypothesis about why this is, is that most organizations probably don't need EDA yet. They don't have that many data producers and consumers and don't have HA and other requirements that drive the need, so implementing it is overkill, and so their experiences have been bad.

<comment><USER10> "Trying to implement google-scale things when you're tiny" seems to be an extremely common and understandably tempting antipattern.

<comment><USER11> But "trying to decouple, modularize, and choose the right tools for the job" for your applications seems applicable at any scale.

EDA requires a change in testing methodology, in software design, and a bit of reading, but calling it a "google-scale thing" is pretty fallacious. The idea that a monolith is easier to maintain or that synchronous inter-component communication is easier to reason about also seems fallacious.

I'd love to see a chart of developer's perceptions of event driven microservices and their personal operational expectations.

<comment><USER10> My point was meant to be more general, in that people try to implement the "google-scale" version of any given conceptual model even when they don't need to (i.e. this is about "choosing the right tools")

For example, one can do a CQRS style database setup just fine with a single API server, a single worker process system, and a single postgresql db - <USER2> given all changes are already driven by command objects, building out other datastores later if you need to tends to work out well.

Though I would also point out that _on average_ , communication within a process is easier to reason about than communication outside because there are fewer failure modes, and sync is easier to reason about than async because there are fewer failure modes.

Admittedly, a monolith _does_ make overly tight coupling between components easier to not notice as you're doing it ... but then again it's depressingly easy to accidentally end up with what's essentially a distributed monolith even with a theoretically-microservice-based design (googling "distributed monolith" will provide a bunch of articles with disagreeing definitions of the term ;)

</comment></comment></comment></comment><comment><USER7> This is just an overly elaborate concept of a centralized (or commonly accessible table) of states that other independent systems can use for their own "triggers".

What seems like a lifetime ago, we achieved this with IBM MQSeries allowing us to send events from a Microsoft transaction server (MTS) object to a COBOL program that listened for the events to insert records into an order entry system that was on an AS/400 DB2 db.

Maybe an Event Bus concept carries all the expected "good design aspects" of this pattern. But it is just another example of an _integration concept_ \- but please can we stop with evangelizing this as though it ought to be the linchpin or necessary aspect of a good modern system you are starting with!

Edit: this design concept 25 years ago was the best we had considering the zero alternatives for guaranteeing that events don't get lost etc. IOW: this design itself was a compromise for absence of a cohesive and unified database (what the Event Bus crew and the Microservices crowd would now call a monolith)!

<comment><USER12> I think this is just a good overview of the architecture and its characteristics. I'm not sure anyone is trying to evangelize anything.

</comment></comment><comment><USER13> Event-driven architecture can be nasty. Ideally, you want the point of origin of an action, and the point of its execution, to be connected by a chain of function calls which can be traced in a debugger.

Events are not easily traceable. An event is pulled from some event queue, and by the time that happens, the thing that put the event into the queue has long since buzzed off to do something else.

That's just one problem. The other problem is how events can be subject to a routing, translating, duplicating and splitting labyrinth. Events can bi{tri,quad,...}furcate. Just because your code is processing the event over here doesn't mean you were the first to do so, or the last.

I have a good idea! Let's process this event and re-inject it. Two years later, someone is debugging an event routing loop.

</comment><comment><USER14> For people cannot view the article, here's an archive: [https://web.archive.org/web/20200210123446/https://pradeeplo...](https://web.archive.org/web/20200210123446/https://pradeeploganathan.com/architecture/event- driven-architecture/)

</comment><comment><USER15> Ubuntu's "Upstart" init system used an event-based design, which was criticized by the creator of systemd, thus:

—

[Upstart]'s main feature is its event-based approach: starting and stopping of processes is bound to "events" happening in the system, where an "event" can be a lot of different things, such as: a network interfaces becomes available or some other software has been started.

Upstart does service serialization via these events: if the syslog-started event is triggered this is used as an indication to start D-Bus since it can now make use of Syslog. And then, when dbus-started is triggered, NetworkManager is started, since it may now use D-Bus, and so on.

One could say that this way the actual logical dependency tree that exists and is understood by the admin or developer is translated and encoded into event and action rules: every logical "a needs b" rule that the administrator/developer is aware of becomes a "start a when b is started" plus "stop a when b is stopped". In some way this certainly is a simplification: especially for the code in Upstart itself. However I would argue that this simplification is actually detrimental. First of all, the logical dependency system does not go away, the person who is writing Upstart files must now translate the dependencies manually into these event/action rules (actually, two rules for each dependency). So, instead of letting the computer figure out what to do based on the dependencies, the user has to manually translate the dependencies into simple event/action rules. Also, because the dependency information has never been encoded it is not available at runtime, effectively meaning that an administrator who tries to figure our why something happened, i.e. why a is started when b is started, has no chance of finding that out.

Furthermore, the event logic turns around all dependencies, from the feet onto their head. Instead of _minimizing_ the amount of work (which is something that a good init system should focus on, as pointed out in the beginning of this blog story), it actually _maximizes_ the amount of work to do during operations. Or in other words, instead of having a clear goal and only doing the things it really needs to do to reach the goal, it does one step, and then after finishing it, it does _all_ steps that possibly could follow it.

Or to put it simpler: the fact that the user just started D-Bus is in no way an indication that NetworkManager should be started too (but this is what Upstart would do). It's right the other way round: when the user asks for NetworkManager, that is definitely an indication that D-Bus should be started too (which is certainly what most users would expect, right?).

A good init system should start only what is needed, and that on-demand. Either lazily or parallelized and in advance. However it should not start more than necessary, particularly not everything installed that could use that service.

Finally, I fail to see the actual usefulness of the event logic. It appears to me that most events that are exposed in Upstart actually are not punctual in nature, but have duration: a service starts, is running, and stops. A device is plugged in, is available, and is plugged out again. A mount point is in the process of being mounted, is fully mounted, or is being unmounted. A power plug is plugged in, the system runs on AC, and the power plug is pulled. Only a minority of the events an init system or process supervisor should handle are actually punctual, most of them are tuples of start, condition, and stop. This information is again not available in Upstart, because it focuses in singular events, and ignores durable dependencies.

[…]

— [http://0pointer.net/blog/projects/systemd](http://0pointer.net/blog/projects/systemd)

</comment><comment><USER16> Web servers are event-driven architecture. They listen to events on the HTTP bus.

</comment><comment><USER17> Says database error. Was that an event?

</comment><comment><USER18> When I follow the link to the article I get an "Error establishing a database connection" message.

Delicious irony.

<comment><AUTHOR> yes, this is ironical. I was away and thanks for the HN hug of death my blog went down :-). My blog provider throttled it down severely and I was able to restore it from backups just now. I blog occasionally to put down notes on what ever I am working on or thinking through, in the hope that maybe it would help some one or myself in the future. Apologies if I wasted your time.</comment></comment>


Show HN: Dasherize – Open-Source Dashboard for Project Health Status - <AUTHOR> http://www.dasherize.com/ <comment><USER2> Like many 'Show HN' posts lately, this site suffers from readability problems by using thin fonts. The text almost disappears into the background for me on Win7 Chrome: [http://i.imgur.com/mDayCop.png](http://i.imgur.com/mDayCop.png)

<comment><AUTHOR> Hi! I built Dasherize. Thanks for bringing that to my attention. I'll look into it!</comment></comment>