It is succesfully flying 51 year. And will work next 50 years. Systemd probably will changes syntax in next 2 years. Modern development mindset: if tool is not rewritten last month - it is outdated and we need to reinvent it. Probably using blockchanin and AI.
I don't love cron's time format - it's easy to make mistakes - but one-line, one file configuration is simple in a nice way. I bet we could make a cron that was easier but still simple.
Crontab could be confusing at first glance but 100 lines (literally) of man page have everything including examples. In my exerience they covers 99% of use cases unless you need something REALLY fancy.
And you have cron on every system including BSD and not sure but probably also AIX/Sun/etc. It is universal and everyone knows about it. If your server doing something weird your probably will check crontab, not some obscure systemd subsystem almost no one knows about.
Instead using standart solutions (POSIX by the way) systemd again found NIH problem with cron and added one more tool in init combain.
My point was purpose built doesn't mean its the best tool for the job.
As for the rest of the drivel: so what it was used for a long time. That just means it was pretty good. That doesn't mean it has to stay forever, just that a new contender should do things better.
Systemd timers address real shortcomings of cron.
Your argument boils down to: everyone should be stuck with shortcomings of the early days of computing because you don't like new things.
> My point was purpose built doesn't mean its the best tool for the job.
But you are agree cron is pretty good so it seems analogy with flying brick does not work here.
> Your argument boils down to: everyone should be stuck with shortcomings of the early days of computing because you don't like new things.
I would say: do not fix it if it's not broken. You need a really serious reason to change a good software to one with dubious quality and future. And without portability.
5:7211/1.27 here - though I think this address is long long gone. I'm gobsmacked that I can remember it. :-)
We got fidonet in Zimbabwe in the early 1990s. It was utterly revolutionary for us - more than the internet that came later really. For the first time we could communicate with my two brothers overseas without paying for extremely exorbitant international telephone calls that lasted a couple of minutes at best.
Our modem was 2400bps (8-N-1 IIRC). We used the zmodem protocol. It was after I learned about computers but I learned a HUGE amount from this about protocols etc. Our phone system was terrible so error correction etc were of great importance. Working out how to dial slowly was also important for our terrible phone exchanges.
It let me keep in touch with my pal, K, who emigrated to South Africa and as a result he ended up sending me 21 1.2MB floppy disks with SLS Linux on them and kernel 0.99 (I think). The journey began! :-)
In Harare in 1998, I remember the pleasant surprise of finding a good "internet café" in some downtown office building... Was Fidonet still active in Zimbabwe at that time, or had Internet access supplanted it already ?
"Mango", which was the name of the fidonet node, probably still existed but was on its way out. I was at university in SA by then. I know it was still around in 1996 but I cannot find all my backedup emails to see if my parents were still sending me emails from the mango fido/internet bridge after that time.
Interviewing is difficult IMO - asking imperfect people to judge imperfect people in a short time.
In my experience, which is not that great, it's the attitude that people have which is more important than the perfect answers. You're usually hiring for a team so someone who is prepared to be decent to others is essential and IMO their 10xness is much less important than this.
Then I want someone who is interested in computing or things in general - not purely motivated by the money. That sort of person who is going to try to do a good job for the sake of it and who wants to learn something new - who will be ok with doing things they're not yet experts at.
These 2 sort of areas are not easy to have together IMO. If I find people like this I am eager to work with them.
What I get from being the interviewee is that other people are not always looking for these characteristics. They're often looking for someone they can dominate. This is like my point about being part of a team but taken further obviously. In a team you cannot have everything your own way but you get to put your point across and see if you can convince others, as a peon in a feudal system you will have nothing your own way and must not only do but also say and pretend to think what you are told.
Bullshit is just really a test for whether you're amenable to being part of the propaganda. Some people have no trouble doing this but I think there's something about being a programmer that tends away from fakeness. That's not to say that we haven't got an overload of bullshitters but at the root you have to be able to make things that work.
I've been on both sides of the interviewing process and I agree with you.
It's the questions like "what is you greatest weakness?" that tick me off where an honest answer at most places will probably kill you chance of getting the job. Instead you are told that the "right" answer is to pose a strength as a weakness. I don't see the point of asking questions like these. What are you learning about the candidate from getting the expected BS response?
Ironically, I think having the self awareness to recognize your own weaknesses is a great strength, but this question subverts this.
I don't think you can really understand assembler without writing it and since compilers are fairly deterministic and get constant attention most of us using them haven't truly had to fight with what turned out to be a compiler bug.
Whereas LLMS regularly produce shit. One can excuse them for not understanding one's turn of phrase or whatever but it amounts to the same problem in the end - you have to understand the output language a lot better than most people ever had to understand assembler.
It's now being used by a lot of people because they have to rather than want to so there is a desire to ** it up and reinvent their favorite language by adding all sorts of warts. That's the price of success.
A proper revenge would be to introduce "easy mode" to Rust - where the compiler takes a huge chill pill and you get non-enforced garbage collection. :-)
reply