You can also skip the subshell invocation of date by using %(fmt)T from bash's printf:
%(fmt)T -output the date-time string resulting from using FMT as a format string for strftime(3)
The man page provides a bit more detail:
%(datefmt)T causes printf to output the date-time string resulting from using datefmt as a format string for strftime(3). The corresponding argument is an integer
representing the number of seconds since the epoch. Two special argument values may be used: -1 represents the current time, and -2 represents the time
the shell was invoked. If no argument is specified, conversion behaves as if -1 had been given. This is an exception to the usual printf behavior.
It happens... I can think of a couple that bit me in the last 5 years or so. Some of them felt like bugs but were flagged as new features in later releases like this one from 4.4... spent way too long trying to figure out why this worked under 4.4 but not 4.3 and didn't even consider a bug, let alone a feature at the time. I was convinced it was something I did wrong :P
"a. Using ${a[@]} or ${a[*]} with an array without any assigned elements when the nounset option is enabled no longer throws an unbound variable error."
I switched from a Mac to a Thinkpad running Pop a bit over a year ago.
I miss the Mac trackpad and gestures. I miss the trackpad size and the surface itself. Wiring up libinput-gestures helps some things but you still don't get things like pinch to zoom in Chrome, for example, and the overall experience is not nearly as polished.
I miss Mac OS HiDPI support as well. Fractional scaling helps a bit, but switching from HiDPI to LoDPI and vice-versa (docking/undocking) can leave some apps scaled incorrectly, make a mess of your desktop, and I haven't been able to get a mixed configuration working where only my laptop monitor is scaled while my external display is not. I end up running this 1440p laptop screen at 1600x900 or 1920x1080 instead just to forgo the headache.
The VPN clients we use at work were much more pleasant to use on macOS. We have the option of using one of two different OpenVPN solutions as alternatives, and they're fine, but again, the polish isn't there (little things like automatically reconnecting to the VPN without my intervention would be nice).
I can't really think of anything else I'm really missing these days, though. Things I explicitly DON'T miss: Docker on Mac is a poor experience compared to natively running on Linux... Having a real Linux userspace by default is SO much more pleasant than dealing with Homebrew (which is great if you absolutely need it but I'm happier not having to deal with it at all anymore). I don't miss the Mac keyboard and touchbar. I don't miss troubleshooting things on macOS... it is incredibly opaque in comparison.
Overall, I don't think I'll be switching back any time soon, but would love to see more attention to the overall fit and finish as far as the desktop experience goes.
It's much improved by 19.10 on my machine, which IIRC went from libinput 1.12 to 1.14. The thumb detection (which was wrong just often enough to be torture) in Pop 19.04 is pretty solid in 19.10.
But then again I don't use anything fancy beyond one- or two-finger gestures. If you want all the fancy gestures, I can't really say much about that.
FWIW, the stock kernel (and HWE/HWE-edge kernels) recently picked up current ENA drivers. ixgbevf, unfortunately, doesn't look like it's been updated in-tree so it still lags behind Amazon's recommendation (currently 2.14.2, whereas Xenial's in-tree driver claims to be 2.12.1 and Trusty has 2.11.3).
It's not a high-traffic area at all (I'm at the other end of his row, and I've got a high-traffic seat w/ high walls to block visual "noise").
While I would prefer an office (solo or shared with a few), we're given enough options that in general, it's not bad at all.
We haven't done much in the way of modification of Jenkins, and the big ball of plugins and configuration (with the associated deadlocks from bad plugins and some bad core Jenkins foo) is now 25 smaller balls of plugins and configuration. We're looking at ways to manage the new pain and are considering a number of routes from writing some tooling to help manage the world, introducing a smaller CI system that handles the very basic cases with Jenkins for more complex solutions.
Our biggest problems are probably plugin creep (and the poor state of plugin maintenance in some cases), the cluttered UI with chunks of configuration hidden behind "Advanced" buttons, the inability to store job configuration with code a la Travis (which may be better with workflow), and handling routine maintenance across shards (without something in place like Operations Center), API inconsistencies (and the inability to fully manage via the API, forcing things like Groovy scripts over Jenkins remoting...).
Once we have some direction on where to go, I'm sure we'll follow up with some more blog posts and share things at our meetups.
I recommend, strongly, looking into Concourse. It's well suited for this sort of case, because that's why it was built.
I've seen pipelines with hundreds of inputs (an embedded software company), others with over a dozen stages (other teams at Pivotal), both kinds with fan-in/fan-out as necessary. Today I even saw a generic pipeline that could test and build identically-structured product files in a uniform way across quite different products (Redis, Apache Geode etc).
People have written resources (the main means of extension) in Go, Ruby and Python so far. If you can put it in a Docker image and execute it, then it can be taught to behave like a Concourse resource.
So far it's working well for us and others trialling it. I am very bullish about the future of Concourse.
My first approach was as an individual, which was quite difficult, because it took me a while to work out the differences between jobs and tasks and how to lay it all out. Lots of copying and pasting from other pipelines I studied.
At this point pretty much every team in Pivotal's Cloud Foundry division is running a Concourse pipeline, including the one I belong to. What's been interesting is how each team is experimenting with patterns that Concourse makes possible.
For example, I and my peers are now turning various things into "executable documents" -- the terminology sucks at the moment. Think of all the stuff buried in READMEs and wikis and long-forgotten cron jobs. How to build that special docker image that you only update every few months. The database backup. Keeping the blue-green deploy codepath warm.
When we find another one of these, we now encode it into our pipeline. That way, if I need to find it, it's there. And if it goes bad, the pipeline definition points me at where to go looking for everything of interest.
Another pattern that is emerging for us is "enforce project invariants". For example, we have multiple repos, so multiple Gemfiles and Dockerfiles, all of them with ruby versions set. At the front of our pipeline there is a little gateway to check that these are all identical. If not, it prints a table of versions found, so again, I know instantly where to go look. We have various other little invariants that turn days of insane debugging into a few seconds of sanity-checking.
None of this is novel. What Concourse lets me do is hoist good design practices out of code and apply them to CI. The final feedback loop I rely on can itself now be checked in, broken apart according to SOLID principles and even (my colleagues in Buildpacks are pioneering this) unit tested. Some colleagues in London have designed a fully generic pipeline that can be configured at runtime to build any of the five products they manage.
