Slashdot Mirror

Also, the fact that its more difficult to make your system unbootable with FreeBSD (since by default when you install a new kernel it saves your old one) and if your new kernel doesn't work, you can get back to the old one more easily [ no worries about munging up the system so bad you need a recovery disk to re-do LILO ].

I was able to get a working kernel from FreeBSD the 1st try (because of the Online Handbook being decent...)

I have only rebuilt a linux kernel once (when I needed more than the default 4 software raid drives in RH 5.2).

I also think editing 1 file verses the 5 miles of check boxes for a Linux kernel is easier. You can also more easily change 1 thing then rebuild your kernel and keep going..

Well, on the same note, business that use FreeBSD are not necessarily all FreeBSD companies.. a list of 967 commercial firms that use FreeBSD. Some which are ZDNet/Aus, Yahoo!, and Siemens -- who also require mission-critical second-to-second reliable running of their business. One may argue that these are just web-servers; however, with the multitude of transactions that just Yahoo! handles, c'mon -- it's a real mission-critical OS.

I don't see the compelling advantage of SCO that you mention; however, if you really do have a point, please drive it home. I may just use it for my new Linux startup. ;-)

Well Mr Coward I shall bite.

I do not know what you think BSD but I think Server and damn good server.

Now you tell me. FreeBSD seems to have rather good driver support.... Does that look like an acceptable amount of drivers to you? I think the Driver support in FreeBSD has picked up a LOT lately. Anyhow other BSD's can hacn n port. I rather enjoyed reading that big list of NIC's that are supported.

Hmmn anyhow.

ftp://ft p.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES /4.0-install.iso

ftp://ft p.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES /4.0-install.iso

ftp://ft p.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES /4.0-install.iso

This is not some kind of 'grand enlightment' here people.

Fred on the developers page
Apple joining BSD

So as you can see, Apple has no problem 'getting' the concept of OpenSource.

Apple STILL sees themselves as a hardware company and not a software company. (they look at where the money comes from) And if the latest rumblings out of the Apple rumor mill are to be believed:
1) 2+ years ago Jobs went to Moto and said 'it will be great in 2 years when we aren't using you as a supplier' (fact)
2) Apple backed down...they never DID carry through with the Rhapsody on Intel project. (fact)
3) Rumor site claimes "t Steve Jobs himself has met with Motorola executives and hit them with both barrels recently" (rumor)
4) "Apple in talks with Wintel vendors regarding OS X for Intel?! " (rumor) Is that the 'both barrels'?

It is possible Apple might just see themselves as a software company that HAPPENS to sell hardware, and make alot of money there. Parts of Apple grok what they do, and the world they live in. The question to be answered yet is: Does Steve Jobs and his management understand and be able to execute?

This is not some kind of 'grand enlightment' here people.

Fred on the developers page
Apple joining BSD

So as you can see, Apple has no problem 'getting' the concept of OpenSource.

Apple STILL sees themselves as a hardware company and not a software company. (they look at where the money comes from) And if the latest rumblings out of the Apple rumor mill are to be believed:
1) 2+ years ago Jobs went to Moto and said 'it will be great in 2 years when we aren't using you as a supplier' (fact)
2) Apple backed down...they never DID carry through with the Rhapsody on Intel project. (fact)
3) Rumor site claimes "t Steve Jobs himself has met with Motorola executives and hit them with both barrels recently" (rumor)
4) "Apple in talks with Wintel vendors regarding OS X for Intel?! " (rumor) Is that the 'both barrels'?

It is possible Apple might just see themselves as a software company that HAPPENS to sell hardware, and make alot of money there. Parts of Apple grok what they do, and the world they live in. The question to be answered yet is: Does Steve Jobs and his management understand and be able to execute?

The FTP install capability of FreeBSD is great when you have a NIC but no CDROM drive. Especially if you're behind a firewall through which you can FTP but not NFS. I'd really like to see an FTP install for Linux as was discussed in the interview.

Just do a pkg_add XFree86-4.0.tgz and it's yours :) (hopefully)

