Right. I'm not sure if you're referring to LEO sats or "secret" sats here, but in any case you're correct that not all get removed. It's possible, depending on the particular orbit that a 30sec exposure wouldn't produce a long enough streak to get caught by the filters.
Anyway, here's what the oficial FAQ [1] says about the process, they are trying to remove them all, but not always succeeding.
> Streak detection is implemented in the Rubin data processing pipelines, and occurs in two main portions of the pipeline. First, pixels associated with detected streaks are identified in the image mask plane and excluded from contributing to the deep coadded images. Second, sources identified in regions associated with streaks or glint trains are flagged during image subtraction and not used to create new difference imaging objects. In addition, alerts are only sent for detected difference-image sources that do not coincide with known satellite sky locations.
> Signatures from satellites may appear in LSST data products despite the Rubin Data Management team’s best efforts. Difference imaging catalogs have some flag columns which are designed to indicate sources that may be affected by streaks or glints (e.g., look for columns with “streak” or “glint” in their name). The IAU CPS SatHub has developed NOIRLab-hosted tools that may be useful for scientists working with Rubin data products.
various other examples. One really annoying thing is this has also happened in open source projects too - generic things that, sure, help out with AI tasks are now "AI" things.
> The real core of infrastructure monitoring isn’t dashboards. It’s the alerts.
“it’s not X it’s Y”
at this point when I see this pattern in writing I assume most if not all of it is AI generated - same with em-dashes.
This is not to discount the idea that alerts are more important than dashboards (I work directly in observability) - but just to say that I personally shut off reading anything else with these patterns because, generally speaking, the rest of the content is just not original or interesting.
I think that this is sad, because it is a useful pattern.
It is very frequent to find things about which a majority of the people wrongly believe that they are X, but in fact they are Y.
In such cases, you must point to them that "it's not X it's Y".
There are a few alternative ways to formulate this, but the alternatives are typically longer and more complex.
The same happens with em-dashes, which have valid uses and one should not care that there exist some people who are not familiar with the classic ways of using punctuation.
I do not believe that the right solution is to attempt to use more convoluted expressions or inappropriate punctuation in order to avoid to be accused of being a clanker.
I'm not sure in this case it's AI per se so much as a change over time.
At the first role I ever had 10+ years ago, we had a TV in our team's office space constantly showing our dashboard for our critical services and health. We still had alerting monitors but it felt like those alarms were for important issues (like sev-2 or worse).
the last couple roles I've had we don't constantly look at our dashboards unless our monitors keep ringing us with alerts. We have also had more monitors in general than the first role I mentioned. Occasionally if another team asks us if we're affected by something we'll look at the dashboards we have to make sure we don't have a monitoring gap.
THANK YOU, 1000% agree. I call this style “contrastive language”, and find it viscerally unpleasant. It is a pithy attempt to be overly attention-grabbing and “punchy”. Everything that is (was?) wrong with social media (sic LinkedIn) posts, even in the immediate lead up to when it became 100% LLM slop.
For files up to 100kB of size, this should effectively be really close to the same price as S3 when writing (didn't check reading so much, but the writes/PUT is always much more expensive than read/GET)
Would be really useful pre-compaction and to deal with small files issue without latency penalties
I find the people who end up with spaghetti code did so because they didn’t translate their normal processes over.
Being completely methodical about development really helps. obra/superpowers, for example, gets close but I think it overindexes on testing and doesn’t go far enough with design document templates, planning, code style guides, code reviews, and more.
Being methodical about it takes more time, but prevents a good bit of the tech debt.
Planning modes help, but they are similarly not methodical enough.
That works until you make a plan/tests/etc, set the thing loose, and then when it has trouble it decides "actually the pragmatic thing would be [diverge from the plan/change the tests/etc]" and goes off the rails. I'm so frustrated by these things right now.
reply