CuriousCosmic
Joined 10 years ago
Joined 10 years ago
So for example if you do a pattern of "do a small op to each part of a large block of data and then do another small op to each part of that block of data, etc" then at least in CPU SIMD (ex AVX) you end up memory bottlenecked.
However if you can do a bunch of ops on the same small blocks of data before moving on to the next blocks of data in your overall large block of data then said small blocks can fit inside the L1 cache (or in the registers directly) and that can run the CPU to it's absolute limit.
Hence it becomes a game of scheduling. You already know what you need to optimise but actually doing so gets really hard really fast. Albeit things like MLIR (which are still very new) are making this easy to approach.
And for appointees that require congressional confirmation the checks have been giving to congress prior to hearings for the same reason.
They weren't required but they very much have been done for political appointees in every admin in recent history except this one.
It's a cute little feature that allows you to send something helpful (or just amusing) to the next generation of players.
The user oriented term refers to on-device notifications that pop up at the top of the screen. Those are technically just normal notifications but people like to call them push notifications for various reasons.
Push notifications in the technical sense however refer to a system for remote services to notify a client that something happened rather than the client manually polling the server for new updates. It's the difference between the client asking "do you have anything new" and the server telling the client "hey pay attention you have something new". This is what we are talking about when we say push notifications.
Email clients that automatically get new emails in the background all either do so using fetch polling or push notifications. The traditional method is fetch polling at a regular interval but nowadays most email clients support push notifications. We are discussing a tool that these clients can use behind the scenes to provide these push notifications for the email client in a battery and data efficient manner.
The benefit of this service is mainly for people who can't or don't want to use google's push service. Namely for users of de-googled devices and for users of android devices that google blocks from using play services (ex: users of Huawei devices).
But also it's worth noting that unified push provides an optional google FCM fallback so that apps can use google's push services (provided they are available on the device) when a unifiedpush distributor isn't available or configured. So in this sense it means supporting a single push notification standard instead of multiple and the underlying system can switch between which provider to use.
And of course for users of completely self hosted services this means you get all the benefits of a proper push aggregator like google's FCM without having to configure firebase with your services. This is particularly appealing if you self host locally and don't already use cloud services.
If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem.
If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection.
And this protocol (along with the proprietary push notif aggregation services it is aiming to replace) exists to deduplicate those many long-running connections into a single connection out to some hardwired server that manages the many services/connections for it.
This exists to improve battery life and decrease data usage for android users who don't use google services or prefer to host their own. And generally it exists to provide a standardised, independent, privacy preserving option for users and app developers.
Neither RSS nor email solve this problem and actually this specific service would be the exact type of service you'd use to notify the user's device that the apps that use RSS or email have new content to fetch.
The "distributor" receives notifications onto the device and sends them to the apps via a standardized API.
The apps themselves then post the notifications to the user via the android on-device notification API.
The "gateway" receives the notifications from the services over a standardized API and sends them to the distributor.
How the gateways actually distribute the notifications is actually completely up to the gateways. The main gateway (ntfy) uses websocket, another (nextpush) piggybacks off of nextcloud, and the new kid on the block (sunup) uses the Mozilla Push Service behind the scenes.
Nothing in this is restricted or locked in to a centralised platform.
- Contaminating the site
- Spreading whatever is causing the initial wound
- Weakening the skin barrier and allowing whatever contaminant/infection to penetrate deeper/spread below the skin.
TLDR: They show a potential benefit of scratching (which may explain why it evolved in the first place) but suggest it doesn't outweigh all of the established harms.
> not to mention lost opportunities such as not being able to be a father.
This isn't true. Even if you stay trans the entire rest of your life you can still often have kids. This goes for trans women, trans men, and nonbinary people. Generally at worst you'd just need to supplement with some hormones to support fertility but often even that isn't necessary.
But supposing someone de-transitioned, fertility generally returns completely or near completely within 6 months to a year.
The only case where you can't "undo" any degree of loss of fertility is with an orchiectomy (testicle removal) but even then the standard procedure is to preserve sufficient semen in cold storage for future use.
People have done this all the way back time eternal, the only thing that's different today is that people are allowed to be more open about it and that there are many discrete labels that allow people to easily describe what they are specifically feeling.
It's worth noting that while Spironolactone can be used to suppress testosterone, that's not really what it's used for. Rather it weakly blocks androgen receptors so it makes the body act like the testosterone isn't there or is lower than it actually is. And this is effective at a far lower dose than the testosterone "suppression".
This is why it's sometimes prescribed to women for hair loss, improper hair growth, and/or acne.
It's for that purpose that it's normally prescribed in trans healthcare and it's generally only temporarily (~3-9 months) prescribed while an estradiol regimen suppresses testosterone production. After that it can be dropped with the estradiol doing the rest of the work.
And outside the US it's far less commonly prescribed for this purpose with other androgen antagonists generally being preferred but US doctors tend to be more weary of those other medications and therefore prefer spironolactone.
So while said kid may be a bit "weird" in your eyes, nothing about this really seems unusual. At worst they probably just need to ask their doctor to prescribe a different androgen antagonist instead of spironolactone.
And the reason they should have interest in doing it is because the overwhelming majority of trans people in the military are people who were diagnosed with gender dysphoria while in the military. The military treats that gender dysphoria so that they can continue to be effective members of the fighting force.
These are people who are already in the military and want to continue to be in the military and do their jobs effectively. A few pills a day or an injection every few days or weeks is generally effective at treating gender dysphoria with accommodations such as social transition further treating it while doing nothing to diminish the efficacy of the fighting force.
Not treating or accommodating them means they either leave the military (which is a problem because the military has a critical shortage of senior personnel due to horrific retention issues) or they perform their duties in a diminished capacity. There's no reason to harm the fighting force's efficacy and/or retention over a treatment that has essentially zero cost and no impact on operational readiness (compared to all the other long term treatments they allow which do impact operational readiness).
https://mlir.llvm.org/docs/Tutorials/transform/ChH/