Linux openness *really* useful?

  • Thread starter Rob Hulsebos Philips CFT
  • Start date
R

Thread Starter

Rob Hulsebos Philips CFT

Linux-supporters often claim that the 'openness' of the system, i.e. the availability of all the source code, is a major plus in comparison to Windows. The reasoning goes that if there is a problem somewhere, you can "just" fix the code.

Now I wonder whether this is really true. Of course, from a theoretical view it is true, but now from a more practical side. Even though it is Unix, that does not mean that it is simple and it is not small either. I wonder whether most
Linux-users have the knowledge to fix the kernel, or the windowing system, or the network applications, or the shell(s), and even if they fix it within reasonable time, are they are aware of any potential side-effects?

Kernel-kacking might have been simple with the 10K-sourceline Unix V6 kernel of 1980, but the kernel and the applications have grown quite a lot since then.

Any opinions?

Rob Hulsebos

 
R

Ralphsnyder, Grayg

The biggest trouble is when you ask 'Does the person fixing it really know
what they are doing?' Who are YOU going to let fix YOUR copy of Linux that
YOU are putting into the pharmaceutical manufacturing plant? I am not
implying that uSquish (or anyone, for that matter) has anything near perfect
but an OS is a pretty complicated beast.

On top of this you have code maintenance and all the fun stuff that goes
along with it.

Oh yeah, one of the promises of a 'standardized' operating system is that
you can take a program with dataset and run it on this machine or that and
it still works and you get the same results. So now with all this openness
we have a thousand copies of Linux (or whatever) that are all slightly
different from each other because a thousand different automation vendors
saw a problem and 'fixed' their copy of Linux. Maybe multiple versions
within the same company.

Openness is a great thing. Hurrah ! But you get what you ask for. When it
comes to reliability of a manufacturing facility - off the shelf standard
parts is the order of the day - computers and operating systems are just
another part number that you can order and stock on your shelves. Write all
the Process Control programs (PLC, PC, GUI, DCS, etc..) that you want - that
is the field that we here reading this ARE THE AUTHORITIES. The authorities
on OSs are all of those guys and girls working for uSquish, and Red Hat, and
who ever the other OS vendors are.

I am not sure what the operating definition of openness is today. Surely it
will help increase competition and force improvements all around in the OS
market. We surely need it. Heck, we used to modify VSDs (PCB level) from
AB, ABB, etc. to fix problems we saw and help them fit the application
better.

In the end what I am saying is - be careful, do due diligence, and be safe.
 
K
Granted, the notion of wading in and actually fixing (buggy) OS code
is probably not very practical, however possible (if the sources are
available). To me, a more mundane but practical situation is where
you're trying to nail down some minor detail of a system, but things
aren't working out. Without access to the source code, you're relegated
to studying the provided documentation, asking for technical support from
the software's authors, hunting for "workarounds" to try to side-step the
problem, etc. The source code, though, *can* show you exactly what is
going on; whether you then fix the code or just work around it, you can
do so with absolute knowledge of how things are working. The sources are
the ultimate documentation, the guts of the machine. If you're comfortable
just being able to see the front panel, and it works for you, then maybe
you don't need open source systems. The advantage of open source is
not just for heroic hacking, it's being able to see the machine.

Ken

--
Ken Irving <[email protected]>
 
W
Hi,

Yes, Linux openness is *really* useful. But....

I don't agree that so many people are fixing their own code, or even bothering to look at the source code. My opinion is that this ability to fix the source code is not directly useful to even 1% of users. Its usefulness lies in the fact that the openness implies that it *can* be fixed, and that there are programmers around who *will* fix it if the need arises. These programmers know what they are doing, and can do in their sleep what it might take an uninitiated user/programmer/hacker a week or more to do.

But this is indirectly useful to the user, so it is still necessary for the user to have access to the source code, if they ever want it. It functions as more of a guarantee than a useful possession.

The open source movement would not be anywhere near as successful, or perhaps even exist at all, if (as someone suggests) there were thousands of different hacked versions extant for any release of a program or O/S.

Regards,

Willy Smith
 
M

Michael Griffin

An end user wouldn't buy a Linux system. Rather, they would buy a
system which happens to use Linux as the operating system. The advantages of
source code access would accrue to the developer of the system the end user
is buying. The end user would thereby hopefully get a better product. The
product might be a complete off-the-shelf machine, a custom software system
(written by a consultant), a soft logic system (which the user then
programs), or a computerised test developement system (e.g. Labview). The
developers of these sorts of products are in many cases quite capable of
fixing source code.

