yyyk

Obvious problem is anticircumvention laws are just as much an interest of the EU and others. These laws pass power from the individual, and the EU (its corps and govs) are just as interested in exercising power over the individual.

Oh dear, time to switch to OpenVMS on Itanium arch.

Note most modern Chess engines use UCI instead of Winboard protocol. But either is fine really.

>this is the very opposite of the ideological premise to justify a genocide.

Genocide is an attempt to kill a group; That does not happen only by murdering people - it's also forced assimilation. In this case, Russia is directly violating article 2) e) of the Genocide Convention*: "Forcibly transferring children of the group to another group."

>citizenship

Citizenship is not relevant to the genocide convention at all.

* https://en.wikipedia.org/wiki/Genocide_Convention

Actually, they did not want US to attack Iraq:

https://forward.com/opinion/9839/sharon-warned-bush/

That will never ever happen. Making 240/4 public will break Amazon (and many others) which do use it privately. The software updates to route it across the net would have been taxing. When making it public was suggested years ago, IETF saw the proposition as encouraging IPv4 and refused to entertain it.

In short: The market has already decided and it's private. It's far from the first time an unofficial arrangement is the de facto standard.

It's not Second System Syndrome. Nearly every complaint against IPv6 is downstream of the decision to enforce a global centralized namespace for an end-to-end principle many don't care for.

e.g. Getting a unique address would be way more risky with 64 bits (there's a reason UUIDs are 128 bits too!), even before considering the network:interface split.

240/4 is private and more than sufficient.

Didn't you read the Classic sci-fi novel 'Create The Torment Nexus'?

SSD controllers and VFSs are often optimized for sequential access (e.g. readahead cache) which leads to software being written to do sequential access for speed which leads to optimization for that access pattern, and so on.

Aka .NET SecureString - which is barely used because everything accepts String.

It's clear humans have several networks working together. Some Mathematicians report they 'see' the solution, these rely on a visual network *. Others report they prefer to do math symbolically (relying on the language network?).

Perhaps there are also multiple human paths to higher-level thought, with Keller (who lost her sight) using the language facility while others don't have to.

* Given Box 1 contents, the article authors seem unaware of the research on this? e.g.

https://www.youcubed.org/resource/visual-mathematics/

https://www.hilarispublisher.com/open-access/seeing-as-under...

3-4 years is political eternity.

Every bulk transactional email provider I could find* allows SMTP relay even in the basic/free plans. That feature seems to come for free everywhere.

* e.g. SendGrid, Postmark, mailjet, mailgun, mailerroo, etc.

These are email marketing platforms, not bulk transaction email platforms, and I don't see why they can't do with the latter. At a bulk transaction platform, such a tiny amount would cost at most $20-$50/mo. If you're willing to do a bit of work to use AWS SES, that would be $2-$5 a month. Azure ACS would be even cheaper.

OpenBSD FFS is robust in the sense of 'it is unlikely an FFS bug will lose your data'. But it is ancient, and, well, there are reasons for filesystem developments in the last half century, like 'not losing your data thanks to blackouts or hw bug'.

The lack of at least a journaling FS is inexcusable in a modern OS. Linux and Windows have had it for 25 years by now, and we could argue softupdates are roughly equivalent (FreeBSD has had SU+J for years now too).

Careful on what you wish for. The same regulatory action can be (is) being used for Chat Control (that dropped off the main page for some reason). Ultimately neither power center acts for the general interest.

This assumes the direct mode of exploitation. The indirect mode (where an attacker inserts a vulnerability) does not necessarily have the 'short time span' issue. So not a complete solution by any means.

Also, there should a way to distinguish between security updates and normal updates for this. If there is, a cooldown is a useful idea in general for normal updates, since (presumably) the current version works and the new version may introduce bugs.

Sounds like an idea that would really benefit from a JIT-like approach to basically every software.

By that logic, wouldn't the electric kettle heating water for the coffee be intelligent? Had it not measured heat when activated, it wouldn't know how to stop and the man would have thrown it away or at least stopped paying for the kettle's electricity.

I think we need a meta layer - ability to reason over one's own goals (this does not contradict the environment creating hard constraints). The man has it. The machine may have it (notably a paperclip maximizer will not count under this criteria). The crow does not.

The reddit people are very skeptical regarding the paper:

https://www.reddit.com/r/computerscience/comments/1odgx6v/le...

https://www.reddit.com/r/learnmath/comments/1odh3f5/is_this_...

If "newer = better" was my thinking, I'd be all for these new protocols on top of JMAP. But I actually think they're useful only in a limited context.

JMAP is better than IMAP because IMAP is a too stateful design, the IMAP/SMTP distinction allows for misconfigurations where sending doesn't work, has dozens of extensions where key extensions are inconsistently supported, doesn't have as many batched operations, etc. One could make an effort to improve IMAP - but the effort to do this consistently in server software would likely be comparable to adding JMAP and the result worse...

OTOH, the new protocols intrude on areas that go far beyond email software (you're very unlikely to get support for these in older Androids/iOS/Windows even if the modern OSs ever consider them), and don't offer as much as JMAP offers over IMAP. The cost/benefit is worse. They may make sense for a JMAP email client but IMHO not elsewhere.

I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere).

I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the 'already wrote a JMAP email client' case. Virtually any other case would rather stay with widely supported protocols?

Cheque depositing? Fingerprint (etc.) login?

I like KDE (definitely better than Gnome), but their Wayland migration in KDE6 removed features that could still be implemented. e.g. I get why they don't want custom lockscreen programs now, but running custom scripts on lock/unlock was removed. That's rather unfortunate.

So it's just a a generator with yield?

After 2100... I'm sure we'll have some way of handling it by then.

Really bad GPT answer on so many levels. e.g. Tunisia is much worse now; Bangladesh succeeded in toppling the old regime (we'll see about the new gov). Myanmar became a full fledged war that they might actually win (IMHO, the junta would be done by now had it not been for China).

Tunisia fell back hard. The new dictator has way more power now.

Grok is a lickspittle, don't ask it about facts. But the clever thing is that Grok can do meta queries for you ('give me the last 30 users from X who posted about Y using the word...').