Commenti in evidenza

Free account, indefinitely, to whoever needs it to store this data … including the storage vendor. Just email…

> In 2001 Mark Probst implemented tail-call optimization in GCC That's me. The motivation back then was to allow compilers that target C to assume that tail calls will be "proper". That's different from an optimization, which is usually optional, and which compilers don't guarantee. The LWN post briefly sketches why this is hard: C allows variable-argument functions (like printf) where only the caller knows for sure how many arguments it passed, which means that only the caller can clean up the stack, unless the stack frame size is also communicated, which "normal" C calling conventions don't do. But when the callee does a proper tail call, the stack frame that returns to the callee is not the stack frame that the callee originally sent. This is explained in more detail in my thesis starting on page 16: https://hostr.flingit.run/s/proper-tail-calls.pdf

I got rid of mine for a year thanks to a comment on HN. The only reason it came back is because of my lack of discipline. It's bearable as I only notice it when I actively listen for it now. Anyway, I am sure this would just work again. So there was a comment that claimed it was related to bad neck posture. Being a keyboard warrior in my late 30s at that time I suffered the same issue: Tinnitus and generally bad posture. I figured that even if that wasn't true, working on my posture might be a good invest either way. So a couple of YouTube videos later I started working on it. Turns out the process to straighten your neck - even after like three decades - with just some casual invest everyday only takes about a month or two. To my surprise the tinnitus was actually also gone. As I haven't build a real habit around the exercises eventually a bad posture came back, and so did the tinnitus. Both are generally not as bad as they were before, though. 10/10, would do again.

I ran a few research tasks at JPL, small dollar studies. We'd often recruit part time work from engineers around the lab through informal networks, (instead of the official channels that segment by "specialization"). One year, one of the developers on my task was the apparently last person who could encode the command sequences for Voyager 2 (hoping memory serves me correctly - event though it was only 8 years ago). She would occasionally come late to meetings because they were dealing with some trouble with the old satellite. Pretty amazing how little is set aside for these projects that most the staff keeping it alive have "day jobs". I hope she's still uploading

This kind of observation is a big deal for solar physics. It's been believed for decades that these small-scale (~100km and below) turbulent features are critical to understanding how energy dissipates in the Sun. And thus, how sunspots and flares form. The subject has been very qualitative but is yielding on both observational and simulation fronts. I worked adjacent to this area from the 1990s-2010s, and it had been true that MHD numerical simulations of significant volumes of the Sun (but at a scale fine enough to resolve these features) were not possible. That has obviously changed! Additionally, it had been that the best solar observatories could not quite resolve these features. In the late 1990s some of the best images came from a couple of observatories in the Canary Islands (e.g., the 1-meter Swedish telescope -- https://svs.gsfc.nasa.gov/4715/). The spatial resolution was perhaps in the ~100km range. Of course, these are absolutely mind-boggling images. You're looking at a slice of the solar photosphere that has a temperature such that it activates a spectral line around 400nm. By isolating that wavelength, we can see what's happening at that temperature, and thus, sample a slice of the photosphere. So, that had been the state of affairs. Now DKIST (4m aperture), with the particular instrument highlighted in OP, appears to be at a spatial resolution ~5x finer than the above imagery -- see Fig. 1c in the Nature paper (https://www.nature.com/articles/s41586-026-10871-3). It appears also (https://dkist.virtualsolar.org/vanNoortfastcam/) to be observing at 740Hz (!) for speckle reconstructions at ~1Hz. At this scale, vortices of the flow are well-resolved -- where before you just resolved the convective cells but not the turbulent features around them. It's these turbulent features that are transporting energy. To contextualize with respect to a HN perennial topic: DKIST (commissioned 2021) is funded by NSF, from the same pile of money that once funded Arecibo (up to 2020).

