lbradstreet

Is it locked to a prepaid carrier? If so, then it's probably being sold at under cost.

Isn't that against AppStore rules? It used to be that you couldn't charge a different price for an equivalent purchase.

In theory there should be a trade off when offering such a solution. Companies are more likely to trust you, and use your product if they can be sure there is a fallback plan (open source) upon your product being shuttered. Yes, you may lose some potential fallback plans for your company if it is being bought for its technology, but hopefully the number of additional adopters who would trust you early on in your company's life would compensate for this.

I'm not saying there is a moral obligation to do so, merely that it might be a good decision for both sides. See, for example, how open source is increasingly becoming a requirement for infrastructure products that companies come to depend on. This may be a good middle ground. Personally think open sourcing from the start is a better choice.

Interestingly, Iran is the only country in the world that allows its citizens to pay for someone to give up their kidney https://en.m.wikipedia.org/wiki/Kidney_trade_in_Iran.

By some accounts it works rather well, see http://www.econtalk.org/archives/2015/09/tina_rosenberg.html.

(It is true that they do allow other nationalities to pay for a kidney, however someone of their own nationality must give up the kidney, preventing at least some level of medical/tra splant tourism).

I would love to see a similar proposition with proprietary products run by companies.

If you run an infrastructure style product, there should be a living will involve where the product will become open source upon the bankruptcy or shutdown style sale of the company.

For example, FoundationDB was bought by apple and the product was shuttered. Under a living will, the product would become open source, as it is no longer developed by the company.

I realise this may lead to a lower selling price, all things being equal, however people/companies are also more likely to trust you when you are small, as they have a greater chance of survival should you fail.

My personal feeling is that most of these products should be open source from the get go, and it will probably have to be this way going forward, however this is a reasonable middle ground.

I've had good luck with prismatic schema https://github.com/Prismatic/schema, which seems to be along a similar direction. It's fairly low commitment and can lead to big gains fairly quickly. I assume this would be similar.

https://github.com/mefellows/muxy looks interesting, albeit for certain test types. I'll be trying it out in the near future.

I've always wanted a model like this to point people to. I don't have a dog in the buy/rent column, but I feel like most of these decisions are made without a regard for many pertinent considerations. The main one that bugs me is how long you will likely stay in a place. Completely disregarding market effects, if you're not going to hold onto it long then it's probably not going to work out.

I guess you mean Hillary for the Senate

I've used Onyx, but I haven't used Spark, so take this with a grain of salt.

A few key differences:

Onyx aggressively uses data structures to define the structure of computation, defining the data flow (Onyx workflow) and parameterization (Onyx catalog) of the the computation via clojure maps and vectors. In comparison Flambo and Spark define the structure of computation via functions over collections. One way in which Onyx's approach is powerful is that it becomes trivial to manipulate workflows or catalogs before submitting jobs at runtime, allowing you to add additional tasks, task options, etc.

Onyx also implements batching over streaming operations, whereas Spark appears to be the opposite. There are likely to be trade-offs between these approaches.

Spark is also a lot faster, though this isn't necessarily intrinsic to the approaches.

I'm the author of the ClojureScript port. I'd really love to hear from anyone who eventually uses it, as I'm getting it into shape so it can eventually be merged upstream.

All the tests pass and it works for my use case, but it'd be great to get some more data points.

I'm skeptical of the total loss quoted. If a stock drops from 2B to 0.3B market cap, it doesn't necessarily mean that investors lost 1.7B in the pump and dump. For that to happen 100% of the shares would have had to have traded hands. The remaining investors would have been there for the ride up as well as the ride back down.

I assume you mean data outside the container?

Maybe you could at least silo the utility that needs to delete so that it can easily be inspected and so you don't have to trust the whole program.

Definitely a bit on the whimsical side but has a lot of interesting stuff I respect. It'd work on me, but maybe not on a lot of people who might hire you - though that may act as a good filter for your sake. I'm not sure.

A agree with the post below about the adventurer bit though. It makes the rest a bit more over the top. I also agree with the posts about the colours.

The new webkit view (WKWebView) is JITed. I'm not sure about using JavaScriptCore independently of it though.

With Microsoft making moves like these for their open source projects, it seems like network effects are alive and well, and working for GitHub. Of course, it did require some change from above to get to the point where Microsoft is willing to open source this stuff in the first point.

I don't think that's correct as it is most of the point of the LGPL. I think it's how QT was able to sell licenses to closed source software despite being GPL'd as well (dual license).

Surely Bitcoin has an independent monetary policy, along with free capital movement.

The monetary policy follows the block reward (currently 25 BTC).

Of course with this monetary policy and free movement of capital, it is impossible to have a fixed exchange rate, but it does in fact have two out of the three.

I'm not going to mention a specific paper, but Papers We Love (https://github.com/papers-we-love/papers-we-love) has some good stuff on it, and the meetups have always been interesting (at least for my local chapter).

These deals are net positive for Nevada (tax breaks don't really hurt them that much if they wouldn't have gotten the facility anyway), and net negative for the US overall (revenue wise, at least). If nobody engaged in these kinds of deals then Tesla would surely pay more tax.

I don't blame Nevada for engaging in it, and I think they probably won overall.

Other factors (cheap land, regulatory, etc) almost definitely came into play but nobody is really complaining about those.

I totally agree that it helps with callback hell / reasoning, but I think your argument was more about coordination. Hence the sliding buffer example - something that would be very, very hard to /coordinate/ with callbacks.

Addendum: if it weren't for Tim Pope and his Vimscript mastery, I would already be using emacs in Evil mode.

I've spent a fair amount of time in core.async, and I feel like I'm on the edge of enlightenment here, but I don't quite understand how CSP helps with this example. Is the point that you can take multiple puts off the channel in one go? That's the only thing I can think of.

Maybe you could present the CSP alternative, and a basic example use case?

* edit: I guess a basic example is a sliding-buffer that only keeps, and thus only reacts to, the last mouse event. Is this on the right track?

I am seriously glad that this is a thing. I donated after the original bountysource, and seeing the momentum I may just donate again.

The iPad 3 is pushing 4x the number of pixels as the iPad mini as it's retina. I'm not surprised by this at all.