It makes a lot of sense for businesses to seek to reduce their costs wherever they can. But, from what I've heard about brick and mortar distribution, you used to pay quite a bit more and get a lot less than what Steam gives you.
From what I can tell, that 30% cut gets you -for the rest of forever-
* distribution for both the current version of the game and some number of older versions you choose to make available [0]
* a place in their searchable games index [1]
* "cloud" storage for your players' savegames
* basic forum and blog hosting for discussion of and news about your game
From what I could tell as someone who used to buy games in retail stores, in a bricks and mortar distribution unless you were -like- the Starcraft/Diablo/Warcraft boxed set, you got like maybe a half year of time on the shelf. I've heard folks say that you had to pay a 50->80% cut for that.
[0] Valve will even distribute games that don't work anymore. This is both good and bad, but Steam's no-hassles refund policy combined the existence of unofficial patches that make games work on current versions of Windows make me generally fine with charging for and distributing games that no longer work as-is.
[1] ...at least until the wrong horde of pearl-clutching busybodies demand that credit card companies require your game be erased from the commercial world because it is art that discusses those busybodies' bugbear du jour
As a user of both EGS and Steam, the one thing that EGS doesn't have that Steam does is multi-threaded downloading. Steam can saturate any connection I've thrown at it, whereas EGS gets a few-hundred mbit/s and saturates a single CPU while doing it.
Perhaps game devs get a whole bunch of "gee whiz" features from the Steam Platform that Epic Games doesn't provide, but I -personally- couldn't care less about those.
> You don't need multiple threads to saturate a gigabit connection. Even many embedded SoCs can do it.
What I've observed is
* when Steam downloads are in progress, between four and nine logical CPUs worth of processing power on my 32-way Threadripper are being used and zero logical CPUs are running at 100%
* when EGS downloads are in progress, exactly one logical CPU on that Threadripper is pegged at 100%
It's true that you can do gigabit downloads without having a multithreaded downloader. [0] But it seems to be true that the two biggest PC-game-store clients absolutely cannot... for whatever reason. Given the prevalence of gaming machines that have CPUs with four or more logical CPUs, I expect it's not really worth the effort to make whatever Steam is doing single-threaded, or whatever single-threaded thing EGS is doing fast enough to saturate a 1gbit+ download.
> ...burning ten thousand tons of toxic e-waste annually...
Expressing water usage in gallons makes it seem really large, too. NASA says[0]:
Scientists estimate that about 48.5 tons (44 tonnes or 44,000 kilograms) of meteoritic material falls on Earth each day.
If we assume that they're all the heavier v2 units, the total mass of the orbital portion of Starlink is ten point four tons. [1] If we assumed that they lasted one year (instead of the five that they're reported to last[1]), then over the course of a year, Starlink would dump six hours worth of asteroid collisions into the atmosphere.
I think we'll be fine. Pour all that frustrated energy you have into substantially reducing the amount of incredibly hazardous d-waste [3] big commercial operators burn up into our atmosphere, instead.
I think you missed a factor of 1000 somewhere in there: Each satellite weighs about 1 ton, there are about 10,000 of them. That is 10,000 tons in orbit for the constellation, not 10. Assuming a 5 year decay, that's 10000/5/365 ~= 5 tons / day. Still about 10% of the natural incoming material, but considerably more than your "six hours worth per year".
> I think you missed a factor of 1000 somewhere in there... there are about 10,000 of them. That is 10,000 tons in orbit for the constellation, not 10.
I did. what. the. hell? Maybe my swiss-cheese brain read the "," in 10,413 as a decimal separator? I guess that's what I get for posting while old. Thanks for the correction and supporting arithmetic.
Though, I still stand by my "please for the love of everything, get to complaining about CO2 because this thing you're complaining about is a damn nothingburger" conclusion. (I am sufficiently aware to notice that that you're not OP, so the "you" in that pseudoquote is not directed at you.)
You think the toxity and dangers of materials are defined by the atoms the materials are made of rather than the molecules? Swimming in a ocean of Hydrogen-Oxygen salted by Sodium Chloride must feel dangerous..
Also the toxic fumes from burning batteries don't really come from the lithium but everything else the batteries are made of.
> Meteorites don't have any of toxic chemicals used to build a server with ... solar panels
Right. The toxic chemicals found in solar panels known as silicon, aluminum, copper, and trace amounts of lead. These chemicals are only found in fuming Earthbound laboratories, and are nowhere else in the universe.
Hello! I'm a USian, so my telecom situation might be really weird when compared to the rest of the world, IDK.
> It’s better than SMS...
If it guarantees timely and in-order delivery, then yes, it's better than SMS. If it doesn't, no matter what else it does it's just as bad.
> ...and is the new industry standard.
Odd. The only RCS messages I receive are spam. Literally zero legitimate entities send me RCS messages.
Plus, I heard that Google's shipping this "Feed us more metadata about who you're calling and when!" service that's billed as a "Ensure the caller calling you is actually on an Android(TM) or iPhone(TM) phone!" "safety" feature. No thanks.
Don’t use it if you don’t want. I’m not some kind of RCS salesman. I usually use third party apps myself. That doesn’t mean it’s not an upgrade versus SMS.
Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files. Looking around, it seems like folks running Dialyzer against Elixir code are using some "dialyxer" thing.
You talk about circular dependencies causing minor compilation troubles, so it doesn't sound like you're talking about types defined in terms of each other. I might be unaware of something important, given that I've never had the opportunity to do Erlang professionally [0]... but aren't the only "dependencies" of BEAM files the exported functions they call in other modules? If I'm not wrong about that, then what happens when you run Dialyzer against BEAM files compiled from Elixir that has circular dependencies? Do its reports become more reliable, or does the reliability of those reports become irrelevant because the transformations the Elixir build system makes to your code make the structure of the BEAM code difficult to trace back to the Elixir source code?
[0] ...and have written nearly zero Elixir in any context...
> Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files.
Once compiled, it boils down to BEAM files that Dialyzer can understand, yes.
And the [Dialyxir](https://dialyxir.hexdocs.pm) wrapper helps translating error messages in Elixir.
But, there is a significant limitation compared to plain Erlang: Elixir protocols (which are quite used in core parts of the language) are not an Erlang construct, so Dialyzer will be clueless about them, just accepting any term. Enum.map(nil, & &foo/1) or to_string(%{}) will be invisible to it.
Ah. So I assume that Dialyxir does some sort of patch-up or correlation or enrichment or whatever you want to call it between the results dialyzer pulls out of BEAM files and the Elixir-specific type-and-other-metadata that Dialyxir has access to?
That sounds complicated, but so's Dialyzer. Hopefully the Dialyxir people are having a fine time working on it.
Dialyzer (and Dialyxir) were written prior to compiler tracing, and also are based on Erlang's "Typespec" syntax which is a bit lacking.
I still use the Typespec syntax for its documentation benefits, and for catching "dumb" bugs, but as the Elixir compiler has improved I have found Dialyzer to be less relevant as the compiler usually catches things before Dialyzer would as it's not built into the compiler and isn't able to be.
There's dialyxir which is wrapper to Dialyzer and I found it work fine on pure (non Phoenix) code.
As for how the problem manifests: even obvious contract violations stops being shown (making it feel like "Dialyzer is useless") but the second tell is very long check times (tens of seconds up to minutes).
[W]hat happens when you run Dialyzer against BEAM files compiled from Elixir that has circular dependencies? Do its reports become more reliable, or does the reliability of those reports become irrelevant because the transformations the Elixir build system makes to your code make the structure of the BEAM code difficult to trace back to the Elixir source code?
1) Your production equipment doesn't have its TZ set to UTC? Enjoy dealing with the intermittent and irregular hassle of DST changes, I guess.
2) From the crontab(5) on my system:
The CRON_TZ variable specifies the time zone specific for the cron ta‐
ble. The user should enter a time according to the specified time zone
into the table. The time used for writing into a log file is taken from
the local time zone, where the daemon is running.
If you have a job you need scheduled in a different timezone, dump a new file in /etc/cron.d, alter its CRON_TZ variable and go to town, as it were.
1) It's supported by cronie. I bet it's supported by many other crons.
2) "Great" news! The software in the Systemd Project only officially runs on Linux, so "it's not portable" is a really bad counterargument when "alternatives to some Systemd Project feature" is the discussion topic.
> In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command
Nope. From crontab(5)
The RANDOM_DELAY variable allows delaying job startups by random amount
of minutes with upper limit specified by the variable. The random scal‐
ing factor is determined during the cron daemon startup so it remains
constant for the whole run time of the daemon.
That's from my cronie install, but it looks like this has been a feature of some crons for at least a decade. (Notice that the post date of [0] is in 2016.) Given that cronie is based on vixie-cron, and I think I was was using vixie-cron in 2002, I bet it's been a thing for at least twenty years.
[1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.
I found the systemd time spec syntax you referenced to be logical and well thought out.
Cron syntax is simpler for the easy cases because cron tries to do less. It ignores years and seconds entirely, and doesn't try to adhere roughly to ISO8601 ordering and field separators, instead using space universally for field separation and euro-style least-to-most significant field ordering. I like ISO8601, so I get along with systemd's style better, despite it introducing slightly more cognitive load.
The only thing that threw me for a loop and seems like "special magic" was
> "Mon *-05~07/1" means "the last Monday in May."
But good luck doing that in one line in cron.
Some cron-style libraries seem to support L/W/# for last / nearest-weekday / nth of month, but I don't know if any system crons do. (cronie? dcron? I don't think so. fcron? bcron? I don't see it there either.) '#' is syntactic sugar for DOW + 7-day range, while L is covered by the above quoted syntax.
If your cron has that kind of syntax, then for a case like "weekday closest to 1st of month", "W" is more convenient than writing 3 systemd timer rules to cover the three cases (weekday day 1, monday day 2, friday last day of month), but that's a big if. Generally you'd have to write 3 rules in cron anyway.
> I found the systemd time spec syntax you referenced to be logical and well thought out.
I found this amusing when in combination with
> The only thing that threw me for a loop and seems like "special magic" was
but -regardless- a careful reader notes that I never said that the Timer scheduling syntax was illogical or poorly thought out. It's at least as complicated as crontab-style time syntax, which was my entire point.
Related: Not that it's ether part of the core scheduler syntax or necessarily as nice as having it in the core syntax, but my crontab(5) suggests that one can use things like date(1) to get more fine-grained control over the time of execution:
As noted above, skip values only operate within the time period they´re attached to.
For example, specifying "0/35" for the minute field of a crontab entry won´t cause
that entry to be executed every 35 minutes; instead, it will be executed twice every
hour, at 0 and 35 minutes past.
For more fine-grained control you can do something like this:
* * * * * if [ $(expr \( $(date +%s) / 60 \) % 58) = 0 ]; then echo this runs every 58 minutes; fi
0 * * * * if [ $(expr \( $(date +%s) / 3600 \) % 23) = 0 ]; then echo this runs every 23 hours on the hour; fi
Adjust as needed if your date(1) command does not accept "+%s" as the format string
specifier to output the current UNIX timestamp.
While I expect that you're not one of those people, I know that folks who are accustomed to working with extremely inflexible tools forget (or never learned) that these sorts of things are possible. I'm very aware that people sometimes cut off their own limbs with power tools, but that's not a good reason to ban their use.
Obviously you can do additional time & date checking in a shell wrapping the script or binary cron ultimately runs, just as you could do the time & date checking in the script or binary itself. That's far more complex.
Systemd enables cleaner, simpler syntax for common cases. Instead of "59 23 * * *", simply "23:59". Instead of "0 0 * * sun[day]", simply "sun[day]". 1st of the month and don't care exactly what time? Instead of "0 0 01 * *", simply "*-*-01".
Systemd started with the principle that they wanted to accept ISO8601 timestamps, then extended that with lists, increments, ranges. They developed that into a superset of basic cron capabilities, while maintaining similar syntax as best they could for increments and lists; they diverged for ranges and nth-from-last because those conflicted with the - date separator. They repurposed the little-used ~ cron randomization operator in the process. (systemd uses a separate RandomizedDelaySec line for that, which is also arguably superior because it randomizes per trigger, not on initial load of the timer)
The alternative is how AWS does it. They have separate cron() and at() syntax. at() takes timestamps. cron() takes cron+quartz syntax, mangled to remove seconds. They also have rate(value units), because apparently cron syntax is too complicated for most people. I'm sure in theory they did it to support "every 7 minutes" cases. I bet if you surveyed actual rate() AWS schedules, 99% would be cases that evenly divide a larger time unit, and could therefore be implemented with cron().
Cron syntax is more of a mess than I thought. While basic system crons don't support any advanced features, AWS and Cloudflare have adopted LW# capabilities, derived from quartz job scheduler syntax (Cloudflare references quartz explicitly). Quartz has extra fields for seconds and year (year optional, so it must go last, which breaks d m Y sequencing) so its syntax has 6 or 7 fields vs the standard 5. CF uses 5 fields, no seconds or years. AWS uses 6 fields, years but not seconds. Whenever you interact with cron-derived systems, you have to remember not just whether they support quartz-style syntax, but whether they support seconds and/or years. Is that really simpler?
The one feature I found interesting, "W", may not work the way I anticipated according to quartz's documentation. I thought "nearest weekday to the 1st of the month" might be useful because it maps to some billing cycles, but quartz (at least through 2.3) couldn't do that. The 2.3 docs say that 1W, if the 1st falls on a Saturday, triggers on the 3rd because it won't jump backwards over a month boundary. That was my only interesting use case for "W". Systemd does everything else, though it requires more verbosity in some cases, it's simpler in many others. 2.4/2.5 are from the last couple of years, and their docs are restructured and don't mention that, so maybe it was finally fixed? I'm not about to install java crud to test.
I didn't find the *-*~01 syntax that strange (last day of every month). The "fri *-*~07/1" syntax for "last friday of every month" is what I found magical, but it makes sense now that I've thought about it more.
What would you prefer for 3rd friday of the month? Cron (5-field, quartz syntax)
0 0 ? * fri#3 (special syntax is needed because cron uses logical-or to combine day and weekday fields)
or systemd
fri *-*-15..21 (works because systemd day and weekday are joined with logical-and)
> Systemd enables cleaner, simpler syntax for common cases.
I disagree. It's all a matter what you're accustomed to. On top of that, what's at least as important as clear syntax for simple cases is the establishing of a handful of rules that well serve both the simple and complex cases. Consistency that leads to complicated cases being made easy should not be avoided just to make the simple cases extremely welcoming to the newcomer. Note that I'm not saying that 'systemd-crond' falls into this trap, but I am saying that oh so many tools that aim to be "approachable by newcomers" enthusiastically throw themselves into it.
> Cron syntax is more of a mess than I thought.
Nah. It's just there are a very large number of cron implementations. If The Systemd Project were actually a thing that people could make an independent reimplementation of, we'd see at least as much inconsistency in 'systemd-cron' scheduling syntax as people extended it in their reimplementations to meet their needs.
> What would you prefer for 3rd friday of the month? Cron (5-field, quartz syntax)
I don't understand why the "day of month" column has a "?" instead of a "*", and I don't understand why "fri#3" isn't rendered as "Fri/3", but whatevz. I prefer that to the systemd syntax.
FWIW, I think you can directly translate your systemd scheduler line into this for most crons:
* * 15-21 * Fri
Edit: Oh, no, you cannot. From crontab(5)
Note: The day of a command’s execution can be specified in the following two fields — ’day of month’, and ’day of week’. If both
fields are restricted (i.e., do not contain the "*" character), the command will be run when either field matches the current time.
For example,
"30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.
Hm... Yeah, the handling of the "day of week" column is a terrible wart on the rules.
I think you're talking about syntactic simplicity. Systemd requires three field separators (space, :, -) because that's how ISO8601 dates are written. That means not all fields will be space separated, which may be more challenging to visually parse. It's not going to look as clean. Is that what you mean?
Everything else is simpler. You don't have to count fields to figure out whether you're dealing with a day vs a month, or an hour vs minute, no matter how the fields are aligned or how long or complex they are. You can scan left and right and look for space and dash and colon to figure out where you are. The formats for time and date are distinctive and ubiquitous. You don't have to guess what you're looking at when you just see one of them in isolation.
Very little follows from cron's format. You have to learn which fields are which for your particular implementation: does it include seconds? You have to learn the bizarre interaction between day and weekday, to do something non-trivial with them. You have to carefully keep track of which field you're in because you can't determine that from neighboring syntax. The visual clutter, if you want to call it that, of systemd's iso8601-based syntax only applies if you're doing complicated rules. In the vast majority of cases it would simply be an ISO8601 timestamp with various values replaced with *'s, and at most one /.
That first impression you had is what I thought too, before diving into it for my previous replies. But no, cron logic is that day and weekday are ORed. It lets you do clever things like run a script on the 1st and 15th of every month, AND on mondays, all in one line. I don't think I've ever seen such a thing in the wild. I'd go so far as to say it's stupid, because it's likely to be misinterpreted if anyone did use it that way. All the other fields are ANDed. I would say that systemd's AND logic is better... and more consistent, which is your own acceptance criterion.
> It's not going to look as clean. Is that what you mean?
Nope. I don't give a shit how "clean" something looks, [0] I just care how difficult it is to learn and either retain or remind yourself of the syntax when you need to do something complex with it. In that regard, [1] systemd-crond's scheduler syntax is at least as complicated as that of most crons'.
> You don't have to count fields to figure out whether you're dealing with a day vs a month, or an hour vs minute, no matter how the fields are aligned or how long or complex they are. You can scan left and right and look for space and dash and colon to figure out where you are.
So, you have to learn a tool-specific format. Just like you do for crontab. I've read both man pages, and I'm 100% unconvinced that systemd-crond's scheduler syntax is actually simpler. I do agree that it can express specific schedules that one cannot in the syntaxes used by most cron implementations.
> Very little follows from cron's format. You have to learn which fields are which for your particular implementation:
Sure. And I expect that exactly nothing other than systemd-crond uses its weirdo syntax. And -as I mentioned in the comment you're replying to-
Nah. It's just there are a very large number of cron implementations. If The Systemd Project were actually a thing that people could make an independent reimplementation of, we'd see at least as much inconsistency in 'systemd-cron' scheduling syntax as people extended it in their reimplementations to meet their needs.
> But no, cron logic is that day and weekday are ORed. It lets you do clever things like run a script on the 1st and 15th of every month, AND on mondays, all in one line. I don't think I've ever seen such a thing in the wild. I'd go so far as to say it's stupid...
On this I agree with you. Changing the rules for the Day Of The Week column (but only when it's used in combination with the day of the month column) is catastrophically idiotic. The only time I've ever had need to use the DoW column was to schedule something to run weekly... so I've been blissfully unaware of how incredibly idiotic that behavior is.
[0] If anything, I've noticed a strong inverse correlation between how "clean" a syntax is regarded to be and how easy it is to both do complicated things with it, and come back to those complicated pieces of work six+ months later and be able to understand what the hell you did.
[1] With the notable exception of cron's DoW column.... read on for further discussion.
I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. Mine is: why not migrate since they're both "weirdo" syntax, and systemd's is at least based on ISO8601 and has integration with other systemd features.
Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fields, the syntax becomes ambiguous... not to a parser, but to whoever's reading and writing the lines, unless they already know the exact cron variant in use. Google, the one large cloud provider that seems to have stuck with basic cron syntax without quartz-scheduler extras, even invented their own pseudo-natural-language scheduling syntax to fill in for features cron lacks, or for people who don't like cron syntax.
Systemd's is definitely novel, but as I keep repeating, it's ISO8601 + cron. An alternative would be some extension to ISO8601 interval syntax, but that looks clunky and has probably never been used outside of niche applications for data interchange, probably inside xml files; it's used in https://docs.cibseven.org/manual/2.0/reference/bpmn20/events... (syntax at https://en.wikipedia.org/wiki/ISO_8601#Durations ). I think systemd's syntax is better than that.
The direct benefits, even if cron syntax suffices: Calendar timers are integrated with systemd, with all its process-management capabilities[1]. Unifying to systemd timers also avoids duplication of functionality ("is this scheduled process managed by systemd or cron?"). Cron doesn't let you `systemctl list-timers --all`. You'd have to grep through cron logs, possibly (and ironically) using journalctl, or have those logs already in a management dashboard, and that still doesn't let you see the next time the timer would fire. Cron also doesn't let you beta-test cron lines like you can with `systemd-analyze calendar --iterations 10 "Fri *~8..14/1"`
There's even a systemd-cron translator/generator that's in the official debian/ubuntu repos, and in Arch's AUR of course, which avoids the need for system cron but allows you to retain existing crontabs by importing them as systemd timers. They won't be quite as well integrated because it uses defaults for task names and other parameters, but the crontabs get run... without cron.
> I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax.
I'll repeat my opinion, as expressed in my first post:
To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example:
Mon,Fri *-01/2-01,03 *:30:45
Who'd ever want to go back crontab format for nontrivial scheduling? [1]
[0] <https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html#Calendar%20Events>
[1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.
The first one works in that specific case, but not more generically. For example, "Last Monday in February", or "last Monday of the month" for multiple months unless they're all 30 or all 31 days.
This was fun to cook up and may (or may not!) break if one's locale changes:
# Run a command on the last day of the month. Only starts checking at midnight towards the end of the month. Assumes GNU date, which is fair if we're discussing a Linux-only cron-alike.
0 0 28-31 * * if [ $(date +\%d) -eq $(date --date="$(date +\%m)/1 + 1 month - 1 day" +\%d) ]; then /usr/local/bin/runCommand.sh; fi
I bet one could do something similar to determine if we're at the "last $NAMED_WEEKDAY in the month" by counting ahead a week and seeing if the month name changes.
If I were doing this for real, I'd either switch to a more capable cron, or take a serious try at the date math and then wrap it up as a standalone helper. Or I guess I'd look to see if someone already built that helper. ...I guess...
I am curious whether there's a more capable system cron that supports that kind of thing. Quartz job scheduler (java), AWS, and CF obviously wouldn't qualify. I think this is only possible if you're using a heavyweight job scheduler like those. Or... systemd.
It ultimately doesn't matter "for real", because almost nobody without some horrific legacy system to integrate with would need to use anything more than lists, ranges, and increments. There's a reason nobody's added these features to system crons. Clever trigger times for events that don't really need to be triggered at clever times... sure, but lacking that capability wouldn't change anything, the trigger would just be a more boring one.
Events like "last Friday of the month" or "nearest weekday to the 1st of the month" or even "Friday the 13th" are more for business logic, not system crontabs.
> I am curious whether there's a more capable system cron that supports that kind of thing.
I am no cron scholar, nor am I young enough to have the energy required to do an exhaustive survey... so -sadly- I don't know of one. It seems like there'd be one being used internally in at least one business in the world, though, yanno? That just seems like the sort of thing that at least one bored programmer would take a few days to crank out.
> Events like "last Friday of the month" or "nearest weekday to the 1st of the month" or even "Friday the 13th" are more for business logic, not system crontabs.
Oh quite possibly, yeah. But, system crons are quite fine for one-shot things that are re-run on a regular schedule... as well as things that don't have complicated scheduling and/or retry requirements. If you're working on a Big Enterprise Project [0], then you're almost certainly going to have a scheduler inside of you, and -IME- you're very likely to use it to do a lot of that BEP's scheduled tasks. [1]
[0] Or a tiny one wearing the clothes of a BEP
[1] ...if for no other reason than it requires little effort to get the BEP's data and code into its internal scheduler, and can be a huge pain in the ass to get it into an external one.
Looking at the other examples on that page, I'm gonna say that it's only arguably easier to read for basic stuff... especially if you're familiar with the syntax. The complex stuff is -at best- just as difficult.
> That does require you to still know what the default environment is, but it is a mostly completely clean environment, without any influence from any shell.
Odd. This script
#!/bin/bash
set > /tmp/set.txt
when scheduled like so
* * * * * $HOME/bin/testCronScript.sh
Produces this file in /tmp/set.txt which has had a handful of values (HOME, UID, etc) lightly redacted prior to posting here -to remove PII or for length- but its keys are entirely untouched:
Seems pretty clean to me. Even when I run this via /etc/crontab, rather than as a user cron job:
* * * * * root /home/user/bin/testCronScript.sh
I get effectively the same results.
Maybe your distro's default cron environment was bad, and you never bothered to check and unset the badness? I'd be surprised if they were unable to make the default environment for Timer Units to be bad.
Regardless of exactly how clean the environment is, my favorite part of systemd is the fact that there is only one regardless of how something was triggered. Whether a unit is triggered via a mount unit, timer unit, udev rule, it's the same units at the end, so it's the same environment.
The same problems that could be caused by a polluted environment in cron can be caused in reverse by a polluted environment elsewhere, when you unwittingly copy a command that depends on some environment being set. If you are using systemd as the service manager, this necessarily doesn't happen because it's all units. (Well, you could still copy something from outside of systemd and run into a similar problem, but at least there's essentially only one set of caveats you have to learn for whatever thing you want executed in the background.)
So I guess this isn't so much cron vs systemd timers, but more cron + other init and service supervisors vs systemd init in general.
> Regardless of exactly how clean the environment is, my favorite part of systemd is the fact that there is only one regardless of how something was triggered. Whether a unit is triggered via a mount unit, timer unit, udev rule, it's the same units at the end, so it's the same environment.
>
> The same problems that could be caused by a polluted environment in cron can be caused in reverse by a polluted environment elsewhere, when you unwittingly copy a command that depends on some environment being set.
I'm confused about what you need this for? Are you running some utility command that needs the same environment provided by the daemon's service file? If so, any competent init system lets you extend upstream-provided service files. In OpenRC:
So, if you need to do maintenance for a service on a schedule in the same environment that is provided for starting that service, you can simply extend the service script and use cron to execute that functionality.
But. Another thing that confuses me is why you think that SystemD [0] provides anything special here? If you were to create a service file in most any other service manager and start it with cron, you'd get exactly the same environment sanitization as you get for all other services. Given your testimony, I expect that prior to SystemD, you'd have refused to create service files for things like one-off jobs that weren't system services... so why are you okay with it now that you're using SystemD?
[0] I spell it "SystemD" not to mock it -as I understand some do- but to distinguish The Systemd Project from systemd(1). It sucks minor ass that the two share the same name, but what can you do?
From what I can tell, that 30% cut gets you -for the rest of forever-
* distribution for both the current version of the game and some number of older versions you choose to make available [0]
* a place in their searchable games index [1]
* "cloud" storage for your players' savegames
* basic forum and blog hosting for discussion of and news about your game
From what I could tell as someone who used to buy games in retail stores, in a bricks and mortar distribution unless you were -like- the Starcraft/Diablo/Warcraft boxed set, you got like maybe a half year of time on the shelf. I've heard folks say that you had to pay a 50->80% cut for that.
[0] Valve will even distribute games that don't work anymore. This is both good and bad, but Steam's no-hassles refund policy combined the existence of unofficial patches that make games work on current versions of Windows make me generally fine with charging for and distributing games that no longer work as-is.
[1] ...at least until the wrong horde of pearl-clutching busybodies demand that credit card companies require your game be erased from the commercial world because it is art that discusses those busybodies' bugbear du jour
reply