Depends on your health insurance. My previous insurance company paid back the full cost when I was 30 years old. I can recommend checking https://www.entschiedengegenkrebs.de/vorbeugen/kostenerstatt... (and then also confirming that with the insurance company over text, just to be safe)
HN user
dTP90pN
What happened to the good old tin can telephone down the side of the house to the washing room?
There's no "relaying" when the the attacker just captures unencrypted WiFi packets from the air, or more traditionally, splits some light out of the fiber line.
The German Wikipedia has a list of such DDIs in various countries (primarily France since they apparently invented them in the 1970s):
https://de.m.wikipedia.org/wiki/Anschlussstelle_(Autobahn)#D...
The real solution is obviously to use geolocation to find the closest country which officially uses the individual language(s).
A small number of people with likely professional involvement in the Fedora project and possibly RHEL.
A supply chain attack serve as the basis for another supply chain attack.
If Xen uses these addresses "on boot", why has booting Xen worked the past 11 years then?
You can "wipe"/"drag" upwards to exit the A/C overlay (just like, for example, android quick settings/notifications).
Of course, you have to do this the "correct way", which in and of itself requires a bit of experimentation to learn.
Mozilla implemented a fork server to fix this issue. It is enabled in the new deb packages, but not yet in "normal" Firefox:
Why would Firefox have to "rollback" their UA string back to version 64, released 6 years ago (2018)? That seems utterly ridiculous for a server side UA sniffing bug rolled out by the Google Search Team.
This does not account for inattentional deafness, which is why there ought to be sense-redundant alerts, at least for alerts requiring immediate action.
If web developers would just start using `<time>`, we might someday reach such a reality.
To be fair, SDDM has the same issue, at least on multi monitor setups.
You have to choose between HuC firmare loading (required for media hardware-acceleration; old i915 driver only) and VM_BIND support (required by various games; new Xe driver only)
Prospective owners which use Linux should know, that they will have to decide which driver to run: i915 with hardware-acceleration support (more generally, HuC), or Xe with VM_BIND support (highly relevant for gaming):
If you're not running a Zen 2 CPU or APU, you don't have to worry about this.
If you're running the latest kernel, which automatically sets the chicken bit, you don't have to worry about this.
If you're running fixed microcode, which is only available for Rome, Castle Peak and Mendocino, you don't have to worry about this. Good microcode revisions are:
Rome / Castle Peak: 0x0830107a (published)
Xbox Series X: unknown
Renoir / Grey Hawk: 0x0860010b
Lucienne: 0x08608105
Matisse: 0x08701032
Van Gogh (Steam Deck): unknown
Mendocino: 0x08a00008 (published)
If you're running neither the latest kernel, nor fixed microcode, you should set the chicken bit yourself until you have updated those. wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))More details:
`good_revs` as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...
Currently published revs ("Patch") (git HEAD):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
As of this writing, only two of the five `good_rev`s have been published.
AMD have released an microcode update for affected processors.
I don't think that is correct. AMD has released a microcode update[0] for family 17h models 0x31 and 0xa0, which corresponds to Rome, Castle Peak and Mendocino as per WikiChip [1].
So far, there seems to be no microcode update for Renoir, Grey Hawk, Lucienne, Matisse and Van Gogh. Fortunately, the newly released kernels can and do simply set the chicken bit for those. [2]
[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
[2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...
You seem to be incapable of understanding that it is quite possible and not at all unusual to internally carry patches to dependencies on which your commercial product is built. In this case, the patch merely involves changing two bytes[1], three if you include the pyOpenSSL bump, something a company like IBM should easily be able to do.
[1] https://github.com/mitmproxy/mitmproxy/commit/8c6ec5cb56fbf4...
Btrfs mounting of larger arrays became near-instant for me with the new block group tree enabled; see btrfstune: https://btrfs.readthedocs.io/en/latest/btrfstune.html
~~While school/company IT as a use case is being considered[1], that is not the primary intent for this feature.~~
edit: I misread that ticket. It's about allowing school/company IT to disable the feature, not to allow them to use it.
Mozilla can remotely set that pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1832791
There is consideration to allow enterprises to disable this feature though: https://bugzilla.mozilla.org/show_bug.cgi?id=1834985
edit: fixed 2nd link description.
Have you looked at the crash reports via `about:crashes`? This should show you if there's any open bug report associated with the crash(es) you encounter.
Regarding libdbus-glib-1-2, you may want to open a bug. It looks like [1] it's mainly used by the ~12 year old UPowerClient, and more recently, for wake/sleep and timezone change notifications (nsAppShell).
[1] https://searchfox.org/mozilla-central/search?q=DBusG.*&path=...
So you would've considered the Honda Civic to not be violating the rule, if it had been unregistered?
Note: According to the published server source code, the NotificationCheckInterval has been increased to 60s sometime in back in March:
https://github.com/christianselig/apollo-backend/blob/b992d2...
Reddit had many years to listen to 3p devs and to it's own internal developers to improve their API. They/Leadership decided not to do so.
Do you mean native JSDoc namepaths like
/**
* @type {module:look/here~MyType}
*/
or TypeScript "JSDoc" imports like /**
* @type {typeof import("./look/here").MyType}
*/
or both?Here's the tzdata: https://github.com/eggert/tz/blob/71faa2a55db2c9f21f4099b58c...
Looks like the negative DST has already caused problems in the past and applications that can't handle it (ICU & OpenJDK) have to build tzdata as per the rearguard section / ziguard.awk.
Did that end up becoming a problem in all the other distros using aliased directories, for example Fedora which has 10 years of experience with this scheme? An quick look on Fedora 35 with
$ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin
doesn't really show any objectionable binaries being referred to via /bin (I count those I excluded in the negative lookahead as certainly non-objectionable).(I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier)
[1] http://www.drregex.com/2019/02/variable-length-lookbehinds-a...
Alternatively, a simple
grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin
to also include binary files does the job as well.Minus the high safety profile current vaccines exhibit.
The newer 12-page version on the preprint server has a PDF creation date of 3/3/2021, 11:32:56 AM, created with pdfeTeX-1.30.4.
https://eprint.iacr.org/eprint-bin/getfile.pl?entry=2021/232...
The previous (reportedly wrongly uploaded) version is from 12/5/2019, 9:10:13 AM created with pdfeTeX-1.30.4.
https://eprint.iacr.org/eprint-bin/getfile.pl?entry=2021/232...
The university website version is from 3/5/2020, 12:00:19 PM created with pdfTeX-1.40.15.
These dates & times are MM/DD/YYYY & CET.
A co-editor of the Cryptology ePrint Archive confirmed the submission on twitter: