Board index » cppbuilder » Re: CBX - outstanding idea!!!

Re: CBX - outstanding idea!!!


2003-10-10 03:32:55 AM
cppbuilder94
Oscar Fuentes < XXXX@XXXXX.COM >wrote in news: XXXX@XXXXX.COM :
Quote
"mr_organic" < XXXX@XXXXX.COM >writes:

[snip]
>I'm not going to get into the why's and wherefores of choosing the
>GPL; I'll just say that it is a very valuable license, and a very
>good one in lots of situations. Linux has thrived over the years,
>and has avoided the forking problem that the BSD's had due to the
>more liberal BSD license.

The whole point of the GPL is about software distributors granting to
the *users* the right of doing whatever they want with the
software. That includes creating a fork. There is nothing on the GPL
that disallows forking the project.

[snip]

Yes, but the GPL is more "fork resistant" than the BSD license because
the BSD license allows someone to take their changes private/commercial.
Because of this, many importnat changes never got back to the community
at large. Also, the GPL tends to foster the "one true codebase" idea
(for lots of reasons too complicated to go into here).
Contrast this with BSD, which (at last count) had six different kernels
and distros: NetBSD, OpenBSD, FreeBSD, Mac OS X, DragonflyBSD, BSDi, and
probably some others I can't think of right now. Mac OS X is based on
MACH, but uses a modified FreeBSD userland and toolchain. There is a
simply amazing amount of wasted effort in each tree because each distro
does things in a slightly different (and incompatible) way. The "ports"
approaches are a good example: all three "free" BSD distros use different
ports mechanisms.
Linux has gone as far as it has as fast as it has because everyone is
working off the same page in the same book (although this is less true of
the distribution side of things, where things get much messier).
The GPL doesn't *forbid* forking, but it does *strongly discourage*
forking, in that you have to be pretty specific about why you are forking
the project and make it clear in the sources that you are working off of
a forked codebase. It "costs more" to fork a GPL'd project than a BSD
project, that's all.
mr_organic
 
 

Re:Re: CBX - outstanding idea!!!

"GBR {CrewGBR}" < XXXX@XXXXX.COM >wrote in message
Quote
So? And what's your point? What framework have you in mind that doesn't go
beyond c++ standard? Geez, the standard doesn't even know anything about
threads, much less about any of the dozens of 3-4 letters words that every
modern framework is peppered with.
That sure as heck doesn't make it right to break the std. if you don't need
to. Many vendors didn't need to, but used it instead to encourage people to
stick with their implementations. At one point, where anyone's guess was
good for how the standard would eventually be written and implemented in
some areas, this probably even made technical sense in some cases.
From a technical standpoint if not a financial one, back when BCB was
introduced the CL could have been developed from the ground up to support
the proposed std. at least - there were already decent GUI frameworks that
did much of what the VCL does with std. conformance. And I don't buy that
the talented Borland engineers would have had to necessarily sacrifice all
of the important bells and whistles of VCL to do this either. It probably
made sense financially at the time to use the VCL and add the keywords, but
that is also exactly why there are so many pissed off and worried BCB users
right now.
IMHO, CBX is great because it is built on the idea that standard conformance
is now pretty relavent to the C/C++ world, and it encourages language
standard and portable development. Our code run through more than one
compiler is almost always the better for it also. With BCB there isn't even
a chance to do that for a good part of most applications as originally
written.
 

Re:Re: CBX - outstanding idea!!!

"mr_organic" < XXXX@XXXXX.COM >writes:
Quote
>The whole point of the GPL is about software distributors granting to
>the *users* the right of doing whatever they want with the
>software. That includes creating a fork. There is nothing on the GPL
>that disallows forking the project.
>
>[snip]
>

Yes, but the GPL is more "fork resistant" than the BSD license
because
I'm not doing a BSD vs GPL comparision. I'm just saying that the GPL
gives you the right to create a fork.
[snip]
Quote
Contrast this with BSD, which (at last count) had six different kernels
and distros:
[snip]
There is a
simply amazing amount of wasted effort in each tree because each distro
does things in a slightly different (and incompatible) way.
[snip]
Your view is based on that a project has a "goal". When someone thinks
he would do things differently, the GPL gives him the right to go
ahead. This promotes creativity instead of adhesion to the
Project. Maybe the reason BSD has some many forks explains the almost
absence of bigotry on the BSD field. Lots of people on the Linux side
thinks the Project is about achieving something concrete
(i.e. punching down MS, for the most part). That raises religious
actitutes. [Please take no offesense, this is not addressed to you,
mr_organic]
Quote
The GPL doesn't *forbid* forking, but it does *strongly discourage*
forking, in that you have to be pretty specific about why you are forking
the project and make it clear in the sources that you are working off of
a forked codebase.
I don't see on which part of the GPL is stated, directly or
indirectly, what you say. For a GPL project, you simply get the
sources, modify them, publish and you have a fork. Nowhere is said
that you must (or should) justify that.
Quote
It "costs more" to fork a GPL'd project than a BSD project, that's
all.
I don't think so.
--
Oscar
 

{smallsort}

Re:Re: CBX - outstanding idea!!!

Oscar Fuentes < XXXX@XXXXX.COM >writes:
Quote
"mr_organic" < XXXX@XXXXX.COM >writes:

>>The whole point of the GPL is about software distributors granting to
>>the *users* the right of doing whatever they want with the
>>software. That includes creating a fork. There is nothing on the GPL
>>that disallows forking the project.
>>
>>[snip]
>>
>
>Yes, but the GPL is more "fork resistant" than the BSD license
>because

I'm not doing a BSD vs GPL comparision. I'm just saying that the GPL
gives you the right to create a fork.
I think survivial of the fittest applies after a fork. If you publish
your changes, and you implement something that really is a better idea
than mine, then eventually people will use your version, or I'll be
forced (by market forces that is) to adopt your version.
To maintain multiple competing versions is wasted effort. Not that it
doesn't happen all the time, but usually the less dominat version dies
out in popularity very quickly, and effort is either abandoned or the
better idea is adopted.
Without the GPL, if you fork the code and keep it a secret, even if
you have a superior version, you lose out on it taking over unless you
have very aggressive marketing. But people tend to not like secrets,
and there will remain support for the free and open version from which
you originally copied the source. Your innovations in that situation
do not become part of the "official" release. So fragmentation
occurs.
--
Chris (TeamB);
 

Re:Re: CBX - outstanding idea!!!

Dave,
Yesterday I compiled my BCB v6 sp4 project and got an internal compiler
error. The compiler crashed. Well, I messed around, exited BCB, came
back in, and instead of doing make I did a compile of a particular
module. It compiled okay, then the Make worked. I breathed a sigh of
relief. Those kinds of episodes scare me. I don't want to get into a
position where something I did in several hours of editing across many
files suddenly put me in a position where I can't build my project any more.
That, in a nutshell, is why I don't like the idea of continuing to
maintain old projects in BCB v6: what if something breaks?
If Borland supports the v6 bcc32 with BCB v6 and new linker versions as
well and all bug fixes to them are usuable under BCB v6 then at least
two major sources of concern would be lifted.
Dave wrote:
Quote

I realize there has been great investment in VCL tools, but they can still
be used going forward (with the "old" IDE) even if CBX doesn't support them,
and I'm sure there will remain a market for a while for the good ones. What
I see here for the developers making a living off of current BCB VCL tool
sales is a great ground-floor opportunity for another (potentially much
larger) market I guess.


 

Re:Re: CBX - outstanding idea!!!

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >writes:
Quote
>I'm not doing a BSD vs GPL comparision. I'm just saying that the GPL
>gives you the right to create a fork.

I think survivial of the fittest applies after a fork.
[snip]

To maintain multiple competing versions is wasted effort.
[snip]
Your innovations in that situation
do not become part of the "official" release. So fragmentation
occurs.
I see open source from a different POV: when I need something, either
I code it myself (original work), get it from somewhere else or modify
some similar thing. This is about getting the work done, not about
winning wars.
NetBSD is an example of that: they know what they want, namely, having
a good OS for their purposes. They do not intend to conquer the
world, just to obtain something useful and having fun at the same
time, if possible.
A Linux fork would have strong *political* implications, to the point
of dwarfing technical ones. When OpenBSD split from NetBSD, some
NetBSD people actually thought it was a good thing for the future of
NetBSD itself. The people who left had its own ideas. Instead of
changing their mind to adapt it to the mainstream or keep arguing with
the others forever, they forked the project. That's good, IMO.
--
Oscar
 

Re:Re: CBX - outstanding idea!!!

Oscar Fuentes < XXXX@XXXXX.COM >wrote in news: XXXX@XXXXX.COM :
Quote
Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >writes:

