I tried running a 2nd instance of Roblox simultaneously on macos 15 with another account but this shows up, if my mac can handle it then why can’t it just let me do it? If I have two copies of an app like Roblox in separate User/Applications folders, macos moves them to the /Applications/ folder.
Sometimes it won’t run apps claiming to be corrupted, so I then have to do sudo xattr -cr /Applications/someapp.app in the terminal and they run perfectly fine. It always nags me if I download apps from anywhere but mac app store. Some of these messages can only be gotten rid of by disabling system integrity protection, but then macos blocks you from running MAS apps due to having “permissive security”.
I don’t daily drive macOS anymore, I switched to Linux on my M1 mac where I can do whatever the hell I want.
We’ve been mucking around with how to pre-configure Raspberry Pis after flashing at $DAYJOB and basically, the way the Raspberry Pi Imager works is that it writes a
firstrun.sh
onto the SD card which gets run during first boot.How does it know to not run that script from the second boot onwards? Well, one of the lines in that script is:
…it deletes itself while it’s running. 🙃
That is not a great solution
I would look into actual deployment tools. Stuff like Ignition, cloud-init and Ansible and your friend.
Oh yeah, we only want to pre-configure it with a static IP address on its Ethernet port, so that we can SSH into it in a controlled manner and then we intend to do the rest with a deployment tool.
That’s not what that is.
You setup Ansible pull or you use something like Cloud init where you provide a declarative config file. I also think Dietpi has something simular
What if the script fails?
Yeah, that is a very good question. It’s one of the last commands in the script and initially I thought they had set up the script so that it would abort, if any of the commands before it would fail.
But then a colleague pointed out that it’s actually the opposite. So, you can tell the shell to abort execution on error by running
set -e
. But what they had written at the top wasset +e
, which explicitly turns that off (even though it should be off by default).The last command in the script is also
exit 0
, so it always indicates success.So, yeah, they seem to have knowingly made it so that if the script fails, then it doesn’t retry or anything. It tries to plough through as many of the commands as it can manage (ignoring any that fail on the way) and then it always deletes itself.
I guess, it’s not as egregious of an assumption, because it only runs on a fresh OS. That’s a pretty controlled environment to be executing in, so the chance of something going wrong is rather low.
Well, and the other question is what else would you do? If the script fails and you don’t delete it, it’s going to re-run on the next boot. What’s going to be different on the next boot to make it succeed then? Might as well do as much as you can and then quit…
That’s pretty clever