Microsoft Next Generation Shell

An anonymous reader writes "I found this while searching for Perl Jobs in India: "The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the .NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."

Comments

Cygwin

[TheShadow]

I liked this the first time... when it was called Cygwin.

Re:Cygwin

[Anonymous Coward]

I liked this the first time... when it was called Cygwin.

For those whou don't know, Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: (1) A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. (2) A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. The Cygwin DLL works with all non-beta, non "release candidate", ix86 versions of Windows since Windows 95, with the exception of Windows CE.

Other thing which I'd suggest for anyone who is unfortunate enough to work under Microsoft Windows is Perl Power Tools: The Unix Reconstruction Project. The goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so. See the command list.

(I post as AC, because I'm not a Karma whore or anything like that.)

Re:Cygwin

[kraf]

Or MinGW if you don't want to rely on cygwin.dll.

Re:Cygwin

[dknj]

And microsoft had what to do with Cygwin? Seriously, if this is true then this is a good thing. Microsoft's scripting support has been lacking in a lot of ways ever since batch files.

-dk

Re:Cygwin

[Anonymous Coward]

Actually, Cygwin was developed by Cygnus, which was later gobbled up by Red Hat in the bubble days like Taco 'n' Hemos gobbling up Steve Jobs' dripping dick.

Re:Cygwin

[joeykiller]

How this can be considered Insightful beats me. Cygwin is an attempt to create a Unix emulation layer on Windows, while this apparently describes a fully flegded .Net integrated shell enviroment for Windows.

If this is true, this will (in my opinion) give Windows a tremendously powerful and coherent (i.e. a single understandable object model and class library) scripting and shell environment.

Say what you will about Cygwin - I like Cygwin a lot and use it daily - but it cannot be said to be coherent and consisting of well integrated parts.

Re:Cygwin

[Hentai]

Yeah, beautiful. And the first time some script kiddie figures out a buffer overflow in MicroSoft Outlook.NET that automatically runs the contents of an email attachment as a shell script, with said 'tremendously powerful and coherent' scripting and shell environment? Where said script kiddies don't even NEED to attach an .exe or .scr to the email, they can just embed some script as HTML comments in the message itself and pipe it to c:\winnt\system32\bash32.dll?

Every time Microsoft adds 'new powerful functionality' to its products, they're creating another exploit waiting to happen - until they fix their fundamental security model.

Let's hope to God .NET does runlength-checks on every single buffer read, and all .NET applications process their data at the lowest security level necessary to accomplish their task.

Re:Cygwin

[Doc Hopper]

I feel the need to respond to this, though the parent poster borders on flamebait.

You've provided a straw man argument in "Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format", and then attempt to categorize Eric S. Raymond and other UNIX or Cygwin users in this light. Cygwin is a tool, part of your arsenal of options in systems administration, and nothing more. The ability to obtain a UNIX-style directory listing is irrelevant compared to the ability to use the same script to accomplish the same thing regardless of software platform.

• "Using Cygwin under Windows is about as intelligent as using Microsoft command shell batch files on UNIX."

"Crock of Crap" is the first thing that comes to mind. Bash/tcsh/ksh/psh/etc. are so many light-years ahead of the MS-DOS command line scripting language when it comes to pure functionality and understandability that there it is difficult to know where to begin creating a valid comparison. Using a Bash shell under Cygwin to accomplish systems administration or automation duties on W32 is a sound, rational decision for reducing your time investment when supporting legacy platforms like Microsoft Windows 32-bit stuff. Using Cygwin to be able to provide environmental portability across platforms can be an intelligent, measured decision that can make sense both on a personal level as well as corporate decision-making.

• Many of the [legacy W32] command shell commands are designed to handle the way you do things in the Microsoft world ... using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.

You've made at least one incorrect assumption in this paragraph, and that is that using Cygwin makes DOS scripting unavailable. That is simply not true. Every facility of the MS-DOS command shell is available via a Bash shell in Cygwin. You can call external programs, or even use an MS-DOS batch program to launch a Bash shell. Cygwin gives you more power and flexibility to deal with all the things you wrote of, not less, and in a fully POSIX-compliant environment to boot. Using Cygwin is a giant step forward, that is, unless you are mind-locked into the legacy Microsoft Windows paradigm.

• the command shell being too incomplete... I also think this has been a good thing. [I can see] when shell scripting is at its end and jumps to coding a c binary to do something... Using shell scripting for real programming is like using Perl to write a database. It's just silly

You're entitled to your opinion. I'm a professional systems administrator, not a professional programmer, yet I've used Perl, Python, Bash, Cshell, Visual Basic, Excel scripting, MS-DOS command scripting, TCL, and other languages to automate certain tasks, make my job easier, or provide additional functionality where it was needed. Each tool has its place. I would not use Python to attempt to create a performance-critical OpenGL game, no more than I would use C to write a small daily cron job that mounts a filesystem, copies files, and unmounts the file system. Each tool has its strength. Cygwin and the programs available within that environment allow you to do more and go further with command scripting than MS-DOS command can possibly do. The "jumping off point" to an alternative language is very, very low on W32 MS-DOS scripting. Conversely, the "jumping off" point using a real, powerful command shell is quite high, and allows you to accomplish a great deal without having an enormous knowledge base of various programming languages.
The line between "scripting languages" and "programming languages" doesn't exist except at some arbitrary line which differs from programmer to programmer. Whatever language lets you get the job done in the shortest amount of time with the greatest degree of maintainability is probably what you want to pick. I can take my pick of Perl, Python, Bash/csh/ksh/whatever, Java, C, or anything in between to create what I need to get the project complete. Cygwin lets me have that additional flexibility, with the side benefit that I can use the superior command-line tools (grep/awk/sed/uniq, for instance) of a UNIX environment from Windows.

• They just learned a few words, then decided that the rest of the vocabulary wasn't needed.

The world always has a need for the simple, elegant, and practical. I would submit that your analogy is flawed. Allow me to share an analogy of my own. I recently had a choice of transportation to and from work, between daily riding the bus (an hour and fifteen-minute affair each way), or driving my car (45 minutes each way). Now, for many people, the choice is very obvious: Use the option that takes the least amount of time, driving the car. Given only the time data, many would come to the same conclusion, that driving the car takes 1.5 hours per day, while riding the bus takes 2.5 hours per day. This overly simplistic view of the question doesn't nearly cover all the facts, however. Here are some other factors that influence my decision:

• My car consumes a gallon of gas every 30 miles. Work is 40 miles away, so I will fill my 10-gallon tank roughly every 3-4 driving days, which will cost me somewhere a bit less than $20 each time
• My work provides me with a parking space ($40 value) or a bus pass ($40) every month.
• I have to pay for maintenance on my car.
• Time spent in the car is time that I cannot do something else: I must be exclusively driving

On balance, I decided to take the bus. The extra time consumed by the bus ride is time that I can sleep, work on my laptop, or read a book, whereas if I were driving that hour and a half would simply be lost to me.

How does this relate to the question? Well, I think your perspective on why people use Cygwin and other UNIX-like tools on non-UNIX operating systems is a bit skewed. The native tools may be elegant, powerful, and complete (which would be quite a debatable point on legacy W32 platforms IMHO), but the question lies in the balance. Would using native tools allow you to take that same programming effort and use the same script on another operating system? Would using native tools give those who follow you a proper perspective on how to maintain your programs once you've moved on? Would re-implementing something in a native tool, when one could otherwise just install Cygwin and run the same code that is running elsewhere in the enterprise successfully, be the best use of time and the company's dollars?
Regardless, when using Cygwin you are using the native tools available to you, but just substituting a powerful command shell and scripting language for the severely retarded one that is provided by default on W32. "When in Rome" (or some foreign operating system), they say, do as the Romans do. However, if doing so would compromise system integrity, maintainability, stability, or compatability, then I do whatever I need to to make the system work well, even if it requires using a tool that doesn't quite seem "native".

I do not use Cygwin much myself. I boot to Microsoft Windows to run legacy or gaming applications on my home system, and exclusively use GNU/Linux at work and home otherwise. I do a lot of work with legacy W32 systems at work and am a big fan of "use the right tool for the job", which, to date, has not included installing Cygwin on those machines. However, it has included installing Perl, Python, or TCL as the situation requires; if Cygwin were needed to make something work, I'd use it as just another tool in my box.

Get with the program! When running any OS, use the best tool for the job!

(As a final note, I think it's very interesting that Microsoft has finally acknowledge that their shell is horribly crippled and are working to fix that. I'm not anti-Microsoft, I am pro-GNU/Linux, and am very excited to see them finally addressing the massive wart of a lack of decent systems automation on W32 platforms.)

Re:Cygwin

[Jeremiah Cornelius]

O.K., The DOS shell syntax SUCKS. No ifs, ands, buts or apollogies. It's not much better than CPM/80 with directory recursion and crude pipes. And you think there are some people resistant to change!

Crap work in all Windows shell environments:
* Device access. What the hell IS the device name of the "2nd LAN Adaptor"? If it's PCMCIA? If there is also a 3rd? How does anyone ping from a specific interface, or sniff traffic from one?
* Equivalent of /dev/null. Essential for any shell-like environment.
* Variable handling, shell expansion/substitution, internal functions, library functions. Some of these shortcomings can be addressed by building your own extensive solutions, as .bat files. Sad. Even 4DOS and other CMD replacements miss this boat. Elementary parts of POSIX/ksh implementations. This is why MS systems shipped with BASIC for years.
* Brain-dead logical operations: conditional looping, etc. Chokes when variables are substituted in function-like context, etc.
* One word: MATH

I could go on in detail, but It's more painful than writing system scripts in csh...

Re:Cygwin

[TheShadow]

They have everything to do with Cygwin. If they had provided halfway decent shell and command line tools there would have been little reason for Cygwin to be created.

Re:Cygwin

[jonathanclark]

I also built a single-EXE version of cygwin that has many of the utilities that fits on a floppy. It doesn't require any installation, or rely on external DLLs, and always stays as a single EXE file (nothing extract to disk). So it's a nice little file to have sitting around.

http://thinstall.com/docs/index.php?sp=unix_tools. html

Re:Cygwin

[Billly Gates]

I think what he was refering too was that most win32 apps do not have the "everything is a file" paraidiagm that dominates the unix world.

I am not an administrator or a professional coder so my opinion comes with a grain of salt. It seems to me that all of the unix tools like awk, sed, and grep are powerfull because everything is a file and that is not true in Windows. You can manipulate everything that even includes the peripherals and processes! They too are files which really impressed me. I think Microsoft is taking a step in the right direction with developing a more advanced shell but all of these features are useless if you can not edit text or xml files and only manipulate objects. %99 of win-32 apps only use the cryptic registry for information settings so you are stuck using gui tools unless you know what you are doing.

I read a similiar comment here about someone making the opposite arguement that using COM via vbscript to manipulate and send information to objects is more powerfull. You can do things like tell excell to open a particular spreadsheet and do these things to it. I do not know the answer to this but I see both arguements.

All I know is Microsoft is abandoning the metabase in IIS and making everything xml including IIS. I believe they talked to unix developers and admins and asked them why they like Unix so much. Now Microsoft must find a way to entice developers to make all of there programs write there settings in files rather then using the cryptic registry. Perhaps Microsoft could add some features to .NET to automatically create xml config files whenever a programmer decides to compile something.

Re:Cygwin

[Jeremiah Cornelius]

Uh, there's the NUL reserved word...

But yeah, the Win32 command line is shocking. Try piping even two Borland GREP's together.

The NUL keyword doesn't function as a "Blackhole" for any kind of operation, like a *n?x device.

The culprit here is the same as your pipe. I/O is not mapped to files - but to generally arbitrary memory locations. Pipes work because of the stdout/stdin relationship to /dev/console, or equivalent. The CMD.EXE or COMMAND.COM "device" is con. Where the hell is con? Fire up another prompt, it's in a different memory location. If there were some other useful unifying namespace in Windows systems instead of the filesystem, this could work. Unfortunately - there is not.

My understanding is that MS is trying to provide a clearing-house for accessing pluggable namespaces in .NET, via the clr. This is the worst of all! Particularly when the Win32 API is being promoted as a 'namespace' in this context.

Re:Cygwin

[0x0d0a]

Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format.

I certainly prefer ls's default format to dir's default format, yes.

Re:Cygwin

[0x0d0a]

Uh, there's the NUL reserved word...

Yes, but the difference is that

cat NUL/NUL doesn't bluescreen a UNIX box like it does an unpatched 9X box. :-)

Re:Cygwin

[Jeremiah Cornelius]

/dev/null = NUL
eg:
echo "Do some research" > NUL

My criticism of the MS NUL vs /dev/null is as a general purpose utility, not merely as a feature to absorb console echo.

Link a cookies.txt file to the NUL keyword, during script runtime, while piping, looping, etc.

Feel free to research this. I can't bother.

Re:Cygwin

[miu]

Microsoft's scripting support has been lacking in a lot of ways ever since batch files.

This has got to be the blandest understatements I have ever seen on slashdot.

I use Windows for many things and think Visual Studio is an excellent development environment. It is what emacs should have been. That said, I've never really felt at home in Windows because of the awful, dane-bramaged, evil, despicable, cluster that is the Windows console command shell.

Cygwin makes it a little better, but does not interoperate with Windows in many ways that you would expect. eg: shortcuts are not symlinks, endline conventions are not handled invisbly, drag and drop not fully supported, cut and paste still limited by native console libraries, etc.

Python also goes a long way to automating tasks like dumping excel spreadsheets to csv format, find and replacing a name in a large number of documents, etc.

I hope Microsoft can deliver all this with a single set of tools. I'll certainly use it.

Re:Cygwin

[knighten]

RedHat deserves praise and support for Cygwin, but describing Cywin as "a UNIX environment, developed by Red Hat, for Windows." is misleading on several fronts. First it is primarily a port of the GNU toolset to Windows, it isn't UNIX (which is still a trademark), and it was developed by Cygnus well before they were bought by Red Hat.

Re:Cygwin

[Doc Hopper]

I'd regard Windows Services for UNIX as a competitor to Cygwin. Both are native tools for doing what you want to do, but doing it in slightly different ways. It seems kind of like choosing between Microsoft Office and OpenOffice.org.

Going to go download it, though, and see how different it is from when I evaluated it three years ago. Thanks for the link.

Re:Cygwin

[Alex Belits]

This is just a troll. .NET apps run in a configurable security sandbox, and use runtime type checking. How often does your Java code suffer from a buffer overrun?

Who checks the checkers?

.

Re:Cygwin

[0x0d0a]

Or UnixUtils (mingw ports of lots of posix utils...without the performance and dependency issues of cygwin).

Re:Cygwin

[Jeremiah Cornelius]

Tom,

You make a great case against csh as a system shell.

I hope you didn't read my post as an endorsement of the practice! :-)

Re:Cygwin

[Yunzil]

Time spent in the car is time that I cannot do something else: I must be exclusively driving

You obviously don't live in the Washington, DC area.

Re:Cygwin

[aoeuid]

Well whatever, but if you can't symlink cookies.txt , for example, to this windows null device, then it doesn't have equivalent functionality.

Re:Cygwin

[aoeuid]

You stated that the Windows NUL device was equivalent in functionality to the Unix /dev/null. And now I am showing you that no, it doesn't necessarily provide the same functionality.

And they can call it. . .

[kfg]

bashWinXP

KFG

Re:And they can call it. . .

[moncyb]

How about C:<enter>### ;-)

Re:And they can call it. . .

[robbyjo]

Fortunately, they won't backport that to WinME. Otherwise it would be called "bashme".

Re:And they can call it. . .

[pythorlh]

More like Wish...
And it's so damn appropriate, too. ;)

Re:And they can call it. . .

[ninewands]

Soory, that name's taken ... by Tcl/Tk.

Re:And they can call it. . .

[Alsee]

DOS XP

-

Re:And they can call it. . .

[mbogosian]

And they can call it...bashWinXP

No, that would never happen. It would be Microsoft bash or mash or something. After all, they invented HTML too.

Re:And they can call it. . .

[Tumbleweed]

No way, it'll be the C# Shell. (see sharp shell)

As opposed to the previous c:\DOS shell.

Shell, sharp, shell!

Maybe they'll do a Visual C Shell?

wonder what this means

[neildogg]

"Candidates should have Windows NT or Windows 2000 system programming experience, development experience with object-oriented languages and design methodologies as well as with scripting and shell languages like PERL, Python and Bash. Candidates should have at least 2-5 years experience (based on level interviewing for) in high technology, preferably delivering products for both Windows and non-Windows operating systems."

I guess Microsoft has viewed users of other platforms as important before (recruiting of Palm developers) but this seems like a direct call to Unix (mostly Linux) developers to make Windows shell exactly like other existing technology. Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Re:wonder what this means

[GutBomb]

now i know this is microsoft and they have a ntendancy to copy other's work but give them the benefit of the doubt. Perhaps they want someone with experience with Bash, Python and Perl so they simply have someone that understands what a shell is and ho0w one works, not neccisarily to make their shell exactly like bash.

Re:wonder what this means

[IamTheRealMike]

Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Actually, the next version of IIS has dropped the binary metabase and has replaced it with XML config files, so IIS can be administered by hand, just like Apache (but with a pretty GUI if you want one). Maybe as part of this next-gen shell they'll introduce a good command line text editor.

This sounds to me very much like Microsoft is having a good hard look at what Linux/open source does well, and copying it. Fair game - we've copied them plenty, and are continuing to do so. We could well find that Windows moves on a lot thanks to the competition offered by Linux: will we be able to keep up, and keep pushing things forward to? I think so. I hope so. But the era of kicking Windows for being unstable is already over, insecure looks on its way out (I read coders can get fired now for writing insecure code at redmond), and soon traditional UNIX strongholds like good remote administration may no longer be unique either.

We have our own stupid problems to fix too of course. Lack of a decent object model? Lack of binary portability? That one is killing us at the moment, and there is no good solution (as I'm finding out as part of my project). We really really don't want to have to setup build farms (a binary for every distro version), that'd suck. But it seems the very nature of Linux itself dictates it. Now Windows is moving to .NET they are tidying up a lot of these problems, while we're still playing catchup.

It's certainly going to get interesting soon. Microsoft have sort of woken up.

Re:wonder what this means

[Zapman]

That's one of the most insightful comments I've read on /.

Your point about binary compatability on linux is almost painfully valid at times.[1] It'd get a LOT easier if glibc/gcc would finally decide to stop breaking backwards compatability.

There is a work around (most of the time). You could distribute a statically compiled binary. It's not pretty, and it's not perfect, but it will solve a lot of the problems.

[1] Ever had a debian firewall on a pentium/60 with no gcc, and redhat behind that, and no other available linux boxen to compile things on? Updating the kernel on that firewall was a royal pain.

Re:wonder what this means

[IamTheRealMike]

Your point about binary compatability on linux is almost painfully valid at times.[1] It'd get a LOT easier if glibc/gcc would finally decide to stop breaking backwards compatability.

The problem I was thinking about wasn't actually related to glibc (which actually doesn't break binary compatability at all, it uses symbol versioning) or gcc (which was only for C++, and hopefully will not break binary compatability again now it's standardised).

I'm mainly thinking of the problem that the link tree always has to be identical to the system a binary was compiled on. For instance, if you have a frozen bubble game, which was compiled against libpng3 and libSDL, then you run it on a distro where libSDL was compiled against libpng2, then two ABI incompatible versions of libpng will be linked into the same address space and you'll get an instant segfault.

Well, those sort of symbol collisions can be 95% resolved by either making everybody use symbol versioning (hard) or applying some patches to the linker and ld (easy, but libc maintainers won't do it). But you still have problems if for instance frozen-bubble passes structs between the 2 versions of the library.

I think the real solution in the long run is for people to stop using C for writing libs and apps. Higher level langauges that can do reflectivity (python/ruby/java/.net/in fact, anything other than C/C++ basically) don't tend to suffer ABI problems in quite the same way, and we'd all have higher productivity anyway.

But there are problems with trying to write everything in such langauges. I've got ideas for how to solve them too, but can only tackle one thing at a time, and pulling people away from C is going to be very hard. MS can sort of do it through sheer marketing will and forcing Windows in that direction, even for them introducing .NET will take years. We can't do that though, it's not so easy.

Re:wonder what this means

[joto]

I would be much happier if the "new shell" project was started and implemented in the Unix/Linux world. Instead, the sh in SunOS 5.8 still diplays ^[[A when I try to recall previous commands by up arrow (of course, I can immediately type in "zsh" and be in a more friendly environment, but such workarounds should not be needed),

Uh? You want sh to be zsh? Why insist on typing sh then? Why would you break script-compatibility by replasing sh with something that is not sh? Why do you think yet another new shell will fix that?

and I would be happy not to have to deal with the details of PATH and environment in various Linux shells.

Uh, why are you dealing with them now? It should be set up by the distribution for you. I can't remember having fiddled much more with environment variables under linux than I have under DOS (except when I'm developing of course, but I hope it's not that you are complaining about?

Open source indeed needs a more open minded and innovative attitude.

Well, I didn't even know open source had an attitude. It's a concept, a subset of all possible software-licenses and associated software. Do you seriously believe that everyone who uses/publishes/writes/fixes/documents/etc open source software are close-minded and never innovative?

Re:wonder what this means

[_Sprocket_]

When was the last time you had to mess with environment variables on a Windows 2000/XP machine to get a windows program running?

Just the other week. I installed GnuPG on a Win2K machine and had to tweak my path environment variable (or its equivilant) to find it no matter what directory I was in. Granted - I didn't install GnuPG using an installer. And I have the binaries where Win2K doesn't expect.

Its much the same for any Unix/unix-like environment I've used. Usually I don't have to mess with my path. Unless I'm doing something unexpected.

It seems that this point is more due to inexperience than a design flaw.

Re:wonder what this means

[_Sprocket_]

Instead, the sh in SunOS 5.8 still diplays ^[[A when I try to recall previous commands by up arrow (of course, I can immediately type in "zsh" and be in a more friendly environment, but such workarounds should not be needed),

Get with your sysadmin. Ask him to set your default shell to your current favorite (apparently zsh). Voila, you're set.

I find the Unix shell rather interesting. It enables various users to run environments that appeal to them without forcing "defaults" on the entire user base. In addition, by building scripts against the standard Bourne Shell you have a pretty good chance of those scripts working on any Unix platform. And you can do this even if you prefer the oddities of, say, C Shell or the Korn Shell.

Re:wonder what this means

[shaitand]

When a high level language is as efficient as C or more so then I'll start using it. Being able to run on the phenominal resources of a 486 w/8mb ram should come before rapid developement. You see there is this magic thing that tends to happen when you aim for hardware well well below current standards... the software runs extremely rapidly on faster hardware. Hell I'd use Assembler if it was portable.

Re:wonder what this means

[Sentry21]

Maybe as part of this next-gen shell they'll introduce a good command line text editor.

What do you mean 'maybe'? Windows XP Pro already has edlin.exe, what more do you really need?

(Sometimes, backwards compatibility goes too far.)

--Dan

Re:wonder what this means

[shaitand]

Yes microsoft is having a look, they are doing the same thing they've always done. Playing catchup with the *nix world. They did it with multi-tasking, multi-user. They played catchup with Mac on a gui system, now they are playing catchup on the command line. What major component of the windows system was microsoft's innovation again??? The problem is, after they take *nix concepts and make them their own, proclaiming their great innovation, will those concepts be compatible with those they stole them from? or will they "embrace and extend( in proprietary insecure manner)" like everything else they steal?

I strongly disagree, the era of kicking windows for being unstable is hardly over, it is still extremely unstable. But it is better. The biggest thing making a windows system unstable is lack of true protected memory space. Actually implementing this would mean program startup would appear to slow down and microsoft won't have that in exchange for stability, an app will always be able to hit the system. The system will always be insecure because it does implement kernel level handling of process security. Instead it relies on layers laid atop the kernel for security and every user is admin as far as the windows kernel is concerned.

Remote administration?? In terms of the command line absolutely, in terms of gui? Citrix beats *nix solutions by conquering the bandwidth barrier, that one is beaten.

As for our own stupid problems... yup we've got them, there is always room for improvement. The UI sucks for home users, and there is no excuse for it either. Lack of games, and those that do run perform for sh*t. Software installation is a big issue as well as the binary compatibility you spoke of. I had thoughts of an extremely simple system at least for source compilation and package managment utilities. This would essentially consist of a simple text in a location written in stone of a name written in stone, a centralized online non-profit that gives ID numbers to programs and libraries, and sub ID's for various versions, when a program is installed it writes it's ID, subID, and install location to the text. When another program is installed that needs to find if a certain library of version X or higher is installed, it checks the text, the subID, and location so it can find where it exists on this system. Obviously this would rely on donated resources to run the server that generates the ID's and of distributions adopting the standard, but this would sit below the package manager, so the package manager would need to implement this as well (and could keeps it own database as well).

Re:wonder what this means

[Doc Hopper]

If I recall correctly (and my memory may be flawed, my copy of MS-DOS 6.22 has been sitting on this shelf next to me no small number of years), the environment space on MS-DOS was quite limited, so your %PATH%, by necessity, had to be somewhat small. The work-around in Windows 3.1, continuing to this day in Windows XP, is to have desktop "shortcuts" to the applications you use.

Until a distribution is developed where the only planned interaction with the underlying operating system for the casual user is through a GUI, we'll probably continue to have the pain we have now with PATH and other environment variables. I've often thought it would be fun to develop a completely GNU/Linux distribution that was completely pain-free for casual users, but it looks like Xandros, Lindows, and XPde are making admirable progress in that arena.

I expect that arriving at some home-directory standard for installing software that does not run as the root user will be the eventual solution. Something like "$HOME/opt/packagename", with automatic desktop shortcut creation in Gnome/KDE (Crossover Office and Crossover Plugin both do this admirably well at present).

Re:wonder what this means

[0x0d0a]

(of course, I can immediately type in "zsh" and be in a more friendly environment, but such workarounds should not be needed)

Try "chsh -s zsh [username]".

Zsh is a nice shell, but the whole sh syntax is *still* over-convoluted. I could go for a new shell system, frankly. Doesn't mean that MS is gonna do it, but I've looked at alternatives like rc, and there really isn't anything as usable but a bit more modern than zsh.

Re:wonder what this means

[0x0d0a]

Lack of games, and those that do run perform for sh*t.

You're certainly right about the lack, but on my system, which has run both Linux and NT 4.0, Starcraft and Alpha Centauri run more smoothly in (Starcraft in WINE, obviously) than NT 4.0 (and doesn't hit the never-fixed "looping sound" bug that NT's DirectSound implementation has), Quake 2 runs more smoothly in Windows, and Quake 3 runs more smoothly in Linux.

Re:wonder what this means

[Malcontent]

"This sounds to me very much like Microsoft is having a good hard look at what Linux/open source does well, and copying it. "

Yes that's always been what MS means when they say "innovation" it means somebody else thought it up and we stole the idea.

"We could well find that Windows moves on a lot thanks to the competition offered by Linux:"

This more then anything else defines the most inmportant reason why open source is critical to the future of computing. Without open source MS would not improve their OS and without open source to copy they would not have the means to improve their OS.

"But the era of kicking Windows for being unstable is already over, insecure looks on its way out (I read coders can get fired now for writing insecure code at redmond), and soon traditional UNIX strongholds like good remote administration may no longer be unique either."

Windows still has stability and security problems (IE exploits are still coming out at at least once a month). Windows already has terminal server for remote mgmt. I really don't see what a shell gets them. Maybe as a result of all this though we can now start calling Microsoft communists and refer to them as cancer. That would be good outcome don't you think.

"Now Windows is moving to .NET they are tidying up a lot of these problems, while we're still playing catchup."

They'll abandon .NET in two years don't worry. MS does not keep new buzzwords very long. As soon as we know what .NET means they'll shelve it.

Re:wonder what this means

[joto]

It seems I was mighty unclear.

Perhaps :-)

I wanted to say that the existing Unix/Linux shells (1) are mutually incompatible (2) are often a pain to program (bash, uh) and use, (3) and some big vendors still keep the oldest and least friendly.

(1) Yes, they are. (Personally, I use bash for exactly that reason, since it keeps me from remembering to many syntaxes as bash is essentially sh++) (2) Well, I think bash is pretty ok. But of course, there could be lots of room for improvement. And yes, since you mentioned it, PATH (and CLASSPATH, LD_LIBRARY_PATH, etc) being colon-separated instead of newline separated makes it harder to manipulate it without a few nifty aliases. They should be standard and builtin to make things easier. (3) Well, trading backwards compatibility with user-friendliness is not always so easy. But since most shell-scripts start with #!/bin/sh anyway, it would make sense to give the users a more friendly shell by default.

Why do you think yet another new shell will fix that?

It could, if well designed.

And as we both know, there are plenty of alternatives already. In particular, the following shells are all "better" than sh for end-users: tcsh, ksh, bash, zsh, es, and tclsh. It's not obvious that a new shell would improve the situation more than just add to the confusion.

But, for example, some aspects of the CLI could benefit a lot from a insightfull redisign.

I most definitely agree. But designing a "better shell" is very hard, and most people fail (look at the (lack of) success of es for example). The tradeoffs between terseness (for command-line use), regularity (for scripting), familiarity (to get anyone to use it at all), simplicity (to be useful for newcomers), and expressivity (to be the best tool for experts) makes it as much an experiment in psychology as in programming.

I doubt that we will ever reach shell-nirvana in unix (or any other place for that matter, but windows has a large advantage here, one of the things that holds us back, is that we still care about being able to run the shell over telnet to a teletype, but in windows they will probably make the default user experience to be more like e.g. emacs interaction mode, nice menus and all... By the way, have you ever looked at XMLterm? It's nice, and certainly innovative :-) Why not combine it with XML shell to get away from the pipe-filter on characters/lines only paradigm?).

The current unix-shells are the result of decades of stepwise improvements on a really good idea (at the time), and continues to be so much more useful than any of their alternatives that it's going to be hard to penetrate the "market"...

Not that it wouldn't be worth it though :-)

Re:wonder what this means

[joto]

If you use .deb or .rpm software that's OK. If you use say Portland Group FORTRAN (ugh) you have to tweak your environment.

Ahh, so you were thinking about programming (wink, wink)? But seriously, you should probably blame the Portland group instead of the shell here. It's not like they couldn't have made a .dpgk or .rpm out of it.

And even if they couldn't do that, it's not like they couldn't write some shell-scripts that could be put somewhere in your path to invoke the compiler (and set up the environment first). They could even write a small installer that modified those scripts depending on where you installed the compiler. For an excellent example of this, look at suns JDK.

Re:wonder what this means

[Malcontent]

"Typically, the confusion with the .NET buzzword is because microsoft marketing department have named everything product.NET.. what a stupid idea. Speaking of stupid idea's, passport wa... ahh forget it."

What are you saying exactly here? Isn't the MS marketing dept a part of MS? Don't they speak for MS? You are talking as if it some outside alien enttity. .NET is a buzzword. I know so because MS tells me that. Not even MS knows what it is and by the time we all figure it out they will have abandoned it. Just like they abandoned COM/DCOM/COM+ in favor of .NET. Two years from now there will be a new buzzword.

Re:wonder what this means

[Keeper]

The reason why the .NET platform is very important for Microsoft (and for that matter, those who write software which words in a Windows enviornment) will become very apparent when 64bit CPUs from both AMD and Intel hit the market.

While AMD's 64bit chip will be backwards compatible with 32bit x86 CPUs on an instruciton level, the 64bit instructions will not be compatible with Intels version. And Intel's 64bit CPU is deathly slow emulating 32bit code. So a developer "needs" to write at least 2 versions (an Intel 64bit version, and an x86 32bit version) and probably a 64bit AMD version if their stuff ever catches on.

That sucks. Sure, you might be able to just flip a few switches on the compiler and make a second binary, but that sucks. Or have the compiler run different bits of code depending on what CPU it's running with (similar to how SSE/3dnow stuff is done) but that sucks too. And when the NEXT platform comes out, you've got to recompile code again. And that really sucks. .NET is "Java the Microsoft way". It isn't meant to be platform and OS independant the way Java is. It's meant to be platform independant and OS dependant. And while this kind of utility isn't very apparent right now, nor do I know if this is the reason why MS decided to compile binaries in a manner similar to java, I have a feeling that it will be very significant in Microsoft's future.

Re:wonder what this means

[doug363]

I strongly disagree, the era of kicking windows for being unstable is hardly over, it is still extremely unstable. But it is better. The biggest thing making a windows system unstable is lack of true protected memory space. Actually implementing this would mean program startup would appear to slow down and microsoft won't have that in exchange for stability, an app will always be able to hit the system. The system will always be insecure because it does implement kernel level handling of process security. Instead it relies on layers laid atop the kernel for security and every user is admin as far as the windows kernel is concerned.

Well, Windows (NT, not 9x) does implement correct memory protection. I've done quite a bit of programming, and never had the computer crash because of my program overwriting memory where it shouldn't have. You can't read other programs' address spaces unless they deliberately share memory.

The Windows kernel does know about security (including process security), it's not just a Win32 API thing. Programs which are run in kernel mode (during the boot screen) are run under the "localsystem" account by default, and you can start services under the localsystem account as well. But programs which are run during *nix startup scripts are usually run as "root". The kernel does know about users and security, including ACLs. The Win32 API layer is actually very close to the kernel-mode API (NT API), and most Win32 API (kernel, GDI, and USER) calls result in a message passed to part of the kernel. Some security is provided by the login program, for example, but it's the same deal as with "login" in Unix.

And not every user is an admin. That's just the default in WinXP Home. Not Pro. Not Win2K, NT or .NET server.

However, Windows has it's share of problems. The scheduler in particular is one of the weakest parts of the NT kernel IMHO. Fairness is a major problem: processes can be starved for tens of seconds at a time fairly easily. This is unacceptable for an interactive process that the user is waiting on. The VM has a few cases which cause it to thrash excessively, but it's not too bad. There are far more issues outside the kernel, but on the whole, the kernel is quite solidly designed.

Re:wonder what this means

[shaitand]

To the developer... and equally important are resources consumed. Memory requirements... remember in many cases a commadore 64 had equivelent programs to what we have now in some cases there is little improvement functionally. The difference? Their's ran with 64k ram or less and they reinvented the wheel. Those same programs were also used a heck of alot less disk space.

My point is being efficient (not neccesarily speed of execution) should be a primary concern. Set the target environment as small as it can be, not at some point in relation to what most people have on their desktop today.

Re:wonder what this means

[shaitand]

linux is a unix clone and claimed to be nothing else. It's SUPPOSED to have copied it's technology from unix. Windows is supposed to stand on it's own merits... so what are they? What exactly is all this innovation microsoft talks about? My point is that it's not *nix that is catching up with windows, it's windows that is, and always has been playing catchup with *nix.

Re:wonder what this means

[shaitand]

Yeah I've heard alot of people say this about Quake 3. My experience is that it runs smoother in XP than linux. But let's be honest, most people don't use an NT based system for playing games, they use 98SE where they can still run alot of DOS games. And in terms of single app performance (such as a game) 98se runs faster.

Re:wonder what this means

[shaitand]

"You can't read other programs' address spaces unless they deliberately share memory. "

Parts of a program are also cached to speed up program startup the next time around. Which means the next instance of a program starts faster. Interprocess communication should be done through messaging, not shared memory space.

Re:wonder what this means

[Malcontent]

"Microsoft is betting EVERYTHING on it."

That's a lie. It's a lie that MS employees (and I guess ex employees) like to tell. Of course I realize that lying is a virtue in MS but nevertheless it's a lie.

MS does not bet EVERYTHING on ANYTHING. MS is a hugely diversified company which makes hardware, games, owns controling and non controlling shares in hundreds of other companies, has lots of patents, owns many media outlets and makes a ton of money on services. If MS was to bet EVERYTHING on .NET they would have to abandon all their non .NET holdings. They won't do that because all those investments are a hedge in case they are not able to shove .NET down the throat of all their developers.

MS is not dumb, they will never put all their eggs in one basket.

Re:wonder what this means

[shaitand]

you cannot buy a COMPLETE 700mhz desktop from wal-mart for $200, in fact what you can buy is a POS. But that's another issue.

I'm one of those with this crazy idea that a system over 1ghz with a half gig of ram and a 7200rpm drive should actually be faster than a p200 system running software that was current at the time.

"Worse yet, optimized programs will almost always be"

This is a load of nothing but BS from someone who obviously does not know how to optimize code. Programs written for stability and efficientcy (does not neccesarily mean speed, but a balance of speed and memory utilization) are less buggy not more. The programmers are actually paying more attention to the code they are more familiar with every facet of what is written. Actually paying attention to what is written results in less bugs, sloping out as many lines of code as you can because some idiot in management actually uses this as a benchmark results in more bugs. You can be efficient and still be modular, ease of maintaining code is a result of good design, which lends itself to efficientcy. Reinventing the wheel is generally a bad idea, but only so long as you can't invent a better wheel. Also to be considered is the fact that properly written code requires less maintaining from the get go. It costs less to do the job right the first time around.

"In the future, maintainability, portability, and ease of development will be more important than performance. Hardware will make up for the deficiencies of programmers."

Unfortunately in many programmers eyes this is already the case. A good programmer realixes that the quality of what he codes and the time of it's users is more valuable than his time. If it's not, then it's not much of a buisness model is it?

So, we're back to the 60's.

[pmorrison]

All my friends who learned to program computers (ok, Windows) in the 90's think it strange that I keep one or more command prompts open to get work done. Besides having 'grown up' with prompts, my argument is that the core of programming is algebra+logic, and text makes a pretty good notation for both of those things... it's a much better graphical notation than anything developed in the last 40 years. So it's heartening to see even MS come back around to the way things were.

Re:So, we're back to the 60's.

[Sh0t]

If you mean command prompt On Windows, there honestly no reason to keep it open unless you made a ton of batch scripts in the windows dir. The windows shell post 98 isn't comparable to the nix shells so i don't see how having it open makes things any easier. Windows was designed around the gui interface and honestly IN WINDOWS things are just easier to manipulate from the regular interface. Not to object to your l33tness or anything but I really don't see the point. "To get work done" What kind of work? Text editing with the dos editor?

Re:So, we're back to the 60's.

[Gordonjcp]

Well, I do a lot of graphics editing, including resizing and thumbnailing images from digital cameras. It's far easier for me to knock up a script to do this than to struggle with GUI programs to get the job done. Since they're going to go on a Unix webserver anyway, I can just resize then scp them across. If I'm doing a heavily graphics-orientated project, a GUI works well. If I know exactly what I want the machine to do, command line can be better - it's usually easier to ask for something by name than to point at it, in the hopes you'll be understood.
Consider - I want to resize a directory of images, and put them in a thumbnail directory. Which is easier?
Command line:

mkdir thumbnail
for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;

or GUI:

Click File/Open
Go to the right directory
Open the file
Click on Edit/Image Size
Set it to 128x96, or 96x128 depending on if it's portrait or landscape
Click Save As...
Go to the right directory
Click OK
Go back to the start, until all 300 or so images are done....

Re:So, we're back to the 60's.

[NineNine]

mkdir thumbnail
for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;


Looks like somebody is inthe same business I'm in (see below) ;) I've been doing this for years, but my tool doesn't even rquire any batch scripting.

Re:So, we're back to the 60's.

[dknj]

How about creating users in an Active Directory automagically? I do not like the fact that we had to install Perl to get the job done (and thats the only reason why perl exists on the server) so I took it upon myself to rewrite the script in C. When I get back to work I will happily uninstall perl and not have to deal with the crappy Windows Task Scheduler anymore.

-dk

Re:So, we're back to the 60's.

[redhog]

Eh, I just came home frrom visiting my parents. When there, I helped them with their WinXP computer, on which they needed ome files to be editable by just some users, and so on... It turned out you couldn't change the ACLs from explorer, as you can in w2k (right-click, select properties, etc), at least, I couldn't find it... In the end, I had to reort to the command prompt, and found out that cacls and dir /Q was quite a decentt tool for what I wanted to do... Sometimes, even MS does things right, even when it comes to good old cmd.exe...

Re:So, we're back to the 60's.

[Gordonjcp]

No, not preview them, resize them and put them somewhere else. I don't really want to use a GUI tool for that, because it's easier just to type in a one-liner that does it for me.

Re:So, we're back to the 60's.

[Soul-Burn666]

Want a command prompt in Windows? Just install cygwin.

Re:So, we're back to the 60's.

[alvi]

I think the point is that the command line is much more generic. Sure there might be a GUI which will just do this resizing thing automatically, but what if your requirement is slightly different, i.e. renaming the files at the same time according to the exif header?
What if you don't find your exact 'do it!' button? Settle for less?

Re:So, we're back to the 60's.

[spongman]

cmd.exe?

FOR %i IN (*.JPG) DO convert -resize 128x128 "%~i" "thumbnail\%~i"

Re:So, we're back to the 60's.

[droid_rage]

You could have easily done it with ADSI in VBScript which is already natively supposrted. What were you trying to do, just write a script to add users? How about:

Function CreateUser(sOuDomainPath,sUserName)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sUserName)
oUser.Put "sAMAccountName", sUserName
oUser.SetInfo
oUser.AccountDisabled = False
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser = True Else
CreateUser = False
End Function
Function
CreateUser2(sOuDomainPath,sFirstName,sLastName,sDe scription,sEmail,sPassword)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sFirstName & " " & sLastName)
oUser.Put "sAMAccountName", Left(sFirstName,1)& sLastName
oUser.SetInfo
oUser.FullName = sFirstName & " " & sLastName
oUser.GivenName = sFirstName
oUser.Sn = sLastName
oUser.AccountDisabled = False
oUser.Description = sDescription
oUser.SetPassword sPassword
oUser.Mail = sEmail
'oUser.Profile = "\\server\share\username"
'oUser.Put("HomeDrive"),"X"
'oUser.HomeDirectory ="\\server\share\username"
'oUser.LoginScript = "myscript.vbs"
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser2 = True Else
CreateUser2 = False

End Function

That's actually some code that can be easily found in a number of locations Microsoft, for example.

Im not a huge fan of MS (Read my journal for opinions on your run-of-the-mill Windows admin), but I wish people would stop bashing Windows for a lack of understanding on their part. Most of this stuff is in the Windows 2k Server resource kit, too. I guess your company didn't shell out the $100, or you didn't read it...

Re:So, we're back to the 60's.

[Col. Panic]

This is just not true.

If you are in a networked environment, you might want to use the 'net' command and its various subcommands. Typing the command that launches a service is much quicker than navigating to services in control panel, or in newer revisions of windows (2000 and xp) control panel, then adminitrative tools, just type the command dammit!

Also there are lots of win32 ports of *nix tools that you can use from a command prompt. Check out sysinternals for ports of strings, ps (pslist/pskill), and lots of others.

(not checking link this time because fscking ie doesn't want to remember the form post data like mozilla will and i am typing this for the second time after checking the link on try #1. - yeesh)

Re:So, we're back to the 60's.

[freeweed]

Off the top of my head, telnet client, ftp client, ping, finger, commandline winzip (a godsend).

Just because YOU don't see a use doesn't mean there isn't one.

Re:So, we're back to the 60's.

[Anonymous Coward]

Installing yet another stupid GUI is still BS (and would it even run on 98?).

My parents just bought a digital camera. They asked me to show them how to use it. No problem.

But then they needed to know how to download the images into a coherent directory structure, create thumbnails, etc. Problem!

So I installed Cygwin on their system and wrote a script. Now there is an icon on the desktop that does it all - via script.

The fact is, giving someone directions on what to click, pull down and select, create a folder, etc, is imprecise BS. Especially when you are talking about creating files, naming directories based on the date, etc.

It doesn't matter if it is your Mom or a junior admin.

Vendors often think it is all about the GUI. But in every serious environment I have worked in, the engineers want to script everything.

Re:So, we're back to the 60's.

[Pathwalker]

Personally, I would do neither - resizing images for display should be the webserver's job.

With Roxen, I just throw a bunch of pictures into a Directory and the webserver generates the thumbnails as needed, caching them in a database after they are generated.

The only scripting was adding option='thumbnail' and &_.thumbnail; to the directory template.

Re:So, we're back to the 60's.

[Monty Worm]

You are kidding, right? I have work to do that needs to be done in a command processing environment.

I have 550 WMA files that I want to convert to mp3, but some rubbish software (Media Player) has added track names, and put them all into an artist/album tree. If I had a command line conversion tool, I could just write a perl script to create a batch file to do all the renaming so I can use mp3 tools to work with it (like under Linux).

These files are 1/6 of my total music collection which is currently in storage elsewhere, but I'd like to have access to it all eventually

Under Linux+bash, I had a 1-liner command line script to count the albums per artist that my CDDB player had seen. About 6 filters - I can't work out how I'd do this in windows......

Re:So, we're back to the 60's.

[spectral]

if you reboot in safe mode it comes back (in XP Home). I've had to do it when some permissions got royally messed up somehow (I have no clue how they managed this, but it has happened to my friend)

Re:So, we're back to the 60's.

[JohnFluxx]

I don't see why - just cache the operations. Assuming the pictures don't change much, then all that is needed is to compare the date of the thumbnail and picture.

Basically we are saying the same thing tho - just that perhaps we can have the pogram that does the thumbnailing on the server rather than as a seperate program for sake of consistency and neatness.

Re:So, we're back to the 60's.

[Gordonjcp]

What's the point of that? Why load down the poor webserver with that stuff?

Re:So, we're back to the 60's.

[dknj]

I wrote a proof of concept application with VB first. I know all about the resource kit and ADSI. If you read my post, you would see I wasn't bashing Microsoft in any way. I just said I replaced perl by rewritting the script with C.

Now if you really want the entire background of the story, here it is: the last admin wrote the user creation script with perl and used the task scheduler. I see NO need for perl on the system when the whole thing could be written with WSH and ADSI. Therefore I wrote a replacement in Visual Basic (did not want to use the scheduler so I chose VB instead of WSH). I wanted to refine my C skills, so I rewrote it in C (my work for the winter was done, I had time). I took the time to make it a service, allow control from remote machines, and other little things I wanted to see in the program. Just the fact that I replaced the script should have clued you in that I know about ADSI.

-dk
Welcome to slashdot.

Re:So, we're back to the 60's.

[ortholattice]

Many people don't even realize that you can iterate through files with one command in DOS.

for %1 in (*.jpg) do convert -resize 128x128 %1 thumbnail/%1

Uh, I'm not an expert on DOS (nor WinXP) but on WinXP "HELP CONVERT" at the Command Prompt says: "Converts FAT volumes to NTFS." Was there an image-converting "convert" command in DOS that they took out for XP? I thought "convert" was a GNU/Linux thing.

Re:So, we're back to the 60's.

[Gordonjcp]

I don't have Photoshop. I don't really want it, either. Please educate yourself before making silly assumptions.

Re:So, we're back to the 60's.

[Gordonjcp]

Not really. As I said in a previous reply, the problems I'm solving are known and simple - resize and possibly rotate by multiples of 90 degrees. I don't want to use a GUI to do that, because I already know exactly what I want to do and how to do it. I still don't see the point in adding an extra layer of complication to things. GUIs work well for drawing and retouching photographs, or where you're doing intensely visual work, but some of us can picture what the effect of a given edit will be without seeing it in "real time", as it were.

Re:So, we're back to the 60's.

[throx]

The problem however with the command line app is you are limiting yourself to the functionality available in that application. What is a much better option is to have a scriptable GUI app which allows you to perform batch tasks on files and can be driven from the command line.

Say for example you decide you want your thumbnails sepia toned. Had you used the scripting capabilities of Photoshop and/or used the batching tool (which lets you drag/drop a stack of files onto a pre-recorded macro) then the task would be exactly the same as the simpler resize. In your simple command line case however you are left finding a new tool which performs the more complex task and possibly working out the new command line syntax to change your scripts.

The key thing isn't command line vs GUI. It's the ability to drive an application in batch mode vs one which purely runs as a GUI or command line app.

Re:So, we're back to the 60's.

[alvi]

Your second sentence doesn't justify the first one: What would YOU do if you don't have your GUI-based image manipulation program?

If there wasn't a 'convert' program, there would be a 'mogrify' command or whatever. And I can still use it in a *generic* way. You can't come up with a GUI which would do all the things I could do on the shell.

It has very much to do with GUI vs. CLI. It has to do with the very simple fact that GUIs can't anticipate every wish a user might have. On the shell, programs don't need to anticipate anything because the user can glue things together himself.

Re:So, we're back to the 60's.

[Gordonjcp]

Well, it's nice if you've got the choice to do both. However, a lot of the time I find that GUIs are counterintuitive and difficult to use. Perhaps it's a left-handed thing, or perhaps it's because I fear your sig...

Re:So, we're back to the 60's.

[mackstann]

it's not the gui, its the applications. X is fine, and for the most part, window managers are fine (i LOVE waimea, i cant imagine using something else), the problem is the applications. i go to a page and download an mp3? oh, i have to set that up in mozilla and tell it to save somewhere, then i go listen to it with mpg321. i go to a page with a mpg in it? oh, i gotta download that, then watch it with mplayer. i get a digital camera, and i have to set that up, and then i have to find some application that works nicely, or just give up and use the command line for whatever i want to do with them.

if i was on MacOS, i would just plug the camera in, iWhatever pops up, i click "make a web page", and i have a little html page with thumbnails and everything. it's this simplicity and usefulness that the applications in X dont provide. integration and simplicity - that's why i need a Mac :)

Re:So, we're back to the 60's.

[0x0d0a]

Love those environments where you say that "a product is perfectly capable of doing this" and then turn around and admit that you have to shell out more money to do so.

Windows remote administration? Development? File serving? Sure, we can do that...as long as you're willing to keep forking out.

Re:So, we're back to the 60's.

[Vaughn Anderson]

I am not disagreeing with you that pre-scripted functions (rotate & resize)that you don't witness and control each step are ideal in mass image manipulation.

I do however disagree that it is faster using pure command line.

As a graphics person (and handy with scripts and recording commands)it is a rather simple task to simply select "Convert to Thumbnail" from my GUI's command menu (which I setup and have complete control over), 2 clicks.

I can also link my command to a keyboard shortcut, which makes it even that much faster. (unless you can do this with command line, this feature in itself makes it faster and easier than any command line control)

On top of that I can make my own GUI control elements which in can throw in dozens of simple controls to give me ultimate control and immediate access to any setting, filter or other scripted commands.

Another handy feature I have access to is recording steps and playing them back as a script and command. This is standard in Photoshop and Fireworks.

So we are both doing the same thing, running a premade script to do work for us. Only I can stay in the GUI where I did the image manipulation and not have to jump to a seperate command line window for this.

The only real difference that I see is that of typing out a command or simply clicking on one.

-v

Re:So, we're back to the 60's.

[maraist]

> cmd.exe?
I think the point was that windows doesn't facilitate command-line friendly applications (You're more encouraged to do GUI and only GUI).

Therefore, no shell can compensate for the lack of glue that application developers provide.

It does seem that MS is on the right track though. Assuming that administrators are willing to learn the ins and outs of VB.NET, they'll have access to the entire .NET API of an application. Essentially administrators could be programmers at a lesser level (only having to learn the very public APIs (such as print, convert image attributes, etc) similar to OLE features). It's much more powerful since application developers don't have to think about what to export; if they write inter-application API's, it'll be available to the sys-admin.

Course the same thing already exists with java, but there just isn't enough java in OS's tool-boxes to really be considered here.

Re:So, we're back to the 60's.

[swillden]

Okay, so how about this one:

I need to resize a single JPEG image, but there are a wide variety of filters and quality settings available, and I want to find the one that gives me the best quality for the file size. So, I just ran:

for j in Point Box Triangle Hermite Hanning Hamming Blackman Gaussian Quadratic Cubic Catrom Mitchell Lanczos Bessel Sinc; do
for i in 70 75 80 85 90 95 100; do
outfile=IMG_3972_Im_$i-$j.JPG
convert -geometry 640x480 -filter $j -quality $i IMG_3972.JPG $outfile
display $outfile&
done
done

(Apologies for the lack of indentation: the 'ecode' tag doesn't seem to honor spacing).

Do you have a GUI tool that will do that for me, and make it easy to compare the results side by side? And what if I wanted to apply some additional effects as well?

I also have some tiny shell scripts that I use to do a host of other image manipulations as well. For example, one downloads all of the pictures from my digital camera, reads the EXIF tags from them to get the dates they were taken, places them in pics/originals/<year>/<month>/<day> , makes copies resized to each of 1400x1050, 640x480 and 160x120 and places them in pics/backgrounds, pics/webversions and pics/thumbs, respectively. Another crops and adjust color ranges, preparatory to printing. Another synchronizes my images between my laptop where I do all this stuff and my server where my image repository lives.

CLIs, programmable shells and scripting aren't for everyone, but for those who can use them, they're extremely effective tools. Much of this can also be accomplished with GUI scripting as well, but in my experience, GUI scripting is much more error-prone and the scripts tend to be longer and more complex for a given task.

The ideal, IMO, is exactly the way we see things done in Free software on Unix systems: Lots of small, very-specific libraries that are used by small, quite-specific command-line tools, with GUI apps build on top of the libs and/or the command-line tools. That way, all functionality is available from the CLI for scripting, or from GUI apps for point-and-click (and in library form for the times when you decide that scripting isn't going to cut it and the existing higher-level apps don't work the way you need them to).

It sounds like MS is going exactly this direction as well: Everything availabe as object components, which can be accessed from a powerful scripting shell or from higher-level apps. And that is a good thing. It sounds like it may even be a better thing...

Re:So, we're back to the 60's.

[droid_rage]

Ahem... I never said you had to buy the resource kit. I specifically said that WSH comes native to windows. I just said that there are some very good canned scripts available through the resource kit, which cost about $100. The scripts could probably be found on the internet for free quite easily, or could be written very easily by someone who knows how to write the scripts.

Re:So, we're back to the 60's.

[droid_rage]

You specifically said that you needed Perl installed on the server, and I merely pointed out that it isn't true. It was obvious that you knew about ADSI, but not clear that you knew it could be used with VBScript (Which is not VB, which is not clear that you understood from your post).
My apologies for misunderstanding.

Re:So, we're back to the 60's.

[alfaiomega]

Well, I do a lot of graphics editing, including resizing and thumbnailing images from digital cameras.

Welcome to the porn biz... :)

for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;

...where Bash and ImageMagick are your main advantage over the competition.

(Using Perl and Image::Magick is the Next Level of being a Porn Wizard.)

Re:So, we're back to the 60's.

[Gordonjcp]

That is a lovely script, and one which I will play with later. I never thought of that, but I can already see a lot of possibilities.

Of course, it's not about whether GUI is better than CLI or vice versa, just which is more appropriate to the task at hand.

Re:So, we're back to the 60's.

[redhog]

This, of course, was XP home edition. Blurgh! Stupid MS making things so damn userunfriendly!

Development in India

[slashuzer]

It would be interesting to know just how much of Microsoft's "future devlopment" are being made in India. My guess is that the OS, Office etc continue to be further developed by the team(s) in Redmond, but most new products/services are being developed in India.

Re:Development in India

[SerpentMage]

That is what I found more interesting than the job description itself....

Re:Development in India

[GutBomb]

the job listing was most likely a job in redmond washington, but posted in an indian job listing to specifically recruit indian guys.

Re:Development in India

[ninewands]

Well, the tail end of the job listing says "This position is in Hyderabad, India." ... now unless the city fathers of Redmond and the Washington state Legislature have decided to do some fast and dirty name-changing, I seriously doubt that the job is in Redmond.

Is this news?

[nuggz]

You mean the big bad MS is developing all sorts of technology. Some of it just copying features found before in other operating systems.

Does it really surprise anyone that MS knows about other operating systems, Bash, Perl and Python.

The things they list in this post are good useful tools, it should be obvious that they would look to implement them now that clustering is becomming a larger concern. Admin by GUI works for a handful of computers, but when you start dealing with many, you need something else, and MS is going to provide that.

This just shows they are acting more serious about providing Enterprise Solutions.

Re:MS is responsive: that's why they're #1

[the eric conspiracy]

This was one of the last holes they had to fill.

Will it be free?

Starting to sense a pattern ...

[YetAnotherName]

MS-DOS was just a boot loader. Windows 95 gave us preemptive multitasking. A message-passing microkernel got stable in Windows 2000. And soon we'll have a scripting language.

Let me guess what's next down the pike: a /proc filesystem, a serial console capability, runlevels, and a package manager with dependency feature.

Hmmmm...

Re:Starting to sense a pattern ...

[Anonymous Coward]

Neither Win2k nor NT 4.0 are microkernels. Read "Inside Windows NT" by Helen Custer. They explicitly state that NT has some MicroKernel-like features but that's it.

Re:Starting to sense a pattern ...

[diamondc]

If you get all your RPMS from RPM or get all your debs from the official Debian servers and follow the instructions, you shouldn't have rpm or deb dependency hell.

Once you start downloading third party debs/rpms, from who know's where on whoever's hacked up computer, then you're on your own.

Re:Starting to sense a pattern ...

[LadyLucky]

they do. WHen doing java development, it's much easier to simply use the / character on all platforms, as it works on windows and on unix.

Re:Starting to sense a pattern ...

[goon america]

...and a package manager with dependency feature.

> winpm install Mozilla
Must satisfy dependency: Microsoft-Office-XP

> winpm install CuteFTP
Must satisfy dependency: Microsoft-Office-XP

> winpm install StarOffice
Must satisfy dependency: Microsoft-Office-XP

hmmmm

Re:Starting to sense a pattern ...

[pz]

W95 doesn't have *preemptive* multitasking: all multitasking depends on the cooperation of each process to yield unused cycles to the system.

I'm pretty sure (please corret me) that proper preemptive multitasking didn't appear until W2K
(at least in OSes from Redmond).

Re:Starting to sense a pattern ...

[sheldon]

- a /proc filesystem

WMI, only it's not a filesystem it's a relational database.

- a serial console capability

That's in .Net Server 2003. The purpose is really to support newer blade servers. But it requires hardware support. The reason Windows never supported this in the past is because the x86 design didn't. Try to get your POST info off the serial port with Linux on an x86 machine.

- runlevels

Hmm. Services start in order by dependency. So you just say FooService is dependent on RPC, and the OS handles the rest. That's been there for quite some time, if not from the start.

- and a package manager with dependency feature.

Windows Installer

It's not surprising to see similar solutions, because the problems are generally universal for any OS. The difference is in the way Microsoft has chosen to solve them, generally in a superior fashion to the Unix solutions.

For instance by making WMI a relational database, one can query it with SQL statements. The next step, they say, is to make the entire filesystem a relational database... That path was started when ADO was introduced and you could use it to query the filesystem.

Re:Starting to sense a pattern ...

[Khazunga]

Try to get your POST info off the serial port with Linux on an x86 machine.

There's nothing inherent o x86 architectures that forbids doing it. IBM's xSeries servers can do that, via RS485 and IBM ASM software.

Re:Starting to sense a pattern ...

[popeyethesailor]

And the tech support will say

RTFM !

Re:Starting to sense a pattern ...

[Electrum]

- a serial console capability

That's in .Net Server 2003. The purpose is really to support newer blade servers. But it requires hardware support. The reason Windows never supported this in the past is because the x86 design didn't. Try to get your POST info off the serial port with Linux on an x86 machine.

You can with a PC Weasel.

Good step

[Captain_Frisk]

This is a good step, but what good does it do to have a top notch shell, when the vast majority of windows programs are gui based?

Are they going to release command line versions of most of their administrative tools?

Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it.

Re:Good step

[earlytime]

wha they really need to go along with a real scripting environment is to integrate it with the gui like apple does with applescript. Then anything can be reliably scripted.

hey wait a minute, if they do that, how are the MCSEs gonna make a living? I guess they'll just have to half-ass it like they do everything else.

Re:Good step

[nighty5]

Not exactly so.

Ever since NT4 became a serious peice of infrastucture, Microsoft provided Resource Kits available to manage the more advanced characteristics. You can control everything that the GUI offers. It's just that a lot of people don't bother to look past the surface of the Control Panel.

If you want more advanced analysis of NT domain related issues, RPC problems etc, mass creation of accounts the only solution you have is to use the command line.

Re:Good step

[oren]

You are missing the point about this shell making heavy use of the .NET framework. Presumably, any .NET object would be accessible to the command line... Given that they intend for their whole OS to be based on .NET, this means the command line may offer access to more functionality than /bin/sh offers on a UNIX platform.
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell, rather than a simple shell replacement.
If this achieves its potential, Linux/UNIX may end up playing catch-up on the CLI front as well as on the GUI front. Good move for Microsoft, and one that would be hard to counter in the open/free software world because we have no universal object-based virtual machine/interface for use as a basis.
Or rather, I should say we have too many - Java, CORBA, the Mozila components, and even .NET (Mono). Microsoft could, if it plays nice, actually set a new portable standard for shells (based on .NET on Windows and Mono on UNIX). Of course, knowing Microsoft, they'll blow it by succumbing to the temptation of poisoning it with all sort of Windos-isms. This will be interesting to watch...

Re:Good step

[the eric conspiracy]

Given that they intend for their whole OS to be based on .NET, this means the command line may offer access to more functionality than /bin/sh offers on a UNIX platform.

And how would that be? UNIX is a file/text based OS, and all of its functionality is controlled by running shell scripts. Exactly what UNIX functionality is not available from a shell script?

Re:Good step

[CH-BuG]

Control a running program ?

Re:Good step

[oren]

And how would that [more functionality] be?

Well, in UNIX, if you haven't wrapped system calls in an excutable, you can't access them from the shell. Assuming a .NET based OS, all system calls would be available as methods of a "System" object or some such. This holds for more than system calls. The shell model enforces the executable as the basic level of granularity. Hence if I run, say, Perl, I can't access a specific Perl module from the shell; I need to wrap it in an executable Perl script first.

In contrast, theoretically, in a .NET based OS, where all code is written to the .NET run time, one should be able to access any class defined in any VB project and hook it with any other class written in a C# one, without having to go through creating a special "executable" wrapper for each one first.

That's all in theory of course; you still have one hell of a naming space problem, for starters, not to mention typing problems and the like. Good documentation of available classes and interfaces would be vital. UNIX had 'man' for that, and it did its job admirebly well. Microsoft would have to set up an equivalent system if this is to fly.

Of course, Microsoft isn't known for helping code not written by Microsoft work together with the system (these are the same people who brought us 10 years of DLL hell, for example). They'd probably document (some of) their stuff in MSDN and leave everyone else SOL. So I wouldn't worry too much. It would probably fizzle to become their version of AppleScript - killer application in theory, but rarely used in practice.

Re:Good step

[stevey]

That sort of thing can already be done with jscript, or vbscript.

Opening processes, reading text from windows, interfacing with active directory and reading the registry - for example are all possible with the WSH (Windows Scripting Host).

Personally I use Perl for most scripting under Windows if I have to do any at all. The DOS batch file languages are seriously crippled.

Re:Good step

[ninewands]

Quoth the poster:

Assuming a .NET based OS, all system calls would be available as methods of a "System" object or some such. This holds for more than system calls.

Great ... so now all some script kiddie has to do is something like:

net call \\mybox.mydomain\system.WinOpenFile(<filename>)

or some such thing.

Why do I think this is NOT a Good Thing(TM) given Microsoft's history on the subject of security?

Re:Good step

[sheldon]

"This is a good step, but what good does it do to have a top notch shell, when the vast majority of windows programs are gui based? "

Think outside the box...

In Windows we're not limited by piping text from one command to another. We have COM automation today which allows one to instantiate Microsoft Word as an object and issue commands to it. This new scripting/shell will apparently allow for similar automation using native .NET framework objects.

"Are they going to release command line versions of most of their administrative tools? "

command line version of administrative tools have been available since NT 3.x. For those that don't you can use WSH to automate the task.

"Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it."

Huh? Can you open up the word processor in Star Office and build a document based upon data you pulled from an Oracle query, complete with various layout features from a Unix shell script?

We've been able to do that from the Windows command line for several years now. I don't think you fully understand the scripting capabilities Windows offers.

Re:Good step

[sheldon]

"(vi) GNOME programs are scriptable in any language with CORBA bindings."

GNOME imitates the way Windows works today. Where do you think Miguel get's his ideas from?

Re:Good step

[markov_chain]

If they unify the object model, the shell will have access to gui based programs just like javascript code has access to objects in the browser.

Re:Good step

[the eric conspiracy]

Well, in UNIX, if you haven't wrapped system calls in an excutable, you can't access them from the shell.

I don't think that has any practical significance. UNIX has a very complete set of fine granularity binaries to support shell scripting.

where all code is written to the .NET run time...

UNIX solved this long ago by exposing methods from its binaries with command line options and connecting the binaries with pipes.

It would probably fizzle to become their version of AppleScript - killer application in theory, but rarely used in practice.

There will probably be some community develop around it, as in AppleScript. But the learning curve will discourage anyone else.

Re:Good step

[Abcd1234]

Err... I suppose you've never heard of psh?

Re:Good step

[sheldon]

"Yes"

Ok, how? StarOffice supports automation...
http://udk.openoffice.org/common/ma n/tutorial/offi ce_automation.html

But this is within the Windows environment, I want to know if this is available with Linux. I know that KDE and GNOME do support this type of functionality, but it's not a universal feature of the OS and as such automating one app is very different from another.

"Text files have always been easier to manipulate from third-party tools (like the *NIX commandline tools and scripts) than Microsoft's formats."

I'm not talking about text files. I want to pull in the data from Oracle, and then build a formatted table within the word processor. You know with headers, footers, titles, shading, bold, font changes, etc.

"They're still easier than Microsoft's way."

Not really. The way you appear to be suggesting is you create a document using HTML or something at a low level. To do so means you need to understand the inner workings. With the Microsoft way, you don't care... I want to change something to Bold, I just do something like

myRange.Font.Bold = 1

"Similarly, SVG has greater potential than Flash because dynamic content can be created from simple scripts (and commandline tools!) more easily, with general-purpose XML tools."

But again, to do so means understanding the basic file formats. That's not efficient.

""Those who do not understand Unix are doomed to reinvent it--badly." -Henry Spencer"

Fortunately Microsoft understands Unix. They were the first to port it to the x86 platform back around 1980. As such they have taken some of the better ideas for Unix, but in Unix weak areas like process automation the design and implementation within NT is vastly superior.

If it wasn't a better way to do it, KDE and GNOME wouldn't be trying to mimmick it. This isn't new, the Amiga had ARexx to do very similar process automation.

Re:Good step

[jafac]

For me, it's the lack of. . . I guess you'd call it performance.

About two years ago, I was trying to parse a log for a customer who needed to feed it into their backup program to recover their data from tape. I had some tools I liked to use in DOS for text filtering and such, but ultimately, the 800 meg logfile kept getting lodged in Windows' throat somehow. I couldn't find any DOS tool that could handle such a large file. I even tried cutting it into smaller bits. After about two hours, I nearly gave up. I had done this sort of thing before many many times with smaller files. Ultimately, I had a freind with a Linux machine help me. He used awk, and including the time it took to read the MAN page to find out the syntax, the job was DONE in 10 minutes. Finished. File opened, parsed, and output written. The Windows machine was an 800 MHz Pentium with 512 Megs of RAM, and the Linux box was a 400 MHz Pentium with 128 megs of RAM.

I was converted that night, and haven't looked back. Except at work where we're forced to run Windows - but I use Cygwin now - and it still has problems with large files. I use Mac OS X at home, of course.

I just hope that if MS goes through all this trouble to create a decent set of tools, that they actually bother to fix whatever it is that causes the whole environment to just be absolute crap. But I doubt they will.

Re:Good step

[battjt]

How is understanding a COM interface easier than understanding an equivalently expressive file format?

Is myRange.Font.Bold=1 obvious? Why 1 and not myRange.Font|=Bold, or myRange.Font.append(Bold), or myRange.Text.Style += Bold?

Writing LaTeX is just as easy as using your COM interface to Word.

I would create an OpenOffice file with the correct format, then cut and paste into a script to create that file from the Oracle data. (Actually, I would use LaTeX, because it is a very efficient renderer.)

Joe

Re:Good step

[alfaiomega]

(iv) X programs can have events/messages sent to them on the fly

(v) KDE prgorams can be controlled to a level of granularity similar to Amiga ARexx of yore via the dcop CLI command.

(vi) GNOME programs are scriptable in any language with CORBA bindings.

And don't forget:

(emacs) you can even attach GDB to a running process.

additional information

[neildogg]

There are also other jobs related to the same area listed for Microsoft India Development Center here.

Those dont know UNIX are

[Akoma The Immortal]

bound to reimplement it.

I don't know who said it. But it true IMHO.

Happy New Years to you all!!

Re:Those dont know UNIX are

[Tet]

I don't know who said it. But it true IMHO.

"Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer

Re:Those dont know UNIX are

[mav[LAG]]

I don't know who said it. But it true IMHO.

Henry Spencer - who originally said: those who do not understand Unix are condemned to reinvent it, poorly.

Even more appropriate...

A good thing, really.

[bdowne01]

Actually, I'm really intrigued about the possiblity of having a "strong" shell on Windows. It's one of the main reasons I can't find myself using Windows for much.

Usually, if I had to...I just installed Cygwin and used it from there. However, the interaction between the actual Windows environment and Cygwin was a little cumbersome--but usable. I've written some crazy shell scripts using Cygwin, but trying to run a Windows command using variables from the script can be tricky, for example.

However this opens up some other nice possibilities for a Windows environment. If the shell they create is complete enough, you may not even need stupid "remote control" apps, instead you could just SSH into the box and take care of things.

On the other hand, I guess it just makes Windows easier to crack too ;)

Re:A good thing, really.

[sheldon]

"If the shell they create is complete enough, you may not even need stupid "remote control" apps, instead you could just SSH into the box and take care of things."

The existing WSH already allows for this.

However WSH uses VBScript. If this article is true, what Microsoft appears to be doing is building up a new scripting environment based upon .NET. It does appear to be taking a different direction so that rather than having a scripting host, the shell as a whole is the host.

It'll be interesting, mainly because it will provide much greater consistency which has been the big win from the .NET framework. But it doesn't appear to be providing much new in terms of functionality.

Re:A good thing, really.

[Vicegrip]

It's not that tricky:
Retrive Windows environment variable into a cygwin bash shell:
foo=`cmd /c "echo %dosfoo%"`

Most nt command prompts can be accessed directly from the bash shell. Then if you need access to specific COM objects you just use a little WSH and javascript or, alternatively, active perl to get at them.

Personally I love cygwin. It makes a ton of daily tasks so much more effective and fun.

Like: find . -iname "*.dll" -exec regsvr32 /s {} \;
Easiest way yet I've found for re-registering COM components in one of the projects I deal with.

We'll see what kind of shell they come up with. Everything Windows previously had was abysmal. But what do you expect from a company whose products seem to be largely administered by teaming hordes of VB gurus who can't handle anything that doesn't have a point and click interface.

"isn't there a control that does that?"
or
"re-booting should fix that but I don't know why"

Re:A good thing, really.

[babbage]

On the other hand, I guess it just makes Windows easier to crack too ;)

Actually, I think you've got a really good point there, but maybe not for the reason you seem to be getting at.

What happens if, a couple of years from now, commonly available versions of Windows -- server versions at the minimum, consumer ones as a possibility -- start coming with a reasonable complement of standard-ish Unix-ish tools? Just to list a hypothetical set: sshd, perl, bash, a handful of utility programs (grep, tr, etc) and maybe some of the more specialized tools for networking, hardware monitoring, etc.

Where would we, as users of an "ecosystem" of computer platforms, be? Better off? "Yay, I can take my 'leet hacker skills to Unix, Mac, or Windowland now! Joy!" Or worse? "This new ssh vulnerability allows remote compromise across all versions of Unix, Mac, and Windows. When coupled with recently discovered buffer overflow errors on the version of Perl commonly installed by default on many of these platforms, remote users can...."

?

When the DNS root servers were recently DDOS attacked, a major factor preventing a complete [root] system wide failure was the heterogeneous nature of these servers, according to several post-attack analyses. The fact that each of them was running different hardware & software configurations prevented the attack from being universally effective, even though it was extremely effective against some servers and moderately effective against others.

Broaden that to the internet as a whole. As much as I like the idea of being able to "port" my Unix originated shell skills to every platform I have to use, at the same time I'm worried about the situation we'll be in when writers of malicious software will be able to port their exploits as well. If the 2005 variant of CodeRed or Nimda does not just have to be confined to the Windows target, my bet is that it won't be -- we're *all* going to have to worry.

Be careful what you wish for, you just might get it...

Good news... kinda ;-)

[bumblebury]

Well, perhaps if windows users get used to using a shell, then the switch to UNIX won't be too hard for them, it certainly makes it easier for the Linux movement if there are more similiarities than differences between the windows *gui* and the linux *gui*, as a large majority of Linux's advantages are more in respects to the underlying architecture, philospy[1].

--

[1] Actually, I happen to think that the linux desktop is much better than the windows desktop, if you shy away from GNOME, KDE and try some of the non-standard desktops. I've been using WindowMaker on my laptop for a year now, and I see no reason to ever switch (it just fits the way I work). Furthermore, once you go shell, you never go back.

Re:Good news... kinda ;-)