This is beautiful work! First, I thought this would involve using PCA to go from 3D to 2D, which would result in an easier selector to use, but at the expense of representing every person. Then, I thought this would stop at using the U-space vectors (the ones that form the basis of the PCA image) and their corresponding ellipse to form our color space, but no, the function fitting is a very slick idea, even if it was executed by hand. Lastly, I love the presentation of sampling from different r values. Whether you sample from a fixed r value or a range of r values, I bet this has great applications in game design or animation. I still don't quite get the manual data labeling process at the beginning? It seems like it would encode some bias, but the consistency of the first point cloud and the results certainly speak for themselves.

Oh, this again. I should put a website with this up... I was the person who personally ran 10.6 security updates at Apple (10.6.1+), the "DRI". My team in the Updates Program office and I reviewed every single bug to determine if it should go in a security and stability update or wait for the next major version. Seriously, every morning we group triaged all Mac OS X bugs, both incoming and those nominated internally for us to look at and determine if it should go in an update. I packaged and audited the builds and tuned the delta vs full updates. I built the system that largely automated diffing "trains" for software updates (automastering). The new version of the OS was always being developed in a branch/train, and fixes were backported to the current version as they were found. They weren't developed linearly / one after another. So, if you are comparing the most stable polished/fixed/stagnant last major version with the brand new 1.0 major version branch, the newer major is going to be buggier. That would be the case with every y.0 vs x.8. But if you are comparing major OS versions, Snow Leopard was different. Snow Leopard's stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don't believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up "here is what we are planning to ship" and in Snow Leopard it was top down "can we ship this?". AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs. The first .1 or .2 ALWAYS fixed critical bugs, because: 1. You had to GM / freeze the software to physically create the CDs/DVDs around a month before the release. Bugs found after this process required a repress (can't remember the phrase we used), which cost money and time and scrambled effort at the last minute and added risk. This means the bar was super high, and most "bad, but not can't use your computer bad" bugs were put in software updates...which was developed concurrently with the end of the main release (hence why .1 came out right away) 2. Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn't even the complete OS that was being tested. Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.

It should be relatively straightforward to imagine — we already have that in gasoline-powered internal combustion engines. The Watt-hours per kilogram of good Lithium Ion batteries is around 250-280 Wh/Kg; for Lithium Iron Phosphate it's about 180 Wh/kg, and for Sodium-Ion about 170 Wh/Kg. The raw energy in gasoline is about 12,300 Wh/Kg but automobile internal combustion engines get only about 20-30% efficiency yielding about 2500-3600 Wh/Kg. For aviation piston engines it is a bit better at 25-30$ so 3000-3600 Wh/kg. So, the batteries, instead of being 10-12X the weight of the gasoline for the same net driving/flying range, could weigh about the same as the gasoline. So, a typical car with maybe a 16 gallon tank and 30 miles per gallon fills up with 128 pounds (58 kg) of gasoline to get 480 miles of range. The Li-Ion battery for that range would weigh something like 1300 Lbs (590 kg). That is a substantial additional weight for a car that could be 2800-3800 Lbs in ICE configuration, so 35-45% added weight (a bit less because of savings on the ICE engine, etc). This requires everything else to also be heavier, from the structural frame, the suspension system, and even the wheels and tires (which is also unsprung weight, further impairing performance). With a 130Lb/60kg battery instead, and saving the weight of the ICE engine and fuel system, the overall car design could go much more lightweight, regaining a lot of performance and range, all while gaining the huge torque of electric motors. In aviation, a battery systems of that weight would enable all-electric aviation to go from small performance niches to the default for general aviation. So yes, it would be a HUGE benefit to achieve 10X energy density batteries, and we do have reference points for people to imagine it.

Something I learned awhile ago is that most people that I consider "celebrities" really aren't that famous, and as such are generally pretty happy to respond to emails. In ~2014 I sent an email to Joe Armstrong (one of the creators of Erlang) asking some questions about concurrency because I still didn't fully understand why Erlang was supposed to be better for it. I expected him to just point me to an FAQ or simply not respond [1], but instead he wrote a very long, detailed explanation about the rationale of Erlang's design. It was well-written and it made a lot of things "click" in my brain. That simple act by Joe was extremely instrumental in my career, I think for the better. I became very interested in Erlang, but also just concurrency theory and distributed systems, and I would like to think I almost understand it now :) He and I would exchange emails occasionally over the next few years and he seemed genuinely enthusiastic about programming, Erlang, and people using it, and despite me barely knowing the guy, I was genuinely pretty sad when he passed away in 2019. I think about that a lot; if I hadn't sent a dumb cold email my entire life would likely be very different. [1] Which, to be clear, would have been perfectly fine!

I can’t speak for other startups, but I applied to the most recent YC batch with my idea for making AI proactive instead of reactive, and pre-being selected I’ve published a paper on recursive self-improvement mapped to the Epoch AI data. I contacted a professor from a university in the UK and he responded since he was working on similar work, then asked me if I wanted to meet with him. We talked for about an hour since we had overlapping results and different methods, specifically different assumptions. I say all that to say, as a physics student getting my undergrad, simply doing independent research and speaking to experts about it enabled me to network with someone I otherwise likely wouldn’t know. For young people getting into any business, research is a great way to meet new people.

I had an argument with Steve Jobs about pie menus at the Educom conference in Washington DC, October 26 1988 -- right after he finally shipped NeXTSTEP (people had been teasing it as vaporware with "NeVRSTEP" t-shirts). I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth. Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling: "That sucks! That sucks! Wow, that's neat! That sucks!" Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me: "I don't need flexibility -- I got my window system right the first time!" Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted. So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged. More context from that week: https://news.ycombinator.com/item?id=17098824 Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version) ...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ". Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard! HyperTIES founders storyboard: https://donhopkins.com/home/ties/emacs/founders.st0 Bill Joy's Head Target: https://donhopkins.com/home/ties/emacs/obj/founder.curly.tn0 NeWS PostScript pop-up target class: https://donhopkins.com/home/ties/target.ps At least it wasn't RMS, who would have immediately objected strongly to the "Evil Software Hoarder" version of Emacs I was using. Here are some examples of not-locked-down NeWS user interfaces: HCIL Demo - HyperTIES Browsing: https://www.youtube.com/watch?v=fZi4gUjaGAM HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS: https://www.youtube.com/watch?v=hhmU2B79EDU Just the Pie Menus from All the Widgets: https://www.youtube.com/watch?v=mOLS9I_tdKE Ben Shneiderman, Don Hopkins, and pie menus in Spring 1989 on a Sun Workstation, running NeWS: https://www.youtube.com/watch?v=8Fne3j7cWzg Nelson Spins Pip While Emacs Watches: https://www.youtube.com/watch?v=aRaD5zH3Qdg (Oops that was a different Emacs, my cat.)

I actually asked Dr Colmerauer once if the original program code had survived, but sadly he did not believe any of it was still around.

When I was in grad school, I had the opportunity to take a course from my adviser in which he discussed his current research and some open questions. It was a relatively accessible subject area and the questions were sometimes easy enough that we could meaningfully contribute. On one particular Friday afternoon, he stated a conjecture that he hoped was true, and invited us to try to help him prove or disprove it. It was the sort of thing that he really wanted to be true; he liked things smooth and beautiful. I, on the other hand, hoped it was false as I like the weird and exceptional in mathematics. It was also the case that I had absolutely no command of the sort of machinery that one would use to prove such a thing, but I could certainly look for a counterexample. I learned on Monday that he had spent the entire weekend trying and failing to prove it. I, on the other hand, had put all my energy into finding a counterexample and had one within an hour. My single (quite small) contribution to mathematical research was a counterexample because it was all I could do. The story does illustrate that it can be helpful to have people with different tools, hopes, and motivations working on a problem, though. I was not, and will never be, even a shadow of that great mathematiciam I studied under, but on that occasion, I had reason to look in a different direction than he did.

