hyperrail

* Baseball Stadiums Are Closed to Fans - but This Guy's Balcony Is Open for Business

* Americans Craving Contact Ponder New Rules for Throwing a Party in Real Life

* When Your Best Friend in Quarantine Is a Squirrel, You May Be Going Nuts

* Beware of Falling Tofu: China Takes on High-Altitude Littering

* Did You Forget Things During Lockdown? So Did People With Superior Memories

In that context I don't have a problem with the title "Who Is the Mystery Shopper Leaving Behind Thousands of Online Shopping Carts?".

The advice is still "don't use .NET managed code for your in-proc shell extension", but the given reasons are not necessarily specific to the .NET runtime:

1. The .NET framework CLR takes too long to load for an extension that could be loaded by any app that pops up shell UIs.

2. There are seams between .NET and COM even with interop. These seams open traps for you because the COM-era shell APIs (Windows 95 to Windows 7) were designed for people who write their shell extensions in C++ and so can deal with all the tricky details of COM.

In particular only the older C++/CX has ^ pointers or other Microsoft-specific C++ language extensions. C++/WinRT is standard C++.

Writing your code using WRL (Windows Runtime C++ template Library) is good if you want to learn enough about how the Windows Runtime extensions to COM work in order to debug effectively. However, its close relationship to the underlying COM and Windows Runtime APIs also makes it far too verbose to quickly write good API-consuming and -producing code, in my opinion.

Filing a bug in another Microsoft product has been technically easy for a long time. It's true that each product team has their own Product Studio database or Azure DevOps organization, but Product Studio gives you a listing of all PS databases company-wide, and I think you can get the same thing with AzDO. And in both, you can open a bug in any work item tracking database you have write access to.

To the extent that you cannot/could not touch bugs or sources for other Microsoft products than the one you work/worked on, that was more a feature of Microsoft's confidentiality policies and corporate culture than of our tools. That is, people in the Windows organizations had access to Office's Product Studio DB or master source repos only if they were specifically delivering features for Office, and vice versa.

That attitude is mostly gone now. Since 2013, everyone working on product R&D has had access to most other products' resources, and (IMO) almost no one tries to jealously guard their code against "outsiders". There are still different bug databases for each Microsoft product, but you have permissions to read all of them by default.

Exceptions to this general openness and transparency are largely limited to consumer hardware products (Surface, Xbox) which remain very tightly controlled against leaks.

(Above is based on my personal experience working for Microsoft in the start and end of the last decade, with a gap in the middle.)

It attempts to solve both the cultural challenge (bugbase written by a different company/team from the source control, imposing 2 different styles on you) and the technical one (bugbase and source control don't talk to each other, and so bugs and checkins are not linked).

I think that will not be easy. Let's say you get hired as a "Senior Software Development Engineer" at Microsoft (internal folks will know this is Level 63 or 64). Your signing bonus will be approximately $20,000 to $30,000, and your stock award will be highly variable but generally has a 1-year cliff for vesting, so it can be disregarded your first year.* 20k-30k per year gives you only a minimal subsistence in the Seattle region or SF Bay Area, especially with the high cost of housing in both.

* https://www.levels.fyi/salary/Microsoft/SE/Senior-SDE/ gives a good idea of how much Microsoft pays a Level 63. Regarding stock awards, Microsoft does not give stock options or RSUs. Instead we have a RSU-like system for equity awards where the company gives you unrestricted stock on a schedule. It is RSU-like in that you can't sell the stock until it "vests", but unlike an RSU in that you don't hold the stock at all until it "vests", only a future right to get it.

- "Don't use the MSIT image you get from PXE boot on corpnet": The customized Microsoft-internal image works fine, and saves you time installing Office. You can't avoid "MSIT shovelware" by installing clean Windows; if you join corp.microsoft.com AD or @microsoft.com AAD, the same software will still be pushed to your PC eventually via System Center Config. Mgr. and Microsoft Intune.

In any case, soon you won't be able to do network boot to install anyway, either plain Windows or the customized Microsoft-internal image. CSE&O (Microsoft's IT department) intends to shut down the Windows Deployment Services network boot servers as part of its overall thrust to make the corporate network unnecessary and move Microsoft entirely to the cloud.