[NineNine]

Actually, I think that there will be even less of a reason to switch to something else in the first place. I'm betting that this is what MS is thinking, too.

Re:Good news... kinda ;-)

[the eric conspiracy]

even less of a reason to switch to something else in the first place.

Microsoft shops have already adapted to Microsoft's admin tools and don't see them as a disadvantage.

What this may offer is the reverse - Microsoft wants to make it easier to switch from UNIX/Linux to Windows.

I think that those who are switching from Windows are doing so because of license costs, the new provisions of the license program, the costs associated with making sure that you are in compliance, objectionable EULA terms, security issues, issues regarding scalability and having to run many Windows servers where fewer Linux/UNIX servers would do, rebellion at the costs associated with .Net migration, and so on.

Re:Good news... kinda ;-)

[caspper69]

a large majority of Linux's advantages are more in respects to the underlying architecture

Oh, if this were only true. As a systems developer and operating system architect (no, I do not work for MS), I can say, beyond a shadow of a doubt, that the underlying architecture of Linux (i.e. the kernel) is NOT superior to the 2k/XP kernel. Not by a longshot. OSS kernel hackers are making significant progress, but they are unfortunately stuck using an aging paradigm (UNIX) from a distant era of computing. UNIX is meant to be a data monster, nothing more, nothing less. Machines you could run for years without giving them a second thought as they churned through unfathomable amounts of information. And to be quite frank, it is still very well suited to its original purpose. On the flip-side, MS was able to start from scratch. The NT/2k/XP kernel, while similar in architecture to VMS (Dave Cutler from DEC who wrote VMS also single-handedly wrote the first NT kernel), is robust and modern. It's main issue to this point has been the inclusion of the Win32 API. But make no mistake, it is a well-designed, efficient kernel. The original NT design specification was over 1200 pages (there is quite a bit of information and excerpts available on the web). If you really want to get into architectural level discussions, or just peruse many of the thousands of threads on the "big" Win kernel vs. Linux, I suggest browsing the newsgroup alt.os.development for a while.

