Slashdot Mirror
FreeBSD XP^H^H 4.5 available now
The_Rift was one of many who wrote in with this news: "The official mail has gone out to the FreeBSD-announce mailing list announcing the availability of Freebsd 4.5. Check your local mirrors for the ISOs.". The release notes have all the details, but take it from me -- this one is worth it just for the TCP/IP performance improvements by Matt Dillon and others. Kudos to Murray, Bruce, and the rest of the release engineering team.
Why do you call it XP? Anyway, I recently tried to install 4.4 on my Windows XP laptop. I used Partition Magic to shrink the NTFS partition, added a couple logical partitions, and when it came time to install, found out that BSD doesn't even recognize the logical partitions. Something about "slices". Settled for SuSE (which ain't all that, IMHO) Should I reconsider FreeBSD now? I run RedHat 7.2 on my desktop. (RedHat 7.2 and Mandrake 8.1 weren't easy to set up on the laptop either)
Maybe I should really check out the FreeBSD FAQ & site & stuff, but hey, there's a lot of experts around here who can help me out, so I'll throw it in anyways:
;-)
Is it worthwhile for me to try FreeBSD now? I've already installed Win 95/98/2000, RedHat, Slackware,Suse,Debian & BeOS before and I still have an unfinished Linux from scratch install lurking around, but until now only Debian, Slack & Win 2000 stayed on long enough to make real use of them. ATM I'm running Debian w/KDE2.2 and I'm really happy with it, but hey, I still have a free 2Gig partition.
Can I run all apps/libs (or equivalents of the same quality) I use regularly now on FreeBSD? That would be KDE2.2, XMMS, OpenGL on GeForce2, MSN client, \LaTeX{}, Java1.2 a.o. Would It really bring me some extra performance/stability?
The whole FreeBSD approach does appeal to me, so I'm definitely interested in trying, but only if it has a real chance becoming my primary LILO partion
try open bsd. I am running it on my nat firewall (cable) and it runs in very modest settings. (I am running on a p100 w/32 megs ram and base install was 60 megs). You can install it from floppy disk over ISDN in an afternoon. (Look at the web site www.openbsd.org for install howto).
I love FreeBSD and wish I'd discovered it years ago instead of messing around with Linux worrying
about distribution problems but.... frankly the installer on 4.4 was buggy to say the least.
I hope they've fixed it for 4.5. It was the only thing that cast a cloud on the 4.4 release.
An OpenBSD example can help you how FreeBSD scales for your biz.
A Pentium 120 with 48 MB RAM and a total 62 MB installation. 3 legged bastion host, making NAT for 130 WEB and ICQ maniac clients, protecting the DMZ with a heavy loaded Web server inside (2 requests per second). Making stateful inspection for the DMZ.
The only part expensive is the ethernet cards used in this box. Intel Pro100S, 51$ +VAT each (here in Turkiye).
ISDN support for {Free|Net|Open}BSD is really sophisticated. It's hard to experience problems.
Regards...
Yes, in fact, I remember quite clearly when Linux 2.0 got syncookies. I'd wager 2.0.27 or 2.0.28. The syncookies implementation was totally awful. I was a pretty newbie sysadmin at the time, and whenever someone checked POP3 mail on our mailserver.. it'd warn us about sending syn cookies, and that all the students were attacking the mailserver whenever they loaded Microsoft Internet Mail.
:)
I didn't quite know what syncookies were. I just knew I didn't want them anymore after that. If it was an option in FreeBSD at that time, I would have laughed at the option, and subsequently turned it off. After other issues in 2.0.28 (was Linus drunk?), I tried FreeBSD by suggestion of my brother. Been pretty happy since.
I'm sure the issues I had have been long fixed in the Linux tree, and should be in the new FreeBSD implementation, I hope.
I'd check the CVS commits on the Linux kernel to give more precise info of the syncookies, but I can't seem to find them linked from http://www.linux.org/
Also, OpenBSD's installation process can be intimidating the first few times through. Where Free makes it easy, Open makes you think about disk partitioning and other low-level issues.
Without sounding like an elitist, (which I am clearly or qualified to be), though the instalation was a bit awkward, it was direct and forward. After getting it installed, it was VERY easy to setup the configuration. All you really have to do is follow the instructions on the website. I had a machine setup in 2 hours (downloads and all w/floppy based install), after never touching the distro before thats not bad. Within 3 hours (and another helpful howto) I had the box hardened. Before the end of a long working day I had a VERY impressive set of rules setup to block various types of traffic, I understdood the difference between a stateless and statefull firewall and most importantly I understand why all the rules in my PF config where there.
I just find it nice knowing that there OBSD crew is working overtime to help me sleep better at night. At this stage in my career, if I am using and deploying open source solutions.. my judgment and credibility is on the line. I can't blame it on Scott or Bill if something goes wrong.
Cheers
I had thought it was announced that the new Sun Authorized JDK was supposed to be in this release, but I find no information on the readme or the site?
I'm not sure how you went from syncookies to OpenBSD, but you did mention stateful inspection, so flame on!
Stateful Inspection(tm), stateful inspection, and TCP flag checks are not all the same thing. The INSPECT engine included in FireWall-1 is a dynamically-programmable state machine, capable of semi-complicated connection state tracking over a variety of connection-oriented (e.g. TCP) and connectionless (e.g. UDP) protocols. INSPECT is, in some form or another, patented. IPFILTER 's keep state clause (and IPFW's dynamic rules using the keep-state clause and the check state rule) also tracks connection state, but only for ICMP, UDP, and TCP, and it can only be changed by re-compiling the appropriate C code.
Here's the rant part: SIMPLY CHECKING TCP FLAGS IS NOT STATEFUL INSPECTION!! It's sometimes called stateless inspection and it means that a decision to pass or block a packet is decided on the characteristics of that packet alone. Allowing J. Random TCP packet to go through the firewall with a cursory check of the headers means I can do FIN or ACK scans through your firewall, and if you've got it set up to only log connection attempts, the scans won't even be logged. Suck!
As for stop denial of service attacks (aside: I hope to God I'm not the only person who has to figure out whether a person means the operating system or the network attack every time he sees those three letters), the only way to do that is to implement proper ingress AND egress filters on the gateway firewall or router. Needless to say, this is complicated, so most people don't bother.
Only you can prevent forest fires and improperly configured firewalls.
I'm proud of my Northern Tibetian Heritage
What I would like to see in freeBSD...
1. Fast boot ups
2. Ease of use
3. Better setup interface (auto probe of PC hardware, setup hardware, if no drivers for hardware install modem or NIC and download drivers via cvsup and complete setup using xserver)
4. One standard/exclusive window manager (kde, gnome, something standard)
5. One tool for window manager configuration
6. One tool for driver/software tracking and installation/removals
7. One tool for system administration (printers, servers, security, user administration, updates,etc)
I know we all want options. I believe if we have no standards for window managers and such it will hold freebsd from moving forward at the speed I would like it to.
In my option freeBSD is the best server OS out. I think taking these options into consideration would help move a lot of people to freebsd or at least give it a try.
What I would like to see in freeBSD...
1. Fast boot ups
2. Ease of use
3. Better setup interface (auto probe of PC hardware, setup hardware, if no drivers for hardware install modem or NIC and download drivers via cvsup and complete setup using xserver)
4. One standard/exclusive window manager (kde, gnome, something standard)
5. One tool for window manager configuration
6. One tool for driver/software tracking and installation/removals
7. One tool for system administration (printers, servers, security, user administration, updates,etc)
I know we all want options. I believe if we have no standards for window managers and such it will hold freebsd from moving forward at the speed I would like it to.
In my option freeBSD is the best server OS out. I think taking these options into consideration would help move a lot of people to freebsd or at least give it a try.
> Contrary to popular belief, the ports system is
> a steaming pile of horse crap. It offers little
> or no flexibility in regards to how packages
> are built,
Most ports include all the options you need as make defines. If you need more, you can copy the makefile and edit it to your hearts content, and maybe type "send-pr" and submit a patch. Or you can just compile from bog standard source and have the rest of the ports tree use it because they look for libs, binaries and executables, not packages.
> and has a nasty habit of installing
> unecassary dependencies.
Such as? It's certainly nowhere near as bad as Debian, where the entire packages system is so complex and interdependent that it needs to go through years of testing before a release is concidered stable.
> For an example, try compiling PostgreSQL on a
> non-XFree FreeBSD machine from the ports tree.
> Notice how it insists on installing XFree86.
It used to want TK, which would want the XFree libs. That's no longer the case.
> You can't pass it any configure script options > like --without-xfree or ---don't build-
> retarded-gui.
For most people flags like -DWITHOUT_X11 etc are good enough. Otherwise scratch your itch and send-pr.
> Even with RPMs I can do that. In the end, you
> usually just wind up downloading the tarball
> and compiling it yourself, which seems to
> defeat the purpouse of a Ports/ Package
> Managment system entierly.
Making your own ports is trivial, pr's usually get resolved in a couple of days, and installing from source interacts with the ports system far better than any RPM/DEB system I've seen.
Frankly it sounds like you haven't tried it in a while. Sure, it's nowhere near perfect, but what is? Certainly not a binary package system with fragile dep issues and completely unaudited sources.
Let's have a close look at the costs involved when running a Linux system.
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.