The Internet of Things Will Be the World's Biggest Robot - <AUTHOR> https://www.schneier.com/blog/archives/2016/02/the_internet_of_1.html <comment><USER2> Rather than IoT, I'd like to have networked Things under my control. The problem is not that they're networked but that they all want to phone home to central services.

<comment><USER3> I use a few IoT devices, and have them on a non-internet network. Unfortunately it requires me looking into each product first to see if it phones home, and deciding which features I want to give up by blocking that.

<comment><USER4> Well, at least most of the protocols are really really easy to RE.

</comment></comment></comment><comment><USER5> Utopias require a slave class. Having autonomous robots doing most/all manual labor sounds pretty good - AS LONG AS they aren't all phoning home to their corporate overlords every 30msec.

When are we going to start demanding devices that are untethered from a mothership and run from home computers?

<comment><USER6> When an untethered machine can provide all of the functionality of a machine that phones home.

(never)

<comment><USER7> Which is 20 years ago. Seriously, in most IoT / smart appliances, the "phone home" capability gives pretty much nothing for the user that couldn't be done without it. Including voice recognition, which worked off-line pretty decently for the last 10 years, and didn't have the network-induced latency. Phoning home is only there because companies are lazy and/or trying to monetize user's data.

<comment><USER8> I'd imagine phoning home heavily subsidizes some of the products through the data produced in aggregate and at the level of the individual through which research can be performed and which may also be monetized in other ways.

For instance, Google paid 10x revenue for NEST [0]. Profit is obviously much lower which means that's a very long term investment for the acquirer. But maybe not if the NEST product integrates with other Google products bringing more people into the Google ecosystem, incentivizing people to stay in the Google ecosystem, and providing data for Google to both improve it's ecosystem even for non Nest Users and to monetize with third parties.

Now if NEST stayed on it's own, it could integrate with other ecosystems or create it's own or just exist as a standalone product but NEST wouldn't have too much data to sell to increase profits, and wouldn't be able to draw as many conclusions as a company which could integrate their data with other data sources. It could create it's own ecosystem but comfortably living within another established ecosystem will probably bring more users to NEST as ecosystem creation is obviously very much outside the purview of a smart Thermostat.

So it sort of makes sense that these products "phone home" even if it's not exactly what we as computer software engineers and privacy advocates might look for in a product.

[0] - [http://www.businessinsider.com/nest- revenue-2014-1](http://www.businessinsider.com/nest-revenue-2014-1)

<comment><USER4> > bringing more people into the Google ecosystem

But literally everyone that could use a NEST product already uses google.

</comment></comment></comment></comment></comment><comment><USER9> My friend Mike O'Dell quoted someone as calling it the "Inherently Dangerous Internet Of Things."

<comment><USER10> Apt. Microsoft actually seems to care about support, compatibility, and security, but it took years (a decade?) of Windows getting hacked for them to finally get serious about security. After another decade or so they're still a ways from fixing the problem, and part of that "fix" is telling people perfectly happy with their current Windows 7/8 systems to go to hell.

The IDIoT means appliance and car makers get to repeat this same slow learning curve, but on both client and server. In a decade or so, buyers will force them care about fixing their buggy, unsupported, insecure software (both client- and server-side this time). In another decade, they will be at around Windows 10 levels of support and security.

Oh, yeah, and a hacked car or HVAC system can kill you much deader than a hacked PC.

</comment></comment><comment><USER11> Obligatory: [https://twitter.com/internetofshit](https://twitter.com/internetofshit)

</comment><comment><USER12> Apart from the "Minority Report" considerations I'm wondering how long this crazy addiction to electronics can be environmentally sustainable.

I can't say I'm optimistic about it.

<comment><USER13> Which part of them is particularly environmentally sustainable?

The metals and plastics used in their manufacture is pretty minimal compared to cars or home appliances.

Their power consumption is low compared to heating or lighting (a macbook consumes power equivalent to about two lightbulbs, and most devices use less).

Earth metals represent probably the biggest environmental impact of consumer electronics. They're not actually rare, just expensive to mine, so there isn't an issue of _sustainability_. (As in, the earth metals aren't going to run out any time soon. There's some nasty environmental damage in the vicinity of the mines, but that's limited to a particular area).

I'm trying to fathom the reasoning behind this comment. Is it that because electronics are really useful and beneficial, they must have a proportional cost?

<comment><USER12> Did you mean "unsustainable" in your first sentence ?

It seems to me that even at our current level of mass consumerism our lifestyles wouldn't be sustainable for more than a few decades. I'll give it to you that it's more a hunch than a an opinion backed by facts.

You're talking about cars or home appliances but generally we have a few of them. Each one of us will probably have thousands of IOT "things".

Billions of humans having thousands of things that are discarded and replaced by new ones when they fail or are not modern enough is not, in my opinion, a recipe for sustainability.

For the record I counted 17 sensors just for my house alarm and I didn't go overboard, if I hadn't be budget constrained I would have put much more than that.

<comment><USER14> How often are you replacing those sensors?

<comment><USER12> The alarm is only one year old, but I wouldn't be surprised if in 5 years the company would tell me they're obsolete and I have to buy the new ones to get better protection.

</comment></comment></comment></comment></comment><comment><USER15> The internet of things won't be anything unless someone can figure out a better user story than "turn your house lights on and off from anywhere!"

<comment><USER16> That statement assumes the IoT is only the part that is exposed to consumers. It's also increasingly ICS/SCADA and other M2M technologies that as soon as they connect to the wider web are part of it. As @vdnkh points out below it is not new - just rebranding.

But the implications (especially for security) are huge. Not just because of _new_ bugs or design flaws but also because the momentum (and media frenzy) it creates puts these old (buggy) technologies into the limelight of security researchers. E.g. stuff that was lurking in old protocols suddenly becomes relevant (want to stop a train? [https://media.ccc.de/v/32c3-7490-the_great_train_cyber_robbe...](https://media.ccc.de/v/32c3-7490-the_great_train_cyber_robbery) ).

There are countless applications not just for BAC but also for logistics, power-grids, industrial automation, e-health, insurance, ... where the IoT is already actively pumping out use-cases, product ideas and actual products.

<comment><USER17> Exactly. To summarize, the major use cases for the "internet of things" are industrial. Think mining, mills, etc.

</comment></comment></comment><comment><USER18> Come for the plant hydrator, stay because.. skynet.

</comment><comment><USER19> The world's biggest botnet too.

</comment><comment><USER20> SMART - Surveillance Marketed As Revolutionary Technology

</comment><comment><USER21> For some definition of robot.

I'm also a fan of Gaia Theory, but it doesn't mean that the Earthly ecosystem is an organism in the same sense as the individual flora and fauna.

<comment><USER22> I am reading into your comment but I am thinking you are considering that the _transient_ and seemingly non-stable nature of a lot of human and animal activity implies that Gaia cannot be an Earth-level macroscopic scale organism comparable to the human body. I think that if you consider the replaceable and transient nature of the molecules and cells in traditional organisms, you will see more correspondences between the two. Also imagine how at the microscopic level (even macroscopic level), humans and animals change quite a bit day-to- day..even moment to moment. So the busyness and seemingly "unstatic" nature of Earth-at-large is no reason to think of it too much differently than a traditional organism.

And considering two further things makes for even more interesting conversation: 1) there's no super-clear distinction between life and death..there's a massive difference in function and activity along the development and decay cycles that are possible for animals. 2) Animals without limbs or with added tools(extensions of our limbs) are quite workable.

This is only meant to add to your conversation; I'm not really detracting because I agree it's not in the same sense but rather a different class of a being.

Oh, and one more thing: Animals' collections of physical cells are also home to a large number of cells from a WIDE VARIETY of different "species" of bacteria and viruses..so many of which can basically take a person either up or down in health by a large factor. So this is analogous to the Earth which is home to a great diversity of humans, animals, plants, and so on. Beautiful really. Except for that which isn't.

</comment></comment><comment><USER23> Thank goodness I'm not the only one who gets this. (I know how that sounds but damnit I feel very lonely most of the time.)

Conceptually speaking, there is only _one_ machine. Two "independent" machines, once coupled, now form one machine. And in the real world all the machines are already coupled.

Also, I feel like people should watch "Maximum Overdrive" and "Demon Seed".

</comment><comment><USER24> Calling the iot a robot is a bit clumsy. This label will do the opposite of the intent, the prudent exposition of the iot as the largest unobtrusive surreptitious surveillance system of all. total information awareness come true.

Labeling it as a robot will rather make people discount the idea. "A robot? That man's crazy. Little things interconnected do not make a godzilla-like world stomping and destroying robot! Nuts!"

To be sure, putting all your industrial scada equipment on the public net could result in consequences similar to having a Godzilla running amok.

</comment><comment><USER25> How long until it deliberately kills someone?

<comment><USER26> Weapon bearing drones?

</comment></comment><comment><USER27> > The World-Sized Web -- can I call it WSW?

I call it IFTTT

<comment><USER28> What about... World Wide Web?

</comment></comment><comment><USER29> What a nightmare - millions of fridges DDoSing nuclear power stations...

</comment><comment><USER30> I have acutally kicked this idea around 4 or 5 years ago of A "WSW" but more so in a sense that modularity would have been the groundworks for such a revolution.

Modularity. Modules, taking the scale of what cpus on the phones have to what the cpus in the late 90's till now had... interoperability... it is just not there yet. Infact it stagnated.

<comment><USER16> ... _interoperability_ ...

a lot has changed in the last months alone. there are several standards ready for IoT (ETSI M2M) [0], some are still being drafted (W3C Web of Things "WoT")[1].

Where I still see lot of room for improvement in standards is for totally radically new use-cases. Standardization guys are usually industry representatives from bigger companies who think about inter-op (and to a lesser extent use-cases). But many use-cases in IoT transcend or even threaten the business models of what the bigger players have built their power/dominance on (they prefer sustainability over disruption -- god I hate those buzzwords).

Therefore smaller innovators (individuals or garage start-ups) who have radical ideas such as building a decentralized business model (maybe using cryptocurrencies or blockchaining and _not_ driven by harvesting user-data or advocate strong privacy) usually don't have the resources or time to put one of their staff into the slow-moving standardization bodies to make/defend their case.

Though the W3 is extremely open compared to others and even there are official members who vote behind closed doors, ... if enough contributors bring ideas in the open discussion groups, then these points too might get standardized.

The biggest problem though is standardizing security.

It is no coincidence that most IETF drafts especially older ones and official RFC's have under "Security" a note that says "to be done". Thinking ahead what might become a design problem later is hard and depends on how the standard later gets understood by the industry. But more important there aren't enough people who understand security in standards groups. That is not just a standards problem though and more of a disease of our industry. Just look at most web developers and have them explain how XSS/SQL-injection works ... or ask an Embedded engineer who is used to building non-connected appliances to think about remote exploitable buffer overflows after they connects the _thing_ via a CoAP proxy to the WWW ... Yes you'd _assume_ they know that in detail but reality is usually most have no idea - not because it's hard but because we are not incentivized by making it extra secure (security often is a useless feature unfortunately only indirectly affecting your financial bottom line (when sh1t hits the proverbial fan)).

[0] [http://www.etsi.org/technologies- clusters/technologies/m2m](http://www.etsi.org/technologies- clusters/technologies/m2m)

[1] [https://github.com/w3c/web-of-things- framework](https://github.com/w3c/web-of-things-framework)

EDIT: typos (possibly even grammar mistakes _gasp_ )

</comment></comment><comment><USER31> Alright, I'll be the one to say it:

Skynet</comment>


Mailcheck.js - jQuery Plugin Suggests A Domain When Misspelled In Email Address - <AUTHOR> http://functionn.blogspot.com/2012/03/mailcheckjs-jquery-plugin-that-suggests.html#.T2oKI08Uzak.hackernews <comment><AUTHOR> Direct Link To Github repo for those who prefer it: <https://github.com/Kicksend/mailcheck></comment>


An Open Source Push Notification Service Written with Rust - <AUTHOR> https://github.com/xray-tech/xorc-notifications <comment><AUTHOR> Our company decided to open source what we could and one of the now free services is a system to send push notifications. It has served us for a couple of years without that much maintenance. I hope somebody finds use for the code and it could be a showcase how to use Rust in your company.</comment>


HBO: Game of Thrones Piracy is a Compliment, Doesn't Hurt Sales - <AUTHOR> http://torrentfreak.com/hbo-game-of-thrones-piracy-is-a-compliment-doesnt-hurt-sales-130401/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Torrentfreak+%28Torrentfreak%29#.UVlf-kKNKcE.hackernews <comment><USER2> What is HBOs problem with Netflix or Hulu? I won't paying double or maybe even triple to Netflix or Hulu to get much better content by including more movies and newer content. Sheesh.

<comment><USER3> Why would HBO license their content to Netflix or Hulu for a pittance when they could make more money offering it directly?

HBO has already stated that the only thing holding back HBO Go is that its current contracts with cable and satellite providers are still too profitable to cannabalize with a dedicated online offering (and more to the point, are effectively cost-free since HBO does not have to employ a sales/marketing force).

<comment><USER2> I see. What an endless chain. Consumers can't switch out of cable because they want to watch GoT. HBO makes sure that you can watch only on cable because they make so much money out of it. We consumers pay way too much to cable operators to get so little out of it.

I think the problem is sports. If sports could move to online streaming, then the entire cable industry would crumble.</comment></comment></comment>


Ask HN: Can I list previous employers as customers of my services business? - <AUTHOR> Currently an independent contractor looking to start a larger consulting company.<p>Is it legal (and ethical) to list my previous contracts as customers of my new consultancy? <comment><USER2> It's legal and probably ethical to note that those companies have benefitted from services of your consultants, though.

<comment><AUTHOR> Hey, thanks for your feedback. A few colleagues made similar comments today and I tend to agree but was curious how that would be perceived.

</comment></comment><comment><USER3> The answer is probably no to both</comment>


Ask HN: What are the implications of CloudFlare leak? - <AUTHOR> I'm having a hard time understanding the implications of this CloudFlare breach. As I understand it, although only the websites who have been using the combination of features from CloudFlare have triggered the leak, the leaked information is from any website which was using the service for MitMing their https for some feature. Am I correct? There is a lot of misinformation out there about the scope of this... Also, is it ok to suppose pretty much any smaller website has been using CloudFlare? Has our payment information been leaked? Should we request new credit cards?
I'm using a few passwords with differing complexity for various websites which have my credit cards stored unfortunately. I have so far been trying to use my strongest passwords exclusively with websites which have my most sensitive info but I still reused the same password for 4-5 websites each.
This fiasco has coincided with me moving over to 1password anyways but I'm worried a bit about my credit cards. <comment><USER2> Without wishing to sound too melodramatic, a complex problem like this one should be the least of your concerns online. Part of my job over the past twenty years has been auditing website code, and I can tell you there are online stores that do things that would absolutely terrify people if they knew what was happening to their data - on one site everyone's creditcard information was being emailed to the site owner's Hotmail account so he could put payments through the till system in his shop.

If you're worried about your credit card data just don't put it in to a website you don't _know_ is secure. If it isn't Amazon, Stripe, Paypal, <your preferred payments provider> etc, just don't use it.

<comment><USER3> +1 for mentioning offloading CC stuff to payment providers

</comment></comment><comment><USER4> "...the leaked information is from any website which was using the service..."

Potentially, yes. Not _just_ HTTPS, but those are obviously the more worrying cases.

It's not possible to know the totality of information that has been leaked, though efforts are being made to try and list affected / potentially affected sites.[1]

My advice would be: For any sites you're worried about (ie hosted on CF and you have an account), log out of all sessions on all devices, and reset your password. Don't share passwords between sites either; if you're using 1password now, you can use unique & complex passwords for everything.

[1] eg [https://github.com/pirate/sites-using- cloudflare](https://github.com/pirate/sites-using-cloudflare)

</comment><comment><USER5> You don't need to preemptively change your credit cards, but keep an eye on them. Your analysis of the potential leak is correct. It's possible that one of the bits of memory contained your credit card information, but changing your card just for that is kind of silly without some indication of illicit use.

After all, people happily hand their credit card to restaurant employees, pop it into gas station devices, etc. without worrying too much. Keep an eye on it, but don't fret.

You kind of goofed with the re-used passwords, though :). Kudos for switching to a password manager!

</comment><comment><USER3> I never trusted Cloudflare's TLS/HTTPS infrastructure. Consider any CC information that _could_ have been in their servers as already compromised. Stuff like that should be on a dedicated payment provider, and insulated away as much as possible. Stripe and other providers are perfect for handling CC, because it's _what they do_ as a service.

</comment><comment><USER6> "I'm having a hard time understanding the implications of this CloudFlare breach."

The implication is that people are still not very smart trusting anything to a 3rd party.

As the saying goes, "If you want it done right, do it yourself."</comment>


Google is developing cancer and heart attack detector - <AUTHOR> http://www.bbc.com/news/technology-29802581 <comment><USER2> I had the opportunity to speak to the head of this project Andrew Conrad at length.

[https://medium.com/backchannel/were-hoping-to-build-the- tric...](https://medium.com/backchannel/were-hoping-to-build-the- tricorder-12e1822e5e6a) What struck me was his optimism that this was really going to happen. Usually researchers are ultra cautious about going out on a limb like that (Yes, he said there was much to do, but read the interview to get his tone.) I think that comes from working at a place like Google X that encourages the big reach.

<comment><USER3> I was diagnosed with a cancerous tumor less than a year ago. It is a tumor that has been growing inside me for at least 5 years. Had it been correctly detected/diagnosed 5 years ago, it would have been an operable tumor with a high chance of a cure rate. Unfortunately, now that tumor is currently non- operable.

Current cancer screening guidelines aren't sufficient and in almost all cases they utterly fail in the early detection of cancers for people under the age of 50.

I applaud anyone working towards a better method for early detection!

<comment><USER4> I am so sorry to hear that! My mother, also, was found with a tumor that we didn't know about for a long time. She fought as long as she could. She never gave up hope.

Doctors don't know everything. There are ways to fight, even natural ones. Fighting with anything is better than giving up. Hope is very powerful. Don't give up. Keep fighting.

Best wishes to you from one who has walked this road with another.

</comment></comment></comment><comment><USER5> Google: "We want to scan your body with our amazing new technology and possibly add 20 years to your life!"

Haters: "No thanks, _way_ too intrusive. I don't want you tracking me/selling my data/showing me ads."

<comment><USER6> Seriously, why would I let an advertising company _in my body_?

<comment><USER7> > _an advertising company_

[http://www.wired.com/2014/10/future-of-artificial- intelligen...](http://www.wired.com/2014/10/future-of-artificial- intelligence/)

> Around 2002 I attended a small party for Google—before its IPO, when it only > focused on search. I struck up a conversation with Larry Page, Google's > brilliant cofounder, who became the company's CEO in 2011. "Larry, I still > don't get it. There are so many search companies. Web search, for free? > Where does that get you?" My unimaginative blindness is solid evidence that > predicting is hard, especially about the future, but in my defense this was > before Google had ramped up its ad-auction scheme to generate real income, > long before YouTube or any other major acquisitions. I was not the only avid > user of its search site who thought it would not last long.

> But Page's reply has always stuck with me: "Oh, we're really making an AI."

<comment><USER8> Most likely you and your kids are gonna be wiped out by intellegent machines just in a few decades.

<comment><USER9> I'm more worried about intelligent humans

<comment><USER10> I worry more about the other side of the bell curve.

</comment></comment></comment></comment></comment></comment><comment><USER11> The heart attack detector seems great, but I wonder about the cancer detector. It may lead to a high number of false positives resulting in unnecessary exposures to CT scans, which because it uses radiation can actually lead to cancer, and unnecessary medical procedures and expenses, and unnecessary anxiety. If they get the false positives down it would be very beneficial of course.

<comment><USER12> Seems like a straightforward optimization problem. Only alert someone if the expected probability of disease is high enough to be worth the risks of radiation and unnecessary procedures.

<comment><USER13> Many tests top out at 50% or less and even if the specificity is high you can't necessarily say whether you have a bad form of the disease or not. That's the problem with PSA testing for prostate cancer.

</comment></comment></comment><comment><USER14> I'm not worried about an "advertising agency" handling this project at all. Google is hardly just an ads agency anymore. They're multi-faceted. Maybe we should be concerned that they're(successfully) reaching their hands into just about every problem domain, but so far it's been good news for the consumer and they haven't done anything that I'm aware of to warrant them to be untrustworthy.

That being said. Watch your diet and carb intake. Preventative measures are better than having to fix the disease at the last minute.

</comment><comment><USER15> I would hope they investigate whether the ingestion of "disease-detecting nanoparticles" increases one's risk of cancer.

<comment><USER16> These aren't amateurs.

<comment><USER17> [http://en.wikipedia.org/wiki/Scotchgard](http://en.wikipedia.org/wiki/Scotchgard)

This product was not made by amateurs and was on the market for about 30 years. Its key component was perfluorooctanesulfonamide, a precursor to perfluorooctane sulfonate, which lingers in the human body for five and a half years and can cause developmental delays, cancer, immune disorders, and all kinds of other things.

Amateurs can exercise due diligence and professionals can miss things.

</comment></comment></comment><comment> EZ-E Why do Apple, Google and major IT companies seem so much interested by our health suddenly ? What are they planning to do with the data ? Just selling it ? (life insurance companies ?)

<comment><USER7> > _Why do Apple, Google and major IT companies seem so much interested by our > health suddenly ?_

I have come to the conclusion that some of the tech visionaries recently are actually motivated, on the bottom-most level, by doing Good - in the old- fashioned moral sense.

As far as I can tell, Elon Musk is firmly in this category. Recently I've started to believe that Larry Page and Sergey Brin also belong here. Sure, they have companies and profits and board meetings to worry about, and of course they don't mind having their egos pampered a bit, but their prime motivator appears to be improving the future of humanity on a large scale.

Not everyone is like that, however. In fact, the list is very, very short. I'm only willing to put these three names on it, so far. Most of the others are energized by more mundane reasons, and of course there's also a minority of plain old villains out there.

<comment><USER18> You've named three unbelievably wealthy people who you believe are motivated to Do Good. Which is Iron Man? Which is Batman? And more terrifyingly, which is Ozymandius?

<comment><USER7> I think we're clear (or at least the press is) on who is Iron Man in this bunch.

Batman is still pretty cool, in my book. I've been around the block, and I've learned that to ask 100% kink-free moral perfection from human beings is a fool's errand. Stomp a few people's faces for the eventual greater good is fine, if you don't do it too much. Not sure if I could find an equivalent in real life, though. Maybe Bill Gates? No, he's more like the ruthless merchant turned philantropist.

Ozymandias is some famous media moguls, along with a bunch of finance tycoons for good measure. It's a far more popular archetype.

</comment></comment></comment></comment><comment><USER19> Including my mom in the last 10 years I've lost 4 female members of family to cancer. This product is revolutionary no doubt and I am very excited about it. I believe Google will face an uphill task as there are lots of things to explain to the consumer before taking this full stream.

1\. Will these nano particles stay in my blood stream forever or do I have to inject them in my body periodically. What are its side effects?

2\. The wristband on my hand communicating with these nano particles in someway connects back to the Google's network and now along with my emails and pics Google is tracking my health and my DNA. I mean I can turn off my phone and not use my email but I can't turn off my body. When combined with the DNA this project has the potential to provide an RFID to each and every human being.

Ignore my ignorance I am not the expert here just curious about all these possibilities.

</comment><comment><USER20> This sounds great and I hope they're successful.

That said, what's the point of pre-announcing stuff like this, when it's at such an early stage? Is it just goodwill?

<comment><USER21> From this article[1]:

        There's still a million crazy things that happen with
        people, and there's a long journey to put medicines into
        people, and it has to be done in the open because we're
        going to do experiments— people will be wearing these
        devices at our Baseline Study.

And:

        Yeah. That's part of the reason we had to talk about this.
        There's a pretty substantial body of patents that describe
        what we're talking about in great detail that will be
        publicly noticeable in the next month or so.

[1]: [https://medium.com/backchannel/were-hoping-to-build-the- tric...](https://medium.com/backchannel/were-hoping-to-build-the- tricorder-12e1822e5e6a)

</comment></comment><comment><USER22> Honest and serious question:

Will this compete or compliment the notion that using canines in the cancer / disease detection process is an avenue for further study?

Re:

[http://well.blogs.nytimes.com/2014/09/10/training-dogs-to- sn...](http://well.blogs.nytimes.com/2014/09/10/training-dogs-to-sniff-out- cancer/)

<comment><USER23> Most likely compete. Google excels at organizing information by means of symbolic processing/manipulation. Dog "know-how" is opaque enough to mix well with existing expertise.

Unless they go meta and get in the dog training business, effectively using dogs as black box components in their wider system.

</comment></comment><comment><USER24> I imagine "killer app" is no longer the understatement when your next wearable actually actively monitors your health like this. I think the privacy concerns can be worked out, and they shouldn't slow down the research.

Seeing the headline, I thought it would be an article monitoring passive signals to calculate risk scores, so I was really happy to see biochemistry. I think Google pouring funds into this kind of research will lead to some awesome advancements. It's easy to imagine a recurring revenue stream from a device like this which adds years to your lifespan. Owning a device like that actually reduces the cost of your life/disability insurance because anything that does go wrong gets discovered earlier with better outcomes. Actually, you could pay for the device out of those savings alone.

It is amazing to think what the feature comparison chart for wearables in the next decade will look like.

</comment><comment><USER25> Nano-bubbles and particles have been used since a long time to diagnose diseases and enhance the quality of ultrasound analysis (contrast agents). You can also link an antibody on their surface to target them against a particular protein or reveal a zone of interest (e.g. a tumor revealed by a specific biomarker). Nano-bubbles are even use to destroy adjacent tissue on purpose (sonoporation).

Usually such particles are constructed via a mix of lipids and have a very short life time in the blood stream. I wonder how they're going to keep them alive in the blood stream for what seems to be a very long time and their design regarding toxicity.

</comment><comment><USER26> Reading the story all I can think of is the possibilities. Suspend the particles into and disperse with aerosol in public places and then scan for indicators you want as they walk through or by detectors. You could set it all up to report to individuals anonymously, but the idea of what a future of health care might be should include a system which requires no action on the patients.

The privacy concerns could be immense or moot, but many would trade for the convenience

</comment><comment><USER27> Sounds pretty elaborate - perhaps if we could just work on a lower cost almost do it yourself access to an MRI or ultrasound detection as well as many other troubles in the body could be detected... But this is health care 7 billion opinions very few solutions beyond reducing pain and cutting stuff

</comment><comment><USER28> That would pretty much cover the rest of the population, as far as getting people to wear a smart watch.

</comment><comment><USER29> Specially trained dogs are able to sniff out stuff like cancerous cells or if a kid needs his insuline.

Always wondered why we cannot build an artificial nose like that. Does anyone have any insights into this topic?

<comment><USER30> the cancer sniffing dog thing appears to be a case of Clever Hans

<comment><USER29> Did some quick googling. Seems like research so far supports the claim. [http://en.wikipedia.org/wiki/Canine_cancer_detection](http://en.wikipedia.org/wiki/Canine_cancer_detection)

Is there any research, with different results, missing from the Wikipedia page?

</comment></comment></comment><comment><USER31> World's largest advertising company developing cancer and heart attack detector. Think of the great AdSense and AdWords lead generation opportunities coming. It's like printing money.

<comment> vertex-four They've generally been quite good at refusing to let advertisers target on sensitive subjects. It's probably a legal minefield in most developed countries, and it'd be a PR nightmare if there were any sort of adverse effects.

"We won't associate with an individual's cookie any audiences considered sensitive, such as those based on race, religion, sexual orientation, health, certain financial information, and others."[0]

[0] [https://support.google.com/adwords/answer/2497941?hl=en](https://support.google.com/adwords/answer/2497941?hl=en)

</comment></comment><comment><USER32> Hmm... Anyone seen the show "Continuum"? You should. It's on Netflix. And would instantly raise some red flags for this.

</comment><comment><USER33> I read this as "cancer and heart attack deflector," and it seemed a lot more awesome than it really is. Oh well.

</comment><comment><USER34> Google is uniquely positioned with the amount of data it has to uncover strong correlations between behavior and disease.

</comment><comment><USER35> why are they doing that - just because they can and it's a great headline?

if i were a google shareholder i'd rather have them return excess money than go on those pet / "greenwashing" projects

<comment><USER24> They say this is how they are going to run the business in the prospectus. They are fully entitled to directing their own R&D efforts.

</comment></comment><comment><USER36> Marketing, competition, new features, bugs, expoits, evolution. These things could go viral. Literally. A hard robots.txt equivalent cellular protocol might be needed to protect body parts from the gaze of Grey Google.

</comment><comment><USER37> Google is a developing cancer and heart attack...

</comment><comment><USER38> I find the idea of potentially handing Google, a firm whose core model is selling ads and generalized user data, the details of my biochemical makeup quite troubling.

<comment><USER39> Honest question: Why?

<comment><USER38> >Honest question: Why?

Why should an advertising company get access to this data in the first place? What do they intend on doing with it?

Selling us adverts based on a combination of our biochemical data, or the state of our health, coupled with our search terms that might indicate we have concern over one area or another?

Being able to help the medical sales industry target us more efficiently? As in "X user has Y indicators in their health data, therefore they would be a prudent market to advertise Z to"?

<comment><USER39> Nobody is saying they _should_. The data is yours, and if you don't get any value from giving access to it, then don't.

My question was: Assuming you get something in return (better health, or longer life, for example), what are the factors you are weighing against it?

Note in particular that I'm not saying there aren't any. I'm just challenging the knee-jerk statement of "my body's bio-chemical data is super private and sensitive so nothing in the world can be worth giving access to it", without any actual argument for it.

</comment></comment></comment></comment><comment><USER40> Google is developing cancer

[long inhale]

and heart attack detector</comment>


Close-Up View of DNA Replication - <AUTHOR> https://www.ucdavis.edu/news/close-view-dna-replication-yields-surprises <comment><USER2> For anyone interested in the molecular process of DNA replication, here's a pretty cool video that explains what happens at the protein level. It's always amazing to watch what is in practice a molecular-sized machine:

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

<comment><USER3> I'm looking at this video and can't stop thinking: "Who created this process?" With all advances in technology and know-how we are not able to put such sophisticated process together... And it is present in EVERY living creature and happens millions of times in every body... So how this process came into existance?

<comment><USER4> And thus, the argument from incredulity was born, with a dash of personification.

<comment><USER5> Here's the argument from Phys.org: [https://phys.org/news/2013-04-law-life- began-earth.html](https://phys.org/news/2013-04-law-life-began-earth.html)

<comment><USER4> Huh? That's one self-described "thought experiment" by two scientists that attempts to fit Moore's law (you know, governing CPU speeds) to evolution. It doesn't fit, surprise. This is after they arbitrarily define "genetic complexity".

That's not _the_ argument from Phys.org which is just a online news organization, anyway.

</comment></comment></comment></comment></comment><comment><USER6> Something I've never understood is how the nucleotides arrive to be included in the DNA strand. These animations always just show them appearing in perfect sequential order when they're needed, which is of course not what happens.

How are they delivered to the polymerase in the first place? How do they "know" where to be?

Are there just so many of them in the cytosol that through sheer numbers, there's enough random chance they'll just shuttle into place when the polymerase needs them?

<comment><USER7> I wrote a blog post a few years ago explaining how molecules get to the right place at the right time. The short answer is that cells are nothing like the nice, peaceful animations. Cells are extremely crowded and things move extremely fast. Glucose molecules, for instance, move around cells at 250 miles per hour and collides with something billions of times a second. An enzyme might collide with a reactant 500,000 times a second. And proteins can spin a million times per second. So as you suspect, by random chance molecules are in the right spot very frequently.

[http://www.righto.com/2011/07/cells-are-very-fast-and- crowde...](http://www.righto.com/2011/07/cells-are-very-fast-and-crowded- places.html)

<comment><USER8> Thank you for writing this. I used to wonder how flies have such terrific reaction times and whip around the air with insane agility. And then I wondered if we are just seeing them in fast forward, due to the relatively slow clock in our heads. I imagined it was why they had such a short lifespan of just several days. And I imagined them seeing us as glacially moving statues—"man this guy hasn't moved in years!"

Reading your description of cells as moving imperceptibly fast only fills me more with this sense—that we are very slow moving giants, waiting on the billions of "years" of inner machinery time to tick us forward ever so slowly.

<comment><USER9> Time for you to read "Dragon's Egg", a hard sci-fi book about a civilization that evolves on a time scale far shorter than humans ultimately leading up to interaction with humans and this civilization. Awesome book which explores different time scales.

[https://en.m.wikipedia.org/wiki/Dragon%27s_Egg](https://en.m.wikipedia.org/wiki/Dragon%27s_Egg)

<comment><USER10> Dude, that was awesome. Thanks a lot!

I haven't had a book this good in some weeks. Cheers!

</comment></comment></comment></comment></comment><comment><USER11> I can feel there is something really interesting here but the writing, title and explanation here seems to be poor. The surprise here is the random starts and stops as well as 10X speed difference in the DNA replication process. Wouldn't it be more surprising that these processes run at the same speed?

"...started watching individual DNA strands..." I'm wondering how important the visualization and nature of "filming" helped to form the idea or prove the hypothesis that replication is a async process. I didn't quite gather which is more impressive, the filming or the discovery.

"Sometimes the traffic in the next lane is moving faster and passing you, and then you pass it. But if you travel far enough you get to the same place at the same time." also doesn't quite make sense to me as the video clearly shows no queuing structure as seen in real life traffic, and there is no real hypothesis to explain the sudden stops and starts.

</comment><comment><USER12> > "It's a real paradigm shift, and undermines a great deal of what's in the > textbooks," he said.

Sorry, but is this really that new? I've never been taught that the DNA strands coordinate with each other while replicating, so it seems quite possible that synthesis of each strand can be independent of each other.

<comment><USER13> The "paradigm shift" is referring to the "stochastic" nature of replication, which apparently was not known before.

<comment><USER14> i was taught all the things they're saying in this press release ~20 years ago in biochem class.

</comment></comment></comment><comment><USER2> > "We've shown that there is no coordination between synthesis of the two > strands. They are completely autonomous," Kowalczykowski said.

Couldn't that be the unintended effect of doing things in a flow chamber?

</comment><comment><USER15> This is amazing. I can't wrap my head around the fact that some brilliant people discovered this long back. Scientists and Physicists are so talented! And I can't center a <div> without googling. Sigh...

<comment><USER16> text-align: center

align: center

<comment><USER17> only works horizontally :/

<comment><USER18> This says more about the talent of the designers of the CSS spec.

</comment></comment></comment></comment><comment><USER19> Hmm…possibly there's some other process going on during those "slowdowns" that we haven't observed yet?

<comment><USER20> I agree, that's part of the import here.

</comment></comment><comment><USER21> My mind always boggles at the sophistication of this little machinery, and what forces drove random chemicals into the first primitive forms of encoding and reproducing heritable traits subject to selective pressure. The bootstrapping of evolution.

</comment><comment><USER22> Not sure if the apparent stop start observation, and also one strand sometimes getting synthesized while the other isn't would actually occur in-vivo. This is a pretty cool technology but a heavily artificial in-vitro system at the end of the day.

</comment><comment><USER23> \- "Almost all life on earth is based on DNA being copied, or replicated" \- Can anyone tell me what they are referring to here? (life on earth that isn't based on DNA)

<comment><USER24> RNA I believe. ( Which I only existed at one time, in theory? Or some people think viruses count as life )

<comment><USER23> i did spend an embarrassing amount of time trying to find an example of RNA life after reading your initial reply lol.

I suppose viruses do count as 'life' in some sense, so fair enough, thanks for clearing that up.

<comment><USER14> viruses don't count as life. they have no metabolism (but satisfy the other requirements).

</comment></comment></comment></comment><comment><USER25> I really appreciate science journalists who can explain accurately and clearly in this manner. Good job.

</comment><comment><USER26> As someone who works in the DNA analysis software industry...

#neat

</comment><comment><USER27> Most explicit porn ever!

</comment><comment><USER28> I have no idea what I'm seeing here.

I don't doubt what they are saying, but that looks nothing like the models of DNA that are used as eye candy in movies and such.

<comment><USER29> It doesn't look like DNA models you are used to because a microscope that would give you that level of resolution does not exist.

Even in the best images that exist, all you are going to see are little bits that look like string.

<comment><USER28> I guess I'm just struggling to see how the animation maps to the DNA or how the scattering of dots becomes a double helix.</comment></comment></comment>


Stop Using Linked Lists - <AUTHOR> http://highscalability.com/blog/2013/5/22/strategy-stop-using-linked-lists.html?utm_source=feedly <comment><USER2> On a related note, cache alignment is one of the reasons Clojure's vectors (log32 insertion, access, and deletion) and linked lists (o(index) insertion, access, and deletion) have unintuitive performance characteristics. For instance, constructing lists of either type takes roughly the same amount of time for big lists:

      user=> (with-progress-reporting (bench (into '() (range 100000))))
                   Execution time mean : 9.293932 ms
          Execution time std-deviation : 269.771284 µs

      user=> (with-progress-reporting (bench (into [] (range 100000))))
                   Execution time mean : 9.882163 ms
          Execution time std-deviation : 359.744662 µs

And with smaller lists, building vectors is ~30-50% slower.

      user=> (with-progress-reporting (bench (into '() (range 24))))
                   Execution time mean : 2.483705 µs
          Execution time std-deviation : 71.302962 ns

      user=> (with-progress-reporting (bench (into [] (range 24))))
                   Execution time mean : 3.349080 µs
          Execution time std-deviation : 114.007930 ns

However, _traversal_ is significantly faster for vectors, because you can pack 32 references into a cache line at a time. Here's a decent-sized list:

      user=> (let [x (apply list (range 100000))] (bench (reduce + x)))
                   Execution time mean : 8.586510 ms
          Execution time std-deviation : 80.923357 µs

Vs a comparable vector:

      user=> (let [x (vec (range 100000))] (bench (reduce + x)))
                   Execution time mean : 4.564553 ms
          Execution time std-deviation : 135.795328 µs

Traversing small lists:

      user=> (let [x (apply list (range 24))] (bench (reduce + x)))
                   Execution time mean : 2.041794 µs
          Execution time std-deviation : 18.752533 ns

Vs small vectors:

      user=> (let [x (vec (range 24))] (bench (reduce + x)))
                   Execution time mean : 1.051182 µs
          Execution time std-deviation : 10.413211 ns

[http://blog.higher-order.net/2009/02/01/understanding- clojur...](http://blog.higher-order.net/2009/02/01/understanding-clojures- persistentvector-implementation/)

<comment><USER3> Benchmarking on the JVM is tricky, beyond pure algorithmic efficiency (assuming all memory accesses are equal), there's cache effects, JVM heap and GC effects and the usual warmup/inlining concerns of benchmarking. On page 551 of the excellent scala staircase book (2nd edition[1]) there's a collection efficiency table w.r.t. head/tail/indexing/insert, but that's a jumping off point (sorry, I can't find an online version of the table).

[1] <http://www.artima.com/shop/programming_in_scala_2ed>

<comment><USER2> These benchmarks were taken with Criterium, which performs JIT warming, GC purge, final GC, retains results for each run, isolates outliers, etc.

</comment></comment></comment><comment><USER4> I don't understand all the hate about the post, one of the referenced articles is actually very good and gives a quite compelling case (maybe it should have been submitted instead):

[http://kjellkod.wordpress.com/2012/02/25/why-you-should- neve...](http://kjellkod.wordpress.com/2012/02/25/why-you-should-never-ever- ever-use-linked-list-in-your-code-again/)

It shows that linked lists are slower than vectors for real-world-like scenarios even for those cases where the asymptotic complexity for linked lists is lower. Seems that that modern CPU architectures have changed so much that our theoretical models diverge further and further from reality, I think this is pretty interesting.

<comment><USER5> I do not think our theoretical models diverge from reality; the theoretical models are based on how the performance relates to the size of the input, and remain valid even if you have a very fast computer. What modern architectures have done is to change the constant factors a bit; that just raises the threshold for problem sizes, but it does not eliminate it.

Sure, there are cases where asymptotic analysis can be dismissed. Matrix multiplication comes to mind: the fastest algorithms have impractically large constant factors. Usually, though, asymptotic analysis does matter, because it is often the case that input sizes will grow unexpectedly.

<comment><USER4> This has nothing to do with simply having a "fast computer", it would be all fine if we just used 486s clocked at 10Ghz, but we don't, the changes in the architecture of CPUs do indeed make the theoretical model more diverged from reality, because it presupposes a lot of things, like that every instruction takes the same time to execute, also implying that instruction execution times are independent, that one instruction gets executed at a time, etc. If those assumptions do not hold you cannot assume the factor is really constant, and even if it were so, you cannot dismiss this difference indefinitely on this ground, if on datasets of the size commonly encountered in practice the algorithms with a larger asymptotic complexity start outperforming the ones with a smaller one. For matrix multiplication this was known for years, for linked lists it is a relatively new development that came with larger and faster CPU caches etc.

<comment><USER5> Except that the theoretical model is not affected by any of the things you mentioned. The existence of caches, branch prediction, instruction reordering, parallel execution, etc. does not chance as problem sizes change. If your inputs become large enough, you will reach the upper limit of your CPU's ability to speed up execution with those features. In the limit, the asymptotics still matter, and experience has shown that the limit is not at all far-fetched in most cases.

What makes matrix multiplication an exceptional case is that the constant factor on the best known algorithm is so large that we do not know how to build a computer with enough memory to store a problem large enough to overcome that constant. That is not the case with this analysis of linked lists; all one can say is that the data sets chosen in that _particular_ article (possibly representative of the most common data sets) are not big enough. One can certainly store a large enough data set to overcome the advantages arrays have, and so the only real question is, "Is it possible that the inputs will be so large?"

Maybe the answer is truly, "No, that is unlikely." I am skeptical, though, as there are not many cases where such statements can be made. Even software written for embedded systems that target specific products is likely to be repurposed for new systems with different inputs. Even researchers, who write software for the particular datasets sitting on their hard drives, often re- use their code in future work. There are "border" cases, like integer multiplication, but typically libraries will just select the best algorithm for a given input size (e.g. for multiplication, you'll probably only see FFT methods applied above a particular threshold). Perhaps linked lists are now a "border" case, but all that would mean is that we need to use abstract "sequence" operations that dynamically choose particular implementations to use as their sizes change.

<comment><USER4> [http://en.wikipedia.org/wiki/Asymptotically_optimal_algorith...](http://en.wikipedia.org/wiki/Asymptotically_optimal_algorithm#Formal_definitions)

 _Sometimes vague or implicit assumptions can make it unclear whether an algorithm is asymptotically optimal. For example, a lower bound theorem might assume a particular abstract machine model, as in the case of comparison sorts, or a particular organization of memory. By violating these assumptions, a new algorithm could potentially asymptotically outperform the lower bound and the "asymptotically optimal" algorithms._

See also:

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

[http://en.wikipedia.org/wiki/Random-access_stored- program_ma...](http://en.wikipedia.org/wiki/Random-access_stored- program_machine)

<http://en.wikipedia.org/wiki/Cache-oblivious_model>

etc.

As far as I know all asymptotic analysis has to be done using some abstract machine model.

<comment><USER5> Sure, but how do modern architectures not fit into the RASP machine model? You can view the cache contents as being _part_ of the state (rather than the memory); you can similarly view instructions as being part of sequences, so that a single instruction can mean different things depending on the state from which it is fetched. Other modern features can be similarly approached (with the exception of CPUs whose behavior depends on environmental factors like temperature, but that is an edge case).

Really, if you doubt that the RASP model is appropriate for modern architectures, you can test it (a typical exercise in an algorithms course) -- see if, as the input size grows, the timing follows the asymptotic analysis. That is basically what the article you linked to does, and the results are not all that surprising -- where things are linear time in theory, they are linear time in practice; where they are quadratic time in theory, they are quadratic time in practice. It is worth pointing out that in all but the last example, the list and vector operations had the _same_ complexity (because of the linear search), so it was really a comparison between constant factors.

<comment><USER6> Asymptotically, sure, you're right. Constant factors are often important in practice, and simple cost models (e.g. ones that don't model cache locality) will no longer give you a decent estimate of constant-factor differences in performance between algorithms.

I think the issue here is that, in the past, with shallower cache hierarchies, models that assumed a constant cost per memory access would maybe be off by smallish factor (I don't know, maybe 50%).

However, now memory access is frequently the limiting factor for an algorithm, and there can easily be an order of magnitude in variation between the average memory access latency for different algorithms (i.e. cache-smart versus cache- dumb).

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It seems that often articles like this overstate their case to the point that it really detracts from the message.

There is a valid point, that a naive analysis of linked list vs. static array based on intro CS course descriptions of their properties isn't a good model for what is going on in a modern system.

The real lesson is: if you want to achieve high performance you simply must understand the impact of things like cache localization, vectorization, hardware prefetch, pipelining etc., and how your data structure operation will interact with them.

"Never use a linked list" is a silly lesson to take from this though. "In these situations, linked lists might not perform as well as you expect" is more like it.

"Use the right data structure for the job" is still as good advice as it ever was.

<comment><USER8> Exactly. Also, pointers are just an implementation detail of linked lists. You can implement an array based linked list and avoid "scribbling all over memory", which really is a valid concern raised in the article.

<comment><USER9> What exactly would an array based linked list be but either an array or an array deque? These things have names for a reason.

<comment><USER5> Instead of pointers, you would store an index in the array of nodes:

      struct node {
         void * data;
         uint32_t idx_next;
      };

You are still dereferencing pointers, of course, but you have better locality, even after doing a lot of insertions and deletions.

<comment><USER10> It's even better with intrusive containers. As an extreme case, let's say we need a collection of 24 bit RGB triplets:

        struct node {
            uint8_t r, g, b;
            uint8_t idx_next;
        };

Of course, a contiguous array uint8_t[256][3] might still be faster.

</comment></comment></comment></comment></comment><comment><USER11> What stupid advice. Linked lists (and trees formed from lists) are a fundamental functional data structure. They have tremendous expressive advantages in functional code where operating on the head and the rest of the list leads to clear expression of an algorithm, and easy sharing of sub-parts makes certain other algorithms much more elegant.

An example is maintaining the lexical environment as you're compiling a programming language. The first response might be to use something like a hash table. But then how do you handle shadowing (where an inner block shadows a variable of the same name in an other block)? A much cleaner way is to use an association list that's implicitly maintained as you recurse over the AST.

E.g. in psuedo-Python:

        def parse_let(form, environment):
            (name, value) = parse_declaration(declaration_part(form))
            return parse_body(body_part(form),
                acons(name, value, environment))

For those unfamiliar with Lisp, "let" introduces a new name bound to the value of an initializing expression, which is only in scope for the body of the "let" construct. Assume here that we're generating code from an AST and that the return value of a parse function is the register number where you can find the result of the expression, and the lexical environment maintains a mapping from a variable name to the register where that variable can be found. Or we could be creating an intermediate representation and the lexical environment maintains a mapping from a name to an IR node. Or whatever.

Here, "environment" is the association list. Assume that "acons" is a Python function that adds a pair of (key, value) to the front of a linked list. Note how the list is never explicitly mutated, it is maintained implicitly by passing a new value for "environment" as you recurse down. The beauty of this is that entries are removed from the lexical environment implicitly as parsing functions return, and also that "environment" is a purely functional data structure. You can stash away "environment" in say an IR node and it will always refer to a snapshot of the lexical environment for a given AST node, even after other nodes are parsed or the current function returns. This is non-trivial with say a hash table. Storing a copy at each IR node would eat memory. With a linked list, sharing of sub parts falls out for free.

Also, look at the Linux kernel sometime. It uses linked lists all over the place. Your malloc() implementation likely keeps a set of segregated free lists maintained as linked lists. They do this because they avoid ever traversing the list completely. They just operate on the head/tail.

<comment><USER12> Consider that the source is High Scalability, a blog that focuses on how orthodox methods are inadequate for 1-10M concurrent connections and how different methods are being employed to reach these lofty goals, I think the advice is pretty spot-on.

It's important to consider that if your objective is scalability and performance, then the article's advice is appropriate. The article's title ought to read "Stop Using Linked Lists if you care about High Scalability", but I attach the dependent clause on many titles I read from that site.

<comment><USER11> I'm sure the Linux kernel developers care about scalability and performance. Count how many linked lists you see in the kernel code. See: <http://lxr.free- electrons.com/ident?i=INIT_LIST_HEAD>.

<comment><USER13> I'm sure you will find strlen and linear searches too. It's more likely that absolute performance wasn't necessary for those cases, or memory usage with linked lists is better than a more complex data structure, or maybe even that linked lists were easiest for C developers.

<comment><USER11> Linked lists are used pervasively in performance critical parts of the code (e.g. the scheduler, the VM, etc). Linked lists just happen to have very suitable performance characteristics for the kind of tasks that happen often in a kernel. E.g. say you keep queue of IO buffers that have pending operations on them. You get an interrupt and the driver gives you back a pointer to the IO buffer it just filled. You want to copy that data out, and them remove the IO buffer from the pending queue and add it to a free queue. In this case, you'd almost certainly rather use an (intrusive) linked list rather than maintaining these queues as arrays.

</comment></comment></comment></comment></comment><comment><USER14> There's been some discussion on HN in the last few days about negativity. If there's one thing that inspires negativity, it's hearing categorical statements like "ALWAYS do X," or "Y is NEVER true" when the listener has specific experiences that contradict this.

We all come at computing from different perspectives. The perspective of a JS developer is very different from the perspective of an OS developer. "Rules of thumb" that make sense in one scenario may be completely wrong in another. Different programmers are faced with different constraints, different performance profiles, and different relative costs (which can lead to different tradeoffs).

If you're tempted to make a categorical statement, maybe it's better to first consider whether your statement is as universal as you think it is.

</comment><comment><USER15> This is not good advice if you need your list to have unbounded size and want it to be lock-free. Growing an array and copying all the elements over is very expensive in a thread-safe scenario. If you use a linked list, however, you can implement all the operations without using any locks at all.

(Linked lists are what we use for our channels in Rust, and as a result they're extremely fast: in the new scheduler they're totally lock-free except if the task is sleeping, which we can optimize to be lock-free later. They have unlimited size, which helps prevent deadlocks.)

<comment><USER16> Very cool. What kind of lockfree linked lists? Did you work from one of the papers on the subject?

(Searching "rust lockfree" reveals a feature request for a lockfree malloc. I happen to have one of those, but the reality is that synchronization will probably not be your bottleneck.)

</comment></comment><comment><USER17> I'M ARGUING AGAINST CONVENTIONAL WISDOM! PLEASE GIVE ME ATTENTION!

Use linked-lists in situations where you need fast insertion and lookup time isn't as important. Don't use linked-lists when lookup time is important. Don't make fallacious claims supported with misguided and incomplete examples.

<comment><USER18> > _I'M ARGUING AGAINST CONVENTIONAL WISDOM! PLEASE GIVE ME ATTENTION!_

I don't think it's like this, it's true that the article is a bit harsh, but it contains a lot of references that support the claim.

Additionally I also came to the conclusion that plain linked list are virtually always slower in practice because insertions in vector is amortized constant time, or because you can use better more local structures like deques, or because hash tables are always an option, and so on. Also check Soustrup's vector vs list slide in the presentation by linked by chmike's in this thread it's pretty demonstrative.

</comment></comment><comment><USER19> Stop Using Linked-Lists (in areas where linked-lists are the wrong structure to use)

Edit: I should note this article's advice is really good advice if your focus is performance.

<comment><USER20> More: "Linked lists are much, much slower than you think they are and should not be used in performance-sensitive code." That fact isn't remotely obvious to most hackers, and simply brushing it aside as an area where linked lists are "wrong" is missing important details.

<comment><USER21> Even in performance sensitive code, linked lists might be the right way to go. If you need to store an unknown amount of data, a resizable array probably does amoratize to a better performance than linked lists. But, all of the 'slowness' happens at the same time, so it might be worth slowing down the average case to avoid the worst case. The most notable examples I can think of are video games where FPS is king, and kernels, where you always want to exit quickly.

Linked lists can also work better in limited memory environments because, with the overhead of 1 pointer per element, you can make use of fragmented memory.

<comment><USER22> Or something between the two: "Unrolled linked list": In computer programming, an unrolled linked list is a variation on the linked list which stores multiple elements in each node. <https://en.wikipedia.org/wiki/Unrolled_linked_list>

</comment></comment></comment></comment><comment><USER23> The link to the article about "Starcraft crashes because it uses linked lists" seems underhanded. That article talks about intrusive lists and why they are useful, and what the down sides are. The actual crash seems to be related not to the use of a linked list at all, but just lack of shared data synchonisation which can happen with many other data structures.

</comment><comment><USER24> True story. I was working for a property/casualty insurance company in South Carolina. There was a local community college that had programming, and most of the "programmer analysts" at this place went there and took the intro to C course, which included writing a doubly linked list. It also had the notion that not writing your own code was "cheating."

The application I was working on had something like 500 separate implementations of a doubly linked list, each of which was used to support exactly one collection, and each of which involved hours of coding and debugging. The company didn't care, as client companies were billed by the hour. One of the client companies had programmers who were horrified at this and their programmers introduced an adaptable linked-list library called "SuperLink." It was accepted as a "modification," incorporated into just the one implementation, then forgotten.

</comment><comment><USER25> At page 45 of this presentation of Soustrup, [[http://ecn.channel9.msdn.com/events/GoingNative12/GN12Cpp11S...](http://ecn.channel9.msdn.com/events/GoingNative12/GN12Cpp11Style.pdf)], he shows benhmark comparison between linked list, preallocated list and array for insertion and deletion of small element values in list up to 500 000 elemnts.

Arrays are beating linked list.

<comment><USER21> That example involves inserting (and deleting) elements at a specific index, which means you would have to traverse (on average) half of the linked-list each time.

Generally, when I work with linked-lists (excluding functional programming) I only delete elements after I already have a pointer to them for something else. Similarly, I generally do not care about the order of elements, so I can either insert a new element at whatever index my cursor happens to be at, or append them to the end.

<comment><USER25> These are specific use case. Indeed in some cases lists are more efficient than arrays. The advice to use arrays instead of linked list is a rule thumb. Not all programmers are still sucking their thumb. ;)

</comment></comment></comment><comment><USER9> I think a lot of people are missing the point, and that's probably at least in part because of the bold claim of the title. The point is that some of the (very most common) conventional wisdom about the appropriateness of linked list has become outdated and wrong in the age of very fast local cache.

It really does mean that in a lot of cases that, say, Knuth's books would have suggested you use a linked list, you really probably shouldn't any more, even if it doesn't really mean you never should.

</comment><comment><USER26> From the perspective of computer architecture, the author provides what look like -- on their face -- good arguments. They quote from Aeter Suleman, who says things like: "they throw off hardware prefetching", or "they reduce the benefit of out-of-order execution".

These may have been true on machines of the past, but these are no longer true on modern systems. With the advent of trace caches and runahead execution [1], linked lists are _really_ no longer as painful as they once were. (Indeed, even back in the day, Alpha had low-cost "explicit" runahead-like semantics, where the programmer could specify other work to do while waiting for DRAM; this was usable to accelerate linked-list traversal.)

[1] <http://users.ece.cmu.edu/~omutlu/pub/mutlu_hpca03.pdf> (disclosure: I worked closely with Onur at one point; his Ph.D thesis introduced runahead. I may be excessively biased in favor of that technique :-))

</comment><comment><USER16> The correct way to do linked lists is to store the list traversal fields next to the data. In C, this would mean storing next/prev pointers inside of the structs which will be placed on lists.

In light of this, the things in the OP are often non-issues because you'll need the data in cache immediately after the list operation anyway (or during the traversal, for O(n) operations like list_find). In fact, vectors of pointers are worse for the hardware because you'll need to load in _more_ cache lines than with lists, in order to traverse the array.

Lists aren't clearly the better option when the data will need to live exactly as long as the data exists in the container. In this case, you can store the data itself in a vector's backing array (and so the data will be invalid as soon as it's removed from the vector).

<comment><USER27> Who the heck puts the payload into a separate allocation?

I'm pretty sure I've never seen such an implementation. Not once. I could imagine seeing something like that in textbooks where they use graphical diagrams to illustrate how a linked list works but who would actually implement it like that -- I don't know.

The canonical way is to do:

      struct listnode {
        struct listnode *next;
        struct listnode *prev;
      };

      struct your_own_data_node {
        struct listnode node;
        int x, y, z;
      };

which ensures that you can have a set of functions that operate on struct listnode * and you can use them for all of your lists.

<comment><USER16> I wouldn't call that canonical. You can take a further step, as in the Linux version that someone posted below:

<http://kernelnewbies.org/FAQ/LinkedLists>

</comment></comment></comment><comment><USER28> In performance-critical code, this is well known. Also, since the 64-bit days, storing linked lists also has a significant overhead over arrays due to the additional storage requirements of the pointers, which means you fit less in cache which compounds the problem even more.

</comment><comment><USER29> The article( and its referenced article) recommends against using linked lists because they are inefficient on modern processors (due to cache misses).

However, there is a better solution than throwing away a powerful and expressive data structure. Rather than linking individual data elements, instead link blocks of consecutive elements.

This hybrid approach takes full advantage of cache locality and it minimizes the memory overhead of storing both the links and the data.

This is the approach used in Python's implementation of deques: [http://hg.python.org/cpython/file/85c04fdaa404/Modules/_coll...](http://hg.python.org/cpython/file/85c04fdaa404/Modules/_collectionsmodule.c#l4)

</comment><comment><USER30> This is awful advice which is based on a complete misunderstanding of the use cases of linked lists. Linked lists apply in situations when you can't place things in arrays (because they are too large to copy, or because there will be pointers maintained to them).

The author makes much ado about locality of reference and cpu friendly layout without understanding that those things are irrelevant because this is a data structure to use when indirection is _required_.

It always amazes me that such simple data structures can be so poorly understood.

</comment><comment><USER31> I feel like this could have perhaps mentioned the cases where one should use linked lists.

Is a simple queue still implemented as a linked list? That is all I ever seem to use them for.

<comment><USER32> A queue would be an excellent time to use a linked list.

I don't understand the point of making a claim like this about a data- structure. The most fundamental thing in data-structures is that there is a time and a place for using each one. No data-structure is inherently 'better' than the others.

<comment><USER33> Based on the disruptor paper (<http://disruptor.googlecode.com/files/Disruptor-1.0.pdf>) linked lists make poor queues also. Ring buffers backed by arrays are much better.

<comment><USER32> Very interesting, but I feel there is a difference of need here.

You're right...there a Ring buffer with an array is better, but for average programmers a linked-list makes a damn good (maintainable, easy, understandable, and pretty quick) queue.

</comment></comment></comment></comment><comment><USER34> Mmmmmeehhh. Profile it first.

</comment><comment><USER6> This is pretty reasonable advice. There was a time when linked-lists didn't have such a massive performance disadvantage compared with more contiguous data structures, but that time has passed and I'm not sure that the programming community is fully aware of it (certainly you wouldn't be explicitly told it in most CS programs). Memory efficiency is also often terrible on 64-bit machines, especially for doubly-linked lists.

Sometimes they're the right data structure, but I've definitely come across programmers who want to use a linked list for everything, even in code where performance is important.

Edit: the general advice that you should avoid linked lists for performance reason is good. The idea that you should _never_ use them I just took as additional trolling for page views.

</comment><comment><USER35> I was recently working some data structures in C++ where I needed to have tree-based structures and sustained performance. The compromise that I hit on was to allocate all of the nodes of a tree out of an std::vector. This allowed me the flexibility of tree-based structures together with all of the locality of reference that I needed. As the tree grew, the vector would resize and move, but the amortized average cost of that is directly proportional to the size of my data structure.

I offer this in case a similar compromise might be useful for someone else. (My guess is that it is probably standard for people who need to know this sort of stuff. I'm just not usually someone who needs to know this sort of stuff.)

<comment><USER28> This is used a lot for things like acceleration structures in 3D graphics - you also get the benefit of being able to store an uint32_t offset instead of a 64-bit pointer, fitting a bigger tree in memory/cache.

<comment><USER35> I used that trick as well. :-)

</comment></comment></comment><comment><USER36> I've been working on an application for a card game and I have been considering the implications of using a linked list for the deck structure. I just don't see how using an array would make sense for a deck of cards. I need the ability to constantly grow and shrink the deck (this is for Yugioh so cards would get put back into the deck often). I did consider using an array but it seemed to be more trouble than its worth considering the need to remove cards from random locations in the deck. My question is then what kind of data structure is optimal for this then? Are arrays still the better choice or is there another data structure I don't know about that is optimal for card decks?

<comment><USER37> "optimal for card decks"

When n is human-typical card deck size, the optimal solution is whatever minimizes some balance of development time and debugging time. CPU and coding efficiency will never enter as a limitation.

The absolute dirt simplest way to test your numerous card manipulation algorithms might be two arrays (or plain text files?) and your algos copy from one array into the other.

In Yugioh isn't there some inherent (however ridiculously large) limit to the possible number of cards in a deck?

</comment></comment><comment><USER38> If you use a List in .NET, you get a wrapper for an array that will expand as needed (doubling in size every so often). The reasoning is quite similar to the reasons given in this article.

<comment><USER39> System.Collections.Generic.List<T> is similar to std::vector, but oddly named. System.Collections.Generic.LinkedList<T> is the implementation of the canonical double linked list ADT.

</comment></comment><comment><USER40> What is that about "premature optimization" and "the root of all evil"?

O(n) arguments are all very well as long as you keep in mind that, ehem, there are constants all around and they usually tend to be pretty big.

So a more honest title would be "linked lists may harm your efficiency in high-speed environments". Notice the 'may' and the context.

The title implies straightaway "stop using LISP", which to my taste is a rather bold statement.

</comment><comment><USER41> So, exist a list of wich structures are better for the main use cases? ie, a simple "cheat list" or something like that? Because the norm, I think, for the naive developer is use the main one offered by the language (ie: in python, list, dicts).

</comment><comment><USER42> I'm almost certain my tests I did a few years ago were valid, when attempting to push, pop and sort array vs linked list. Would be nice if there were so numbers, examples, etc.

<comment><USER43> The article links to another article that gives a ton of numbers and examples: [http://kjellkod.wordpress.com/2012/02/25/why-you-should- neve...](http://kjellkod.wordpress.com/2012/02/25/why-you-should-never-ever- ever-use-linked-list-in-your-code-again/)

</comment></comment><comment><USER44> They're useful where you need to grow a collection in constant time. Re-sizing arrays is potentially very expensive.

<comment><USER45> If really needed you can have it both ways, you could roll a data structure that is a linked list of arrays. Then you have constant time growth and good caching/prefetching.

Toy example:

      struct ListSegment {
        T[64] items
        int nextItem = 0
        ListSegment* nextSeg, prevSeg
      }

<comment><USER43> If you're using C++ you don't need to roll your own because the standard library provides it. It is called deque.

</comment></comment></comment><comment><USER46> Who used linked lists in practice anyway?

<comment><USER47> LIBXML uses them for in-memory representation of DOM parsed XML.

They are also very effective in Trie node structures (<http://en.wikipedia.org/wiki/Trie>). They provide super-fast searching of large texts.

I prefer arrays. I experimented with linked lists in my early C days, and this code turned about to be the most bug-prone and hard to maintain. They have their place, but given a choice, arrays are simpler, and faster to code for.

<comment><USER21> >I experimented with linked lists in my early C days, and this code turned about to be the most bug-prone and hard to maintain.

I had almost the exact opposite experience. Arrays always felt like I was shuffling indexes around, and needed to do extra bookkeeping to keep track of where I was. Linked-lists seemed more explicit.

Granted, I have had times where arrays produced easier code. These tended to be when I need random access (or to backtrack n-elements or such). Furtuantly, these cases also (normally) coincide with the cases where arrays are the more (asymptotically) performant data-structure.

</comment></comment></comment><comment><USER48> Maybe we should use Linked Arrays :)

<comment><USER49> Back in highschool we'd come up with the idea of using arrays of pointers, those getting the speed of iteration of arrays with the smaller memory footprint of linked-lists.

At the time, we thought we'd discovered something magical.

</comment></comment><comment><USER50> This is akin to saying "Don't use text! Binary data is always more efficient!" Or "Never use uncompressed data storage!"

The reality is linked lists are a tool. They can be used well or they can be used poorly. Just because there are disadvantages doesn't mean they should never be used.

Very link-baity article.

<comment><USER51> They're bad in the same way arrays are bad and "should never be used": appends often require reallocating the entire array, and are thus O(n) (although the reallocs are usually better on average.)

<comment><USER52> Right, but if you overallocate a bit you can ensure amortized constant time. (A comment in Python's list resize code claims that it does this, at least. You can look at [http://hg.python.org/cpython/file/d047928ae3f6/Objects/listo...](http://hg.python.org/cpython/file/d047928ae3f6/Objects/listobject.c) , function 'list_resize' for their sizing algorithm.)

<comment><USER53> .Net's System.Text.StringBuilder does the same... and you can choose the starting provision... When it runs out of space underneath, it will double the allocation for text. Which works pretty well.

I wrote a utf-8 character encoder for use with PostgreSQL early in the C#/.Net 1.0 days, and allocated a StringBuilder for the output at 3x the original string size (up to 8K), which worked very well.

</comment></comment></comment></comment><comment><USER54> I don't think any advice you can get from highscalability.com can be any good, because their whole mission statement is crap.

They talk about getting 10 million concurrent clients only; they don't talk about scaling in any other dimension. And you'll _never_ have 10 million clients of one server in practice, because how much network bandwidth does your super server have? 10 gbps? So that means you'll be strangling each client down to only a few kbps - way to go for performance. The 1980s called, they want their network apps back.

In real life, you'd offload the task from the server onto middle-tier machines that talk to the clients. There'll be at most _thousands_ of these, and each one would have at most _thousands_ of clients. And this will let you provide several mbps to each client if you get the networking right.

In fact, it means that even highscalability.com's original mission statement of 10 thousand clients was _moot in the first place_.

</comment><comment><USER55> Funny this should pop up on a day where I'm writing some flocking.... switching away from a home built linked list. Mostly to use foundation classes - just saw the talk form the developer of Braid about not wheel-inventing or optimizing data structures.

</comment><comment><USER56> Just a bogus claim by a troll. Nothing to see here move on.</comment>


Airbus Beats Boeing in Annual Jet Order Contest - <AUTHOR> http://fortune.com/2018/01/15/airbus-boeing-orders-2017/ <comment><USER2> Previous discussion has some more info: [https://news.ycombinator.com/item?id=16152760](https://news.ycombinator.com/item?id=16152760)

</comment><comment><USER3> I know that a lot of sales are coming from China but in Europe if you do not buy "european" the others throw a hissy fit about european solidarity and blah blah...though yeah there are exceptions to this :)</comment>


Hacking of artificial intelligence is an emerging security crisis - <AUTHOR> https://www.wired.co.uk/article/artificial-intelligence-hacking-machine-learning-adversarial <comment><USER2> "AI" seems to be synonymous with "crappy statistical analysis algorithm".

<comment><USER3> I'm not sure why this comment is being upvoted this much, but it seems fairly snarky and adds little value to the discussion.

<comment><USER4> The comment may just seem annoying but after a fair amount of reading on AI, I think it actually is an OK if snarky comment on state of the art AI.

Current AI involves complex statistical analysis that essentially sacrifices robustness and unbiased-ness for predictiveness. It's basically blindly squeezing all the extrapolative qualities available in a huge dataset, getting impressive seeming results while picking up all sorts of "garbage associations" along the way.

<comment><USER5> At the same time, there are really no 'models' like in, say, Physics or Engineering. The state-of-the-art consists in 'well, this seems to be reasonable and seems to work'. I mean 'models' like 'mathematical models' not like 'a model of a simplified neuron'.

Which for a chess/go-winning program is pretty harmless and even interesting.

Not so much for autonomous driving and/or security, for example.

</comment></comment></comment></comment><comment><USER6> Arent humans tricked the same or in similar ways? For instance advertising exploits weaknesses in human psychology. Advertising is sort of an adversarial tactic.

AI attacks take it to the next level, but the problems are not new I'd say, just an evolution of existing issues that are now applied to computer algorithms instead of humans.

<comment><USER7> > Arent humans tricked the same or in similar ways?

The human perceptual apparatus is eminently hackable. This is how optical illusions work and it's how magicians make a living.

But those hacks are not usually the same as the relatively simple hacks possible with current neural nets.

<comment><USER8> Sure but then AI Is working in terms of mirroring our brains. The nature of problem is similar to ours and AI is just less capable of solving at this point. It's not some weird problem brought about by the fundamental brokenness of our approach to AI.

It shows that it's not ready for prime-time. That's different to "our approach to AI is broken let's do something else."

</comment></comment></comment><comment><USER9> Human "intelligences" are hacked in masses since the dawn of humanity costing in millions of dead.

But it seems rather the force driving the society forward.

<comment><USER10> AI might be able to help with that by spotting subterfuge out there.

</comment></comment><comment><USER11> "Fernandes explains that self-driving cars use multiple sensors and algorithms and don't make decisions on any single machine-learning model." For now, maybe, but, from what I have heard, there is push from the car manufacturers to consolidate on one type of sensor feed as much as possible, to minimize costs. Which implies just that - that the wanted state is one type of sensor, as cheap as possible + one model that is expected to tell the absolute truth. Which is stupid of course, but I assume that the cost-cutting guys are not aware / willfully ignorant of the pitfalls. On another note, the article conflates machine learning / neural networks with AI, I expected better of Wired...

<comment><USER12> DL is a subset of ML is a subset of AI. No fallacy or conflation.

<comment><USER11> I see your point. From my perspective however it is akin to insisting that foot == human.

<comment><USER13> It's clearly akin to human is mammal.

One is a category, another is a sub-category.

</comment></comment></comment></comment><comment><USER14> This is the saddest part of this new artificial intelligence gold rush; not everyone has security/cybersecurity/defensive programming training. The mistakes we see with ETH smart contracts or with JavaScript on web apps is going to be replicated at a far greater scale and at a more dangerous level with machine learning.

Not only will there be algorithmic bias problems, but security problems too! :'(

<comment><USER15> Do you have a link to go with that reference to mistakes? Thanks

<comment><USER16> For ETH the big one is the DAO where they had to fork it to recover

There's also other smaller bugs like coinbase and parity wallet

</comment></comment></comment><comment><USER17> I'm actually really tired of people acting like the world is ending because ML algorithms can be tricked. The only time this will result in actual danger is self-driving cars, and military applications, hardly a world ending crisis. Other than that it's a user sending bad inputs to a search algorithm or natural language classifier, neither of which will actually result in anything other than a wrong result for the end user. Adversarial examples are an interesting research area to make ML more robust but hardly the world-saving pursuit it's proponents make it out to be.

Edit: the real security crisis is the massively non-secure web which our entire society depends on and which we are going to connect everything to

</comment><comment><USER18> Just means the main use case for "AI," (not ML) is probably too ambitious for tech for the foreseeable future. ML has a lot of useful applications for decision support and data analysis. But the key use case for AI is: to be sufficiently sophisticated that it can shield owners and managers from liability.

I would go so far as to say there are almost no instances where someone using the term "AI" is not referring to the deflection of liability for an outcome from a human owner or manager. It's a euphemism and we should identify it when people use it. Perhaps to coin a phrase, we should specify that AI really means "deflected or diffuse accountability," or DA.

<comment><USER19> That's not exactly wrong, but it's not very sexy either. If you mean to replace the term AI with something more accurate, it needs to be a term its proponents can actually get behind.

<comment><USER20> Accountability Indirection? Ass-covering Intelligence?

</comment></comment></comment><comment><USER21> When security is only an afterthought, the product (and in this case, the entire discipline) will remain insecure for decades.

Just like security was an afterthought in the software world up to the late 90's. Software today is still written in C...

<comment><USER22> When security is the top and only goal, you'll end up with a dystopian prison society controlled by authoritarian governments and corporations. IMHO that's an even worse alternative.

</comment></comment><comment><USER23> In summary, adversarial examples.

<comment><USER24> Aye. There may be some special definition of the word "crisis" known only to copy editors.

</comment></comment><comment><USER25> Stumbled across this unique way to make ad exchanges violate Civil Rights legislation. Clever way to hack AI.

[https://archive.fo/iMAbs](https://archive.fo/iMAbs)

</comment><comment><USER26> In other words, artificial intelligence isn't intelligent at all.

</comment><comment><USER27> How many kill by miliary weapon vs car? Can car kill? Can car be a weapon?

Would car used by x to kill?

Can car be remotely controlled — randomly, by target or massive used ... to kill?

Would anyone interest to hack then ?

</comment><comment><USER28> Feels like an episode of Travelers from Netflix.

</comment><comment><USER29> What another shitty title. "Turning data against itself". It doesn't make me want to click the link at all. I did though and, while blinded by the terrible layout, it seems like they're showing off some of the _techniques_ used to mess with AI systems.

<comment><USER30> I guess the idea is that by feeding bad data they can do the equivalent of implanting bad thoughts in someone. Think of it this way, if your parents raised you racist you would probably think racist thoughts until you learned enough perspective

<comment><USER31> Noticing differences in people is natural and starts at an early age. I observed this in my own children. However, what we identify as racism and sexism is learned behavior. It emanates from stereotyping, prejudice, and bias.

<comment><USER32> Stereotyping, prejudice and bias _are_ natural behavior and are observed even in children. Whether the specifics of racism, at most, are learned or not is somewhat immaterial-- as for sexism, there's even less ambiguity about it being deeply rooted in human nature somehow in a way that's very hard to change - it certainly isn't our "societal structures" telling kids that females have _cooties_.</comment></comment></comment></comment>


Show HN: Snapwee Angies List for Individuals! - <AUTHOR> https://www.snapwee.com

<comment><AUTHOR> make extra $ by helping your neighbors with odd jobs

A new service, [https://www.snapwee.com](https://www.snapwee.com) allows you to do such a thing! We need users to try it out and give feedback! thanks! AW, IV</comment>


Firefox Quantum DOM Cooperative Threading Design - <AUTHOR> https://docs.google.com/document/d/1MZhF1zB5_dk12WRiq4bpmNZUJWmsIt9OTpFUWAlmMyY <comment><AUTHOR> Firefox 57 has its share of detractors among the HN crowd, particularly those who want XUL extensions to continue to live on. I am not in that camp; I think Firefox is fighting for its future, and I like that my browser of choice is closing the performance gap with Chrome.

The 57 release is chock full of great features and performance optimizations. Ehsan Akhagari manages a critical initiative, called Quantum Flow, and he publishes a weekly newsletter that chronicles performance improvements in Firefox on his blog [1].

In the recent newsletter [2], he mentioned "Quantum DOM Cooperative Threading", a feature that has landed in Firefox Nightly, but is disabled for now so that issues can be fixed. To quote Ehsan on the project's goals:

"... this past week the first implementation of our cooperative preemptive scheduling of web page JavaScript, more commonly known as Quantum DOM, landed. The design document describes some of the background information which may be helpful if you need to understand the details of how the new world looks like."

This combined with other efforts -- such as de-prioritizing background tabs, event queues, and lazy loading -- should significantly improve Firefox's perceived performance.

If you haven't given Nightly a try, I suggest that you do.

1\. [https://ehsanakhgari.org/blog](https://ehsanakhgari.org/blog)

2\. [https://ehsanakhgari.org/blog/2017-09-01/quantum-flow- engine...](https://ehsanakhgari.org/blog/2017-09-01/quantum-flow-engineering- newsletter-22)</comment>