- "domain join to Microsoft's Azure Active Directory instance": If the machine is a desktop, I recommend you join to on-premise AD instead ([location].corp.microsoft.com). If you join your PC to AAD, you can connect to it via Remote Desktop only from another box that is also AAD-joined or on-premise-AD-joined. Which means if you want to work from home without a laptop by TSing/RDPing into your desktop, you won't be able to avoid joining your home computer to AAD - negating the current advantage of the CSE&O RD Gateway.

In addition, the management policies are slightly different between @microsoft.com AAD joined machines and on-premise-AD-joined boxes. Usually this is to the detriment of dev work on the AAD-joined boxes.

You can learn more about the Delaware experiment from the same places I did:

- https://www.youtube.com/watch?v=4FYUU4wP9s8

- https://www.usatoday.com/story/news/nation-now/2018/03/14/mo...

Raymond Chen complains about Microsoft products often. He even has a response to people who say that he is the man in a glass house throwing stones: https://devblogs.microsoft.com/oldnewthing/20060713-12/?p=30...

And while you can say "he works on Windows too, not another Microsoft product", he doesn't work on or review all the business plans, technical designs, or pull requests for all of Windows either. He does serve on an internal Windows API review board, though.

Disclosure: I work at Microsoft on products including Windows. However, I have only interacted with Raymond Chen in a couple of email threads. Regrettably but perhaps understandably, he was curt in both.

This phrase made me laugh, because UW imapd was largely written by Mark Crispin, who invented the IMAP protocol!

It seems that in about 2007, Crispin forked UW IMAP to create his own IMAP server, "Panda IMAP" [1], which at least one website claims to be "fully compliant" with the IMAP RFCs while UW IMAP is not. [2]

[1] https://github.com/jonabbey/panda-imap

[2] https://imapwiki.org/ImapTest/ServerStatus

https://store.wsj.com/shop/US/US/wsjussblds0919/

They are currently running a 2 months for $1 sale and a half off for 1 year sale, but a digital subscription normally goes for $38.99 per month.

Oddly, it's a couple of dollars cheaper per month to buy the print newspaper and digital subscription together than to buy the digital sub alone.

Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.

On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.

We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.

[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.

In my culture (Thai), I put my given name first and then my family name (inherited from my father), like in most of the west, but actually my name of formal address is my first, given name, and my family name is hardly ever used except as a differentiator. [1]

In Vietnamese culture, I believe the given name is also the name of formal address, yet the family name comes first as in China and Japan. Hence Nguyen Anh would be called "Anh".

[1] http://blog.jclark.com/2007/12/thai-personal-names.html

Bazel was first announced and made open-source in early 2015, but by that time Domino had already been in development for at least a year. I remember following the early internal discussions at Microsoft on the One Engineering System or "Apex" initiative which first provided the impetus for what became Domino; some of those discussions were quite animated :P

Also, while I don't know BuildXL and Bazel well enough to compare their goals and relative strengths, I will say that BuildXL was developed at Microsoft, which has historically had a great diversity of build toolchains and workflows across all its software products. Just on the toolchain side, Microsoft has many different build engines/make tools, unit test frameworks, tools and conventions to register an automated test to run on a certain schedule (for products too big to run every test on each and every build), build and test server farms, continuous integration tools to orchestrate those server farms, tools to email people and/or file bugs on test failures, and so on...

From my limited understanding, Google has never been this way at all, and so some of the lessons and ideas incorporated into BuildXL may seem strange to Bazel's designers.

https://news.ycombinator.com/item?id=19678579

https://news.ycombinator.com/item?id=19678578

I can't reconcile that claim with PC Magazine's tests of the iPhone XS's mobile performance: https://www.pcmag.com/news/364116/iphone-xs-crushes-x-in-lte...

The PC Mag author, Sascha Segan, says repeatedly that the iPhone XS at worst only slightly trails the Galaxy Note 9 and other high-end phones with 2018 Qualcomm SoCs. To quote directly:

> Between the three 4x4 MIMO phones, you can see that in good signal conditions, the Qualcomm-powered Galaxy Note 9 and Google Pixel 2 still do a bit better than the iPhone XS Max. But as signal gets weaker, the XS Max really competes, showing that it's well tuned.

> Let's zoom in on very weak signal results. At signal levels below -120dBm (where all phones flicker between zero and one bar of reception) the XS Max is competitive with the Qualcomm phones and far superior to the iPhone X, although the Qualcomm phones can eke out a little bit more from very weak signals.

We could say this is all Apple tuning the phone's antenna array and materials, but I find it extremely unlikely that would have compensated for "5 years" of Intel lag - back then LTE was several times slower in theory and practice.

We could also say this is just Apple giving Intel all the secrets of modems that Intel couldn't figure out themselves. That could be more plausible, but again I'm doubtful, since Apple would have little incentive to hoard those secrets and then loan them to Intel instead of using them to build their own chips. Unless of course Apple stole those secrets from Qualcomm or someone else...?

https://web.archive.org/web/20080415231058/http://thedailywt...

In driving school, I was taught to adjust my side mirrors exactly the way described here: rear view mirror points to rear, side mirrors just barely show the side of the car. And still there are blind spots in every car I've driven, no matter how much "fine tuning" I do.

This is why blind spot warning systems are a must in any new car I consider buying.

The only way I'm driving fast down 101 south is if I'm there at 11 am. Which counts as morning, but is also unreasonably late even for salaried workers in a relaxed company.

I wonder if WSJ was chasing Bloomberg? Or if this phenomenon isn't really as strong nationwide as is being implied, but is mostly only in certain parts of Texas?

It's hard not to be cynical about cycles of former rebel leaders and their families setting themselves up as the new dictators, but at least here, things are looking up.

[1] https://www.voanews.com/a/congo-opposition-supporters-protes...

[2] https://en.wikipedia.org/wiki/ECOWAS_military_intervention_i...

For example, the British Boy Scouts organization is simply the "Scout Association" and has admitted girls under that name since the 1970s, though the British Girl Scouts organization is "Girlguiding" and is still for girls only.

Perhaps we Americans could rename the Boy Scouts and/or Girl Scouts to have a similar distinction as a way to smooth over this dispute.

(see https://en.wikipedia.org/wiki/Scouting and https://en.wikipedia.org/wiki/Girl_Guides )

> By default, Mac computers supporting secure boot only trust content signed by Apple. However, in order to improve the security of Boot Camp installations, support for secure booting Windows is also provided. The UEFI firmware includes a copy of the Microsoft Windows Production CA 2011 certificate used to authenticate Microsoft bootloaders.

> NOTE: There is currently no trust provided for the the Microsoft Corporation UEFI CA 2011, which would allow verification of code signed by Microsoft partners. This UEFI CA is commonly used to verify the authenticity of bootloaders for other operating systems such as Linux variants.

It isn't clear whether new root CAs can be added or if there is a customer-accessible setup mode for secure boot at all.

Another part of the discussion is about the various levels of secure boot enforcement. In the default "Full Security" mode, the Mac OS setup (or Boot Camp assistant for Windows boot) requests that Apple sign the OS boot loader with a signature derived from the T2 chip's unique ID, and then the boot firmware on the T2 checks for this machine-specific signature on boot. As I understand it, Apple claims that by simply changing its online service to deny signing certain boot loaders, it can prevent many OS downgrades to versions with known vulnerabilities.