dunno much about linux

[MyndFyre]

Oh god, that makes my day! Java's going to be a real player now. Not that it wasn't already =P

EDIT: Oh and Myndfyre, this is why Java > .NET. Just wanted to grind your gears .

.NET 2.0 and .NET 1.0 in source forms.  Check out the date published for 1.0 -- November 5, 2002.  Looks like .NET beat Java to the punch.  Oooh.  Guess you're not as cool as you thought.

As far as your question goes, I've answered it too many times. Here's the last one I posted on this forum (and the ensuing melee):
http://www.x86labs.org:81/forum/index.php/topic,4467.msg49300.html#msg49300

Well, like I said, I understand the hobbyist perspective, and now that VC is free, I think your second point is fairly well-negated, particularly considering the awesome debugger that's in VC.  And, as to your third point, yes, I do shell out the money for software that I like.  When appropriate.  I do not support software piracy, and I do like to support the companies whose software I like.

Incidentally, I open-source most of my software because I generally think others can benefit from it, and I'm too self-conscious to think that I could make money from anything I've written.

That's no excuse.  If you don't know what a socket is in Unix or how they work, you can easily 'man net' or 'man netintro' that explains the network routines.  Documentation is meant to be thorogh.  If you didn't understand something MSDN was saying and it offered no explanation for a concept, then it wasn't thorogh enough.

Speaking of sockets, but I've heard Yoni comment that MSDN does not explain very well how to do proper socket programming and that Skywing had taught him.

man net

I disagree; I think it *is* a valid excuse.  Socket programming in .NET was also something that I struggled with, and in fact I still try to avoid it as much as possible because I sometimes worry that I don't have the error handling correct or something (network I/O, as opposed to file I/O, is a time-specific operation, and sometimes you have to wait and poll for data; it's not that I don't know how to use the API, but I sometimes feel that my handling of these kinds of operational program structures is just off.  (Of course, others have felt the same way, which is why polling is now "out" in favor of I/O completion ports).

It looks like Microsoft is starting to get it ... however, you're still bound to buying different versions of Windows for diferent functionality.  I don't thik Windows is very portable and its obvious that it demands a lot from hardware to run.  Unix is very portable, NetBSD alone exists for dozens upon dozens of platforms, and it provides all the functionality that you need Windows * version to do. 

Well, then - I hate to sound repetitive - but, if it provides all of the functionality that Windows provides, and that users need, why isn't NetBSD taking market?  Platform independence is over-emphasized, and it sounds special, but NetBSD really isn't platform-independent, and - let's be honest - the only thing that Microsoft would need to do to move platforms is provide a new HAL and maybe tweak the kernel according to the memory management demands of the system.

A command interpretor is known as a shell.  I'm glad they adopted the terminal/shell concept.

Microsoft has supported the "shell concept" since MS-DOS.  I used the Norton Utilities 6.0 command shell as my environment in MS-DOS 6.0.  I never loaded command.com.

You wouldn't need a specific windows kernel because it is a true microkernel.  Most Unixes use a monolithic kernel (minus say Mach...thats Microkernel).  Although, I believe you gain a subtle performance gain by compiling certain drivers into the kernel.  Ability to compile a kernel also gives you control over kernel specific features such as SMP, preemption, IPv6 support and a variety of other features.

Windows isn't really true microkernel - it's a bit of a hybrid in that the HAL provides interfaces that drivers must implement in order to work, and so the HAL defines the types of hardware supported by Windows.  Windows can't work with hardware that doesn't have some kind of intrinsic representation in the HAL.  Of course, even the most obscure devices can be made to work by, say, writing a miniport of a bus driver and then layering the functionality by calling, say, DeviceIoControl.  The Windows API just doesn't provide functionality specific to the device until it's been incorporated into the HAL.

Because of the all-mechanism-no-policy nature of Unix, Unix doesn't force the use of a GUI environment nor does it even have a GUI.  Your question about tablet machines really depends on what Xorg or XFree86 can do.  That said, I would be really surprised if some X API didn't exist for touch screens.  Furthermore, I would be surprised if some applications that use this API didn't exist.
What I can tell you for sure is that there is no Window Manager or Desktop Environment that I know of that allows control with a stylus that I know of ... maybe Gnome or KDE. 
One solution would be to write a daemon that interfaces with X and acts like, say, moused.

