Comment highlights

I have a Tim Curry-adjacent story. A family friend had a yellow ~73 Duster. Tim Curry autographed her hood in spray paint. This was back in the early Rocky Horror days - a live performance in NYC, I think. Everyone adored the signature. ff to mid 80's: She is leaving work. She gets to her parking space and sees that her hood is just yellow; the autograph is gone. She's staring in shock when the attendant walks up to her and says in a heavy Arabic accent: "I'm so sorry that happened to you. I scrubbed and I scrubbed all morning until I finally got it all off!" and is just beaming at her. Her shock hasn't let up any. She manages to squeak out a "Thank you" and leaves.

AI was always awkward! Long before I ever encountered Richard Wallace's AIML (which was quite unintentionally silly, but not actually a joke, unfortunately), around 1996 I wrote some joke web pages to parody VRML, announcing "AIML: Artificial Intelligence Marketing Language", by taking a couple of gushing articles about VRML, strategically replacing "VR" with "AI", and tweaking just a few words. The point being that the VRML hype back then was as bad as the AI hype right now (well maybe not QUITE as bad). I don't have a very high opinion of VRML obviously! They didn't bother integrating it with an extension language at the time, so it was useless. AIML: Artificial Intelligence Marketing Language https://donhopkins.com/home/catalog/text/aiml.html Support for AIML https://donhopkins.com/home/catalog/text/SupportForAIML.html To go along with the AIML parody, and give it a whiff of authentic scientific research, I formatted as html and published an actual AI research paper with the funniest title ever, by a company called Roanoke AI Laboratories, Inc., from The Journal of Theriogenology. (NSFW, unless you work in the Artificial Insemination industry!) https://donhopkins.com/home/catalog/text/AILabratories.html The author Jim Crump, Jr. actually found it by googling his name, and sent me a sincere email thanking me for formatting and publishing his AI paper on my web site, because his own publisher wouldn't allow him to publish his own paper on his own web site, due to draconian copyright restrictions. So I left it up because he was linking to it. Apparently it's well known in the AI Industry as the "Crump Technique". Attention is all horses need, too. I miss the early days of the web...

Eh everyone I know in YC answered this in an ethical way. In fact, I suspect YC keeps this wording to catch people admitting to something unethical while rewarding people who see something in a system that could be different. My answer that got me accepted was that there was a lip syncing competition at my college that was dwindling because everyone had to submit a CD and sign up in advance. It also was held in an auditorium. When I took over, I moved it to Spotify and moved the venue to the lawn, and we went from ~20 people the previous year to 1.2k the year I ran it.

