Systemd lets you create templates that take an argument in from the scheduled service. It gets that from the value after the @. So you can write a unit file that schedules a task to run say every 3 days and in that unit file reference `jobs/%i`, then put your task in a file in jobs and say `systemctl start every-3-days@script1.sh` to run `script1.sh` on your schedule without needing to create a new unit file for each script. StepCA has a nice write up on their site about using these templates to schedule cert renewals for any arbitrary service
This is a just so story that is trivially and obviously false and I don’t understand why it continues to persist. Paid public police forces in the US appear as early as the 1600s in Boston. The first what we might consider modern police departments were formed in the urban hubs of 1800s America where immigration tensions and the general increases in crime you expect when putting a lot of unconnected people into a concentrated area were driving factors for changes to what laws were made and how they were enforced. And those were modeled off the London police forces, themselves guided in large part by Robert Peele’s principles of policing.
Slave patrols were a form of early organized policing, but only one of many and hardly the first. And certainly this isn’t to say that racial tensions didn’t drive various forms of law enforcement. But this idea that police in general and American Police in particular are some direct descendant of salve patrols or wouldn’t exist without the institution of slavery ignores so much of human history and the long history of organized forms of law enforcement that predates the American colonies.
> formed in the urban hubs of 1800s America where immigration tensions and the general increases in crime you expect when putting a lot of unconnected people into a concentrated area were driving factors for changes to what laws were made and how they were enforced
This is a dog whistle if I’ve ever seen one. I’m not going to let that slide and your citations are not supportive of the strength of your claim
How is it a dog whistle? What words would you like to put into my mouth?
Are you suggesting that “urban hubs” and “immigration tension” are code words for “black people” and “slavery”? Because I regret to inform you that when New York City established the first US police department in 1845 (per britanica) the “immigration tension” at the time would have been the influx of Irish immigrants. And while Cincinnati had indeed had a white on black race riot in 1841, when it established its own police department in 1852 the anti-catholic / anti-German immigrant riots in 1853 and 1855 were the more contemporary “immigration tensions” I was referring to. Boston too when it founded its police department in 1854 was in the middle of a surge of Irish immigrants. Certainly these northern state city centers weren’t simply giving uniforms and badges to “slave patrols” when they founded their police forces, regardless of what other racial tensions may or may not have played a hand in the demands for a police force.
All of which is to say if you recall your American history, we have a long and storied tradition of hating on our immigrant populations and having conflicts with them. Yes white vs black was a problem at the time. And so was “white vs Irish” and “white vs German”. Our history is littered with racial tensions across just about every set of ethnic lines you could care to draw.
> That's an unbelievably bad _and_ disrespectful take. They accept these low wages because it's their only way in the industry, and because the industry has made sure to keep a steady supply of fresh meat to burn out
Is it really “disrespectful” to make an observation of how the world is even if it maybe isn’t how it should be? That fact of the matter is no one “needs” to accept these wages. Software development in general and game development in particular are labor fields of choice. Being a software developer can pay you better in so many different parts of the field, even today long after the dot com boom. People are choosing to accept these bad offers because they value working in this part of the industry more than they value the higher wages they can get elsewhere. Just like plenty of us choose not to make FAANG levels of money because we value our work life balance, or our specific living locations or our principles and beliefs over the money that those companies are throwing at people.
We can talk about how these bad offers are knowingly abusive or artificially suppressed and still acknowledge that people are making informed choices to accept those offers.
> In order for that to change, the market has to increase in size by appealing to a more casual audience, or existing gamers have to pay more. Not something I think most gamers would like.
To really drive this point home, the gaming community recently lost their minds when it became clear that this generation of video games were going to retail for ~$90 per game. Never mind that even in the early 90’s an average game might retail for $40 and what we would call a AAA game could reach as high as $70. In 2025 gamers declared that $90 was highway robbery. But go look at the credits for an early 90s video game. That $40-90 per unit in the early 90s might need to cover the salaries of 23 people (the size of the credits list for Super Mario World on the SNES). Now $90 has to cover 435 people (the credit list for Super Mario Wonder on the switch). Sure we’re selling a lot more copies now, and (some of) the manufacturing costs are lower. But that’s a nearly 20x increase in personnel for a mere 2x increase in (non inflation adjusted) price.
It's also amortized over a much longer period of time too. Those 23 people would scratch build that $40 game in 2 years. These days it's more like 8 years, and you're rarely building from scratch.
I’m not sure I understand why this is a problem. RSS is a spec for publishing a list of available content, or publishing the content directly. Formatting that content was always going to be something people wanted to do, so whether it was rich text, html or what became markdown, it was inevitable that aggregators were always going to have to deal with both publishes wanting their publication to have styles and users wanting their aggregator software to either handle that style or hide it.
At least with a cdata tag your being explicitly told “here be dragons”
I guess the difference is if you want the descriptions to be readable by simple tools, or if you assume that every reader has a full-fledged Chrome available.
ai can remix things on the fly so lots of widgets that were being stamped on are not needed anymore.
we are in middle state where ai tools to generate on the fly widget work arent accessible in the form that most ppl need. So programmers are currently doing the manual step by managing remix into easily consumable form.
One question I have is are these "constraints, style guides, corner cases, error handling, optimization guidelines" extra things that you wouldn't need otherwise, or are they formal documentation of the baked in assumptions and knowledge accumulated over the years? Every project I've ever worked on has had heaps of shared knowledge that's just part of stuff the team just "knows" and no one ever really writes down. Things like "sure you can use java's built in assert for tests, but we don't compile or run the application with the flags that enable them. Use junit's assertions/use the assertj library." or "prefer using auto generated accessors instead of manually writing them out". Even things like "if you change the structure of this ID string, you need to change all the code in modules A, B, and C because they all rely on the ID being in a certain format".
If you're really lucky, maybe a lot of this is documented in some wiki page somewhere, but everyone knows the documentation is never as complete as you'd like it to be. The longer a team works together without new people coming on board, the more likely it is that the documentation of these soft requirements and knowledge has drifted from reality. IME nothing shows how much you've failed to document than revisiting your onboarding process documents for the first time 2-3 years after you wrote them.
As I've experimented with the various AI tools, I feel like a lot of these extra documents I've written are documenting a lot of these things "everyone knows". But I'm also not at the "80% of the professional code I write is generated" stage yet. So I'm curious if you're finding that you're creating documentation that goes beyond just documenting what we used to just keep in our heads and are now getting into "writing a book about how to code" territory?
There is a great thing. Because the agents can do so much toil you can add things like formal verification, fuzzing, and other feedback mechanisms and quality gates to your projects cheaply. In a human written project you still needed those things, but it cost a lot. Agents require these quality gates and they can implement them for you. The problem with AI documentation is it will just write a lot of useless bullshit unless you guide it on what is important. You can also get agents to identify transitive dependencies via testing and other things.
I adopt the mindset of docs are for humans, tests are for agents. They document formal dependencies and leave a measurable artifact behind. If you identify some behavior or transitive dep in your system, agents document it first with a test codifying the expected behavior. Tests are the source of truth about expected system behavior and you can convince agents to write decent behavioral tests if you ask them to with the right structure. Docs are now cheap and a render, not a long term thing. There is some token efficiency to consider, but still, they are quick and cheap if you don't understand some module or its purpose.
Yeah "plus one" to this. Static analysis, fuzzing, linting, integration tests -- there are all sorts of very useful artifacts which have been around for a long time, but which are very time consuming to implement and then maintain. LLMs shift the economics around producing and maintaining these tremendously, so we can now afford these robust validation mechanisms.
These serve as living documentation which cries out in pain when they get out of sync with the system in question, generating specific error messages -- as opposed to natural language docs which rapidly drift into an ambiguous "kinda useful" state. And the validation is performed mechanically (as opposed to neurally) so no hallucinations are possible.
The one thing I would add is that you do want these artifacts to be human-friendly from a reading perspective -- you want engineers to be able to scan over these and check that they are validating the right things.
> Because the agents can do so much toil you can add things like formal verification, fuzzing, and other feedback mechanisms and quality gates to your projects cheaply
Works great until they sweep you a test under the rug which always passes because the condition is something like if(true) .
That was my point. Validating actual behavioral tests. Not letting them cheat. They still will at times, but like, resd their code, fix it or send a reviewer agent to find and make todo list. If you give them a behavioral test skill it will do a much better job. Sometimes I have to hint to them. I rarely ship anything I have not reviewed at least once.
> Not letting them cheat. They still will at times, but like, resd their code,
Well then, if they "still will", your effort kind of misses the point. Sure maybe, you'll catch it every time and maybe that one time you did not catch it, it was no critical mistake...But it only needs to make that critical mistake once, and all of this effort was in vain.
(as an outsider) what this sounds a lot like to me is trying to manage a very large team of human personnel that have a high turnover rate which is not directly in your control.
Some of them will make mistakes, some of them will cheat, some of them will do things you don't like, and "punishing" them will be less helpful to you due to the high turnover than building a system which instead disincentivizes things from a high level. Which catches bad actions and starts them over.
Classically I think we are more accustomed to "building a team of humans, and being able to chastize or fire a bad employee helps the team grow more cohesive and build accountability".
But it is possible to get the same (less than ideal) situation with teams of humans where accountability cannot be easily instilled into the team as we have with teams of agents.
And then obviously the reason one might consider using such an unusual and difficult to manage team as a tool is when the cost is low and the supply is high, which is purportedly the case with AI at least for the moment.
I’m a big fan of JetBrains model for this. Buy the software on a subscription, and the subscription gets cheaper for the first 3 annual renewals. While you’re subscribed you get access to the most current version and when you stop subscribing you have a lifetime license for the latest major version (and it’s patches) that you’ve paid for at least a year of. The subscription helps fund the continuous development that is expected of modern software but you still get to keep something for having invested that money when you’re done.
I feel like this is the reporter choosing ambiguous words. Was this a permit to discharge into “an unnamed ditch” whose location and ownership and end destination are unspecified in the permit and so it is unclear whether this ditch is the appropriate ditch? Or is it “an unnamed ditch” located near by the property, and is very clearly this ditch, the ditch just has no name? The wording in the article could be read either way.
Edit:
Found the permit in the news article linked from the original article. It seems like the wording comes directly from from the permit (https://ewscripps.brightspotcdn.com/14/fb/2a0cdfa24e8791af37...). That reads to me though that this is then the second case (this specific ditch, which is unnamed) and not “an unnamed ditch, of which this is the wrong one”
reply