Re:Good news... kinda ;-)

[mikefoley]

Dave Cutler did not "write VMS". He made significant contributions, but there's alot of other extremely talented engineers (some still there!) that contributed to the success of VMS.

I doubt much of Cutlers code lives on at this point. VMS has had a number of serious code upgrades over the year. It's currently being ported to Itanic at the moment!

I remember a presentation back in Windows NT beta timeframe. I was working in VMS at the time. We sat there and watched while concepts and methods of Windows NT were shown. I heard someone remark "They stole our stuff".

It's interesting to see Microsoft coming around to the bennies of a command line, 10 years after the fact.

Re:Good news... kinda ;-)

[mamba-mamba]

I don't think it is fair or makes much sense to lump all unices together with respect to kernel architecture. They are not all the same. I'm not really a kernel expert, but I know the different unices employed different techniques and came from substantially different code-bases.

Also, I would be interested in at least one and preferably a few example(s) of how the "aging paradigm" of UNIX is a major disadvantage to "OSS kernel hackers," as compared to Microsoft NT/2k hackers.

Also, it would be nice to see how this disadvantage or these disadvantages affected the Mac OS 10.2 hackers as well.

MM
--

Needed at the Enterprise

[Chewster]

The thing is, this is sorely needed by Win32 to compete at the enterprise, so I'm not at all surprised they're doing it. Trying to stop/start Unix services remotely through ssh is a breeze. We gave up trying to use VNC (and others) remotely for Windows services since the performance was so bad.

