chameleon

Well, my recommendations for anything semi-automated would be Ansible and Fabric/Invoke. Fabric is also a Python tool (though it’s only used on the controlling side, unlike Ansible), so if that’s a no-go, I’m afraid I don’t have much to offer.

Realistically, there is only a trivial pure security difference between logging in directly to root vs sudo set up to allow unrestricted NOPASS access to specific users: the attacker might not know the correct username when trying to brute force. That doesn’t matter in the slightest unless you have password auth enabled with trivial passwords.

But there is a difference in the ability to audit what happened after the fact if you have any kind of service storing system logs remotely or in a tamper-proof way. If there’s more than one admin user on a service, that is very very important. Knowing where the compromise happened is absolutely essential to make things safe.

If there’s only ever going to be one administrative user (personal machine), logging in directly as root for manual administrative tasks is fine: you already know who the user is. If there’s any chance there might be more administrative users later (small but growing business), you should consider doing it right from the start.

You’re most likely booted, otherwise you might need a live USB. Hopefully, the system isn’t in read-only mode. What I’d recommend doing is:

cp /etc/fstab /etc/fstab.backup

To make a copy once. Then, nano /etc/fstab to run nano, a basic CLI editor. You can use the arrow keys to navigate and type freely in it. The hints like ^O shown on the bottom mean ctrl+o.

You’d use the arrow keys to go down to the line that probably says /dev/md0 /mnt/raid morecrap, put a # in front of it, press ctrl+w then enter to save. If that worked, ctrl+x to exit and try a reboot again.

Obviously can’t promise this is “the” error preventing the system from booting, but it’s generally a good idea to disable broken stuff like this to get the system working again, then fix it from there. Hopefully, this does the trick. Your RAID setup will not be activated on reboot after you do this but it’s not going to permanently delete data or anything.

The RAID1 seems to be failing according to that screenshot. That breaks the “Local File Systems” task and since quite a lot of things tend to depend on that, many things usually end up failing in an annoying cascade failure. It’s also failing with a timeout instead of a strict error, which is odd.

Either way, I’d try commenting that line for /mnt/raid in /etc/fstab for now and seeing if that makes the system boot. It’s possible that journalctl -u dev-md0.service or systemctl status dev-md0.service might tell you more, but it’s 50/50 if it’ll be anything useful.

No, it comes together with a CLA being required to contribute. In other words, Canonical (and only Canonical) is still allowed to sell exceptions to the AGPL.

Yes, the post says there is no copyright assignment. That’s extremely carefully chosen wording to avoid mention of the CLA which was made required in the same commit as the license change. It’s “just” a super extended license that lets them do whatever, not assignment.

Not that high. Spotify uses some pretty tight compression (not good, just tight); most users get 96-128kbit/s AAC, premium can go a bit higher if opted in. That works out to about 16KB/s or 58MB/hour, assuming nothing’s cached.

Bandwidth pricing very much goes down with scale, not up. But even the non-committed AWS pricing at Spotify’s scale is 2 to 3 cents/GB. You end up paying way less than that with any kind of commitment and AWS isn’t the cheapest around to begin with.

A biggie you miss is the toolchain: the compiler/binutils/linux-headers/libc/libstdc++ combination. The libc and usually libstdc++ are key components of any install. The other parts usually don’t make it to non-dev-desktops, but the distro couldn’t be made without them, so they’re virtually always available as packages.

Only exception is if the entire distro is cross-compiled or it’s made exclusively for containers, but those kinds of special distros break every rule imaginable anyway. Some might not even ship a bootloader or a Linux kernel by themselves.

