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.
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.
> 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?
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.)
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.)
> 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.
> 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
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.
> 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.)
> 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.
> 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.
> 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.
(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 :)
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.
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.
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.
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]
I too thought VSCode's being web based would make it much slower than Sublime. So I was surprised when I found on my 2019 and 2024 ~$2,500-3,000 MacBook Pros that Sublime would continually freeze up or crash while viewing the same 250 MB - 1 GB plain text log files that VSCode would open just fine and run reliably on.
At most, VS Code might say that it has disabled lexing, syntax coloring, etc. due to the file size. But I don't care about that for log files...
It still might be true that Visual Studio Code uses more memory for the same file than Sublime Text would. But for me, it's more important that the editor runs at all.