There are 2 things I wonder about though:
1. Why is this only via .Net and not the full OS?
2. How much of the OS will be accessible via the prompt?

Kinda hard to tell by just the job posting. Neat to see though.

Re:Needed at the Enterprise

[NineNine]

Trying to stop/start Unix services remotely through ssh is a breeze. We gave up trying to use VNC (and others) remotely for Windows services since the performance was so bad.

You guys didn't research this too hard, huh?

Re:Needed at the Enterprise

[NineNine]

You're right. NET START has been around since NT 3.1, I think. That's been about... 10 years? NET START will only work locally, though. But NETSVC is an addon that's been available for a while now. Not sure how long, but it's part of the Resource Kit.

Re:Needed at the Enterprise

[spongman]

They do do it, and have been since win2k. Put yourself in the know:

• COM
• WSH
• WMI
• ADSI

Also, in the "Computer Management" management console select "Connect to another computer" from the "Action" menu.

Re:MS is responsive: that's why they're #1

[grondu]

Responsive? How long has windows been around? And they're just now planning to have a full-featured shell...I'm glad the fire department isn't that responsive.

Re:MS is responsive: that's why they're #1

[Khan]

..they've got security,

Uh, I think they still need to fill this "hole" (pun intended). Perhaps if they try removing all those integrated services and make them modular, they might be able to lock down their OS to the level that most NIX's have enjoyed for years now. Think of it in terms of inbreeding...the more times you marry your sister, the weaker the blood becomes. Same thing with Windows. My sig says it all in regards to why Windows is so popular.

they'll screw this one up as well

[g4dget]

I am sure Microsoft will do everything they promise, and as a result, their new shell will be absolutely awful. Microsoft's response to everything is "we'll implement something with more features, more technology". What they don't get is that simplicity and restraint is valuable in itself. You can see this throughout their systems. Their file systems are becoming databases. Their programming environment is fully object based and component based. Their file system protection allows you to specify arbitrary ACLs on arbitrary files. And on and on. In different words, just about every single one of Microsoft's products suffers from the "second system effect".

Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.

Re:they'll screw this one up as well

[countach]

In theory, object file systems, an object component environment and so forth CAN be a simplification of things.

In practice, I agree that Microsoft doesn't know how to do it right, and in practice they are not simplifications at all, but rather complications.

Re:they'll screw this one up as well

[leandrod]

> Their file systems are becoming databases.

This in itself is not bad. It would even be good, if they would become a true RDBMS, like Alphora Dataphor or Tutorial D.

Unfortunately, it is bad indeed, because it will be most likely yet another OO DBMS-construction-kit that does not get the basic database concepts right and throws us 30 years back to pre-relational concepts.

Re:they'll screw this one up as well

[g4dget]

Removing command line editing? How is that an advantage? I use that constantly!

Command line editing and job control have been moved from shell built-ins into separate programs. That makes those capabilities much more easily reusable and extensible.

You can get something similar for Linux: "cle" is a generic command line editor, and "screen" is something like job control.

Re:they'll screw this one up as well

[g4dget]

Oh, I think a "true RDBMS" is an absolutely horrible idea for a general purpose file system: it's way too complex and has way too much overhead. And it's been tried before several times and never caught on--for good reason, I think.

UNIX/Linux file systems are actually a database: a very specific kind of database. If the UNIX/Linux file system needs to evolve at all, it's in the ReiserFS and Plan9 directions. Those systems really do improve aspects of how file systems are used in the real world.

Re:they'll screw this one up as well

[g4dget]

In theory, object file systems, an object component environment and so forth CAN be a simplification of things.

Object storage is useful, but an object file system isn't merely object storage, it's object storage in the kernel. Does object storage need to be in the kernel? Does the kernel need to know how to invoke arbitrary user-defined methods on file system objects? I don't think so.

