shanemhansen

Killedbymeta.com when?

To me it looks like a SharePoint for engineering teams.

With plugins focused around projects/deployments/metrics.

Which sounds actually interesting.

Chrome supported this for a long time and it really helped small developers outside of Google be able to build chrome without specialist machines.

But that feature was pulled by the chrome team with the stated justification being that since C++ guaranteed different things (iirc around variable scopes outside of a namespace) for one file vs multiple files, supporting the jumbo build option meant writing some language that was "not C++".

Unfortunate.

I had noticed that Google's ML teams are doing a ton of Python, and at the same time the overall support for Python in prod was pretty low.

This has lead to some interesting situations over the last year. Especially as "move fast and break things" Google Labs style demos meet "everything deployed must comply with a thousand horizontal mandates relating to SLAs, logging, production best practices, etc".

An astonishing number of things used every day at Google are unfunded "community commons" projects. This sort of used to work in the past when the company and the employees had a different relationship.

As Google gradually changes that relationship to a more conventional one, they will see more and more conventional results.

As I learned in Google SRE: "hope is not a strategy"

I do think this was well written and informative. I have a request (I know I know another entitled non customer).

Why not tell me how fast they are supposed to be? I hear "they are so fast it sounds like a brag but no really they are super fast" and I just want to know: how fast? I did 2-3 searches and didn't find an answer.

Google publishes instructions for benchmarking via fio. https://cloud.google.com/compute/docs/disks/benchmarking-loc...

I understand more than most just how variable these results can be but I've always appreciated that the gcp docs essentially give customers repro steps for confirming performance.

I live somewhere with similar weather and I don't feel like the weather is getting me down... Until there's a sunny day and I'm 10x more productive and happy.

I think it's 50/50 whether or not I believe the reasoning.

One one hand: killing a product for not being multi billion user multi billion dollar overnight success is incredibly on brand.

On the other hand: I 100% believe that they just found government pushback too burdensome to comply with. That would match what I saw when I worked there.

I use it. But honestly the reason why is because in 2005 or so I got a web job and my manager sat me down at a Solaris sunray running thr Java desktop environment (gnome) and told me to click on XEmacs to edit code.

Now I stay because lsp makes it good for every language and then org mode and tramp and babel and eshell are just game changers.

I don't see too many emacs users. My old director at Walmart Peter was one iirc.

Port knocking involves sending a packet to certain ports on a host. It's overkill but typing http://host:port/ in your browser will, as part of trying to make a TCP connection, send a packet to that port.

I wasn't around Google when the book was written but after having read it and then managing a SRE team at Google my takeaway was: the book was not a documentary on how SRE works day to day. It was a loose collection of aspirational essays and fun historical stories. The reason those stories were so fun is because they are in fact still pretty unusual.

The problem of "how many CPUs should I use?" is really only answerable empirically in the general case.

The problem of "how many CPUs are available?" is a little more tractable. Currently when running podman, the cpus allocated seems to be available in the /sys fs. I wonder if it's the same under k8s?

    podman run  --cpus=3.5 -it docker.io/library/alpine:latest /bin/sh
    / # cat /sys/fs/cgroup/cpu.max
    350000 100000

They do. But I'd say most employees go their whole career without needing to do anything that requires a VPN.

It's basically all web based access through what is, at the end of the day, a http proxy.

SREs need to be ready for stuff like "hey, what if the big proxy we all use to access internal resources is down?".

Well technically they do, but honestly the number of companies that need to worry about redundant DNS is probably .001%. It does matter for the some people, but as someone from SRE once said "100% availability is the wrong target for basically everything".

dig SOA news.ycombinator.com

; <<>> DiG 9.18.16-1-Debian <<>> SOA news.ycombinator.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10818 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;news.ycombinator.com. IN SOA

;; AUTHORITY SECTION: ycombinator.com. 900 IN SOA ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 39 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Oct 25 10:52

I discovered this independently. After years of trying and failing to organize my notes by project/folder I finally was inspired by my scientist wife's labbook entries and decided that to try an append only log (which happens to be an org file).

My current main labbook.org file has 20k lines and a header for each day. Super easy to just search for any content/tags. I use org todo tracking (which mostly just automates toggling between [TODO][DONE]) and the org babel features mean that I can also use it like a python/jupyter notebook with little code snippets and visual graphs. I use snippets of python, graphviz, shell most often but occasionally sqlite/duckdb/too.

It's really the only system that's worked for me.

I used this over a decade ago when writing some tests involving postgres stored procedures, it's nice to be able to output a standardized format and have other tools be able to read it. Especially since at the time most of our company used perl.

junit's xml format is also similarly valuable as an interchange format and was how I set up unit test reporting on some of my first golang CI pipelines in jenkins/hudson.

It would be a fun test to run. But I'm not encouraged by the fact that the existing brotli dictionary already contains a bunch of javascript specific stuff:

https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e

brotli literally already has a tokens for function/return/throw/indexOf(/.match/.length/etc.

Also verify after decompress is not without tradeoffs. On one hand we have folks like github who can't change the version of zlib because people rely on identical .tar.gz. https://news.ycombinator.com/item?id=34586917

On the other hand we have a whole lot of iffy stuff you can do to make programs decompressing content use large amounts of resources https://en.wikipedia.org/wiki/Zip_bomb which makes "decompress this potentially untrusted file so that I can validate it's safe to use" hard.

Great article. I had the misfortune of writing a bunch of twisted code over a decade ago and I wanted to remind the author that twisted has a feature called "inline callbacks" that allow you to use yield. https://twisted.org/documents/16.4.1/core/howto/defer-intro....

So twisted code can actually look like:

    @inlineCallbacks
    def doIt():
        responseBody = yield makeRequest("GET", "/users")
        returnValue(json.loads(responseBody))

iirc `returnValue` throws an exception of a specific type. It's ugly, but it's also the logical implementation of async on top of yield/generators.

The author said something that is technically correct but I feel gives the wrong impression to us folks who may be trying to solve the "kill all child processes" problem. There is a simple bash one-liner to ensure child processes are killed that doesn't require root and it's using one of their examples of a process leak:

    unshare -U --map-user=$(id -u) --map-group=$(id -g) -f -p sh -c '{ sleep inf &} &'

The author doesn't share this example because "user namespaces introduce a number of quirks, such as breaking gdb (by breaking ptrace), so they also can't be used by most users". I disagree that the container/unshare approach can't be used by most users. So strace works just fine on my machine and gdb is able to attach and print a backtrace. Now it's true that gdb itself prints out a warning when I do this:

    warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.

So:

- user namespaces do solve the "kill all child processes" problem

- strace still works

- gdb from outside the namespace isn't fully supported

So if you wanted to debug a child subprocess with gdb you'd presumably have to invoke gdb via unshare so it shared the same pid namespace (not tested).

QUIC could be a candidate, RPC over UDP/IP is definitely the direction proposed by Ousterhout. He has a few specific TCP things he's listed as being undesirable and frankly I'm not sure how QUIC stacks up on.

- Bandwidth sharing (“fair” scheduling) - Sender-driven congestion control

See: https://arxiv.org/pdf/2210.00714.pdf (pdf download)

This seems like a review of John Ousterhout's work w/ Homa. I highly recommend reading the original. https://arxiv.org/abs/2210.00714

For those who don't know Ousterhout created the first log structured filesystem and created TCL (used heavily in hardware verification but also forming the backbone of the some of the first large web servers: aolserver). I was actually surprised to find out he co-founded a company with the current CTO of Cloudflare. https://en.wikipedia.org/wiki/John_Ousterhout

He has both a candidate replacement as well as benchmarks showing 40% performance improvements with grpc on homa compared to grpc on TCP. https://github.com/PlatformLab/grpc_homa

With that in mind I think nobody will replace TCP and I doubt anything not IP compatible will be able to get off the ground. His argument is essentially that for low latency RPC protocols TCP is a bad choice.

We've already seen people build a number of similar systems on UDP including HTTP replacements that have delivered value for clients doing lots of parallel requests on the WAN.

I think many big tech companies are essentially already choosing to bypass TCP. I recall facebook doing alot of work with memcache on udp. I can't find any public docs on whether or not Google's internal RPC uses TCP.

I wouldn't be surprised at all if in the near future something like grpc/capnproto/twirp/etc had an in-datacenter TCP-free fast path. It would be cool if it was built on Homa.

I think google search trends might not provide good data on interest in TikTok search.

In my experience Kafka is alot of work. If you need the guarantees it provides or the ecosystem it unlocks then by all means, use it.

If you can relax your constraints, then something like NSQ can be a great option that I heartily recommend.

I need to read more about the "dictionary" approach. I am not stoked if using generics carries the performance penalty of virtual calls, but it sounds like it's sort of a hybrid approach where Vec<T> won't be "boxed" which is a big win.

I get your point but I think Snake Oil might be too harsh. More like flu vaccine. Proven effective against an attack that was going around and similar attacks but not really guaranteed to prevent all strains of flu.

So no guarantees on whether it will solve all of your apps problems, but from a public health perspective likely to save VMs from getting owned in aggregate.

There's lots of ways to lie with surveys, I wonder what the exact wording was and what the responses would be to variants such as:

1. Do you want to be CEO of your own company or a peon employee?

2. Do you want uber to set your hours?

3. Do you want medical, vacation days, or unemployment insurance?

For some people these are all basically the same questions. For most folks, I don't think they are.

Just a random gopher sharing their level of surprise. I didn't know about the spf13 project, but I instantly thought of https://godoc.org/golang.org/x/tools/godoc/vfs

Looks like they mention that package in their proposal.

I can't really confirm/deny whether what he was saying was true, but I heard this from him around 2009.

So I used to work with someone from Amazon retail. He told me, in no uncertain terms, that Amazon mined their seller data to undercut them. We sold on Amazon and he constantly told us that we were fools to do so. He even mentioned that prior to accepting a position he had looked up our seller performance to make sure he was going to a good company.

Maybe policies have since changed. At the time I was also told the most popular "test" SKU used by Amazon engineers was a 50 gallon barrel of lube.

Ah, good old links2 -g