Like I said, I realize that I'm sure there's something out there that mimics some tablet functionality.  But I guess what I'm saying is - okay, tablets are a cool thing.  Windows has supported them for 3 years (or more).  Since Linux has no "policy," it doesn't define a way for me to expect it to work across distributions, etc.  And I know I couldn't expect to write something like that on my own, at least, not nearly as robust as the Windows implementation.

It's a minor point that I'm sure could be argued across platforms, but it was an example on my mind.

You shouldn't need a kernel debugger to diagnose problems.  One thing I wish Windows had was a console where the kernel could print errors ... Windows has no such thing.  The event logger is not verbose or detailed enough.  The boot log is okay.

I'm sorry, I misspoke because the kernel debugger is the same application as, for instance, the crash dump analysis application.

Code: [Select]

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000066, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e5deb, address which referenced memory

Debugging Details:
------------------
FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  433d2dd2

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
 00000066

CURRENT_IRQL:  ff

FAULTING_IP:
nt!KeReadStateEvent+56
804e5deb 66394616        cmp     word ptr [esi+16h],ax

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

BUGCHECK_STR:  0xA

LAST_CONTROL_TRANSFER:  from 804e5deb to 804e0aac

STACK_TEXT: 
WARNING: Stack unwind information not available. Following frames may be wrong.
b4cda8c0 804e5deb badb0d00 00000000 b4cda910 nt!Kei386EoiHelper+0x2883
b4cda940 804ecdf2 b4cdac98 00000000 00000000 nt!KeReadStateEvent+0x56
b4cda99c 804ecd6a 88b0c528 b4cda9e8 b4cda9dc nt!IoGetBaseFileSystemDeviceObject+0x779
b4cda9ec 804dc819 00000000 00000000 00000000 nt!IoGetBaseFileSystemDeviceObject+0x6f1
b4cdaa0c 804e84ec 00000103 89a6e008 f76dc64f nt!ExReleaseResourceLite+0x280
b4cdaa18 f76dc64f 89a6e1a8 b4cdaa54 8a302470 nt!KeResetEvent+0x1f
b4cdaa2c bae49985 89a6e1a4 887b4b38 00000082 VMNetSrv+0x564f
00000000 00000000 00000000 00000000 00000000 NDIS!NdisDprFreePacketNonInterlocked+0x1b0


STACK_COMMAND:  kb

FOLLOWUP_IP:
VMNetSrv+564f
f76dc64f 015d4c          add     dword ptr [ebp+4Ch],ebx

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  VMNetSrv+564f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: VMNetSrv

