I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
1. The overall architecture (with the JVM) made it slower than the equivalent C# code.
2. C# really started embracing modern language features at a time when Java was kind of languishing (lambda functions, async patterns). Java seems like it's been in perpetual catch-up since then.
(Not OP, disclaimer, I work for Microsoft and this is only my opinion).
> I haven't kept aware of changes to Java in the last decade, but the things I didn't like about it then were:
It's almost a shame. I am genuinely impressed with the gains the team has made in both, language aspects as well as JVM technology. They have some brilliant people working on it and I love to hear their talks (Brian Goetz and Mark Reinhold, mostly).
But I suppose I would say the same about .Net, it's just that you guys have much less public exposure of your internal reasoning.
I've seen the gains in Java; the main things that would close the gap are not yet there in Java. .NET code, especially when tuned, still has significantly more knobs in your code to tune and make faster. An example would be proper generics with value types together means less boxing in generic code in general overall but there's a lot more I can think of. I've seen almost 50% of gains, particuarly when doing math like code, of moving away from Java to .NET especially if the jump to C/C++/Rust is too much for the team in question due to other requirements.
> What do you want for the USA? Completely open borders? Closed borders, but we don't enforce it very well? Something else?
The 2024 bipartisan border bill (https://en.wikipedia.org/wiki/Mexico%E2%80%93United_States_b...) seemed like a good compromise to me. Of course, it wasn't brought to a vote by the house (for reasons that I won't elaborate on), so it's mostly a hypothetical.
And, if I had to choose between the two, I'm more supportive of the Biden era immigration policy than I am of the current Trump policy.
If an executable isn't code-signed, Windows SmartScreen displays a big scary "This file may harm your computer" warning box, requiring multiple clicks to get past. Been like that for years.
Code-signing certs used to be very expensive and annoying to obtain. The situation has improved a lot since the launch of Azure Trusted Signing, and now it's roughly on par with the cost and annoyance level of code-signing for Mac binaries.
Big scary box might as well be outright disallowing, since someone who isn't 100% sure about your software will likely be dissuaded by the warning. But if they want to install it, then they can.
My understanding of the article is that there is nothing that a user will be able to do to install your software.
> “developers [that we approve] will have the same freedom to distribute their apps directly to users through [installation] or to use any app store they prefer.”
> Why doesn't the README file explain what this repository is doing?
It explains exactly what it's doing.
"Microsoft Store package for Windows LTSC."
It provides a Microsoft Store package for LTSC builds, and an install script that allows it to actually work. Windows LTSC builds don't have Microsoft Store preinstalled, and Microsoft offers no official way to re-enable it.
> Windows LTSC builds don't have Microsoft Store preinstalled
No, it's not that it isn't "preinstalled", the Microsoft Store is literally not supported on LTSC, by design. LTSC was never intended to run the Store. The original use case for LTSC was for ATMs, industrial control equipment, hospitals, and the like, where IoT wasn't appropriate, where you needed the ability to run full desktop applications.
> Microsoft offers no official way to re-enable it.
Yeah that's because the Store was never supposed to run on LTSC. It's not supported. Why would they offer an official way to re-enable it? The whole point of LTSC is that it doesn't include the store.
If someone cobbled together an ugly hack to shoehorn it in, by definition it could break at any time.
If by "customer" you mean "way of making money", I agree, since I didn’t pay for it. OTOH, I have been running LTSC on my desktop for years because it's the best edition of Windows, and I haven't had any issues with the Store, which I had to install manually, thus far.
To be fair, the headline could have been better worded. The convention for something like this is
“Show HN: Title of Repo”
I could understand how one might not understand what the aim of this post was. Maybe the ensuing conversation could have been handled better, but I would certainly include the parent comment in that indictment.
The store is also an app on windows and is sometimes an hard dependency to install apps that only exist on the windows store without having to jump through many hoops. It's usually part of windows itself in the regular retail builds of windows, but LTSC which is meant for enterprise and embedded system does not include it. Installing it is not straightforward which is what this repo provides.
There's no source code, it's a just a bunch of binaries and an install/uninstall script.
Edit: I should clarify that the link provided in the repo is not the microsoft store that the apps refer to. This would be a better link https://apps.microsoft.com
I don't think there's anything nefarious going on here but to someone just quickly looking over the page it has the impression of being an official Microsoft project, given the gratuitous use of their trademark and zero mention of it being a "community" effort.
> The lack of support on LTSC is the least baffling thing going on here but I'm open to the possibility that I'm misunderstanding something....
And yea, you're right, but Indeed, many people need to use the store on LTSC, especially after Microsoft migrated many ecosystem attempts to the store, for example Microsoft Photos and some extensions like HEIC, and now not only UWP applications can enter the store; regular applications can also do so. It actually poses a very big problem that we cannot use the store anymore, at least that's what I think.
Furthermore, it is not just LTSC 2019 that cannot be used; this means that older versions of Windows (at least 1809 or older) are also no longer able to use it. In other words, we can no longer use the store on older versions of Windows. You might say that Microsoft itself didn't intend to provide support for older versions, and yea, I agree, that's true. However, the fact is that many people use Windows largely because of its compatibility advantages. I believe everyone should at least be aware that Microsoft is not as compatible with older programs, especially its own, which is what I want to express.
As for the license, I would like to clarify that it is only to prevent the packaging scripts from being used for commercial purposes and promotion. As you can see, this repository is not specifically intended for hosting store programs, so it does NOT apply to the store programs themselves, but only to the deployment scripts :)
I agreed with a lot in the article, but I was a bit baffled by the DEI name-drop in the opening.
> "... the guys who had big tech startup successes in the 90s and early aughts think that 'DEI' is the cause of all their problems."
Who is the author referring to here?
(I realize that DEI has been rolled back at some companies, and Zuckerberg in particular has derided it, yet I still feel like the author is referring to some commonly accepted knowledge that I'm out of the loop on.)
certainly Andreessen has gone on many public rants about how he thinks dei and other "woke" initiatives are killing american tech innovation. Here's one interview - https://www.nytimes.com/2025/01/17/opinion/marc-andreessen-t... About halfway through he really lets it fly
Suppose user U has read access to Subscription S, but doesn't have access to keyvault K.
If user U can gain access to keyvault K via this exploit, it is scary.
[Vendors/Contingent staff will often be granted read-level access to a subscription under the assumption that they won't have access to secrets, for example.]
(I'm open to the possibility that I'm misunderstanding the exploit)
My reading on this is that the Reader must have read access to the API Connection in order to drive the exploit [against a secure resource they lack appropriate access to]. But a user can have Reader rights on the Subscription which does cascade down to all objects, including API Connections.
But also the API connection seems to have secret reader permissions as per screenshot in the article… Giving secret reader permission to another resource seems to be the weak link.
The API Connection in a Logic App contains a secret in order to read/write (depending on permission) a resource. Could be a Key Vault secret, Azure App Service, Exchange Online mailbox, SharePoint Online site..., etc.
The secret typically is a user account (OAuth token), but it could also be an App Id/Secret.
But somebody gave the API Connection permissions to read the KV secrets from, Exchange Mailbox, SharePoint folder etc… And anybody who has access to the API Connection now has access to the KV, SharePoint folder, etc… I do not think this is a problem with Azure, this is just how permissions work…
The API Connection in the example has permissions to read the secrets from the KeyVault -as per screenshot.
It seems to me the KeyVault secret leak originated when KeyVault K owners gave secret reader permissions to the API Connection. (And I will note that granting permissions in Azure requires Owner role-which way more privileged than the Reader role mentioned in this article.)
[edit - article used Reader role, not Contributor role]
> it's not a data breach for the government to have access to government data
This absurd oversimplification needs to be called out.
The 'government' is not a single individual, nor should 'government data' be treated without regards to specifics.
The exact entity doing the accessing, and the exact data that's being accessed, all need to be accounted for, and the appropriateness of the access will change depending on the context.
DOGE hasn't been transparent in any of this, which is my chief complaint at the moment.
Totally disagree, I've used KQL for about 10 years now, and SQL for 20. Given the choice, I'll always prefer KQL.
Sorry, I don't have time for a thorough rebuttal of all the topics mentioned in the link you provided, but if I had to bring up a few counterpoints:
1. (Can't be expressed) KQLs dynamic datatype handles JSON much better than SQLs language additions.
2. (variables/Fragile structure/Functions) KQL fixes many of the orthogonality issues in SQL. (Specifically: both variable assignments and function parameters can accept scalar and tabular values in a similiar way, where-as SQL uses different syntax for each)