>>I'm not doing a BSD vs GPL comparision. I'm just saying that the GPL
>>gives you the right to create a fork.
>
>I think survivial of the fittest applies after a fork.
[snip]
>
>To maintain multiple competing versions is wasted effort.
[snip]
>Your innovations in that situation
>do not become part of the "official" release. So fragmentation
>occurs.

I see open source from a different POV: when I need something, either
I code it myself (original work), get it from somewhere else or modify
some similar thing. This is about getting the work done, not about
winning wars.

Spoken like a true application developer! ;-) Still, if you develop
libraries or frameworks rather than end-user applications, you rapidly
begin to see the wisdom of using the GPL.
Quote

NetBSD is an example of that: they know what they want, namely, having
a good OS for their purposes. They do not intend to conquer the
world, just to obtain something useful and having fun at the same
time, if possible.

And NetBSD *still* doesn't have a functional Posix threading
implementation. As far as I know, they are the last major *nix to have
this piece missing. (The SA threading is in the _CURRENT tree, but not
the production release). And both OpenBSD and FreeBSD do threading in
similar-but-different ways, meaning that any heavily-threaded application
(like a web server or database server) would have to be modified on all
three platforms to run well. A common threading approach might have been
*less efficient*, but would have been ready far sooner, and meant much
less work for all concerned.
Quote

A Linux fork would have strong *political* implications, to the point
of dwarfing technical ones. When OpenBSD split from NetBSD, some
NetBSD people actually thought it was a good thing for the future of
NetBSD itself. The people who left had its own ideas. Instead of
changing their mind to adapt it to the mainstream or keep arguing with
the others forever, they forked the project. That's good, IMO.

OpenBSD was (and remains) all about Theo's ego, nothing more. Rather
than simply creating a NetBSD patchset, Theo forked the whole project.
NetBSD lost at least a year and maybe two in the upheaval that followed,
and the kernels and userland have diverged enough now to make porting
software between the two a real pain.
It often occurs to me that the *BSD's inherited the legendary Unix
fractiousness that kept it from becoming the {*word*109} OS in the 1980's,
paving the way for Microsoft. Linux (so far) seems to have avoided that
kind of divisiveness, at least at the kernel/system level.
mr_organic
 

Re:Re: CBX - outstanding idea!!!

You seem to be quite familiar with the BSD family of OS's. Do you know if
programs developed for Linux will run under FreeBSD? (I assume a recompile
and relink.) FreeBSD is attractive to me because it is very stable and has
documentation.
. Ed
Quote
mr_organic wrote in message
news:3f86aedd$ XXXX@XXXXX.COM ...
 

Re:Re: CBX - outstanding idea!!!

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
You seem to be quite familiar with the BSD family of OS's. Do you know if
programs developed for Linux will run under FreeBSD? (I assume a
recompile
and relink.) FreeBSD is attractive to me because it is very stable and
has
documentation.

I don't know about FreeBSD, but OpenBSD claims to be able to run most
programs that run on Linux.
From their home page:
"OpenBSD supports binary emulation of most programs from SVR4 (Solaris),
FreeBSD, Linux, BSD/OS, SunOS and HP-UX."
The thing that worries me here is their use of the word "emulation". This
suggests to me something like a compatability layer which would likely carry
some performance hit. Whether I have misunderstood, or if not, whether such
a hit is significant, or not is another question.
I guess the only way to really know is to try it, but I'm not going to mess
with a multiple boot system, nor am I going to get a number of systems to
test it.
HTH
Ted
 

Re:Re: CBX - outstanding idea!!!

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in
Quote
You seem to be quite familiar with the BSD family of OS's. Do you
know if programs developed for Linux will run under FreeBSD? (I
assume a recompile and relink.) FreeBSD is attractive to me because
it is very stable and has documentation.

. Ed

>mr_organic wrote in message
>news:3f86aedd$ XXXX@XXXXX.COM ...