> The Jacobian Conjecture Interestingly, Yitang Zhang of the twin-prime-conjecture fame spent 7 years working on the Jacobian conjecture under the advisor Tzuong-Tsieng Moh at Purdue. A key step in his thesis used a corollary of Moh's. It turned out that the corollary was incorrect. As a result, Moh refused to write any recommendation letter for Zhang, and Zhang couldn't find any teaching or research job and ended up spending years working at a Subway[1]. Imagine Zhag had ChatGPT in 1986 when he started working on the Jacobian Conjecture. [1] Of course now this has become an inspiring story. That said, the story definitely invokes complex emotions. The best way to describe it is probably this Chinese poem, which I have no idea how to translate: 庾信平生最萧瑟，暮年诗赋动江关

If you lay a yardstick from fully desaturated white to maximum perceivable green, you’re effectively seeing #119911 even if you’re looking at a green quantum dot #00ff00 LED, because the color green can also be seen by your eye’s non-green receptors a little bit too. The green in ProPhoto RGB is shown at a ‘distance’ from the other colors that’s impossible for human photoreceptors to perceive (let’s say it’s #00bb00), because there’s no way to trigger our green receptors at such a severe distance from white — they can’t differentiate greens beyond #009900 — without our perception also mixing in some of the other colors (result: #119911) due to those receptors being analog-curve-blended rather than sharp single-frequency cutouts like quantum dot, sodium lights, or laser emission spectra. So no matter how strong a green you emit in reality, it can never reach when perceived the depth of green that ProPhoto RGB represents, because the eye can’t perceive #00bb00 green as being different from #009900 green, and it can’t perceive any intensity of green as #00gg00 rather than #11gg11 without optical illusions or other fun tricks like shooting your green ‘M’ receptors with pinpoint laser beams: https://news.ycombinator.com/item?id=43741013 So, the upside of having three overlapping curves is that we can distinguish different shades of similar colors with much higher accuracy, but the downside is that we cannot see undiluted green or blue. Human tetrachromats, theorized to have a fourth receptor at +/-yellow, would in theory be able to differentiate colors even more strongly, peaking at that +/-yellow versus red/green; but, perhaps, they might(?) lose a bit of the ‘imaginary’ three neon CMY colors that we synthesize from that overlap (for example #ffff00), in exchange for gaining six? new ones (#00ff00ff?). I need to consider 4-D rhodopsin interactions for longer than this comment’s edit window to be more certain of that implication :) DxO created a wide color space a while back that they fit better to human receptor sensitivity than ProPhoto, and while I’m not qualified to judge whether it’s Better or Worse, their explanation of how they constructed it around Pointer’s Gamut — someone sampled actual real world objects to see what the strongest colors we can see in earthly reality are! — provides some very precise images showing ‘the strongest color distances we can find from white on real life objects’ versus ‘the strongest color distances from white that sRGB and ProPhoto RGB can represent’: https://www.dxo.com/en/news/white-paper-wide-gamut/ (heading “How we designed”) This post also does help explain in depth why having ‘impossible’ color spaces is helpful for digital processing: It lets you manipulate photos without color truncation (do your intermediate math in double-float), and then when you’re ready to ‘land’ the photo back into reality — either on sRGB, or Dosplay P3, or HDR10, or Kodak film negatives — you can control how that inevitable rounding-off of the impossible colors occurs (store the final result in half-float). Do you want to prioritize eye-searing color or preserve the fine gradients of hue, in your photo of a flower petal? There is no single correct answer, but if you do your work in ProPhoto, you’ll have the option to preserve those gradients (or to convert them to luminosity gradients!) that you would lose if you’d done your work in a more limited colorspace. Hex code nitpicks: Colorspace pros, I acknowledge that RGB hex codes are wildly incorrect to use here, not the least of which because they encode luminosity and hue when I’m just using them as hue above, but also because they’re wildly incorrect to mix with modern color spaces. This is done solely for analogy purposes and supports the curiosity basis of colorspaces 101; those who wish to learn more are welcome to — and join us in being grumpy about web hex codes and colorspaces :D

