I have multiple bluetooth headsets that I use with multiple devices. I have collected a series of tricks that I use when I can't get bluetooth to operate the way I want it to: turning bluetooth on/off, restarting the bluetooth device. "Forget the network" is not one of those tricks, but I wouldn't be surprised if others have learned to use it.

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).

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.

Why would you need a package to wrap a website? Wouldn't the website be accessible on a LTSC build, even if the official package isn't available?

If this is filling a highly useful role that I'm admittedly oblivious to, why are there only three commits in the project history?

(Best I can tell, this is a personal project that somehow made it to HN front page)

Why doesn't the README file explain what this repository is doing?

OP, what did you hope to accomplish with this submission?

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....

> "... 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.)

(No disagreements with your post, just want to give credit where it's due. I'm also a big fan of the syntax)

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)

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.

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)

(disclaimer, msft employee)

I might suggest that coding doesn't take as much of our time as we might think it does.

Hypothetically:

Suppose coding takes 20% of your total clock time. If you improve your coding efficiency by 10%, you've only improved your total job efficiency by 2%. This is great, but probably not the mind-blowing gain that's hyped by the AI boom.

(I used 20% as a sample here, but it's not far away from my anecdotal experience, where so much of my time is spent in spec gathering, communication, meeting security/compliance standards, etc).

For a large portion of my career, the dashboarding solutions I've worked with have followed a similiar model: they provide a presentation layer directly on top of a query of some kind (usually, but not always, a SQL query). This seems like a natural next step for organizations that have a lot of data in one spot, but no obvious way of visualizing it.

But, after implementing and maintaining dashboards/reports constructed in this way, big problems start to arise. The core of the problem is that each dashboard/report/visual is tightly coupled to the datasource that's backing it. This tight coupling leads to many problems which I won't enumerate.

Power BI is great because it can provide an abstraction layer (a semantic model) on top of the many various data sources that might be pushed into a report. You're free to combine data from Excel with msSql or random Json, and it all plays together nicely in the same report. You can do data cleaning in the import stage, and the dimension/fact-tables pattern has been able to solve the wide variety of challenges that I've thrown at it.

All this means that the PowerBI reports I've made have been far more adaptable to changes than the other tightly coupled solutions I've used. (I haven't used Tableau, but my understanding is that it provides similar modeling concepts to decouple the data input from the data origin. I'm not at all familiar with Looker).

[disclaimer, I'm a Microsoft Employee (but I don't work in Power BI)]

"The oldest trees are estimated to be over 200 years old." https://www.oldgrowthforest.net/md-schoolhouse-woods

"The age of the oldest trees is not certain, but 100 rings have been counted on a downed loblolly pine and a downed chestnut oak. There is no old-growth forest in this park, however, the strong protections put in place on this forest ensure that it may recover in time." https://www.oldgrowthforest.net/va-james-river-park-system

(The exact definition of old-growth isn't agreed on, but I've seen some foresty documents in the PNW that demand tree age of 400+ years as a prerequisite for the old-growth categorization)

It might be easy to argue over the exact degree of similiarity, but I'd argue that the US has repeatedly made manufacturing investments since the 1950s. Buried in bills signed into law, you'll find such investments.

Recent examples include the Recovery Act of 2009 or the American CHIPS act of 2022.

https://en.wikipedia.org/wiki/American_Recovery_and_Reinvest...

https://www.cfr.org/in-brief/what-chips-act

But one thing I don't get about this: what was the role of the enterprise admins?

Most administrators at large companies are cautious about rolling out new software versions to their employees. They (normally?) test before broad deployment.

Seems like one of three things would have had to have happened for this to be missed:

1. Admins ignored testing this update prior to enterprise rollout.

2. Crowdstrike forced the update on unwilling users.

3. Crowdstrike does not provide a framework for such pre-rollout testing, and enterprises chose to use it anyway.

Can anyone offer insight?

[Disclosure: I'm a Microsoft employee, but not an enterprise admin]

Examples:

"while other people who just picked a better company to work at 20 years ago and never left have been growing their wealth by a couple million dollars per year every year for almost their entire career"

"What is it like to join a company where all the co-workers your same age have made $10+ million over the past 4 years while you are joining with nothing?"

You'd have to be very high in the org chart at a FAANG style company to make that kind of income.

Thanks for the correction! I must have read about Washington States objection a while ago, and been unaware of a change in their position (since I first read about it)