It depends. Most basic stuff works with the usual "configure/make/make
install" if you have a sane toolchain and the correct installed headers.
But GNOME especially has heartburn with the *BSD's because of things like
threading and the VFS layer. FreeBSD is probably the most i386-friendly
distro around, and lots of people work hard to make GNOME compile on that
box, but generally you're better off going through the ports system
rather than trying to do it yourself.
The situation is somewhat worse with NetBSD and OpenBSD. Neither has a
very good Posix threading implementation (although NetBSD will have a
version of Scheduler Activations in the next major release), and the
ports trees on both tend to lag due to the smaller user bases. Hardware
support also tends to lag for the same reason.
Many source trees do not build cleanly on the *BSD's because the
developers mostly work on Linux, and there are small but definite
differences in things like system headers, filesystem layout, and even C
library calls (Linux uses the GNU C library, or glibc, while the *BSD's
use a patched Berkeley C library). Most of the patches you see in the
BSD ports trees tend to be workarounds for GNU-isms and Linux-isms in the
source-code, or support for bad or broken Posix threading. Even shell
scripts can sometimes fail because Linux assumes the GNU version of bash
(Bourne Again Shell), while BSD uses the traditional /bin/sh Bourne shell
or the C shell. I've seen quite a few configure scripts barf because the
GNU bash shell wasn't being used.
The *BSD's tend to be a more "old school" UNIX approach than Linux, and
this is quite apart from the whole "BSD vs. GPL" thing. Lots of
developers of the BSD's tend to think that their code is cleaner and more
"correct" than the Linux stuff, but in my experience the code-quality is
about the same -- in fact, there's quite a lot of cross-pollination in
things like drivers and system utilites (OpenSSH came from OpenBSD, while
lots of BSD drivers are hacked versions of Linux drivers).
As far as "stability" goes, you have happened to hit the BSD camps at a
time when they are in quite a bit of flux. FreeBSD, long the bellwether
for stability, has had some issues with the 5.1-CURRENT tree. They still
recommend using 4.8-stabLE for production use. NetBSD is also promising
a new version "soon", but 1.6 is still your best bet -- but it lacks a
kernel-threads library, which places some limitations on the software you
run. I've had Linux boxes in production use that haven't been rebooted
in more than a year, but the same is true for FreeBSD 4.8 machines. I
don't have any NetBSD stuff in production, but I've heard good things
about it. Ultimately, "stability" is more ad administration issue than
it is a quality-of-code issue -- if you don't mess around with your
machines and be careful how you install and run stuff, any Unix box
should run just about forever.
HTH. HAND.
mr_organic
 

Re:Re: CBX - outstanding idea!!!

Thanks a bunch for the quick, detailed answer.
That cinches it. FreeBSD is not an option for me. I liked the idea because
I have far more experience with a couple of different Unix OS's (but were
not the same) and was a bit comfortable with that. FreeBSD does not free me
from the nightmare of continually changing stuff. Now to decide if
something very stable like Debian or more easily installed and configured
like Mandrake or RedHat would be best. Until then I'll stick with Knoppix
loading on the fly from CD.
. Ed
Quote
mr_organic wrote in message
news:3f86c531$ XXXX@XXXXX.COM ...
 

Re:Re: CBX - outstanding idea!!!

In view of your knowledge of BSD and Linux, let me ask you what you make of
OpenBSD's security claims. Are they as secure as they claim? Are they any
better WRT security than the various Linux distributions (and is there much
variation among the latter WRT security)?
If I wanted to set up an older machine to serve as a router and firewall,
which would serve the purpose better WRT security?
I have a colleague whose son has been programming security related
applications for years on Linux, and they claim they have yet to see a
successful break in, on their own LAN, despite seeing many attempts recorded
in their logs. But that is a sample size of one and is dependant on their
own code (I have no idea if they have made their stuff open source), and so
says little about Linux in general.
Cheers,
Ted
 

Re:Re: CBX - outstanding idea!!!

"Ted Byers" < XXXX@XXXXX.COM >wrote in
Quote
In view of your knowledge of BSD and Linux, let me ask you what you
make of OpenBSD's security claims. Are they as secure as they claim?
Are they any better WRT security than the various Linux distributions
(and is there much variation among the latter WRT security)?

Disclaimer: I think Theo is a jerk. Take all statements that follow with
that in mind.
OpenBSD probably *is* the most secure out-of-the-box Unix variant today.
The OpenBSD has done a really good job at doing code-reviews and in
setting good defaults. That said, you can make any other Unix just as
secure by being careful and using sane defaults. Security is not a
product or a technology; it is an approach, a state of mind. Security is
a constantly-moving target. It has a lot more to do with you as a user
and administrator than it does with the software you are using on your
box.
OpenBSD tends to have fewer security problems than any other OS for a
couple of reasons.
1) It's small, and deliberately so. It's packaged as the kernel +
userland. (You can load X if you want it, but many OpenBSD folks disdain
this since you automatically inherit X's security problems.)
2) The core team pays close attention to buffer-overflow exploits, which
accounts for the majority of Unix cracks. Still, a few do crop up --
OpenSSH had a pretty bad one a few months ago, and that's one of the most
heavily-audited packages on OpenBSD's code tree.
3) It ships with good default settings in terms of what ports are left
open, how PAM is configured, etc.
4) Few of the script-kiddies use it (most are Linux or Windows users).
This grants a certain amount of "security via obscurity".
Quote

