brianpgordon

That doesn't make sense. Each email is only worth so much to a spammer. They can't lose money on every email and make up for it with volume.

The paper's argument assumes that the PoW scheme is required though. It could be an option which just guarantees that individual mail can get through, while still keeping the usual reputation-based spam filtering for clients which don't want to participate.

I guess the idea was too obvious to be original. I'm surprised that it inspired Bitcoin instead of the other way around though.

Unfortunately, I think it's more likely that no matter how bad private healthcare gets, people in the deep red states mentioned in the article will just assume that socialized healthcare would be even worse and dig in their heels all the more out of redoubled fear of losing what little they have left.

> If you can’t do a “one shot, one kill” email. Then call the person.

Please don't do this.

It would be nice if these big mail services accepted actual proof of work as a way to guarantee that your mail gets through. Maybe someone could extend SMTP with a bitcoin-like challenge where the server sends the client a nonce and a difficulty factor, and the client has to reply with a suffix that you can append to the nonce so that the whole string hashes to something with the corresponding number of zeroes at the end. People sending personal emails will be happy to burn a penny of CPU time as "postage" but spammers won't be able to send their spam profitably, especially if you increase the difficulty factor based on how many emails you've sent in the last hour.

If that's the case, the strategy isn't working. The big-name non-RHEL distributions (Fedora/SUSE, Debian, Ubuntu, Mint) all run systemd by default. Users would have no reason to think that Red Hat would help them avoid any systemd-related hassle.

Rendering/layout engine is an admittedly sloppy term referring to the whole stack, except for the JavaScript engine.

