Since the zone is is device specific, it doesn't make sense to send it over the wire in html links or a host header, bit it does seem like it could be used in the url bar, at least.
I wouldn't say that the PATH is ambiguous, but cron does have some problems with PATH:
- the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root.
- on some distributions (for example Arch Linux) the man page doesn't even say what the default path is, or recommend setting it.
- if you need to add something to the path for a single script, you either need to wrap it with a call to env, set it in a wrapper script, or set the path before the entry and reset it afterwards
- you can't use ~ or $HOME in the path, you have to write out the full absolute path. Which is particularly annoying for user crontabs.
Sure, it isn't too hard to work around those, but IMO systemd timers are a better experience, especially since the default uses the same path as all your other services.
> - the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root.
What do you mean by "you would expect", that doesn't also apply to systemd timers? /opt/foo/bin is not in the path. Would you expect that?
And if this is an objective problem, can we just change the cron default PATH?
> - on some distributions (for example Arch Linux) the man page doesn't even say what the default path is, or recommend setting it.
Send a PR. This doesn't seem like an inherent problem.
> - if you need to add something to the path for a single script, you either need to wrap it with a call to env, set it in a wrapper script, or set the path before the entry and reset it afterwards
Or on the line, right?
* * * * * FOO=bar $HOME/bin/foo.sh
The line can get long, but is this really a problem?
> - you can't use ~ or $HOME in the path, you have to write out the full absolute path. Which is particularly annoying for user crontabs.
This is incorrect. You can definitely use $HOME in user crontabs.
I'm still not seeing something that warrants a rewrite. (except what you did not mention, which is the ability to run "trigger this now" as a missing feature)
I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.
I don't really expect /opt/foo/bin to be there, but if you want to have it available by default everywhere then you can just add it to systemd once, rather than having to remember to add it to crontab as well.
> Or on the line, right?
Oh you're right. I forgot cron evaluates the command with the shell (which has its own set of issues...)
> This is incorrect. You can definitely use $HOME in user crontabs.
You can in the command itself, because that is evaluated by a shell, but not when setting an environment variable. From the Ubuntu crontab(5) manpage:
> The value string is not parsed for environmental substitutions or replacement of variables or tilde(~) expansion
Maybe it depends on the cron implementation though. The cronie documentation doesn't say either way.
> I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.
So changing the default PATH for cron requires a green field rewrite? You would expect /usr/local/bin. cron doesn't include it. It seems like a disagreement on default settings. I would agree with you about what the default should be, but I don't understand how this has anything to do with cron either as code or architecture.
This seems a bit like /sbin being missing in the default PATH for the root user's regular shell being a reason to rewrite bash to systemd shell.
For a large project with dedicated resources that is pretty reasonable. And GitHub issues probably isn't sophisticated enough for you anyway. But for a small to medium open source project, that's a lot to set up and manage, and in the case of gerrit, you have to host it yourself.
And then for Youtrack, Jira, Confluence, etc. You still have the same problem where it is difficult to migrate to a different system, because the data is all stored in a proprietary format that can't easily be ported to something else. For the wiki, there are somewhat standard formats used by multiple systems, like markdown and mediawiki. But for issues, I don't know of any standardized format, and migrating from one product to another is going to be pretty difficult.
I'm doubtful a dev was involved in this at all. More likely someone set up the AI support system and gave it access to existing support tools without thinking through how that could go wrong.
I've sort of reached this point, because I've reached the highest point for an "individual contributor". I do not want to be a manager, and don't think I would be good at it. But at most companies, once you reach a certain point, that's the only way to move up. And I've seen people who are good engineers get promoted to managers where their skills are less beneficial.
Thankfully, my company is pretty good about still giving me raises.
From what I can tell, that's already the case for these subscriptions. They give you some extra stuff but you're still getting ads, and they are still collecting your data
If it's high value, there isn't really much you can do that will be completely effective. Traditional captchas can often be beaten by AI, or by "captcha farms" where impoverished people are paid pennies to complete captchas. Fingerprinting can be beaten by using a full browser to make the requests. Basically anything you do is just a matter of making it more expensive for bots to access it.
Beating fingerprinting and beating traditional captcha is far more expensive than solving pow. Pow doesn't stop anyone, not even the most novice bot operators
The truth is, there's something about the vibe coder hive mind where they all create the same thing. Everyone is working on the same thing. There's hundreds of projects like this where the creator thinks they've created the most unique powerful thing.
I think it demonstrates how overuse of LLMs for brainstorming/planning and building destroys creativity. That zeitgeist changes from month to month, but when a vibe coded "AI Native" project gets released you'll always see dozens of people in the replies talking about the identical project they've also built or are working on.
I also notice this in my own work, the people who have most eaten the LLM brainworm will come to me asking for us to build the same projects. They all eventually converge to wanting some sort of power user app (like this) that can just do everything because AI is magic to them and there's no reason why it can't do everything.
I hate Peter Thiel but he has that famous quote form years ago where he says not to build the obvious thing because the obvious thing isn't special, so maybe this has always been a phenomenon.
I think the thing is users run into the same problems (barely desirable tool UX), and arrive at very similar solutions (but with their own small twists and preferences). And now that the barrier to make things is essentially gone, they jump in and make things that git their own desires week because nothing out there was an exact fit.
Like I found a really cool project a few weeks ago that I started using and even made a few QoL changes to. Then I thought of the many other changes I wanted, and that the project was written in a language I'm not familiar with (Rust), and I started a port in what I know well (Python) so that I'll be able to actually review the code if needed and generally make better architectural decisions.
Yea good point, the branding clause is a real gotcha, technically "open source" but with that restriction baked in, which makes it source-available rather than properly free under the OSI definition. A lot of people don't realize until they try to fork or rebrand it for a team/customer deployment and hit the wall.
Conifer (launching tomorrow, June 1st) goes the other way on this, properly open source with no branding strings attached, so you can actually fork or rebrand if you need to. Local AI runtime + IDE, native on Mac/Linux/Windows: conifer.build
Class action lawsuits usually end up with settlements where the offender pays much less than the harm they caused, and those harmed get almost nothing. Even if it does go all the way to a court verdict, the sentence is usually insufficient. And the process is long and expensive.
I don't really know what the solution is, but the current system clearly isn't working. And I don't think it was really designed for the scale of mega corporations with hundreds of thousands or even millions of customers.
reply