hyperrail

I'm not so sure moving to Git alone would have helped your case. Getting an enlistment is only a small part of contributing to Windows.

As Brian Harry alluded to, this is in fact very close to the previous system. As I recall it from my time at Microsoft:

The Windows source control system used to be organized as a large number (about 20 for product code alone, plus twice that number for test code and large test data files) of independent master source repositories.

The source checkouts from these repos would be arranged in a hierarchy on disk. For example, if root\ were the root of your working copy, files directly under root\ would come from the root repo, files under root\base\ from the base repo, root\testsrc\basetest from basetest, and so on.

To do cross repo operations you used a tool called "qx" (where "q" was the name of the basic source control client). Qx was a bunch of Perl scripts, some of which wrapped q functions and others that implemented higher-level functions such as merging branches. However, qx did not try to atomically do operations across all affected repos.

(The closest analog to this in git land would be submodules.)

While source control was organized this way, build and test ran on all of Windows as a single unit. There was investigation into trying to more thoroughly modularize Windows in the past, but I think the cost was always judged too great.

Mark Lucovsky did a talk several years ago on this source control system, among other aspects of Windows development:

https://www.usenix.org/legacy/events/usenix-win2000/tech.htm...

I believe it is still valid for folks not using GVFS to access Windows sources.

Interestingly, there is also Apache Bloodhound (http://bloodhound.apache.org/ ), which is _also_ a forge/project hosting system.

However, Bloodhound, which started out as a Trac clone, seems to be less active in development: http://svn.apache.org/viewvc/bloodhound/trunk/

Reading Consumer Reports' judgments based on their subscriber surveys, I would say that Tesla reliability is comparable with BMW and Mercedes-Benz.

The Tesla Model S rates 3/5 or "average" in expected reliability, while the Model X is 1/5 or "much worse than average".

Out of 12 reviewed BMW models, the 2 Series is 5/5, the X1 is 4/5, and all others are 3/5. (BMW also owns Mini; all 3 reviewed Minis score 2/5.)

Benz is worse, or at least less consistent: out of 12 models, 7 score 3/5, 2 each score 1/5 and 2/5, and one scores 5/5. (Benz owns Smart; the Smart ForTwo scores 2/5.)

I think that at worst, you can say that Tesla is slightly worse than BMW and Benz. And since the Model X is a new model, the low score for it could reflect early bugs not yet fixed.

I don't know the exact numbers, but when I left Microsoft a couple of years ago, the following product divisions were among those based in the 6 buildings of the Mountain View SVC (https://www.google.com/maps/place/Microsoft+SVC+Building+1/@... ):

- Outlook.com (formerly Hotmail)

- Parts of Office for Mac OS X and iOS

- Xbox hardware and accessories (Xbox software was in Redmond)

- Windows Phone online services

- Microsoft Research Silicon Valley (but that was closed in the first round of layoffs several months after I left)

SVC was originally built for Hotmail and WebTV (remember that?).

Microsoft also had separate offices in Sunnyvale (in the big cluster of relative skyscrapers just south of Moffett Field), which I believe were mostly folks who came from Skype and/or Nokia.

Microsoft's Silicon Valley Campus is also just north of the 101 Shoreline Blvd exit - currently, it and LinkedIn HQ are only about 1 mile apart, possibly within walking distance. If and when this deal goes through, this won't be the case anymore, and so LinkedIn will be isolated from other Microsoft offices.

I guess it is too early for LinkedIn to be making decisions as part of Microsoft...

It's even worse than that if you include recent past job cuts too:

> LivingSocial will employ around 200 to 225 people after the cuts.

> [...]

> The Washington, D.C.-based company has now cut nearly 900 jobs over three rounds of layoffs since Thakar took over for founder Tim O’Shaughnessy 18 months ago.

FWIW, Windows has had a built-in Cherokee font since Vista, several years before this font (2014). Windows 8 added another font and, more importantly, a partial Cherokee localization of the UI.

srcs: [1] http://blogs.microsoft.com/firehose/2012/12/18/microsoft-add...

[2] http://www.cherokee.org/languagetech/en-us/windows8cherokee....

Interesting that Eric Lawrence didn't choose to go back to Microsoft. Though given how much vitriol he directs on Twitter at MSFT and the IE/Edge group he was part of, I imagine neither he nor they wanted him back...

This part seems eerily prescient, doesn't it?

> "I think it's an important step in pioneering this work, but later on we'll probably see more exciting things in the way of digital cash," said Philip R. Zimmermann, a computer security consultant in Boulder, Colo., who created the PGP program.

> Digital cash, Mr. Zimmermann explained, is "a combination of cryptographic protocols that behave the way real dollars behave but are untraceable."

> In other words, they are packets of worth that have value in cyberspace, the same way dollars have value in the real world, except that they have the properties of anonymity, privacy and untraceability. Many details remain to be worked out, Mr. Zimmermann said.

> Also, "dnf" is not at all awesome to say out loud, while "yum" is among the most awesome commands to say out loud.

Indeed, to me, saying "dnf" out loud suggests "did not finish," which is the opposite of what you want from a package repository tool!

One issue with the str..._s() functions is that the invalid-parameter handler is a global setting - all code that calls the slibc functions and hits an invalid parameter problem will call the handler. This could cause anything from your application code to some random library you never heard of to make your program abort().

I personally don't think this is a big problem, as the kinds of issues that would cause the invalid parameter handler to be called usually are not recoverable no matter where they originate from.

But I can definitely see why the loss of control is technically troubling - those random libraries could be calling set_constraint_handler_s() and thus causing your code to keep running and not abort(), forcing you to rely on your second defense of checking the return values from all the functions.

(There's also a potential political issue with str..._s(), but I won't go into that one.)

"Crazy" is probably the wrong word for me to use (I have been known for my hyperbole in speech). What I meant was that, from my point of view, having multiple depots is almost the same as having multiple directories at the root of a single depot. The Perforce Support article you linked to says the same thing.

Hence, I feel that having multiple depots on one Perforce server simply eats up client names and causes confusion among those who haven't learned the distinction between "depot" and "server".

Please elaborate on "training". Do users check in things they shouldn't? Complain that clones take forever because of the sheer size of the files in a tree? Something else?

> All of the secret code depots

DepotS ? So I assume Google finally gave up on making their one Perforce server scale, then?

(Unless Google is crazy enough to actually do multiple depots on a single p4d instance...)

This looks like a close competitor to CoApp (http://coapp.org/) - both are FOSS package managers for Windows, although it appears Chocolatey places less emphasis on libraries and other developer-focused packages. That is, CoApp is emphasizing shipping both source and binary packages, and provides more help to package maintainers still trying to make their programs build on Windows.

Chocolatey will probably get more users early on though, because of its association with the ever-popular NuGet (watch for the Scott Hanselman blog post...).

No, no, it's still up: http://blindsearch.fejus.com/

Finally! True serializability! Never let anyone (including the docs for older postgres versions) tell you that predicate locking is too hard to implement.

How recent was your experience with TFS? It's been around for 6 years and shipped 3 versions, that should be enough time for it to be good enough for dogfood.

> When you reconnect to the server, just ask your P4 client to "synchronize offline changes" (in P4V, I think)... I'm sure these operations could be easily scripted, too.

p4v does have a lot of added features and conveniences. Maybe I'm an old fart, or maybe I'm just too used to sd (which didn't have an official GUI client app when I used it) but I don't actually like to use p4v, preferring to use the p4 command-line tool. So, yes, I've gotten used to automating certain operations via shell scripts that wrap p4.

> ... or just checkout your entire clientspec and ask your P4 client to revert unchanged files...

If you do that, though, the server will tell everyone else that checks out any file that you have it opened for edit too. This can be really misleading when they want to delete or integrate to the file. I don't like that Perforce implicitly discourages merging branches through "who else has opened this file" notifications, but that's how it is and I'd rather not abuse the system.

> TFVC is a centralized-server model that requires constant and active communication between a client (read: developer) machine and the server. If, for example, the network goes down for 1 hour, development grinds to a halt. The reason here is that TFS will mark all files as read-only on the filesystem until you have asked the server to check them out for you.

Perforce works the same way, causing much frustration for me whenever I have to work with a slow and unreliable p4 server (and, despite Perforce marketing, those exist). You can override p4 and make writable the files you want to edit without telling the server. But when you want to check in a changeset, you have to tell the server you edited the files, otherwise they will get left out of the changeset. Worse yet, if you try to get too clever with your local copy's settings, the p4 utility might overwrite your changes with a newly checked-in version the next time you update your local copy.

When I worked at Microsoft in the early part of the last decade, we used a Perforce fork called Source Depot. (Internet mentions of sd are rare, but here is one: http://stackoverflow.com/questions/491295). I have no experience with TFS version control, but it looks to have taken a lot of inspiration from sd, which was a fresh breath after the previous revision control tool which didn't even support branches.

> Google can launch products with a much better work/life balance than most games studios, and their engineers make a lot more money for it too.

I wonder: if Google decided to get into the video game business, would it fall into the game studio trap?

I'm not really sure what the answer is myself. For what it's worth, when I was at Microsoft, I heard no horror stories about overwork at MGS. However, any such stories would be second-hand at best because I never interacted with any MGS people.

> graduating a semester late (at the cost of several thousand dollars to myself)

Really? Your funding isn't guaranteed?

When I did my Master's I was funded as an R.A. without my advisor/lab having to tap her particular grants. Grants and fellowships were usually seen as something "extra" for master's and Ph.D pre-quals students, not their main source of funding. I find it surprising that your school or department seems to (or is forced to) think differently.

> I would imagine [Visual Studio would] improve a lot if they ate their own dogfood.

We do - just not VS :)

I used to work on Microsoft SQL Server. Our build system back then was substantially the same as Windows's. We used the Visual C++ command-line compiler, but we didn't use Visual Studio projects. Instead, our build utility was the BUILD.EXE program in the Windows driver development kit (http://msdn.microsoft.com/library/ff542351). BUILD is a wrapper for make that defines various useful macros, and enforces certain conventions for makefile contents (for example, the Sources file contains all and (mostly) only the source filenames to be compiled in the current directory). Our build environment wasn't the public DDK, but both have the same origin.

Relatively few people used Visual Studio, mainly because its C++ Intellisense was very slow (it took half an hour one time for the VS debugger to load a just-in-time crash dump). Instead, I used the Source Insight editor (a proprietary third-party product, but site-licensed by Microsoft), and used the WinDBG debugger from the public Debugging Tools for Windows. Source Insight is very fast at code browsing, fast enough for SQL Server's code base - indeed that is its main marketing bullet point. WinDBG isn't particularly fast, but it's no slouch either.