Slashdot Mirror
Microsoft's new CLI
An anonymous reader writes "Months ago a story ran regarding a job advert at Microsoft for a developer role to lead the work on a new generation of command line interface.
It has now been disclosed at the PDC and its name is MSH (Microsoft SHell), codenamed MONAD.
Here is the best description so far."
Take that, dirty Linux hippies! Take that, Thieving Macintosh Republicans!
Seriously, this is a wonderful thing. The shell has been one of the most lacking areas under Windows. I don't know how many times I've dropped into Cygwin or, before that, wasted time writing little C apps just to do basic bulk renaming operations and the likes.
Any word on whether they'll standardize the environment across all Windows products, or is this likely to be a server product only? Will this be the standard shell replacement, or will we now have command.com, cmd.exe and newthing.exe all living in parallel? I like choices, but Windows apps' ad hoc use of largeley-incompatible command.com and cmd.exe is already a source of pain.
Anyone who wants to do a bit of scripting on Windows has vbscript, javascript, perl, tcl/tk, and a plethora of other options.
This is going to be for headless servers. So you can ssh into a box and administer it remotely, or through a dumb terminal on a serial port, etc, etc..
There's no good reason your mailserver or each machine in your SQL Server farm needs a GUI.
I don't need no instructions to know how to rock!!!!
You get rated 'Insightful' for stating what OpenSource zealots hope. What if this shell actually knocks the socks off *sh?
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Do you think the average developer/manager at MS is dumber than your average OS participant? (This is not a tric.. Damn, I'm falling in myself..)
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
Linux is narrowing the gap to MS on the desktop (albeit slowly), and MS is narrowing the gap to Unix on eg. CLI, stability and security. Their software matures too, you know..
And then there's Apple. They make fun stuff. The are not afraid to invent, and they have the money to launch stuff that the OpenSource movement cannot. I don't quite know where to place them compared to OpenSource and MS.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
According to this page, it means "ultimate, indivisible unit". Interesting. :)
Z
2+2=5 for extremely large values of 2
You should read the article, if it actually lives up to everything he's talking about, that shell will in fact be pretty damn cool. Returning objects instead of text is a very neat idea, and I'm rather dreading facing the resident Microsoft Weenie on my hall if he catches wind of this..
Ratio of replies to old sig content : replies to actual post content > 0.5. Sig changed.
Funny eh. They're moving away from the registry back to services that run with conf files. And they're doing CLI only versions of their OSs for ease of remote configuration. Why not just port all their stuff to some free unix-like OS?
Get your own free personal location tracker
Actually, MONAD's type-awareness is a bad idea.
.NET object, Excel, whatever) is coding to
Consider ESR's tract on "how Unix Happened"; one
of his major (and correct) points is that you
should code a program NOT to talk to programs
that you already have, but to compatibly talk
to programs that HAVE NOT YET BEEN INVENTED.
In short, the coding to use a view (html, XML,
be back-compatible; that trick never works.
Multiple views now means that view maintenance
is now a N^2 problem to keep updating
your view translations as your programs evolve.
If a view translation falls behind, you now have
a big hole and your "shell" no longer does
what you need to do.
The _correct_ (and that is both an ideological
and engineering "correct") is to code the view
so that programs NOT YET CONCEIVED OF will still
be able to interoperate.
Axiom: piping anything but a single data format
is a bad idea.
Theorem: that lowest-level rep needs to be
compatible with simple programs and scripting
languages.
Conclusion: Monad's "type aware" piping is
a _bad_ idea.
I have to say that passing objects instead of streams of untyped bytes is neat. They may have screwed up the implementation, but having typed data passing in and out of command line tools would be awesome. Consider how cool it'd be if you had command line tools that spit out things like image, HTML, and music objects, etc. The shell could be smart enough to do smart things with the data; you could do a lot more on the normal command line, especially with a framebuffer. Also, apps could do input validation through type checking.
bash is "object'ish" - the thing is that the objects are called "programs", and they have "standard interfaces" called STDIN and STDOUT, etc...
as for a scripting language that is "objectish" - the closest thing isnt perl, its python...
... hi bingo
I thought 'NONADS' would be more descriptive.
The more microsoft morphs to become like linux, the less people will be inclined to throw away their money when they can get better functionality for free.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
But what you Microsoft people don't seem to understand is that Unix programs don't try to do everything by design. That's the Unix way of thinking - make smaller programs that do one main task and do it VERY WELL. Make them so they can be chained together to accomplish the bigger task.
And I'm not sure why this is really being debated, because, while I'm sure there are some Windows users who would be capable of effectively using this, the majority of them won't have a clue and won't bother. They complain about the command line now. Try adding all sorts of options that they'll have to remember.
While this sounds like a cool idea, I predict it will fade into the woodwork eventually.
Voltaire's criticism and satire of Leibniz was centered around "the best of all possible worlds" premise. It had very little, if anything, to do with Libnitz's monads.
Monads were, essentially, philosiphical atoms or molecules, albiet in a very metaphysical sense.
=Shreak
sadly, the opposite will be true. microsoft will sell it to the PHB's as the "best of both worlds" sorta thing. "keep your *nix geeks happy, and get real work done". crap like that. the real questions are can you run the system from the command line without the GUI, doe sthe GUI need to be loaded, can you remotely admin the machine, and will it play nice with others. those are the real questions. and i don't think that is in microsoft's strategy.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
You get rated 'Insightful' for stating what OpenSource zealots hope.
..." are just as speculative as "it probably won't." Secondly, when has MS ever been able to do something right on their first try?!?! It typically takes them 4 or 5 versions before things begin to acheive what they promised at the outset.
And you get rated 'Insightful' for stating what MS zealots hope.
What if this shell actually knocks the socks off *sh?
Lets be realistic, shall we? First of all, we're talking about what is essentially vaporware - things like "what if it
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Again, more vapour. And (again) what's MS's track record WRT security? I think the phrase "I'll believe it when I see it" sums this up appropriately.
You get rated 'Insightful' for stating what OpenSource zealots hope.
No, you get rated insightful for noting what MS has done in the past, and extrapolating the future of their next products based on that.
What if this shell actually knocks the socks off *sh?
That would be nice.
Keep in mind that this isn't a contest. MS has some very nice features burried in their software, and that's great. If MS Windows is ever a better platform choice than the free operating systems out there, I say great!
Woefully, it will still not be the platform I use. Why? Because I require the ability to fix bugs, apply patches on my own timetable (sometimes so fast that my vendor doesn't even know about them yet), and generally control my systems behavior.
Windows does not give me that.
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Security is not a "thing", it's a process. You don't ship your OS in a box with a "NOW WITH 20% MORE SECURITY" sticker and get more security. Longhorn's security will be poor as long as Microsoft continues to deprioritize it in favor of market share. I see no evidence that that has changed since the days of NT4.
Do you think the average developer/manager at MS is dumber than your average OS participant?
No, of course not. The problem is that the average MS employee is working on what a mid-level manager decided he would be working on, based on a company directive from on high that is motivated mostly by marketting. The reason Open Source software tends to be so much more USEFUL, even when it lacks many seemingly obvious features, is the fact that it's created, maintained and refined by those who need it the most. Shells don't seem all that well designed to developers and manageres... and that's because they're not for developers and managers. They're primarily use by sysadmins. A developer spends most of their time in an editor and/or using a rule-based system like make. The shell is just a tool for odd jobs, and many IDEs and feature-laden editors like emacs and vim pretty much suplant the need to use the shell 90% of the time. Sysadmins do not have that luxury.
Look at the MS shell. It is clearly being designed by developers for developers. The ability to manage excel data from the shell is not something that targets the needs of anyone who will have to use this shell routinely. Why is it there? That sort of thing scares me right off the bat, and tells me that this is not a sysadmin tool. Developers under Windows already have very nice tools in their IDEs to script all sorts of interaction with every part of the system that they need. Managers and desktop workers will never want/need a shell.
So ask yourself, which will be more useful: cygwin's bash port to Windows or msh? I can ssh into my Windows box and do admin today, and it requires no msh at all. Why do I need this beast?
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
No, you don't have to steal anything. First off, let's disabuse ourselves of the notion that anything in a shell is new. Shells have existed for decades that do everything msh is (so far) claiming to do. Most of them died a quick death for lack of use.
Next, the most valuable thing that MS has done in the last few years is to put pressure on other OSes to use features that were long available. For example, MS had a journaling fileysystem. Journaling was not new, it was just kind of hard to get right, and all of the implementations out there were fairly speical purpose or closed source. When MS demonstrated that an end-user OS could indeed benefit from having such a feature, dozens of porojects sprang up to take this long-implemented wheel and re-invent it for open source oses.
This sort of "test environment in the large" is very valuable, and MS has alway
Because Bill thought that VMS with a GUI would be better, and he doesn't want to lose face now.
Stick Men
psh never really seemed to take off but it let you basically enter a perl debugging session but execute shell commands also. This would basically trump anything msh could muster and also provide the entire universe of CPAN to the shell.
.NET API- that psh as I use it now does not, putting it in the position to *be* trumped by MSH rather than the other way around. Hell, MSH, with Perl.NET installed, could just as easily use all of that CPAN stuff as you could in vanilla psh.
.NET.
First- on OS X and Linux, I use psh. I love having a real language as my shell, no need to write little glueish C programs or look up really (more than perl sometimes!) obscure bash syntax. As far as Unix shells go, it's definately top shelf.
But I don't think it could trump MSH- unless we were talking about Perl.NET running psh on Windows or under other OSes using Mono. MSH has some serious strengths- like having access to everything going on in the computer, all of the
But, put psh on top of Perl.NET and we've got a really capable setup. Sign me up! Perhaps psh+mono could be the OSS/FS community's answer to MSH on
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
The magic of Unix's CLI lies in having lots of small, useful tools that play well together by talking text. It's brilliant and has a 3 decade track record.
Instead, Microsoft wants to have a massive Borg-like internal heap of objects and functions, and give you a text interface to it.
I'd much rather have lots of little, self-sufficient programs that essentially *are* the OS, rather than a new view into the OS.
Yes, having function-level access and object manipulation sounds really cool and orderly compared to the barbaric pipe & grep. But when all goes to h3ll, you'll wish you had text.
Text is universal. Objects and function calls change like the wind.
Does it hurt to hear them lying? Was this the only world you had?
in psh [...] works just fine.
...". And if you want to invoke other things from Perl, you can, obviously, use "open", "system", "`...`", and all those other facilities.
People who propose systems like MSH want to iterate over files and all that good stuff using object oriented scripting features. I'm saying: that turns out not to be very useful in practice. The fact that psh happens to be able to emulate sh behavior is completely besides the point.
It is 'conception' that is basically the problem - you don't know what it is like to use a real scripting language from the command line so its strengths are not apparent.
Sure I do: I have used psh at times, and I have used Smalltalk and Lisp, which are much better at this kind of integration and scripting than even Perl or MSH.
But that kind of design of interactive shells, something that integrates full programming, has always lost out in the real world.
In fact, UNIX has a much better answer: rather than trying to force everything into the same address space, it provides facilities (environment variables, etc.) that let software written in multiple different "little languages" co-exist as if they were all part of a single, unified scripting environment.
If you want to use Perl in a script or pipe, just say "... | perl -e '...' |
The UNIX approach is great; you should give it a try sometimes. MSH and psh, on the other hand, are Microsoft-thinking: obvious, gimmicky, and not all that good in the end.
Read down the article for details on how they can now do things like mount the registry as a drive and walk it like a filesystem. Yegads!
Finally, they're starting to appreciate the unified namespace that unix has been offering since the seventies.
They're only doing it on a way to high level.
Everything should look like a file and be accessible through the same API. read(), write(), ioctl() and select() are all you fundamentally need to do with anything. Inband I/O, out of band I/O, and wait for event. What more could you want to do with any object whatsoever?
The unix model is so beautiful, too bad it isn't taken far enough, even in unix.
Microsoft has an especially long way to go if they're trying to unify all the different system objects on such a high level (the shell).
All generalizations are false, including this one. (Mark Twain)