The way things are headed, the only way people are going to be able to obtain money to pay for those widgets is via social welfare programs.

At least in my neck of the woods, we have ZERO spare water. We're in a 'negative water' situation. Using any water is a problem. That makes the narrative that data-centers are 'water hungry' very effective at causing unrest.

And many places where they put them up, they don't have enough power infrastructure either. So power bills go up as well.

US: 66% (Wall Street's numbers aren't those found in official statistics)
UK: 28.9%
Holland: 23%
Norway: 16%
China: 6%

US' conclusion: The rate is a complete mystery, we've no idea how to decrease it, let's do more of what we're currently doing differently to everyone else.

There is a slight possibility this may be flawed.

Most likely the next step change in AI improvement will come from the next generation learning from today's LLMs and diffusion models. But not being trained on their output. More likely they will be evaluated by current AI.

AI advancements have a predictable pattern. First we mimic how humans do something, then we use those AIs to evaluate the next generation which learns how to do it without mimicking humans. LLMs have been trained on human output and work by trying to determine what a human would do in any situation. The next generation will most likely learn how to think and speak without ever seeing a word of human generated text. Now that LLMs exist to evaluate their output we have the necessary building blocks to design the generation of AI that can really produce content far better than any human.

We are living in the era of early-to-mid 90s chess engines, where AI learned from human moves and brute forced its way to barely beating the best in the world. It took 10 years from the point where chess engines could compete with top humans players until chess engines were effectively unbeatable. And those unbeatable engines were trained by other AI, not by looking at human games. It got to the point where looking at how humans played would have just made it worse.

That's why they compared it with YouTube shorts, which is basically YouTube's TikTok replica.

I have never detected even a single advantage of systemd. It didn't bother me enough tow switch distributions, but that's the best I can say for it.

There's nothing in Linux that demands you use SystemD. You can choose to use SysVInit if you really want to. Indeed the only kernel requirement is something called "init" is either in /, /bin, or /usr/bin

But the init scripts are really just faking what init was doing - watching processes and restarting them as necessary. The SysVInit scripts are a crude re-implementation of inittab.

strncpy() was not intended for null-terminated strings at all. It should have been named copy_null_padded_buffer(). Then its operation would have made sense to almost anyone. People wouldn't have minded the longer name much either, because hardly anybody uses null-padded buffers in modern software.

Note that a null-padded buffer that is completely full doesn't have any nulls in it at all. That's why strncpy() doesn't necessarily add a null termination. It also fills the entire destination buffer with nulls after the end of a short copy, which can be very inefficient when used with null-terminated strings.

TL;DR: don't use strncpy(). It doesn't do what anybody thinks it does.

C doesn't have strings, but sometimes people like to have some bytes with a 0 on the end. Some of the memxxx() functions are useful with C's fake strings. For example, memchr() is good for when you have a null-terminated string but it also some upper bounds. And stuff like strncpy() doesn't appear to have anything at all to do with null terminated strings, and is grossly misnamed.

strncpy() copies a string to another location stopping when it reaches a NUL or the end of the buffer.

The problem is the second case doesn't NUL terminate the string so you either have to make the buffer one smaller and terminate always or terminate always. Or try to handle it. The other problem is 'n' is unintuitive - it's the size of the buffer in characters. Easy peasy with 8-bit chars, not so much for Unicode strings. (UTF-16...)

I've personally be more of a fan of the BSD "l" versions - strlcpy and strlcat - both take the size of the target buffer in bytes - so a sizeof() is the proper way to use it, and both properly NUL terminate the string. strlcat has the added benefit that it computes the size it needs to copy based on the existing length of the string, so you can use strlcat() to concatenate a bunch of strings without computing the remaining buffer sizes (as you would in strncat). Luckily the BSD versions are in libbsd because they aren't in Glibc. Much nicer and much easier to use functions.

On the other hand, any city resident who has ridden a city bus and been robbed or assaulted would probably vote for it in an instant. For that matter, any KC official who had been similarly victimized would probably do the same.

It is very easy to take the moral high ground in situations where you will not be affected by those policies. It is a different matter when you are one of rank and file who ride the bus every day.

And how often does that actually happen? Because it's a super common myth perpetuated by those who want a car-first lifestyle that public transportation is unsafe to promote their vehicles.

And yes, it does happen. But you know what? We have surveillance cameras already on buses and other public transit. Taxis have dashcams that face both ways.

And this has been true for decades.

The only difference now is facial recognition, which we already know is already problematic and full of false identification. And if necessary, people do run facial recognition on the surveillance video all the time - be it from a bus, workplace, public street, business, etc.

The car equivalent would be to put up more license plate readers everywhere snapping photos of everywhere you go. But we already know how that's going, and really, this should go the same way as well if you dislike license plate readers.

The difference is you were buying a license. The software maker couldn't really revoke your license to use it.