Yeah. Stuff happens. There is the famous case of dropping the NOAA N-Prime weather satellite on the ground. They were trying to turn it from vertical to horizontal and they forgot to bolt it to the adapter. Worse: multiple people signed the paperwork attesting that they verified that it was bolted down correctly. Pictures and details here: https://spaceflightnow.com/news/n0410/04noaanreport/ Or the famous “space aligator” event. There the original plan was to launch a manned space craft and an unmanned module to do a docking test between them. But the shroud protecting the target module didn’t deploy properly. If i remember it right because the man who usually assembled that part had to leave during assembly because his wife was giving birth. Someone put it together but appearantely not correctly. The half opened shroud reminded the astronauts to the jaws of an angry aligator hence the name. Pictures: https://www.nasa.gov/missions/gemini/gemini-ix/gemini-ix-cre... Or to not only list American failures: this russian satelite launch failed spectacularly because the IMU was installed upside down. https://youtu.be/ycRVAcZC5R4?si=LRTS7sutKSp6HnGs This was designed to be impossible to do, but someone bent and forced the component to stay in place in the wrong orientation. Then someone else whose job was to check it just signed the paperwork without climbing into the location where he could have checked it. I love these cases. Because it shows to me how even though the trappings of high-tech we are all fundamentally just occasionally lazy, occasionally distracted monkeys banging rocks together.

Hi, I'm Robert Standefer, the guy who made this happen, with lots of support. I'm excited to see the enthusiasm about Comic Chat being open sourced. How this came to happen is a very interesting story that spans a six-year period with success that hinged upon being in the right place at the right time, literally. I want to point out that, while I (along with Scott Hanselman) made the Comic Chat open source release happen, I am not the original developer. That is DJ Kurlander, and he was very supportive of this project. He was even enthusiastic about it.

I worked on the ARPANET project under Steve Crocker at UCLA and met his bud Vint there (with his ever-present 3 piece suit, briefcase, and hearing aids) ... what a great guy. An anecdote: I wrote a program (in Sigma-7 assembler I think) to play Jotto--a bit like Mastermind but with 5 letter words. Vint loved to poke around in people's directories to see what they were up to and found my program. He played it a few times, and then collared me to ask me a couple of questions: 1) It seemed to know some of the words he entered but not all -- what was up with that? 2) What sort of AI algorithm was I using for the program to make guesses? (It usually beat the human player.) Answers: 1) I didn't have a digitized dictionary (it was 1969!) so I hand-entered the five letter words from a pocket dictionary but got tired halfway through so it only knew words starting with a-l. 2) The program would eliminate any words that didn't fit the responses to its guesses so far and then pick a remaining word at random. Upon hearing my answers Vint walked away in disgust! But years later he gave me a recommendation when I interviewed with Google (it didn't work out for other reasons). I also shared a cubicle wall with another Van Nuys High alumni, Jon Postel, aka "God of the Internet". Sartorially, Jon was the complete opposite of Vint--long scraggly beard, blue jeans, forever barefoot--but those weren't the things that mattered. Man, those were the days.

I interviewed him a few times, when I was a tech journalist in the 90s - a very impressive man. However I never forget my surprise, Idly flicking through TV one evening and coming across Earth Final Conflict - and there was Vint in a fairly substantial role

You may be relived to know that Unix epoch time does not have this problem. But you may also be horrified to know why. First, epoch seconds are not the numbers of seconds since 1970/01/01. This is a lie we tell to children. Rather, epoch seconds are the number of days since 1970/01/01 * 86400 plus the number of seconds since midnight. Leap seconds, to epoch time, don't exist. Or maybe they are double counted. Or maybe we smear them over 12 or 24 hours (but which 12 or 24 hours depends on whether you are Google, Microsoft, or Oracle; I can't even make this stuff up). The point is, it's not defined, and this means implementations do it differently. A negative leap second might be easier though. The spec suggests (though lack of speaking) that a correct implementation will just skip it since number of seconds stays less than 86400 for that day. But of course the smear-organizations still smear it. So what if you really want to know how many seconds were between two different epochs? Subtracting epoch seconds is wrong because you need to correct for the number of leap seconds between the two times. And the smears.

