A Roundtable On BSD, Security, And Quality 60
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."
Automated installs (Score:4)
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.
Re:Linux networking stack (Score:2)
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?"
Dobbs strikes again! (Score:1)
Re:stolen code? (Score:1)
Plus, a great deal of OS still contain in their docs stuff like " Contains code license for the UNiversity of California" etc etc
Re: (Score:2)
Re:Automated installs (Score:2)
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
Re:Sums it up nicely (Score:2)
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)
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)
Actually, he meant
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:
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)
The item in Linux on that page says
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.)
This coverage is great (Score:1)
Re:Automated installs (Score:1)
Re:stolen code? (Score:4)
Show me. (Score:2)
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's more, std::string can be *more* secure (Score:2)
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:
But of course, you won't hear about it on /. if they do any of that, because that would make C++ look useful.
Re:I somewhat agree...in userspace (Score:1)
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.
Re:Linux networking stack (Score:2)
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
Re:Might be outdated. (Score:2)
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.)
Re:I somewhat agree... (Score:1)
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.
Re:As a beginning C programmer... (Score:1)
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.
Re:Slashdot disses C++ yet again (Score:1)
Re:Who is Doctor Dobbs? (Score:1)
Re:I somewhat agree...in userspace (Score:1)
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.
Re:the death that *BSD Died (Score:1)
Re:Werner Losh is lying (Score:1)
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)
So what happens when people GPL BSD code? Is there anyone to sue to get it taken out?
Re:Linux networking stack (Score:3)
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
More you ask?
http://neuromancer.rmci.net/linux-vs-freebsd.html [rmci.net]
Please stop talking from the wrong end....
Re:Slashdot disses C++ yet again (Score:2)
NFR link (Score:1)
Sums it up nicely (Score:2)
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.
std::string (Score:1)
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
Re:Linux networking stack (Score:2)
Re:Might be outdated. NEW LINKS (Score:1)
http://innominate.org/%7Etgr/slides/performance/i
http://innominate.org/%7Etgr/slides/performance
Re:Linux networking stack (Score:1)
The irony... (Score:1)
Re:Linux networking stack (Score:2)
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)
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
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.
--------
Re:stolen code? (Score:2)
The advertising clause was the only thing that was removed. Go read a copy of the license for more understanding, if you'd like.
Might be outdated. (Score:1)
--
Re:stolen code? (Score:1)
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.
TCP record performance still for FreeBSD AFAIK (Score:2)
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 ?
Not very recent (Score:1)
Re:std::string (Score:1)
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.
--
Re:Linux networking stack (Score:1)
Re:C++ is broken on *BSD (Score:2)
Brzzzt. Next contestant.
Re:As a beginning C programmer... (Score:2)
Why the strlcopy etc are not a part of glibc?? (Score:1)
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..
Re: (Score:1)
Re:stolen code? (Score:1)
Roundtable, huh? (Score:2)
Good.
'Secure by default' should be the norm, not the exception.
Re:stolen code? (Score:1)
Hence why TCP/IP became a standard... there was a freely available stack for eveyone to use.
Slashdot disses C++ yet again (Score:2)
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"?
Re:stolen code? (Score:1)
I'm suprised... (Score:2)
CAP THAT KARMA!
Moderators: -1, nested, oldest first!
Linux networking stack (Score:1)
> 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 somewhat agree... (Score:2)
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)
A poster explained it well here: http://daily.daemonnews.org/view_story.php3?story_ id=1485 [daemonnews.org]
Re:I'm suprised... (Score:2)
CAP THAT KARMA!
Moderators: -1, nested, oldest first!
Re:stolen code? (Score:3)
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.
Re:Linux networking stack (Score:1)
I don't see any of the BSDs doing that these days..