A modest amount of additional flexibility in the UNIX/Linux file system may be desirable. Plan9 lets you hook up a well-defined, fixed set of user-defined methods to file system objects. That may be a good idea, although it can still be done in user space (and perhaps is better done there). ReiserFS makes small files and large directories more efficient. Some additional kernel support permits change notification. Those are the kind of incremental changes to the proven concept of a "file system" that make sense to me. Taking an OODBMS or RDBMS and putting it into the kernel is asking for failure.

Re:they'll screw this one up as well

[enkidu]

Good link. And the reason is that the whole project will be feature driven, code will be written and implemented before the final design is complete, problems will be fixed by adding hacks instead of refactoring, more problems will be fixed by adding hacks on top of the original hacks, resulting in a cobbled together half assed, inconsistent, unusable, crappy design. Oh and junior level programmers will be making design decisions on the fly. It'll also break complex scripts with each new release. I'll pass.

EnkiduEOT

Re:they'll screw this one up as well

[leandrod]

> I think a "true RDBMS" is an absolutely horrible idea for a general purpose file system: it's way too complex and has way too much overhead.

No, you are thinking RDBMS == SQL, and that is not true. SQL is indeed too complex and slow, but that is precisely because it is not relational. It was originally based on some (not all) relational ideas, but since then it has been catapulted back thirty years to pre-relational times.

> it's been tried before several times and never caught on

You are mistaken. The only true RDBMSs now existing is Alphora Dataphor, and it is not yet a full, portable DBMS. In the past we had IBM BS12 (never a generally available product, pretered for SQL) and Ingres (its QUEL relational language was dumped for SQL). Each of these products have been found to be better to its non-relational counterparts, including SQL.

Re:they'll screw this one up as well

[g4dget]

No, you are thinking RDBMS == SQL, and that is not true. SQL is indeed too complex and slow,

No, I'm not. Don't tell me what I'm thinking. I said that RDBMSs are a horrible idea for a general purpose file system, and that's what I meant. SQL is a query language, not a database system.

Besides, the kinds of database engines that are sitting underneath SQL are what Microsoft claims they want to put into the file system.

The only true RDBMSs now existing is Alphora Dataphor, and it is not yet a full, portable DBMS.

Well, yeah, right: you and Alphora's marketing department think that.

Besides, the evidence that any more "pure" relational query language than SQL is better is thin at best. If you are going to redesign databases from scratch, there are better choices than either SQL or some unproven 1960's idea.

Re:they'll screw this one up as well

[leandrod]

> Don't tell me what I'm thinking.

Yet I can tell you are committing a serious logical problem in equating SQL to relational.

> SQL is a query language, not a database system.

A database system is defined by the language it supports. SQL systems are not, and cannot be, relational systems, because SQL violates fundamental principles of the relational model.

> the kinds of database engines that are sitting underneath SQL are what Microsoft claims they want to put into the file system.

Agreed.

> you and Alphora's marketing department think that.

Me, Christopher J Date and Hugh Darwen. And everyone I met that knows both the relational model and Dataphor. If you don't believe me, go to their web site.

If you don't know who they are, hint: you should before you say anything about relational databases.

> evidence that any more "pure" relational query language than SQL is better is thin at best.

Hm? Is set theory and predicate logic enough evidence for you?

> there are better choices than either SQL

Indeed: the relational model.

> or some unproven 1960's idea.

Unproven? Let me see. This idea single-handledly changed its field overnight, obsoleted all other practices, forced everyone to redefine not only their ideas but their concepts and the very terms and methods they used to think about databases. There were three successful implementations, and more are coming. It has produced the clearer writings in the field ever, indeed some of the best CS literature ever.

1.960's? OK, let's throw away Math, after all it's how many thousand years old?

Re:they'll screw this one up as well

[g4dget]

A database system is defined by the language it supports. SQL systems are not, and cannot be, relational systems, because SQL violates fundamental principles of the relational model.

I think any reasonable database system and query language should be Turing complete. That means that, no matter what front-end you put onto it, you can express the same queries in it. And since they have to solve the same problems, any reasonable database system better perform well on those problems, too.

Yet I can tell you are committing a serious logical problem in equating SQL to relational.

I'm not equating SQL to relational. I am saying: SQL is just a query language.

Unproven? Let me see. This idea single-handledly changed its field overnight, obsoleted all other practices, forced everyone to redefine not only their ideas but their concepts and the very terms and methods they used to think about databases.

You're contradicting yourself. On the one hand, you claim it single-handedly changed the field, on the other hand, you claim nobody is actually implementing it. Which is it?

Hm? Is set theory and predicate logic enough evidence for you?

No. Good theoretical foundations are neither necessary nor sufficient for building good practical systems. Turing machines, for example, are wonderful and well-founded theoretical models of computation, yet we don't use them as the basis for designing programming languages.

Furthermore, there are many other ways for translating set theory and predicate calculus into database systems. Date and Darwen's approach seems woefully dusty and cumbersome; those guys are stuck somewhere in the 1960's, and they completely muddle up issues of syntax, data representation, algorithms, and abstractions.

Re:they'll screw this one up as well

[leandrod]

> any reasonable database system and query language should be Turing complete.

Not necessarily. Turing completeness is required basically for the definition of operators on new types. I agree that modern RDBMSs should have this.

> no matter what front-end you put onto it, you can express the same queries in it.

You are thinking programming. Yes, you can program anything. But if you don't comply with the relational model, you get no performance improvements, no ease of use, no data independence. Please study the relational model, you will see what I mean.

> On the one hand, you claim it single-handedly changed the field, on the other hand, you claim nobody is actually implementing it. Which is it?

Both. There are people implementing it, I pointed to three existing implementations, one of them modern. If you cared to visit the URL I pointed you too, you would see other projects.

And even if these implementations were and still are overshadowed in the market by SQL, whatever qualities SQL still have were inherited from its imperfect foundations on the relational model. Too bad marketroids got in the way.

> Good theoretical foundations are neither necessary nor sufficient for building good practical systems.

Man, where do you live? The moon? You do not know what you are talking about. Ever heard of Dijkstra's contributions, just for an instance? Not to mention that yourself just used Turing as a model to evaluate a language...

Also, it is clear you don't realise the power of the relational model. Please do your reading. This is not only programming. It is about providing a useful, agreed-upon, powerful, logical, abstract data model.

> there are many other ways for translating set theory and predicate calculus into database systems.

For example?

> Date and Darwen's approach seems woefully dusty and cumbersome; those guys are stuck somewhere in the 1960's, and they completely muddle up issues of syntax, data representation, algorithms, and abstractions.

Huh? And what better appeared since the 60s? Do you have a pointer to prove your muddling up allegations?

It is crystal clear you never read them properly if at all. Either that or your thought is too muddled by OO to be able to analyse the issues at hand.

Re:they'll screw this one up as well

[g4dget]

Man, where do you live? The moon? You do not know what you are talking about. Ever heard of Dijkstra's contributions, just for an instance?

Systems don't become usable by having a good theoretical foundation, systems become usable by taking into account principles of cognitive science and psychology in their design, and by adapting to the needs of their users over time.

Huh? And what better appeared since the 60s? Do you have a pointer to prove your muddling up allegations?

Object oriented databases, functional databases, knowledge representation systems, and logical databases, to name just a few.

It is crystal clear you never read them properly if at all. Either that or your thought is too muddled by OO to be able to analyse the issues at hand.

Fortunately, these things will not be decided by your insults or put-downs, but by the market. And I don't see anything replacing SQL when it comes to the preferred language for querying relational databases because, while SQL isn't much of a language, people know it and it has evolved to the point where it gets the job done. I do, however, see an increasing reliance on non-relational databases in the market.

Re:they'll screw this one up as well

[leandrod]

> Systems don't become usable by having a good theoretical foundation, systems become usable by taking into account principles of cognitive science and psychology in their design, and by adapting to the needs of their users over time.

We are not talking in the same level here.

What you say is valid for a user interface. I am interested in the conceptual level. Both are right in their own spheres, but no user interface can fix a flawed concept.

Moreover, fixing flawed concepts with user interfaces leads to feature creeping and bloat. As can be seen with SQL and associated tools.

> Object oriented databases, functional databases, knowledge representation systems, and logical databases, to name just a few.

Taking a hint from Fabian Pascal, none of these are sane. Either they do not qualify as general data models, or they get important characteristics wrong.

Try comparing any of them with the relational model. Try naming advantages. You cannot, because there are not any.

People who advocate alternative so-called models generally never understood the relational model in the first place, and usually did not even understand what a data model is.

> Fortunately, these things will not be decided by your insults or put-downs, but by the market.

Sorry if you feel insulted, but it is my way of trying to make you see you need to educate yourself.

But that the market decides is usually unfortunate. Just see LISP vs C, IBM vs many others (in mainframe era), MS vs open systems, NeWS vs X, SQL vs relational.

> I don't see anything replacing SQL when it comes to the preferred language for querying relational databases

You seem to be carefully avoiding the point that SQL is not relational anymore. From the start it was only a contrafaction of the relational model, adding lots of complexity and arbitrary restrictions. And now, just when it was finally acquiring relational completeness, it has ditched the relational model completely, not even using relational concepts, much less terminology, in the standards documents.

> while SQL isn't much of a language, people know it and it has evolved to the point where it gets the job done. I do, however, see an increasing reliance on non-relational databases in the market.

That proves again you do not understand the identity and the power of the relational model. People use non-relational databases, obviously, because SQL itself is not relational. But people use aberrations like OODBs and the such because they do not understand that what they are looking for beyond SQL can be better found, and much simpler too, in the relational model.

WSH

[lseltzer]

Most of these capabilities are already in Windows Script Host, which has been standard in Windows for years. What's new, I suppose, is that this version is based on the .NET Framework.

Re:WSH

[lseltzer]

Macro viruses aren't usually based on WSH, but on internal scripting in applications. WSH is very popular among Windows system administrators.

Re:WSH

[lseltzer]

Interesting point. If WSH were part of the command interpreter it would be a shell, but would there be any real functional difference?

Apart from modest improvements in batch programming, MS has kept the scripting out of the command interpreter. Perhaps this new shell is a move to the UNIX style of integrating the shell and scripting environment. Or maybe the ad is misleading.

This validates the UNIX way of doing things ...

[RNG]

For years now MSFT has said that their platform is more user friendly by providing nice GUIs for all admin modules.

For them to turn around and now build this super-shell basically amounts to admitting that a GUI based aproach does have some serious shortcomings and that the UNIX way of allowing everything to be scripted provides serious benefits which are hard to come by if everything is accessed through a GUI. If nothing else, this validates the UNIX way of doing things and should make it easier to argue this point when competing for (a) large (number of) server installs/farms.

Re:This validates the UNIX way of doing things ...

[iggymanz]

Wait till a certain Unix-like OS takes over Europe, Asia, and India, because it can run on very cheap equipment yet support the latest networking & languages, and doesn't require licensing or upgrade fees. 90% of the world will not be using Microsoft in 5 - 10 years.

Re:This validates the UNIX way of doing things ...

[SecretAsianMan]

For years now MSFT has said that their platform is more user friendly by providing nice GUIs...

It is important to note that they aren't dumping GUI-based administration. They're keeping it and providing hooks into it from a CLI. So it's not so much an admission that CLIs are better at everything; it's an admission that CLIs are better at some things, if implemented in a certain way.

this validates the UNIX way of doing things and should make it easier to argue this point when competing for (a) large (number of) server installs/farms

Depending on how well this is all integrated, Microsoft may make this argument a tough sell yet. They could point to the non-OO, non-XML, non-other-buzzword nature of the UNIX way, and they may also point out deficiencies of UNIX graphical administration utilities.

you are absolutely right

[g4dget]

MS is #1 for a reason: they do what the users want.

Yeah: they collect every possible feature under the sun into a gigantic feature list. Then they hire away a number of experts from other companies that feel constrained not to be able to do what they wanted to do at their previous jobs and give them lots of money and programmers. And instead of having to compete for market share with their ideas, they just get to dump whatever they come up with into the Windows distribution. The result spells out "second system effect" in big letters.

Good design requires restraint and tradeoffs. It requires figuring out how to pick a small set of features that get most of the work done. It requires actually competing in the market place, where not only dysfunctional systems fail to find acceptance, but also systems that are too complex and big for mere humans to figure out. Microsoft completely lacks the taste, corporate culture, or ability to make those tradeoffs.

But you are right: this approach is indeed why they are number one. There are many morons out there who do indeed think that the longest feature list is what makes a system good.

Re:you are absolutely right

[g4dget]

I think that they DID make that tradeoff. I'm sure that by building a very solid GUI first wasn't accidental.

Leaving aside the question of what a "very solid GUI" might be or whether Microsoft can even remotely be argued to have one, you are ascribing too much long-range planning to Microsoft.

Microsoft responds to the market like a leaf in the wind. All their various approaches to GUIs were driven by a panicky reaction to competition. Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT. RDP was an attempt to clone X11's remote access features. And their latest, C#/CLR is basically a Java clone.

Now, Microsoft feels extremely threatened by Linux, both on the client and on the server, and they are desparately trying to clone the essence of Linux so that their servers won't become completely irrelevant.

Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.

Re:you are absolutely right

[NineNine]

Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.

Well, I can't get inside of Gates' head, so I can't say for sure, but I'd find it a tremendous stroke of luck if a company could go from nothing to the largest on the planet in 20 years by doing nothing but kneejerk reactions to competitors.

Re:you are absolutely right

[g4dget]

but I'd find it a tremendous stroke of luck

It has nothing to do with luck. Embrace-and-extend works if, like Microsoft, you have a monopoly. And Microsoft didn't even earn that monopoly themselves, they got it handed for free by IBM.

Re:you are absolutely right

[Proc6]

Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT.

Yea, really. Copying sucks. Damn those dickhole car makers like Porcshe and Ferrari. They're just copying Ford. And screw that guy who came up with e-mail, what a total rip off of postal mail. And those leeches over at NASA trying to copy all the ideas of science fiction writers. God. What a bunch of losers.

Re:you are absolutely right

[g4dget]

I'm sorry, but you are barking up the wrong tree. My argument was not about whether copying is good or bad; I happen to think copying can be quite good, actually: open source software and biological evolution both involve a lot of copying. I simply pointed out that the Microsoft GUI wasn't created in some long-term master plan, as NineNine claimed, but instead was a long series of short-term reactions to market pressures.

Re:you are absolutely right

[rseuhs]

Well if your mother hangs around with IBM-people and helps you get the one single contract your whole product palette is built on, I would call that "tremendous stroke of luck".

Without IBM licensing DOS, Microsoft would be just another software company.

Re:you are absolutely right

[ninewands]

... and I might add ...

Nicrosoft inked their contract before they even owned DOS. They got a non-exclusive deal from the original developer, signed an exclusive contract with IBM, then went back to the developer and said "We changed our minds ... here's $50,000, we want to BUY it, not distribute it."

Re:you are absolutely right

[Grishnakh]

If I'm not mistaken, Ferrari hand-builds all their cars. They don't use an assembly line because they don't produce enough cars for it to be worthwhile.

Re:you are absolutely right

[g4dget]

Last I checked, Linux was desperately trying to clone Windows

There are several Linux projects to clone the appearance and behavior of the Windows desktop environment, to make people moving from Windows to Linux feel more comfortable. Nobody is trying to clone the Windows software architecture, however: all major Linux environments are properly layered on top of a POSIX kernel and the X11 window system.

so as not to remain completely irrelevant.

Linux is probably costing Microsoft half its server market, and, if anything, Microsoft is falling behind. Now, Linux is making inroads on the client as well.

Linux clients and servers require far less staff to install, support, maintain, update, and secure than Windows clients or server installations. That's in addition to not having to pay the steep Microsoft licensing fees, of course.

Microsoft management is scared, and they have reason to be.

I don't see Windows adding in bizarre installers, removing hardware support, or require convoluted commands for simple procedures like Linux, so I don't know what you're talking about.

Well, it's obvious that you don't know what I'm talking about.

tabs billy, tabs! (aka request for tabs)

[smd4985]

good to see MS will be integrating a cmd-line tool into windows. i'll prolly still use cygwin. anyways, if any MSer is listening, do us all and favor and include tab support. being able to have many cmd-lines in one window is just sweet (thanks you RH 8.0).

sorry, but this won't help Windows either

[g4dget]

they're going to absolutely pummel any competitors on the server end.

Microsoft already has their own scripting environment, and you can already get the most popular shell environments (Bash, Korn) for Windows for free. It doesn't help, because the system just isn't built for scripting.

They've got stability, they've got security, and now they're gonna have good scripting. Wow. Who would'a thunk?

Very funny. XP can be fairly stable and secure--if you dedicate machines to individual tasks and disable most multiuser features. Running Apache and ssh helps, too. But, compared to UNIX and Linux, XP's stability and security are still ridiculously poor. And that's not because lacks features, it's because it has too many features.

Re:sorry, but this won't help Windows either

[leandrod]

> compared to UNIX and Linux, XP's stability and security are still ridiculously poor.

Actually things are not so simple. Desktop environments and graphical applications still crash a lot under GNU/Linux, while rarely at MS-W2K. The OS indeed is more stable, but not the GUI.

Re:sorry, but this won't help Windows either

[hermescom]

" It doesn't help, because the system just isn't built for scripting."

Well, isn't the point here that they're adapting the system for scripting? Making more of the features available via command line?

There's a world of difference between a CygWin environment, which you have to install separately and which can run the handfull of specially programmed utility clones, and the built in, "officially blessed" shell which gives you the run of the system.

The only problem though, is that current windows admins aren't too hot on shelling into a remote system to maintain it. So there will have to be a pretty massive re-education effort for the feature to get used.

Re:sorry, but this won't help Windows either

[the_2nd_coming]

the reason most folks think XP does not crash is becasue rather than trowing up a BSOD, it just reboots the machine. I have had that happen about 3 or 4 times.

Re:sorry, but this won't help Windows either

[g4dget]

Desktop environments and graphical applications still crash a lot under GNU/Linux

Desktop environments like XFCE and IceWM are rock solid, as is the X11 server itself.

Gnome, Mozilla, OpenOffice, and KDE, of course, are works in progress, but no worse in my experience than what Microsoft ships. I still see "Send Bug Report to Microsoft" dialog boxes regularly on Windows XP, while I hardly ever see a GUI application crash on Linux.

Beyond that, there are, of course, plenty of buggy GUI applications for all platforms.

Responsive!?

[Detritus]

The amount of effort Microsoft has put into enhancing and fixing bugs in their command line tools since the release of MS-DOS 1.0 and MS-DOS 2.0 is so close to zero that it generates an underflow error. Bill said many years ago that he doesn't assign programmers to projects unless the project will make money for Microsoft or advance its strategic goals. Making customers happy is not a sufficient reason.

Re:Responsive!?

[NineNine]

Bill said many years ago that he doesn't assign programmers to projects unless the project will make money for Microsoft or advance its strategic goals. Making customers happy is not a sufficient reason.

That's how business works. You can't make every customer happy. That's impossible. Gap can't have a rack of clothing designed to perfectly fit every single individual that comes in there. Not possible. I have a small store. I can't have *every* item that every customer has ever asked for. That's not possible, either. But, at the same time, you DO make money by making as many of your customers happy as possible. That makes 'em buy. Kinda' basic. Contrary to the popular Slashdot opinion, MS doesn't have legions and legions of pissed off customers. If they did, then Apple would be huge today. So I agree, making customers happy alone isn't a sufficient reason, but it is a major part of deciding what to implement when.

Re:Responsive!?

[Anonymous Coward]

Bill said many years ago that he doesn't assign programmers to projects unless the project will make money for Microsoft or advance its strategic goals. Making customers happy is not a sufficient reason.

Do you really think that BillG got to be worth $40 billion by making customers UNhappy? Do you really think that 93% of all end-users are masochists? Do you really think that people in a free market choose of their own free will to buy inferior products?

Or do you suppose that Apple [Macintosh] & NeXT [NeXTSTEP] & Commodore [Amiga] & Novell [DrDOS/NetWare] & Digital [RSTS/VMS/True64] & Sun [SunOS/Solaris] & IBM [OS/2] & Linux [Gnome/KDE] couldn't [and, to date, still can't] get their heads out of their asses for long enough to give the consumer he wants: An inexpensive platform that allows him to copy from a text editor, paste to a spreadsheet, and vice-versa, without having to go back to school to get a goddamned PhD in the minutae of Bourne Shell scripting [much less artificial intelligence, LISP, and emacs]?

