B
Bart C
Kaz said:
So I was right to question the size of code needed to run an OS. (And I
thought drivers and things were outside the kernel.) That's reassuring to
know for some reason.
So I was right to question the size of code needed to run an OS. (And I
thought drivers and things were outside the kernel.) That's reassuring to
know for some reason.
J
joe4702
Linux source is like most any large body of software developed by many
people - some of it is beautiful, clean, modular and maintainable, and
much of it is garbage spaghetti code that looks like a Programming 101
first homework assignment.
S
Syren Baran
Estimate based on what?Billy said:
When you pay someone to do
Clearly you have never seen commercial software development. Often
enough time frames get set by people with absolutely NO knowledge of coding.
The coding skill does not magicly increase or decrease depending on
wether you get paid or not.
When i do freelance work i just get the some job done. Anything else
would be a waste of time and thus money for the contractor.
When working on my own open source projects i have no deadlines, try new
tricks and can add features that just wouldnt be feasible to implement
in a paid project. You know, often enough open source developers
consider their projects to be more like their babies.
So does Red Hat, Novell, Canonical etc...
Others get paid cause their company has a viable interrest in Linux,
such as IBM, Intel, AMD etc...
To my knowledge all big open source projects also have paid developers.
Its not like all open source/free software developers are a bunch of
holy preaching hippies.
S
Stephen Sprunk
Billy Bong said:
The Linux kernel is an ugly mess in places. It's a good example of
real-world code with lots of contributors, but I wouldn't hold it up as a
model of how to do things right. As with most things in life, it's only
good enough to get the job done.
Who said they were bugs? The term "kludge" is usually applied something
that works but inelegantly; the comment is mainly requesting someone else to
find a more elegant solution -- if there is one. Sometimes, there just
isn't.
"FIXME" is more likely to be a true bug, but not necessarily. It might be
that the code is known to break under circumstances that, as far as anyone
knows, never occur. If it actually caused problems, someone would track the
problem down and fix it.
That does not prove the nonexistence of bugs or even kludges -- it just
means that Microsoft's marketing department has removed things from the
comments that make them look bad. You think there aren't any bugs in MFC?
Do you think it's better to admit the problems, in hopes someone will fix
them, or pretend they don't exist?
I'll also note, as others have, that comparing an OS kernel to a GUI library
is inappropriate. I'd bet the Vista kernel has _at least_ the same rate and
types of comments, but you can't see that because it's closed source. If
you want to compare something to MFC, try Qt or GNOME.
Well, it's better than not putting the comments on that same code. Better,
of course, would be improving the code so they no longer apply, but that
ignores several realities in any human endeavor.
If you think people, even "professionals", always do everything perfectly,
you're in for a rude awakening one day. I'd rather have people that
recognize and admit when something's not perfect than ones who can't/won't.
Why not?
Absolutely nothing useful that couldn't also be said about every other large
software project, both open and closed source, that I've seen.
(TeX, I believe, is claimed to have zero bugs. I haven't read the source,
though.)
I'm quite sure Linus is aware of those comments and has written many of them
himself. He's human just like the rest of us.
Then you misunderstand the "evidence" you've collected.
S
C
CBFalconer
santosh said:
No. When source code is hidden, you don't have the opportunity to
pay or not to pay for improvements. You have to accept the
product, and can only swear at the mistakes.
To be accurate, you have to compare systems released under the same
open-source licenses.
C
Chris Hills
[QUOTE="CBFalconer said:
No. When source code is hidden, you don't have the opportunity to
pay or not to pay for improvements. You have to accept the
product, and can only swear at the mistakes.
To be accurate, you have to compare systems released under the same
open-source licenses.[/QUOTE]
CRAP. I can supply a LOT of professional course code that is not FOSS ,
GPL etc. Many commercial systems come with source code.... (that
includes Linux which is in effect a commercial system now)
I
Ian Collins
Chris said:
CRAP. I can supply a LOT of professional course code that is not FOSS ,
GPL etc. Many commercial systems come with source code.... (that
includes Linux which is in effect a commercial system now)[/QUOTE]
Good point. Other commercial and non-commercial open source operating
systems also use different licenses.
S
santosh
CBFalconer said:
Er, most closed source software has mechanisms through which you can
complain about problems. If everthing else fails, you can always
actively stop buying, or using, the product in question.
Yes. Many respondents have already pointed that out to the OP.
My point is that people who have a natural aptitude for what they are
doing are likely to produce a better job than others. Money, or fame,
or whatever is no substitute for interest, IMO.
Anyway it's beyond doubt now that "Billy Bong" /is/ a troll, so this
discussion (or any other discussion with him) is fruitless.
K
Kelsey Bjarnason
[snips]
In any large-scale development project, there will typically be boatloads
of things which need fixing or are kludges. This is the way of the
world. Nor is this necessarily a terrible thing.
One piece of code I wrote many moons back involved about six lines of
code, which, when examined, should have had no actual effect whatsoever.
The fact they did was due to an immensely obscure bug in the firmware of
a modem the code was controlling. While the mechanism I came up with did
work, I was quite convinced there was a better way - if we had more
information on the modem. Hence, it got a KLUDGE tag - but it also made
it to the release version. Why not? After all, it worked, it was
effective, it was just ugly.
Some of those kludges may stick around a hell of a long time, too, for
the simple reason that while they may be ugly, they work, and other
things are more important.
The same might be true with a FIXME as well. Consider, oh, a driver. To
get best performance, you might want to set the device into a particular
operational mode - but not all devices might like that. Any which are
identified as "can't do that" might get blacklisted, set to run in a less
than optimal mode.
This is probably acceptable insofar as the system _works_. That said, it
would be better to figure out what other systemic changes need to be made
to get the device running at peak, but this may involve significant
changes to several other important pieces of code, something not to be
done casually.
Such a case would definitely warrant a FIXME, IMO, as it means you're not
operating as you should be - it's not simply ugly, it is actually
defective - but until you figure out a workaround and patch all the
affected areas, it at least works.
So what should one do in such a case? Say no, sorry, we won't support
that device at all? Not good. How about holding off release until the
device is fully supported? Possibly an option, but if the hardware
vendor isn't helpful, it could mean a potential delay of years or more
before release.
The best answer seems to be to bite the bullet, release it as it is -
optimal on most devices, suboptimal on others - but note, in the code,
that this really needs to be fixed.
Ain't nothing wrong with that. FIXME and KLUDGE and the rest are only
worrisome if they involve something where there's a really fundamental
failure or there is a comparatively trivial fix - but this is not,
generally, the case in code such as the Linux kernel.
In any large-scale development project, there will typically be boatloads
of things which need fixing or are kludges. This is the way of the
world. Nor is this necessarily a terrible thing.
One piece of code I wrote many moons back involved about six lines of
code, which, when examined, should have had no actual effect whatsoever.
The fact they did was due to an immensely obscure bug in the firmware of
a modem the code was controlling. While the mechanism I came up with did
work, I was quite convinced there was a better way - if we had more
information on the modem. Hence, it got a KLUDGE tag - but it also made
it to the release version. Why not? After all, it worked, it was
effective, it was just ugly.
Some of those kludges may stick around a hell of a long time, too, for
the simple reason that while they may be ugly, they work, and other
things are more important.
The same might be true with a FIXME as well. Consider, oh, a driver. To
get best performance, you might want to set the device into a particular
operational mode - but not all devices might like that. Any which are
identified as "can't do that" might get blacklisted, set to run in a less
than optimal mode.
This is probably acceptable insofar as the system _works_. That said, it
would be better to figure out what other systemic changes need to be made
to get the device running at peak, but this may involve significant
changes to several other important pieces of code, something not to be
done casually.
Such a case would definitely warrant a FIXME, IMO, as it means you're not
operating as you should be - it's not simply ugly, it is actually
defective - but until you figure out a workaround and patch all the
affected areas, it at least works.
So what should one do in such a case? Say no, sorry, we won't support
that device at all? Not good. How about holding off release until the
device is fully supported? Possibly an option, but if the hardware
vendor isn't helpful, it could mean a potential delay of years or more
before release.
The best answer seems to be to bite the bullet, release it as it is -
optimal on most devices, suboptimal on others - but note, in the code,
that this really needs to be fixed.
Ain't nothing wrong with that. FIXME and KLUDGE and the rest are only
worrisome if they involve something where there's a really fundamental
failure or there is a comparatively trivial fix - but this is not,
generally, the case in code such as the Linux kernel.
C
Chris Hills
Ian Collins said:
In fact ALL the commercial software I supply RTOS, stacks, file systems
etc comes in source code form.
Fortunately they don't have the highly restrictive GPL license.
C
CBFalconer
Chris said:
So you are saying that, when you supply source, the receiver is
free to show that source to anyone who wishes to bid on making
improvements? And that there is then no restriction on altering
and compiling that source? Glad to hear it. However, that
characteristic is not general.
S
santosh
CBFalconer said:
There are many software which come with source, but which may not be
modified, or sometimes, redistributed with modifications. Such is the
case, for example with Microsoft's MFC, CRT etc. So the source can be
verified for it's quality, but any requests for modifications have to
be made to the copyright holders.
C
Chris Hills
CBFalconer said:
No. Why would they want to?
None.
However they don't have to make any of their source public. The
restrictive GPL license is a non starter for most of my customers.
What I have discovered over the last few months is a LOT of places get
FOSS, use it, improve it and don't release any source either the
application it is used in or the Open Source they started with.
Basically a lot of commercial companies are using FOSS as though it had
the sort of license the SW I supply has got not the GPL it came with..
C
Chris Hills
santosh said:
In theory. They can modify it and use it themselves.
S
Syren Baran
Well, you can get commercial support even though the product is freeChris said:
(both like in the speech and beer thing), yes.
Thats a big difference.
When a neighbour came around and asked for toilet paper i gave him the
product, but no support, i mean, expected him to proficient enough with
the product to wipe his own ...
I
Ian Collins
That comes close to Sun's CDDL terms (provided the original header is inCBFalconer said:
tact). There are significant bits of OpensSolaris code (with local
enhancements) in MacOS.
C
CBFalconer
Chris said:
So that the bidder knows what he is bidding on.
Good. If you don't want to retain rights to your software, that is
entirely your business.
So they are stealing. If you can identify such actions you will do
the world a favor by exposing it. Aren't there laws in the UK
against concealing thievery?
M
Michal Nazarewicz
Many people are paid to work on Linux and some love working on it
because then they get an operating system they like free of charge.
Commercial/noncommercial classification have nothing to do with open
source/closed source classification. A commercial program can be open
source and noncommercial program can be closed source.
because then they get an operating system they like free of charge.
Chris Hills said:
Commercial/noncommercial classification have nothing to do with open
source/closed source classification. A commercial program can be open
source and noncommercial program can be closed source.
R
Randy Howard
Yeah, a lot of businesses are making really stupid business decisions
with little or no real legal advice. That's a common problem with
small businesses. Most large corporations have a full time legal team,
and have gone to great lengths to make sure their employees do not
violate GPL, because they have deep enough pockets to be sued silly and
not have a jury be sympathetic with them because they are a a "mom &
pop shop".
There are extremely large companies that do play fast and loose with
GPL restrictions (yeah, that one you're thinking of right now).
K
Kelsey Bjarnason
[snips]
A license which allows you to do virtually anything you want, with
essentially the sole exception of keeping the relevant sources from the
users, is "highly restrictive"?
One can only conclude that, if you were *ever* faced with a license such
as, oh, the usual Microsoft EULAs, you'd fall over in a dead faint and
we'd all be attending your funeral.
Since you're still alive, I can only conclude you've never actually seen
a restrictive license.
A license which allows you to do virtually anything you want, with
essentially the sole exception of keeping the relevant sources from the
users, is "highly restrictive"?
One can only conclude that, if you were *ever* faced with a license such
as, oh, the usual Microsoft EULAs, you'd fall over in a dead faint and
we'd all be attending your funeral.
Since you're still alive, I can only conclude you've never actually seen
a restrictive license.