casmclas

I mean, it's no worse than the standard antipatterns, which are designed to be so easy to click "accept" and so hard to follow the "don't accept" flow. None of them are about coming to an agreement with the user; all of them are about obtaining as much data as possible. Until the EU mandates a handwritten letter to obtain permission for tracking cookies, these demonstrations of bad faith will be our friends on the internet.

That's certainly the implication of their text. It is not a legitimate conclusion. Given the premises "Apple has made a decision X" and "Apple has made billions of dollars since making that decision", you cannot conclude "the decision has made Apple billions of dollars". We cannot accept "All wood burns, therefore all that burns is wood" but "All of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan".

Lots of people disapprove of Facebook's data practices, yet they still run several of the overwhelmingly most popular social networks. Apple could be in a similar position: producing an otherwise excellent product that has a limitation people tolerate.

The fact that Apple makes billions of dollars is not evidence that every single decision of theirs is the best decision for their profitability. In order for their profit to be used against the argument and comfort of a certain Hacker News commentator, we need some evidence that the revenue is because of, not despite (or unaffected by), the decisions that made the random Hacker News commentator unhappy. At best we can conclude that the decision is not such a howler that it's cost them their market viability, but perhaps if they'd made a different decision they could have owned the entire smartphone market in a way that Windows used to own the desktop OS market.

(Another logical fallacy implicit in the argument is that a decision made by a powerful person is more worthy of respect than another decision. I must admit these kinds of reactionary values are extremely far from me, and I am shocked and uncomfortable to find how common they are.)

Well that is an argument no-one is making. No one is comparing email and IM and asking which is succeeding better at being a decentralised application. You're right: email is certainly less centralised than Whatsapp. But it's a red herring. The comparison is between the original implementation of email as a decentralised system and the current experience of email, which is highly centralised.

In the olden days, any business could say in good faith "I want to offer email services" and they would have been treated pretty much the same as any other good faith provider of email service. But today, a business who wanted to start up an email service is insane; just check out the nearby thread of a person who replaced Mailchimp with a semi-self-rolled service. As a matter of fact, no matter what the RFCs say, people in the industry do not treat email as decentralised.

This is partially because people joined the network in bad faith, but it's also because a small number of large nodes are able to assume anyone who isn't known to them is acting in bad faith and therefore force people towards the larger nodes.

As I said before, email and the web continue to be usable in a decentralised fashion, but to do so involves wearing a hairshirt. This is the failure of decentralised applications. The author of the article has a view that is closer to "the market is only as free as its weaker members" rather than the view more fashionable hereabouts "the market is only as free as its stronger members", which leads to a different conclusion. It would probably lead to more insightful disagreements to discuss this underlying difference rather than arguing about what technologies email is less centralised than. (Edit to clairfy: These things in quotation marks are not quotes. The quotation marks are used to help delimit the propositions.)

I think that's a fair characterisation of her premises. For instance, she argues that these outcomes aren't happening because of any systematic quality difference in the products: many centralised products that win significant marketshare are a bit ordinary. I'm not in a position to judge that claim; I tend to avoid products that make gratuitous demands on my personal data so I have less material to compare, but the idea that a universal Electron app is better than a variety of independently developed native apps is certainly not one I would rush to accept.

Her actual conclusion is that in order to create a market whose average members are free, we need more regulation.

It isn't a fallacy, and in any case the article isn't claiming that decentralised software has become centralised because companies have built good defaults on top, so that's a complete strawman.

> I don't agree that email isn't an example of a decentralized application. She argues that it's not because it's really hard to run your own mail server.

I don't think this is a fair characterisation of the article. She argues that email is an example of something that is failing as a decentralised application: Google's power over email is too strong. This is very different from claiming that it isn't an example of a decentralised application.

Email and the web are decentralised applications. But they are not the email and the web of the 1990s, when their decentralisation was the killer feature that saw them beat out centralised networks. To try and live on a non-Google/non-Facebook web is like using Linux on the desktop in 2000: it's certainly possible, but it's a bit of a hairshirt.

NixOS and GuixSD aren't user friendly because the people who use them are like GNU/Linux users circa 2000: people insane enough to install an operating system that is very particular about who its friends are.

But they do have an excellent solution to the whole updates debacle: Install them in a separate location, initialise them when booting or when they're finished installing, and delete them when they're inaccessible from a few standard locations like /boot or /proc.

I mean, sure, but probably most programs we use these days are written in Javascript/DOM and gratuitously interface with remote systems. It demonstrably isn't difficult to write decent assembly that is faster than the naive RESTful APIs called by Javascript that makes our 8 core 2-5 GHz computers feel slower than a wet week. A system written entirely in assembly is probably going to be significantly faster than a modern general purpose computer, but it probably won't be running checking your work webmail any time soon.

I found in Paris, the easiest way to communicate was to speak English with an exaggerated French accent, and throw in the few words of French I know. In the other parts of France I've been to, English was effectively useless; I made do with broken German. This wasn't for conversation, but conveying information, buying stuff etc.

"Can't" isn't even the slightest bit passive. But a person who is telling others how to communicate well will always use technical terms with the wrong meaning.

In this case a negative imperative is what you should be using. Moreover, since it's a life-or-death matter, we need to carefully explain ourselves. "Do not add too much water to the reactor. If you add too much water, the reactor could explode. The reactor should never contain more than 1000 litres of water. If it is overfilled, immediately follow the steps in 3.4.1 to perform an emergency evacuation." By being careful in our follow up, we reduce the risk of any misunderstanding. We cannot prevent a person from misunderstanding, but at least they are more likely to realise they have misunderstood something and seek clarification.