Some people really, really like FreeBSD installation, some don't. Some do stupid things (like using the "Custom" or "Expert" install options without being experienced users) and end up hating it because it delivered the bullet to the place where you aimed the gun at: Mr. Foot.

Pros: the context-sensitive help is mostly ok; partitioning has an Auto option that makes reasonably-sized partition sizes; Standard installation will step you through all installation steps in the correct order (you will still get all the options available through a Custom install, btw); there are reasonable "distribution sets" that auto-select what should be installed depending on what's your intended use.

Cons: the interface has it's quirks, a result of the lousy UI library with which it was written half a decade ago; there is no set of "packages" to be auto-installed, which means you don't get many of the GNU goodies Linux users come to expect; it's post-install management is very poor; it won't configure packages; it does have a couple of bugs that cause crashes under certain rare situations; editing and compiling a new kernel are still required for some goodies, though things will mostly work.

Anyway, post-installation configuration help can be found on the handbook or the FreeBSD Diary. They are very useful resources, so do search them when you have problems or want to know how to do something.

Also, read the message that appears when you first log. It provides some useful references for the beginner. Finally, BSD man pages are good and useful. man and apropos are your friends.

It's just a matter of time. Meanwhile, you damn well better hope that your OS is secure.

If you're using Linux, you should check out Bastille Linux. If you're a BSD fan, I recommend you look at OpenBSD, although hopefully FreeBSD will catch up soon thanks to the FreeBSD Audit Project.
--
Brad Knowles

jail(2) is basically chroot(2) plus some other stuff (it actually calls chroot(2) internally). One of its more interesting features is that the structure passed to jail(2) contains an IP address. All IP traffic send to or from the program running in the jail is forced to use the specified IP address. This would obviously be very cool in a virtual hosting environment. For more information, see the jail(2) man page.

Why do you think that no-one else would have started a compiler project if RMS hadn't?

Come to think of it, why do you think that no-one else woudl have started a compiler project even if RMS had? You can get lcc from here or bcc from here.

Granted, I belive that gcc is a better compiler than bcc or lcc, but that's mainly because it is the most popular, and much work has been put into improving it by various parties. If gcc had not existed, and say bcc had been the standard compiler most people chose, then I'm sure that it's code generation & the number of targets would be as good as gcc's.

RPM is the most-used, and often, most-hated of the options, with Debian's dpkg/dselect and BSD Ports vying for the "most-loved" status.

The Ports use of what amount to "just plain makefiles" gives it the merit of being the most "traditionally-UNIX-like" packaging scheme.

Is there likely to be any "convergence" of the sort where libraries are added/modified so as to maximize the ability to use something like Ports?

I left Slackware in about '95 in favor of what I saw then as improved manageability of Red Hat's RPMs. I have since migrated to Debian, which provides better answers than RPM. It would be interesting to see the tide turn back due to Ports providing more deeply improved system manageability...

Read the full thing here.

I spoted an article at NewsAlert. Most Linux News sites, including LinuxPlanet, also has articles on the subject.

In case you didn't know, "nik" is an employee of Walnut Creek CD. He lives in the UK and recieves payments from a company in California. He is paid to post articles favorable to Walnut Creek CD and FreeBSD. If you want to write to "nik" his true email address is nik@freebsd.org.

Look at the walnut creek web site, dull, boring, stale. Look at the FreeBSD site, the home page hasn't been touched in well over a year. Look at the BSDi site and you would think they were out of business. You can't even find a comprehensive feature list for BSD/OS. I think it is telling that none of the sites listed above have an announcement of the merger!

So is FreeBSD repositioning itself to focus on the server segment of the market, leaving the workstation segment to Linux?

This merger announcement has me shaken.

The FreeBSD trademark has long been held by Walnut Creek CDROM, with some rather arbitrary restrictions on its use to describe derivative works that improve things such as the install process, or the overall "new user" experience.

I notice that Jordan Hubbard's FreeBSD History at FreeBSD History is a bit revisionist.

