Either the vaccine has notable safety issues or it should be at least fine to get the vaccine at an older age.
The reason many people don't trust the CDC's advice is they don't really tell you why or why not.
If you're over 26 you're pretty likely to already be exposed to HPV but not necessarily every strain which would be protected by the vaccine (as it says in the article).
So this pushes the question: why shouldn't I get it even if there's only a small chance it will be beneficial at my age? Is there really a risk they're not telling me about or are they giving bullshit answers? There isn't a third direction.
Vaccine recommendations are based on more than just safety. Efficacy, cost, availability, and prioritization are also considerations.
> Compared with the benefit of the existing HPV vaccination program for adolescents and young adults through age 26 years, the additional benefit of vaccinating people age 27 through 45 years would be minimal.
> Given abundant evidence for safety of HPV vaccines, undesirable anticipated effects are minimal. Also, anticipated population-level benefits are minimal for vaccinating adults over age 26 years. In this scenario, other considerations including cost-effectiveness play an important role in guiding policy-making.
> There’s not a safety issue past age 45. We just aren’t sure how much the vaccine will help men and women who are past that age, because so many of us have acquired HPV by that point, and because it takes many years for cancer to develop after acquiring the virus. However, as the average life expectancy increases, it may benefit the population to increase the age limit for HPV vaccination as well.
Thats nonsense. Their "recommendation" is based on supply and epidemiological trends, not actual need of the drug. If supply gets constrained, its up to the CDC and drug makers to make more, not to tell the population to limit uptake.
This is why I don't trust CDC guidelines, nor doctors who blindly parrot them without explanation or context.
Sure, check with "your doctor" about the vaccine. If they give you no good reason not to take it, then take it.
CDC guidelines are nonsense here and I fail to see why they would give them. Is there a vaccine shortage?
The claim is that you're more likely to catch the virus early in your life and thus "lifetime efficacy" is reduced as you grow older. Duh, this is true of any vaccine. There are various strains of HPV and you can catch them one after the other. Having HPV at 50 is just as painful as when you're 18, if not more since your immune system is less effective.
The second part of I don't understand this advice is that they say there's no HPV test for men because the result is non-actionable. What? HIV is also nearly "non-actionable" but knowing one has it definitely reduces the chances of spreading it, does it not?
I don't get it.
I got the vaccine in my thirties against doctor's advice.
Please get the vaccine if you're sexually active with more than one person, regardless of your age.
Just to be clear, it is not the Base Address Register (BAR) itself that gets resized, it is the mapped region of video memory which is pointed to by the BAR.
When I think of the BAR, I think of how the OS uses it. Read the address (32 or 64 bits as the case may be), write the flag so the card is not active, write all 1s to the BAR, read the address which tells you how big the mapped region is (the adress will be 0s for bits that are within the mapped region), write back the original address, and finally re-enable the card.
Resizable bar doesn't change the bar from a 32-bit bar to a 64-bit bar, it just changes the number of bits used in the mapped region.
But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.
As I mentioned in my first reply, the firmware is expected to have complete knowledge of the address mapping of the system, and the OS isn't.
There are lots of ways for the firmware to convey information about the address map to the OS, but it may not always be complete. Mapping two devices to the same address is a recipe for trouble.
That's not to say an OS can't change these things. PCI/PCIe hotplug rely on the OS to set the BAR address for newly connected devices. And that may require rearranging existing device mappings so that things fit. And so, OSes that are capable of hotplug can often do address reallocation for all the devices, but firmware would need to have allocated the devices used to boot the OS already, and you may as well use those if they're there, right?
Laptops that use Coreboot with the SeaBIOS payload to load Linux are being produced today by privacy/security oriented vendors. Most of them have integrated graphics, but BIOS is certainly not dead yet.
Edit: Also Heads [1] secure boot firmware can use Linux in firmware to load the OS and does not need any UEFI services.
Most city police and sheriffs officers have jurisdiction anywhere in their state, AFAIK. They typically stay in their area, but if they’re pursuing a suspect they don’t break off if they cross the city limits.
If the default ETag algorithm for non-encrypted, non-multipart uploads in AWS is a plain MD5 hash, is this subject to failure for object data with MD5 collisions?
I'm thinking of a situation in which an application assumes that different (possibly adversarial) user-provided data will always generate a different ETag.
Sure, but theoretically you could have a system where a distributed log of user generated content is built via this CAS//MD5 primitive. A malicious actor could craft the data such that entries are dropped.
My understanding of the feature, and correct me if I'm wrong, is that you are not granted write access based on a hash. You already have write access. You can use the hash to avoid overwriting someone else's data that was appended to the file in between you checking the file and writing to it. If you already have write access, the hash is irrelevant. As a bad actor, you can corrupt the data without it.
MD5 should not be used for anything security related. Granting write access based on an MD5 hash would be a huge no-no.
Right, the issue comes when a trusted writer is logging data that is sourced from an untrusted party.
Imagine a transaction log being a blob per-customer with many lines corresponding to price, sku, etc, that additionally have some “memo” field provided by the customer. A trusted distributed worker process is responsible for taking incoming requests by the user, pulling their blob down, appending the line based on the request, and CAS’ing it back in (retrying on failure). With enough effort, a particularly devious user could issue many requests with ‘memo’s engineered to not alter the MD5 of their log. This would cause some lines to be lost. An audit of their account transaction log would be unable to accurately reflect the requests they made to the service, and the failure would be invisible.
This is obviously a bit contrived – I’ll be the first to admit. But if the incentives were to exist for this to be worth someone’s time for some system, I think it would be likely to see it come up eventually.
With Google Cloud Storage, you can solve this by conditionally writing based on the "generation number" of the object, which always increases with each new write, so you can know whether the object has been overwritten regardless of its contents. I think Azure also has an equivalent.
Most of the source files have copyright headers indicating that the code is AGPLv3 and forked from existing projects with top-level LICENSE files, https://github.com/falkenber9/falcon and https://github.com/srsran/srsRAN_Project. They should indeed add a top-level LICENSE file to cover the build and other supporting files.
My source of truth is a self-hosted Radicale CardDAV server with git revision control of vCard data in the backend. Clients are anything that speaks CardDAV, including Thunderbird or DAVX on Android. Raw vCard data is only a "git clone" away, and is an input to scripts to handle birthdays and mailing list updates.
This is false, please don't take medical advice from an HN post. CDC guidelines do include quite a bit of discussion of patient age. [1]
1. https://www.cdc.gov/vaccines/vpd/hpv/hcp/recommendations.htm...