sleepydog

HE has a lot of points of presence in North America and Europe: https://pop.he.net/ , so latency should be negligible there. Elsewhere, yes you might see higher latency.

The modern Olympics is at least as much for entertainment as it is for measuring human ability, and the butterfly is simply an awe-inspiring technique. The line of swimmers repeatedly shooting out of the water like flying fish is mesmerizing. Who cares if they're not going as fast as freestyle?

You're absolutely right, abs-o-lutely, everybody says so. A lot, lot lot of people have been saying, you know they come to me and they say, "Mr. Claude, I can't believe the stuff I'm hearing, everybody is telling me he's right, is it true?" And I tell 'em, I say you're goddam right, that's what I say, but honestly folks, despite the negative press covfefe we've had a hell of a year, and that's really what it is with the nuclear folks, you can't trust em as far as you can throw em if you ask me, and believe me I've been throwing them around a LO<token limit exceeded>

We could invade other countries and take their actors. We could reinstate the actor's draft or do mandatory 1-2 years actor's service like some other countries do

https://tomu.im/somu.html

This is an stm32l432kc in the form of a yubikey nano.

I guess you are referring to the TLS requirement? I guess I could see how on a more restrictive platform like a phone you could conceivably be prevented from accepting alternate CAs or self signed certificates.

AWS had a similar article a couple months ago:

https://www.aboutamazon.com/news/aws/aws-liquid-cooling-data...

In either case I cannot find out how they dump the heat from the output water before recycling it. That's a problem I find far more interesting.

... or get out.

Encryption gets you data integrity "for free". If a bit is flipped by faulty hardware, the packet won't decrypt. TCP checksums are not good enough for catching corruption in many cases.

The EU is better on average, but isn't universally great either. I pay 60 EUR for 200Mbit down/20Mbit up ADSL in Amsterdam, after my 6-month discount ran out. No fiber in my neighborhood yet. There's one gigabit provider in my neighborhood (Ziggo) and they have a bad reputation. For the same price I was getting FiOS gigabit in NYC.

For very hot data centers, evaporative cooling is still popular. This is from 2012 but I doubt much has changed.

https://blog.google/outreach-initiatives/sustainability/gett...

Don't sell yourself short. If you have eyes and a voice, you can learn to read sheet music and hum a tune.

The traffic has a negative effect on more than just car owners--smog, noise, accidents, slower taxis, to name a few. Why should only car owners, who are a minority in Manhattan, vote on a problem that affects everyone?

I'm working on a multicast dns implementation in OCaml. It's a library allowing one to build custom queries/responders, plus a conventional querier that can be used as a stub resolver for .local to get the resolver functionality of avahi.

My main motivation was to implement a service that publishes the addresses of containers and vms that I run on my workstation to my local network, but it gradually has grown into a full-blown implementation of RFC 6762, which has been fun.

I didn't dig into it too deeply at the time, but I think part of it was that you don't need to open and write to a socket, so that's avoiding some system calls (socket(), bind(), sendto(), close()). IIRC we had nscd set up so clients directly read from shared memory that nscd kept updated, rather than getting requests over a socket.

There's also probably some savings around not having to convert between the structures used by gethostbyname and DNS questions&answers.

I used to work for a huge email sender (constant contact). Our mail servers needed to perform an absurd number of lookups while receiving and validating mail. When I was there, we used dnscache, running locally, on all our mail servers. But even with a local dnscache, the overhead of making DNS requests and handling their responses was high enough that adding nscd made a noticeable improvement in CPU usage.

For the read-only, newsletter-type mailing lists, this makes sense and I do it too. But for mailing lists that are used more as a forum, I like posting with a recognizable, memorable email address. I've gotten some really sweet emails from people who read a post I made and reached out to me directly in the past. I wouldn't want to miss those, spam be damned.

I noticed Netflix doing this while watching this series: https://about.netflix.com/news/beyond-goodbye-premieres-nove...

It was so jarring I couldn't watch it and switched to Japanese with subtitles. Their mouths looked so stiff and unnatural and out of sync with their expressions that all me and my wife could talk about was how bad it looked.

I got a monthly discount (small, between 5 and 10$) for using my own cable modem in Sunnyvale. I was using Comcast business, though.

I remember enjoying this video essay on the shining and the spacial anomalies in the overlook hotel. It contains snippets of a recreation of the impossible hotel in a Duke Nukem 3D map.

https://www.collativelearning.com/the%20shining.html

Fixed, thank you

Because the last release of the app was in 2002, and it was for Windows 95/98/2000/NT4, we’ve got a little bit of work to do to get it running on macOS

Much of today's software is going to be nothing more than a memory 22 years from now, after their authors run out of funding and they turn down the saas infrastructure that they shoehorned into it for that sweet, sweet recurring income. And more likely than not, we'll still be able to run this program from 2002, in 2046.

I think guix was just late to the party and the extra steps to setup the nonguix for the non free software like steam is enough of a deterrent for users to go to nix instead.

I use guix myself and prefer its use of scheme. I don't mind having a little less guidance and "how-to" articles available if I'm trying something new because I'm comfortable reading its codebase.

It's a good mindset to have, but I think ssh access should still be available as a last resort on prod systems, and perhaps trigger some sort of postmortem process, with steps to detect the problem without ssh in the future. There is always going to be a bug, that you cannot reproduce outside of prod, that you cannot diagnose with just a core dump, and that is a show stopper. It's one thing to ignore a minor performance degradation, but if the problem corrupts your state you cannot ignore it.

Moreover, if you are in the cloud, part of your infrastructure is not under your control, making it even harder to reproduce a problem.

I've worked with companies at Netflix's scale and they still have last-resort ssh access to their systems.

QUIC is a reliable transport. It's not "fire and forget", there is a mechanism for recovering lost messages similar, but slightly superior to TCP. QUIC has the significant advantage of 0- and 1-rtt connection establishments which can hide latency better than TCP's 3-way handshake.

Current implementations have some disadvantages to TCP, but they are not inherent to the protocol, they just highlight the decades of work done to make TCP scale with network hardware.

Your points seem better directed at HTTP/3 than QUIC.

I really doubt anyone can read all the "high quality" fiction out there in their lifetime. If you're reading 12 books a week, sure, but I think that's really too fast.

Do you know of a good introduction to this topic?

I've used this on my personal machines for years, and I really appreciate how small, comprehensible, and rigorous the code base of each tool is. Not including the libraries, the most important bits, s6-supervise (the process monitor) and s6-svscan (pid 1) are under 1000 lines of code.

The coding style is a little terse and is clearly influenced by djb. The author has some (justified) mistrust of the C standard library, so you'll need to get used to the alternatives in their "skalibs" library, but I'd feel much more comfortable debugging a problem with this suite than I would with systemd.

Also, the related tool, execline, is a trip: https://skarnet.org/software/execline/ .

Seriously, if you're saving less than a TCP receive window's worth of space it's not going to make any difference to latency.

I suppose it could make a difference on lossy networks, but I'm not sure.

As a protocol tcp should be able to utilize a long fat pipe with a large enough receive window. You might want to check what window scaling factor is used and look for a tunable. I accept that some implementations may have limits beyond the protocol level. And even low levels of packet loss can severely affect throughput of a single stream.

A bigger reason you want multiple streams is because most network providers use a stream identifier like the 5-tuple hash to spread traffic, and support single-stream bandwidth much lower than whatever aggregate they may advertise.