Aww, okay. I'll just have to go back to licking Switch cartridges then...

I think this one will work. Most of these games are already "multihomed" on different ad networks and display the one that is most profitable to them at any given time, or a semi-random mixture. The differences in profitably aren't that huge, and it will get even worse if advertisers run away from Unity too. Unity is making an absolute killing from their ads division, and this is now being threatened.

And who are the advertisers? Other game devs. The whole mobile game advertising scene is one gigantic ouroboros with the ad platforms cutting off a huge portion in the middle. If you leave, you're going to both stop showing ads and stop your advertising there.

This is a fun one we're gonna be hearing about for a while...

It's fortunate it was discovered before any major releases of non-rolling-release distros were cut, but damn.

Senior YAML programmer

Won't help here; this backdoor is entirely reproducible. That's one of the scary parts.

Given that the UUID changed, you almost certainly made a new LUKS container, overwriting the old one. That's bad, because the LUKS header is the only source of the actual encryption key that was used, and making a new one will overwrite both the main header as well as its backup copy immediately. Your password/keyfile/whatever is merely used to decrypt the part of the header that has the actual encryption key, and that's gone in that case.

Unless you have access to a header backup from before that, there's a fairly strong chance it's irrecoverable. I'd suggest going through any archives you might have to see if you have such a backup - most of the instructions on the Gentoo wiki encourage making one, so you might have made one through the power of copying & pasting instructions. Should be a file of around 16MB.

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.

It's not what the buttons look like, it's what they do. In Krita, making an ellipse involves clicking the ellipse button and dragging it somewhere. You now have an ellipse, and you hold shift if you want to make it a circle instead.

In GIMP there is no direct ellipse tool, there's only an ellipse select tool, likewise you hold shift to make it a circle. Then you use a menu item to select the border of your selection, getting a popup to let you determine how much pixels you want. And then, you use the fill tool or fill menu item to fill it. That's a surprising amount of clicks to accomplish what's most likely the single most common task for anyone opening a screenshot in an image editor. I'm not aware of any easier/faster method to do it. Feels like it should exist, but this is also what you get if you search for how to draw a circle in GIMP, so if it exists everyone's missing it.

GIMP's method gives you more power, but you rarely ever need that power. But when you do, Krita also has ellipse select, border select and various fill tools that can be strung together in the same way.

Reproducible builds generally work from the published source tarballs, as those tend to be easier to mirror and archive than a Git repository is. The GPG-signed source tarball includes all of the code to build the exploit.

