It's like the speed of light being a constant, or the Planck length being the smallest that can be subject to standard physics.

Quantum computing, which is a complete change in the actual physical model of computing, appears to be the only alternative.

They bought and funded (and still fund) Redhat which funds Fedora and GNOME and Wayland and systemd.

I don't think this will change in the US, because your governments have been totally corrupted and you have much bigger problems than datacenters.

It will/is happening in more enlightened/democratic jurisdictions.

The only reason is to remove them from local/regional, and potentially national/international jurisdictions.

Oh, and of course, the other reason is to give SpaceX to have a reason for xAI to be part of its structure.

Starlink makes sense, LEO comms using a mesh makes sense.

LEO/geosync satellite data processing doesn't.

Specifically to reduce the ongoing demand for water.

DCs need to get to net-zero on their energy requirements and their water consumption.

They are already losing their political license to operate because they're not.

That's independent of the noise and other impositions on the local communities.

For a DC to be politically acceptable it must be:

* Net zero emissions on energy consumption, preferably powered by renewables in addition to the existing local supply.

* Net zero on water consumption, especially fresh/drinking water from local supplies.

* Low to no noise or other pollution.

Don't the US Military and NASA use metric now?

Take into account that some Unicode codepoints work together to combine to form a grapheme which then links to a glyph for display.

If you use UTF-8 internally, you will be expanding out to full 32 bits when scanning the vector anyway.

So if memory isn't an issue (and most of the time it's not), indexing a vector by codepoint (ie 32 bits) makes more sense from a processing POV.

The issue is that none of the print carriage movement ASCII characters should be used internally to indicate "end of line", because each of the chosen possibilities are used separately to indicate different carriage movements.

The logical decision would have been to choose one of the "separator" characters to indicate "separation of one line from another" and then allow the I/O drivers to decide what to send/receive to/from a particular device.

I'd say Multics/Unix was technically correct, except this was still the wrong decision for I/O ever since.

The Record Separator is the logical character code to use to indicate the end of a line of text and print position characters, assuming that a line of text is a "record".

Otherwise you need to have some sort of escape mechanism, exactly like quoting strings in CSV. In fact, there's an ASCII code "ESC" for entirely that purpose. :)

The problem is that those characters are non-printable, which means if you're just dumping the file out somewhere, you can't see them.

The fat pointers are much more efficient in that you don't need to scan memory to get the length or find the end to append or take slices etc.

Especially for vectors that don't have any value that can be used as a sentinel.

And maybe it was 5/10 years earlier? Not sure. My uni days were the very early 1980s. Our university literally still made 1st years use marked sense (not even punch) cards.

I never ever liked C++, it always seemed to be tacked on to the side of C (literally at the start).

I liked the "better C" bits, but the "++" bits and the magic under the covers and then later the added layer of templates just seemed ridiculously complicated especially because we were still in the days of inheritance and "is-a" instead of "has-a" objects.

I loathed all the overloading that suddenly << meant something completely different when doing I/O and weird multiple function definitions to provide the generics.

Much preferred the Objective C idea of messages, was much more what I understood OOP to be after Smalltalk.

But by then I'd made the leap to being an "architect" and got to pontificate from on high and languages became semi-irrelevant.

VMS used:

    node::device:[dir1.dir2.dir3]filename.extension;version

The versioning was cool as long as you remembered to clean them up.

The server doesn't get to stop the browser making calls that it didn't want, so it's a browser security feature, to stop the browser sending cookies where it shouldn't, or more precisely, to only send authentication and other info where it should.

It relaxes the same origin policy.

Usually a browser will not load resources from another origin based on the HTML it receives. If the page is from example.com, it won't allow you to load a page from example.org.

That stops things like authentication and cookies etc from example.com being transmitted to example.org if someone hacks the webpage.

CORS allows the server to relax those rules so that it can say "You can load resources from me, or from these other servers."

So it can say "I'm example.com but you can load resources from example.org and that's OK."

At least, that's how I think it works :)

If BCPL begat "B" and "B" begat "C", then "C" should have begatten "P".

Not sure if begatten is a word :)

SMPTE have chosen github because it has the other stuff to allow them to manage the committee work, handle the issues raised in committees, drafts, tagging different versions, dealing with the committee processes etc.

They could have chosen something like JIRA, so at least we've avoided that.

That's what they said in the post about it being open.

They've moved the internal email mailing lists and other workflow to github as well as using git for the version control of the source.

Unix used LF, Apple used CR, Microsoft used CRLF.

They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent.

So they all made the "wrong" decision about what to store in a file.

They just chose different wrong characters.