Re:Responsive!?

[ninewands]

Actually, Microsoft "doesn't have legions and legions of pissed off customers" because Microsoft tells Joe and Velma Six-Pack "You want this" and they accept it.

You would not believe the number of people out there who honestly think that Windows is the greatest thing since sliced bread (or, in Joe & Velma's case, canned beer) ... and who think that "THEY oughta just leave Microsoft alone and let them make Windows better and neater." Of course they'll also tell you that "The only thing wrong with Windows is ... ooooh, shiny!"

Re:Responsive!?

[ninewands]

Quoth the poster:

Do you really think that 93% of all end-users are masochists?

Quoth Merriam-Webster:

Main Entry: masochism
Pronunciation: 'ma-s&-"ki-z&m, 'ma-z&- also 'mA-
Function: noun
Etymology: International Scientific Vocabulary, from Leopold von Sacher-Masoch died 1895 German novelist
Date: circa 1893
1 : a sexual perversion characterized by pleasure in being subjected to pain or humiliation especially by a love object -- compare SADISM
2 : pleasure in being abused or dominated : a taste for suffering
- masochist /-kist/ noun

Masochist? No ... more like indifferent to pain and suffering caused by being abused or dominated, while being hypersensitive to pain and suffering caused by having to think for themselves. Why do you think PC sales into the home market didn't REALLY explode until Windows (specifically Windows 95 OSR2 (which was Microsoft's first really internet-capable OS)) was released?

Just my US$0.02

Re:Responsive!?

[Grishnakh]

As a proud owner of an Acura, I find your equating of Acura (only one 'c') with Microsoft very insulting. My Acura has never broken down for no reason, the dealerships give great service, they have excellent engineering in them, and there's nothing gay about them (like those MSN commercials).

Re:What the...

[Anonymous Coward]

This and all of the similar idiotic comments just goes to show how little the /. crowd knows. Reading even the summary of the article shows how untrue this is. bash has command discovery via reflection API's? Really? It can discover commands by any other mechanism than searching the path? I think not.

They're talking about discovering which objects are installed on the system and finding which API's those objects expose, all from the command line. Sounds very much unlike bash to me.

I currently use cygwin bash and bash on FreeBSD, and the description of this new MS shell sounds way better.

This really goes to show why Windows will "win": Everything Windows does could be done on a Unix box. Absolutely everything. But it isn't, and it won't be. Here's why: There's no agreement among the developers on the Unix platforms. Sure, I could write a command shell on FreeBSD that has some sort of similar discovery mechanism, or I could write a GUI and a few apps that allow embedding parts of spreadsheets inside of word processing documents, but what have I gained? Not a whole lot. No one else will follow my lead, so my work will die. On Windows, MS does a reasonably good job of things like this and all applications jump on the bandwagon, and the users profit from it.

I would imagine....

[inode_buddha]

...that they would call it "Bush"?

in theory, but not in practice

[g4dget]

Yes, there are plenty of command line tools for system administration that come included with Windows. Nominally, you can do pretty much everything with them that you can from the GUI. In practice, however, you can't.

First of all, since most people use the GUI most of the time, if you want to move on to scripting, you have to learn both entirely new commands and figure out how to script them together. Not even the concepts and paradigms of how to manipulate the system are easily mapped onto one another.

Also, the command line tools don't seem to keep up with what's in the GUI, and any third party components that require administration often don't come with command line tools at all.

Finally, Windows doesn't ship with a lot of the glue necessary to make scripting work. Apart from the pathetic cmd.exe, most devices are not accessible through the file system and many important command line programs are just missing. Some come and go (NT used to come with pax.exe, but it seems to have disappeared now, leaving no archiver around).

Possibe names for the shell

[The_Mutato]

The candidates are as follows:

Command-line Remote-capable Advanced SHell (CRASH)
Microsoft Advanced SHell (MASH)
Synchronous Multi-user Advanced SHell(SMASH)

What is YOUR favourite?

Re:Possibe names for the shell

[handsomepete]

MY favorite?

Windows Extensible Argument Related Event Activator Made On Needlessly Over Programmed Object Languages Yesterday

Yes, I know. I am a huge loser.

Re:Possibe names for the shell

[Simon Kongshoj]

True Redmond Advanced SHell (TRASH)
Let's Emulate A SHell (LEASH)

The problem with re-inventing the wheel...

[crovira]

is the desire to make it square, so it won't roll away, and to later enhance it by making it triangular thereby eliminating one bump.

M$ seems to have an absolute overarching need to make everything and anything all their own. Not better just their own. It just takes them three tries at anything before customers stop asking that it work properly.

Just reply that their marketing division has succesfully polluted M$'s own resource pool since schools curricula now only teach operating systems as "How to sys admin with Windows NT"

Comment removed

[account_deleted]

Comment removed based on user account deletion

Virus delight

[corvi42]

Wow, a hugely complex scripting environment with hooks into every aspect of the OS.
Virus writers - here is your big chance to spread like wildfire through windows machines!
.... Again!

Re:Virus delight

[0x0d0a]

Wow, a hugely complex scripting environment with hooks into every aspect of the OS.
Virus writers - here is your big chance to spread like wildfire through windows machines! .... Again!

I wish CIOs would figure out that when MS says "integrated" they generally also mean "insecure"...

Re:MS is responsive: that's why they're #1

[NineNine]

Pasted from a great AC post higher up in this thread. He's already said it better than I could:

Do you really think that BillG got to be worth $40 billion by making customers UNhappy? Do you really think that 93% of all end-users are masochists? Do you really think that people in a free market choose of their own free will to buy inferior products?

Or do you suppose that Apple [Macintosh] & NeXT [NeXTSTEP] & Commodore [Amiga] & Novell [DrDOS/NetWare] & Digital [RSTS/VMS/True64] & Sun [SunOS/Solaris] & IBM [OS/2] & Linux [Gnome/KDE] couldn't [and, to date, still can't] get their heads out of their asses for long enough to give the consumer he wants: An inexpensive platform that allows him to copy from a text editor, paste to a spreadsheet, and vice-versa, without having to go back to school to get a goddamned PhD in the minutae of Bourne Shell scripting [much less artificial intelligence, LISP, and emacs]?

Re:What about this one?

[Lumpish Scholar]

That ad is also interesting in several ways; but Windows Services for Unix is old news (warning: MSFT hype ahead):

... provides a universal environment in which to run both Windows and UNIX applications on a single system.... reduce development time while leveraging existing employee skills sets.... a UNIX environment that runs on top the Windows kernel, enabling UNIX application and scripts to run natively on the Windows platform alongside Windows applications.... you can continue to get value out of your UNIX scripts and applications -- simply reuse them on Windows.

Also old news are the Posix subsystem within Windows, and Microsoft claiming Posix compliance; the first in support of the second, and the second to get around U.S. government requirements for Posix-compliant solutions. For example (I think):

Windows NT has a minimum level POSIX compliance and has become the de facto client/server standard for small server requirements because of widespread usage.... Windows NT has been chosen as the server with the best workstation/small server capabilities. SUN Solaris' UNIX will continue as the operating system choice for enterprise or robust solutions....

Previously, most of Microsoft's Unix-like stuff has been standalone, unable to integrate with the rest of "the Win32 subsystem"; maybe that's changing.

P.S.: I accidentally discovered that the native command line interepreter in Windows XP has a decent filename completion feature. Without thinking, I hit tab to complete a file name, and it took me a minute to notice that it worked even though I wasn't using bash.

Damn...

[torpor]

Microsoft: We Invented the Shell in 2003.

I worked at a large (1000+) NT consulting shop

[alexhmit01]

We had some engineers working on a project that was going to involve migrating 2000 users. They were all trained MCSEs, and they going to migrate 2000 users by hand. When I showed them all the command line tools that came with the NT4 resource kit, they were floored. We put together some batch scripts and saved the clients some money.

Point-and-click Admin GUIs are really convenient. If you are doing one user, or something similar, it is easier than remembering command line arguements. There is nothing inherently superior about a text based approach to graphical. You need to understand what you're doing, arguements vs. icons is irrelevant.

However, when you have a LOT to do, and you want to do it based upon a list of names, CLI is the way to go.

The group with the slickest solution is Apple w/ Applescript. Instead of separate GUI and CLI versions (NT), or CLI with GUI wrappers (Linux), it's all integrated. The applications can accept arguments while running or while not running. There is no reinvention of the wheel or duplication of effort.

Alex

Re:I worked at a large (1000+) NT consulting shop

[Cylix]

Thats a design implementation, not a feature locked into by any particular operating system.

Take for instance xmms (an mp3 player for linux which uses winamp skins), this program takes both command line arguements and the typical mouse clicks.

I generally log in to the box upstairs and change tracks from my laptop without using X sessions. Any gui based application can be targeted to function in both cli and gui mode, many do, but its simply a chocie for the author.

Re:I worked at a large (1000+) NT consulting shop

[spongman]

windows already has this, it's called WMI. the remotable command-line tools, the MMC GUIs and the scriptable COM interfaces all use this for remote administration.

Pervasive Autocomplete

[SteveX]

This is an excellent idea, bringing this to the shell.

If you look at the command prompt in VS.NET you'll see some of this technology today - you can type "Project." and get a list of things you can do with the current project... If you want to do a build you can type "Build.BatchBuild". If you type "b.b", down arrow, return, you've done the same thing with 5 keystrokes (the autocomplete fills in the rest). Same number of keystrokes that typing "make" and hitting return takes.

Difference between this and typing "make" is that when I type "Build." I get a list of things I can do with the current build - it becomes an object oriented command line. It's pretty nice once you work with it a bit - You want to work with the current project (add a file to it for example) type Project. and look at the list - same for File. Debug. etc

Interesting thing about this new shell that Microsoft is talking about is it will take capabilities ALREADY exposed by most Windows apps (through OLE automation) and make them available at the command line. If I could type this in a shell:

$Word=CreateObject("Word.Application")
Word.Fil eOpen "my.doc"
Word.Print
Word.Quit

Then I can print a Word document, using Word, from shell (and without ever seeing Word) using the same scripting interface available to VBScript (etc).

Most Windows apps support scripting (even non-MS apps). It's getting at this functionality from the shell that's new here - something I don't think there's any Unix equivalent of yet.

- Steve

Re:Pervasive Autocomplete

[the eric conspiracy]

something I don't think there's any Unix equivalent of yet.

Hmmm, then what might AppleScript for OS X be?

Answer:

AppleScript is an object oriented scripting langauge that is capable of controlling applications, discovery of methods using reflection, etc. It supports a variety of languages through the Open Scripting Architecture. There are hooks into the MRJ (Macintosh Java Runtime). It even supports interacting with web services in the scripting environment.

And it is here today. On OS X, clearly a flavor of UNIX.

Here is a brief blurb from Apple's developer site on one of it's capabilities:

Java Methods as AppleScript Commands

Most method calls on a Java object are available as AppleScript commands. In the dictionary displayed by the Script Editor, each Java class is listed in its own suite with an AppleScript class representing the Java class and a list of commands in that suite that correspond to the methods.

Re:Pervasive Autocomplete

[SteveX]

I think you answered your own question there.

"AppleScript is an object oriented scripting langauge".

We're talking about things you can do in a shell - writing a script, saving it and running it isn't quite the same thing.

Re:Pervasive Autocomplete

[the eric conspiracy]

Most scripting languages also supply a shell. Here is one for AppleScript.

http://www.macosxapps.com/article.php?story=2002 06 04102147364

POSIX compliance ?

[InodoroPereyra]

I wonder if the shell will be POSIX compliant. I anticipate it will not be. Why ? The key to MS's monopoly is to create their own versions of standards. That is, to destroy standards and force people to use software that understands their "standard". Note that they do not mention "knowledge of POSIX" as a requirement in the job announcement.

Re:POSIX compliance ?

[papasui]

NT is already posix.

Re:POSIX compliance ?

[iggymanz]

Not really, it had a broken implementation of Posix 1.0 that was fairly useless...there was a company called Softway that made higher level Posix API & tools for NT, for $199, but even then one still had to buy yet other add-ons for basic built-in Unix services....like they had Telnet server for $99.

Can they get serious?

[Ektanoor]

For YEARS they have been slowly but surely killing the shell world. They were so prone on such trend that they:

Didn't develope its command line interfaces since the beginning of the 90's.

Didn't support implmentations of more advanced scripting tools like perl or python.

Claimed for years that shell suxxx. They marketed their system as a growing evolution from the crippled shell environment.

Granted that, in the future, all management would be through the GUI.

And now I am hearing that they are getting back to the start?

Interesting. I have seen several interesting things while I developped for Windows. and one of the things I was pretty sure, was that implementing shells or scripting tools was hard. Perl (native Win32) or bash (through cygwin) gave me always a sense of a certain handicap in relation on the *NIX world, where most of its control was based on the existence of shells. I could not get into the inner mechanics that ruled many Windows apps because their data was never supposed to be handled directly by shells. Note that many apps produce binary data, even when there is no clear need for it. So, if one needs to use perl or something similar to handle Windows data, one usually needs an interface or some tweaking on files. And, due to the fact that Windows lacks established standards for (almost) similar kinds of data, one needs to deal with different tools to deal with each piece of data.

A similar situation occurs also with file formats. Sometimes, the format of different versions of one and the same program varies so radically, that one is forced to deal with different interfaces for each version. That's also one of the reasons whyscripting tools didn't gain a wide acceptance in Windows.

Also one problem is that many programs on Windows base their interaction in a memory-to-memory basis, while *NIX still keeps a lot of its interchange in a filesystem basis.

So I am scheptic that M$ is able to do a serious move on this field. However I may understand why they are moving with a new scripting system. Frankly, with all the mess they created, perl and many other tools will never be able to have a fullscale use on Windows like in *NIX. But that depends on how far M$ will go on the development of this new system. If they will create some sort of Easy-VB-like scripting tool, it will not catch the souls of sysadmins. If they create a full-scale mutant like perl, they risk to give a new weapon for script-kiddies, but sysadmins will surely catch the wave.

Re:Can they get serious?

[sql*kitten]

Didn't support implmentations of more advanced scripting tools like perl or python.

Actually, Microsoft paid for ActiveState to port Perl to Windows.

Note that many apps produce binary data, even when there is no clear need for it.

That's because Microsoft's way of saving things to disk is just to persist the COM object that represents your Word document (or whatever) in RAM. It's more accurate to say that MS don't convert documents to text when there's no clear need for it.

So, if one needs to use perl or something similar to handle Windows data, one usually needs an interface or some tweaking on files.

That's what COM, OLE2 and COM+ are for. The scriptability of Office and other Microsoft apps is really surprising. You can write a trivial VBscript to query SQL Server, graph the results in Excel and paste them into a Powerpoint presentation, all automagically.

And, due to the fact that Windows lacks established standards for (almost) similar kinds of data, one needs to deal with different tools to deal with each piece of data.

You will find that COM et al are very well documented. Remember that to a significant fraction of the developer world, perhaps even a majority, Microsoft is the standard.

Sometimes, the format of different versions of one and the same program varies so radically, that one is forced to deal with different interfaces for each version.

Doesn't matter - the COM interface is the same! In Unix you would have to rewrite your parser if the format changed!

Frankly, with all the mess they created, perl and many other tools will never be able to have a fullscale use on Windows like in *NIX.

Have a look at the Win32 modules in ActivePerl. You might be surprised at how complete they are.

Bill's reading /. :-)

[KjetilK]

Anonymous reader, yeah sure! I mean, posting this job advert on slashdot, what would that cost? I'm telling you, this is Bill posting job adverts disguising them as "new features"! :-)

new restrictions?

[kipple]

I fear that they will put this new shell only into new OSes, or into service packs with strong licenses that will allow them to, say, apply DRM on your data without your agreement.

Then the vast majority of slashdotters will rant to defend their privacy, but will install it because it's useful or it's required at work, thus giving up another bit of their rights.

An alternative...

[kennylives]

Is to use good-ol cygwin and set up the sshd on the windows machine. I do this to all my boxen, and it works great.

Huh?

[Rogerborg]

Hasn't Amazon got a bunch of patents on this?

Re:MS is responsive: that's why they're #1

[the eric conspiracy]

Do you really think that BillG got to be worth $40 billion by making customers UNhappy?

Bill Gates got the opportunity to be worth $40 billion because he convinced Lotus to write 1-2-3 for MS-DOS rather than CP/M.

MacOSX, Applescript and why MS is doing this.

[theolein]

OSX has some of the functionality mentioned here in it's netinfo database, and system and programme defaults can be set through the defaults command which is based on xml. Applescript is a good glue between the CLI , System and other software.

What is interesting is MS' motivation behind this. It does seem as they are of the opinion that having an amazing shell will pull all the OSS crowd over to using Win instead of Linux/BSD/*NIX. Why I think it won't work, at least in the first few iterations, are because:
a.MS still has that licence problem which they would rather die than let go of.
b.You still have to pay extra $$$ for the whole bundle of extraneous shit that you don't need.
c.It will still be easier to script apps in VBA. 80% of the extra cludge, OO this , reflection that etc will go unused.

Re:Learn how to use your apps

[Gordonjcp]

Because I don't have one. I don't want to go and get one either. Really, why would I want to learn how to use a piece of new software when the CLI version does it perfectly well?

Re:Micro-Kernel in MS windows !

[spongman]

my ntoskrnl.exe is 1.8MB.

MS was at USENIX/SAGE asking what makes a good CLI

[furry_wookie]

FYI.. .I was at the USENIX/SAGE L.I.S.A Confrence 2002 in Philly a few weeks ago, and some guys from Microsoft had a late night get together to talk to us unix people. I couldn't not go, after all it was Microsoft at a 100% NIX-only event, so I figured some fun would be had at their expense.. It was called: UNIX + Windows Admin Management with Scripting & Command Line: What are your requirements?, and was on thursday night. The point of the meeting is that, they wanted to know from UNIX admins what makes a good Command Line environment and what it would take to make Windows have as powerfull a CLI as Unix. They pretty much told us that there is a LARGE high-level project at Microsoft to make Windows servers to be as easy to manage and configure as Unix servers from a serial port with no gui required. What is their REAL goal: From what I could tell its simple... they want to eliminate the competitive advantage that UNIX has with the CLI. That this away from NIX as a "advantage", then thats one less think people can point to as something that Windows lacks. They want to be able to honsetly say... "Unix isnt any easier/more-powerful on the CLI than Windows." After all, that is one of the SINGLE LARGEST differences there are today between their product and NIX. Take that argument away, and you have a huge marketing/argument weapon against us NIX people.

Uh oh

[Andrewkov]

I'm I the only one concerned about the next version of Windows having these abilities:

a very rich object-based mechanism for managing system properties

and:

transparent remote execution.

Given Microsofts dedication to security, this scares the pants off me.

Re:Uh oh

[spongman]

windows has had all of this since win2k. the security model is based on kerberos.

Wouldn't it be interesting ...

[ninewands]

I defy Microsoft to be able to prove that a developer with " ... Windows NT or Windows 2000 system programming experience, ... as well as with scripting and shell languages like PERL, Python and Bash." and "2-5 years experience in high technology, preferably delivering products for both Windows and non-Windows operating systems." to be able to PROVE that any similarity to bash arose in a "cleanroom reverse engineering environment."

Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL ... it's be Microsoft's worst dream come true ... <VERY Evil Grin(TM)>

Re:Wouldn't it be interesting ...

[MobyTurbo]

I defy Microsoft to be able to prove that a developer with " ... Windows NT or Windows 2000 system programming experience, ... as well as with scripting and shell languages like PERL, Python and Bash." and "2-5 years experience in high technology, preferably delivering products for both Windows and non-Windows operating systems." to be able to PROVE that any similarity to bash arose in a "cleanroom reverse engineering environment."

Bash is not so original (bash = bourne again shell - i.e. it is a superset of yet another shell) that it can't be cloned, there are plenty of other shells available in *nix that have some of the same command line completion or better, and much of Bash's command language is a superset of the POSIX shell, an open standard that M$ can clone with impunity. That having been said, their intention to meld it with .Net says that it probably won't be a Bash clone but rather something more propritary; and they'll probably mix it with some monstrosity like VB or C#.

Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL ... it's be Microsoft's worst dream come true ...

