Kind of normal I think, at the companies I've worked for, most outages were caused by a change in production, for which the impact was not properly assessed.
This could actually be extremely convenient to use in many parts of Africa where place simply do not have addresses. Right now what we do is latitude longitude, which works wonders but can a bit clunky especially in cities
Really? It is up to them if they want to use what I wrote. Why would I get fined or jailed for not writing documentation? Good luck trying to prove any wrongdoing. If you want support feel free to hire me to do that, or just do it yourself, pretty much like big tech is doing right now with open source
Read "Everything I Want To Do Is Illegal: War Stories from the Local Food Front" by Joel Salatin to learn about what the government did to farmers. The simple truth is you won't even have the ability to ask to be hired, because it will be illegal to demonstrate your skills in the first place.
I haven't read that book, but asked for a summary.
Honestly, I cannot see software being regulated the same way as food industry is, for the very simple reason that software can trivially cross borders (legally or not) while food cannot. Regulating that industry to prevent any progress by erecting bureaucratic barriers in a given country will just kill the industry in that country and make it thrive elsewhere where it's less regulated. As a result, the regulation-freak country will lose any of its competitive advantages due to lesser efficiency.
Doing this on a global scale requires "CFC-ban"-levels of global coordination which I cannot see happening in the world we live in today. Just look at how global CO2 reduction and climate change is being handled today at the global scale.
This book is now on my reading list, but I expect it to be a crackpot book along the same lines of people who think COVID vaccine mandates are the same thing as Nazi Germany.
A serious security issue indeed, if someone knows the hash.
How I manage this is that every time I want to open-source a previously private feature, I take the changeset diff and apply that to the files in the public repository. Same features, but plausibly different hash.
Transitioning from CentOS 7 to RedHat 8 and 9 at my former company's private cloud has smooth for most teams, pareto-style, with 80% of migration-related incidents caused by the 20% of the teams that did some really weird changes to the VM's OS that was no longer allowed under RHEL 8 or 9.
At first, I thought it was just to reduce the complexity of managing hardening rules for several OS and OS versions.
Recently we had issues with RH 9 not having header packages for openssl 1.1 (which means e.g. you can't have erlang < 25). There's a potential for breakage for anything that is 3+ years old.
Not sure if that applies to your line of work but RHEL has been an increasingly annoying source of issues in low-latency space. Their kernels are a bizarre mixture of cherry picked stuff from upstream and a completely bonkers project structure.
Also, they break ABI across minor kernel versions which is unthinkable in mainline. What I'm trying to say is: if you're doing more funky stuff with your OS, just go with a distro built on top of mainline.
Scientific clusters have more options though, as Rocky/Alma and other alternatives to RHEL are available without dealing with "this distro does not ship FIPS-140-3 certified crypto" or similar.
Yes, that's true. However, tons of software was written solely for CentOS, so ironing out the small kinks will take some time.
The problem is, scientific software can silently error out in many ways (like slightly lost accuracy), and detecting and fixing those will take some time.
Considering some of these tools are developed over (almost two) decades, there's a lot of verification we have to go through.
Considering how many interesting issues that specific CentOS7-locked job had just with updating kernel to latest LTS (which required a lot of fun stuff as well, given that it didn't compile with included GCC)...
Rocky and Alma are okay-ish for scientific clusters. They work and drivers appear to mostly cooperate. Some changes, like switching to sssd, were suboptimal but to be expected.
CentOS just had a lot more testing being done by vendors. We still regularly hit problems with, e.g., Lenovo LESI being not aligned with our Rocky systems for many parameters.
Anecdotally, I am hearing scientific computing customers who are unhappy after moving to Rocky - the window where each minor OS version is "supported" is too small and their hardware vendors have trouble staying current. Have seen quite a few move to Ubuntu, and the rest switch to regular RHEL.
Talking firsthand, There is significant effort into ensuring that both 8.6.z (through to current) and 9.2.z (through to current) are fedramp compliant, this requirement eats my day, every day.
8.6 and 9.2 kernels are released more frequently than other streams, if you want more frequent updates for compliance reasons, these are the streams to use.
If you were using centos for fedramp, unless you got a variance from the feds, you were not in compliance. No one actually paid to have NIST evaluate centos's binaries (evaluation/certification must be of the compiled binary, not the source code, barring an exception made for openssl, and only openssl, not the kernel)
There was a time when RHEL FIPS certificate also applied to CentOS, and one of my former $DAYJOBs depended on that for a long time. Then Red Hat pulled the cert, and later there was a mad scramble to get rid of CentOS because of the EOL :)
> Because a human has fundamental output limitations (parallel capacity, time, lifespan) and a machine does not.
Industrialization as we know it would have never happened if we artificially limit progress, just so that people could still have jobs. I guess you could hold the same kind of argument for the copists, when printing became widespread; for horses before the automobile; or telephone operators before switches got automated. Guess what they have become now. Art made by humans can still exist although its output will be marginal compared to AI-generated art.
LLMs are not humans but are used by humans. In the end the beneficiary is still a human.
I'm making an argument that we need new laws, different than the current ones, which are predicated on current supply limitations and scarcity.
And that those new laws should redirect some profits from models to those whose work they were trained on during the temporary dislocation period.
And separately... that lobotomizing our human artistic talent pool is going to have the same effect that replacing our human journalism talent pool did. But that's a different topic.
For the AI/Robot tax, the pessimistic view is that the legal state of the world is such that such tax can and will be evaded. Now not only the LLMs put humans out of a job because an LLM or a SD model mimicks their work, but the financial gains have now been hidden away in tax havens through tax evasion schemes designed by AIs. And even if through some counter-AIs we manage to funnel the financial gains back to the people, what is now the incentive for capital owners to invest and keep investing in cutting-edge AI, if the profits are now so meagre to justify the investment?
Happened with GPT2, for which they didn't publish the model for several months, GPT3 and 4 whose models were also not published, but given to Microsoft before being published as ChatGPT. The latter being dumbed down further and further over time as jailbreak prompts are patched one after the other.
reply