"Must not" is reasonably well-understood by native speakers of English, but it is confusing to non-native speakers because even though "must"="have to", the negations have different meanings. It is no use being technically correct if the person whose responsibility it is thinks you said "you don't have to add too much water to the reactor". The prevalence of "must" also varies throughout the native-speaking world.

> or how about smokers who will as a result of their actions will cost spades more than "good souls"? or type 2 diabetics on dialysis?

Why not just tax the cigarettes and subsidise bike roads instead of car roads?

I think there's a difference between fire brigades that are private businesses and government owned fire brigades that have territorial jurisdiction and which apply common sense to their funding to ensure the most efficient service possible.

For instance, given that fire brigades are commonly city-level in the US and that American cities often have highly irregularly and interlocking shapes, it is plainly more efficient to trade a certain amount of funding to have the other city look after your dog leg. But there is a mandate on them to look after all structural fires in a certain area. They can pay someone else to look after it on their behalf, but the mandate remains. Territory and funds are exchanged. In other places, where fire brigades are run nationally or regionally, perhaps even individual stations will trade — "we specialise in rural fires and you specialise in urban fires, so you should take this newly urbanised region off our hands" "okay, but we will also take your newly urbanised funding off your hands". But it might also occur at the national or regional level and thus be central planning rather than business like.

But a fire brigade that is a private business will look after fires that are cheaper for them to put out than to burn. Perhaps they will put out a fire in a non-member's building since every neighbor is an important member — and then they might sue them for all their worth. But if they have no customers in an area because the people who live there do not have the money, then they might let the fire burn. Or they might say "we are liable for a hundred thousand dollars compensation if we don't put out this fire, but it will cost us at least a million to put out". (The local fire brigade will probably have to let some fires burn because they don't have the resources to put them out — it may be vastly too dangerous to get involved, but of a nature that, after a day of burning, it will be much safer. Here, the difference is the consideration — the question is the relative safety of attacking it vs waiting it out, rather than the relative costs of attacking it vs waiting it out.)

A mediate position could exist, where private corporations are allowed to get involved in the firefighting business, but if that were permitted, it would be a situation where the mandate remains and the private firefighters would be paid by mandatory payments from the property owners of the relevant territory. Unlike most businesses, they aren't free to pick what they do. A private supermarket can decide if they want to stock Mildew Milk or not. But a private regulated/mandatory firebrigade would have to put out the fire at Mildew Milk even though they've had a long running feud.

Hospitals are run and funded by each state in Australia. I think a decade ago the federal government started to run a hospital in Tasmania, but they pulled out of it because it was ridiculous. There are also numerous private hospitals. GPs and specialists are largely privately operated. Comparing Medicare to a single nationalised hospital system is not accurate — it's more like a national health insurance system with membership fees paid by the tax system.

Obviously having a single purchaser of so many services allows them a large degree of control, but it isn't even a single payer system, since many health services require extra funds (even a routine doctor's visit requires out of pocket costs for many people, like $30 — that isn't cheap) although that's a recent change. There's also private health insurance and extra fees you can pay for nice service (like a room of your own).

I think there's differences of attention that make it different. When there's only one brand name, it invites a competitor from another market in. When there's three, but they all have the same policy, that's a bit different.

I think comments here seem to be missing the point, which isn't so much that Nunavut is geographically huge, but that Canada doesn't seem to have anything like the principle of one person one vote. There's huge disparity between the electors or people per district figures - 1:8. That's some epic malapportionment.

Is there any kind of movement in Canada to introduce democracy? Americans regularly complain about their undemocratic constitution, giving equal say to sheep in the middle of nowhere and humans in New York. The UK has a few problematic cases, but they're easily removed and maintained because they want to maintain them.

But Canada's excuse is that they can't change their constitution — indeed, they continue to use the UK parliament to change what ought to be part of their constitution, that's how cowardly they are. Why is Canada considered so much a centre of democracy when all the evidence is against that notion?

I think it's considering only single member districts. If you count multi-member districts, Western Australia sends six members to the Australian Senate and it's 2.6 mio sq km. There's probably others around too.

According to the English language article https://www.zdnet.com/article/free-software-advocate-richard...,

'According to Segala, Stallman requests no video feeds in "places using proprietary JS."'

Therefore, we see that his concern isn't about the language of implementation, but whether it's proprietary or not. So you could write a FOSS web video player and post a video of him there, but he doesn't want to be on YouTube since I can't say "well, this video player would be much nicer if..." and then do that.

I've tried several times to use Purescript to target web browsers. I got frustrated by Bower - it's especially hard to start a new project using tools that say "don't use me, I'm deprecated". There was a huge amount of fairly sloppy javascript boundary code. And - it turns out - I like laziness.I dunno, I wish I could run ghc code efficiently in a web browser. But even though I can't, I much prefer to run ghc code inefficiently in a web browser than run a language intended to facilitate binding to javascript's sloppy semantics.

When I tried using ps-concur or some other ps gui libraries, I didn't feel inclined to keep progressing. When I learnt reflex with ghcjs, I built stuff, and I kept finding new things I wanted to build.

The best way for a Haskell to target browsers at the moment is via ghcjs. Hopefully one day it'll be with a ghc-to-wasm compiler.