cakes

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?)

[0]http://vdirsyncer.pimutils.org/en/stable/

and if rsync doesn't quite work for what you need/a target you want to use, rclone is always an option as well

https://rclone.org/

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)

Whatever is easier for you but (if you can) target what they write in

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.

and also what you work on.

I've been through it working on released and unreleased projects and how things are handled changes based on that

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.

Generally what parent says and to add: Does the company have a good/stable/solid vision/strategy? Do you believe it is/can execute on it?

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.

[0] planet.archlinux.org [1] https://lists.archlinux.org/pipermail/aur-general/2018-July/...

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).

I can understand this. If I had to pick a marketable/future employment language today, I would pick C# over D (I have used both).

I wonder if this is the actual final death of TFS (Server) at this point as they could now move Github into that offering space for enterprises

I was surprised (years ago) when I learned about SOUNDEX() in Microsoft SQL Server. I always wondered why SOUNDEX was in SQL Server (not that I thought it shouldn't be, was just curious).

This would be great...but it seems more likely that what happens if a forcing function is applied is that anything in the current gray area (gray area is putting it nicely) of using the DoD Root CA will likely just become not publicly accessible whether it makes sense or not to do that for the resource (e.g. webmail)

Again, this would be awesome but as a DoD civilian employee...I don't see it happening in a good way

This was pretty much true when I was last using C#. You would find specific places where you need "an object" (e.g. maybe you want to LINQ over some data in a method) so you could dynamically create it but if you wanted that object to go anywhere outside of scope you had to have a concrete definition.

I can understand this rationale technically, when I was using skype (at work) ~8years ago we would have some real problems and a lot of it was attributed to "SuperNodes" if you dug deep down far enough. Chat and group chats at the time, though, were very reasonable

Whether that improved quality or not, I wouldn't know, I haven't used skype in quite some time.

Personally - I write aliases locally that I know I don't need/can live without remotely (e.g. "vi" aliases to "vim" because sometimes I fail to get that "m" on there and I want vim but only on my laptop), I can't imagine writing "system-wide" things as an alias without losing some sleep.

I'd agree with the concept of memorizing it in theory but I'm with you that it becomes a bit too much when the tooling differences in switches from command to command can be even minimally different (something as simple as scp "-P" vs ssh "-p" is easy to forget in the moment). Yeah, I can memorize that example but everything has flags for everything and they can be vastly different (like you mentioned sort vs. cut)

that surprise could include "management says we don't have to do anything :/" <5.99 months pass>, management: "we have to patch this and it needs to be done yesterday."

Having attended a university that was coop-based, I've had this discussion (or did when it was more relevant) and the key truly is "a well written resume" (plenty of coop positions come and go so...)

Often I would have conversations with people about resumes where they had problems and those problems would be things like: * How long is your resume...? (way too long, often) * Can you drop/compress any positions? (keep recent/relevant) * Instead of "Employment", can you say "Coop Experience"? for the section? * etc.

(thought questions, not asking for responses). I do agree, you definitely have to make the "coop" part super obvious otherwise you won't make it past initial filters.

As an avid fan and (previous) user of C#, the thing I struggled with was everything moving to Nuget...everything.

It felt very much like Nuget was an attempted solution to DLL hell but it was just another version of that same hell itself but at least now on your VS machine you didn't have to find wherever your company stored their libs

Silverlight didn't really thrive though...

> the obligations he has to the community.

There isn't an obligation though. You could fork or pick an alternative as much as a maintainer/owner can abandon a project. They aren't obligated to do anything for you and you aren't obligated to do anything for them.

If you don't like a project because of personalities involved, avoid them. I have personally done this without problem. It can be a pain but I have no actual pull in the matter.