Source code access for software developers is actually very common,
even with proprietary software. Commercial software libraries often can be
purchased with a source code option. This is usually very expensive, but not
always. The source code is sometimes invaluable to a developer, because the
library documentation may be ambiguous, or even incorrect. I have in the
past had cause to consult library sources (for hobby programming), and there
simply is no substitute for it. Think of it as the difference between
reading a general description of how a machine is built versus actually
looking at the electrical schematics.

Operating system source hasn't been available for Windows until
recently. Microsoft has now made available a limited amount of Windows
source code to a handfull of companies which Microsoft has selected. Even
so, I imagine that this limited availability comes with strings attached. It
also doesn't address the needs of those companies which were not selected
for this special access.

One of the problems which developers of computerised test systems
(both OEMs and consultants) have expressed to us is the lack of detailed
information about Windows. While there are a multitude of books and other
information sources about business or entertainment systems, there is very
little which addresses their needs. This is a very big hole which I don't at
present see anyone filling.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
Rob Hulsebos:
> Linux-supporters often claim that the 'openness' of the system, i.e. the
> availability of all the source code, is a major plus in comparison to
> Windows. The reasoning goes that if there is a problem somewhere, you can
> "just" fix the code.

> Now I wonder whether this is really true.
...
> I wonder whether most Linux-users have the knowledge to fix the kernel,
> or the windowing system, or the network applications, or the shell(s),
> and even if they fix it within reasonable time, are they are aware of any
> potential side-effects?

No, they don't.

Like Willy Smith writes, though, the openness is important as a guarantee,
more than a practical matter.

If a hundred people dislike some feature of NT, there's not much they can
do about it. If a hundred people dislike some feature of Linux, they can
hire OS programmers to fix it. They can even pool resources, if they can
get themselves organized enough, or just do it individually (and pool
resources after the fact, as it were).

As ESR argues in one of his papers: it's important to have the right to
fork the code (create a new version independent of the original author),
even though such forks are generally frowned-upon.

It is a last resort, but the last resort must be there.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
J

John Waalkes

> The biggest trouble is when you ask 'Does the
> person fixing it really know what they are
> doing?' Who are YOU going to let fix YOUR copy
> of Linux that YOU are putting into the
> pharmaceutical manufacturing plant?

One of the kernel developers maybe? Just a guess...

And in other news, who's going to fix your Microsoft system? Apparently not Microsoft.

http://www.msnbc.com/news/598028.asp?cp1=1

If you want to know about reliability, go to www.netcraft.com and do your homework.

Or if it's good enough for the NCSA, who am I to complain?

http://www.netcraft.com/Survey/Reports/current/developers/ncsa.html
So no more FUD please.


> I am not implying that uSquish (or anyone, for
> that matter) has anything near perfect but an
> OS is a pretty complicated beast.

Nope, that's why the version numbers go up and not down :)

And that applies to just about everybody...


> On top of this you have code maintenance and
> all the fun stuff that goes along with it.

You mean like .dll hell?


> Oh yeah, one of the promises of a standardized'
> operating system is that you can take a program
> with dataset and run it on this machine or that
> and it still works and you get the same results.

Just an aside, but did you realize that Linux supports more hardware out of the box than NT does?


> So now with all this openness we have a
> thousand copies of Linux (or whatever) that are
> all slightly different from each other because
> a thousand different automation vendors
> saw a problem and 'fixed' their copy of Linux.
> Maybe multiple versions within the same company.

I guess that it's time for some clarification:

Linux is the kernel. That's the OS part, here's a better definition than what I can give you:

http://whatis.techtarget.com/definition/0,289893,sid9_gci212439,00.html
What it is:

The core portion of the OS that handles memory, interrupts, events, etc. Kind of like the combination of MSDOS.SYS, IO.SYS, & COMMAND.COM in the DOS world.

What it isn't:

A conglomeration of various applications combined together. That is what is called a distribution (commonly called a distro, i.e. Redhat).

So back to your 1000's of linuxes, what you are referring to here is the way that different "vendors" combine different applications together and (usually) pack them onto a CD.

Linux comes from www.kernel.org. Not Redhat, not SuSE, not Corel...

I won't dispute the "thousand copies of Linux" comment since there is just about any linux solution that you can dream up already packaged for you (and hence all the different distros...).

It's nowhere near a thousand, but whatever...


The upshot of this is that you don't need to worry about multiple versions of linux any more than you have to worry about your controls solution being bundled with Solitaire. Oh wait, bad example... :)

