The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

What's so awesome about linux? I'm tired.

This weekend and past day or two I've had to port some of my C++ stuff to linux so that I could run it from lighttpd. Lighttpd is great, but it doesn't work well yet on Windows. I'm ostensibly a Windows developer (C++, .NET, MFC, that sort of thing- no kernel level stuff), and I had this feeling that linux was somehow better in many ways pertinent to a developer. I'm not completely new to to the environment, but after these couple of days, I actually just wish I could run my stuff on Windows. I am going to mention some things I love about Windows, and would appreciate a rebuttal from a linux person. Here goes:

1. Everything is documented, in one place. Install VS2005+MSDN collection, and you've got comprehensive docs for just about everything, from the compiler to the Win API, to the shell, directx, etc). If you have a hard problem, google can very often help you with a single search. Compare the first google result of 'MapViewOfFile' vs the same for 'mmap'. Apple seems to write a bunch of useful docs though, which sometimes apply to the unix world.

2. How do you debug a C++ web application in linux? In windows, I just pop a DebugBreak() in my code, invoke the url again, and boom- I get the JIT debugger, which lets me debug my app from inside the IDE. No need to fprintf(stderr) or any junk like that. No need to learn emacs. It just works.

3. Delay-loaded DLLs. Correct me if I'm wrong, but linux has no equivalent. I'm not talking about LoadLibrary/dlopen. I'm talking about importing the whole shebang (in my case ruby.h/ruby.lib), but only loading it on demand. The end-users of my DLL (be they developers or not) don't need to have ruby installed to run my DLL, but if they do, then they can use it from ruby. I could achieve the same in linux using dlopen, but it would be a tedious chore.

4. vnc on linux requires that you leave a user logged in to the machine. On Windows, it's simply a matter of ticking the box that says "Allow Remote Desktop connections to this machine". I'm sure there is a better way than vnc on linux- I've seen some stuff, but it requires me to learn a whole lot of junk that I shouldn't have to.

5. Once you've used wprintf (or any wide-char function), printf (or any char function) no longer works. A few minutes of google could not answer this question for me.

So please- tell me why linux is *pants* and windoze sux0rs.
Ben Harper Send private email
Saturday, August 26, 2006
Linux is great if you have constructed your entire self-image around the conviction that Microsoft sucks. That's pretty much the only reason to think it's great, though.
Chris Nahr Send private email
Saturday, August 26, 2006
"So please- tell me why linux is *pants* and windoze sux0rs."

The only way you'd get that definition would be if you were a anti-Microsoft fanatic.

They both have their plusses and minuses. Linux happens to be a nicer (IMHO) server OS because of the ability to only run what you need running. Windows, even at it's bear minimum, still requires a crapload of services and integrated components, all of which can present a security risk. Linux processes still have security risks, but they tend to be fewer as all the code is open source and has more eyes going over it.

So, in short, Linux is not "awesome" but it has it's uses.
Josh McFarlane Send private email
Saturday, August 26, 2006
Well, two days of Linux won't make you a pro, either.

Just as well as somebody who lived most of his life on Linux wouldn't know what to look for, what to do, on Windows, in a couple of days.

C++ on Linux has two fronts, from my humble point of view. One is the Qt/KDE one, with their KDevelop IDE. They use lots of C++, so their tools need to be helpful. The other one is more generic, more ANSI compatible or something. This one can use the Anjuta IDE or simply Emacs, and probably follows some standards, like ANSI/Posix. Either way, one needs to know his things.

The VNC "problem" is the feature of multiusers on Linux, and of security. On Linux, 20 different users could log on the same machine, with some VNC-like approach. So, it differs quite a lot of the Windows support for mostly one user. There are tools that reopen your session, so you don't lose what you have been working on. One of these tools is text mode only, and is named "Screen" I think. So with a SSH connection -- text mode -- you can log on your machine and check out status or continue what you been working on with your Emacs/Vim editor. This is hardcore. For GUI-like, you could use another solution, like NX:

The centralized help is a problem with Linux, because it's decentralized in nature. One just needs to know his way with Linux, and that's why computer science students succeed, because they have more time to study it, normally.

It's not an excuse. It's just reality. I've heard hardware driver companies have been, sometimes, developing their drivers on Linux and porting them to Windows and its several versions (98, 2000, XP, etc).