The Git repository does not include the code to build the backdoor (though it does include the actual backdoor itself, the binary "test file", it's simply disused).

Verifying that the tarball and Git repository match would be neat, but is not a focus of any existing reproducible build project that I know of. It probably should be, but quite a number of projects have legitimate differences in their tarballs, often pre-compiling things like autotools-based configure scripts and man pages so that you can have a relaxed ./configure && make && make install build without having to hunt down all of the necessary generators.

DP is very much not free. VESA themselves is happy to tell you that DisplayPort is excluded from their list of free standards, and the leaked copies of old standards are stamped with a "distribution to non-members is prohibited" notice on every page.

I'm not sure where that misconception came from, but it really needs to stop at some point. The best thing to say about VESA is they're slightly less bad than the HDMI Forum. But only by so little.

"If we don't let the oppressors roam freely, they might try to oppress you" is not something I expected to read from the EFF today. But well, here we are.

It has been standard internet behavior that if a platform does not have the proper response to abuse complaints, you move up a layer higher until you find someone that is receptive to it. This has been standard operating procedure for more or less for the entirety of the current millennium, and this article has done absolutely zero work to provide a good reason it should be anything otherwise, other than bringing up generic "free speech" stuff.

You should not get a path out of that process because one layer immediately above the problematic entity is actively choosing to disregard abuse complaints. You simply move up to the next step. And this process simply must keep existing, as doing anything otherwise is to allow people to pull off all kinds of bad things; scams, spam, illegal activity and far more.

And if you abolish the non-legal form of that process? Well, there's still a legal process - and as soon as someone that wants to censor minorities gets control over the legal process, they will simply change the rules in their favor, as has happened countless times in the past.

Unfortunately, it's definitively an instance of intentional design. This whole consent dialog thing became a booming "consent management platform" industry. Many of them advertise better acceptance rates than the competition, or used to but have removed those claims in more recent times now that the big GDPR boom is over.

This particular dialog is TrustArc, who are infamous. At one point they defended it with a "well, we gotta retry if it fails to make sure your preference is expected, and we can't know if your adblocker is causing it to fail or if it's just a fluke", which is one of those things where they say something that's not totally wrong but you know they're lying through their teeth.

No, I most definitively hate Jira (and also my manager). Jira is the only software I've had to use where 10+ second page load times are a regular everyday occurrence. On their cloud hosting, so it's not like we could do anything to fix it other than filing tickets... which we were told to simultaneously keep doing so they can track it but also stop doing because it's working as intended and we were wasting their time and abusing support.

JQL is absolute garbage, and it doesn't even take hindsight; they took SQL but in an attempt to simplify it, they broke everything about it. Whether any particular functionality is a field or a function to run on some other field is a mystery. And if you're using Jira Service Management, it gets infinitely worse; everything is bolted on in a terrible way.

Every interaction between their "Kanban board" and "ticket" system is confusing. They pull from the same database, except not quite, except they do. It's a representation of data, but not the same representation the data is in. If you have any kind of custom workflow setup at all - which the blog both criticizes as bad and uses as a reason to explain why Jira is the only good option (????) - it will simply never do the right thing unless they map 1 to 1.

There are all kinds of perpetually missing features. Multiple assignees are a big one, there is simply no correct way to represent "John and Bob will spend some time together brainstorming about a new architecture" or simple things like pair programming, despite that being a fairly significant task that should somehow be accounted for in planning. You can half-ass it with custom fields or sub-tasks, but then the entire ecosystem of tooling built on the assignee field crumbles.

Likewise, you can't assign issues to a "virtual" position of any kind, all you can do is leave them unassigned or make (and pay license costs for) a fake user. It's not possible to represent concepts like "the first available person from the Ops team" or "whoever is currently managing the security team" unless you make it into a status and leave it unassigned, which causes a massive amount of issues when multiple teams led by different managers are working on one project or someone is temporarily or permanently unavailable for whatever reason (vacation/sick/etc). Planning software that cannot deal with people being unavailable is worthless.

Permissions are a complete mess. There's all kinds of funny interactions between admin and project permissions, and some things are in what could have obviously never been the correct spot. How it ended up with project releases being an administrative permission speaks volumes about how poorly everything is designed. Happy tenth anniversary to the cloud ticket, the original server one has another decade on it. Twenty YEARS of the most basic feature imaginable not existing when the initial implementation was patently incorrect to begin with.

Yum, smells like microwaved 'microwave-safe' plastic!

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.

I guess a CEO opened the YouTube frontpage while logged out and went "what is this shit".

But seriously, this seems like it's a good thing overall. The "default"/empty history algorithm recommendations are truly, truly horrifying more often than not. It's almost entirely low-quality clickbait and I can't imagine many people actually appreciate it like that.

If you're making something to come up with recipes, "is this ingredient likely to be unsuitable for human consumption" should probably be fairly high up your list of things to check.

Somehow, every time I see generic LLMs shoved into things that really do not benefit from an LLM, those kinds of basic safety things never really occurred to the person making it.

Okay, the thing that really matters to me:

“Frankly, we have more important things to do than spend a lot of time trying to figure out how to protect kids from books,” Exman tells PopSci via email. “At the same time, we do have a legal and ethical obligation to comply with the law. Our goal here really is a defensible process.”

According to Exman, she and fellow administrators first compiled a master list of commonly challenged books, then removed all those challenged for reasons other than sexual content. For those titles within Mason City’s library collections, administrators asked ChatGPT the specific language of Iowa’s new law, “Does [book] contain a description or depiction of a sex act?”

It really only got rid of things that would've otherwise had to go to begin with, while saving a few others.

It feels a bit closer to malicious compliance more than truly letting the AI decide the fate of things, and doing full proper compliance within the 3 months they were given would've been nigh impossible. I'm suspecting that the lawmakers were hoping that by giving them such a small timeframe, schools would throw everything vaguely suspect out. This ultimately leaves more books accessible, which I consider to be a good end result, even if the process to get there is a little weird.

And they're also deleting/deleted all classic Minecraft accounts from before that. They invented an incredibly weird and needlessly obtuse process to extend the migration deadline by 3 months (true final deadline is now mid December 2023), but that's seemingly it. Everyone not paying too much attention to their email just gets $30 worth of game deleted because of a completely arbitrary decision.

View -> User Interface, change to Tabbed or Tabbed Compact (or Notebookbar in old versions).

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)

The KeePassXC people are also volunteers and dealing with the fallout of this decision.

Already been done, there's a data dump of every MM1 course on archive.org. The dump is dated but it came after level uploads for MM1 were shut down so it should be about as complete as it gets, minus courses deleted by Nintendo before that.

Actually playing anything seems to be quite complex but there's some instructions in the reviews, so it should be doable for someone to set up a replacement server in the future (Pretendo network already has the basics for custom Wii U online running).

