|
In spite of all the monopolistic claims against Microsoft, they definately have one thing going for them: Consistent APIs. Now, this doesn't mean that I like some of the APIs, because they can indeed be clumsy at times. However, if anyone here has ever tried to write software that is portable across different Unix variants, or even different versions of the same variant, (I have done both), then you know how much of a headache it can be.
A good example of this is writing an application that runs under XWindow. Do you want to support raw Xlib, Motif, GTK, or Qt? Which version will you support? How can you guarentee that the end-user will have that particular library installed?
Even for command line applications, simliar issues arise: Who's libc will you use? Which version? Are you interfacing with kernel structures? If so, how? Is your Unix variant POSIX compliant, giving you access to certain standardized functions?
While you could argue, and rightfully so, that if I'm just downloading something, the GNU configure script can take care of a lot of the differences, there is a catch: As a system administrator, I would not want to have to download source code and compile it for 'n' different Unix variants and versions in my shop. I would rather everyone use a single platform that I can download a binary for, and simply install it.
And yes, a shop could standardize on a specific Unix variant, but then there's always the question of hardware support. If something in your computer is not on your Unix vendors list of supported hardware, then you're out of luck. (Unless you use something like a Sun, where one company is responsible for both the hardware and the software. Apple, anyone?)
I would enjoy seeing some arguments in favor of variety, rather than standardization! Please, prove me wrong! 
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Well, with Unix, however, you usually have a choice whether you want a binary (that is if you are using a popular variant and the binary is availabe) or you can compile from source (typically provided). Under windows it's not so obvious because the OS doesn't come with compiler, so you can do nothing unless you buy compiler and by any luck there is a source.
API are totally unconsistent under Win - see the time stamp problems and even something so simple as the conversion betweeen the "long" and "short" filename under Win95, 98, NT and w2k. Enjoy!
|
|
|
|
|
I'm sorry, but I have yet to find a user who will compile my product before using it. Get real, most people don't even know how to click on setup.exe
Cheers,
Karim.
|
|
|
|
|
The trick is, they can compile. It's not all that hard to type:
make ./install
The Unix will not let the system to fall just because user will install some software. Try that with windows - it's gonna die hard just because of some DLL being replaced by stupid setup.exe.
|
|
|
|
|
I'm sorry George, but I have to agree with Karim. In the past, I have worked as a teacher in adult education classes for people wanting to learn more about computers. I have also done one-on-one training for people at their homes. Probably 99% of them simply don't understand what a compiler is, or how to use one. Nor should they!
A compiler is a tool used by software developers. I would not expect the end-user of one of my products to understand how to compile it from source. Besides, not all Unix variants come with a compiler. The ones that are commercially available (Solaris, Irix, HP-UX, AIX, etc.) usually do not have any bundled compilers. Yes, they could download GCC and install it, but even then, they would have to download a binary for their system, and install it, because they don't have a native compiler to build GCC from sources.
You have to stop looking at things from your limited point of view as a developer. To understand how a user thinks, look at a software installation from your parents' or grandparents' point of view. Would they rather have a computer that simply "works", and can have new software installed just by inserting a disc in the CD-Rom drive, or should they have to learn what a configure script is, how to run make, and how to edit in vi or emacs when something doesn't go quite right?
Try to be a little more open-minded about this subject, rather than using a "fallacy of hasty generalization" in many of your posts.
FYI: "Fallacy of hasty generaliztion" means using too small of a sample to support an argument. For example: I had a setup program overwrite a DLL, therefore all setup programs will exhibit this behaviour. In fact, Microsoft has gone to great lengths with the file protection system to ensure that this does not happen, even when a setup program misbehaves.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Gee, come on - the point is that you CAN, not that you HAVE TO compile the stuff. Most of the time - take a Red Hat Linux - you also get a binary and it works out of the box, the user has no problem to install or use. If you use a popular platform - you get a binary. If not - there is a code to save your ass and money. This is not a limited point of view - it's as broad as you can get, because I am talking about a choice here, and you are talking about the "user" - pretty narrow.
Now - CD-ROM trick is no problem - works everywhere. To run make you simply type "make".
You are using a very small sample to support your argument. Eg.: "I once had to install software by compiling it on Unix therefore every installation is a compilation on Unix". Truth is - any system CAN be user friendly or not, on a case by case basis. However, Unix as being properly designed, maintained and reviewed offers a lot more on the security and stability fields. It is a good choice for a comming generation of people who know how to use make and who want to have a choice. We just have to wait and see how it all goes along... 
|
|
|
|
|
My comment about your generalization was made in reference to your statement:
The Unix will not let the system to fall just because user will install some software. Try that with windows - it's gonna die hard just because of some DLL being replaced by stupid setup.exe.
I have had this problem with Unix systems, including Solaris and GNU/Linux. Software wants to dump some dependant libraries in /usr/local/lib, and another piece of software installs a different version of these libraries in /opt/*/lib. Which one you get depends on the setting of the LD_LIBRARY_PATH environment variable, and the settings in /etc/ld.so.conf. I have even had 'make install' scripts add things to /lib and /usr/lib, or change one of the symlinks to point to a "newer" version of a library, just to have it blow up on me. As I stated in my previous post, Microsoft is working toward eliminating this problem. Their solution may not be the best, but at least they're trying to do something about it.
However, I never made a general statement saying that installing from source is the only choice for Unix systems. I am merely pointing out that it is impractical for most end-users.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
The fact is, George, people are still complaining on how difficult computers are to use, even with Windows. How do you expect them to cope with UNIX?
Microsoft are trying to get rid of DLL hell. That's what COM was about, and that's what .NET is about. Together with the new installer service, this can reduce user irritation, and puts the onus on the developer to make a clean installation script.
As an example, I was recently installing a PERL-based app on a web hoster's server for a client. The PERL app needed several modules which were not installed. Although the technical support staff were very willing, they didn't have a clue how to install these modules. If tech. support have difficulty with a relatively simple task like this, how do you think Gran'ma Ethel is going to cope? She's not. In fact, she wouldn't even get close. You may argue that PERL is not compiled, but the fact is, even tech support get confused sometimes. While this remains true, Windows setup, though not perfect, is the only viable alternative for 99.9 percent of our clients.
Speaking of clients, I have yet to find one who didn't want Windows. This being the case, I will continue to develop for the platform of choice. Why develop for the 10% when you can develop for the 90%? It doesn't make financial sense!
Cheers,
Karim.
|
|
|
|
|
>How do you expect them to cope with UNIX?
Usually "people" are not working with computers but rather with applications. So in fact the individual applications decide how easy or how difficult the work is. Typically, installation if a fraction of the whole time the computer is used, so it doesn't matter too much. Sure everybody says that vi is hard to use, but at the same time MS Word is as much confusing to the beginner. It's a matter of proper training to get used to particular software - then it all goes smoothly.
>people are still complaining on how difficult computers are to use,
>even with Windows
Well, with windows people mostly complain about crashes
>Microsoft are trying to get rid of DLL hell.
>That's what COM was about, and that's what .NET is about.
Nah, that's not it. That's more about the money and power
It's just replacing one hell with another. Also, .NET (Runtime error - object doesn't support the property or method.) is somehow a weapon against Java, specially C#.
>If tech. support have difficulty with a relatively simple task like
>this, how do you think Gran'ma Ethel is going to cope?
Well, are you sure those people are qualified to be a tech support? I notice a skills downgrade among the IT staff related to Windows, but I was always explaining that it's just my biased mind. You should see two sysadmins trying to figure out why two similiarly configured servers didn't work identical. All those jumping from one "properties" screen to another and trying to see if any checkbox or radio button is set differently. "Registry hell"? Any solution for that? Also it was so much fun to see them rebooting 10 times to no effect
>Speaking of clients, I have yet to find one who didn't want Windows.
>This being the case, I will continue to develop for the platform of choice.
>Why develop for the 10% when you can develop for the 90%?
Well, the right tool for the right job. Windows for the people, Unix for the server. Truly, anybody who cares about their data and reliability will prefer Unix, and a really big guys are almost always using Unix-based solutions. For the security, speed and stability. Those 10% actually holds 90% of money in their hands
Also, I don't care about "financial sense" - I do it for fun and joy of it, they pay me but it's not the most important factor.
|
|
|
|
|
I voted for multiple desktops with equal market share. No, I am not a masochist. But if that were the case, I could almost guarantee that more people/companies would put effort into cross-platform tools. Already there are some, there are interpereted languages such as Java, and also cross-platform C++ libraries, like wxWindows and Qt. You are right in that it can still be cumbersome to develop an application that works similarly in multiple platforms. If Windows weren't so dominant, I bet there would be more focus on creating good cross-platform solutions.
That being said, you can argue that the WinAPI itself is inconsistent... many APIs function quite differently on 9X than they do on NT, 2000, and XP, although users expect programs to work the exact same on all Windows OS's.
Variety is the spice of life.
|
|
|
|
|
> A good example of this is writing an application that runs under XWindow.
> Do you want to support raw Xlib, Motif, GTK, or Qt? Which version will you
> support? How can you guarentee that the end-user will have that particular
> library installed?
I'm about to delve into a little Linux C++ coding for XWindows. Is it even possible to make a statically linked executable program for XWindows?
I'm completely new to Linux, so go slow. 
|
|
|
|
|
As long as you have a static version of the library, then yes, you can link your program against it.
Netscape has always done this with Navigator and Communicatior. They are basically Motif applications, as is evident by the "look 'n' feel" of the window. However, the product was released long before Motif went open source, and Netscape was not authorized to distribute the Motif libraries, so they statically linked the whole thing. That is why the executable is so huge, and takes so long to load.
In the Windows world, you link against a .lib file. If that .lib file happens to correspond to a .dll file, then the .dll will be loaded at run time. However, if the .lib file was a static library, then the linker grabs the whole thing.
On all Unix variants that I am aware of, libraries come in two flavors: .a (static) and .so (shared object). Instead of needed two separate .lib files and the .dll, there are simply two library files. One is static and one is dynamic. Link against the appropriate one, and you're all set. The problem, of course, is that not every library is available in both flavors. A lot of times you have to take what you can get.
Good luck!
--
Paul
"I drank... WHAT?"
|
|
|
|
|
they definately have one thing going for them: Consistent APIs
Yep
I once worked a place where we both used Linux and Windows at the desktop (for security testing stuff).
When we got a new version of Windows, we just installed the good old program, and it worked
When we got a new version of Linux, the Linux guy had to compile all the programs, change a lot of code, on those that didn't work, and test them, before we could use them. 
A lot of the Linux programs we used just didn't work with newer versions...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Why should our applications be run directly on OS?
I think most applications can be run on higher platforms than OS that ensure the standardization, then we can choose any OS.
The platform seems to be Java Virtual Machine now.
Though the Java apps is much slower than Win apps.
What do u think, eh?;)
|
|
|
|
|
The largest problem with using a "higher" (meaning abstracted from the underlying OS) platform for your application means that this abstraction is usually based on the lowest common denominator of all the OS's that it supports.
There are many features in both Windows and Solaris that are not supported by Java, simply because the feature is so specific to that platform. If you plan to take advantage of it, then you end up having to write some of your code in another language, and then use JNI to glue the pieces together. (Unfortunately, JNI is hopelessly slow, which precludes its everyday use.) You end up with an application that is locked to a particular OS, even though you wrote it in this wonderful platform independant language!
For the moment, most of the application development I intend to do will be Windows-based, and use C or C++. I just don't see the advantages of writing code for other platforms that do not have as large of a user base.
Another thing that I have against Java is that Sun wanted everyone to adopt it as a language that would run on anything, because the JVM would be so widely ported. Right now, we have solid JVM implementations for Windows and Solaris, because that is what Sun itself is willing to support. There are implementations available for other OS's, such as Irix, Linux, and FreeBSD, but the JVMs available are usually not the lastest verson (1.1 and maybe 1.2), they do not support the newer features of the language itself, and they do not support some of the newer libraries like Java3D and the JMF. The result of this is that I would only be able to support Windows and Solaris. The number of Solaris users who would want my software is small, which sends me right back to Windows. Now, what is the point of having a 30MB JVM to (slowly) run a 20kB jar file, when I could have used the WTL and ended up with a 50kB executable that runs 50x faster? Thanks, but no thanks, Sun.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
