mhandley

Rocket Lab is growing into being a real competitor. They've been very innovative and successful in the small satellite market and, given what we've seen so far, I have confidence they will also succeed with Neutron which is their upcoming fully reusable medium-lift launcher aimed at supporting launch rates needed for megaconstellations. https://www.rocketlabusa.com/launch/neutron/

Concorde had 13 fuel tanks, but only four directly fed the engines, so they were constantly moving fuel between tanks. In addition, fuel was used to cool the aircraft structure because it got very hot from supersonic speeds. And fuel was also used to trim the aircraft pitch - if you were a little out, it increased fuel consumption, but if you were a lot out it would be uncontrollable. And of course all the changed constantly as fuel was consumed. So a key part of the flight engineer's role was managing fuel.

https://www.heritageconcorde.com/fuelgeneral

It took me a little while, because that blue line is definitely a distraction. But once the other holds all settled down to being properly in the plane and sharply focused, and I ignored the blue line, the misplaced one was clearly above the plane.

Thanks for that - five minutes well spent!

The problematic thrusters are in the service module, which separates and burns up on reentry. So even if it lands OK, they won't learn anything new about the thruster problem by recovering the capsule.

Unless you're a diver, it should be OK. I've never taken mine off for swimming or sailing and not had a problem in two years.

I have exactly the same watch for exactly the same reasons. With saphire glass and a titanium case and strap, it's very light and after two years of being worn constantly, it's still completely unmarked. It's also nicely inconspicuous - it's "just a casio", but those who know, know.

If it doesn't show for you in the README (it didn't for me at first), just click on demo.gif

If this were a manned launch, I would guess that unless the telemetry showed something very off, they would most likely have completed the full second stage burn. That would have left Dragon in a 190 x 205 km orbit, which is stable. If I understand correctly, SpaceX doesn't do orbit raising for Dragon by restarting the second stage engine (which is where the RUD happened on this Starlink launch), but rather uses Dragon's own thrusters to raise orbit. So most likely this would have been a successful flight.

On Starlink flights they don't have the margin to reach a full circular orbit on a single burn. It's more efficient to achieve an eliptical orbit initially, then coast and perform a second burn at apogee. It's that second burn that proved problematic this time.

Edit: having watched the videos, it would have been clear to SpaceX that they had an oxygen leak right from the start of the second stage burn. So I guess it depends on whether the pressures and flow rates within the engine looked OK. If the leak was external to the engine, then the main risk would be running of out LoX - engines really really don't like ingesting a gas bubble instead of liquid. If it looked like they were getting low on LoX, I'm sure they would have initiated one of the abort modes. Otherwise it's probably safer to continue to orbit. They do have cameras inside the tanks, in addition to all the telemetry - they have occasionally shown then on the livestream.

London also created Thameslink in the 1980s by linking existing suburban rail north and south of the city. It's not as fancy as the new Elizabeth line, but it did make a big difference to a lot of people commuting to the City of London, saving them the extra time of changing from rail to tube.

https://en.wikipedia.org/wiki/Thameslink

If you're going to design a taxi from scratch, why would you not make it wheelchair accessible? All newer London black cabs are wheelchair accessible. What a missed opportunity.

My son has a Seat Leon MK1 from 2002 and that uses coil-on-plug. The MK1 was released in 1999, so likely at least VW group were using coil-on-plug in the late 1990s.

A Jupiter Ace was my second computer, when I was 14 or 15, after a Sinclair ZX81. Great little computer, but compared to the Spectrum that came out around the same time, it had a worse keyboard, only black and white graphics and 3KB of RAM. Because it used Forth, you could do quite a lot in 3KB, but it was still a bit limiting. I think mine was a very early one, because it had some added soldered wires on the board, correcting some errors.

Mine got modified quite a bit over the next couple of years. Extra RAM. Some dumpster diving got me several keypads with good quality keys. I took them apart and made a proper keyboard to replace the original dead rubber monstrosity.

I made a parallel I/O port out of TTL logic and veroboard. And then temporarily my Ace rode about on the top of a fairly flaky micromouse exploring mazes. It didn't win any prizes but it did get me an A in O-level Technology.

My school was throwing out an old teletype, so I scavenged that. Then I modified the parallel I/O port to output +/- 12V on one pin, and wrote software to bit-bang RS232 at 110 baud. Back before the Internet, just finding the specs for RS232 was not so simple - our local library was a bit limited in that way - but I got there in the end. A lot of guesswork and trial and error. I don't think anyone made a printer for the Ace, so I may have had the only one. Being able to print code listings really helped.

The first summer I wrote a whole load of games, mostly in Forth, but sometimes Forth just wasn't fast enough. I got a copy of "Mastering Machine Code on Your ZX81", and learned Z80 machine code. If there was an assembler available, I didn't have it, so this was all hand-assembled. Getting jumps right was a total pain, as was debugging. Generally, it either worked first time, or you started from scratch again. Usually I got there in the end.

I sold those games through a ad in "Your Computer" magazine, and earned back the price of the computer several times. But recording and shipping tapes one at a time got tedious really fast, so I didn't take that any further.

Somewhere over the years, with my parents moving house multiple times, the Ace disappeared. Many years later, I found one on Ebay, and still have it. But somehow I never fell back in love with it - it just wasn't as good as I remembered my one rather non-stock one being at that formative time in my life.

Dialing by tapping the cradle switch to produce your own pulses was very useful once upon a time - it allowed you to bypass the dial lock that some places fitted to allow incoming calls only. Some people who shall remain anonymous got quite good at it.

Just because you cite a paper doesn't mean you agree with it. At least in CS, often you're citing a paper because you're suggesting problems with it, or because your solution works better. Cascading deletes don't really help here - they'd just encourage you not to criticise weaknesses of earlier work, which is the opposite of what you're trying to achieve.

