This avoids the question, apparently because the design of this part makes it certain that when it does come into existence, it will depend on the rest of systemd.
The problem with systemd is that it's purposefully designed to be a viral monolith, without this it's got no purpose. We've been with this long enough to pretend otherwise.
> The problem with systemd is that it's purposefully designed to be a viral monolith
Is it though?
Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.
The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).
Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!
Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.
Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.
It's not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.
systemd-appd will likely depend on some but not all of the rest of the systemd system.
But the original question is beside the point -- systemd-appd will provide an API that can be implemented by others. I doubt the questioner actually cares much about how much of systemd systemd-appd pulls in, they want none of it.
The pace of progress is precisely why many people qualitatively assume the curve will flatten soon: J curves are generally (obviously not always) unsustainable.
You're arguing that the limits will appear because they usually do. (Correct my paraphrase if this is unfair.) Apart from being blind faith, this argument is oblivious to the fact that capability so far has scaled directly with compute and that the experts developing the models expect that to continue.
That is the lowest effort of lame responses. Look at the actual authors on the paper then. Or, I don't know, actually make a substantive comment about the research in the paper beyond your 8th grade redditor "Ha ha Siri sucks" response.
I have a co-worker who does this now. He's very smart, very capable, very experienced and it's clear that he's just a frontend for Claude now. It's tragic.
Maybe organize to give these workers more equity or rev share instead of just a wage so they care more for quality results instead of the behaviors they’re evaluated on and you’ll find them more pleasant to work with.
I offered an opinion in the previous version of this comment that was unhelpful to the discussion, even if the subject of the opinion was anonymous. Can't see how to delete a comment so I'm editing this instead.
Maybe he keeps more plates spinning ... in his side projects. Clearly, developers are expected to produce more results with LLMs and switch between contexts quickly. It shouldn't be surprising that everyone may be running their own thing(s) on the side now.
I didn't flag or upvote. I'll reluctantly agree with the mods inasmuch as this topic doesn't seem to produce any productive discussion anymore. Early on, I genuinely learned quite a bit from these threads. Now it's mostly empty name calling.
They also try to drive to canada with their guns, and believe they can't be "foreigners" because they're american. 30% of americans are functionally illiterate, no surprise really.
Embarrassing, but the statistic cited there is 6 cases in 2017 for a single crossing point, looks like there are ~1.5M visits a year[1] so I would imagine even if we're talking hundreds of cases (generous), still not too common?
US currency is accepted in a surprisingly large number of countries abroad. Just not in Europe proper. US dollars are even accepted in some European sovereign territories outside of Europe.
It is very convenient for Americans. Depending on the parts of the world you've traveled it is easy to get the impression that the US dollar is a sort of universal currency.
Which isn't to excuse the people in your story. It is pretty easy to find out if US currency works where you are traveling.
I've seen plenty of waiters, taxi drivers, etc., be quite happy to receive tips in USD in many countries where USD is not the official currency. In fact, I can't think of a single time when I've seen such a tip be rejected because of its currency.
That's quite different from trying to pay a bill (invoice) in USD in those countries.
No one expected anything and there wasn't any weirdness in getting a tip in your national currency. It's just that people happily accepted strong/popular foreign currency like the US dollar (I think that the Deutsche Mark was another option).
Sometimes you could even pay with it even if it wasn't officially accepted. Getting some money and then exchanging it yourself into the national currency (so that the accounting books are in order) is better than getting no money. And if it's a fuss, just charge a big extra, there's no need to make a big deal out of it.
*I guess there would have to be some mechanism for the database to push notifications to the client. This is not a fundamentally unsolvable or particularly interesting problem.*
> All this does is require the user to select a non-verified age bracket on first boot.
This is the age verification requirement which you rudely and incorrectly said doesn't exist. Nothing is done with the data (for now) but age is in fact verified on the assumption that the user doesn't lie.
Instead of lengthy condescending missives about the behavior of other users, you should instead write "I'm sorry for being negative and bringing down the quality of discussion."
Ah we should be happy about a bad law because it's enforcement mechanism is weak? That's twice-bad: undermines the strength and meaning of Law, and aligns Law with the bad.
When the law and it's execution are undermined and weak, it becomes the cudgel of fickle changing power, i.e. it is applied selectively and it means nothing to people except when they are being beat in the head with it, at which point they only regret having been caught, successfully undermining the social and political fabric of a nation.
Having a bad law with a weak enforcement mechanism isn't quite the thing to be boasting about you seem to think it is.
If it must be ignored, then it exists. The bill proposes age verification. You may think the measures employed are weak or trivial, and I would agree, but the bill proposes age verification.
You seem to be operating with an unreasonably weak definition of "verification". What this bill is requiring is that app stores or operating systems ask for age information. Verification would mean doing something to verify the accuracy of the information provided, not merely receiving a response to the question. "Age verification" is not a synonym for "having age-based restrictions".
> and gates further interactions based on the answer
No. The OS does literally nothing with the age information other than water it down to a few pre-defined age brackets and pass that on to applications. There's nothing in this law that says any action has to be denied. It's information collection and reporting, with no verification, accepting the information reported by the user as-is. The law does not require the information to be true or accurate, and explicitly removes liability from app developers when their users lie about their age.
Even applications don't need to do anything with the age information, unless there's a different law already on the books saying something needs to be age-restricted. And in those cases, getting the information about whether to apply restrictions from the OS instead of however they're currently getting age information is not "verification".
"Verification" necessarily implies at least two pieces of information or steps in the process: first, an assertion of something as fact, then something to confirm that fact. This law omits the second step. There's no confirmation.
Gatlin, you need to apologize for ignorantly mangling the definition of "verification". This is truly embarrassing for you. It really brings down the quality of the discussion.
You seem to have an almost religious devotion to your worldview. Which makes sense: it works for you and you feel compelled to convince others. You also limit yourself to thoughts and practices that align with these views. Imagine for a moment that this is also true of other people for other beliefs.
reply