Google Chrome to stop back-button hijacking - <AUTHOR> https://chromium-review.googlesource.com/c/chromium/src/+/1344199 <comment><USER3> I implemented the history.pushState API in Firefox many moons ago. Dunno why I didn't add this protection then, other than, it was a simpler time. It was around then that we added the API for vibrating a phone and we all sort of said "eh, someone _could_ abuse this, but why would they?" (In my defense on that one I was on the side arguing that they would do it specifically for ads and we needed to lock it down.)

Anyway, I approve of this change.

<comment><USER4> Can you explain how this change stops abusers while still allowing front-end routing? I'm a bit confused because they seem mutually exclusive to me, or should I say they come together or not at all.

<comment><USER5> The commit comment explains, "Entries that are added to the back/forward list without the user's intention are marked to be skipped on subsequent back button invocations."

The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.

So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.

But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.

<comment><USER6> A lot of seedier sites already abuse these mechanisms, by doing nasty things when you click to close a GDPR notification, focus a search box, or similar intention.

Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!

<comment><USER7> Yeah but in that case the malicious website should only be allowed to push a single frame, allowing you to escape by going back twice.

This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.

</comment></comment></comment></comment></comment><comment><USER8> One by one, the Chrome engineers continue to chip away at the techniques in The Annoying Site [https://theannoyingsite.com](https://theannoyingsite.com) (warning: open in a secondary browser).

Talk video here: [https://www.youtube.com/watch?v=QFZ- pwErSl4](https://www.youtube.com/watch?v=QFZ-pwErSl4) Source code here: [https://theannoyingsite.com/index.js](https://theannoyingsite.com/index.js)

Well done.

<comment><USER9> What is allowing site JS to physically move the browser window on my screen and how do I burn this feature with fire?

<comment><USER10> This only works in popup windows. According to the guy who made this website [1] this is to stop cross-origin communication, which is quite interesting. But it also has the effect that if you force popup windows to appear in tabs rather than windows then you do indeed burn the feature with fire. And IMO it's worth doing anyway, because no one has the right to open a browser window on my computer except me. It's possible in FireFox by changing browser.link.open_newwindow.restriction to 0 in about:config [2].

[1] [https://youtu.be/QFZ-pwErSl4?t=558](https://youtu.be/QFZ-pwErSl4?t=558)

[2] [https://support.mozilla.org/en- US/questions/1066799](https://support.mozilla.org/en-US/questions/1066799)

<comment><USER11> FireFox used to have an option to disallow pop ups to move themselves... I can't find that setting anymore, and I think Chrome used to as well, it still might. It's one of the first things I disable on my browsers due to some prank sites using this tactic for maximum trolling.

<comment><USER12> I wonder what could possibly be a use case why they would allow it and even built an API/interface for that.

</comment></comment></comment></comment></comment><comment><USER13> I've recently noticed Chrome (71) on Mac is now hijacking the `Command + Q` shortcut and asking if I really want to quit. I appreciate people will occasionally shut down a Chrome session by mistake, but it seems a little ironic that they're clamping down on behaviour hijacking in one space whilst implementing it in another.

(Caveat: I'm not sure if this change is being committed by a Google Chrome dev or non-Google Chromium dev)

<comment><USER14> When using Command + W to close a tab, it's only a fat finger away to close the entire browser. Years ago that happened and it was a huge hassle since it wasn't easy to reopen all the tabs you had.

<comment><USER15> wasn't "reopen recent tabs" a launch-day feature for chrome?

<comment><USER14> I'm not sure. I remember hitting Command+Q a few times by mistake and losing whatever tabs I had open. Maybe I didn't know about that feature at that time.

</comment></comment></comment></comment><comment><USER16> Funny, one of the things that convinced me to switch away from chrome (back to Firefox) was when chrome got rid of the backspace-key-navigates-back. Sure, I could use an addon to restore the feature but .... why should I live with a browser that subverts decades of standard keyboard shortcuts?

<comment><USER17> It was a horrible keyboard shortcut that caused countless lost form entries. Just because something is standard doesn't mean it is good.

<comment><USER16> Google had several possible solutions:

\- warn before navigating

\- give options for the keyboard shortcut

\- change shortcut unilaterally

They chose the third, which some (likely the overwhelming majority) preferred. I didn't, so I switched to Firefox. We're both happy this way I guess.

<comment><USER17> >warn before navigating

This requires too much page context. A search field being partially filled is very different than a long registration form being worked on.

>give options for the keyboard shortcut

You said yourself, they released an extension for this.

<comment><USER16> > You said yourself, they released an extension for this.

Oh was there an official one? At the time, the only extension I could find was some slightly-sketchy third party one that allowed you to set hot keys for many things.

> This requires too much page context. A search field being partially filled > is very different than a long registration form being worked on.

Fair enough.

<comment><USER17> >Oh was there an official one?

Yes, Google released an official extension to coincide with the update that removed the hotkey.

[https://chrome.google.com/webstore/detail/go-back-with- backs...](https://chrome.google.com/webstore/detail/go-back-with- backspace/eekailopagacbcdloonjhbiecobagjci?hl=en)

</comment></comment></comment></comment></comment></comment><comment><USER18> Only the most anti-social sites break the back button, I kill the tab of any site that does.

What I hate and is much more common is the "do you want notifications". I'd love a "never ask about notifications again" option.

<comment><USER19> That's an option right in the settings. Along with all other permission requests.

Just set it to "never ask" or something similar and it will auto-deny all notification permission requests.

You can also enable it for specific sites if you want.

<comment><USER20> There is a bit of hubris when it comes to websites even asking to allow notifications. No site is that important. why would I ever want to enable notifications under any circumstance ever. I generally get badgered about it by a site I'll probably only visit once.

<comment><USER21> It makes sense for web applications that are real applications. The CI suite my company uses sends notifications for a passed/broken build, which is a reasonable use. Mail sites can send new messages.

The problem is that there's lots of content the publisher thinks is notification worthy, but not the user. No, I don't need a notification every time you post to RandomNewsSite.com.

<comment><USER22> "The CI suite my company uses sends notifications for a passed/broken build, which is a reasonable use. Mail sites can send new messages."

That would still annoy the hell out of me.

<comment><USER20> This is basically why I don't read work email. If it's important, someone will come over to my desk asking if I got the email within 30 seconds. Hell I stopped listening to voicemail from a previous boss and just deleted it, For three years or so and it never caused a problem.

My default is now "select all, delete"

<comment><USER22> I just leave my email client and systems report open all the time. That way I can easily glance over and check if something needs my attention when I have some attention to spare, rather than be distracted by a notification appearing randomly over my work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> The full page email popups/page dimming are the worst, I hate that it has caught on so much.

<comment><USER24> At least they have a nice big div to hit with your element blocker.

</comment></comment><comment><USER25> I know why Google has reacted now, I noticed few month ago that "clickfarm" websites began visually spoofing popular websites.

You accidentally click "clickfarm.com" from, say, google.com; then you press back button, it seems that you are "back," by the moment you click on another link, you realise that google.com page was fake, and is stuffed with invisible ads.

<comment><USER26> What purpose does invisible ads serve?

<comment><USER27> I think opacity set to 0, you didn't knew but you saw the ad and this will count as view?

<comment><USER25> Google looks for obscured ads, but there are new ways of tricking both the bot and the ads code coming out almost monthly.

What they look above all else are the organic clicks from clear IP ranges.

</comment></comment></comment></comment><comment><USER28> Please also fix the back button on the PDF reader built into Chrome; pressing the back button on my mouse seems to go nowhere.

</comment><comment><USER29> I quit using chrome, but it would be nice if they alerted you to the fact that the site is hijacking the button. Personally, when sites do that, I immediately add them to a block list because they are shit and I don't want to visit them ever again. Now you'll never know.

<comment><USER30> How do you define "hijacking the button?" There are many valid uses of pushing state to history, and it's very difficult to distinguish a malicious use from a non-malicious use in the general case.

</comment></comment><comment><USER31> More in-depth discussion about the rationale and design process behind the intervention: [https://github.com/WICG/interventions/issues/21](https://github.com/WICG/interventions/issues/21)

</comment><comment><USER32> How does this work with single page apps where it's not uncommon to modify the history?

<comment><USER33> I mean, aren't SPAs kind of a hijacking of how browsers are intended to be used?

<comment><USER34> I get what you're saying, but browsers haven't been stateless url-loaders since the late 90s. JavaScript in general, cookies, local storage, and plug- ins are all compromises with "pure" http navigation that (a) can be abused but (b) offer some much needed client-side cooperation in maintaining continuity and reducing repetitive traffic with the server.

<comment><USER24> There are ways of doing SPAs without polluting the history. In fact, I find them less frustrating to use. If your design relies on cues taken from malware pages, that's on you.

<comment><USER34> This is a frankly ignorant statement about SPA design. Pushing history on major navigation events has nothing to do with malware patterns. It is way of making SPAs compatible with user expectations and protocol investments based on the non-SPA web. It allows them to use their own tools for bookmarking, link sharing, and history management rather than forcing a from-scratch experience when they come to the sites.

Accessible navigation patterns are a key part of making the web accesible to decentralized improvement. If every SPA was a black box with its own navigation regime, the web would regress to walled garden apps that characterize 90s desktop and early iOS ecosystems.

<comment><USER24> I fail to see how I can be ignorant of what I find less frustrating and more compatible with my user expectations.

>It allows them to use their own tools for bookmarking, link sharing, and history management rather than forcing a from-scratch experience when they come to the sites.

Such as the behaviour of buttons outside the sandbox the browser provides? To quote you:

>browsers haven't been stateless url-loaders since the late 90s

Why break the expectations of the back button to hack the other tools to work how you'd expect when, really, all of the features you're describing worked perfectly fine before SPAs. The very reason pages like this frustrate me are because they don't work with the history management I expect.

<comment><USER34> The ignorant part was accusing SPA authors of copying malware patterns.

Regarding your opinion, I'm still not sure what you are comparing / suggesting.

Are you saying that late 90s reactivity on the web was good enough? I think you are very much in the minority on that one.

Are you saying SPA authors shouldn't expose URLs for different navigation paths to the browser? I think you would be surprised at all the places your browser experience breaks, like not being able to restore tabs, or copy links to interesting news stories.

The _right_ way to do SPA is to design nav actions that feel like links, and only update the history in those. A user not watching carefully for page refreshes or net traffic shouldn't be able to tell the difference - <USER2> perhaps there are times this is happening on your browser that you aren't aware of because it _can_ be done smoothly.

<comment><USER24> Hijacking history is a pattern used by malware and trying to stop it has broken some honest websites. This happened with Flash, with Java applets, with popups. It shouldn't be a surprise. As I see it, you're considering the malware an acceptable sacrifice for having SPAs work slightly better (for what you value as better and I don't).

Websites as apps will continue to work, they'll either lose this functionality or use normal links - the kind that are good enough for Facebook et al. Or for Hacker News.

>Are you saying SPA authors shouldn't expose URLs for different navigation paths to the browser? I think you would be surprised at all the places your browser experience breaks, like not being able to restore tabs, or copy links to interesting news stories.

No. All of these work with links. Aren't you trying to fit a SPA shaped piece in a website shaped hole?

<comment><USER34> Links force a reload of additional assets, break ongoing socket connections, and at minimum requires a re-rendering of the entire DOM, which is a waste for many navigation actions that still deserve their own URL. In particular, the many tcp handshakes necessary for a total page refreshes are expensive on mobile.

As a concrete exampke, rich news experiences that let you scroll through preloaded stories benefit a lot from not needing to re-render all of the surrounding layout when the content changes, and from assigning a different url to each story.

Btw, I never said this was worth the current trade-off with malicious sites, just that the history features were originally inspired and still used by honest sites. Fortunately we have better options than all or nothing; sounds like Chrome is implementing a heuristic that makes sure url history can only be updated in some proportion to human actions. Another option might be a whitelist check like "<site> would like to update your history".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> This works with JS disabled:

[https://bugs.chromium.org/p/chromium/issues/detail?id=907167](https://bugs.chromium.org/p/chromium/issues/detail?id=907167)

<comment><USER36> Thanks - the mountain of JS on the other page failed on iOS

</comment></comment><comment><USER37> This is very much needed. Every site I visit through google news hijacks the back button. They only show their news letter signup page for the most part but still very annoying.

</comment><comment><USER38> How about stopping right-click hijacking and smooth-scroll hijacking too?

<comment><USER39> Right-click is very useful in some cases. I have some productivity apps I have built for myself using web technologies, and it's extremely useful to be able to have custom context menus. Since web applications are doing more of the work that native apps used to, I'm ok with some level of annexation of the browser's UX territory when a site can really justify it.

That said, I would be in favor of an option to disable it globally, or for certain domains.

</comment></comment><comment><USER40> Right now you can't close a tab with ctrl+w if the "Would you like to see desktop notifications?" dialog is up. For a second I thought this was a fix for that.

</comment><comment><USER41> Does this mean they no longer support history.pushState?

</comment><comment><USER42> Will this affect SPA routers? How is "without the user's intention" defined, does it mean programmatically added items or something else?

<comment><USER43> If the current event loop task ( you may need to read up on the JS event loop ) was spawned by something like a click event then it is marked as a "user interaction". These tasks can do things like opening a popup window, start audio playback etc. whereas normal tasks are normally blocked from doing this.

It's a clever mechanism but malicious sites tend to just attach a click listener to the page and trigger everything when the user clicks for the first time.

On the other hand it can also be a pain to program around this if you need it. Say you have a webapp that allowed you render an image then display it in a popup. But the rendering is time consuming, so you do asynchronously in the background. The user clicks the button and you start the render. When the render is complete you try and open the popup, but your now in a different task where the popup is blocked. The best way to work around this is to display a modal dialog, saying that the render is complete. Then when the user hits "ok" you can use the task that the event created to display the popup. But it might confuse the user why they need to confirm the render is complete.

<comment><USER44> Couldn't you open the popup immediately while keeping a reference, do the proceeding, then just manipulate the reference to the window you just opened?

</comment></comment></comment><comment><USER45> This is bad for my Electron app. I wish there would be a flag to disable all the web "security"(i.e isTrusted field requirements).</comment>


Break Up the Insulin Racket - <AUTHOR> http://www.nytimes.com/2016/02/21/opinion/sunday/break-up-the-insulin-racket.html <comment><USER3> I've been type 1 for over 30 years since I was a toddler. I could stand to lose a few pounds these days, but I am not fat, nor obese. Adjusting my diet would do very little to change the increasingly high amount I spend on insulin.

The cost of insulin over the last few years and as recently as the last few months has skyrocketed. Not just the fancy fast acting insulin, but even the regular stuff that you can buy over the counter without a prescription(R and NPH) has nearly quadrupled in the last 12 years. It's not an increase in manufacturing costs. It's price fixing by the two major players(Lilly and Novo).

You'd think that with Lilly significantly raising their prices a few months ago, that Novo Nordisk could make a killing, but no, they both did it at the same time. Funny how that worked out.

<comment><USER4> I have a relative that is type 1. A couple of years ago he went on a no carb diet and at xmas he was telling me that he now uses a lot less insulin and generally feels a lot better. He also lost some weight (he wasn't obese, either, but he now looks very trim).

Have you tried something like that?

<comment><USER5> I know you mean well, but managing this sort of thing is something that's extremely different from person to person, very hard to get right, and often a source of great personal pain for people trying and failing. Please refrain or be extremely cautious about enthusiastically telling everyone what worked for your relative.

<comment><USER6> While I agree it's worth being cautious about how you phrase any "advice", I think the parent post was perfectly reasonable. There was something that worked well for someone he knew, and he mentioned it in case it might help.

For context, I've been a Type 1 diabetic since around '85 and, as I get older, I'm becoming more insulin resistant (Type 2) also. While I've been able to keep my blood sugar mostly under control, I test my blood 4-10 times a day and sometimes need to take insulin 5+ times in a single day (sometimes it just doesn't "work" and I need to take more in smaller amounts to bring my blood sugar down. I can't just retake the original amount in case the first shot suddenly "kicks in").

</comment></comment></comment></comment><comment><USER7> I think the hardest thing for the American political system to grasp about our medical system is that spending more money is not the answer. We already spend 16% of GDP, about double what almost all other countries spend on health care and have worse outcomes.

I'm glad that there's some new thinking going on here that may lead to some movement. Unfortunately, all the incentives are aligned such that everyone who is making a ton of money off the system lobbies to make even more.

<comment><USER8> The insurance system is itself a racket. Putting even more people into the insurance system only makes insurance companies richer, doesn't do much for the average American.

<comment><USER9> True, that.

If pressed to name the single stupidest concept I've ever encountered in over forty years of life, I'd have to say it's the notion of selling "insurance" in a market where you know perfectly well that 99.9% of participants will eventually have to file expensive claims.

Communism is way up there, along with smoking, and religion, and then there's the time that Circuit City tried to sell their own proprietary brand of self- destructing DVDs. But none of them can compare, in terms of sheer forehead- slapping stupidity, to the idea of "health insurance."

<comment><USER10> Briefly, since I'm on mobile, I'll explain why I think you're completely wrong.

Insurance doesn't seek to prevent the inevitable. That's not why we buy insurance. We buy insurance to insure against catastrophic risk. Would you rather flip a coin and lose your house, or flip 10,000 coins where each toss risks $100?

Humans are risk averse, and there is plenty to say about the value of risk reduction. We buy insurance as a trade off: we know we're getting skimmed by the salesman, but our preference for reduced volatility means we gladly take a small certain loss instead of a possible huge one.

On the other end, insurance sales men don't just sit on their obligations. They swap risk and find complementary risks: it's highly unlikely a hurricane in Florida will happen at the same time as an ice storm in the north east. Tally up all the insurance salesmen and you'll find they all aim to hold a bit of each other's risk. They, just like us, prefer to take a small certain loss than a possible disaster.

This is the purpose of insurance: to dilute the 'pain' of singularly disasterous events across a large enough population so we collectively do better off.

Health insurance is supposed to be the same way: you shouldn't need insurance for buying aspirin at Walgreens. $5 ain't gonna kill you. What will seriously damage you is an unforeseen large medical expense. As it stands, most people don't really need much in the way of serious medical care- it's true to say that a small population of people incur far higher medical expenses than the rest of society. This is exactly the purpose insurance was designed to deal with.

I leave my discussion here. I recognize that there is something deeply unfair about leaving a population out in the cold. I agree, we ought to do something for them, but this is not a critique of our social policies at large. I mean to simply remark that insurance is exactly the financial vehicle that best serves to smooth out the consequences of unlikely yet expensive occurrences.

<comment><USER11> > Insurance doesn't seek to prevent the inevitable. That's not why we buy > insurance. We buy insurance to insure against catastrophic risk.

Ideally, that would be the purpose of health insurance, but in the USA its used to pay for essential health care such as regular visits to your dentist or general practitioner, or to get the negotiated rate on prescription drugs.

When people talk about the inevitability of healthcare use, they don't refer to heart attacks, an onset of cancer, or broken legs. They refer to chronic conditions like arthritis, or high blood pressure that will plague the vast majority of people simply because of their increasing age. These chronic conditions are seemingly inevitable, and are factored into the cost of health insurance.

</comment></comment></comment></comment></comment><comment><USER12> How timely: this just dropped in the NYTimes today as well, "A Do-It-Yourself Revolution in Diabetes Care".

[http://www.nytimes.com/2016/02/23/health/a-do-it-yourself- re...](http://www.nytimes.com/2016/02/23/health/a-do-it-yourself-revolution- in-diabetes-care.html)

Featuring the Open Insulin project. Many of the supporters of that project came from HN.

<comment><USER13> I'm a biologist who works in the pharmaceutical industry. I like the idea of open source insulin as much as the next guy. But. I just took a look at their website and it's a complete joke, frankly. It's basically a high-school science experiment. The sort of thing that a single undergrad could do in a few days. Compared to the thousands of man-years required to produce and test a new pharmaceutical product.

I wish them luck, but c'mon. Biopharma is not IT where a smart kid can compete from his garage. It just isn't.

The NYTimes article says "the hackers hope to be able to demonstrate the technological feasibility" rather than manufacture a drug. But everyone knows that it's technically feasible -- the challenge (and cost) is in the doing.

<comment><USER14> > Biopharma is not IT where a smart kid can compete from his garage. It just > isn't.

It isn't today, but it may be at some point. We tend to underestimate the effects of monumental shifts like we've had in IT. This project represents the first steps in that direction.

> The sort of thing that a single undergrad could do in a few days.

Even if this were true, the OpenInsulin project doesn't have a large institution's lab facility. Nor does the project have a government grant as benefactor. They are operating only off crowdfunding. It's obviously not enough to get through the FDA approval process, but IS enough to construct a roadmap to that end and make headway on a functional insulin producing organism. The project already has _E. coli_ making proinsulin. The experimental focus has now moved to methods of purification. They are also investigating the feasibility/cost of getting this through the FDA approval process for biosimilar molecules.

I think the real magic of this project is its open nature, which I find to be lacking in the scientific community. This is research that anyone can make meaningful contributions to. Science (specifically biology) can learn a lot from open source software.

<comment><USER13> > construct a roadmap

I just don't understand what this means here. Cloning a gene and expressing it in e.coli is something that has been routine for _decades_. Literally. These simple experiments won't provide a roadmap to do anything that we haven't known how to do for a long time. It's like a crowdsourcing project to raise money to write a "hello world" program. Seriously.

Open-ness is great. But "meaningful contributions" are generally made at the cutting edge of scientific research. The experiments described are nipping at the heels of science that was worked-out in the early 80s, so I fail to see how a meaningful contribution will be made here. Open source is great, but making headway in drug discovery or development is a Hard Problem and this doesn't strike me as a serious effort. Just my two cents.

<comment><USER12> I think you're being disingenuous for the sake of argument. There is a non- trivial scientific challenge of characterizing both proinsulin subunits and developing a protocol that works for public domain without adverse effects. Specifically, getting the sequence right to get the folding right.

Yeah, it's been done before but with different variations. To do so in a way that isn't locked up in IP is worthwhile. And it's a challenge that faces an uphill battle in terms of incentive and payoff. The crowdfunding covers that risk capital gap that would otherwise make this impossible. You could say their approach is a road not taken.

<comment><USER13> Fair-enough. I'm not an insulin expert so perhaps I don't appreciate the particular challenges here. But the way it was described on the website didn't make the task sound too impressive.

I was also struck by the money involved. ~$15k will pay for an experiment or two, as they indicate on the website. It takes many thousands of experiments to get anywhere in Biopharma.

So... it's a nice start, and maybe a worthwhile challenge, but it hardly seems like a serious effort. And not everyone realizes that, so I thought it was worth pointing out.

<comment><USER12> Yes, $15k would not be the same for a biopharma company, but they explicitly do not have the same goals of a biopharma company, nor are they a biopharma company, nor do their people come biopharma, nor are their users biopharma companies. Biopharma companies do not benefit from this, so why does it even matter what the status quo or state of the art of "doing science" is?

It's easy to be a cynic on HN, it's harder to think critically about why someone else would believe that it could work. You don't really get rewarded for empathy on here.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> > In much of Europe, insulin costs about a sixth of what it does here. That's > because the governments play the role of pharmacy benefit managers. They > negotiate with the manufacturer directly and have been very effective at > driving down prices. In the United States, we rely on the private sector and > a free market for drug pricing.

Cartels are an emergent phenomenon[1] and it is in the interest of a _fair market_ to not be "free market," whenever it leads to rackets.

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

<comment><USER16> The fact that drugs are cheaper in Europe does not mean the market there is fairer or more efficient: [https://en.wikipedia.org/wiki/Monopsony](https://en.wikipedia.org/wiki/Monopsony). European governments have monopsonist power: through negotiating with manufacturers directly, they drive prices below the efficient level.

<comment><USER17> Is that a monopsony though?

The market for drug companies is global. If you were talking about doctors or some type of medical provider that was limited to providing goods and services within a single jurisdiction, you might have a point.

<comment><USER18> Even if it is a monopsony, the questions are 1) do they abuse its monopsony powers, and 2) what factors go ino defining 'efficient' and 'abuse'?

<comment><USER17> No, the monopsony designation is key to the comment I was responding to and the point I was trying to make.

If there is no monopsony power, it's hard to make any claim of abuse on the part of the government. Single payer governments are leveraging their bargaining power like any rational market participant. Drug companies are not required to sell to them. They do so of their own volition at a price favorable to their bottom line, otherwise they wouldn't do it.

<comment><USER18> Most shareholders would be up in arms if instead of a 5% loss in profit due to government monopsony, the company CEO decided to shut down the company and not sell anything at all, so the statement "not required" isn't that relevant.

"They do so of their own volition". No. You are expressing the Panglossian viewpoint that just because something happened it was the best choice.

We know from experimental economics that people make decisions different than rational market theory would predict. The heads of large pharmaceutical companies are not exempt from this irrationality.

Nor are all people in government short-sighted pennypinchers. The price negotiations also include the reality that some of the profits are turned into more research for future drugs. Hence the questions of what "efficient" and "abuse" means, which go into the pricing negotiations.

<comment><USER19> I think the "monopsony==inefficient market" argument is a fig leaf for the shibboleth that state economic actors are somehow "tainted" because they're not "private" enterprises. If a pharmaceutical firm were "negotiated" (tortured?) below their break-even somehow by state actors, they would simply fold. The entire concept of "below efficiency levels" is questionable here.

<comment><USER20> "below efficiency levels" isn't some sort of moral statement, it's a mathematical one. It's not a question of moving sellers below their break-even point (you're correct that would obviously never happen). It's about transferring producer surplus to consumer surplus and introducing deadweight loss into the system.

[https://en.wikipedia.org/wiki/Monopsony#Welfare_implications](https://en.wikipedia.org/wiki/Monopsony#Welfare_implications) explains it pretty clearly for the example of labor.

<comment><USER18> "A mathematical one" in a simplified analysis which assumes a rational actor model which doesn't model what people actually do.

Or if you want to use the model, the deadweight loss in your evaluation can instead be interpreted as the price that people are willing to pay for the good feelings of knowing that everyone in the country has accessible and affordable basic health care.

<comment><USER20> > assumes a rational actor model which doesn't model what people actually do

Sure, but in the case of drug prices in countries with national health systems we don't really have any reason to think that the model doesn't reflect reality.

> the deadweight loss in your evaluation can instead be interpreted

Yes, this is exactly my point! The science of economics makes no judgement about the relative moral values at play here. That may very well be a tradeoff people want to make. Or it might not. Economics doesn't comment on that question one way or another, it nearly provides data on the practical outcome of the decision.

<comment><USER18> Which is why I wrote: Hence the questions of what "efficient" and "abuse" means, which go into the pricing negotiations.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> A simple fix could go a long way - disallow really minor improvements and work hard to get rid of evergreening.

[http://www.nature.com/news/indian-court-rejects-novartis- pat...](http://www.nature.com/news/indian-court-rejects-novartis- patent-1.12717?WT.ec_id=NEWS-20130402)

<comment><USER22> How do you define "minor"? These insulins have dramatically different serum half lives (for example there are fast acting ones for postprandial administration, others that are optimized for pumps, etc) and so there is a clear pharmacological difference. Moreover, discovering these variants is nontrivial, as each insulin must be checked against igf-1 receptor cross reactivity, lest it become teratogenic. Making matters worse, the exact binding of insulin and igf-1 to their receptors is not known making this endeavor especially difficult to predict.

What is not clear is whether these modifications are an over optimization over "the original". For each patient the cost/benefit calculation will be different and based on many variables.

<comment><USER21> [http://theconversation.com/explainer-evergreening-and-how- bi...](http://theconversation.com/explainer-evergreening-and-how-big-pharma- keeps-drug-prices-high-33623)

I'm not an expert and I can't comment on specifics. But I'm of the opinion that a small enhancement is not the same as an invention of a drug and it doesn't come anywhere close to extending the life of the patent - <USER2> that tiny change actually makes a big different in effectiveness.

Any good patent system should find a good balance between the two seemingly conflicting goals of incentivizing companies to innovate and keeping the price down for patients.

<comment><USER22> These insulin changes are like the difference between a spanner and a torque wrench, or a spanner and a ratcheting wrench. The torque wrench is definitely more effective for certain use cases, as is the ratcheting wrench, both are nontrivial, but 99% of the time the spanner would do just fine / maybe be a bit more of a hassle.

<comment><USER23> (for Americans: "spanner" -> "hammer")

<comment><USER24> I believe you meant wrench.

</comment></comment></comment></comment></comment></comment><comment><USER25> There are so many people on both insulin and government health insurance that it's probably in the taxpayers' interest to build an insulin factory to supply the low-end.

<comment><USER26> I had a similar thought a few years ago that it would have been in the government's interest to buy Pharmasset when they sold for $11B to Gilead based on the future potential of Sovaldi (the infamous $1,000/pill, 12-week treatment for Hepatitis C). The government through Medicare / Medicaid is currently spending upwards of $4B/year on the drug and private insurers and international buyers are spending billions more. It would've been an absolute net-win for humanity had the USGov or someone else just bought the company rather than giving Gilead billions in annual profits.

<comment><USER17> When it comes to Medicare, there is a much easier win: just allow the government to negotiate prices. The government should have massive bargaining power.

> When Congress created the Medicare drug benefit in 2003, it specifically > prohibited the government from negotiating prices with drugmakers.

[http://www.bloomberg.com/news/articles/2015-02-02/drug- price...](http://www.bloomberg.com/news/articles/2015-02-02/drug-prices- prompt-obama-to-call-for-medicare-bargaining-power)

Imagine making a deal with a company where you are one of their largest clients but you are specifically prevented from negotiating any prices with them at any point in the future.

<comment><USER27> Hah, never happen since the people who would vote on this are all on the Pharma take. Both parties, an equal opportunity bribery, which means nothing will ever change.

</comment></comment></comment></comment><comment><USER28> in France, in UK, and probably rest of Europe people with Type 1 and 2 diabetes are taken in charge 100%

that means whatever amount of insulin you need, you get it for free

and it's not only the insulin, it's also all the rest: test strips, glycemic reader, etc.

I'm pretty sure the article is wrong about

"had Type 2 diabetes for over 30 years. She takes several injections of insulin each day."

this more describe Type 1 situation

anyway, I'm pretty sure the price of insulin went up also in Europe, except the government paid the bill, not the patient, a bit more civilised but still the problem stay the same:

big pharma corporation are abusing the situation and make money from it, it is disgusting and criminal

first, about the patent and why there is no generic insulin, read [http://www.medscape.com/viewarticle/841669](http://www.medscape.com/viewarticle/841669)

second, most people are uneducated about diabetes, they think it concern only fat people or other countries, and other BS like that

nope, it is worldwide major public health problem, many studies show the amount of people with diabetes rising , for ex

[http://www.nytimes.com/2015/06/08/health/research/global- dia...](http://www.nytimes.com/2015/06/08/health/research/global-diabetes- rates-are-rising-as-obesity-spreads.html)

"reported a 45 percent rise in the prevalence of diabetes worldwide from 1990 to 2013"

finally, why it is disgusting and criminal for pharma corp to make ppl pay for insulin ?

it as simple as that: if you don't take insulin you die, period.

It's not curable, there is no alternative diet, nothing, zilch, nada

and those big pharma corporation they made a business to profit from that, and when profit is not high enough, simple, raise the price.

<comment><USER29> Type 2 diabetics often progress to insulin treatment as their pancreas becomes exhausted and ceases proper function.

The low insulin sensitivity in type 2 means the pancreas produces large amounts of insulin in a futile attempt to reduce blood sugar. Initial treatments focus on insulin sensitizing agents to try and assist the natural insulin to be effective. Despite the amazing capabilities of the body, it eventually becomes too much and people have to start insulin replacement therapy at that point.

<comment><USER28> no problem, it's like the honey moon period for a type 1 patient

I was saying "maybe", in general I see type 2 ppl who are just on pills and have no need to take insulin, but yeah the diabetes can progress in different way, no problem with that

</comment></comment></comment><comment><USER30> Generally speaking companies "extend" their patent by making a slight tweak to get a new patent. But that doesn't stop their old patent from expiring. And the old formula from becoming open to a generic.

So why aren't there generic versions of old formulations? Who cares if it doesn't have the latest tweak? The complain about such tweaks is that their minor and unimportant. Meaning the previous version should be just fine.

<comment><USER31> Just one data point:

I have Crohn's Disease. Up until a few years ago, I took Asacol for this. This is one of a whole class of drugs based on the active ingredient "mesalamine": Asacol is specialized in that it's got a coating that keeps it from dissolving until it gets to the colon. Somebody found that this coating (notice: not the drug itself, just an enteric coating) might be a risk for pregnant mothers - something that I will never be. So they stopped making Asacol, and came out with a new "Asacol HD", which is still good old-fashioned mesalamine, but with a slightly different enteric coating - and with a brand new patent.

Although I don't have any evidence to support the idea, it seems suspicious that this revelation about the coating being questionable during pregnancy, came to light not very long before the expiration of the patent on original Asacol.

So there exists a small group of patients (pregnant moms) who might have had trouble with original-packaging Asacol. Rather than putting these patients on other mesalamine meds (like Pentasa or Delzicol) for 9 months, that was parlayed into a need to discontinue the entire Asacol product and come out with a new one.

In this case, it seems that a desire (or a pretense) to make something safe for all sub-groups, even those that are small and easily segmented, becomes the engine for renewing the patent, and thus keeping generics out of the market.

<comment><USER13> But as forrestthewoods pointed out, if the improvements in the new version are so marginal, then you'd think there would be a booming market for the old version if it was cheaper (generic). So what's stopping the generic manufacturers from cranking out the old versions? Seems like there would be lots of money to be made, unless patients (the market) actually did value the incremental improvements and would likely chose not to purchase the original formulation.

<comment><USER31> Well, in my example, it seems like the manufacturer hasn't just moved onto an abstractly nicer formulation, but in the process they've left some FUD that the previous version might be problematic (for some subgroup).

<comment><USER32> I'm sure most people outside that subgroup would jump at the chance to get a cheaper substitute.

Asacol HD is $600 - $700 for 90 pills: [http://www.goodrx.com/asacol- hd](http://www.goodrx.com/asacol-hd)

<comment><USER31> You should see the other stuff I take, Entyvio[1], at around $25K/dose (which is every other month). I don't know why they list it for various pharmacies, since you can't buy it - it has to be administered by an infusion center. I'm the reason that healthcare insurance is so expensive.

[1] [http://www.goodrx.com/entyvio](http://www.goodrx.com/entyvio)

</comment></comment></comment></comment></comment></comment><comment><USER33> I am tempted to believe that the pharma companies are more interested in keeping their recurring revenues from diabetics than find a one time cure.

Here in India, the medicines and tools for a diabetic (particulary IDDM) is still prohibitively expensive for most people who have it. The prices of insulins and testing strips have increased by 10% or so many times in the past couple of years. Things like CGMS, insulin pumps are not affordable even to well-off people like me.

There has always been news of research from various government and government aided organizations towards the development of low cost testing strips (at about Rs. 5 per strip compared to Rs. 17 and above for the existing products) but nothing has come out as a product. What's worse is an unknown healthcare company has acquired the technology from ICMR (Indian Council of Medical Research) a year back and till now their only product is a low cost sanitary napkin. Wouldn't be surprised of the involvement of the big pharma companies in the delay.

All this said, at least India doesn't have an insurance system like in the US which has pushed up the prices repeatedly to help the insurance companies (imho an unwanted middleman in most cases) make more and more money.

I am not very optimistic about the future.

</comment><comment><USER34> My mom just told me in tears today it cost her over $400 rather than the normal $80-90 copay she was used to

</comment><comment><USER35> Can anyone explain me the evergreening - even if new patent is granted for new molecule the old molecule should be free. So why is nobody producing them?

<comment><USER36> Because no one is interested in spending billions to get a generic insulin through FDA or other regulatory agencies.

Too much profit is to be made.

<comment><USER35> IIRC you don't need to spend billions to get it trough FDA. That is the whole point of the generic. That the molecule is already approved and tested.

<comment><USER37> You don't need to spend money on phase 1-3 trials for safety and efficacy of the molecule but you do still need to spends tens of millions of dollars to prove that the generic drug you are manufacturing behaves like the original, within a margin of error, and that you can maintain that quality control in the future.

</comment></comment></comment></comment><comment><USER38> According to the article, Pharmacy Benefit Managers are as much to blame for the increasing costs of drugs as the manufacturers. I suspect that's partly true, but I also suspect the "percentage of blame" is being ignored here.

<comment><USER39> A model that is more direct from business to customer sounds like it would eliminate costs. Too many people trying to put themselves in the middle and make a cut.

</comment></comment><comment><USER40> At least in some states you can buy a form of insulin over the counter. It is an older formulation and apparently it is not the easiest thing to DYI figure out the correct dose. NPR had a report on it a while back. [http://www.npr.org/sections/health- shots/2015/12/14/45904732...](http://www.npr.org/sections/health- shots/2015/12/14/459047328/you-can-buy-insulin-without-a-prescription-but- should-you)

<comment><USER41> A fair enough statement: "The broader availability of [over-the-counter] insulin allows patients with diabetes to obtain it "quickly in urgent situations, without delays," the FDA says, and is intended to increase patient safety."

However, it seems like there are no visible protocols in place to control use in non-emergency situations like with the patient mentioned in the NYTimes article. That's certainly risky for poorer diabetics who don't necessarily know better, or are desperate enough financially to risk the long-term consequences.

</comment></comment><comment><USER42> Some previous submissions: [http://www.psmag.com/health-and-behavior/why-is- there-no-gen...](http://www.psmag.com/health-and-behavior/why-is-there-no- generic-insulin) [http://www.psmag.com/health-and-behavior/why-is-there-no- gen...](http://www.psmag.com/health-and-behavior/why-is-there-no-generic- insulin)

</comment><comment><USER43> "This is true, in no small part, because the big three have cleverly extended the lives of their patents, making incremental "improvements" to their insulin."

Possibly dumb question: If the improvements really are that minor, what's stopping other companies from using the original, "unimproved" formulation in a generic? How would disallowing the "improved" patents change the situation?

<comment><USER44> > If the improvements really are that minor, what's stopping other companies > from using the original, "unimproved" formulation in a generic?

The fact that doctors won't prescribe the unimproved formulation when the improved one is available.

</comment></comment><comment><USER45> > Insulin has been around for almost a century

> In the United States, just three pharmaceutical giants hold patents that > allow them to manufacture insulin

How does this work with patent lifetimes being 25 years?

Anyway, as the article says, in countries where chronic medical conditions aren't seen as an opportunity for price-gouging, it costs much less or is free to the user.

</comment><comment><USER46> This project started a while ago[1].This could pretty much change the way people approach medicine.

[1]:[https://experiment.com/projects/open- insulin](https://experiment.com/projects/open-insulin)

</comment><comment><USER47> I see generic Insulin is available in India:

Actrapid 40 iu, 10ml at Rs. 145, or about US$2

so the lack of availability would seem to be down to regulatory / patent bs.

There should be some way to alter the laws in the US to favour the US people rather than the billionaires. Saunders?

<comment><USER48> [http://janaushadhi.gov.in/list_of_medicines.html](http://janaushadhi.gov.in/list_of_medicines.html)

</comment></comment><comment><USER49> What happened to Genentech? Wasn't this their first product? Didn't this happen in the late 70's?

F. Hoffmann-La Roche AG is their parent now, not named.

</comment><comment><USER50> The cost to start a drug company to make generic insulin must be prohibitive enough that we don't see any.

</comment><comment><USER51> Check out Dr Bernstein's Diabetes solution and use less insulin.

</comment><comment><USER52> Shouldn't it be called patent extension racket?

</comment><comment><USER53> It's really weird to read this kind of article from outside the USA, where healthcare is a public service.

(of course, here in the UK, the tories are doing their best to ruin the NHS, but it's still _so much better than this_ ).

<comment><USER25> Every time there's a health care post people chime in with the useless comment, "this is really weird to those of us not in the USA."

Jeez, really? Wow.

<comment><USER54> I agree with that. But, as a European, I also agree with the parent comment. It is weird in the sense that we could never think of something like that, things such as a "doughnut hole" where a few months a year you don't have an insurance.

I currently live and work in the US, love it, love the country. I have the chance to have a great plan thanks to my company. But i'm not sure how much more I can keep tacitly approving this system.

<comment><USER55> The doughnut hole isn't that weird, a coverage was expanded, with a limit on how far it was expanded. The limitation is on spending, not related to the calendar beyond that:

[https://www.medicare.gov/part-d/costs/coverage-gap/part-d- co...](https://www.medicare.gov/part-d/costs/coverage-gap/part-d-coverage- gap.html)

Of course once the annual limit is reached coverage is reduced for a period of time, but there will also be cases where the limit is not reached.

And while it doesn't compare favorably to a simpler to access program that covers all expenses, enacting it didn't make anybody that ends up using it worse off.

</comment></comment></comment></comment><comment><USER56> > except the government paid the bill, not the patient, a bit more civilised > but still the problem stay the same (...)

God I hate those moral high ground stances seeping everywhere in HN comments.

You think it's more civilized, I think it's barbaric to forcefully take something from someone. Just like that, you made it that much harder for me to take anything from what you've written.

> (...) second, most people are uneducated about diabetes, they think it > concern only fat people or other countries, and other BS like that (...)

And the NYTimes article you linked immediately after starts by saying "The prevalence of diabetes has been rising in rich countries for several decades, largely driven by increases in the rate of obesity."

Are they totally clueless?

>finally, why it is disgusting and criminal for pharma corp to make ppl pay for insulin ? it as simple as that: if you don't take insulin you die, period.

Well, gee, it sure sounds like food, water, vitamins, or a bunch of other stuff that are sold for profit everywhere.

>It's not curable, there is no alternative diet, nothing, zilch, nada

Except that type 2 (the one that is the rise, by your linked article) is preventable. There is a high correlation between type 2 diabetes and sugar intake.

<comment><USER57> We detached this subthread from [https://news.ycombinator.com/item?id=11154983](https://news.ycombinator.com/item?id=11154983) and marked it off-topic.

</comment></comment><comment><USER58> Just throwing this out there, I am not sure of this myself. But aren't there studies where you could do without insulin shots if you avoided carbohydrates while feeding on protein and fat?

<comment><USER59> I believe this is the study you're thinking about [http://ajcn.nutrition.org/content/early/2015/07/29/ajcn.115....](http://ajcn.nutrition.org/content/early/2015/07/29/ajcn.115.112581.short)

"The LC diet, which was high in unsaturated fat and low in saturated fat, achieved greater improvements in the lipid profile, blood glucose stability, and reductions in diabetes medication requirements, suggesting an effective strategy for the optimization of T2D management."

I haven't heard of any formal studies where they got off of medication 100%; I've only heard of n=1 studies (single person reporting) where that has happened. The most remarkable n=1 is this from a type 1 diabetic: [https://www.reddit.com/r/keto/comments/2rnn9b/doctors_can_su...](https://www.reddit.com/r/keto/comments/2rnn9b/doctors_can_suck_it_im_staying_on_keto_for_the/) but in this case the person is still on it which isn't a surprise as they are type 1.

<comment><USER24> I don't know of any formal studies offhand, but for some pretty consistent anecdotal evidence you may want to read some of Maria Emmerich's work. She's a nutritionist who specializes in treating people's metabolic issues.

[http://mariamindbodyhealth.com/about- me/](http://mariamindbodyhealth.com/about-me/)

<comment><USER60> I don't necessarily want to suggest that when I see "nutritionist" I read "witch doctor", but if there is any field of science which has made less progress over the centuries, it is nutrition. I am not suggesting that any particular practitioners are ignorant or incompetent (per se), merely that it is a very hard problem to study. Among other issues, there is evidence to suggest that glycemic responses are highly individual[1]. However, this is also an area of political and commercial interest, and there are many actors presenting shall we say "motivated" studies, demanding an exacting scrutiny of any empirical results.

In short, not only are the self-reported anecdotes of a person with a bachelors in nutrition not adequate evidence of anything, but even formal studies are suspect. As far as my own opinions go I suspect that I would be inclined to believe what she says, but truths that mesh with one's preconceptions demand an even higher standard of evidence. Were I you, I would not be promoting this person's work, and I feel it was inappropriate as a response to the parent.

[1] [http://www.cell.com/abstract/S0092-8674(15)01481-6](http://www.cell.com/abstract/S0092-8674\(15\)01481-6)

</comment></comment></comment></comment><comment><USER61> The risk of diabetes is strongly associated with obesity, and even a modest weight loss has been reported to substantially decrease the diabetic risk. According to statistics from the US Center for Disease Control and Prevention, 55% of diabetic patients are obese and 85% are overweight - [[http://www.sciencedirect.com/science/article/pii/S0899900712...](http://www.sciencedirect.com/science/article/pii/S0899900712000731) ]

Is it the drug companies or the sugary food makers running the racket?

<comment><USER29> You're conflating a whole range of issues about diabetes into a single, misleading, factor. I don't know if it's intentional misrepresentation or genuine ignorance on your part.

Type 1 diabetes is not associated with being overweight and weight loss does not help. Indeed, rapid weight loss is often an early indication of the condition. Treatment with insulin (the only method available) typically results in weight gain, as the body recovers due to the newly available injected insulin. Often these patients start at normal weight range (i.e. BMI < 25) and are often substantially below typical weights prior to development of diabetes.

Type 2 diabetes has strong genetic factors and substantial evidence shows these, combined with weight and some other factors of diet, lead to an expression as diabetes. In these cases, some people have had significant improvements in their conditions due to calorie restriction (leading to weight loss but often it also means they've switched to a healthier diet in the process and that also helps). The mechanisms here are believed to be due to improved sensitivity to insulin which is still being naturally produced.

Various ratios of diabetes are quoted, but generally 1 in 20 of the white european population has diabetes and 1 in 20 of those has type 1 (and the other 19 type 2). Figures for Indian/Pakistani origin people are dramatically different if they move to Europe or North America and research suggests this is due to very different foods consumed [the 'western' versions being significantly less healthy than those from origin countries]. Much higher numbers of type 2 diabetes are found in these populations (reinforcing the factors as both genetics and types of food are involved). Other population groups differ too.

Treatments for diabetes typically create weight control issues as increased insulin or sensitivity to insulin promotes body fat storage.

It's untrue (and frankly verging on offensive) to simply blame diabetics for their condition because they are obese or overweight. Addressing and treating the condition is significantly more complex and weight control may be one of the few elements the patient has any input to, while many other factors are entirely outwith their control and they bear no culpability for.

<comment><USER62> The article talked about type-2 patients. Our NIH estimates that 60% of them would be cured if they simply ate less: [http://www.ncbi.nlm.nih.gov/pubmed/17227327](http://www.ncbi.nlm.nih.gov/pubmed/17227327)</comment></comment></comment>


Low-level is easy - <AUTHOR> http://www.yosefk.com/blog/low-level-is-easy.html <comment><USER2> I've found this very true, as I've moved over the years from very "high-level" programming (client/server apps, database-driven web sites) to "mid-level" programming (working on the Firefox browser) and then toward systems programming (working on Rust and Servo). The desire to stop dealing with masses of fragile dependencies keeps driving me lower in the stack. I really need to practice more assembly coding so I can continue in this direction...

You get some similar benefits if you are working on code where you have some control over the levels above or below, or if your project has any form of self-hosting. For example, Firefox, where most of the UI is rendered by Gecko and some of it even runs within a browser tab. If you're a web developer and you run into a rendering engine bug, you report it and then ship a workaround for three years as you wait for enough people to update. If you're a Firefox front-end developer, you can just fix the Gecko bug and ship the fix along with your feature.

<comment><USER3> Quick question, I've been stuck doing CRUD for way too long but have always had an interest in low level programming. Unfortunately the few times I have tried to give it a shot I always come back defeated to my CRUD world, it all seems very alien to me. What do you think is the best way for your typical CRUD/Web developer with no background in low level programming whatsoever to dive in to low level stuff? Any tips or links to resources you may have are very much welcome :)

<comment><USER4> Hi, I'm interested in learning low level programming too! I've been taking classes, reading tutorials about programming, and starting projects on my own. It really depends on what kind of projects you want to work on. Some of the major types of projects include compilers, OS-level projects (drivers, kernel, etc.), networking (server/client), and graphics. You'll probably want to learn C and/or Assembly, probably x86 but I've found ARM to be fun. (and Raspberry Pi is built on it!)

\- Compilers: I'm taking the Stanford course on Coursera right now. It just started two weeks ago so you can still catch up. Here's the link: [https://class.coursera.org/compilers-004](https://class.coursera.org/compilers-004) Here's some literature on compilers/interpreters/JIT (Just In Time compilation): [http://www.stephendiehl.com/llvm/](http://www.stephendiehl.com/llvm/) (I've heard good things about LLVM!) [http://blog.reverberate.org/2012/12/hello-jit- world-joy-of-s...](http://blog.reverberate.org/2012/12/hello-jit-world-joy-of- simple-jits.html) (Just saw this today) Tutorial on building a Lisp in C, from two days ago: [http://www.buildyourownlisp.com/](http://www.buildyourownlisp.com/)

\- Operating Systems: Definitely check out MIT's open courseware on xv6! It's an implementation of Unix version 6. The course includes a git project that you can clone and play with yourself, as well as some labs. Here's the link: [http://pdos.csail.mit.edu/6.828/2012/index.html](http://pdos.csail.mit.edu/6.828/2012/index.html) OSDev wiki had some resources too: wiki.osdev.org If you have a Raspberry Pi or are patient enough to try to emulate the hardware, here are some tutorials on ARM assembly for RasPi: [https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/](https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/)

\- Networking: Here, you'll probably want to look for tutorials on socket programming and the TCP/UDP protocol. People recommend Beej's tutorials, which are quite comprehensive and a good source of information, but I found some of his server code confusing and convoluted (deeply nested loops and if statements). Here's a link to his site: [http://beej.us/guide/bgnet/](http://beej.us/guide/bgnet/) Here's a easy to learn server/client tutorial: [http://www.thegeekstuff.com/2011/12/c-socket- programming/](http://www.thegeekstuff.com/2011/12/c-socket-programming/)

\- Graphics: I have the least amount of exposure to this, but a good resource is at the website open.gl. Basically you'll want to learn about shader languages and how the graphics pipeline works.

Hope this helps!

</comment></comment></comment><comment><USER5> Low level is a lot more fun in the very least.

I wouldn't say it is _easier_ by any means.

The first time you open up the debugger and your v-table pointer is null (presuming you know what a v-table pointer is!) things start to be interesting.

Or there was that time I printf'd a 64bit number and a random stack variable was corrupted. That was a lot of fun.

Memory protection? Haha. No.

For that matter, my team just came across a bug in our own code a couple weeks ago, we were performing a DMA memcopy operation (for which you get to setup your own DMA descriptors yourself of course) over a bus and at the same time sending a command packet to the same peripheral that was being DMA'd to.

oops.

Expected things to be put into order for you? Nope. Not unless you implement your own queuing system. (Which we are doing for that particular component now.)

All in all it is a ton of fun though. I'm loving it. Having seen an entire system be built up from setting up a clock tree to init'ing peripherals to our very own dear while(1). (We actually moved away from while 1, async is where it is at baby! Callback hell in kilobytes of RAM! oooh yaaaah)

<comment><USER6> There is certainly nothing easy about it. I have quite some experience with low-level and embedded devices, but hardware has progressed to the point where a Cortex M3 is quickly becoming the jellybean baseline throwaway uC, and have you seen the datasheet of one of these things?

The amount of stuff they do is incredible, and everything is interconnected in unexpected and intricate ways.

<comment><USER7> I haven't messed around with x86 enough to know whether it is actually somehow easier than the ARM stuff, but I certainly agree with you that CPUs are damn complicated.

I loaded up the datasheet for the M3's when typing up this reply. 384 pages. Contrast that with the TI 74181 ALU datasheet from the days of old: 18 pages, most of which are just detailed diagrams of the distances between the pinouts. The logic diagrams fit on a single page. You can build a simple CPU using one of these machines in a few hours in your basement.

Hardware is only going to get more complicated. At what point does it become so complicated that no one person can reasonably understand how a computer works "under the hood", even from an abstract level?

<comment><USER8> Maybe then there could be an easy to use (for a human) virtual machine at some level in between...

<comment><USER9> Is that not the role of the operating system?

</comment></comment></comment></comment></comment><comment><USER10> In the company I used to work for we covered quite a range of development targets, from embedded micros up to very high level factory control systems, and I always found the most challenging stuff was "in the middle" \- stuff at the systems level.

At the bottom, it really felt like programming a machine, and I found it all good fun, much like solving a puzzle (with occasional obscure headaches, mostly compiler related). At the top everything is pretty abstract, and there's more freedom to do conceptually interesting things (for example we were doing quite a bit of adaptive control type stuff, which would have been a nightmare to write with lower-level languages).

In the middle, however, it seemed to me to be largely just a complicated network of interacting conventions. Those systems are neither firmly grounded in "reality", because they are generally trying to abstract away those details, nor are they "theoretically pure", because they need to be efficient (though there is a lot of interesting stuff there). What that means is that you simply have to learn and understand all those human-defined conventions to know what you're doing, and that makes solving problems at that level more difficult, or perhaps rather it requires much more hard-won expertise (which I never got much of - I just bugged other people until they would help me out!).

Obviously, my views are coloured by my personal experience, so make of them what you will.

</comment><comment><USER11> I get the point of the blog author and I partly agree with it; but there are different types of "hard" and "easy".

To produce much of value at the low-end you need a really comprehensive understanding of the technology at the level you are working at which has significant upfront learning (and likely just plain aptitude) costs that aren't really addressed too much here. Once you have that knowledge, then yes, you get far less surprises, but acquiring it in the first place is not at all trivial or "easy" (though it may seem like it if you're a geek that's been banging away with assembler for years... you've just forgotten how much effort you expended at that stage, probably because it felt fun to learn).

At the higher-end you can string together a bunch of frameworks and glue code you cut and pasted off Stack Overflow and get something that pretty much does what you want, most of the time, maybe, while barely understanding the underlying technology.

Which is "easier" or "harder" depends a lot on what you mean by those terms.

Also the assumption that "high-level" means HTML/CSS/JavaScript is not that useful for the overall debate since not all high-level development is as annoyingly unpredictable as HTML/CSS/JavaScript.

</comment><comment><USER12> A beautiful elaboration of what I've been feeling for many years. I don't get all this excitement over web programming. The process is a pain in the neck -- why doesn't this color turn red when it's supposed to? Oh, this IE workaround conflicts with this Firefox bug. To me it feels like a house of cards held up with old, dessicated duct tape. Yeah, you can do amazing things with cards and duct tape, but because of the shaky foundation, it ends up being vastly more frustrating and so much more work than it really should be.

I haven't responded by going as far down the stack as this guy has -- although I've done a fair bit of assembly and enjoyed it, I spend most of my time in Python and Erlang -- but coding web apps can be such a ghetto.

<comment><USER13> If you go further down, at least on x86 you'll find a lot of duct tape. I guess most people who have written serious code in x86 assembly wonder how those machines can actually work so reliable in practice. Probably because kernel developers do a good job.

// my perspective: I started with low level c and assembly, mainly on x86 and do web programming nowadays.

<comment><USER14> What do you mean by duct tape on x86? I'm quite familiar with the architecture, and this can be interpreted in more than one way.

<comment><USER15> Well for one thing, the machines need to maintain 8086 compatibility even though it is horribly outdated. IIRC the actual processor just runs microcode that emulates an x86-compatible system or something to that effect.

It's sort of like gcc where layers keep getting put on top of layers and only like 5 wizards from MIT know how it actually works.

<comment><USER16> The word "emulation" is uncharitable. Breaking a high-level instruction into micro-operations allows the architecture to present a consistent ISA to programmers while optimizing execution for the micro-architecture. Yes, x86 originally did this out of necessity. But it's a little unfair to call it "duct tape". Case in point: ARM sometimes does the same thing, despite being a RISC.

In other words: design your clean, orthogonal RISC ISA however you want: at some point in the future, some processor designer is going to end up translating those instructions into something else.

As for layers upon layers of abstractions: welcome to computer science. ;)

</comment></comment></comment></comment></comment><comment><USER17> Playing the piano is easier than playing a violin. I would argue that a world- class pianist is about as skilled as a world-class violinist.

If you could allocate skill points like an MMO, the violinist is spending 3 points on instrument mastery, and 7 points on musical mastery, while the pianist spends 1 and 9.

I hate spending my limited skill points on "browser mastery," so I mostly do lower level things.

<comment><USER18> It seems to me that musicians play more complicated things the easier the instrument is, so it does even out at the end. Drummers do some insane things, even though they only have five drums to hit (whereas a piano has 60ish keys).

<comment><USER19> I agree with your general point. So maybe the following is the exception that proves the rule, but:

An acoustic piano has 88 keys, and classical or jazz piano music tends use many of them. Whereas a 60 key electronic keyboard is often subject to the Flock of Seagulls treatment, wherein one key at a time is held down. :) It's roughly like touch typing vs. hunt and peck.

But aside from that example, yes, I think you're onto something.

</comment></comment></comment><comment><USER20> The big difference, and the reason most find low level harder, is that you can do a pretty bad job on front end code and still produce something of value. Whereas low level code tends to need to be more solid.

</comment><comment><USER21> I would not say that dependency of the layers is like a tree and if trunk breaks, everything does. I'd rather see the levels of programming abstractions as a graph with lower/higher level nodes.

As it is pointed out in the comments above, x86 has surprisingly much of a duct tape in it. There is a lot of much more saner platforms, but programming still lives happily on x86. Why? Because it does not matter at all so often. x86 is hidden from us with OS, compilers and virtual machines. That's where the beauty of programming shines: if you have a lame implementation below your level, just abstract it away as far as resources allow you (e.g. full-scale managed memory programming is theoretically possible in DOS but noone did it because of CPU/memory constraints). Another example: Win32 API and MFC and other native stuff is horrible, but .NET platform seems to be quite sane. Javascript is horrible, but jQuery is, um, beautiful.

On the other hand, a hardware guy still operates with an abstraction of a microcontroller. If memory is corrupted, his abstraction fails also. It's just that the HW guy does not have to invent good abstractions often (or rather at all).

The point is, abstracting may be self-healing: if something is broken at some level, a level above can use the good parts to build a fully functional emulation.

<comment><USER22> This is why I think higher-level programming is easier. I love to build an abstraction around a complication so that I don't have to think about it anymore. It was only very recently that I began to embrace what kind of programmer I am. I prefer high level abstractions; I prefer the mathematical underpinnings; I detest doing things manually. Other people have the opposite inclinations and I'm happy that the world has both.

I have recently had to work with C++ on some systems-level code. It's the lowest-level I've had to work on for a while. I find that having to think about things like memory management and system peculiarities like buffer alignments gets in the way of thinking about the higher level algorithm or problem. In this case I did not have the luxury of being able to build abstractions around some of the quirks I encountered.

On the other hand, when I work at a high level with a suitably high-level language, I can recognize patterns and abstract them away. For example, I've seen many instances of the pattern

        b = a.f(); if (b != null) { c = b.g(); if (c != null) {...}}

This pattern is fairly common, and in a suitably rich high-level language I can abstract it and just write

        c = a.f().g();

It saves me a lot of thinking and honestly feels a lot easier.

</comment></comment><comment><USER23> This seems pretty spot on to me. More moving parts = more failure points...as a web engineer, I find myself bitten more by the trappings of abstract code structure than by things like faulty algorithms. This ties pretty heavily into why I feel the standard technical interview for web engineering talent is severely broken, but I digress.

</comment><comment><USER24> The author makes some valid points, but he seems indifferent to the most important question: why program computers at all? He doesn't seem to enjoy it much (although that may be more of a sarcastic tone). I think we need more devs who do it because they want to accomplish something particular, and less devs who are doing it _cause computers are kewl_ (or to get paid for that matter). With a utility view, the choice of low-high level gets less emotional:

* high-level is more productive in the short run, but may hinder you in the long run

* mid-level (C-ish level) tend to be more portable and more future proof

* low-level will probably give you better resource usage (speed, memory etc), but not necessarily these days

Personally, I find C++ (plus open source libraries) gives the best trade-off, but that's probably dependent on the task (I do audio/video analysis/synthesis).

<comment><USER25> Most of my enjoyment of programming comes from the coolness of math, logic, and simulation. Most of my hatred of programming comes from the brittle, messy, confusing, uneven frameworks laid down before me by other programmers. My career consists of maybe 10-20% of the former. The rest is the latter. Consequently, I've really hated, and I mean hated, doing this for a job.

Another way to look at it is, just as in all other spheres, I enjoy the abstract intellectual part and hate the human part.

<comment><USER26> Hell is other people, after all.

</comment></comment></comment><comment><USER27> "Memory-mapped devices following a hardware protocol for talking to the bus will actually follow it, damn it, or get off the market."

Says somebody who clearly never had to deal with cheapass webcams in Linux... :)

</comment><comment><USER28> And the similar: server-side/back-end is easy!

Sure, there's an ubersmooth learning curve with HTML/CSS/Javascript, but once you get to heavy client side SPAs and supporting every device and format under the sun and then someone say "it's not good enough, try and make it feel like a 100% native iOS app - and no, you can't just write an iOS app" ...and good luck _hiring_ a good front-end guy (at least if you don't do the expensive way of "hire 5 instead and fire 4 of them after two months" route).

</comment><comment><USER29> I agree with this article. The Web is a shambling mess of crap technologies, just a Jenga tower of crap. When is it going to collapse under its own weight? The rise of native apps suggests that the collapse has already begun.

</comment><comment><USER30> I found this very true, even for other kinds of low-level. I do database engines in low level Java.

</comment><comment><USER31> This seems like a kind of selection bias to me. For the most part we only build "high level" things on top of "low level" things when we're successful in finding a use for them, by definition. The more successful you are, the easier success seems. Put another way, if they weren't "easy" then there wouldn't be a "high level" above them to make the concept of "low level" meaningful or concrete.

Also, as a caution against asserting low level means "easy", I will take this opportunity to drop one of Murphy's Laws:

        "An easily understood, workable falsehood is more useful than a complex, incomprehensible truth."

sometimes written as

        "All abstractions are wrong, some abstractions are useful."

As an example of a low level abstraction that is both useful and wrong, consider the libc strtod() function, which converts a decimal string to a native floating point representation. If I were to give you the pre-parsed integer significand and integer exponent, base 10, then you'll find there's no mechanism in the C standard library to convert those two integers to the correct double value, despite strtod() having to do the very same thing, at some point after the parsing stage. If all you ever want to do are string to double conversions then this function will always have appeared quite low level, but the reality is that this is only the case because it's always been so damned useful.

Low level things are intrinsically useful and the more useful something is the less wrong it seems.

<comment><USER32> > Put another way, if they weren't "easy" then there wouldn't be a "high > level" above them to make the concept of "low level" meaningful or concrete.

Yeah, the higher level is things that are also rejected at large by the industry and moribond in research like DSL, code generation, modelisation, algebra stuff and proved programs. Things that exists more or less at every level but widespread in CPU making.

</comment></comment><comment><USER33> I suppose if you just want to program because you like to program, then this article makes sense. If you want to program because you want to make stuff non-programmers can use, then you are more interested in productivity and distributability and are likely to choose higher level languages like JavaScript.

</comment><comment><USER34> I've been thinking about this a bit lately. I'm not a low-level developer in the slightest, but the question I've been pondering is, when you get the low- level stuff, is it a lot more focused on simple I/O? The complexity (as I understand it) comes from understanding the register, address, hexadecimal stuff (which I don't really understand).

If I understand correctly, the OP is basically saying the same thing. The complexity in the higher-levels comes in when we try to create an API further up the stack which is responsible for manipulating the more understandable data into something that the device understands at a low level. The difference in retrieving a file stream vs getting the file in standard utf-8 format, which anybody can read.

What are your thoughts on this. Have I got it right? Or am I on the right track?

</comment><comment><USER35> The conundrum is that the high-level customer-facing stuff wouldn't be possible without the low-level behind-the-scenes work that was done on protocols and kernels.

</comment><comment><USER36> If you look at the author's actual arguments you realize most of them rely on other people. I don't know about others, but I include many more bugs in my code when I write low level code as opposed to high level code. Having to deal with the chance that someone else included a bug below me, I think, is worth it if I don't have to worry about anywhere near as many bugs in my code.

IIRC pg has an essay about this.

</comment><comment><USER37> I'm sure making the assembly instruction set was not an easy task. The instructions are small, but the simplicity and the beauty of keeping it simple is in itself a great accomplishment.

How floating points are represented in computers is such a neat hack, yet it can be done with a simple formula on pen and paper.

Doesn't mean you can come up with.

Everyone knows E= mc^2. It's easy, But you didn't come up with it.

</comment><comment><USER38> As a young web engineer who have had the pleasure of dealing with what seems like 30 different versions of RSS-feeds, which also appear to be evolving in random directions like living things, I can confirm this. (I've also messed around in C, and even Assembly at one point.)

</comment><comment><USER39> The higher you go, more abstractions, more specs, standards and frameworks. Its actually more complex, but once you understand "all" of it is not that hard. Lower level is easier to get started but the more complex problem the more difficult to solve.

</comment><comment><USER40> Please add 2008 to the title. Halfway through I realised I had already read this a few years back.

</comment><comment><USER41> This is overly simplistic. Sure, low level programming can be easy if you understand the basics of what you are doing, and the same is true for high level programming.

However, there are aspects of low level programming which are far more technical than anything you are likely to run into programming UI's or the like. Thread scheduling, OS development, compiler development, standard library stuff, etc. tend to be quite challenging from a technical perspective (I've done all but one of them.)

The author is picking one type of low level development and painting the rest with the same brush. Low level development occurs on more complicated architectures as well.

Of course, high level development can be challenging as well, but often in a different way. The challenge here lies in understanding the quirks of your libraries, creating a good user experience (terribly hard at times, but not often technically challenging), working around oddities of your platform, etc.

>And it sucks when you change a variable and then the other processor decides to write back its outdated cache line, overwriting your update.

Well... that's why you use memory fences (volatile if your language supports it) even for writes on types which would be atomic.

<comment><USER42> Low-level programming requires a great deal of knowledge, in exchange for which you get an enormous amount of control over how your efforts behave. High-level programming offers the prospect of a quick start, but, especially with today's web frameworks, you tend to rapidly find yourself bogged down in dealing with magic that's baked into the platform and which nobody really bothered documenting very well because "it just works" \-- which is fine, except when it doesn't, and you get to spend time working on your tools, instead of the problem you're using them to solve. I don't want to RAILS name any names here RAILS, but RAILS I'm sure every RAILS web developer has RAILS at least RAILS some RAILS inkling of RAILS what I'm RAILS talking RAILS about RAILS here RAILS RAILS RAILS.

My observation of the programmers with whom I've worked, and whom I know socially, has been that a given hacker's degree of intelligence and capability tends to be inversely proportional to the thickness of the stack on which he chooses to base his efforts; the smartest person I know, who has multiple doctorates and is currently busy breaking new ground in bioinformatics, doesn't even use _libraries_ if he can help it, and complains constantly about the frustrating misbehaviors of those which turn out to be irreducibly necessary. Perhaps I've merely been observing a constellation of coincidence, but on the whole I rather doubt it.

(P.S. for the benefit of anyone who feels like I've just called him stupid: my last gig was a Rails job, and if you took all the programmers I've ever known and broke their smarts up into quintiles, I'd be somewhere in the upper second, _maybe_ the lower third. It doesn't take genius to recognize genius at work; I've merely been uncommonly fortunate, for the most part, in my choice of friends and colleagues.)

(P.P.S. for general use: Speaking of recognizing genius at work, it scintillates in every jot and tittle of the article here under discussion.)

<comment><USER43> Sounds like your friend with multiple doctorates has put himself in situations where he has time to not use libraries, rather than the necessity of shipping everything asap.

<comment><USER42> Spoken like someone who's never had a particular software stack and methodology forced on him, and then been hamstrung by it. The genius of the friend I mentioned is evident, as much as anywhere else, in the way he has placed himself beyond the reach of the sort of mediocre-to-incompetent management under whose yoke web developers so often find themselves struggling.

<comment><USER9> There are usually well tested libraries for most stacks. Even VB.</comment></comment></comment></comment></comment>


Harnessing light for wireless communications - <AUTHOR> https://code.facebook.com/posts/484014178459953/harnessing-light-for-wireless-communications/?utm_source=codedot_rss_feed&utm_medium=rss&utm_campaign=RSS+Feed <comment><USER2> Maybe with this technology, we can finally build the 80's neon cyberpunk future we've all been waiting for.

<comment><USER3> I wanted to upvote this twice.

</comment></comment><comment><USER4> One of the major challenges for FSO is that it requires direct line of sight (LoS). One reason that electromagnetic radiation in the RF range is more desirable for communications is because it can be non-Los (think about your cell phone, you do not have to see the tower for it to work, you can be indoors for example).

The second issue is the free space pathloss (see [https://en.wikipedia.org/wiki/Free- space_path_loss](https://en.wikipedia.org/wiki/Free-space_path_loss) ) you can see by the formula that the loss goes up exponentially by not only the distance but also the frequency, which is why the wireless carriers are so interested in the 600Mhz spectrum, you need to build fewer towers using 600Mhz than say 3.5Ghz.

The sudden interest in mm-wave (e.g. 28Ghz) for 5G is because the spectrum is much wider, that is the channels can be very wide allowing more data to be encoded, the trade off is that you start losing the NLoS capability, or it becomes much more difficult.

With light, all those problems are orders of magnitude more difficult to overcome. Also, there are regulations around the level of emissions of light for safety reasons, if a laser is turned up too high it can harm a persons eyes if they happen to look at it, so although the spectrum itself is not regulated, the amount of power you can emit is. That makes it very difficult to implement an FSO system that can safely transmit more than one or two kilometers, but if you get fog, rain or snow, that distance quickly becomes 100's of meters at best.

They are correct that the best way to overcome this issue is by developing sensors with much better sensitivity, by making them larger you can theoretically collect more photons, like a telescope. Since it is unlikely you can overcome the safety issue of increasing the transmission power level, it is smart to focus on the receive end and improve the sensitivity. But that does not help the LoS problem.

But a very interesting development nevertheless.

<comment><USER5> Loss goes up quadratically with distance, not exponentially.

The graphs showing the quadratic dependence of loss vs. frequency assume a half-wave antenna, meaning the antenna size decreases inversely to wavelength, so most of the effect is from having a smaller antenna.

In any case, path loss doesn't usually limit network capacity. Densely deployed systems are limited by interference, and the interference experiences the same path loss as the signal.

<comment><USER4> Yes, by the square, this is HN I cannot speak so loosely:) For Multiple access RF systems yes, but got point to point systems, that is line of sight, noise is not an issue, free space loss, also impairments from fog, trees and other things are dominant.

</comment></comment></comment><comment><USER6> After reading this post, I was left with the question of why bother with the luminescence--why not just collect the transmitted light with the fibers and transmit it directly to the detector. The linked journal article makes it clear that the transmitted light is not collected by it entering the ends of the fibers. Instead, the transmitted light "scatters" off of the dye (changing wavelengths in the process), regardless of where and at what angle it hits the fiber, and some of it is scattered in the proper angular range to be transmitted along the fiber.

<comment><USER7> Efficiently directing light into a fiber optic cable is a difficult problem, in general. The luminescence is their proposed solution to this problem and one of the key results in their journal article.

You have to shine light end-on into a fiber--you can't couple light into the fiber by shining on it at the side. Even for large, visible-light scintillating fiber used in this paper, you only have a few degrees of possible incidence angles that direct the light into the fiber. See for example, (one of the first results from Google), the figure on page 4 of this datasheet [0].

[0] [https://www.ethz.ch/content/dam/ethz/special- interest/phys/p...](https://www.ethz.ch/content/dam/ethz/special- interest/phys/particle-physics/precisionphysicsatlowenergy- dam/TeachingContent/ASL/bicronfiber.pdf)

</comment></comment><comment><USER8> Reminded me of the Ronja project: [http://ronja.twibright.com/about.php](http://ronja.twibright.com/about.php)

</comment><comment><USER9> Isn't it amazing how we in the "developed" nations always presume that the "developing" nations need our technology? Colonial Europe assumed the savage nations needed railroads and hospitals, and now us enlightened 21st century liberals assume the developing world needs our internet, our network of connectivity.

But do they? Are they not already connected, and are we truly connected? Consider our societies. We are epidemically depressed, living alone, and becoming increasingly friendless. The internet has undoubtedly created business opportunity (I'm work remotely as a researcher); but has it "connected" us as we were not already connected? Instead, has it in fact disconnected us in its facade of relationships?

<comment><USER10> > (I'm work remotely as a researcher)

Sounds like you're projecting your own existential crisis onto others. Maybe you should try quitting your job and finding something local and more hands on.

<comment><USER9> No projection of my own. I have a significant person in my life and friends. I'm commenting on the well-documented reality of some western cultures. I few searches brought these stories up:

Depression: [http://www.nimh.nih.gov/health/statistics/prevalence/major-d...](http://www.nimh.nih.gov/health/statistics/prevalence/major- depression-among-adults.shtml)

Living Alone: [https://www.washingtonpost.com/politics/more-americans- livin...](https://www.washingtonpost.com/politics/more-americans-living-alone- census-says/2014/09/28/67e1d02e-473a-11e4-b72e-d60a9229cc10_story.html)

Friends in UK: [http://www.telegraph.co.uk/men/active/mens- health/11996473/2...](http://www.telegraph.co.uk/men/active/mens- health/11996473/2.5-million-men-have-no-close-friends.html)

</comment></comment></comment><comment><USER11> My immediate question was isn't their bundle of optical fibres performing essentially the same function as a lens? Why not use a lens?

Answering my own question, having just read the abstract (in case anyone else had the same reaction). The claim is that they get the light collecting powers, combined with a wide field of view. A lens collects the light, but has a narrow field of view, which requires steering/alignment.

Edit: Another possibility is a Luneburg lens, a type of lens that can focus plane waves from many directions to a small area? [https://en.wikipedia.org/wiki/Luneburg_lens](https://en.wikipedia.org/wiki/Luneburg_lens)

</comment><comment><USER12> > In addition, this portion of the spectrum is not regulated

Apart from not pointing a laser at a flying aircraft. I'm guessing this would be affected by weather.

<comment><USER13> Clouds and optical turbulence are both problems that have to be mitigated by FSO systems

</comment></comment><comment><USER14> I wonder what their detector's dark count rate and activation threshold is. If both are low enough, this is precisely the sort of detector people doing free space quantum crypto need.

</comment><comment><USER15> Are they trying to re-invent Li-Fi ? [https://en.wikipedia.org/wiki/Li- Fi](https://en.wikipedia.org/wiki/Li-Fi)

<comment><USER16> the article is easily digestible and you'll find that no, they aren't. not even close.

<comment><USER12> Hm, they seem similar because both Li-Fi and free-space optical communication (FSO) use visible or near-visible spectra to send and receive information. I guess they might be seen differently as Li-Fi is potentially designed for indoor use? I don't see why they are substantially different, however, or at least incomparable.

What the post discusses: [https://en.wikipedia.org/wiki/Free- space_optical_communicati...](https://en.wikipedia.org/wiki/Free- space_optical_communication)

<comment><USER13> One significant difference is that FSO operates over a much longer distance and has to contend with atmospheric interference (clouds, turbulence, etc). Also, the transmitter/receiver hardware used is much different.</comment></comment></comment></comment>


Since its Ban, The Pirate Bay has Jumped 100,000 Places in the UK Rankings - <AUTHOR> http://torrentfreak.com/pirate-bay-ban-rockets-pirate-party-website-into-the-big-time-120518/

<comment><USER2> Is going to take a long while to sink that ship, no matter how much the governments try to make an example of it.</comment>