Don't be rediculous, considering the GNU (now ended) boycott of Apple platforms when Apple were suing about look and feel, they are unlikely to do the same. Besides, if you were familiar with the similarities of bash with other shells such as tcsh, the korn shell, zsh, and POSIX sh, you wouldn't be so confident that it's look and feel is protected by law.

Re:Wouldn't it be interesting ...

[Patrick]

to be able to PROVE that any similarity to bash arose in a "cleanroom reverse engineering environment."

First, MS wouldn't have to prove this. The burden would lie on GNU to demonstrate illegal copying of code. They might be able to subpoena pieces of Windows code to do line-by-line comparisons, but don't count on it.

Second, there are lots of people out there who have programmed in Perl, Python, and bash without ever bothering to look at the source code behind them. Including me. I could go take this job (Yay, India!) without any risk of tainting MS code with Perl, Python, or bash sources.

Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL

Imagine spelling "Stallman" properly. :P

Imagine a standalone command-line interpreter getting "infected" and the remainder of Windows remaining "clean." MS grudgingly ships code to, gasp, the equivalent of xterm+bash, and no one cares.

Imagine a judge realizing that stopping shipments of Windows is an extreme measure and finding some lesser solution. Companies (Stacker and Sun, to name two) have won lawsuits against Microsoft before, but not to the point that they've blocked sales of DOS or Windows.

Microsoft already ships Unix code (Interix), old Mosaic code (IE), and Perl. Shipping something with syntax slightly similar to bash is unlikely to be a problem.

Re:Wouldn't it be interesting ...

[alfaiomega]

Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL ...

Bihl Gates would really pissed off!

(Sorry, I couldn't refuse...)

Re:Ignorance is not existence

[SteveX]

I'm not ignorant of OS X - I actually have commecial shipping OS X software - but to my knowledge, you can't use AppleScript directly from a command shell, can you?

Scripting isn't the same as a command prompt...

Sweet justice

[stinky wizzleteats]

For years I've had friends who think I'm an idiot for not swallowing the blue pill (MCSE), and instead insisting on learning Linux and the requisite scripting languages to work in it.

It warms my heart to know that those brainless, cert-chasing mercenaries will have to learn Perl. Bwahhahahahaha!

Re:What the...

[CoolVibe]

This and all of the similar idiotic comments just goes to show how little the /. crowd knows. Reading even the summary of the article shows how untrue this is. bash has command discovery via reflection API's? Really? It can discover commands by any other mechanism than searching the path? I think not.

tcsh can. Guess the problem is still solved. tcsh can expand command from other 'completors' other than just the $PATH. Like, type mount somehost: and it will try to expand from the output from 'showmount -e' for example. Granted, they aren't reflection API's but that's just another buzzword to me :)

What this will come down to...

[shatfield]

When Microsoft Windows can do everything that a *nux box can do, and a *nux box can do everything that a Windows box can do, then it will all come down to what you value as a person.

Right now, the majority of the people in the world seem not to value anything, just being able to read email and browse the web. When Microsoft really steps up their customer abuse, which we've seen the first signs of, that's when the *nix boxen will start seeing some new users.

Microsoft is their own enemy.

link checking on IE

[TheLink]

shift+left click is your friend[1] :).

There's also ctrl+enter for addresses - type google in the address bar and press ctrl+enter

[1] But javascript links usually won't work.

Bullshit

[BierGuzzl]

First of all, the appeal for candidates looks to be directed at developers who have experience in multiple operating systems, not at all a direct call to unix developers.

This is also not the first time that Microsoft has pursued technologies that are similar to unix.

From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:

XENIX

<operating system> A commercial version of {Unix} for
{microprocessor}-based computers, released by {Microsoft} in
1980. In 1992, {SCO} became Microsoft's co-development partner
and the alternate source for the product.

(1999-12-07)

ThumbNailer

[Smallest]

http://www.smalleranimals.com/thumb.htm !

The job is indeed in India

[Doug Merritt]

the job listing was most likely a job in redmond washington, but posted in an indian job listing to specifically recruit indian guys.

It's not necessary to carefully avoid reading the very short page that this story is about. It's not necessary to make a (completely wrong) wild speculation that is trivial to double-check just by glancing at the final line of the job posting. It's not necessary to embarass yourself in public. The final sentence of the job posting says:

This position is in Hyderabad, India.

Of course, this is the first time anyone on Slashdot ever posted something incorrect without reading the story in question, and doubtless no one will ever do something that silly ever again.

Microsoft LISA 2002 Scripting BOF

[tubaman24]

Jim Truher from Microsoft had an informal Birds-Of-a-Feather session at LISA 2002. I showed up because I wanted to see this guy squirm a little (LISA is almost all UNIX/Linux folk). He claimed to be one of the designers of this new shell and he wanted our input about the most needed features. He mentioned created a language similar to PERL only better(i.e. proprietary). Full transaction support was suggested as well to allow a multilevel "undo" capability.

I think this time it's to late...

[Qbertino]

M$ allways gets the message when their cornered.
Same as back then with IE, to name a prominent example. That's because they've actually got a personality as CEO. Yes, say what you will, but Billyboy and Steve'O. they're personalities - have to give them that. They will finally put an effort to making their inhouse OS transparent for scripting, automation and chain processing and other usefull stuff like that. But I'm certain this time they're to late.
A year and a half ago they could have bought RedHat and published a Linux distro and nobody would have even guessed that Linux isn't an M$ projekt and is available for free. But M$ chose to bitch about licenses and get people aware that there is something besides M$. They could have done this new OO shell and OS aproach thing, called that .Net and would have actually had something usefull to brag about.
But now I don't think that M$ can pull the wagon around anymore. OSS alternatives to Mickeysoft are here and here to stay. And they will never go broke.

Re:Micro-Kernel in MS windows !

[jeffphil]

my ntoskrnl.exe is 1.8MB

That won't fit on a floppy. See Coyote Linux.

Not the main problem to me.

[TheLink]

The main thing I want from a filesystem is to store data and be sure I can retrieve it.

Look at how long it took to get the critical NTFS bugs fixed. All those NTOSKRNL corrupted errors whoopee - how can a _kernel_ file get corrupted or become inaccessible so easily? By service pack 4 thru 6a things started getting better but then it became "Win2K or die time".

By the time/before their db filesystem becomes safe to use they'll have moved the goalposts yet again.

Re:Not the main problem to me.

[leandrod]

> By the time/before their db filesystem becomes safe to use they'll have moved the goalposts yet again.

If it was (it will not be) a true RDBMS, not a half-baked SQL or OO contraption, it would be safer than anything in existance.

it is not CLI vs. GUI

[StrawberryFrog]

OK, guys, get a grip.

1) The fact that CLIs are good for some things does not mean that GUIs Are Bad (tm). GUIs are brilliant for some things (try playing chess or working Photoshop/Gimp via a CLI) and CLIs shine for other things (notably here, batches and scripting).

2) I wouldn't call this a "change of direction for microsoft" as I really don't think that this will mean a significant slowdown on MS's GUI-related activities. If you will, it is the great amoeba expanding in yet another direction at the same time.

Often, MS doesn't have a masterplan - they throw a bunch of stuff against the wall, and see what sticks. If it sells, sell it.

The great Ektanoor, who may not be a troll but does tend to rant when he should listen, claims that "For YEARS they have been slowly but surely killing the shell world". I don't think you need ascribe that any motive other than neglect and lack of enough vocal customers asking for it (they were no doubt too distracted by the shiny gui toys)

Microsoft has a history of picking the low-hanging fruit that are bright and shiny and tempt in the casual buyer, then slowly climbing up to more difficult tasks that thier users ask for.

The way in which this will leverage .NET (like *spits*VBScript could leverage COM objects) is interesting, and could be worthwhile.

I don't want to even think about the security implications right now.

No. You Can't

[Pinball Wizard]

any competent Windows admin could make any W2K machine as stable as any other *nix.

For the simple reason that you need to reboot every time Microsoft comes out with a security patch. I have Windows Update turned on on my desktop machine and every week there is a new security flaw.

Therefore, to keep an internet connected Windows machine "secure", you are talking weekly reboots. Most of us here consider uptime to be the best indicator of stability, and Windows is a far cry from being the most stable system.

Now, its true there have been security holes found in Linux(about 1/4 the frequency of Windows). But at least you don't have to reboot every time you patch something, unless its the kernel. Most patches are on a higher level subsystem that simply needs to be HUP'ed to begin running the patched code. Not so with Windows.

You unfortunately seem to have confused the desirability of running a Windows desktop system with that of running a server. Depending on what kind of server you are talking about(web, email, DNS, firewall, etc.) Microsoft is nowhere near being the most popular, and its because Unix and Linux servers have proven to be more stable and more secure than their Linux counterparts. And they always will be because ease of use is anathema to security and stability.

A competent admin doesn't need a GUI for these servers, in fact a GUI is just a large chunk of code that gets in the way of what these servers need to do.

Unix poorly faked

[octogen]

So they are going to sell us an operating system, whose API was originally designed as a graphical user interface for DOS, then ported and somehow upgraded to run in hybrid real/protected mode but still on top of some DOS (called Win32), then patched to be multiuser-capable and ported onto a kernel which was originally meant to be something like VMS w/ an OS/2 API until they hacked a Windows API into it (and renamed it as Windows NT), and finally packaged with a pile of user-space programs which let this crap look like a unix shell?

There is so much missing in NT compared to Unix. No VFS-like filesystem, no symbolic links, no device nodes, no setuid/setgid, no privilege sets in the filesystem, ...

Even if you add a really powerful shell environment, it still can't compare itself to modern Unices.

Why don't they throw it all away and build a REAL unix instead of bending some wannabe-unix-stuff round a broken Kernel/API design?

Does a so-called professional server- and/or development-platform really need to be compatible with Windows 95/98/ME/Win32?

Remember this classic line?

[IGnatius T Foobar]

"Given enough time and resources, Microsoft will eventually invent UNIX."

Re:Remember this classic line?

[SecretAsianMan]

"Given enough time and resources, Microsoft will eventually invent UNIX."

They already did. Ever heard of XENIX?

Re:Remember this classic line?

[presearch]

They already did. Ever heard of XENIX?

