I work in HPC and mostly on the shell/console. Without a doubt, the combination of Bash (or another shell) and AWK is truly amazing. Being able to quickly generate statistics, filter out unnecessary information, generate pipelines, etc., is unmatched, and 99% of the time only requires a pipe redirect. Not to sound trendy, but using AWK really is the proverbial "if you know, you know".
One of my favorite use cases is based upon grep with extended regular expressions; there's always a need to search for strings while needing to exclude others, think of a basic example as "grep -E 'this|that' file |grep -Ev 'not(this|that)'". With AWK it's simple, "awk $0 ~ /(this|that)/ && $0 !~ /not(this|that)/' file". Or, if you're monitoring server load averages via a tool like sar, you can pick and choose which loads you want to monitor based upon a threshold, "uptime |awk '$10 ~ /[0-9]{3,}\.[0-9]{1,}/ || $12 ~ /[0-9]{3,}\.[0-9]{1,}/'". This will print matches if the 1 minute or 15 minute load averages are over 100.
Just because it's an "old" language doesn't mean it's obsolete or useless!
> Counterpoint: most shops do not need most of the bespoke cloud services they're using. If you actually do, you should know (or have someone on staff who knows) how to operate it, which negates most of the point of renting it from a cloud provider.
Well said! At $LASTJOB, new management/leadership had blinders on [0][1] and were surrounded by sycophants & "sales engineers". They didn't listen to the staff that actually held the technical/empirical expertise, and still decided to go all in on cloud. Promises were made and not delivered, lots of downtime that affected _all areas of the organization_ [2] which could have been avoided (even post migration), etc. Long story short, money & time were wasted on cloud endeavors for $STACKS that didn't need to be in the cloud to start, and weren't designed to be cloud-based. The best part is that none of the management/leadership/sycophants/"sales engineers" had any shame at all for the decisions that were made.
Don't get me wrong, cloud does serve a purpose and serves that purpose well. But, a lot of people willfully ignore the simple fact that cloud providers are still staffed with on-prem infrastructure run by teams of staff/administrators/engineers.
[0] Indoctrinated by buzz words
[1] We need to compete at "global scale"
[2] Higher education
> Out of curiosity, do you know what happens to the decomissioned hardware? is it scrapped for useful parts like perhaps the PSUs? or is gold and other metals extracted from the chips and the metal sold for recycling?
I cannot state with 100% clarity what happens after the systems are acquired by surplus vendors, but I can say that we have received certificates of what was "recycled". Once the surplus vendors take possession of the hardware, it's theirs and they can do what they want with it. In fact, we recently had to purchase EOL'ed, refurbished Infiniband switches to continue to support an interconnect fabric still in use (~2016). Interestingly enough, some of the switches still had "core" and "edge" labels on them.
> Is there anything useful someone could do with it or it's just too much of a problem to set it up and repurpose it?
In my opinion, it really depends on the node. If the chassis supports hot swappable & redundant hardware (HDD, PSU, etc.), then we'll typically cannibalize several chassis to create an administrative and/or infrastructure node. Case in point, a large portion of our older 12 core nodes have been put aside to serve as administrative nodes, all fully redundant (RAID1 HDD's, dual PSU's, ECC memory, etc.). Since we have a stack of these, we're fairly confident that these will serve us for the next few years, worry free, given the abundance of parts lying around.
We were being harassed (read: annoyed) by rsync's incremental and non incremental backups for our primary research storage, accounting for ~66 TB.
We were able to reduce run times by 80 to 90% by using GNU parallel and rsync. In a nutshell, a wildcard directory list is created for rsync, which is then piped to GNU parallel.
"I think you have to be a bit of a masochist to use a standing desk alone for more than 15 minutes per hour."
I'll agree to a point regarding the 15 minutes per hour when you first transition to a standing desk, but after that I'll have to strongly disagree.
I've been using a standing desk (Versa Desk) for almost a year now, and I have no problems standing for hours on end - even after running 4 miles before work (4x a week). But, I'm sure it helps that I have comfortable shoes on and can lean from time to time (this helps a lot). I will find myself seated though, when there are long RTFM campaigns, or if there are too many pieces of a trouble-shooting puzzle in play.
Agreed, sometimes the reward is just too high to simply "pass on an opportunity".
We had an undergrad utilize our then, nascent CUDA nodes. But, simple monitoring of the nodes raised a red flag.
When we looked into his running jobs, we found an expediently crafted work-flow, where there was no attempt at obfuscation. That is, the user's input files all contained references to various mining sites at that time...
Needless to say, privileges were revoked and never restored!
Just an update in case that someone is experiencing something similar.
1.) If using RHEL, most likely the latest microcode updated offered via RHEL entitlements will contain the requisite updates.
2.) Slapping myself over this one(!), but the family, model, and stepping ID's need to be changed to hex. I confirmed this via inspecting a node which was patched using the latest updates (kernel & microcode) from RHEL; I am now able to verify that the majority of the microcode offered by Intel appears to be ready to go.
I hate to say it, but I'm also finding myself scratching my head at this one. I've randomly chosen 3 separate Xeon E5 family processors that are in production, and _each time_ I look at the intel-ucode files, _absolutely none_ of the family-model-stepping outputs from lscpu/dmidecode match.
I'd guess that the format above (using HSW-ULT Cx/Dx as an example), that 01:72 means stepping 1 through 72?
"sed is useful for making small, line-wise tweaks to text."
Couldn't agree more!
A great example of this was using (surprised it wasn't mentioned) sed with the -i & 's///g' operators while "cleaning" hundreds (seriously) of HTML/PHP files from injected content at a shared hosting provider.
Although, I cannot comment personally on what employment chances are after serving in prison, I can state with confidence that having a single, felony drug conviction [0] doesn't automatically result in a denial of employment all of the time.
The largest, single reason which I could see as an automatic rejection for chances of employment is the prior criminal history [1]. It's much easier to explain (and look past) a single offense, versus multiple offenses - especially if they're all in the same vein.
My most recent major job search a few years ago (Texas and Florida, ~8 years post-conviction) was basically 50/50, in terms of offers of employment after criminal history was disclosed. The irony is that the majority of potential employers who asked for details were the ones that sent the job offers.
I know that no two situations are exactly the same (I'll provide details if you want them), but hopefully this is proof that there is light at the end of the tunnel.
At least the Lustre developers (pre-Intel) had the foresight to enable extremely good debugging - you could simply enable a few procfs settings and easily find the offenders.
It's still amusing to me however, that the biggest offenders of Lustre slow-downs were single core processes. I'd check the RPC counts per node, find the violator, and then check per PID statistics; it was always (95%+) a single core application performing thousands of calls.
We never did experiment with the 2.x branch of the software. I recall one of our co-workers stating that even the developers did not believe the dual MDS set-up was production ready at that time.
Our previous configuration was Lustre and XFS/NFS; the former was the scratch file system for HPC applications and the latter for home directories and what not.
Lustre was definitely a beast (in a good sense), but we'd occasionally get bit by a work load high in metadata operations - which would bring Lustre to its knees due to latency.
XFS/NFS was great for its purpose (no HPC workloads), but we'd also get bit by a user or users reading seemingly tiny, innocuous files (inadvertently in parallel) which would cause load averages to spike; surprisingly the latency wasn't as bad as the Lustre workload mentioned above.
Not too drink the GPFS kool aid here, but it's definitely solved both problems above. It has its issues, but definitely handles the common I/O patterns seen on our cluster.
One of my favorite use cases is based upon grep with extended regular expressions; there's always a need to search for strings while needing to exclude others, think of a basic example as "grep -E 'this|that' file |grep -Ev 'not(this|that)'". With AWK it's simple, "awk $0 ~ /(this|that)/ && $0 !~ /not(this|that)/' file". Or, if you're monitoring server load averages via a tool like sar, you can pick and choose which loads you want to monitor based upon a threshold, "uptime |awk '$10 ~ /[0-9]{3,}\.[0-9]{1,}/ || $12 ~ /[0-9]{3,}\.[0-9]{1,}/'". This will print matches if the 1 minute or 15 minute load averages are over 100.
Just because it's an "old" language doesn't mean it's obsolete or useless!