mhandley

Here's a pretty complete list of UK brands: https://moralfibres.co.uk/the-teabags-without-plastic/

Unfortunately the best of them is 1080p.

In honor of today's XKCD https://xkcd.com/3017/

Yes, I think it is quadratic. I don't claim it's practical (the original isn't practical either though), but just that the dependency on filenames isn't fundamental.

You could do the same spitting trick but only split at progressively increasing file lengths at the character '5'. The "compression" would be worse, so you'd need a larger starting file, but you could still satisfy the requirements this way and be independent of the filenames. The decompressor would just sort the files by increasing length before merging.

It's already happening. For the more demanding workloads such as AI training, RDMA has been the norm for a while, either over Infiniband or Ethernet, with Ethernet gaining ground more recently. RoCE is pretty flawed though for reasons Ousterhout mentions, plus others, so a lot of work has been happening on new protocols to be implemented in hardware in next-gen high performance NICs.

The Ultra Ethernet Transport specs aren't public yet so I can only quote the public whitepaper [0]:

"The UEC transport protocol advances beyond the status quo by providing the following:

● An open protocol specification designed from the start to run over IP and Ethernet

● Multipath, packet-spraying delivery that fully utilizes the AI network without causing congestion or head-of-line blocking, eliminating the need for centralized load-balancing algorithms and route controllers

● Incast management mechanisms that control fan-in on the final link to the destination host with minimal drop

● Efficient rate control algorithms that allow the transport to quickly ramp to wire-rate while not causing performance loss for competing flows

● APIs for out-of-order packet delivery with optional in-order completion of messages, maximizing concurrency in the network and application, and minimizing message latency

● Scale for networks of the future, with support for 1,000,000 endpoints

● Performance and optimal network utilization without requiring congestion algorithm parameter tuning specific to the network and workloads

● Designed to achieve wire-rate performance on commodity hardware at 800G, 1.6T and faster Ethernet networks of the future"

You can think of it as the love-child of NDP [2] (including support for packet trimming in Ethernet switches [1]) and something similar to Swift [3] (also see [1]).

I don't know if UET itself will be what wins, but my point is the industry is taking the problems seriously and innovating pretty rapidly right now.

Disclaimer: in a previous life I was the editor of the UEC Congestion Control spec.

[0] https://ultraethernet.org/wp-content/uploads/sites/20/2023/1...

[1] https://ultraethernet.org/ultra-ethernet-specification-updat...

[2] https://ccronline.sigcomm.org/wp-content/uploads/2019/10/acm...

[3] https://research.google/pubs/swift-delay-is-simple-and-effec...

> Or why no EU company came up with an OS that could fight Mac OS or Windows.

They sort of did. For a while Symbian had two thirds of the smartphone OS market. And the real winner in the global OS marketplace today is Linux (I'm including Android here, though you could debate that), which started out life as European. But I do agree about investment opportunities.

RFC 791 which defines IP talks about both packets and datagrams. IP sends datagrams. Each IP datagram is fragmented into one or more packets depending on the underlying L2 network.

But RFC 791 dates from when the underlying L2 network was most likely ARPAnet, which had 128 byte packets. Today the distinction is (or should be) moot - if you're relying on IP fragmentation to send your large IP datagram over multiple L2 packets, you're doing something wrong. IPv6 doesn't even support in-network fragmentation.

In practice, the distinction has largely disappeared over time. Everyone I know talks about packets and very rarely bothers to distinguish between frames, datagrams and packets, because in practice one Ethernet frame generally carries one IP datagram, and everyone calls it a packet.

Yes, it was a poor choice of name. It was originally just a placeholder in the htsim code, from New Datacenter Protocol, but we avoided choosing a better name for too long and had already talked about it as NDP to enough people (especially research funding people) that we decided it would be confusing to change. With hindsight, we should have changed it earlier. Later on we did change the name of its derivative to EQDS.

It's taken a while for spraying and trimming to go from being a crazy research idea to mainstream in UEC, but if you're interested, the old animations from my Sigcomm 2017 talk still give the general idea: https://www.youtube.com/watch?v=BO0QhaxBRr0

In addition to what is in the video, UEC introduces a new libfabric-based transport layer and a new congestion control scheme. Plus a bunch of stuff at the lower layers like link-layer retransmit. Hopefully the specs will reach 1.0 around the the end of the year - unfortunately at the moment you can only get them if you're a member of UEC.

Broadcom also builds xPUs for Google, Meta and Bytedance. Maybe these companies know a thing or two.

That's mostly an British English vs American English distinction:

https://dictionary.cambridge.org/pronunciation/english/lieut...

https://dictionary.cambridge.org/pronunciation/english/straw...

Meta is already in the chip design business, albeit in collaboration with Broadcom who build it for them: https://ai.meta.com/blog/next-generation-meta-training-infer...

The article talks about NVidia racks, but also about their DSF [0], which is Ethernet-based (as opposed to Infiniband) built on switches using Cisco and Broadcom chipsets and custom ASIC xPU accelerators such as their own MTIA [1] which is built for them by Broadcom. So they are talking more than one approach simultaneously.

[0] https://engineering.fb.com/2024/10/15/data-infrastructure/op...

[1] https://ai.meta.com/blog/next-generation-meta-training-infer...

Yes, it was a big deal when I was in school in the 70s. Everyone played. There were never any conkers left unclaimed under any Horse Chestnut within a mile of the school. We all tried lots of tricks - soaking in vinegar, baking in the oven - practically anything was allowed, but I'm not sure any of it made a difference. It could be pretty painful as getting your hand hit by a high speed conker was common occurrence, but I don't recall anyone getting any lasting injuries.

My daily cycling mostly consists of a mile and a half to the station each way without any serious hills, but my station bike is one we got second-hand for my brother when he was a teenager back in 1980 or so and we repainted it back then, so it's probably over 50 years old. It is the scruffiest bike in the bike shed at the station, which is just the way I want it. But most importantly, just about everything on it still works. It was once a racer with a lightweight steel frame, but I put straight bars on it 20 years ago. It lives outside year round and has done so for 25 years, so it has a nice patina that means thieves always look the other way. A little rust converter every now and then ensures the corrosion looks much worse than it really is. The original pedals finally fell apart a couple of years ago, but replacements were readily available. The front derailier failed and I removed it, so it's a 5-speed now, but that is fine for my use. The saddle has been replaced many times. And the rear wheel needed replacing twice. But it's still on the original chainwheel (!), brakes, rear derailier, shifter and remarkably, front wheel. Headstock bearings and bottom bracket are original too. Anytime I have needed something, the local independent bike shop has it - all the parts are still available.

Alongside it at the station are so many nice looking bikes, but chances are mine will outlive all of them and not get stolen either. Anyway, if you're getting a bike as transport, get yourself something used from way back that was a high quality bike back then. Some of them at least were built to last, they're easy to repair, and are still way lighter than most modern bike shaped objects.

That's true, except it neglects the cost of the launch tower itself. If you botch a catch and need to rebuild the launch tower, that could get very expensive, both in immediate costs of rebuild, plus in opportunity cost of missed launches. So in the end, whichever has the lowest wind limit, launch or landing, will likely determine whether they fly.

As to whether catching the booster adds risk - I'm not sure it does.

First, to the extent the booster is out of position in the x (sideways) direction, the chopsticks can move to accomodate error. But actually I think this dimension is the easiest of the three, as the booster has plenty to time to null any error in this dimension.

In the y direction (direction of travel towards the tower), the rails on the chopsticks can cope with the booster touching down along quite a long distance. But importantly, they appear to be smooth, so the pins can initially skid along them and then the booster can swing if it has not fully nulled any horizontal movement. In contrast, if the booster used legs and has not yet fully nulled any horizontal motion at touchdown, there is a greater risk of breaking a leg or simply tipping over.

And in the z direction, it should be possible for the chopsticks can absorb more vertical motion than legs can absorb, because you can easily build in huge springs/dampers/etc into the ground equipment without concern about mass.

Catching also puts the booster in tension rather than compression - it's easier to be rigid in tension than compression.

Finally, if legs were used, the engines would have to get close to the ground during landing, so reflected shock from the ground could cause damage. I know Falcon 9 does this, but the area of the base of Starship is much greater, so there's effectively less room for the reflected energy to escape. Catching completely removes this risk.

On balance, I think they would have better chance of success for each mission by catching. The main downside would be if you fail to catch, you may need to build a new tower, whereas a flat pad would be cheaper and easier to repair.

Things can only be cheap if you mass produce them. That tends to require standardization of components, and inevitably standardized components are a compromise between requirements, where up until now, saving mass was a critical requirement. If you don't have to care nearly so much about mass and volume, then that opens up many avenues for much cheaper standard satellite components.

The Nobel prize cannot go to a team so they have to pick individuals. This is true for many (most?) nobel prize awards. Consider for example the discovery of gravity waves - the team that built and operated LIGO was huge, but they have to pick. This has commonly been the case since the inception of the prizes - the professor gets the prize, the PhD students and postdocs don't usually. Not saying this is right, but it's the way it is.

Who is "they" here? There are completely separate committees for each subject's Nobel prize.

Edit: the individual committees are even not all run by the same institution [0]. The medicine prize committee is run from the Karolinska institute, whereas the physics committee, for example, is run by the Royal Swedish Academy of Sciences.

[0] https://www.nobelprize.org/the-nobel-prize-organisation/priz...

Back in the early 1980s when I was maybe 15 I got one of the first Jupiter Ace computers. The Ace never sold well, so there wasn't a lot of software or hardware available, and even if there had been I didn't have the money. My school didn't offer computer science, so I arranged to cycle across town to another school that did. They had just got two Research Machines 380z's and were throwing out the ASR-33 they had previously used. Of course I scavenged it and took it home.

I'd previously built a parallel port for the Ace on veroboard from TTL logic, based on a design a friend of mine came up with for his ZX Spectrum, so I could use the Ace to ride around on a micromouse. To drive the ASR-33, I had a 24v smoothed power supply that I'd scavenged from a skip when my mother's employer had scrapped some prototype ATMs (cash dispensers), so I wired that up to give +/- 12V and switched that from one line on the parallel board using some power transistors desoldered from the ATM. Then I wrote code to bit-bang 110baud RS232 in Forth on the Ace. It took a lot of trial and error, as there wasn't exactly a lot of documentation available in the town library, but I got there in the end.

I'm not sure if I was the only person who ever had a printer connected to a Jupiter Ace, but I'm pretty sure I was the only person to print Ace code listings to an ASR-33. I wish I still had that ASR-33 but somewhere along the way my parents decided they were fed up with storing all my junk, asked what I wanted saving, and I didn't think to save that.

I'm not a fan of Drax (is anyone?), but I guess the alternative is worse, at least for now. In the short term, the marginal alternative is LNG, also shipped in oil-fueled cargo ships. So as we continue to build out wind and solar and reduce the amount of natural gas we burn, it's probably good to keep Drax on biomass. But it shouldn't be a long term solution.

The graph in the article makes clear that isn't really true. Around half of coal use was replaced by natural gas in the 1990s, as you say. That's still a win - same energy, but half the CO2 emmisions. But since 2010 or so, the remainder of coal use was largely replaced by renewables.

Now we just need to get rid of the remaining natural gas use. For electricity production, the trend here is pretty good. Natural gas won't disappear anytime soon, but there will be longer and longer periods where none is burned. But for home heating, I don't think gas will be phased out as fast as really needs to be done.

"Let’s consider a trivial example:

  struct {
      int a;
      time_t b;
      int c;
  };

With 32-bit time_t, the offset of c is 8. With the 64-bit type, it’s 12."

Surely it's 16 not 12, as b needs to be 64-bit aligned, so padding is added between a and b? Which also kind of makes the point the author is trying to make stronger.

Here's the full article, but turns out it isn't really any longer that you can see from outside the paywall: https://archive.is/jQtuc

I think that tile shape has one cusp-like corner and two ~90-degree corners. Thus it's not a complete transformation of a polygon into a soft cell, and hence the "at least two" rule doesn't apply.

I'm not holding wind to a higher standard - I'd rather have two pretty reliable sources whose downtime is uncorrelated.

Yes, Hinkley and Sizewell may be expensive - but they're unlikely to be that much more expensive than wind/PV plus enough storage to provide reliable 24/7/365 power. In the end, I'd much rather have some diversity in the system. If the choice was 100% nuclear vs 100% wind/PV, the answer would probably be different, but for 15% of the UK's capacity to come from a reliable (but expensive) source that is uncorrelated with wind or PV downtime, that extra cost seems to be a good investment to me.

There's a blast from the past - I had that book too and absolutely loved it. I'm glad I grew up in an era when a child had some hope of thinking they could understand all the technology around them (even though with hindsight, I know that knowledge was extremely superficial).