Well it has actually. MLIR (being built by the LLVM team) is basically the next generation of LLVM and one of the MLIR tutorials is literally "write Halide".
So as someone who is by no means an expert you are half right. The compiler doesn't have to guess what parts are parallel and it's very clear which ops are parallelisable but how you parallelise them is the name of the game.
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.
Background checks have always been done on political appointees. They aren't a requirement for getting the position but historically they've been done prior to appointment so that leadership knows if they are a security risk.
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.
Subnautica has a somewhat related concept which is that at the end of the game you have the ability to send a single time capsule to the maps of new players. They contain text, a picture (taken with the in game camera), and a handful of items.
It's a cute little feature that allows you to send something helpful (or just amusing) to the next generation of players.
I think you are thinking about something different. So "Push Notifications" can refer to two different things.
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.
But what is your email client using for notifications?
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.
The purpose of this standard is to replace Google's FCM push notifications so that you can receive push notifications on a mobile device for a bunch of services while only needing to maintain a single low-overhead connection.
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.
? I think I'm misunderstanding your comment. This replaces the entire push notification infrastructure.
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.
It's not that the body's response is problematic. It's that scratching is still problematic even if it does help some. The main issue with scratching is that it injures the surrounding skin including mostly healthy or completely healthy skin. This comes with a host of problems that are well established in plenty of other literature:
- 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.
The goal is not to make yourself whole and even if it didn't work out, they could de-transition (and should be supported in doing so). Stopping HRT (as long as you at least temporarily take HRT in the opposite direction to kickstart things again) has little in the way of long term effects.
> 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.
To be honest I don't think that's really concerning. It's not unusual for people even into their late 20s to experiment and figure themselves out. And sometimes that experimentation is influenced by the people we surround ourselves with.
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.
> He's taking a cocktail of drugs that gets prescribed via telemedicine and was telling us about the serious side effects he was suffering: one of these drugs, spironolactone, is primarily a drug that alters your mineral metabolism but has the effect of suppressing testosterone if you take 20x the normal dose. (My doc gives it to me for my blood pressure.) He has insatiable cravings for salt as a result.
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.
They aren't cosmetic. Hormone replacement therapy has more mental impact than anything else.
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).
> should not have to fund any cosmetic procedures to make an individual appear to be of the opposite sex
Why is this a talking point? Gender affirming surgeries are extremely rare. Very few trans people go through with them. And even when they do, recovery times are in the order of days or weeks which has little to no impact on the efficacy of the fighting force.
The main things trans people want are:
1. That people treat them with basic human dignity and respect.
2. Access to gender affirming medications. It ultimately doesn't really matter who pays for them because they cost nothing. They are quite literally some of the cheapest medications on the market. Estradiol without insurance costs like 10-20USD for a 3 month supply. Testosterone about the same or less. Androgen blockers cost like 1-5USD for a 3 month supply. You could not find cheaper medications and most pharmacies won't even run insurance for them because they are so cheap. The reason the military "needs" to pay for them is because they need to run the medication through their logistics network so that it is accessible where it is needed.
The cost is irrelevant. What matters is that the medication can get delivered to ships and bases in a timely manner. And that is why the military pays for it.
Yeah. And ngl porting up to newer versions of CMSIS isn't too terribly hard. I'm looking at porting up to CMSIS 6 soon and it doesn't look like it'll be that bad either.
Really the main thing that needs to be done is opening up the RCS API on android the same way the SMS API is. Google has been holding on to it to try and pressure people to use their closed source app instead.
The point of Chesterton's fence is that the fence was created for a specific reason and then was removed without addressing that. Replacing that fence with something built for an entirely unrelated purpose isn't replacing that fence. The closest equivalent would be replacing an electric fence with a small stone retaining wall.
They do different things. The electric fence is for keeping animals in/out and the retaining wall is for keeping soil from moving. Sure you may add the retaining wall but you've still removed the electric fence so the foxes can now get into your chicken coops or your cows are running free. That's chesterton's fence. Even if well meaning, making a change that fails to replicate/fulfil the original purpose of the original fence causes the issues to return.
https://mlir.llvm.org/docs/Tutorials/transform/ChH/