You add it to enough regular uranium or uranium ore that the enrichment goes under fuel rod levels. One part weapons-grade to 4 parts unenriched uranium should be safe.
Adding it to concrete is not very effective, it's easy to purify uranium from other elements and then you just get your enriched uranium back. For separating elements you can use chemistry, only separating isotopes is hard.
It's complicated.We have time at a large scale, and at a small scale. On the small scale, particles interact with time but in a mostly symmetric way, forwards and backwards are the same.
This would and does translate upwards, except it so happens in our "past" is a low entropy state, the "early" universe. Entropy tends to increase, energy spreads out, so what we call time, or more important causality, is the gradient of entropy.
For all we know, another universe could be in the past "before" "the big bang", which has its entropic time running the other way, also towards an expanding universe. (this is kinda adjacent to the big bounce theories, but does not postulate this repeats).
Now, there is a bunch of weird stuff general relativity permits with spacetime, including stuff that time travels (e.g. wormholes, warpdrives). This may or may not be possible to create if it doesn't currently exist, and it also may or may not be possible to use without getting destroyed even if it exists.But interestingly, even if it were to be usable, be it wormholes, ftl warp stuff, or whatever, it may not break entropic time, only particle time which noone cares about. Causality may simply still be running forwards through that connection. That's still in the theorycrafting stage though.
There is yet more weirdness. For example, when you cross the event horizon of a black hole, you cannot go back, only slow your speed of going forwards, but you can with that travel through things that have fallen in before and after you. So compared to outside, entropic time is now in the direction of a spacial direction. Technically this lets you time travel through the particle-time axis, by some definition, but entropic time is still boringly pointing in one direction, though now by some more definitions that entropic time would causally sit after the end of our universe, so you have very efficiently entropically time-travelled to the end of the universe, infinitely far into the future.
So yeah tldr what we mean by time travel is not looking very possible lately (other than travelling to the future).
One of the reasons why if I ever get a phone supporting gos, I will root it.What business does an os have to support taking screenshots, and support disabling notifications, but then make it completely impossible to take screenshots of some things or disable some notifications out of judgement that is sometimes just wrong.
The headline is claiming that. You can't just lie and then walk it back once someone clicks. There is a limit to how much inaccuracy you can put into a headline to simplify it, and this is definitely past it. To save one word they make it this wrong.
I have used both for a long time. Initially freefilesync, then later syncthing.
I have to say the difference isn't great but syncthing is definitely nicer to use.
For one, syncthing can do more. The syncs are more efficient (it can send only changed parts of files, ...), offer more customizability, it's way more capable in networking, or when devices go offline intermittently.
Syncthing also runs a bit better. It is more like a service, I had to babysit ffs a lot in comparison. It also properly detects file changes, ffs's "service" just triggered a full disk scan after a bit.
The webinterface is nicer than logfiles I had freefilesync dump on a dedicated nas share.
One mixed bag is that ffs has to work through network mounts, while syncthing has to work via its own networking (I can still share network mounts with it ofc). In practice there is no network share that is as efficient as syncthing, but it has the downside that syncthing needs to run on both sides where ffs only runs on one side.On the other hand that automatically gives some checking since if one end dies the other will complain.... Thinking about it more, in theory you could run 2 syncthings on the same machine, and give one network shares of one target and the other of another, then make them sync. That would keep syncthing traffic in localhost, essentially replicating ffs, if a bit clunkily.
Another potentially big thing is syncthing can do many-device shares. It even does fancy routing things balancing between nodes. This is probably a big deal if you wanna have say 2 backups (one could even easily be offsite, with no networking required except regular residential internet access).ffs I would expect to become messy with more than 2 devices. I never tried, but I recall it being set up around having precisely one sender one receiver folder, so even cycling 3 scripts would probably break conflict resolution and also be a huge pain and perform poorly.
Never mind the privacy implications. Could you imagine if a rogue actor got into the system-level of your iPhone, disguised as an AI assistant?
I don't see the point here. Assistants are inherently untrustworthy. They are unreliable, and can be taken over vy hostile actors. Or, from Apples perspective, by the user.You can't let users jailbreak their phones using siri prompt injection, and you can't let siri perform any system actions or exfiltrate data without confirmations because it could go rogue or be taken over by some prompt smuggled into it by a hostile actor.If you have to safeguard it anyway, and it is untrustworthx anyway, you already have to make it withstand everything an untrustworthy 3rd party implementation could do.
Gott verdenke dass eine gute Tat (aus Sicht der Regierung) ungestraft bleibe.
Du hast vor 15 Jahren freiwillig gedient? Jo fick dich dien halt noch mehr.Findest keinen Job weil du als ex-freiwilliger gebrandmarkt bist? Komm arbeite doch bei der Arme, da kannst du nicht eingezogen werden.
Not sure where you are taking that from. Wikipedia has
Later, in an Ars Technica interview, Sid Meier similarly stated that the bug was possible, "but it was not intentional".
On September 8, 2020, Sid Meier's autobiography, Sid Meier's Memoir!: A Life in Computer Games, was released, containing confirmation that the Gandhi software bug was fabricated and a detailed background of the urban legend's formation.
So this sounds like the statement you refer to was not "ultimate" but still part of creating the hoax.
Edit:Quoting the translation of one of the sources here:
The myth was also refuted by Brian Reynolds, the leading game designer of Civilization II - in a video for People's Games, his quote is mentioned, that the game has only three possible levels of aggression, and not 10 or 255. At the same time, at the first level there was not only Gandhi, but also other leaders, which in this case should lead to similar bugs with many other factions.[...]It all started with Sid Meier's Civilization V. In it, India really had the preference for nuclear weapons to other forms of warfare at a point close to the maximum - at level 12. John Shafer, the leading game designer of the fifth “Civilization”, made this parameter so high solely for the sake of a joke.
Article goes into it a bit more, but summary it all started with Civ5 in 2010, where it was an intentional (joke) decision not a bug.All nuclear ghandi stuff dates to civ5, it did not exist before that time. Then in 2014 someone on reddit made up the hoax and publications just ran with it.
Falls es irgendwer verpasst hat, es ging nicht darum Zwangsabtreibungen o.ä. durchzusetzen, das sollte migration verbieten.
Erst Asyl und Familiennachzug ab 9.5 mio Einwohnern, dann EU Schengenzeugs, also EU Bürger ohne schweizer Pass aus der Schweiz werfen.