How a Windows device's global ID is generated may be new info in the public sphere, but the fact that the global ID exists is not a secret. This format of device ID has been in Windows since the initial release of Windows 10 in 2015, when it was introduced as part of Windows' current telemetry subsystem. To see your device's global ID, open Windows Feedback Hub, then go to Feedback Hub Settings and look under Device Information.
In a sense it doesn't matter how the global ID is used now. The fact that it exists allows it to be used in ways like what you describe, either by a malicious (?) Microsoft itself or by a malicious third-party attacker.
I'm familiar with these global IDs because I routinely used the Windows telemetry system as part of my work on the Windows core at Microsoft. We had strong policies on how and when we could access or use data for a single device as identified by global ID.
But ultimately, these policies will have a "government or court order" exception in reality even if not in theory, just like in most other consumer software observability systems. The Windows difference is simply the breadth of data that is intentionally collected by Microsoft or can be identified by any Microsoft-controlled IDs. That difference is huge in potential impact but very small conceptually.
I always assumed Chrome and Edge already did this — but sent the data to their respective masters.
Isn't every Chrome download unique?
It used to be even though the package contained an Authenticode signature, each installer stub download had a unique hash, because Windows' digital signatures allow a non-executable data area in the trailer which is not computed as part of the signed data.
There is zero technical reason to do this (generating unique binaries) aside from tracking purposes.
There are, unfortunately, a lot of abuses people will tolerate in the name of convenience, especially if those abuses aren't readily apparent and affecting them directly at the time they learn about them.
The alternative is not running any proprietary tech. This would require people to give up a lot of convenience, build their own tech stack, make tools where none exist, etc. Doable for most on this forum I'd suspect, not really feasible for the population at large so the choice is even worse for them: be spied on, or abstain from using technology all together.
Its a captive audience, and why advocating for privacy is such a difficult, losing battle. People aren't going to stop using Windows because of this, so Microsoft has no incentive to do anything differently. Same goes for Meta, Google, Apple, etc.
Even for myself, I've gotten really lazy over the years and have traded quite a bit of my computing freedoms for the Apple device ecosystem's convenience factors. And that's the trap. When even the people who understand exactly what they're giving up still choose the golden handcuffs, the market has no incentive to change.
A typical phone operator records the data your phone sends to them on their servers. They're just lucky enough to have the absolutely unique ID of your phone number. Don't confuse this with something else. Microsoft and Google don't have the authority to create an ID for your computer unless they allow me to use that ID to make calls to your computer.
> This is almost entirely an artifact of the financial instruments used to pay for these buildings, regardless of any Seattle policy changes.
Why would this be different in Seattle than in other cities? Many downtown office towers are bought or built using a lot of debt throughout the U.S. What do you think makes Seattle special?
> We just saw another building turn over, US Bank Center. The new owner bought it at a price where they'll be able to lease it competitively, and it won't sit empty. We'll see that continue to happen.
The news story mentions the U.S. Bank Center example. What it says that you're leaving out is just HOW big that discount is:
> The new owner of the U.S. Bank Center, having paid just $280 million, or less than half of what the building went for in 2019, presumably can afford to lower rents enough to fill the place, which is now 45% vacant, according to CoStar.
A discount of more than 50% is a bubble bursting. It's great that the new owner can offer fire-sale rent, but where does that leave the old owner, if they were truly as leveraged as you suggest they were likely to be?
> The Seattle Times has always been a conservative rag, and their editorial board hates the new mayor, so they hit the "Seattle is dying" story as often as possible. They've got a long history of this whenever there's leadership they don't like, ask me about it!
OK, I'll ask you about it. This "Seattle Times = Blethen family propaganda" line has been tiring for the 25 years I've been hearing it. What exactly are they not covering about Seattle's downtown today that you think they should be? Why do you think that their opinion staff influence the news coverage so much? In short, if the Seattle Times has a conservative bias in its news coverage, why does the Wall Street Journal famously have a liberal-biased newsroom?
Why is Seattle impacted worse? Because so much of our office space was tech companies that decided they didn't need as much office space and can do their work remotely.
Look up the old owner and you'll realize why it doesn't really matter that they're taking a massive loss, and why I don't really care. I left it out because it's already a long comment and that's not really relevant.
They could have written an article about how foreclosures on office buildings take a long time and that sublet offerings in Seattle are turning over at a healthy rate. And the owner of a company in media absolutely influences that coverage, why do you think everybody's worried about CBS, or for a long time Fox News?
Think it's significant that Zillow's one of the few significant tech companies to maintain full remote working? They don't leave an Amazon-sized hole in downtown, but they had quite a few floors.
They kept at least the main floor in Russell Investment Center. I don’t know if they have all ten+ floors any more. They were trying to sublease around 100K square feet right after the pandemic but I haven’t seen any news since then.
One way I find traditional Lisp style more painful for functional code than Ruby is that fully functional-style Lisp pushes me to read and write code the opposite way from how I think about it. In the author's example:
the equivalent Lisp code would either be written in imperative style as multiple statements that each write to a temporary variable or (let) binding, or would look like this:
(reduce #'+
(map (lambda (o) (getf o 'total))
; this group_by replacement function
; might be written as hash-table code
(my-group-by 'customer-id
(remove-if-not
(lambda (o)
(>
(getf o 'placed-at)
(- (my-now) (* 60 60 24 7))))
orders))))
where I now have to read from bottom to top to understand the order of operations on the `orders` record set, even though when I wrote the code earlier, I "logically" thought from first operation to last when deciding which high-level operations to use in which order.
Other imperative languages that support functional code either make you do things imperatively to get the "logical" ordering of functional operations like I feel Lisp pushes you to do, or they do something like Ruby where things can be chained left to right in a "single" statement even for operations that were not thought of ahead of time by the creators of opaque data structures you later need to operate on. (Everything is a user-extensible object like Ruby, unified function call syntax in D, extension methods in C#, or pipelines of structured objects in PowerShell.)
But I prefer the typical Lisp code where I get the sums of the totals of the orders with the same customer ID which were placed in the past week, instead of the orders made the past week grouped by customer ID their totals summed together.
In contrast to, say, Java (I can't speak to the code above):
List<Things> things = thingIds.stream()
.map(model::findThing)
.filter(Objects::nonNull)
.toList();
These are streamed. This is pretty much a pipe structure, whereas the threading macros will create a lot of temporary copies of the data (I don't know if that's a universal truth). That is, if you're processing a 1000 items, say `gather` returns a 1000 items, that 1000 item list is passed to `uppercase-list` which return a new 1000 item list to feed to `sort` which returns another 1000 item list (assuming none of these are destructive).
I wish CL had something like the Java streams (maybe it does).
The version with a threading macro, will create a lazy-sequence for each step in the pipeline. It will not instantiate the entire list, so it's O(1) memory overhead in terms of peak memory, but it churns O(N) extra garbage.
(->> things
(map model/find-thing)
(filter some?))
And the version with transducers, which will not create any intermediate sequences:
It's common to write the thrush combinator as a lisp macro. Clojure ships ->, ->>, as->, some->, some->>, cond->, and cond->> out of the box. You can find similar macros for CL[0], Racket[1], and a scheme SRFI[2]. Writing them is a fun exercise in your lisp of choice if you don't have a library available.
Using a threading operator where there is no such consistency is painful. This is why I dislike CL’s or Python’s map function, taking the list to operate on as second argument, instead of first. A threading operator wouldn’t be as effective there.
The issue is that these functions in Lisps are variadic and can accept more arguments than one. `map`, and `zipwidth` in lisps are actually the same function.
My use of `git add` - and the explicit staging area more generally - is mostly a workaround for the fact that the repos I work with have checked-in dev setup scripts, IntelliJ/Visual Studio/Xcode/VS Code configurations, and so on.
My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it easy to not do that MOST of the time. The rest of the time, it's a `git stash` dance, which I sometimes screw up and lose the customizations.
I've tried to manage the configurations a different way, such as by having a private branch with my own settings checked in, but that doesn't usually work out. I'm aware that the REAL problem is that my coworkers have checked in those settings to begin with, but I would counter-argue that the REAL REAL problem is that those tools don't have a good way to combine "settings that I override or that only I care about" and "settings that have project-wide defaults but are safe for me to override." (Visual Studio gets it close to right with its .xyzproj and .xyzproj.user files, but VS Code's single .vscode/ folder breaks down in shared repos.)
If you feel like fucking around with new source control tools, jj (jujutsu)'s megamerge workflow is really good at this.
(If you're not interested, feel free to skip the rest of this).
I have each in process workstream in a commit that is merged at the top level, then I have a new wip commit off of that where stuff I'm typing right now sits.
It's easy to split/squash/absorb parts of that commit into the right destination, but also to introduce parents of the megamerge that will never get merged.
> Meteorologists and climatologists from the NDMC, NOAA and USDA take turns as the lead author of the map, usually two weeks a time. The author’s job is to do something that a computer can’t. When the data is pointing in different directions, they make sense out of it.
> How do we know when we're in a drought?
> No single piece of evidence tells the full story, and neither do strictly physical indicators. That’s why the USDM isn’t a statistical model
> The essential message is that weather and climate data do not support the claims of extreme or severe drought in eastern Washington this year.
> There is no expectation of water problems over or near the Columbia Basin. The Drought Monitor graphics, which are created subjectively, are sufficiently problematic and deficient that they should not be considered or applied to any serious decision making.
cliff is an expert but also famously sort of a "climate contrarian" and his takes are regularly cited by climate skeptics and conservative irritants here in the PNW. just noting his takes don't exist in a vacuum.
Contrarian experts are really important imo, and I don't think their efforts should be devalued just because nuts might be attracted to them. As long as they're properly engaging in the scientific method I reckon that they're perfectly fine to quote.
So? You’re trying to engage in tu quoque without saying it explicitly. If you think the argument is wrong, make a counter-argument. Don’t just say that the arguer hangs out with people you don’t like.
Cliff in an expert, he worked in the Obama administration on climate, and unsurprisingly, he is being cited for having opinions the support the thesis of the article.
ah.. a fallacy guy. there should be a named fallacy for mischaracterizing remarks so they fit the form of a fallacy, in order to clothe one's argument in an illusory erudition.
anyway if anything it would probably be poisoning the well. really though it's just pointing out that cliff isn't a garden variety climate scientist and comes with something like a warning label.
FWIW you can go back and look at historical data rather than rely on a snapshot of 2022 written in April.
Basically it’s complicated. Some areas did experience extreme droughts that year and others faired well.
BPA was able to lever up their reserves early due to those same forecasts which allowed them excess supply to sell when other utilities experienced extreme heat (drought) and couldn’t produce enough.
> Notably, Bonneville was able to offer much needed support to other Pacific
Northwest and California utilities during late-summer heatwaves and
scarcity events. Our hydropower operations planners and traders positioned
the power system to maximize supply, enabling us to deliver significant
amounts of power across the West to help keep the lights on during a
string of energy emergencies.
I like the map. It's usually on track but sometimes it's quite a bit off. I've seen it say drought when it's been wet --maybe just not as wet as usual. It also doesn't indicate when above average and I do not think it averages precip out when a wet week was extremely wet and the next one dry. It'll say it was dry last week. In other words you could have cumulative average precip but it's only counting last week's precipitation.
> [Authors] bring together the physical climate, weather and hydrology data and reconcile that with local expert feedback, impact reports and conditions observations. The author is also responsible for weighing different indicators based on what’s most appropriate for a particular place and time of year. In the West, for example, winter snowpack has a stronger bearing on water supplies than in the East
It is, and the subjective assessment component is a black box. That said, the USDM has many other components that are objective, so it's far from being a subjective measure -- I would argue that the Fed Funds rate, for instance, is determined far more subjectively.
Also, there just isn't a more objective measure of drought out there, let alone a fully objective measure.
Also also, it's unclear to me that this black box is being gamed any harder than most other black boxes in our system. If you want to game agriculture, you game the farm bill.
i think calling it "subjective opinion" is kind of disingenuous. it is a subject matter expert interpreting the data. there is a vast gulf between that and someone else simply offering their opinion on the matter.
I worked in weather for TV as a technician and I was lucky enough to work with meteorologists. I thought they were high priests in the church of science, however, I detected a gambling mentality going on.
I was just surprised at how subjective their work was, with differing opinions regarding the big picture depending on whom you asked and what their background was, as in university, whether they had worked for the navy or whether they had worked for the government.
The big surprise of the gambling mentality reminded me of people that dedicate their lives to losing as much money as possible betting on horses. These people know the form, the weather and so much, yet they do their own bets.
It was kind of the same when working out what the weather would be in Springfield tomorrow. Would it just be cloudy or actual rain? That would be a 'bet'.
The next day the observations would come in and the meteorologists would either win or lose their 'bet'. The guy who has been to Springfield and knows the local geography well would have his own reasons for his 'bet', whereas the guy who was more interested in long term storm development would have another rationale for his 'bet'.
Then there would be 'wrong all the time me', able to look at the low level cloud from contrails (which are really huge in some wavelengths on the satellite pictures) to assume rain every day.
Hence climate and weather is highly subjective even if it is highly educated and vastly experienced professionals that are interpreting the data.
There is also the additional issue of computer models constantly chasing global changes. About 10-15 years back I used to talk with folks that worked on weather modeling and they were in a state of frustration in that as soon as they could make models that could work on older data sets to do reasonable predictions, the global weather patterns had change just subtly enough that it made them just kind of average on forward predictions.
This was right before GPU compute started to become a big thing, I do wonder if they now use machine learning models on these to speed up model iteration? I would hope so, but even then there is the human factor as you said. Eventually someone has to make the call on what the data shows and how to present it to the world.
Indeed, even ones from companies as big as Microsoft!
There is a story in Writing Solid Code by Steve Maguire [1] where Apple asked Microsoft to fix hacks in its Mac apps that didn't conform to the developer docs in Inside Macintosh because such workarounds were required when the apps were first developed alongside the original Macintoshes. However, Microsoft's workarounds would be broken by a major System Software update under development at Apple, which naturally wanted to avoid having to permanently add back the implementation bugs and quirks that the workarounds either relied on or were meant to avoid.
As Maguire told it, removing one such workaround in Microsoft Excel was hotly debated by the Excel team because it was in a hot-path 68k assembly function and rewriting the code to remove it would add 12 CPU cycles to the function runtime. The debate was eventually resolved by one developer who ran Excel's "3-hour torture test" and counted how many times the function in question was called. The total: about 76,000 times, so 12 more cycles each time would be about 910,000 cycles total... which on the Macintosh 128k's ~7 MHz 68000 CPU would be about 0.15 seconds added to a 3-hour test run. With the slowdown from removing the workaround thus proven to be utterly trivial, it was indeed removed.
(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy)
I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.
Now let me completely undermine my apology by nitpicking your comment :)
> It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off.
At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.
Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.
So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.
> What actually happened [re Windows RT, but I think the point applies to UWP in general] was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.
The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!
And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.
Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)
Thing is, Silverlight and Windows Phone 7 were already two steps that made developers go WTF. There was WPF, hot off the press and obviously very promising (but also obviously requiring a lot of polish; I don't think it was truly ready until .NET 4). And then instead of actually, you know, polishing that, like we did with WinForms, there was suddenly that new Silverlight thing, which was obviously very similar but not quite. That was when third party devs first started balking, but it really went into high gear when Windows Phone 7 guys said that their XAML will be yet another different thing. By the time we got to Win8, the developers for the platform were already allergic to all this nonsense. So I don't think it would have helped much to support WP7 apps (although it certainly wouldn't have hurt!).
> And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever.
It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.
Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.
I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).
> It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.
fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.
Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.
> If anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.
Win7 Metro also had ALL CAPS in a few places, which is where I believe this was copied from since it was used there on the top of the screen, so where the menu bar is in a desktop app. The MSDN blog post that announced it also specifically cited Zune: https://devblogs.microsoft.com/visualstudio/a-design-with-al.... That said I have no idea why they actually did this, only that it was not a popular decision among devs working on VS at the time - so much so that they snuck in that registry key that'd let you disable it (I bet the management really appreciated that when they had to back out after overwhelmingly negative feedback). The monochrome icons were also unpopular on the team, but there was little they could do about that one.
> I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.
I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.
In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.
That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.
It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.
> In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012".
You might note that I had to forcibly reiterate that, no, Win8 apps don't have to be written in HTML/JS, because people genuinely got that impression from what they saw at BUILD back then. It's not that the "COM 2.0" and the "this also works on .NET" parts were completely missing, but they (.NET especially!) were de-emphasized to the point where it genuinely created confusion and alarm among the developers. And, ss far as I can tell, this was entirely Sinofsky's idea, and one that he still refuses to admit was an epic failure.
Microsoft has always had a broad vision of itself as a technology company; I feel it's perfectly fine to not be able to describe Microsoft in one sentence without using platitudes like "empower every person on Earth to achieve more" or "put a computer in every home and every office" (both paraphrases of actual MSFT company mission statements), and I suspect many other current and former Microsoft employees would feel the same way.
IMO Microsoft's best long-lived products have always been both finished solutions to your problems and platforms to help you develop more solutions, and Microsoft leadership has always recognized this. Examples: Windows. Office. Dynamics (their Salesforce competitor).
But even if a product doesn't meet that "why not both?" ideal, there is always going to be room for it at Microsoft, as long as it is not only a good or at least mediocre product by itself, but also works to sell you on the whole Microsoft ecosystem. Sometimes that is a bad thing (see all the Windows adware for Bing, Copilot, and M365). But that at least is where Microsoft remains consistent.
That was such an amazing mission statement. It was a real measurable goal, and progress towards it was quantifiable. And Microsoft actually did it! That mission statement drove actual strategies (lower costs, don't complete with Apple on the high end, force OEMs to compete against each other on price, etc) that resulted in its ultimate fulfillment.
Both this blog post and the Steven Sinofsky response really set my blood boiling, because they both reek of retired-executive score settling, a kind of blame game that gets played out decades after the fact between ex-high-ranking people in hopes that whoever writes last is able to cement the conventional wisdom.
People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.
The most offensive part of the Sinofsky response is this part:
> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past
I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.
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.
Unfortunately the only valid response is "Don't be so sure." There have been too many exposés about the poor data privacy practices of virtually every automaker including Honda. [1]