It casually mentions Bill Jolitz, but fails to mention John Sokol, who posted the original 386BSD code to the net, Jesus Monroy, who had a lot to do with the move from 386BSD 0.0 to 386BSD 0.1, or Terry Lambert, who wrote the original FAQ, patch kit, and patch kit production software, and then handed it off (as far as I can tell from the archives, the phrase "the patch kits last 3 coordinators: Nate Williams, Rod Grimes and myself" means "everyone ever involved in administering or creating the patch kit, except Terry").

It also fails to mention that Bill Jolitz had originally lent official support a "386BSD 0.5" interim release, based on the patch kit work, or that "the patchkit swelled unconfortably every day" is a paraphrase of Lynne Jolitz's complaints, which resulted in Bill Jolitz's "rude" withdrawl of support.

This seems antithetical to the BSD credo of "credit when due", and bodes ill for a future where it appears the source tree will have to be closed down for a while, while proprietary bits are sorted out of BSD/OS for integration.

I am unsure of what will occur as a result of this merger, and the idea of the merger itself makes me rather anxious about the historically centralized control of the project by a few people who initially checked in a large amount of code, but later became a barrier to progress, and the centralized control of the "BSD" related trademarks.

People who argue over such issues have long suggested that it would be possible for a commercial entity to "hijack" a BSD project; I have always publically dismissed this, but it seems that perhaps I was wrong. If so, I have a lot of crow to eat, which would be made ever more bitter for it being the result of failed idealism on my part.

I hope that statements are issued soon, clarifying what this merger is going to mean, the process by which it is going to be accomplished, the status of the use of BSD/OS binary-only drivers in a future FreeBSD, the permissable public use of the FreeBSD trademark going forward (preferrably, a trust will be established), and so on.

I feel like Tim O'Reilly, decrying the Amazon patents. 8-(

They're also going to be pushing partnerships & co-marketing a lot harder, as well as a branding and pre-installation program so that you can make sure that the machine you buy is 100% compatible with FreeBSD, or you can even get FreeBSD pre-installed on the machine.

There's a lot more that they're going to be doing. I'm just waiting for the updated plans to be posted to the web pages of Jordan K. Hubbard, CTO of Walnut Creek and soon to be CTO of the merged BSD, Inc.
--
Brad Knowles

What I suspect you really want is MacOS X on x86, and that is something that only Apple can port, if they choose to do so.
--
Brad Knowles

Heh, yes well, we can't all have the (most excellent) Ports System. :)
I've built (pre 1.0) xmms from unmodified source and used it on FreeBSD without any problems.
I plan on letting SF know that they can send people to the various BSD Ports Collections (Available via FreeBSD's CVSWeb) so they can incorporate the various OS specific patches into their source.
(Such changes would exclude items that are specific to the Ports system, like overriding PATHs and make variables, etc. These items would remain in the Ports patches.)
I'll be having articles in the FreeBSDZine about FreeBSD's Ports system in the near future.

Sorry for forgetting this link:
http://bento.FreeBSD.org is the moniker for the actual port-building cluster. Satoshi's documented some very good ideas there, including trying each port under its own clean chroot to make sure dependencies are correct.

It seems you've already gotten the idea of putting multiple distros in chroots on the machine, so it could be trivially extended to have a tarball containing that environment that could be unpacked and chrooted to for testing :) That's how the building for 3.X-STABLE is done, on top of a 4.0-CURRENT base.

It might be really nice to have a ports-type tree to do this, with more simplistic Makefiles which have targets for configuring, compiling, installation, and cleaning. Full SourgeForge "tree" building could be done that way =)

--

First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.

A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.

There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.

Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...

--

Reminds me of PicoBSD which is bassed off of FreeBSD.

Reminds me of PicoBSD which is bassed off of FreeBSD.

Have a look at the man page for the FreeBSD mount command and say that (search for async while there). For those occasions when you don't mind flying by the seat of your pants, you can of course have async writes. It isn't a new option either. And there's always softupdates too.

I suppose it wouldn't be so easy to win arguments if people actually checked their assumptions...