IMAGE_NAME:  VMNetSrv.sys

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner
---------
The above is the WinDbg analysis of the memory.dmp file I generated by typing "!analyze -v" once the dump file was loaded (I removed the "wrong symbols" notices because I don't have the symbols installed).  The bugcheck was initiated when I installed a Linksys Wireless-N network card driver.  We can see from the stack trace analysis that the problem initiated in an NDIS call and was apparently faulting in a VMNetSrv.sys.  At the very least this tells us that a network device was faulting - they usually don't just break.  Of course I knew that I had just installed the faulting device.

Thats only a fraction of what you can do with md.  Regardless, you can't do things like update or view hardware parameters.

To demonstrate just one among things I can do with ACPI:

dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
dev.acpi_ibm.0.%driver: acpi_ibm
dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
dev.acpi_ibm.0.%parent: acpi0
dev.acpi_ibm.0.initialmask: 2060
dev.acpi_ibm.0.availmask: 16777215
dev.acpi_ibm.0.events: 0
dev.acpi_ibm.0.eventmask: 2060
dev.acpi_ibm.0.hotkey: 3487
dev.acpi_ibm.0.lcd_brightness: 7
dev.acpi_ibm.0.volume: 14
dev.acpi_ibm.0.mute: 0
dev.acpi_ibm.0.thinklight: 0
dev.acpi_ibm.0.bluetooth: 0
dev.acpi_ibm.0.wlan: 1
dev.acpi_ibm.0.fan_speed: 4025
dev.acpi_ibm.0.fan: 1
dev.acpi_ibm.0.thermal: 46 43 34 48 33 -1 23 -1

Many of these, like 'thinklight', 'volume' and so forth can be modified.
You do not get this kind of flexability in Windows at all.  This is a trivial demonstration, you can do other things like define the max UDP packet size, adjust caching, tune file systems and much much much more.

NOTE: The mask mibs are for devd...devd is a daemon that reacts to hardware events ... it is scriptable, very flexible indeed.

That's just an example.  Low-level hardware access *is* available in Windows, too.  You just need to write a driver.

In the Linux world, most things come precompiled, although, in BSD you do have to often compile your applications.  You can do everything on Unix that you can do on Windows minus gaming, that includes taxes, writing reports and so forth.  Very rarily do you have to hack the OS source or drivers and friends.

Yeah, I know.  I was making a hidden implication that software like OpenOffice just can't compete with Microsoft Office, for instance.

A power user is any user who can use, and usually requires, special and sophisticated features ... usually they are users who are curious about how things work underneath.  They are making a transition between using software to writing software.

So, do you consider me a "power user"?  I read books like Windows Internals for shits and giggles (it's actually really cool, and I hope projects like ReactOS are using design principles from it), and I write software.  Or is it that I'm not a programmer because I only write Windows software?

The device driver I wrote was for a course ... of course I don't normally write drivers, its extremely difficult.  But I would like to bring to your attention that for our last project we had to write a device driver for real hardware, many had trouble finding hardware, new and old, for this project because there are already so many device drivers available.  As much as I dislike Linux...Linux supports thousands if not hundreds of devices.

In my assembly language course, which I *hated*, we had to interface with the SDK-86, which is basically a rudimentary hardware debugger and numeric keypad for the 8086.  They were horrid days!  (At least debugging the 80186 let us use a connected terminal running a debugger... ugh). 

Incidentally, I probably could have sent you hardware that Linux doesn't play nice with.    You should have done work on Winmodems or something!  Just think of the headaches you would have saved.

[Ender]

Oh god, that makes my day! Java's going to be a real player now. Not that it wasn't already =P

EDIT: Oh and Myndfyre, this is why Java > .NET. Just wanted to grind your gears .

.NET 2.0 and .NET 1.0 in source forms.  Check out the date published for 1.0 -- November 5, 2002.  Looks like .NET beat Java to the punch.  Oooh.  Guess you're not as cool as you thought.

My bad. But the ego-crunching was unnecessary ;-)

[nslay]

That's no excuse.  If you don't know what a socket is in Unix or how they work, you can easily 'man net' or 'man netintro' that explains the network routines.  Documentation is meant to be thorogh.  If you didn't understand something MSDN was saying and it offered no explanation for a concept, then it wasn't thorogh enough.

Speaking of sockets, but I've heard Yoni comment that MSDN does not explain very well how to do proper socket programming and that Skywing had taught him.

man net

I disagree; I think it *is* a valid excuse.  Socket programming in .NET was also something that I struggled with, and in fact I still try to avoid it as much as possible because I sometimes worry that I don't have the error handling correct or something (network I/O, as opposed to file I/O, is a time-specific operation, and sometimes you have to wait and poll for data; it's not that I don't know how to use the API, but I sometimes feel that my handling of these kinds of operational program structures is just off.  (Of course, others have felt the same way, which is why polling is now "out" in favor of I/O completion ports).

I don't know what you're talking about, socket programming is extremely easy, and so is the error handling.  The man pages make error handling very clear cut.  If MSDN documentation was thorough, then you would not need to worry about handling errors properly.

It looks like Microsoft is starting to get it ... however, you're still bound to buying different versions of Windows for diferent functionality.  I don't thik Windows is very portable and its obvious that it demands a lot from hardware to run.  Unix is very portable, NetBSD alone exists for dozens upon dozens of platforms, and it provides all the functionality that you need Windows * version to do. 

Well, then - I hate to sound repetitive - but, if it provides all of the functionality that Windows provides, and that users need, why isn't NetBSD taking market?  Platform independence is over-emphasized, and it sounds special, but NetBSD really isn't platform-independent, and - let's be honest - the only thing that Microsoft would need to do to move platforms is provide a new HAL and maybe tweak the kernel according to the memory management demands of the system.

It may not have market share, but that does not negate its ability as a workstation, server, or embedded OS.
That is a fallacious argument.

EDIT:  Unix is historically, and still is, extremely portable.  That's why it still exists today.

A command interpretor is known as a shell.  I'm glad they adopted the terminal/shell concept.

Microsoft has supported the "shell concept" since MS-DOS.  I used the Norton Utilities 6.0 command shell as my environment in MS-DOS 6.0.  I never loaded command.com.

MS-DOS is not a shell.
A shell is any independent program that interfaces human input/output to/from the system.
A terminal is a piece of hardware or software in which a shell is invoked. The terminal displays output from the shell and forwards input to the shell.
Is there an MS-DOS shell that Command Prompt invokes separately?  As far as I know, Command Prompt is not a terminal or a shell.

Examples of terminal/shell model:
xterm with bash
aterm with csh
eterm with ksh
aterm with bash
xterm with csh
...

Because of the all-mechanism-no-policy nature of Unix, Unix doesn't force the use of a GUI environment nor does it even have a GUI.  Your question about tablet machines really depends on what Xorg or XFree86 can do.  That said, I would be really surprised if some X API didn't exist for touch screens.  Furthermore, I would be surprised if some applications that use this API didn't exist.
What I can tell you for sure is that there is no Window Manager or Desktop Environment that I know of that allows control with a stylus that I know of ... maybe Gnome or KDE. 
One solution would be to write a daemon that interfaces with X and acts like, say, moused.

Like I said, I realize that I'm sure there's something out there that mimics some tablet functionality.  But I guess what I'm saying is - okay, tablets are a cool thing.  Windows has supported them for 3 years (or more).  Since Linux has no "policy," it doesn't define a way for me to expect it to work across distributions, etc.  And I know I couldn't expect to write something like that on my own, at least, not nearly as robust as the Windows implementation.

Don't think of Unix as solely a set of distributions.  That is unique to Linux.
Linux is a kernel by itself.  A Linux distribution bundles commonly preferred software by a group, the GNU userland, and the Linux kernel.  On the other hand, all other Unixes, AIX, BSD, IRIX and so forth are true operating systems.  They include their own kernel and their own tools.

It's a minor point that I'm sure could be argued across platforms, but it was an example on my mind.

You shouldn't need a kernel debugger to diagnose problems.  One thing I wish Windows had was a console where the kernel could print errors ... Windows has no such thing.  The event logger is not verbose or detailed enough.  The boot log is okay.

I'm sorry, I misspoke because the kernel debugger is the same application as, for instance, the crash dump analysis application.

Code: [Select]

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000066, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e5deb, address which referenced memory

Debugging Details:
------------------
FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  433d2dd2

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
 00000066

CURRENT_IRQL:  ff

FAULTING_IP:
nt!KeReadStateEvent+56
804e5deb 66394616        cmp     word ptr [esi+16h],ax

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

BUGCHECK_STR:  0xA

LAST_CONTROL_TRANSFER:  from 804e5deb to 804e0aac

STACK_TEXT: 
WARNING: Stack unwind information not available. Following frames may be wrong.
b4cda8c0 804e5deb badb0d00 00000000 b4cda910 nt!Kei386EoiHelper+0x2883
b4cda940 804ecdf2 b4cdac98 00000000 00000000 nt!KeReadStateEvent+0x56
b4cda99c 804ecd6a 88b0c528 b4cda9e8 b4cda9dc nt!IoGetBaseFileSystemDeviceObject+0x779
b4cda9ec 804dc819 00000000 00000000 00000000 nt!IoGetBaseFileSystemDeviceObject+0x6f1
b4cdaa0c 804e84ec 00000103 89a6e008 f76dc64f nt!ExReleaseResourceLite+0x280
b4cdaa18 f76dc64f 89a6e1a8 b4cdaa54 8a302470 nt!KeResetEvent+0x1f
b4cdaa2c bae49985 89a6e1a4 887b4b38 00000082 VMNetSrv+0x564f
00000000 00000000 00000000 00000000 00000000 NDIS!NdisDprFreePacketNonInterlocked+0x1b0


STACK_COMMAND:  kb

FOLLOWUP_IP:
VMNetSrv+564f
f76dc64f 015d4c          add     dword ptr [ebp+4Ch],ebx

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  VMNetSrv+564f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: VMNetSrv

IMAGE_NAME:  VMNetSrv.sys

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner
---------
The above is the WinDbg analysis of the memory.dmp file I generated by typing "!analyze -v" once the dump file was loaded (I removed the "wrong symbols" notices because I don't have the symbols installed).  The bugcheck was initiated when I installed a Linksys Wireless-N network card driver.  We can see from the stack trace analysis that the problem initiated in an NDIS call and was apparently faulting in a VMNetSrv.sys.  At the very least this tells us that a network device was faulting - they usually don't just break.  Of course I knew that I had just installed the faulting device.

Ever heard of dumping core?  The Unix-Haters handbook loves to poke fun of it.  Applications who misbehave dump core and terminated.  Then a debugger can be used to study the core file.

Thats only a fraction of what you can do with md.  Regardless, you can't do things like update or view hardware parameters.

To demonstrate just one among things I can do with ACPI:

dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
dev.acpi_ibm.0.%driver: acpi_ibm
dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
dev.acpi_ibm.0.%parent: acpi0
dev.acpi_ibm.0.initialmask: 2060
dev.acpi_ibm.0.availmask: 16777215
dev.acpi_ibm.0.events: 0
dev.acpi_ibm.0.eventmask: 2060
dev.acpi_ibm.0.hotkey: 3487
dev.acpi_ibm.0.lcd_brightness: 7
dev.acpi_ibm.0.volume: 14
dev.acpi_ibm.0.mute: 0
dev.acpi_ibm.0.thinklight: 0
dev.acpi_ibm.0.bluetooth: 0
dev.acpi_ibm.0.wlan: 1
dev.acpi_ibm.0.fan_speed: 4025
dev.acpi_ibm.0.fan: 1
dev.acpi_ibm.0.thermal: 46 43 34 48 33 -1 23 -1

Many of these, like 'thinklight', 'volume' and so forth can be modified.
You do not get this kind of flexability in Windows at all.  This is a trivial demonstration, you can do other things like define the max UDP packet size, adjust caching, tune file systems and much much much more.

NOTE: The mask mibs are for devd...devd is a daemon that reacts to hardware events ... it is scriptable, very flexible indeed.

That's just an example.  Low-level hardware access *is* available in Windows, too.  You just need to write a driver.

Yes, but these settings are not always available by the driver.  Skywing had to write a driver to throttle his computer's speed because the ACPI driver offered no such functionality.  He needed this because his computer would often overheat.  On the other hand, these settings in Unix (more specifically BSD and Linux) are universally available.

In the Linux world, most things come precompiled, although, in BSD you do have to often compile your applications.  You can do everything on Unix that you can do on Windows minus gaming, that includes taxes, writing reports and so forth.  Very rarily do you have to hack the OS source or drivers and friends.

Yeah, I know.  I was making a hidden implication that software like OpenOffice just can't compete with Microsoft Office, for instance.

To be frank, OpenOffice sucks but to be fair, Microsoft Office is quite an old project.  Microsoft has been developing this office suite for a decade (?).  I can remember Office versions that were bloated and slow too.  OpenOffice on the other hand is a very young project.

A power user is any user who can use, and usually requires, special and sophisticated features ... usually they are users who are curious about how things work underneath.  They are making a transition between using software to writing software.

So, do you consider me a "power user"?  I read books like Windows Internals for shits and giggles (it's actually really cool, and I hope projects like ReactOS are using design principles from it), and I write software.  Or is it that I'm not a programmer because I only write Windows software?

I sure do, although I think you could learn a great deal more from Unix.

The device driver I wrote was for a course ... of course I don't normally write drivers, its extremely difficult.  But I would like to bring to your attention that for our last project we had to write a device driver for real hardware, many had trouble finding hardware, new and old, for this project because there are already so many device drivers available.  As much as I dislike Linux...Linux supports thousands if not hundreds of devices.

In my assembly language course, which I *hated*, we had to interface with the SDK-86, which is basically a rudimentary hardware debugger and numeric keypad for the 8086.  They were horrid days!  (At least debugging the 80186 let us use a connected terminal running a debugger... ugh). 

Incidentally, I probably could have sent you hardware that Linux doesn't play nice with.    You should have done work on Winmodems or something!  Just think of the headaches you would have saved.

Haha, I've talked to a grey beard about winmodems.  Do you know what a winmodem is?  It's essentially a piece of hardware that gives the OS direct access to the phone line.  Basically, when you buy a winmodem, you're buying a piece of metal that does absolutely nothing, or a small subset of what a real modem does.  Not only that, but winmodem device drivers are modem specific ... it's even so bad as being revision specific sometimes.  Very little to no code can be recycled between winmodem drivers.  I had contemplated writing a winmodem device driver, but after talking to this guy, now I know why nobody else bothers.  There is a Linux effort to support winmodems, but I think its pointless.  It's better to buy a real modem, preferrably serial or USB.

[MyndFyre]

I don't know what you're talking about, socket programming is extremely easy, and so is the error handling.  The man pages make error handling very clear cut.  If MSDN documentation was thorough, then you would not need to worry about handling errors properly.

It's definitely easy now that I understand it.  But what defines "thorough"?  To me, that sounds like an arbitrary measurement for the sake of the argument.  What I might consider thorough, someone with absolutely no experience might say "WtfIdungetitwritemecode."  Of course, I tend to think now that socket programming is more a self-explanatory thing, and I'm not saying that this is an excuse for non-documentation.

It may not have market share, but that does not negate its ability as a workstation, server, or embedded OS.
That is a fallacious argument.

EDIT:  Unix is historically, and still is, extremely portable.  That's why it still exists today.

I didn't once disagree that it's extremely portable.  My question was - if it's free and provides all the functionality of Windows, which is what you'd stated, why hasn't it taken more desktop market?  If it really is as good as you say it is, you'd think that more people would use it.

The thing is, it doesn't provide all the functionality of Windows, because if it did, it wouldn't have such a learning curve.

MS-DOS is not a shell.
A shell is any independent program that interfaces human input/output to/from the system.
A terminal is a piece of hardware or software in which a shell is invoked. The terminal displays output from the shell and forwards input to the shell.
Is there an MS-DOS shell that Command Prompt invokes separately?  As far as I know, Command Prompt is not a terminal or a shell.

Yes, I'm quite aware of that.  What I said was, Microsoft has supported the shell concept since MS-DOS.  In MS-DOS, your shell was the command interpreter - that provided the interactivity between the system and the user.  That was command.com by default, but Microsoft let third-party shells exist by providing the SHELL= statement to be in config.sys.  As I showed you, Windows also supports third-party shells (I provided the example of bbLean; I've seen other shells as long ago as Windows 95 on my aunt's computer).

When I said "MS-DOS" I meant specifically the operating system MS-DOS, not the command prompt in Windows.  In Windows, no, it is not a shell.

Don't think of Unix as solely a set of distributions.  That is unique to Linux.
Linux is a kernel by itself.  A Linux distribution bundles commonly preferred software by a group, the GNU userland, and the Linux kernel.  On the other hand, all other Unixes, AIX, BSD, IRIX and so forth are true operating systems.  They include their own kernel and their own tools.

Yeah, if you want to be technical.  I'm talking practical.

Ever heard of dumping core?  The Unix-Haters handbook loves to poke fun of it.  Applications who misbehave dump core and terminated.  Then a debugger can be used to study the core file.

I wasn't saying that Unix doesn't have it.  I was simply saying that you were wrong - it is NOT a painful process to track down problems in Windows.

Yes, but these settings are not always available by the driver.  Skywing had to write a driver to throttle his computer's speed because the ACPI driver offered no such functionality.  He needed this because his computer would often overheat.  On the other hand, these settings in Unix (more specifically BSD and Linux) are universally available.

As dumb as I think that is (you have problems with the way your computer is built physically if your processor overheats at 100% of rated maximum), it'll be supported in Windows Vista.  That's not an excuse in and of itself, but things *are* coming around in that regard.

To be frank, OpenOffice sucks but to be fair, Microsoft Office is quite an old project.  Microsoft has been developing this office suite for a decade (?).  I can remember Office versions that were bloated and slow too.  OpenOffice on the other hand is a very young project.

It's not that young.  It's a descendent of StarOffice, which I was using back in Chicago for some time (this is at least 8 years ago).

I sure do, although I think you could learn a great deal more from Unix.

I'm sure.  I think it could learn a lot from me too.   

Haha, I've talked to a grey beard about winmodems.  Do you know what a winmodem is?  It's essentially a piece of hardware that gives the OS direct access to the phone line.  Basically, when you buy a winmodem, you're buying a piece of metal that does absolutely nothing, or a small subset of what a real modem does.  Not only that, but winmodem device drivers are modem specific ... it's even so bad as being revision specific sometimes.  Very little to no code can be recycled between winmodem drivers.  I had contemplated writing a winmodem device driver, but after talking to this guy, now I know why nobody else bothers.  There is a Linux effort to support winmodems, but I think its pointless.  It's better to buy a real modem, preferrably serial or USB.

Yeah, I agree.  ;-)  I've always hated Winmodems.  But like I said - if you wanted to find hardware to support.... ;-)

[nslay]

I don't know what you're talking about, socket programming is extremely easy, and so is the error handling.  The man pages make error handling very clear cut.  If MSDN documentation was thorough, then you would not need to worry about handling errors properly.

It's definitely easy now that I understand it.  But what defines "thorough"?  To me, that sounds like an arbitrary measurement for the sake of the argument.  What I might consider thorough, someone with absolutely no experience might say "WtfIdungetitwritemecode."  Of course, I tend to think now that socket programming is more a self-explanatory thing, and I'm not saying that this is an excuse for non-documentation.

Okay, I made a comparison between BSD's socket man page and MSDN's socket page and they both seem to follow the same "thorough" style.
That is:
1) A synopsis
2) A description
3) Return values
4) Error codes
5) External references

