I've started to question if GMail's spam folder is marketing more than substance. I've used the same primary email address for nearly the same number of decades. The time I saw the "most" spam in a spam folder was only while it was hosted on Google Workspace. Actually trying to skim through those "1000s per day" a lot of them seemed suspect in strange ways (why was this even delivered anywhere?) and some of them even seemed like Google just dumping random ad copy from legitimate search ads into the folder.
(Also it says a lot that right now my two biggest sources of daily spam are Google Calendar Notifications and Random Firebase Accounts. Both of those further leave me questioning if Google's approach to spam filtering is sincere.)
I’ve had the same gmail address since it was first announced. It also gets email forwarded to it from another ancient email address that I used to self-host and that still gets occasional real mails. Most of the spam is addressed to that other address.
Just took a peek at my spam folder: 207 messages going back to March 18th, two false positives (both from mailing lists), but nothing critical. I think maybe I’ve seen one spam message across all my accounts in my inbox. Their filters benefit from a huge set of trainers on their data.
(As an aside, I would note that some newer addresses that I publish naked on some websites that I maintain get very little spam (14 messages between the two accounts in the same timeframe, most of which are from a single sender who decided that they should send me their press releases without any means of opting out.)
RCS is incredibly centralized. More than half of the phone carriers decided it was too complicated to run their own RCS servers and so just sub-contract them to a Google subsidiary (Jibe).
I think for Sinofsky the "respecting the past" refers more to WinRT was/is still just Spicy COM under the hood. Most of the article as I read it is about how .NET was a mistake for Windows UI development and a return to (Spicy) COM its savior.
That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.
Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).
"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.
But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.
One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.
The GAC and certain CAS configurations would require paid certificates, too. Certainly the requirement of paid certificates can be seen as a part of how both of those eventually fell out of favor. That is another of the things I felt UWP missed learning from .NET. Developers do generally dislike code signing certificates and try to avoid them.
Also to be fair, UWP had a rather streamlined certificate system if you targeted only the Store and let the Store manage your certificate chain. It was even a little bit easier to use than Apple's similar App Store management of XCode certificates. Not that that was a high bar to clear.
> It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP
There was some progress. Office involves a lot of teams working at different paces and sometimes extremely different codebases. OneNote was fully UWP for a while and was at one point considered a flagship and testbed for UWP "Fluent Design" (both before and after the shift from touch-first to the over-correction to "it's just a desktop framework that sometimes is touch friendly"). Several new Office apps were written UWP first, including the "Office Hub" app that became called just "Office" and now is even more confusing called "Microsoft Copilot 365 app". "Outlook (New)" has always been React Native, but as a React Native project, it ran entirely in UWP, too, for a while. It was said to have been one of the drivers for deep UWP support in React native at the time. There were also the React Native-based Word, Excel, and PowerPoint "mini" versions that ran entirely in UWP. Those are said to have influenced more of the real codebases pushing towards React Native, but did not try to replace the original codebases in the same way that "Outlook (New)" today is overtaking "Outlook (Classic)".
There were a lot of strategy problems with UWP, but adoption was further along in some areas than it looked.
There are still some things that are still locked in the UWP world that I wish were not.
For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.
This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]
I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.
Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.
That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.
UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.
They did pull that rug, twice, in two different directions.
1) VB7 (VB.NET) entirely split the VB developer community.
2) VB6 IDE has not worked well and is entirely unsupported in every Windows after XP. It's generally recommend to build VB6 apps in an XP VM and XP being out of security support it's now a huge "Use at your own risk" and "Do your best to isolate the VM from ever having an internet connection". (Not to mention that installers like Install Shield that still understand VB6' super messy version of COM are generally also out of support and security support.)
It was alleged that Microsoft almost dropped the runtime components for VB6 in Windows 11. It starts to feel like only a matter of time before they do.
"Backrooms" don't just come from videogames. They are meant to represent liminal spaces like "endless" cubical farms and conference rooms and the back offices of movie studios or any other modern business. (Even the idea that on the backside of the cool theme park structure that seems so otherworldly is just a couple of boring janitor's closets and hallways for staff/crew to navigate between shifts.) The videogames building "unused" rooms like this were in part trying for verisimilitude to these sort of "just around the corner" spaces that exist in so many buildings. Often as a joke. It was a part of the humor of Duke Nukem. It was a key part to the humor of Portal. It was the entire basis of The Stanley Parable.
I think we can argue that real world places that inspired our fantasy Dungeons were similar liminal spaces: the creepy basement hallways that connected staff/crew (servants) access to other parts of the building(s) above. The multi-use spaces below that are most remembered in pop culture for such uses as torture and imprisonment, but were also often staging grounds for much more boring household logistics tasks (storage), and even equivalents to conference rooms, janitor closets, and "offices".
The concept did not originate in videogames. The whole thing started from a 4chan post where someone posted a photo of a yellow interior. Then, in 2022, Kane Parsons created a viral YouTube video based on that post. You can see it here: https://youtube.com/watch?v=H4dGpz6cnHo . The video game adaptations all came later.
Yes it did. "noclipping out of reality" is a metaphor that is nonsense outside the context of videogame worlds. The 4chan copypasta that popularized the Backrooms meme doesn't mention video games but that particular post is not the origin of the backrooms concept.
There are literal backrooms you can noclip into existing in games that that predate that 4chan post by several years
I've had dreams like this - I think a lot of people have - where you find yourself trapped in a space, an office or a mall or wherever, one common version seems to be a public bathroom - and you keep moving through an endless maze of doors that lead nowhere.
The article has it wrong, this was a archetype of the human collective unconscious well before 4chan turned it into a meme.
Which article is wrongm Both the article and Wikipedia entry focus on The Backrooms which are a type of liminal space. Yes, liminal spaces have existed in fiction, dreams, etc. However, here the discussion is on The Backrooms and how that idea and aesthetic became very popular very quickly.
You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.
If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].
All of them are optional and can be disable at the instance-wide level, in addition to some of them having account level opt outs.
They also are still generally bound to an instance's own horizon: there's no global "trending feed" (and it would be really hard to create one), these optional "algorithmic" tools still differ from instance to instance based on what that instance follows and its trading relationship to its neighbors.
> Some of the most toxic conversations I've seen were on Mastodon.
> If there's a healthy future for socializing on the internet, I think it will happen in small communities.
I think that is why I still trust Mastodon/ActivityPub a lot more than Bluesky/ATProto. Mastodon at least provides the tools for small communities. Big instances still exist. Pile ons and drive-bys are still possible. But also Mastodon has plenty of small instances including many one-person instances. Even out of the box small instances are smaller overall traffic among the great river of ActivityPub. But also forks like Hometown exist for adding extra, simple "picket fences" around small communities. A "complete" view of ActivityPub is intentionally hard to get. By comparison, ATProto seems to me overfocused on the Relay system as a grand centralizing data bus and missing pieces of a conversation seen as much more of a bug rather than a feature (of ActivityPub).
I also think the future is healthier in the hands of smaller communities. I can teach someone how to effectively use Mastodon for small communities across an almost nice spectrum of "insular" with useful options on both sides from strangers tolerated to strangers mostly unwelcome (though that starts to lead away from Mastodon and back towards classic forum software). I don't see how to do anything like that with Bluesky and a lot of the design decisions of ATProto seem intentionally to try to avoid small communities.
Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.)
There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
(Also it says a lot that right now my two biggest sources of daily spam are Google Calendar Notifications and Random Firebase Accounts. Both of those further leave me questioning if Google's approach to spam filtering is sincere.)
reply