garenp

I must say I was immensely entertained by reading "IBM stepped up with buildfarm animals". :)

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?

Imagine an OS specific bug that could lead to failure. Now imagine you're using that single OS everywhere.

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.

Does it replicate the same kind of "evil" bugs as in the article, or does it provide an improvement?

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.

ICC like many commercial compilers used the EDG front-end, not their own.

Was there anything you did that helped you get better?

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.