Best CPUs for Workstations: 2017 - <AUTHOR> https://www.anandtech.com/show/11891/best-cpus-for-workstations-2017 <comment><USER2> "Some workstation users will need ECC memory, and up to 512GB of it. When memory has an error rate of 1 error per GB per year, using 512GB ensures almost two bit errors per day: something that a 60-day simulation would find catastrophic."

<comment><USER3> Just to offer a partial counterpoint to the popular "ECC is a must for real work" sentiment, I've ran many 60-day simulations where a few bit errors would be completely irrelevant. Many physics simulations include internal checks (that must be there regardless of ECC, for algorithmic reasons) that would catch virtually all such issues. While a bit error could certainly crash the simulation, long running simulations can be resumed from checkpoints with minimal loss of time and the probability of a crash is still very low for most real workloads.

In truth, there are plenty of good reasons, both for data integrity and security, to have ECC. However, there are real costs to ECC too - 10-30% immediate performance overhead (depending on your application) and much more than that for memory-bound workloads (due to lower frequencies and subtiming issues), not to mention hardware cost efficiency. Instead of oscillating between "ECC for everything" and "ECC is useless" people should rationally compare the costs and benefits for their specific workload and choose accordingly.

<comment><USER4> Thank you! That sentiment on HN about how "Everything should have ECC" really grinds my gears. There is no need for ECC in your iPhone or on your MacBook. Your average emoji-laden WhatsApp Conversation with your friends does not require Bit Error Correction. People who really need ECC do exactly what you just mentioned: Evaluate, and often enough they will find little to gain from ECC.

<comment><USER5> But when you need ECC, you really need it. My FreeNAS server has like 32GB or ECC memory because it runs ZFS, which basically doesn't work unless you have ECC memory. However, my desktop computer or my laptop don't need it. When you need ECC, use it, but if you don't need it, then no biggie.

<comment><USER6> Why does ZFS "really need" ECC? I have a few friends running freenas on just old machines without ECC, no issues so far a few years in.

<comment><USER7> Traditional filesystems will let files just sit on the hard drive, untouched.

ZFS is a lot more active... checksumming and caching mean that important information is spending time in RAM. It's not good if that information gets corrupted.

<comment><USER6> Doesn't ZFS perform checksumming and error correction on that data to make sure that memory or disk issues _don 't_ get affected by corruption? I thought that was a main reason to use it.

<comment><USER7> Well right. It protects against silent bitrot on the hard drives. But it does this by caching and checksumming _in RAM_ , so now you need to defend against bitflips in RAM.

It's not that ZFS without ECC is completely unsafe... it's just not as safe as it could be. ECC RAM becomes the next biggest concern once you've addressed on-disk bitrot.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> OT:

I am in the market for an upgrade to my home PC. I use it for Compiling and Gaming.

I am finding the sheer variety of CPU's and their weird naming conventions utterly confusing. Then combine that with the almost-as-confusing choice of motherboards and the bit-better-but-not-much choice of RAM and I am completely lost.

Any tips out there for finding a path through this maze, how do I upgrade my PC without requiring an advanced degree in Intel/AMD marketing speak?

 _EDIT: Added use of PC._