I grew up on a farm on which the apiary and all connected with it was a major part of the farm's output. Honey, beeswax, nukes (a queen and 10K or so worker bees as a starter colony, sold to other apiaries in the spring if they'd had too many winter losses), fertilizing services (drop a couple colonies off at a berry farm after dark, pick the colonies up two weeks later, profit!) and other products. It's been over ten years since I spent any serious time with bees, but the bees themselves did a great job on the varroa mites. Sentinel bees at the hive entrance would pick the mites off the incoming bees. The problem was if the colony had a solid floor the mites would just climb back onto the next bee that passed nearby. If the solid colony floor was replaced with a mesh, the mites would fall through to the ground below while the bees could still go about their business. We would still sometimes treat for varroa, but making it easier for the bees to handle varroa how they had evolved to was the first line of defence. This was Canada, regular Italian bees, hard winter kills of whatever wasn't properly winterized.

The cartridge heads have a super curious digital protocol - the cartridge electronics have no power supply. There is no power rail internally either. Instead they use the fact mosfet gates have capacitance, and can therefore store 1 'bit' of information. Through a network of hundreds of MOSFETs, the right bits can be put on all the nozzle gates as needed, and then a 'fire' pulse is sent which for around a microsecond turns on a tiny heater (or not, depending on mosfet gate state). The heater boils some ink, making a pressure wave which travels down a pipe and makes a drop of ink fly out towards the paper. That heating and cooling again can happen around 10,000 times per second per nozzle (and there are ~300 nozzles). I suspect this decision is because the custom silicon process needed to manufacture these nozzles is cheaper if they only have n type MOSFETs - and without p type MOSFETs you can't make a typical push pull logic gate. The nozzles themselves are quite a lot of silicon - perhaps 100mm^2, with deep etched holes, and are effectively disposable, so I assume huge efforts have been taken to reduce costs - including this curious electrical design. The protocol also is hugely irregular, which I suspect might be to avoid any wires on the chip needing to cross eachother.

I'm not a handgun expert at all but I've caught a few of these, like the guy who racked the slide on his revolver. The author who really impressed me, although not with his handgun knowledge, was Tom Clancy. I was in the anti-submarine warfare business in the 1970s and some of what he wrote in Red October I only knew from classified sources.

I built one of the connected tools included in this launch (the Biomni HPC [1]), and I have spent an inordinate amount of my life working on this problem. (I also worked at Anthropic, but not on this product.) As other comments have pointed out, this is for data science – but it's capable of more than making plots and writing papers [2]. It has integrations with many databases and computational tools, including a researcher's institutional cluster. That alone is valuable. I founded a startup after struggling with this problem at a bio startup; integrating these tools and databases is hard and time consuming. If the only outcome of this product is that great APIs are built for LLMs, it will be a massive positive impact. Many databases used in computational genomics are still only accessible through FTP! LLMs are particularly good at navigating these tools and databases. It's often very specialized, but straightforward, work that benefits from in-context skills. Seeing an early glimpse of my former customers – bioinformaticians – using LLMs to solve this problem is what led me to join Anthropic in 2024. Also, this pattern isn't fundamentally constrained to data science: you can also integrate with a wet lab or a CRO for some kinds of science. This is what I'm spending my time on now. This type of science doesn't solve everything, but it's useful in some niches. For example, progress on many rare diseases is bottlenecked by researcher attention rather than a fundamental breakthrough. [1] https://x.com/phylo_bio/article/2029233694775624096 [2] In comparison, OpenAI's science product – Prism – was effectively a LaTeX editor they acquired with Crixet.

I know less about the airframe differences across the -400 and -8, but I can say the 747-8 represented a major upgrade in Flight Management Software. I re-wrote the Central Maintenance System (portion inside the FMS) in C from scratch because no one had the original detailed design documents. The original -400 code was written in Pascal if I'm remembering correctly. I gleamed what I could from the source and relied on unit tests to get the rest of the way there based on what I knew of the protocol itself. The entire FMS software was completely re-written in C++ and using modern object oriented patterns (at the time). Probably the most fun I've had over my now 20'ish year career. Of course Boeing was pissed with the delays this caused because the airframe wasn't a major change. I'll quote a Boeing (from MD originally) executive as saying "Meeting this project deadline is more important than your child dying." Sadly this was also the time I remember Boeing's engineering ranks began to thin out. Personal opinion, this was a large part of what led to the MAX situation.