Yes, I've heard of it. And like most things, M$ didn't
invent squat. (Well, actually they did invent the squat
but that's another story).

XENIX was AT&T Unix v7, with the work done (mainly
doing s/UNIX/XENIX/g) in Toronto by HCR - Human
Computing Resources which leveraged much of the
work from talent at Univ. of Waterloo.

offer access to more functionality than....

[oliverthered]

Current script based viruses have.

Microsoft tends to sand-box things like the costa-blaca.VB-script was a virus writes dream come true, I hope they make a better job this time.

Use of the term "shell"

[Codex The Sloth]

The term shell does not necessarily imply command line shell. That's just the typical unix implementation. In Windows, the Explorer GUI is the shell and the command window is just an application executing in it.

Re:Learn how to use your apps

[sydb]

The Unix 'find' command let's you recursively descend directories and select files and/or directories dependent on several attributes, like name, access/modification timestamp, even content with a little cleverness. Then execute an arbitrary command on each resultant filename. You could easily get it to prompt you at each filename for a Y or N, thus replicating your mouse-click functionality at much-enhanced speed.

If you have your images sensibly filed, then some accurate verbally-expressed command is much faster than vague mouse movements.

I like GUIs. I used to dream of a system which didn't (need to) offer a command line. Since I discovered Unix and unix-like systems, my dreams were exposed as freakish nightmares. I saw the GUI for what it really is - a feedback system for completing ill-defined goals. It's a tool, nothing more, nothing less - use it when it is best fit.

Your 'living in the past' statement makes me think of someone recommending a power drill for driving a nail into a piece of wood. Hammers do that much better, despite their simplicity and antiquity. I don't see hammers disappearing any day soon.

As others have said, GUIs are nice when you don't know what you want to do. The goal is clarified through the feeback loop created by your eyes and the monitor.

If you DO know what you want to do, then just say (or type) it. Then get on with some more interesting business, which is what computers are meant to allow us to do anyway.

Re:Learn how to use your apps

[Gordonjcp]

Well, for starters, your method can't work correctly unless all the files share a portion of their filename or path.

Correct. Fortunately, when I download the memory card from any of the cameras, all the files are in - guess what? - one directory.

I'm not sure what your "living in the past" comment is supposed to mean. I'm choosing the method of working that's most suitable to the job I'm trying to do. Just because something is newer, doesn't necessarily mean it's the best for all jobs.

The Surprising Sheep

[jefu]

On a related topic, does anyone know if the scripting language for the Amiga - "sheep" ever went beyond rumourware?

Smarter Shells == Smarter Admins

[Proudrooster]

May I have your Attention Please: To all the MSCE's who went to the MS mouse wiggling academy, get ready for elightenment, a real scripting language may be coming to a server near you. No longer will remote systems administration require VNC, PC-Anywhere, Windows Terminal Server, or a Webconsole (which works some of the time).

As a person that despises inefficiency in enterprise systems, I have been ignoring all Microsoft technology since it is a Royal PAIN in the arse in terms of administration. Theres nothing I like more than trying to use a GUI over dialup to fix a problem at 2AM. While the Microsoft mouse wiggling academy has produced some of the finest mouse wigglers and mice (that new MS optical mouse rocks), I am glad to see them finally open the door to the smarter administrators that like their hands glued firmly to the keyboard. Taking steps like this may even allow me to integrate Win2K into the enterprise instead of forcing it to live in it's own little world off to the side.

This industry just keeps getting stranger and stranger. No camp seems happy in their current location. Linux wants the desktops and Microsoft wants the servers. I guess all brunettes want to be blondes too, eh? ....

As iron sharpens iron, so one man sharpens another.

Re:What about this one?

[self assembled struc]

I too discovered this, and then learned from one of the Win32 programmers at work that this has been available in the NT command line since 3.51, it's just turned off by default. You have to turn it on via the registry.

security.

[coredumpman]

Is this going to open up a can full of worms for security on windows systems?

New Invention: The Wheel (round 2).

[Eric_Cartman_South_P]

Wow... reflections? I wish Java had tha... oh wait...

Powerfull prompt action? I wish bash had th... oh wait...

I can see it now. John C. Dvorak blurting about how great and flexible it is to "telnet into a box and get a prompt to do anything you want" and how the unix boys almost had it right. And that Java is dead.

Re:regarding "object model"

[RetroGeek]

It is OO fans who love it and the rest who say "whatever".

If you have done any serious programming over any real length of time, you tend to do OO programming whether you call it that or not.

Grouping variable names using a prefix, allocating and initializing structures using a function, operating on those structures using well defined functions, etc.

These are OO concepts without the formal OO architecture.

Extended conversation

[Anonymous Coward]

behold, the MS 40 year unix-recreation plan!

Unix sux. lets hack out all of this bloat.

Hmm. actually, I guess that GUI thing wasn't so bad after all.

Thinking about it, I guess those long file names were quite a neat idea.

On reflection, the whole multi-tasking thing was fairly useful too.

Hmm. server admin. tricky stuff. lets see if we can't crowbar that back in too.

Right, in another ten years, with all these super features in place we'll have a whole new product...MSnix is born!!!

Re:regarding "object model"

[IamTheRealMike]

See here for some good discussion of relational filing systems. In general, the author concludes that relational structures are not always the best fit, and something better can be used.

Object models are primarly good for boosting programmer productivity by reducing wheel reinvention, and by allowing you to use languages that are most appropriate for the task at hand. If you're writing a media player, C is not the best language to use. If you're writing a high performance codec, maybe it is. Object models that let you share code a la COM/.NET mean you don't have to choose langauges based on what code is already available to you in that language.

Best tools for jobs

[smittyoneeach]

So, you dump the photos into a folder and use an RDBMS to give you arbitrary meta-data
about your archive. About the only thing you can't do is have arbitrary numbers of images named 'RillyKewlCar.jpg' in the same folder.
The killer argument in favor of what you already have is that a robust SQL engine that
would fit on a bootable floppy would probably be software art of Knuthian proportions.

Re:Best tools for jobs

[Tablizer]

(* The killer argument in favor of what you already have is that a robust SQL engine that would fit on a bootable floppy would probably be software art of Knuthian proportions. *)

dBASE used to fit on a CPM floppy. True, it was not fully relational, but close enough in most cases. The biggest problem with a compact relational query engine is the bloated SQL syntax. Get rid of SQL, not relational. Define queries in smaller chunks, Function Programming-like. Competitors to SQL did that once, but for some odd reason SQL won. Probably because of it is allegedly more English like. But that same goal bloated COBOL in similar ways. SQL is the COBOL of relational query languages.

Re:Best tools for jobs

[smittyoneeach]

True, if you know a priori that you are dealing with character data, your file metadata are highly stable, and the recursive nature of a file hierarchy is the scariest piece, one would suppose that a customized file system database engine might not be too huge.
But I speak well above my skill level, having just written my first little bit using a RegEx. Go, boost.
Maybe keeping an eye on Hans is a good idea.

Re:Well that's nice

[orangesquid]

No, see, that's the point. Microsoft doesn't support Linux, but Linux people want some of the things Microsoft provides for Windows, so we have created our own. It's not innovation. I have never seen any open source programmer consider cloning proprietary software innovation. Major innovation (totally new ways of doing things) is usually somewhat rare in software created by hobbyists because companies generally spend thousands on research-and-development costs to majorly innovate. Open source is full of minor innovations, though (clever hacks, minor improvements, small enhancements), that can make the difference between software being a pain to use and a joy to use.

Microsoft is infamous for speaking so highly of their innovation while usually only performing minor innovation (many of their products are simple improvements on another company's software, or were straight-out bought from other companies which does not constitute innovation in any form). If you are going to talk of how innovative you are, come up with some really-damn-new, really-damn-good ideas on your own!

Way to Go, Microsoft

[SecretAsianMan]

This is the moment of truth for all you people out there who have made arguments like the following:

• Having both Gnome and KDE is good because the competition will cause both to get better
• Having a Linux/UNIX desktop environment is good because the competition (with Windows) will cause both to get better

I've seen these kinds of arguments spouted repeatedly by purveyors of the Slashdot party line, and I've even made a few myself. What we have here is a confirmation of the underlying idea: that competition improves products.

Plan and simple, Microsoft is competing. They've acknowledged a strength in a competitor's product and are (finally) going to tackle it head-on instead of with shady business, cash, and lawyers. They're going to try to build a better product. This is what we've wanted all along, isn't it?

I wish Microsoft's programmers the best of luck in creating these new features. They will most likely be a great improvement to the Windows platform. Likewise, I wish the Linux/UNIX communities the best of luck in creating new features to greatly improve Linux/UNIX. I believe that competition between the two groups will significantly advance the start of the art in software. Microsoft is ready to play serious but fair ball, and it's up to the rest of us to build a winning team and play the game. Humanity stands only to gain.

Re:Way to Go, Microsoft

[Cyno]

Yeah yeah yeah, but what if Microsoft wins? They'll go right back to the same crappy service and products as they had before because they're only concerned about money. It is not in their best interest to create a stable, secure, standards compliant OS if they can sell you something that looks like one and save a bundle in developement costs. What happens when Linux goes away? You have no more free software.

Oh and since when has Microsoft ever played a seriously fair game of ball? I have yet to see an ethical action from that company.

But I guess its more important to have new stuff come out every year like .NET, XP and longhorn. The advancements and the technology are simply amazing, aren't they. I don't know what we'd do without Microsoft. We'd be lost.

Their type of competition is anti-competitive. How much better would our technology be if corps like BeOS would have been allowed to compete. Their product was argueably superior but lost out because of the usual ignorance on the consumer's part and Microsoft's anti-competitive behavior. I suggest you read up on it sometime it might surprise you.

Microsoft should have been broken up. But at least in all honesty on a long enough time line there is no way any single corporation can compete with GNU/Linux.

Re:Way to Go, Microsoft

[SecretAsianMan]

Yeah yeah yeah, but what if Microsoft wins?

If winning means producing a better product, and that is what I'm arguing, then you'll want to use their product and not any other. If they win (over Linux), that means they made something better than Linux.

They'll go right back to the same crappy service and products ... when Linux goes away

Oh, I doubt it. If they did, someone would just go revive Linux or build another free OS with which to whip their collective ass. The great thing about Linux is that it can never really be squashed; there will always be people who want to write quality free software in online communities. Microsoft can't make them go away. Microsoft's only recourse is to keep elevating the quality of their product to compete.

since when has Microsoft ever played a seriously fair game of ball?

I didn't say they had a history of it. We're all wonderfully aware of their past transgressions. But it looks as if this could possibly be a move in the right direction as far as business practices go. If we don't give them the chance to shape up, we're all hypocrites. It's not right to complain so loudly about how bad this or that is and then refuse them any chance to solve the problems. Or are we all really just in love with the fight itself?

Their type of competition is anti-competitive

I'd call that a contradiction...

How much better would our technology be if corps like BeOS would have been allowed to compete

You mean Be, don't you? Be was allowed to compete, just like Linux was/is. Be failed. They had some great stuff, but it had drawbacks -- major ones. It was too Mac-oriented for a long time. Macs have only a small fraction of the personal computer market share, and with Apple's jealousy, Be could only have a small fraction of that fraction. Then there was the horrible hardware support. A couple of years ago, I was pumped to try BeOS, but my x86 PC just wasn't supported well enough. And the biggest problem? We've heard it before. Software, software, software. Where was it? Be just didn't have what it takes.

the usual ignorance on the consumer's part

A very important note: if you're trying to get people to use your product, calling them stupid isn't a great way to start. How well would the following ad go over in PC Magazine? "Use Linux, because you're a fucking moron!" Not the best way to start a relationship...

But at least in all honesty on a long enough time line there is no way any single corporation can compete with GNU/Linux

Then what's the worry? As long as there's a community around like the Linux community, there will always be a good OS for your box -- no matter who makes it. Competition, man.

Re:Way to Go, Microsoft

[Cyno]

If winning means producing a better product, and that is what I'm arguing, then you'll want to use their product and not any other. If they win (over Linux), that means they made something better than Linux.

This is capitalism fool. Winning means you make the most money and beat out your competition financially. Has nothing to do with the quality of your product. You should know that by now.

My comment about Microsoft's competition being anti-compeititive fell of deaf ears. You simply don't understand the destruction Microsoft has caused to our computer industry. The only thing that has a chance at competiting is not competing on the grounds of capitalism. They had to develope a license so liberal that it is virtually communism and give away their product for FREE. That's what I mean by anti-competitive. Linux is also anti-competitive towards corporations like Microsoft, which is why I don't have anything to worry about. But it does not change the fact that without Linux we'd have 2 choices, Microsoft or Apple.

Apple is understandable since they build their own hardware, just like Sun. But why is there no alternative for the PC than Microsoft, even when one, Be, developed an OS far superior in technical merit. Because Microsoft forces distributors to sign NDAs and various licenses prohibiting them from selling competing products if they want to also sell Microsoft products. That's anti-competitive if anything is.

I don't care how friendly you say you are if you kill or enslave everyone who talks to your friends I won't have anything to do with you. I'm sorry, but this is not business as usual. This is capitalism at its best, or worst depending on how you look at it.

Re:Way to Go, Microsoft

[Cyno]

But I have to admit you have a good point about competition, it is always good for us consumers. Although I think competition would be better if Microsoft stopped being so anti-competitive. If they didn't go out of their way, for example, to develope new hardware for the PC that only works with Windows.

wow

[Tom]

After 25 years, Mr. William Gates III has finally found out what that funny thing he never understood on his Altair was for. It took some work to convince Balmer, but the promise that the @ symbol in the prompt will be animated and provide the user with a constant stream of "you seem to want to run a command, may I assist?" hints in addition to morphing into a dancing monkey whenever there are too many CPU cycles not being wasted on something else finally did the trick.

I just wonder if they will also create a .NOT ^H^H^H NET implementation of vi, or if they'd rather copy emacs. Maybe just to piss off RMS. (they got away with stealing 90% of what windos is today, surely they could care less about RMS taking them to court).

He's not missing the point.

[edunbar93]

The point of shell scripting in UNIX (and I dare say, period) is to patch together a bunch of pre-existing programs so that you don't have to build the functionality of each one from the ground up every time you want to use it.

Command.com (and cmd.exe) already has the functionality to do this. There's just a tiny little problem with doing it with all windows programs and most DOS-based programs too. They were never built to be scripted.

Here's a perfect example. Say that as a sysadmin you want to check to see how many times "foo" shows up in your system logs on a daily basis. And since you administer 20 such servers, you don't want to have to log into each of them every day and search the logs yourself. Here's how you'd do that in Unix:
(no, I haven't tested this, and undoubtedly my syntax is wrong. It's called pseudocode.)

Place a line in the crontab like this:
(every day, 3pm) mail -s "system report" edunbar93@youknowhere grep foo /var/log/bar | wc

Yes, there are better, more elegant ways of doing this. This is the simplest. In windows, you'd have to somehow do the following, assuming the default toolset that comes with windows 2000:

Get the "Find files or folders" program to somehow spit out only the line that says how many results were found, somehow get that information into Outlook Express, and somehow get OE to send it automatically.

Of course, the first person that accomplishes this feat will win a Nobel prize in computer science, because it's nearly impossible.

Of course, you could "just" make a scripting language that would make the process easier. For instance, you could make function calls/objects for mailto(), grep(), and wordcount(). Not to mention any number of other function calls that might be needed, which would undoubtedly be added by future include files, patches, and upgrades. It's still a far cry from a one liner, because your program would now look like this:

#include grep
#include wordcount
#include mail

$x = grep("foo", /var/log/bar)
$x = wordcount($x)
mailto("edunbar@youknowwhere.com",$ x)

And, it's worth noting, you're also still a far cry from a scripting language. This is closer to perl than it is to sh. Why bother at all, when you can just use perl? It doesn't matter if you're using the .NET framework, or VB, or whatever, because it's missing the entire point. The point here shouldn't be to create a huge behemoth to perform small tasks, it's to create an army of mice to work together to perform big tasks. Make programs in such a way that you can take one program, glue it to another, and make it into something completely different. Also, the entire raison d'etre should be that the sysadmin should be able to build these constructs in seconds, not hours or days.

Microsoft's operating system works on the basis of complexity. Unix works on the concept of simplicity. Guess which one is better at doing simple things, and always will be better at doing simple things.

Re:dont understand

[cranos]

WOuld that be an undergraduate text book from Microsoft Press?

What about the helios?

[captredballs]

Many folks have commented that this is just a command line, when it sounds like much more. It reminds me of the scriptable capabilities of KDE though the dcopclient utility. In other words, it provides dynamic and manipulative access to running systems without prior knowledge of their interfaces.

Sure, bash + vi + kill -HUP is provides some level of dynamic configuration, but it assumes prior knowledge of configuration file formats and whatnot. Also, there appears to be a desire for trans-network discovery as well.

eh?

Promises, promises (vaporware and monopoly)

[aphor]

Ha, ha: only serious...

Just in case you were working on something to solve a shell problem, just stop, because you can't compete. I mean, this is Microsoft, and nobody will believe that you can put out something that works better than theirs.

Even if you do actually accomplish that feat. Even still, Microsoft will trace the API calls your shell makes and pull the rug out from underneath you in the next automated .NET framework service-pack.

Then, they'll link their knowledgebase to promos of their product so when your customers search for a solution to why your shell started behaving badly (just after the ServicePack was applied), they will see "use the Microsoft shell". Next, your boss will get a letter explaining that Microsoft is attempting to purchase the rights to your project, and all your boss has to do is kill your project to collect more money than they've ever paid you (and prolly some killer seats at _insert_big_sports_event_here_).

Next, you'll probably end up contributing code to some consulting firm that agreed to make the Microsoft shell do what yours already did. It'll cost 20 times as much, and it'll be 1 year past the delivery date you would have made, and by then you'll be sick of dealing with the problems your shell intended to solve.

You'll try to move on to something else, but every where you go, no matter what you try to get into, the same old shell scripting problems will stymie you because NOBODY solved the problems that Microsoft promised their shell would solve. It will haunt you until you completely switch fields or commit suicide, or some other depressing and too-boring-to-enumerate possibility.

There is no monopoly in Unix implementation. Stick to Unix if you don't want to hire (or be) a staff of service-retarting, server-rebooting, reinstalling monkeys to do boring repetitive click-and-drool tasks at the console of a server , in what was *supposed* to be a lights-out data center, checking blanks on the left margin of of a mainframe-era "run book" as they (you) go.

Happy new year!

Much more than normal scripting?

[captredballs]

Ahem. I appear to have "remembered my form values" via mozilla at some point, which means that "what about the helios" got inserted for me based on a post several months ago

Score: -5, OffTopic Subject Line :-)

Or in VBS (automate that GUI App!)

[steve.m]

WSH ships as part of Win98 and above. Of course, you wouldn't know that being a Linux only user...

thumbit.vbs:


Set WshShell = CreateObject("WScript.Shell")
Set fso = CreateObject("Scripting.FileSystemObject")

WshShell.run "c:\progra~1\paints~1\psp.exe", 1
WScript.Sleep 100

WshShell.AppActivate "Paint Shop Pro"

WshShell.SendKeys "{ENTER}"

Set MyPics = fso.GetFolder("c:\tmp")

For each Image in MyPics.Files

WScript.Sleep 100

WshShell.SendKeys "^o" & Image & "{ENTER}" 'open file

WScript.Sleep 1000

WshShell.SendKeys "+s" 'open resize dialog

WScript.Sleep 100

WshShell.SendKeys "100 {ENTER}" 'maintain aspect is set so only enter width

WScript.Sleep 100

WshShell.SendKeys "^s" 'save file

WScript.Sleep 1000

Next

Unix aren't living in the same world as Windows

[Jugalator]

Another proof comes from that site:

You can download the huge current tree in standard gzipped tar format, but be warned: it's about a megabyte right now.

IIRC, Microsoft didn't warn us explicitly before downloading the 100 Mb Service Pack for Windows XP. :-)

Re:Unix aren't living in the same world as Windows

[Richy_T]

I think he meant a Gigabyte. I did a "get release.tgz" and that's about what it came out to for me

Rich

Re:Unix aren't living in the same world as Windows

[Jugalator]

I don't know where you found this.

Hmm... Try looking at the page linked to in the article. :-)

Re:Unix aren't living in the same world as Windows

[Jugalator]

Grr... Sorry... I meant the link in the parent I was replying to. :-P The last one, to be precise. ;-)

Re:Try again

[__past__]

and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.

The OpenOffice people, the Mozilla people, the KDE people, the GIMP people, etc would probably beg to differ.

Unfortunatly, all but the Mozilla guys would be wrong, and even them would only be right in the eyes of users that consider "has useful features" a more worthwhile development goal than "comes preinstalled anyway", which are depressingly few.

Sigh, you're doing it all wrong...

[sheldon]

You wrote your script wrong, it should be:

mkdir thumbnail
for %i in (*.jpg) do D:\imagemagick\convert -resize 128x128 %i thumbnail\%i

I used the path to the imagemagick conversion program because NT also has a convert command, and I don't wish to mistake them. You could also rename the imagemagick convert to imgconvert or something.

Now let's say you want to take 35 different bitmaps and for each one create 32 different rotational views. Now you could try to use Imagemagick, but your results will be unsatisfactory as it doesn't do rotations at other than right angles well.

So now you have something like Paintshop Pro, which is entirely GUI based. Your process is:
1. Load original bitmap
2. Rotate X degrees
3. Save bitmap

Now why on earth would you want to do this over 1,000 times? A better solution is to automate Paintshop Pro by sending keystroke events to it using a scripting tool like Winbatch. Unless of course the GUI tool already includes scripting capabilities(many if not most do).

Again, you could do the same with your image resize problem. This gives you a great deal of functionality in the event that Imagemagick doesn't produce very good results(which is unfortunately quite common).

Re:Sigh, you're doing it all wrong...

[Gordonjcp]

Well, fair enough, but I should point out a couple of things - I only ever need to rotate an image by multiples of 90 degrees, so I should have pointed out that my solution is to a given, known, non-arbitrary problem. Furthermore, Winbatch and Paintshop Pro are exclusively Windows programs, and since I don't have Windows I'm stuck there.

Oh, the horror...

[Jugalator]

Ok, let's see how to copy a file...

System.LocalDrives.Drive1:> copy test.txt test2.txt

copy: Unknown namespace

System.LocalDrives.Drive1:> System.IO.Copy("test.txt", "test2.txt");

System.IO.Copy: Type mismatch at parameter 1: expecting System.IO.File

System.LocalDrives.Drive1:> using System.IO;
System.LocalDrives.Drive1:> File fSource = GetLocalFile("test.txt");
System.LocalDrives.Driv e1:> File fDest = new File("test2.txt");
System.LocalDrives.Drive1:> Copy(fSource, fDest);

Wohoo, I did it!

Re:Ignorance is not existence

[moof1138]

man osascript

Why perl?

[sheldon]

Why not just use the addusers.vbs script that comes with the Resource Kit?

This lack of knowledge about Windows really annoys me. Instead of criticizing products, why not use google.com to search for ways to solve your problem, or just ask someone else how you might do this.

Oh, that's easy!

[twitter]

Only someone who's got experience with NT and "non-Windows" operating systems would know what kind of portablility the new .NeT should have. It will resemble the famous Korn shell of NT and be at least as portable as NT was. Ah yes, the new CEMENT OS is on the way.

Ehhr???

[miffo.swe]

Wasnt it Microsoft who left all development of the CLI back in 90? They have since claimed it useless and worthless. If they decide to implement it now they will be atleast 10 years behind in security. That is, if they dont look at others source code and doesnt reinvent the wheel again. Either they will be up the creek without security or they will "borrow" code and knowledge from the unix world. Either way they are in for a rough ride. I suggest that we keep a close eye out for any similaritys.

I have a strong feeling that they wont go at this from scratch. That would make them implement numerous bugs into windows, again.

One last quiestion, do they think all that is linux is the CLI? What about price, freedom and developers etc? Either way, the users of windows are the real winners here. Damnit, all of you that love windows, support linux and get better windows. It should be pretty obvious by now.

There is too much crap in windows to...

[3seas]

make a worthwhile shell. It's why MS has what must be one of the worse shells ever. Or is iut because MS wants to keep the users to stupid to take advantage of all the holes.....in windows?

Re:dont understand

[cranos]

Winnt and XP are not only insecure because of the apps, thanks to tie ins with IE and Outlook/Express script kiddies have a handy avenue into the OS itself.

That and the slack approach to bug fixes and exploit alerts that MS has shown in the past makes Windows 2000 and XP less secure than Linux.

Copy of AppleScript

[EelBait]

This looks like a blatant attempt to copy AppleScript. On OS X, one can send high-level object-oriented messages to applications, extract data and then manipulate the info with bash or perl scripts. And, you can wrap your AppleScript program with a nice GUI if you so choose.

MS and the CLI

[0x0d0a]

Not only that, "coherent and well-integrated" is just stupid in this context.

Okay, if someone whips up a Linux system with a mixture of KDE apps and GNOME apps (and doesn't use null) and uses some Athena apps too...then things aren't going to be that consistent from a UI perspective. MS has their own UI consistency warts, like one-of-a-kind widgets in Outlook, non-OS-derived widgets in Office, and the Start menu and task bar. However, this is all in the GUI. Once you move to the CLI, MS's degree of consistency is really, really, really bad. The current collection of CLI utilities that MS ships sometimes uses UNIX switches (-), sometimes MS ones (\). Ping uses -, dir uses \. There are a few fairly standardized switches in the UNIX world -- -h for help, -v for verbose. MS's software doesn't have even this.

As for "well-integrated"...well, "integration" usually refers to non-modularly engineered software, with a dose of MS hype about why this is good. It also doesn't really penetrate the CLI world, where utilities pretty much stand on their own.

I wish...

[Gordonjcp]

Sadly I don't. Not a bad idea though.

Re:Yes shame on Microsoft for trying to change

[cranos]

Gotta sell ad space? Have you seen the number of visual studio ads here?

Frankly, with Microsofts track record of fumbles and screw ups I wouldn't be surprised if they managed to bugger this up as well. They are going to basically tack on a shell programme to an OS that has gone all GUI, exactly the opposite of whats happening with Linux.

Just bear with me for a minute while I ramble. Microsoft has a reputation in this industry for shoddy code with no real attention paid to security. They have tied Internet Explorer into the core of the Operating System thus allowing a much wider range of attacks than if it was a stand alone application sitting above the kernel. Outlook express and Outlook are major avenues for virus propegation due to the same shoddy code and crappy OS design. Their answer to the problem has been to build a pretty GUI and call the bugs a feature.

And now they say they are going to re-build the shell. Let me just say that I'm glad I have the only Linux machine in the organisation because at least Linux has been built with the shell in mind when it comes to security. Whereas the MS version will be a tack on, no matter which way you look at it.

Re:Micro-Kernel in MS windows !

[spongman]

no, i didn't because they're drivers (they run in the executive) and are not part of the kernel.

Embrace and bloat

[Alex Belits]

I find it disgusting that the only time Microsoft adopts a good idea is when they can make an implementation stuffed with some irrelevant crap to the limit and far beyond.

The job of a shell is to talk to the user, call programs and run scripts. It is not to mess with the network or have giant builtin pieces such as dotnet interface. If they wanted to do something reasonable they could've just distribute bash and a wrapper utility to call whatever they want in dotnet.

Re:Learn how to use your apps

[cybermace5]

Well, your script is useful if all the files are in the same directory, and you want to resize all of them. But what if you want to resize a few images from different directories across your system?

Since I have to use Windows at work, and don't mess much with images at home, I can't recommend one Unix graphics program over another. But on Windows, Irfanview is priceless. The batch convert program works incredibly well, and does a lot of things like color balance changes and format conversions. Also, the thumbnail view lets you take a directory of images and convert it straight to a web page with thumbnails, linked to full-size versions and with file sizes listed below the thumbnails. Irfanview is the best Windows program I have ever used.

To quote Linus...

[truthsearch]

"...message passing as the fundamental operation of the OS is just an exercise in computer science masturbation. It may feel good, but you don't actually get anything done."
- Linus Torvalds (from Tigran Aivazian's Linux Kernel 2.4 Internals)

It's my understanding that the tiny windows kernel core's only job is message passing between OS objects. And I think you're over-generalizing when you speak of UNIX's purpose as the paradigm for the Linux (kernel) design.

So, MS wants shell scripting?

[crazyphilman]

Marvellous. It's only taken them 20 years to produce something Unix has had for nearly 30. Their mothers must be proud.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:MS was at USENIX/SAGE asking what makes a good

[babbage]

Given the context -- nice signature :)

The funny thing is, from a certain point of view, this looks like both a validation & cancellation of what Apple has managed to do with OSX. Once OSX came out, Windows was the only remaining family of mainstream operating systems that wasn't either Unix based or, if nothing else, had a robust layer for using Unix tools (BeOS wasn't really Unix/Posix, but it was glose enough for many purposes; everything else is even closer & usually at a pretty deep level).

Legions of Unix fans were able to boast that they could take their shell skills to any other platform painlessly. The Macintosh found a whole new audience that had in the past mostly ignored it. And aside from efforts like Cygwin (which is imperfect at best and, besides, isn't available out of the box), Windows users were left out of the party. Not that that bothered most Unix fans.

Unfortunately, it seems like Microsoft was paying attention to all of this. If the really do get something like the Unix command shell running as a native capability of some near-future version of Windows, you're right -- much of Unix's unique strength won't be quite so unique any more, and again you're right -- Unix unfortunately doesn't have as much to fall back on as one would maybe hope. As much as *I* would hope, anyway...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Learn how to use your apps

[Gordonjcp]

I think a combination of power drill and wood screws is superior to ordinary nails and a hammer.


Only for certain jobs. For most jobs that require nails, then a hammer and some nails is the only real solution. Learn some joinery then post :-)

Re:Learn how to use your apps

[Gordonjcp]

But what if you want to resize a few images from different directories across your system?

It's something I may not have made totally clear, but that's something I *never* have to do. I need a solution to a known problem, and the problem never significantly changes.

Comment removed

[account_deleted]

Comment removed based on user account deletion