Thanks for the correction.
1,765 karma · joined March 18, 2012
Currently: Elixir developer at ably.io
[ my public key: https://keybase.io/swoolf; my proof: https://keybase.io/swoolf/sigs/peGiDfVOfeAJ1dy6H68hG8PBmsdx6s1kXWY6rVhzUr8 ]
You don't have to wait for them to enable it for everyone. Enable it yourself by setting browser.tabs.remote.autostart to true in about:config (on ff48-53 this'll use one one process for ui and one for all tabs, I believe on 54+ it'll use more). (As long as you don't have any addons that don't support it, anyway -- after enabling it, check in about:support under "Multiprocess Windows", and if not, about:addons should show the offending addon. IIRC there's a staged rollout, so it may already be enabled for you even if you don't force it on, unless you have an addon that doesn't support it)
They didn't. The syntax is explicitly stated to be a mixture of OCaml and Elm. The -- comment syntax is from Elm. Elm in turn got it from Haskell.
> We’ve found that some of the most cost-effective charities can buy one year of perfect health (a QALY) for as little as $80
Which was that? IIRC GiveWell only claim $100/QALY for the AMF - have you found a charity you believe is 20% more efficient than that, or is this just a difference in how you measure cost per qaly?
[Edit] another question -- there's recently been criticism[0] of the poor quality of data and effectiveness research in animal welfare EA, compared with human welfare EA. Would the animal welfare fund be doing things like actively commissioning new research into intervention effectiveness? Or would it be more hands-off, just limited to picking charities based on the data that's out there at the moment?
[0] https://medium.com/@harrisonnathan/the-actual-number-is-almo...
$ curl -o /dev/null -s -w "@time-format.txt" http://rest.ably.io/time
time_namelookup: 0.012
time_connect: 0.031
time_appconnect: 0.000
time_pretransfer: 0.031
time_total: 0.053
$ curl -o /dev/null -s -w "@time-format.txt" https://rest.ably.io/time
time_namelookup: 0.012
time_connect: 0.031
time_appconnect: 0.216
time_pretransfer: 0.216
time_total: 0.237
Luckily not that much of an issue for us as when using an actual client library (unlike with curl) you get HTTP keep-alive, so at least the TCP connection doesn't need to be renewed for every request. And most customers who care about low latency are using a realtime library anyway, which just keeps a websocket, so sidesteps the whole issue. Certainly not enough to make us reconsider using TLS by default.
Still, a bit annoying when you get someone who thinks they've discovered with curl that latency from them to us is 4x slower than to Pubnub, just because the Pubnub docs show the http versions of their endpoints, wheras ours show https, even though we're basically both using the same set of AWS regions...
I was going off the page you linked to[0], which describes it as: "an insurance product which provides up to two incidents of accidental damage coverage"...
Looking more closely though, it looks like AppleCare and AppleCare+ are different products (which I hadn't previously grokked), and that sentence applies to AppleCare+ only. My bad, sorry for the confusion.
It's still not that simple.
It's not like you get six years of unlimited state-mandated insurance. The 'six years' is just from the statute of limitations -- it's just the limit after which you can no longer do anything about a violation of a contract of sale. [0]
But there still has to be violation of the contract of sale. Which means it only applies to defective products. (Or ones not as described, not fit for their purpose, etc.)
So eg it doesn't apply to accidental damage. If you spill coffee on your shiny laptop, consumer law won't help you, even if you only bought it ten minutes ago (unless the product was sold as waterproof, ofc). It also doesn't apply to normal wear and tear, unless you can argue that the degree to which it's deteriorated is enough to imply that the goods weren't of satisfactory quality at the time they were sold, taking into account the context of the kind of good, how it was described, the price, etc.[1]. And so on.
Until six months, the burden of proof is on the retailer to show that anything that goes wrong with the product was not due to the product being defective. (I.e. if there's a problem, and there's no obvious cause, there's an assumption that the goods are faulty). After six months, that assumption is reversed, and the burden is on you to show that the product was defective.[2]
We have pretty good consumer protection in the UK, but it's not a replacement for insurance (e.g. applecare etc). (Whether you actually need insurance for a laptop purchase is another question. Generally if you could replace a thing without too much hardship, insurance is pointless -- the expected value is negative (ie Apple makes a profit on Applecare); you're purchasing a reduction in variance).
(IANAL, just interested in consumer law)
[0] http://www.legislation.gov.uk/ukpga/1980/58/section/5 [1] http://www.legislation.gov.uk/ukpga/2015/15/section/9 [2] http://www.legislation.gov.uk/ukpga/2015/15/section/19
Nitpick: not sure it's nonsensical. Plug g(x) = 0 into the usual definition, and you get |f(x)| ≤ k⋅0 for some k in R, which reduces to f(x) = 0. Which is not satisfiable by any nontrivial algorithm, so not very useful, but not nonsensical.
Generally you won't have a choice. If something in your function calls another async function, the function as a whole is forced to be async. If not, then it won't be.
It's possible to make a function fake-async even if it doesn't call any async functions, by just calling the callback at the end. But there's not much point -- and callers may make assumptions about the the callback being called in a separate iteration of the event loop, so doing that could cause subtle bugs. That latter problem is solvable by calling the callback in a setImmediate callback, but again, no point unless you have a good reason to.
(Exception: there are a few apis where you do have a choice, e.g node's randomBytes can be either sync or async. Generally they're things that might block, where the sync version returns an error if it can't satisfy immediately. But generally you don't.)
What am I missing?
This is just a disagreement over definitions.
If you define alchemy as e.g. 'the search for the ability to transmute elements', then sure, nuclear reactions are alchemy. But that's not how the word is generally used. It's used to describe a practice bound up with a bundle of concepts, beliefs, and connotations[0], which mostly disappeared after the 18th century. (That's a useful thing to have a word for -- under a definition of alchemy for which nuclear physics is alchemy, you'd probably want to invent a different word to describe that practice, and then that just introduces unnecessary confusion when talking to people who use the more common set of definitions).
> For example, if your product requires that you have longer channel names, a more lightweight protocol, ability to batch messages together in a particular way, transform or filter or analyse data streams on the backend as they arrive, apply advanced authorization rules on the backend or to integrate directly with data from your own database... you need an open source solution.
I'd query a few of these -
- Re channel name length: we have no particular limit on that...?
- Re lightweight protocols: The article we're commenting on is actually about us adding support for more protocols :) (including MQTT, which is pretty lightweight - though that one's not in general availability yet). We also support queues as an alternate way to consume data, which gives you AMQP and STOMP too.
- Re batching: Clients can batch messages together into a single protocol messages as they like, just by passing an array of messages to publish(), and subscribers will receive them all together. (Which assumes they're all for the same channel, but if not, not sure what it'd mean to batch them).
- Re analysing data streams on the backend as they arrive: you can subscribe to messages on your server, and then do what you like with them. (Or alternatively use our queueing feature, which lets you have arbitrarily many independent backend workers consuming messages from the queues). It is true that you can't filter messages before they're broadcast to other clients, though. I guess our answer to that would be to have the client publish to a channel that only the server has permissions to subscribe to, set then have server filter those and rebroadcast on a different channel. (Probably in combination with the queues, so you can have multiple server workers doing this). It's true that that will add a bit more latency, though.
- Re advanced authorization rules -- our token capabilities system allows the server pretty fine-grained control over the permissions it grants each client.[0] But sure, it's never going to be as flexible as a completely custom solution.
[0] https://www.ably.io/documentation/general/authentication
Yep, creating a barebones pub/sub service is pretty trivial (and fun!).
But then you may find yourself slowly adding things that a decent pub/sub service should have. E.g. connection state recovery, so that a client on a phone driving through a tunnel gets all their messages (in the right order) once they reconnect. Presence, and presence data. Stored history. A permissions system. Encryption. Smart push notifications. Decent multi-region federation, so a channel that happens to only have subscribers in ap-southeast doesn't roundtrip messages to us-east. Guaranteed message ordering preservation. And so on.
And eventually, you end up spending what adds up to quite a lot of effort, which could have been spent in ways other than slowly recreating the SAAS.
I think that's the case for a lot of SAAS products (that creating a barebones version of the product yourself is pretty trivial, but the SAAS is still a useful product, since often people don't just want a barebones version).
(Disclaimer: I work at Ably)
> For the rest of us (think young startups, smaller shops) your costs may be prohibitive ( almost 6K / year)
I'm afraid I don't follow that. We have a generous free tier (a lot of startups are fine just on that), and self service packages starting at $20/month. And very cheap overage pricing - $1.25 per million messages + $12.50 per 1000 peak concurrent connections, so people who aren't sure how much they're going to use (often the case with startups) can just pay what they use. I've linked to it elsewhere in the thread, but: see https://www.ably.io/pricing/self-service.
I think you reached that number from the cost of the 'enterprise' package, but that's really for companies whose corporate policy requires that they have a personal account manager they can call at any time or something, or who want customised versions of things (eg versions of client libs with our name replaced by theirs connecting to a CNAME on their domain). Not really relevant for young startups.
> did you see that there was a 'problem' in the space and built an MVP, or did you create this need?
Re how we came to be, Matt has a blog post on that - https://blog.ably.io/the-story-of-how-ably-came-to-be-1d859f...
We weren't the first company in the space -- e.g. Pusher and Pubnub were both here before us -- but we weren't happy with the existing solutions for a bunch of reasons, see https://www.ably.io/compare
(I work at Ably) Others have already replied to the main question, but just on this - the enterprise package is only if you want the features that come with that package, it's not like we try and detect what kind of business you are and charge you extra based on that. Free tier gives you 3 million messages/month, and above that we've transparent, usage-based pricing - https://www.ably.io/pricing/self-service
Not sure if your comment's implying it's a random number picked for amusement? That figure (2.7 years) seems about right to me -- the frequency of a blue moon is necessarily the same as the frequency that a lunisolar calendar has to add a leap month, which is every 2 or 3 years. I don't see any reason to doubt Google's number.
While this happens to be true in this specific case, as a general statement, it's misleading. It is true for copyright infringement because that is a strict liability tort, which means it doesn't require any particular state of mind ('mens rea'[0]).
Not all torts, and not all crimes, are strict liability. In your examples, if a necklace accidentally falls into your purse, that is not theft (in English law, anyway), as theft requires intent to deprive the owner of the thing[1]. Though once you notice it, if you decide not to return it, at that point it will become theft. Speeding, on the other hand, is strict liability (again: in English law, I don't know about US), as are most minor regulatory-type offences where it'd be difficult and impractical to prove intent.
(Also note: tort != crime. Copyright infringement can in some circumstances be a crime, but this is a lawsuit: the company is suing the Navy; the Navy isn't being prosecuted).
[0] https://en.wikipedia.org/wiki/Mens_rea
[1] http://www.legislation.gov.uk/ukpga/1968/60
NB: IANAL (did law, but ended up going into software dev instead)
The same way you 'prove' anything in criminal law: by adducing evidence that convinces a jury beyond reasonable doubt. If they don't have any evidence, the accused has no case to answer.
> If they arrest someone with a laptop encrypted with ransomware, will they force this person to pay?
Which provision are you thinking they could do that under? s.49 and 53 aren't relevant, they're only if someone is in possession of the key. With ransomware, some third party bad actor is in possession of the key.
You're right, those are problems. But they're not problems with this law, they're problems with jury-based criminal justice systems. And the system's had 900 years to evolve solutions -- judges summing up, "No case to answer" / directed verdicts, etc.
There's room for disagreement about how effective those solutions are. Point is, as the main objection to this law, that complaint 'proves too much' -- since essentially the same objections apply to all but the most trivial criminal offences, the solution then becomes scrap juries and go for a Germany-style professional/inquisitorial justice system. (And maybe we should, I don't know).
(btw, this is very, very far from being the most complicated law or subject matter that juries have to face, compared to e.g. complex fraud trials)
(To be clear, I think this is a terrible law! But just because I agree with TFA's conclusions doesn't justify his fearmongering, IMO)
Alarmist and inaccurate. If you read the statute that Mr. Falkvinge links[0], it turns out that if there's a serious question about whether you have the key to some piece of supposedly encrypted data, the burden of proof is on the prosecution to prove you do have the key to it (and therefore that it is encrypted data) beyond reasonable doubt, just as you'd expect. s.53(3).
(Incidentally, if you just change the url from http to https (or use the EFF's https-everywhere addon) it works fine, the server does support it)
"Last month, Ecuador’s prosecutor-general rejected a previous request from the Swedish prosecutor to question Assange in London. That office, in a letter to Swedish authorities, said it will interview Assange and asked for a list of questions the Swedish prosecutor wants the Ecuadorian prosecutor to ask the Wikileaks founder."
(http://www.theatlantic.com/international/archive/2016/02/swe...)
That'll be because it isn't e-ink :)
It's an LCD, specifically this[0] Sharp 'memory LCD'. Pebble brand it as "e-paper", but that's just marketing fluff, the technology is unrelated to e-ink (what kindles use).
Preventing war has been an explicit aim of European integration going back to the beginning. From the Schuman declaration (1950, founding document of the ECSC): "The solidarity in production thus established will make it plain that any war between France and Germany becomes not merely unthinkable, but materially impossible"[0]. This principle has been widely accepted in Europe for the last 65 years.
You may of course disagree that economic integration is the main reason for the lack of intraeuropean wars since then (especially compared to the previous few millennia), but dismissing it as a "myth" is at very least least a surprising claim that requires some actual argument to back it up, and "new" is just factually incorrect.
[0] http://www.robert-schuman.eu/en/declaration-of-9-may-1950
Given any input domain, you can choose an algorithm that will make bruteforcing the entire domain take as long as you like. As an extreme example, bcrypt with a work factor of 20 takes over a minute to calculate a single hash on a high-end desktop. (Of course, whether whatsapp are actually doing any of this is another question).