You may at least want to take a look at vdirsyncer[0]. Assuming all of your sources run CalDAV that you can hit than you can at least extract the events. I use it for backup for a calendar of my own (so I don't know what I would use to "merge" multiple synced calendars into a singular view but maybe you could do that via a "master" account an write all the other events to it?)
Especially if you witness it as an employee and run it up the chain as far as possible and it gets ignored.
Having had good and bad in my career has saved me from realizing that this was happening and that I shouldn't sit idle but if I'm not idle and do something it becomes extremely disheartening to watch this happen (and then I leave when it becomes apparent that nothing will be done and I'm miserable under my manager)
Disagree, I was the not in the "in crowd" with my boss at a previous location and yet I was the person (as suggested) in regards to everything backend related.
This is very true. I'd see this in software I worked on integrating ERPs where we'd have support for like 5-10 custom fields.
The best workflows were those were the custom fields were used and just had a nice label (e.g. "Old Customer Id") and not the workflows where some consultant had created an additional UI that didn't even use the underlying fields and did something like write the data to some unrelated storage mechanism and then building reports that are trying to awkwardly mix and match these data sources.
I'd forgotten all about interop with DCOM until just now! Several years ago (when I last had to do it) I recall having to horribly mess with services on my local machine just to get anything to appear to work...let alone actually knowing if it did what I wanted (consistently) and then how to get that to work at a customer site (we were told to document it and throw it over the wall to support...)
I've also started experiencing that even though all actions are cleared and I can navigate away that sometimes those actions "didn't take" and I'd be cleaning up emails for the N-th time.
It's hard for people to have recall over events and (again not always malicious) what one person may consider a "big deal" to have done (or not done) will influence whether they remember and how they remember it. I've been pulled through changes I was opposed to (in my opinion, it made less sense to make the change) and eventually conceded to the change. 1.5 years later everybody (both those who agreed with me at the time and those who disagreed) was all about changing it again (back to the way it was). I had the email conversations and remembered what previously happened and was able to (re-)inform people about why the decision had been made (no, I did not want to revert all the work I did even if I still thought we shouldn't have made the change).
Yeah there is definitely annoyance, overhead, and expense but you are trying to securely transfer data to an air-gapped network so just "plugging things in" (what some people expect, like just grabbing a usb drive) is a risk in that regard so it's a lot of trade-offs.
the '-C' option to let me do git operations without being in that directory is vastly helpful when I go to script against a variety of git repositories (--git-dir is pretty nice too, I just don't often have a use for it)
This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption.
Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.
This makes sense and I agree. You will learn some about the domains you write software in but often you are in those by force and not by choice and you will only ever be so interested in the problems you face/software you build. I once got to write a compiler for financial formulas and that was very interesting but that was the exception and not the rule for most of my professional work.
Maybe you get lucky and have a hobby/personal interest that can fulfill this need to some degree (this partially has happened to me, apparently people who write software don't often overlap with people who cross stitch).
I do enjoy writing code but I much prefer writing code for problems or in domains that interest me.
I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"
One of the problem I see with helpers is that a lot of them start to wrap the whole user's package handling experience (pacman wrapping) where it seems like it would be easy to ignore the prompts and "just download the package already". You can tell users the AUR is unsafe and to review PKGBUILDs but that doesn't mean they are going to listen or do it.
I did write a helper, mainly for myself and a few other arch users I know, and if not for having completed it enough to use it, I wouldn't do it again (I don't support pacman wrapping). I use like 5-10 packages from the AUR and I either maintain them or they _never_ change and I would know something is wrong.
The other point to this is how is this sort of compromise best communicated? It's important enough to hit [0] and obviously this news site, the mailinglist[1], but not the frontpage of arch itself.
Or just delete the source safe files from the share and have everybody in a panic (this happened where I worked in ~2010 for some legacy apps still in source safe...it was an untrained user trying to undo a change).
[0]http://vdirsyncer.pimutils.org/en/stable/