Although in my past experience I've had a bad time with MSDN.

EDIT: We could argue BSD's socket man page is more descriptive and informative than MSDN's

It may not have market share, but that does not negate its ability as a workstation, server, or embedded OS.
That is a fallacious argument.

EDIT:  Unix is historically, and still is, extremely portable.  That's why it still exists today.

I didn't once disagree that it's extremely portable.  My question was - if it's free and provides all the functionality of Windows, which is what you'd stated, why hasn't it taken more desktop market?  If it really is as good as you say it is, you'd think that more people would use it.

The thing is, it doesn't provide all the functionality of Windows, because if it did, it wouldn't have such a learning curve.

Market share and learning curve have nothing to do with its functionality.  You seem correlate the two that:
Small Unix market share => Unix isn't very functional
Thats a fallacy!

Can Unix be made into a reliable desktop? YES.  Many people use it as a desktop everyday, especially academia.
Can a desktop Unix do taxes, reports and just about anything work related under the sun? YES.  FreeBSD is the less popular of popular Unixes and it has 15000 ports available ... I've had very little trouble finding software that does what I need.
Does it play games?  NO
Can Unix be made into a reliable server? YES.  Thats why Google(Linux), Yahoo(FreeBSD), Qwest(FreeBSD and Linux) and so forth use it.  Check netcraft.
Can Unix be used as an embedded OS? YES  If you're using a DI-624M, WRT54G, Tivo, etc, then you're using a device that runs Linux.

