How Accurate Are These Smartphone Sound Measurement Apps? - <AUTHOR> http://blogs.cdc.gov/niosh-science-blog/2014/04/09/sound-apps/

<comment><USER2> That's better than I would have thought, and in some cases on par with very low cost (sub-$50) dedicated SPL meters.

I have a side business that does audiovisual services, and I've been meaning to get the other folks in the crew to test their phone with one of these apps against my SPL meter (which is a ~$80 unit that I believe is pretty accurate in most circumstances), so they'd have a ballpark idea of how loud they're running the gear (there are noise ordinances that we sometimes have to take responsibility for following).

I'd be curious how well a phone could act as an RTA, as well. I used to use my Amiga to do analysis (non-realtime, but reasonably useful in a time when having a high resolution spectrum analyzer was amazing), and standard PCs have been able to act as RTAs for at least 15 years, so I'm absolutely certain the processing power needed is there in modern phones and tablets, but the mic and audio interface would be a limiting factor.

<comment><USER3> Maybe you could get an idea of the accuracy by e.g. feeding white noise to the phone and seeing how flat the spectrum is? And though I've never used them personally, I hear there are some pretty good clip-on microphones for smartphones on the market.

</comment></comment><comment><USER4> AS a former Sound Engineer and Studio owner I am blown away at what a phone can do now a days. It really is asy to have someone down load an app and talk them through live sound and EQ with the visual (accurate or not) to show what happens with sound when they play with cheap EQ (AKA cheap EQ is always for REDUCTION and never amplification)

I think if I was doing any sound work anymore I would quickly pick up an external mic and just always use pink noise and the meter to rough in a system.

<comment><USER5> out of curiosity, what app(s) do you have them download?

<comment><USER4> I don't have an answer, sorry.

</comment></comment></comment><comment><USER6> I've been using SPLnFFT for a while now, with consistent results and I'm happy to see a formal evaluation.

The problem that remains is that there are differences in microphones between iOS devices. SPLnFFT author should probably calibrate the app on every device that is out there on the market. I'm not sure if that's at all feasible.

</comment><comment><USER7> They're now running a similar study with external mics (MicW i436)

