Slashdot Log In
FreeBSD 7.2 Released
Posted by
timothy
on Mon May 04, 2009 03:56 AM
from the quite-up-to-date dept.
from the quite-up-to-date dept.
An anonymous reader writes "The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 7.2-RELEASE. This is the third release from the 7-STABLE branch which improves on the functionality of FreeBSD 7.1 and introduces some new features. Some of the highlights: Support for fully transparent use of superpages for application memory; Support for multiple IPv4 and IPv6 addresses for jails; csup(1) now supports CVSMode to fetch a complete CVS repository; Gnome updated to 2.26, KDE updated to 4.2.2; Sparc64 now supports UltraSparc-III processors. For a complete list of new features and known problems, please see the online release notes and errata list."
Adds another anonymous reader, "You can grab the latest version from FreeBSD from the mirrors or via BitTorrent. There is also a quick review of the new features and upgrade instructions."
Related Stories
[+]
FreeBSD 7.1 Released 324 comments
Sol-Invictus writes "The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 7.1-RELEASE. This is the second release from the 7-STABLE branch which improves on the functionality of FreeBSD 7.0 and introduces some new features. Some of the highlights:
The ULE scheduler is now the default in GENERIC kernels for amd64 and i386 architectures. The ULE scheduler significantly improves performance on multicore systems for many workloads.
Support for using DTrace inside the kernel has been imported from OpenSolaris. DTrace is a comprehensive dynamic tracing framework.
A new and much-improved NFS Lock Manager (NLM) client.
Boot loader changes allow, among other things, booting from USB devices and booting from GPT-labeled devices.
KDE updated to 3.5.10, GNOME updated to 2.22.3.
DVD-sized media for the amd64 and i386 architectures."
[+]
A Taste of FreeBSD With VirtualBSD 43 comments
ReeceTarbert writes "If you wanted to try FreeBSD but didn't have the right hardware, or enough time to make it useful on the desktop, VirtualBSD might fit the bill: it's a VMware appliance based on FreeBSD 7.1-RELEASE and features the Xfce 4 Desktop Environment and a few of the most common applications to make it very functional right out of the box. If you're curious you can have a look at the screenshots, or proceed to the download page and grab the torrent file right away. (Note: VirtualBSD also works in VirtualBox 2.x as long as you create a new virtual machine and select the virtual disk from the archive instead of creating a new one)."
Submission: FreeBSD 7.2 Released by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Includes ZFS and DTrace production ready ! (Score:4, Informative)
Cheers !
Re:Includes ZFS and DTrace production ready ! (Score:4, Interesting)
Parent
Re:Includes ZFS and DTrace production ready ! (Score:4, Informative)
The ZFS in 7.2 is v6, and pretty much can't be brought up to date without breaking 7.x ABI.
ZFS v13 is in 8-CURRENT and pretty much is as production-ready as what's in opensolaris.
Don't expect miracles on a 32-bit platform. The opensolaris people don't recommend it on their 32-bit codebase either.
Parent
Re:Includes ZFS and DTrace production ready ! (Score:5, Insightful)
The problem with ZFS on OpenSolaris i386 is that ZFS is very heavy on 64-bit arithmetic. The only way of doing this on x86 is to store the 64-bit value across two registers, meaning that each calculation uses 4 registers in total, dramatically increasing register churn. This makes performance suck.
The problem on FreeBSD is that the adaptive replacement cache runs out of memory and the kernel panics. This is a much, much more serious problem. I'll take slow-but-working over crashes-and-loses-data any day.
Still, I'm looking forward to 8 RELEASE if it includes ZFS v13 and the improvements to the sound subsystem (per-vchan volume, faster mixing, and so on).
Parent
Re:Includes ZFS and DTrace production ready ! (Score:4, Interesting)
In 7,2, you still get the "ZFS is cosidered to be experimental" message when you boot. As mentioned, elsewhere, the 7.x branch retains the ZFS v6 code, and v13 will be in 8.0.
That said, I've put ZFS through its paces on the amd64 platform, and it works great (at least w/ the 2- and 4-GB RAM configurations I've had on my workstation). I don't think I've ever had a ZFS-caused panic on amd64. However, I couldn't find a stable config under i386 to save my life, but I don't really feel that's a problem because ZFS is truly a 64-bit subsystem and should be treated as such. If you're competent to administer large data sets to begin with, you'll be competent enough to take care of any tweaking ZFS may need (which is minimal under amd64, if needed at all).
Parent
I really wish BSD would take off. (Score:3, Insightful)
Re:I really wish BSD would take off. (Score:5, Funny)
I really feel for the BSD guys. Just hope they can keep users. Having choice in OS selection is great.
There will always be a market for BSD. Afterall, what will us elitists use once Linux becomes too mainstream?
Parent
Re: (Score:3, Insightful)
Re:I really wish BSD would take off. (Score:5, Informative)
Parent
Re: (Score:2)
Re: (Score:2)
OpenSolaris?
That comes after the BSDs take 10% of the desktop market share.
2148 if you were wondering.
Haiku / BeOS (Score:3, Insightful)
Re:I really wish BSD would take off. (Score:4, Funny)
> I really feel for the BSD guys. Just hope they can keep users.
There are quite a few changes in there, so I can imagine that they will both be happy.
Parent
Re: (Score:2, Funny)
That's only because they're geekier.
Re: (Score:2, Funny)
[citation (and pics) needed]
Re: (Score:3, Interesting)
http://freebsd-image-gallery.netcode.pl/_daemonette/111143969_35533831ab.jpg [netcode.pl]
http://freebsd-image-gallery.netcode.pl/_daemonette/freebsd-002.jpg [netcode.pl]
http://freebsd-image-gallery.netcode.pl/_daemonette/freebsd-003.jpg [netcode.pl]
http://media.photobucket.com/image/penguin%20mascot%20girl/twistedliza/signature%20pics/blog/DSC00767e.jpg [photobucket.com]
http://images.celebrateexpress.com/mgen/merchandiser/38199.jpg [celebrateexpress.com]
http://z.about.com/d/raleighdurham/1/0/u/8/-/-/Fat-Penguin-Clowns-at-Ringling-Bros-Circus.jpg [about.com]
just my two cents (Score:5, Interesting)
still waiting for autofs support as well, as converting from my autofs to amd on local machines is a pain.
if i have 3500 servers i need to deploy, pxe is still not supported without a kernel hack. makes for long nites.
Re: (Score:2)
still waiting for autofs support as well, as converting from my autofs to amd on local machines is a pain.
Pretty hilarious — I switched to amd back in the SunOS 4.1.3 days because sun's automounter was complete poop. Here you are trying to avoid using amd. Why not just bite that bullet? How hard could it be to write a script to convert one config to the other?
Re: (Score:2)
the problem with recompiling the limit in BSD is tha many apps only allocate enough memory for the 16, so if you managed to recompile with say 32 or 64 groups, you end up having to rebuild the ports tree and most of your supporting apps to make sure they dont implode when they hit a user with >16 groups
Re:just my two cents (Score:4, Informative)
Are you aware that Linux 2.6.3 is 5 years old? Linux increased the default group limit in the following release, 2.6.4, to 65536 [kernel.org]
Parent
Re: (Score:3, Insightful)
Are you aware that Linux 2.6.3 is 5 years old? Linux increased the default group limit in the following release, 2.6.4, to 65536 [kernel.org]
I absolutely love this argument that "linux is better" because one constant in the kernel is bigger in the linux kernel (thus also causing certain kernel data structures to be necessarily larger) than on FreeBSD, neither are runtime configurable, both can be changed at kernel build time, and the common case is that a user belongs to well under 65K groups. I concede, linux has won the day, and is the One UNIX-like System To Rule Them All.
Three UNIX-like Systems for the mainframe users under the sky,
Seven f
Who sponsors FreeBSD? (Score:3, Interesting)
First of all, I'm not trolling.
Most successful open source projects have some kind of corporate backing, whether it be developers, funding or both. Linux has IBM, HP, RedHat, etc. Sun sponsors and manages a number of open source projects.
The community behind FreeBSD have put together what seems to be (I've never used it for more than a few minutes at a time) a solid server operating system whose command-line code forms part of the basis of what is IMO the best consumer operating system (OS X). From what I understand, this is due to a small but devoted group of developers.
Still, not to bemoan the FreeBSD community's efforts, but I'm wondering if there's some kind of corporate backing, seeing as I'm certain several companies use it in critical production situations.
There was nothing about this in the Wikipedia entry.
Re: (Score:3, Informative)
FreeBSD is supported by (but not run by, as far as I can tell) the FreeBSD Foundation [freebsdfoundation.org], a non-profit. Previous sponsors of the foundation include some big names like Google, NetApp, and Juniper [freebsdfoundation.org]. Apple is missing from the list, but I know that they have donated some significant chunks of code.
Re:Jails (Score:5, Informative)
FreeBSD Jails [wikipedia.org] are a kind of light-weight server partitioning scheme, in the same vein as Solaris Zones [wikipedia.org].
Parent
Re:Jails (Score:5, Insightful)
And in the same vein, they are inadequate because all instances share a kernel.
And are significantly faster (on our workload) and more efficient for the same reason. Since all jails pull from the same heap, you don't have to worry about under- or over-allocating RAM to an instance. You also don't have to contend with multiple kernels all trying to do bookkeeping many hundreds of times per second.
Jails obviously aren't the right tool for every job, but when they suit your needs, they're outstanding.
Parent
Re: (Score:3, Informative)
Re:Jails (Score:5, Funny)
Parent
Re:Yaaaaay! (Score:5, Interesting)
ZFS + Ports, take that Ubuntu!
I dunno about ZFS, but I've recently been playing with a freebsd install (7.1 I think), and ports, while a cool idea, seems pretty creaky in practice.
My main beefs were not with the infrastructure, which seemed OK, but that the package maintenance seemed pretty spotty: many many packages (even fairly "major" ones) were pretty out-of-date, even compared to e.g. debian stable, and in many cases they were installed as monolithic chunks where a bit of judicious splitting would have been very helpful -- for example, an otherwise fairly dependency-free library that happens to come with some demo apps that drag in all of OpenGL and X (it would have been better to put the apps with their heavy dependencies in a separate package, or make their inclusion easily configurable)!
Sadly, the ports collection felt kind of like a 2nd-class add-on (and I gather, that's essentially what it is). Even though there are many packages in debian where the maintainer should probably be doing a better job, on average debian's package collection feels a lot more solid to me that what freebsd has in ports...
Parent
Re: (Score:3, Interesting)
You can usually configure most ports, try doing a "make config" on the port dir... You should be able to turn those X11/OpenGL demo apps off if the port is well written.
What i hate about binary packages, and debian suffers from this greatly, is when a feature is optional to compile in (as opposed to comprising solely of separate files as in your example).. a binary package will typically be compiled with all the options turned on, thus necessitating dependencies you may not want or use.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
What about removal of packages?
One of the things I like about Debian source packages, is that they can be compiled, installed, played with, upgraded, etc and finally removed - all that without a hustle.
Impression I had that ports is just a nice front-end for "./configure && make && make install". And as usually "make uninstall" is largely missing (as only few source packages provide the functionality).
That means over time system gets loaded with orphaned files.
Actually the thing
Re: (Score:3, Informative)
What about removal of packages?
Ports provide a build skeleton for creating packages. Every port comes with a list of installed files and potentially an uninstall script. You can remove them with make deinstall in the port directive or with pkg_deinstall / pkg_delete, just as you can with binary packages.
Impression I had that ports is just a nice front-end for "./configure && make && make install".
Yes, it is (and various other build systems). And providing uninstall support is part of the difference between a nice front end and a trivial front end.
Re: (Score:3, Interesting)
What about removal of packages?
This is a really basic "RTFM." It's not "make uninstall" like you wrote in your post, but "make deinstall"
Alternatively, you use the "pkg_delete" or "pkg_deinstall" command to delete any installed package. (again, to find out potential options etc, RTFM)
Very simple.
One of the things I like about Debian source packages, is that they can be compiled, installed, played with, upgraded, etc and finally removed - all that without a hustle.
Yes, those would be fundamentals of any packaging systems.
Impression I had that ports is just a nice front-end for "./configure && make && make install". And as usually "make uninstall" is largely missing (as only few source packages provide the functionality).
Your impression is somewhat correct. Again, this is something expected of ANY source packaging system. I'm not sure how else you would want it to operate?
That means over time system gets loaded with orphaned files.
I may have missed something...why
Re: (Score:3, Informative)
Unlike Debian or even OpenBSD, ports in FreeBSD don't receive much testing.
Some ports haven't been updated for a while, some even never worked at all, but they are still in the tree for ages. For instance lang/neko never worked on FreeBSD. It compiles, but it was obviously never tested as creating a basic thread is enough to make it crash. Oh and it still has a knob to compile it with MySQL 4.x library (yes, 4.x ...).
Re: (Score:3, Informative)
First you have to know where it is located
(for that you either need to install another package to (and you have to know that name too) or make sure you have Internet connection and go to freesbd.org ports page to search for the name
cd /usr/ports
make quicksearch name=packagename
You'll find the package. No need to install anything new.
Then you have open the login shell as root,
(and you must know how to do that -- it does not automagically prompt you for a password )
"apt-get install foo" doesn't hold your hand, either. Nor did rpm prompt you for a password the last time I used an RPM-based system.
Then you CD to that directory start the build
and discover that it tries to download source
code for Gnome or KDE then build it -- which
will take half a day on some machines....
welcome to the ports system
The FreeBSD maintainers aren't concerned with being trivial to use. They're more concerned with creating a powerful and flexible system.
They focus on this almost to a fault. There's a recent thread on freebsd-questions with the subject "Modern FreeBSD Installer" where a fe
Re:Yaaaaay! (Score:5, Insightful)
And in rare cases when you need a rare obscure feature, it will not be compiled in, leaving you to play a bit with debuild and stuff. That sucks, too.
However, binary packages are much convinient in many cases. I've been using FreeBSD with ports before, and now I'm using Gentoo with portage (which is inspired by FreeBSD's ports) and I'm happy to turn optional features as I like, but I miss a lot of things from binary distros like Debian -- speed of installation, some assurance that the package will work, less work on my part to get it working, etc. To get the source, change a few switches and create your own deb isn't such a deal if you have to do it for only several packages. I did this on Nexenta OpenSolaris installation recently, and I say it's easier than maintaining a Gentoo installation.
And the unneeded features aren't such a big deal, really. I've run Debian on slow low-end devices, and it runs fine, they take a bit more space and the memory usage somewhat grows, but on a modern system that shouldn't be a problem at all -- it is offset by the lack of ports tree, the need for installed compiler and headers, and the faster installation. Debian developers also splits some optional features as seperate packages, where it is possible. And you never know when you actually might need these optional features.
So ports have their pros and cons, I really liked them when I had to play with them, but as I'm lazy I would choose something apt-get-style now. Debian GNU/kFreeBSD is a nice choice if you want apt-get, FreeBSD kernel. I'm not sure if they have working ZFS and DTrace support at the moment, but it's still worth checking out.
One of the main reasons I would choose FreeBSD at the moment is ZFS. And there is very low probability that we'll see this in Linux.
Parent
Re:Yaaaaay! (Score:5, Informative)
Parent
Reason I favor Gentoo Over Debian (Score:3, Interesting)
Revolves around those optional features that are compiled into the damn package, pulling in all those extra dependencies. Portage and the Use flags are very good for that. I can specify on a per package basis what optional features I want, which helps keep my system much leaner.
Another issue I've got with many other distros is the continual insistence of starting so many services at boot. To me it's reaching the point that most distros look like a damn windows installation with all the services running. Per
Re:Yaaaaay! (Score:4, Informative)
"and ports, while a cool idea, seems pretty creaky in practice"
"any many packages (even fairly "major" ones) were pretty out-of-date"
"Sadly, the ports collection felt kind of like a 2nd-class add-on"
Dude, what are you talking about ? Non of this is true!
If you tried the ports that come with 7.1-RELEASE they are several months old, this is normal, they come with the release. If you want up-to-date software you just need to update the ports collection, this is done via the csup(1) utility. Please try to get a little bit deeper into FreeBSD before talking bullshit about it!
Parent
Re:Yaaaaay! (Score:5, Informative)
Sadly, the ports collection felt kind of like a 2nd-class add-on (and I gather, that's essentially what it is). Even though there are many packages in debian where the maintainer should probably be doing a better job, on average debian's package collection feels a lot more solid to me that what freebsd has in ports...
I don't mean to slam your dick in the door, but one cannot compare ports (apples) to packages (oranges).
Now before you fire back with, "But Debian says packages are both source and binaries !", allow me to reply, "Damn you, Debian." Seriously, though -- apt-get from Debian uses either source packages (equivalent to freebsd ports) or binary packages (equivalent to freebsd packages), depending on the commands you feed to it.
Here's how FreeBSD separates source installs from binary installs:
Ports: Slower source installs compiled on your machine with make.conf optimizations for your system's architecture. Gentoo (portage/emerge) and Debian (apt-get) have Jordan Hubbard (now working for Apple on Darwin) to thank for these. Quick explanation below in the code quote:
Installation process for installing imaginary app "slashdot" (assuming you have the ports tree installed on your system):
Packages: Fast binary install that is compiled on someone else's system with their choice of "make config" options, for their architecture; usually a very generic build. These use pkg_tools to install, delete, get info for these binary packages.
Installation process for installing imaginary app "slashdot":
When i say slow and fast for install speeds, these comments are relative to two things: source install and binary install. Source compilation time for monolithic packages like firefox3, openoffice.org, xorg, gnome2, etc. take upwards or 6 hours to several days depending on the system doing the compiling. The loss in program responsiveness by using a generic binary package install may be worth it(unnoticeable) to save 3 says compile time. With computers getting faster, optimizations are less noticeable, etc., however, programs also demand more resources as time goes on, andso this may be a wash; and one STILL may want to compile certain programs for their own machine.
My main beefs were not with the infrastructure, which seemed OK, but that the package maintenance seemed pretty spotty: many many packages (even fairly "major" ones) were pretty out-of-date, even compared to e.g. debian stable
The reason for binary package apathy on FreeBSD, as I see it, is as follows. Most people that use FreeBSD don't care about binary packages beyond the base package for a RELEASE branch install from ftp or cd/dvd. For all other programs, most users will compile from source using ports and fetch new versions using portsnap, and lastly upgrade to said new versions using portupgrade. For aforementioned monolithic programs like openoffice.org, one may want to just bite the bullet and avoid a 3 day compile (which currently takes up ~12 gigs of space) including several license agreements, etc. to compile the beast, and just install a precompiled binary package from the "ooo" site.
With that said, most ports maintainers are fairly quick to release the latest version of a port, and some even maintain not only the release port of a program, but the beta. e.g. there is a firefox3(curren
Parent
Re: (Score:3, Informative)
My main beefs were not with the infrastructure, which seemed OK, but that the package maintenance seemed pretty spotty:
Could we get a less vague or subjective characterisation? The general concensus by FreeBSD users (and one shared by myself), especially those coming from a Linux background, is that the ports system Just Works(TM). As for the tools to manage installed ports or package, there's certainly plenty to choose from. By that I mean the issue, if there is one, is generally one of "preference" ra
Re: (Score:3, Informative)
I don't get it either. As if I'd want FreeBSD to be a desktop OS.
Desktop OS's are supposed to be ready for the desktop. Not FreeBSD.
That's...not altogether true. Though maybe kind of. It depends a good deal on how you view computers. If a person views computers as simply a tool, a means to do something mainly concerning the "real world" and events surrounding it, but of no interest as to the computer plus software in and of itself, then that person would probably be better-served with something with Windows
Re: (Score:3, Insightful)
Maybe you could have read his post instead of imagining what it was and then commenting that he is wrong.
What, and sully such a longstanding /. tradition?
Besides, that also means that one would actually have to think and respond to certain facts and logical arguments put forth by another person. Such tedium!
He was talking about PC-BSD, a FreeBSD-based distro designed for desktop use. Since it has many pre-built packages and a GUI front-end for ports, it is actually quite a usable desktop distro. Pretty much
Re:KDE updated to 4.2.2 (Score:5, Interesting)
Parent
Re: (Score:2)
It absolutely is on FreeBSD amd64, but this is mainly due to the fact that it is still lacking accelerated Nvidia support on that hardware. Terrible hardware support (I've mentioned wifi before) the makes FreeBSD an appalling desktop anyway. I'd leave it in the datacentre where it's actually an excellent choice.
Re: (Score:2)
Re:It not about the technical excellence (Score:5, Funny)
I think BSD needs a new, cuddly but cool mascot. how do you compete with tux? Is the cresta (remember that?) polar bear available?
He's MIA after his glacier suddenly melted. Witnesses saw a little guy with some sort of trident fleeing the scene.
Parent
Re: (Score:2)
Well no, Gentoo is Linux which is not the same thing at all.