Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

A Roundtable On BSD, Security, And Quality 60

Posted by Nik from the no-info-on-what-colour-the-table-was dept.
mccormi writes: "Dr. Dobb's Journal is covering a roundtable with four key members of the BSD movement at the recent USENIX Security Symposium 2000. The participants emphasized that reliability and security are achieved through simplicity. Other topics included the evolving distinction between Linux and BSD, why they don't use std::string, and why no one to likes IKE."
This discussion has been archived. No new comments can be posted.

A Roundtable on BSD, Security, and Quality More

A Roundtable on BSD, Security, and Quality

Comments Filter:

  • Automated installs (Score:4)

    by guacamole ( 24270 ) on Tuesday January 09, 2001 @10:37AM (#519799)
    Theo: "The direction I'm going is to have a facility for installing large numbers of machines easily. Right now you have to do attended installs. It would be nice to have a config file, TFTP or NFS mounts, preload a bunch of defaults, and splat out 30 installs at once. Most of the major OSes have this in some form or other. RedHat Linux KickStart is more complicated than it need be."

    Amen! This would be a very very nice feature!
    I use mostly RedHat and Solaris at work. We use Jumpstart for automating Solaris installs and configuration and kickstart for RedHat installs.
    Yes, it takes an effort to secure a Solaris or RedHat box, but if you script it and prepare an unattended install method then it doesn't matter to you whether to install 20, 30 or 200 boxes at once. This is the reason why we use RedHat instead of Debian (Debian installation is waay too interactive..)

    If OpenBSD will have this feature, good for them.

  • http://people.freebsd.org/~ken/zero_copy/ [freebsd.org]

    It's been done, and applied to NFS and others, for quite a while. The freebsd-announce mailing list would be a good place to check for more; substantial work on it has been done for several months.

    As for Linux, it's soomething that just came into 2.4 with one of the TUX patches in Q3 2000, as far as I know (source: http://boudicca.tux.org/hypermail/linux-kernel/200 0week36/0979.html)

    "He's as blind as he can be, just see what he wants to see, nowhere man can you see me at all?"

  • So this conference is being held by the infamous Dr. Dobbs. The Church of the SubGenius [subgenius.com] strikes again! Beware Bob Dobbs! [mit.edu]
  • Didn't the new BSDL get rid of the ad clause?
    Plus, a great deal of OS still contain in their docs stuff like " Contains code license for the UNiversity of California" etc etc
  • Comment removed based on user account deletion

  • Ahem:

    http://freshmeat.net/projects/fai/

    FAI stands for Fully Automatic Installation, and does what you describe for Debian systems.
    Sotto la panca, la capra crepa
  • I wasn't aware that IPsec was so far along. I was planning on writing some code for a 'secure' server and had been looking at FreeBSD and writing up a lot of my own daemons like FTP et al, but now I'll probably take a longer look at the stack on OpenBSD. Does anybody know how far they've got with implementing these features in userland so far? Any plans for other OSes to get compliant so we can start seeing proper IPsec infrastrucutres popping out of the mists?

    Well, AFAIK, the KAME stack has a relatively complete feature-set. In fact, I think the IPSec implementation in a lot of stacks (Linux included) is fairly complete. HOWEVER, from what I understand, interoperability is still an issue. If you have a homogenous network of OpenBSD boxes, you could probably set up an IPSec-based infrastructure. However, once you mix things up a bit, it probably won't work as seemlessly (although, since the BSDs share the KAME stack, they'll interwork... the real problem is when you get commercial stuff in the mix).

    And as for the userland implementation, again, AFAIK, there's a nice API for accessing all these features. You'd still have to modify the apps to make use of the APIs, obviously, but the interfaces are there.

    Also thought the SMP stuff was good, but I'm still under the impression that the OpenBSD crowd aren't that keen on it.

    Well, from previous conversations with Theo, I don't think SMP is even on the horizon for OpenBSD, due to the huge architectural overhaul required.

  • Re:Linux networking stack (Score:3)

    by mce ( 509 ) on Tuesday January 09, 2001 @11:44AM (#519806) Homepage Journal
    Yes, I remember that post from Alan (some 2 or 3 months ago, IIRC). I just did a Google search, but can't find it archived right now. However, here's an equivalent quote from the January 16, 1996 version (yes, this whole confusion is that old already) of the Linux NET-2/3-HOWTO [ruhr-uni-bochum.de]:

    2. Disclaimer.

    The Linux networking code is a brand new implementation of kernel
    based tcp/ip networking. It has been developed from scratch and is not
    a port of any existing kernel networking code.
    ...
    NOTE: While its name may appear similar to the Berkeley Software
    Distribution NET-2 release, the Linux network code actually has
    nothing at all to do with it. Please don't confuse them.

    --

  • Re:*CORRECT* LINKS Re:Might be outdated. (Score:3)

    by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday January 09, 2001 @12:54PM (#519807)

    Actually, he meant

    Slide 35 [innominate.org]

    Slide 36 [innominate.org]

    so you don't have to cut and paste the frigging URL from the article's text.

    I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.

    In any case, please note that Slide 42 [innominate.org] says:

    moving target: is only valid for today

    Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....

  • Re:Might be outdated. (Score:3)

    by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Tuesday January 09, 2001 @11:12AM (#519808)
    Well, looking at the date on that page (01 October 1998) it seems to me that this info just might be just a tad out of date. Have you actually looked at what's in the 2.4 kernel? Maybe things haven't changed, but it sure wouldn't harm to have a look before fudding.

    The item in Linux on that page says

    Current releases of the supported versions of Linux (Red Hat and Slackware) do not use BPF or DLPI. Instead, libpcap sniffs packets by reading packets one by one into user space. The packets source address is compared against its interface name. This implies that all interfaces send all data to all promiscuous listening processes and that the user code is responsible for determining if a packet is interesting.

    The packet sniffing mechanisms available in 2.0[.x] kernels, err, umm, suck. 2.2 introduced a better mechanism, and if you've configured in the right kernel option ("Socket Filter" or something such as that) it supports doing packet filtering at the kernel level (i.e., uninteresting packets aren't copied up to userland).

    Some Linuxes come with libpcap libraries that use the new mechanism; the current CVS version of libpcap at the tcpdump.org Web site [tcpdump.org], and the beta versions of libpcap 0.6, also use the new mechanism.

    2.4 has, I believe, a mechanism that shares a memory-mapped buffer between the kernel and userland; I don't know if any versions of libpcap use it yet.

    So Linux may now do a better job, at least if you configure the socket filter code into your kernel. It doesn't have any buffering mechanism to "batch up" multiple packets in one recvfrom() call, the way BPF and the bufmod STREAMS module on Solaris do; the 2.4 mechanism (which will, I think, eliminate a copy) might obviate the need for that.

    (People are looking at similar memory-mapped mechanisms for BSD. Had I bothered to implement the "memory-mapped stream head" stuff I was thinking about ages ago at Sun, it might've been available in Solaris as well; so it goes....)

    Note that on Solaris, the same "everything is copied to userland" problem exists that exists on some versions of Linux; I'm not sure why the NFR document speaks of the Linux mechanism as being lower-performance - it may be due to the lack of a buffering mechanism to batch up packets. (They speak of HP-UX, which also lacks such a buffering mechanism, as requiring more CPU for that reason.)

  • The more coverage the OpenBSD project gets, the better. Firstly, it will probably lead to wider support for, acceptance, and deployment of this wonderfully secure OS. Second, even if people don't deploy it, as more developers and users hear about OpenBSD's approach to security, there will be more implementation of these features in GNU/Linux (which seems to be destined for a higher level of popularity than BSD) and other UNIX OSes. Developers will hopefully become more conscious of their style and methods, and perhaps implement more crypto into their programs. Users will hopefully clamor for something more like a "secure-by-default" setup, which is hard to come by now, but will hopefully be standard soon enough (or at least, it will be the norm). More security implemented in computers and networks is always good.
  • I think he was referring to the previous poster's assertion that you could not do an automated install with Debian.

  • Re:stolen code? (Score:4)

    by logicTrAp ( 2864 ) on Tuesday January 09, 2001 @11:53AM (#519811) Homepage
    As others have said, GPLing BSD code is mostly ok (modulo the old advertising clause). But it's mostly a moot point since "Linux stole the BSD TCP stack" is just a piece of fiction that has managed to survive all these years. The only BSD networking is actually the BSD PPP compression, the rest is a grounds-up reimplementation (for better or for worse).

  • Show me. (Score:2)

    by rjh ( 40933 )
    its templatized nature leads to massive code bloat

    Please show me a C++ snippet, using the STL, which demonstrates this "massive code bloat". While some C++ compilers are certainly atrocious (Solaris C++ comes to mind), the majority of them make small, fast code.

    In the Red Hat 5.x days, C++ compiled to massive size due to an error in how Red Hat was set up--not due to an error in the compiler.

    Seriously. Please show me a code snippet, using GCC-2.95 or later, which expands into a large executable. I'd like to see it, and so would the GCC maintainers.
  • What is it about C++ and OOP that Slashdot has to continually disparage it?

    Because /. is written in Perl and PHP and who knows what else. Not C++. You'll note that /. doesn't post major articles attacking Perl, because that would make them look like hypocrites. Anyhow...

    Programmers interested in security should definitely take a closer look at std::string. I agree with you that the reason that it's only used in one out of 300 programs is because they're writing an OS, not an application nor a library nor an extensible framework, etc, etc. But std::string answers most of the same security concerns they brought up!

    I'll just give two reasons right here:

    • It grows as necessary. You can't have buffer overflows if the buffer keeps expanding. Eventually the size of the buffer will use up all your RAM and swap space, but if that happens you have bigger coding problems. It will not, however, allow the buffer to spill onto the code stack.
    • It's freakishly extensible. It would be absolutely trivial to specialize char_traits to use the strl* routines they were going on about. Put that in the system headers, and boom -- every instance of std::string in the system uses strl* to do its underlying work. Automatically.

    But of course, you won't hear about it on /. if they do any of that, because that would make C++ look useful.

  • OOP can be good for somethings, but I do not think a OS has to be readable to "normal" people. It would be nice, but coding decisions should on "readability" alone.
    I like my Operating System (whatever it be) to slick and fast and it should do whatever I want it to do.
    C++ (any any other OO Language) does add some overhead to a program and in the case of an application that can be affordable, but I would rather have a OS written in C or even better Assembler, because the OS should "just" be the OS nothing else.
  • Sonny boy, FreeBSD included support for these new fangled zero copy sockets a while back. They're also in their NFS implementation. Linux has had them since late August/early September thanks to TUX in some Linux-2.4.0-pre-test-ac145-mdk3 kernel. Don't confuse them with turbo packet support now. But of course, the reality is that some other OSes have had zero-copy for quite a long time (Solaris, IRIX, Windows2000!). Although the 9000 byte MTU jumbo gigabit frames are used rather than the nice 1500 MTU ones...

    Its also funny to see you use techno-babble you don't understand in regards to hardware checksumming. But I digress...

    The fact is that Linux and BSD each help make the other better, with friendly competition among the actual developers and a free flow of information between them. With rare exceptions, the attitude between workers in the two camps is one of mutual respect and even occasionally admiration. The BSD vs. Linux lamers simply don't understand

  • Last I checked, the BPF has to be compiled into the kernel, and is NOT there by default.

    In the 2.2[.x] Linux kernel, you have to configure the socket filter code on; it's not on by default (for reasons not obvious to me).

    (If you're referring to the BSD BPF code, that has to be compiled in on some BSDs, although it's there by default in recent FreeBSDs and possibly in other BSDs; however, if it's not there, you can't do packet capture at all - the in-kernel BPF engine is an integral part of the BPF packet capture mechanism, unlike Linux where you can have PF_PACKET sockets without the socket filter.)

  • I use mainly C++ because it is not a pure OOP language.

    The best thing about C++ is that it isn't an language. You can use it to write structural code, object oriented code, generic programming code, and even functional code. Or mix all of the above. It gives you the tools and that's it.
  • It would really help me a *lot* if they would document all these common problems somewhere.

    Most of them ARE documented. Just peruse the man pages. Take a look at strcpy() for instance. Throw away your "Learn C in 2 Hours" and get real docs.
  • How is C better for low level systems programming? In many ways, C++ is a better C. If you don't use the complex features, the language isn't comples.
  • The history is laid out here [ddj.com], but the point about which you're asking would be:
    The name "Dobb's" came from collapsing together (sort of) Allison's and Albrecht's first names. Unfortunately, the pasteup artist titling the original newsletter thinking Allison's name was Don, combined it with Bob to produce Dobb (DOn and BoB).
    (it makes more sense in context).
  • C++ (any any other OO Language) does add some overhead to a program and in the case of an application that can be affordable, but I would rather have a OS written in C or even better Assembler, because the OS should "just" be the OS nothing else.

    Not entirely true. You just have to be a bit careful about the features that you use. Using virtual functions, for example, might not be desireable. Creating operators like the complex multiplication as inline functions on the other hand, adds no overhead. It only makes code more readable. Just think about the simple example of comparing two structs. You could create a macro or inline functions that take two structs as arguments, or you could create an inline == operator for the structs.

  • You can quit showing your ignorance now!
  • No BSD derived stack was ever in the Linux mainstream

    Read that carefully "was ever in the Linux mainstream".

    That says that BSD code was in some way, shape or form in some verison of Linux at some stage.

    If you want to refute an argument make sure your comments support your side of the argument!

  • stolen code? (Score:2)

    by Anonymous Coward
    WL: Not a lot, though sometimes one steals ideas. Linux, for instance, stole part of the BSD networking stack. [Pauses.] All of it.

    So what happens when people GPL BSD code? Is there anyone to sue to get it taken out?

  • Re:Linux networking stack (Score:3)

    by keepper ( 24317 ) on Tuesday January 09, 2001 @10:39AM (#519825) Homepage
    Links my friend.... Links... Last i've heard, we still mopped the floor with linux on networking...

    Have you ever tried to do any bandwith shapping with linux, or routing? anything network intensive? then you would now why most router OS's have based their stacks on the BSD code.

    But, since you didn't provide links, I WILL BUDDY.
    case 1) NFR's home page. quote
    The performance of NFR on Linux will be poor on any hardware when compared to NFR on BSD-based systems on the same hardware. Linux does not use the BPF. The libpcap library uses another method to extract packets from the kernel on Linux. The code for this method does not appear to be written with performance in mind. Programs such as NFR, which use libpcap to read packets from the interface in promiscuous mode, will experience significant packet loss on any network that sees traffic of several megabits per second or more.


    Linux does not properly handle interfaces in promiscuous mode. It fails to it fails to distinguish packets addressed to it from packets addressed to other machines. This means that you can subvert the Linux system in various ways: Other systems on the network can detect Linux based sniffers by looking for responses to requests sent to the wrong MAC address. The Apostols Web page (http://www.apostols.org/projectz) (in Spanish) describes the exploit. The source code for the exploit program contains comments and error messages in English. On an NFR that is multihomed, someone could use the flaws in Linux to route traffic from the promiscuous interface to other interfaces.


    More you ask?

    http://neuromancer.rmci.net/linux-vs-freebsd.html [rmci.net]

    Please stop talking from the wrong end....
  • STL is certainly a handy set of classes but its templatized nature leads to massive code bloat. If bloat is a consideration don't use STL even if you write the rest of your code in C++.
  • I wasn't aware that IPsec was so far along. I was planning on writing some code for a 'secure' server and had been looking at FreeBSD and writing up a lot of my own daemons like FTP et al, but now I'll probably take a longer look at the stack on OpenBSD. Does anybody know how far they've got with implementing these features in userland so far? Any plans for other OSes to get compliant so we can start seeing proper IPsec infrastrucutres popping out of the mists?

    Also thought the SMP stuff was good, but I'm still under the impression that the OpenBSD crowd aren't that keen on it. I can understand why, but I think that they've pretty much got the security sussed now, so perhaps it's time they started looking further afield - the remote install stuff looks good and is not only good for rolling out over a LAN but makes OEM installs for machines to sell easier as well.

    I think this was typical of the BSD crowd though (myself included) by discussing all the bad stuff with Linux without actually mentioning any of the good stuff. Although, like I said, I'm a BSD bigot, so I'm not quite sure what the good stuff in Linux is. :-) I bet that last comment gets me marked down as flamebait or troll.
  • The original poster made it look like BSD developers weren't using std::string because it was insecure, while, accoring to the article, the reason they don't use C++ is because they "are not C++ programmers".

    I'm not saying that if you are an 60 year engineer who used FORTRAN all his life you should start learning C++. There's too much legacy: UNIX is written in C, numerical libraries in FORTRAN. But if everything was starting today from ground zero and you persued FORTRAN & C, I'd call a shrink for ya.

    Wroot

  • Noh, what's odd is that we all laughed and wondered how it could have been stolen and screwed up so badly in the process. :)
  • Ok, how about newer benchmarks?
    http://innominate.org/%7Etgr/slides/performance/im g36.htm
    http://innominate.org/%7Etgr/slides/performance/ im g37.htm
  • BSDTroll's are even more amusing than those WinTroll's of old
  • Of talking at great lengths about the (mainly aesthetic) shortcomings of C++ and then discussing whether or not close() can fail and how you check for it! I don't particularly like C++ (it really does suffer from syntax bloat), but exceptions really are nice...
  • Yes, this has been hashed over and over again on the kernel list. For the record, there has never been a BSD derived stack in the official linux kernel tree. Someone ported it in the timeframe of early 90s, but because of the license (advertising clause) it couldn't be included in the kernel. I tried to search for a reference to this effort, but couldn't find one right now (Alan Cox mentioned this on linux-kernel once).

    Just about the only BSD code that has been included and still lives in the kernel tree, is the PPP compression code. It could only be compiled as a module, but now as the license has been changed, this has changed.

  • I like FreeBSD (Score:3)

    by Bender Unit 22 ( 216955 ) on Tuesday January 09, 2001 @11:28AM (#519835) Journal
    I just added a 45GB drive to my FreeBSD box, it's an old 75mhz Pentium on a Intel motherboard that can't handle drives over 8gb.
    So the BIOS reported some wierd numbers and when I made the partition in FreeBSD, it just said "The BIOS reports some f****d up numbers, do you want to use mine instead(Y/N)"(ok, not word by word). I made my slices on the drive, got it up and running, added it into /etc/fstab and now I have the drive installed and working even though the Intels site says that you can't add a drive at that size on that board. heh.
    And yes, it worked after I booted the machine.
    Well maybe it would not work on a OS that depends on what the BIOS reports.

    --------
  • The advertising clause is totally different from the copyright reproduction clause. One requires that all advertising materials must give credit, and the other says that in source redistribution, the copyright/license MUST remain intact, and in binary redistribution, it must be included with the supplied materials.

    The advertising clause was the only thing that was removed. Go read a copy of the license for more understanding, if you'd like.

  • Well, looking at the date on that page (01 October 1998) it seems to me that this info just might be just a tad out of date. Have you actually looked at what's in the 2.4 kernel? Maybe things haven't changed, but it sure wouldn't harm to have a look before fudding.

    --

  • This is the BSD License in its current form, notice the two conditions. A lot of people think that BSD Licensed software is more-or-less public domain, this is simply not true. There is really only one condition, that being to inform people that things were taken from a BSD licensed product. That doesn't seem like too much to ask for.

    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions
    are met:
    1. Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.
    2. Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in the
    documentation and/or other materials provided with the distribution.

    THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
    ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
    IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
    ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
    FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
    DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
    OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
    HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
    LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
    OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
    SUCH DAMAGE.

  • AFAIK a team of researcher working on FreeBSD still have the record for TCP performance, using FreeBSD/Alpha on a Myrinet [myri.com] network.

    See..

    The performance reached was 1.147 billion bps on a single TCP connection... Way over what Gigabit Ethernet or ATM are even physically able to do. Those boards are really fast...

    Anyone know about more recent results ?

  • The conference took place last August see http://www.usenix.org/events/sec2000/ [usenix.org]. This is either an old article or a new web posting of an old paper article.
  • Its not only BSD developers, its developers _period_. If you were to count the number of c++ files in the entire ports system, you'd come to the conclusion that c++ is a fringe language.

    For open source projects, at least, C is king. The C++ language could disappear tomorrow and I wouldnt be any wiser for it because there isnt a single program running on my installation of Linux or FreeBSD that uses it.

    Of course, you kde and qt users will have slightly different mileage.

    --

  • If the file was modified at all, it must remain a module unless all the authors agree to the change.
  • How bizarre. I'm using FreeBSD with Qt/KDE. No problems. Perfectly reliable. Surely Qt/KDE counts as noncomplex C++ programs. I also do my own C++ development on FreeBSD. No problems. By the way, BSD uses ELF, not aout.

    Brzzzt. Next contestant.
  • Maybe I'm not a smart as most C/C++ programmers. I can't remember the arguments for all the library functions. So I always use man. It's my primary documentation. And every time I use man strcpy() it always tells me to beware.
  • This I can't understand.
    I've read the paper about these neat tools.
    They help security, with minimal loss of efficiency.

    So why are they still not present in Linux?

    I think that the dangerous function should be "deprecated": the Java way, it still works but upon compilation there is a warning which advise using the new function..
  • Comment removed based on user account deletion
  • I think they're actually not compatible if it's the old-style Berkeley license, because the advertising clause clashes with the GPL's requirement of no restrictions on distribution other than the GPL itself. Perhaps that's wrong. At any rate, the original author can always dual-license it, and without the advertising clause (e.g. the MIT-style license) they're perfectly compatible. (Hi Ceren!)
  • From the people involved, it looks like things are rather slanted toward OpenBSD...


    Good.

    'Secure by default' should be the norm, not the exception.

  • The BSDL allows for this...
    Hence why TCP/IP became a standard... there was a freely available stack for eveyone to use.

  • What is it about C++ and OOP that Slashdot has to continually disparage it? Just today they have a complete article on the "hype" of OO, and now this. Their mention of std::string in its context makes it sound like BSD thinks std::string is a bad thing, possibly even insecure.

    Read the friggin article! They don't use std::string in 299 of 300 programs because those programs are written in C! Why not C++? Because it's an operating system. C is better for low level systems programming, not because C++ sucks.

    Out of the hundreds of points made in this article, dozens of which can be considered at least somewhat controversial, why did Slashdot choose to mention "why they don't use std::string"?
  • sorry, by standard, i really meant "widely used", or "industry" standard...

  • ...that they have to discuss that the fact the things that are more simple are easier to secure. That's one of the first rules in any form of security, and especially in computer security. As for the widening rift between Linux and BSD, that came about because of the different startup schemes (SystemV for (most) Linux systems and, well, BSD for BSD). Oh yeah, and the different logos (The penguin is cooler...but chicks the daemon is hot...)

    CAP THAT KARMA!
    Moderators: -1, nested, oldest first!
  • > WL: Not a lot, though sometimes one steals ideas.
    > Linux, for instance, stole part of the BSD
    > networking stack. [Pauses.] All of it.

    Doesn't it strike you as odd that the BSD people have been touting the superiority of their networking stack for years, and now that it has become clear that Linux stack cleans up everything out there (see the specweb99 results), they change their opinion and suddenly it is 'stolen from BSD'?

  • I can see where the author is coming from because some proffessors swear by OOP. Stuff like, "it's not right unless it's OOP and/or OOD". At the same time, I think he is over stating the procedural languages.
    In some ways procedural languages like C could be confusing. You'd have all these functions working on data, and unless the person did a good job of documenting it, it can be hard to follow.
    Add to that the fact that in C, and other procedural language, if you wanted a function to work on some variable you had two real choices. You could make the variable global--which some consider a big no no, or you can pass it in the arguments. You can really increase the number of augments fast that way.
    I use mainly C++ because it is not a pure OOP language. This allows you to use a function where appropriate, and a class where it would work better. For example, let's say you have complex numbers you want to manipulate. In languages like C, you need to create a function(s) for all the mathematical operations you want to perform. Then the code reads something like this:
    ...
    complex res,x1,x2;
    ...
    multiplycomplex(x1,x2,res);
    ...
    In C++, you can incorporate all the functions into one class, and you can overload operators to make the code more readable. The above example could look like this:
    ...
    complex x1,x2;
    ...
    res = x1 * x2;
    ...
    To me, this is more readable and it looks more like the what you want the operation to do.
    In the end, no mater what style of programming you use, it comes down to how you design it. While I like using OOP, I don't like religous use of OOP just for the sake of OOP.

  • Re:stolen code? (Score:3)

    by bugg ( 65930 ) on Tuesday January 09, 2001 @11:02AM (#519855) Homepage
    But you still must observe the BSD license, reproducing the copyright and disclaimer.

    A poster explained it well here: http://daily.daemonnews.org/view_story.php3?story_ id=1485 [daemonnews.org]

  • Oh, yeah - duh; the kernel as well...

    CAP THAT KARMA!
    Moderators: -1, nested, oldest first!

  • Re:stolen code? (Score:3)

    by Ceren ( 102734 ) on Tuesday January 09, 2001 @11:06AM (#519857)
    It's not stolen. GPL-ing BSD code is, well, just fine, since sometimes the only way to make use of the code includes slapping a GPL on that copy of it... whatever's clever. We don't care. Good code getting used usefully is the end goal... not spreading a licensing scheme to topple the evil companies that pay programmers.

    Besides, there's a previous copy of that code out there with the BSD-style license on it, so it's not as if suddenly the stack is magically GPL-restricted. Everyone else is still perfectly free to use it for whatever they want.

    The closest thing we have to "stolen" is "taking for use without giving fair credit to the programmer."
    And that's not nice.
    Don't do it.

  • Heh..it is kinda funny. I know that there has been a patch or two on the linux-kernel mailing list doing zerocopy TCP, which the tcp checksumming being done on the ethernet controller(if it supports that of course). But from what I've read they have been able to max out a gigabit ethernet link with a p3@500mhz.

    I don't see any of the BSDs doing that these days..

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close