seabass

The news did not affect the price in the way you are describing. The AH drop you are noticing was well after markets had time during the trading day to react. The timeline is important: the earliest archive link of the news I can find is from 11:55pm UTC April 30th. This leaves the entire trading day May 1st for the market to react. Apple’s earnings call was also May 1 after hours and it was their quarterly financials that led to the drop you described. In addition, pre- and post-market trading tends to have higher volatility due to the lower volume. In other words, markets are not pricing in a significant hit to Apple’s bottom line as a result of this ruling right now.

{"error":"Too many requests, please try again later."}

a missed opportunity for some humor

My first thought as well! The author of uPlot has a good demo illustrating their pitfalls https://leeoniya.github.io/uPlot/demos/stacked-series.html

He did, by rerunning it on a screenshot of the image

Trekker coverage is often official, too. I think you are confusing this with photospheres. Also important to note that there is vehicle coverage that is unofficial.

To me, no. It’s in the developer experience where Solid really shines.

It’s been an absolute joy to write Solid the last few years. After a workday of writing React, it always feels so liberating to come home to my personal solidjs code. When used with solid-primitives it feels very expressive and powerful. But mainly I think reactivity just jives with my mental model better than React’s top-down “rerender everything unless it’s a memo” approach. All that said, concerns about the solidjs ecosystem are valid. For example, if you want to use trpc your options are either to use v10 with an unmaintained adapter, or use v11 but not have the built-in support for tanstack-query that you would get with an adapter. Similarly, if you want to use framer motion, you’ll be a few versions behind the React folks. As someone who loves building my own stuff, usually ecosystem limitations don’t bother me too much, but it can feel frustrating to not get to use all the latest things available in the react ecosystem.

If you haven't seen Argyle's gui-challenges series, it's some of the best content I've found for learning how to use a variety of cutting-edge CSS features. I thought he was one of the best voices for the Chrome team.

https://github.com/argyleink/gui-challenges

Running `man` without any arguments is a fine place to put an easter egg, though. I'm glad this at least stayed there and was only removed from `man -w`.

Never understood why it had to be in the same folder. Can’t the os have its own little db somewhere that has a reference to each path?

If you’re using it as a reason to learn React or it gets you excited to get started, sure! Especially if you plan to have more than just static content, it’s totally a viable choice. But as someone who writes a lot of React for work, do I think it sounds like the right technology for a personal portfolio? Not really.

To me, part of the joy of small personal sites is that you can sidestep all of the tooling and compilation stuff and instead just write and publish. But I’ve also seen some highly interactive portfolio apps that run on React or similar, so a lot depends on your vision and what excites you.

Loved this write up. Of course the usual caveats with this level of optimization apply, and in general we should be aiming to optimize for human readability. But if nothing else I think it’s a good thing to get a better internal understanding of how the interpreter works.

With that in mind, it’d be interesting to see the relative costs of each deoptimization to the others. For example, is a monomorphic->polymorphic deopt an order of magnitude worse than an unnecessary string mutation? In nanoseconds, what’s the actual cost of each of these? Because there are certainly going to be some optimizations that matter much more than others.

Since the definition of Em and Ex are circular, how do bowser implementers go about actually building them? Do the actual implementations differ from the spec in that regard?

Adding ai features to the right-click menu is something I’ve been working on for the past year or so, and it’s always both exciting and disappointing to see one of the big players adopt a similar feature natively. I do strongly believe in the context menu being a far better ux than copying and pasting content into ChatGPT, but this release does have me questioning how much more effort to expend on my side project [1]. It doesn’t seem like Apple will support custom commands, history, RAG, and other features, so perhaps there is still space for a power-user version of what they will provide.

[1] https://smudge.ai

Yabai - tiling window manager

Raycast - better spotlight

Zed - fun text editor for pair programming

f.lux - makes the color temperature warmer at night, much more configurable than the built-in night mode

Suppose you don't know the shape of the content ahead of time. This would be the case for most apps that allow users to upload their own sources.

It sounds like (at the expense of more computation and time) the reverse adaptive tree approach you described would be ideal for those scenarios.

When they recommend using smaller chunks, how small in general are we talking? One sentence? One paragraph? 100 tokens or 1000? While I understand that the context of the data is important, it’s hard for me to ground vague statements like that without a concrete realistic example. I’m curious what chunk sizes people have found the most success with for various tasks in the wild.

Is there a mirror link? The original has been down all day

There's manim [1] from YouTuber 3blue1brown. And while it doesn't work on the web, there is a port [2] that does, which runs on p5.js. If you want a bit more control, you can use a canvas animation library directly. A few popular ones are p5, GreenSock, and PixiJS--but there are so many others. For simpler animations and for the most control over the result, it's pretty rewarding to just use the built-in Canvas API [3] directly.

[1] https://github.com/3b1b/manim

[2] https://github.com/JazonJiao/Manim.js/

[3] https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...

That's a great point. Dragging on any of the interactive elements currently fails. Building in the cmd+click option to bail out makes it possible, though.

I recently had this debate with my friend, who built this fun test to see how much latency was actually added by waiting for mouseUp: https://click-duration-timer.vercel.app/

I felt pretty strongly that I would hate triggering events on mouseDown because of how often I "cancel" an action mid-click. But I decided to add this userscript to my browser and live with it for a week:

  let preventNextClick = false;
  const interactiveElements = ['a', 'button', 'input', 'select', 'textarea'];
  
  document.addEventListener('mousedown', (event) => {
    if (event.metaKey) return; // allow cmd+click to bail
    if (event.button !== 0) return; // handle left clicks only
    
    // ignore all but a handful of elements
    const tagName = event.target.tagName.toLowerCase();
    if (!interactiveElements.includes(tagName)) return;

    event.target.click();
  
    // set a flag to prevent firing two click events
    preventNextClick = true;
  });
  
  document.addEventListener('click', (event) => {
    if (preventNextClick) {
      event.stopImmediatePropagation();
      event.preventDefault();
      preventNextClick = false;
    }
  }, true); // use capture phase

