FreeBSD 6.2 Released To Mirrors 168
AlanS2002 writes "FreeBSD 6.2 has been released to mirrors. The release notes for your specific platform are also available. FreeBSD is an advanced operating system for x86 compatible (including Pentium and Athlon), amd64 compatible (including Opteron, Athlon64, and EM64T), ARM, IA-64, PC-98, and UltraSPARC architectures. It is derived from BSD, the version of UNIX developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. Additional platforms are in various stages of development."
Availability (Score:5, Informative)
Torrents are available. [freebsd.org]
A script for upgrading FreeBSD 6.1 systems is available. [daemonology.net]
Re: (Score:1, Interesting)
Re:Availability (Score:4, Informative)
Re: (Score:1, Informative)
They have support for the expensive and fast disk controllers and the fastest network cards.
10Gbit might be more and more used, but it is to early to say it is old.
Release announcement (Score:4, Informative)
Re: (Score:1, Insightful)
Yeah, now we can't bitch that it's a dupe!!
Some people are never pleased.
Re:with an ad no less (Score:5, Informative)
From the release announcement:
Re: (Score:2)
This is SOOO cool, now I don't need to compile the Modula-3 compiler anymore to compile this essential piece of software.
nope (Score:4, Interesting)
AT+T's lawsuit ran in to problems becuase they hadn't properly protected their code from unpublished disclosure. At the time, copyright law was very different, so this mattered. The judge indicated that AT+T might not have copyright to some things. AT+T was also caught violating Berkeley's copyright.
On the other hand, the trademark was being violated by BSDI and there may have been some minor problems in the BSD code base.
So the parties agreed to quit and keep things quiet.
If you want to use the trademark, you need a license. Licenses are easy to get, provided that you fully and correctly implement an OS that follows a standard called the Single UNIX Specification. FreeBSD violates this standard in many ways, and is thus inelligible for getting a license to use the trademark.
Linux isn't UNIX either, though it's now close enough that the Open Group can maintain a small list of deviations that need to be voted out of existance.
Re: (Score:2)
Single Unix Specification (Score:3, Informative)
On the whole, the goal is to comply with the SUS. As with most operating systems, the difference is in the implementation and the corner cases.
The main difference I notice is 'ps'. The Unix spec wants 'ps -ef'. BSD wants 'ps auxww'.
Some information on current efforts:
Re: (Score:2)
But wait..... (Score:2, Interesting)
Re:But wait..... (Score:5, Funny)
Re: (Score:3, Informative)
That was Gentoo/FreeBSD [slashdot.org].
Re: (Score:1)
Race to post the first FUD? (Score:1)
Well my computer is working awefully well for one running on an OS that is dying. And I haven't even CVSUPd from the prerelease to the release yet.
Ha! I did it! (Score:5, Funny)
So last night I downloaded 6.1 and installed it.
Voila! 6.2 out today.
Wanna see it rain? I'm going to go wash my car.
Re: (Score:1)
Re:Ha! I did it! (Score:4, Informative)
Luckily, FreeBSD has an excellent system for updating the operating system by source code. This guide [freebsd.org] teaches you how to update to the latest stable release of FreeBSD via source code. It's really nice and works well. Just remember to use FreeBSD-STABLE instead of FreeBSD-CURRENT, unless you are a FreeBSD developer or are interested in the absolute latest development version of FreeBSD, working or not.
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:1)
(Please don't hurt me... I know portage was inspired in some FreeBSD system).
Re: (Score:2)
Oh well, I guess that's just the way Beastie likes to torture us sometimes.
Re: (Score:1)
Upgrading from 4.x (Score:4, Interesting)
Thanks in advance..!
Re: (Score:1)
Re: (Score:2)
Re: (Score:2, Interesting)
I suggest you go from 4.11 to 5.5 (RELENG_5_5) first, and
Re:Upgrading from 4.x (Score:5, Informative)
3 Upgrading from previous releases of FreeBSD
Source upgrades to FreeBSD 6.2-RELEASE are only supported from
FreeBSD 5.3-RELEASE or later. Users of older systems wanting to
upgrade 6.2-RELEASE will need to update to FreeBSD 5.3 or newer
first, then to FreeBSD 6.2-RELEASE.
And from INSTALL.TXT:
Warning: Binary upgrades to FreeBSD 6.2-RELEASE from FreeBSD
4-STABLE are not supported at this time. There are some files
present in a FreeBSD 4-STABLE whose presence can be disruptive,
but are not removed by a binary upgrade. One notable example is
that an old
to compile incorrectly (or not at all).
Re: (Score:2)
Just a warning for those thinking, "how bad could it be??"
Re: (Score:2)
Re: (Score:1)
I'd also be really careful with mergemaster.
Much of
Maybe tar up
Re: (Score:2)
Re: (Score:1)
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
Re: (Score:3, Interesting)
I know 4.11 was probably the most stable operating system I've ever used, but I'd recommend a wipe and reinstall (and if you have your non-OS stuff in its own partition, of course, it's always easier).
Of course, it's not necessarily dangerous to stretch out your 4.11 installations for another year or two, if you'll commit to keeping your ported software upgraded, even if via hand ins
Re: (Score:2)
The other big gotcha -- and something that eventually caused me to drop FreeBSD -- is that large drives are not supported on many common controllers. They'll show up as available and you can certainly write to them, but at some point you'll start getting bogus DMA timeouts. The hardware that worked fine in 4.X began failing in 5.X/6.X. The response from so
Thanks everyone (Score:2)
Tha
annnd, now it's official (Score:1)
Date: Jan 15, 2007 12:29 AM
Subject: [FreeBSD-Announce] FreeBSD 6.2 Released
To: freebsd-announce@freebsd.org
So, wow, Slashdot was only an hour and eleven minutes ahead of the announcement.
If you're not on the announce mailing list, the full text should appear at this URL soon: http://www.freebsd.org/releases/6.2R/announce.html [freebsd.org] -- not yet working as I write this!
But... (Score:1)
*runs*
Re:But... (Score:5, Informative)
*runs*
Re:But... (Score:4, Informative)
When the ELF loader sees the Linux brand, the loader replaces a pointer in the proc structure. All system calls are indexed through this pointer (in a traditional UNIX system, this would be the sysent[] structure array, containing the system calls). In addition, the process is flagged for special handling of the trap vector for the signal trampoline code, and several other (minor) fix-ups that are handled by the Linux kernel module.
/compat/linux/original-path directory, then only if that fails, the lookup is done in the /original-path directory. This makes sure that binaries that require other binaries can run (e.g., the Linux toolchain can all run under Linux ABI support). It also means that the Linux binaries can load and execute FreeBSD binaries, if there are no corresponding Linux binaries present, and that you could place a uname(1) command in the /compat/linux directory tree to ensure that the Linux binaries could not tell they were not running on Linux.
The Linux system call vector contains, among other things, a list of sysent[] entries whose addresses reside in the kernel module.
When a system call is called by the Linux binary, the trap code dereferences the system call function pointer off the proc structure, and gets the Linux, not the FreeBSD, system call entry points.
In addition, the Linux mode dynamically reroots lookups; this is, in effect, what the union option to file system mounts (not the unionfs file system type!) does. First, an attempt is made to lookup the file in the
In effect, there is a Linux kernel in the FreeBSD kernel; the various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, System V IPC, etc... The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux binaries get the Linux glue functions (most older OS's only had their own glue functions: addresses of functions in a static global sysent[] structure array, instead of addresses of functions dereferenced off a dynamically initialized pointer in the proc structure of the process making the call).
Which one is the native FreeBSD ABI? It does not matter. Basically the only difference is that (currently; this could easily be changed in a future release, and probably will be after this) the FreeBSD glue functions are statically linked into the kernel, and the Linux glue functions can be statically linked, or they can be accessed via a kernel module.
Yeah, but is this really emulation? No. It is an ABI implementation, not an emulation. There is no emulator (or simulator, to cut off the next question) involved.
So why is it sometimes called "Linux emulation"? To make it hard to sell FreeBSD! Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was going on; saying that FreeBSD ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded--hence "the Linux emulator".
Also there is this, which is another good explanation of the differences between but support for the two OS's in FreeBSD programming.
FreeBSD is an extremely flexible system. It offers other ways of calling the kernel. For it to work, however, the system must have Linux emulation installed.
Linux is a Unix-like system. However, its kernel uses the Microsoft system-call convention of passing parameters in registers. As with the Unix convention, the function number is placed in EAX. The parameters, however, are not passed on the stack but in EBX, ECX, EDX, ESI, EDI, EBP:
open: mo
another project like that: WINE (Score:2)
Re: (Score:2)
So register-based parameter passing is now slower than stack-based? I'm not buying that.
Me neither, let's see what the stack-based sequence would actually look like:
mov eax, flags
push eax
mov eax, mode
push eax
mov eax, path
push eax
mov eax, 5
push eax
int 80h
add esp, 16 ; don't forget to adjust the stack!
Even if you wanted to play some trickery by moving the parameters directly to the proper stack frame locations instead of PUSHing them, you still need to load them into registers first (more in
Re: (Score:1)
Actually, for all practical purposes, it does. The Linux kernel is a bit iffy, but all userland Linux binaries run just fine. The Linux syscall emulation works really well.
Re: (Score:2)
FreeBSD 6.2 Released to Minors (Score:1)
I don't know what a child would have to do to deserve that.
now, did I mean that as a reward or as a punishment? Let the fanboys decide!
Re: (Score:2)
Linux ripped it off? (Score:1)
Re: (Score:2)
Re:Linux ripped it off? (Score:4, Informative)
The i386 was the first Intel chip that had the memory protection mechanisms required to run a real UNIX. Although they were released in 1985, it took some time for people to get around to porting UNIX to run on them. It wasn't until around 1990 that the PC was so firmly entrenched that it made sense to run Linux on such an inferior architecture; people who wanted a real computer but were on a budget got a cheap 68K machine.
Re: (Score:2)
Of course, Linux was designed for said inferior architecture.
``people who wanted a real computer but were on a budget got a cheap 68K machine.''
Do the 68Ks actually have MMUs? Or are they separate chips in Real Computers? Any MMUs that the 68Ks may have certainly don't seem to be used in Macs...
Re: (Score:2)
They do as of the 68030. I can't speak for MacOS, but AmigaOS used the MMU a lot for nifty tricks like copying the OS ROM into RAM and then remapping it because it was many times faster.
Re: (Score:2)
Do the 68Ks actually have MMUs?
It was optional. The MC68010 was the first chip in the family to properly support one, and they were on-die on some of the later revisions (68030 onwards). Early Sun workstation (anything pre-SPARC) used a 68K, and ran a BSD-derived version of UNIX.
Any MMUs that the 68Ks may have certainly don't seem to be used in Macs...
Not quite true, actually. A/UX, Apple's first foray into the UNIX market, ran on 68K Macs and required an MMU. All of the 68030 and 68040 based Macs include an MMU, and some 68020 processor Macs have a 68851 PMMU. For a list of some of the ones with an MMU
m0n0wall (Score:1, Informative)
The next version of m0n0wall will be based on FreeBSD 6.2 release.
For the curious:
http://m0n0.ch/wall/beta-1.3.php [m0n0.ch]
Pleasantly surprised with laptop support! (Score:5, Informative)
I downloaded the netboot version of 6.2RC2 some days back and was pleasantly surprised to find that almost all the hardware was correctly recognized. This is a 2 year old compaq laptop with an Ralink PCMCIA wireless card. Not even the latest Linux distros can detect this card but OpenBSD and FreeBSD have the excellent ral [freebsd.org] driver in the kernel. Moreover the configuration is so simple when compared to the mess in Linux (iwconfig,iwpriv,ifconfig??) not to mention the troubles I had with ndiswrapper
All the BSD's use X.org anyway nowadays, so the folks who are looking for a good GUI environment won't be disappointed. Again, the laptop display settings were correctly detected and I didn't have to touch xorg.conf at all
Give OpenBSD and FreeBSD a try - you won't regret it. Having said that, prepare to actually RTFM in case you run into problems. 99% of the time the answers are in the fine integrated documentation that comes along with your OS install.
Sweet! (Score:1)
questions from a linux guy (Score:1, Interesting)
small servers, and really liked how they were well designed, clean and stable. Therefore I'd like to take a better look at *bsd (*) and probably start using it among my other linux machines. My question is: what are the general caveats for someone coming from Linux, eg. that missing or different command/device/configuration file/installation procedure, etc. In other words those simple tasks that could be made difficu
Re:questions from a linux guy (Score:5, Informative)
1. Device names are different. What Linux calls
2. Partition maps are different. Linux uses DOS (or BIOS, I'm not sure where they originate from) partition tables on the PC, and Apple partition tables on Power Macs. I don't know about other architectures. The BSDs use BSD disklabels, where each partition gets a letter (from a to z), with some letters having special meanings (e.g. a is the root device, c is the whole device). For example, if your root partition in
3. The BSDs do not implement a lot of GNU extensions. This includes library functions (e.g. there's no strndup on OpenBSD), command line switches, and makefile directives. Of course, a lot of software is shared among BSD and GNU systems, but the differences will bite you sometimes. GNU usually implements BSD extensions.
4. GNU make is usually available on BSD systems, but under the name gmake. make is BSD make, which has a different set of extensions to basic make.
5. BSD systems provide third-party software primarily through the ports system (called pkgsrc on NetBSD), although binary packages may also be available. This is not common in Linux distributions, although Gentoo mimics the BSDs in this.
6. There is generally a higher focus on source code. For example, upgrades are typically performed by first getting the latest version of the source code through CVS, and then running "make world".
7. The BSD startup scripts are usually much simpler than those found on Linux distributions, which typically use SysV style init scripts.
8. The BSDs consist of a complete operating system that is maintained as a single unit, whereas, with Linux distros, the kernel, libc, core utilities, etc. are usually maintained and upgraded independently.
9. The BSDs pride themselves on technical quality and good documentation, whereas GNU/Linux is heavier on features and making things work _today_. Complaining about missing features, or asking questions without having read the documentation is likely to rub BSD people the wrong way. Be especially careful with OpenBSD developers.
10. The BSDs have traditional, monolithic kernels. All have some features available as loadable modules, but the modularization is definitely not strong as in Linux. Stability is considered more important.
11. The choice of filesystems is more limited on the BSDs than it is on Linux. All support Berkely FFS, as well as some variations on it, fat, and ext2, but there's no ReiserFS, JFFS2, QNX fs, etc.
12. Among the BSDs, NetBSD focuses on clean code and portability, OpenBSD focuses on security, and FreeBSD is the most featureful. Dragonfly BSD is a fork of FreeBSD that aims to provide a more modern architecture with a microkernel and without the Big Kernel Lock. There are some others, too, but I don't know what they're about.
Just to put this information in perspective: I've used GNU/Linux since 1996, and OpenBSD for about 5 years. My experience with NetBSD and FreeBSD is only sporadic. I've also created ports for OpenBSD and NetBSD, as well as developed quite some new software for them. If you count Mac OS X as a BSD, I've got about 2 years of experience with it, including the creation of pkgsrc ports for it.
Thank you! (Score:2)
If you haven't before... (Score:4, Insightful)
I've also noticed how much the comments attached to this article are riddled with trolls, flamebait, and assorted rubbish. Richard Stallman was the first to slander the BSD license and attempt to discourage its' use, and it is obvious that there are Linux users who seek to continue their master's work in that regard, and shame themselves in the process. They tell people a lot more about their own character (or lack thereof) than about that of what they are attacking.
Re:If you haven't before... (Score:4, Insightful)
BSD-like licenses do not prevent your competitors from taking your contributions, improving upon them and keeping the improvements for themselves, turning what you did as open-source into closed-source/proprietary stuff, even using it to compete against you. If you are bigger than other fish, investing in BSD makes more sense.
GPL-like licenses, on the other hand, would require your competitor to release its improvements keeping the field level. If you find the ideals behind GPL attractive, you will also feel more comfortable that improvements on your work will not become proprietary software. If you are smaller than most of the other fish, GPL makes more sense.
If we (as a company) were to invest a given amount of resources in an improvement we did wish to keep to ourselves and eventually sell, we could choose a project that had a BSD-like license. If, however, we wanted to use that improvements to foster an ecosystem where no one should gain much advantage over us, we would choose a GPL-licensed project.
They are tools. You pick the one that makes sense.
FreeBSD on laptops? (Score:2)
Re: (Score:2, Informative)
Re: (Score:1)
Re: (Score:3, Funny)
I don't know exactly how things work for FreeBSD, but with OpenBSD, it's like this: the OpenBSD team develops and maintains the whole operating system, consisting of kernel, libc, commands, compiler, documentation, X, etc. When you install, you get to choose sets: bsd, main, comp, etc, games, and so on. Some of these are mandatory, others are optional. This allo
Re: (Score:2)
cd
make buildworld
make buildkernel
make installkernel
make installworld
reboot
how much life does 4.x have left? (Score:2)
Re: (Score:2)
Yes: two weeks from now [freebsd.org].
Re: (Score:2, Funny)
Re: (Score:2)
Is there a point to your at least pedantic, and at most douchebaggy, comment about the difference between x86 and IA32?
one could also ask the same thing about your comment.
Re: (Score:2, Insightful)
Re:x86 compatible? (Score:5, Funny)
Re:x86 compatible? (Score:5, Funny)
Re:x86 compatible? (Score:5, Funny)
Yeah, I had the turbo switch fixed and everything...
Re: (Score:2)
Re: (Score:2)
http://elks.sourceforge.net/ [sourceforge.net]
Re: (Score:3, Informative)
Thank you captain pedantic (Score:3, Insightful)
There's no point in breaking down support by specific chip level unless you
Re: (Score:2)
You're thinking of NetBSD that claims to run on everything, not FreeBSD
Re: (Score:1)
Re: (Score:1, Insightful)
Re: (Score:3, Funny)
Re:*BSD is Dying (Score:4, Funny)
"I'm not dead yet!"
"I'm getting better!"
"I don't want to go on the cart!"
Re:Installed it this morning (Score:4, Informative)
Benefits of csup (Score:1)
Re: (Score:3, Insightful)
Re: (Score:2)
Thank you! I just found out about portsnap after reading your comment.
I remember reading about portsnap on the install docs, but for some reason I ended up using cvsup instead...
It was definitely a happy discovery. It makes the update go from several minutes to a few seconds, and has to be easier on the update servers, too.
OTOH I did not find about portupgrade until few weeks after I started using FreeBSD (which I regret).
Don't regret it! You may not always find yourself on a machine that has portupgrade installed.
Portmaster (Score:3, Interesting)
Embarrassed (Score:1)
Re: csup (Score:2)
To elaborate
CVSup [cvsup.org] is *the* way to update the software and the OS on FreeBSD. You keep your
It is a great tool, and really the only downside to using it is that it was written in Modula-3. Building CVSup from sources required a *lot* of time and was unnecessarily c
Re: (Score:3, Interesting)
Re:I noramlly check Distrowatch.com (Score:5, Insightful)
Yes, it's very nice
Mac users use it,
No they don't, they use Mach with a BSD api wrapper
Solaris is based around it,
No it's not, Solaris was on the SysV side of the SysV/BSD Unix wars (not a bad thing, Solaris is nice too)
and most of Linux is a cheap ripoff of it.
No, Linux is a school project based loosely off SunOS & Minix
Re: (Score:2, Insightful)
Re: (Score:2)
No they don't, they use Mach with a BSD api wrapper
Actually there is more BSD code than that. Mach provides the basic kernel infrastructure, but a few of the Mac device drivers are FreeBSD derived and large portions of the networking stack. Apple entirely replaced other sections of FreeBSD though, e.g., the USB stack.
and most of Linux is a cheap ripoff of it.
No, Linux is a school project based loosely off SunOS & Minix
Lets ignore the cheap ripoff part... and that Linux has its
Re: (Score:1, Insightful)
SunOS 2.x / Solaris is SysV.
And Solaris, like every other UNIX/UNIX-like system I've ever used has it's pros and cons.
Cons would be the really shitty user land, though it improved dramatically in Sol 9.
I also don't like pkg* much, and the installer just plain sucks in too many ways to mention.
Nice things...
Zones are very nice, lacking a few things, but still very handy.
Stability, Solaris on SPARC boxes is about as stable as it gets, save perhaps for mainframes.
Binary compatibility is also
Re: (Score:1)
The machine is sort of wonky, too. I wonder if FreeBSD would be a happy camper on it.. Maybe I'll give it a try
Re: (Score:1)
Re: (Score:2)
FreeBSD is the only distro I found that supports the embedded AMI megaRAID controller "out-of-the-box".
small correction: FreeBSD is not a "distro", it's a full blown OS.
Re: (Score:2)