You wouldn't install a windows-based package that includes Quake with it would you? What makes you think that a linux-based package would be any different?


And while I'm at it, the "open" part of linux comes from the GPL license -- not linux. You can write a program for Windows that is GPL'ed and it will come with the source!

Wow, we used to call this freeware :)


> Openness is a great thing. Hurrah ! But you
> get what you ask for. When it comes to
> reliability of a manufacturing facility - off
> the shelf standard parts is the order of the

Let me ask you this, if you were writing a program in VB and you needed a control that wasn't included in the "Enterprise edition" and you found a freeware solution that came with the source, would you use it?

Of course you would.

Why is this so much different?


> day - computers and operating systems are just
> another part number that you can order and
> stock on your shelves. Write all the Process

Ya know, that's the way that we feel that our OS should be too.


> Control programs (PLC, PC, GUI, DCS, etc..)
> that you want - that is the field that we here
> reading this ARE THE AUTHORITIES. The
> authorities on OSs are all of those guys and
> girls working for uSquish, and Red Hat, and
> who ever the other OS vendors are.

You mean like how AB has the old ICOM boys write their code, and how GE does their own (and it shows).

These are the same people who can't write a decent manual.


> I am not sure what the operating definition of
> openness is today. Surely it will help
> increase competition and force improvements all
> around in the OS market. We surely need it.

It will. Even if it has to drag the automation world into it by its heels. :)

> Heck, we used to modify VSDs (PCB level) from
> AB, ABB, etc. to fix problems we saw and help
> them fit the application better.

Was that because AB(B) wouldn't fix the problem for you?

And how is this different from an Open Source developer fixing a problem? (and then submitting his/her fix for the world to see by way of the source code)


> In the end what I am saying is - be careful, do
> due diligence, and be safe.

Absolutely. Linux already scores higher in reliability than Microsoft does. So why use an inferior platform?

Or would you want your controls platform to do this?

http://www.info-sec.com/OSsec/OSsec_080498g_j.shtml

John

 
Grayg Ralphsnyder:
> So now with all this openness we have a thousand copies of Linux (or
> whatever) that are all slightly different from each other because a
> thousand different automation vendors saw a problem and 'fixed' their
> copy of Linux. Maybe multiple versions within the same company.

This seems unlikely - because of the way the GPL works, each of those fixes is available to all the other vendors, which means the other vendors will pick them up... (at least the good fixes)

> The authorities on OSs are all of those guys and girls working for
> uSquish, and Red Hat, and who ever the other OS vendors are.

In Linux, the ultimate authorities would be Linus Torvalds and Alan Cox.

> I am not sure what the operating definition of openness is today. Surely
> it will help increase competition and force improvements all around in
> the OS market. We surely need it.

Yup.

> Heck, we used to modify VSDs (PCB level) from AB, ABB, etc. to fix
> problems we saw and help them fit the application better.

Well, not much different from modifying the OS, then...

> In the end what I am saying is - be careful, do due diligence, and be
> safe.

Always.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
B

Bob Peterson

[email protected] writes:

> Yes, Linux openness is *really* useful. But....
>
> I don't agree that so many people are fixing their own code, or even
> bothering to look at the source code. My opinion is that this ability to
fix
> the source code is not directly useful to even 1% of users. Its usefulness
> lies in the fact that the openness implies that it *can* be fixed, and that
> there are programmers around who *will* fix it if the need arises. These
> programmers know what they are doing, and can do in their sleep what it
might
> take an uninitiated user/programmer/hacker a week or more to do.

However, our current discussion is about using Linux for automation. This requires an experienced automation engineer who is also an experienced Linux user and an experienced realtime C or C++ (or whatever) programmer. These
guys do not exist in any quantity at all. They just don't. If the guys on the LPLC project can get a usefull RLL system together that any automation engineer could use, I am reasonably sure that person could learn enough about Linux reasonably quickly (much as they have learned fairly quickly to deal with the various flavors of Windows) to be able to install and run such a
piece of software and not have to worry a whole lot about needing to fix whatever bugs might be in the LPLC code or Linux itself, or being some kind of Linux/C/C++ genius.

> But this is indirectly useful to the user, so it is still necessary for
the
> user to have access to the source code, if they ever want it. It functions
as
> more of a guarantee than a useful possession.