This causes any of the interactive elements on a page to trigger their onClick action during the mouseDown phase rather than onMouseUp. It's probably not perfect, just a scrappy user script. But omg it is so much nicer to browse with this enabled. And I say that as a hater of the original idea with strong opinions.

So, if you want to have a slightly more informed opinion on the issue I suggest trying this or something like it out for a week! I can't go back to the way it was before. Everything is so snappy now.

I haven't (yet) found a case where I wished I had the mid-click cancelability I had before. I think that getting used to the idea of clicks being instant rewired my brain a bit to simply not rely on that behavior anymore.

Just canvas APIs! A lot of fillRect and roundRect in a requestAnimationFrame loop

Ah, of course it's HaRGB. Really cool. I'm curious, you de-star the color layers or leave them as is when combining channels? When I've tried HaRGB, the Ha layer has the best/smallest stars which means that the RGB color layers end up leaving rings of color on the background around each star.

You already noticed the technical card [1], but I can describe some of the details that go into this for those unfamiliar with the items on it.

1. The scope they used is roughly equivalent to shooting with an 800mm telephoto lens. But the fact that it's 8" wide means it can let in a lot of light.

2. The camera [2] is a cooled monochrome camera. Sensor heat is a major source of noise, so the idea is to cool the sensor to -10deg (C) to reduce that noise. Shooting in mono allows you shoot each color channel separately, with filters that correspond to the precise wavelengths of light that are dominant in the object you're shooting and ideally minimize wavelengths present in light pollution or the moon. Monochrome also allows you to make use of the full sensor rather than splitting the light up between each channel. These cameras also have other favorable low-light noise properties, like large pixels and deep wells.

3. The mount is an EQ6-R pro (same mount I use!) and this is effectively a tripod that rotates counter to the Earth's spin. Without this, stars would look like curved streaks across the image. Combined with other aspects of the setup, the mount can also point the camera to a specific spot in the sky and keep the object in frame very precisely.

4. The set of filters they used are interesting! Typically, people shoot with RGB (for things like galaxies that use the full spectrum of visible light) or HSO (very narrow slices of the red, yellow, and blue parts of the visible spectrum, better for nebulas composed of gas emitting and reflecting light at specific wavelengths). The image was shot with a combination: a 3nm H-Alpha filter captures that red dusty nebulosity in the image and, for a target like the horsehead nebula, has a really high signal-to-noise ratio. The RGB filters were presumably for the star colors and to incorporate the blue from Alnitak into the image. The processing here was really tasteful in my opinion. It says this was shot from a Bortle-7 location, so that ultra narrow 3nm filter is cutting out a significant amount of light pollution. These are impressive results for such a bright location.

5. They most likely used a secondary camera whose sole purpose is to guide the mount and keep it pointed at the target object. The basic idea is try to put the center of some small star into some pixel. If during a frame that star moves a pixel to the right, it'll send an instruction to the mount to compensate and put it back to its original pixel. The guide camera isn't on the technical card, but they're using PHD2 software for guiding which basically necessitates that. The guide camera could have its own scope, or be integrated into the main scope by stealing a little bit of the light using a prism.

6. Lastly, it looks like most of the editing was done using Pixinsight. This allows each filter to be assigned to various color channels, alignment and averaging of the 93 exposures shot over 10 hours across 3 nights, subtraction of the sensor noise pattern using dark frames, removal of dust/scratches/imperfections from flat frames, and whatever other edits to reduce gradients/noise and color calibration that went into creating the final image.

[1] https://www.astrobin.com/w4tjwt/0/

[2] https://astronomy-imaging-camera.com/product/asi294mm-pro/

It has been extremely fun to use for personal projects. There are still some things that just do not work, though, like brotli compression which means any library using axios with their default brotli compression setting will crash at runtime. There is also no equivalent to the `npm outdated` command and a few other niceties. It is always little unexpected things, so it would be difficult to recommend for production uses just yet, but things are improving rapidly and I could see it becoming stable enough very soon. The APIs it exposes are so awesome—like giving node an excellent standard library—and the fact that I don’t need a compile step to execute TypeScript code makes it easier to get up and running with Bun than without it. Highly recommend trying for non-production work!

This is unintentionally a great ad for perceptual color spaces. I found it easier to ignore the color and just look at the percentage changes after a while when zeroing in on a guess. I wonder if that would be different in a game of Guess My OKLCH!

What is it about ipv6 that is so difficult for hosting providers to support?

It appears to be all but Ohio that are down now. It's hard to tell from the status page, though, which says "No downtime recorded on this day" for all locations 2h into the incident. I have one Oregon database that has come back online, though, so it looks like things are gradually being restored.

Whenever there's an incident like this, it seems like the status pages take a while to reflect the problem. Why is that? The part of the status page that can be manually updated is now correct, but most of the automated checks still show 100% uptime and only "degraded performance" in some cases despite being fully offline.

If I were implementing a status page, it might look something like a ping to some url from various regions. Assuming that's what these status pages are doing, why do they often say "All systems operational" until well into the downtime? Frustrating that I have to confirm on HN before I can know for sure something isn't just down for me.

The ORM API is very reminiscent of Drizzle, which I think was a great call on Astro's side. I have so far only used Astro for SSG, but seeing code like this [1] has me interested to see how far it can go for SSR tasks that you might currently use metaframeworks such as Next/Nuxt/SolidStart/SvelteKit for.

[1] https://docs.astro.build/en/guides/astro-db/#insert