So, what do you get with Linux for your developments? Normally, you get something only if you use it on a daily basis. And I don't know about the visual debugger. Sorry. But if I had to bet, I think Linux has it too.
Saturday, August 26, 2006
Well, I can't address all of these issues (I never developed C++ webapps, and also didn't use wide char functions)

man and info pages document the entire c library (just try 'man open'). I admit that the standard man viewer is not very comfortable, but there are alternatives, such as man2html.
Many libraries (such as GTK+) are documented, although there is no 'centralized place' for docs. The reason for this is rather simple: On Windows, all the developer libraries are  from MS. In Linux, they are mostly independent projects. The GNU project has created Texinfo, a hypertext documentation format, which they use for everything. It's quite good, but outside of GNU, it's very little used.

on MapViewOfFile vs nmap: the first result of the former is , which is a strange documentation with characters my browser can't display.
the result for mmap is this: , a quite detailed spec of the mmap function.
(I assume you got different results)

3. There's a tool that does exactly that: (I've never used it myself)

Granted, Linux looks strange when you are used to Windows (and vice versa), and both system differ in various things. But different does not mean worse.

Where I think Linux is better than Windows:

1. Linux has a much more modular design. If I write a small graphical app, I use a widget library (e.g. GTK or Qt). This library uses X to draw its widgets. X, in turn, uses kernel interfaces.
GTK's only task is drawing widgets and dispatching events.
X's task is drawing pixels on the screen.
Due to this modular design, porting GTK to other systems (such as Windows) is easy; you just use another back-end to draw your pixels. Porting WinAPI to Linux is *much* more work (more than 10 years so far, look at )

2. Shared libs are versioned. If two versions of a library are incompatible, their file name includes an "interface version number". For example, is incompatible to, but this doesn't cause any problems, as an application can explicitly link with the version it uses.
On Windows, this problem is solved by shipping an application with all needed DLLs, but this is (a)     unnecessary and (b) shipped DLLs can be buggy or contain security leaks.
Saturday, August 26, 2006
Linux has issues.

Windows also has some. Here's a couple;

1. Why is everything IDE based?? It makes it astonishingly hard to automate processes.

2. The documentation is terrible. It is, like Linux, missing those "overview" documents that roadmap all the other stuff and tell you how it hangs together. But the documentation for the system APIs is sloppy, imprecise and doesn't document known bugs. The pages don't conform to a common layout and often don't tell you what standards the calls conform to.

3. What is WITH this service vs application distinction? In linux, you want to test a service, you can just run it on a command line or in a debugger.

Both systems have fairly major flaws; proper developers pick the right one for the job. Servers on UNIX, users on Windows. Never the other way round.

They're /DIFFERENT/ is the thing. Personally I find Windows development painful and tedious and the IDEs get in the way. TOH doesn't much like UNIX dev work because he likes the IDEs and feels more productive there.
Katie Lucas
Saturday, August 26, 2006
Putting it in perspective:

If you need a Unix system, you could try Solaris. It has it's quirks, but you're only dealing with one vendor. And all of the docs are in one place:
Saturday, August 26, 2006
For remote use, as I understand it (I prefer Windows too) you're supposed to take advantage of the network-transparency of X. This actually works really well, and is about 1e99f times better than vnc.

