bradford

I've been battling with locking down my kid's devices for much of my life.

I haven't found a parental control feature that works: we've tried several, but, generally, nothing survives the 'Hey, I'll just factory reset the device and start with a clean out-of-box-experience' bypass. Kids can figure this stuff out.

Even when we thought that things were under control, kids can easily procure new devices. Many families don't dispose of their old phones; it's not too hard for kids to find an older model that's been sitting around collecting dust, bring it to the schoolyard, and trade it like a baseball card.

I wish I had a good answer, and, distasteful as the age-verification might be, I'm open to such draconian measures at this point. If you say there are better ways to enforce this, I'd honestly love to hear the specifics.

The quote resonates with me, even though I haven't experienced the exact "set a vibe on a date" scenario.

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.

Let's avoid falling into the trap of assuming the worst of people when replying to comments.

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

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.

Can you explain in what way Windows already does this?

Thanks for your response!

Ok, but the brief README links to an actual microsoft.com domain (https://www.microsoft.com/store).

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 is a repository called 'Microsoft Store' being hosted on a seemingly random github account?

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

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

I hate to be that guy, but I believe the `|>` syntax started with F# before Elixir picked it up.

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

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)

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)

(disclaimer, msft employee)

How can this be possible if you literally admit its tab completion is mindblowing?

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

What do you love so about PowerBI?

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

It's a great site, but I don't think many of the listings could be properly categorized as old-growth. For example, I checked out a few samples:

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

Does the US invest in manufacturing like this anymore?

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

I see discussion about who's at fault: Microsoft or Crowdstrike.

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]

It's not a typo. The author alludes to these inflated salaries several times.

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.

As the dissent notes, “all 50 state Attorneys General have signed on to this plan.”

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)

Does anyone find it strange that this is described as a loss for the victims?

I can see it going both ways, yes: this means that 6 billion dollars are not immediately available for compensation.

On the other hand, certain states (Washington was one, if I recall) argued that 6 billion dollars was such a pitifully small amount (relative to the damage done) that they declined to accept compensation in hopes that future lawsuits would yield more.

I view this decision as rejecting the immediate compensation, but opening up possibility for greater compensation in the future (with obvious risks and delays).

To be clear, I don't find SQL difficult to understand. I've used it for 20+ years and I can always get the query to generate my desired output. But I often find that the language is a hindrance, and that I can more efficiently reach my desired output using modern languages.

for example, here's the KQL equivalent to the 'average of sums' query:

  purchases
  | summarize total_per_customer=sum(amount) by customer
  | summarize avg(total_per_customer)

I view SQL right now similar to the way I viewed C++ in early 2000s:

I hate it, but there's little point in complaining because it's so ubiquitous.

More robust criticism is provided here (https://carlineng.com/?postid=sql-critique#blog), which pulls on an interview here (https://www.red-gate.com/simple-talk/opinion/opinion-pieces/...) The quote I usually drag out is from Chris Date, who helped pioneer relational DBs:

"At the same time, I have to say too that we didn’t realize how truly awful SQL was or would turn out to be (note that it’s much worse now than it was then, though it was pretty bad right from the outset)."

As an example of a language that does it better, I think kusto-query-language (KQL, https://learn.microsoft.com/en-us/azure/data-explorer/kusto/...) has been a dream to work with. (disclaimer, Kusto is a Microsoft product, and I'm a Microsoft employee).

I was coming here to say something similiar.

The article only shows examples of dual axis charts where line series are used for both axes. This will clearly cause confusion (especially when tooltips are not available).

I've generally found that when displaying a percentage, it is helpful to show the individual counts for numerator/denominator. I believe that showing percentage as a line series on one axis, and raw counts, represented as a column on the other axis, can be a helpful visual.

Not OP, but I'd guess there's greater industry awareness of relational DBs than there are of parquet files. I've been on the receiving end of a Parquet file that I didn't know how to crack open the ambiguity on how to proceed was frustrating.

I don't think this is a particularly insightful article.

Data engineering can be lonely. I like seeing the approach that others are taking, and this article gives me a good idea of the implementation stack.

I used SQL in various implementations for about 15 years. I didn't find much fault in it until I started using KQL (the language which seems to have inspired Pql).

The difference in enjoyability is stark: I truly hate SQL now.

More robust criticism is provided here (https://carlineng.com/?postid=sql-critique#blog). The quote I usually drag out is from Chris Date, who helped pioneer relational DBs:

"At the same time, I have to say too that we didn’t realize how truly awful SQL was or would turn out to be (note that it’s much worse now than it was then, though it was pretty bad right from the outset)."

https://www.red-gate.com/simple-talk/opinion/opinion-pieces/...

I may have interpreted the problems addressed in the article differently.

Certainly, privacy incidents can occur due to mishandling of sensitive information (i.e., secrets, identifiers). Addressing these are a no-brainer and something that technology can and should address.

I interpret the article as addressing a second kind of privacy issue that isn't due to mishandling. Instead, it's part of the profit model for many major tech companies: advertising. In this case, the privacy issue isn't a mishandling, it's by design and explicitly disclosed in the Terms of Service.

(I can't say which one is a bigger issue at large, but I believe policy is needed to address the second issue).

I'm of the opinion that 'surveillance capitalism', as described in this article, is a problem of policy/legality, not technology.

Technology minded individuals keep looking for a technical solution to this problem. I'm hesitant that a technical solution exists.

Unfortunately, I also don't expect Congress to promptly pass new legislation that competently addresses the problem. (I am more optimistic about the efforts by the EU and individual US states.)