One of the million reasons why Windows sucks (religious) | The Coffeehouse

crontab

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

Dear %FULL_NAME%,

etc.

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... Smiley )

Manip

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?

jcarlisle

yah I agree ... don't feed the trolls...

crontab

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).

spod

Hi crontab

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...

Dim objMessage
Set objMessage = CreateObject("CDO.Message")
With objMessage

  .From  = sfFrom
  .Sender = sfFrom
  .To  = sfTo
  .Subject = sSubject

With .Configuration.Fields

   .Item(cdoAutoPromoteBodyParts) = True
   .Item(cdoSendUsingMethod)   = cdoSendUsingPort
   .Item(cdoSMTPServer)     = sSMTPServer
   .Item(cdoSMTPServerPort)   = 25
   .Item(cdoSMTPAuthenticate)   = cdoAnonymous

   .Update

  End With

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 Smiley

cheers
jeff

Jorriss
Don't piss-off the Ibis.

First Sun and now this. Is MS trying to stop ALL holy wars? Blessed are the peacemakers...

crontab

Thanks, Jeff.

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
    do
        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' Smiley

), 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.

Jeremy W
that blogging guy

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 Wink

crontab

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 Smiley

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... Wink

jsnover

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. Smiley )

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.

Jeremy W
that blogging guy

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 Wink

Manip

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.

crontab

Wow, wow... MSH is object-oriented. I'm intrigued Smiley

and of course I'll look into it.

Thanks, Jeffry.

lars

Yes! I've been dying to test MONAD since I read about it for the first time.

/Lars.

Jeremy W
that blogging guy

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.

Jaz
From the depths of Wales I come

just outta random intrest, have any of you MS guys played with or used Xenix?

Akaina
C9 is cool, but /. has better karma.

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!

Akaina
C9 is cool, but /. has better karma.

BTW,

Why the **** do I need to learn an entire object model just to redirect text?

Jeremy W
that blogging guy

You won't get something that'll do Word conversions commandline, as that would require tapping into the core Word functionality. The Word document format is rather complex (Chris Prately covered this recently if you want detailed info). It's not like WordPerfect's tag system at all. It's a robust, (for lack of a better word) oject oriented way of assigning attributes to runs of text.

As such, doing the conversion to HTML would be messy and inconsistent. To the point where Chris says "I wouldn't want to try it".

Akaina
C9 is cool, but /. has better karma.

I'm convinced that everytime I hear the word 'robust' it means "slow and convoluted".

If they made it easy to convert documents they'de lose all their business, because everyone would switch (to RTF, PDF, or HTML). Ever notice the trick question when you try to save in a 'non Microsoft' format?

"Are you sure?"

-Click Yes to return and save as the most recent type
-Click no to continue and save in old format

you see, by saying you're sure that you want to save the file, you're switching to a MS format.

That's why Unix is better - because Unix doesn't have to play games.

ZippyV
Fired Up

OpenOffice does the same thing.
This is not a Unix issue.

Jeremy W
that blogging guy

OpenOffice is even worse. You get an error when saving AND when closing, both of which are like "if you do this you want have our features!!!"

Before you pass judgement on how Word does it's format, at least read Chris Pratley's blog entry on the subject. If you choose not to agree that's one thing, but there's no reason to get all "here's why Unix rocks". It has nothing to do Windows or Microsoft, and it's not bad.

As far as robusdity (hehe), lots of things are robust, including PHP, Oracle, etc. Has nothing to do with 'bloat' (I loathe that word).

Akaina
C9 is cool, but /. has better karma.

robustidy hehehe... I'm gonna have to start using that.

I'm referring to the trick question. Warnings are fine. If they do trick questions in OpenOffice I would be against that too.

I know what 'robust' means. But whenever someone in sales says it my skin crawls.

Robust is an ambiguous term. They may as well be saying "_________ has a new $great architecture".

"Robust how?"
"Robust with respect to what?"
"Compared to what?"

You see what I mean?

Jeremy W
that blogging guy

Of course, but it's not like I'm a sales guy Smiley

I say it because that's how I see it.

warren
atom heart mother

Your "one of the million" reasons has been shot down: Services for Unix.

So, you're presently at zero items. Would you like to list the other 999,999 reasons why Windows sucks, so that we can demonstrate to you that you don't actually know enough about Windows to be in a position to criticise it?

Go on, then...