What an Aging Population Means for the Future of the Internet - <AUTHOR> https://www.buzzfeednews.com/article/craigsilverman/old-and-online-fake-news-aging-population <comment><USER3> Article totally misses another major issue with an aging demographic: UX concerns.

I'm 54. A UI with clutter, or carousels that move too fast, or text in a small font (or one with low contrast against the background color/image) is hard to use. I also have middle-aged memory issues, which only get worse with age: I'm far less able to hold multiple bits of information in working memory, so I can get demotivated and give up when a website or app expects me to remember seemingly irrelevant details (hint: disabling copy/paste in password entry fields is a great way to lose me as a customer because I rely on 1password and know enough to use strong passwords — but I can't memorize them).

Apps and websites designed by twenty somethings tend to assume twenty- something levels of cognitive performance and sensory ability and reflexes which older users once had but have now lost.

And so on.

… And before you comment to say "well, don't use the app/website, then", bear in mind that it's increasingly impossible to avoid filing your tax return online, dealing with your bank and credit cards via an app, ordering supermarket deliveries online (especially if, as with many elderly people, you're mobility-impaired) …

There's a point at which bad UX design becomes life-threatening. This is well understood in human factors engineering in e.g. the aerospace sector, where aircraft cockpit controls are carefully designed to be where and do what pilots expect. But there comes a point at which badly-designed smartphone apps are going to become an actual hazard to users who are unable to use them as their (younger, able-bodied) designers expected.

<comment><USER4> The market will respond. Look at television. Turn on CNN. Every add is for either a drug or retirement planning. Old people have all the money. As soon as old people start relying on smartphone, when they actually start using them as the young do today, the apps will adapt.

Facebook is getting older. I'd expect the first real UI changes to begin there.

<comment><USER5> I'm _not_ old (well, not _that_ old) and I bounced off Facebook when I first tried it around 2010 or so, because I couldn't figure out where anything was or what anything did or meant. Recently have had to use their "workplace" product and it's just as bad as I remember. Their UX is so bad I can't figure out how to use their product, accessibility entirely aside.

It's like Crusader Kings II but without the game to motivate me to figure it out, and also not apparently as _necessarily_ complex so I'm not sure why it's so confusing.

</comment></comment></comment><comment><USER6> I am shocked how some older people behave in their inboxes... One lady clicks on every single link in every e-mail she gets. Her man tries to open every attachment. I was even more shocked when I saw, that their free mail provider Gmx doesn't really have spam filter. I use gmail in Germany and see spam every few months. Gmx's inbox had many suspicious e-mails when Amazon purchase notifications landed in spam folder. Both computers Windows 7 with no antivirus. After years educating them I achieved, that she does not open suspicions e-mails and the guy open attachments only from his friends. Some of these friends strongly believe, that everything on Internet is true. It was a weird moment understanding, that some random website is trusted by older people on same level as quality journalism like Sueddeutsche Zeitung. This aging population is nice target for individuals with not the best intentions.

<comment><USER7> _Everything_ you have written applies equally to young folks too.

I was shocked when I discovered how our kid's friends are with tech - <USER2> is 20 now, and has been messing with computers since 4. Shocked because unlike my parents generation they've all grown up with, and been educated around tech their whole lives. All I have to do to get a significant number of them to believe $conspiracy, or 2+2=7.234 is put it on a convincing _looking_ website. They'll mostly install any and every app that passes under their nose. In the days of FB among the kids, and FB games and surveys, they'd go with every single one of those too... and share, and ping their whole contact list... Before that every drive by popup/malware install...

At least my parents generation had their expectations fixed in the 1930s and 1940s. Receiving something in writing _meant something._ Honesty and ethics were mostly to be expected. The scams were far more about in-person confidence tricks, or the dodgy tradesman charging for work that's not needed etc. I don't blame some for not adjusting their model to everyone's a spamming scammer. :)

I do blame the youngster's generation. How the hell do they not get it and so glaringly badly?

<comment> kris-s > I do blame the youngster's generation.

When you're young the older generations complain about you. When you're old you complain about the younger.

[https://mentalfloss.com/article/52209/15-historical- complain...](https://mentalfloss.com/article/52209/15-historical-complaints- about-young-people-ruining-everything)

<comment><USER7> Just as I would blame me and my generation for not having awareness of climate change, or not changing lifestyle and politics because of it. Or illiteracy. Or inability to wire a plug. I would _blame_ a 55 / 60 year old for those.

Everyone my age got taught and surrounded by English. Everyone my age did _not_ grow up with tech. Some my age are deeply naive about tech thanks, in part, to having surprisingly little exposure until recently as it became unavoidable.

It's not generational whining - that's a very different animal, it's the simple ubiquity.

</comment></comment></comment></comment><comment><USER7> I mostly felt like I was reading a piece from 10 years ago. Liking a page on the back of a share or ad for something popular is so common as to be a trope. Britain First were hugely successful pushing their far right racist bullshit with this tactic ten years back. It's how they grew to being noticeable in the first place! Now every idiot can be heard.

Much of the age statistics also apply across the demographic - if non- technical. I don't think anyone, of any age, outside of tech has a reasonable picture of how algorithms affect their lives, and what they might see. The older couple might get taken in by a Microsoft tech support scam or a you won a lottery you didn't buy a ticket for spam. The kids buy cheap games/festival tickets/fashion/tech from absurdly poor scam sites - then don't complain as they've been educated by site policies rather than any awareness of consumer law.

Last, I think _everyoen_ is more lonely. We have apps that centre on us, the individual. No need to go to the club without an appointment, or make a phone call, or interact with any of those pesky humans. Apps, internet and politics are all driving this hard. Purely from what I see, it _seems_ like the youngsters are hardest hit - they _should_ have their max amount of friends and least chance of existential loneliness. By the time you hit 60s half your friends have moved miles away or died. A good proportion will have been widowed. Loneliness rather goes with the territory of ageing.

</comment><comment><USER8> (source: I'm 58)

I think another challenge that is already happening is reduced accessibility to older people of household devices that are app driven.

I'm in the process of buying some new high-ish end audio equipment. All of the systems I've seen pretty much involve having a smart phone / tablet to control it and access to streaming services (e.g. tidal or deezer) if you want high quality sound. There are several challenges right there for folk who just want to insert some physical media and press 'play'.

I can handle this, for now. But who knows what the interfaces to these systems will be like in say 10 or 15 years time. Voice control may address some of these challenges, but I think for a lot of people, a whole range of devices they rely on will become alien and scary.

<comment><USER9> It's not just older people - I'm late 20s and I don't want a a high end ANYTHING that relies on a third party to work. Sometimes unavoidable, but I feel like there are quite a few cases (yours included) where it's just unnecessary. I see discounts all the time for smart TVs - I just want a 60 inch monitor without someone else proprietary BS stuffed in it. Seriously concerned about the possibility of smart/app everything with no dumb/consumer customizable options. Apparently something similar is happening with car audio too, because of the increasing integration of the head unit into the guts of the car.

We should be making things easier for people to do themselves, not finding more ways to extract money by doing it for them.

</comment></comment><comment><USER10> I wonder if this is a transient phenomenon in which people from the last generation not to grow up with internet (=people born before 1985 or so) becoming easy prey to manipulative agents online, or whether it will continue in subsequent "old" generations due to age-related cognitive decline and social isolation.

<comment><USER11> 1985 is way way too high, I'd presume you are young enough, though.

If you were born pre-1985, you might have witnessed netiquette and its desolation.

<comment><USER12> b1970. I remember when it became September Forever.

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

</comment></comment></comment><comment><USER13> Dealing with my aging baby boomer father concerning the internet has been a FUCKING NIGHTMARE. He somehow gets every toolbar installed on his computer, falls for every phishing/fraud scheme. I am terrified of what the world will look like when I start losing my faculties.

<comment><USER14> The solution for this is to give them locked down devices like iPhones or iPads.

</comment></comment><comment><USER15> I'm a bit annoyed when people talk about "fake news" as if everyone understands what that means. It seems pretty clear to me that different people have different conceptions of what that is.

<comment><USER16> I'm sure there was a moment when "fake news" meant stories coming from superficially reputable looking websites, that in reality were fugaciously created to give a veneer of respectability to made up stories. This meaning of "fake news", which I think is actually meaningful and useful, seems to have completely vanished, or maybe I just imagined it?

<comment><USER17> The term dates to the late 1980s when it referred to propagandistic video and audio "news releases" generally created by or for corporate interests. That usage continued through to mid-to-late 2000s decade.

It was applied to more general misinformation in the 2010s, before being 'undefined' by many of the promotors and beneficiaries of fake news.

[https://www.sourcewatch.org/index.php?title=Fake_news](https://www.sourcewatch.org/index.php?title=Fake_news)

[https://www.prwatch.org/fakenews/execsummary/](https://www.prwatch.org/fakenews/execsummary/)

[https://www.prwatch.org/fakenews2/execsummary](https://www.prwatch.org/fakenews2/execsummary)</comment></comment></comment>


Governments will always suck but we need them - <AUTHOR> https://www.atlassquats.com/post/governments-will-always-suck-but-we-increasingly-need-them <comment> trail-system This article approaches a few correct points on some very obvious ideas while saying a lot of other things that I find crazy.

 _My personal experiences with the government have been either frustrating, inefficient, meaningless, or detrimental. At some point, you inevitably start questioning why such a large government exists and why we need it._

The authors is listing words with very specific negative emotional subtext. It barely makes sense in the context of the sentence.

 _" The first thing to understand about governments is that governments and corporations are exactly the same. Both are just groups of people trying to create value in some market."_

The first thing to understand is generalities can be the death of any reasonable perspective.

The authors use of language betrays the mistake of personifying the government as a cohesive and singular entity.

The truth is that most governments exist as an ecosystem for many different parts to cooperate for various reasons. A very large amount of the people within that ecosystem are genuinely passionate about being able to work for the public good and do a fantastic job of it. A large amount of people within the same ecosystem do not care and take advantage of their civil service role as a means of personal/commercial benefit. Now what about the people in between these archetypes?

The actual "thing" is too varied and complex for almost any generality to be usefully applied.

<comment><AUTHOR> The point of generalities is to be able to reason about things too complicated to fully describe. Whether or not you think a specific generalization, framing, or model is a good or useful one is completely up for debate. Denouncing the idea of generalities doesn't give any room to reason about anything complicated.

Saying something is too complicated and varied to reason about is an indictment against all of science. Reality is fractally complicated yet we still manage. Physics is an approximation of reality. Chemisty is an approximation of physics. Biology is an approximation of chemistry. No model is perfect.

In my opinion, understanding government as a monopoly in the business of violence provides a useful framework.

1\. It's generalizable. Monopolizing violence over its citizens is the common factor between every government. From North Korea to China to the US to Norway, all governments maintain the absolute and unrivaled power to exert violence over their citizens. I cannot personally find any counterexample.

2\. We can apply existing research. Modeling governments as businesses in a specific industry enables to use research about how markets and businesses work. This whole post is essentially an argument to change macroeconomic modeling. Instead of treating the government as some separate special entity, we can simply existing macroeconomics models by treating the government as yet another business.

3\. It's simple.</comment></comment>


Verizon threatens Netflix with legal action over network congestion alerts - <AUTHOR> http://cir.ca/news/internet-peering-disputes <comment><USER2> [https://news.ycombinator.com/item?id=7853603](https://news.ycombinator.com/item?id=7853603)</comment>


Prisoner of Facebook - <AUTHOR> https://medium.com/@pof/prisoner-of-facebook-521929a26a95 <comment><USER2> I also fell for this back in my younger days. Gave them my birth cert, and student ID. It still haunts me to this day, but I was just a dumb high school kid.

Needless to say, I haven't went back to Facebook since.</comment>


Can company give IP rights away for application I wrote off hours to a startup? - <AUTHOR> http://programmers.stackexchange.com/questions/162002/can-my-company-give-ip-rights-away-for-an-application-i-wrote-off-hours-to-anoth

<comment><USER2> Assuming this is taking place in the US, and under the given facts, no.

For the company to own the IP, it would have to be a work for hire as defined in 17 USC 101. That requires that it be made by an employee withing the scope of his employment.

The author was an unpaid intern. Interns that are employees MUST be paid at least minimum wage under the Fair Labor Standards Act, so we may infer that the relationship in this case is not an employee relationship. Without an enployee relationship, no work for hire. (Specially commissioned works can be work for hire without an employee relationship, but only for specific kinds of works which are not applicable).

The request is even more questionable in this case because it doesn't sound like it is the COMPANY asking for the code. A director wants to give the code to his brother who has a start up in the same industry.

Personally, I'd report the company to the Department of Labor for possibly illegal internships, and I'd report that director to the other directors or owners who might not be aware that he's trying to use code their intern developed to help his brother's startup.

</comment><comment><USER3> Short answer, hire an Intellectual Property Lawyer. Laws are different state to state, country to country.

</comment><comment><USER4> Make it open source under BSD.

That's what I did when I was in your situation. This way, 1) You don't burn any bridges, 2) You're recognized for your work and 3) If you get other contributors to your project, your software will end up coming out on top.

<comment><USER4> Oddly enough, the company ended up hiring manual labour that took 4 people and 2 weeks to do something my application did on a coffee break. Reason being - that project was assigned to another department. I guess what I'm trying to say is - not to worry, things work out for the best, and karma always comes back around.

</comment></comment><comment><USER5> Please stop</comment>


iBench – realtime search developers / No freelancers here - <AUTHOR> https://ibench.net/ <comment><AUTHOR> Realtime match. In industry you need. High performing engineers available today</comment>


Tell HN: un-design of everyday thing - <AUTHOR>

On a recent business trip, I was booked at the W Hotel in SF.  Nice decor, but they overdid it to the point that "usability" suffers.  Now I used to travel every week, so I know business hotels.  Just like in s/w or web design, when a designer tries too hard to be cute or fancy, he/she ended up irritating.  Here are some examples from that trip.
I could not find the light switches for the desk area for the first hour, because they were all located in an out-of-the-way side.  And the switches are small.
For a hotel that recommends the guest to be green by recycling, their water lever in the bath / shower did such a poor job that when you set it to shower, half the water actually went down to the bath, instead of to the shower head.  Wasted water.
The water faucets at the wash basin: one turn clockwise and the other turn counter-clockwise to open the water.  Go figure.
I can mention a couple more, but the point here is not to rant - I like Starwood hotel chain.  The point is to hear your experiences of "un-design" similar to mine.
And Merry Christmas, by the way! <comment><USER2> Good design isn't what most people think it is. Good design isn't about bells and whistles, fancy doorknobs and thick carpets. It's about making something that works just like you expect it to. Apple and dropbox know this and it's a large part of their success. It just works. All the fanciness in an apple computer or an iphone is there for a reason, there are no equivalents to fancy doorknobs or thick carpets.

This is also why Scandinavian design seems to be held in such high regard - it's very simple and works like you expect it to.

This wikipedia should be compulsory reading for industrial designers: <http://en.wikipedia.org/wiki/Form_follows_function>

<comment><USER3> The Law of Least Astonishment is also a good one.

</comment></comment><comment><USER4> My car's turn signals are frustrating as hell. Normally, when switching lanes, I don't push the signal lever all the way over, so that it locks; I simply push it and hold it, so when I am in the moved-to lane, I just let go, and the signal turns off.

However, the designers found a way to trick me, making my attempts at signaling useless. When I push the lever over, the point at which there is significant torque pushed back also turns on a faster-than normal click of the turn signals. However, the signals do not turn on until I push past this; there is a further point where the turn signals actually turn on.

My instinct is to push the lever until there is audible and felt feedback, but this doesn't work, since that point does not turn the signals on. Very frustrating.

</comment><comment><USER5> You should read Norman's "The Design of Everday Things." I bet you'd really enjoy the bit where he discusses hotel doors.

[http://www.amazon.com/Design-Everyday-Things-Donald- Norman/d...](http://www.amazon.com/Design-Everyday-Things-Donald- Norman/dp/0385267746)

It's a really great book, and something I would consider a must-read for serious UI designers/developers. While the book was written in the 80s, and talks about things like ring slide projectors, VisiCalc, the original Macs, the ideas about what constitutes good and bad design are salient to this day.

<comment><USER6> Based on the title of the post, I'm sure that's where part of the inspiration for this post came from. That said, great book which I completely recommend.

</comment></comment><comment><USER7> This reminds me of an article I read by Dustin Curtis.

The flimsy doorknob and the cheap receipt:

<http://dustincurtis.com/two_stories.html>

I highly recommend that you read it. Basically it is an article about how presentation can make a positive or negative effect. And Dustin Curtis does a phenomenal job with the presentation of his own website. It is a real joy to read and always makes me aspire to the shear elegance of his typographic layout.

<comment><AUTHOR> Great article; I agree with him wholeheartedly.

To those who think that faucets are supposed to be like double-doors, I understand, but usability is not always about idealism or philosophy. Sometimes it's about consistency. If most faucets operate one way, wrongly or rightly, then doing it differently forces the users to do it wrong the first time (or first few times) he/she uses the product.

The book that comes to mind is "Don't make me think" by Steve Krug. He did not advocate perpetuating "wrong" convention, but the point is still valid: don't waste the user's time by designing something to behave differently than "expected".

</comment></comment><comment><USER8> While I get your point in general, I disagree with the water faucets. Typically that's how they work - because they turn outwards (so to speak) from the spout in the center.

<comment><USER9> Exactly. I expect them to be symmetrical, just like double doors, and would be surprised if they both turned in the same direction, because hands turn naturally in opposite directions.

What's really annoying, though is when the faucets (or light switches) in a place are not consistent.

<comment><USER10> For the faucets to be consistent, they need to behave like every water bottle, valve etc.: righty tighty, lefty loosy.

@ojbyrne: It does not matter how they work from an engineer's point of view: Design needs to be user-centered.

<comment><USER8> I'm not talking about an engineer's point of view. In fact "righty tighty lefty loosy" is an engineer's point of view. When taps are presented in pairs users expect them to open "away" from the central spout.

<comment><USER10> That'd be interesting to clarify in actual usage testing – unless you already have such data to support your claim.

I regard »righty tighty lefty loosy« as an established standard for opening revolving things. But due to the mnemonic existing in the first place, that probably needs some testing as well.

<comment><USER8> I'll admit to not having data to support my claim, other than my personal behavior (and the guy above). I'm not sure how you would do the testing since I think everyone has used faucets, and they almost always go the way I described (or at least that's my best recollection).

<comment><USER10> I had to think about this thread when today I, oddly enough, stumbled over not 1 but 2 blog posts regarding water faucets and taps: [http://mattmorphett.blogspot.com/2009/01/sometimes-there- is-...](http://mattmorphett.blogspot.com/2009/01/sometimes-there-is-good- reason-to-break.html) [http://www.malcolmcoles.co.uk/blog/usability-taps- lessons-we...](http://www.malcolmcoles.co.uk/blog/usability-taps-lessons-web- design/) (via [http://www.uselog.com/2009/05/checklists-and-water-taps- for-...](http://www.uselog.com/2009/05/checklists-and-water-taps-for- usability_28.html))

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> W isn't supposed to be "good design". What they are is "stylish". They cater to image & brand-conscious people just like Prada or Versace. I assume it's a profitable niche.</comment>


TextDrive is Back - <AUTHOR> http://joyent.com/migration/ <comment><USER2> A story of corporate communication amateur hour; So i have to read on HN that my textdrive/joyent hosting is stopping. Bit pissed i write an email to support that i'd like more time to move stuff and that a refund would be nice. I get a canned reply with a repeat of the email mentioned on HN. Then on their support forums the Joyent president suddenly is all helpful and grants everyone refunds. we'll have to ask/haggle with support about it though. So i email support again quoting their fearless leader. This time the support staff promptly grants me a refund (which i haven't heard or seen anything about since i should add). I'm happy enough with that outcome for now though and start moving all my sites to other hosting options. Fast forward to today (about a week later). Again on HN (still not on that mailing list it seems) i have to read that textdrive is restarting after all (tada!) and we can keep our precious hosting accounts running. Wow, thanks good timing as well. Can i still get my refund and get the f out though?

Note to budding entrepreneurs; don't do this.

<comment><USER3> I requested that they honor the refund offer (as I'd already started migrating away, and as they've destroyed any remaining trust I had in them.) I just received the reply:

 _We are sorry for the inconvenience our change in plans has caused. This is the only option available. We will continue to honor your original Lifetime purchase, and you will continue to receive hosting services from TextDrive._

So, no, we can't get our refunds and get the f out. I'm deeply unhappy with how they've handled this, start to end. (I too failed to receive any of the mass mail-outs.)

<comment><USER4> Yeah this isn't going well: <http://forum.textdrive.com/viewtopic.php?pid=242571>

</comment></comment></comment><comment><USER5> Someone please correct me if I am wrong, but by relaunching as a separate company from Joyent, it opens up the ability to truly shut down the service and avoid all of the lawsuits.

Remember that the key wording was "as long as the company exists". Once the spinoff is complete, TextDrive can be shut down while Joyent continues on.

Perhaps I am too cynical, but I see no other reason to jump through all of these hoops and separate.

<comment><USER6> I don't think this was ever about Joyent wanting to escape their lifetime hosting obligation. It was more about them not wanting to be in the shared hosting business - they don't want to do that work. They still don't want to be in that business, but they old founder has offered to come back and do it. All it will cost them is a little money, which is not so much when they think of all the damage this publicity could cause their business in years to come.

<comment><USER7> Sure, but all it was really costing them in the first place was infrastructure and support costs.

Is the new Textdrive supposed to be financially self-sufficient? That doesn't seem possibly. Even if Joyent gives them all the hardware and bandwidth for free, who is going to pay for the support and maintenance? The handful of paying shared hosting customers?

<comment><USER6> Obviously they will have to build a real business. They will have the incentive to do it this way though.

<comment><USER7> Fair enough, but it seems like it would be hard to build a shared hosting business even without having to support a bunch of non-paying customers from day 1.

</comment></comment></comment></comment></comment><comment><USER8> I already finished migrating off of my TD lifetime account and onto WebFaction. I don't see why I should put my sites back on TD. So I guess my TD lifetime account is a spare, for now. I'm sort of glad to hear they're doing the right thing, but they did it the wrong way.

</comment><comment><USER9> I wonder what this means to the 5-year hosting or full refund offer given to lifetime account holders.

I submitted it here: <http://news.ycombinator.com/item?id=4410682>

<comment><USER3> It means those offers have been withdrawn. They are no longer an available option. (I just heard back from support.)

<comment><USER10> I was told different, by support. I could chose between the 5 year offer, or TextDrive.

Reading the forum thread, the refund _has_ been withdrawn - which is a really crappy thing to do to the people who had already accepted that offer.

</comment></comment></comment><comment><USER11> While I would like to beleive that they will fix all the problems, my previouse experience with Joyent tells me that this may be an attempt to try to get away from the a lawsuit.

I posted a coment here two weeks ago [1] and I received dozens of responses - if anyone would like to join the class action to ensure our rights are not lost please conact me. I am not really interested in lawyers - I hope we can work something out.

[1] <http://news.ycombinator.com/item?id=4392052>

<comment><USER7> Im not defending the ridiculous path they took to get here, but how could you have grounds for a lawsuit now that they are holding up their end of the original bargain?

</comment></comment><comment><USER12> Here's the e-mail that was sent out:

[Name],

If we haven't met, I'm Dean Allen, a founder of TextDrive, the shared hosting company started by Jason Hoffman and me in 2004. I'm also a founder and erstwhile President of Joyent, which some time ago merged with TextDrive, though I haven't been active with that company for a while.

If we have met, I hope it went okay.

A couple of weeks ago I received, at the same time as Joyent's shared hosting customers, a message announcing an end to support for shared hosting, affecting customers who've been with us for years, some of whom invested in accounts we had intended to support for the rest of the life of the company. The announcement struck many as abrupt. Some took it to be an abandonment of, if not an insult to, your good faith, written in marketing and lawyer speak.

I soon spoke with my friend Jason, who by then was deluged with abusive emails and imaginative threats. After I rubbed some salt in his wounds, we began imagining what it would take to continue providing what we'd intended all along to those who put their faith in us. After some wrangling, we've found a way to make it work.

I'd like to announce that on November 1st, 2012, TextDrive will relaunch anew as a separate hosting company, staffed and funded, run by me. Please consider the recently announced end-of-life for Joyent's shared hosting customers now revised to be a continuation-of-life, to be carried out in the same friendly, creative, publishing-centered spirit of TextDrive's early days.

No matter its humble beginnings, Joyent now operates in a very big arena, producing heavy artillery for the armies of cloud computing, and it's been years since the company has been structured to service the retail hosting customer. Moreover, the servers on which your accounts still reside are old, slow, inefficient, and they go down on occasion. Everyone deserves better.

Current shared hosting customers can expect to have at least double the resources provisioned have now, running on vastly more stable and efficient infrastructure. Running, in fact, on the very heavy artillery mentioned above.

I intend to have all current paying and lifetime shared hosting customers moved from our old data centers to new, modern and efficient infrastructure by November 1. We'll be doing all we can to automate the migration process and keep discomfort at bay. More communications and instructions on the migration process will follow. For now, know that Joyent shared hosting customers, whether paid or lifetime, are now TextDrive customers and that service will not be interrupted.

For updates and resources click here [the page linked by the OP].

It gives me great pleasure to indicate that I'll talk to you soon.

Dean Allen

TextDrive

Edit: Here's the previous HN thread discussing this: <http://news.ycombinator.com/item?id=4391669>

<comment><USER13> I wish I had received this email, I think I missed out on one of the migrations at some point and I dropped off the list, but I re-added myself now.

It really makes me feel happy to see Dean to come out of the woodwork and handle this. I'm sure there's a million things he'd rather do than be involved in web hosting anymore, but he obviously felt some obligation to all of us who believed in his vision 8 years ago, and that more than makes up for a thousand what'd-you-expect-from-shared-hosting-you-idiot comments on HN and elsewhere.

</comment></comment><comment><USER4> I choose to give them the benefit of the doubt. Both TextDrive and Joyent Cloud have been highly productive enterprises. I hated to see TextDrive fall by the wayside but I still trust them more than a run-of-the-mill exit-seeking startup. I hope the new TextDrive makes money and is around for a long time.

</comment><comment><USER14> What was it used to do? Can somebody tell, please?

<comment><USER15> IIRC it was originally a shared web host. I think they also had a gimmicky lifetime subscription if you pre-paid for a year's worth of service.

<comment><USER16> The lifetime subscription was designed to fund TextDrive as a nascent company.

[http://photodude.com/2004/06/01/textdrive-or-how-to- raise-40...](http://photodude.com/2004/06/01/textdrive-or-how-to- raise-40000-in-4-days)

<comment><USER5> Thank you for posting that link, it adds a lot more depth to this story -- Anyone not familiar with the TextDrive lifetime subscription needs to read this.</comment></comment></comment></comment>


REST Anti-Patterns (2008) - <AUTHOR> https://www.infoq.com/articles/rest-anti-patterns <comment><USER2> > Ignoring status codes

My favorite is when everything returns a 200, but the response is something like:

       {
         status: "fail",
         error: "forbidden"
       }

Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.

<comment><USER3> A quick glance at history of HTTP can explain this without incompetence. HTTP is fundamental to the world wide web and existed from the beginning in 1989. Fielding's dissertation introduced the idea of REST in 2000. And REST became part of mainstream client libraries in what, 2010? So there's a 20 year period during which code was written against HTTP libraries which were not idiomatic from a REST perspective. Returning status codes in the response body is a common workaround for compatibility with code written in this 20 year window.

<comment><USER4> Status codes aren't something introduced by REST, they've been a standard part of HTTP since HTTP 1.0. They've been in widespread use for decades. People use 200 for errors for a few reasons, but it's not because HTTP 0.9 didn't have them.

<comment><USER5> I started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes.

There's a load of early, popular, Stack Overflow questions that revolve around what status to return when, and how to actually return those codes in your language. For example, in ASP.Net/IIS it was actually quite hard to stop IIS 6 (?) from swallowing your 500 xml response and serving a custom html error page. If I remember correctly some browsers didn't support PUT properly either.

So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use.

I remember this article from the first time around, when people were really getting into REST and there was a fierce debate about strict REST Vs RESTful. In reality RESTful has mainly won and this article was on the wrong side of history.

<comment><USER4> > I started programming professionaly in 2005 and I can assure you that back > then, outside of the browsers, people really didn't know or understand > response codes.

> So while you are technically correct, the codes were in use, you are > historically wrong, few people outside of a small community understood their > use.

I started in the late 90s, and even back then they were commonly used. They weren't just well understood by developers, but they were actually in non- developer's lexicons as well. If you asked the typical geek back then what a 404 was, chances are they'd be able to tell you that it meant something was missing. So I don't agree with you that they were understood by "few people outside of a small community" at all. Using status codes has been standard practice for decades. Maybe it took a couple of years at the beginning of your career for you to notice them, but there simply wasn't this time period of decades when they weren't in use until REST came along.

<comment><USER5> Given that ajax was only added to browsers in 1999 and AJAX didn't really catch on seriously until 2003/2004ish, what you're claiming is at odds, again, with actual history.

404s are a different matter because you'd get 404 pages, so it's not at all an argument to support your position. It doesn't mean developers understood what to return from an ajax call, or that they understood HTTP verbs.

I'll remind you again that it was actually fairly hard to return the correct codes from a lot of frameworks, so objective facts are at odds with your recollection of events.

I stick by my assertion that the vast majority of web developers in our industry didn't really understand http until the latter half of the 2000s. I also specifically remember presentations to all our developers both junior and senior of how browser caching worked, which to most developers at the time was a bit of a mystery, and the correct headers to return to control it.

Here are some examples from 2008 of developers on SO discussing things which seem obvious today:

[http://stackoverflow.com/questions/165779/are-the-put- delete...](http://stackoverflow.com/questions/165779/are-the-put-delete-head- etc-methods-available-in-most-web-browsers) [http://stackoverflow.com/questions/165720/how-to-debug- restf...](http://stackoverflow.com/questions/165720/how-to-debug-restful- services)

<comment><USER4> > Given that ajax was only added to browsers in 1999 and AJAX didn't really > catch on seriously until 2003/2004ish, what you're claiming is at odds, > again, with actual history.

Ajax is not the only way to access a web service.

> 404s are a different matter because you'd get 404 pages

…which are returned with a status code of 404. That's where the name comes from. Non-200 status codes were ubiquitous even back then.

> It doesn't mean developers understood what to return from an ajax call, or > that they understood HTTP verbs.

Ajax is irrelevant and we're talking about status codes, not verbs.

> I'll remind you again that it was actually fairly hard to return the correct > codes from a lot of frameworks, so objective facts are at odds with your > recollection of events.

Perhaps the technology _you_ were using made it difficult, but it certainly wasn't the general case. PHP, classic ASP, mod\\_perl, mod\\_python, CGI scripts… they could all respond with non-200 status codes easily. Which ones are you thinking of that made it difficult?

> Here are some examples from 2008 of developers on SO discussing things which > seem obvious today:

Come on man, clueless questions get asked about extremely well established things on Stack Overflow every single day. That doesn't mean that those concepts are suddenly no longer well understood, it just means that the person asking is a beginner. And neither of those questions mentioned status codes at all!

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> The problem is that people want an RPC mechanism, and REST gives them a document transfer mechanism.

If your API will never be navigated by a human operating a browser, a lot of the REST specification is inapplicable (navigation links, etc.)

So you're throwing out a lot of REST regardless, and the question becomes where to draw the line between ease of implementation and compliance with a standard that doesn't really fit your needs.

<comment><USER7> Another problem is that people want an RPC mechanism, when what they need is a state-transfer mechanism.

It turns out that the semantics of RPC — attractive as they undeniably are — are pretty poor for building real-world distributed systems, while those of REST as a pretty good (or at least _better_ ) fit.

<comment><USER8> People need both. REST works well for CRUD operations that don't have complex side effects or constraints. What's often missing in this is intent. I just want to do "the thing" to this particular account or whatever.

Personally I like to very selectively add RPC actions on top of the base resource. Tacking an RPC action onto the resource URI allows you to encapsulate the intent of the user's action, handle all the updates required server side, and then return the updated representation.

<comment><USER9> I almost always have both. I tend to use event sourcing and the intent is mandatory. There might be 20 reasons to modify one resource, each with its own list of side effects to later perform.

So it's usually POST resource/:id/action and that's fine.

<comment><USER10> > So it's usually POST resource/:id/action and that's fine.

There's nothing wrong with that. It's not anti-REST or anything, assuming you satisfy the other REST constraints, ie. each request is self-contained and any stateful resources are designated by URLs.

As an aside, I'm personally not a huge fan of human-readable URLs because it encourages API consumers to rely on/construct URLs client-side, which is not REST.

<comment><USER7> I think a more properly-REST approach would be to PUT a representation of the resource with the action applied. That is, rather than POSTing to /resources/:id/close, one would PUT a closed version of the resource to /resources/:id.

<comment><USER10> I don't see why that would be more REST. POST is to be used for side-effecting operations, PUT is an optimization over POST for idempotent effectful operations.

Certainly a PUT solution might have some advantages for replayability in case of network partitions, but REST doesn't this choice dictate one way or the other.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The biggest anti-pattern of all: marketing your API as RESTful, when it is really more RPC-like.

I agree on all points of this article. The only nitpick I have is that tunneling through GET/POST is strictly necessary for HTML forms, since they do not support other verbs.

<comment><USER12> > _The only nitpick I have is that tunneling through GET /POST is strictly > necessary for HTML forms, since they do not support other verbs._

Only if you ignore AJAX in its entirety. Yes, the browser's capabilities are limited, as it must be a common denominator and can't describe every situation, and thus, can only GET/POST in certain forms.

</comment></comment><comment><USER13> If API's are best represented via REST, then why aren't software API's in general RESTful (e.g. I dont POST triangles to my GPU)? The answer: SOME API's are best represented with REST, but most are not.

<comment><USER14> Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.

<comment><USER15> I agree but also have counter example, perhaps not yet as an interface for two systems. But let's start with this:

What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version.

^ has been done as a separate monitoring tool like Osquery, but can't we make such protocol natively? I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect.

<comment><USER16> > _What if I can ask my OS to do things I normally do over some protocol like > HTTP in a RESTful style? Create user, list directory, find the last login, > tell me linux kernel version._

The /proc filesystem is somewhat close to that when it comes to GET.

> _I don 't want to parse my command-line output if I can just speak in one > human-readble, machine-friendly dialect_

That's not what REST (the original concept) is about.

<comment><USER15> I understand REST's original motivation, but having a modern protocol to work with resources on a computer doesn't seem too much to ask.

</comment></comment></comment></comment></comment><comment><USER17> I believe REST as Fielding defined it has some great benefits. But I'm not a purist. And actually, neither is the person who wrote this post. Because no matter how much the disciples try to wriggle there way around it, using cookies for sessions is not allowed.

"We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.Session state is therefore kept entirely on the client." \- from Fieldings dissertation.

To be fully compliant you have to do use something like HTTP Basic Auth, where you resend the username and password with each request.

I think you should use cookies to store a token that the server can then use to determine whether the "context" of the request is "logged in" or not. I do it. But it's technically a violation.

<comment><USER18> I question that idea. Cookie is a standard header. So is Authorization. It's up to the server to require either. Basic auth header removes the need for a handshake to negotiate tokens. Authorization: Bearer (token) is now a standard. I suppose Cookie: (token) could be too, but too many people felt dirty.

My point is that Cookie does provide the credentials required for the call contex, this fulfilling the self containment requirement.

<comment><USER17> As I read it, the problem is not the mechanism by which a session is maintained, but the very existence of a session at all.

<comment><USER18> I know that's what people think. But a JWT in a cookie doesn't strike me as worse than basic auth.

</comment></comment></comment></comment><comment><USER19> Missing anti pattern: consider URLs insecure, especially if for a web browser. Don't include customer details (name, email, account number, etc) or search queries (free text) unless you have determined the security settings on your logging, audit, proxies, .., all conform to data protection requirements that suggest they should be encrypted and only visible to necessary staff. If you expect pages to be bookmarked or shared, then consider the security impact of where they are stored on local machines too, including in caches if your company is silly enough not to enforce disk encryption for all users.

<comment><USER20> > consider URLs insecure, especially if for a web browser.

A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out.

It gets even worse. Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in.

The page also doesn't use HSTS so is easily vulnerable to SSLStrip.

<comment><USER10> > A web site I used recently puts your session ID in the URL. If you log in, > then alter the URL to remove the session ID, you appear logged out.

Nothing inherently wrong with that, but it depends on the situation.

> Clicking the "Log out" button on the page simply removes the session ID from > the URL. If you go back and reload the web page with the session ID in it > again, you still appear logged in.

That's bad.

</comment></comment></comment><comment><USER15> My #1 complaint is there is no OOP client available from service provider. i.e. building a driver to consume the response and turn that into your client code. The irony is I often write my own harness for REST service, and those are generally object-oriented, because I don't want to speak HTTP over and over. Basically I built my a client while writing test, but I need to write test to assert my client which was developed to help writing my test.

<comment><USER21> SOAP works that way. But that has its own set of problems...

</comment></comment><comment><USER22> Anti-pattern #1: Using REST. It's just cargo cult along with everyone describing it and then implementing it differently. The only good part it has is how to layout the URL, and even then it's just common sense.

<comment><USER23> One can't really fault REST for the flawed implementations - Fielding's thesis is very explicit about what REST is and isn't.

Just because something becomes an often-misapplied buzzword doesn't say anything negative about the original concept so much as the people mis- implementing it.

</comment></comment><comment><USER24> seriously i dont really care whether an api is restful or restish. at the end of the day its all the same to me. just give me an api endpoint, request and response objects nicely documented and i am golden.

</comment><comment><USER25> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense?

What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more flexible than trying to cram your functionality into GET, POST, PUT, PATCH, or DELETE?

If you find yourself using a lot of these anti-patterns, maybe you should consider switching to something a little less "REST-ful".

<comment><USER26> Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start).

REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design.

It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON- returning APIs were attractive because processing XML with circa-2006 "cross- browser" nightmare-mode Javascript was about as pleasurable as pulling teeth.

People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are.

During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time.

Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.

<comment><USER16> > _REST is not fundamentally inappropriate, it just needs a lot of careful > design about domain objects, link relations, and media types. Generally, > people are not very good at thoughtful design._

Especially if it's not worth the effort.

<comment><USER7> Generally, people are not very good at determining if thoughtful design is worth the effort.

Yes, waterfall was a mistake, but design-nothing is mistaken too. Thinking before doing helps avoid waste & rework.

</comment></comment></comment></comment><comment><USER27> Same title, different article from a few months ago: [https://news.ycombinator.com/item?id=12479370](https://news.ycombinator.com/item?id=12479370).

<comment><USER28> This provides a very concise and to the point explanation of the original article.</comment></comment>


Nikola Tesla Pitching Silicon Valley VCs - <AUTHOR> http://www.youtube.com/watch?v=zngK13FMgXM

<comment><USER2> That made me laugh out loud.

</comment><comment><USER3> Haha. This is awesome! :)

</comment><comment><USER4> Infuriatingly accurate.</comment>


An Experiment with Checking the glibc Library - <AUTHOR> http://www.viva64.com/en/b/0237/

<comment><USER2> I'm not buying these conclusions - on a quick scan, the "strange expression" isn't wrong: the code is scanning to find the first character that isn't a colon. The check against the zero byte is harmless, and I could imagine _other_ static analysis tools insisting on it (as cheap insurance against scanning off-the-end).

As for the "shifting negative integers is undefined behavior", this is a technically-true statement that's been practically-false for quite a few years - does _anybody_ still use a machine that doesn't use two's-complement integers?

<comment><USER3> The strange expression does seem wrong to me: the loop should terminate on end-of-line or ":", so continue while not end-of-line and not ":".

I _think_ you're right that shifting negative integers is fine on most any platform you're likely to encounter, but until recently one could also assume that adding two signed integers would wrap in practice, despite being undefined in theory; due to gcc optimizing ever more aggressively, code assuming that signed integers wrap is now broken (see e.g. [http://thiemonagel.de/2010/01/signed-integer- overflow/](http://thiemonagel.de/2010/01/signed-integer-overflow/)). So I'd be careful with shifts of negative integers in my own code.

<comment><USER4> It's skipping over ':' characters (which serve as delimiters) to get to the next token of the string (or end of line). So it looks correct, but the check for end of line is superfluous (unless any architecture uses ':' as end of line marker of course).

I think it is more likely it looks the way it does because it was made by copy-pasting and editing the loop a few lines further down that copies a token:

      while (categoryvalue[0] != '\0' && categoryvalue[0] != ':')
        *cp++ = *categoryvalue++;

As for the shifting, I would assume glibc is free to expect whatever holds true on the platforms it currently supports. But fair enough warning about it in a analysis tool.

</comment></comment></comment><comment><USER5> _The compiler is allowed to remove the call of the memset() function when compiling the Release version. Well, it is actually obliged to do so for the sake of optimization. Since the 'temp_result' buffer is not used anywhere after calling the memset() function, the function call itself is not needed too._

I'm constantly amazed by the perversity of 'compliant' compilers, but can this be true? It seems really unlikely unless memset() is treated specially in the spec.

Presumably a compiler is not 'obliged' to remove calls to write() or free() just because the argument is not used again after the call. How can it tell the difference?

I've always presumed that if I call a function in a shared library, that the call will be made. Is this not the case?

<comment><AUTHOR> > I'm constantly amazed by the perversity of 'compliant' compilers, but can > this be true?

V597 - [http://www.viva64.com/en/d/0208/](http://www.viva64.com/en/d/0208/)

Zero and forget -- caveats of zeroing memory in C - [http://www.eliteraspberries.com/blog/2012/10/zero-and- forget...](http://www.eliteraspberries.com/blog/2012/10/zero-and-forget-- caveats-of-zeroing-memory-in-c.html)

Overwriting memory - why? - [http://www.viva64.com/en/k/0041/](http://www.viva64.com/en/k/0041/)

<comment><USER5> I think I understand those issues, and I agree that this is potentially a real bug. It's the statements in your description I'm not sure I agree with.

I do not believe though that a compiler is allowed to remove a function call to the external library function call memset(), as it does not know whether there are any side effects to that call. It does not matter if I use the argument again afterward, a library function call will not be optimized out. Consider: what if at runtime I link to a different library where memset() performs IO?

The issue is that there is that there may be no function call to the library function memset() in the source. Rather, memset() may be defined as a macro such that the memory manipulations are inlined. Since the optimizer sees only these memory operations (rather than the function call), in the absence of a 'volatile' declaration it can legally delete them.

Thus whether this is actually a bug depends on whether the compiler treats memset() as a builtin macro. This is only a bug if there is no function call in the source by the time the preprocessor has done its work. One does not have to live in fear that a compliant compiler will delete non-local function calls. Or at least if it does, it's a bug in the compiler.

</comment></comment></comment><comment><USER6> >One might expect the glibc library's code to be written in such a way as to provide maximum portability.

Its worth noting portability was one of the reasons cited by Debian for moving from glibc to eglibc.

</comment><comment><USER7> I am shocked to see the strlen expansion. Is it common or something specific for some very special compiler options? I can't imagine a lot of cases where I would want that in my code.

</comment><comment><USER8> Looks like yet another dependency that I'll have to build from source code, and test, fix, and refactor myself.</comment>


Markus Frind Drops His $60k/yr Comscore Account for Compete.com's Free Statistics - <AUTHOR> http://plentyoffish.wordpress.com/2007/05/08/measurement-firms-end-of-the-line/ <comment><USER2> So, you can find out how your site ranks among people who install Compete.com's toolbar? How does this differ from Alexa?

<comment><AUTHOR> _"How does this differ from Alexa?"_

It's done much better. Alexa was bought by Amazon so innovation stopped. Compete.com is still improving at startup-speeds and becoming a pretty kickass tool.</comment></comment>


NFC Data Dump: Part I - <AUTHOR>

NFC technology and concepts sprang from RFID (a family of technology itself, operating across 4 very different frequencies) technology. RFID emerged originally as a replacement for barcodes in the supply chain. The metrics of focus within the supply chain  were on read range and tag_reads/ second. NFC operates at 13.56MHz.  In RFID, you had the reader that was powered, and the tag which was a powerless inductor with a EEPROM chip attached. The reader is the transceiver, the tag is a transponder. NFC turned this paradigm on its head-> the transceiver/ transponder were one. In ISO RFID standards, you had ISO 15693 and ISO 18000-3 that focused on the supply chain; and, ISO 14443A and 14443B which focused on security/ data rate ->payment->passport. Sony purposed a 14443C standard for the FeliCa chip, but that failed. NFC technology only works within a range of 4 inches (10cm) by standard, but 2 inches in reality.<p>I've got a ton more knowledge about NFC, but I don't want to spam HN if there is no interest. If there is interest, I can go into silicon mfgs and device mfgs  (like VIVOtech, about to go IPO) <comment><USER2> I am very interested. Especially about mass production costs, information about contract manufacturers/design firms for NFC components/designs friendly to startups, tech challenges in noisy (as in EM noise) and crowded (as in dozens/hundreds/thousands of NFC devices in a small area) environments, regulatory environments around the world (as applicable), adoption stories and results, security concerns.

Thanks!

<comment><AUTHOR> Tags only cost about $1. If you go for volume you can reduce that cost. UHF tags used in the supply chain now (e.g. wal-mART) are 900MHz, and a whole different ballgame.

</comment></comment><comment><AUTHOR> Silicon providers that make tag ICs (transponders):

NXP Semi- (formerly Phillips semiconductor) \- most prominent being Mifare (14443A) Texas Instruments- (15693/ 14443B) Broadcom- through Innovision acquisition (14443B) Infineon- (1443B) they got the contract for US passports (I read and have a 500 page spec; NDA required)

<comment><AUTHOR> Silicon providers that make reader ICs (transceivers):

1) NXP semi 2) Sony Felica- very guarded, about everything 3) Melexis- they allow TI to repackage, but their IC can be used to call commands of all kinds; it isn't clear their Ip rights beyond 14443B. French Telecom has IP rights here.

Oops, I forgot: 4) Inside Contactless - French company (Visa is one strategic investor)

</comment></comment><comment><AUTHOR> ISO 18092 has two parts, and part 2, where your phone is just a passive tag, is not currently possible, This technology has been stagnant for 4 years because Visa/ mastercard/ amex have been fighting att/verzon/tmobile over who gets the fees.

</comment><comment><AUTHOR> Can someone help explain to me why the HN community isn't interested in the technological underpinnings of the next of wave payment technology? [I, personally, prefer cash.]

</comment><comment><USER3> When are we getting those RFID microtags which you can eat with the food in restaurant, and have your stomach scanned when it's time to pay?

<comment><AUTHOR> This is my attempt at being serious because NFC can enable a_lot of companies and I want the smart folks that read HN to be as informed as possible.

<comment><USER4> I haven't spent much time reading or thinking about NFC, but I'd love to hear some thoughts about what industries & companies NFC could enable. Outside of payments & access control/authentication, what other opportunities do you see in the industry?

<comment><AUTHOR> Imagine not having to check-in at the desk to get into your hotel room, but instead being sent your "key" digitally. When you get to your hotel room door, you simply tap your phone on it. These were use cases we used 4 years ago, before the rise of smartphones.</comment></comment></comment></comment>


The impact of gratitude on adolescent materialism and generosity - <AUTHOR> https://www.tandfonline.com/doi/full/10.1080/17439760.2018.1497688 <comment><USER2> My friend and I discussed this today and are still left without a lot of good ideas for our kids (who are mostly normal), but show shocking levels (to us) of materialism and lack of gratitude.

What's developmentally appropriate? When is a kid ready to focus away from shiny stuff onto what matters for a good life?

<comment><USER3> Just make sure they learn to recognize the value of trans-material assets: one can loose their financial wealth in an instant easily, but their reputation, skills, knowledge, intelligence, health, psychological capacity, inner dignity and freedom of compassion, unconditioned vision and decision-making are less volatile. Understanding this is the first step upwards and is enough for many. Eventually, as the consciousness develops and matures a subject can also recognize these assets are also volatile and seek forth to meet their true self that actually owns these and is the only reliable invariant in their subjective universe.

At the same time try to avoid values dichotomization so the kid won't grow up with a destructive idea of financial wealth being a bad thing to pursue.

If their intelligence seems not sufficient try to make it fun for them to play n-back games like BrainWorkshop, their intelligence will develop stronger and my experience suggests it helps to grok all kinds of stuff (including even transcendental matters!) a lot, in whatever an age (it in fact has enhanced my own mind capacity enough to instantly realize that life in a society is not a zero-sum game and it is usually more beneficial for myself to help others to develop, succeed and strive than to care about maintaining competitive advantage over them and that in whatever an argument the primary objectives are to understand the opponent (whatever bizarre they may sound and regardless to whether or not they're wrong) and enrich your vision while winning the argument is a secondary objective and even happens to be irrelevant in many cases).

<comment><USER4> > Just make sure they learn to recognize the value of trans-material assets: > one can loose their financial wealth in an instant easily, but their > reputation, skills, knowledge, intelligence, health, psychological capacity, > inner dignity and freedom of compassion, unconditioned vision and decision- > making are less volatile.

Your post has good aim but I don't believe this is the case. Financial wealth is relatively trivial to safeguard after a point - particularly more stable forms (if you own a home outright, in a jurisdiction without property tax, it's essentially yours).

By contrast, one could wake up tomorrow suffering amnesia, could be hit by a car, or suffer any number of health ailments that would drastically curtail those "inner" attributes.

<comment><USER3> Everything may happen but I feel like some things are generally easier to take with you wherever the life may throw you.

</comment></comment></comment></comment><comment><USER5> I grew up poor and never had a strong desire for material things. I don't know if growing up poor is the reason for this, but I do know that not having access to "fancy" things a kid might have access to, made me spend a lot more time playing outside and keeping occupied with activities. Of course this was all before I had access to a computer. The moment I discovered Age of Empires, I had a strong urge to have my own computer.

</comment><comment><USER6> By the metrics, the most generous person in the world is Bill Gates who has given away something approaching 30 billion dollars. Maybe there is an argument that he isn't materialistic, but I think the evidence is against that.

I suspect they are misusing "materialist" in this context and they meant "selfish". The link is selfishness causes materialism, not materialism causes selfishness.

<comment><USER7> There is absolute and relative generosity. On absolute terms Bill is the most generous. On relative terms even after giving away $30b he still has more money than he could ever spend so there is really no personal sacrifice made.

<comment><USER8> Actually, on relative terms I think he has given away roughly half the money he has ever earned, which makes him exceptionally generous relatively speaking.

<comment><USER9> I stopped calling myself Christian as a result of reading the Bible, but it does have some interesting takes on this topic:

"""Amen, I say to you, this poor widow put in more than all the other contributors to the treasury. For they have all contributed from their surplus wealth, but she, from her poverty, has contributed all she had, her whole livelihood."""

[https://en.m.wikipedia.org/wiki/Lesson_of_the_widow%27s_mite](https://en.m.wikipedia.org/wiki/Lesson_of_the_widow%27s_mite)

<comment><USER8> I don't think this story is useful because it makes poverty imaginarily virtuous and downplays the very real benefit of philanthropy. In absolute _and_ relative terms, Bill Gates is lightyears ahead of nearly everyone, since he both pledges billions of dollars to charity and also pledges (if I remember correctly) a majority of his money to charities. Would you mind explaining why you think it's better for the woman to donate what little she had than the rich to donate their surplus?

<comment><USER10> It's not depicting poverty as virtuous it's depicting _sacrifice_ as virtuous.

Bill Gates is sacrificing basically nothing by giving away half (or even 90%) of his wealth. He lives the exact same life of supreme comfort that he did before.

Weirdly this is one of the few things the bible was actually abundantly clear about (and it's a pretty good point).

</comment></comment></comment></comment></comment></comment><comment><USER11> What I realized as I get older and have met many different people, is that, everyone, is, judgmental. Of course, different people value different things. Some judge by wealth, some by looks, some by height, skin color, hobby, manner, education, intellect, family background, job, way you speak, way you act, etc, etc.

Why are some judgmental criterias more acceptable than others? I mean, compared to many of the less change-able traits like look, skin color, where you are from, intelligence, etc, isn't wealth, being acquire-able, a somewhat more "fair" criteria to be judged on?

<comment><USER12> No, because wealth is not fairly distributed. The biggest predictor of wealth is being born rich. Looking at only the best case is not sufficient to call a criterion "fair."

<comment><USER13> Is anything truly "fair" then? Even people's decisions and actions are affected by their genetics and upbringing, none of which are really fair. By this logic it's unacceptable to judge people on anything.

<comment><USER14> > By this logic it's unacceptable to judge people on anything.

Why do we need to judge people at all? If it is simply to feel superior, you can just make stuff up. "Look at that person with/without an iPhone while I don't have/have one."

<comment><USER12> IPhone is just a proxy for wealth. I suggest instead, "Look at that pathetic guy trying to justify evil actions by making wealth at any cost seem like a virtue."

</comment></comment></comment></comment></comment><comment><USER15> They didn't measure materialism, and very poorly measured generosity.

They had some of the participants journal what they were grateful for, they paid all the participants, and they suggested that participants make a supposedly anonymous donation of cash to an unknown cause.

Keeping the money is supposedly materialism. No, it is not. Spending the money on frivolous status symbols might be materialism, but that wasn't measured. Keeping the money long-term, or spending it on something of importance, is financially responsible. Giving the money to an unknown cause (might even be an offensive cause) is foolhardy.

</comment><comment><USER16> Now, what that tells us about action in opposite direction? How to spoil the kid? Tell it that he should feel no gratitude because wealth distribution is random and that hard work, merit, or discipline matter.

</comment><comment><USER17> > According to research, materialism has been linked to a variety of mental > health problems, such as anxiety and depression, as well as selfish > attitudes and behaviors.

It would be interesting to many here, I suppose, to find details of such research. Also comparisons of problems caused my materialistic world view versus idealistic world view could be interesting.

However we may easily trip into religious disagreements here, which are both burdensome and seem to be quite outside of the YC area. May be we best leave this topic undiscussed here?

<comment><USER18> > comparisons of problems caused my materialistic world view versus idealistic > world view could be interesting

Materialism ties your happiness to the state of a vast and unfriendly external system that you, particularly if you are a child in a non-wealthy family, cannot control. Suppose one day materialistic instincts - manipulated by advertisers and wealthy, high-status peers - inform you that you ought to acquire an expensive Thing to maintain your status and sense of self-worth. Your parents are unwilling or unable to provide the Thing for you. You, as a young person, cannot earn or save enough to buy the Thing on your own. As a result, you become unhappy. The situation repeats frequently, as materialistic instincts then go on to tell you that you ought to acquire Thing_2, Thing_3, etc.

<comment><USER19> I don't know about that but my parents always said: Money doesn't bring happiness, but being unhappy in a Porsche sure as hell beats having your old clunker break down on the way to pick up your kids from kindergarten.

Money solves problems. Fewer priblems makes you happier.

<comment><USER20> > Porsche

> Fewer problems makes you happier.

Ironically the "old clunker" is likely to generate fewer problems that cost less.

I recently had someone complain to me about getting their newer BMW serviced at service centers; I told them you could always buy a 10 year old car that you could take anywhere; like me.

<comment><USER19> The problem is when your choices are "Do I fix my car or buy groceries this week"

</comment></comment></comment></comment></comment><comment><USER21> tldr: get your kid to express some gratitude. Eg: reflect around the dinner table and be thankful for the food.

<comment><USER22> I will agree so, since I discovered this and how this and positivity affect my perception I practice it daily like a meditative practice . basically it prolongs your instant gratification.

</comment></comment><comment><USER23> My 2 centidollars: Consistent boundaries and "no" to almost everything. Dumpster diving, second hand stores and DIY maker craft_ship. Resourcefulness over new and shiny. Occasional extravagances where it makes sense.</comment>


Ask HN: How do you market a Chrome extension? - <AUTHOR>

I recently launched a Chrome extension that adds audio voice commenting capability on top of Facebook, called "Talk and Comment".
Question is, have you ever marketed correctly a Chrome extension? given the fact that they're not being featured on the Chrome webstore.
Any real-life case would be appreciated. <comment><USER2> I have a chrome app (similar).

Make an informational website.

Basic "5 page site" with marketing information and documentation can be a great source of drip traffic.

Make sure the "download" link is on every page and within reach.

The whole concept is similar to marketing an app, albeit on a different store. Somebody else might know about how to get featured, and much like the app store, that also certainly helps your numbers.

If I type "your extensions name" into Google, it's feasible to cover the first page in properties related to your extension:

1 chrome store link

2 your marketing site

3 prominent app/extension review

4-6 social media pages

7 - 10 get creative

</comment><comment><USER3> The fact that a majority of the reviews you have so far mention you by name makes it look like you encouraged friends and/or colleagues to post them.

<comment><AUTHOR> Never.

</comment></comment><comment><USER4> i got wakeup.io in lifehacker within 24 hours of building it

you just have to be clever

we have chrome extension w/200 users

<comment><AUTHOR> Well ... TalkAndComment kinda got 600+ active users in 24hours. I might be lucky, but not clever enough lol

</comment></comment><comment><USER5> LifeHacker and similar blogs?

<comment><AUTHOR> Similar blogs such as ...?

<comment><USER6> [https://www.google.com/search?q=related%3Alifehacker.com](https://www.google.com/search?q=related%3Alifehacker.com)

</comment></comment></comment><comment><USER7> I have no experience. Just wanted to mention the prominent case of a solo teenager winning a hackathon for her Chrome-extension relating to TV shows [http://www.motherjones.com/media/2013/05/meet-17-year-old- sa...](http://www.motherjones.com/media/2013/05/meet-17-year-old-saving-you- game-thrones-twitter-spoilers)

I'm kind of kicking myself for not doing more chrome extension work. We consume such a variety of information and Chrome has huge flexibility in working with that info...seems to have a lot more potential usefulness in our day to day lives, and plus, you don't have to learn a new IDE and language

<comment><AUTHOR> I do 80% on my recreational programming building Chrome extensions. It's exiting, challenging, and really fun. Try it.

</comment></comment><comment><USER8> you ask Moad to do it for you !!</comment>


Google Glasses & Sergey Brin on the Runway - <AUTHOR> http://runway.blogs.nytimes.com/2012/09/09/dvf-gives-google-glasses-a-spin-on-the-runway/

<comment><AUTHOR> For those of you not in NYC, Fashion Week takes over the city twice a year, and these runway shows are huge productions. Lots of money & time goes into not only the clothes, but also the runway events themselves -- especially with the major designers like this chick Diane von Furstenberg (wife of Barry Diller, founder / CEO of web giant IAC). Lots of celebrities show up, and photos from the events show up all over the press. Hardly the place I'd expect to see Google Glasses and Sergey.

Which is why this is so interesting. Seems Google is making a push for Glasses to be "hip", and not just a toy for us geeks and hackers. Not only did Sergey sit on the front row, but the models & designers wore Glasses during the show, and Sergey walked with the designers at the end. This last bit is a rare thing for any of the regular celebrity attendees to do, much less Sergey Brin who I doubt has ever been to a runway show before.

Think of it like Sergey attending a major opera or orchestra performance, and then being brought up on stage at the very end when everyone is clapping for the director/singer/conductor.</comment>


Announcing TypeScript 1.8 - <AUTHOR> https://blogs.msdn.microsoft.com/typescript/2016/02/22/announcing-typescript-1-8-2/ <comment><AUTHOR> For a more complete list of features, check out our What's New in TypeScript page:

[https://github.com/Microsoft/TypeScript/wiki/What's-new- in-T...](https://github.com/Microsoft/TypeScript/wiki/What's-new-in- TypeScript#typescript-18)

<comment><USER2> Woah! I love how little it takes to go from Swift to TypeScript in terms of context switching. That method declaration with generics is so nice looking.

I love TypeScript just wish it was easier to use with their libraries and editors. I know it's not as bad as previously but it's still a lot of work with Babel/webpack and etc.</comment></comment>


AppLovin to Be Acquired by Chinese Investor for $1.4B - <AUTHOR> http://fortune.com/2016/09/26/applovin-orient-hontai-capital/?xid=soc_socialflow_twitter_FORTUNE&utm_content=buffer150dc&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> Huge congratulations to the entire team! Their growth has been really impressive to watch from a business perspective, and even more so from a technological perspective. If you're interested see [https://www.youtube.com/watch?v=mJbflVZJD4g](https://www.youtube.com/watch?v=mJbflVZJD4g) (their CTO's presentation about scaling to 15B ad requests per day) or this (slightly outdated) post on HighScalability: [http://highscalability.com/blog/2015/3/9/applovin- marketing-...](http://highscalability.com/blog/2015/3/9/applovin-marketing-to- mobile-consumers-worldwide-by-processi.html)</comment>


Ask HN:  Simple stock investment web-sites? - <AUTHOR>

I'm looking to get in on one of the IPOs coming this week (Service-Now), but I've never actually done any stock purchasing before outside of 401ks, etc.  Can anyone recommend a website that's somewhat user friendly for this?  I know there's stuff like e-Trade/Scottrade/etc, but I figure HN will know about any good alternatives if they exist. <comment><USER2> Fool.com has a bunch of tutorials (<http://www.fool.com/how-to- invest/thirteen-steps/index.aspx>) and some premium newsletters that can help you through this process. From what I can tell, there aren't a lot of simple alternatives to the big brokers. We do have a comparison table (<http://www.fool.com/how-to-invest/broker/index.aspx>) that covers the pricing and features of a lot of them.

Disclosure: I work there as a developer.</comment>


No More Captchas - <AUTHOR> http://nomorecaptchas.com/ <comment><USER2> The research seems to be from here... [http://oxford- biochron.com/](http://oxford-biochron.com/)

And it's linked to google, facebook, and "others" ...

Since I don't use google, facebook, or "others", I don't think it would work for me.

EDIT: I guess I was looking at the wrong product. However, my guess is the system measures mouse movement within the window or click rate or some variation of these. It said somewhere that an HTML5 browser is necessary, so I imagine the product would not work with a text browser. In any case, it seems dubious. If Bayesian email filters can be fooled, so too can an otherwise untested human noise detector in the "real" world of the cloud...

</comment><comment><USER3> The only technical details I could find on the site were:

> The method is called biochronometrics and it maps behavior based on a series > of complex algorithms. 5 million live tests show that bots can't mimic human > behavior when biochronometrics are applied.

and:

> NoMoreCaptchas analyses behavior while a user name and password are being > entered and determines if the user is human or a bot.

So presumably it monitors mouse and keyboard events during login; particularly the timing, judging from the name "biochronometrics"...

</comment><comment><USER4> As the kind of person with technical knowledge to make a relevant decision, they fail to convince me that it is legit. So what if the page thinks I am human? If it is supposedly so accurate, how do I get to witness a failed case?

I do not know if they are marketing to nontechnical managers who force a decision on "Yes, boss" developers.

Next, what if I want to have a mobile app? How do I secure a sign up process there? (without reverting to a web form)

</comment><comment><USER5> Looks shady. Image from their site [0] that is supposed to tell me that I'm human or bot is just a gif.

[0] [http://nomorecaptchas.com/what-is- nomorecaptchas/](http://nomorecaptchas.com/what-is-nomorecaptchas/)

</comment><comment><USER6> Frustratingly there is very little technical information to be found on the website.

They're essentially saying "hey, here are some words we made up, now trust us, it works!" without delving into any real detail with examples.

<comment><USER7> From the website:

The method is called biochronometrics and it maps behavior based on a series of complex algorithms. 5 million live tests show that bots can't mimic human behavior when biochronometrics are applied.

That being said, yes, I would love to see some more technical details on the implementation...

</comment></comment><comment><USER8> This is less "no more captchas" and more "Buy our captchas, they work, trust us."

That should set off everyone's bullshit detectors.

</comment><comment><USER9> The method described is rather vague, but I think monitoring mouse movement and page scrolling should be enough to determine human user.

</comment><comment><USER10> I wonder his this fares with auto-filled forms by the browser and things like lastpass / onepassword</comment>


FOIA Machine by The Center for Investigative Reporting - <AUTHOR> http://www.kickstarter.com/projects/cir/foia-machine/

<comment><USER2> How is this different than what Muckrock is doing?

[http://www.muckrock.com/](http://www.muckrock.com/)

"MuckRock is an open government tool powered by state and federal Freedom of Information laws, a generous grant from the Sunlight Foundation, and you: Requests are based on your questions, concerns and passions, and you are free to embed, share and write about any of the verified government documents hosted here. Want to learn more? Check out our about page."

<comment><USER3> FOIAMachine dev here. There are a few projects operating in the space and it seems the more help being offered to get people asking their government for data and documents the better off we'll all be. There's gonna be some overlap, nothing is totally novel and I like to think FOIAMachine builds on some of the great ideas that came before it, including those generated by MuckRock. I see FOIAMachine different in a few ways. It has tighter controls for sharing requests with specific people (or keeping them private). We're building controls so you can make requests more social. What that means is sharing a request with others to build support publicly. And of course, we'll share what users make available via an API. Also, while we're asking for funding now the service will be totally free. It's built so users can help each other. It's built so you have the tools to stay organized. Once the code is done the hosting costs are minimal and it won't need much to keep the lights on and help people create their requests. MuckRock and Alaveteli are great and their creators have done yeoman's work. FOIAMachine approaches the problem from a different angle and I think it'll be a useful tool for a lot of people.

<comment><USER4> "FOIAMachine approaches the problem from a different angle."

FOIA Machine has been telling me this since 2011, and yet you continue to copy what we deploy, feature by feature. Seriously. I'd love to work together, and I already offered to open source our source code for you, but that's not an offer that has ever been taken up.

I'm always available to talk: firstname.lastname@example.com.

</comment></comment></comment><comment><USER5> It's kind of funny--you know that subcomponent of PRISM where the government sends a machine-readable subpoena, and a corporation, in response, automatically runs a query to pull together a user's records and drop them in a government-accessible dead-drop computer? If done correctly, this would basically be the same thing, but for citizens "subpoenaing" government.

I say "if done correctly" because it currently sounds like it only handles the "send" part of the FOIA request. It'd be a lot more convenient if it also used the Center for Investigative Reporting as the receive address, scanned in and OCRed all the FOIA'ed documents that get received... maybe even have some lawyers pick through each received document and provide analysis + highlight interesting bits, like Groklaw does. Is that part of the plan? (The non- receiving version could always be kept in place either way, for when people want to just get at their own personal records.)

<comment><USER4> Hi derefr!

That's exactly how we operate, and we're working more on the "analysis" end of things now ([https://www.muckrock.com/news/archives/2013/jun/25/booz- alle...](https://www.muckrock.com/news/archives/2013/jun/25/booz-allen- hamilton-contracts-help-analyze-thousan/)). Would love suggestions on how we can do it better.

</comment></comment><comment><USER6> Another project with similar aims, which I worked on when I was employed by MySociety and which is used in several countries around the world is Alaveteli: [http://www.alaveteli.org/](http://www.alaveteli.org/) [https://github.com/mysociety/alaveteli](https://github.com/mysociety/alaveteli)

Alaveteli is based on the code that has powered the British site [http://www.WhatDoTheyKnow.com/](http://www.WhatDoTheyKnow.com/) for several years.

<comment><USER7> Also used in New Zealand: [http://fyi.org.nz](http://fyi.org.nz) \- it's awesome :D

<comment><USER8> Also used in Australia : [http://www.righttoknow.org.au](http://www.righttoknow.org.au)

</comment></comment></comment><comment><USER9> I couldn't quickly find if it is a proposed feature but...

A cool feature would be to crowd fund the feeds. After filing a request and it makes it through to the fee portion, list it somewhere so that users can chip in to unlock a request.

<comment><USER3> foiamachine developer here. this is a great idea. thanks so much!

</comment></comment><comment><USER10> It just reached its goal! Good job everyone!

</comment><comment><USER11> i just donated $25.</comment>


MIT researchers used Wi-Fi to recognize people through walls - <AUTHOR> http://gizmodo.com/wifi-networks-can-now-identify-who-you-are-through-wall-1738998333 <comment><USER2> Blogspam. Source is [http://gizmodo.com/wifi-networks-can-now-identify-who- you-ar...](http://gizmodo.com/wifi-networks-can-now-identify-who-you-are- through-wall-1738998333)

Paper: [http://rfcapture.csail.mit.edu/rfcapture- paper.pdf](http://rfcapture.csail.mit.edu/rfcapture-paper.pdf) (site is currently slow)

It doesn't use an unmodified wifi base station, of course. Squinting at their photos, it looks like it uses at least 16 antennas. It's basically a big 5-7ghz phased array radar. If it's got 16 radios connected to those 16 antennas, then it probably costs at least a thousand bucks.

It doesn't use wifi hardware, it doesn't use wifi transmission codes, it doesn't use wifi frequencies. It has nothing to do with wifi.

<comment><USER3> Thanks! Url changed from [http://www.theverge.com/2015/10/28/9625636/rf- capture-mit-wi...](http://www.theverge.com/2015/10/28/9625636/rf-capture-mit- wifi-tracking-surveillance-technology).</comment></comment>


NSA Analysts Intentionally Abused Spying Powers Multiple Times - <AUTHOR> http://www.bloomberg.com/news/2013-08-23/nsa-analysts-intentionally-abused-spying-powers-multiple-times.html

<comment><USER2> _The actions, said a second U.S. official briefed on them, were the work of overzealous NSA employees or contractors eager to prevent any encore to the September 11, 2001, terrorist attacks._

Horseshit. This "they were just doing their jobs _too_ well" line is just another way to sweep all of this under the rug.

<comment><USER3> It also fails to explain parallel construction. Every time the NSA tries to defend itself with these ridiculous claims made to earn PR brownie points, you can point at parallel construction to show that they are full of it.

</comment></comment><comment><USER4> Like the Manning/WikiLeak revelations, I kinda wonder at what point will the mainstream just get bored, move on, and essentially stop acknowledging the shock power of these revelations at some point...</comment>


The Lamp That Saved Coal Miners' Lives - <AUTHOR> http://mentalfloss.com/article/71969/show-tell-lamp-saved-coal-miners-lives <comment><USER2> It is sad reading the impact section at [https://en.wikipedia.org/wiki/Davy_lamp](https://en.wikipedia.org/wiki/Davy_lamp)

"The introduction of the Davy lamp led to an increase in mine accidents, as the lamp encouraged the working of mines and parts of mines that had previously been closed for safety reasons."

and

"Another reason for the increase in accidents was the unreliability of the lamps themselves. The bare gauze was easily damaged, and once just a single wire broke or rusted away, the lamp became unsafe. Even when new and clean, illumination from the safety lamps was very poor, and the problem was not fully resolved until electric lamps became widely available in the late 19th century."

Seems like it wasn't as successful as it is made out to be in this article.

<comment><USER3> An extreme example of [https://en.wikipedia.org/wiki/Risk_compensation](https://en.wikipedia.org/wiki/Risk_compensation). I was somewhat disturbed when I first learned that this is what actually happens.

</comment></comment><comment><USER4> I don't understand how a methane/oxygen reaction, once ignited, cannot travel through a metal cage… I'm sure it works but the "absorb the heat that caused the explosions" explanation doesn't make sense to me. Does anyone know in more detail how this works?

<comment><USER5> more details here:

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

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

[https://www.youtube.com/watch?v=u-GeraWUP6E](https://www.youtube.com/watch?v=u-GeraWUP6E)

The wire mesh drops the temperature below ignition temperature and also drops the pressure. Since the outer air remains relatively cool, the mesh presumably continues to shed some heat through contact with the outside air, and so doesn't itself reach the ignition temperature on the outside. Maybe sort of like how you can hold a flame to a paper cup full of water and even though the paper is dry on the outside, it won't catch.

</comment></comment><comment><USER6> Sir Humphry Davy (the inventor of the lamp) had an awesome honeymoon: [http://blog.jgc.org/2008/09/ultimate-nerd- honeymoon.html](http://blog.jgc.org/2008/09/ultimate-nerd-honeymoon.html)

</comment><comment><USER7> _The chemist received a medal from the Royal Society and was made a baronet; he even "designed his own coat of arms, showing the safety lamp encircled with a Latin motto which announced: 'I Built The Light Which Brings Safety.'"_

Excellent!

</comment><comment><USER8> From the article on Wikipedia:

"The introduction of the Davy lamp led to an increase in mine accidents, as the lamp encouraged the working of mines and parts of mines that had previously been closed for safety reasons"</comment>


Will TypeScript replace JavaScript in development? - <AUTHOR> I have used JavaScript for many years since before Angular1. Since then I have worked with Angular 1 and React. Tried a few javascript-replacement tools and never liked those. At a new implementation, I started with Angular2, didn't like it because thinking in React is addictive. But loved TypeScript and now switched to using React+TS. I think any large web-app nowadays requires a framework (read: ecosystem) like React, Angular or others. And it feels odd and substandard to not to use development and build tools like webpack.<p>I like TypeScript for many reasons and just don't want to code in plain JavaScript anymore. But I am concerned if TypeScript will end up dying just the way all other javascript-replacement frameworks ended. <comment><USER2> This is not at all my area of expertise, so take my opinion with a grain of salt. That being said, Javascript Flow seems like a better solution than Typescript. Long term, a sandboxed low-level VM like WebAssembly will hopefully catch on and allow web devs to replace all of these not-quite- javascript languages.

</comment><comment><USER3> TypeScript is Microsoft's front end language. It's not going to die off like other open source projects.</comment>