The 1k packets you saw probably correspond to the default block size being used for the DB, that is a vestige of using spinning disks. That you were using NFS or any kind of networked filesystem is what I'd say is a performance hostile environment. Did no one think of just not using NFS?
In my experience RHEL has been better at backporting patches and maintaining a relatively stable kernel. This means that third-party software that targeted it is more likely to work over time. Canonical by comparison is absolutely terrible, and seemingly just blindly imports whatever is thrown over the wall from kernel.org even in their so-called "LTS" versions, and now after running an innocuous "apt-get upgrade" command your frobnitz device no longer works and/or you can't rebuild the driver for your frobnitz device due to incompatible kernel changes.
Some vendors also explicitly detail exactly which distro and versions they support ("RHEL or Centos x.y"), so even if you can get things to work on another distro, a vendor can easily deny your support request with the usual BS line: "that configuration is not supported. Switch back to RHEL x.y or SLES and let us know if you can reproduce the issue! La-la-la have a nice day, buh-bye! phone click".
Interesting point about raw Li-ion cells - sounds like the result of the exploding hoverboard fiasco years ago(?).
Another unfortunate "feature" was that the device refused to be powered with it's own USB cable. It felt to me like the manufacturer were deliberately trying to limit your options as a customer so that you had to keep re-buying batteries from them - reminding me very much of the situation with printer ink cartridges.
It does feel like there needs to be a better tradeoff between consumer safety and repairability. I can replace nearly every part in my car with an aftermarket part, so why can't we do the same with these little computing devices etc?
Not long ago the battery on my Dymo 280 died and was pretty surprised to find that the cost of replacing it (~$30) was about the same as I paid for the product. The battery consists of two small 14430 cells in a plastic package that isn't serviceable.
For awhile I limped along by buying a few cells online and jerry-rigging my own connectors with a soldering iron but after the printer itself finally died recently, I actually replaced it with an _older_ 160 model that uses AAA cells instead - go figure - newer is worse.
This is generally my sentiment as well. The reason to avoid using goto is if it makes following the flow of execution for us humans difficult, which typically happens when jumping backwards.
Using goto judiciously to more easily escape a deeply nested block of code and/or jump to a cleanup section is not hard to follow.
This is also my thinking, and doesn't seem too implausible given that the dosage is so much higher than Pfizer (100mcg vs 30mcg).
My relatives who got Moderna had similar reports to some of the posters above. I got Pfizer and barely noticed.
Your last point about career development is an interesting one that comes up. If you are remote but your co-workers are interacting in person I can see how there would be an informational advantage in favor of your co-workers that is unavoidable.
My preference is to WFH most of the time, but not all the time. When WFH for awhile, I can much more easily get into a zen-like state of concentration after an hour or so that is extremely difficult to get in an office. At the office I have to contend with constant sources of distractions and interruptions (people walking up on foot, phone ringing, non-work related discussion, ...) which has often made me feel like the only time I can push through a hard problem is during off-hours when no one is around. Most importantly, being in a zen-like state while working and getting stuff done is what makes work enjoyable for me.
That said, whenever there is a significant amount of collaboration or a need for a lot of round-trip communication with someone (new employee, need to bring someone up to speed, ...) it's better in person - but I find this to be only an occasional need.
Atlassian does not provide particularly good guidance on how to get their tools to perform well. The first big issue for any moderately busy system is that you need to dedicate huge gobs of heap memory (think 16G+) to the tool. After that, they suffer from poor schema design - there are tables that are literally missing indexes on commonly queried columns, and some columns that have delimited values embedded in them.
It's hard for me to imagine that atlassian would allow individual instances of jira/confluence/etc in their cloud versions to get nearly as much resources as you need to give them on-prem. The incentive would always be for them to try to minimize the amount of memory every instance gets, which does NOT maximize your individual performance. Shared resources will also make performance more variable and "noisy", making it more difficult to narrow down specific causes. It's hard for me to see how "Java" and "cloud" go together.
Yup. If you look at the end of the 'changes' link[1] you'll see individual bugzilla links for issues (or PRs as they call them) that were resolved in a given point release.
Of the CI tools I've used (most of them) TeamCity was my personal favorite--but the advantage of Jenkins is that it's very widely used, has a greater breadth of capabilities due to the huge plethora of plugins, and a huge amount of support info readily available online. Some plugins are even maintained by an external vendor that produces the tool you're trying to integrate with and are either better supported or the first to get timely updates.
Bamboo on the other hand is IMO the worst of the commercial CI tools by far and where I work has gone down for us the most. Atlassian itself doesn't appear to be investing in it much anymore judging by the slow pace of development in recent years and at their most recent conference, you can hardly find it mentioned or see much presence for it anywhere.
In all the CI systems I've used though, there has not been one that I haven't encountered some major difficulties with.
Beyond that, anything to do with build automation for a large number of users always quickly becomes a support & maintenance quagmire. Users frequently want to install a new (barely maintained) plugin to solve a problem they have, complex interactions lead to difficult to understand failure modes that require time consuming investigations ("your CI tool is the problem and broke my build" ... "No, your build is broken" ...).
As far as I can tell they all work (N=1 and all that), so I'd say that whatever you find easier to actually do is what you should do - just keep it up as often as you can over time.
If you wanna get a little geeky about it like I was, could consider buying a Precision Xtra to measure your glucose and ketone levels. For me this was helpful because I could see changes in the numbers after changing my eating habits. Had I not seen that, I would have only my scale to see body weight, and would've just looked at that and thought "looks like nothing changed, maybe this isn't working / doing anything at all." This also allowed me to "gamify" the whole process a bit ("I wonder how low I can get these numbers to go? how long I can stay there?" ... etc).