[https://twitter.com/NIOSHNoise/status/522456711882629120](https://twitter.com/NIOSHNoise/status/522456711882629120)

I expect apps would be even more accurate with external mics

</comment><comment><USER8> It's not surprising that a device around a mobile device can produce decent results. The Bruel and Kjaer 2250 [0] and 2270 sound meters (probably considered to be the highest-end sound meter on the market) is built around Windows CE.

That said, the JASA paper give this very huge caveat near the end: _Furthermore, this study examined these apps in a controlled noise environment. Field measurement results may vary greatly due to the effect of temperature, humidity, long-term use, object interference, and overall stability of the microphone and electronics in these devices._

Furthermore, they tested the devices with relatively high SPL signals (65 to 95 dB), the only tested overall noise levels (no frequency response testing) and in a reverberant field so these results may not be applicable to many other situations (temperature extremes, lower sound levels, etc)

The week point of using a smartphone as a sound meter is going to be the microphone. If you can pair the smartphone with a precision microphone (using something like Studio Six Digitals iAudiointerface [1] for example) you can have the equivalent of a IEC Class 1/ANSI Type 1 microphone (I and colleagues have used this setup for sound measurement projects involving litigation). But if you're depending on the device's internal microphone, be very careful at how you apply those results, especially given the vacates listed in the paper.

That said a smartphone sound meter apps will get you in the right ball park, and as alluded to by SwellJoe they can be at least as accurate (if not more accurate) than some of the $50-$100 Type 2 meters on the market. Just don't rush to any conclusions based solely on data obtained from those setups.

[0] [http://www.bksv.com/Products/handheld-instruments/sound- leve...](http://www.bksv.com/Products/handheld-instruments/sound-level- meters/sound-level-meters/type-2250.aspx)

[1] [http://www.studiosixdigital.com/audio- hardware/iaudiointerfa...](http://www.studiosixdigital.com/audio- hardware/iaudiointerface2/)

</comment><comment><USER9> From a comment at the link:

"NIOSH does not recommend nor endorse a particular commercial product. The data from our study "Evaluation of smartphone sound measurement applications" is available in the journal article referenced at [http://scitation.aip.org/content/asa/journal/jasa/135/4/10.1...](http://scitation.aip.org/content/asa/journal/jasa/135/4/10.1121/1.4865269) . The discussion section (page 189) highlights two apps — SoundMeter and SPLnFFT — that had the best accuracy over our testing range. There were two other apps — Noise Hunter and NoiSee — that were within ± 2dB of the reference sound source. Once again, note that the data results in the study do not constitute as NIOSH endorsement of any of these products."

</comment><comment><USER10> I'd like to have seen a few tests with Windows Phone (somebody must care about us!). My Lumia Icon has 4 "high def" microphones with great claims of accuracy and background noise reduction from Nokia. In my experience they've worked well but I don't have an SPL to compare it against.

</comment><comment><USER11> Pity it only mentions iOS apps and not the ones I use on Android. I use two apps and they read radically different values (unless I am reading them wrong - that might be the case).

<comment><USER12> Read their paper ( [http://scitation.aip.org/content/asa/journal/jasa/135/4/10.1...](http://scitation.aip.org/content/asa/journal/jasa/135/4/10.1121/1.4865269) ) , it's free to read the PDF.

The hardware is at least as important as the software (I'm amazed to see so much scatter between apps), so the homogeneity of the iOS ecosystem is a boon to this sort of measurement. Figure three in their paper shows that the Apple hardware is quite consistent across all models tested.

They did test Android phones and apps; the final paragraph from their results section makes a general statement:

 _A similar examination of Android apps and devices was not performed because of the low number of apps with similar functionality, and the lack of conformity of fea- tures between devices. Testing conducted with the four Android smartphones also revealed a high variance in measurements of similar apps between different devices._

<comment><USER11> Apologies - I did go and take a look at the paper but examined the graphs and scanned the last paragraph but saw iOS everywhere; a more concentrated reading would have stopped me making a fool of myself.

Thanks for pointing the paragraphs out.</comment></comment></comment>


Standup Timer Android App - <AUTHOR> http://johnpwood.net/2009/12/04/my-first-android-app-standup-timer/ <comment><AUTHOR> We've been using this for a few weeks now and it's been really helpful</comment>


What the iPhone Teaches Us About Happiness - <AUTHOR> http://trueslant.com/ryansager/2009/06/18/what-the-iphone-teaches-us-about-happiness/

<comment><USER2> Yes, experiences trump possessions, but...

I almost think the iPhone might be an exception to this generality. I saw a t-shirt on Threadless recently that said "My iPhone has totally changed the way I poop." Or, as I often have said, having an iPhone means never having to be bored. Whenever I'm in line, waiting at the Dr. Office, etc... I have something interesting to read at the tips of my fingers, or a game, music, or whatever.

So perhaps the iPhone takes the edge off of what otherwise might be dull/unpleasant experiences to such an extent that its overall impact on happiness is quite high. I, for one, am still hugely attached to my original 2G and feel lost without it.

<comment><USER3> I lost my 1st gen iPhone a few weeks ago. Waiting for the 3GS has been quite an agony - I didn't realize I use it so much in my daily activities. To me the iPhone is an interface to the collective wisdom of the internet that is always with me. I feel stupider without it.

To many people the iPhone is just a fashion item. The number one reason I have heard from my friends for not wanting one is that it is so common: everybody has one. Well, obviously some of us don't care about this... what surprised me with the 3GS is that Apple apparently doesn't care too. They didn't change the appearance of the phone at all, even though that would be an easy and cheap way to get the more fashion-oriented users to upgrade. Does anyone has an explanation for this?

</comment></comment><comment><USER4> Interesting to see the attachment to the physical object:

 _I love my iPhone. I'd lay down my life for it. If it fell onto the subway tracks, I'd jump in and grab it — ignoring the posted signs and tempting fate to strike me down for my worship of a material good. A bright, shiny, covetable material good._

The iPhone isn't a singular object however, it's an instance of a dataset. The iPhone gets backed up every time you sync. Drop it on the subway tracks and it's no trouble. Plug in a new iPhone and restore from backup and you wouldn't know the difference. Same data. Same icons. Same phone number.

Watching the upgrades to the iPhone 3GS is going to be interesting. It looks the exact same. The software is essentially the same 3.0 on your old iPhone. Will people feel ripped off? Will they place less value on the upgrade?

<comment><USER5> I think that's why Apple reserved Voice Control for 3GS. There's no legitimate technical reason for it not being on the iPhone 3G.

<comment><USER6> I recall someone (possibly John Gruber) saying that there's a dedicated DSP chip in the 3G S, which would explain why Voice Control is only in that model.

</comment></comment></comment><comment><USER7> The phenomenon that people tend to adapt to their material circumstances is generally referred to as "the hedonic treadmill."

<http://en.wikipedia.org/wiki/Hedonic_treadmill></comment>


Zillow CEO Overpaid for His Los Angeles Home, According to Zillow - <AUTHOR> http://la.curbed.com/2016/7/11/12157338/zillow-ceo-brentwood-home-zestimate-overpaid <comment><USER2> Is it really fair to judge their algorithm on "one of the most expensive sales of 2016"? Only a tiny, tiny portion of the half million houses sold in the US each year would be even approaching the 20 million USD mark. His service isn't intended to service the mega rich.

<comment><USER3> It is intended to depress the net worth of middle class homeowners.

<comment><USER2> Never assume malice when a shitty model will suffice.

<comment><USER4> Sufficiently advanced shittiness is indistinguishable from malice.

</comment></comment></comment></comment><comment><USER5> The model was off by 5%.

Sounds like a pretty good estimate to me, particularly considering the paucity of back data for this kind of inventory.

<comment><USER6> Those kind of ultra lux purchases are closer to the art markets than to the commodity housing ones. So - it is actually pretty good.

</comment></comment><comment><USER7> I live in the Midwest and our home prices are relatively flat over the last decade for the city I live in. 18 months ago I noticed that my zestimate was inflated and rose to 2x my appraised value of my home (refinanced that year). I looked into it and noticed that Zillow was doubling the sales price of recent homes. This was the main issue. I reported it to Zillow and some in customer service said their engineers would look into it. Only in the last few months have th Zestimates come back to reality.

I bring this up because I was curious as to how this would play out for my city and home prices. Would this increase prices for the area or would realitors ignore the data and go with what they knew would make sense.

I haven't seen a huge increase in prices nor have a done any study of it. But just the idea that a bug could cause such a calamity for a least the size of a city was eye opening.

<comment><USER8> I have a friend who is a realtor and we talk about this subject occasionally. My understanding is that most realtors will recommend using Zillow to "get a feel" for the market. But Zillow's estimates are only as good as the data that goes into them. Usually, data for an area is publicly available and up-to- date, but sometimes it's very old or just plain wrong.

I think Zillow claims their estimates to be within 10% of actual sale price. To me, that figure seem to be pretty good from a data analysis stand point; but 10% of the value of a house is a lot of money for even a modest home.

Most realtors used closed databases, like MLS, to document sales and compare area housing prices. I believe MLS data is typically manually entered and verified (I'm not 100% sure about this though). I believe there is also a lot of extra metadata added to MLS listings that Zillow can't get from public records. Realtors also tend to look at property tax assessments for their areas in order to gauge market trends (just like Zillow does, except without a hidden algorithm).

</comment></comment><comment><USER9> It's not surprising that Zillow's AVM [1] isn't accurate for this sale. The model needs local comparable sales data to function properly which it didn't have in this case; it's not everyday that mansions are bought and sold. The next best thing it can do is look at the last recorded sale (or tax assessor's indication of value) and project out by looking at market trends and applying some other proprietary mumbo-jumbo to come up with a price.

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

</comment><comment><USER10> I didn't realize people actually cared about zillow zestimates. I'm not trying to be mean, I love Zillow as someone too introverted to go to open houses but still curious what the inside of homes look like around me.

I live in a city (stl) where less than one mile north are houses <30k and less than a mile west re >1m and one block east are 150-200 and one block west are 500k.

Whenever houses sell around me my zestimate goes nuts but we have a smaller house in the middle of 100+ year old 4k square foot homes. They sell for either MUCH higher prices (someone kept it up) or much less (they didn't) causing our estimate as a unrelated newer home to go haywire.

</comment><comment><USER11> I would never expect an algorithmic prediction of property prices to do well on a very unusual ("one of the most expensive sales of 2016") property.

Zillow's estimates in general may or may not be useful -- and personally, i'd be awfully interested in finding out more about their (presumably proprietary secret) algorithms. But "one of the most expensive sales of 2016" is not a good example to say anything about how the algorithm functions in general.

</comment><comment><USER12> I don't see how a model is supposed to accurately predict a house's _selling_ price when in many markets people look at those estimated prices and add a percentage.

<comment><USER13> What do you mean? If there's an easy way to improve on the accuracy of the estimated price, by eg adding a percentage, shouldn't you just bake that simple way into your model in the first place?

<comment><USER12> recurse.

<comment><USER13> If the recursion converges, just take that price as the output of your model?

If it diverges or oscillates: what's the point?

</comment></comment></comment></comment><comment><USER14> So the Redfin and Zillow price of my house I purchased in Oct. 2015 is off about 125K from my purchase price (1.125M) and misses the 400K in remodel. I checked the houses on the same street that sold since and they are off by 200-400K from the ASP. To be fair I live in Los Gatos in Silicon Valley and the housing prices are crazy stupid. Anywhere else in the US the house would be 400-500K.

<comment><USER15> Or you could have the situation a couple of blocks from me: 1920s remodel that was awesome in the inside sold for $850k. Crappy 1940s house with one owner for 40 years (and it shows) is Zestimated to be the same price as they have the same stats in square footage and bathrooms. They are listing for a reasonable $575k.

Zestimates are a complete joke. They can complain that they don't have all the facts (but they can infer from the wording of "needs work" and "recently remodeled") but that's like if a frog had wings it wouldn't bump its ass a hopin.

What I don't get is that they have the data on millions of sales. Surely they can come up with something that's not 30% off. At that rate you minus well just guess at a price and be better off.

<comment><USER16> Because a more accurate estimate of value requires well-formed data. They would need a good way to judge condition and other characteristics that might require a very subtle interpretation of a listing, or might require an in- person visit to a property.

These kinds of judgements are much more complicated than traditional machine learning. My guess is that they are feeding easily-obtained data into a machine learning algorithm, and quality of property, interpretation of a listing, and viewing of pictures, is not something that's easy to feed into a machine learning algorithm.

</comment></comment></comment><comment><USER17> If the CEO is overpaid himself, I see no problem overpaying for a house :)

</comment><comment><USER18> Generally I find that Redfin's estimates are more accurate than Zillow's. Zillow often is off by more than 10% compared to market prices.

</comment><comment><USER19> That's a nice house

<comment><USER20> Pity about the furnishing/interiors. What is it with rich americans having such banal taste? Looks like a bland hotel

<comment><USER21> Aren't those the pictures from the real estate agent? You probably want to keep things as simple and 'blank' as possible when trying to sell a house so that people can easily visualize their own tastes onto the house.

</comment></comment></comment><comment><USER22> From a PR perspective this is a horrible move any way you slice it. If I were on the board I would be fuming right now.

</comment><comment><USER23> What a pathetic example of clickbait. Zillow's zestimates are wildly inaccurate. My own home had a zestimate for 2.5x its value. When we sold it, we got an offer well above what it was worth, but about half the zestimate. We viewed the deal as fantastic, and ignored Zillow. In the years since we sold, the zestimate has fallen lower. Go figure.

</comment><comment><USER24> I would only pay 5...

</comment><comment><USER25> Humble brag?

</comment><comment><USER26> $20M for Zillow CEO's home. Zillow itself loses $25 million per quarter. Well done.

<comment> at-fates-hands Not really. . .

 _The company — which completed its $2.5 billion acquisition of Trulia in February 2015 — reported quarterly revenues of $186 million, a 25 percent gain over the same period last year. It also boosted its revenue projections for the year to $825 million to $835 million, up from a previously stated range of $805 million to $815 million._

Are you referencing the Move Inc legal battle?

 _In fact, the company's litigation costs during the quarter tallied $15.7 million, $4 million higher than Zillow expected. Total loss for the quarter was $47.6 million._

 _For the full year, Zillow expects to spend $50 million to $55 million defending itself in the case involving Move Inc._

[http://www.geekwire.com/2016/zillow-group- posts-25-revenue-g...](http://www.geekwire.com/2016/zillow-group- posts-25-revenue-gain-boosts-revenue-projections-2016/)

<comment><USER27> _Total loss for the quarter was $47.6 million._

 _the company's litigation costs during the quarter tallied $15.7 million_

Therefore the company's loss for the quarter without the legal costs was 47.6 - 15.7 = $31.9 million.</comment></comment></comment>


Students Hack Honda Engine to Run Entirely on Hydrogen - <AUTHOR> http://www.automotto.org/entry/students-develops-scotching-hydrogen-internal-combustion-engine-vehicle/

<comment><USER2> impressive</comment>


How the FBI got into El Chapo's encrypted communication network - <AUTHOR> https://threader.app/thread/1082697402539229184 <comment><USER2> The interesting part about this that the servers had to be moved to the Netherlands tk make the wiretapping legal. Seems the Netherlands is not only a tax evasion heaven but also useful for wiretapping.</comment>


Patient details of 'any Australian' for sale on darknet - <AUTHOR> https://www.theguardian.com/australia-news/2017/jul/04/the-medicare-machine-patient-details-of-any-australian-for-sale-on-darknet <comment><USER2> _TWO_ file photos of shady hooded figures with obscured faces and glitch art effects or other digital overlays put over the pic! Truly, this is a very comprehensive report about hacking indeed.

On a serious note, I'm not at all surprised that my government's screwed up some sort of online database of private information. We had the famous census night access issues due to a DDoS and I am just waiting for that data to leak. It doesn't surprise me whatsoever when our government mismanages IT projects in particular and I suspect more of this sort of data leak is going to inevitably happen as a result.

ITifying _all_ of the things isn't necessarily a good idea. Some things are honestly worth the extra hassle of being left to pen and paper.

<comment><USER3> > We had the famous census night access issues due to a DDoS and I am just > waiting for that data to leak

That wasn't a DDoS, that was a few million Australians trying to use a poorly implemented system.

<comment><USER2> I thought they blamed a DDoS by unknown parties in addition to the unexpectedly high load of us all trying to access it?

<comment><USER4> They tried blaming it on that, but it was just incompetence. They didn't even buy DDoS protection services.

There's more details on the inside story of the Census here: [https://risky.biz/censusfailupdate/](https://risky.biz/censusfailupdate/)

<comment><USER5> "DDoS protection services" are a racket. Build the thing right and you don't want or need them.

<comment><USER6> You haven't worked in a govt department have you. In one meeting the BA Ministry lead fell asleep and actually started snoring. In another, the ministry infrastructure architect said, "oh, that thing, I've lost the word, what is it?" \- "a server?".

As an ex antipodean govt contractor, I'm not even kidding. Many other stories of complete fuckwits who had no right to touch a keyboard, never mind run things. My conclusion was anyone with any smarts was completely bamboozled by the abject incompetence and left to the private sector, leaving behind the above characters. Unbelievable, but true. Saying that, don't believe me, get a job there and I see for yourself :)

<comment><USER5> Requiring them to buy DDoS protection would be part of the problem, not the solution.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> @dang, could you please update the link to the article by the original journalist. [https://news.ycombinator.com/item?id=14693998](https://news.ycombinator.com/item?id=14693998)

</comment><comment><USER8> On a related note, I've recently had two UK banks request more personal documents from me, and a video, for anti-fraud or anti-laundering, blah, blah reasons. When, not if, they get hacked, the intruders will have even greater ability to abuse my identity. Data protection acts are barking up the wrong tree - what we need are data limitation acts to require corporations to store as little data as possible.

<comment><USER9> If they get hacked next time they'll ask you even more info.

</comment></comment><comment><USER10> Original story from The Guardian: [https://www.theguardian.com/australia- news/2017/jul/04/the-m...](https://www.theguardian.com/australia- news/2017/jul/04/the-medicare-machine-patient-details-of-any-australian-for- sale-on-darknet)

</comment><comment><USER11> Wait, this is _75 records_? What kind of leak is that? Seems far more likely to be one user accessing data over an insecure network and having that session captured, or similar one-instance leak. But on the other hand...what are the odds this journalist was one of a random 75 records?

<comment><USER12> Given certain details they were performing lookups on demand for a price. This does not suggest server ingress, it implies lack of bulk exfil. Access to a logged-in authenticated session. Nothing like Google/Royal Free Hospital heist.

</comment></comment><comment><USER13> My bet is it is a compromised client certificate from a doctor or hospital.

The authorities will query the audit logs to determine who accessed the journalists record and revoke the cert.

The log will show the other leaked records, which the authorities will report to the victims.

The investigation into how those records were leaked will land several people in jail, as it is easily traceable to the credential.

Bad idea, darknet vendor! Selling data this traceable is sure to get you v&

<comment><USER14> You are implying that they have such logs. I'm fairly sure you will find they do not.

</comment></comment><comment><USER15> Anyone have any feasible monetization schemes for personal healthcare data?

<comment><USER16> Advertising? "Buy medicine X now because it's much better than medicine Y for your condition". Also, insurance companies like to know what you have. If they secretly have your personal healthcare data, they could do a more focused 'sampling'.

<comment><USER17> I don't think medical data, other than information that is actually directly printed on a card, is obtained or sold.

</comment></comment></comment><comment><USER18> Original article written by the reporter who actually did the original research: [https://www.theguardian.com/australia- news/2017/jul/04/the-m...](https://www.theguardian.com/australia- news/2017/jul/04/the-medicare-machine-patient-details-of-any-australian-for- sale-on-darknet)

<comment><USER19> Ok, we'll change to that from [http://www.news.com.au/technology/online/security/hackers- ar...](http://www.news.com.au/technology/online/security/hackers-are-offering- to-sell-the-medicare-details-of-australians-on-the-dark-web-government- confirms/news-story/c475b1cbc963648c191a1eaceba4b12b).</comment></comment>


Unlocked, Dual SIM Android Smartphone with Tor - <AUTHOR> https://www.indiegogo.com/projects/boss-phone-world-s-first-unlocked-dual-sim-w-tor

<comment><AUTHOR> Would you trust something like this?</comment>


Taking Microsoft to Task Over IE8 Myths - <AUTHOR> http://www.webmonkey.com/blog/Taking_Microsoft_to_Task_Over_IE8__Myths_ <comment><USER2> It's marketing bullshit. There's lots of that in the world. It's not worth paying attention unless somebody in this community still uses IE by choice.

<comment><USER3> Actually, it's worth paying attention because it's about a convicted monopoly abuser spreading disinformation about its competition in order to hurt it.

That's nasty.

<comment><USER2> But it's hardly surprising.

<comment><USER3> Nor disappointing

</comment></comment></comment></comment><comment><USER4> While it's good that we're all paying attention to this, writing articles about it is not the most direct way to solve the problem. Simply report Microsoft to the Federal Trade Commission for misleading advertising, like I did: <http://news.ycombinator.com/item?id=663319>

</comment><comment><USER5> I think Microsoft ways to promote IE8 are very ____*. If we gather and send emails (millions) of protest they should be ashamed

<comment><USER3> I don't believe "shame" is an emotional response we could expect from Microsoft.</comment></comment>


Show HN: Stensal SDK: Retrofitting C/C++ code with quasi-memory-safety - <AUTHOR> https://stensal.com <comment><USER2> Looks interesting. I have some questions:

(1) Where can I find a minimal code example where Stensal SDK finds a bug that could not be found with Valgrind, Sanitizers (i.e. Asan, UBSan) nor with MSVC debug mode?

(2) From the Get Started guide it looks like Stensal SDK is a custom compiler. If this is correct: which versions of C++ does it support? Does it fully support C++17? Is it based on another compiler (GCC/Clang)?

(3) As your pricing seems to be on a 'per user'-basis, does the CI server count as a single user?

(4) What is the observed slowdown in real-world applications? Or benchmarks like these: [https://github.com/google/sanitizers/wiki/AddressSanitizerPe...](https://github.com/google/sanitizers/wiki/AddressSanitizerPerformanceNumbers)

<comment><USER3> I think (1) is the wrong question to ask, because none of these tools are suitable for usage in a production deployment, so you will only find those bugs with them that can be triggered with your test suite, which is necessarily incomplete.

A better question is, is this new tool intended to be used in production deployments, and what, if any, new attack surface does it introduce?

<comment><USER4> As you have rightly pointed out the intended use case. I want to add more constraints to it. It's intended to be used in production deployments that are security critical, constant applying security patches is not an optimal solution, and slowdown is bearable.

It will introduce denial of service attack. QMS executables can operate in two modes: warning mode and crash mode. Both will reduce the level of service, but neither will allow memory accession violations to happen.

Edit: added more constraints to the suitable production deployments.

</comment></comment></comment><comment><USER5> Using memory and address sanitization goes very far, without the need for special libraries.

gcc/g++ and clang/clang++ both have full support at this point.

<comment><USER4> I'm the founder and built the SDK.

Agreed, ASAN and Valgrind cover the most memory errors and are readily available for almost all platforms.

The SDK is designed for a different purpose -- to catch all runtime memory issues with a very high probability. The generated executables can be deployed and used by the end users who don't want to upgrade just for the fixes of memory errors. There are many cases the memory errors are never exploited. By using the pre-built QMS executables, you know when you are exploited, and the exploit will be stopped by the runtime checking.

Edit: Even though I have been reading HN for a quite long time. This is my first post, I just registered recently. I could not figure out how to post Show HN and had to ask a friend to post it for me.

Added more details.

<comment><USER6> I couldn't figure out much from the site as to how this works. Can you go into some detail?

<comment><USER4> I guess you ask how this dynamic type system works. It basically gives each valid pointer a type, which includes the size information and liveness information of memory pointed by the pointer. When a pointer is dereferenced, the runtime checking will verify whether the dereference is valid. Null (and uninitialized) pointer does not have a type.

It uses a completely different mechanism from the one used by ASAN and Valgrind.

Edit: delete a wrong answer.

<comment><USER5> Interestingly, SillyMUD and its descendant Phoenix at one point had similar memory checks that occurred at runtime, as well as shared memory with reference counting and a paging virtual memory system.

Unfortunately, even with that and it having been run with purify (a commercial predecessor to valgrind), i was still able to find some severe memory issues that didn't manifest by compiling with address and memory sanitization about 25 years later.

<comment><USER4> I didn't know SillyMUD. But I did read the paper about an interpretation based memory checking tool many years ago. Unfortunately, I forgot the name. I believe the interpretation based memory checking tool assigns each pointer a type. So the idea is not new.

ASAN is great because of its compatibility with existing libraries, as you have pointed out, is available in both gcc/clang. Valgrind is in the same league. Both are fantastic tools even though they might miss some errors.

</comment></comment></comment></comment></comment></comment><comment><USER7> Could you compare your approach to SoftBound ([https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/](https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/)) ?

<comment><USER4> I want to avoid to do comparison with the said X tool without fully understanding their constraints because different approaches have made different design trade off and each has its own strength. That having been said, the academia often publish some survey papers about the state of art of memory error detection tools. There is a recent paper "SoK: Sanitizing for Security"([https://arxiv.org/abs/1806.04355](https://arxiv.org/abs/1806.04355)) that has categorized most of the known dynamic memory error finding tools very well. They analyzed the different detection mechanisms and collected empirical data with their best efforts in their categorization. It's highly recommended for anyone who wants to understand the difference among these detection tools.

IMHO, If you want to increase your detection coverage. You might need multiple tools to fulfill your code quality requirements. If you cannot use multiple tools, pick the one that is readily available.</comment></comment>


Exposure to neonicotinoids impairs honeybee winterization before colony collapse - <AUTHOR> http://www.bulletinofinsectology.org/pdfarticles/vol67-2014-125-130lu.pdf <comment><USER2> Reprising a comment from an earlier honeybee thread:

For what it's worth, EconTalk had a really fascinating interview with a honeybee economist (<\-- thing that exists!).

Turns out:

* Practically 100% of US honeybees are domesticated; wild honeybees were wiped out in the late 80s by Varroa mites.

* Honeybees aren't native to the US; I'm not sure if I heard this right, but it may be that _none_ of the social bees are.

* Colony collapse is largely a phenomenon observed during overwintering. Some 15% of domesticated colonies fail over the winter. CCD seems to have upped this figure to 30%.

* If CCD is causing problems for professional beekeepers, those problems don't seem to be reflected in the economy. The price of queen bees (raised by specialized apiarists to help other beekeepers split colonies) hasn't changed. The price of pollination services --- mostly for the California almond crop, which is fed by beekeepers from around the country --- hasn't changed significantly either, with the possible exception of a small spike in pollination fees at the peak of almond pollination season.

It's hard to reconcile what the economist reported with the alarmism surrounding colony collapse.

It's also difficult to compare the impact of "neonicotinoids" with that of the Varroa mite.

<comment><USER3> _Honeybees aren 't native to the US_

Both wild and domesticated Honey bees were present in the Americas when European colonists arrived. However, the common honey bee was not among them, and the other (I hesitate to say 'native') species are indeed no longer extant.

 _If CCD is causing problems for professional beekeepers, those problems don 't seem to be reflected in the economy. The price of queen bees hasn't changed._

Queen pricing might not be as strongly correlated to CCD as you might expect. Raising queens is indeed done commercially by specialized beekeepers, but if you're already a beekeeper, it is not hard to do or learn. You can raise dozens at the same time, in a single hive, and this does not stop that hive from producing honey later in the season. It's therefore quite possible that the increased demand in queens after overwintering has simply been met by an increase in the supply.

<comment><USER4> _It 's therefore quite possible that the increased demand in queens after overwintering has simply been met by an increase in the supply._

I think that this is the earlier point--

(ie, with no huge price ∆)

</comment></comment></comment><comment><USER5> The paper is short and clear. It's worth reading, and worth thinking about how it could have been differently so as to be more conclusive, and how a followup study might be improved.

1) There is no mention of whether the people caring for the bees were blinded as to control versus treatment. This is simple, and should have been done if it was not.

2) There were only 6 hives in each treatment group (control, imadacloprid, and clothianidin). There are always constraints, but more hives would be a much stronger study.

3) Lu's previous study found 100% mortality with 1/7th the dose of imadacloprid. Why did they increase the dosage for this experiment?

4) There are 3 apiary locations, but they don't report the breakdown per apiary. Did all the apiaries experience approximately equal losses in the neonicotinoid hives?

5) Is there a "file drawer" effect here? If there had been one fewer treatment hive collapse and one more control collapse, would this study have been published?

6) Were any other studies performed? Or started and abandoned? I'd presume not, but it would be great to have a clear statement from the authors.

7) Is it reasonable to assume that the dosage is spread evenly across all bees? If the clothianidin LD50 is 3.4 ng/bee, and they are administering .74 ng/bee/day, it seems likely that some bees will die from acute poisoning.

8) They don't breakdown the numbers per hive, and instead give averages that include abandoned hives. Were the surviving non-abandoned neonicotinoid hives any weaker than the control hives?

My hope would be that the authors would provide the full data if requested, but I'm constantly surprised that journals don't require this. Without additional information, this seems like an interesting exploratory study that neither confirms or denies any specific hypothesis.

I'd guess that there are enough beekeepers interested in future studies that a larger scale study would be possible. Many bees are fed over the winter with sugar, to compensate for the honey that is taken. Do you suppose that there are beekeepers that would agree to a blind dosing of their bees if the lab were to provide the (possibly poisoned) sugar?

</comment><comment><USER6> This is one of these crazy situations where companies are lobbying the crap out of politicians to keep these insecticides on the market.

These bees are fundamental to the production of most vegetable matter that we eat. The financial implications of the loss of these insects is huge compared to the 'loss' of money the insecticide companies would bear if these chemicals were banned from sale.

</comment><comment><USER7> "Big Agro" is probably more inve$ted in this than "Big Chem". For those skeptical conspiracy theorists...

"A survey of honey bee colonies revealed no consistent pattern in pesticide levels between healthy and CCD-affected colonies when pollen, bees, and beeswax were tested for the presence of 170 pesticides. The most commonly found pesticide in that study was coumaphos, which is used to treat honey bees for Varroa mites.

The pesticide class neonicotinoids (clothianidin, thiamethoxam, and imidacloprid) has been accused of being the cause of CCD. The neonicotinoids were developed in the mid-1990s in large part because they showed reduced toxicity to honey bees, compared with previously used organophosphate and carbamate insecticides."

[1][http://www.ars.usda.gov/News/docs.htm?docid=15572](http://www.ars.usda.gov/News/docs.htm?docid=15572)

</comment><comment><USER8> I see wild bee colonies all the time in New Mexico and some built a colony in my apartment wall in Arizona. These bees are serious... in fact, they kill several people every year.

I see lots of articles on bee decline, often blaming pesticides, but they don't seem to have affected wild bees (from my informal survey anyway). These wild bees are very similar to honey bees... I doubt an untrained person could tell the difference. I wonder why the decline in one and not the other? It seems pesticides would affect them both. My guess it has to with genetics and/or cultural techniques. I see mites mentioned sometimes as suspect.

<comment><USER9> > I wonder why the decline in one and not the other? It seems pesticides would > affect them both

I think the difference probably comes from the practice of transporting domestic bees to large orchards and vegetable fields for pollination services, where their diet is almost exclusively limited to agricultural products (which are sprayed).

<comment><USER8> That's a good point. Wild bees probably happen into agricultural areas but not as much and have the option to avoid them.

</comment></comment></comment><comment><USER10> Does anyone know where one could get good data on bee populations, migrations, etc? or pointers to good bee keeping resources which might refer me on to data sources?

</comment><comment><USER11> Something interesting I heard the other day is that Australia has neonicotinoids and no verrora mite and doesn't suffer from colony collapse.

</comment><comment><USER12> Sample size of 18... in other news vaccines cause autism.

<comment><USER13> 18 hives. That's a whole lot of bees.

Furthermore, the results are jarring. Bees deserted the twelve hives treated with neonicotinoids, to the point that half of the hives died. The survivinghives were seldom populated and either without queen or without brood.

There was no desertion in the control group. One hive of the control group died of some disease, but the hive was full.

<comment><USER12> And one person is a whole lot of cells...

<comment><USER13> The comment was indeed a bit disingenuous :-)</comment></comment></comment></comment>


A core Python committer's (very shallow) thoughts on Dart - <AUTHOR> http://sayspy.blogspot.com/2012/05/my-very-shallow-thoughts-on-dart.html <comment><USER2> _Dart views types as helpful documentation and a way to help tools assist with things, period. I actually find it rather refreshing to have a language that treats types as just documentation since that is really what they are for the programmer_

But, just like documentation, if it gets out of date you're really wonked.

I'd prefer something that is both useful as documentation _and_ is used by the compiler (a la Haskell's type classes).

<comment><USER3> It already is - you just have to run in checked mode.

<comment><USER4> I have to admit, there's some part of me that wants to think that "types as documentation" is a good idea. But I have to go with the OP on this one... I watched the Dart presentation from Lang.NEXT and laughed a bit to myself at one point because even in the presenter's example, the "type documentation" was already outdated. During his presentation it doesn't matter, because everyone watching is in the context of the code as part of his discussion. But if you put that code in front of somebody a year from now, out of context, would they immediately pick up on it? Or will they be frustrated by the fact that they expect the types to be what they say they are, but they aren't?

Are people really going to run in checked mode to verify their code? Or they going to do what they do with compiler warnings and turn them off as soon as they see one? I'm sure there will be a million blog posts titled "Dart Best Practices" that will say "do not use checked mode, it slows down execution and prints confusing messages". Of course, any bugs in checked mode will mean people will need to get their production systems working by ignoring checked mode.

I guess... my gut tells me that you should either have types, or not have types. Being in the middle creates too many opportunities for cognitive dissonance, too many opportunities for sneaky bugs, and too many opportunities to keep having this debate. It's one of those things that seems really smart and cool that, on a practical level, will probably turn out to be a complete waste of time and a total distraction.

<comment><USER5> _I guess... my gut tells me that you should either have types, or not have types. Being in the middle creates too many opportunities for cognitive dissonance, too many opportunities for sneaky bugs, and too many opportunities to keep having this debate. It's one of those things that seems really smart and cool that, on a practical level, will probably turn out to be a complete waste of time and a total distraction._

The worlds collective programming experience doesn't really back that up. Almost every language drops (or makes optional) type support when constructs become too complicated, or they become so complicated no one can understand them.

Languages with the best type systems (OCaml) aren't particularly popular, while languages we think of as strongly typed (eg Java) have big backdoors to allow people to bypass the type system.

On the other side, weakly typed languages are adding typing-like features by integrating unit test facilities into the environment (which - optionally - catch many of the bugs typing can help with).

Like so many things, optional typing might seem impure, but often messy systems are the most robust.

<comment><USER6> Dart's optional typing is not common in languages at all. What you're referring to is a combination of dynamic and static typing, which is not Dart- style optional typing. In statically-typed languages, the dynamically-typed values are clearly delimited in the source text and are not a compiler switch.

</comment></comment></comment></comment></comment><comment><USER5> Interesting, and very positive review.

Maybe it's my Java background coming through, but I _like_ the idea of Factory constructors.

<comment><USER7> Every time I read about Java developers and their love of Factories (and Factory Factories) I think of this wonderful comment on Joel on Software:

<http://discuss.joelonsoftware.com/default.asp?joel.3.219431>

NB Factories are one of these things that _seem_ like a good idea in theory, but often seem to end up with crazy levels of abstraction in practice.

<comment><USER8> A message I received from a friend working at Google:

"New layers, more layers, bigger layers, better layers, abstract layers, injected layers, factory layers, module layers, AbstractFactoryFactoryModuleBuilderInjector layers, layers upon layers within layers wrapped in layers, a glorious spire of layers to reach the heavens and bring renown to Babylon! Hellelujah!"

</comment></comment></comment><comment><USER9> Single-inheritance, but interfaces can have default implementations? Isn't that... multiple inheritance?

<comment><USER4> You can implement multiple interfaces on a single class, but only "inherit" from a single implementation.

Or, perhaps more specifically, you can implement an interface without extending its default implementation.

As the article states, the default implementations are there more so that you can say "m = new Map()", instead of having to remember about this other thing called "HashMap".

</comment></comment><comment><USER10> _they still went a little overboard in my opinion on some things (e.g. the list interface has a last() method instead of supporting negative indexes)._

A last method is much more intention revealing and easier to scan for me than negative indexes.

<comment><USER11> Are you also a fan of list.first() over list[0]? I think it's just a convention that takes getting used to and ends up being quite handy.

<comment><USER10> Have you seen some of the early Bittorrent code? Code with lots and lots of this[n:-3] or this[1,:,:] sprinkled around in the same piece of code starts to get like regexp or Perl. It's a cool operator to have to get stuff specified in a few keystrokes, but that makes it quite terse, so high density use of it is hard to read.

</comment></comment></comment><comment><USER10> _...have done toy examples now in 18 languages...this is actually usually enough for me to grasp the inspirations for a language and thus understand its essence._

 _Usually_ is the dangerous word here. (Dangerous as in, "a little knowledge.")

<comment><USER12> Actually, that's the point when I stopped taking him seriously (though why anyone in core Python should be taken seriously as a language designer I don't know). 18? Come on. I've deployed projects in that many languages.

<comment><USER10> My point is more that in-depth knowledge in a number of languages is also vital. The 18 toy examples is completely unimportant. Competency in core Python is. I would look for such depth in one or two other languages.

</comment></comment></comment><comment><AUTHOR> Some responses from the Dart team: [https://plus.google.com/115362263245161504841/posts/82jKeP4Y...](https://plus.google.com/115362263245161504841/posts/82jKeP4YjbG)</comment>


Online bullying – a new and ugly sport for liberal commenters - <AUTHOR> http://www.guardian.co.uk/commentisfree/2012/oct/18/online-bullying-ugly-sport-liberal-commenters

<comment><USER2> Comment threads on articles posted on the internet degenerate into petty proselytizing? Color me surprised!

</comment><comment><USER3> "There's no hate like liberal hate"

[https://www.google.com/search?q=there%27s+no+hate+like+liber...](https://www.google.com/search?q=there%27s+no+hate+like+liberal+hate)</comment>


Why Today's Automobile Industry Looks a Lot Like IBM in 1985 - <AUTHOR> http://techcrunch.com/2015/05/17/why-todays-automobile-industry-looks-a-lot-like-ibm-in-1985/ <comment><USER2> The author's point is that by using Apple CarPlay or Android Auto, they hand over control over software and become "commoditized hardware providers", just like IBM and the IBM-clone providers in the 1980s and 1990s.

I consider this argument ridiculous, as the in-car-software controls nowhere near as much of the user experience as the operating system and applications of a personal computer. Today's car builders have their profit margins because of engine design, build quality, exterior design and branding. They don't lose power by outsourcing their software stack. Actually a lot of them _already use the same software over their entire model range_ (f.e. Volkswagen, Ford, BMW all do) and it does not seem to hurt the sales & profits of their top-end models, so the point that software is the crucial buying factor is basically already refuted.

(I think they should rather be afraid of Tesla overtaking them in what actually matters)

<comment><USER3> I suspect this is going to be like the iPod launch itself: software doesn't matter, until someone produces some that the non-enthusiast users find is a great improvement in usability.

In-car entertainment is going to be a marginal thing in the smartphone era; people just want to use the car as a peripheral display and speakers for the phone they always already have. Maybe integrate some buttons so you can control the navigation more easily.

The two threats are Tesla (battery changes the owner experience as charge requires more active management by owner) and self-driving cars in general.

<comment><USER4> I'd argue that the latter is a reflection on the escalating costs. Self driving is really a sharing scheme. I work in a place in a average cost city where the average salary is north of $100k -- I'd guess the average car is 7 years old. Hell, I'm the boss and I'm driving a 13 year old Honda.

In the 90s, the average car in my high school student lot was newer!

<comment><USER5> That might be part of it, but car quality has increased dramatically over time. In many ways the average 10 year old car now is in about the same mechanical condition as a 5 year old car in 1990. Combined with the general low mileage of most city cars and there is little reason to drive a new car.

</comment></comment></comment></comment><comment><USER6> This author has a lot of misconceptions what a car is and how it is composed of.

The HMI/MMI or however you would like to call that thing in the middle is only a small part of the software in a car. And even using standards like Apple CarPlay or Android Auto does not mean, that they give anything away. Both "platforms" are not even platforms, they are just proprietary versions of VNC. Its like the current iteration of the Apple Watch: there is no application running on the watch. The applications can display information and they have a back channel for the user interaction. But the real application still runs on the phone. That is also true for Android Auto and Apple CarPlay.

Then there is much more to control in this second display (the first display is the dashboard), which is air condition, power sliding windows, roof, and all the other car functions. Because anything in a car is controlled by software. In a normal mid-sized car there are about 40 to 60 ECUs (electronic control units), in a luxury car that can go up to 90 and some more.

Current estimates are that a modern car is comprised by about 30% software, 30% electronics, and 30% mechanics.

Seeing the reason decline of software quality by Apple, I am feeling pretty comfortable that they are only doing user interface stuff, that is unimportant to the cars performance.

</comment><comment><USER7> Have you checked with the customers? I have never heard of a customer commenting software features of a car. It looks to me that car buyers are interested in other things in a car. I mean, at least for me (potential customer?), an Audi with the shittiest software will always win vs a Fiat with the best software. You can't just compare completely different industries and draw conclusions like that, you should give some more factual stuff to prove your argument I believe.

<comment><USER8> _> Have you checked with the customers? I have never heard of a customer commenting software features of a car. It looks to me that car buyers are interested in other things in a car._

Even as a fellow auto enthusiast, I get the sense that we don't represent the majority. There's a reason most car salespeople can't explain anything technical about the vehicle they're trying to sell you -- most buyers don't care about those details.

If Tesla (or anyone else) comes out with a cheap enough car that can't do over 50mph, runs on a user-friendly electric ecosystem, has terrible driving dynamics, and can autopilot between home and work?

I feel like they'd seize 25%+ of US auto sales at least.

<comment><USER9> Nah, at least not people where I live. While most people aren't enthusiasts, almost everyone does 60mph on the main arterials, and 70-80 on the actual highways.

<comment><USER8> And I just threw out 50mph as a "cheaper" number.

You really think people would trade the ability to completely focus on something else during their commute (autopilot) for the ability to go faster but have to focus on the road?

<comment><USER9> I think those of us who would do that are already using public transit (I include myself in this group, by the way). It might get some people who say "well, I _would_ take the bus if it ran where I live/work", but anyone who lives and works on a bus route would already be using public transit if most people felt this way, and public transit will continue to be cheaper for quite some time.

<comment><USER8> The cost of public transit for me is mostly time: imo bus connections are terrible when you're doing it every day (or twice!). And I ride as often as possible.

It also supposes your city has an efficient and reasonably cost effective public transit network. Which isn't always the case.

Automated electric personal vehicles solve both these issues: it's as timely as you can get (unless dedicated rail is weighed in, but...), and it requires only a city electrical grid.

</comment></comment></comment></comment></comment></comment><comment><USER10> _Cars will become commodified, and as long as it's running CarPlay or Android Auto, I won't care what I'm driving._

Somehow I don't think so. It doesn't help that the author gets the mechanics of the PC transistion wrong as well. The biggest threat at the moment to automobiles is self driving. If we get a self-driving Uber or Lyft we're going to have an entire generation of people who just have their phone summon transportation and never own a car.

<comment><USER9> > If we get a self-driving Uber or Lyft we're going to have an entire > generation of people who just have their phone summon transportation and > never own a car.

This is going to be affected by cost. Let's look at the numbers.

A Lyft between work and home for me is about $10, plus tip (which is usually $2 for me, except in the rare case the driver's a creep), assuming Prime Time isn't in effect.

If I were to take Lyft both ways every day, that's about $24/day. If I work 22 days in a month, that's $528/month just on my commute. If I want to run errands and Lyft it to places outside of work, that's even more money. Oh, and until the beginning of this year, I worked much farther away from home than I do now, and a Lyft would've run me about $25 each way (possibly closer to $30), plus tip (which, by this point, would go up to $5). At $60/day, I'd be spending $1320/month on commute alone.

How does this compare to other methods of transportation?

Looking at public transport, a monthly pass here is $80. This is a great deal if you both live and work on a bus or train line, assuming you're willing to put up a longer commute. For example, public transit was perfect for my last job, because I lived and worked on the same bus line, and while my commute took an hour (going from the suburbs to downtown by bus takes a while), I didn't mind it because I could just spend the bus ride reading books and comics on my phone, or if I'd been sleep-deprived, I could just zone out in my seat. Also, the only benefit my last company offered was that they'd pay for employees' transit passes (or for those who drive, they'd pay for a parking pass at a local garage, but we could only pick one or the other), so I basically got to commute for free. If you're off the beaten path, however, public transport isn't an option, and if you're reliant on public transit, it limits the companies you can accept positions at.

How does this compare to owning a car? I don't know. I'm not joking here: I've never actually owned a car. Anyone else care to chime in? For the record, I live in North Texas, where cost of living is relatively low, so I'd especially like to hear from other people in my area. If owning a car is cheap enough, then Lyft and Uber will have to drop their prices like a rock to supplant cars for everyone.

<comment><USER11> You live in suburbia, where the distances are long because it's been designed for cars, parking, roads and huge highways. The parking & roads are also subsided. Also your transit is probably subsidized heavily. %80 of the cost is probably paid by your local government / tax dollars.

Lets take the cost of owning a Prius V that drives 500 miles a day:

\- $260/mo car 'lease' ($8.6/day) [200'000 miles over 8 years]

\- $200/mo in repairs ($6.6/day) [Will probably be less in reality]

\- $200/mo in insurance ($6.6/day) [Will probably be less in reality]

\- $50/day in gas

Now the shift employees, that you pay lets say $15/hr on average for 18 hours a day are $270/day. Their cost alone is 3.75 times greater than all of the other costs combined of $72/day. Even if the robot service costed a crazy $2000/month (which it wont be), that is still 4 times lower than employees. So if the corporation passes the robot savings to you your commute costs, they will be x2.5 lower even with my inflated estimates. Your $528 will become around $220, and that is less than the cost of owning a car currently.

If we can convince governments to shift their subsidies to these robot cars to make it %20 of costs, it will be $44/month, which is about half of your transit ticket cost, for on demand travel.

In all cases, the majority of the costs is human labor.

By making cars shared, less cars will need to exist, so parking real estate can be reassigned to other more productive uses. There will be less congestion because these automated cars can synchronize properly. The total amount of cars that would need to exist would only be needed to serve peak base load, like a electrical utility.

Also the speed of trains comes from the fact that they have a dedicated 'road' that only they can travel, so congestition doesn't exist and therefore the service is predictable. You can do the same thing with busses and roads.

<comment><USER10> Exactly this, and the fact that self driving cars can replace all of the other forms of transport (train, bus, taxi) and with electric versions of said cars amortize maximize energy utilization and reduce waste, the numbers just get surprisingly good all around. 80% of the population of the US lives in an "urban" area and they won't personally own cars any more.

[1] [http://www.citylab.com/housing/2012/03/us-urban- population-w...](http://www.citylab.com/housing/2012/03/us-urban-population- what-does-urban-really-mean/1589/)

</comment></comment></comment></comment><comment><USER12> Software is only a small part of the car. The other parts to consider is the build quality of a car. For example, compare a Skoda and a VW. Even though, they are from the sample base platform, their build quality is very different. They share plenty of the same software. Build quality includes items like suspension, safety features and about 1000s other items.

<comment><USER13> That's not actually quite correct. Build quality usually refers to the overall integrity of the finished product, it's ability to withstand wear and tear and reliability.

The difference between a skoda badged VW and a VW badged VW is more about the finish quality - the differences in the seat materials, amount of sound deadening, the amount of standard features and so on.

In most cases the active and passive safety features of a skoda/VW will be identical for the same platform, especially when it comes to things like power train components, which are purchased and built in bulk. The main difference between a VW and skoda engine is that the skoda misses out on the plastic engine cover.

</comment></comment><comment><USER14> This article is a stretch at best. There are too many subsystems in a car that are already controlled by software from Bosch and a few select other companies that have no or little interface into the UI of a car. The author here either doesn't get that cars are a level of magnitude more complicated than computers or he doesn't care. Electric cars can simply things somewhat as it takes a lot of sensors and cpu power to make a gasoline or Diesel engine run and meet emissions standards. However there is still a lot to manage in electric cars too that goes way beyond Bluetooth control and maps.

</comment><comment><USER15> I think I'd trust Google or Apple more with my self-driving car's security than say BMW.

[http://www.pcworld.com/article/2878437/bmw-cars-found- vulner...](http://www.pcworld.com/article/2878437/bmw-cars-found-vulnerable- in-connected-drive-hack.html)

Alex Stamos on Twitter recently:

> _If software is eating the world and all companies are software companies, > then they all need to learn hard infosec lessons faster._

[https://twitter.com/alexstamos/status/600075692731191296](https://twitter.com/alexstamos/status/600075692731191296)

Couldn't agree more.

</comment><comment><USER16> This talk of connected cars is kind of disturbing. How long until cars serve targeted ads on their HUD?

<comment><USER17> If the car can drive itself, what will the person inside be there for? If not to view ads and consume media?

<comment><USER18> To take the blame when the software... err.. car... crashes, of course. The corporation sure isn't going to take the blame.

</comment></comment></comment><comment><USER19> CarPlay is not great.

I don't have any experience with Android Auto or MirrorLink, but I installed a Pioneer head unit (AVX-4000NEX) a few months ago in my car so I could use CarPlay.

The head unit itself is great, gets good reception, sounds great (especially after using the microphone calibration), and the Pioneer interface is fine. I don't know that it's worth the price without considering the deep phone integration. I considered reinstalling the factory head unit (a Scion Bespoke w/ navigation), but I had sold it before I could come to a decision.

CarPlay would work great if Siri worked well, but I've never been able to get Siri to work well in the car or elsewhere (and that assumes Siri is taking requests at the moment). Text-to-speech works fine; dictation is a constant frustration. The other week, I tried to send a message to my wife that "I am in a little traffic so I'm running late, but should be there at 5:20". I don't recall the erroneous outputs generated by Siri, but they weren't even close. After multiple tries, I had to give up. The Maps colors are idiotically low contrast and it can be very difficult to see what current traffic conditions are as a result. The zoom levels in Maps never seem to be right, either too much or too little. The touch interface itself requires too much attention to use and is a car accident waiting to happen.

CarPlay has a long way to go before it is competitive with iDrive, MyFord Touch, or Uvo, which are the systems that I've experienced. My experience with CarPlay makes me question how much testing it actually got while installed in cars with people driving, because there's a lot of glaring usability problems and general interface quirks that should have been caught during testing.

I used to think that CarPlay, Android Auto, and MirrorLink were going to destroy the car maker's infotainment systems. After using CarPlay, I'm convinced it's going to be a while before that happens, if ever. The car manufacturers have a lot of experience with "car UX" and aren't standing still with their own products. Infotainment is also a minor part of the entire car ownership and use experience, and I don't know that I can think of anyone that bought or leased a car because "it has iDrive" or whatever. Drawing an analogy between car manufacturers and 1985 IBM feels forced and is flawed.

<comment><USER20> > I am in a little traffic so I'm running late, but should be there at 5:20

I would phrase this as "Running late due to traffic, ETA 5:20" and this usually works. Siri seems to trip up on articles especially if you don't speak precisely. (And yes, this is extremely annoying)

</comment></comment><comment><USER21> This seems a silly thesis, if only because cars are already commoditized due to years of competition. Early PCs has huge profit margins; current automobiles generally do not.

<comment><USER22> Commoditization is not the same as low profit margins.

The auto makers historically spend a ton of marketing money to keep the auto market from being a commoditized market. So far they've been very successful.

Profit margins are pretty healthy in some segments, for that matter.</comment></comment>


Constructing human-grade parsers - <AUTHOR> http://duriansoftware.com/joe/Constructing-human-grade-parsers.html <comment><USER2> > For a user-facing tool, parse errors should be recoverable and the parser > should be able to keep going to collect multiple errors.

I don't necessarily agree with that assertion. I need to fix syntax errors one at a time anyway, and very often the parser recovers incorrectly and a single missing parenthesis gives hundreds of errors. Depending on the tooling, later errors can obscure earlier ones, but later errors are more likely to just be a result of the parser recovering incorrectly.

A lot of academic work has gone into making recoverable parsers, but a lot of that work originated from when compilers were much much slower. Remember there was a time when compiling meant taking your stack of punch cards down to the computer room, and checking on the results the next morning. The largest C++ file in my corner of the project I work on is about a quarter megabyte, and builds in 2 seconds on my aging desktop. Of course most of that time is compiling and not parsing. I intentionally added a parse error on its last line, and the compiler only spent 800ms to find it. Most languages parse faster than C++, and most source files are smaller. Waiting 800ms to get to the next syntax error isn't that bad, and it sure beats a screenful of false syntax errors resulting from incorrect parser recovery.

Tooling matters though. Good tooling means that rather than having to search a scollback buffer for the errors that matter, you editor has just jumped to some highlighted lines. But good tooling also means that as soon as you fix one syntax error, the parse results are updated. So it doesn't matter if the one error you fixed is the only one, or the tip of an iceberg.

<comment><USER3> Compilers are not the only tools worth considering. Language services are also important, and language services see most use when the code is half-written and malformed.

        func foo() {
            b

        func bar() {
        }

`foo` is still in the process of being written and the user has invoked auto- completion after typing `b`. It's good if the parser can recover and parse the `bar` function so that the language service can suggest `bar` there.

<comment><USER4> As I sit in my fancy editor typing away code fragments I am often struck by the notion that my productivity would improve if the analyzer remembered something about the last clean parse of the file.

If you parsed the file as a diff against the last known good state you should be able reason a lot more about what's going on. Especially if the programmer has a habit of writing code incrementally.

<comment><USER4> Instead, what my editor does is autocomplete code blocks or statements in order to keep the parse tree consistent.

But my editing style causes it to constantly jam me up when I'm trying to change string construction, Boolean logic, function calls or function chaining.

</comment></comment></comment></comment><comment><USER5> I tried using parser generators; it's been quite a while, and the state of the art is almost certainly improved over lex+yacc and bison. But I got sick of diagnostics no more specific than "Error in line 15", and sticking intermediate states into yacc to improve errors broke the grammars. Probably I should have looked more closely at ANTLR.

So I wound up at state-machine driven lexers with recursive descent for parsing, and since the code is hand crafted it's relatively easy to print errors that make sense to users. The parsers might be harder to maintain. But they are easy to understand.

I am not a career compiler jockey, for the most part I've just wanted to get languages of medium complexity into tree form so I can reason about things and generate some code or do some analysis. Mostly I want to get another job done, but emitting quality error messages is a general good.

<comment><USER6> While I certainly understand the desire to hand-write parsers, I think people often underestimate how useful it can be to have an explicit grammar for your language (even if you hand-write the parser then just fuzz test it against the grammar or something like that). It can help so much with external tooling, and you can often analyse explicit grammars in ways you could never analyse a hand-written parser.

As a concrete example, I recently had to write a parser for i3 config files and trying to figure out what was and wasn't syntactically valid was so horrendous that I ended up just hacking together some half-arsed thing just about works for the one or two files I tested it but that I'm fairly sure is going to break horrendously at some point.

</comment></comment><comment><USER7> For those who may be interested in improving the error messages generated for LR parsers, you might want to look at MERR from the Unicon project.

[http://unicon.org/merr/](http://unicon.org/merr/)

EDIT: correct spelling mistake

</comment><comment><USER8> Hmm,

Aside from the technical aspects, it seems like constructing good error messages involves understanding human ideas of the meaning of programming constructs.

A big thing is people think of a program as a set meaningful statement with errors involving additions or subtractions from this. But a naive c parser can't give a "missing semicolon" error. All it can do is give "unexpected token X" or some such, because it goes through the code token by token it reaches a token that make sense - that "unexpected token" may be what comes right after the missing semicolon or it might be even further down.

All this is an indication how different the human understanding of a unit of meaning is from just a language spec.

<comment><USER9> That doesn't (in theory) prevent a parser from taking a guess what the user meant though, for example by incorporating formatting (that is otherwise irrelevant to the parsing). In C++ terms, a missing a semicolon after a class definition is a problem, but almost always the next token is not on the same line but multiple lines further down if this is what happened. A parser that encounters a class definition followed by one or more newlines and then an unexpected token could very reasonably output a hint that there is probably a missing semicolon here (and possibly continue under the pretense that it was there).</comment></comment>


macOS Meltdown Patch in 10.13.2 was also in El Capitan & Sierra Security Updates - <AUTHOR> Apple just updated <i>About the security content of macOS High Sierra 10.13.2, Security Update 2017-002 Sierra, and Security Update 2017-005 El Capitan</i>[0] with the following additional information:<p>> Kernel<p>> Available for: macOS High Sierra 10.13.1, macOS Sierra 10.12.6, OS X El Capitan 10.11.6<p>> Impact: An application may be able to read kernel memory<p>> Description: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.<p>> CVE-2017-5754: Jann Horn of Google Project Zero, Werner Haas and Thomas Prescher of Cyberus Technology GmbH, and Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from Graz University of Technology<p>> Entry added January 4, 2018<p>[0] https://support.apple.com/en-us/HT208331 <comment><AUTHOR> Since posting this 18 hours ago, Apple has changed the text yet again[0] to apparently indicate that the fix was NOT included in El Capitan and Sierra Security Updates:

> Kernel

> Available for: macOS High Sierra 10.13.1

> Impact: An application may be able to read kernel memory

> Description: Systems with microprocessors utilizing speculative execution > and indirect branch prediction may allow unauthorized disclosure of > information to an attacker with local user access via a side-channel > analysis of the data cache.

> CVE-2017-5754: Jann Horn of Google Project Zero, Werner Haas and Thomas > Prescher of Cyberus Technology GmbH, and Daniel Gruss, Moritz Lipp, Stefan > Mangard and Michael Schwarz from Graz University of Technology

> Entry updated January 5, 2018

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


BizSpark has discontinued - <AUTHOR> https://trainingsupport.microsoft.com/en-us/tcbizspark/forum/tcbsprk-tcjoin/bizspark-program-update/4457bcb6-418c-4233-84bc-13e856a47a00 <comment><USER2> I am really sorry, it was a great offer to legitimate startups, but it was abused by illegitimate requests.

They should have partnered more aggressively with universities and startup accelerators - at the end of the program you had to request a code to access it.

My startup attempt failed, but BizSpark was basically the biggest outside help we received and it was a great way to bootstrap without other investment (plus I believe Azure is great though a little pricey).</comment>


Pixels - <AUTHOR> http://blakefrost.tumblr.com/post/10612682218/pixels

<comment><USER2> If 1 pt = 0.75 pixels, then there is no meaningful distinction between the measurements. It's a scale factor. It's like advocating for mm over cm. I don't quite understand the point of the article.

If he's worried about terminology, then redefine the word pixel as being 4/3 of a pt. Problem solved.

Also, either his last sentence is a mistake, or I must have misunderstood the entire article.

<comment><USER3> I totally agree.

As someone who is a programmer, not a designer my reaction to reading this is:

"What is this I don't even...."

I figured he was going to be advocating moving to a relative system where the rendering engine was made aware of the dpi of the display and vector graphics (or differently sized bitmaps as in the Android ldpi/mdpi/hdpi model) were used where possible, because we very clearly have to start embracing that model as the dpi and size of devices is beginning to be wildly divergent in all directions... but what he's actually suggesting is basically meaningless, IMO.

<comment><AUTHOR> If you're referring to that last line, yeah I totally fat fingered that. I fixed it.

I'm advocating moving to an absolute system. As in an absolute width, measured here, measured there, measured anywhere. This can then be scaled to mimic the appropriate absolute width based on viewing distance and other parameters such as screen real estate.

I know what you're thinking. "But pixels are an absolute measure...". Actually yes, and actually yes. Pixels are an absolute measure in the sense that they state that I want something to be the absolute size of a single pixel but the pixel is arbitrary and now your absolute measure is relative to the actual size of the pixel. As mighty as this sounds, it actually turns out to be not all that useful in design; as screen resolutions vary so will your renderings. This is why CSS pixels are different, they're for all intents an purposes interpreted as 1/96th of an inch. So, great they're absolutely 1/96th of an inch, they're absolute! So why should you stop using them? This paragraph is why you should stop using them. I didn't like writing this paragraph, and I'm gonna guess you didn't like reading it. Pixels are confusing and pixels are ______* liars. Use points.

</comment></comment></comment><comment><USER4> I'm pretty sure that this is wrong. A css pixel is a screen pixel as long as the screen dpi is reasonably close to 96dpi. Certainly 1px borders on my MBA are always 1px, not a blurry px and a half.

The correspondence between pixels and screen pixels break down when the dpi is nuts, which is why 1 px (css) = 2px (screen) on the retina screen of the iPhone 4.

You can't avoid pixels in CSS. Yet.

<comment><USER5> You are correct. This article is misleading on many levels.

A CSS pixel is ALWAYS the exact same thing as a screen pixel, unless:

1\. The browser's view has been "zoomed". This can occur on desktop browsers or mobile browsers, although it's much more common on mobile browsers.

2\. You are on a quad-pixel display like an iPhone 4. In this case, 1 CSS pixel = 4 real pixels, exactly.

Options 1 and 2 rarely breaks anything due to a use of "px". Those situations that are problematic usually are due to a design flaw in your CSS (and will not be fixed by switching to "pt").

Option 2 will never break your CSS. The only time it matters is if you want to serve double-resolution images [1]. Other than that, you have no access to the super-grid, so don't worry.

[1] [http://www.sitepoint.com/razor-sharp-images-in-mobile- safari...](http://www.sitepoint.com/razor-sharp-images-in-mobile-safari-on- iphone-4/)

<comment><AUTHOR> "A CSS pixel is ALWAYS the exact same thing as a screen pixel"

Not true. You should reread the article, if you care to, and perhaps check the sources. Even if what you were saying was true do you think it makes sense to define things at the native resolution of a monitor? :Faceplam:

</comment></comment></comment><comment><USER6> The idea is that someday browsers will be resolution-independent. They'll have to let go of 96ppi and probably pixels altogether. Making this change is preparing for a future that may or may not come to be. (The Retina Display hints at this.)

The point is valid if not immediately useful. Practically speaking, if you can start and stay with pt measurements, you might as well.

(Regarding how we might bring in a resolution-independent future browser, it would have to be some sort of meta tag or doctype, or maybe CSS fallbacks as we do with font faces.)

<comment><AUTHOR> This has actually already happened. Just start using resolution independent measures and never look back. I'm telling you, they work.

</comment></comment><comment><USER7> Pixels are the best way to get consistent cross-browser font sizes: <http://css-tricks.com/2580-css-font-size/>

Also, graphics are inherently bound to a fixed pixel size... so layouts often have to follow, if you don't want things getting out of whack at other pixel densities.

<comment><AUTHOR> You would think so, but that's not true. Design in points (1/72) and ship in points. I'm telling you, you're stuff is rendering at 1/96th, not native res. Try it out for yourself. Make two divs, specify one as 96px and the other as 72pt. See, same size, same size. Now think, if that were an image... Not native res, but yet it still looks right... Interesting.

</comment></comment><comment><USER8> perhaps if he'd offered to go with em's and to just roll with keeping the design of a page relative to the font size I could understand.

But the easiest way to understand why everyone still uses px, is because when you've got a design created beforehand it'd take an awful lot of work to make it exact using relative sizes.

<comment><AUTHOR> Points aren't relative, their absolute. em is great but another subject entirely.

</comment></comment><comment><USER9> that website is loaded with pixels in the css

<comment><AUTHOR> Do what I say, not what I do. j/k. That's a tumblr theme, I didn't write it and I take no responsibility for it.</comment></comment>


Ask HN: Page Rank Suggestions - <AUTHOR>

I see from a recent post Google has made adjustment to their page rank.  Also we saw a slight adjustment with our rank.<p>Was wondering what are the factors that affect page rank?  Also, the experiences of fellow hackers that caused your page rank to increase and decrease. <comment><USER2> The basic factor is how important your site is. Important sites get higher PageRanks.

I know that's not the answer you wanted, but it's the truth. Lots of people have schemes. They might work for a little while, but Google figures them out and often punishes participants.

The best information can be found here: [http://www.google.com/support/webmasters/bin/answer.py?answe...](http://www.google.com/support/webmasters/bin/answer.py?answer=35769)

In basic: Links to you from _reputable_ sources help you. Having your pages have good content for users helps you. Doing anything to manipulate Google will hurt you eventually. Hiding things (like with CSS), trying to load up on keywords, duplicating content, and other sneaky things hurt you. Hiding content behind a registration or other thing a search engine can't do hurts you. Being browsable with a text browser helps you.

Google's software is advanced. If you put something in an H1, it will realize that it's important to your page. However, if you then resize it to 10px, it's likely to pick up that you're using H1s inappropriately as the Googlebot now grabs CSS as well.

And PageRank often isn't as important as other factors. For example, let's say you want users to find your site when they search for "blog". If people are linking to you with the line "There are cool accounts at [site name]!", that's not going to count much to the keyword "blog". However, if people are linking to you with "Get a [free blog] over at site name!" it'll help a lot more. The fact is that one doesn't care about PageRank so much as one cares about where they get placed in results for certain keywords.

Most of it is just common sense. If your site has compelling content, it will be seen positively. If it doesn't, it won't. It becomes harder and harder every day to fool Google. I suggest not trying. Best case, it boosts you for a short while. Worst case, you get delisted.

</comment><comment><USER3>
          The basic factor is how important your site is. Important sites get higher PageRanks.

Well... that's somewhat of a self fulfilling prophecy. Sites that get high PR show up first in search results, which helps them get more traffic, becoming more well known, hence becoming "important".

PR solves for your score (self consistently) by basically averaging out all the scores of everybody linking to you while coupling this with a (rather crude) model of user behavior. Of course, this is how it's described in the original paper and definitely very far from what actually goes on under the hood now a days.

It should also be noticed that several improvements on/replacements for PR have been suggested over the years, with:

TrustRank <http://www.vldb.org/conf/2004/RS15P3.PDF>

BrowseRank [http://research.microsoft.com/en- us/people/tyliu/fp032-liu.p...](http://research.microsoft.com/en- us/people/tyliu/fp032-liu.pdf)

HITS <http://www.cs.cornell.edu/home/kleinber/auth.pdf>

being the better known ones. Alternatives usually revolve around improving the user behavior model (like including real traffic data in the calculation <http://www.informatics.indiana.edu/fil/Papers/click.pdf> ), but there is still a lot of work to be done in this field (there's couple of interesting papers coming out in WSDM09 and WWW09 about this).

</comment><comment><USER4> There's no easy way to improve it. It's logarithmic, so each jump you make is substantially more difficult than the previous. They tweak it sometimes when they find out how people are gaming it, so every time you try to find some "trick" they're going to fix it. I spoke with one of the engineers who works on the core algorithms and page rank team, and they tweak that stuff sometimes hundreds of times a day. They're extremely diligent, so you won't figure out a way to easily increase your page rank.

The best way is to get highly credible sites to cover you. Time is taken into account (how long your domain has been up), the amount of content on your web site, how relevant your content is to a search query at the time, the amount of traffic you receive, amongst several other things that are more minuscule. You're best hope is to just do whatever you do really well so that it inspires people to talk about you.

<comment><AUTHOR> Has anyone used website.grader.com? If so did you find it helpful?

<comment><USER5> thought that was a scam from a marketng depertment

<comment><AUTHOR> It's a service from HubSpot.com - owner is publisher of onstartups.com. Random posts from said blog appear on HN frontpage.

<comment><USER6> Indeed, some of my OnStartups.com posts do show up on the HN front page. Hopefully, it's not completely random and some people do find the articles useful.

<comment><AUTHOR> Random was not meant derogatorily.

</comment></comment></comment></comment></comment></comment><comment><USER7> Google Official Search Engine Optimization Starter Guide: [http://www.google.com/webmasters/docs/search-engine- optimiza...](http://www.google.com/webmasters/docs/search-engine-optimization- starter-guide.pdf)

Note: Link to PDF

</comment><comment><USER8> Here is a case study about how big company like 1800flower boost the page ranking.

[http://blog.ask2link.com/case-study-advertisers-get-great- re...](http://blog.ask2link.com/case-study-advertisers-get-great-results-with- ask2link-text-links)

</comment><comment><USER9> More links point to your site than your site points out to others, basically. Quality of links is taken into account, of course, so permanent front page of a high pagerank could boost yours quite a bit.</comment>


iOS update leaked Snapchat's source code; data leaked to GitHub - <AUTHOR> https://www.scmagazine.com/ios-update-leaked-snapchats-source-code-data-leaked-to-github/article/787034/ <comment><USER2> You mean, someone could now find out how the user interface works and post a cheat sheet with all the taps, swipes and gestures used?</comment>


Profit per phone vs volume sold for mobile handset manufacturers - <AUTHOR> http://www.asymco.com/wp-content/uploads/2011/02/Screen-shot-2011-02-01-at-2-1-7.30.42-PM.png

<comment><AUTHOR> Full context here (which still doesn't explain the time period depicted in the linked chart): [http://www.asymco.com/2011/02/02/making-it-up-in-volume- how-...](http://www.asymco.com/2011/02/02/making-it-up-in-volume-how-profit- and-volumes-traded-off-in-the-fourth-quarter/)

</comment><comment><USER2> Do they intentionally mix smartphone and non-smartphone sales to make some kind of point? Seems a bit misleading otherwise.

If they dropped all the feature phones from Samsung and Nokia etc. I'd guess the graphs would look a lot more similar since they'll be selling much less and at a much higher average price.</comment>