No PowerShell at LISA

No PowerShell at LISA

  • Comments 21

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

 

Enjoy.

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 <lisa07chair@usenix.org>.

 

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

 

Paul Anderson

 

 

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?

If the

latter, why?

 

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.

Will it

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.

 

6.2.1.3 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

 

6.2.1.7 - could do with some elaboration and more explicit comparisons to justify the claims for improved security.

 

6.2.1.8 - the statement "Data can be output in graphical formats to leverage the PCs interaction and visualization capabilities" seems to be inconsistent with statement in 6.2.1.1 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.

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • Thanks for posting the comments. They are a great read.

    I remember an author took the table of contents and intro of previous Best Sellers submitted them to today's publishers and watched all the rejections come in.

  • I encourage you to read the feedback again later. As the author and architect you may not have the emotional distance, yet, to see the value that there may be in the reviewers comments.

    As a monad fan boy since the earliest beta, I'm disappointed too. But, Microsoft has a poor track record with the sysadmin community.

    MS gets developers, gets the corner offices, and its products are run on raised floors and in closets by people who are passionate about the MS product they maintain.

    Still, in my own opinion, MS does a terrible job communicating clearly with the sysadmin community. This is especially true for large enterprise systems.

    That is and will continue to change for the better. Heck, PowerShell is an example of success in that space. Still, you must admit that it wouldn't have been easy to deliver from MS if you hadn't sold a bunch of internal developers on it's usefulness.

  • I get the sense that the paper reviewers don't actually manage any systems, large or small in size. PowerShell will revolutionize the way Windows systems are managed and I'm pretty sure that the "Windows systems administration communities" already know this. Today, the reviewers comments seem ridiculous, but 1-2 years from now, they're going to seem ludicrous.

  • Hi Jeffery,

    Did you feel like you were back in English class?

    This line, "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." made me want to vomit on the floor.

    PowerShell is a fantastic tool and an amazing time saver.  The way things are going we are going to "need" it even more in the future then we "need" it now.

    Thanks for putting up with foolishness like this response in getting the word out.  I guess some people just don't get it.

    Jonathan Walz

  • I like this one:

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

    I'm pretty sure Exchange Server 2007 is being used outside Microsoft. ;)

  • Nil desperandum Jeffrey ! Bak to Skul again ...

    Your ( Jeff Bruce Jim George et al) frenetic enthusiasm is the best thing out of MS for years. Many thanks for PowerShell.

    Regards from Aotearoa.

  • This comment is going to be painful to the author of the post. Please turn off your endocrinal system before reading further.

    Ready?

    Let me being with the good:

    PowerShell is a better shell than anything else I've used. Huge thumbs up on the architecture.

    Now the bad:

    You guys are, on average, bad communicators. The samples you provide are poor and don't provide much insight into how things really work. You're Petzolds when you should be Nathans.

    To make things worse, I have yet to find a good description of the internals. For traditional shells that's not really a problem because there are none - they just stream data through the pipeline. But you guys leave a host of questions unanswered.

    To give you an example, when I first started using PowerShell, I wanted to write a CmdLet for sucking data from our in-company data source. That in turn led me to a need to load various external assemblies, which led me to the question of how to unload these assemblies (is each CmdLet in its own AppDomain?) lest I create a leak. Did I learn that from the samples? Noooo.

    So please find a dedicated person for providing good documentation.

    Dejan

    P.S.

    Let me kick you when you're down:

    Two biggest gripes about PowerShell:

    a) Not enough CmdLets. Out-Clipboard and Out-Notepad should be there from the start, not as a community extension. There's no 'tail' program for Christ's sake, and that's an elementary part of any Bash shell for anybody that deals with large log files.

    b) No support for remote work which is bread and butter of anybody administering a network. Sure WMI and a couple of other things have built-in support for remote access but that's a drop in the sea. Give me a SSH equivalent and the ability to integrate remote executed commands into the local pipeline.

    [Yes, I know about PowerShell Remoting but it doesn't support 'legacy' programs which are useful if you want to, say, oh, concatenate large binary files without waiting for the Sun to turn nova. And don't give me that 'legacy' bullshit, the Java guys tried that on me ten years ago and it didn't stick.]

  • Dejan - I appreciate your comments.  Let me ask some follow ups.  When you that that samples are poor - are you refering to those in our HELP our DOCS or the BLOG (or all of them)?

    Not enough cmdlets - guilty.  We had to make a bet here.  We bet that if we focused on the utilities and the language, that people would find it a really good investment of their time to generate cmdlets, providers and scripts because the environment gave them so much.  The downside of that bet is that we didn't spend as much time on the cmdlets that actually do work.  Frankly we struggled with this and I think we won't know whether we made the right decision or not for a couple of years.  We certainly are feeling the pain of the missing cmdlets but on the other hand, we get a lot of feedback about the great value developers get out of the environment.  They tell other developers who tell other developers and we'll see what the brings the ecosystem in a year or two.

    Remoting.  Yup.  That is our #1 complaint.  I think you'll like what we are cooking up and int he meantime there are multiple 3rd party implementations.  I didn't understand your comment about "legacy" programs.  Could you rephrase the problem?  

    Thanks Dejan!

    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

  • DEJAN

    I think some of the websites of MS regarding powershell, and the scriptcenter do have bad examples, and some of hte info you can search for isn't well communicated..

    But if you have ever seen Jeffery give a demo of powershell, i think you wouldn't say he is a bad communicator. In fact personally i think he is one of the better tech communicators, and the only one that i have seen gotten a standing ovatation at teched.

    Also bruce, the author of the language of powershell communicates very well about powershell in his book "powershell in action".. Maybe MS should get the rights to this book and put it on their web site ;) hint hint.

    Actually i think having 2 quality demo/videos by jeffery (beginner and intermediate) accessible form the main powershell page would go ALONG WAY in communicating clearly about powershell.

    Jeffery,

    on the monad manifesto, I think you'd really have to have written something from scratch , targetting the LISA folks directly, using their terminology, and introducing powershell through their worldview. Personally when i read it, i gleamed alot of cool tidbits, but also there were things in there that were obsolete as well as things that I got - only because i already knew the context.

    -Karl

  • There is a famous quote from our former German Prime Minister Konrad Adenauer that says it all:

    "We all live under the same sky, but we don't all have the same horizon"

  • Considering that the vast majority of papers accepted at such conferences are not earth shattering (to say the least) I am sure you have not lost sleep.  If you have, don't.  

    Time will speak to its merits.  No one, including myself and the reviewers of your submittal can give or take from that.

    I have written *nix shells for years, and PS now for 7 months.  I am very happy with the direction and distribution (looking forward to r emoting in Aspen?  Got a GA date on that?).

    It IS intuitive to me, and THAT is so cool, I just wish everyone saw the trade off between intuition/time to market versus nickels and dimes.

    Yes, MSFT took until 2006-2007 to get a shell I will champion, but I live in the now.

    You are more that OK in my book (and other I presume).

    L

  • Jeffrey:

    First, I apologize for the tone of my original comment. It was late at night and my fuse was short. I criticize you because I love you. :)

    Now let me answer your questions:

    1. Poor Samples:

    I was referring mostly to the TechNet Script Center Samples, which are the first samples one comes upon from the PowerShell download page. Those miss the mark. Here's what I think you should provide instead:

    - A single page that shows off the .NET objects pipeline and gives the reader an idea of how PowerShell works

    - A cmd.exe command equivalence page that explains how _each_ DOS command, with all its switches, can be rewritten as a PowerShell equivalent

    - A unix toolset equivalence page that shows how PowerShell commands can be used to perform tasks one usually performs using Bash

    - A Windows administration page that shows how tasks that are usually executed through the GUI can be executed using PowerShell. That should cover both your plain vanilla XP/Vista boxes and Windows Server boxes.

    - A page describing the command syntax and scripts

    - A page that explains the pipeline and writing CmdLets in depth

    This blog is fine, but it's more of a "here's the cool thing I did with PowerShell" type of blog when what's needed is a "publishing on MSDN is a pain the ass so I'll provide the missing content here" type of blog.

    2. Not enough CmdLets:

    If you want to harness the community that's fine, but you are not working towards that goal. I have no idea what your lawyer situation is, but a comunity needs a central repository (Perl's CPAN) and maintainers that will review submitted code (what Linus does for the Linux kernel). And Microsoft needs to stand behind the effort.

    Also, your default security model is FUBAR if your goal is for people to share CmdLets and scripts. I'd argue that it's FUBAR anyway but that's another discussion.

    3. Remoting

    I'm glad you are aware of the problem.

    My comment about the word 'legacy' was referring to the docs for PSHost.NotifyBeginApplication. PowerShell Remoting doesn't support them as shown here:

    http://www.codeplex.com/powershellremoting/Thread/View.aspx?ThreadId=11674

    The problem is hard because Windows command line doesn't give you a terminal emulation but instead lets apps poke around the console. But I wrote a remote console proof of concept program a couple of years ago so I know it's possible.

    --

    Apologies again for the tone of my original comment. I know you guys are working hard and have created a fantastic product.

    Dejan

    P.S. You also need to do something about the speed of the pipeline.

  • I was very excited when I started using PS, because it's design is revolutionary to me.

    Very big thanks for the new quality in scripting.

    But it needs much more work before it's usable. And maybe LISA reviewers knew that ;)

    At first, you have to add poor performance to the Dejan's list. An example: I have a directory in which almost 200.000 files are created during a week by our ERP software. I was unable to efficiently select and remove files older than say 2 days with PS, which did "get-childitem" for several minutes (and other tools didn't). I don't remember how much memory did it swallow during that operation, but the time factor was sufficient to not use PS for that (very straightforward) purpose.

    Also, the Microsoft Connect, which is advertised method of providing PS feedback, doesn't contain Monad or PowerShell channel, and nobody answers e-mails. Pretty disappointing.

    And don't forget lack of '<' operator, poor and non systematic docs (there's hardly anything on exceptions, one has to dig through PS blogs), MTA threading, simple usage of event handlers and delegates.

    So IMHO PowerShell is not ready for enterprise deployment, maybe one can enjoy Space Invaders in it (http://ps1.soapyfrog.com/2007/01/02/space-invaders/) but that's not enough...

    I'm eager to see PowerShell 2.0 or whatever will be available.

  • @qq,

    PowerShell is on connect, just hard to find:

    https://connect.microsoft.com/site/sitehome.aspx?SiteID=99

    Seems to come and go from the list of available programs?

    @Dejan

    There's also:

    http://www.nsoftware.com/powershell

    Of course this is to connect *to* a PowerShell host...

  • Deja and qq - thanks for the details.  Those really help us prioritize our work.

    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

Page 1 of 2 (21 items) 12