shanemhansen

I wonder how well this will actually work.

The core problem is that alot of crawlers aren't spending their money. They are part of a botnet so they are just spending the victim's money.

But hopefully most of the crawlers aren't botnets or funded by free VC money so they have an economic incentive to avoid crawling systems requiring proof-of-work.

This is a complete shot in the dark but wild speculation is fun. If atop had a buffer overflow when reading a process name (changeable at runtime using $0 in perl for example) this would be the kind of issue I expect.

Similarly, some other value that was expected to be null terminated but wasn't.

I used to live in a suburb. I met people the same way you meet people anywhere: common interests.

A dozen or so people with dogs met at the park every day. We knew each other, watched each other's houses/pets on vacation, and sometimes did dinner or BBQs.

A few people organized a DnD group after advertising on nextdoor (which is a cesspool but only 70%).

Of course those with kids the same age often knew each other because of school or activities.

The neighborhood park had a system of "pea patches" where you could grow some stuff next to your neighbors.

There's nothing that unique all in all about this space other than there was a "third place" we all had built and took care of (the park was originally supposed to be a school that never got built so the community got it to become a park but at least half the work came from the community. The county provided some matching work).

The weird thing is people are people no matter where they are, mostly. And if you are lonely, you can go fix it.

Lots of people move from somewhere they hate so somewhere they think will solve all their problems. And they are right. Or they move from somewhere they love to somewhere that they know will be terrible. And they are right. It seems like whether you think your neighborhood is great or terrible, you're not right.

So ChromeOS and also the OS for GKE are still basically built this way.

Don't forget:

Writely: Google didn't make Google docs.

Android: Google didn't make Android.

Alphabet is great at marketing themselves as makers. But what they really excel at is finding great ideas in the wild and making them mediocre.

I disagree. As a former googler, that company has never had a problem creating IP.

It has a problem executing on that tech to create great products. It has a real problem with canning any project that doesn't have a billion users within a year.

Honestly they fail to understand how lucky they got with doubleclick and culturally the entire project evaluation criteria is based around the assumption that they can do another computer science rain dance to make it rain ads-level cash.

I would like to live in this world. If for no other reason than the idea of teams frequently declaring "bug bankruptcy" or the frequent use of "stale bots" to ignore issues that I haven't nagged about enough recently are actually offensive.

Both of them throw away real bugs and even work done by users to reproduce and turn a fact: "your program crashes when x happens" from something they can verify and accept to an ongoing time commitment to nag them. I don't want to nag them, I doubt they want to be nagged by me. What they probably want is some signal for prioritization of planning which stale bots do, poorly.

Why do they constantly ignore what their users tell them? Because to use the terminology from the article, to a user they are reporting a bug but to the maintainers that is potentially adding to planned work and their capacity is finite. A team should absolutely be able to say "we have no plans of addressing this even though it's true that our software doesn't work on an ancient version of glibc" for example.

In this model the stale bot would apply to plans not bugs. A "stale" plan would be an item of work that users have not expressed interest in for the last N days. Which at a gut level is a lot more acceptable than "the software we acknowledged is broken hasn't been fixed this month so we're going to close the issue".

The nice thing about Google Takeout is that sometimes, if you retry often enough, it works.

The frequent failures to generate my takeout are annoying though.

Well at the VM level live migration and vmotion have been around for a while. I've watched a VM get migrated while ping is running without missing a single packet.

CRIU is used lots of places for Linux processes but in my experience is far more low level and finicky and it tends to do things that require root permissions. It's used in production, but I would be shocked if, for example, someone made it so k8s could just live migrate any pod with CRIU.

Just think of the possible ways apps that might break if you changed their hostname or pid out from under them. And that's not even including stuff like connections to localhost or shared memory.

Well I know it's not directly the answer to your question, but the article mentions that in practice a partitioned cache increases bandwidth by 4%. Which at the scale of billions of web browsers is actually pretty bad.

In my opinion the benefits of domain consolidation outweigh the costs.

Using a bunch of domains like a.static.com,b.static.com etc was really only helpful when the limit on connections to a domain was like 2. Depending on the browser those limits have been higher for a while.

For http/2 it's less helpful.

