Archr

Strange I guess I am not aware of any distros that come with network drives pre-configured. But either way that would be a configuration error on the distro’s side then. Waiting for a network share to be available is actually a feature to many. Say for instance you had critical data on the network share then you might not want to boot if that is not available. And if you don’t then you might mark the share as nobootwait. Without knowing what the configuration on this specific drive you are having trouble with I really could not say what is wrong.

If you are having those issues with booting maybe it is because you configured your network share incorrectly? If you are waiting on shutdown timeouts for something then just go edit the timeout. systemctl edit . Typically when I crawl through journald it is to diagnose a problem with a specific application. Actually, the fact that those logs are easily accessible in a centralized place with easy to understand commands to access them is a reason why systemd (or more specifically systemd-journald) is so great. The only times that I have had major issues like that was either because (A) I misconfigured something or (B) a package came misconfigured.

Do you have a source on the udev thing? I have not heard of this.

there’s not a system in place to assign them responsibility regarding the child accessing places it should not (if we do really think they should not). That’s what this law does. It provides a system (age attestation) and penalties for violating it.

So fucking true. Once you get more than a hundred systems or so it feels like something new to resolve every day. Especially when your work let’s people with no idea what they are doing have root on different servers. I have dealt with issues ranging from someone uninstalling subscription manager (RHEL) and then clearing the package cache to people replacing chronyd with ntpd for… Reasons? I guess?

Sure I can chime in here. You did actually read the post correct? Not just the title? The original poster, Jef, is talking about implementing a Unix socket or a dbus protocol similar to what apple already has. They are literally just referencing their definition for a struct. So no this will not be ID verification, it won’t ask for face scans, and it won’t necessarily send the data anywhere. The article is just using the big A word as some boogeyman to generate clicks and further rile up the community. The systemd change is benign and this is not proof of your slippery slope theory.

Ahhh. And then you have people like me who have been seeding for years but are way too socially anxious to even start any of that process. (:

But you do give it permission. The data is only shared when you either install or open an application. Both things that you need to initiate. Nothing in the law requires that the data be sent off device. Ideally all of this checking would happen on device. And for those apps that don't meet that standard, don't use them.

That is accurate and should absolutely be fought to the end. But the one that this "new" "distro" talks about is specifically the California one.

The law does not require giving the government any access to your system or even sending them any information. This is just false equivalency.

This just seems like an attempt to get sued to challenge the law. Funny the amount of work that people are putting into such a nothing burger of a law. Edit: also interesting to see the critical meltdown our community has over a law that doesn't even require ID verification. Edit 2: also I will be honest I did not read the entire home page. It is like 5 or 6 times longer than the law that it is complaining about.

How I understood it would be that the api could be implemented as an API contained within your os. So it would be more equivalent to comparing it to a system call like open file or allocate memory than a REST API.

This is just the slippery slope argument. The California law does not require verification. Only attestation.

Yup, that is what it says. This will all depend on what the courts (assuming this even gets there) decide an application is. Maybe we should move more towards package managers only providing libraries and utilities. And not full-blown applications. Then rely on Flatpak and appimages (or snaps :-1:) for actual apps. It would be better for security anyways.

The bill does describe what a covered app store is. Here is a link in case anyone wants to read it. …legislature.ca.gov/…/billTextClient.xhtml?bill_i…

What you propose falls into the same pitfall that I see a lot of people here mentioning. How would we enforce that? From what I have read of this law there is no requirement for the OS to send the data to any source (ie. The government) other than the applications and app stores. There are even requirements that they not send the data elsewhere and nowhere else. People always bring up “it’s just a matter of time until the government starts trying to collect that data.” But that is true every day so I don’t really understand that argument. Besides many of us are on linux anyways where we will just say no.

Just moving the Overton window is not a good argument for or against anything. If you are concerned about what data the government may gather then say that and we can have a real discussion. I am going to assume that you are referencing the epstein files. This is not a law about that, if you want them to be prosecuted then that is something you should direct at your congressperson. Not at a state level law about age attestation.

Leaving it to parents is the reason why we are in this mess.

Someone else had brought up in the past few days that parents either don’t know that parental controls like this exist. Or they don’t care. This law puts that age setting front and center and allows apps, like Discord, so say “no <13 year olds”. I think where this maybe gets tricky is if an app says “only <13 year olds”. As like people have said there is nothing stopping people from lying, and that is a two-way street.

I mean yea. If you don’t make a good faith effort to implement this age attestation page and api to allow apps to pull from it. Then yes. You would be liable. You could of course decide to not provide to residents of California and Colorado. No one is forcing you to provide for either of these states.

… That is literally what this law does. When a parent creates the account for their child they specify the age. If the parent decides to lie or circumvent the system and it affects their child then they would be fined. Just to be clear the law itself says absolutely nothing about actually verifying the age.

I haven’t seen any devs in the linux space actually write about a real solution but my guess is likely not. Since the law specifies that users are “children”.

Are they? The law effectively only applies penalties to the parents. If you have not ready the law I highly recommend it. It is very short and says nothing about actually verifying the age of the user. It is equivalent of entering your age on steam or the “are you 18+” questions.

I think people are down voting you since they actually have not read the law themselves and don’t realize that the law itself says nothing about actually verifying that the age is correct. It is no more than what you said, like steam asking your birthdate before you look at certain games in the store.

The point of it is actually the exact opposite. With this law the parent would set the age of their child. And if they decide to lie and their child is affected then they could be fined. The other thing it does is if a platform decides to ignore the age range of a user and it affects a child then they could be fined. But as long as they do best effort then it really only affects the parents. It also prevent platforms from requesting additional ID verification unless they have confidence that the age bracket of that user is incorrect.