Why async fn in traits are hard - <AUTHOR> http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/ <comment><USER2> This article shows how it's hard to _design_ and _implement_ a novel and powerful language like Rust. You have to understand "Haskell concepts" like GADTs and then try and find a way to hide them from the _users_ of the language.

<comment><USER3> Erik Meijr and his team did wonders bringing Haskell concepts to VB and C#.

"Confessions Of A Used Programming Language Salesman, Getting The Masses Hooked On Haskell"

[https://www.researchgate.net/publication/237445028_Confessio...](https://www.researchgate.net/publication/237445028_Confessions_of_a_Used_Programming_Language_Salesman_Getting_the_Masses_Hooked_on_Haskell)

<comment><USER4> > Erik Meijr and his team did wonders bringing Haskell concepts to VB and C#.

If it took wonders to make Haskell concepts mainstream in languages with a GC, I can only describe what Rust achieves as true miracles.

<comment><USER3> Indeed, however having a GC doesn't preclude having linear types as well, thus having the cake and eating it too.

In any case, Rust has already managed other language designers to take a look into adopting such type systems ideas, in itself that is a big victory from Rust community.

</comment></comment></comment></comment><comment><USER4> > The only real drawback here is that there is some performance hit from > boxing the futures – but I suspect it is negligible in almost all > applications. I don't think this would be true if we boxed the results of > all async fns; there are many cases where async fns are used to create small > combinators, and there the boxing costs might start to add up. But only > boxing async fns that go through trait boundaries is very different.

In a situation like this:

        trait Foo { async fn foo(&self) -> Bar; }
        trait Baz: Foo { async fn baz(&self) -> Meow { ...await self.foo() into a Meow ... }

you'll end up with boxes of boxes of boxes. It kinds of makes the feature something for the outermost abstraction layer or you end up with boxes of boxes of boxes.

> And of course it's worth highlighting that most languages box all their > futures, all of the time. =)

It's also worth highlighting that most of those languages (1) have a GC that makes boxing a much cheaper operation than in Rust, and (2) those languages aren't advertised as "low-level" languages and that justifies implicit boxing as a trade-off.

\---

I feel that async shouldn't really be special but rather just build on other features that stand on its own. GATs and impl Trait in Traits seem reasonable. But being able to do dynamic dispatch on trait methods that return a type that isn't `Sized` seems like a tough problem to solve, and the blog post didn't managed to convince me that implicit boxing is the right approach here. AFAICT, we need either some kind of boxing, or better support for unsized rvalues or similar. I think I would be more comfortable with "sugar" for boxing if the caller of the trait method were in control of where exactly the result is allocated (not necessarily a Box), but that calls for some kind of placement syntax.

<comment><USER5> > most of those languages (1) have a GC that makes boxing a much cheaper > operation than in Rust

Why is that? I would intuitively think it is the other way. (Is a malloc/free pair not cheaper than an allocation on the GC heap + collecting its garbages?)

<comment><USER6> As always, it depends on a _lot_ of details. A generational garbage collector can be made to allocate extremely quickly; IIRC for the JVM it's like, seven instructions? For short lived allocations, it sort of acts like an arena, which is very high performance. malloc/free need to be quite general.

It's always about details though. If a GC is faster than malloc/free, but your language doesn't tend to allocate much to begin with, the whole system can be faster even if malloc is slower. It always depends.

<comment><USER7> Doesn't something like jemalloc basically give you this, but without pauses? Thread-local freelists for quick recycling of small allocations without synchronization.. funnily enough, jemalloc even uses some garbage collection mechanisms internally.

<comment><USER6> I don't know a ton about jemalloc internals, but it is true that a lot of modern mallocs use some mechanisms similar to GCs. There's some pretty major constraint differences though.

</comment></comment></comment></comment></comment><comment><USER8> Does anyone know how kotlin coroutines compares to async await in rust? And why did they choose async instead of coroutines?

<comment><USER6> I don't really know Kotlin, but it was discussed while async/await was being designed. [https://www.reddit.com/r/rust/comments/83tak7/implementing_k...](https://www.reddit.com/r/rust/comments/83tak7/implementing_kotlinstyle_continuations_on_top_of/) is one thread I remember.

There's also [https://www.reddit.com/r/rust/comments/6zy8hl/kotlins_corout...](https://www.reddit.com/r/rust/comments/6zy8hl/kotlins_coroutines_and_a_comparison_with_rusts/)

One tough part about digging through history here is that designs change over time...

</comment></comment><comment><USER9> What's a "semver hazard?" Doing a Google search finds very few references.

<comment><USER10> It's just a fancy way to say "risk of breaking backwards compatibility". Semver is Semantic Versioning, a versioning scheme that all Rust crates are expected to use.

<comment><USER11> Why is semver expected? Isn't it well known to be a flawed practice yet?

<comment><USER12> > Isn't it well known to be a flawed practice yet?

Care to explain? Why would using semantic versioning, something near universally accepted as a best practice, be flawed in your eyes?

<comment><USER13> It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some way for some users.

<comment><USER4> Actually, you are wrong in that semver cannot be enforced by tooling.

Rust has tooling to automatically enforce semver. For example, this tool: [https://github.com/rust-dev-tools/rust-semverver](https://github.com/rust- dev-tools/rust-semverver)

Once you modify a Rust library, it downloads the last released version, compiles it and extracts its AST, and compares it with the AST of the current version.

The diff of the two ASTs tells you what the changes are, and there is a Rust book that documents which changes are semver breaking and which aren't. So if you only add a new function to your crate, the tool says that you can bump the semver patch version or minor version, but if you change the name of a public API, the tool requires you to make a new major semver release.

Setting this tool in CI is dead easy, and will make your CI fail if a PR changes the API of your crate without properly updating its semver version.

<comment><USER11> That sounds super interesting I didn't know rust crates were managed like this.

The question in my mind is where does semver come into this?

Why do you need three arbitrary and meaningless numbers when a commit hash, branch, or tag would suffice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I grew up when OOP was the shit. Everyone wanted to add OOP to every language. C++, ObjC then Java.

I absolutely hated, not because OOP is bad, but because they never really manage to blend it just right with static typing. But I was the odd one. Everybody else seemed to love it and use it for everything.

I was lucky enough to outlive this OOP craziness.

Now I am seeing the same craziness with "a sync" and continuations and wonder if I will be lucky enough to outlive it to.

        fn get_user(&self) -> Pin<Box<dyn Future<Output = User> + Send + '_>>;

This is plain craziness.

<comment><USER15> This is a silly argument, of course de-sugaring language leads to a less nice type signature. C functions compiles down to assembly and C++ or Java hide vtables and such when you do method calls.

If you go lower in the abstraction level you get more complicated mechanics, and that says nothing over the validity of the high level semantics.

<comment><USER16> _> C functions compiles down to assembly and C++ or Java hide vtables and such when you do method calls._

I don't think it makes sense to compare the output of Rust macros to assembly code generated by a C compiler or to vtables.

Macros are part of the Rust language, as is their output. Understanding Rust means understanding both input and output. So this abstraction boundary is intentionally leaky to some degree.

Generated assembly and vtables on the other hand are compiler implementation details subject to change without notice. Any abstraction leakage is unintended and undesirable (even if developers sometimes benefit from understanding that output)

Your line of reasoning makes all debates about language complexity completely pointless.

<comment><USER5> I disagree that the user of the macro needs to understand its output. The output of a macro is an implementation detail, and the documentation of the macro should be enough to use the macro without even looking at its output.

For example, no need to understand the magic behind the 'quote!' or the #[async_trait] macros to use them.

<comment><USER16> Not every user has to understand every macro. But the output of a Rust macro is valid Rust code whereas the output of a C compiler is not valid C code.

As a consequence, criticising the complexity of whatever a C compiler generates cannot possibly be valid criticism of C's complexity on a _semantic_ level whereas criticising the output of a Rust macro can be valid criticism of Rust on a semantic level.

<comment><USER15> Nearly all C compilers allow inline assembly. Macros are similar to inline assembly in that they step outside the normal bounds/use case of the language and are a complicated but valid and useful tool.

Most C programmers won't have to write or understand inline assembly often, if ever. Of course you can encounter it in production problem or something, so you could make an argument that all C programmers need to understand "C with inline assembly", which you are making for Rust macros.

As long as you just use Rust macro's and not write your own you are solidly in "C _without_ inline assembly" territory.

<comment><USER16> _> Nearly all C compilers allow inline assembly. Macros are similar to inline assembly in that they step outside the normal bounds/use case of the language and are a complicated but valid and useful tool._

I couldn't disagree more. Macros are not similar to inline assembly at all precisely because they do _not_ step outside the bounds of the language.

Whatever similarities you may find, it's simply not helpful to deny the fundamental distinction between language A generating code in language A and language A invoking/generating code in language B.

It's futile to debate the properties of a particular language if you can't make a distinction between that language and anything it can generate or embed in some opaque way.

<comment><USER15> What I fail to understand is why it's so important to you whether a pre- processing/compiler/de-sugaring of language A results in a valid snippet of language A or another language for complexity of language A.

Take Objective-C automatic reference counting [1], implemented as a transformation of the original code to valid code of the same language (similar to a Lisp/Rust/Scala style macro) by automatically adding the appropriate statements.

If I understand your argument correctly, according to you this increases the complexity of "Objective-C with ARC", but would not have done so if the compiler would have implemented it as a direct transformation to its compilation target instead.

To me, that is an implementation detail which does not matter. "Objective-C with ARC" is exactly as complex in both cases. I'd argue it's even a little bit less complex with the "macro" implementation since you don't need to know assembly to know what ARC is doing.

Similar to ARC, Rust implements some things with macro's, which first "compiles" something to valid Rust. To me this is not more difficult for users than it would be if the compiler would directly generate LLVM IR without this intermediate step.

The inclusion of macro's in a language do make the language more complex of course! And creating macros is notoriously difficult since you're basically implementing a small compiler step! But for the user using something is not suddenly more difficult because it's implemented using a macro.

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

<comment><USER16> _> What I fail to understand is why it's so important to you whether a pre- processing/compiler/de-sugaring of language A results in a valid snippet of language A or another language for complexity of language A._

It's important because any and all code in language A is fair game when it comes to criticising semantic properties of language A. Code in other languages isn't.

noncoml criticised Rust based on a piece of Rust code. My point is simply that this criticism is potentially legitimate in ways that criticising C based on a piece of assembly code could never be.

I think our disagreement arises because you are asking a completely different question. What you're saying is that for devs who invoke some code it may not matter one bit whether that code was implemented in language A or language B or language A generated by language A or B. Those distinctions do not necessarily affect the semantic complexity for users of that code.

I completely agree with that. I also agree that the code snippet noncoml posted does not mean using async code in Rust has to be overly complicated.

But when I see a piece of Rust source code, I can criticise Rust based on it regardless of where that code came from or what purpose it serves.

Someone had to think in terms of Rust in order to write that code, and it's always worth asking whether it shouldn't be possible to express the same thing in a simpler way or whether that would have been possible in another language.

The fact that this code does not have to be understood by its users is completely irrelevant for this particular question.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


COVID-19 Tests Don't Cost Over $3,000 - <AUTHOR> https://www.factcheck.org/2020/03/covid-19-tests-dont-cost-over-3000/ <comment><USER2> Great job burying the true cost at the bottom of the article:

"Jennifer Kates, the director of global health and HIV policy at the Kaiser Family Foundation, said in a phone interview, 'there could be other costs incurred.' Visits to the doctor's office and the emergency room can cost patients money, she said, noting that some high-deductible insurance plans could effectively charge patients who go to the ER $1,000 or more."

<comment><USER3> That's just an average deductible, too. If the cost is $100,000,000, they could still say "effectively charge patients who go to the ER $1,000 or more." and not be wrong.

It also doesn't include the cost of coverage. I have a healthy friend under 40 with a healthy family, and he pays $1200 every month, with a $1,500 deductible.

So, if you pay $18k per year, it might cost you $1,000 or $1,500, but that still doesn't tell us how much it costs for a person to go to the ER and get tested for Covid-19.

For an accurate assessment, they need to report the cost for an uninsured person, or report the total that's being billed to the insurance company.

</comment></comment><comment><USER4> Whenever you go to a hospital it's impossible to tell what the cost will be. Literally, my doctor told me before my operation "I have no idea, probably whatever your deductible is" when I asked the cost

Coronavirus test or not is just a detail

<comment><USER5> > Whenever you go to a hospital it's impossible to tell what the cost will be.

Hospital emergency rooms are for emergency services.

Suspected Coronavirus patients should not be presenting to hospital ERs for testing and care _unless_ they are experiencing respiratory distress or other urgent symptoms.

Basic testing and diagnosis should be handled via local doctors. Please call first to discuss the Coronavirus protocol.

Don't go to the Hospital unless you need urgent emergency care for something. You will be charged urgent, emergency care prices.

<comment><USER6> And that is what the hospital should have told him and then sent him home. They should not have done the tests and charged him 3k for it.

</comment></comment></comment><comment><USER7> The original story as I heard was from a person who said that they were mandated to get tested because of their risk of exposure. Now we learn from the mandatory hospital stay, they got a bill for $3000 _and didn 't even get the COVID-19 test?_

<comment><USER8> Yeah, the original story is only somewhat misleading here. They had to get tested because of possible COVID-19 exposure, and doing so did cost $3000.

The real problem is that healthcare in general in the US has absolutely insane costs, not something specific to the coronavirus.

</comment></comment><comment><USER5> The amount of misinformation surrounding COVID-19 and healthcare is staggering. Some practical advice:

1\. Call your family doctor or a local doctor first. The emergency room at the hospital is only necessary if you have immediately life threatening symptoms. If you go to the emergency room, you will receive and be charged for emergency care. This is expensive because it's for emergencies. Call your doctor first!

2\. Local doctor's offices have protocols for COVID-19 testing already. This might involve some combination of staying in your car until a practitioner comes to escort you, keeping your hands folded across your chest so you don't touch anything, wearing a mask to minimize the spread from coughing, and going in a separate entrance, and staying in a reserved back room that will be carefully disinfected after you leave. Again, _do not go to an emergency room and sit in the waiting room just to be tested_.

3\. The COVID-19 test itself is being paid for by government funds, as stated in the article. However, you will still be billed for medical services rendered such as the administration of the test. This is one reason why a local doctor is much cheaper than going to a busy emergency room.

4\. Do not assume that you're positive for COVID-19 before working with a professional to understand the risk factors and diagnostic criteria. They will likely screen you over the phone to reduce the rate of false positives.

5\. If you are concerned about the cost, _please ask your doctor what your options are_. This is not an uncommon situation and in many cases there are low-cost or free options available.

</comment><comment><USER9> Sure the test itself doesnt cost $3000, but you will be out around that much money if you go to the ER to get tested. The article about the guy in miami didnt even include a COVID-19 test and he was still billed $3270

</comment><comment><USER10> I think the most important part of the story, regardless of its truth or not, is the plausibility of the situation, and that is what allowed the story to be viral.

<comment><USER5> The real problem is that people are choosing to believe sensational headlines instead of doing their own research.

I'm seeing a sharp increase in the number of young people who don't understand how their own health insurance works. They just assume it's awful because that's what they read in the news.

I can't tell you how many times I've had to tell people that generic insulin is actually only $25/vial at Walmart instead of the hundreds to thousands that they read about in the news. Yes, it's not identical to the newer, longer- acting analogs that cost more, but it's an effective option for those who can't afford the more expensive versions.

This kind of thing is actively driving people away from taking the 10 minutes to understand their health insurance and seeking proper care.

<comment><USER10> > The real problem is that people are choosing to believe sensational > headlines instead of doing their own research.

I think the real problem is that people believe they could receive a 3k bill for doing the right thing.

> I'm seeing a sharp increase in the number of young people who don't > understand how their own health insurance works. They just assume it's awful > because that's what they read in the news.

As someone who grew up with parents who had health insurance, I still had to see them choose to not go to the doctor due to costs. I saw medical bills arrive. I've had to deal with calling to find out if the doctor I needed to go to was in network, and yet still fearing that information was incorrect due to the massive bill I could expect afterwards. I've seen a 5k deductible plan staring me in the face.

Call it anecdotal all you want, but I'm not unique and this is the reason that a lot of young people know their health insurance is trash.

> I can't tell you how many times I've had to tell people that generic insulin > is actually only $25/vial at Walmart instead of the hundreds to thousands > that they read about in the news.

Assuming the other poster is correct that this isn't viable for everyone, it's a little funny given how you're harping on about those millenials/zoomers and all their lack of knowledge.

> This kind of thing is actively driving people away from taking the 10 > minutes to understand their health insurance and seeking proper care.

Most people, if they have the average ~4k deductible, are not going to go to the doctor because they fear a 4k bill.

<comment><USER5> > Assuming the other poster is correct that this isn't viable for everyone

I'm very familiar with it, actually. The idea that it's not viable for some patients is further misinformation, sadly. If you want to understand further, you can search for "insulin analogs".

The generic insulin available cheaply at Walmart _does_ work, but it also requires dosing adjustments due to the different duration. If patients take the time to adjust their dosages, it will work. If patients try to apply the same exact protocol they used with a different insulin analog, they will have problems. This is where the "doesn't work for everyone" myth comes from.

> it's a little funny given how you're harping on about those > millenials/zoomers and all their lack of knowledge.

Please, I said nothing about "millenials/zoomers". Most of the diabetics I know are neither millenials nor zoomers.

This is why I hesitate to discuss practical health care advice online. Too many people want to turn it into a political debate. I never suggested our system was great and I fully agree that we need to make changes.

But it's not doing anyone any favors to spread misinformation to amplify the urgency for political change. It's critically important that we all work on spreading the most accurate information to people so they can direct their care responsibly within the bounds of our (flawed) system, rather than using scare tactics to amplify the politically urgency.

<comment><USER11> Yale endocrinologists aren't "spreading misinformation":

>"Human insulins are a reasonable option for many patients with Type 2 diabetes," said Yale endocrinologist Kasia Lipska, who often prescribes the drugs for patients who can't afford newer formulations. "But the drug isn't optimal for everybody. And human insulin sold at Walmart is definitely not the solution to our insulin crisis."

Nor are Diabetes advocates:

>For people with Type 1 diabetes, human insulins "are harder to live on, lead to worse control, make it harder to hold down a job, impact quality of life," said James Elliott, a trustee at T1International, an independent patient advocacy group, "and not everyone lives near a Walmart."

[https://www.vox.com/science-and- health/2019/4/10/18302238/in...](https://www.vox.com/science-and- health/2019/4/10/18302238/insulin-walmart-relion)

You can't hide behind "not wanting to engage in political debate" when you yourself misconstrue the reality of the situation to make it seem less urgent than it actually is.

</comment></comment></comment></comment></comment><comment><USER12> So how much is the test?

Test costs USD ~190.- in Switzerland and all insurances are required to cover it under basic care but only suspected cases get tested (You were in Italy, Wuhan or in contact with people who were)

<comment><USER5> From the article: The test is paid for by the government.

It's the ancillary hospital services that cause the charges. If you go to a hospital, you have to pay for the usage of the hospital. This is billed to your insurance.

<comment><USER8> So, the test itself doesn't cost that much...but, _getting tested_ does cost that much.

When most people are talking about the test, I think they're talking about the whole process.

<comment><USER5> > getting tested does cost that much.

Getting tested at _a hospital emergency room_ for 20+ different possible viruses could cost that much, but you shouldn't be presenting to the _emergency_ room for basic testing. That should be handled through your local doctor.

The hospital emergency room is for urgent emergencies. ER doctors are rushing to get things done. Unless you're having severe respiratory distress, you should not rush to the ER for routine Coronavirus testing.

</comment></comment></comment></comment><comment><USER13> In Germany I think the test is free if you show enough symptoms and had contact to an ill person or you travelled to a sick area. If you do not match those criteria but still want to be tested them the test costs 500. My company covers those second scenario for free.

</comment><comment><USER14> If we don't guarantee free care for this, it's going to spread unchecked because people aren't going to go to the doctor.

It doesn't help that trump is going on tv telling people that it's just a cold and you should go into work if you have it.

<comment><USER9> Its really far too late for that. They are trying in NY (they made it free) but you can't undo decades of societal conditioning so fast. Not to mention we probably needed to get ahead of this three weeks ago since the incubation period is so long. Folks w/ symptoms have been for sure avoiding testing over the last couple weeks.

<comment><USER15> > They are trying in NY (they made it free) but you can't undo decades of > societal conditioning so fast.

I consider myself fairly well informed on these topics and I don't believe it, either (though I'm not in NY). I believe that certain regulators and governments _intend_ for it to be free, but I don't believe it will be that easy when the provider billing and insurance systems get involved.

<comment><USER9> We'll see, the governor has ordered insurers to waive all costs ([https://thehill.com/policy/healthcare/485622-new-york- insure...](https://thehill.com/policy/healthcare/485622-new-york-insurers- ordered-to-to-waive-costs-associated-with-coronavirus)), and actually California just did the same.

Maybe tax payers will end up paying in the end though, either through civil courts or some kind of backward-effective legislation.

</comment></comment></comment></comment><comment><USER16> \- my test suites runs <1s !

\- yeah, but spinning up the test env and loading data cost >3000s.

</comment><comment><USER17> Some thoughts:

1) It doesn't matter how much the test itself costs. It doesn't matter whether it even gets done. The only thing that matters is, how much you're likely to pay _if you go_ to take that test. That's the only variable consumer is considering.

2) Cool that "as of now, the two authorized testing agencies aren't billing patients for the tests" and that Medicare & Medicaid have a code for this test. That's _as of now_. The $3000 story broke over a week ago, and nothing here convinces me that this wasn't a representative number up until now.

</comment><comment><USER18> Test kits made by TIB Molbiol cost EUR 2.50 per patient. One kit can be used for 96 patients (or up to twice that number if diluted), so cost of work is spread over quite a few people. Their estimate for a reasonable price is EUR 10.00 including work.

Source (German): [https://www.tagesspiegel.de/berlin/tib-molbiol-berliner- firm...](https://www.tagesspiegel.de/berlin/tib-molbiol-berliner-firma- produziert-corona-tests-fuer-die-ganze-welt/25602142.html)

</comment><comment><USER19> Wait... Is the US really charging for the tests? If they want to stop the spread of the virus, the test needs to be free.

Actually, go one step further, they need to begin random screening. A lot of people are not presenting severe symptoms and therefore are not going to the hospital, but are still carriers.

</comment><comment><USER11> I find this kind of fact checking quite specious. The person wasn't given a COVID-19 test (presumably because the testing has been a disaster), but visited the ER, was tested for 22 other respiratory pathogens, found negative, and discharged.

Wouldn't this be true for anyone who went to the ER under similar circumstances? They would have to clear the same tests, pay the same ER fee, etc before being given the COVID-19 test.

These preliminary cost hurdles to testing aren't going to be removed simply because the test itself is now required to be covered by health insurance and Medicare/Medicaid. And what about the uninsured?

<comment><USER20> Exactly, and I agree that this type of fact check seems to be on the rise, where you carefully rearrange and redefine all the words in the initial statement, and find some narrow way in which it's then not strictly true. Fun game, but not especially enlightening.

<comment><USER21> It's literally the opposite of good investigative journalism. We've come full circle from click bait to click bait fact checking.

</comment></comment></comment><comment><USER22> For covid19 testing of low-likelyhood samples can you batch?

IE - take 64 samples, combine them, test it once.

If positive, divide and conquer?

</comment><comment><USER23> The interesting thing to me is the "who" and "why" of this disinformation spreading. Would this be considered pro-Healthcare-For-All?

</comment><comment><USER24> Nitpick:

Wouldn't surprise me if the _cost_ is $3k at this point. The _price_ is another matter.

</comment><comment><USER25> IIRC I was reading a comment on Reddit who said their family member's bill of the test was $3000.</comment>


GSAP JS – Javascript animation library - <AUTHOR> http://www.greensock.com/gsap-js/

<comment><AUTHOR> I used to use his Flash tweening library, which was great. Looking forward to try this out.</comment>


Ship crosses Northwest Passage, sails into history - <AUTHOR> http://www.theglobeandmail.com/news/british-columbia/bulk-carrier-becomes-first-to-successfully-traverse-northwest-passage/article14516278/

<comment><USER2> There are only a small number of countries that consider the entire Arctic to be national/internal waters. Most of the world, including the US ([http://www.parl.gc.ca/Content/LOP/researchpublications/prb05...](http://www.parl.gc.ca/Content/LOP/researchpublications/prb0561-e.htm#BRelations)) and all of the EU other than Denmark and Norway, consider the Arctic to be international waters.

In this particular case the coal was being shipped from Canada, which benefits Canada, who happens to claim to own much of the Arctic. Presumably ships carrying Canadian cargo would be cleared to use this route, and legally be required to seek such clearance in order to be cleared to leave Canadian port. Other ships which do not leave from, refuel at, or stop on Canadian land, would presumably be asked to seek permission to pass through what most of the world considers international waters. There are only certain countries that would even want to, but it would obviously be useful for China, Japan and Korea to use this route for shipments to Europe.

Eventually someone will take the route without permission, and then Canada will need to figure out to what extent they can assert their claimed ownership of the Arctic.

Should Canada succeed in their claims internationally, it may be a good opportunity for other countries to make use of the new doctrine as well. For example Somalia has long claimed that ships going through the Suez canal are passing through their territory, and other nations claim that these are international waters not subject to Somalian boarding for inspection and collection of fees (which other countries call piracy). It will be interesting to see if Canada prevails in its Arctic claims, while maintaining Somalia has no similar claims to control of what they consider national waters, which don't extend anywhere nearly as far from land as Canada is claiming here.

<comment><USER3> > Should Canada succeed in their claims internationally, it may be a good > opportunity for other countries to make use of the new doctrine as well.

To be fair this statement is pretty inflammatory.

There is no new doctrine. Canada has always claimed they owned these island and no other country has ever disagreed with this(1), until the past 20 years or so when oil was found under the water and the north west passage started to open up.

And to be clear, Canada has claimed ownership, of these islands since 1880, so this isn't exactly a fresh land grab:)

As can be seen from this diagram, any ship going through here sails directly through Canadian waters.

[http://en.wikipedia.org/wiki/File:Northwest_passage.jpg](http://en.wikipedia.org/wiki/File:Northwest_passage.jpg)

(1) with the exception of Denmark and hood island. However here both countries disagree about which side of their territorial borders a small island lies on.

<comment><USER4> Again: it's not about the islands, it's about the water between them.

Let's stipulate that Canada owns every island in the hemisphere. Now what? If enough ice melts that there's a passage between them which doesn't come within 12 nautical miles of an island's coast, then there's a passage that isn't in Canada's territorial waters, and Canada can't, under current international law, forbid ships using the passage.

<comment><USER5> For the passage in the wikipedia diagram, both of the two paths after the first bifurcation (moving westward) pass through channels less than 24 nautical miles wide. Canada would need to build observation towers but it could be defended with "cannons" e.g. the M777.

</comment></comment></comment></comment><comment><USER3> From the article.

> "The Canadian government needs to take a firm stand on shipping via the > Northwest passage in order to safeguard the environment and to enforce > Canada's sovereignty,

This is a big deal in Canada right now. There have been a bunch of rumblings from our neighbor to the south that maybe Canada doesn't really own the islands in our north and that the Northwest passage should be considered open water for everyone.

This is troubling for a number of reasons, specifically sovereignty, mining and oil rights and most importantly shipping of oil and nat. gas through the passage. There is a bid debate going on as to what sort of cargo should be allowed to go through the passage, specifically should oil tankers be allowed.

many people want this shipping lane closed to oil tankers, some for environmental reasons, other because they've spent billions on pipe lines. The only consensus you can get in Canada is that we own the shipping lanes and therefor can control what and who goes through it.

<comment><USER4> As I understand it, the island ownership doesn't necessarily solve this; there would still be a dispute over what happens if a passage wider than 24 nautical miles opens up. Canada isn't an archipelagic state, so would not be able to make an argument for the same sort of broad internal waters that, say, the Philippines have, so any such passage would be outside of Canada's territorial waters.

There would still be exclusive rights to economically exploit, of course, but Canada would not be able to forbid international shipping through such a passage.

<comment><USER6> I didn't pick up on this subtlety. Really good point. Can I ask about the significance of 24 nautical miles? Assuming that's an international boundary condition between Canadian territorial waters vs. international waters?

<comment><USER4> Territorial waters extend 12nm from the coast. So if there's a path through that's more than 24nm wide, some part of it must lie outside of Canadian territorial waters, regardless of the status of the islands.

<comment><USER7> Yes but exclusive economic zones extend much farther and are how a country can claim parts of the sea. Canada's exclusive economic zone covers this part of the world currently: [http://arcticecon.wordpress.com/2012/01/13/the- northwest-pas...](http://arcticecon.wordpress.com/2012/01/13/the-northwest- passage-dispute-canada-map-with-exclusive-economic-zones/)

<comment><USER4> Yes, which was why my original comment distinguished between the right to bar shipping and the right to economically exploit.

Even if Canada prevails on ownership of every single Arctic island, a passage more than 24nm wide would mean supertankers could come through, and Canada would not be able to forbid it.

<comment><USER7> But that's disputable given that Canada claims that some of the Northwest Passage is _internal waters_.

<comment><USER4> That's a claim which, from looking at a map, is unlikely to hold up; internal waters are lakes, rivers, and inlets which come further in than the baseline established by the coast.

The only exception I can find is for nations which are made up of an archipelago of islands, and Canada is not one. So again, so long as there's a wide enough route through the islands, it doesn't matter what country owns the islands -- the sea passage between them would be open to international shipping.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> The important thing isn't the crossing, it's not needing to be accompanied by an icebreaker. The oil tanker SS Manhattan [1] made the trip in 1969, but unassisted crossing makes this economically competitive.

[1] [http://en.wikipedia.org/wiki/SS_Manhattan_(1962)](http://en.wikipedia.org/wiki/SS_Manhattan_\(1962\))

<comment><USER9> Yes, and that is likely going to mean that, the Arctic is never going to freeze again (if this takes off).

Goodbye, Polar bears, we like you, but we don't think your survival is in our "national interests". Meh.

<comment><USER10> This is the first thing that crossed my mind when I even read the title. This is a sad thing and I don't think it is a cause for celebration. Next up, oil platforms in the Arctic.

<comment><USER11> >Next up, oil platforms in the Arctic.

on that side. Other side is already full steam:

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

<comment><USER10> Sad times :(

</comment></comment></comment></comment></comment><comment><USER12> Thanks in part to humanity's over use of fossil fuels, the northwest passage is now open for commerce.

The first cargo ship to make it unaided through the passage carries a load of coal.

It's sad _and_ funny.

</comment><comment><USER13> As far as I know, they could only have used Iridium satellites for communications. All of the alternatives that I'm aware of have satellites on geostationary orbit, which makes it impossible to cover anywhere outside 80 degrees North and South, whereas Iridium has 75 (originally 77, one failed, another collided with a defunct Russian satellite) satellites on the polar LEO orbit that covers literally the whole earth.

Iridium constellation consists of LEO satellites which have an orbital period of less than two hours.

Trivia: Iridium is #77 in the periodic table.

</comment><comment><USER14> Can I use this as a tangible example of climate change when discussing with my doubting f̶i̶e̶n̶d̶s̶ friends?

<comment><USER15> Do your friends doubt climate change is happening at all? Or do they doubt that it's our fault?

<comment><USER16> It's true that the more aware deniers updated their propaganda 5 to 10 years ago with the non-anthropogenic argument. But there are still a lot of less informed deniers that swallow the hardcore right-wing conspiracies whole. i.e. there is no warming, it was invented by Al Gore to take away our freedoms and establish a one world government.

<comment><USER17> Real climate has disproved all models to date. There has been no forthcoming explanation for the 15 year hiatus in warming. In other words the science underlying climate is far from known. As Feynman reminds us "It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong.". Thus we have to push on and cannot advise politicians.

Since 1979 the IPCC report has published a best estimate for the climate sensitivity. Its latest report says "No best estimate for equilibrium climate sensitivity can now be given because of a lack of agreement on values across assessed lines of evidence and studies.".

It is not a question of denying or conspiring. It's a matter of discovering the science behind our climate. Let's do it without the silly rhetoric.

By the way, if you believe the very worst prediction (proposed on the basis of failed models) then you will be interested in this link which asks what the cost of 'doing something' is. [http://topher.com.au/50-to-1-video- project/](http://topher.com.au/50-to-1-video-project/)

<comment><USER16> You're proposing "discovering the science behind our climate" by ignoring what the actual scientists are saying. For example their explanation for the 15 year pause [http://www.theguardian.com/environment/damian-carrington- blo...](http://www.theguardian.com/environment/damian-carrington- blog/2013/sep/27/global-warming-pause-mirage-ipcc)

<comment><USER18> You'll note that the article carefully doesn't link to actual data showing the amount of heat that has actually been "trapped". (No, the IPCC report is not "data". I'm talking about actual data sets that are archived on publicly available servers with cryptographic signatures to ensure that it's complete and intact. You know, the sort of thing that is routine when you're downloading a piece of code, but which the climate science community has decided is much too difficult for data on which they want to hang the fate of the planet.)

Reading between the lines, their numbers for "trapped heat" are based on computer models, not on actual data; what they're basically saying is "the only data we have doesn't show the heat, but our models say it should be there, so we assume it went into the oceans".

<comment><USER16> Good demonstration of my point. You refuse to believe what actual scientists are saying.

<comment><USER18> I refuse to believe it without checking it, yes. (I noted somewhere upthread that there was a link to a GRL paper that might shed more light on the details in this particular case.) I take the same attitude when I read a claim about physics. I don't accept arguments from authority, and that's what "actual scientists are saying it" is. Actual scientists can be wrong. So can I, but that doesn't mean they get a free pass.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> It is very sad to see that this is the case. I'm becoming more convinced that Humans have become, as Attenborough put it, a plague on the Earth.

</comment><comment><USER19> Welp. Countdown until a giant oil spill in the arctic.

</comment><comment><USER20> I'm curious what this will mean for international shipping as a whole. Not having to transit the Panama Canal means freighters are limited in size only by the dimensions of their ports of call. That alone might make the Northwest Passage attractive even for those routes where it's not the shortest path.

<comment><USER21> Keep in mind that the locks of the Panama canal are getting bigger. By 2015 a new set of locks will increase capacity of the canal and also allow ships that are up to 60% wider (55m), 33% longer (427m), and with 45% deeper draft (18m) to pass through.

Granted, even that size is not large enough to accommodate a monster like a Maersk triple-E class container ship (which is 59m wide and has too deep a draft to dock anywhere in the Americas), but the vast majority of the largest container ships in the world (see: [http://en.wikipedia.org/wiki/List_of_largest_container_ships](http://en.wikipedia.org/wiki/List_of_largest_container_ships)) will fit (91 out of 100 by my count). Whereas none of the ships on that list could pass through the current locks in the Panama canal.

<comment><USER22> I realize you mentioned this, but there would be ships bigger than New Panamax[1] and if nothing else a Northwester Passage might mean that more larger ships get built.

[1][http://en.wikipedia.org/wiki/Panamax](http://en.wikipedia.org/wiki/Panamax) Interesting, if nothing else.

</comment></comment></comment><comment><USER23> Ah, fantastic. The only thing missing from the global warming "debate" was a party that heavily benefits from a melted arctic.</comment>


Lilith: x86-64 OS written in Crystal - <AUTHOR> https://github.com/ffwff/lilith <comment><USER2> Wow. Preemptive multitasking, graphical window management, POSIX-like, in a programming language that to my knowledge it hasn't yet been done in... and in just several months of work.

There's no smoke and mirrors as far as I can tell. I dug back to the initial commit: [https://github.com/ffwff/lilith/commit/c9fa1053dc6a22d630ee6...](https://github.com/ffwff/lilith/commit/c9fa1053dc6a22d630ee62163d3504f4c003cea8) \- and it's just bootstrapping to VGA.

Very well done, and inspiring. Makes me want to try OS dev again.

<comment><USER3> Maybe it's just because I come from Ruby, but Crystal seems like an amazing language. I'm interested why it seems to be getting little attention compared to Go, Rust, & Julia. It seems in the same league to me.

Kotlin and Swift have more obvious reasons for their adoption.

<comment><USER4> What's Crystal's unique selling point? It's older than Rust, Kotlin, Swift, Nim, or even OCaml, and doesn't really offer anything they don't. More Ruby- like syntax? Fine, but most people don't particularly like Ruby syntax.

<comment><USER5> > It's older than Rust, Kotlin, Swift, Nim, or even OCaml, and doesn't really > offer anything they don't.

Crystal is only five years old.

Nim is 11, Rust is 9, Kotlin is 8, OCaml is 23 and Swift is 5.

Basically, Crystal is tied with Swift as the youngest.

What it offers right now is a simple porting process for those with Ruby codebases.

<comment><USER6> I think they meant younger.

But, yeah, besides the syntax familiarity for Ruby programmers it doesn't seem offer much that the others do.

<comment><USER7> Okay, port your existing Ruby code to a compiled language, giving it multiple times the speed? Maybe three is a slight business opportunity here.

Also, give your developers a more productive language that can go where Ruby can't (like OS development), which is 90% instantly recognizable — may also be worth something?

<comment><USER4> Is it really so hard to port Ruby code to any of the languages I mentioned? Even with Crystal you will still have to make changes to your code, is having to use a slightly different syntax such a big difference? If you've got Ruby code and you haven't already ported it, how badly do you need the speed?

<comment><USER8> Mentally context switching between Ruby and any other language to do the translation actually is kind of a hassle.

<comment><USER6> I could imagine, that the subtle differences could get you ugly problems while porting.

<comment><USER4> Won't the differences be more subtle and difficult if you use a language that's syntactically Ruby-like but not actually Ruby?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Oh wow someone actually posted this! Thanks a lot for the comments and criticisms guys, really means lot to me. Before I go I'll answer some questions, so ask them away!

<comment><USER10> How old are you?

<comment><USER9> shhh.

</comment></comment></comment><comment><USER11> Is the dev a high school student? From their blog: [https://fw.neocities.org/blog/5.html](https://fw.neocities.org/blog/5.html)

If so, this is crazy impressive.

<comment><USER12> Apparently they've also written a language, a static site generator in that language, a brainf*ck interpreter, and a markdown parser, among other things. Super impressive stuff. [https://github.com/ffwff?tab=repositories](https://github.com/ffwff?tab=repositories)

<comment><USER13> >Neural networks that learn to generate anime faces.

This is my favorite

</comment></comment></comment><comment><USER14> Two things that I immediately respected about Crystal's landing page [1]:

\- It shows numerous code snippets covering various functionalities. Not just "Hello world" but code samples that give you a very solid flavor of the language.

\- Its spinning logo can be manipulated with the mouse.

[1] [https://crystal-lang.org/](https://crystal-lang.org/)

<comment><USER15> i really like that spinning crystal; its a small thing really, but i find it very endearing

</comment></comment><comment><USER16> This is really impressive! Crystal was just barely on my radar until now: it's a lot higher up now.

For anyone unfamiliar:

[https://crystal-lang.org/](https://crystal-lang.org/)

<comment><USER17> Crystal has the most badass color on Github. Solid black.

<comment><USER18> It's actually #000100.

</comment></comment></comment><comment><USER19> I've been following Crystal for long time (Shameless plug I've been running a geo-location service in production for years now [https://gitlab.com/maxpert/crlocator](https://gitlab.com/maxpert/crlocator) and it works flawlessly). Despite the setbacks in past Crystal has continued to evolve and I am waiting for fully baked version 1. I am not surprised that Crystal can pull of something like running a complete operating system. Modern language landscape is getting populated and brings novel ideas (Rust, Zig, Golang, Julia); and Ruby's nice syntax with efficiency of compiled language IMOH still remains desirable for a lot of us.

</comment><comment><USER20> I just missed it on my earlier comment.

Homage to the Modula-2 OS, Lilith?

[https://en.m.wikipedia.org/wiki/Lilith_(computer)](https://en.m.wikipedia.org/wiki/Lilith_\(computer\))

[http://pascal.hansotten.com/niklaus- wirth/lilith/](http://pascal.hansotten.com/niklaus-wirth/lilith/)

<comment><USER9> Cool coincidence but nah. Maybe its a reference to the first angel in Evangelion? Maybe its a reference to Adam's wife? Maybe its best girl from Machikado Mazoku?

Hint: asuka best girl.

</comment></comment><comment><USER20> Lovely, very inspiring to see "not yet another UNIX clone in C", in a language like Crystal.

Wishes of a successful long term project.

I will be adding it to my OS list.

<comment><USER21> Is your OS list public?

<comment><USER20> Yep, and easy to find with some Google-fu, however there you go.

[http://www.progtools.org/article_new.php?name=safe_systems&s...](http://www.progtools.org/article_new.php?name=safe_systems&section=compilers&type=tutorial)

</comment></comment></comment><comment><USER22> Wow. That's impressive.

Crystal is a solid alternative to Go. I gave it a solid look when figuring out which language I should learn. The only reason Crystal didn't make it is because it's just missing some core features. The one that sticks out is there is no way to get the length of a channel last time I looked.

But this is impressive and I can't wait to see what's next

<comment><USER23> It's missing many things that make it a viable language:

\- libraries

\- community

\- support

The language itself is not even finish or properly tested.

<comment><USER24> I can only see 1,209 repos after using Crystal for close to a year, some are no longer maintained. [https://github.com/topics/crystal](https://github.com/topics/crystal)

There are lacking of stories around the cloud computing or any large businesses has success with Crystal. They need more of those to gain support if they don't want to remain in "uncharted territory" which mentioned in their interview.

<comment><USER25> [https://crystalshards.xyz/](https://crystalshards.xyz/) is the de facto aggregator of various libs for the language.

<comment><USER24> I'm aware of this nice site, but I think you are aware Kemal threw an unfriendly message error when you reach to the last page? 100's shards on each page is rather slow and limited options to search, I would prefer to stick to Github or self-host with Github API that supported some language.

[https://crystalshards.xyz/?&sort=updated&page=11](https://crystalshards.xyz/?&sort=updated&page=11)

</comment></comment></comment></comment></comment><comment><USER26> How does memory management work in Crystal. Is it RC or GC or manual?

As a D user, I've been curious about Crystal for a while, but until it gets proper Windows support I won't be playing with it too much.

<comment><USER9> Out of the box, Crystal does garbage collection through the boehmgc library, however if you pass in some compiler flags you can get application to not use GC.

As for my OS, I wasn't gonna port libgc, and since I have prior knowledge of building a GC in rust (very badly!) I decided to make a tri-color concurrent, mostly precise (through compiler patches), garbage collector, in Crystal.

<comment><USER27> Have you read Mike Pall's proposal for a quad-color collector in LuaJIT?[0] That you took this approach leads me to think you'd find it interesting.

[0]: [http://wiki.luajit.org/New-Garbage- Collector](http://wiki.luajit.org/New-Garbage-Collector)

<comment><USER9> I've read up on how luajit does garbage collection (in fact the current gc/allocator with allocation/marking bitmaps is inspired by his tri-color gc. Apart from specifying when the GC should run, I won't be changing anything about the core gc algorithm used in the project anytime soon.

</comment></comment></comment></comment><comment><USER28> This is one of the most fun things I've seen in a while. Congrats.

</comment><comment><USER29> Just this morning I was pondering the same thing in Elixir.

I wonder if Elixir and Crystal compete for ruby developers to pick up

<comment><USER30> I think Ruby developers are a lot more likely to switch to Crystal than Elixir. Elixir encourages a much more functional style than I think Ruby developers are used to.

<comment><USER31> Probably depends on the type of Ruby developer. As a Rails guy Elixir seems more useful for my day-to-day but Crystal is indeed compelling.

</comment></comment></comment><comment><USER32> Crystal is soo good. I could read the code and understand it.

</comment><comment><USER33> What is that beautiful desktop wallpaper? any source?

<comment><USER34> There's a link at the bottom of the readme.

[https://www.pixiv.net/en/artworks/78375860](https://www.pixiv.net/en/artworks/78375860)

Seems to require login, though.

<comment><USER35> View Source, and you can find the direct link...

[https://](https://) i.pximg.net /img- original/img/2019/12/20/00/00/03/78375860_p0.png

(Deliberately made unclickable, because you will get a 403 unless you send the correct Referer.)

</comment></comment></comment><comment><USER36> For those who like Crystal, they have bountysource [1] to support their development.

[1] [https://salt.bountysource.com/teams/crystal- lang](https://salt.bountysource.com/teams/crystal-lang)

</comment><comment><USER37> So how would this compare performance wise to a lightweight linux with lxde? Can you run this on a raspberry pi and get good performance? What are the minimal memory requirements?

<comment><USER18> I doubt this is usable for general purpose work; many filesystem interfaces are unimplemented.

</comment></comment><comment><USER38> The name is great too! Just in time for co-marketing with Diablo 4 ;)

</comment><comment><USER39> I wonder what the plan is for a media layer - audio and video streaming, etc?

Sure would be fun to write a content-creation app - i.e. DAW - for such an environment.

</comment><comment><USER40> I don't even know what to say, but you are definitely the captain now.

</comment><comment><USER41> As admirable an accomplishment as this is, and as with many other projects where the arenan is highly saturated, I feel the README should start with a quick WHY? section. I'm truly not trying to dismiss the programmer's great deed.</comment>


Ask HN: What ISP do you use, and what do you recommend? - <AUTHOR>

Which internet provider do you use? And which would you recommend for speed, reliability, customer service, etc... <comment><USER2> that reeeeaally depends on the area you live in. You'll probably not get the answer you want if you're not more specific.

</comment><comment><USER3> At my address I can have Comcast (what I use), or CenturyLink DSL.

Oh, for the days when you _chose_ an ISP, rather than submitted to one.</comment>


How to Get Hired: From a Developer and Manager Point of View - <AUTHOR> https://code.likeagirl.io/how-to-get-hired-from-a-developer-manager-point-of-view-5c8a43c8ce95 <comment><USER2> To summarize the article: you must eat, sleep, and shit code, and tell the whole world about it all the time in order to prove that you're "passionate" about programming.

Yeah, you can do that, if you legitimately want to. Or you can have a life away from the computer and go outside once in a while. So here's some different advice.

DO: Be good at your craft. Be able to go into an interview and discuss architecture or algorithms or whatever it is that you're interviewing for with the people you're going to be working with. Be able to talk about your thought process, so that even if maybe you don't remember the exact syntax of some API call or command-line utility, you can explain to the interviewer what you're thinking and why.

DON'T: Don't for a minute believe that you must be "passionate" about programming in order to enjoy it or to be good at it. Don't forget that you and your employer are engaged in a business relationship, and nothing more. Don't romanticize your job or define your self-worth by the fact that you work for FaceAppleGoogSnapZonFlix (or that you don't).

And don't work your ass to the bone chasing _someone else 's_ big idea.

<comment><USER3> I completely agree with you in principle, yet I still find myself working on a personal website with stuff to show off how I think and work.

In any industry, you need to capture people's attention one way or another. You can craft your personal brand through a website, and your projects and your articles --

Or you can craft your personal brand in person, by schmoozing and networking and making sure people know who you are and what you can do.

I'm not the best people person, but I am a truly excellent software engineer and businessman. I haven't had much success maintaining a loyal network of people who will connect me with opportunities, but I do have an excellent track record of building great software.

The problem is, how do I convince people of that? Most of my code is proprietary and cannot be shared with prospective clients or companies.

<comment><USER4> I believe that insisting on seeing code is a trap. Code is notoriously tricky to evaluate without actually running it for a while, anyway - look at all the bugs that make it through code reviews - so it works well for "ok they're not completely full of shit" but rarely a lot beyond that.

If there's truly interesting and clever architectural stuff going on, that can be explained in words in an interview (in person or not). That puts some burden back on people skills, but... if you're creating clever solutions you can't explain to other technical people, I'm going to be worried about your ability to work on a team anyway.

If I'm hiring someone with more than 5 years of experience I'm hoping they can tell me some interesting war stories or have some interesting design ideas when asked about a potential business problem.

</comment></comment></comment><comment><USER5> All of the recommendations are just manifestations of, or proxies for, the really important things you need to be a great developer: enthusiasm, energy, curiosity, dedication and thoroughness. In general, for most programming jobs, the technical stuff is unimportant by comparison.

I would like to throw in a note of caution to what's being presented here as desirable traits. It's all just trumpet-blowing and self-promotion, AKA advertising. The results obtained generally never match the level of noise being generated. Most of the really impressive people I have worked with have been very or perhaps too quiet or self-starters. These are the types of people you need to seek out if you really want to doing something worthwhile.

</comment><comment><USER6> Passion is the biggest red flag from a company to me. It often means we want to work you to exhaustion.

<comment><USER7> I've heard that argument, but recently I've started to disagree with it. I can only speak to my limited experience, but my three prior gigs have all wanted some amount of "passion", but never once was I expected to work 50/60+ hour weeks as a result. There was crunch time once where we came in on a Sunday and the company paid for lunch and dinner, but that was it.

Anyway, now when I see that companies want "passionate" people, I interpret it to mean "convince us you're enthusiastic enough during the interview". It's all a game of how much you can bullshit. I like to believe that most managers, and especially most developers, realize that most code isn't "sexy", because most software isn't "sexy" and most developers are working on most software.

Caveat: I work in the Midwest. Maybe things are different in Silicon Valley, where every startup seems to fancy itself as changing the world.

<comment><USER8> > "convince us you're enthusiastic enough during the interview". It's all a > game of how much you can bullshit.

I agree with both you and GP and it's only convinced me more that 'passion' is a toxic word.

</comment></comment></comment><comment><USER9> > have a pet project

I do. My daughter. She's vastly more interesting.

<comment><USER10> I don't mention my family in an interview unless the interviewer mentions their own family. I've had a couple of instances of (possibly) agism in interviews, and I am doing my best to get hired.

<comment><USER11> I always mention my family. I want to be "discriminated against". I want any company I work for to assume I'm going to put my family first. I don't want to work for a company that expects any less.

<comment><USER9> I always mention in the following context:

"When necessary I will work overtime, but I prefer not to. I do not normally stay extremely late because I have a child that I care to see."

If a company reacts negatively to that, I will not accept the job. If they later complain I will remind them that I mentioned this before even starting. And most people are understanding, or you just don't want to work for them.

</comment></comment></comment></comment><comment><USER12> It's interesting how much advice given is "show people hiring you your programming projects". I don't find this does so much for me, because projects I want to work in in my spare time don't have any relation to the job I do. Now, perhaps that might be my failure in managing my career, but I don't know about that.

Now, those things might be _interesting_, but they're not as immediately impactful as "I made an SPA for my personal site using React & Redux, so I'm ready to use React & Redux to make SPAs at work". Very few people are hiring, for example, to make Emacs packages, generative art, write anything in Lisp, or a cigar box guitar.

And there's something exciting about doing the things I like only as much as I like them -- if I had to make a dozen cigar box guitars every week, I wouldn't enjoy it as much as I do the ones I have in progress.

</comment><comment><USER11> This article is definitely meant for someone just starting out. I was about to dismiss this completely, until I realized I did something similar to get started - back in 1994 and not on purpose.

I wrote a HyperCard stack that was basically a much better Eliza clone and posted it on AOL. A guy from another college over 100 miles away saw it and asked me to do a side project for him while I was in a no name college.

A year later, during the summer of my junior year, I put that on my resume and along with my interview skills, I got a paid internship with housing in Atlanta.

The next year after college with companies not exactly beating down my door to hire me from a no name state college, I was offered a full time low paying job as a computer operator back at the same company.

That served the purpose (along with help from my parents) of getting me back to Atlanta from the small town I came from. They had one new programming project that lasted until 99. I left, got my first real programming job and from then on my resume, interview skills, and networking with recruiters made it really easy to get jobs whenever I started looking.

I don't have a single line of code on GitHub, I don't have a blog, and I am on LinkedIn but don't worry about curating it that much.

</comment><comment><USER13> "Our field changes constantly, so if you stop coding for one moment, technology may pass you up."

In my view you can easily skip a few generations and nothing is lost. Its not hard to catch up if you actually want to. And if you work on something worthwhile for a while you most likely will rely on mature stuff that works. Chasing the latest tech all the time seems a suckers game. Spend your time on doing something well instead.

</comment><comment><USER14> Young and Foolish...</comment>


Funding DRACO research - <AUTHOR> https://www.facebook.com/TheDRACOFund

<comment><AUTHOR> We expect to have information over the next two months... in the mean time, if you care to, please like the Facebook page so we can establish an effective communication channel.</comment>


The "book" is dead - <AUTHOR> http://diveintomark.org/archives/2011/04/29/the-book-is-dead

<comment><USER2> > who bothers to steal books these days when you can go to Stack Overflow or a > web forum or, yes, even Google, type a question, and get an answer?

He's definitely wrong about this point. A book proposes answers to questions you didn't even know you had. A book can save you the trouble and time of searching for a thousand different queries. There is definitely value in having the information logically organized, all in one place, with the same tone, and the same assumptions about the reader's level.

Q&A sites are complimentary to books, not a replacement.

<comment><USER3> Absolutely. Today, if I need to know about a specific CSS technique, I can Google it. A few years ago, when I was clueless about CSS, I didn't know where to start. So I read "CSS: The Definitive Guide." It walked me through why CSS exists, all the things it can do, and best practices. I would never have known the questions to ask without such a a well-organized guide.

Any time I want to learn a new topic, I get a book. And, incidentally, I still like paper books, because when I'm reading on the couch with one, there are no distractions. A computer offers too many other things to do besides read.

Books may change forms and distribution models, but there will always be a need for well-organized and thorough books.

<comment><USER4> _I still like paper books, because when I'm reading on the couch with one, there are no distractions. A computer offers too many other things to do besides read._

Another thing that you can't yet do on the computer is highlight. I highlight important sections as I read technical books and it improves my comprehension immensely. As an additional benefit, when I come back to the book, I have to spend much less time hunting around for the information I need - the things that I've found valuable in the past are already made prominent.

Try doing that with a Kindle :)

<comment><USER5> Kindles have built-in support for highlighting and annotations, although using the buttons to highlight is surely slower than using a physical highlighter. If you're just highlighting important passages and not every other sentence (as some people are wont to do), it shouldn't be a problem.

</comment></comment></comment></comment><comment><USER6> We've had cookbook/FAQ style technical books for years. If that was a superior format then the chaptered linear book format would have died out before this discussion took place.

When people talk about the death of a particular genre of books or the publishing industry, I am reminded of books of poetry written by living authors.

The poetry book has been dead from a publishing perspective for a number of years. A large portion of single author poetry books are printed as the result of contests, many of which have an entry or 'reading' fee. Great poems are found easily on the internet, and almost no one speaks of poem piracy because the number of words is often quite small.

Despite the arrival of poetry book doomsday, it's still easy to stuff a bookcase full of little poetry chapbooks. There are poetry books printed at fine art presses with complex bits of vellum, embossing and debossing. It's even a friendlier industry now that large publishers have all but ignored it.

It sucks that it's not so easy to make a job of it anymore. However, lack of a traditional publishing industry is unlikely to kill the technical book.

(edit: repetition)

</comment><comment><USER7> I think the title was poorly chosen.

Is the technical book dead? Well, it's declining but I wouldn't say dead yet. The problem with the market for technical books is that there are tons of them. Everywhere. Some are good, many are bad and there are a few 'classics' (Knuth, Stephens etc.). I think the problem with technical books (in our spheres) is that they don't integrate with the reader's workflow. The reader is often at a computer when reading a programming book. Switching between the computer screen and book page can be mentally expensive compared to having it open on the screen next to you. The pirated versions of books (particularly epubs) tend to be better indexed, can be copied and pasted and more easily integrated into your daily life. These are the challenges that technical books face. The pirated versions often provide a better user experience. It's the same (or rather similar) with DVDs.

Now taking that a little further to the title. The book (in general) is not dead, very far from it. I took an ereader on holiday last year and read through about 12 books in 4 days. It was the only piece of tech that I took (I like to unplug). It doesn't feel the same, but as with comparing FLACs to Vinyl the experience makes up for it in it's accessibility. Having said that, I still prefer to read books where I can. Having a Star Trek TNG style reading experience is great, but having the paperware feels an irrationally superior experience.

</comment><comment><USER8> I kind of see the original point as it relates to coding, but anecdotally StartupsOpenSourced.com has made $10k+ in revenue in the past week (not all of it is owned by me, but that's what people have paid so far)

I think it fits into more motivational type of book than anything else. At the end of the day, it's like Starcraft casters: there are guys like HD, Husky, and Day9 but I don't think they ever see themselves as competitive (while the users seem to think the exact opposite) because users will always want to watch more of them. just like I would never see something like Mixergy as competitive because the two things are so complimentary, plus it seems like there isn't really a lot of reading material for early stage founders anyway. Mixergy, StartupFoundry, and Founders at Work might be the three things I'd go to, thinking off the top of my head.

I want to believe that if what you write has some value to it, people are willing to pay. I didn't pay for Photoshop licenses until I was about 18, when I could actually afford it, so I pirated it until I could. There was enough value that it allowed me to pay for it over time.

</comment><comment><USER9> Good post.

As someone interested in HTML and CSS, the books available are so unfathomably meagre with useful, new content - the newest books are basically even worse. There's this culture of making CSS books that largely repeat themselves with very random compositions. Often, they make a site and slap on some CSS3. I don't recommend learning HTML and CSS from anywhere else than HTML Dog, CSS Pivot, and just playing around with your own experiments. It boggles the mind that this can really be the case - CSS hasn't changed a lot in many years, and the big difference is mainly that there's a larger chance that a browser will support your code.

Having said that, there still are purposes for some books. Just look at the Python debate. Getting into Python is a pain in the ass compared to HTML/CSS. I am currently annoyed that I can't find an up-to-date Django book, and DjangoBook.com is not a very good resource - it seems to suffer from the wiki syndrome where a lot of co-editors have removed any sense of style and red thread to follow.

<comment><USER10> I do recommend some books: <http://www.cssmastery.com/> <http://handcraftedcss.com/> <http://simplebits.com/notebook/2009/06/09/wssse/>

<comment><USER9> Those are the exact same(!) books I would recommend. The only different thing I would write is an added "... if any".

</comment></comment></comment><comment><USER11> Having just now taken delivery of a new technical book - Learn You a Haskell for Great Good! - I'm guessing that rumors of their death, as Mark Twain said about his own, are greatly exaggerated. I bought it on the basis of an online review that would inform this discussion. <http://www.jerf.org/iri/post/2910>

In the review, Jeremy Bowers discusses his own experience trying to learn Haskell over the past few years from the random bits and pieces that float about the web and how the careful development of ideas in this book "blew what turned out to be my rickety assemblage of concepts apart and replaced them with a solid understanding of what is going on with them, and why."

We tend to forget that learning is not the same as carrying around a giant reference book. It's a painstakingly linear process where leaps of understanding happen only when a solid foundation is in place. Books and the linear style of books will always be with us, but to compete with instant search writers must learn to teach.

</comment><comment><USER12> Warning: slightly off-topic.

Is the book really dead? The post's title is poorly chosen. Until e-books come anywhere near the experience of reading a physical copy of say _À la recherche du temps perdu_ , the book isn't dead.

Clearly the post isn't about Proust, and I hope I don't come off as an ass for being picky about the title.

The post is about technical (especially computer-related) literature, and I think it's inevitable that this genre will suffer greatly. I think it will be supplanted by more interactive alternatives, which is great. There is something strange about a paper book full of source code, isn't there?

And let's be honest: 90% of the books on software engineering (and perhaps on computer-related subjects in general) that should never have gone through a printer.

<comment><USER13> I'm not sure it is off-topic so much as out of context. It's not just a technical post, but in large part a very technical blog and the author of the post is also the author of 'Dive into Python, Greasemonkey and HTML5', so it is also somewhat a reflection on his own work and place in the technical publishing sphere.

</comment></comment><comment><USER14> This sub-thread, <http://news.ycombinator.com/item?id=2500758>, to a request for a book on learning python, makes several general good points for why books are still useful and important.

</comment><comment><USER15> Google's search enables the consumer. Obviously the consumer seeks the lowest possible price, and legality has nothing to do with this.

</comment><comment><USER16> Worst. Font. Ever.

<comment><USER17> I would not go that far but it definitely seems a poor choice as for me it has coloured edges, looks blurry and is a strain to read. I use a TFT screen, this font seems like it is not doing that specific feature I forgot the name of.

<comment><USER18> subpixel rendering perhaps? (Microsoft calls it ClearType).

The font looks terrible on my linux machine, it looks fine on the macbook.

<comment><USER19> Looks great on Ubuntu here, possibly because of the higher-than-average DPI?</comment></comment></comment></comment>


Ask HN: Any legit reasons for non-self-service service cancellations? - <AUTHOR> Recently I've had several frustrating instances of being able to self-service signup for some paid service but then when I end up wanting to cancel it, it is not as easy. Generally in these cases you have to email them requesting a cancellation, and then they may have a follow up email requiring you to confirm more details. In a rare (and exceedingly frustrating) instance they required you to call them in order to cancel.
In my mind, this is a shady business practice which should be regulated against. If you can sign up in a self-service way, you need to be able to cancel in a self-service way. The way I see it, the businesses who do this are not proud of/confident in their product/service and want to make sure they keep some of the recurring revenue from those who can't be bothered to go through the more complicated cancellation process (especially if it is a low monthly cost service).
I would love for this to be something regulated, but at the same time large brush stroke actions are risky and can negatively affect groups you didn't realize.
I'm curious if there are any legitimate reasons why self-service account cancellation is impossible when you are also able to sign up and pay for the service on your own. <comment><USER2> California law [1] requires online services to offer an unsubscribe option. The only reason to add friction to the cancellation flow is to continue earning revenue from users who give up easily.

[1] [https://legiscan.com/CA/text/SB313/2017](https://legiscan.com/CA/text/SB313/2017)</comment>


Apple-Centric Observers Get the Facts Wrong: H.264 Still Ain't Free - <AUTHOR> http://createdigitalmotion.com/2010/08/apple-centric-observers-get-the-facts-wrong-h-264-still-isnt-free-for-firefox

<comment><USER3> A meta-comment on the article:

Apple-centric observers weren't the only ones to get the facts wrong, and phrasing like that title is only used to make a point. This implies that non- Apple-centric observers got the facts right. I don't know about you, but I'm not an "Apple-centric observer" and I had no idea H.264 wasn't free.

And since I'm one of many, then the goal of this article was either to a) notify Apple-centric observers that H.264 isn't free and/or b) point out to everyone how biased Apple-centric oberservers are, how they just eat up everything Steve Jobs says, and high-five non-Apple-centric observers for being so coolheaded, rational, and informed. And since "Apple-centric observer" is clearly a codeword for "Apple fanboy," the implication here is essentially "smart people don't like Apple" or worse yet "if you like Apple, you're stupid."

This is just flamebait disguised as news. Fanboys accusing fanboys of fanboyism. Move along, nothing to see here.

</comment><comment><USER4> Oh dear... I understand the good intention, but I think the author has got a lot wrong.

All these talk about Safari being the only roadblock...

First: Internet Explorer is apparently fine because Microsoft supports it via separate coders... but that's exactly what Apple does too. Safari simply uses whatever is installed in the OS.

Second: I'd be surprised if Safari, the forth browser online with something like 5% of the market could actually force anything. This is not IE6 that we are talking about!

<comment><USER5> It's Mobile Safari with its impressive mind/marketshare and total lack of user customizability that's the main battleground here. (Though luckily most of the iDevice installed base can only cope with baseline H.264.)

Safari on Mac OS X will pick up WebM decode as soon as Perian auto-updates to it. Perian (basically ffmpeg for Quicktime) being one of the must-have installs on Mac OS X in order to play any video/audio codecs and containers outside the blessed subset that Apple chooses to support.

<comment><USER4> What does Blackberry use then? Or what will Windows Phone 7 use? And WebOS? (I am asking seriously)

I think in the mobile realm you can't blame a company for not supporting a format without hardware acceleration. Now, once the new chips arrive with WebM acceleration, and someone doesn't support it then sure, I agree that sucks.

<comment><USER5> Apple's the only manufacturer that seems to make a selling point out of not shipping tools that users can shoot themselves in the foot with.

A perfect example is mobile Flash, which is (or soon will be) a major selling point of basically all non-Apple mobile devices and runs lots of legacy VP6 video without hardware acceleration. And Adobe has committed to supporting VP8/WebM in future Flash versions.

<comment><USER4> Ok. First I think the jury is still out if it will be a major selling point or not. Maybe you are right, maybe you are not. It seems a bit premature to use such adjectives.

Second that is true about Apple. But that's their philosophy: I am sure if Firefox can have their own philosophy so can Apple. They like things that work, and work well (though sometimes they fail, as shown by the antenna problem). I don't see any reason why Apple wouldn't include WebM support once its hardware is capable of decoding it in hardware.

But if your argument is that Apple should implement WebM despite it being much worse for mobile simply because otherwise Firefox can't join in, then I think you are asking a bit much.

If it hardware acceleration weren't important for the battery then I would agree with you that Apple should implement WebM pronto (while still keeping AVC). As it is, I think there are not clear rights or wrongs, and it's up to each company to decide what they think we'll be best.

</comment></comment></comment></comment></comment><comment><USER6> I don't think it's such a big drama. My prediction would be that h.264 will continue to dominate in the next years, either displayed using Flash with a HTML5 fallback (for mobile Webkit browsers) or the other way around, depending on how that whole Flash thing turns out. Heck, that's not even much of a prediction, that's pretty much reality right now. What Firefox does or doesn't do doesn't matter, the next changes will only come with the next generation of codecs.

</comment><comment><USER7> OS X and Windows have licensed encoders, right? Is it possible for Firefox and others to use those on OS X and Windows and use a less-than-legal decoder on Linux as is, AFAIK, done for MP3s and DVDs?

<comment><USER8> I don't think it's the technical obstacles that much, then the principle of the thing. And I can't say I disagree with it.

The GIF fiasco illustrated very visibly what cans of worms can be opened when propriatary, patented technologies undermine open standards.

I tend to agree with the author that it's more of a pr coup then anything else.

<comment><USER9> Actually, there are also technical obstacles.

The first time there is an exploit in system-provided video decoder (any decoder, not just H.264), you can be sure, who will get blamed for that - <USER2> browser, of course. So any browser maker wants to make sure, that they can update anything, that is being touched by web.

In case of Apple and Microsoft, they both can update the system provided H.264 decoder. In case of Opera, Mozilla and Google, they can not. This is one of reasons, why all three browsers bundle their own decoders (the another one is multi-platform consistency).

<comment><USER4> I think there's a certain irony in this. Isn't FOSS a big proponent of these sort of dependencies? I mean, whenever you discuss Windows or MacOS way of installing software, you'll hear how Linux does it better because each component is separate and therefore they can fix something upstream and your software will automatically use it.

But suddenly now people complain because a piece of software doesn't have control of their pieces...

How are these two views consistent?

(incidentally: I like the Linux's way, and try to replicate it as possible with Macport).

<comment><USER10> I think this has more to do with GNU/Unix design philosophy rather than being an explicit part of FLOSS ideology.

Also, you need to remember that GNU/Linux projects do have a certain amount of control over upstream, seeing as the source is publicly available and can be forked/modified. On the other hand, if Firefox relied on proprietary software, they would be completely at the mercy of decisions made upstream.

</comment></comment></comment></comment></comment><comment><USER11> The whole codec discussion instigated by the Mozilla Foundation is so mind- numbingly odd that it makes me cringe. I fully understand the arguments that creating a completely free and open source web browser is an important and non-negotiable goal. Nevertheless the (non-existent) dilemma relies on the false assumptions that:

1\. Deciding on a single codec that everyone should use for everything, forever (or until we get to have the same discussion again with HTML6) is the only way forward. Which is just stupid and ignorant. Different codecs are good for different use cases. There is no "one true codec"and there never will be. H.264 is a good all-around video codec for hi-def internet video, which is why it is popular on sites like YouTube, etc.

2\. "Support" does not have to mean including code in the Firefox browser for decoding H.264 video. It simply means that the browser makes a best effort try to play the video. That's all that the end user really cares about, and that is easily accomplished by using the codec frameworks already present in most modern operating systems. Webkit uses Quicktime to play media on OS X and thus supports all formats that Quicktime supports, for example.

<comment><USER8> "Deciding on a single codec that everyone should use for everything, forever (or until we get to have the same discussion again with HTML6) is the only way forward. Which is just stupid and ignorant."

Mozilla never dictated that there should _be only one codec_. It's my understanding that they are happy to support any coded, which is not encumbered by patents.

You're putting words into their mouth, which they never said in this form.

<comment><USER12> Not quite. Mozilla was one of those pushing for the HTML5 spec to _require_ support for Ogg Theora. Fortunately, saner minds prevailed and explained what a stupid thing it would be for a spec with an expected lifetime of a decade or so to mandate a 2009-era (when this first started being an issue) codec.

<comment><USER13> Correct, except that Theora (née VP3) is really a 2000-era codec (and one of the worst of its generation)

</comment></comment></comment></comment><comment><USER14> One day, the Mozilla folks are going to wake up and realize that all the opinion-makers abandoned them for Safari and Chrome.</comment>


Ask HN: When does it make sense to complete rebuild a web application? - <AUTHOR> This open source application is built on the same PHP codebase that existed since 2001. Over time it developed for example a custom MVC framework, a templating engine, ORM and object serializer.
On one hand it is very hard to get new developers on board, since there is no good documentation and there were questionable decisions in designing this application.
On the other hand, this software is widely used and deployed at different locations. It's not terrible but also not a great experience using it.
Would you rebuild the project from scratch? How would you go about it? Would you use a web framework?
(Mentioned software is Stud.IP, a campus management system and e-learning platform for German universities) <comment><USER2> Rarely.

Complete rewrites invariably take far longer than expected. That old codebase, however messy, includes almost two decades of decisions, lessons learned, special cases, and tribal knowledge. The rewrite will surface each one of those issues again over time.

Second, you need to retrain everyone on the new software. Surely the new UI/UX will be better, but how many people have years of accumulated knowledge in the old software? It's not just about retraining. Some of the old users will hate the new system just because they don't like change. It may be objectively better, but if it makes everyone complain to your boss's boss every day because 100 people had to relearn a new system, is it really better for the org?

Third, the old software is certainly more complex than you can see from the surface. At minimum, you should start by adding analytics to the existing codebase so you can see which features are used. You will be surprised to learn that people use the software much differently than you would have guessed.

Fourth, you're not off the hook for maintaining and supporting the old software during the rewrite. If a new, urgent feature request comes in and the rewrite is too far behind schedule to be ready in time (it will be behind schedule, guaranteed) then you must still service the old codebase in the interim. This is a constant tax on productivity that slows down rewrites, unless you can justify two completely independent teams.

My advice: Make an effort to calculate the ROI on the rewrite. Include the overhead of maintaining the current system during the rewrite, as well as the costs of retraining everyone who used the old software. If you can't reduce overall costs after a few years with a rewrite, it's hard to justify. It's an unpopular opinion with programmers, but some times it really does make sense to continue to throw developers at an old codebase instead of rewriting from scratch.

If you must rewrite, look for a way to rewrite incrementally. For example, writing a new front-end for the existing back-end with a modular API translation layer. Ship the new front-end, work out the bugs, and then work on replacing the back-end later. Depending on the codebase, you may even be able to write a backend shim and slowly replace individual endpoints and rework the API one feature at a time until the old backend can be fully deprecated.

</comment><comment><USER3> I see no reason for a rewrite based on those problems. You have a codebase that has been working for 18 years, and still works. The problems you described are with maintaining it, and usability, but not with its functionality.

There is no documentation, so write some. Question decisions were made, so do (major) refactors to correct those decisions. Likewise, you can pick pieces to modernize, one at a time, and improve the UX one piece at a time.

This does sound like a sizable project to get it where you want, and if you do one piece at a time, you may end up with 90+% new code when all is said and done anyway... but you'll do it in bite size pieces without impacting your customers or your stability.

</comment><comment><USER4> The infamous rewrites that Joel Spolsky once urged to never do, are those where development on the current version is halted while a brand new version is developed from scratch and then launched with a big bang. Without answering the question directly, web applications are some of the easiest to rewrite gradually, endpoint by endpoint. Especially in PHP, where requests are stateless. You could start a new thing in the middle of the old thing and slowly let it take over, while already live and working in tandem with the old parts.

</comment><comment><USER5> I would consider a rewrite, if anything else for security, has the existing code base been updated to run on PHP 7.3?

I would look at using the Laravel framework for the rewrite.

This would also offload maintaining the existing framework, templating and ORM. Plus you'll gain lots of features already in the Laravel framework that the legacy framework probably does not have.

Does the app have modules or components that you could start moving over to Laravel one by one?

</comment><comment><USER6> Would need to see the git repo. I could only find this [https://github.com/studip/studip-gsoc2013](https://github.com/studip/studip- gsoc2013)

If this is an example of the code base then it doens't look too bad in terms of layout.

BUT before a re-write/refactor.

Get a really good CI/CD process in place. i.e. build -> unit test -> browser testing.</comment>


Titans of Space - <AUTHOR> http://www.crunchywood.com/ <comment><USER2> Untested on Linux? Seems rather silly since Linux is the easiest to test on. It is free and installs wo a license in a VM. Guess I wont be the ginny pig.

<comment><USER3> How are you defining "ease" of testing in this case?

Testing is more than opening your app in a VM sandbox.

Maybe the underlying drivers for Oculus are a pain in Linux. Maybe the 3D acceleration required in Linux is not great, or unavailable in the VM they have available, if any. More likely the case, Linux users aren't their target for this small experiment in the first place, and they are busy so spending time to install/test their program in Linux would distract from their other work.</comment></comment>