



FreeBSD 5.2 RC2 Now Available 301
Dan writes "FreeBSD Release Engineering Team's Scott Long announces the availability of FreeBSD 5.2 RC2 which fixes a number of bugs, specifically the one in which users experienced system panics during install and dynamic library problems in the 'fixit' environment. Scott is asking everyone to test this release over the holidays. You can download it from one of your preferred mirror sites." Update: 12/24 23:01 GMT by T : Dan writes with more info: "Scott Long has also laid out a roadmap for future FreeBSD 5.3 releases now that FreeBSD 5.2-RC2 is getting close to release quality."
Crossing my fingers (Score:0, Offtopic)
Pre-emptive troll Strike! (Score:0, Troll)
It's dying!
It's dying!
It's dying!
It's dying!
There... feeling better, little trolls? I know you would!
This being out of the way, kudos to all the FreeBSD developers for all the good work -- it's a nice Christmas present!
Re:Pre-emptive troll Strike! (Score:2, Interesting)
Indeed, the developers have done alot of hard work making FreeBSD an excellent OS. I've been using 5.x since it came out and have few complaints. Even for a developer release I've found 5.x to be rock solid, with high quality in mind, and quick time to fix any problems that do come up (mostly port maintainers keeping up with 4.x->5.x changes :)
Re:Pre-emptive troll Strike! (Score:2)
OK, I'll bite (Score:5, Funny)
It's dying!
OK, It's so much that it's dying .... it's that all these companies like SCO are able to keep living by forking off endless proprietaty code for themselves because the FreeBSD license allows it. Do a "strings" command on any SCO binary and you'd be amazed how much similar stuff they have to the FreeBSD equivalents. (what's even more amazing is that for all that copying you'd think they'd be able to make SCO stable)
Unpopular Freedom (Score:5, Insightful)
In the words of Theo de Raadt:
As opposed to the the GPL, which exists as Stallman's attempt to redefine "Free Software" as any software that suits his political ideology.
The GPL as a strategy is fine, but to call it "freedom" is less than honest. Whose freedom is being protected by the GPL? The developers? Not really. The developers are only allowed to use the source as long as they conform to the RMS ideology that the work they do should benefit the collective and not necessarily just the individual who wrote the software. As for the users, what freedom do they gain by using GPL software over BSD licensed software? The freedom to use software that does not co-exist peacefully with others? The freedom to view the source code they don't understand or care to understand? Besides, the original BSD software always remains free as in speech and beer, even if the Hated Proprietary Software Vendor of the Week exercises their right to protect their own interests.
I'm certain that I'll be moderated as a troll, but this something that I've been pondering quite a bit lately, and I'm certainly willing to be proven wrong.
Re:Unpopular Freedom (Score:1, Insightful)
The author's freedom. The author chooses the license under which he makes his software available, remember?
Re:Unpopular Freedom (Score:5, Insightful)
Re:Unpopular Freedom (Score:0, Insightful)
they are free to use the code without otherwise arranging a license.
smells like trolls around here
Re:Unpopular Freedom (Score:1)
Re:Unpopular Freedom (Score:0)
I'm glad we got that out of the way, especially since my baby mulching machine is nearing readiness for beta testing. Any beta testers out there? http://babymulch.sourceforge.net [sourceforge.net]
Re:Unpopular Freedom (Score:5, Insightful)
A fairer perspective is that the BSD License and the GPL represent competing political ideologies, your assessment is a loaded one. Is the BSD a 'more free' license? Likely. Is it a better one for it? Debatable. 'More free' is not necessarily always better, crying 'fire' in a crowded theatre for example. From this non-developer's perspective, proprietary software will always live in conflict with OSS - SCO as another example - and the BSD license gives companies the means to do BSD harm. They take without giving. The GPL might be less free and, by forcing cooperation, the better for it and the future of the software under its wing.
Re:Unpopular Freedom (Score:2)
And that may very well be the case, but the problem I'm having is that it's being done under the banner of "Freedom", which "forced cooperation" certainly does not mean. Perhaps, instead of "Free Software", it should be renamed, "Cooperative Software", but even that's a misnomer, since GPL software often is unable to really cooperate with anything other than other GPL software consistently and predictably.
Re:Unpopular Freedom (Score:0)
As a non-developer perhaps you need to look into the SCO history.
SCO used to be a GNU/Linux company called Caldera. Caldera took the IPO money made when they offered a GNU/Linux product and bought the UNIX(tm) code via buying SCO. Before SCO had UNIX(tm), Novell had UNIX(tm). And before Novell, USL had UNIX(tm). Back when USL had UNIX(tm), they took code from Berkeley, removed the copyright notices of Berkeley and put on USL copyrights.
Now, somehow from these known facts you've come up with:
BSD license gives companies the means to do BSD harm.
The 'harm' to BSD was the ACTUAL theft of the code.
forcing cooperation
From http://www.m-w.com/cgi-bin/dictionary?book=Dictio
"association of persons for common benefit"
Why should anyone sign up for a FORCED association? Yet, this 'force' isn't all that effective, given the number of posts on slashdot telling of companies/people who are accused of violating the GPL.
Re:Unpopular Freedom (Score:3, Interesting)
This is one of the big flaws I find with GPL logic. Information should be free because it is an endlessly renewable resource. However we can't just let the information be out there without a license because some evil company might do it harm!
Re:Unpopular Freedom (Score:4, Interesting)
Allowing freedom includes allowing people to do things you don't necessarily agree with. I used to defend the GPL consistently, but I'm starting to feel like "Free as in Speech" should also include unpopular speech, and that's what the BSD license protects that the GPL does not.
I think you're working off the false premise that copyrights are not an inherent restriction of peoples freedom. The GPL solves this problem by "fighting fire with fire" the FreeBSD license doesn't.
The logic is sorta similar to ..."I think people should be free to own slaves".
The FreeBSD license disreguards that copyrights "the right to restrict what other people copy that is at their disposal" is inherently biased as anti freedom to begin with.
Re:Unpopular Freedom (Score:2)
Re:Unpopular Freedom (Score:4, Insightful)
It assures that improved or modified code is cycled back into the community for their benefit, rather than locked away as some proprietary binary.
Re:Unpopular Freedom (Score:2, Insightful)
The original developer loses nothing, of course, unless he/she foolishly assigns the copyright to the FSF, in which case the code becomes even LESS free, because then it is owned by a third party, and is only available under very strict licensing. Doing so simply helps the FSF grow its suite of free software that is only available under the GPL. I suppose it's a noble goal, but the fact is it is just another company with strict licensing rules, although they include the benefit of being open source.
On the other hand, the BSD license doesn't guarantee much of anything for the developers, and it's sad in a way that it's so easy to use the code w/o giving anything to the coders. And I suppose that's where the GPL comes in; if you feel that your free contributions should only be available to those who are willing to make more free contributions, you should use it.
There is no question that the BSD license is more "free" than the GPL. But there is the issue of whether the GPL perpetuates more (a greater amount of) "free" code overall than does BSD. I think the GPL is quite useful in that sense.
-Dan
Re:Unpopular Freedom (Score:2)
Why is it sad? And who say's I don't get anything out of writing BSD licenced code?
Let me try to explain using the economic term "utility". The concept of utility is a measure of happiness or satisfaction.
I could go on and on about this. But suffice it to say... I love writing code. I do. It gives me one hell of a buzz. Whether it be a PHP website, a quick Perl script, or mission critical application in C. Once it's written I really don't care. For me it's the journey, not the destination, which is important. If I am able to release my code I simply slap a BSD licence on it and forget about it I really don't care what happens next - I've gained all the utility I care about.
And there is nothing sad about that.
Re:Unpopular Freedom (Score:2)
Ok lets burn some karma here
Allowing anyone to reuse code does not nullify the achievements brough about by the code. That is unless your objective is non technical like Stallman's.
Much BSD code has been reused by commercial products. Its a governemnt research project. A government setup by fans of Adam Smith. As such they set forth laws and precedents to encourage capitalism. This eventually evolved into government funding in research and universities that encouraged making technology available to corporations for them to make a profit. This is partially how BSD came about. Remember Berkley is a State school.
One of their objectives was that corporations would steal their code, make better OSes, and cause the American dream of aqquiring lots of nice shiny things to be achieved.
I personally use both Linux and BSD. Here is what I've observed. Decentralized development like Linux gives us innovation. The bazaar model gives you the most options. Thats why Linux has drivers for a zillion file systems, KDE and Gnome are so robust, and linux is the flagship platform for so many projects. However, the Cathedral model excells at polish. Thats why Linux Distros tend to use the Cathadrel approach. Debian and Gentoo being notable exceptions. Most distros have a central authority directing a team of developers to track a set of packages and maintain installer and configuration tools.
Reality is a harsh bitch-goddess mistress. (Score:0)
Now this would be the company that took stock market IPO money from its GNU/Linux offering and bought the USL code. The same USL that had chunks of BSD copywritten code in the USL tree where the USL people removed the BSD license and copyright and put on USL copyrights?
Your 'statement' ignores the past. But if it helps you feel better about yourself, keep thinking BSD licensed code is somehow evil, ok?
More like son-of-BSD (Score:5, Insightful)
The current BSD's are like the children of the original, taking on the family business.
BSD is like the late, great, patriarch, whose portrait hangs on the wall, in the living room of the family mansion.
Re:More like son-of-BSD (Score:1)
Re:More like son-of-BSD (Score:0)
Netcraft confirms: *BSD trolls are dying (Score:0, Funny)
Fact: *BSD trolls are dying.
Re:Pre-emptive troll Strike! (Score:1)
Status of FreeBSD 5... (Score:5, Informative)
That means that the next two releases on the 5 branch are going to be last times new features are added to the branch before -current forks, so it's going to require a lot of testing to ensure stability.
Why do you care?
Well, if you don't ever plan on using FreeBSD, you don't. If you do use FreeBSD, tossing this release on your hardware and making sure things like ACPI function with your motherboard are really important as NOW is the time to fix them so that they can be tuned and maintained prior to the 5.3 Release when the code is marked stable.
The major changes in FreeBSD 5 are significant. There's new locking throughout the tree, which should improve SMP performance everywhere. There's also finer grained locking in the Network stacks (thanks Sam), better ACPI (thanks John), support for AMD64 (coming slowly, thanks Peter), and the GEOM disk abstraction layer (nice work PHK), which has already been shown to be useful for things like GEOM-gate (a la nbd in Linux), is getting more mature with every release.
Performance and stability
Status of pf, NAT, etc? (Score:1, Interesting)
What's the status of pf on FreeBSD? And what's the preferred packet filtering/firewall setup these days?
The last I checked, circa 4.8, you had to recompile the kernel just to get a NAT "router."
Has NAT-ing and filtering drawn any attention in the 5.x series?
I ask because FreeBSD has about the best host adapter/hard drive support in the business [possibly better even than NetWare] - if you've got an old hba and an old hd, FreeBSD will load the drivers and do the LBA translations to perfection. I've seen countless motherboard/HBA/HD combinations where e.g. Windows 2000 just can't get the LBA translation right. Or OpenBSD, for that matter.
Which brings me to the question of Theo. Since I'm interested in NATing/PFing/SSHing, most people would say, "Then you want OpenBSD," to which I say, Yeah, some of Theo's goals are laudable, but, quite frankly, the guy's a kook, and guts of his operating system don't work all that well.
I'd rather use something designed by grown-ups.
Re:Status of pf, NAT, etc? (Score:1, Informative)
'ipf/ipnat' are available with kernel options.
'ipfw/natd' are available by loadable modules without recompiling the kernel.
Re:Status of pf, NAT, etc? (Score:5, Informative)
One of the goals for 5.3 (and indeed something that Sam has been doing some wonderful and hard work on) is cleaning up the IP stack. Getting IPFW pfil(9) ready (if I understood correctly) is also one of these goals and will mean that using any software firewall solution such as pf, IPFW or ipfilter would be a question of loading the module. At which point you wouldn't have to recompile the kernel for this functionality.
But this is a 5.3 goal and will not be present in 5.2.
Hope this was of help.
Re:Status of pf, NAT, etc? (Score:2, Interesting)
One of the goals for 5.3 (and indeed something that Sam has been doing some wonderful and hard work on) is cleaning up the IP stack. Getting IPFW pfil(9) ready (if I understood correctly) is also one of these goals and will mean that using any software firewall solution such as pf, IPFW or ipfilter would be a question of loading the module. At which point you wouldn't have to recompile the kernel for this functionality.
Hope this was of help.
I can't tell you how welcome this sort of functionality will be. I know I'll get flamed for this, but some of us out here in the real world just don't have the time to spend a couple of weeks trying to recompile a kernel. [And no, it's obviously not the actual compile time - it's the fiddling: What happens if I set this flag? What happens if I don't set that flag? Oops, that didn't work - maybe if I were to change that to this... Getting the configuration just right can take nigh unto forever.] Loadable modules for filtering, NATing, and SSHing will be MOST appreciated.
Thanks, and keep up the good work.
PS: If I can be a little greedy, the other thing that really benefits a firewall-ish device is rock solid support [i.e. drivers] for hardware-accelerated encryption [SSL, SSH, and the like]. Of course, rock solid drivers are one of FreeBSD's fortes, but if you're redesigning the stack, I'd just say: Redesign it with hardware acceleration very much in mind.
Re:Status of pf, NAT, etc? (Score:2)
Huh ?
Your default install kernel has been compiled from GENERIC, too. Copying GENERIC to MYVERYOWNKERNEL, inserting option "IPDIVERT" somewhere and remaking that is a matter of about 10 minutes (less on a fast machine)
You dont have to write your kernel file from scratch...
pf/nat (Score:2, Interesting)
1. Cannot dynamically reload rules of ipfw (your connection can be broken after a flush, and before new rules).
2. Poor (really no) integration of natd/ipfw.
3. Weaker rules/macros than pf.
The FreeBSD pf port [love2party.net] is coming along nicely. I am currently using it with a kernel loadable module and a startup script, both of which are installed by the port. You do still have to recompile the kernel:
You need these options:
"device bpf" and "options PFIL_HOOKS"
The port will tell you to do this when you install it. My transition was very easy, and immediately I was happier with pf. I had never used it before, and I prefer it immensely. I use it to do firewalling and NAT, and they are integrated, of course.
So, I'd say the status is...good! I'd prefer not to have to rebuild the kernel, but I'm used to that by now.
-Dan
Re:Status of pf, NAT, etc? (Score:1)
i'm using 4.9 and i never had to recompile to get my nat box working. I'm using the ipf / ipnat combination, and they were already installed. I just had to configure them, and put it in the starup scripts. The recompiling part is for purists who would rather have them in kernel vs. loading them as modules. For noncritical work, modules are fine. I looked into ipfw / natd, but the configuration is too nasty. ipf/ipnat is in comparison so much simpler.
The freebsd handbook *always* wants you to recompile. That's not the case if you just want to use the modules.
stability, THEN release (Score:3, Interesting)
Shouldn't this read something like:
NOW is the time to fix them so that they can be tuned and maintained so that the 5.3 Release can be marrked stable.
In other words, the code should be marked stable when it IS, rather than at some arbitrary release level.
Re:stability, THEN release (Score:0)
The issue is that there may be hardware that is unstable with the current release, but without testing, that's unknown. Therefore, it's likely that it will be marked stable when all of the known bug reports are in, and at some later time, someone will show up with untested hardware that has bugs.
Again, -STABLE is _NOT_ the most stable. (Score:5, Insightful)
But yes, thanks to the developers who have been working on this. And thank heavens that it's the holiday season; now I'll finally have time to work on locks in the IPv6 stack (thanks Sam and Robert
Re:Again, -STABLE is _NOT_ the most stable. (Score:0)
RELENG, as you're talking about, is nearly immutable. The only fixes are for security/stability. Sticking with, say, RELENG_4_9, is like picking kernel 2.4.23, and staying there, only applying patches that are absolutely necessary. So you have, say, 2.4.23p4 instead of jumping to 2.4.25 (or whatever).
Re:Again, -STABLE is _NOT_ the most stable. (Score:0)
And less is more, more is less. We have always been at war with Oceana.
Re:Again, -STABLE is _NOT_ the most stable. (Score:0)
I re-iterate. -STABLE is *NOT* the most stable branch. It is not comparable to 2.4 in Linux.
Then what is? I know! 3.3-RELEASE!
Re:Status of FreeBSD 5... (Score:4, Interesting)
I recently deployed 5.1 on a Toshiba Satellite Pro 4208XDVD and an older IBM Thinkpad 600X. Neither of them correctly probed my Cardbus controllers without specifying the size of allocated memory to the controller. I also had difficulty once the controllers came up, in that none of my wireless cards would work. (Orinoco Gold, MS Wireless Broadband Adapter)
Has anyone else had Newcard difficulties with the FBSD 5 release train? I've read of quite a few workarounds to get Cardbus working correctly. I have yet to recompile a new kernel removing Newcard - is it worth it altogether?
Merry Christmas Slashdot!
-Pat
Re:Status of FreeBSD 5... (Score:0)
Sorry I think I'm going to be sick..
Re:Status of FreeBSD 5... (Score:0)
It's likely that it works, but you have to make some subtle change somewhere.
Re:Status of FreeBSD 5... (Score:1)
Opteron 64-bit support? (Score:4, Interesting)
And yes, before the Linux hordes flames me to death, yes I know that Linux kernel does have Opteron support and has been more or less 64-bit compatible since the DEC Alpha days.
I'm talking about the distribution. I am considering buying a dual Opteron in January but all the Linux distros seem to be betas. A quick search on Google reveals that the distros have serious problems. In particular, X doesn't work and compilers fail completely.
FreeBSD reports Opteron as tier-1 hardware, so how is it?
Re:Opteron 64-bit support? (Score:5, Informative)
AMD64 Porting
Contact: Peter Wemm
The last known bug that prevented AMD64 machines completing a full
release has been fixed - one single character error that caused
ghostscript to crash during rendering diagrams. SMP work is nearing
completion and should be committed within the next few days. The SMP
code uses the ACPI MADT table based on John Baldwin's work-in-progress
there for i386. We need to spend some time on low level optimization
because there are several suboptimal places that have been ignored for
simplicity, context switching in particular. MTRR support has been
committed and XFree86 can use it. cvsup now works but the ezm3 port
has not been updated yet. The default data segment size limit is 8GB
instead of 512M, and the (primitive) i386 binary emulation support
knows how to lower the rlimits for executing 32 bit binaries.
Notable things missing still: Hardware debug register support needs to
be written; gdb is still being done as an external set of patches
relative to the not-yet-released FSF gdb tree; DDB does not
disassemble properly; DDB cannot do stack traces without
-fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64
linux binary emulation is needed, and the i386 FreeBSD binary
emulation still needs work - removing the stackgap code in particular.
The platform in general is very reliable although a couple of problems
have been reported over the last week. One appears to be a stuck
interrupt, but all that code has been redone for SMP support.
Re:Opteron 64-bit support? (Score:2)
Re:Opteron 64-bit support? (Score:1)
Re:Opteron 64-bit support? (Score:0)
I know it is stable, because I use one
Buy a system based on AMD (AMD 8000) or VIA (K8T800) chipset, and I think you will be fine.
I use Gigabyte GA-K8VNXP (VIA K8T800), Athlon 64 3200+, 512 MB Kingston KVR400X64C25/512 DDR400, Seagate 120 GB 8 MB Cache ATA 100 hard drive, CD Burner, DVD Drive, Radeon 7000 Video card etc.. And I use SUSE 9 for AMD64 distribution.
I have stress tested this system from both CPU, Memory and IO point-of-view (under both SUSE's 2.4.x kernel and custom 2.6.0-X8664), and I have not seen a single System stability issue. As for XFree86, the open-source radeon kernel DRI driver supports my card. I play TuxRacer with no problem
Refer some of these URL's and read users' feedback, before make up your mind:
http://www.x86-64.org/mailinglists
http:/
The RedHat RHEL products support AMD64 platform. When Mandrake 9.2 for AMD64 will be released, I expect it be good. (I think a Fedora based distribution is in the make. I hear both Debian and Gentoo AMD64 distributions are in the make too.)
IOW you need to get the right components then you will be fine. My advise is that do not buy a system where you need to use closed source (binary only) kernel drivers, that will spoil your Linux experience. IOW buy a system where everything works out-of-the-box from kernel.org's and x86-64.org's kernels (2.6.0 for eg..)
All the best.
Hari.
Try it today! (Score:2, Funny)
Anybody who hasn't tried 5.2 RC2 yet is really in for a treat...
Re:Try it today! (Score:1)
Hmmmm (Score:2)
Re:Hmmmm (Score:0)
Re:Try it today! (Score:2)
Experienced user panic during install? (Score:3, Funny)
> experienced system panics during install
I wonder how they expect anyone to actually use an operating system whose installation procedure makes experienced users panic... Oh, yeah; I forgot. It's open source.
Re:Experienced user panic during install? (Score:2)
mspaint (Score:2)
Perhaps not, but remembering that mspaint still exists might be a qualification in itself. That program seems as ancient as dosshell these days.
Re:mspaint (Score:2)
XP still comes with Program Manager (\WINDOWS\system32\progman.exe)
test the release over the holidays ? (Score:2, Funny)
Re:test the release over the holidays ? (Score:0)
Sit down with the extended family?
No friggin' way!
Do the testing for the developer? (Score:0)
Is this an example of copying the Microsoft practice of having the customers perform the actual testing?
Re:Do the testing for the developer? (Score:0)
Re:Do the testing for the developer? (Score:1)
This is open source. You know, where we all help each other to make a better product? Unlike Microsoft, where you pay THEM to test THEIR product and then you get NOTHING in return.
If you don't want to support this project, then don't. It's as simple as that. Just don't come here comparing us (the open source community) to Microsoft.
Better jail support (Score:3, Informative)
What I really wish for is private Sys V IPC and multiple IP's for jails to be available as standard features. Currently, there are some patches [freebsd.pl] out there, but they seem outdated.
Re:Better jail support (Score:1)
I'm not trying to start an argument, just curious
Re:Better jail support (Score:1)
New Technology Release (Score:0, Redundant)
Re:New Technology Release (Score:0)
FreeBSD 5.2 RC2 (Score:0)
Anyone know ... (Score:1)
If anyone knows if this has been resolved, I'll probably update my box from 5.1 to 5.2-RC2 tonight.
As a side note, I'm curious as to what ports are broken, I've yet to encounter one that I can't compile under 5.x, including all the things I used to run under 4.x/3.x/2.2.x (yes i've had the same FreeBSD box that long)
Re:Anyone know ... (Score:0)
Re:Anyone know ... (Score:1)
I can't find a good link now, but I read somewhere that the GENERIC kernel was going to be made SMP by default. Therefore, you may want to save some overhead and recompile your kernel without the SMP.
FreeBSD 5.x (Score:1, Interesting)
The background fsck saved me a couple of times before I got UPSs for them, and the new GENERIC SMP kernel will be great once I get my new dual Opteron.
All in all FreeBSD is doing great, and I'll never go back to Linux; there's no incentive, nor need.
RedHats off to the BSD guys. (Score:2, Interesting)
Re:RedHats off to the BSD guys. (Score:2)
Did you try Slackware? It runs on the lowest end of the hardware spectrum; has everything you need for a base system and then some, pre-packaged in tgz format; is easy to customize; and stable as hell.
But really: what happened to love and peace? Y'know, BSD and Linux (or GPL, depending on point of disagreement considered) can coexist: BSD is Good, Linux is Good, and yay 4 us.
Re:RedHats off to the BSD guys. (Score:0)
Then again, I've seen this post many times before, just a silly troll trying to bash BSD. In fact, the "despite the BSD machines chip architecture"... umm... I thought this was about an OS, so what does the chip have to do with it? I mean, my P2/350 with 128MB runs *far* better running NetBSD than it ever would running windows.
Sux0rs (Score:0)
In a startling turn of events today, a previously little-known fact came into the public eye: "*BSD Sux0rs". This came as a complete surprise to the BUWLA, or BSD Users With Large Assholes, as they previously thought that *BSD 0wned.
"You see, even though I have never contributed code to any BSD project, I thought it was my duty to be a big asshole to others which don't use the OS I do, because it just 0wnz.", said one FreeBSD user. "Now that I know it sux0rs, though, I have to go find something else to be an asshole about."
One notorious OpenBSD fanatic known as WideOpen, told reporters, "I have to kill myself. This isn't how it was supposed to happen. My BSD has always been the best, and shouting that opinion in other people's faces at every chance I got has been my only hobby. It was all I ever did. It was what got me out of bed in the morning. Now I have to die. I will jam my bedpost up my ass until I hit my brain. It is the only way to go: BSD style."
In the volatile world of operating systems anything can happen. "At least we don't sux0r as much as Windows users", BigAzz, a relatively well-known NetBSD user said. "Screaming things in people's faces is my calling. Now I need to scream that BSD sux0rs. What a sad world. At least I won't kill myself like those uber-asshole OpenBSD guys. They are just way over the top. Or were, at least."
Nobody knows for sure what the future holds for the state of operating systems, but with Netcraft confirming the sux0r status, *BSD users all over the world will have to stick something else up their asses from now on or risk looking even more gay than they used to.
ATA RAID Solutions for FreeBSD 5.x (5.2+)? (Score:3, Interesting)
I've recently switched from Debian Linux to FreeBSD 5.2. I was running a pair of RAID-1 arrays off a Highpoint HPT372 RocketRAID 133 [highpoint-tech.com] controller using Highpoint's rather lackluster, "open source" driver. Of course, contacting them about FreeBSD support greater than 5.0 has yielded nothing useful, so now I am on the hunt for other solutions.
I've come across offerings from 3ware [3ware.com], notably the 7006-2. What caught my eye about this card (well, all of them from 3ware) was that it's actually a hardware-based ATA RAID adapter (where as RAID functionality is implemented in software for most ATA controllers out there). Does this mean that I can use this card without any driver hell? Will a RAID-whatever array simply appear as another /dev/a[dr]* device or is it not that simple? (By the way, I care little about CLI tools for rebuilding the array. I am content to use the card's BIOS to do management.)
Of course, if I can solve the problem with my Highpoint, that'd be useful too. Currently, if I create a RAID-1 array, the two real disks appear as /dev/ad4 and /dev/ad5 but I also get a /dev/ar0 device. However, if I simulate a disk failure, none of the devices appear. It appears to me like FreeBSD indeed supports the RAID functionality of this card out of the box, but a bit of minor tweaking is required.
The bottom line however is I wouldn't mind buying a a RAID adapter with functionality implemented in hardware. That'd be better overall. I just want to make sure it'll work with flying colors in whatever OS I choose to use.
Re:ATA RAID Solutions for FreeBSD 5.x (5.2+)? (Score:1)
If you are looking for ultra-cheap solution, or have one of these promise cards built into a mobo (as in my case), and you are more concerned with data integrity/redundancy than with 100% uptime, this card is definitely servicable.
Good luck...
umass driver changes, RAID, and USB 2.0 (Score:2)
However, USB 2.0 (EHCI) is still not supported (to try it, add "device ehci" to your kernel configuration). This makes using portable hard drive enclosures under FreeBSD less than optimal, as transfers go at the slow 1Mbps of USB 1.1 instead of the much faster USB 2. No one seems to be working on ehci.c at the moment; Firewire portable drives currently seem to be a better option for support under FreeBSD.
Re:I thought you were dead! nt (Score:0, Funny)
Re:I thought you were dead! nt (Score:5, Funny)
An HP ProLiant DL140 server, apparently.
Oh wait, you've probably got a different ad...
Re:I thought you were dead! nt (Score:2)
An HP ProLiant DL140 server, apparently.
Oh wait, you've probably got a different ad...
For sex appeal, pretty much anything beats the geek I'm staring at. Apparantly he's using his UNIX experience to administer Windows Server 2003.
OT: OSDN Hottie (Score:2, Informative)
Whoever she is, I can tell she's into BSD.
Re:I thought you were dead! nt (Score:2)
Perhaps (Score:3, Insightful)
Re:Perhaps (Score:1)
Re:Perhaps (Score:0)
If you use FreeBSD unstable, you take that chance. Its the choice for desktop use, only.
BTW, if you havnt seen BSD crash, you dont use it enough. Real OS warriors will be beating the hell out of a desktop. Tinkering around doesnt cut it.
Troll (Score:0, Interesting)
I had three BSD servers that would crash (sometimes often, sometimes sporadically) quite often that I had to switch over to Linux and NT.
BSD users outright lie about the OS.
PROOF OF BIASED MODERATION !!! (Score:1, Insightful)
And you guys wonder why you get trolled so much? Maybe if you folks weren't so uptight about your operating system and could have an honest discussion of the facts, you wouldn't be in this situation. But hey, you brought it upon yourselves.
Re:Then you sir are a moron... (Score:0)
Re:What bias! (Score:2, Informative)
Calm down. We are talking about the release candidate of a development branch. FreeBSD 5.x isn't stable yet. The first stable FreeBSD 5.x release will be 5.3. Nobody says that there are major problems with the stable branch of FreeBSD.
Yet, the myriad of kernel panic issues in Linux go conveniently ignored.
This is hardly on topic in a FreeBSD release announcement.
Re:What bias! (Score:0, Flamebait)
Re:What bias! (Score:1)
Am I the ONLY fscking BSD user on slashdot without a persecution complex?
Re:OSDN Personals ? (Score:0, Troll)
I agree with this post (Score:0)
Re:10 points to upset all the BSD Zealots: (Score:3, Insightful)
On a more serious note - I'd recommend any Linux fan to give FreeBSD a shot. It took me a while to get my head around the whole philosphy behind the way things are done (just as I had to get used to Linux - its just "different" to most linux distros), but once you get used to it, its far more logical and consistant. Faster, in my experience, as well.
Even if you decide to go back to Linux, knowing BSD will put you in a better position to understand the way other Unices work, as Linux is far less similar to them than BSD.
My 2c.
smash.
Re:10 points to upset all the BSD Zealots: (Score:0)
Go back to windows you loser and stay out of our Linux community! Linux ownz you bitch and windows sucks as much ass as you do! Now fuck off!
Re:YHBT YHL HAND (Score:1)
I posted the response in case some less clueful people out there actually took it as the truth.
Which was a hell of a lot more relevant than your post.
smash.