Mark Russinovich, Microsoft Critic, Is Now Building Azure
wired.com
wired.com
* Anders Hejlsberg
* Mark Russinovich
* Scott Hanselman
They have the clout and the job security to speak their mind - and they do. They all work on neat projects and are interested in talking about the internals. I saw Mark at Build this year and his talk was about the "fails" of Azure. It was an honest breakdown of how they've had failures that have taken down customers, taken down Microsoft services, and hurt the reputation of Azure.
I've followed Mark's blog since before he became a Technical Fellow at Microsoft, and he deserved it, no doubt. Very few people could write or speak with such precision about the internals of Microsoft kit. His interviews on Channel9 are all fascinating, before Azure he did work on the NT Kernel (and who knows what else) and he spoke candidly about dealing with issues scaling up the operating system. He has given interviews solely about removing global locks from the kernel, because that's his domain and he's good at it. If that reminded me of anyone else, it would be Linus Torvalds and his intimate knowledge of the Linux kernel.
Indeed, he "wrote the book" on it, which is apparently freely available as PDF now [1].
As someone who knows nothing about OS's, I picked up a cheap copy out of curiosity, and found it highly readable and enlightening (until it got rained on somewhere around chapter 10).
EDIT: Do you have a link to the "fails" talk? I've been using Azure for the last few months and have been extremely impressed so far.
[1] https://www.google.com/#q=windows+internals+russinovich+pdf
http://channel9.msdn.com/Events/Speakers/Mark-Russinovich
Thanks for the reference -- always interested in watching frank talks about software failure.
ps: hope the things shared in the one before last episode are now completely over. My best wishes.
Regarding other people, certainly many are worth following. It'd be remiss not to mention Erik Meijer's group or the work done by others in MSR. They make for great Channel9 videos and great papers when they publish. But when I go to or watch a MSFT conference, those 3 are the top names I look for. Fair enough?
Gosh I have such a nerd crush on him. Easily my favourite language designer, by far. I wish I could be him, and funnily enough am learning language design outside of work, but I highly doubt I'll ever be as good!
I really hope this advice is taken by others, particularly the Windows team. Powershell is a golden example of this. Great idea, piping around objects instead of text, but wait, they must be .NET objects. So the entirety of the language community cannot participate other than Microsoft languages.
I'm hoping they revitalize the command line taking this advice, start with something simple and let others build on top of it.
http://www.powershellmagazine.com/tag/language-specification...
Also another thing I have a problem with is the startup time, for a lot of quick hacks, I can start up, execute and close down the terminal (cygwin lets say) in the time i am still waiting for powershell to initialize. Not huge problem but for me it holds me back from using powershell somewhat.
1. Result of a command-line tool is its output, not its exit code, so you have to use $LastExitCode when treating command-line invocations as boolean values
2. Stream behaviour other than stdout gets weird when redirecting one stream into another (e.g. 2>&1 causes every line that's output on stderr to be thrown as an exception.
3. Encodings are a mess, sadly. They mangle Unicode output from external programs. This was a compatibility decision, but it's unfortunate, especially because the appropriate .NET APIs are a bit clunky to use.
1 is just different from bash, 2 and 3 can be dealbreakers depending on what you do, and the workaround is the same, but annoying, admittedly.
The one-second startup time has been awful, I know. Although for me at least since Windows 8 it has been instantaneous, making this a non-issue. (Pash is worse at about two seconds currently, though.) But from the time when Powershell was slow to start I still have a habit of just running cmd for things that can be done in cmd.
How would you do it, though? Pipe around JSON or XML? Then you just have data structures, but not objects. They can't have methods and if they could, what language would they be written in?
That's what the comment I quoted is saying, Microsoft likes to do big up-front designs that restrict their platform to uses that they have already thought about.
http://www.jsnover.com/Docs/MonadManifesto.pdf
And Snover's description of the process almost a decade later:
from http://www.jsnover.com/blog/2011/10/01/monad-manifesto/ > I had had a number of conversations with our team in India where everyone shook their heads and smiled and seemed to get it but then the code clearly demonstrated that they had absolutely no clue what I was saying but weren’t telling me that. > We tried a number of times to get very precise in our documentation but time and time again, it was clear that they just weren’t getting the concept
Wow, Microsoft Architechture Astronaut in a nutshell. He handwaves an idea, and then complains when someone actually writes some code and it doesn't match his imagination.
"before the first public release in 2006, the codename for this project was Monad. The name Monad comes from The Monadology by Gottfried Wilhelm Leibniz, one of the inventors of calculus. Here’s how Leibniz defined the Monad:
The Monad, of which we shall here speak, is nothing but a simple substance, which enters into compounds. By “simple” is meant “without parts.” —From The Monadology by Gottfried Wilhelm Leibniz (translated by Robert Latta)
In The Monadology, Leibniz described a world of irreducible components from which all things could be composed. This captures the spirit of the project: to create a toolkit of simple pieces that you compose to create complex solutions."
Can you provide an example?
Ruby implementations will tend to return a byte stream rather than a value a value against the .NET API. Even if Microsoft provided another API on top of the .NET API, the same situation would exist because Ruby implementations usually don't write to that API by default. It's turtles all the way down on the .NET side.
Programming .NET in Ruby requires writing to the .NET interface from the Ruby program. If one wants to program to the .NET interface through Powershell from Ruby, a Ruby program can always output text that can be interpreted as a Powershell script. One way or another, the responsibility is on the program to write to an API.
What would be the output of a Brainfuck program that should operate as a PowerShell cmdlet? Would it ever be more than text which can be interpreted as a PowerShell command or script?
also you can use the '&' operator to call anything executable, so you could take an exe and call it from powershell without issue
& 'externalProgram.exe'
when you can just use externalProgram.exe
just as well. I see a lot of weird things on Stack Overflow with & or even Invoke-Expression, especially when it involves passing parameters to programs and the lack of understanding how parameter passing works. The results usually aren't pretty, then."just data structures" is a subset of objects - they are objects with data but no methods. i.e. DTOs. They're not always useful, but to say that they can't be accommodated in a pipeline because they "aren't objects" is not quite right.
You could pipe around DTOs like that, and as long as they had a structure that attached typing information to them, you could use something like intents (similar to those in Android or Web Intents) to attach "methods" to them. The executables implementing behavior could be written in any language that the platform could run.
1. Replace PowerShell with a .Net interpreter so you can "just run" a .cs_exe file or whatever. No one wants to learn/deal with yet another throwaway proprietary scripting language.
2. Replace all the PowerShell cmdlet garbage with .Net libraries. You'd also be able to then trivially automate any scripting from existing .Net programs/tests.
3. Have a JavaScript -> .Net compiler so people don't have to deal with C# or VB.Net if they don't want to.
Scripts look something like (C# in this case):
using Microsoft.Scripting
void Main()
{
SQLServer.Configure(<SOME JSON>);
var result = IIS.Start("MyWebPage");
if (!Installed(<some windows package>))
{
File.Install()
}
if (!UserExists(server, user)) {
CreateUser(user)
}
}
You can't do all of this today (at least not easily or without installing many extraneous or 3rd part libs which create deployment headaches).EDIT: for clarity.
PowerShell is far better for scripting than C#. C# is terribly verbose and lacks scripting-ish stuff like string interpolation. I'm not sure it even had dynamic when PowerShell was made.
It is pretty dumb that C# still hasn't shipped a proper REPL or script runtime though.
The problem is that rather than adding libraries to improve .Net for scripting-ish stuff like string interpolation, you have to deal with an entirely different platform that shares little with the command line, and little with .Net.
Workin' on it.
http://channel9.msdn.com/coding4fun/blog/REPL-for-the-masses...
Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about and probably have never looked at it again. This happens a lot where people who work on big projects just assume everyone else will look past the initial experience and grasp the cool vision.
I think this depends on what component/system your trying to use. Recently I found myself using powershell (mostly via copy/paste) for what I consider simple one time system administration type duties. In the past I don't think microsoft would have shipped a product without a first class GUI to manage it (ignoring registry editing for "rare" tweaks). Now, it seems the prevalence of powershell allows some groups inside Microsoft to write a bunch of code without a functional UI, leaving the users to grub through what is effectively programming documentation to perform simple things like enabling/disabling a core feature of the product. I would expect from an architectural level, that microsoft would assure that the major functionality in their product is controllable both from the GUI as well as from the command line. That doesn't appear to be the case anymore than windows 8 can be used entirely from the metro/modern interface.
Frankly, its yet another erosion of what I considered to be Microsoft's strong points against Linux.
So PSh gets treated as the first-class interface with the GUI being a frontend to underlying PSh functionality. I've gotten away from Windows sysadmin work, but from what you're describing it sounds like they've swung the pendulum a bit too far in the other direction and no some of the GUI stuff isn't easily accessible.
Having both would obviously be ideal, but if you were to put a gun to my head and make me choose, I'd take the current situation of a lacking GUI every time, personally. All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating.
BTW: In the past (because I don't do a lot of this anymore either), GUI operations were automatable with one of the dozens of clones of the windows macro recorder. The ones I remember using had their own little scripting languages (which could be automatically generated/recorded) with simple variable substitution and control flows. The resulting scripts were callable from the command line/batch files. Those products overwhelmingly relied on the ability to walk the GUI resource trees and find things by id/name/some attribute and then send messages like clicking or typing to them. How well applications like this still work in a metro/modern environment I don't know. Although a google search indicates a number that are still available.
BTW: For the linux/X users out there, check out http://www.gnu.org/software/xnee/
The feeling of being restricted on windows as a developer always gets me running back to linux sharpish.
However because of its youth, some equivalent tools are missing.
The world did not need PowerShell.
The team that developed PowerShell actually wanted to do just that. They didn't, because Unix was built mostly around text files, so tools that work with text files are a good way to manage such a system. Windows however, is not, so Unix tools are a particularly poor way of managing Windows.
That's also why PowerShell treats file system, registry, WMI, etc. as first-class constructs, because it has to to be effective.
Also- it exposes them as filesystems & files.
MS is full of architecture astronauts (along with super smart people, who do useful things - but the arch people are in charge) that sit around and contemplate all these bizarre use cases for things that no one actually has. Then, since MSFT believes they have little/no competition in the space, they spend years developing this grand vision and dumping it on their customers, who then attempt to figure out what parts of this vision are useful and what parts are bunk.
Microsoft then looks at what happens, sees the work arounds, and rewrites the whole thing again to accommodate not only those use cases, but a whole host of other imagined ones, too.
Lather, rinse, repeat.
Open source generally doesn't have this problem, as a) some developer was scratching their own itch, so the problem is real b) doesn't have unlimited time and budget, so they have to keep it small and evolve, and c) relies on developer's contributions, so it has to be marketable.
Open source : Microsoft :: Lean startup : Waterfall
MFC was bad, but there are even worse stuff
Every time I have to check a new API (thankfully, not that often) it's a mess. They keep "re-solving" the same problems with new APIs that are a pain to use
The .NET stuff is not too bad though (but yes, it has some warts)
If you did development on a Windows machine in the last 20 years, you probably downloaded a sysinternals tool at one point. Many Microsoft KB articles pointed to their tools and articles and when Microsoft announced their acquisition, most people were like "That makes sense".
I think Mark is just honest about the technical aspects of Windows and thankfully his attitude has not changed since Microsoft pays his checks.
One example of this are his videos about Windows Memory Memory management (from 2011, hosted on MSDN)[1], which besides being a detailed technical explanation don't skip all the shortcomings of Windows' memory subsytem. Sometimes his statements seem harsh but I think it's more sincerity and he has been as sincere about his own tools as well[2].
[1] http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL...
[2] http://blogs.technet.com/b/markrussinovich/archive/2009/11/0...
Every system has pros and cons and learning how to work with those constraints is how you become a master. From what I understood Mark is one of a small number of people who has an extremely deep understanding of Windows inner workings.
Sysinternals gave lectures about windows internals to Microsoft employees.
His blog has some pretty good reads for anyone that wants an in-depth view of Microsoft products:
http://blogs.technet.com/b/markrussinovich/archive/2006/07/1...
"I’m joining Microsoft as a technical fellow in the Platform and Services Division, which is the division that includes the Core Operating Systems Division, Windows Client and Windows Live, and Windows Server and Tools. I’ll therefore be working on challenging projects that span the entire Windows product line and directly influence subsequent generations of the most important operating system on the planet. From security to virtualization to performance to a more manageable application model, there’s no end of interesting areas to explore and innovate."
A little off topic, but if you ever wondered what all those numbers shown by Task Manager really mean, Mark did a video[1] that really explains it well.
[1] http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL...
http://technet.microsoft.com/en-us/sysinternals/bb963887.asp...
That's a bit of a journalistic stretch.
The S3 stuff was kicked off in the late 90s and everyone just kinda-sorta said why? But it seems to have been the first modern cloud-type service.
Now, I personally hate the term "Cloud" because it's pretty meaningless, and you can look back throughout the entire history of computing and find examples of distributed, remote storage, compute power etc etc.
But if we're going to call anything "Cloud" in the sense we try to use it now, then I reckon Amazon were first to market by a mile.
What? As far as I know, S3 launched in 2006.
But I'll happily admit my memory might be faulty! And yes, that's not S3 as it's known now.
— John McCarthy, speaking at the MIT Centennial in 1961
(As quoted at http://en.wikipedia.org/wiki/Utility_computing)
Multics was the result of this vision of McCarty and others at MIT, hence its strong focus on security.
Wikipedia: Amazon launched S3, its first publicly available web service, in the United States in March 2006[2] and in Europe in November 2007.[3]
But I'll happily admit my memory might be faulty!
http://aws.typepad.com/aws/2006/08/amazon_ec2_beta.html
The Wikipedia article is organized confusingly. It talks about the 2002 launch of "Amazon Web Services" which at the time was just an API for the Amazon retail catalog. Then for some reason it links to a press release about the 2009 release of "EC2 for Windows", then goes back to talk about earlier launches like MechTurk (2005), S3 (2006), and EC2 (2006). I'll see if I can clean up this mess... [Update: cleaned up the article and added some citations.]
Note: I worked at Amazon.com from 2005 to 2008, the period when the company launched its first cloud computing services.
(Disclaimer: pre-merger employee)
AWS' strategy of virtualization honors interfaces (cut points) between the major OS and network stack functional areas.
Grid computing was about portable code running on compute farms, more like a time share. Like an app server.
I shamefully admit I was slow to grok AWS. I had been using VMware for testing and cohabitation and such for years. I just didn't see how AWS was any different, or better. I really missed the boat on this one.
They hired him (effectively) quite some years ago when they bought sysinternals (2007 or there abouts IIRC).
Props to them for neither neutering him nor making him leave though, either of which is common with a buy-out that includes a critic. A good critic can be a powerful resource for reflection and positive change.
(New idea for facebook: allow users to submit abstracts/summaries of articles, and show me the one written by someone least removed from me by friendships.)
(I'd suggest not downmodding this, folks. Politely asking for a summary is nice, as is providing one, and let's not discourage it. It's not the same as just squirting out a "TL:DR?".)
So maybe I'll just start asking for an "abstract" in the future, since that sounds fancier.
WITH world-class cloud services, Microsoft could derive revenue from Apple and Android users.
It appears that Microsoft's biggest problem was egos. People wanted to "leave their mark" rather than play to strengths and achieve the possible. Microsoft could readily be 3X bigger if they focus on what they are good at and on the customers most likely to welcome Microsoft products.
TBF this had a lot to do with the stack-ranking MS was famous for. When you've got to justify your job every year making a name for yourself is mandatory.
That sounds very much like App Engine Managed VMs.
I had been following Mark for quite some time in the early 2000s and was a big fan of his tools but hadn't seen him speak or anything like that. He then did talk on work he was going for the next Microsoft OS, which at the time was Windows 7. His talk was easily the best talk that day. He was confident, knew his subject and was passionate about what he was doing. No one else that day was as authentic and enthusiastic as he was. I'm not sure how many people in that particular audience recognised his drive and talent though.
I'm glad to see him written up about and if he's a big part of driving Microsoft into the future, then Microsoft could very well become exciting and relevant again.
Edit: No takers? Ok, I'll try to come up with one.
The article, though, has an embarrassing number of typos...
If you want to see the magic before MSFT force it behind the wall, here you go.
https://code.google.com/p/akeo/downloads/detail?name=sysinte...
And fuck you, Microsoft, and long live Russinovich. Could not have done without them in sysadmin work, open or closed.