Does it have a learning curve? YES  Does that mean it doesn't have most of the functionality most people want? NO.

Does it have more functionality than a single version of Windows...I'd argue that it does.  It can be setup to do anything without licensing or worries of the OS version.  There is no Unix Server, Unix Advanced Server, Unix Home Edition, Unix Professional, Unix Web Server etc...

Ever heard of dumping core?  The Unix-Haters handbook loves to poke fun of it.  Applications who misbehave dump core and terminated.  Then a debugger can be used to study the core file.

I wasn't saying that Unix doesn't have it.  I was simply saying that you were wrong - it is NOT a painful process to track down problems in Windows.

Maybe for software crashes, but I've had times where problems were extremely hard to diagnose.
For example, back in the Windows 2000 days, before even Code Red, I had this german guy break in (through IIS) to a Windows 2000 Adv Server machine and delete the windows shell registry key.  I have no clue how you would diagnose that without special knowledge of the registry or Windows shell.  Skywing ended up telling me that was the problem. 
If something like that happened in X with a window manager, the X documentation explains how X works, what initialization scripts it invokes and so forth.

Yes, but these settings are not always available by the driver.  Skywing had to write a driver to throttle his computer's speed because the ACPI driver offered no such functionality.  He needed this because his computer would often overheat.  On the other hand, these settings in Unix (more specifically BSD and Linux) are universally available.

As dumb as I think that is (you have problems with the way your computer is built physically if your processor overheats at 100% of rated maximum), it'll be supported in Windows Vista.  That's not an excuse in and of itself, but things *are* coming around in that regard.

Right, but for now, sysctl (thats the output I quoted) interface is way more powerful than what Windows drivers offer.  It lets you adjust most kernel and hardware features.
I dumped everything in sysctl:
EDIT: sysctl.txt
Pretty extensive huh?  Much of it can be modified, the rest is read-only.

I sure do, although I think you could learn a great deal more from Unix.

I'm sure.  I think it could learn a lot from me too.   

Big talk for someone largely unfamiliar with Unix