Looking at the Tudor map, one thing that really stands out is how many abbeys and monasteries there were (shown in pink), and how much of London was taken up by them.

Also home to Tesla's Berlin factory, which accounts for around 1/4 of German EV output.

On the other hand, Meta just rapidly built two different training networks in existing datacenter buildings, with existing cooling constraints, using mostly commodity components (albeit expensive commodity components) each of which would place at #3 on that top500 list in terms of GPU power. Compare that with how long it took to get any of the other supercomputers from design to being fully commissioned.

Yes, that is correct - they need the header tanks to make sure that fuel is immediately available, not sloshing around the main tanks as the ship flips. Rockets really don't like sucking in vapour. I'm not sure if they're pressurized separately from the main tanks though - I would assume not, as that would be more complicated, but I could be completely wrong.

The fact that it managed the flip and landing burn means the fuel tanks (i.e. most of the fuselage) must have suffered no burn-through, despite what happened to the front flap. They've obviously got some redesign needed on the thermal protection around the flap hinges, but broadly, the thermal protection system and aerodynamic control during reentry seem to have worked well enough. It's finally starting to feel like Starship could actually work!

Also at T+57:20 or so, watching the front flap start to come apart: https://x.com/SpaceX/status/1798098040588480826

I had a Psion 3a - it fit in my back pocket and was strong enough it didn't break when I sat on it. I carried it everywhere and used it as my main device for taking notes in meetings - the combination of form factor and a usable keyboard was great.

Then I lost it and got a Psion 5 as a replacement. Despite the keyboard and software being way better, it was just that little bit larger and heavier so that I didn't carry it everywhere. It lived in my bag, not my pocket, so in the end I used it less.

So I switched to a Palm V, which was a wonderful light form factor and looked fabulous, but I found I didn't really use it at all, except as an address book. The lack of a physical keyboard made it basically useless for my main purpose.

In the end, I ended up with an ultra-lightweight Sony Vaio PCG-505 laptop, ran FreeBSD on it, added a Ricochet radio modem, and never looked back. Even 27 years later, I still think the PCG-505 form factor looks good, and at 1.3kg it weighed the same as today's lightest Macbook Air.

In my case, Tesla just don't make the car I want. If they made a hatchback variant of the Model 3 and gave it physical controls, I'd probably buy it. But I don't want a Model Y - it's ugly, I really don't want an SUV, and I'm not a fan of touchscreens in cars. But I've also heard from friends that they don't want to buy a car associated with Elon Musk, so perhaps that is also hurting their sales.

Yes, on the last flight both the first and second stages had no problems with the engines on ascent. If this were a Saturn V booster, it would have been a complete success. They did suffer failures with booster recovery, and with the RCS in orbit, but controlling large numbers of small powerful cheap engines seems to be a solved problem already.

I remember Van Jacobson saying in the early 90s that IP would work over two tin cans and a piece of wet string. For several years, I set this as a possible student project, partly as a joke, but it was had no takers for quite a few years. Then in 2009 a student finally took me up on the offer. The main things we learned were that the tin cans were a bad idea (undesirable resonances), and that you could either do on/off coding at the string's resonant frequency, or try to stay well away from the resonant frequency, but then the signal strength was very low but you could distinguish multiple frequencies so do more interesting coding. In the end the project was successful, but the student ran out of time before he could really investigate in great depth.

First time I've ever seen the aurora from West London - I always assumed the light polution would make it impossible to see, but here's a picture I took of it over the Thames: https://twitter.com/MarkJHandley/status/1789070802459000892

If the article is correct and it's a 737-300, then it's a very old plane built long before the recent Boeing issues.

I upgraded the UCL CS webserver to CERN/3.0 (the last CERN httpd release) running on a Sun Sparcstation 10 back in 1994, and it has been in production use ever since. The hardware got replaced at least once (our sysadmin has a large pile of spare mid-1990s Sparc hardware), and the NFS server storing the data has changed more than once, but it's the same software install still running on 1990s Sun hardware. It needed some minor patches for Y2K, but nothing in the 24 years since. Will be 30 years this summer. Needless to say as it predates SSL, it's no longer our primary server, but it does still serve everyone's home pages.

  % nc www0.cs.ucl.ac.uk 80
  HEAD /staff/M.Handley/ HTTP/1.0

  HTTP/1.0 200 Document follows
  MIME-Version: 1.0
  Server: CERN/3.0
  Date: Sat, 27 Apr 2024 22:06:54 GMT
  Content-Type: text/html
  Content-Length: 9973
  Last-Modified: Thu, 07 Dec 2023 13:26:26 GMT

As renewables started to increase, people were saying it wouldn't be possible to keep the grid stable once renewables reached 50%, due to the lack of spinning mass in fossil generators. That obviously has been proven wrong. If I understand correctly, they could have run without any fossil sources on a few occasions recently, but keeping some helps with grid stability. Next step is to reduce fossil fuels to zero for some short periods. But there will be some spinning mass still in nuclear and in biomass generation. Eventually the biomass needs to go too, but each step is good and not completely trivial to achieve.

Before we finalized the specs we did a lot of testing to make sure that enabling MPTCP wouldn't break connectivity. Either it would be passed correctly, or it would fall back to single-path TCP safely. Generally, so long as a middlebox passes through unknown options unmodified, and does not try to enforce that the TCP sequence space it sees is contiguous, MPTCP should work through that middlebox.

If you're interested, we wrote a couple of papers on this:

[1] https://www.usenix.org/conference/nsdi12/technical-sessions/...

[2] https://www.researchgate.net/publication/229002024_Is_it_sti...