Are Unix and Unix-like vendors making implementing this harder than it needs to be? Here is what is required for laws like California's.
1. To modify account creation so that in the scenarios where the law applies (account is being created for a child who is the primary user of the device) to ask for the age and/or birthdate of the child.
2. A way for applications to ask for the age range of the user ([0, 13), [13, 16), [16, 18), [18-infinity)).
Implicit is to store enough information from #1 to support #2.
The way I would store that information is by creating a directory, say /etc/age_group, and in that creating one file named after each age range. These files would be owned by root and not group or world readable.
On creating an account this applies to add an access control list (ACL) entry for that account to the appropriate file in /etc/age_group that allows that user to read it.
Then for #2 the way applications can check is by simply checking which files /etc/age_group it can open.
This should be more portable than the other ways I've seen proposed. POSIX access control lists are included I believe on every major Linux distribution (and also MacOS, FreeBSD, and maybe other BSDs).
This would give application writers on most Unix and Unix-like systems a common way to check if they are on a system that implements the California law (does it have /etc/age_group?) and a common way to check age group.
This is a great idea. It very compactly implements a barebones parental control system: a parent (with admin access) can assign an age group to a user account, and apps which care can easily check it.
I think it's exactly how such a system should work: apps, sites, etc should declare an age limit, and the user's OS should decide if it's going to give the user access to them. This approach is opposite to having the user to prove their age (and worse, the legal identity) to the web site, app, etc.
I ran a Debian box for my daughter when she was a toddler and a pre-schooler. She was good at selecting her favorite movies and music in XBMC, and enjoyed simple drawing apps.
That’s a clever start, but it has a problem. What happens when the list of age groups changes? This list is not fixed; it changes over both time and space. How do I tell the difference between a system that doesn’t support age attestation vs one that only supports age groups that I don’t know about? For example, suppose I am looking to see if the user is in the `over_13` age group, but only `/etc/age_group/adolescente` exists? What if there are multiple readable files?
Systemd’s solution is simpler and doesn’t have these edge cases. A higher level of software, such as the desktop environment, can query the user’s birth date from systemd and use their locale settings or time zone or other information to compute the correct age group.
Or find the best third party library and copy the code from a widely used version that has been out long enough to have been well tested into your source tree.
The problem is not third party libraries. It is updating third party libraries when the version you have still works fine for your needs.
Don't do this. Use a package manager that let's you specify a specific version to pin against. Vendoring side steps most automated tooling that can warn you about vulnerabilities. Vendoring is a signal that your tooling is insufficient, 99% of the time.
Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages.
If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.
This is only true if you aren’t internally mirroring those packages.
Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.
> Is there any package manager incapable of working offline?
I think you've identified the problem here: package management and package distribution are two different problems. Both tools have possibilities for exploits, but if they are separate tools then the surface area is smaller.
I'm thinking that the package distribution tool maintains a local system cache of packages, using keys/webrings/whatever to verify provenance, while the package management tool allows pinning, minver/maxver, etc.
> What's the actual steel man argument for why noncompetes are good?
It probably depends on the kind of job.
If say Walmart tried to use a noncompete to stop cashiers from going to Target there probably is no reasonable argument in favor of that.
On the other when the employee is a top level executive who knows all the company's trade secrets and all their plans for the next year or so and they want to go to a direct competitor it is hard to see how they won't use that information at the competitor. Even if they scrupulously try to uphold any NDAs they are under and so don't consciously do it stuff will leak.
If the first company sues accusing the second company and/or ex-employee of using such information it can get pretty messy, and consumer judicial resources better used for other things.
A policy then of allowing noncompetes in this situation might overall be beneficial. Top level executives are generally well compensated and should be sufficiently sophisticated financially to understand the consequences of a noncompete and take that into account when deciding on taking the job so having to sit out 6-12 months before taking a directly competing job should not be a serious issue.
> On the other when the employee is a top level executive who knows all the company's trade secrets and all their plans for the next year or so and they want to go to a direct competitor it is hard to see how they won't use that information at the competitor.
Since this is a steelman, what is the rationale for this dynamic needing to be protected? If this employee wants to go to a competitor because they they are getting a better employment deal, why not just try to keep them with your own better employment deal?
Why does it need some forced restriction? I know people aren't perfectly rational market participants, but what besides financial compensation or an enjoyable work environment would compel someone to go to a competitor?
The article covers this, but probably worth having it mentioned here too: Washington already had partially banned noncompete agreements.
They were banned for employees who made less the $127k/year or contractors who made less than $317k. Those numbers were adjusted annually for inflation.
> No court is going to enforce a non-compete if it means the person who cannot compete is going to be unable to support themselves. The only time it'll be enforced is if you're already independently wealthy.
The first part is probably usually true, because places where non-competes are enforceable generally will not enforce them if they are overly broad.
But for tech workers there are almost always other jobs that the worker can qualify for and pay similarly to their old job but are not covered by the non-compete and then then non-competes do get enforced even though the worker is not independently wealthy.
Block pages that contain a construct that is commonly used by humans in human writing and has been for centuries because AI that trained on human writing also uses it?
Should we also block pages that contain no spelling errors or no grammatical errors?
Among SUV drivers in the US the biggest segment is compact SUVs (think Toyota RAV4 or Honda CR-V). Then midsize (like Toyota Highlander or Hyundai Palisade), subcompact (Mazda CX-30, Hyundai Kona), then full sized (Chevy Tahoe, Ford Expedition).
RAV4 non-hybrid is around 35 mpg highway. CR-V 34 mpg highway.
In midsize, Highlander is 29 mpg highway, and Palisade is 25 mpg highway.
In subcompact CX-30 is 30-33 mpg highway depending on options. Kona is 29-34 mpg highway depending on options.
The full size category, which does get down to around 20 mpg, is only around 3-4% of SUVs in the US. Tahoe is 20 mpg highway. Expedition gets 23 mpg highway.
Great, but it's still 9.5 hours of time on the wheel. Train/plane eliminates that. So even if it is 1/3 cheaper in fuel, it's something that needs to be considered.
> RAV4 non-hybrid is around 35 mpg highway. CR-V 34 mpg highway.
....35mpg at 60mph and little traffic, maybe. I can't speak for that specific model, but most vehicles I've driven do significantly worse than advertised.
My Subaru Legacy advertised 27 City, 35 Highway, 30 Combined. In practice I average 25-26 while commuting and on extended highways drives more like 29, still on stock tires.
There’s a reason most universities don’t hand you a bachelors degree in economics as soon as you complete EC101. You should look into EC102 and the rest of the curriculum.
reply