login
Search
The question was asked recently on a FreeBSD mailing list, "What will be new in FreeBSD 5.0?" The thread discussed several ways a person could obtain such information, one good source being the latest release notes. The first developer preview of 5.0 was released on April 8th [earlier story]. The final release is targeted for the end of this year.
Robert Watson offered an interesting summary of items to look forward to in FreeBSD 5.0, including: SMPng ("next generation" symmetric multiprocessing), KSE (improved scheduling), devfs (automatic /dev management), Firewire support, and much more. Read on for more details.
From: a.s.gruner
To: freebsd-current AT FreeBSD.ORG
Subject: What will be new in FBSD 5 ?
Date: Tue, 7 May 2002 19:52:40 +0200
Hi.
Can someone explain, or give me an URL, what will be new in FreeBSD 5.0
?
Are there major changes ? And what kind of ?
Is there a place where these changes are described ?
Thanks.
asg
From: a.s.gruner
Subject: Re: What will be new in FBSD 5 ?
Date: Tue, 7 May 2002 22:32:36 +0200
Oh, i forgot somthing.
Can i find out when atacontrol (or any other change) was the first time
in a release ? In 4.4 or 4.5 ?
asg
From: Terry Lambert
Subject: Re: What will be new in FBSD 5 ?
Date: Tue, 07 May 2002 22:52:23 -0700
The easiest way I've found is to cd into the source directory,
and do a "cvs log | more", and then look at the tags.
-- Terry
From: Robert Watson
Subject: Re: What will be new in FBSD 5
Date: Wed, 8 May 2002 10:28:59 -0400 (EDT)
Actually, the easiest thing to do is to check out the 5.0 release notes
from the source tree, build them, and read them. Or you can read them in
sgml source, of course :-). You can check them out of
src/release/doc/en_US.ISO8859-1/relnotes
Ignore entries marked '&merged' since those are things that went into the
5.0 branch but got merged back to 4.x and will be included in a release
prior to 5.0. They get removed before the release happens but are left in
for reference. Off-hand, some of the really interesting things going in
are:
- Fine-grained kernel SMP (SMPng) which permits higher performance and
parallelism, and restructures the kernel around improved synchronization
primitives. Many scalability improvements for SMP, and an improved
kernel locking paradigm.
- KSE: Derived from the notion of Scheduler Activations, this mechanism
will support much improved scalability and performance of user threads
on FreeBSD.
- devfs: the device filesystem removes manual management of the /dev tree,
allowing the system to adapt to device environment changes more cleanly
and with less administrator intervention. This is really helpful with
widespread use of USB, firewire, etc.
- Client-side NFS locking using a distributed lock manager, a feature
we've needed for a long time and will finally have.
- A complete reimplemntation of the /dev/random entropy collecting
mechanism based on Yarrow, improving the gathering and management of
"randomness" for cryptographic purposes.
- Support for Sparc64, IA64, and possibly PowerPC depending on how that
goes :-)
- Support for extended attributes and file system ACLs in UFS, and also
support for an enhanced version of the file system, UFS2, which targets
higher performance for EAs and ACLs, support for larger disk and file
sizes, and more. Support for file system snapshots. Support for
background file system checking at boot.
- A high performance SMP-capable kernel slab memory allocator.
- A complete reimplementation and reintegration of Pluggable
Authentication Modules (PAM), correcting many long-standing integration
issues and bugs.
- The "GEOM" framework, improving flexibility of the disk device
framework, bringing support for cryptographic protection of swap and
file systems.
- Removal of almost all use of /dev/kmem and setgid for system monitoring
tools, improving security by reducing the level of privilege required
for routine monitoring activity.
- Support for UDF, the filesystem used on DVDs.
- Support for Cardbus, and a complete reimplementation of the PCCard
stack.
- Support for ACPI, which replaces (among other things) the existing APM
mechanism, improves hardware discovery and probing, and allows us to
support much of the new hardware being released. This is for both i386
and also (I believe) ia64.
- Support for Open Firmware, which serves a function similar to ACPI on
PPC and Sparc64.
- An OpenSSH upgrade or two
- The TrustedBSD MAC framework, which permits run-time extension of the
kernel security framework, including support for a variety of MAC models
(Biba, MLS), as well as a plug-in SEBSD module which uses the framework
to support substantial parts of NSA's FLASK and SELinux implementations.
A bunch of other random security modules that plug in, including
mac_seeotheruids, mac_bsdextended (a firewall-like tool for file
systems), and more.
- A move to the lukemftp client and server, improving functionality and
the level of support.
- Upgrades to the USB stack to support, among other things, USB2
And much more that I've forgotten, and beg forgiveness for forgetting.
All in all, this is going to be an excellent release, and will really
propel the FreeBSD operating system to (as people so rediculously put it)
"the next level".
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[Email Blocked] NAI Labs, Safeport Network Services
From: Robert Watson
Subject: Re: What will be new in FBSD 5
Date: Wed, 8 May 2002 11:05:24 -0400 (EDT)
Oh yeah, a couple more things:
core@ recently approved a committer to bring in firewire support.
Hopefully this will mean support for firewire in FreeBSD 5.0-RELEASE.
TI-RPC, which upgrades our RPC and NFS userland frameworks, adds support
for IPv6, and more.
And much more.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[Email Blocked] NAI Labs, Safeport Network Services
From: Garance A Drosihn
Subject: Re: What will be new in FBSD 5
Date: Wed, 8 May 2002 13:09:37 -0400
At 10:28 AM -0400 5/8/02, Robert Watson wrote:
>Actually, the easiest thing to do is to check out the 5.0
>release notes from the source tree, build them, and read
>them. Or you can read them in sgml source, of course :-).
>You can check them out of
>
> src/release/doc/en_US.ISO8859-1/relnotes
You can also check them out at:
http://people.freebsd.org/~bmah/relnotes/
as the ever-busy Bruce Mah often builds the latest snapshot
of the release notes. It may not be up-to-the-minute, but
I find it a lot more fun to take advantage of other people's
work than to do the work myself... :-)
devfs!
I'm a linux user myself, but KUDOS to the FreeBSD people for shooting for DevFS in 5.0! Hopefully this pushes acceptance and use of devfs in the Linux realm, too. The old system has *got* to *go*.
Re: devfs!
The old system has *got* to *go*.
Perhaps, but our racey evil thing called devfs is not the solution.
maybe you can explain
I know Patrick Mochel is working on something called driverfs along with the new driver model which builds a proper device tree allowing for proper initialization and shutdown. Is driverfs slated to replace devfs? Do they have the same functionality? Can they co-exist? Any light you or anyone else could shed on the relationship between devfs and driverfs would be very much appreciated.
thanks,
Paul Lorenz
pal6640 at RochesterInstitituteofTechnology.EDUcation
driverfs
There's a documentation file: Documentation/filesystems/driverfs.txt in the Linux 2.5 kernel tree. By the looks of things, it is functionally closer to procfs than to devfs.
5.0?
If you read devfs 's manpage.
devfs was in freebsd since 2.x
but it was not on by default..
bugs, maybe. i don't sure
Yeah, that Robert Watson guy
Yeah, that Robert Watson guy - what
the hell does he know about FreeBSD?
I mean he can't even read the devfs manpage.
;) (in case it wasn't obvious)
Yeah, that Robert Watson guy
Yeah, that Robert Watson guy - what
the hell does he know about FreeBSD?
I mean he can't even read the devfs manpage.
;) (in case it wasn't obvious)
o_O devfs has already been r
o_O
devfs has already been removed from Linux
i hope FreeBSD will develop a better implementation or drop the idea early
Trusted BSD Information
I'd like to find a good DETAILED tutorial of the Trusted BSD features in 5.0. I've been to the web page, but documentation seams more an overview than practical...
Any suggestions?
Thanks!
devfs useful, but is it insecure?
I really like the idea of having a clean /dev hierarchy, but is this the same devfs that Red Hat refuses to include because it's insecure?
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50497
Hard to say...
Most of the objections to devfs seem to be highly politicized. I'd take any criticism without any backup with a rather large grain of salt.
RTOS, Under Pinnings and InfraStructure?
Am wondering if RTOS RealTime OS, and RealTime Event models underpinnings are Not the way of the Future for any n all Operating Systems? The pieces certenly need to be apart of the Kernel with the infrastructure just above, before RealTime Event models can be considered to be a universal given.
I remember in the mid to late 1990's Real-Time was the tech catch word of the day, and everything seemed to get labeled accordingly to be Real Time. Yet Real-Time is exactly what a Personal Computer needs. To be able to respond to the Users changing moods, wants, and needs.! By shifting its priorities as required.!
Perhaps RTOS, and RTE's RealTime Event models and feedback loops, with the User in the center, need more thought? Yes, the game interface is but one good example. Multi-medial another. Todays n tommorrows personal computer are n will be systems in their own right.
Sincerely
Real-Time is a real part of Device's Now.
Many of the Device Drivers already have and use Real-Time models as apart of their implementation, Now.! ... RTOS and RTE's would be an opportunity to provide a Unified front to this potential conflict of interests Problem, ;)
Real-time misunderstandings...
Yet Real-Time is exactly what a Personal Computer needs. To be able to respond to the Users changing moods, wants, and needs.! By shifting its priorities as required.!
Most people misunderstand the term 'real-time'. The technical definition of the term is simply this: a system with a strictly bounded response time.
In other words, if the design spec calls for a response in 10 milliseconds, then the system had better respond within 10 milliseconds, come hell or high water. If it doesn't, then it is considered to be a design failure.
In order to provide guarantees about response time, some tradeoffs are made which seem very counterintuitive to what an ordinary computer user might think. For example, processor caches decrease the execution time per instruction _on average_, but in the worst case, they actually increase the instruction execution time. Therefore, caches are often disabled on real-time systems.
As you can see, real-time systems are rather exotic, and make tradeoffs which make no sense for desktop or for server applications.
Real-time is not about minimizing response time. Enhancements which lower the average response time can be helpful for realtime systems, but only if they don't increase the worst-case response time beyond the design spec, or worse yet, make the response time nondeterministic.
Likewise, dynamically adapting the system's perfomance characteristics to the job at hand might be a worthwhile area to work on, but it has nothing to do with real-time.
hummm, Bottle Necks and Buffers?
BottleNecks indeed.! You can only push the contents through the restriction so fast, and No matter how you try you get daeminishing returns, there after.! Buffers can hold the flow on either side and thus allow the contents to try and flow as quickly as the bottles neck will allow.! But in the end, the only real solution is a bigger pipe.!
I would think that Real-Time in systems and especially net-work terms' is not the same Real-Time one thinks of when considering UseInterface design.! For there the constraint is User happyness, ...! Miss just one event, and disaster is afoot. Cause the smooth flow of video to hickup and ouch, or the sound glitches caused by the content Not arriving at the sound card in a timely manner, ...?
Yes the Human User is a very sensative critic, hard to please.!
Even with a complete system at their beck n command they seem to always want more, ...! And 2 think, computers have speed up two thousand fold in the past decade? wowww! Will it never End?
from 1meghz to 2000meghz or 2gighz.
find time of addition
The easiest way to find out when something was added is to simply read the man page. for example: man atacontrol
HISTORY The atacontrol utility first appeared in FreeBSD 4.6.