And yes, a plain old pee cee can easily serve those 1100 hits/second and saturate a 100baseT card. My old 200MHz Pentium Pro does it quite easily, with CPU cycles to spare. Of course, it runs thttpd and FreeBSD 3, not Apache and Linux. According to my measurements, running Linux would slow it down by a factor of two, and Apache would slow it down by a factor of five. Running both, with a factor of ten less performance, my old machine would indeed not be able to saturate its network card. No doubt this is where people got the idea that they needed multiple machines to serve mid-sized web sites - when they run inefficient software, they are right!

znu wrote:

I haven't found a single web page that's actually fully compliment, with the exception of the pages on the iCab site.

http://www.freebsd.org/ passes with flying colours. Of course, I did have a hand or two in that. . . :-)

If I get some copious free time in the near future I'm going to whack my slashdot.org hat on and take a look at the Slash code, to see if I can assist on that front.

N
nik@{freebsd,slashdot}.org

So while I would like to go to OpenBSD I can't (AFAIK). What is FreeBSD like in that respect? Educate me!!!

Before anyone out there hurls a "RFM" at you, try going to FreeBSD's site. &nbsp It's a real cool website with some really informative FAQs. &nbsp I was almost ready to install it myself but decided to opt for something different. &nbsp But since it is the most used of the "open source" BSDs out there, you'll have plenty of support for it. &nbsp Yahoo, Microsoft's Hotmail (hee hee), Apache, etc., use it.

And by the way, I have a Red Hat 6.1 server at work running SMP just fine thank you.

;-)

The reason Linux's SMP code is better than FreeBSDs is that FreeBSD has this thing called the Giant Kernel Lock.

When running SMP, any process that needs to access the kernel employs the GKL, which prevents every other process from accessing any portion of the kernel.

Linux has no such problem. SMP in Linux is likely going to be better for a while - there are a lot of very nasty problems that need to be solved before FreeBSD can remove GKL.

If you really want to know more about this, search the archives for either GKL or Giant Kernel Lock in either the FreeBSD-Current or FreeBSD-SMP mailing lists.

Mik

NetBSD users work together if they use computer types of different kinds. VM additions done from architecture ONE also benefit architecture TWO and THREE - same deal with networking, security, pkgsrc, toolchain, userland, X11, kernel, ports and homepage right?

FreeBSD is missing support on Intel for a number of hardware devices available from NetBSD now you know? Even if "NetBSD supports many more platforms than FreeBSD, but compared to the Intel platform it's a drop of water in the river" a good number of soundcards, cardbus, pcmcia and scsi cards are available in NetBSD but not FreeBSD. Your point?

FreeBSD seems to have met many of the author's requirements with their ports system. Might something like this work for Linux too?

Why not use something like the FreeBSD Ports package management toolkit? It maintaines all the dependencies. It also provides simple install and uninstall mechanisms. In fact, I have never had a package installation go sour with this. In fact, the FreeBSD package manager was one of two reasons I dropped Linux completely. It is just that nice.

Unfortunately, that isn't all that suitable for "naive lusers" who will react to this with a big Huh?!?

Rather than GNU Stow, I'd think the direction of BSD Ports would be suitable; that provides the merit of automating the process of setting up configuration info for lots of packages that hasn't yet been done with Stow. You may want to believe that

Dependencies could be added to Stow by someone without a lot of trouble.

Note that Ports, like Stow, uses nothing that anybody gets tangled into thinking is somehow "proprietary." (Not that RPM or DPKG actually use anything proprietary; it's mostly Slackware bigots, with emphasis on bigot, not on Slackware, that claim, dishonestly, that RPM/DPKG are somehow proprietary formats...)

But that misses the point.

Your proposal may be suitable for you and I, albeit marginally so, as I'd much rather that the administration of package installation for the 99% of packages where "default is fine" be dealt with by someone else; it is NOT, by any stretch of the imagination, suitable for making Linux deployable in other than highly UNIX literate environments.

yeah I wont type it :) fsck jon katz%@# FSCK THEM ALL! I hate the tick! Alfred sucks! News announcement: Jon katz retiring? Good!

mmm k, can we say rant time. . .