From memory, run X server on your PC (cygwin one should do for Windows, existing one is fine if you're on Linux already), telnet into your remote computer, "export DISPLAY=<local PC name/IP>:0" in bash, then run X app(s) with "&" suffix to shove it in the background. e.g.,

$export DISPLAY=
<witness xterm from remote host pop up>

As for debugging, I bet you can attach gdb to the web server, and thus have it pop up when you do a break. My Linux experience didn't extend to this sort of thing, though, so this is just a suggestion.

You might have to run the server by hand for this to work, though, rather than as a daemon(?). You can set yourself up a specific runlevel that doesn't run the webserver as a daemon, and switch runlevels when you need to. Configuring the ins and outs of each runlevel is not that hard, but it requires a bit of fiddling in the usual Unix fashion.
Saturday, August 26, 2006
I just remembered that IEEE single precision floats don't get that big. So, let's say that remote X is 1e38f times better than vnc.
Saturday, August 26, 2006
Linux documentation can be found:

  1. man pages
  2. /usr/share/doc/*
  3. (The Linux Documentation Project)
  4. Google is your friend
  5. Google Groups is your friend (over a decade of archives)

Don't expect Linux to act like Windows. Don't expect your windows methods to apply to Unix, it is based on a totally different philosophy.

Pick up a copy of Eric Raymond's "The Art of Unix Programming"

Good Luck,

Brian C. Lane Send private email
Saturday, August 26, 2006
1. Everything *microsoft* is documented in one place, granted, and that's a lot. But no project I was involved in was a microsoft-only project; There were always additional tools / libraries involved. Integrating 3rd party help files into MSDN used to be painful experience which was rarely successful; perhaps things have changed.

Most Unix/Linux tools and libraries I've used come with their man pages. It's not as easy to navigate as MSDN, but it's standard, and usually high quality. What's wrong with "man mmap"? Any decent IDE will show you man pages within the IDE.

2. Ahhm. Your windowisms show. Call abort(), or send your process a signal (e.g. kill(getpid(), SIGTRAP), or do it from any other command).

Linux is great in that you DON'T need a JIT setup on the machine this runs on -- e.g., a production machine. Just make sure the process can dump core ("limit core 512M" should probably work), and then you can do a post-mortem debug on any machine using the same corefile. I've been using this feature of Unix for 15 years now, it's saved me countless debugging hours, and it's hard to believe Windows still doesn't have anything equivalent (and no, the minidumps don't yet come close, plus they need plumbing inside your program; coredumps are universal).

You can use gdb or ddd or many other debuggers; Most use gdb under the hood, and provide a graphical or text interface above it. Kdevelop and anjuta IIRC both do that.

3. DelayLoad is a compiler feature introduced in VC6, it has nothing to do with the operating system. And the "relaytool" linked above gives it to you. And you don't really need it -- just don't link with an import library, tell the linker the symbols should be weak, and have a script that preloads a DLL with those symbols when running the program. If you had worked on a Unix, you'd cry for something like <> instead.

4. That's how you set up your vnc. There are many other ways; you can set up vnc to accept as many sessions as you wish. On the other hand, vnc on windows can't accept more than one connection. You're comparing apples to oranges. If you compare Remote Desktop, compare it to either xrdp (exact Remote Desktop semantics, and overhead), or various X solutions -- I had a server with 64MB serve 30 logged on X terminals 12 years ago, with reasonable performance. remotedesktop/vnc uses a model that doesn't scale as well.

5. I have no idea; I never had that problem and no one else I know did either. Perhaps you have some overrun? Consider using "valgrind", a BoundChecker/Purify style tool you should have gotten with your distro ($800 value on Windows, which therefore most developers don't have).

Linux/Unix is a developer's system, Windows is a user's system. You can tailor it much more than you can do with Windows.

want to know how many users have "jon" in their name?
$ getent passwd | grep jon | wc -l
You may have an MSDN that tells you how to call "EnumerateUsers()" , "MatchRegexp()"  etc. But the problem is you actually need those docs and a compiler to achieve a simple task.

Want to change file system semantics? You're off to kernel land in Windows, with horrible pain, undocumented corners, and a hell of incompatibilities. Linux has FUSE. And if you think "Why?" then: a) your antivirus already does that, and there are many other uses. b) Use a few recent fuse modules -- map databases, web sites, ftp sites, zip files, etc. as honest-to-god files that can e.g. be mmap()/MapViewOfFile()d. Compare that with Windows' web folders or zip file handling which only work properly in Explorer.

Windows has a long way to go in my book.
Ori Berger
Saturday, August 26, 2006
"Windows has a long way to go in my book."

you can say the same for *nix for whatever purpose/progonda that you try to sell.

like someone else already said, both have minus and pluses, for me since my Windows kung fu is far better than my *nix kung fu. i run everything from desktop to server with MS platform while learning new stuff on *nix but i won't put my production stuff on *nix 'cause my *nix admin skill is not on par with my Windows admin skill.
Saturday, August 26, 2006
Most "problems" are direct outcome of your frustration and inability to be comfortable with change.

1)Install KDevelop - it comes with a documentation browser which by default installs a ton of documentation. If you have a Internet connection I am sure you should be able to find all you need there. Secondly Linux is UNIX - so most UNIX stuff applies. KDE even has a MAN page IOSLAVE - in konqueror if you do man:/open you should able to view the man page right there. Packages install documentation in /usr/share/doc/<pkg> directory. It is most likely in HTML or PDF format.

2)Cosmetic problem - Fire gdb and attach to the process you want to debug and set break point to the function you are interested to debug. KDevelop, DDD have GUI interfaces to GDB if you are incapable of using command line. (If you write few more lines of code - you could sleep(5) in the function checking for a flag - attach the debugger and set the flag var to 1 which will allow the function to come out of sleep and continue normal execution.)

3)What are you talking about? I didn't understand what you wanted to do and if you just wanted to see if ruby is installed and then do a dlopen that's easy. Not sure why that is tedious. And what does Windows do in such a situation apart from using LoadLibrary? Toolkits like Qt have easy to use Plugin classes. Take a look.

4) So you think letting only one user login to the Windows desktop while logging out all others is a functionality of Windows that you actually miss? Linux is more advanced - it allows more than 1 user to login to more than 1 separate X11 based sessions. Any way how is your problem different from Windows - Windows requires you to login to the remote desktop - so does Linux. With windows the system user account is running the Remote desktop process and on Linux the login user is running it. What is your problem?

5)Provide code and we will see.
Saturday, August 26, 2006
Oh and you need not be required to stick to VNC - You can you Krfb - windows style remote desktop sharing with all the power of UNIX.
Saturday, August 26, 2006
Ben, I agree with you completely. Windows has, hands down, the best development tools and documentation available.

Somewhere behind that, quite a ways in fact, is the Mac, in terms of ease of development.

And Linux is way behind where the Mac is.
Meghraj Reddy
Sunday, August 27, 2006
Thanks for all the help! You guys are invaluable.
Ben Harper Send private email
Sunday, August 27, 2006
As for the wprintf/printf thing, try compiling this:

#include <stdio.h>
#include <wchar.h>

int main( int argc, char** argv )
 wprintf( L"Hello wide\n" );
 printf( "Hello char\n" );

-- I'm running Ubuntu 6.06, and all I get is 'Hello wide'.
Ben Harper Send private email
Sunday, August 27, 2006

the infos here may help -- it seems to be a feature, not a bug.
Sunday, August 27, 2006
"Windows has, hands down, the best development tools and documentation available."

I'm actually a big fan of .Net and VS - but I don't agree that these tools win "hands down". In many cases there are features in Java IDEs that are still better than VS .Net 2005 and Java that I write on a Windows box can be deployed quite happily to Linux or Solaris servers. Native C/C++ tools on Linux are pretty good too - the learning curve is pretty fierce though.

Developing on an open-source platform also has one huge advantage - if something goes wrong you can look at the source. Now for many projects this isn't a big deal - but I've managed projects where it was invaluable that we had the sources.

In many respects, well structured sources are the ultimate documentation!
arethuza Send private email
Sunday, August 27, 2006

if you encounter such behavior,

1) study the function result -- printf has a return value indicating success or failure.

2) study the function definition if googling the symptoms doesn't help.

It is always a good idea to know the functions you want to use and the context in which they work -- though I'm aware that the printf-family is not only one can of worms, but half a dozen cans mixed together.
Sunday, August 27, 2006

Linux is a great place to learn stuff.
Just about everything has the source code.

On windows much is blackmagic.
Simply try writing a device driver on windows and see how soon you bluescreen it.

OTOH, within a week of when I first used linux ( back in 1998 ), I had hacked the kernel to prevent it from locking the CDROM tray and recompiled X Windows to support only my graphics adapter.

Believe me it takes years and years to get the proficiency required to program windows easily.I know coz ive gone from DOS programming to linux to windows all the way upto device driver stuff
Vivek Send private email
Sunday, August 27, 2006
The VNC thing is a complete red herring.  In the UNIX world, things work like this:

1. sshd provided connections via a secure channel, so any client that can speak ssh can connect.

2. You don't need a GUI to do most things, unless you're actually developing GUI apps.  But people will think less of you if you can't accomplish your tasks from the command line.

3. The windowing system natively works on remote terminals, provided they're running an Xwindows service themselves.  VNC would be adding a very unfortunate layer of complexity to the whole mess.

The documentation thing is a complete mess on Linux, and I won't try to make any excuses for it.  The GNU foundation screwed the pooch when they moved their docs to infotext.  OpenBSD, on the other hand, will not install packages that aren't documented via man pages.  Their documentation is wonderously helpful.

The web app debugging you're talking about is strange and shouldn't be tried under any kind of UNIX.  For UNIX a web app is just a console app which happens to know how to parse CGI input.  To debug it you provide input which matches the problem input you're seeing (some CGI libraries even provide a mechanism for this), then debug with gdb.  I generally find though that adequate use of exceptions and exception reporting deals with my debugging problems better than anything else.  And yes, I develop web apps on Linux using C++.

If you find that you need to do more work on Linux, I strongly recommend grabbing the libc manual available from the GNU foundation.  It does a good job of explaining the interwoven behaviors of the standard library.
Clay Dowling Send private email
Sunday, August 27, 2006
Secure nailed it down right - The call to wprintf initializes the stdout file stream to allow wide character I/O and disallow char I/O. Once you initialize a file stream to be either wide char or char it cannot be changed until the stream is closed and re-opened.

More than that you have to question why does your program need this sort of mixed I/O - most programs are either WCHAR enabled or not.
Sunday, August 27, 2006
"More than that you have to question why does your program need this sort of mixed I/O - most programs are either WCHAR enabled or not."

Uh, how about an app that takes data from a network or file source that's doesn't use the app's character type?  Or an app that uses a library that doesn't use the app's character type?
SomeBody Send private email
Sunday, August 27, 2006
Uh, how about an app that takes data from a network or file source that's doesn't use the app's character type?  Or an app that uses a library that doesn't use the app's character type?
Huh? I was questioning the need for doing wchar and char I/O to *same byte stream*. More over, applications typically work with one character set - UTF or WCHAR or just plain US-ASCII for example. Input is converted to the program's in-use character set. On UNIX for example it is most easy to work internally with wchar_t and convert the input from current locale.

And any normal buffer like a network recieve buffer is just that - area of memory - you take it and then interpret it according to the source character encoding and convert it to the program's in-use character set.

Libraries - again you convert to the library's expected charset, nothing to do with mixed I/O into the same byte stream.
Sunday, August 27, 2006
1 - This is subjective.  I could say the same thing in reverse and you are no closer to your end goal.  The bottom line is they are different, documented different and need to be treated as different. man and info are invaluable starter points on a unix box - learn to embrace them along with their invocation options, e.g.  man -k $SOME_GENERAL_TERM  This makes an excellent starting point in the unix world hence the best place to start, "man man"

2 - Remote debugging is fairly straight forward when you read up on the gdb debugger.  A trivial example of attaching to a remote process:

$>ps ua | grep your_exe
(gdb) file your_exe
(gdb) attach your_exe_process_id
Proceed with debugging as needed.  Not sure if you noticed but this can be done via multiple shells, terms, consoles, or even computers if need be.

3 - Not the authority on this so I won't pretend to be in this case.

4 - While unix has VNC support I believe that you might be looking at this the wrong way (as already stated in other replies) X has a very unique design and like stated in bullet point number 1 - windows and unix ARE different and should be treated as such.  ssh and X are the unix way of doing this.  Not to say that you can't use VNC, xrdp, etc. but to imply Windows has better networking support...Well, unix was designed with networking in mind and was never an after thought.  Windows has just recently over the years began to achieve what unix users have been doing for many years in particular domain.

Bottom line is they are different systems and require different approaches.  You can't juxtapose one mindset on both tools and expect to become effective with each.  To say one is better than the other is an idiotic statement on its own merit and you are typically safe to discount anyone making such assertions.  Every problem needs a context to be applicable since generalized solutions generally don't work in all cases.
Chris Send private email
Monday, August 28, 2006
D'oh!  Forgot to chime in on 5

5.  As already been asked:  Why are you writing both unicode and non-unicode on the same stream?  I don't see how this is possible on any platform that uses anything, C or C++ for example, without resetting the stream first.  Initializing of the stream calls the necessary allocation routines for each type.  Mixing and matching of initialized streams seems to be misunderstanding of principle systems rather than lacking support.
Chris Send private email
Monday, August 28, 2006
I think this topic boils down to not liking the unfamiliar. Windows development has the advantage that a lot of things are done for you. Unix development tends to revolve around (relative) simplicity. I prefer simplicity myself, but this may largely be due to my comfort in unix development.

As for your questions...

1: Yes, you do have a point. MSDN has documented everything, it provides so much documentation that I can rarely find what I need quickly. I find MSDN documentation poorly organized.

In the unix world, the programming interfaces also tend to be well documented in man pages. The man pages are even (traditionally) seperated into kernel interfaces (section 2 of the manual) and libraries (section 3 of the manual). This does not mean, of course, that every maker of every library will provide a manual page, nor that these pages meet some minimum level of quality. Of course, GNU is famously frustrating by underdocumenting their man pages in an attempt to get people to care about their info pages, where they can provide more tutorial/documentation like material (as opposed to the reference-like documentation in man pages). From what I can tell, nobody cares.

OpenBSD in particular is big on making sure everything is properly documented. Even there, though, it applies only to things in the base install, obviously they can't control what third parties do (neither can microsoft, and third party library documentation under windows is often somewhat lacking).

2: Run it from GDB? While there's no DebugBreak in linux, you can write one easily. On the IA32, something like this would be sufficient:

#define DEBUG_BREAK asm("int $3")

It is not as flexable as the windows equivilant, but it's an easy way to programatically add breakpoints to your code. You can wrap it in a #ifdef DEBUGCODE if you want.

3: I think it's less of a chore than you are making it out to be, with dlopen(). For tasks like this, automatic code generators really ocme into their own, and are usually the way to handle this sort of problem (automatically generating stub code).

4: Yes, i'll agree vnc on linux is not so good. For most uses, I find you're better off in using the remote desktop features unix has had for decades. X is a network protocol, so I encourage you to use it as such. You can even configure xdm to broadcast xdmcp packets so remote users can just connect.

X apps typically accept a -display param to specify where the input/output device is. The only downside is that X has no concept of a sound device, so there's no standard way to transfer audio.

5: reinitialize stdout.
Brian Mitchell Send private email
Monday, August 28, 2006
annu_gogte, are you being deliberately obtuse or do you really not get it?
SomeBody Send private email
Monday, August 28, 2006
SomeBody - WTH are you talking about? Did you at least read the original question? If you didn't understand - the OP was trying to write CHAR and WCHAR to the same byte stream. You quite ignorantly asked some irrelevant stuff about network and libraries. Do *YOU* get it now? How in the world was your question about Network or File source even vaguely relevant in this context? Care to explain, instead of being obtuse?
Monday, August 28, 2006
byte streams are used to represent data. Streams are commonly used in network communication and libraries.

Can you give an example of wanting to use both wide characters and normal characters in the same stream, and a valid reason for doing so other than wanting too much freedom to change the non-wide necessary lines to use wide output?

As he listed, in network interfaces, it's either transmitted in wide mode or not. Then as a client of the stream, you convert it into the mode that your program uses internally.

How do you consider a concrete example like that "irrelevant" to the OPs question and possible misunderstanding?
Josh McFarlane Send private email
Tuesday, August 29, 2006
Sorry annu, got you mixed up with the other guy.
Josh McFarlane Send private email
Tuesday, August 29, 2006
Just my 2cents:

>want to know how many users have "jon" in their name?
>$ getent passwd | grep jon | wc -l
>You may have an MSDN that tells you how to >call "EnumerateUsers()" , "MatchRegexp()"  etc. But the
>problem is you actually need those docs and a compiler to
>achieve a simple task.

It is all about know your tools:

  wmic useraccount | find /C "Jon"

You want regular expressions?

  findstr /?

All of this "I am such a bash wizard therefore I am Linux god" behaviour is so lame.

Just you not knowing Windows doesn't make Linux imperior.
Husker Send private email
Wednesday, August 30, 2006
>3. What is WITH this service vs application distinction? In linux, you want to test a service, you can just run it on a command line or in a debugger.

This post is kind of tired and closed, but I can't help mentioning- The distinction is between:

rc.0, rc.1, rc.2, rc.etc.etc.etc, init.d, rc.local, inetd, xinetd


'a service' that runs 'at startup' of the machine.

On windows, any reasonable developer will allow their 'service' to be run on the command line too. If you've encountered otherwise, then blame the developer, not Microsoft's abstraction, because take a look at the various efforts to clean up the unix init process and you'll notice that not even unix people are happy with the way linux starts up. Ubuntu is writing a new init thing, I can't recall the name. Apple wrote their own. Sun wrote their own.

The reason I care about this stuff is this-
Just because I am capable of getting somebody else's source code to compile on my machine and/or go through a lengthy process, with the help of google, to get their thing going on my machine, doesn't mean I want to spend my  entire Tuesday night doing that. Doesn't mean I want to spend more than 30 seconds in fact. Unix was clearly made 'for developers, by developers', but has matured into quite a lot more than that. The linux crowd has not as a whole embraced the value in a single-click installer (albeit with some 'Next,Next,Finish' clicking), that works within seconds and requires no further downloads. The stability of the Windows API and infrequency of Microsoft's CRT updates is a grossly undervalued thing.

my 3 cents!
Ben Harper Send private email
Wednesday, August 30, 2006
On my mac, I open the dmg drag the application where I want it to live, and execute it. No installer is necessary. Darwin is a *nix derived system.

Debian has apt-get, I choose a package and install it, if it needs input from me it will prompt me for said input, usually it just does it's thing.

Same for fedora core, ubuntu, and everyone else. The average application deployment in unix requires 0 effort. There's lots of problems with unix systems, this is not one of them.

The fact that vendors don't solve this problem in the same way, however, is one of them.
Brian Mitchell Send private email
Wednesday, August 30, 2006
Ben - But I don't have to distinguish between a service and command line app while writing for UNIX - no special code necessary apart from the standard I/O redirection and the like.

Last I checked I had to write some ugly code to get the thing to run as windows service.

UNIX service is just plain simple - specify run level to start and stop and may be write dumb script to do the book keeping and you are all set. Distros like Gentoo have Vim  templates - you open a file in /etc/init.d directory and you get a pre populated template - write the commands there and you are all set. There is even start-stop-daemon to run processes in  background.

UNIX is about keeping things simple - if you think otherwise your thinking is severely flawed.
Wednesday, August 30, 2006
Hmmm... not sure how much easier it could be to write a Windows service using .NET. It sure looks easy to me.  ;)

namespace TestWindowsService
    public partial class Service1 : ServiceBase
        public Service1()

        protected override void OnStart(string[] args)
            // TODO: Add code here to start your service.

        protected override void OnStop()
            // TODO: Add code here to perform any tear-down necessary to stop your service.
Turtle Rustler
Wednesday, August 30, 2006
Turtle Rustler - there is more to it than that.  You also generally have to have support for the service installer as well.  (VS.NET has a component for this).  Finally you then need to run the service installer.

Of course a unix daemon needs to be put into init scripts and should do various well behaved things such as supporting SIGHUP to reread its configuration.

So, as always, both sides skipped over a whole load of annoying essential details for the sake of their rhetoric :-)
Thursday, August 31, 2006
For all the folks complaining about various distros and incompatible ways of doing services on Linux, there is something called Linux Standards Base (LSB) which specifies the standard way of writing Linux init.d scripts to start/stop your program at boot and shutdown -

Most major distros seem to be LSB compliant - at least Redhat and SuSe are and Ubuntu being Debian based should also be.
Thursday, August 31, 2006
"Turtle Rustler - there is more to it than that. "

Agreed.  :)
Turtle Rustler
Thursday, August 31, 2006
Well, in my humble opinion there are couple things that are confusing about this thread. The title is "What's so awesome about linux?" but Ben complained almost 100% about tools...

It depends on what you are doing and programming right? Say you are programming Java, what tools do you have? Well, there is Eclipse, NetBeans etc. And those tools provide the "nice features". Same in what you are complaining about. VS provides the "nice features" it is tailored to make developers life easy in certain domains.

I am a heavy Linux user (for development). I haver to debug a bunch of code that runs in Unix platforms. This is not very easy with tools in Windows. But they are in Linux (start with X where you can export/import displays!).

Services... yeah Unix like models are simple yet powerful (Solaris has that new SMF feature that makes it even nicer to debug your service).

I think it all depends on the perspective and likes of every person. I cannot stand the fact that I have to hunt down some silly GUI in windows to do something as easy as a restart of a service, in Linux two commands do the trick. I cannot stand the lack of grep, awk, sed, and decent scripting capabilities in Windows (I know there are tools to do this like cygwin but that is not the point).

Linux is still a long way to go from the usability point of view but, it will get better.
Ed Send private email
Tuesday, September 12, 2006
"I cannot stand the fact that I have to hunt down some silly GUI in windows to do something as easy as a restart of a service, in Linux two commands do the trick."


*From the Command Line*


Two Commands Friend :)

It's also extremely easy to write a WSH script that can just prompt you for the service name and do it for you, clickable from the desktop of course.

Alternately you can just press the "Windows" key and go to services from the Administrators menu.  No need to look for GUIs :)

Windows is inherently an end-user operating system.  Commands like grep, etc. are traditionally commands and utilities used by programmers (distributed with *nix due to its design).  There used to be commands like debug, etc. in other versions of windows and those were taken out to protect users from them.  I started learining ASM with debug and "DOS PowerTools" :)

Nate Walker Send private email
Thursday, September 14, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz