Automating the world one-liner at a time…
If you were thinking about attending a PowerShell talk at LISA (Large Installation System Administration conference), the answer is NO. Someone suggested that the attendee's of this conference would love a PowerShell talk so I submitted my Monad Manifesto as a draft with the thinking was that I would bring that paper up to date, provide more details etc. I'd be hard pressed to think of a topic more relevant to people managing large systems so I thought it would be a good fit. Sadly, the paper got turned down and the reject notice (below) provided feedback from various reviewers.
I thought you might enjoy these as many of them are highly entertaining. I especially enjoyed this one: "tone of the paper is often promotional rather than discursive, at times frenetically so. This detracts from its readability and often results in emotional effusion in place of technical substance". "Frenetic" - he had me on that one (though I was planning to do a "tone" pass on the final paper). I wasn't quite as convinced by this one, "the author does not seem to understand the Windows system administration communities". J
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
I am sorry to inform you that your paper: "Windows PowerShell: A New Approach to Automation" was not selected by the Refereed Paper Program Committee for the LISA 2007 conference.
Please acknowledge receipt of this email to <email@example.com>.
We had 55 submissions and were only able to accept 22. I am enclosing some comments on your submission by members of the programme committee - I hope that you will find these helpful, and that you will consider submitting to LISA again in the future. I hope that you will be able to attend the conference in Dallas and I look forward to meeting you there - you may also like to consider submitting a poster or a WIPS presentation: http://www.usenix.org/events/lisa07/cfp/workshops.html.
Many thanks for your submission
I want to accept this paper but after careful consideration I find that I can't recommend that we do so. The author provides a great deal of information about the work, but in my opinion it is both the wrong information and there is not enough technical detail in the information provided. I find this disappointing because, as I said, I wanted to accept this paper.
The most notable lack is what role the author played in the work. Did he write the programs himself? Was he a member of the team that wrote the programs and, if so, what was his role in the team? What is also lacking is any detail about how the programs were written, what problems were encountered while implementing the programs, what design decisions had to be revised because of these problems, etc.?
Next, the author gives very few examples of how the work is used, nor does he include any information saying whether the programs have been used and where. Is this just a research effort? Are the programs being used to manage internal systems at the author's institution? If they programs are being used, for how long and under what circumstances? What changes (if
any) have been made or are planned based on feedback from actual users (system administrators, one presumes)?
The author provides no conclusion. What did the author learn from writing these programs? Did the programs actually provide a better solution to the original problem or did they turn out to be less useful than hoped?
The author mentions providing references in the final paper but those references are needed in this submission in order to judge the work. Has anything like this been done before? If so, why did the author implement his solution? What about the original work didn't suit the author's requirements? How heavily did the the author base his work on previous work? If nothing similar has been done before (an unlikely proposition, in my opinion), what other related works did the author consider when implementing his solution? Did the author look to any previous works to find problems to be avoided and, if so, how did the author avoid those problems.
Another small item that is missing is the availability of the work.
be given away? Provided under some sort of license? Sold? Integrated into another Microsoft product? Strictly speaking this isn't required in a submission but it would have been nice to have.
When all the missing bits are added up, this submission comes off as something much closer to a product whitepaper than a technical paper suitable for inclusion in a refereed journal. I find that disappointing because the problem the author set out to solve is indeed a significant one and the solution appears (on the surface, at least) to be both interesting and worthwhile.
I *strongly* encourage the author to resubmit this paper again next year but with many, many more technical details.
This paper describes PowerShell, a command line administrative facility ("shell") for the Window
(.NET) environment. While this work is potentially useful, the present paper has many problems that prevent it from being acceptable.
First of all, despite its length, there is relatively little specific information about what PowerShell actually does. The few example are very brief, simple (or even simplistic) and repetitious. From the information given, it is very hard to evalutate the work's scope or technical quality.
Secondly, the tone of the paper is often promotional rather than discursive, at times frenetically so. This detracts from its readability and often results in emotional effusion in place of technical substance.
Thirdly, the paper makes no reference to the VAST amount of previous work and other similar solutions for Windows. Its enabling assumption, that the choices for Windows administration are GUIs or writing programs, is simply false, and it is something that has been false for almost a decade. The number of Microsoft-provided and third party command line utilities and scripting infrastructures is legion.
Finally, the author does not seem to understand the Windows system administration communities. There are reasons most Windows tend to use VB for their scripting needs (as well as other automation solutions), many of which are cultural rather than technical. In addition, those Windows administrators coming from and/or involved in other OS environments also already have other solutions and do not really need PowerShell.
A very interesting paper providing an introduction to the powershell architecture and concepts. Whilst providing a good introduction to the subject as a general systems administrator I do feel the paper did not make it clear enough what the advantages of Powershell over a traditional vb/batch scripting solution were in a real world environment.
It may be an idea to include a worked example directly comparing powershell with a batch/vbs solution highlighting the advantages of powershell over the traditional solution in an "in the field" environment.
As you acknowledge references and discussion of related work need to be added.
4.3 and 7 - management model discussion does not seem as directly relevant to addressing the core problem identified at the start of the paper, ie. the paper could lose it and not be any less strong.
5.1 - not being fully .Net aware the example here needs a lot more explanation for me, eg. "structure the automation in terms of nouns and verbs" and "using the CmdNoun and CmdVerb attributes" meant little to me.
It was not clear from this how easy it would be to write a CmdLet to process, lets say, a web servers access/error log (normally basic test) instead for example.
188.8.131.52 and 6.3 - the discussion of the PowerShell language itself mentions but does not give any detail or examples of how CmdLets are actually written in this language
184.108.40.206 - could do with some elaboration and more explicit comparisons to justify the claims for improved security.
220.127.116.11 - the statement "Data can be output in graphical formats to leverage the PCs interaction and visualization capabilities" seems to be inconsistent with statement in 18.104.22.168 that "a CmdLet never directly communicates with the user" - I may just be misunderstanding the intent.
Overall I found this a very interesting paper and the approach taken by PowerShell to implement a long overdue overhaul of Windows (and Unix) command line management with GUI integration is to be welcomed.
Allright, finally I've managed to get access to it :) Thanks Marco.
I cant believe the ignorance of some people.
I too have a background in MSFT products and SUN products. Powershell dominiates in my mind, especially after I integrated it with GVIM. Powershell meets VI, how awesome is that?!
Hi Jeffrey ..
I'm sorry you didn't contact me directly if you had any queries about the LISA reviewing process and criteria - as the chair, I truly wanted to encourage more Microsoft-oriented contributions, and the problem in this case was not the subject of the paper, but its presentation for a LISA technical paper - if you read the published criteria for submissions, you will see that it is essential to address a number of issues - including comparisons with similar work and other things beyond just a description of what you have created. I would certainly have been open to criticism had I not adherred to these critera.
I think that your Powershell work is something that many people would be interested in (I heard an interesting talk at UKUUG) and there are several venues for this - a LISA BOF or poster, a login; article etc. I notice that the reviewers encouraged you to address some of the issues and perhaps resubmit next year (which I would be very glad to see).
I should say that we were fortunate to have a very experienced group of reviewers who have a *lot* of experience in both the practicalities of running very large sites, and the theory and development of systems to manage them. They volunteered their time to provide you with informal comments and feedback which you should have found useful - even if it was only to show you that people had a misconception of your work! I am sure that everyone was happy for their comments to be published, but doing this probably doesn't encourage the kind of frank feedback which most authors find particularly useful.
I do hope that this has clarified things and reassured people that we would definitely like to see more MS submssions in the future. If you (or anyone else) has any questions about the requirements or content of technical papers, then please feel free to emal me.
PS. I didn't personally participate in the reviewing of this paper which I left to people with more MS experience. Personally, I'd be quite interested in hearing how you think procedural scripting such as this fits in to a solution of the overall configuration problem (as described in say the SAGE system configuration booklet) ...
Thanks for leaving a thoughful comment. That is more thought than I put into my original post. :-) I don't have any big problems/issues with the LISA reviewing or criteria - it seems pretty reasonable and fair. I posted the feedback because I thought it was amusing on a couple of accounts. First is because anyone that knows me can agree with the "frenetic" comment. The others were amusing because they seemed so off the mark. That is understandable given that we are in the early days of PowerShell adoption. Most of the feedback was perfectly reasonable.
I am sorry Paul, but some of the comments seem to be from the perspective of people who have had their head in the sand for the past 5 years or so. I mean if your read the comments step by step, they make it as though this is just some research project or evaluation that was done.
Right out of the gate because JPS did not toot his horn about his credentials (being ONE of the lead architects) that knocked his credibility of the paper( Ex: "The most notable lack is what role the author played in the work. Did he write the programs himself? Was he a member of the team that wrote the programs and, if so, what was his role in the team?"). Also in speaking on the product the initial reference in the paper says this it not the final word on V1, but was the guiding light for it. So Yes this actualy is a product.
Then you get to comments like, "..the author does not seem to understand the Windows system administration communities. There are reasons most Windows tend to use VB for their scripting needs (as well as other automation solutions), many of which are cultural rather than technical. In addition, those Windows administrators coming from and/or involved in other OS environments also already have other solutions and do not really need PowerShell." Well to that I say that it is not indended for other platforms (though people are thinking fo cloning it). The specific space it was intended to solve was the administrative command line. It does and excellent job of doing that at the V1 level.
Now it does not at this time totally replace the existing tools, but it goes a long way to not needing them any more. I just got the feeling from some of the comments that they did not understand or do not know what PowerShell is and how it solves the current problems with the existing tools.
In some respects as they portrayed the paper being overly simplified, but the responses seemed to respond in kind.
Learning Power Shell is still driving me nuts. I just bought Payette's book. I am still having conceptual trouble bridging my command.exe, cmd.exe, BASH shell skills to powershell. At first it seemed much more intuitive than vbs scripts. Now I am just looking for a large collection of some simple one-liners that would be informative to a generic network administrator. I have know doubt that this is a great product however, perhaps it is just greater than I can easily comprehend at the moment. Maybe your paper should appeal more to the "Unix one-liner" community. Make sure they see the brilliant simple things you can do at a PS prompt that couldn't be done easily before in Windows. That's my two cents.