just wanted to add something to this completely entertaining thread. if i was a female daemon, I would thoroughly investigate getting with that sexy creature... how could ya resist those eyes, that uncanny smile, and that fine footware.

on a sidenote i'm gonna also say what half this issue at hand is in regards to is labels. 90% of slashdotters limit themselves with categories. why does it matter what "group" you fit in -- let it be geek, dork, slut, bitch, male, female . . . i mean, do you really want to be constricted like that? i have always had issues with group titles found in the online subculture. i have no clue as to how to or desire to find a label for who i am. Where do i fit in, eh? I'ma "snowboarding raving linux-using slightly-too-entertained-by-electronic-gadgets solaris admin slut".

here's the doozie...in WHAT way whatsoever will the increase of female "hackers" have for physically-unattractive male computer user? ooh neat another way for your lame asses to get denied -- via icq, aim, email.

race / gender / sperm-count / breast size . . . .these things are all quite irrelevent online.

do you feel better that you been given the illusion that the person on the other end of the bits is of the opposite sex? do you feel like you are finally connecting with some1 who is as socially retarded as you are? whatever. go outside, enjoy some fresh air. be yourself and stop having online relationships with 60 yr old men from idaho.

(in no way was this directed at anyone or did it manage to keep its structural integrity throughout. -- oh woops look i broke some "important stuff" rules i think)

(this one being my favorite)

Dig these sassy chicks: http://www.freebsd.org/~jkh/lw2000/

The actual file is at ftp:/ /ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeB SD-SA-00%3A01.make.asc.

Outside of Linux circles, "IP masquerading" is called NAT (network address translation). This is supported in FreeBSD in the form of natd, and more specific information on setting it up can be found in numerous places.

One place to get more informations, other than mailing list searching, is a great site called The FreeBSD Diary, where there's actually an entire section of the topics devoted to NAT :)

--

Outside of Linux circles, "IP masquerading" is called NAT (network address translation). This is supported in FreeBSD in the form of natd, and more specific information on setting it up can be found in numerous places.

One place to get more informations, other than mailing list searching, is a great site called The FreeBSD Diary, where there's actually an entire section of the topics devoted to NAT :)

--

Hi Jon,
FreeBSD does indeed support NAT. Please see the appropriate FAQ entry.
You can also get the same functionality on FreeBSD using Darren Reed's ipfilter program.

For those of you that do not know what benefits are in FreeBSD 4.0, here are a list of new / improved features:
Some New Features include:

The VM system's anonymous storage subsystem (the swap pager) has been completely
revamped. It should be a little faster, with less glitches.
An emulator for SVR4 binaries has been added. [i386]
Driver support has been added for PCI fast ethernet cards based on the ADMtek Inc.
AL985 Centaur chipset.
Driver support has been added for SysKonnect SK-984x PCI gigabit ethernet adapters.
Driver support has been added for Adaptec Duralink PCI ethernet adapters based on the
Adaptec AIC-6915 fast ethernet controller.
Driver support has been added for PCI fast ethernet adapters based on the Sundance
Techno-logies ST201 controller, including the D-Link DFE-550TX.
Driver support has been added for PCI fast ethernet adapters based on the Silicon
Integrated Systems SiS 900 and SiS 7016 ethernet controllers.
Driver support has been added for PCI fast ethernet adapters based on the Davicom
DM9100 and DM9102 ethernet controllers, including the Jaton Corporation XpressNet.
The top-level category security has been added, and IPFW now uses syslog(3) to log all
messages to /var/log/security.
A new jail(2) system call and admin command (jail(8)) have been added for additional
flexibility in creating secure process execution environments.
The base C/C++ compiler has been upgraded from GCC 2.7.2 to EGCS 1.1.2. This gives
users full ISO C++ support.

System Requirements: Standard ISA, EISA, VL, or PCI bus based PC (386sx to Pentium), 8MB
RAM, 100MB disk space for a binary-only system & 340MB for a full development system.

For more information, click here


Ben Brewer
brewer@nullified.org

