intergalplan

Specifically, how would a protocol prevent motivated companies from tracking your personal information?

They could still try! But you'd have options.

Take email, for example. I cannot imagine something like that coming into existence today.

I can use my own client to avoid ads and tracking from my service provider—did I download this message? Sure, the server knows that. How long have I looked at the message? Which message did I look at next? Did I follow any links (yes, someone might track that part, but my email provider's going to have a hard time doing that)? What mouse movements did I make while looking at it? No such luck there, and yes websites and closed-platform services do track that stuff.

I can switch providers. Say my email provider starts injecting trackers into all links. I can just dump their ass if I don't like it. I keep using email, and now they receive zero info about me (I mean, they might get a little if I send emails to their users, but you get my point). If I have my own domain name I don't even need to tell anyone I switched.

I can email someone using a different provider. Yes blocklists or whatever might cause a problem but, fundamentally, this does work.

Protocols force providers to act like a telco, at least, except that the situation's even better for software because the barriers to entry in the market are so low... unless all your competitors are giving away access to their strictly closed ecosystem for free, and not supporting open protocols. Then you're screwed, and that's exactly what's happening now and why the Internet protocols are largely frozen in time.

Look up what the Apple's tracking-prevention policy prevents for users that don't opt-in to tracking. You cannot ban generating device or user identifiers with OS permissions alone. Prevent using the built-in ones, sure, but fingerprinting or otherwise creating device or user IDs to share with 3rd parties and other apps? I'd love to see what a permissions model would look like that could do that automatically, at the OS level. I don't think such a thing exists. Not for any app with enough access to the system to do anything remotely useful in the first place.

Usenet, email, http, XMPP, IRC, et c. Yes, just like those. In combination, that bunch is already not too far off. The trouble is that anything trying to do that is competing with "free" spyvertising services, which have no incentive to integrate with them (i.e. implement the protocol), unless it's to do it temporarily to eat their meager market share before cutting them off. IMO that dynamic is why protocols have stagnated for decades. Working on a client or server for some new protocol is thankless when you know it'll be niche at best, and more likely DOA. Making a go at a business with one is insane in this market. So they stagnate. No new ones catch hold, and old ones make slow progress at best, or gradually die.

Notably, however, a competitor need not target the same level of profitability.

Now, whether asking users to pay for a social network at all is a viable business model, is another question.

You can't realistically keep apps from tracking users without permission unless you're rejecting apps that are discovered to be doing that. If they have network access, they can track. The behavior is too abstract to be handled with permissions alone.

I've always taken Zuck's infamous "dumb fucks" comment to come from a place of astonishment, more than malice. Posting tons of private info under your own name online was strongly against Web norms at the time, but all those newbies didn't know that. FB and others made it normal, but the reasons it was a bad idea to begin with didn't go away.

"Social" should be an Internet protocol. The only reason it's not is that we basically stopped making protocols (well, ones that gain any meaningful traction, anyway—I'm aware there are some lightly-used efforts at social protocols) because all the companies in a position to push them to a meaningful number of users are better served by making interoperability difficult. The "free" services spyvertising economy, where captive non-paying user count & eyeball time is what matters, is why things are this way.

A really good point, and all the more reason to make developer-visible async behavior something the developer has to to ask for, even if the call is in fact async under the hood and might let, say, code handling another request run while it's waiting on I/O.

I think a pattern where there are one or two great places at the lowest level of a Node program for program flow to act async, and then a bunch of business logic where it rarely is (probably running "under" the part where async makes sense, if you take my meaning) is far more common than those where async-friendly flow is what you want for over 50% of calls. "Call this chunk of code async, but run everything in it exactly in order" is super-common, and the interface to achieve that is exactly backwards in Node.

It's bigger than that: iOS is big enough that Facebook charging on that platform would be an existential threat to the company.

How?

It opens up the perfect opportunity for some competitor burning VC cash to swoop in and grab a ton of market share in a hurry, with a free iOS app.

FB knows this, so yeah, it's a completely hollow threat. But, just the idea that one of the tech giants has been backed into a corner by the risk of competition from paying-for-marketshare VCs or operating-in-the-red-on-purpose other tech giants, is really, really funny to me. No fun, eh Facebook? Hahahaha.

IMO it was always a fundamental mistake to force the programmer to deal with the event loop by default. Run async in the background, but present as sync to the developer unless otherwise requested, would have been a much saner design. Unless you're developing a framework or library, odds are good your ratio of leveraging async versus contorting yourself to make it (from your script's perspective) go away will be 1:10 at best.

