After been using the CheckPoint safe@office in a live environment for almost two month I have now decided to go back to using my homebuilt pfSense firewall.
Both firewalls have pros and cons. For me the pros of the pfSense made it for me. The biggest pros of the pfSense is definitely the speed. Even if both firewalls are able to deliver around 100 mbit/s throughput, the CheckPoint has some nasty lags sometimes, and drops the connections sometimes to IRC, MSN, ICQ and also webdownloads. Even thou I made a rule to allow all those protocols. Anyway, the biggest pros of the CheckPoint is without a doubt it’s power consumption, heat and sound level. It has a power consumption of about 15-20W compared to my pfSense which is about 60W. No heat or whatsoever from the CheckPoint either. And it makes NO sound at all, it’s fanless.
Whole article here (cyberinfo.se – 06/10/2009)
pfSense is also mentioned at the bottom of the “Enterprises cut costs with open-source routers” article on news.idg.no
Still, as some may have noticed, I have been able to work on some smaller improvements within the last few months. I now have the impression that everything is in order for a release 1.7, also considering that FreeBSD 7.2 has been released this week and should make a stable base system.
Therefore, I would like to release 1.7 as soon as I have some time on my hands. I would appreciate any comments on the recent snapshots (both i386 and amd64) from May 2nd. You can get them from here, as always:
Please understand that there is no room for larger changes such as KDE 4, new features or major bugfixes (unless critical).
PC-BSD ships with the KDE 4 desktop. The following desktop environments can easily be installed as PBI:
Download from here
The Warden/FreeBSD Jails is one of the reasons that I use PC-BSD/FreeBSD. One possible use on the desktop would be a web application developer that wants to keep all the server programs out of the base system and possibly share access with a friend you don’t fully trust. I use The Warden for a similar role personally and I like the fact that at any point I can just stop, move or delete the jail to make the services go away.
With The Warden GUI it makes the FreeBSD jails technology more accessible to the users on the desktop and there is little reason not to use it if your setting up a server for your network. If you are a bit paranoid about security this may help you sleep at night. Overall I was impressed with the simplicity of using the software with the initial importing of the Inmate file the only issue that came up. However I would like to see a little more visual feedback in the output particularly in the creation of jails. I would be happy to recommend The Warden to other security minded friends that are starting with BSD.
Check out the howto here (theitmassive.com – 26/05/20209)
The Gnome window manager PBI can be downloaded here.
Another interesting PBI is the Thin Client Server. This PBI installs dhcpd and configures PC-BSD as a Thin Client Server. Clients connected to the servers NIC, will be able to network boot via DHCPD & PXE, and then be brought to a KDM login screen. For more details about this PBI, please read through our Thin Client Wiki
FreeBSD has a reputation for its rock-solid reliability, and top-notch performance in the server world, but is noticeably absent when it comes to the vast market of desktop computing.
Why is this? FreeBSD offers many, if not almost all of the same open-source packages and software that can be found in the more popular Linux desktop distributions, yet even with the speed and reliability FreeBSD offers, a relative few number of users are deploying it on their desktops. In this presentation we will take a look at some of the reasons why FreeBSD has not been as widely adopted in the desktop market as it has on the server side. Several of the desktop weaknesses of FreeBSD will be shown, along with how we are trying to fix these short-comings through a desktopcentric version of FreeBSD, known as PCBSD. We will also take a look at the package management system employed by all open-source operating systems alike, and some of the pitfalls it brings, which may hinder widespread desktop adoption.
This talk was done at AsiaBSDCon 2009
I sent an email to Dylan Cochran with some question regarding his Evoke BSD project. It’s been sitting in my email for a little while, so it’s time to post it.
These were my questions and Dylan’s answers:
1) Can you give a quick update on the state of the project and what you’re planning for 2009.
We are going to make a release soon, and have been working on solidifying procedures, adding documentation, etc. A lot of the unexciting phases.
2) Can you explain how Evoke is different from nanoBSD.
NanoBSD, TinyBSD, PicoBSD, etc, are toolkits to build FreeBSD for embedded devices.
Evoke is not primarily a toolkit, though we have a flexible build system similar to TinyBSD’s, it’s not intended to be used by the users.
I could spend several paragraphs explaining out differences in detail, however, I’d rather talk about our goals. For one, we have tried to clean up our namespace; so that there are no collisions in operation. This means that we can have multiple versions of evoke on a disk, support multiple architectures per version, and even, multiple abis per version. Since the beginning, we’ve built for 6.x and 7.x at the same time, and we’ve also had amd64 and i386 support being built at the same time (Unfortunately, due to economics, we can’t build the amd64 binaries at this time)
The active version, abi, architecture, they are all seperated on several levels. This allows us to remove restrictions that prevent users from running arbitrary i386 binaries on amd64, from moving a
machine from i386 to amd64, to i386, to back again, without losing data or putting the system in an inconsistant state if problems occur.
We also abstract as many interfaces as we can, that may be architecture or abi specific. For example, rather then using mount, you would use mounter, which has a more abstract interface for
handling various filesystems, native, fuse, or otherwise. This grew out of the necessity of dealing with many different mount interfaces between various kernels.
This is a small sample, there is much more. I’ve been pulling in a lot of design elements from a lot of sources, and using the most effective ones for our needs. It’s deceptively simple.
3) When are you planning to release a new version (alpha, beta?)
We are nearing our first ‘real’ release, 0.1. Though we aren’t there yet, there are some autoconf related bugs in the 6.4 target, and some missing features that I consider show stoppers. A big problem is Xorg support, as Xorg and it’s modules take up a large amount of disk space; inflating our image size signficantly. I would rather use kdrive, and build Xvesa, but all my attempts at porting it so far have
failed. So it’s still up in the air on whether or not X support will be in 0.1.
4) Are you planning to track FreeBSD releases (like PC-BSD, FreeNAS, pfSense etc) as the underlying base or are you forking (like MidnightBSD or DragonFlyBSD)
We build for multiple targets, FreeBSD 6.4, 7.1, and even 8-CURRENT. We also have support for other kernels, Linux, Plan 9, etc, but the build system and scripts don’t have any real support for it.
5) Does the project have a new logo yet?
6) Any other things you want to let the BSD community know?
We are always looking for help, our blog has an entry on contributions, and a list of things we are having problems with. If anyone has any knowledge on these problems (especially kdrive) I will be grateful.
Many thanks to Dylan for his time and for explaining a bit more about the background of Evoke.