It's tax free for the REIT. If it were a C corp, it'd have to pay tax on earnings, and the shareholders would also have to pay tax on dividends. So for the REIT there's a meaningful sense in which "tax-free" applies.
1,095 karma · joined April 6, 2011
As you know, the difficulty with concurrency is with shared mutable state. Purity simplifies concurrency by restricting mutability; rust simplifies concurrency by restricting sharing.
That makes purity less important for rust.
Everyone uses three.js, but if you want to write shaders (a big part of the point of webgl IMO), three.js can be difficult to work with. It has a fairly involved system for building its shaders from a big library of shader snippets. Last I looked, it seemed pretty complicated to hook your own shaders into that system.
If you don't want to write shaders, three.js is great, but if you do, it may be more than you want.
There's another library I've used, also a low-level webgl wrapper, called GLOW: https://github.com/empaempa/GLOW
Development on it has slowed, but I think it has a really nice approach.
They keep saying that they're closing in on 1.0, but there's a few issues left:
https://github.com/json-api/json-api/issues?q=is%3Aopen+is%3...
They've been making a lot of changes lately:
https://github.com/json-api/json-api/graphs/contributors
It's good that they want to get all of the breaking changes done so that they can declare a stable 1.0. But it also seems like they're going to try and call it stable right after making a bunch of changes, which seems risky.
I also pitched JSON-LD/Hydra at work, because they're w3c-backed and JSON-LD has some uptake. But the other people who looked at those specs found them hard to digest. And I agree; as an implementer, I can read the jsonapi docs quickly and have a pretty clear idea of what to do. But with JSON-LD/Hydra, not so much.
I get the sense that JSON-LD/Hydra is more flexible than jsonapi, but I think jsonapi does what we need. And if it does what we need, then additional flexibility might actually be a drawback. I guess we'll see how it goes.
If you're trying to do non-blocking async stuff in other languages, you have to hope/check that none of your code and none of your dependencies try to do blocking I/O. (Unless you're using something that does async under the covers like haskell or go)
"In contrast to demographic reconstructions based on mtDNA, we infer a second strong bottleneck in Y-chromosome lineages dating to the last 10 ky. We hypothesize that this bottleneck is caused by cultural changes affecting variance of reproductive success among males."
"caused by cultural changes affecting variance of reproductive success among males" is a reasonable hypothesis, since the bottleneck affected males more than females. But who pulled "wealth and power" out of their rear end? That's just one possible cultural change. And why would you lead with one possible version of a hypothesis rather than the actual data and results (which are interesting in their own right)?
There are lots of possible ways that cultural changes could have caused a male-specific pattern of reproductive variance. Maybe settling down into agricultural societies changed how (and how much) men fought and died in conflict. There are lots of possibilities; "wealth and power" is a total guess. But that's the part that makes it into the headline.
Also, is it standard to talk about memory growing "down" as the memory locations numerically increase? That's the opposite of my impulse (I would have said that 0xff is the top of memory, and 0xfe is "down" from there) but TBH it's been a while since I took the relevant CS class.
Ha, cable network owner Mark Cuban is totally unbiased, of course.
http://www.infoq.com/news/2014/06/google-chrome-pdf-engine-f...
Civil?
In that model, you would be right. However, that's not what we actually see. Foregone consumption is not automatically channelled to productive investment. If you own a company, you have no reason to invest in increased production capacity if no one will buy your increased output. And why is no one buying that increased output? It's partly an issue of distribution; the wealthy have a lower marginal propensity to consume.
A lot of people and companies actually are sitting on big piles of cash (or other short-term, low-risk investments that don't do much to increase productive capacity). This is part of the reason why interest rates are so low.
If your economy is suffering from a shortage of aggregate demand, as ours is, then promoting consumption is a good thing.
> Note that growing the pie lowers the cost of things, so it inherently benefits everyone. There is no such thing as growing the pie and only benefiting the rich.
Lowering taxes on the wealthy, or otherwise favoring investment over consumption, benefits the rich much more than it benefits everyone else. The "rising tide" metaphor is misleading, because economic policy changes that favor the rich raise their boats much more than everyone else's.
Other policies, that favor investment less, may benefit the less-well-off more than any potential indirect gain they may have experienced from investment-favoring policies.
http://phenomena.nationalgeographic.com/2014/06/10/our-skull...
http://blog.ezyang.com/2013/12/two-bugs-in-the-borrow-checke...
http://blog.ludei.com/webgl-ios-8-safari-webview/
Been waiting for this forever, seems like. Webgl's been in firefox since version 4!
http://cs.brown.edu/~sk/Publications/Papers/Published/sk-aut...
Help cure cancer by building webapps.
At CTIG, we sequence the DNA of cancer tumors to recommend the right therapy for that tumor's specific DNA mutations. Patients and their oncologists use our analyses to help make decisions about how to treat their cancer. With us, you'd help build the systems that doctors and patients use to access and interpret our results, and work on the systems we use to manage our internal processes.
It's really important that our users (patients and doctors) be able to understand the results we're giving back to them. So we're looking for someone who can translate our analyses into web pages that are clear, simple, and well-designed. That makes front-end experience and an eye for aesthetics important, but you'll be working on the backend as well.
Our current web apps are built using:
* Scala, with the Play framework
* Python, with Django and Flask
* Javascript, with Angular.js and D3
* HTML/CSS/LESS with Bootstrap
* Postgres
It's great if you're familiar with those, but general web dev skill and the ability to pick up new tools and technologies is more important. Our other systems also use R, and we're experimenting with the Julia language, so if you're looking to work with interesting technology then you'll find kindred spirits here.
CTIG is located in Mission Bay in San Francisco, across the street from the UCSF campus here. We're a very interdisciplinary group, with bioinformaticians and computational biologists from UC Berkeley, UC Santa Cruz, and UCSF; biologists from UCSF, and physicians from Harvard Medical School. Some of us have PhDs, some of us have MDs, and some of us are college dropouts; we're not credentialists, but we do have strong backgrounds in our respective fields. It's a small team with 6 programmers, so you'd be a core contributor and you'd help set our technical direction.
We're very serious about cancer, but pretty laid-back otherwise; office discussions range from the nitty-gritty details of molecular biology and machine learning to re-enactments of South Park episodes.
We're looking for people who are authorized to work in the US, and can work full-time on-site in SF. If you're interested, email me at mskinner@ctig.com, and include "EGFR" (the name of one of our favorite genes) in the subject.
Help cure cancer by building webapps.
At CTIG, we sequence the DNA of cancer tumors to recommend the right therapy for that tumor's specific DNA mutations. Patients and their oncologists use our analyses to help make decisions about how to treat their cancer. With us, you'd help build the systems that doctors and patients use to access and interpret our results, and work on the systems we use to manage our internal processes.
It's really important that our users (patients and doctors) be able to understand the results we're giving back to them. So we're looking for someone who can translate our analyses into web pages that are clear, simple, and well-designed. That makes front-end experience and an eye for aesthetics important, but you'll be working on the backend as well.
Our current web apps are built using:
* Scala, with the Play framework
* Python, with Django and Flask
* Javascript, with Angular.js and D3
* HTML/CSS/LESS with Bootstrap
* Postgres
It's great if you're familiar with those, but general web dev skill and the ability to pick up new tools and technologies is more important. Our other systems also use R, and we're experimenting with the Julia language, so if you're looking to work with interesting technology then you'll find kindred spirits here.
CTIG is located in Mission Bay in San Francisco, across the street from the UCSF campus here. We're a very interdisciplinary group, with bioinformaticians and computational biologists from UC Berkeley, UC Santa Cruz, and UCSF; biologists from UCSF, and physicians from Harvard Medical School. Some of us have PhDs, some of us have MDs, and some of us are college dropouts; we're not credentialists, but we do have strong backgrounds in our respective fields. It's a small team with 6 programmers, so you'd be a core contributor and you'd help set our technical direction.
We're very serious about cancer, but pretty laid-back otherwise; office discussions range from the nitty-gritty details of molecular biology and machine learning to re-enactments of South Park episodes.
If you're interested, email me at mskinner@ctig.com
No one is arguing that GCC should change licenses. But he seems to think that making GCC more modular would somehow make it less free:
> If GCC were to change from a free compiler into a platform for nonfree compilers, it would no longer serve the goal of freedom very well.
There are two embedded assumptions here. First, that making GCC more modular would result in people creating non-free compilers with it (presumably by connecting a non-free component with GCC using an IR rather than linking directly, to get around the GPL). And second, that such use would become more prevalent than just using GCC itself (which is what would "change" GCC from a free compiler into a platform for nonfree compilers).
I imagine a few people would use GCC components that way, if it became more modular. But would that use be a significant one? That's unknown. And would that use "no longer serve the goal of freedom"? If a large number of nonfree tools appear that generate and consume a GCC IR, that could boost GCC as well.
The GPL seems to be able to defend freedom just fine for all the other gnu software, even the modularly-architected projects. I don't see why it can't ultimately do the same for GCC.
A huge number of people employed on the peninsula would absolutely live close to work and build communities there, if those peninsula cities weren't so hell-bent on preventing dense development. There just isn't the supply there.
And what the f do you mean by "natives", anyway? Native Americans? Everyone else is an immigrant. If you moved here a year before I did, do you have some more legitimate claim to live here? I don't think so.
Of course supply and demand applies to the situation. Your suggestion of banning private buses, while ridiculous, is specifically an attempt to influence demand. Your own suggested solution assumes that the "Econ 101" theory applies.