If I had a plant, I would NEVER allow any automation application software in my plant that I did not have the source code for, along with the capability to make whatever changes I needed to. PERIOD. No one with half a brain would ever rely on the OEM for support. Its just to expensive, not timely, and frequently not even available (OEMs tend to come and go), and a lot of
times its not all that good when you can get it. Sadly the code writing ability of many OEMs is all but nonexistent. With PLCs the source code is
always there. With commercial HMIs it is too. With a roll your own version that might save you a few hundred bux, its a different story.

I actually knew a place that wrote an HMI package of their own in some kind of basic in windows 3.11. They did this because the cost was "less" then buying a panelview or other commerically available HMI. However, as best I can tell, they probably never really saved any money because they only cared about the hardware costs and the cost of the engineer who actually wrote the code and maintained the things was in overhead. When the company went defunct, their customers no longer had any support whatsoever and were stuck
with these abortions. For an end user, what is a couple hours/days/weeks/months of no machine worth to you when some roll your own piece of software or its underlying hardware goes goofy and cannot be made to work and the guy that wrote it is no longer available?

> The open source movement would not be anywhere near as successful, or
> perhaps even exist at all, if (as someone suggests) there were thousands of
> different hacked versions extant for any release of a program or O/S.

I am not so sure that there are not a lot of variants out there. Keep in mind that the Linux people are a very small number of talented software people who thrive on this kind of thing. They think its a lot of fun.

I am not a linux guy, although I must admit I am real close to going and getting a distribution for an old puter I have and trying it out just for the heck of it. Anyone have an suggestions as to what distribution is the best for a rank amateur to start with? Something with some minimal level of available support.

Bob Peterson
 
D
Michael Griffin <[email protected]> writes:

> Source code access for software developers is actually very common,
> even with proprietary software. Commercial software libraries often can be
> purchased with a source code option. This is usually very expensive, but not
> always. The source code is sometimes invaluable to a developer, because the
> library documentation may be ambiguous, or even incorrect. I have in the
> past had cause to consult library sources (for hobby programming), and there
> simply is no substitute for it. Think of it as the difference between
> reading a general description of how a machine is built versus actually
> looking at the electrical schematics.

Even in the case of Microsoft software. I've done a fair amount of coding with MFC in the past. There were many times when it would have
been much, much harder to debug without access to the MFC source code that Microsoft provides. I've also seen embedded software projects suffer long delays because of bugs that surfaced in OS code for which they had no source. Note that the bugs may well have been in the embedded project's code, but understanding them was very difficult
without access to the source of the code the symptoms appeared in.

Dan Pierson
 
Bob Peterson:
> If the guys on the LPLC project can get a usefull RLL system together
> that any automation engineer could use,

Right now we're up to the level of mnemonics, we still need to write/find some graphical RLL editor...

The mnemonics are there, though - you know, LD X001, AND X002, OUT Y003. It's even one of the few pieces of the system that's actually documented. (Though it hasn't been beta-read - any volunteers?)

There's a PID module that just comes out of the box, point it at an input and an output and tune it.

> I am reasonably sure that person could learn enough about Linux
> reasonably quickly (much as they have learned fairly quickly to deal with
> the various flavors of Windows) to be able to install and run such a
> piece of software and not have to worry a whole lot about needing to fix
> whatever bugs might be in the LPLC code or Linux itself, or being some
> kind of Linux/C/C++ genius.

Yup, that's the plan.


> I am not a linux guy, although I must admit I am real close to going and
> getting a distribution for an old puter I have and trying it out just for
> the heck of it. Anyone have an suggestions as to what distribution is
> the best for a rank amateur to start with? Something with some minimal
> level of available support.

I'm using Debian, which (as far as I've heard) is a bit middle-of-the-road as far as new users are concerned - not as rough as Slackware, but not as
hand-holding as Red Hat. The package selector needs a rewrite, which is in progress (right now you press Enter to exit and other weird things).

Then again, if you're putting it on an old computer to learn about Linux, perhaps it's a good idea to avoid the graphical configuration helpers anyway - they just add another layer between you and what's really happening. Changing files in /etc is no harder than changing stuff in the registry, and because they're just text files you can put comments in there to remind you what you've done (and there's comments there to begin with to tell you what the package author's done).


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
As far as a good starting point is concerned. I found Red Hat very useful. You can really think of trying Red Hat for starters, they also provide
support.
Anand
 
C
Hi Bob