MISplice is right -- while KDE et al. may be nice WMs, getting them up can be a huge pain in the ass, as I've discovered to my chagrin this past weekend, when I installed FreeBSD. XF86 has a known bug with ATI Rage graphics cards, such as is present on-board on my current mobo. My hsync is completely out of whack, and I can't even start X with something vanilla like SVGA or even VGA16 servers (640x480: mode not defined. no valid modes found. exiting.) Now, the webpage for FreeBDSM says XF86 3.3.3 and up support the ATI stuff, but I'm using 3.3.5 and still no dice. I've gotten a new video card, am going to bypass the on-board video through the BIOS, and reinstall:
FreeBSD
The patch to let FreeBSD recognize my Ethernet card
The patch to enable DHCP so the box can talk to my router
And then see if I can get X up.

This is freaking light-years beyond what my mom can do. I wouldn't do it if I didn't have a business need to have a Unix system at my house. The effort/reward ratio from the user's perspective sucks, frankly, and I think the article is spot-on, point for point. Major improvements in usability and interface need to happen before any Unix can even begin to think of breaking out of the server ghetto.

gomi

Solaris 8 supposedly has a lot of GNU tools (including the ones mentioned above). They're finally getting a clue it looks like....

Yes, so they're finally going to ship Perl with Solaris 8. Big fscking deal. And how regularly do you think they'll update all these utilities they are suddenly including? You'll be stuck on whatever ancient version of perl they choose to throw in. And of course, the one utility that you want to be in there won't be. Oh, and if they do decide to update them, the update will only be available to contract customers. In short, whilst this is nice for some customers, for the majority it's not what they need. They need something like FreeBSD's ports or RPMs (although Solaris already has it's own packaging scheme, so the latter is less useful).

After a long period of administering sun boxes, I have come to the conclusion that I don't trust sun to get it right. I have a hundreds-of-lines-long script just to fix up their boxes after the install...

Their crass behaviour is vindicated by their obsession with the unhealthy SCSL and now this. I won't be sorry when they do a U-turn on Linux and many other matters later this year.

FreeBSD could have done it a decade ago

Well, more like 7 years ago; the first FreeBSD came out in late 1993.

but for some reason they just didn't have that Linux mojo

The AT&T lawsuit might have contributed to that, at least in part.

You know, there's always the possibility of using Luigi Rizzo's excellent dummynet. Yes, it's for FreeBSD, which would mean changing the Linux firewall box to a FreeBSD firewall box.

Here's some information from the dummynet home page. I hope this helps!

dummynet is a flexible tool for bandwidth management and for testing networking protocols. It is implemented in FreeBSD but is easily portable to other protocol stacks. There is also a one-floppy version of FreeBSD which includes dummynet and a lot of other goodies, see below. dummynet works by intercepting packets in their way through the protocol stack, and passing them through one or more pipes which simulate the effects of bandwidth limitations, propagation delays, bounded-size queues, packet losses, etc.

Each pipe can be configured separately, and packets are forwarded to the appropriate pipe using the ipfw packet filter. Thus you can apply different limitations/delays to different traffic according to the ipfw rules (e.g. selecting on protocols, addresses and ports ranges, interfaces, etc.).

--

You know, there's always the possibility of using Luigi Rizzo's excellent dummynet. Yes, it's for FreeBSD, which would mean changing the Linux firewall box to a FreeBSD firewall box.

Here's some information from the dummynet home page. I hope this helps!

dummynet is a flexible tool for bandwidth management and for testing networking protocols. It is implemented in FreeBSD but is easily portable to other protocol stacks. There is also a one-floppy version of FreeBSD which includes dummynet and a lot of other goodies, see below. dummynet works by intercepting packets in their way through the protocol stack, and passing them through one or more pipes which simulate the effects of bandwidth limitations, propagation delays, bounded-size queues, packet losses, etc.

Each pipe can be configured separately, and packets are forwarded to the appropriate pipe using the ipfw packet filter. Thus you can apply different limitations/delays to different traffic according to the ipfw rules (e.g. selecting on protocols, addresses and ports ranges, interfaces, etc.).

--