This also seems like a great way to get everyone to leave. If what I wanted was a B2B platform, I wouldn't choose one with a history of suddenly changing its policies and only giving one week to catch up.
In fact, it's often much more difficult for a larger business to move that quickly than an independent user.
I've had great experiences with pair programming (and also bad experiences, but this is assuming a great experience), and I'd still want code review. The benefits can actually stack, if not compound, often enough.
Turning PDFs into the replacement for HTML would change the incentives around PDF authoring, and PDFs would then acquire the same problems identified with HTML.
The solution to the identified problems is not to switch to PDFs. Stop reshuffling the chairs on the deck of your sinking ship, and start figuring out how to design, implement, and incentivize the use of, some means of conveyance other than iceberg-vulnerable ships.
> On a related note, part of me wishes Java Applets never died. Getting rid of them seems to have caused the Web to turn into them, and maybe if they'd remained some kind of separation could have been maintained.
It's possible to write PDFs that don't "work" (for some useful definition of "work" similar to the case with HTML) offline. Please stop pretending that's not true.
The reason offline utility tends to be true more often for PDFs is that PDFs are not generally regarded as the preferred online-default format of choice, which is in turn a matter of social effects rather than technical capacity. Reverse the socially accepted roles of the two document formats and watch the same complaints get made against PDFs as you're making against HTML. I'd bet money the "normal" state of affairs would remain the same in terms of the perceived benefit/detriment allocation between online/offline formats; only which format was considered which would have changed.
. . . but then all the web would be even heavier documents, and even less customizable for local viewing, thanks in part to that pagination and strict formatting situation.
Why does it seem like almost everyone doesn't realize that PDFs can easily be made to support all the horrors we see in HTML? No, it's fucking well not impossible -- or even notably difficult -- to jam some malicious dynamic code into a PDF. The only reason a period of widespread fear about PDF viruses hasn't developed as it has for websites spreading malicious code is the fact that websites got much more widely adopted. PDFs have been used as malicious code vectors before, and replacing HTML with PDFs would only result in PDFs being the new common vector for the same problem, with at least the same scale and intensity.
This only seems like a solution if you don't know what PDFs can do -- and, by the way, sometimes pagination is bad, especially static (non-reflow) pagination.
EDIT:
Let's make this clearer.
You can actually embed an entire JavaScript application in a PDF. Tell me again how PDFs somehow prevent the problem of dynamic pages on the web. All using PDFs instead of HTML pages would do is wrap the horrors of the web in forms that are generally more hostile to various viewing contexts for the less harmful use cases (e.g. static pages suddenly being harder to read in some contexts with PDFs than with HTML pages).
I actually dislike HTML per se, but the only two benefits I see for PDFs in the general case are:
- In my experience, it's a little harder and rarer to make PDFs utterly incompatible with different means of viewing them, and it generally requires more overt (if perhaps slightly unintentional, at times) sadism to make that happen.
- PDFs can do some things HTML can't (easily, at least) with document design -- though those things are generally things that would be disallowed in our new "deurbanized" PDF-based web replacement.
Everything else that comes to mind goes the other way, including the fact that the viewing-mechanism incompatibility thing can be even worse with PDFs, even if it's more rare for that to happen at present, and if PDFs became the new standard for the web I'm pretty sure that relative rarity would evaporate anyway. Let's also not forget that HTML can also do some things PDFs can't (as easily, at least) do.
A key here is that it's easier to write good HTML docs than good PDF docs, and much harder to deal with the harmful aspects of PDF docs given present technology.
> Which is interesting! Do you have thoughts on creating peer-to-peer systems that don't enable surveillance capitalism?
I don't know about the other person's ideas, but decentralization plus better anonymization and pseudonimization, with always-on strongest-reasonably-posible encryption, seems like the direction to go.
Those points can be trivially met with static HTML and something like IPFS, and you can still download HTML for local storage and viewing. You can even print to PDF if you really want to do so. Meanwhile, PDFs also allow dynamic files, don't require dating and hashing, and can be used to spy on users or deliver malware.
EDIT: Oh, yeah, and static file formats doesn't necessarily have to mean static document formatting when viewing -- unless you're using PDFs, which tends to break useful stuff like reflowing for paginated documents (one of the worst things about even simple PDFs).
It seems to have been 2017 (hopefully I recall the year correctly), by transfer of legally owned/registered assets (all that comes to mind immediately that was under non-volunteer ownership is a couple of servers and a domain name or two, but maybe I'm mistaken about that). Of course, I'm not on any side of this, especially not the "inside" (wherever that may be), and I've just read some of the stuff being published by both sides.
In my estimation, the biggest potential problem for Freenode policy that I see is based on the the statements by some departing staffers that indicate the parent company may collect and monetize user data. That would be a pretty shitty outcome. I asked a current (post-split) Freenode staffer about improving privacy measures on the network, and got very encouraging responses, though. Of course, a single staffer is not exactly an ironclad indication of policy. Perhaps the only way to really know how it'll hash out is to wait and see. I plan to keep an eye on the Freenode privacy policy.
Just for the sake of those who might misunderstand this comment:
She wasn't a "Civil War widow" per se. She was not widowed by the death of her husband in the Civil War. She was seventeen years old in 1936, and married a ninety-three year old Civil War veteran. She was the widow of a Civil War veteran.
From some of the discussions I've seen, it looks like part of the MobileCoin strategy is to shit-talk Monero as a way to build hype for MobileCoin, and claim all prior art came directly from CryptoNote while ignoring the fact it's implementing stuff pioneered in implementation by Monero. I've seen some pretty friendly discussion history with Monero in the first days of the nascent MobileCoin project turn into MobileCoin people being absolutely, obnoxiously awful later on.
If there's some way this can be explained away by MobileCoin people, I think it'll make a great story, because there seems to be a lot of stuff there that doesn't look explainable.
I'm pretty sure that's just a buzzword for "revenue model", which is to say a plan for how it will make money. The charitable interpretation in this case would be "how to keep devs on the job and not homeless", and the uncharitable case would be "how to make Moxie Marlinspike and his buddies obscenely rich".
It looks to me like either there's a lot of selling out going on here or there's a lot of great examples of how not to market a good thing to reasonable, aware, suspicious people (which is, in short, pretty much the core market demographic of privacy software users).
As for me, I'm starting to wonder whether Session is much better than Signal, and I think that if you want privacy in a cryptocurrency you're probably better off with Monero.
step 2 of any analysis: project forward
You did this well.