Is that you, ChatGPT? Welcome back dude!

Ultimately the best building security will be having an understanding with would-be thieves, that will focus on our mutual interests (..)

Yeah, sure. Try fences, sturdy doors, proper locks & camera's. And somebody / something checking the footage, with guards / cops on call.

Potentially: yes. If system developing the PLC code is compromised, then PLC code developed on that system, could be compromised as well.

It's not often heard of, but potentially very serious. This depends on # and type of customers that use the developed code. And how their systems are configured, deployed & managed.

See: supply chain attack. There are some infamous examples.

Note that PLC-controlled systems tend to be very customer specific. So it would be hard to exploit or profit from an attack. But if so, and target happens to be critical like large industrial site, chemical plant or such, then yeah... Stuxnet level.

WRONG. Most services will claim permission to use user content, but leave copyright where it is - with the user who created that content. You create = you own the copyright. For company to claim that, copyright would have to be shared between user & company (copyright law has no provision for that), or copyright transferred from user to company (which would be very problematic from legal p.o.v. in many use cases). Take for example confidential documents sent via email. If (for example) Google inspects that for antivirus, training internal systems etc - little you can do other than encrypt your stuff before sending. But if Google were to claim copyright over random documents you send via email... well, see how that goes in case it ever hits a court of law. Regardless of what Gmail's terms of service claim.

Exceptions might be things that were entirely created on company's systems. Or not expected to be user owned. For example when you're working on company product, using company's systems, while being paid to do so (employer-employee/contractor). Or in-game assets for some online multiplayer games, that were created using in-game tools. But in that case user already knows that content has a best-before date & wouldn't easily translate to outside-of-game uses (not legally, anyway).

But that is exception not the rule. Where it gets shady: content from users who've closed their account. In some cases that may involve removal of files such that they become inaccessible to other users. But company probably keeps it archived. In some cases the usage-permission may end when user account is closed. Or not (see ToS). In some cases ToS may say permission ends, but company ignores & continues to use that content regardless. Or (likely illegal) scrapes content from competitors or random websites.

I can imagine a future scenario as follows: user buys device X, during checkout selects Y as preferred OS. All OSes of note that can run on device X, are included as option.

Selected OS is preconfigured to run on device, using some enterprise scale fully automated system, built atop a vast database of OS versions, drivers, configuration options, device-dependent defaults, etc, etc, going at least 10 years back for popular options.

How this works exactly, is (mostly) irrelevant from user point of view. Might be standardized configurations for some niche OSes (with limited set of supported devices), different flavours of current / popular OSes, components compiled on-demand on server side, cached or not, binaries for every relevant version/OS pulled from database, etc, etc. The point is it's all automated, all options & their combinations are put into a constraint solver of some kind (like advanced package managers of today), and resulting OS image for preloading on device, is generated on demand.

Upon receiving device, user browses through a Play Store like environment, or even a souped up start menu with 100k+ entries most of which are greyed out, some present pricing options, caveats, user reviews, etc. Payment options are mostly automated, a configuration setting or 2-second "I'm okay with that!" away.

Upon selecting a (greyed out) app, server is contacted. Informs OS what VM or emulator to set up, what libraries & compatibility layers to install, what settings to apply, etc. Again: fully automated. App binary, game data etc is pulled from database or generated on-the-fly in same fashion as OS image used to preload device.

There may be community maintained versions of this "enterprise scale, database backed system". There will be commercial ones. Some may be run as a Netflix style service. Some apps may run server side, streaming to user device. Or be browser based using tech like WebAssembly. But for the vast majority of users, it's irrelevant to the point of "buy device, select preload option, and run apps".

Most pieces are already in place: a vast selection of (binary) apps & OSes including open source ones. Emulators, virtual machines, compatibility layers, binary code translators, Snap, Flatpak, etc etc. Figuring out which combination of options could be used = constraint solving. The state of the art in that has advanced considerably. Automated build farms and networks of download mirrors or other content distribution systems, are in place & actively used.

Yeah I know this is just a vision, and some puzzle pieces are missing. But one can hardly deny that in software land, there is some degree of convergence going on. Major OS choices these days are Windows, Mac, Android or Linux. All offering a comparable feature set, with considerable cross-polination in terms of software libraries, GUI features, and hardware support. Making it (almost) possible to run any popular application software on any popular OS. Not to mention AI powered 'coding bots' that -in near future- may plug some of the holes.