JS keeps coming up with new ways to make this less painful, but it's ridiculous every time because it's a fundamental problem with how Node presents itself. A comical sea of "await"s in front of damn near every call is the modern version of this, and is utterly typical in real JS codebases, but before it's been callback hell, or screwing around with promises all over your codebase when 90+% of the time you just wanted things to execute in order (from your perspective), and so on.

The notion that people making $350K are having a particularly rough time is nuts.

As for inflation, it's threatening to price people under your $150k/yr cut-off for "hardship" out of decent housing even in mediocre cities, ever, and may eventually hurt creditors some (which, I mean, that's a fine outcome according to most people, I'd think). Those with $150k+ salaries had damn well better have some assets to their name, including maybe a (mortgaged) house, and so will ride the inflationary wave alright. Those with little or nothing, on the other hand, may now never be able to afford anything. Young workers just starting out, who have high-ish income but only because they live in a place with insane housing prices, are getting screwed, too, sure, but established professionals will be fine, unless they've somehow managed not to acquire assets over the years.

Pity the normal couple with $60,000/yr household income. Believe it or not, they raise kids on that income. Go figure.

I wouldn't trade places with someone getting by on unemployment for their $12/hr job they were laid off from, certainly. I don't think they're "looting". We're clearly top-heavy on capital, given how the markets are behaving, so I think I've got a better idea of where the looting's happening.

Sure looks like capital chasing returns in the face of weak—or at least insufficient, for the amount of capital available—demand.

Why would it be?

A lot of JS in the wild favors putting everything in objects (maybe not explicitly, but they end up doing it a lot anyway) so gets away with a lot of "const" use that still lets them mutate the values of those objects. If you're dealing with primitives you're going to need "let" a lot more.

3% accidentally hit the wrong thing but didn't bother to fix it. The other 1% is developers who need to be able to test ad tracking in their apps.

The work seemed to pointedly avoid micromanaging, by instead finding out how to open up the correct pathways between cells in a region and instruct them to become something else. No need to say "OK, these cells need to become a retina, these need to become a cornea" or to figure out how to change the body plan of the creature at the DNA level—just place a "become an eye" marker in the right spot, and boom, the cells self-organize to become an eye, and may even manage to connect themselves to the CNS such that it becomes a functioning eye!

The key insight seems to be that you can hack the (as the research put it, by analogy) software of a set of cells and let the hardware (DNA, cell mechanisms) worry about exactly how to do what you told them to do, so rather than, say, figuring out how to read DNA and tell what kind of organism will come out of it such that we can start adding or removing bits here and there (very, very hard), you can instead screw around with inter-cell signaling to hijack functionality that the cells already have, but just aren't using, to get them to do new things.

I thought there were several "holy shit" moments in the video. The cancer thing—yikes. Reconnect genetically-broken, actively dangerous cells to the inter-cell communication network and they stop acting crazy, while still having messed-up DNA? That's a surprising result, and a powerful demonstration of what the technique can accomplish (may not be therapeutically useful for a bunch of reasons I can think up, but it still seems like a notable, surprising result)

Another was the sticky "memory" of a modified organism, that is, the worm that'd had its tail cut off then been instructed to make a second head there instead, and then had that cut off and... grew a head again, without further prompting, demonstrating that body layout and gene expression is some combination of DNA and a kind of cell-memory or cell-state across the whole organism, not something driven entirely deterministically by DNA alone.

The part about tricking worms into growing heads for 100-150 million-year separated evolutionary relatives, complete with the correct-for-the-other-species brain, was nuts. The "instructions" are still there, just dormant, and if you confuse the cell-memory (if you will) of what it's supposed to be it'll sometimes decide to be the wrong species. WTF.

The mechanisms in the body that grew out your more complicated macro qualities are finely tuned to do all of it at once. Maybe we could micromanage it ourselves, but the actual body doesn't know how to do it itself.

The linked video in the grandparent post argues pretty convincingly that the body might know exactly that, actually.

t͡ʃ, t͡ɕ, ʈ͡ʂ all sound so close to my poor ear that I'd struggle to articulate the difference. They sound like exactly the same thing at slightly different speeds.

Gmail's so bad now that I only use "classic HTML" Gmail in the browser, and native clients (Apple's Mail, for example). I have no idea how they managed to make a relatively simple "web app" so huge and heavy. You could add all of full-fat Gmail's features to "classic HTML" Gmail for very little cost in bundle size and active resource use—though the result might not be an "app" in many folks' opinions, I guess. I just know navigating classic Gmail, with its "bad" full-page loads, is way faster than the "efficient" AJAX-style crap on normal Gmail.

