I did try ruby-prolog. The deeper issue is that its just not prolog. Writing in actual prolog affords a lot of clarity and concision which would be quite noisy in ruby-prolog. To me, the difference was stark enough it wasn't worth any convenience already being in ruby was worth.
Interesting! There are ~2 starlink satellites re-entering the atmosphere _every day_ now - and this is only set to increase. I wonder if this was caused by starlink debris?
The starlink satellites are designed to burn up in the atmosphere. They do this pretty often. But there's plenty of other space junk that's not designed to burn up and should have shown up on radar.
1) if this was big enough to get picked up on a 737 radar I think we would be having a very different conversation...
2) even if it did... rentry velocity is like miles per second, that would give you on the order of single digit seconds to recognize something on an intersecting trajectory and take action...
3) even then, I would bet that an object on this trajectory and speed would get filtered out as noise by aircraft radar because it is so antithetical to the types of things an airliner needs to inform pilots of.
And the Titanic was designed to not sink, sometimes reality is harsh. What is the probability for any of the parts of a starlink satallite to survive a descent?
Way less likely than the non-burned up remainder of some item from decades ago that was never specifically designed to burn up because "that's hard and it'll probably hit the ocean anyway"
It's hard to overstate just how much random junk is up there.
I was excited to see some evidence, but if you actually read the article they're talking about flakes of silicon with less than one joule of energy reaching the surface. To break an airliner windscreen, you need an energy more like a big hammer.
> In one rare instance, the company also revealed that "a 2.5 kg piece of aluminum" found on farm grounds in Saskatchewan, Canada, was traced to a Starlink satellite.
A piece of debris of similar size to this is what I'd guess could cause the kind of damage we see in the incident involving the airliner.
So while most Starlink debris may be harmless by the time it reaches the surface, we know this doesn't always happen as expected.
And since the vast majority of reentering space debris is from Starlink satellites, that'd would be the first place I'd look.
To be totally clear, I am doubtful this is actually caused by space debris, but I don't think it's entirely unreasonable for it to be one of the most likely causes.
> The starlink satellites are designed to burn up in the atmosphere.
How high in the atmosphere, though? They're not likely to hit the ground, sure, but 36,000 feet isn't the ground. Second, designs fail. 432 Park was designed not to have cracking and spalling concrete, yet NYT has a story today about exactly those things. Third, people lie about designs and capabilities. Pretty sure anyone who has ever worked in computing (especially with VC involved) has seen that. Who made that claim, and did they ever back it up?
I'm not saying that Starlink is the culprit here. The evidence is thin. OTOH the possibility can't just be dismissed because of a claim about a design to prevent a similar (but not identical) thing.
I pressume its much easier to design something to burn than to do anything else. You are basically just restricting yourself on material selection. The goal isnt for something to not fail, the goal is to fail. Its like asking to build a lawnmower that doesnt have to cut grass, and can look however you want. If you produce a pebble, it fits those criteria.
The atmospheric entrance for these (starlink) sattelites is basically as shallow as possible, so the object spends the most time possible in high atmosphere (think 60-90 km, where the atmo is thick enough to engulf the object in plasma, yet extert low pressure to slow it down, prolonging the time its burning. In otherwords, you couldnt achieve better parameters to burn stuff on deorbit.
All of it will probably be fully burned way before 50km - planes fly at 8-12
"Probably"? Even in their defense you felt a need to hedge, and that should tell you something. As another commenter has pointed out, Starlink has admitted that some components might survive re-entry. Let's not fall all over ourselves trying to give Musk and Co. more benefit of the doubt than they even give themselves.
Im just a rando on the internet, Ive never inspected the sats to know if they are not using materials that just wont burn up, hence "probably".
Im just listing facts to help you make a picture, I am not trying to "defend" anyone/anything. Please try to free your political/corporate bias from ingesting new information.
I haven't read the latest version of their ODAR (orbital debris assessment), but earlier versions of the satellites had a couple pounds of material that wasn't expected to burn up
You can still do this, it all still works, technically. You will have a spam/malware/security issues that wouldn't have been an issue back in the day. You will also have discoverability issues - but that hasn't actually changed, if it's just for you or your friends.
vet and safe-chain look good thanks! I'm just dabbling with Node only (no experience really), so haven't used npm audit but will see how that works too. Appreciate the links.
The store in the case of pass, is a plain text file, whose contents are encrypted strings. If you trust the encryption, you can put it anywhere you like. Keep the keys secret and safe, though!
Until you have to fire one of your disgruntled employees, who has a copy of all your secrets that you now need to rotate.
A repository that an attacker only needs to get access to once, after which they can perform offline attacks against at their leisure.
A repository that contains the history of changed values, possibly making the latter easier, if you used the same encryption secret for rotated values.
This is an awful idea. Use a proper secret management tool you need to authenticate to using OIDC or Passkeys, and load secrets at runtime within the process. Everything else is dangerous.
Thanks for showing this to us. The significance score is interesting. I like what kagi has done here, but news minimalist might be my real find from this post.
That's pretty neat. It doesn't seem to hit the days or months of use on AA batteries constraint. That said, I didn't consider the ESP32 line of SBCs and now I'm looking into low power variants so thanks for pointing this out.
If you want low power, try the nRF52 series of chips (e.g. nRF52840). Much less power hungry than the ESP32 with a comparable ARM core. Only Bluetooth though - no WiFi. nRF52840 sensors can run for months on a single CR2032 coin cell, and the power consumption while running is lower too.