But honestly there's not really one right answer theoretically. multiple domains increase fixed overhead of DNS, tcp connect, tls handshake, but offer parallelism that doesn't suffer from head of line blocking.

You can multiplex a bunch of request/responses over a http/2 stream in parallel... Until you drop a packet and remember that http/2 is still TCP based.

UDP based transports like http/3 and quic don't have this problem.

I agree. Even within those types there are some types of rides that are massively different.

In MTB you have XC (cross country) which can be more about distance and grit. These bikes are lighter and have less suspension because you don't typically do a 10 foot drop on one.

Enduro racing is what I think of as similar to skiing or snowboarding. You can go do the green/blue/black at a resort. You can also do the equivalent of taking a helicopter to the top of a crazy mountain pass and jump out. Then there is park stuff. Snowboarders might hop into a rail in the park. Mountain bikers might ride a wooden feature.

The point being it's important to distinguish whether you're talking about the danger of taking a flowy green downhill or the danger of going off a 20 foot drop or the danger of hopping onto a narrow piece of Park stuff that's 30 feet off the ground.

Because the injury rate of people on double black diamond runs in BC with 30 foot tall one foot wide wooden features is just not relevant to me because I am not riding that kind of terrain.

I empathize because I literally just finished healing from an injury that came within millimeters of killing me because I followed someone into an area that I wasn't prepared for. The first hospital I went to, after doing X-rays said I needed a level one trauma center and called an ambulance to take me to Seattle harbor view.

I broke the cardinal rule of new technical terrain: pre-ride, re-ride, freeride. You get off your bike and walk the feature to see how approachable and rollable it might be. Then you session it (ride just that one feature). Then you ride through it quickly as part of a longer trail.

I went 5 years without an injury. This one healed in 3 months. I believe I know what I did wrong and can fairly easily avoid making that same mistake again. Do I expect zero injuries in the future? No.

What I expect is years at a time of an activity that very much enriches my life, with occasional injuries. Hopefully more than 5 years at a time since I'm making changes to avoid repeating the same mistake.

And I wish people knew that downhill mountain biking is a lot like downhill skiing. You can take the greens down or you can yeet yourself off something that's tougher than a double black diamond. I've gone on many group mountain bike rides with people in their 70s. So like skiing it is something you can shoot for doing into your old age.

This title is so bad it's basically a lie. Better title: spinal cord injuries from mountain biking in BC exceed other high risk sports.

The terrain in that area and parks include things like a lot of 30 foot tall one foot wide wood walkways.

And as a MTB destination this terrain is often attempted by basically tourists.

This is like saying "hiking injuries exceed other high risk sports" on Mt Everest.

I think you are right.

But a gentler answer is that if you don't know what you need to do the hike, you ask around for best practices and probably end up following some that are overengineered.

The people like you during your hike, in my experience, fall into two groups. Either they've had so much experience that they know exactly what works and what doesn't work for the conditions or they kind of got lucky.

I've taken a similar approach to the literal problem. Look I've backpacked in Peru and Iceland and spent enough time mountain biking and hiking and stuff. I'm an adequate hiker.

There's probably not one sport where I haven't been shown up by someone in jeans or payless shoes.

Peru is a great example because when you are hiking the Inca trail to dead womans pass in all your fancy gear there are quite literally locals in jeans and payless shoes with a mattress on their back jogging past you.

I'm all for safety but the truth is there's a lot of "safety theater" with the pattagucci crowd. Signed: someone who doesn't wear jeans, just gets schooled frequently by those who do.

My information is probably out of date but historically yes. Also historically operating systems other than Linux were pretty iffy.

I know you can run BSD on AWS for example.

It depends on if your tools make it easy. For example in Go the default http client and server basically just enable HTTP/2 by default.

My understanding is that bradfitz championed that.

I recently left Google and I do miss blaze. I'm working on some stuff that's rust and wasm and typescript and there are containers and I'm very tempted to use bazel for basically correct caching and stuff.

But even as a xoogler I think that the common wisdom of "don't use bazel until you can afford a team" or "use bazel if you are the only developer" are probably right.

My somewhat janky series of dockerfiles and bash scripts is at least debuggable to my business partner.

I'm just not ready to commit our future frontend developers to having to use bazel yet.