So the answer to question raised in the article: in practice, it is less & less relevant. Pick a set of apps, pick OS, pick device supporting that, download & enjoy.

It's kind of like elections: it's not about winning party confirming they've won, but about convincing losing side they've lost.

In war, this used to be done on the battlefield, by inflicting a decisive defeat onto the enemy. These days... let's just say there are other methods. The battlefield has moved from tanks, planes & artillery to political / economic pressure, cyber warfare, muffling free press, influencing social media to sway public opinion, etc. Military might may still work, but is oldfashioned (and more importantly: crude) method with nasty & unpredictable side effects.

So these days, only dumb leaders rely on their military. Smart leaders play the socials.

How about splitting the projectile, instead?

Shortly before impact, have impactor fall apart into a number of smaller ones. Like a cluster bomb or multi-warhead missile. Drifting apart just enough to hit asteroid with many small impacts across a large area. Overall pushing effect on the object would be about the same.

In case that mechanism failed, you'd still have the object-pushing single impact like the one observed here.

Few exceptions aside, decent companies aren't in the hands of shareholders. Period.

A family business / other privately owned, or democratic government backed enterprise, or non-profit... possibly decent.

Run-of-the-mill public corporation (esp. big multinational)... unlikely.

This war well end. Probably by Putin's regime collapsing - somehow.

I'm sort of expecting that Ukraine will see quite a bit of aid in rebuilding the country. And a good portion of people who fled, will return.

Russia, not so much. As a nation, it doesn't have many friends left. Economy is going down the drain, and (temporary?) high prices for its oil & gas exports won't last, volumes will go down. That income not enough to compensate for all other factors that will be hurting Russia's economy. Foreign aid? (after the war). Forget it.

If you're one of those young / educated people from Ukraine, would you return to your homeland after the war? Maybe, probably, likely. Let's say 50/50 chance or better? Same group, for Russia? Probably not, build new life elsewhere.

This will keep hurting Russia far longer than Ukraine. Maybe, if a miracle happens & Russia steps back onto a path towards democracy... but given Russia's history that would be surprising. More likely another autocrat strongman will step up. Ukraine otoh, will probably join EU by then. That's where it's heading, and they've earned it.

Generalizing or modding queries into "popular", produces more results. But with huge amounts of content on virtually any subject, that isn't helpful.

Few users scroll through more than a few pages of results. Simply having more of those, only serves to bury more specific or relevant results.

Search engines should strive for those specific, less popular, unique / uncommon search terms as provided by users. In your example: maybe user was looking for some other Britney Spears than the singer. Or trying to find out how common the name "Britney" or "Spears" or some variations are. Or trying to figure out if there are alternate spellings for name of [popular figure]. Was it actually mis-spelled? User's fault, no problem if search results reflect that.

In short: mess with search algorithms. But do assume users know what they're doing, and don't mess with their queries. From what I've seen (so far), inserting AI everywhere doesn't help either. Suggestions, or "Did you mean ...?" can always be shown as an option. If users input stupid queries, let them win stupid prizes.

Some recent study (sorry, don't have a link) concluded that as more modern-day performance optimizations are applied (process node, many-stage pipelines, advanced branch prediction, caches, out-of-order execution, instruction level parallelism, etc etc what have you), the less relevant a software-presented ISA becomes. That is: ISA's tend to converge for high-performance parts.

So you can have a few cores with high single-thread performance, or lower-performance cores but more of them. You can have a high-performance CPU with a large power budget, or a small power budget with low(er) performance CPU. But ultimately, it's the implementation that matters, and (assuming that's done well) useful work done per energy spent tends to converge, and whether that's x86, ARM, RISC-V or other becomes more or less a wash.

x86 has traditionally been big in large power budget, high-performance desktop & server CPUs. ARM has traditionally been king in low power mobile CPUs. But nothing says they (or a new ISA like RISC-V) can't invade each other's territory.

On the lower end of the scale (microcontrollers), it's a different ballgame. And of course there's applications with very specific requirements (AI, floating point-heavy scientific computing, legacy software support, GPU-style graphics processing, DSP's, safety critical or radiation-hardened, FPGA's, coin mining, etc)

I've been following RISC-V developments for a while now, and what's happening gives reason for optimism in this regard. Some observations:

Vector extension(s?) are a hot topic among implementers. Not surprising, given the big impact they can have on common audio/video codecs. There are some pre-spec implementations out there, but compiler support for those is (and likely, remains) poor. So it's safe to expect implementations out in the field 5..10 years from now, will be ones following post-frozen spec, with pre-spec ones increasingly rare over time. Compiler support for frozen/ratified extensions is coming along nicely. Little if any fragmentation there.

Practically all implementations meant to support general-purpose OS, are multicore RV64G or superset, read: support integer multiplication/division, floating point, atomics, and cache coherency (fence) instructions. Most of these also support the -C (compressed) extension. Have NOT seen any 64-bit implementations that don't include a MMU (virtual memory, OS vs. userland).

There's hardly any multi-core RV32I silicon out there. I suspect implementers doing multi-core, are doing complex System-on-Chips where the extra silicon area for RV32I -> RV64I is 'free', and CPU performance / memory considerations (code density, >4GB RAM etc) favour 64-bit. Relegating RV32I to the (mostly single-core) microcontroller domain. RV32I cores are small enough to replace eg. a 8051 or Cortex-M0 core in deeply embedded applications.

I currently have a board on order, that's based on StarFive's JH7110. CPU benchmarks put it roughly on par with a Raspberry Pi 3 (not -4). Its GPU is supposedly stronger than RPi's GPU, but driver support for 3D acceleration is sketchy at this point. Much of this driver support is being upstreamed though.

Same SoC is one of the first (if not the first) to support general-purpose use (eg. desktop replacement), and generally available on several affordable (~$100) boards. So it sets a clear baseline in terms of supported features that buyers of such a board could expect. Nothing to stop would-be competitors from implementing a very different set of extensions. But if not supporting features common on boards already out there, chances are would-be competitor is dead on arrival.

Software has some rough edges which are being ironed out. But many things already work as normal. And things change quickly in RISC-V land, especially software side. Vulkan drivers are being worked on, next Debian release is set to include RISC-V as supported architecture, etc etc.

TLDR; toolchains & OS support is maturing, silicon is landing, and prices are dropping fast.

P.S. with "implementations", here I mean actual silicon, that's out on the market & available for purchase. Not the many FPGA designs, IP cores etc.

There's 3 factors involved:

• 1) How much rain falls in what timespan.
• 2) How well drainage systems handle that.
• 3) How much water can be stored on-site (or nearby), and for how long. Read: water seeping directly into the soil, stored & slowly released afterwards. Or caught in reservoirs or rainwater harvesting systems.

That last factor tends to be overlooked, but can have dramatic effect on how severe flooding events are. Most cities have every m^2 paved, routing any rainfall to drainage systems. Rip up some of that pavement (green borders, trees, parks, grass lawns, ponds, etc) and water that hits such a green area largely stays there. Reducing the load on drainage systems.

Of course 700+ mm. in one event is crazy amount. For comparison: that's roughly the same amount of rainfall the Netherlands (temperate sea climate, Cfb in Köppen system) gets.

In a YEAR.

"GNU/Linux" isn't even accurate.

It is (or mostly, was) sometimes used to refer to GNU based OS running on Linux kernel. Like how *BSD refers to BSD userland + matching kernel, maintained as a whole.

That's not how it works. Linux distributions come in many shapes & sizes, which primarily have "using Linux kernel" in common. Some may use non-GNU userland, most will include packages from 1001 sources, including but not limited to GNU software. Components are maintained by many different parties, distro maintainers mostly do packaging, branding & default configuration of those components. There's no such thing as GNU OS or GNU distribution that I'm aware of. Just many 'grab bags' of components of which GNU is a commonly used & important one.

Yes, the GNU project has been an important factor in the spread of Linux. And modern day Linux users have a lot to thank GNU project contributors for. But "GNU/Linux" singles out GNU as the party providing userland for Linux based systems. That's just not fair, and ignores those other 1001 sources of software included in modern distro's. Apart from mis-labeling specialized Linux distro's that have non-GNU userland, or are basically Linux kernel + a statically compiled binary on top.

Regardless of technology. But in the case of nuclear, accidents have a higher tendency towards "spectacular effect".

Procedures & physical safety devices only go so far to avoid 'spectacular' mishaps. Not to mention intentional acts (sabotage, terrorists, cutting corners to safe costs, etc).

The safest move is not to play.