I think my point is still valid, that Microsoft hasn't given up on their browser, just most of the technology underlying it - which their users don't care about. The fact that Edge is a pretty decent epub reader (for now... https://www.thurrott.com/cloud/web-browsers/microsoft-edge/2...) isn't necessarily tied to the fact that it's EdgeHTML based. If they wanted to, Microsoft could implement the same feature set on top of Chromium.

> In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.

I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before.

The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.

Even if you grant some sinister motive on the part of Red Hat (which I do not), the analogy doesn't work. EEE requires some existing technology to embrace. Lennart Poettering built systemd from the ground up. And everything is open-source and done with the collaboration of the community anyway.

Theoretically they could still focus on developing a privacy-first browser on top of the core engine, and continue to influence web standards by implementing them as plugins with some glue patches maintained as a running fork on top of the Chromium code. As it is now, the fact that Firefox uses Quantum instead of Blink and SpiderMonkey instead of V8 isn't really a differentiator for the vast majority of users. There's a vague sense that a technology monoculture is unhealthy, but I would argue that the real threat is a browser monoculture, and Mozilla apparently can't stop that from happening with their current strategy because Firefox is losing.

The examples were intended to illustrate the point that Mozilla has a lot of non-Firefox software development going on, not to be an exhaustive accounting of everything they do. But even so, I have to question only allocating $13 million to the items I listed. Particularly Firefox OS and Firefox Reality. Those are big projects. The blog post I linked even has a pull quote emphasizing how much work the latter was:

> We had to rethink everything, including navigation, text-input, environments, search and more. This required years of research, and countless conversations with users, content creators, and hardware partners. The result is a browser that is built for the medium it serves. It makes a big difference, and we think you will love all of the features and details that we’ve created specifically for a MR browser. – Andre Vrignaud, Head of Mixed Reality Platform Strategy at Mozilla

Even something like Firefox Monitor has lots of design work and art assets and backend infrastructure and management overhead that makes it not as trivial as you make it sound.

> They spent $253 million (45% of revenue) on software development, presumably the bulk going to Firefox.

I'm curious if anyone can locate information on how much of that was spent specifically on Firefox, the browser. It seems like Mozilla was working on a bunch of peripheral stuff during that 2016-2017 period.

* Work on Firefox OS was still ongoing through 1H 2016. (https://groups.google.com/forum/#!msg/mozilla.dev.fxos/FoAwi...)

* They were building a free subscription service to check HIBP for your info. (https://monitor.firefox.com/)

* They were building a file-sharing service (https://github.com/mozilla/send/blob/master/CHANGELOG.md)

* They were building a new VR-first browser and content aggregator (https://blog.mozilla.org/blog/2018/09/18/firefox-reality-now...)

Microsoft still makes a browser; they just don't make their own rendering engine anymore. Which makes sense because it's hard and Blink works just fine. I wouldn't mind if Mozilla did the same thing. The Vivaldi folks are using that strategy and managing to make the best web browser out there with what I assume must be a microscopic fraction of $500 million/yr.

And I don't share your opinion of how far a $500 million budget goes. They're not rewriting the entire thing every year.

Impressive work period!

> While I understand that they have to make money somehow

I don't. I don't understand how Mozilla has over a thousand employees and over 500 million dollars in annual revenue. With that kind of money, Firefox should be absolutely dominating the browser space. They shouldn't be making Firefox worse with advertising in order to subsidize their flailing around trying to find traction in mobile or VR.

It actually reminds me of Wikipedia, especially with the donation links littered throughout the experience. They're both growing out of control, spending mountains of cash in order to justify spending previous mountains of cash on ventures that nobody asked for or wanted. The whole point of Mozilla is supposed to be Firefox and Thunderbird.

Are you saying that after-surgery antibiotics can't be a cause of antibiotic resistance because we've been giving antibiotics for a long time? It takes on the order of decades for antibiotic resistance to be selected for enough that it becomes a problem. And the first antibiotic wasn't even discovered yet a hundred years ago.

Nuke it with lye. Nothing survives lye, even nonliving germs like prions.

What are you saying is the connection between GitHub's acquisition and this header? This code is from git, not GitHub.

Just to give my perspective, I read it totally differently. The impressive part to me was the F# core doing spreadsheety things, and the rest felt like incidental view logic that had to be covered for the sake of completeness but wasn't really important. I thought the fact that the demo is embedded right in the page was incredibly cool because it let you poke the logic interactively, but I wasn't too concerned with how it was done.

Wow, thanks for pointing that out. I didn't know that was a thing. It's not even encrypted with a device key or something on my phone - I can listen to a recording my own voice streaming straight from myactivity.google.com to my desktop web browser.

I guess the voice scrambling thing must have been specific to their human-supervised learning program. I expect the unaltered voice data is treated with some special care on Google's backend... but I'm still creeped out.

I'm not as convinced as you are that people will simply converge to the better alternative. Sheer inertia from npm activity and accumulated GitHub stars can disadvantage new, better options from gaining traction because it's not easy for developers to take a risk on a new project that could be abandoned at any time, and because they have to be pretty comfortable with the technology to confidently decide that the current crowd wisdom is wrong - something that may not be the case if the developer is working outside of their area of expertise. standard/standard is particularly interesting because someone who's not completely in their element could easily see

  "devDependencies": {
    "standard": "*"
  }

in a package.json or

  npm install standard

in a script, either online or in another project at work, and copy it into a new project along with the rest of the boilerplate common packages they need, not realizing what they've signed up for. This would create the appearance of continuing growth and support for the package even though these users are totally oblivious. It's not clear to me that, with that kind of tailwind, an objectively inferior package couldn't continue to be ubiquitous and never be "converged" out of relevance.

Still, I have to agree that the view you describe is a plausible one. If Feross does indeed think that way - which I have no reason to doubt - then that means that he's acting at least in better faith than some are giving him credit for.

That question seriously resonated with me when I saw it raised in the GitHub thread. (https://github.com/standard/standard/issues/1381#issuecommen...)

Any package which transitively includes `standard/standard` also inherits the advertisement. That would seem to suggest a kind of logic like "if people are going to use my work to help make their thing successful, it's only fair that I'm rewarded too." And that really does make sense. I could totally nerd out over the idea of a graph-based incentive structure, maybe implemented with a new crypto token for extra gee-whiz spiciness. If his prototype `feross/funding` package had been launched with a built-in technical mechanism for transitive profit-sharing I think the idea might just have been intriguing enough to distract from some of the appalling terribleness of embedding ads in package post-install messages.

To me that's one of the icky aspects of this. He's parked on the very nice `standard/standard` repo, with a project named "JavaScript Standard Style," emblazoned on the iconic JavaScript yellow... If you take the time to read the readme it does say clearly about halfway down that the project isn't really a standard at all, just one guy's idea of a helpful linter configuration. But if you don't scroll down past all the company logos, it would be pretty easy to get the wrong idea.

I'm not saying that a lot of work didn't go into it, or that the repo name alone is a slam dunk for tricking tons of people. It's not like domain squatting - this is a real project. But I do wonder if a fork would be able to compete on equal footing without the advantage of the name. We like to think that the availability of at least the possibility of forking provides a sort of guarantee that projects which make enough bad decisions will always be leapfrogged by competitors and great software will rise to the top. I guess I'm not surprised that it's raising eyebrows that this maintainer at least seems to be deliberately pressing a marketing advantage which is just inaccessible to potential forks.

I'm not sure what to suggest as the solution to the underlying problem of coveted or potentially confusing package names. Namespacing library names under user/project names was supposed to be the solution to this! Just repeating the same word twice is a clever way around it. Maybe npm should step in and eliminate this loophole.

All of that sounds impressive, until you see red team pros talk about how the whole apparatus melts before the gentlest of social engineering-

https://www.youtube.com/watch?v=JsVtHqICeKE

I'd also be concerned with leaking of mass amounts of records at once due to a security lapse on servers where it's a bit easier for grossly inadequate protections to lurk unnoticed-

https://news.ycombinator.com/item?id=19191241

I think I've read that Google doesn't even store the original recordings, but distorts them randomly to make them unrecognizable but still intelligible by their models. That seems like a pretty reasonable way to protect people, provided they're informed and there's no link back to the original account.

The article makes this exact point at considerable length...

Check out the 'styles' section of the usage notes. Tags (selectors?) specified in the configuration have an associated bounding box that will get drawn on the minimap in the configured color.

It would function great as a scrollbar for long-form documentation on desktop. The built-in browser scrollbar only conveys your current position in the document. A minimap lets you, for example, quickly flick directly to the next section header even if it's currently off-screen. It would also help reduce cognitive load if you're trying to alternate back and forth between two sections of the same document.

The open-source TIC-80 is a less-constrained fantasy console if you're not aware:

https://tic.computer/

Wikipedia's number is 4,414 deaths:

> Research under way by the National D-Day Memorial has confirmed 4,414 deaths, of which 2,499 were American and 1,915 were from other nations.

https://en.wikipedia.org/wiki/Normandy_landings#cite_note-Al...