The FreeBSD 7-STABLE branch saw its first point release today. Don’t let the point release moniker fool you, though, as FreeBSD 7.1 comes packed with a number of pretty significant changes, such as support for OpenSolaris’ DTrace, as well as a new, more efficient scheduler.
The release announcement sums up the most important changes between FreeBSD 7.0 and 7.1 as follows:
- 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.
- The cpuset(2) system call and cpuset(1) command have been added, providing an API for thread to CPU binding and CPU resource grouping and assignment.
- KDE updated to 3.5.10, GNOME updated to 2.22.3.
- DVD-sized media for the amd64 and i386 architectures
More detailed information on the changes can be found in the changelog. Available for amd64, i386, ia64, pc98, powerpc, and sparc64, FreeBSD 7.1 can be obtained in a number of ways, which are all detailed in the release announcement.
The ata(4) driver now supports a loader variable hw.ata.ata_dma_check_80pin. This can be used to disable the 80pin cable check on broken systems such as certain laptops and Soekris boards. The default value is 1.
FreeBSD was only operating system that informed me about my computer broken/malfunctioning IDE 80pin cable that caused headache with strange system crashes and data loss. Replaced it with new one and now everything is just fine.
As “old school” FreeBSD user I tend to upgrade from source code- so, I never tried to do it with freebsd-update before. Looks like I have new tool to play/test now.
That ‘petty’ was probably meant to be ‘pretty’.
“petty significant changes”
“pretty significant changes”
It’s great to see sharing technology between open source projects! I hope they won’t stop and will continue with SMF.
Then there’s another thing it’s good for: It’s now even more obivous why ZFS and Dtrace are not in Linux. You can clearly see who is sharing code and who is not.
Agreed! It is great that code is shared among different projects! No need to duplicate work, well done by others?
Why Linux can not use ZFS and DTrace is because of GPL, of course. Solaris CDDL license allows licensing on separate files. You can CDDL just one single file if you wish. This makes it possible to mix licenses. Apple can lift in ZFS files and mix CDDL with Apple’s proprietary code without problems. GPL on the other hand, requires that _everything_ must p~Ayen GPL. No mixing of licenses are allowed. GPL doesnt work together with others. FreeBSD and Solaris and Apple does.
The Linux camp and Linus Torvalds, demands that everyone must change to GPL, or else they will spew out gall and utter discontempt. “Solaris is dead, it should die” etc. :o(
Edited 2009-01-05 21:41 UTC
It is disheartening to see this opinion always modded down. (Oh well, maybe it was the inflammatory part and not the core issue that got the post modded down.)
Listen, GPL people, all things considered we are you allies, not your enemies. Not all GPL critics are evil. I can only speak for myself: I publish source, I advocate openness of hardware and software, standards, interoperability and I oppose software patents. But, I choose a more permissive license. And I accept the cost of not being able to reuse GPL code by mixing it into my own works. Some don’t seem to understand the extent of that cost.
Software development is a lot about code reuse – from naive copy&paste programming of script or web code, to porting undocumented device driver code between very different operating systems. Do we all have to submit to a single license just to be able to freely share source with each other? I hope not. That’s not the ecosystem I signed up for.
As I see it, the GPL primarily solves a problem I don’t care about, which is “closing” of available source. I don’t see it as such a big deal. It’s not like the original source disappears, or stops working and can’t be developed further.
Well, if there had to be one free software license “to rule them all”, I’d advocate WTFPL. The FSF website says that WTFPL is “a free software license, very permissive and GPL-compatible”. If you can’t decide under which license you should publish your programs, WTFPL is always a safe choice.
http://en.wikipedia.org/wiki/WTFPL
Yes, that’s why even if you don’t care about code ‘protection’ like the many devs who use GPL do, it’s better to use a software license compatible with the GPL: BSD 2-clause for example, not the CDDL (which was made by Sun to prevent this code re-use).
OpenSolaris and FreeBSD share a lot of code without any problem, so its not BSD nor CDDL problem, the problem is GPL2 which is compatible only with itself.
BSD and CDDL does not forbid linking with anything while GPL2 does, now it suffers greatly from their ‘protection’.
Given that
1) the GPL was written many, many years before the CDDL
2) the popularity of the GPL meaning that Sun necessarily took it into account writing the CDDL,
it’s easy to deduce that the incompatibility of the CDDL with the GPL was designed into the CDDL, so claiming that this is an issue with the GPL is a logical error at best, spin at worst..
It’s easy to deduce that the incompatibility of the CDDL with the GPL was designed into the CDDL, so claiming that this is an issue with the GPL is a logical error at best, spin at worst..
Right and the fact that the BSD-license cat use CDDL-licensed code but not GPL’d-code tells you what? GPL is a one-way street.
Congratulations to the FreeBSD team!
I love FreeBSD, it works wonders as my home server and as my desktop OS. I simply love the ports system, and the stability that comes with running a BSD system.
That’s amazing, you have written everything I’d like about FreeBSD.
I also use it in my servers and in my house
FreeBSD is as marvelous OS
I may add the following: FreeBSD has – in opposite to most Linusi – an excellent attitude towards documentation. As a developer, this is a key term to me. Everything in the OS has a manpage: the commands, the conguration files, library calls, kernel interfaces, maintenance procedures and so on. Example files and additional documentation, i. e. the FAQ and the FreeBSD Handbook, round up this great work. All this documentation is available locally, right after installation. You don’t need to grep through the Web and user-made Wikis in order to find an information related to the OS. The system’s source code is very tidy and self-explaining, too.
In my opinion, this kind of documentation is essential for a good OS.
Furthermore, the OS is structured very carefully, well intended and tidy (read “man hier”). Everything comes from one team that carefully watches about what changes within the OS.
Allthough most people deny the pure possibility, I’m using FreeBSD since version 4.0 exclusively on the desktop. Today, it’s my primary OS. (My secondary one is Solaris.)
The new release 7.1 adds new features, more stability and speed to a system. I’m not trying to poke fun on any other OS, but when the version number increases, the speed usually goes down. With FreeBSD, it goes up! (I’m just sad about the “big toolkits” eating up this speed gain already…) I’ve been following -STABLE since 7.0 and have just put 7.1 on an older system to try (before finally updating my main system). It’s impressing how even older hardware can do a really good job using FreeBSD.
Not on pure FreeBSD, but when I was selecting my free/open OS for my latest computer, I first went to PC-BSD 7 because a couple of years ago I had an excellent experience with it. But when I installed it, the interface seemed sluggish and it did not automatically figure out my screen resolution, which sort of suprised me. I did not have any problems before (albeit on older hardware – my current box has somewhat newer chipsets).
I ended up going with a variety of linux which autoconfigured perfectly and is noticeably snappier (which also surprises me).
I know switching distros over an initial, graphical experience is silly, but it left me wondering if there would be other configuration issues.
Since that time I have added an NVIDIA graphics card, maybe for fun I should run PC-BSD again to see if the problem was all related to the intel G31 chip.
It’s really great to see FreeBSD improving by leaps and bounds. I’ve been playing around with it in the form of PC-BSD and DesktopBSD for some time. The only thing really keeping me from using it as my primary OS is lack of easy to use virtualization software like VirtualBox. Since I do a lot of IT related tasks, it’s essential that I be able to access the many other operating systems I need on a daily basis. But I digress. I’m really looking forward to PC-BSD’s implementation of KDE 4.2 final.
I was excited about this release. I was hoping that they’ll have it in time with Gnome 2.24 ported in so that I can just install everything from CD for my desktop. I am just a little disappointed.
The FreeBSD Gnome Team was waiting the output of 7.1-RELEASE, because the frozen ports. Now, maybe while I write this, Gnome will update to 2.24 into ports tree.
Have a nice day
TooManySecrets