I would say "limited and unreliable access". What it says is the cause might be the cause, but it's not on any way certain.
6,599 karma · joined October 31, 2013
And training is currently considered fair use in the US (some court cases pending).
I am not a lawyer, tho.
For example, many companies do well by selling a less capable but more affordable and available product.
Fill in this form to receive an email notification when the course is available: https://docs.google.com/forms/d/e/1FAIpQLSfWW8M6PwOM62VHgc-Y...
AI can be a helpful assistant but they are nowhere near ready for letting loose when the results matter.
I'm not sure what you mean by "Unix specification". But if you mean the international standard POSIX, yes, people care. Red Hat routinely participates in POSIX spec revision.
There are a very few deviations where you have to enable "POSIXLY_CORRECT". If that's what you mean, then you can turn that on. But in every area that matters, Linux distros implement the POSIX spec by default, and you can even turn on the POSIXLY_CORRECT mode to exactly follow it. They extend beyond it, but that is allowed and expected.
The people who build the tools in Linux distros care a lot. I know the implementors of dash and GNU make routinely refer to POSIX. The Linux distros don't have to as much with POSIX because that is generally a conpleted work and it's the maintainers of the tools who must address the updates to POSIX.
However, by design it did not support recursion, directly or indirectly: https://atariwiki.org/wiki/Wiki.jsp?page=Action Variables were assigned constant locations, which made things easier for the cpu, but that's a harsh limitation.
It was only available on Atari and for a while you had to have a cartridge to run its programs. For many, these were deal-breakers, as you couldn't release your programs to many.
As always, trade-offs, but pretty big ones.
I really like the word "assistant" for what we have today. The AI code assistant tools available today, like Claude Code and GitHub Copilot, can't replace humans in doing software development. Not even close. But they are often useful to human developers, and today, that's the more important measure.
I've been spending time with various AI tools, especially Claude Code and GitHub Copilot. They're amazing one minute, and they make bone-headedly bad recommendations the next. It takes effort to learn how to create good prompts, and if you want the results to be good, you have to review and critique the results. I'm particularly concerned about security. They're definitely happy to write insecure code. If you know what you're doing, prompt them well, and review their results, you can get good results.
I don't know if they'll ever reach "full autonomy". They don't need to get there to be useful.
I'm sprry, but I disagree with this claim. That is not my experience, nor many others. It's true that you can make them do something without learning anything. However, it takes time to learn what they are good amd bad at, what information they need, and what nonsense they'll do without express guidance. It also takes time to know what to look for when reviewing results.
I also find that they work fine for languages without static types. You need need tests, yes, but you need them anyway.
I disagree. In fact, I think that's quite unlikely.
First, unlike a metal hull, carbon fiber hulls accumulate subtle damage on compression that's hard to detect. Then, when they fail, they tend to fail catastrophically. So "this hull worked before" isn't evidence of success in this case, as it normally would be, it's evidence that you're getting closer & closer to the disaster.
Second, I think Stockton would have just kept diving, even if this event hadn't failed. He might have even gotten more reckless (though per the report he was already extremely reckless). If you keep playing Russian Roulette, and occasionally add another bullet, eventually the game will end. There is no evidence he was going to stop until he was killed by his own decisions.
None of this takes away the tragedy of it. It's sad, and will remain so.
PHYSICAL CAUSES
"4.2.4.4. American Bureau of Shipping (ABS) Classification Society Background" ... "The ABS Underwater Rules do not permit the use of carbon fiber composites for Pressure Vessels for Human Occupancy (PVHOs)"
"4.2.4.5. Det Norske Veritas and Germanischer Lloyd (DNV GL)" ... 4.2.4.5.3. According to a DNV Surveyor, carbon fiber has not been accepted as suitable material for the construction of submersible PVHOs, especially when subject to external pressure experienced at ocean depths. According to DNV GL, carbon fibers are not considered suitable for significant compressive loading conditions."
"5.1. Inadequacy of Structural Engineering Analysis. OceanGate’s TITAN submersible design was a complex, high-risk, deep-sea submersible. The design and testing processes for TITAN did not adequately address many of the fundamental engineering principles that are considered crucial for ensuring safety and reliability for operations in such an inherently hazardous environment..."
"5.6 Insufficient Understanding of Carbon Fiber Material Properties for Deep-Sea Application. The TITAN’s pressure hull was constructed using carbon fiber, a material chosen by Mr. Rush for its “impressive” strength-to-weight ratio. [However] the use of carbon fiber in deep-sea environments remains unproven—unlike the materials with established safety records. There are currently no recognized national or international standards that approve of the use of carbon fiber pressure hulls for submersibles. Carbon fiber has demonstrated its effectiveness in other applications where the material is primarily under tension (e.g., aircraft hulls where the pressure inside the passenger compartment is pressing outwards). However, in deep-sea conditions, the pressure hull experiences extreme compressive forces, a scenario for which carbon fiber has no established track record and is generally understood to be less effective."
* * *
HUMAN DECISIONS
The physics is just the physics. There was no law of nature that forced them to take the steps they took. Instead, we have points like these:
"5.12. OceanGate’s Toxic Safety Culture. OceanGate’s operational and safety practices were critically flawed, which contributed to the catastrophic implosion of the TITAN submersible. At the core of these failures was a disconnect between the company's stated safety protocols and its actual practices. ... This highlighted systemic issues where submersible safety protocols were either egregiously inadequate or willfully disregarded, leaving critical risks unmitigated. The analysis reveals a disturbing pattern of misrepresentation and reckless disregard for safety in OceanGate's operation of the TITAN submersible, with Mr. Rush seemingly using inflated numbers to bolster the perceived safety and dive count of the final TITAN hull...
Examples of OceanGate CEO’s disdain for traditional submersible safety protocols were abundant. For example... This dismissive approach to safety culture was not limited to engineering decisions. OceanGate’s management actively retaliated against employees who raised legitimate compliance related concerns..."
This was a tragedy, because people died and this was all completely avoidable. It's the only event like this in many, many decades. I hope others will leran and avoid making similar mistakes.
Many reports are written for a narrow audience. That's fine if it provides key information necessary to make a good decision with wide impact.
Control characters in filenames have no obviously valuable use case, they appear to be allowed only because "it's always been allowed". That is not a strong argument for them. Some systems do not allow them, with no obvious ill effects.
See my discussion here: https://dwheeler.com/essays/fixing-unix-linux-filenames.html
One piece of good news: POSIX recently added xargs -0 and find -print0, making it a little easier to portably handle such filenames. Still, it's a pain.
I plan to complete my "safename" Linux module I started years ago. When enabled, it prevents creating filenames in certain cases such as those with control characters. It won't prevent all problems, but it's a decent hardening mechanism that prevents problems in many cases.
In short: there's plenty of evidence Amelia Earhart was reckless. I'm sad that she paid with her life, but that is sometimes what happens when you're reckless while using dangerous machines.