If I wanted to set up an older machine to serve as a router and
firewall, which would serve the purpose better WRT security?

I have a colleague whose son has been programming security related
applications for years on Linux, and they claim they have yet to see a
successful break in, on their own LAN, despite seeing many attempts
recorded in their logs. But that is a sample size of one and is
dependant on their own code (I have no idea if they have made their
stuff open source), and so says little about Linux in general.

Cheers,

Ted

Any free Unix variant will probably work fine as a router/firewall.
OpenBSD is good, but so is FreeBSD and Linux. Pick one you like and feel
comfortable with, install it, make sure it's configured correctly, and
keep an eye on your log files. Learn how to use SNORT or some other
intrusion detection tool, and get in the habit of checking for crack
attempts at least a few times a week. (I was amazed at how many people
do portscans on my cable-modem firewall. I mean, it's dozens *every
day*.)
Like I said, "security" isn't a *property* that, once set, protects you
magically from all harm. This, in my view, is why I view OpenBSD's
mystique with some cynicism. It's an okay Unix distro that ships with
good default security settings.
Windows is insecurable even in principle for lots of reasons (mainly
COM/DCOM and the lousy RPC design thereof). If you lock down Windows
enough to be truly secure, then it is also pretty much unusable. I would
*never* use a Windows box as a router/firewall, even with a product like
ZoneAlarm. I'm not slamming Windows; it's my main development platform
(and my job 5 days a week!). But it is not, and never will be, a
securable operating system.
HAND
mr_organic
 

Re:Re: CBX - outstanding idea!!!

Thanks, that is useful.
Now, while I have often used different flavours of unix, I have never
administered one. Can you recommend a reference (ideally on-line) that
would be useful in terms of learning administration best practices, esp. WRT
security; something that has a good balance and neither asumes I am a moron,
like so much Windows documentation, nor assumes I am a unix expert, like
most of the unix documentation I have seen?
Thanks again,
Ted
 

Re:Re: CBX - outstanding idea!!!

"Ted Byers" < XXXX@XXXXX.COM >wrote in
Quote
Thanks, that is useful.

Now, while I have often used different flavours of unix, I have never
administered one. Can you recommend a reference (ideally on-line)
that would be useful in terms of learning administration best
practices, esp. WRT security; something that has a good balance and
neither asumes I am a moron, like so much Windows documentation, nor
assumes I am a unix expert, like most of the unix documentation I have
seen?

Thanks again,

Ted



The Linux Security HOWTO is pretty good
(www.tldp.org/HOWTO/Security-HOWTO/) but it does assume a certain
familiarity with Unix administration. This is kind of a necessity: good
security requires a good knowledge of the system, the daemons, and how
things operate. (Knowing how to read logfiles is a really really good
idea.) Tools like SNORT (www.snort.org) are useful, but again,
you need to do some reading to understand how things work.
Ultimately, security is hard. This is one of the worst things about the
whole "computers are just appliances" mindset that drove millions of
these machines into homes across the world -- they are *not* appliances.
They are at heart highly complex algorithm-processing machines, and
require a good degree of skill to operate in a secure and safe manner.
There is no "magic bullet", no magical "make this computer secure" GUI
tool.
I've harped on this at length (and this is probably the wrong forum, so
feel free to tell me to STFU), but I'll reiterate: security is not a
*product* or a *thing*. It is a *mindset*, an *approach* you take as the
user and administrator of your computing resources. It means learning
how to use things like packet filters, logfile parsers, intrusion-
detection systems, and the like; it means learning the ins and outs of
TCP/IP networking; and it means enforcing good habits both on yourself
and the users of your computing resources (use good passwords, change
them often, don't write them down on sticky-notes and stick them on the
monitor).
You have to ask yourself: "How secure do I need to be? How important is
my data? Am I at risk of being trojaned or rooted?" (Hint: if you're on
an always-on cable modem or DSL line, you are *very much* at risk.) You
can use products like ZoneAlarm or BlackIce Defender on Windows, which
are okay (but not a panacea); but Unix firewalls provide very robust
security for a little more investment in time and learning.
Did I answer your question, or just go off into a security rant? :-)
mr_organic