I can shed some light here! This is going to be longish comment, but hopefully by the end of it you should understand _why_ we decided to avoid using the disk initially, even if you don't agree with that decision. Historically, the decision to not use disk traces back to this comment https://github.com/rust-lang/rfcs/pull/1317#issuecomment-150..., which is perhaps the single GitHub comment that influenced my life most. Very high impact, thanks dgrunwald! Specifically, >Don't store anything to disk. It's likely the oracle can be fast enough without doing this; and unnecessary complexity creates bugs. "Have you tried deleting the .ncb file?" (I remember having to do this a couple times per day when using VS, ca. 2005) >Use lazy evaluation. The IDE is only interested in very specific bits of information, almost always restricted to a couple of lines around the cursor. Avoid calculating stuff that might never get used before it gets invalidated by the next code change. >At least for C#, laziness saves so much time that incremental compilation is unnecessary for IDE purposes The other part of historical context was that the motivation for creating rust-analyzer was that I didn't want to write a second Rust compiler (having been doing that for a couple of years at JetBrains). So it was explicitly an experimental project to prototype the right architecture for an IDE, to ultimately change how rustc works internally, so that, down the line, an IDE and a command-line compiler could use the same core. Given that rust-analyzer is now effectively a separate rust compiler, it's safe to say I am not good at achieving my life's goals! In that context, I believe that avoiding disk was the _right_ decision: * It's not really germane to the problem space, if all you need is literally a cache, it can always be added later. * Disk is a can of worms of data consistency problems. They can be overcome with engineering effort to ultimately give better user experience, but user experience wasn't the primary goal. And using disk wouldn't actually illuminate the interesting aspects of the architecture, the intended primary goal. * Finally, _not_ using disk would be a forcing function to keep analysis fast enough, to not make startup prohibitive. The last one was a particularly big argument in my mind --- I didn't want to reach out for "easy" solutions prematurely, to avoid avoiding hard problems. And, again, my recollection is probably not 100% correct, but, until we added support for proc macros and build scripts, it was fine-ish from the perspective of startup time (RAM usage is a different story). The problem with proc_macros and build.rs is that they need to run the rust code, so they have to run the real rustc compiler, so all our usual IDE tricks ("information ... restricted to a couple of lines around the cursor") just don't apply. The reason why we didn't add it later was that it seemed a relatively lower priority task than the work to share the parser between rust-analyzer and rustc. So that's what I was focusing on, though, I didn't deliver that. I still think we should do it! There's no _insurmountable_ technical reasons why the parsers can't be shared! It's just (a lot of) engineering work. And, while the parser is the boring part of compiler, it's the interesting part of an IDE. Anyway, that explains how we ended up where we are. That being said, I don't think that "just adding disk cache" is the right approach --- the salsa in-memory data structure is very sparse and pointy. Dumping that to disk would help somewhat, but wouldn't be a great long term solution. What is needed (I also explain this in https://matklad.github.io/2026/08/21/rust-glancer.html) is to design a compact, first class data format for representing analysis information about the crate, and than teaching rust-analyzer to be polymorphic in the source of data. For current workspace, you want to use a lazy incremental in-memory data structure (I do think we sadly need incrementally for Rust, given its compilation unit structure). For dependencies, you want to work off a compact on disk index. And, if the user "goes to definition" and mutates its file in place, we want to transparently switch between the two. The _pre requisite_ for that was to define a backend agnostic analysis API, and that work was always slowly progressing in the background (https://hackmd.io/ytd82QNiT_Ku2XFr1EAtiQ), but it generally took the backseat, while sharing the parser was the main focus.

I've posted this here before but I have been creating animations using a similar process with a regular camera and manually splicing the frames together. [1,2,3] The effect is quite interesting in how it forces focus on the subject reducing the background into an abstract pattern. Each 'line' is around 15px wide. I think I went through exactly the same thought process as the author, funny how ideas can come up independently like this. [1] https://youtube.com/shorts/VQuI1wW8hAw [2] https://youtube.com/shorts/vE6kLolf57w [3] https://youtube.com/shorts/QxvFyasQYAY I also shot a timelapse of the Tokyo skyline at sunset and applied a similar process [4], then motion tracked it so that time is traveling across the frame from left to right[5]. Each line here is 4 pixels wide and the original animation is in 8k. [4] https://youtu.be/wTma28gwSk0 [5] https://youtu.be/v5HLX5wFEGk

In the mid-90s I taught a night class on Unix, and was experimenting with shell scripts from The Unix Programming Environment. There was an example using a loop and the who command to alert you when someone logged onto your local system. My cousin was a professor at a university several states away, and we had already figured out the talk command. So I decided to expand the examples in the book to use finger. By parsing the reply, somehow I could tell if my cousin was logged on, and I would send myself a notice. There was an ISP in the same building, and one day the ISP engineer came to visit me with a stern look. He asked, "By any chance are you sending a finger command every two minutes to this university's mainframe?" I proudly answered, "As a matter of fact, yes, I am!". I eagerly got out my Unix book to show him what I was doing. He just said, "Stop doing that. They have a system console logging program that has churned out dozens of pages of paper printouts because of you". I sheepishly acknowledged my mistake and quit running the script.

Ward Cunningham and I did something similar back in 2008. We were both at a startup in Portland and our office was along the railroad tracks east of the Willamette. We were up on the 4th or 5th floor right above a lot of train traffic including Amtrak. I brought in some extra Mac gear I had including one of the early iSight cameras which back then was an external device you stuck on the top of your display and connected to the Mac via FireWire. We set it up and rolled the desk over to the window in the office and turned the camera around pointing down at the tracks and Ward got to work hacking something up to do a slit scan. It was a fun little project; the speed of the trains affected the horizontal compression of the images. We could tweak the software to expand or contract the size of the image by adjusting the number of slit scans per unit of time. Of course, that affected the exposure but I recall the camera having some automatic adjustments that gave us trouble. That's about all we did with it. Just a quick afternoon hacking project. Neither of us thought much about it at the time so we didn't save anything.

Amit Patel was employee #7 at Google and built many things including the little geo display in the lobby that would show live search queries as dots color coded by language.

It's worth realizing that, before computerized central offices, telephone wiretapping required running physical wires. Back when Rudi Giuliani was prosecuting organized time, not only did physical wires have to be run, the cops were billed for them as expensive private lines. His task force was spending about a million dollars a year with New York Telephone on wiretapping. In one case, law enforcement didn't pay their bill, resulting in the person being wiretapped having the wiretap connection show up on their bill, blowing the case. That resulted in the Communications Assistance to Law Enforcement Act, which mandated that central offices offer remote wiretapping. Capacity up to 1% of lines is required. Back in the electromechanical era, the only call data that could be collected was outgoing dial pulses, using a "pen register".[1] (The one shown in Wikipedia is mine. It's a beautiful piece of antique brass telegraph technology. It records dial pulses as dashes, and has to be wound up like a clock, with a big brass key.) The Supreme Court decision allowing "pen registers" without a warrant refers to these "extremely limited" devices. That definition has been stretched and stretched by law enforcement into all non-voice data collected by telcos. Law enforcement still wants more. [1] https://en.wikipedia.org/wiki/Pen_register

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.