Before I tell you that reason, here is a simple task: write a program that sends an email to all users of a given system (actually a server). I give you the template message, where I mark user's full name with some sequence, say %FULL_NAME%.
The text starts with
Remember, you don't have any IDE's or compilers on the system, only the minimal server installation. VB is okay, then show me that program in VB.
On UNIX the answer is a shell command that uses only the standard UNIX Userland. Any UNIX system administrator can write such command in just 1-2 minutes, because it's simple. I can also show you a simple HTTP server written using only standard tools on UNIX, and no C code. Not possible on Windows.
Even though Microsoft is trying hard to make various components of the system interoperable, things only get more and more complicated. IE with its layers is fine, in fact I liked its design, but I'm afraid it's the only thing Microsoft can be proud of so far. The rest is debris of mostly unusable programming interfaces, each of which were used only once in some [Microsoft proprietary] application, and will eventually replaced with some new interface or technology. Isn't COM going to be replaced with .NET, for example?
In contrary, the components of UNIX are highly interoperable because of simplicity of the fundamentals: everything on UNIX is plain text, possibly with some predefined syntax, and every program is a stream processor. Nobody would ever invent anything simpler AND more flexible (and thus powerful) than plain text that passes through a chain of stream processors.
And that's one of the million reasons why, in particular, Windows servers keep losing their market share over the past years: what system administrators actually want is the simplest thing (a server) that works and gives them a possibility to automate any administration task.
UNIX is the simplest thing that works. Windows is the most complicated thing that sucks. Of course simpler things that suck are possible, but Windows is the king of complexity and uselessness.
(In fact, the complexity of API's and many other weird things like the "DLL Hell" are actually coming from IBM... But that's a different story. Let them open their own Channel9, and I'll show them... )
Before I tell you that reason, here is a simple task: write a program that sends an email to all users of a given system (actually a server). I give you the template message, where I mark user's full name with some sequence, say %FULL_NAME%. The text starts with
Because your not even attempting to be constructive and JUST picking, your entire post is a waste of everyone's time.
You should have just posted "UNIX = Good; Windows = Bad;" would have saved everyone a lot of time.
I would also like to point out that UNIX has fare more interfaces and redundancies in its history but most have been stripped out.. How many ways are there to do X task in Linux? Hundreds? Thousands?
yah I agree ... don't feed the trolls...
Manip wrote:Because your not even attempting to be constructive and JUST picking, your entire post is a waste of everyone's time.
Manip, be constructvie and write that program for me (that sends an email to all users on a server).
I agree the raw command scripting on our current platform is pretty limited. There are cool things coming down the line here in the longhorn timeframe....if you are interested let me know and i'll see how much i can tell...
Now is a good time to give feedback, so if you have specific things you'd like the scripting / command shell guys to get please let me know. We are aware of the composibility and streaming issues and these are being addressed.
regarding the mail program, and assuming you really do need to do this however hard it is, could u use the windows scripting host for this, and write a cscript program. this would let you write in vb script or jscript. You can interface to the mail server through CDO, and to the users info on the server through WMI ( presuming you need to tie these two together this way? )
assuming you have an smtp server the CDO code would go something like...
Set objMessage = CreateObject("CDO.Message")
.From = sfFrom
.Sender = sfFrom
.To = sfTo
.Subject = sSubject
.Item(cdoAutoPromoteBodyParts) = True
.Item(cdoSendUsingMethod) = cdoSendUsingPort
.Item(cdoSMTPServer) = sSMTPServer
.Item(cdoSMTPServerPort) = 25
.Item(cdoSMTPAuthenticate) = cdoAnonymous
you get the idea...i'm not a cdo expert but i imagine you can get to all the users info etc.
another option maybe is to use perl for this; there are certainly perl libraries available for all of this in the implementations i'm aware of...
when i had the same problem i just hacked it, and created a mail group containing all the users i wanted to send to, and changed the mail to Hello All. Assume your situation is more dynamic than this, and cheesy hacks like that won't work
First Sun and now this. Is MS trying to stop ALL holy wars? Blessed are the peacemakers...
I expect the VB script to be 100 lines at least. Actually I don't need this script in my job, and the reason I was asking is rather theoretical. And yes, I'm interested in knowing as much as possible what Longhorn's scripting will look like.
Now, here is the UNIX answer (or one of the possible answers):
while read t
user=`echo $t|cut -f1 -d':'`
gecos=`echo $t|cut -f5 -d':'`
sed "s/%FULL_NAME%/$gecos/" MSG | mail $user
done < /etc/passwd
(awk would also do this job pretty well.)
Assuming the template is in the file named MSG. Cryptic, not very readable (neither very 'writable' ), but all in all, it takes a minute to write it. Do you see any interfaces, protocols or whatever else that would require you to look into documentation here? Nope! Only the very basic standard userland tools: 'cut', 'sed' and 'mail'. The rest is part of the shell language.
Likewise, you solve many everyday administration tasks on UNIX this quickly.
Of course this is trolling. The question is incredibly limiting.
I could easily, for instance, spin this the other way.
Automatically distribute a package to users who logon, but only if they logon within a certain network zone, and only if they are running SuSE's latest build (9, right?).
Or, rollback the version of Konqueror across a WAN.
Or, give users a fully dynamic (integrated into your network with all their apps (no need to download or have installed), etc), seamless environment over dialup with no lag.
See, there are strengths and weaknesses to both OS's. As a sysadmin for a company roughly the size of MS it's the management tools that I love. Linux is just 'icky' that way. Asset Management? Remoting? Helpdesk? Package Management? Managed Virtual Environments?
But yeah, a lot of the shell commands in Linux are fantastic. Awesome in fact, as is the security model.
Well done you
Jeremy: okay, assuming Windows is installed on most desktops in the world, you need another Windows to administer them in each LAN/WAN. BTW, whenever I'm asked to propose a solution for a large corporate network I mostly say "Windows desktops + Windows NT domain and stuff + Linux or Sun as a web/mail server + any UNIX-based firewall".
Speaking of automatic distribution of packages and updates: they are dangerous. An average syadmin is able to do a mistake that would stop all computers in the network, not to mention a malicious attack that would be pretty easy to do with your automatic distribution of packages.
Okay... to continue the race how about administering a remote server through a slow dial-up line? From a relatively 'dumb' terminal? I beleive one day it would be possible to log in to a UNIX machine from a cell phone.
See, I'm not talking about Linux, but UNIX in general. That's another religious issue not relevant here...
We have certainly done a bad job of this in the past. We have focused on GUIs for simple administration and SDKs for complex administration and not paid enough attention to the command line. Mea Culpa. Mea Culpa.
WE ARE FIXING THIS. (That is the great thing about MSFT - we are incapable of sustained error. OK OK, sometimes it takes us 25 years before we fix things but still - we eventually get them fixed. )
We started to fix this in XP and W2K3 by adding 61 new commands. That was great and it moved the ball forward but what was still missing was the rich programmatic shell/scripting language and the rich domain-independent utilities.
That is now fixed by being able to use the free download of Services For Unix (SFU) which gives you all the UNIX shells and utilities. SFU provides great UNIX compatiblity and interoperability. Great stuff - check it out. Use it early, use it often.
We are also working on the next generation of command line scripting tools which will leapfrog the capabilities current tools. This is the MONAD project offically known as the MSH Command Shell. Most Unix guys blanch when I say that there is a better way to do things but then agree after they hear me out and see the demo. The topic is too vast to cover in one posting but what you can do is to check out the DECK I presented at the PDC at: http://download.microsoft.com/download/3/8/1/38198a72-294d-46c3-93ba-faee5cf85d00/ARC334.ppt .
Here is the elevator pitch:
MSH is as
Interactive and Composable as ksh or bash
Programmable as Perl or Phython
Production-oriented as VMS DCL or AS400 CL
And it makes accessing management information as easy as accessing files.
You can also get a copy of the new shell from http://betaplace.com . You'll need a passport account and then login with the name "mshPDC" (case matters). You'll get access within 24-48 hours.
Please investigate and give it a try and throw rocks. I think you'll like it but I'm most interested in finding out where we got it wrong and what we need to do to get it right.
I agree with your assessment. Except that we also have some huge UNIX mainframes (well, VMS actually, which apparently isn't UNIX *L*).
Administer from any device? I can already administer our entire network from my Windows CE device (PDA). Reboot a good chunk of our servers (all the newer ones have management ports built in) gracefully, start and stop apps, work with users, etc.
To be perfectly honest, Linux shines in the appliance space (same as you're saying).
As far as automated distributions, we have a 3-tier test lab. Nothing leaves it until it's proofed. Sure, a novice or uncareful sysadmin could do some serious damage, but that's true of any environment, with any tool on any OS. Hell, an idiot sysadmin could bring down a network with SNMP agents
You are most definitely trolling... And I feel you have little real world experience with things. As fair as script is concerned there is a point where you just have to use a standard programming language. You could consider building a program in full VB6 or .Net. Script's are a good idea but sometimes they are just no suitable.
Microsoft, what I would like to see is a semi-full VB6~ implementation as an interpreter (ala QBASIC). Remove the support for advanced and graphical items that would never be used in scripts. The great thing about this idea is you already have the VB6 compiler source so converting it wouldn't be too expensive.
Instead of the script dev having to look up messy components to do stuff like file OI just have the interpreter do all that 'Open PATH for X as Y' is a winning solution.
This wouldn't even be the first time full BASIC has been an interpreted language.
Lastly, this wouldn't hurt your profit margins as fair as VS6 is concerned because developers still wouldn't be able to use your VB6 interpreter to develop graphic apps or compile in binary executables.
Has anyone else tried using VB6 to make non-visual apps (using a single module + sub main()) or is it just me? Your find when doing that that it is excellent at it.
Please, if you read this at least give it SOME thought.
Wow, wow... MSH is object-oriented. I'm intrigued and of course I'll look into it.
Yes! I've been dying to test MONAD since I read about it for the first time.
Manip, why not just use KiXtart? It's MS 'supported', it's command line, and it's very powerful. You have access to all of the COM stuff, as well as KiX's internal engine and all of the local machine and network settings.
It comes with the NT4 Option Pack, but is also freely downloadable at kixtart.org.
I really don't see any need for a command prompt or shell scripting language beyond that. I don't see what void it fills, who would buy it (and therefore how it'd get approved) or what problem it solves.
just outta random intrest, have any of you MS guys played with or used Xenix?
porting unix commands is handy, but it's not native to windows.
I would like to see some native windows commandline utilities like, let's say they make one called msconv (for MS convert) and you can say like:
msconv thisSheet.xls -F -S=1 --to_CSV
and it spits out sheet 1 to thisFile.csv
msconv thisDoc.doc -F --to_HTML
(F to assume yes and Force any conversion complaints)
And by all means guys, if you want to develop this, feel free to freely use any ideas I'm posting. If you guys had a good native command line it would make Windows a much much better product.
Keep us posted on MSH!
Why the **** do I need to learn an entire object model just to redirect text?