About 11 years ago, I cold-emailed Om for his guidance. I was an absolute nobody, living thousands of miles away. Not only did Om patiently explain how I should think about my career, he kept in touch over the past decade checking in on how I was doing. I left journalism last year to do something else -- coincidentally, again, following Om's footsteps -- and had been meaning to write a long email, sharing so much. I deeply regret missing the chance to have another conversation with him. Om has been deeply impactful to my journalism career and beyond. He was way too kind and leaves a big vacuum.

I used to work at two (UK) telcos. There's a historic reason and a modern reason. The historic reason was, just like the Internet, the international phone network was built on gentlemen agreements by engineers who largely trusted each other. A big national telco is unlikely to attack its peers, so there was little need for safety measures. As smaller telcos came in to the mix via deregulation, that understanding changed - but it was hard to retroactively fit controls. The more modern reason is outsourced call centres. You want outbound calls from your Philippines based staff to show as if they were calling from a local number. When large and reputable entities were doing this it was fine. Just like showing a different reply-to address on an email. If you were designing a modern network, it wouldn't be like this. But international telephony is over a hundred years old and has a huge amount of legacy technology and legal agreements.

When I was in highschool I started writing a game in Qbasic. Along the way, I wanted it to have a console (like Quake) where you could enter commands and modify the game as you were running it. This lead me to create a scripting engine in Qbasic, and long story short, I’ve been on a yak shaving epic quest now for almost 30 years now. No game, but I have a hybrid C / Lua game engine/general purpose application platform. Still tinkering and still no end in sight. I’m having fun though!

I had to take down two absolutely enormous Douglas Fir trees on my property (> 36" base), and asked them to leave the wood rounds for me. I knew it was going to be a lot of wood, but even then, I was not prepared. I spent about a fair bit of my free time over the next 1-2 months just out there slowly working my way through the pile, and you're absolutely right - you get substantially better at it. For me, it looked something like this: Stage 1: At first, I could chop essentially nothing, probably 60+ minutes per round as I mostly puzzled about how to make progress and got lucky from time to time with a round that split easily (fortunately, I had a nice splitting axe) Stage 2: Then I bought some splitting wedges, and I used a handheld sledgehammer to drive them in to what I thought were the weak spots, and then ultimately pried open the log, to pieces that I could split more readily. Stage 3: I bought a massive demolition sledge hammer (essentially a two-handed battle hammer) and used that to drive the wedges in after getting them started, and made a bit more progress on actually splitting the rounds. Stage 4: After doing this countless times, you just a knack for reading the wood, and where it will / won't split. I reverted back to using just the splitting axe, since if you hit the wood in the right spots, it really just splits on its own. Here's where I ended up, if it helps any of you: - Start by establishing the fracture line that will be used to split the round in half. I would eyeball any existing line on the round towards the center, and use the axe head to mark a line, away from any knots , from the center to the edge. These two center-to-edge didn't necessarily need to be inline. They could be slightly offset, like hands on a clock. - With moderate force, just repeatedly strike that line, working from the center outwards. You'd be shocked out how quickly repeated strikes widen the line, and eventually the wood's own weight almost causes it to fall apart. - Recursively do this with the two halves: Draw the line from (what was the center), radially out to the edge. Repeatedly strike until these pieces have been halved. - Continue this process until you have proper pizza wedges. At this point, it's pretty trivial to just chop the pizza wedge, from the wedge to the base, into 4 or 5 smaller firewood-sized logs. I know y'all probably didn't care to read this, but this was quite honestly weeks of my life in learning this, and I couldn't find a great guide on YouTube or anything, especially for rounds this big.

Back in 1984, I wrote the original "obvious password detector".[1] It just checks whether a password has English language trigram stats. This prevents dictionary attacks. Everything is so much more complicated now. [1] https://www.animats.com/source/obvious/obvious.c