I was thinking about this the other day when watching a video about Chernobyl.
They flew countless helicopters over the exposed reactor core and because this was 1986, helicopters didn't have a million sensors or electronics in it. It was entirely mechanical. Effectively all in-use aircraft nowadays could not complete such a mission as the electronics would be rendered null almost instantaneously, even with ECC, etc.
Do these high energy lasers fry the electronics, or are they able to simply ignite and burn holes through the aircraft?
I had to vouch your comment as it and most comments from your account are auto [dead].
The lasers can fry sensors like I mentioned. They can also burn holes in the body of the aircraft and damage engines. I think you may be conflating the modern glass displays with the sensors themselves. In many cases the actual sensors have not changed that much in terms of being vulnerable to directed energy weapons. The energy being emitted from Chernobyl was gamma radiation which at high enough prolonged exposure can cause bit flips. The two TU-16 bombers that seeded rain clouds around Chernobyl were not affected at all by the gamma radiation and I doubt modern aircraft would be affected just flying over it.
Some time log out and view your comments [1] as almost all are auto [dead]. A new account could be a fresh start.
No. This person should not try to circumvent moderation by creating new accounts. They should ask the moderation team for reinstatement of normal posting privileges, but be willing to accept a refusal. They've behaved appallingly.
I havnt seen this before Does (dead) mean they got downvoted or that everything they write is voided? How do you know what they wrote is appallingly bad?
Because 'Teams' isn't just a simple meeting application. It's very feature rich.
If you ever have to deal with the admin.teams.microsoft portal you'll know how many options and toggles it has.
Alongside this many businesses deploy 'Teams Supported' or 'Teams Enabled' devices into meeting and conference rooms. Yealink is a popular brand, they don't have baked in support for LibreMeet or whatever meeting products exist.
If you are <30 and are not in a trade related field, you will likely be unable to purchase a home in your life time.
Banks in Australia are now denying University Graduates, including those like myself in IT Industries, home loans due to increased risk of AI replacement in various workforces.
The "fatigue" from long trips is hardly a result of having to keep in a lane.
It's more so the result of being awake, doing effectively nothing, for a long time. Lane Keep assistance is a useless technology for 99% of the population and the 1% who need it, likely shouldn't be driving a car anyways.
The more we "aid" fatigue, the longer drivers will attempt to drive. This cannot be a good outcome. The worst driving occurs when one is practically half asleep.
I’m not referring to mental fatigue, but the physical ergonomic fatigue simply from continually activating muscles in a narrow range of motion even over a couple of hours.
If you’ve ever driven a 1970s truck you’ll know that continually correcting the steering will wear you out after just a couple of hours. Modern rack and pinion steering is a lot more comfortable, and lane keep is a further comfort improvement.
That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.
If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)
Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.
Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.
Flagship Samsung from the last 3 years. I have to expose myself to 2G, despite no 2G towers being active in my country. We don't even have 3G anymore either.
Probably breaks some other very important things in Windows.
Not a foolproof solution though, you don't want to be constantly updating your hosts file every time Microsoft changes an endpoint to rename their product offering for the 3rd time this year.
Of course this is where PiHole or some other DNS solution comes in, but ultimately a full uninstall would be preferable.
I recently switched to Fedora. I have enjoyed it thoroughly although I am a little skeptical how the upgrade process for Fedora will go when Fedora 44 eventually comes out.
One of the concerns is the package delays on the RPM Fusion repo. I've heard it can take weeks before updated packages are shipped, a package without a valid Fedora 44 compatible package will prevent the update from being installed.
COPR is another can of worms, most people just recommend disabling all COPR packages before upgrading.
What can Terra offer me? How can I prevent dependency hell? What is the upgrade process like when lots of Terra packages are installed?
To solve this, I personally simply wait a few weeks before updating Fedora versions! Generally that's a good idea not only because of RPMFusion, but specially because of the multitude of GNOME Extensions I use, some of which take a bit longer to update whenever there's a new GNOME release.
> I have enjoyed it thoroughly although I am a little skeptical how the upgrade process for Fedora will go when Fedora 44 eventually comes out.
I've updated my current system to every release from Fedora 36 through Fedora 43, and I've had minor issues twice (as in, things that were unexpected/annoying, but I was still able to boot, log in to a GUI, and use Firefox without any problems), but the other 5 updates had zero issues. The updates are usually so uneventful that once my server automatically upgraded to the next version (which is my fault because I misconfigured it), and I didn't even notice until 3 days later.
> One of the concerns is the package delays on the RPM Fusion repo. I've heard it can take weeks before updated packages are shipped, a package without a valid Fedora 44 compatible package will prevent the update from being installed.
I nearly always update the first week that a new release is available, and I have most of the RPM Fusion packages installed, bu I don't remember ever being held up by this. The RPM Fusion packages are often delayed behind the official Fedora ones, and this can lead to some annoying errors in dnf if you don't use the right flags, but usually this is only for a few days—I can only remember a week-long delay happening once. (And right after a new release is usually when RPM Fusion is the most up-to-date, since the main Fedora repos are frozen for a few days before a new release, giving RPM Fusion time to update)
> COPR is another can of worms, most people just recommend disabling all COPR packages before upgrading.
I definitely concur with this advice; COPR causes enough problems that I'd recommend avoiding it entirely unless it has something really important or your technically savvy enough to fix any problems yourself.
> What is the upgrade process like when lots of Terra packages are installed?
I only have two Terra packages installed, and I've only used it for a bit under two years, but I don't remember it ever causing any issues while upgrading.
They flew countless helicopters over the exposed reactor core and because this was 1986, helicopters didn't have a million sensors or electronics in it. It was entirely mechanical. Effectively all in-use aircraft nowadays could not complete such a mission as the electronics would be rendered null almost instantaneously, even with ECC, etc.
Do these high energy lasers fry the electronics, or are they able to simply ignite and burn holes through the aircraft?