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.
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".
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 got a little fish in my first capsule (along something useful that I can't remember, maybe a suit). I kept it the whole game, then passed it on in my own capsule. It's silly, but I still think about that fish.
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.
> 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.
Isn't the purpose of Google's push service that you can receive notifications for a bunch of services with only a single connection?
I don't quite understand how adding a different service helps, although having an alternative when Google's push is unavailable could be useful, and if there's some way to share that alternate service among many apps, that would reduce overhead of having two notification channels where each app with two channels has their own alternate channel?
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.
>I don't quite understand how adding a different service help
I simply don't like having two monopolies (Google and Apple) handling every single push notification for all mobile users everywhere on Earth – except in China, maybe.
There's so much you privacy risks and they can easily infer many things from the meta data alone.
I thought we were in the post-Snowden phase already.
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.
> But what is your email client using for notifications?
Local notifications?
I don't see the problem here with email, it seems to work well that it is great for my use case.
When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications.
At least with E-mail I can see a history of emails that was sent to me.
I just see push notifications as a flawed concept that doesn't make sense for decentralised services.
I don't know what you mean by local notifications, but if you get a notification when a mail arrives, it's most probably because your mail client uses Google or Apple's push service if you use a regular mobile device, or if you installed and configured microG.
And here's your issue: your app that has nothing to do with Google relies on a centralised Google service, and depends on a proprietary library that speaks to some proprietary code running on your device.
Alternatively, your app isn't doing this, but then it risks being unreliable and stop notifying you if the system kills your app because it's been inactive for some time to save battery, or to reclaim memory, and/or it uses more battery than it could.
This post is not about a way to have more notifications: it is an answer to these issues.
> ... but if you get a notification when a mail arrives, it's most probably because your mail client uses Google or Apple's push service if you use a regular mobile device, or if you installed and configured microG.
Except it doesn't?
The Mail app on my iPhone doesn't use push notifications, fetch works well and I still get local notifications. No external push service at all.
> Alternatively, your app isn't doing this, but then it risks being unreliable and stop notifying you if the system kills your app because it's been inactive for some time to save battery, or to reclaim memory, and/or it uses more battery than it could.
You're saying a bunch of "issues" that never actually happened with me or anyone really, there is actually no issues here.
See how I introduced your case later with "Alternatively"? You saw it since you quoted me.
Fine, your email app works well in fetch mode. It took you three roundtrips to mention your actual setup despite having been asked about it quite early and despite it being a critical element in this discussion. Omitting to mention that doing this choice, your notifications are delayed.
Fetch mode is totally a valid choice, email doesn't need to be real time for every one. It will actually save battery life from what I can read: you don't need constant polling. Of course, push notifications are for real time stuff. What costs battery life or requires a push notification service on current widespread mobile devices is timely notifications. I can't help you if you fail to see how this can be useful, even if you don't personally need this or are against the idea.
Despite a thread that started well (yeah, notifications via emails, a decentralized, open standard, why not? It's terrible for many reasons including deliverability and the fact that you need to be notified of new mails so it's a bit of a chicken and egg issue, but sure, let's discuss), you don't seem actually curious or interested in the topic at hand, preferring to stick to your original point of view, to ignore the answers from all of us and to ultimately show contempt and spite to people discussing with you here. By the way, frankly, loose the scare quotes, they are ridiculous. Of course Apple Mail's fetch mode will be reliable on iOS but that doesn't make the topic trivially solved and yes, the problem exists despite what you are stating.
You are calling something over engineered without stopping to wonder why the complexity, assuming it's useless.
I mean, my point with E-mail is to say it already IS a solved problem.
Many services and apps use E-Mail so there is no need to setup additional infrastructure unlike push notifications. That is the complexity.
Send an email notifying me to test@example.com is more intuitive than setting up a push service.
Push notifications suffer from deliverability more frequently (regularly expiring tokens) than E-mail so much so, that when your device is offline and it gets back online, you only get the last notification. This is by design.
Having apps use fetch doesn't mean it's delayed, you can set it to a shorter duration but 5 minutes is the default.
But, it is over engineered as this is complexity that we do not need and would have a higher maintenance and setup than just using E-mail.
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.
Push notifications work with any app. It is nicer to group notifications by app, and have app specific behavior. Emails add an extra step to get to the content in the app.
Gmail does push notifications. Otherwise, have to wait for the client to poll the server.
? 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.
> 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.
I don't think it's the spironolactone part that was concerning, but that the idea of the new gender identity came from someone else and lots of convincing was required.
It reminds me of a friend I have who is quite severely depressed and has gone through a wide range of sexual identities. Straight, to asexual, then gay, then polyamorously bisexual, and now back to monogamously straight. Each change she excitedly explained to me that she had unlocked some deep secret to her identity and now her whole life made sense. This happened well into her adult years, not adolescence.
Some people seem to have a strong sense of a "missing piece" in their lives, and might be susceptible to latching on to almost any identity or community if it can explain that feeling.
EDIT: Because of the current barrage that trans people are under, I should clarify that I know trans people who have a deep and abiding certainty that their gender is different from what it says on their birth certificate; my above comment is not meant to include those people.
So far as the "media barrage" my experience is that I got a lot more negative about the trans movement when I joined Mastodon a few years ago and got exposed to their own words.
My trans friend in college suffered terribly because her mother disowned her. I can say as a parent though, if I saw my child was involved with people who were as hateful and negative as the trans people I see on Mastodon, I'd think "I'd do anything at all to spare my child from that suffering."
---
I think "asexual", as a fashionable label, is particularly harmful. I've met a lot of people who are definitely sexual who went on a phase of glomming on to it and it certainly contributed to their misunderstanding of themselves.
The proliferation of labels about sexuality seems harmful to me (polyamorous is another, BDSM people introduce 10s of them, like you couldn't possible be articulate about your desires but you imagine there is some place where you can pick them off a menu)
My recent experience is that when something squicky goes down or a paraphilia rears its ugly head the people you can trust the least are the ones who talk about sex as if they were liberated or who claim to have some subaltern identity. I think people like this are dangerous not just as direct social connections but even if they are 2, 3 or 4 steps removed.
I don’t assume that I can know anything about another person’s experience of the world. But from the outside, I agree that some communities seem full of deeply aggrieved and unhappy people who seem intent on dragging others into their miserable worldview.
But lots of non-gender-related online communities also look like that to me: some political groups, antiwork, etc.
I see some people, especially young people, treat depression as a kind of virtue. Like “the world is shit and if you aren’t miserable it’s because you just haven’t woken up to reality”. And then they find groups online to reinforce that, and the depression meme spreads. I would want to protect my kids from that too.
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.
Another factor is the media outrage machine. Being a part of a conflict is appealing to some, for the same reasons that some people join the military. I could see this appetite for conflict leading some people to falsely claim to be trans. Whereas they wouldn't if people were more accepting of it, and the media didn't frame every story in a way that showcases outrage.
This person's 'weirdness' is, I think, a neurodivergence which I won't offer a diagnosis of.
I don't think a gender transition will make this person whole, this person will just be a weird person who is also trans. The old problem will persist but now he (maybe she or something else later) will have additional side effects and other baggage not to mention lost opportunities such as not being able to be a father.
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.
> 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.
Why should cosmetic interventions, whether pharmaceutical or surgical, to give an individual the appearance of secondary sex characteristics of the opposite sex, be something the military should have any interest in doing? It doesn't help its mission does it.
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).
Old versions of CMSIS had a weird "only for use with ARM hardware" license header, which also carried through into most BSPs. I don't think this was resolved until around CMSIS 4, so it might just be a matter of front porting since it looks like normal STM32 stuff which is mostly permissively licensed now.
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.
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.