I'm sort of sticking to a lowest common denominator technology stack for most things except where we are spending our innovation tokens in wasm land.

But someday, probably. In the meantime I may setup sccache.

It can be surprising to be on the other end of something and see the lack of sympathy.

I went on a group hike once and somehow ended up telling people that my house had been broken into. It was a bummer. Actual monetary damages about 10k, but so many little gifts and heirlooms that were irreplaceable. It's hard to express the sense of violation. They also stole some of my wife's underwear which was just gross.

Someone replied with "well maybe if they were paid a living wage they wouldn't have to steal". Because obviously stealing my wife's underwear is much like stealing a loaf of bread to survive ala les miserables.

It's like all nuance has been lost. Some people think that if you believe that the housing situation isn't great then you just have to be pro anything that calls itself a solution.

I hope they eventually figure out that's not necessary.

Google is my former employer and this statement isn't referring to stuff I heard while employed there.

But after I left, I heard a that alot of the poor performance of Cloud Run is just plain old oversubscribed shared core e2 stuff.

I saw this used from time to time at Google. There were occasional utility SRE notebooks (colabs). Also the cloud support team seemed to make more use of them.

I think I was very unclear. I didn't mount anything, the docker daemon by default is accessible over http (over a unix domain socket rather than the typical TCP).

I was proposing that this persons web app not do any sort of subprocess automation via something like ht, and instead take in requests and talk to the docker daemon on clients behalf. Since that allows any sort of authentication or filtering that needs to happen.

I wasn't really seriously proposing the straight reverse proxy setup. That's one of those layer violations like PostREST that is either genius or lunacy. I haven't figured out which one.

That would work but wouldn't making http requests to the docker socket itself be a little easier?

Example:

    curl --silent --unix-socket /run/user/1000/docker.sock http://v1.41/version

From: https://dev.to/smac89/curl-to-docker-through-sockets-1mhe

You could even do something like a reverse proxy to very limited paths although I tend to think that would ultimately be a bad idea and making your own http calls is probably better.

Well if you use apt you might be in luck. There's a bunch of apt transports. I don't know the maturity of them but you can google apt-transport-debtorrent, apt-transport-s3, and one for ipfs.

https://github.com/JaquerEspeis/apt-transport-ipfs

It's weirdly specific but I remember old versions of go caused that error. The final packet (close_notify) to close the connection was set with the wrong error level.

This seems like a reasonable use of resources and time? I'm assuming the British Museum has been around a bit longer than 5 years and hopefully plans on being around longer than 5 years.

Maybe than can hire a couple people. [edit] removed inflammatory last sentence.

I'm working on something in a similar space. It's not as mysterious as people make it sound:

You do caching so you don't always have to go back to the DB is the main thing. The other interesting capability is light scripting at the edge. Think "this page is cached but I'm going to add in a custom username".

There's some more exotic stuff around sharded database locality. But I'll skip over that because distributed mutable state is hard and its not my specialty.

Connection warming and shorter tls negotiation round trip times are also a thing but probably less important compared to the database thing you are mentioning.

But mostly this architecture makes sense if you can do some caching or if you're doing more data/log collection stuff.

For prior work see ESI (edge side includes). Assembling stuff at the edge does have some benefits but it has been hard to create a good interface for that.

> You have been blocked! If you are not a malicious actor, please update your web browser to the latest version to access this website. If the problem persists, please contact support.

Unfortunate.

I think that these days the scammers have won. They can do a better job than I can at being authentic.

FWIW based on the comments I actually prefer a richer runtime that allows some of the language level features that have been hard to get support for. I think having mainstream support for effects would be sort of magical.

Actual isolated modules? Talk about living in the future.

Wasm is a lot like the jvm and flash, which makes some people hate it. But for me the problem with those platforms was the execution, not the idea.

I'm cautiously optimistic that wasm will finally give us a good high performance cross platform secure execution target for the web.

I recently upgraded my home network and realized my laptop had just gigabit Ethernet.

So I bought a couple 2.5G USB 3 adapters and confirmed: iperf3 reports 2.5 gigabit between my laptop and desktop connected to the same switch.

Much cheaper than getting a new NIC for the desktop.

gigabit Ethernet over a switch under my desk makes nomachine almost pleasant.