I've been on the 'bottle of rum train' for a LONG while now. It's simply not worth it to either maintain a half dozen monthly subs or try to "buy" movies that still can only be watched in certain specific ways.

Especially when you can buy VPN per year for what netflix charges per month...and then watch nearly anything at any time on any device and share with anyone else who also wants to watch it.

Good question. Their POWER series of CPUs were not insignificant in capability, their chip designers were clearly technically sophisticated, and GPUs are just specialised vector processors with a few extra bells and whistles - stuff IBM is extremely familiar with.

It would not have been difficult to release a GPU or other LLM-specific processor to go along with the POWER11. They'd been working on the POWER11 for 4 years, they knew in 2020 that LLMs had a strong potential to be significant for Big Data processing - an area you use big iron for, they're not rank amateurs, they have plenty of reserve, they could have assembled an emergency team to build a vector processor that was custom-designed for just LLM work, and released an LLM processor card that could run circles around nVidia.

They didn't. Because, as has happened before, their management is simply too stupid and too slow.

Your words all make sense but your points don't.

First: trucking is NOT efficient. Railways are far more efficient for moving bulk goods.

Consistent grades are still grades and waste a ton of fuel that can't be recaptured - except with an EV and, to a lesser degree, a Hybrid.

A hybrid will improve efficiency vs ICE in local delivery/traffic but a full EV is still significantly more efficient.

Putting a hybrid drivetrain into a trailer is ridiculous for the vast majority of situations. There are about 3 semi-trailers for every semi-truck to start with so that's simply wasteful and expensive.. If you only using them for 'special' runs then you complicate logistics which gets expensive fast.

Substations catch fire? I mean, sure. So do fuel stations...which ironically to your point also don't operate without power. So yah, win for EV there.

The /best/ approach is to build out the rail system and leverage EV Semi's for what would then mostly be local/regional delivery.

We won't do that so the next-best approach is to continue building out EV Semi's while focusing on where their immediate strengths are - local and regional shipping. As that continues, the 'charger deserts' become less and less ... while technology evolves to support higher speed charging and more energy dense packs. The need for long-haul diesel diminishes.

These trailers are just a solution looking for a problem. I'm sure they'll find some niches, but just that. It probably makes more sense adding a diesel generator to an EV semi than adding batteries to a semi trailer...but I'm not about to math that out.

What if...

Someone (say someone who was familiar with doxygen and GCC) developed number of comment types, where some stipulated preconditions that must be true for the function to run correctly, postconditions that must be true once the function has run, kernel facilities that the function definitely needs, and kernel facilities that the function definitely doesn't need. These would all be optional for any given function.

A static checker could then validate if the code meets the behaviour expected by the programmer. This is precisely what is done in SPARK, a fork of Ada for high-reliability code. Combined with existing static checker capabilities, this would greatly increase the number of bugs that could be caught with all kinds of tools, AI included.

It could ALSO build a full fine-grained mapping for any fine-grained mandatory access controls system. You'd also want includes that you could import for precompiled libraries. This would allow someone to verify if the code was making unanticipated/undesirable calls but would also make SELinux possible to develop for at the application level.

It would not be trivial. If it was trivial, it would have been done simply because it already IS done in other languages and that makes it "obvious" to anyone who has been programming for a while. However, it should not be massively complicated, simply because you can use AI as the static checker. Once it has a definite set of bounda that must be satisfied, it should be much more capable of knowing what paths would violate those bounds. Which means that the checker stage essentially is trivial today, leaving only the markup stage.

Is to set coursework and exams that are specifically crafted to exploit where AI is weak or prone to hallucinate.

You do not ban cheating, because those who cheat will inevitably find ways to circumvent the ban.

Rather, you exploit the properties of the mechanisms of cheating to ensure that those who actually understand the ideas are marked relatively highly (regardless of whether they reach the textbook conclusion) and whose who do not understand the ideas cannot do well even if they give what is in the textbook.

The interest should not be in precise answers, but in precise use of tools of reasoning and analysis, because this is what actually matters when it comes to understanding. Yes, it means you can't standardise so easily, and you have to devise things in ways that don't penalise intuitive thinkers over methodical thinkers, but you cannot teach a subject properly if you are only concerned about the surface.

I didn't see a 5.6 option on the Windows client last night.

Haa anyone else observed 5.6 in the wild?

Trump doesn't need to have power, he only needs to create fear, uncertainty, and doubt.

Companies are risk-averse, which is why Anthropic pulled their AI model for a while.

You can get Veracrypt to work with the Mac, via FUSE, but I don't know how safe/robust that is. It's probably more secure than anything Apple has. It's certainly more secure than anything Microspot has.

But, yeah, it's getting extremely irritating that useful stuff is being taken out of commercial OS' and junk put in.

There's no known client, but there is a very good unknown client:
(For those familiar with Kenny Everett...)

https://dev.to/jfscoertzen/cha...
https://snapcraft.io/chatgpt-d...

Whether it has all the official features, I don't know. But that's your best bet.

The DoD is known for viruses transporting payloads across airgaps onto Internet-connected machines. One thing it isn't is "so secure".

But, to the extent that it IS secure, it uses pretty much what I outlined. They use Class 3 certs for all users and all machines, and have done since about 2001. The US Navy got to trial run thei system to shake down the defects in the design, before they rolled it out to everyone. Beyond that, they use segregated networks (in principle, physical separation rather than logical separation, but who knows?) and encrypted communications.

What I've done above is take what the US DoD uses today, threw in what the US DoD recommended but never actually implemented in the 70s to fill in some of the gaps, and also included what the US DoD implemented and actually used in the way of Trusted OS deisgns in the 70s and 80s. The NSA and IRS likely use some variants on the same techniques.

So, what I've got above is pretty much why the DoD is as secure as it is.

What I've done is augmented it to handle the fact that you need to verify the hardware and not just the endpoint, and that you need to verify the physical host independently of the logical host. But that's pretty much it.

That is true, but the archaeology shows that this won't work for all island-hopping or all river navigation.

For example, we have clear evidence of hominins not just living on islands across the Mediterranean when no ice was present (it was free-standing water) but commuting to and from shore. We also have evidence of technologies travelling upstream along river-based communities at speeds that cannot be accounted for by simply walking.

So we need a model in which they could actively navigate against the water flow AND across significant distances of open water.

We know that boats built 1.1 million years ago (so around the time of the split) were capable of going long distances up/down rivers between settlements, and across open waters beyond visual range to islands. This places certain language requirements on the hominins of the time, although we can't be sure hobbits had full access to all of those requirements. (There's not much evidence of boat building.)

However, they must have genetically had the capability, whether or not their brains were large enough to make any use of it.

That is all perfectly true, but we have a problem. Boats were capable of navigating reliably and robustly up/down rivers and across open sea beyond visual range. This requires much more complex communication than a gorilla or a chimpanzee is capable of, but obviously orders of magnitude less than a modern human or a Neanderthal.

It would seem reasonable to say that homo florensis was as much like us as those who first built deliberate boats for voyages requiring complex navigation.