<comment><USER9> [http://www.logicalincrements.com/](http://www.logicalincrements.com/) is a handy site that recommends PC builds that give you a good bang-for-buck at various price points. On a given horizontal line, the CPU, motherboard, and RAM will all be compatible.

The site is tilted for gaming, but GPUs are mostly interchangeable - so if you want more compute power, you can drop to a lower GPU and spend the money on the CPU instead.

<comment><USER9> Oh, and the #1 upgrade you can make for everyday use is a SSD. I was recently impressed at just how fast an old Core 2 Duo system was once I installed an SSD. It won't do much for gaming (aside from improving load times), but it will make the rest of the things you do on the computer more pleasant.

</comment></comment></comment><comment><USER10> Remember that one-bit errors aren't necessarily small errors. A single one bit change when working with 64 bit floating point can result in a very large difference in value.

0b0111111111101111111111111111111111111111111111111111111111111111 == 1.7976931348623157e+308

0b0011111111101111111111111111111111111111111111111111111111111111 == 0.9999999999999999

<comment><USER11> How often doe a program load an FP with a value at the absolute extreme of the range though? I mean, if my value is there, I probably already have a problem.

<comment><USER10> Yes, but the point is that flipping a single bit can change a value dramatically. While using 64 bit ints for example programs are likely using a limited range of values and flipping a bit in say the middle of the int will change the value by plus or minus 4294967296. Not many programs will handle this gracefully.

</comment></comment></comment><comment><USER12> Why does the image on this article show rackmount equipment while talking about workstations? I find their selections to be, at least for my work, much more server-oriented than workstation.

Do a lot of people really run >512GB RAM in their workstations rather than running a "thin" workstation and running simulations on servers or EC2?

I just built a new workstation a couple months ago: i7 7700 (not the K), 64GB RAM, one of those closed loop CPU water coolers... As a workstation, I wanted it quiet, and performance has been great. Long running jobs I run on our dev/stg cluster (4 machines, 512GB total RAM, 48 total cores.

<comment><USER13> I second that, in most cases, 64GiB is enough for workstation clients.

I can think of some reasons to have twice, four times, or eight times as much though. You can almost never have enough block cache, after all. Local testing databases come to mind. Also, tracing/profiling Elixir programs takes up enormous amounts of memory. My colleagues at my last company did not have enough RAM to generate meaningful profiles of our system, 64GiB was just barely enough to get a signal out of it. Rather than spending a month working on the profiler, it was nice to be able to get some data out of it as-is.

<comment><USER14> Depends on what you're doing. With video or 3D work, 64GB can often be a bottleneck. With After Effects and Maya rendering we've gone over our 96GB RAM limit using dual Xeon 6-core (i.e. 24 logical) on multiple occasions, especially rendering 4K+ scenes, forcing us to set limits on RAM/thread usage. I want to upgrade them to 128GB but getting bigger ECC RAM sticks in Austria (and EU in general) was (and still is) difficult and stupidly expensive.

</comment></comment></comment><comment><USER15> A discussion when Ryzen was released had quite a bit of info on PC builds:

Ryzen is for Programmers | [https://news.ycombinator.com/item?id=14243350](https://news.ycombinator.com/item?id=14243350) (May 2017, 272 comments)

<comment><USER16> Why did I have to scroll down so far for a Ryzen shoutout? Building with Ryzen has been one of my best investments in years.

</comment></comment><comment><USER17> Well it's nice to finally have serious competition in x86 CPU market.

<comment><USER18> ... again.

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

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

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

<comment><USER17> good point but it has being a while

</comment></comment></comment><comment><USER19> I wonder how the EPYC 7401P would compare with the 1950X in terms of performance/price? It has 24 cores v. 16, but with a lower clock speed, and is $51 more. If you can actually use all the cores, I suspect better?

<comment><USER20> How much more are the Mobo's though?

<comment><USER21> And do the motherboards support features that you would expect out of a consumer version? They often only have a couple usb and video out, with very few features.

</comment></comment></comment><comment><USER22> The new AMD CPUs look otherwise good, but it seems they still don't run rr. Giving up rr is not a reasonable option if the purpose of the workstation is developing software in the kind of language that gdb can make sense of (C, C++, Rust).

</comment><comment><USER23> A workstation will be used or at least turned on 24/7\. The one I just sat down at sure is. So when calculating costs one should include daily power consumption (power used + cooling needs). Some of these new intel chips run very hot.

</comment><comment><USER24> Doesn't Coffee Lake release today? I'm upgrading for sure.

<comment><USER25> It did.

Discussion here: [https://news.ycombinator.com/item?id=15408850](https://news.ycombinator.com/item?id=15408850)

</comment></comment><comment><USER26> If money were no object, Xeon Platinum 8180m ($13k retail).

<comment><USER27> 28 cores sure, but they run a base frequency of 2.50GHz. For $1469 you can have the i9-7940X 14 cores at 3.1GHz probably more suitable for a workstation.

<comment><USER28> No ECC support

<comment><USER27> I'd go for the Threadripper 1950X if that is a requirement then 16 cores, 3.4 GHz, ECC support all for under $1000. Intel doesn't really have anything that meets those requirements at a reasonable price.

<comment><USER29> I thought he said if money was no object...

<comment><USER30> Then his choice is $13,000 vs $1,000.

Money may not be an object, but choosing the first option seems a little stupid. Even rich people don't throw away money like that, because if they did, they probably wouldn't have gotten rich in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER31> Somewhat off topic, but what about open hardware platforms that are really friendly to hacking around on the hardware?

Is this just a thing of dreams?

<comment><USER32> Can you explain more what you mean by open hardware, or expand on what kind of hacking around are you looking to do?

<comment><USER31> Thanks for asking!

I don't have any precise requests, but I would like to be able to pretty much hook up an oscilliscope or logic analyzer anywhere and in principle be able to understand what's going on.

I'm looking to get into hardware by way of tinkering and my mental model is of open software. Currently, any time I have a burning question about one of my tools, I can just open a man page as well as start digging into the source. I think it would be cool to do the spiritual equivalent with hardware.

For example, I am currently digging into the bootup process--everything after CPU POST until a fully ready userspace. However, the details that between pressing the power button on the power supply and CPU POST are completely opaque to me, and some are completely opaque even in principle on my current system. I'd like to have the ability to fully grok the electrical underpinnings of what's going on or at least as close as possible.

</comment></comment></comment><comment><USER33> Somewhat off-topic, but I need to replace my ancient workstation and would love a recommendation. I prefer to max cores and do not care much for clock speeds (I work mostly on algorithm development and can parallelize experiments relatively easily but often run multiple unrelated tests). 10-15k budget.

I was thinking of dual-CPU Z840; are there better options?

<comment><USER34> You can get 64 cores, 128 threads on a 2P EPYC7551 with 256GB of ECC RAM in a rackmount server with redundant power supplies for that much money. e.g. SiliconMechanics.com

<comment><USER33> Thank you for the suggestion, I will look at SiliconMechanics. I need a tower, not rack mounted, but I see capable systems with 24-28 cores there. The site seems to be in a disarray, at least for high performance workstations (two rightmost options of the four, which I would assume to be the most capable are showing up as discontinued when I click on them, etc.).

</comment></comment></comment><comment><USER35> Just in time for Intel to release the 6c/12t Coffee Lake i7, and make all of these comparisons (slightly) out of date.

</comment><comment><USER36> I was one step from getting a threadripper... But then I opted for a 1800x, I will invest more on the gpu side when there will be the hw to properly drive a 4/8k vr headset eh:) I wonder though if there's a way to restore disabled cores on a Epyc chip... As according to and Amd they all born with 32 cores...

</comment><comment><USER37> Hasn't cloud computing reached the point where local workstations like this aren't required?

<comment><USER38> First of all no one has really successfully solved the running Autocad etc. in the cloud problem. Secondly the per core performance is generally pretty poor on cloud computers when compared to high end workstations and for many workloads 16 really fast cores beat out 64 slower cores.

Finally, cloud computing is still really expensive compared to dedicated hardware. A halfway decent EC2 'workstation' like the p2.xlarge is over $5000 a year (plus storage) if you pay for the whole year up front and that 'only' gets you 4 cores and 60 GB of RAM (and a pretty good GPU). $5000 will buy you a really nice workstation with much better specs, and you get to keep it at the end of the year

<comment><USER39> Onshape provides CAD in the cloud, does AutoCAD need a lot of local CPU power ?

<comment><USER40> Yes, most engineering applications end up doing all sorts of simulation that can be summed up as 'run as much math as fast as possible.' There's just routing traces on a PCB, there can be heat or stress simulations on a part built with constructive geometry, and a lot of other things that lets an engineer simulate/try something interactively and not simply 'draw a part.' This is where good workstations can definitely make a difference. An example product that is definitely going to need the local beef: [https://www.autodesk.com/products/cfd/overview](https://www.autodesk.com/products/cfd/overview)

</comment></comment></comment></comment><comment><USER41> $999 for the best choice seems really high to me. I understand that they're trying to generalize a broad range of applications, but still.

They mention the Ryzen 5 is better bang for the buck, but dismiss it for having "low overall performance." I guess I'm wrong in thinking that, for 98% of people, a $250 CPU would still be wasteful.

<comment><USER42> But this is about workstations where CPU bound workloads are running, like rendering or compilation.

Most people will either buy a laptop or desktop (if their smartphone is not sufficient) and not spend nearly as much money, they only need to run a browser and a couple of other small programs.

<comment><USER43> A browser is not a small program. Video can still be demanding (watching, or chat).

The workloads are fairly _standardised_ and non-diverse. Not necessarily _small_.

</comment></comment></comment><comment><USER44> Since this article is about "workstations", it should have only considered ECC-enabled systems. Since it didn't (hardly mentioned ECC in fact) it's a useless article IMHO.

</comment><comment> dis-sys anandtech.com used to be an okay source, but it is getting worse pretty quick, non-sense article like this is helping anantech to get that position fast. threadripper 1950x is not the overall best workstation processor, it is more like a toy for kids into gaming/overclocking.

1950x is slow for multithreaded applications, it has a low cinebench score of ~3,000, you pay some serious $ for a fancy motherboard full of LED lights, then you don't have officially verified ECC support.

As a comparison, you get the same mutithreaded speed, much cheaper system cost if you just buy second hand dual 2696v2 processors with real ECC support. if you need real processing power in a single box and have a tight budget, there is a flood of E5-2696v4 processors on the market at $950-1,100 each. for a much nicer budget, you can always go dual/quad Intel 8180.

<comment><USER45> Nice one, you compare second hand prices to brand new prices. Anandtech's goal is to guide you in the chip market buying it brand new, not hunting it on ebay. Also, what they say with the 1950x being the best compromise between number of PCIe lanes, processing power, maximum memory etc. If you didn't notive, performance is not their only criteria.

<comment> dis-sys I listed dual/quad 8180 as a good option. I don't think you can get second hand 8180 on ebay.

For 1950x, details explanations were provided in my post -

1\. too sloow, cinebench score is 3k, you can get it from 4-5 years old ancient processors already declared as EOL. 2\. no official ECC support

I can list more actually - single socket system with 8 DIMMs only. As explained, it is a good platform for kids to game/overclock.

<comment><USER45> Sure, but as you say yourself, the 8180 isn't the same budget at all, so I excluded it from your price comparison. Also, it's not a competitor to the 1950x. I guess in the end it all depends on what you need to do. Your need seems to be maximum performance, why go for the best "compromise" CPU and then criticize their choice? Clearly you should go for either of the 3 recommended CPU for performance. (which are also better for PCIe lanes and memory, but have a poor performance price ratio).

<comment> dis-sys if it is about budget, or performance per $, surely you'd be buying Xeon from ebay. you don't lose anything as the likelihood of having a dead processor 18 months from now is pretty much 0, no warranty required.

if it is about PCIE lanes, you should at least be buying dual socket systems, that gives you more PCIE lanes than 1950x.

if it is about memory, well, 1950x is limited to 8 DIMMs.</comment></comment></comment></comment></comment>


Police Raided Company Selling $30M of Knock-Off Legos - <AUTHOR> https://www.npr.org/2019/04/27/717840078/everything-is-not-awesome-for-chinese-company-busted-for-selling-fake-legos <comment><USER2> Quite a lot of adults dived into the bad lego scene for small kids. Its actually counter-productive: soft lego and bad-fit lego makes kids not want to use it. The top quality stuff is thou accurate, and it shows. (I had some older pre-70s lego and it was definately less strong than the newer stuff)

<comment><AUTHOR> I watched a video too that was celebrating the downfall of the counterfeiter, and it mentioned there was something on the bricks, like a film or a grease. I can't imagine that is healthy.</comment></comment>


Exploiting Wi-Fi Stack on Tesla Model S - <AUTHOR> https://keenlab.tencent.com/en/2020/01/02/exploiting-wifi-stack-on-tesla-model-s/ <comment><USER2> So this exploit is not specific to Tesla but rather any Linux 2.6.36 (and maybe up) that uses the 88W8688 (and maybe others), which could be a pretty common combination. And all that's required is an AP running the exploit, everything is automatic. Very impressive.

<comment><USER3> Q: How come Teslas are running kernels from 2008?

<comment><USER4> It appears that: Tesla bought this all-in-one ARM board from Parrot, and Parrot gave them a 2.6.36 kernel with thousands of custom patches in, and Tesla's not in much of a position to port it to a newer kernel, and then Parrot presumably went on to building other stuff and ignored keeping this kernel up to date and now we're here.

They (probably Parrot) might have updated it in the last year since the vulnerability was discovered though, it's hard to tell.

<comment><USER5> If it's not in mainline kernel - it's abandonware.

</comment></comment></comment></comment><comment><USER4> > As Linux Kernel 2.6.36 does not support NX

Does the Model S really run 2.6.36, first released ten years ago? I'm sure they're using a stable branch and keeping up with security patches in general [1], but that's still shocking to me.

[1]: although not 100% of security patches are going to end up in the stable@ queue or have their effect on 2.6.36 considered.

<comment><USER6> It looks like a car would need to be over 2 years behind Tesla's OTA updates for it to still have version 2.6.36 and be vulnerable to this exploit.

[https://electrek.co/2017/06/30/tesla-new-linux-kernel- update...](https://electrek.co/2017/06/30/tesla-new-linux-kernel-update-ui- improvements/)

EDIT: See nils2014's comments below. The WiFi chip is connected to the entertainment system which received an updated kernel, but it is seems like the kernel on the WiFi chip itself may not have been updated.

<comment><USER7> The kernel version of the information center is irrelevant.

The Wi-Fi stack is running on a _separate_ module (the Parrot module, as mentioned in the article), which runs its own obsolete linux version.

<comment><USER4> I wonder if there's a way to find out which kernel version Parrot runs today.

<comment><USER8> Do they even still exist? It's impossible to find anything on these modules beyond FCC filings; some pixelated datasheets show the modules with "www.parrot.com" printed on them but going as far back as 2017 in the WWW archive, that site belongs to some drone startup.

<comment><USER4> What do you mean by "still exist"? Obviously a vuln was found in one that was inside a Model S, reported to Tesla and fixed.

<comment><USER8> Marvel fixed the bug in their firmware and apparently Tesla shipped some sort of update, I don't see anything that necessarily requires Parrot, the obscure maker of these modules, to do anything.

<comment><USER4> Oh! You misunderstood my question: I meant to ask whether Tesla's latest software update continues to ship a 2.6.36 kernel on Parrot, or a newer kernel instead, as they do for their other modules.

(Tesla uses the name Parrot to refer to this system in the car.)

A reason for them not to still be on 2.6.36 is that it's deeply exploitable.

<comment><USER8> I think the root of the confusion here is that you think Parrot is just a Tesla nickname. But Parrot is the name of the manufacturer of the fully- integrated WiFi+Bluetooth module so Tesla likely have nothing to do with the firmware that runs on that module with the ancient kernel.

As far as I can tell, Parrot-the-module-maker split from Parrot-the-drone- company and is now [http://parrot-faurecia-automotive.com](http://parrot- faurecia-automotive.com)

<comment><USER4> Oh, I didn't get that impression. Keen's previous Black Hat paper made it sound like Tesla is dual-maintaining 2.6.36 and 4.x kernels, because they're unable/unwilling to upgrade from 2.6.36 on the Parrot board but are still issuing kernel fixes for it.

<comment><USER8> Looking at the datasheet some more, it does seem like the intention is for Tesla (or some other customer) to develop userland software and integrate that with Parrots SDK into a final firmware image for the module. But in that case, their situation is much the same as it is with the nVidia Tegra entertainment board: you are totally dependent on nVidia and Parrot to provide the basic infrastructure from bootloader to a Linux kernel with drivers to interface all the functionality they are selling you (a BSP). None of their hardware has any part upstreamed.

In Teslas position, as the ultimate vendor that is shipping this stuff on thousands of cars, you might decide that your supplier isn't forthcoming with security updates and decide to backport some isolated fixes to the kernel, but an upgrade from 2.6 to say even 4.4 is entirely out of the question; there are thousands of lines of hacked-together proprietary vendor code in those kernels where just going up a minor version will break the build. For a 2.6 based system in particular, you would essentially need to convert the entire board support to a device tree based system.

<comment><USER9> > there are thousands of lines of hacked-together proprietary vendor code in > those kernels where just going up a minor version will break the build. For > a 2.6 based system in particular, you would essentially need to convert the > entire board support to a device tree based system.

What I don't get with these cases at all: by the GPL manufacturers are forced to provide the full (!) Linux kernel source code, same goes for u-boot. But while Tesla at least seems to provide source code ([https://github.com/teslamotors](https://github.com/teslamotors)), why the fuck and how can Android phone and other embedded device makers get away with not publishing anything?

Let's just take two examples of hardware that I know run Linux because I managed to root them:

\- Sony A7S2 camera: the firmware is at [https://www.sony.com/electronics/support/downloads/00016077](https://www.sony.com/electronics/support/downloads/00016077), but no mention _at all_ about contained open-source code, licenses, or build instructions

\- HP Z2100 24-inch plotter: firmware is at [https://support.hp.com/sg- en/drivers/selfservice/hp-designje...](https://support.hp.com/sg- en/drivers/selfservice/hp-designjet-z2100-photo-printer-series/3204963) (you have to select Windows XP 32-bit to see the firmware download, even though the firmware can be installed via anything capable of running a browser), and again, no mention of anything regarding Linux.

<comment><USER10> It's important to remember that the GPL does not require that the modified source be publicly accessible, only available to those who you've distributed the modified program to. How that's verified and distributed is unspecified.

<comment><USER4> > only available to those who you've distributed the modified program to

That's not true. GPLv2 text:

> Accompany it with a written offer, valid for at least three years, to give > _any third party_ , for a charge no more than your cost of physically > performing source distribution, a complete machine-readable copy of the > corresponding source code

(Emphasis mine.)

<comment><USER10> There's two issues with that. First, that's only one of three available options (two for commercial entities) that satisfy the license. The other is to include a copy of the source code with the software distribution. However, separately, this does not require that the source code be posted in a public place for anyone to access. You only must give with the distribution a written offer. That offer is valid to anyone, but it doesn't need to be posted in public and the source code does not need to be posted in public.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> If you find WiFi-based attacks on devices to be interesting, you may be interested in the following research from Google Project Zero on attacking the iPhone's WiFi stack (and linked are articles on Android):

[https://googleprojectzero.blogspot.com/2017/04/over-air- expl...](https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting- broadcoms-wi-fi_4.html)

</comment><comment><USER12> Technically interesting and also interesting that this comes from Tencent.

> Tencent Holdings Limited is a Chinese multinational conglomerate holding > company founded in 1998, whose subsidiaries specialise in various Internet- > related services and products, entertainment, artificial intelligence and > technology both in China and globally.

<comment><USER13> I'd say it's no different to Google Project Zero.

Of course since it's China, there'd be worries. I'd guess the Chinese government also employs crack hackers, like the NSA probably does?

<comment><USER14> Yeah, but they don't share 0 days like this, just like the NSA doesn't.

<comment><USER15> From the article:

> Responsible disclosure

> All the two vulnerabilities we presented above are reported to Tesla in > March 2019. Tesla already fixed them in version 2019.36.2, and the Marvell > also has deployed a fix and published a security advisory[4] to the issue. > The disclosure of the vulnerability research report had been communicated to > Tesla, and Tesla is aware of our release.

<comment><USER14> Right... They shared the 0 day.

NSA and Comment Crew just sit on them like a dragon hording gold.

<comment><USER16> I believe it's less black and white than that - all of these organizations have both offensive and defensive priorities and sometimes choose to disclose exploits publicly after calculating their remaining value. See e.g.

[https://foreignpolicy.com/2017/09/25/is-the-nsa-doing- more-h...](https://foreignpolicy.com/2017/09/25/is-the-nsa-doing-more-harm- than-good-in-not-disclosing-exploits-zero-days/)

[https://www.npr.org/sections/alltechconsidered/2017/11/17/56...](https://www.npr.org/sections/alltechconsidered/2017/11/17/564755961/government- outlines-when-it-will-disclose-or-exploit-software-vulnerabilities)

<comment><USER14> Can you give an example of a recent (say last decade) exploit the NSA or PLA Unit 61398 have publicly disclosed?

<comment><USER17> In a way NSA did publicly disclosed Eternalblue.

<comment><USER14> Lol, not quite what I meant.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> By only connecting Tesla to AP with PMF (encrypted management frames) enabled, this exploit would not work? Because then you can not force a reconnect to AP using Deauthenticate frames.

The problem is more explained here in a recent HN post: [https://news.ycombinator.com/item?id=21889837](https://news.ycombinator.com/item?id=21889837)

<comment><USER8> The DEAUTH thing is entirely incidental to the fully remote kernel code execution exploit chain.

<comment><USER18> I can agree on the Deauth, though it would maybe make it less receiptable to automated attack. I see that Action frames also is encrypted and verified when enable PMF, so it is still viable to avoid the exploit?

</comment></comment></comment><comment><USER19> I'm not sure why firefox thinks I need DRM enabled to play the video on there.

</comment><comment><USER20> Would having a Rust based embedded OS help with attacks such as this?

<comment><USER21> Yes, it would panic when the copy reached outside the bounds of the buffer.

</comment></comment><comment><USER22> Good to see at end all were reported and acted upon before release.

</comment><comment><USER23> With this "wardriving" gets a whole new meaning ;)

<comment><USER24> The MCU is pretty well decoupled from any driving controls other than helping to display a bit of info like the speedometer. I mean it can even be rebooted anytime while driving. So I suspect the larger effect would be on things like entertainment features. Not really driving. But yes harhar, nice play on words.

<comment><USER4> It sounds like you missed that the exploit wasn't in the MCU. That's not the system the wifi chip's connected to.

<comment><USER24> Hmm ic, thanks.

</comment></comment></comment></comment><comment><USER25> Patched already but good to know if you're restoring a write off.</comment>


Ask HN: please review my apps search engine: AppsVu - <AUTHOR> http://appsvu.com/?

<comment><USER2> Remove the ads. Your goal should be to become the standard way people search for apps. Once you do that the business model is obvious (thanks, Google!): app developers pay for ads on the search result page.

First, focus on search quality (precision/recall). Your results right now are awful. <http://iphone.appsvu.com/zynga>

I'd expect a list of Zynga apps, not a list of spam websites[1]. If you hadn't posted this on HN I'd suspect your business model were adsense arbitrage.

Once you have a search engine that actually works I'd release free apps for all the platforms, build Android/iPhone/etc optimized websites, and plug the hell out of the service everywhere there are smartphone users.

The question you should be asking yourself is "Why would someone use this rather than the default way of searching for apps?" For the iPhone that means iTunes. What can you do to make it more useful than iTunes? Are better results enough? Are iTunes' results bad?

[1] I looked through the search results again and realize now they aren't links to spam websites. But the fact that I thought they did is a problem. "Mafia Wars 24 Reward Points FREE by Zynga app detail :: 148Apps :: iPhone Application and Game Revie [sic]" reads like spam.

I suggest you build your own database, and not link to 148apps.com.

<comment><AUTHOR> Interesting. Thanks for your detailed thoughts.

The reasoning behind linking to 148apps and the like was because most app buyers read reviews before making a purchasing decision - so this was meant to help in the use-case, as well as standout above the iTunes search which doesn't have independent reviews.

But, I see where you're coming from and will definitely think about shifting to that track.

<comment><USER2> That's fine. The reviews should be on your site, not some other site.

Maybe mimic Amazon's review system? Get all the reviews from iTunes and augment them by letting people say helpful/not helpful, and then showing the most helpful highest rated review and the most helpful lowest rated review, etc.

Basically create a landing page for each app and then optimize the )(*!@# out of it.

The reason I think this is the right approach in your case (vs. Google) is because your universe is very contained. There's a single, canonical database of applications you need to index (for iPhone apps). Google has to index the whole web, so creating verticalized sub-products is hard to do without knowing what's important and what isn't.

Google is obviously moving in that direction, with maps, reviews, music, video, etc.

This might be different for Android vs. iPhone. I'm not very familiar with the Android ecosystem.

</comment></comment></comment><comment><USER3> Honestly I would rather spend my time developing apps rather than a site that shows peoples apps that have been developed already.

</comment><comment><USER4> Doesn't handle no results very well, it crashes.

Doesn't find apps that exist such as 'kira kira'

<comment><AUTHOR> 1\. Whoa! Thanks! Must have introduced that bug a few minutes back while making last minute changes. 2\. Working on the index quality - not fully indexed the market/appstore yet.

Thanks!

<comment><AUTHOR> Crashing is fixed now.

</comment></comment></comment><comment><USER5> Looks odd when viewed on a large screen.

I'd personal make it 100% width or at least center it.

<comment><AUTHOR> OK! Thanks - I'm guessing it looks squeezed to the left now.

</comment></comment><comment><USER6> oops: <http://iphone.appsvu.com/broadersheet> :)

<comment><AUTHOR> Thanks. The crashing is fixed now. The index is still young as I validate the idea.

</comment></comment><comment><USER7> Quality of search results wasn't very high.

Quantity of ads on page was quite high.

Presentation made it difficult to skim the results.

<comment><AUTHOR> Thanks. With regards to difficulty skimming: Is this because there'a a larger gap between results, or characteristics of the font, ...?

<comment><USER7> I think the gap helps, actually.

I think it's more just the length and repetitiveness of the links... like if I search for Yelp my first result is:

Yelp by Yelp app Detail :: 148 Apps: iPhone Application and Game Reviews And news.....

Maybe it'd work better if you highlighted the search terms?

<comment><AUTHOR> Got it. Yes highlighting and trimming long titles should help with that. Thanks.</comment></comment></comment></comment>


Why Your Startup Will Fail - <AUTHOR> http://gilesbowkett.blogspot.com/2009/01/why-your-startup-will-fail.html <comment><USER3> _Some Reasons Why Your Startup Could Succeed_

-You understand the numbers are against you and realize even if you fail it's worth trying again; you believe it's better to go for _0 for 50_ than _0 for 0_.

-You provide a utility that is good enough for someone to pay for.

-Your startup saves someone time or make someone's life easier.

-Your costs are so low you're virtually impossible to kill.

-You don't care about material possessions.

-Your startup makes others money.

-You treasure not (or rarely) having meetings.

-You love working for yourself.

-There's very little wasted time and red tape. Your team is lean, mean and aggressive.

-You're patient. Twitter, Kayak, Plenty of Fish and Facebook have been around longer than you think. And two of them aren't even profitable.

-You know IPOs or acquisitions aren't required to make a good living..

-You do instead of talking about doing.

-You realize, in the very early stages, that the worst thing that could happen is you lose a few hundred or thousand dollars and learn something. What do you have to lose?

-When you get lucky or catch a break you're ready for it.

-You believe that success is the amount of your life you control.

-You love what you do. Or at the very least, love your situation.

-You avoid blanket statements like this: _All the millionaires were in porn in 2000_ and realize that not every "startup rule" or any rule applies. Businesses can be very different from each other.

-You understand that your odds of having an enjoyable job paying 200k are roughly the same as owning a profitable small business.

</comment><comment><USER4> Do what you love and the money will follow.

If the money doesn't follow, you'll still be doing what you love and that's worth more than money. People like being around people who are doing what they love.

But not a lot of people like being around people with a lot of money. Who cares about the money. I give most of mine away because my life is better without it.

If you have a lot of money, people wonder who you screwed to get it. There's a real bias against people with money in the world. They're greedy. They cause the collapse of the world economy. They force the people to enact laws that limit their own freedoms.

People who are motivated by money aren't that fun to be around.

People who want to succeed or accomplish something or make the world a better place or have a grand vision and work hard to implement it -- those are the people /I/ want to be around.

I know a lot of people with a lot of money and a lot of them are pretty boring. They hate their jobs. They complain a lot. They're actually kind of lazy to be honest. You don't have to work hard to make $70k a year and $70k a year is a /lot/ of money, don't scoff. There are people in many parts of America who don't know where their next meal is coming from. They could do a lot with $70k/yr.

Those motivated by new experiences and love of life. Those people are happy, because well.. they love their lives. They make people smile. They laugh. They make the world better.

One of my favorite VP superiors told me a story once, her mother-in-law was born without a dollar to her name and died without a dollar to her name and /still/ has a library named after her.

Do what you love. Forget the money, you'll have more of it than you'll know what to do with. If you love what you do, you won't have time to spend it anyway...

<comment><USER5> Laissez-faire capitalism is not capable of consistently rewarding people for doing what they love. It does not care about self-actualization.

The fact that you do care about that is refreshing.

<comment><USER6> s/Lassez-faire capitalism/Reality/.

No current economic system can sustain it on a large scale either, because reality itself is against it. Maybe someday, but we need still more productivity first.

<comment><USER7> I think the vast majority of our society would function just fine if ~10% of the populace worked a 40 hour week. EX: When you go to fill up your tank you don't need anyone inside that store, a few vending machines for snacks and drinks would work just fine.

As a thought experiment labor costs go up 10fold which jobs stop happening and which ones become more automated. You could dramatically reduce the distance the average trucker drives by using trains. Small farms suck from a labor standpoint. There is little reason a person needs to make the coffee at Starbucks. Romba style machines can clean vacuum. Bathrooms can be designed and built to be automatically cleaned. etc.

IMO, low skilled human labor is still cheep, but a change in the cost of human labor would soon see a huge shift.

<comment><USER6> I think you're wrong... by about twenty years, give or take quite a bit and highly variable depending on exactly what we're talking about.

We can't _quite_ have robotic truck drivers... but we're actually getting reasonably close. We can't _quite_ automate a gas station... but we are getting reasonably close. We can't _quite_ automate a fast-food joint (one of my personal favorite robotic bellwethers), but we're getting within sight of that possibility.

That's why I left open the possibility that this will change in the future. Right now society still requires us to all work, but we're getting within spitting distance of that not being true. Now, _that's_ going to be an economic disruption on par with the industrial revolution, and I'd say we're actually on the early part of that curve, because the first industries to feel this are the ones most easily Internet-able...

<comment><USER7> How did you go from _reduce the distance the average trucker drives by using trains_ to _We can't quite have robotic truck drivers_. A fairly limited 100MPH train network could dramatically reduce the distance and time it takes to deliver most shipments. Long hall trucking says more about our broken train system than how useful it is.

We have automated gas stations 95% of the time I show up pump my gas and go. There was a time when when a guy would pump your gas but that cost more so people where fine without that. As to Oil, and Tire pressure, my car senses them while I am driving. I don't even need directions due to GPS. Other than cleaning the bathrooms what do do we need someone in the gas station for? O yea, the station does not want to add cash machines to each of the pumps. (I suspect this is because when people are waiting to pay for their gas they are more likely to buy something else.)

IMO, we are already at the point in the US where most people's job's are redundant. But, as the need for people to do stuff drops off the cost of human labor also drops. The human greeter at Wallmart is a great example of this as their job could be done by a sign, OK they also cut down on shoplifters.

<comment><USER6> "How did you go from ... to ...?"

Some interpolation. Cutting humans out by 50% has a surprisingly small effect because we've got most of the low-hanging fruit there and you end up with other human costs getting in the way.

You've got to drop them to 0 to really matter.

"We have automated gas stations 95% of the time I show up pump my gas and go."

But there's a guy in the store, and it's going to take a _lot_ of work to get him/her out. The rest of the stuff you mentioned is low-hanging fruit long plucked, and getting the rest of the way there takes a lot of stuff.

"The human greeter at Wallmart is a great example of this as their job could be done by a sign, OK they also cut down on shoplifters."

Cutting down on shoplifting is their _primary_ job; greeters are secondary. Also, to the extent that greeters make people feel more at home and more likely to spend, that's something nothing but a human is going to accomplish.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> His mistake is not to distinguish between the average and the median case. Being an actor is an inefficient way to make money in both the average and median case. Starting a startup also doesn't pay in the median case, but it does a lot of better in the average case. In the average case it is probably the optimal way to make a lot of money. And if you are young enough to stand the risk, you can afford to care about the average case.

Startups and acting both have great variability, but acting also has demand working against it. Being an actor effectively pays you in other ways than money, because it's considered a cool thing to do. So demand pushes up the price in foregone income.

<comment><USER9> Last time I checked, startups were cool, too. Does that alter your argument?

<comment><USER8> Not cool like being an actor. Perhaps the reason startups seem cool to you is that you're thinking of famous consumer startups like Google or Facebook or Twitter. But the median startup does some boring infrastructure thing, like software for making online stores. You've never heard of the founders of these companies.

Even founders of consumer startups are way less cool per dollar than actors. I'd guess Larry & Sergey are about as famous to the general public as actors whose net worth is 1000x smaller.

<comment><USER10> I think I've heard of the guy who wrote that software-for-making-online-stores stuff. Its Paul somethingorother...

</comment></comment></comment></comment><comment><USER11> > _With a lot less effort, you can get a kickass job earning two hundred grand > a year._

This is exactly why you _can_ succeed. Instead of making someone else a lot of money and them giving you a $200k cut you can do their job as well and collect all the money generated by your effort.

Being the next Zuckerberg might be a lot like being the next Bruce Willis, but creating a small web software business with the ambition of making a few million over the course of years is not. And the big payout for most small businesses is when they sell to someone who already has money but wants a proven business (to add to their existing business usually).

<comment><USER12> _Being the next Zuckerberg might be a lot like being the next Bruce Willis_

I don't imagine having to worry about this any time soon, but if anyone described me as "the next Zuckerberg", I'd need three or four strong people on hand to restrain me from getting in a fight.

<comment><USER13> Ummm...can you elaborate on why you'd be willing to visit violence upon someone for merely comparing you to Zuckerberg?

<comment><USER12> I don't like Mark Zuckerberg much or find him remotely impressive, but it's not even the comparison so much as the diminutive connotations of "the next". If you're truly great, you're not "the next" anything. FDR was not "the next Lincoln", and Obama (whom I expect to be our generation's great president) is not the "next FDR" or "next Kennedy". I believe he has the potential for FDR stature and Kennedy charm, but he is and is going to grow into someone entirely new and singular.

<comment><USER9> [http://en.wikipedia.org/wiki/Criticism_of_Franklin_D._Roosev...](http://en.wikipedia.org/wiki/Criticism_of_Franklin_D._Roosevelt)

</comment></comment></comment></comment></comment><comment><USER14> So sick of hearing all of this.

If it fails, it fails, just go for it!

I hate pessimistic people.

<comment><USER15> ...but it wasn't pessimism, the post was addressing motivation.

One gains money as a side-effect of being successful at something in demand. You don't become successful by becoming a millionaire.

If becoming a millionaire is the goal of your software startup, you're facing some pretty big problems right off.

</comment></comment><comment><USER16> The times in my life when I have made the most money, has been when I set out to make money. So, thanks for the commentary, I think I'll take my chances.

</comment><comment><USER17>
      All the millionaires were in porn in 2000; all the people
      who started startups did it for a different reason.

Two things.

1\. The people who started startups wanted to make money just as badly, they just didn't want to tell mom that they were in the porn business.

2\. I'm really lucky I love porn.

<comment><USER18> He lost me on this blanket statement, too. First off it's simply not true (there were millionaires outside of porn) and he makes it sound as if starting a porn biz would be the surefire way to become rich.

I wonder how that's supposed to work because I'd imagine if there's one example for a "saturated market" then it would be porn? You're not only competing against a whole set of major players in each imaginable segment, you're also competing against bittorrent, porntube and the like. I somewhat doubt that one could get a foot down there without some _serious_ warchest.

</comment></comment><comment><USER19> It is a very well written commentary. In my view, each of us has a decision: quality vs. reward. You won't get to quality by constantly thinking about the reward.

I disagree that you can't get to the reward if that's all you want. Sales is all about the reward as is investment.

I agree on the article's main point: Entrepeneurship (as opposed to sales or investing) should be about the quality of the business. The employees, the customers, and the talented investors all know that the surest path to success is well-targeted quality.

</comment><comment><USER20> Yeah, the guy who started Salesforce.com just LOVES CRM software.

<comment><USER21> Maybe he loves helping others get their jobs done through software that doesn't suck?

</comment></comment><comment><USER22> Even if you _are_ a mercenary type, and you're motivated entirely by money, how can you do better than starting a startup? Getting a job making $200K/year is _hard_ ; most entry-level investment bankers are smart and work ninety hours a week, and they still fell short of $200K even before the crash. And $200K/year is still much less than you'd expect to get out of a successful startup.

</comment><comment><USER23> He doesn't define failure. It seems to mean any outcome other than making millions of dollars. I consider my startup a wild success if it just manages to break even while supporting a liveable income and giving me something useful and interesting to do with my life.

</comment><comment><USER24> That has to be the first time in history anyone has name dropped Edward James Olmos.

</comment><comment><USER25> I dunno, this article seems a bit too similar to smashLAB's article 3 weeks prior.

<http://www.ideasonideas.com/2009/01/startup_fail/>

</comment><comment><USER26> Your Starup will fail.

Don't give up, try it again.

One win is enough.

<comment><USER27> This reminds me of a rule about relationships.

Every (startup|relationship) you start ever will fail.

Until one doesn't.

<comment><USER26> True that. I actually just wanted to disagree with the author in Haiku form after tiring of the traditional long form way of explaining that in startups, you're supposed to try more than once, not fail and give up; but thanks for the reply anyway. :)

</comment></comment></comment><comment> cool-RR Statistically, the author of this article cheated on his wife.

<comment><USER28> Dammit! OK I was re-reading my post because I always check to see if I've written something I can stand by or not. And the answer is kinda, there are some problems with it, but anyway, I was doing that, this was right below it, I saw it. My self-control is not formidable. Having seen, I gotta respond.

So: I've never been married. And I think your statistics are wrong, especially if you only posted this here and not anywhere else.

</comment></comment><comment><USER29> I already disproved (have disproven?) this theory. Google "theory disproven money motivation" || see mark cuban

</comment><comment><USER12> _The startup world requires intensity and focus. With a lot less effort, you can get a kickass job earning two hundred grand a year. Your startup will fail because millions of dollars might be different from hundreds of thousands of dollars, but they just aren't different enough to justify that much effort._

I'm in a startup. Admittedly, I'm doing it, in part, for the material benefits... but I'm taking the long view, knowing that my short-term fortune is highly uncertain. I realize that I might never see a dime from this particular startup, but I figure that what I'm gaining from the experience, because I'm learning 5x more per unit time than I ever did in a corporate job, will benefit me in the long run. I might never be a millionaire, or even see the "kickass job earning two hundred grand a year" (although I've had average- ish jobs close to that) but I feel like I'll be employable in more interesting roles on account of the knowledge I'm gaining here.

</comment><comment><USER30> He's right in that if your motivation is to make a million bucks, you will give up very quickly, because the road there is too long.

If you are just some poor ass person who is tired of being poor, you will also fail.

The only crowd that will be successful are those who don't have any choice but to strike out on your own. If you really hate working for people, if everyone you know is doing business, etc, then your business is the only path.

All the people who just want to be rich will not be rich. Wanting to be rich is not a skill and it's not a talent.

</comment><comment><USER28> So I saw this is on here. I'm going to skip reading the comments because I know from experience that some of you are idiots and I'll end up swearing at you. I'll just save time. If you disagree with me, you need to either re-read the post or study chess.

Every time, that's all it ever comes down to. Every one of you who ever disagrees with me. You either don't understand how to use what I'm saying, or you don't understand what I'm saying itself in the first place. Sorry to skip it, but it's boring as hell.

Anyway, here's the one thing I wanted to add: PLENTY OF MOTHERFUCKING FISH. In 2000 the millionaires were in porn and the crazy fuckers who do shit that doesn't work were in startups. Some of you remember this. Others of you will have to just trust that we old-timers remember what happened and are not in fact hallucinating or making things up.

In 2009, it's not about porn. Today if you want to be a millionaire, you still don't get in a car and drive down Sandhell Road. But you don't hire a bunch of emo girls from Hawaii to take their clothes off, either. You study strategy constantly, you spend __less __than four hours working per week, and you put cash in the bank by the truckload.

Boom. You're done.

I haven't made it work for myself yet, but I had Warcraft characters who were living it. It's a great economics sandbox. Everybody thought my characters were twinks because they had crazy gold at low levels. No twinking, just a system. And of course Plenty Of Fish and Tim Ferriss have made it happen in __reality __in at least two cases. I think the millionaires are paying more attention to that than to VC.

I even see blog posts by monkey motherfuckers who say they believe that the four-hour work week works, but they want to spend more time than that working, because they're passionate about what they do. That's the stupidest goddamn thing anyone could say. The whole point of the four hour work week is it only takes four hours. Take four hours a week out of your busy schedule to do something that actually works, put the money in the bank, and get on with your day. That day, and that busy schedule, can include anything you want it to, including working your ass off on a startup.

OK, come to think of it, if you disagreed with me because of this reason - <USER2> you're that particular idiot - then you don't need to study strategy or re- read my post. You need to learn the fundamentals of logic. Discover the difference between necessary connections and incidental connections.

Come to think of it, I encounter that one all the time too, so if you're that particular idiot, sorry for missing your case in the above condescending blanket dismissal. Here's a special condescending blanket dismissal of your very own: go study logic, you idiot.

And fallentimes, it was hard to skip your post because it was at the top of the page. You would have made it a lot easier to respond to if you had numbered your reasons. However, your reasons mostly aren't worth responding to. They don't represent a cogent response to my specific argument; you're mostly just sticking your fingers in your ears and going "lalalala I'm not listening." Your response is a filibuster.

You do have a few specific responses, however, so I'll answer them.

"You understand that your odds of having an enjoyable job paying 200k are roughly the same as owning a profitable small business."

I'm fairly certain that's factually inaccurate, but I can't prove it, and I'm not going to stick around for your answer, so I'll let it go. What I can nail you on is that this is a comparison on uneven criteria: for 200K to win, you have to enjoy it; for a small business to win, it has to turn a profit. Technically a prostitute has a profitable small business, so in this uneven comparison, a prostitute pulls ahead of anyone making 200K, even if they do enjoy it, since you say their chances are equal. You need to set up even comparisons to be fair. I think we can throw out this part of your filibuster, or at least require you to come back with an even comparison.

"You know IPOs or acquisitions aren't required to make a good living.."

and

"You avoid blanket statements like this: _All the millionaires were in porn in 2000_ and realize that not every "startup rule" or any rule applies. Businesses can be very different from each other."

I think it's obvious I'm only talking about VC-funded startups here. You appear to be suggesting that the way your startup can succeed is by being a different type of startup than the type of startup I'm talking about. That's not refuting my argument. That's merely changing the subject. I apologize for not making it clear that we were only discussing VC-funded startups. However, since this was an answer to a specific person, and a continuation of a specific conversation, let me tell you, as it happens, that's what the conversation was about.

The blanket statement thing is a legitimate dis. You've got me there. But rephrase it: the majority of millionaires were in porn. The core of my argument remains unchallenged. There were people doing a simple thing that worked. If your goal is to be a millionaire, it makes a lot more sense to do something that many millionaires do, which often works, than to do something that few millionaires do, which often fails.

That's why I made the analogy with acting. If you're going to work very hard and the odds are against you, you need to have something which fuels that, and if the only thing that fuels it is a desire for money, that won't be enough to take you to the finish line. Actors come and go in Los Angeles all the time because they think it's going to be easy. I don't get close enough to startups to say this with the confidence of fact, but my intuition is that this is very true of startup founders as well. You need to believe in the technology, or the way you'll change the world, or the corporate culture even. If you set out to become a millionaire using a strategy that very infrequently makes anyone a millionaire, you're going to give up the minute your common sense kicks in.

"You don't care about material possessions."

Again, you're changing the subject. This is a response to a guy who was interested in VC because he wanted to become a millionaire. Obviously, if you're putting forward that somebody who cares about something more than the money might have a better chance, well yeah, that's my point.

Sorry everybody else if there was some devastating, incisive refutation somewhere else on this page. I just don't have the patience, the even-handed temper, or the time.

<comment><USER31> > I apologize for not making it clear that we were only discussing VC-funded > startups.

Ah... now your post makes sense!</comment></comment>


Duolingo Launches Its Certification Program To Take On TOEFL - <AUTHOR> http://techcrunch.com/2014/07/23/duolingo-launches-its-language-certification-program/

<comment><USER2> This is great news, definitely an area which should get disrupted.

Just tried taking the test (it's Chrome only on desktop, Android only on mobile, at the moment).

It will ask for permissions to access your webcam and microphone, ask for ID and finally, to share your screen. This way the can guarantee (?) that you don't cheat. Unfortunately, at the end it couldn't upload my test data and just said "You have to take the test again at another time"

Looking forward for more institutions to join the club!</comment>


Android 0-day vulnerability – Drive by download - <AUTHOR> http://seclists.org/fulldisclosure/2015/Apr/77

<comment><USER2> No, this is nothing new. The user is in fact manually downloading the app and accepting the permissions. The app then maliciously connects to a server and runs commands without the user knowing. However we already knew that this was possible in Android. It's not a 'zero day vulnerability' or a 'drive by download' at all. Just another example of why you need to be careful what you download on Android.

<comment><USER3> No, that's not true. Look at the video starting 35 seconds in. The user touching the "Confirmer" button is actually pressing the "Accept" button on the "App Permissions" dialog. But the user doesn't know that, because another window has been overlaid on top of the App Permissions dialog.

<comment><USER2> Ok, thanks. That wasn't entirely clear from google's French translation.

However you still have to download the dodgy app in the first place. There's a lot of bad stuff that apps can do if you give them permission. This is just a case of a bad app downloading another bad app (perhaps with slightly more permissions).

In the grand scheme of things it doesn't really make much difference -- all apps now request a whole bunch of permissions that most people don't really even care which permissions are being asked for. You really just need to trust the app that you're downloading.

</comment></comment></comment><comment><USER3> My reading of the vulnerability is that you have some app with few permissions, that then triggers installing an app with many permissions. The user is presented with a confirmation dialog for this installation. However, the low-permission app can overlay a window on top of this dialog, showing any content it likes, and this window can be configured to pass touch events through. So the user thinks he is interacting with this overlay window but is in reality confirming the installation of the new app.</comment>


After 400 years, mathematicians find a new class of solid shapes - <AUTHOR> https://theconversation.com/after-400-years-mathematicians-find-a-new-class-of-solid-shapes-23217 <comment><USER2> Quoting one comment from a previous discussion:

        It actually looks more like a redefinition
        than a new discovery: "It may be confusing
        because Goldberg called them polyhedra, a
        perfectly sensible name to a graph theorist,
        but to a geometer, polyhedra require planar
        faces "

\-- [https://news.ycombinator.com/item?id=7252187](https://news.ycombinator.com/item?id=7252187)

Previous submissions:

[https://news.ycombinator.com/item?id=7349581](https://news.ycombinator.com/item?id=7349581)

[https://news.ycombinator.com/item?id=7267909](https://news.ycombinator.com/item?id=7267909)

[https://news.ycombinator.com/item?id=7259409](https://news.ycombinator.com/item?id=7259409)

[https://news.ycombinator.com/item?id=7251805](https://news.ycombinator.com/item?id=7251805)

[https://news.ycombinator.com/item?id=7244254](https://news.ycombinator.com/item?id=7244254)</comment>


Microservice Trade-Offs - <AUTHOR> http://martinfowler.com/articles/microservice-trade-offs.html <comment><USER2> While microservices are certainly the buzzwordy trend of the month, developers really need to take a step back and ask if designing or refactoring a project into microservices is really helpful. I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!" Now they're stuck maintaining five apps, five APIs, etc. and have yet to actually benefit from the split. My rule of thumb is: can I see parts of this project being used in another project? If the answer is yes, it gets considered. If no, it stays the working app that it is.

<comment><USER3> IMO, microservices are successful when the issue is scaling people (you can split into loosely coupled teams, one per service), or scaling data (different read / write patterns allow different data stores). I don't consider reuse as a criteria, unless as a project you mean a new feature within the existing app. It's not like Spotify, for example, is starting many new projects but they will benefit from the above.

<comment><USER4> Yes. A friend is at a company that went from a monolith to a microservices approach. (The service-to-engineer ratio is something like 1:2.) He says it's radically better because somebody after a new feature can mainly just compose existing services. But they had hundreds of employees before they made the switch.

Personally, I would start sooner than that. I think new technologies make service creation easier. But the right moment for me depends a lot on product, team, and tech.

<comment><USER5> Most of the 'problems' with microservices are in the operations phase, not typically in the development phase.

<comment><USER4> Do serious shops have phases for these things anymore? In my view a modern shop should be developing and releasing frequently, and that engineers should experience operational consequences of development choices.

So I guess I would say that any place not working like that might not be ready for a microservices approach.

</comment></comment></comment></comment></comment><comment><USER6> I contend that a lot of the issues related to microservices growing so popular is that we are missing boundaries in our applications. Instead of creating stronger boundaries between modules (or having well defined modules at all), we create physical boundaries between applications and computers to force a protocol based system.

I gave a talk about MWRC 2015 about this: [http://brianknapp.me/message- oriented-programming/](http://brianknapp.me/message-oriented-programming/)

<comment><USER7> You hit the nail on the head. Without discipline module boundaries aren't enforced as developers reach into internal APIs between modules to meet deadlines. The result is a complex web of dependencies that are difficult to understand and maintain.

Micro services are simply a physical boundary to enforce discipline between logical modules.

It is a solution to a symptom rather than solving the root causes.

<comment><USER8> But is treating the symptom rather than the root cause always a bad thing?

Alcoholics don't keep booze in the house either. That's treating a symptom, not a cause, but it's effective. And yes, I did compare programmers violating interface boundaries to alcoholics.

<comment><USER7> Good point and I do agree to an extent. However, without discipline we are simply moving the risk. Eg. We can't enforce interface boundaries in our system vs. we have a micro service architecture with N systems that we need to deploy as a monolith because we don't have the discipline to ensure backwards compatibility between systems.

Yes. My current enterprise client takes a week to deploy their micro service arch. Because all systems need to be deployed at once.

So, they simply traded one complexity for another without fixing the root problem--a disciplined development methodology.

<comment><USER8> Yeah, I think there's a problem with the definition of microservices in theory vs in practice. In theory, the boundary of a microservice is the api, right? In practice, the boundary is the set of things you must change in order to update one part. If you have to DEPLOY ALL THE THINGS!!!! in order to update a single component, _it 's not a microservices architecture_. Not in practice, anyway. It's a monolith with a bunch of different moving parts.

</comment></comment></comment></comment></comment><comment><USER9> Reading this makes me feel a little like I woke up in 1990.

>> Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.

This is a true statement, but it's hardly the point on which current architecture choices turn. Distributed systems are the norm now. Almost everyone is working on one, even if they don't think of it that way (and I bet they don't). There are still simple, single-process programs that are relevant to users and the people working on them, but those aren't the domains in which this microservices debate is supposed to be taking place.

Is it relevant to evaluate "microservices" vs. a "monolithic architecture" based on the costs of traversing the network stack? Back when we were thinking about breaking up our C and C++ programs into processes using RPC as glue this was something we worried a lot about, but that is because in many cases having everything in a single process was still a credible alternative. Few people are wrestling with this choice today.

The last site I worked on consisted of nginx, elasticsearch, logstash, kibana, postgresql, celery, redis, and a bunch of custom python, java, and javascript code. It could run on one server or (as it did in production) twelve. Almost all of those pieces ran in separate processes, communicated over the network using mostly standard protocols, and did one specific thing. Were these microservices?

I feel like microservices as a thing is one of the least meaningful tech fads I have seen. Minimality and cohesiveness aren't surprising new challenges. They were desirable concepts of C++ class libraries two decades ago. An implementation of a service should always be both minimal and cohesive, and it should be complete. It should be as small as possible. Whether that is "micro" or not is entirely too subjective for me.

The other trade-offs mentioned, consistency and complexity, are not much more relevant to the big question the author is trying to convince us to ask. Consistency is a property of a view of state, but the article is about distributing code (otherwise why care about module boundaries and deployment?), not distributing state. Complexity is always a a key trade-off, but the complexity of distributed code is table stakes in the world we actually work in.

<comment><USER10> Plust there's a HUGE flaw in:

> since remote calls are slow and are always at risk of failure.

Talking to e.g. MySQL is a remote call too, that can fail just as easily.

<comment><USER11> Yes, and sometimes an in-process database makes sense to avoid those calls too. I don't see the flaw.

<comment><USER10> My point was that most people don't consider the fact that calling MySQL or the same is a remote call and is just as likely to fail. Of course there are ways to avoid that, but most people don't think in those terms.

</comment></comment></comment></comment><comment><USER12> With a small team, we've refactored more than 150k LOC from being a single app into a lot of small services and we're not looking back.

To avoid increasing complexity in managing all these APIs we have added KONG [1] on top, so we can keep higher consistency and orchestrate common functionalities among multiple services. In some ways it's funny, because KONG "centralizes" a decentralized architecture but we needed one home base to always refer to or rely on,when most of the system started to live on the edges.

In space explorations you always have a mothership after all.

[1] [https://github.com/mashape/kong](https://github.com/mashape/kong)

</comment><comment><USER13> Well, dividing your problem into microservices is a lot more likely to work than another approach to change being pitched today - patching running programs on the fly. If you're considering that, something is horribly wrong with the system architecture.

As for "microservices", part of the problem is that the UNIX/Linux world has historically sucked at interprocess communication. Everything looks like a pipe, and you have to build something that works like a subroutine call on top of it. (Yes, there's System V IPC, which nobody uses.) The mismatch there results in much overhead associated with framing and such. Also, because the IPC and scheduler aren't integrated, each interprocess call tends to put either the sender or receiver at the end of the line for CPU time. This can add huge latency to service calls.

I've written hard real time code for robotics on QNX, which has a good MsgSend/MsgReceive system for calling other programs. Message passing and That works out quite well, especially when some programs run at higher priorities than others and have hard time constraints. QNX doesn't have a really good system for starting up a set of programs and getting them communicating, though; I had to write something for that.

One lesson from QNX is that marshalling and interprocess communication should be separated if performance matters. IPC done right is fast, and marshaling done with code generated for each message format is fast. Generalized interpretive schemes like CORBA and JSON-based systems have much higher overhead than a subroutine call.

Another lesson is that better tools for managing groups of programs are necessary. It's a hard problem. Look at the "initd" mess. That's just a special case of managing a group of microservices. Just getting everybody connected up securely at startup is hard.

<comment><USER11> _As for "microservices", part of the problem is that the UNIX/Linux world has historically sucked at interprocess communication. Everything looks like a pipe, and you have to build something that works like a subroutine call on top of it. (Yes, there's System V IPC, which nobody uses.)_

What about Datagram UNIX sockets using sendmsg/recvmsg? I've implemented a simple RPC using them and it seemed fine.

</comment></comment><comment><USER14> Correct but a bit boring.

In the Java world there is the idea that you make interfaces for services and then a dependency injection systems decides which ones to create at runtime.

Many useful microservices can be implemented with a key-value store, and this could be implemented with anything from an in-memory Hashtable or something that uses the disk or off-heap memory or runs in a huge distributed cluster.

In that case you get to use in-process when it is expedient (like literally, you cut power and latency if you don't waste time turning floating points numbers into strings and whatnot.) When out-of-process makes sense you are ready.

To accompany this you need frameworks and tools that eliminate a lot of overhead, for instance, to automatically generate the stub code for service calls, manage a large number of servers, etc.

<comment><USER15> > In the Java world...

We do the same thing in Go, C#, ...

[https://en.wikipedia.org/wiki/Interface- based_programming](https://en.wikipedia.org/wiki/Interface-based_programming)

</comment></comment><comment><USER16> It's hard to correlate the points made in this post with eventual consistency. Microservice or any service's runtime distribution and deployment model has impacts on consistency but that doesn't imply that systems will automatically become eventually consistent. Nothing prevents service instance clustering and co-location on the same hardware machine in different runtime units like containers or vm's talking to a db running on a single machine. It's a function of the scale and maturity of the system. Consistency itself is a function of state management within a system and more importantly, a non- trivial system typically has quite a few data stores and access patterns with their respective consistency requirements. Saying that running microservices implies eventual consistency is painting with very broad brush strokes.

</comment><comment><USER17> Why we don't build "micro monolithics" ?

Why microservice I am very specialized, and every service should do just one thing well, think about send an email, load the ads or load the comments.

Why we don't build a very shallow service, that does everything for just a very small part of the website ?

In a classic website a micro monolithics (mm) could be something like "/login" or "/post-picture".

The mm will not call any other service but it will be able to do every action by itself.

Simply deploy a (or more) new service for every (busy) end point of your application.

In this way we can share, or isolate, our codebase.

It would be easy to deploy, basically you are simply using a whole server to run one single function at very high frequency.

It can bring a lot of chance for optimization.

Just thinking...

<comment><USER18> I don't know if this was researched by system theorist. A spectrum of scale from micro to mono. When micro communication costs are too high, integrate, rinse, repeat.

Makes me think of [https://news.ycombinator.com/item?id=9777567](https://news.ycombinator.com/item?id=9777567)

</comment></comment><comment><USER19> > Many organizations will find the difficulty of handling such a swarm of > rapidly changing tools to be prohibitive.

I've been working at Giant Swarm[1] for the last few months as the evangelist. Our original intent was to focus on providing a PaaS-like containerized stack in a multi-tenant/public cloud offering; something that felt a bit like Heroku, but less restrictive stack-wise. We're now engaging in a few professional services deals, given the high demand for an easy-to-deploy/easy- to-run container system.

I think the high demand we are seeing in the ecosystem is coming from organizations/individuals who want to understand how to use and deploy containerized stacks. I see the primary problems being people are unable to keep up with the innovation in the space (drinking from a firehose) and are unable to find the properly skilled labor force to implement a solution (training/expereience lagging behind demand). That observation would directly relate to Martin's comments on operational complexity.

I will note I observed a similar phenomenon with OpenStack, so my observations are certainly not an indicator that people will be _using_ these deployments initially. It will likely take some time before microservice-based develplment is a common pattern in larger organizations. At the very least, they know they need to be thinking about it...

[1] [https://giantswarm.io](https://giantswarm.io)

</comment><comment><USER20> One benefit of a microservices/SOA architecture that I never see mentioned is that it can make you a more attractive acquisition target (if your acquirer is doing decent technical due diligence.) There's a good chance that your acquirer (a) just wants a specific part of your stack, not the whole monolithic codebase with things they don't care about, and (b) they want to integrate it into their existing systems, which are very likely written in a different language.

</comment><comment><USER21> > Operational Complexity: You need a mature operations team to manage lots of > services, which are being redeployed regularly. IMO you need first and > foremost a mature development team that releases operable, diagnosable and > fixable (micro)services. Managing a swarm of mini component is a lot easier > when each part is manageable to being with.

<comment><USER22> > Operational Complexity: Tooling is still immature, but my instinct tells me > that even with better tooling, the low bar for skill is higher in a > microservice environment.

Seems like most of the tooling now focuses on automating small parts of dev and ops teams' workflows, instead of looking at the larger picture of organizational tooling. I would guess that in a few years we'll see a lot more PaaS-workflow solutions focused on abstracting away a lot of the operational complexity of microservice architectures, reducing the barrier to entry for "maturity" of dev/ops teams, just like AWS & co reduced the need for people to really understand server hardware.

</comment></comment><comment><USER23> I like the approach of building a monolith (with smaller libraries), and then split it once you need to. The argument is that you're likely to choose the wrong services to seperate until after you've built a bunch of the system.

<comment><USER7> I never worked with a client that built libraries (eg. Jars or dlls, etc). The reason was because it was hard and took effort. So we ended up with monolith applications.

Fast forward to today we have essentially jars and Dlls with the added overhead of an entire system and deployment to maintain.

Boy have we gotten things wrong in this industry.

</comment></comment><comment><USER24> I'm surprised we haven't seen any attempts at frameworks that try and solve this: something that allows you to start with a monolithic app, but is designed to split off bits and pieces into stand alone microservices.

Or maybe this exists and hasn't got a lot of press. Or it has been tried and failed.

</comment><comment><USER25> If you use frameworks where components communicate by exchanging messages then it's quite easy to start with a single app and later scale it to multiple services. With frameworks like Akka (Actors) or Vert.x the communication can be local or remote and the calling code is the same for both.

<comment><USER26> In rails you can do similar approaches (prepare for later scaling) by encapsulating the actual fetching logic in Repository objects

</comment></comment><comment><USER27> I think Elixir/Erlang is a good tradeoff on both, would you guys agree?

[http://blog.plataformatec.com.br/2015/06/elixir-in-times- of-...](http://blog.plataformatec.com.br/2015/06/elixir-in-times-of- microservices/)

</comment><comment><USER28> Despite having an MBA, I do, on occasion, find myself involved in a discussion about architecture.

My rule of thumb when deciding whether to deliver a piece of functionality as a service is "Will another application/system/whatever ever want to be able to use this functionality?"

If the answer is yes, that would be a fairly compelling argument for implementing it as a service. If the answer is no, then the question becomes "Why _not_ implement it monolithically?"

</comment><comment><USER29> First he fuels the hype. The he backpedals. A master of self-promotion.

<comment><USER30> As a person who has done this accidentally, I can offer an alternate opinion.

First, you learn about a cool new thing, understand it and it's limitations well, and advocate it as an improvement: [https://www.chrisstucchio.com/blog/2012/bandit_algorithms_vs...](https://www.chrisstucchio.com/blog/2012/bandit_algorithms_vs_ab.html)

Sometime later, you realize that people are using it well beyond it's domain of usefulness and "backpedal", i.e. try to make sure the limitations are also well known: [https://www.chrisstucchio.com/blog/2015/dont_use_bandits.htm...](https://www.chrisstucchio.com/blog/2015/dont_use_bandits.html)

</comment></comment><comment><USER31> Why is there a consistent drive in the industry to invent new buzzwords and apply untested, complicated ways of working?

The compromise you have to make to have a micro service architecture doesn't make sense for anyone else other than Google or Amazon or extremely large organizations.

Even with such architecture in place, you are going to end up with far more overhead by using microservices, it _simply_ isn't the case that by isolating individual components into functions, you suddenly get productivity.

It just infuriates me when engineers or product managers bored with their job constantly invent buzzwords to confuse, increase complexity, end up failing, and back to just regular old boring tech.

If it ain't broke don't fix it. Why the fuck would you want to now have 100 different API end points to do something that would've taken less than 50 or so lines of code? This doesn't make sense for 99% of software companies out there.

<comment><USER32> The majority of software companies (by employment) are enterprises that have thousands of legacy endpoints in different protocols like SOAP, MQ, or CORBA, deployed in various monolithic shapes.

They damn well will get a lot of benefits from microservices for their newer capabilities... IF they also work on the operational aspects (continuous delivery, a devops culture, and some kind of automated operating platform).

No one sane is publically advocating building microservices for a single team small app.</comment></comment>


What Is Google Vault? - <AUTHOR> https://support.google.com/vault/answer/2462365?hl=en <comment><USER2> I think it's a good addition to g suite, since you can also export the data from a vault rather easily.</comment>


Complete list of airbnb like startups in sharing economy - <AUTHOR> http://www.guotime.com/2012/04/complete-list-airbnb-startups-sharing-economy/ <comment><AUTHOR> added a whole lot more</comment>


Ask HN: what hacker news app do you use on iOS? - <AUTHOR>

<comment><USER2> news:yc is by far the best.

Because of its simplicity, I use it much more than I use the actual HN website.

I've even emailed chpwn (Grant Paul) the creator of the app with ideas for making it better and he was very quick to respond and sincerely consider my suggestions. In the end he chose not to use them, as he feared the UI implementation would not be intuitive.

<http://newsyc.me/>

<comment><USER3> I just installed it, but I'm having trouble finding out how to collapse comment threads; is this feature available, and if so, how ?

<comment><USER2> Thats the feature I suggested, but he rejected. :P How would you implement it?

I suggested swiping horizontally on a comment would collapse the children.

<comment><USER3> I have no idea what would trigger the collapse, but it's extremely annoying to browse this way. Especially on submissions with a lot of comments, you have to go through a huge list of worthless comments to find the next "good comment".

Either a thread collapse or a "skip to next comment on the same indentation level as this" would solve that problem.

<comment><USER3> I just had contact with the author, he seems to be willing to acknowledge the issue, but unwilling to implement a fix. So that's a shame, made me waste some money.

</comment></comment></comment></comment></comment><comment><USER4> I highly recommend <http://cheeaun.github.com/hackerweb/>

</comment><comment><USER5> HackerNode. Unfortunately it's a read-only app, but it works really well for me :)

</comment><comment><USER6> I just use Chrome on my iPad 4, I feel I'm getting the same experience as on the desktop and that's fine for me.

</comment><comment><USER7> I'm curious as to why people don't use the browser.

<comment><USER3> The official site doesn't work well on mobile browsers. There are sites such as ihackernews.com and icombinator.net that fill that gap.</comment></comment>