Re: Is Linux Unix?

• Previous message: Silvan: "Re: Is Linux Unix?"
• In reply to: Kent West: "Re: Is Linux Unix?"
• Next in thread: Karsten M. Self: "Re: Is Linux Unix?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 23 Jul 2004 22:02:34 -0700
To: debian-user@lists.debian.org

Kent West wrote:
> Erik Steffl wrote:
>
>> Kent West wrote:
>>
>>> The result is that the vendor chooses not to go down that path, and
>>> Linux remains a niche product rather
>>
>>
>>
>> let's see another example.
>
>
> <snip>
>
>> so there you go, windows will remain a niche product blah blah blah...
>
> Calling a product that has 3% of the market a "niche product" seems to
> make sense to me. Calling a product that has 90% of the market a "niche
> product" doesn't make sense to me.

   it's not about the percentage but about the line of reasoning plus a
little bit of kidding on the side.

   anectodal evidence against anecdotal evidence - not much reasoned in
the end, what my example was meant to imply is that you cannot
generalize from one example (intel fortran does not determine fate of linux)

   not very strong argument but I also wanted to suggest that version
incompatibility _exists_ in other OSs (that are not really niche, as you
point out)

   also note that linux is niche on desktops but not on servers, the
original poster didn't talk specifically about desktops so one could
also argue that linux already is not niche product.

>>> You keep looking at this from the customer's point of view; the customer
>>
>> do you work for MS?
>
> Nope.
>
>> why did you snipped my suggestion on how to deal with the issue FROM
>> VENDOR SIDE and then you complain I don't look at it from vendor side?
>
> Because I mistakenly was overly aggressive in my snipping, and because I
> misunderstood what you were saying. Up until this point, it seemed to me
> that you were looking at things from the customer viewpoint rather than
> the vendor viewpoint Here's your paragraph just before your bullet points:
>
> I
>> don't understand it. if you (they) think that it is acceptable to buy
>> computer with windows just to make sure that the client has OS that
>> software company supports why wouldn't it be acceptable to buy
>> computer with redhat linux? if you are willing to have a dedicated
>> machine then
>> you can have a dedicated machine that plays nicely with other linux
>> machines...
>
> The paragraph seems to start out from the customer's viewpoint; I
> assumed that it ended from the customer's viewpoint. After re-reading
> the paragraph in light of your response, I'm no longer sure that it
> starts from the customer's viewpoint (it was the "if you ... think that
> it is acceptable to buy computer..." that made me think that).

   oh, that was a response to particular case that original poster
mentioned, about the comapny that makes customer buy a machine for their
software.

> Immediately after this paragraph was:
>
>> depending on the circumstances (not all solutions are
>> possible/desirable in all situations):
>
>> - statically link everything
>>
>> - provide your own shared libs (do not install in system dirs!)
>>
>> - have an experienced sysadmin set up the machine
>>
>> - develop portable software, do not depend on random quirks of
>> kernels/libs
>
> Not being a developer/programmer, I did not pay enough attention to
> these bullet points to recognize that three of these things are
> vendor-oriented.
>
> There was no intended slight on what you had to say; merely
> ignorance/misunderstanding on my part. I apologize.

   oh ok, it wasn't connected to the previous, it was my take on what
vendor could do, I guess I could have titled it appropriately so that
it's clear.

> -----
>
> Karsten made the very interesting point in one of his posts that the
> entire Oracle enterprise database software was ported to Linux with a
> single make command (although Paul indicates that the reference is not
> easily found, and I haven't bothered searching for it).

   I too remembered oracle but can't find it, however I have found
(Informix and linux port: we just typed make):

http://slashdot.org/articles/980801/0948200.shtml

...
> Part of this perception stems from earlier attempts with installing
> VMWare on a Debian box. The installer had to compile kernel modules,
> which involved me getting the headers (nope, that wasn't enough; get the
> full source), etc, and even then, the version of VMWare I last tinkered
> with wouldn't work with the newer kernel (2.6 maybe? it's been a while)
> that I had recently installed. So in that experience, VMWare wouldn't
> work on my particular "version" of Linux.
>
> 1) Could the vendor have made the installation more bullet-proof?
>
> 2) Without lots of resources to do so?

   well, WMWare is not a good example (to generalize from, it's fairly
unique) because it is very tricky to emulate a processor, it is much
closer to kernel than most other apps.

   There are few classes of problems that you can run into and there are
different solutions for each:

   - specific kernel features: most apps should not care about kernel
but some do - e.g. real time (or almost real time) apps (multimedia,
games), apps using unstable (I mean changing API, not crashing) kernel
interfaces (like alsa was until fairly recently etc.). As linux matures
this is getting better. This is hard for developer (vendor) to fix, what
they can do is clearly state what they need and try to work without the
feature (e.g. provide alsa and oss support, don't rely on specific
processor features being available etc.)

   - specific versions of libraries - if nothing else they can provide
statically linked binaries (that's what netscape did when motif wasn't
free) or provide the specific version of shared libs they need - loki
did this, I think it worked pretty well (as far as I can tell, I only
had one game and few demos) - they provided some openGL libs but were
able to work with yours as well - again, this is mostly problem for the
libs that are constantly changing - in desktop world the situation
should be much better once gnome and kde mature

   - write portable code - can't exaplain in few sentences but it is
possible to write fairly portable code if you know what you're doing,
it's not much harder but you have to know what's portable... added
benefit is that portable code is usually much cleaner (= has fewer bugs,
is easier to maintain, easier to port to even more platform etc.)

   one big adavantage is to use gnu development tools - they themselves
are ported to almost everything and therefore it is easier to port apps
build using gnu (because gnu itself is sort of platform)

   there are other development environments that are ported to number of
platforms that provide sort of platform - pretty much all interpreted
languages - perl, java, python, ruby, php etc. (usually performance
suffers but portability increases)

   there is a huge number of applications that already work across large
number of platforms, they do not have big development teams dedicated to
support of the specific platforms. Check e.g. freshmeat.net - almost all
the software is easy to compile not only for various version of linux
but for various proprietary unixes as well (where I worked before we had
solaris, fairly old version and still, I got everythig that I wanted
(compiled from downloaded source) - gvim, tomcat, fvwm, mc, number of
gnu utils (grep, find), perl, aterm etc.).

   it is slightly more complex with binary only software but the above
rules still apply. In unix world it is fairly easy to create a sandbox
for application with all the needed libs (kernel might be a problem but
then again there are only few types of apps that should care)

        erik

-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

• Previous message: Silvan: "Re: Is Linux Unix?"
• In reply to: Kent West: "Re: Is Linux Unix?"
• Next in thread: Karsten M. Self: "Re: Is Linux Unix?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]