The average lunar distance is approximately 385,000 km (239,000 mi), or 1.3 light-seconds.

https://en.wikipedia.org/wiki/Lunar_distance

*Moves mouse*
One Mississippi, two Mississippi, three Mississi
*Mouse cursor moves*

🥴

https://infosec.exchange/@0xabad1dea/116335209525412306

And 3 months later, i have not booted it once

Oh man, I know the feeling. It took me 5 months to remember that I had a Windows partition.

It was so important to me, to have a way back (which is fair enough), and then I just completely forgot about it.

The problem is that in this case, the LLM just naively auto-completes a password from what it knows a password to most likely look like.

It is possible to enable an LLM to call external tools and to provide it with instructions, so that it’s likely to auto-complete the tool call instead. Then you could have it call a tool to generate a correct horse battery staple, or a completely random password by e.g. calling the pwgen command on Linux.

But yeah, that just isn’t what this article is about. It’s specifically about cases where an LLM is used without tool calls and therefore naively auto-completes the most likely password-like string.

I imagine, it’s a matter of asking it to generate some configuration and one of the fields in that configuration is for a password, so the LLM just auto-completes what a password is most likely to look like.

It’s Apple’s programming language, kind of intended as a successor to Objective-C.

From what I hear, it’s actually decently designed and has quite a few similarities to Rust. Still not sure, how great it is outside of the Apple ecosystem…

My instance went down, so I’m way too late to make this joke, but anyways:

We’re not cantankerous, just a little …crabby. 🙃

I hear, it helps with saving up for treatment by not paying for nudes. 🥴

Yeah, I might block a contributor on sight, if they post something like that.

In case, you’re not aware, you can also email the dev. You can code up your commits as normal and then use e.g. git format-patch -3 to put the last 3 commits patch files. You can then attach those files to an e-mail and the dev can apply those patches with git am.

It takes a bit of playing around, but it’s actually really easy.
The Linux kernel, one of the most complex projects on the planet, develops like this.

I think, you could open the same file multiple times and then just skip ahead by some number of bytes before you start reading.

But yeah, no idea if this would actually be efficient. The bottleneck is likely still the hard drive and trying to fit multiple sections of the file into RAM might end up being worse than reading linearly…

Yeah, and the worst part is that submitting the PR is trivial. You just offload the reviewing work onto the maintainer and then feed the review comments back into the AI. Effectively, you’re making the maintainer talk to the AI, by going through you as a middleman, a.k.a. completely wasting their time.

I don’t feel like these positions are at odds with one another, unless you become active in reducing the number of humans, of course.

Like, you can uplift and protect people by stopping them from killing their environment, because you recognize that people are an invasive species that will do that.

If you’ve got access to a microwave, I’ve found rice dishes quite convenient, like for example a lentil curry. They generally re-heat without tasting worse and the rice traps the moisture, so even if your container isn’t 100% sealed, you’re unlikely to get mess everywhere.

(Though I’d still recommend getting a properly sealed container. Personally, I also transport my food in a separate cloth bag, so that if it should ever leak, I can just wash that bag.)

Yeah, I always plead for as much as possible to be automated offline. Ideally, I’d like the CI/CD job to trigger just one command, which is what you’d trigger offline as well.

In practice, that doesn’t always work out. Because the runners aren’t insanely beefy, you need to split up your tasks into multiple jobs, so that they can be put onto multiple runners.
And that means you need to trigger multiple partial commands and need additional logic in the CI/CD to download any previous artifacts and upload the results.
It also means you can restart intermediate jobs.

But yeah, I do often wonder whether that’s really worth the added complexity…

I always thought openSUSE’s package manager zypper has quite a few neat ideas:

• It offers two-letter shorthands for subcommands, so zypper install→ zypper in, update → up, remove → rm.
• When it lists what packages it will install or remove, it will list them with the first letter highlighted in a different color, kind of like so: fish git texlive
  This makes it really easy to visually scan the package list, and since it’s sorted alphabetically, it also makes it easier to find a particular package you might be looking for.
  And while there’s separate lists for packages to be added vs. updated vs. removed, they also color those letters in green vs. yellow vs. red, so you can immediately see what’s what.
• When it lists items (other than packages), it prints an ID number, too.
  So, zypper repos gives you a list of your repositories, numberered 1, 2, 3 etc., and then if you want to remove a repo, you can run zypper removerepo 3.
• When you run a zypper search, it prints the results in a nicely formatted table.

Documentation: https://doc.opensuse.org/documentation/tumbleweed/zypper/

Yeah, same. As they discuss in that issue I linked, it seems like in this partocular scenario, it gets stuck thinking it should remove a UnifiedPush distributor, but there is none to remove, so it keeps trying again and again, each time sending the same notification. But yeah, just my high-level understanding of the initial analysis…

What I find tricky, is that you’re always describing a work-in-progress. I also wanted it to be useful as soon as possible, so I started building the actual core logic first and documented that part of it.

But to actually use it, you need several steps before, which need to be documented, but preferably automated or ideally eliminated.
So, you kind of don’t want to invest time documenting that, because you know it’ll change a lot still.

And just as well, any quirks you document, it’s always like, okay, but what if I fixed this quirk instead?

Obviously, one has to strike some kind of balance. Things will never be 100% perfect or final. And I am most definitely lying to myself, when I figure that fixing it won’t take much longer than documenting it. But yeah, it’s just a constant struggle to find that balance…

It’s likely a bug: https://gitlab.com/relan/fennecbuild/-/work_items?show=eyJpaWQiOiIxNzYiLCJmdWxsX3BhdGgiOiJyZWxhbi9mZW5uZWNidWlsZCIsImlkIjoxODY5NDI0MzF9

Personally, I’m waiting to see what the devs say, but if it gets on your nerves, you can hide the notification in the Android settings.
I’m just not sure, if it is maybe needed again at a later point, which is why I’m holding off.

Perhaps also worth adding that here in Europe, lots of soy is now actually being grown regionally, as it can withstand the higher temperatures we now have from climate change…