I can't speak for Apple but Google does. It falls under their user-generated content policy which requires you to "Provides an in-app system for blocking UGC and users". Google is generally the more lenient of the two when it comes to policies, so I'd be highly surprised if Apple didn't have it...

Technically always has, ROCm comes with a "backported" amdgpu module and that's the one they supposedly test/officially validate with. It mostly exists for the ancient kernels shipped with old long-time support distros.

Of course, ROCM being ROCM, nobody is running an officially supported configuration anyway and the thing is never going to work to an suitably acceptable level. This won't change that, since it's still built on top of it.

"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".

Everything was forked and should eventually end up on F-Droid, but most things haven't had a release yet. My understanding is that they're hoping to do everything right immediately, including having proper new branding and all the shared functionality from Simple Thank You.

The F-Droid versions of SMT apps are perfectly safe and shouldn't be going anywhere. (But if you have Google Play versions, I wouldn't trust those anymore, those are owned by ZipoApps now.)

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.

Memes used to be funny

DMA-BUF being marked as "unstable" for a decade was a fucking joke. It's a protocol that's required to get any kind of meaningful hardware accel going, which nearly every app does nowadays. Within Wayland circles, it's been understood it's not going to change for years, as doing so would break nearly every single existing app, yet all kinds of bikeshedding prevented it from being moved to stable.

Hopefully this marks a turning point for many other similarly important protocols stuck in unstable/staging hell too, like pointer constraints and text input. If devs can't rely on basic functionality to be present and it takes more than say three years to commit to it, it's time to admit that either the process or the protocol is broken.

This is a fork of the evaluator/language implementation/daemon/builder/whatever you want to call it. The other one (Auxolotl) is a fork of Nixpkgs, the repository of build scripts and all the NixOS misc pieces.

Or put into other terms, this is a fork of APT/RPM as well as their associated builder tools, while Aux is a fork of Debian/Fedora/whatever. The Nix evaluator is a much more complex piece of software than most other package managers so it does benefit from having a dedicated team working on it.

I think they'll give it a genuine shot. These stalking services pop up like weeds and every time it gets some media attention they end up with significant problems not much later. dis.cool was the last well-known entry but there's been more.

These things are always easy to say in hindsight, but I do believe that a closer review of the build system shenanigans used to install the backdoor would have at least raised some questions.

Nobody noticed it because nobody is reviewing autotools spaghetti and especially not autotools spaghetti that only exists as shipped in a tarball. Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer's computer. And nearly nobody has a good understanding of what any given line in a .m4 file is going to ultimately lead to the execution of regardless, so why bother investigating any differences? The maintainer of Meson has a good take on this.

Shipping tarballs without any form of generated files and having a process to validate release tarballs against the repo would be a good step, but is much easier said than done for a variety of reasons. Same thing can be said for shipping without any form of binary files in the repo, there's quite high value in integration tests and xz's README for the test blobs has correctly included this paragraph for 16 years:

Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.

This is a shot in the dark, but since the permissions look fine to me, the only other thing that comes to mind is that the SELinux contexts might not have been copied. Fedora is one of the few distros that enables SELinux in enforcing mode right out of the box. That can be very complex to understand if it breaks.

There is a Fedora documentation page about SELinux. The /var/log/audit/audit.log log file should be full of errors relating to your /home if it broke. I believe that stat /home and stat /new_home should display the SELinux context if SELinux is active, and they should be identical.

Also possible I'm totally off the mark, though, it's just a possibility.

It's difficult because you have a 50/50 of having a manager that doesn't respect mistakes and will immediately get you fired for it (to the best of their abilities), versus one that considers such a mistake to be very expensive training.

I simply can't blame people for self-defense. I interned at a 'non-profit' where there had apparently been a revolving door of employees being fired for making entirely reasonable mistakes and looking back at it a dozen years later, it's no surprise that nobody was getting anything done in that environment.

It's the second field on the edit profile page. Can't recommend putting it in, but victim blaming doesn't help anyone that already did so.

The edit profile page has a statement that "providing your real name can help friends find you on the Steam Community" with no indication that doing so also puts you at the risk of capital-G Gamers. I can see quite a bunch of people thinking that that's perfectly reasonable and not going to be abused.

The URL might be broken but the DOI is in there, and from there you can find the article quite trivially. It's a free article, even. https://doi.org/10.1093/biosci/biad080 -> https://academic.oup.com/bioscience/advance-article/doi/10.1093/biosci/biad080/7319571

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.

Someone hacked in a clear (in-game). First time it happened to this level, but not the first time it happened overall.

sudo mv /etc/default/grub /root/old_etcdefaultgrub to get it out of the way, then sudo dnf reinstall /etc/default/grub to reinstall the package that provides it, giving you a fresh unmodified copy. Should work for practically any config file on Fedora.