With PlayStation, Steam, etc., you aren't buying a license. You're renting one. That is, you get a license to use the software, but PlayStation, Valve, Microsoft, etc may at anytime decide to revoke that license from you for whatever reason. So at best, it's a long term rental without a clear return date.

And all the other stuff relating to owning the license versus renting the license - like being able to transfer the license to someone else. If you owned it you could sell it to someone else (e.g., "used games"). Something PlayStation pummelled Microsoft heavily on, even though Sony never really intended to follow through since they pushed digital sales harder.

It would be quite useful to have a database to search and find out what devices I own have been shown as guilty.

The problem is that it varies a lot. And basically it comes down to names - things that require internet access especially.

Things like streaming boxes - if you buy one of those questionable boxes at the mall that claim "never pay for cable again" and such, whilst offering full access to paid content, those may or may not come with a side helping of a VPN endpoint. But it's hard to say because the manufacturers of those boxes make them and put in clean firmware, and other companies buy them up and modify the firmware with their pirate apps and then add other stuff in as well. So you can buy the same box from 10 different vendors, have 10 different firmware on them, and 7 of them have the remote access service on them.

Likewise, that IoT camera you buy may come clean, or may have passed through a dozen hands which may have altered the firmware to add the remote endpoint into it. But again, the same problem remains - the camera is sold with a dozen different firmware from a dozen different companies.

And yes, isolating them is the first step because the remote endpoint software is just a VPN endpoint software - it allows some user to use your device and internet because it's endpoint software.

I grew up in a country that adopted PAL rather than NTSC, so never saw the hue and saturation settings until my family relocated to Canada. I was baffled by how backwards NTSC was.

NTSC is only backwards if you consider it had to work with TV standards that were around since the 1920s or so. It was nicknamed "Compatible Color" because its signal format worked with existing black and white TVs just as well as color TVs. The only change was a slight slowing from 60 fields per second to 59.94 (1000/1001) to accommodate a few cycles of the color carrier.

PAL came afterwards as a full color standard from the get-go - there were other TV standards but all incompatible. TVs that could not display color dropped the color information but it was there and didn't have to be worked around.

PAL worked through delay lines on the color carrier which meant the color sync would be locked on because the color carrier would be present. NTSC didn't have this luxury and the only color sync available was the color burst signal which meant you synced a clock to it, and that clock was used to figure out the color carrier. As the clock drifts through the field (because all clocks will drift) the color will drift as well because the color information is based on the phase difference between that reference clock and the signal. But since the clock drifts, the phase does to. The tint control adjusts the phasing of the signal.

Since PAL had an AM carrier it could be synced. NTSC had the carrier suppressed.

It should be noted that other than timing and the phase alternation, the TV signal formats are basically identical - an NTSC TV will be able to view a PAL signal, but in black and white as the color carriers between NTSC and PAL are different (3.58MHz vs. 4.43MHz) so it won't be able to actually get the color signal.

In Asia, multi-system TVs were basically standard - they could receive NTSC with 3.58MHz color carrier (North America, most everywhere using NTSC), NTSC with a 4.43MHz carrier (basically Japan, sometimes noted as NTSC-J), PAL and SECAM (both using a 4.43MHz carrier). The only real difference is the electron beam timings and how to decode the color - where the carrier is, and how to sync to the carrier - using an internal oscillator (NTSC with colorburst) or an external carrier (PAL/SECAM). Other than that, the information is identical.

And yes, you can run into this if you stick a PAL VHS tape into a NTSC VCR or vice versa. You can get a recognizable picture, though the timing might be off so your TV might be unable to sync properly. (VCRs only have a single sync source - the horizontal sync and the head reads the signal from there and each line is read at output at the appropriate rate).

With the right hype, and a high enough price tag on the machine, the coffee snobs will be all over this.

Well, cold coffee drinks are popular these days. An espresso that is made at room temperature means you can make a cold espresso drink much quicker and with less energy since you don't have to boil water only to cool it back down again.

This would be something you'll find at Starbucks, fine purveyors of sugary coffee drinks. Honestly, they aren't far removed from soft drinks nowadays given the amount of sugar in them. Especially their cold coffee drinks. Cold espresso mixed drinks? Sugar bomb

It has seemed to me, for a very long time, that modern AI systems would need to be integrated with standard RDBMS systems for reliable persistant storage of raw information, some sort of no-sql database (memcache or some variant) for persistant storage of associations, some sort of document database for blocks of textual information, a SPARQL system for searching semantically-marked information within the document database, and a more old-fashioned back-propogation NN to provide a store of understanding that the user can directly manipulate.

Probabalistic classifiers are all fine and good, but only for a subset of the tasks needed. The above structure is a very loose, wildly-speculative initial framework. It's almost certain that if you actually tried building an integrated multi-model system, that you'd end up making a lot of changes to this basic idea, but that you'd end up having to implement the same core concepts that are identified in it.