Mobile Gmail's not just heavy—it's broken. Whatever stupid, misguided bullshit they're doing with scrolling makes it register clicks where they weren't intended if I'm not super careful.

But you don't need to run a giant spying system to make that happen, so the companies whose moat is their giant spying system don't want to even try that. They also happen to have all the users/eyeballs (they need them for their spying system, in addition to serving ads to them). So it's hard for anyone else to try it to see how well it works.

The collection is per se harmful as long as warrants exist.

Beyond that, it's an open secret (as in: it's been mentioned several times in available documents, but never deliberately disclosed or extensively discussed publicly, so far as I know) that since at least the mid or late 00s the US government has had contracts with multiple major tech companies that have a high level of access to citizen Internet traffic to basically search their databases of Internet activity at will. Which companies these are, I'm not sure—I suspect it's mostly telcos, personally—but it's another reason the existence of these datasets is inherently dangerous, and that they should not be permitted to exist at all, no matter who holds them.

Time dealing with our shitty medical billing system is a huge hidden cost of it. I'm also not sure how well accountings of US healthcare costs factor in things like the hours HR folks spend negotiating rates, or government folks in areas related to benefits et c. have to screw around with sorting out who has what private insurance.

From what I've seen there are about four kinds of approaches to Agile, in the wild:

1) "We love agile! We have coaches and everything!" (terrible)

2) "We're agile-ish." (we have performative, hellish standups that are mostly about micromanagement, in which we all get to nervously try to justify our continued employment every day by acting out little one-man plays about how hard yesterday was while going into way too much detail)

3) A range of noncommittal responses that may look a lot like 2 in some cases (often really good, but it's hard to distinguish from #2)

4) "We love agile!" (they actually do, and they actually do adjust processes and add/remove/modify "ceremonies" pretty quickly when the team asks for it; this can be good)

The trouble is it's really hard to tell which you're dealing with (aside from maybe #1, though that can be hard to distinguish from #4 unless they really do start laying out all the dedicated "agile roles" they have, then you can tell it's probably #1).

At this point I'd probably insist on sitting in for a couple "agile ceremonies" before I said yes to a place that "does agile". It's bad more often than not, but can be anywhere from OK to good. When it's bad, though, it's really bad. I'm not sure how to tell which it is without observing what they actually do.

For me, the question becomes—if we must write applications to one target that's going to run on a server anyway—why oh why must it be web tech? The whole appeal of applications (not documents) in the browser was that they were (kinda, sorta) able to run on any platform. If your target is one browser on one OS, and you're writing an actual application, why would you subject yourself, your developers, and your product quality to an HTML + JS UI?

Being actually-correct about one's historical analogies and still making them work (or even finding that they don't! Gasp!) is harder than repeating "common knowledge" tales or fudging things to fit your narrative while writing with the same bold voice you would if you were actually-correct.

Not to pick just on PG—that's more common than not, really.

Exactly. The tech is farcical (surely even a proponent of them can see that?) but that's not really Mighty's fault.

It's bad because their strongest viable business plays seem to all involve leveraging their access to people's browsers in not-so-nice ways.

This product will likely starts as a corporate malware but once the beta is over and their tech is really working at scale (more difficult than you might think) they'll probably give it for free or very cheap.

So you think it is a dragnet-surveillance get-acquired-for-our-data play, longer term? That's even worse, if so.

I have trouble seeing how it's going to find a sustainable market except as business spyware/leak-prevention. Which is yet another reason I'm not a fan of the idea. In that capacity it may actually manage to survive and even thrive, but I'm not going to be happy about it.

Yes! That is definitely a big step in the right direction. It's usually enough to remove at least some of the JS burden on forms. I'm not sure how widespread its use is in practice, though.

TL;DR:

1) Not really, no (Napoleonic and Seven Years' have decent claims to being about as global)

But:

2) It's fair to dub it, at least, a World War, if anything is.

Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost in time and ongoing overhead in time & bugs for everydamnthing else added to the UI after. I've seen business-side people favor terrible products because they have drag-n-drop, while a better alternative doesn't. They love it.

It's heavy-weight, fragile, lots of implementations are framework-specific, and most of them are horribly buggy, but it's nonetheless a must-have feature in many cases. It'd be a great candidate for better support in the browser, generally, if we're going to insist on using it as an application platform.