FreeBSD 5.3-BETA2 available

Nirbo writes "One week after FreeBSD 5.3-BETA1, FreeBSD 5.3-BETA2, is now available to those wishing to update to the most current FreeBSD on the 5.x branch. It's available from the Main FTP servers, and probably a few more places by this point. BETA-3 is due out September 3rd, but for those who don't want to go a single day without updating, you can find snapshots (and the ISO images) here."

Comments

*BSD will live forever!

[Nirbo]

Just because the *BSD's explosive growth is minscule compared to Linux's explosive growth, that hardly means it's dying...

For every 10 Linux users, every 1 has enough sense to fall through the cracks in the Linux Kernel and land in BSD-country (See, we can troll too :D)

Rather, the boom of Linux in recent history has sparked a lot of BSD numebrs to jump too :D... now if only we could get off such dependancies as Linux Compatibility for out Flash plugins, we'd be set as both a Linux-ally, and a Linux competitor...

With 2.5 Million active sites according to Netcraft (Who also run BSD... coincidence? Not really.), *BSD is hardly dead... just too busy disputing the death rumours to really make a show of it's vast and productive life :D

Fast...

[JamesTRexx]

I'm quite impressed how quickly the beta's follow eachother. Even if changes between 5.2 and 5.3 aren't major. (haven't read the changelog though)
It makes me wonder why it takes so much longer for Microsoft with all its resources to go from one beta to the next, even with all the software that has to be tested.

Re:Fast...

[x3ro]

It makes me wonder why it takes so much longer for Microsoft with all its resources to go from one beta to the next, even with all the software that has to be tested.

I assume you're referring to beta versions of Windows? If so, remember that Windows is a kernel, window manager, desktop environment, set of APIs, blah blah blah, all in one. Imagine trying to change versions of not just FreeBSD itself, but also X.org, KDE/Gnome, and probably quite a few apps that aren't part of the OS but come bundled with it (eg Konqueror) .. that would be a better comparison.

Of course the other reason would be bugs being shallower with more eyes etc, closed vs. OSS. But I'm inclined to think that the more significant contrast is OS-as-monolith vs. Unix-style small, atomic utilities. Not talking monolithic vs. micro kernels here .. I mean the OS as a whole, or in MicroSoft's case, as a product.

Example "direct link" to 5.3-BETA2 .iso

[Helevius]

For the install CD, use:

ftp://ftpX.freebsd.org/pub/FreeBSD/ISO-IMAGES-i3 86 /5.3/5.3-BETA2-i386-disc1.iso

Replace "X" with 1 to 14 to use the US mirrors.

For a "live CD" to test hardware compatibility, use disc2:

ftp://ftpX.freebsd.org/pub/FreeBSD/ISO-IMAGES-i3 86 /5.3/5.3-BETA2-i386-disc2.iso

Helevius

Re:Beta 3 Due This Week

[Anonymous Coward]

I, FreeBSD, have NOT failed:

--To support SMP
FreeBSD has SMP support and has for a long long time. SMPnG is SMP Next Generation. It's a complete overhaul of a feature that's already supported.

--To generate media attention
Mac OS X is based on BSD. That's generated lots of media attention. I should also mention that slashdot is a form of media, and has gotten your attention.

--To spawn a professionally managed distribution
Did I mention mac OS X yet? No, oh. How about BSDi? That doesn't count? Oh. Well, I'll have to argue that FreeBSD is much more professionally managed than most Linux distro's (which are a hodgepodge shit-show of amateur code).

--To innovate
FreeBSD SoftUpdates. Ports (which the beloved Gentoo copied and is what most people claim is Gentoo's best feature).

--To be relevant.
BSD is generating news on slashdot, therfore it is relevant and very very important.

Re:

[DashEvil]

Have you submitted a bug report of any kind about this? That is what the BETA is for, and it is why it has the BETA tag.

While I respect your opinion, I do wish you would hold judgement until the final release is made.

good sources for BSD newbs OTHER than Handbook?

[discogravy]

I'm looking for lots of short how-tos and best-practices stuff (security, notably,) and not just "do this to that file and killall -HUP the service to affect changes" -- I'd like some theory behind some of it so that I can understand the whys and hows a BSD system is different from a Linux or Solaris box.

There's BSDWiki, which I contribute to now and again, but it's still early in that project's development and although I know a lot of linux stuff, I am not nearly as conversant in the differences between FreeBSD and Linux, and quite frankly, the handbook makes my eyes gloss over.

Re:good sources for BSD newbs OTHER than Handbook?

[IamInsane]

Here's a list of links that you might find useful:

Interesting read's for all newbies to FreeBSD:
http://www.freebsd.org/projects/newbies. html

Some tutorials, very short list but interesting none the less:
http://freebsdaddicts.org/

Some outdated but still usefull articles here:
http://www.freebsddiary.org/

Excellent information on setting up a new FreeBSD host
http://users.rcn.com/rneswold/fbsd-init.html

The Design and Implementation of the FreeBSD OS

[ubiquitin]

www.mckusick.com/FreeBSDbook.html

The book is divided into five parts, organized as follows:

Part I, Overview

Three introductory chapters provide the context for the complete operating system and for the rest of the book.

History and Goals, sketches the historical development of the system, emphasizing the system's research orientation.

Design Overview of FreeBSD, describes the services offered by the system, and outlines the internal organization of the kernel. It also discusses the design decisions that were made as the system was developed.

Kernel Services, explains how system calls are done, and describes in detail several of the basic services of the kernel.

Part II, Processes

Process Management, lays the foundation for later chapters by describing the structure of a process, the algorithms used for scheduling the execution of the threads that make up a process, and the synchronization mechanisms used by the system to ensure consistent access to kernel-resident data structures.

Memory Management, the virtual-memory-management system is discussed in detail.

Part III, I/O System

I/O System Overview, explains the system interface to I/O and describes the structure of the facilities that support this interface.

Following this introduction are four chapters that give the details of the main parts of the I/O system.

Devices, gives a description of the I/O architecture of the PC, describes how the I/O subsystem is managed, and how the kernel initially maps out and later manages the arrival and departure of connected devices.

Local Filesystems, details the data structures and algorithms that implement filesystems as seen by application programs as well as how local filesystems are interfaced with the device interface described earlier.

The Network Filesystem, explains the network filesystem from both the server and client perspectives.

Terminal Handling, discusses support for character terminals, and provides a description of the pseudo-terminal device driver.

Part IV, Interprocess Communication

Interprocess Communication, describes the mechanism for providing communication between related or unrelated processes.

Network Communication and Network Protocols, are closely related, as the facilities explained in the former are implemented by specific protocols, such as the TCP/IP protocol suite, explained in the latter.

Part V, System Operation

Startup and Shutdown, discusses system startup and shutdown and explains system initialization at the process level, from kernel initialization to user login.

Re:

[BasharTeg]

The beta is broken, plain and simple. No networking ability means it's not ready for prime time. Can you understand that?

BETA. B-E-T-A. BETA TESTING. BETA

• BETA

B
E
T
A

Can you understand that?

"mergemaster considered harmful"

[kace]

mergemaster is the most painful part of a FreeBSD upgrade. 20 minutes of paging through files that I've never touched and probably never will (with a couple of minor exceptions).

I see its purpose, but it could be made much less painful by putting most of those files into /usr/defaults/ and then letting the user put his overrides into a file of the same name in /etc/. Just as we do with rc.conf. Throw in a switch to mean "update everything in /etc/defaults/ without asking me" and everyone should be happy. (That is, the curious and the masochists can still page through every changed config' file.)

K.C.