Try RedHat. There are many other fine distributions including Mandrake, Suse and Caldera. Corel made a good one but it's future is cloudy since they fell in with the MS folks again. Which distro is a religious matter and I like them all but I think RedHat offers the most traditional support. Once you get established, you will find the community is more useful than what you normally think of as support. I find it faster and more flexible to search deja for answers as there is always someone else who
has solved a particular problem or issue. Linux users really try to help each other. There is a real sense of community. I think it's better and much less hassle than "factory" support.

Regards

cww

PS I obviously find Linux openness extremely useful and I try to avoid changing the OS. This is because what I thought was a bug is simply a
misunderstanding on my part which is easily resolved by having the code for reference. The best way to use it is to take up your issue with the maintainer and if it is a bug or you have a good idea, it gets into the source tree and the issue is solved for everyone with no forking. Think community. Even more useful are the hundreds of applications which provide example source code for almost anything you would need to do and a huge productivity boost over starting from scratch. It's a very powerful way to produce solutions when you don't reinvent anything. It's
also the fastest way to learn how to do things bar none.
 
J
> Linux-supporters often claim that the 'openness' of the system, i.e. the availability of all the source code, is a major plus in comparison to Windows. The reasoning goes that if there is a problem somewhere, you can "just" fix the code.
>
> Now I wonder whether this is really true. Of course, from a theoretical view it is true, but now from a more practical side. Even though it is Unix, that does not mean that it is simple and it is not small either. I wonder whether most
> Linux-users have the knowledge to fix the kernel, or the windowing system, or the network applications, or the shell(s), and even if they fix it within reasonable time, are they are aware of any potential side-effects?

Good question, surfing across slashdot I came across a story about a gaping hole (their term, not mine) in SSH (Secure SHell). FYI, it only affects Unix boxen (i.e. linux, Solaris, BSD, etc...)

So what's my point?

It turns out that SSH is is a good example of the benifits/drawbacks of open source programming. This is because long before SSH was a for-pay program (i.e. closed source), it was actually an open source project. At some point, the author decided to "close" the project so that he could turn pro. He's the author, he can do this... He just can't "turn back the clock" on the previous versions.

So when this happened, some OpenBSD'ers (the *other* open source guys) grabbed the last open/free version and "forked" SSH into OpenSSH. (I won't get into "forked" versions, suffice it to say that at times it serves a purpose).

So at one time they were the same program. This would be the equivilent of doctors studying twins. Hmmm...

So on Slashdot we hear of this "gaping" hole, what about OpenSSH? No problems. Does that mean that Open Source is better? Not necessarily, this is just one example. But over the history of the project, OpenSSH has had less problems.

And to give you an idea as to how big "gaping" is, version 3.0.0 of SSH will authenticate any password of 2 characters in length or less :)

So it's just one example, but if you had the source, how long do you think it would take to patch the program? Probably less time than it took to read this... (mostly because I'm long-winded) :)

And I'd like to clarify the differences in licenses, the license for OpenSSH is the "BSD" license, the one for most -- but not all -- linux programs is the GPL license.

The difference being that with the BSD license, you have (nearly) unrestricted use of the software. Basically this means that you can write it, and I can steal it. Oddly enough, Microsoft supports *this* kind of open source license (you can verify this by searching for the "Copyright...Regents of the University of California..." in WinNT/95 -- Try ftp.exe for example)

Remember the networking nightmares of Win 3.1? (Winsocks) Open Source to the rescue...

Here's a page that explains the difference fairly well (from a BSD'ers point of view...)

http://www.openmagazine.net/guestcolumn/00/12/23/1642213.shtml
>
> Kernel-kacking might have been simple with the 10K-sourceline Unix V6 kernel of 1980, but the kernel and the applications have grown quite a lot since then.
>
> Any opinions?

Here's someone who puts it better than I ever could (from a linux point of view):

http://linuxtoday.com/stories/10912.html

And in regard to the number of lines of code:

"Microsoft couldn't deliver NT 5.0, with its estimated 25 to 30 million lines of code. (The Linux kernel, in contrast, makes do with less than one million lines of code.)"

Source:

http://www2.linuxjournal.com/articles/currents/001.html

And I've been dying to bring this up, but did anybody else see the hacked page over at Microsoft the other day?

It was the Microsoft server where you could get the patch for the IIS server ("Code Red" worm) exploit.

Apparently they neglected to apply the patch to their own server :p

And I saved the screenshot to prove it :)

"Welcome to http://www.worm.com!
Hacked by Chinese!"

(And I see that there is yet another Microsoft Outlook virus going around -- SirCam is its name. Get your virus update).

Sorry about the long-winded post :)

John Waalkes
Saturn Corp.
[email protected]
 
Top