The_Decryptor

The laws they’re trying to support require very limited information, but they’re storing far more than that and they’ve actively decided not to protect it properly.

All systemd is storing is the DOB in YYYY-MM-DD format.

Or you just mark your account as an adult, all the california law requires is effectively parental controls to be available, you can just not enable them.

It definitely looks like it’s going to be a standard USB HID type device, if their SDL support is anything to go by.

Windows is pretty much the same as Linux, it exposes the raw events from the device and it’s up to the app to handle them. Pretty sure the overlay handles that by sitting between the OS and the game and e.g. translating everything to Xbox style controls if the game needs it (And getting out of the way if it doesn’t)

Outside of that, well Valve added support for the controller to SDL, so anything using it will be fully supported. But then the game needs to actually be using a new enough version of SDL, otherwise it’ll just see a generic controller device, and that can be hit or miss.

It’s been a few years since I used a Mac, but even then resource forks weren’t something you’d see outside of really old apps or some strange legacy use case, everything just used extended attributes or “sidecar” files (e.g. .DS_Store files in the case of Finder)

Unlike Windows or Linux, macOS takes care to preserve xattrs when transferring the files, e.g. their archiver tool automatically converts them to sidecar AppleDouble files and stores them in a __MACOS folder alongside the base file in the archive, and reapplies them on extraction.

If course nothing else does that, so if you’ve extracted a zip file or whatever and found that folder afterwards, that’s what you’re looking at.

Because of static linking, a single GPL dependency turns the entire resulting binary into a GPL licensed one, so yeah just use something like the MPL in that case (Or EUPL, which I hear is similar)

LGPL has the same issue, since it only provides an exception for dynamic linking. But honestly that’s all an issue for lawyers and judges to sort out (I bet you could win in court with an argument that dynamically linking to GPL is actually fine).

What’s the risk here though, a company like Amazon makes a closed source version of it?

If it was a file format library, or something like a web server I’d get it. But stuff like cp are effectively just userspace wrappers around kernel APIs.

The latest Nvidia drivers have broken composition in Xfce, so I’ve been raw-dogging basic X11. It’s like I’m using WinXP again.

The idea is that it’s left up to the windowing toolkit itself (.e.g GTK or Qt, etc.), so the compositor can focus on just compositing, which makes sense IMO as it’s how other platforms handle it (Except they have a single OS provided windowing implementation). Problem is, that leads to massive fragmentation of functionality, every app has different toolbars and features based on the toolkit they use, and requires each app to handle it, which sucks and shouldn’t be the case.

Like in the Factorio case, it uses SDL for windowing, and SDL actually supports handling titlebars itself. But Factorio just wasn’t including the dependency that enabled it at that point, so all it took to fix it was including it and everything started working. But that’s still extra work that had to be done just to get minimum functionality, which wasn’t needed on e.g. KDE.

I mentioned in my other response, it’s the inflexibility that’s the actual problem. Lots of apps do want CSD, or at least control over how their windows are presented, but Gnome going “you’re on your own” is the worst outcome.

Their go-to solution is libdecor, which is just a library that implements a titlebar, still putting the burden on apps (Or rather, whatever windowing library they use) to be responsible for it.

Worst thing is, I kinda get their argument against supporting it, they’re just really inflexible about it which just makes the whole issue too heated.

what happens if you do run something on GNOME that simply doesn’t have any code that draws its own titlebars?

You get nothing.

Is driver support stable in ReactOS?

It exposes the Windows driver APIs, so it’s “getting there”, slowly. They got the (Win 7 era) Nvidia driver running recently.

They’re called “selections”, the main ones being PRIMARY and CLIPBOARD, and it’s effectively a form of IPC mediated by X. When you select something, that goes into the PRIMARY selection, while when you copy something, it goes into both PRIMARY and CLIPBOARD.

The problem is that “middle mouse click” isn’t actually paste, it’s “insert primary selection”. As long as they’re in sync you won’t notice any issue (Ctrl+V and MMB will both insert the same content), as soon as they’re out of sync you’re suddenly exposed to an implementation detail of the X11 protocol.

And it’s easy to go out of sync, simply copy something and then select unrelated text, now Ctrl+V and MMB will output different things. It can be useful, e.g. if you’re having to copy a bunch of different pieces of text from one window to another, you can simply select and MMB, no keyboard needed, but it’s not intuitive IMO, and conflicts with modern usage of the middle mouse button (Get it wrong when trying to open a link in a new tab and you’ll dump whatever text you last selected into the site instantly)

Also, these selections aren’t a thing under Wayland, it’s been re-implemented as a normal paste operation there. The question is actually whether the middle mouse button should be treated like any other mouse button or have this special behaviour by default. My vote is to expose it via the mouse settings applet and leave it up to users, like any other special mouse button.

Rust has no stable inter-module ABI, so everything has to be statically linked together. And because of how “viral” the GPL/LGPL are a single dependency with that license turns the entire project into a GPL licenced one.

So the community mostly picks permissive licenses that don’t do that, and that inertia ends up applying to the binaries as well for no real good reason. Especially when there’s options like e.g. MPL.

These days there’s scdoc, you can see the source for a man page written in it here, and the output here.

AMD did nothing to make their drivers better, Vale did.

That’s literally the point of open source though, both AMD and Intel rely on open source drivers, so anybody can fix a flaw they encounter without having to rely on the company to “consider allocating resources towards a fix for legacy hardware”

KHTML and WebKit is a historic mess but it’s debatable at best if Apple actually violated license terms.

There’s no requirement that a downstream fork needs to contribute their code back to upstream, they just need to release it, and they always did that.

The lead developer of systemd has said multiple times that we should be fine with break POSIX if it means developing faster.

I mean, so does GNU.

A lot of this is also a post-hoc justification, UNIX didn’t get shared libraries until some point in the 80s (Can’t find an exact year), so before that your options were to either statically compile the needed functionality into your program or keep it as an entirely separate program and call out to that.

It’s a perfect mix, in a time where enterprise storage was measured in single digit megabytes, and the only efficient way to created shared functionality was via separate programs, and you’ve got an OS that happens to have “easily pass data between programs” as a core paradigm.

And now people invoke it to attack an init program for also monitoring the programs it starts and not just spawning them.

Something easily turned off is distinctly not opt in. They’re still lying to everyone.

It’s just that nobody can agree what “opt-in” actually means, apparently.