Don’t bother “securing” directories like that. The meaningful permission bit is the write permission on the directory holding the file. cat ~/.bashrc > ~/.bashrc.new; put-malware-in ~/.bashrc.new; rm -f ~/.bashrc; mv ~/.bashrc.new ~/.bashrc or the like will still work if you have write permissions to /home/username at all. Marking the file immutable with chattr +i as root might be slightly more effective, but realistically still not enough in a lot of cases as the parent directory can still be renamed. Not to mention you’ve only found some of the low-hanging fruit; your text editor most likely also has a few ways to accomplish arbitrary code execution in its config/scripting/plugin files but it absolutely doesn’t stop there.

Don’t bother buying old systems because they can have free firmware. Ever since Spectre, CPU vulnerabilities have made old machines completely unsuitable for high-security purposes time and time again. Not all mitigations are equally effective and with mitigations on, performance takes a massive hit on those 10 year old machines. If you can get a reasonably new system with free firmware, that’s good, though.

I think most people don’t realize how unusual their company structure is. It feels like it’s set up to let them do exactly that. As far as I can tell, once you look past the smoke and mirrors, the board effectively controls both the non-profit and the for-profit.

Senior YAML programmer

AWS has a shitton of in-house “Graviton” ARM stuff available and the ARM server chips from Ampere are popping up in more and more places as well. Most Linux servery distros have ARM images available now, and most software builds without major changes. It’s a slow transition but it’s already happening.

“Open source” has more or less always meant something very specific as defined by the Open Source Definition. Adding restrictions on top like no commercial use or no lawsuits turns it into “source available”.

The current advisory is in webm (VP8 specifically). The webp one was 2 weeks ago. …yeah, not a good time for web browsers lately…

(edit: noticed OP actually did link the webp one, I thought it’d be CVE-2023-5217 because that’s being linked elsewhere)

AGI (artificial general intelligence) is the current term for “The Concept Formerly Known As AI”. Not really a new term, but it’s only recently that companies decided that any algorithm can qualify as regular “AI” if they consider it good enough.

It was made as result of an EU settlement that only lasted about 5 years. https://en.wikipedia.org/wiki/BrowserChoice.eu

I have absolutely no idea why they figured 5 years would be good enough.

OpenSSH’s server login component (the authorized_keys checking) can’t properly respect XDG_CONFIG_HOME because it won’t be set at the time it’s reading the authorized_keys file. The user’s home directory is stored in /etc/passwd but the XDG variables have a million different ways to set them, none of which are truly standardized. Best you could really do is hardcoding .config or the like, which you can do by changing the AuthorizedKeysFile in sshd_config.

You haven’t been able to give them nothing for over 2 years now. For this particular bundle, the minimum split for Humble is 30% and the default split is an insane 45% to Humble, 50% to the company and 5% to charity.

Humble is unfortunately still coursing by on their old reputation of being charity-friendly, but they changed to be one of the worst players around years ago. That goodwill from back then has really been depleted.

I suppose that’s true for some types of financing, but looking more into this particular plan, it all comes down to how much you value the bundled services… and they don’t seem stellar to me. The math I’m seeing from the time of announcement suggests you’d pay $1080 for a $599 smartphone or $1320 for a $899 smartphone. Even if you were planning on paying for YouTube Premium at full price, inflation still has a tough time beating that.

Upgrading would have involved signing a new 2 year deal. It’s just a fancy-sounding financing program; the 2 years were to pay for the device they’ve had for 2 years. I’ll never understand the appeal of buying a high-end/expensive phone on such a program because you’ll be stuck paying for something outdated by the end of it, but shrug, that’s not unique to Google.

If such a process existed, the entity in question would almost certainly end up being shut down by that process, unless they find a funny technical loophole around it, in which case that would be a failure of the law that should not be rejoiced by anyone.

But as it stands, that law and process does not exist; ISPs already can and will shut you down for things like downloading copyrighted content (with or without complaints from the copyright holder), tethering without approval, being a technical nuisance in the form of mass port scanning, hosting insecure services and other such stuff. “Hosting a platform solely dedicated to harassment and stalking and ignoring abuse complaints about it” absolutely deserves to be on that list.