If your security scanner reports a vulnerability based on banners instead of testing the real flaw, they are flawed. Such security scanners feed the myth that changing/removing banners magically makes your network secure.
Unlike Debian or even OpenBSD, ports in FreeBSD don't receive much testing.
Some ports haven't been updated for a while, some even never worked at all, but they are still in the tree for ages. For instance lang/neko never worked on FreeBSD. It compiles, but it was obviously never tested as creating a basic thread is enough to make it crash. Oh and it still has a knob to compile it with MySQL 4.x library (yes, 4.x...).
FreeBSD is way behind every other modern operating system (yes, even Windows) when it comes to exploit mitigation techniques. It basically has nothing (at least in default configuration or in actual use). It has become the main target to learn the basics of exploit coding. Seriously. It doesn't mean that the FreeBSD team doesn't make a wonderful job at maintaining software up to date and at providing patches as soon as possible for vulnerabilities. Actually, they handle security reports in a very professionnal and effective way. But that's reactive security. FreeBSD is really bad for proactive security. And it's way behind Linux, although some efforts have been made for FreeBSD 8 (like Propolice use).
FreeBSD can run Linux apps, but this is only through system calls translations. And that system is far from being perfect. FreeBSD-specific bugs and specific behaviors will remain for emulated executables.
Want an example? The Neko VM ( http://www.nekovm.org/ ) is in the FreeBSD ports tree, but never worked. It crashes with a segfault on any MP system as soon as you create a thread. Why? Because FreeBSD threads have a different behavior than OSX/Linux/Windows/OpenBSD. Neko VM is extremely reliable on Linux. But if you run the Linux version on FreeBSD, it will crash the same way as the native version.
Running userland software with another kernel is fun, and sometimes it can be useful in order to run blobs (Flash, RAID tools, etc). But it can only be less reliable than what the tools were originally designed for. Plus it lacks testing, and you can't expect upstream developpers of software to test their software on hybrid systems like that.
Also, it all depends on your own definition of "distro", but PKGSRC supports a lot of operating systems for a long time, with a huge collection of software. But while it's technically polished for that task, software is actually used and tested only on NetBSD and DragonflyBSD. Other systems just receive minimal testing (basically "it compiles". And that testing is mainly automatic).
MplayerOSX Extended is by far the best media player for OSX.
VLC has a ugly and counter-intuitive GUI. Even going back and forward with the keyboard is not intuitive. And VLC crashes a lot. And while it's supposed to be able to encode videos, except with a few set of settings, it either crash or it doesn't work (also on OSX, never tried on other OS).
CARP is a protocol that does automatic load balancing and IP failover.
Install your application on 2 (or more) servers, give them the same address virtual IP address using CARP, et voila. Nothing more do buy, and no need to install any load balancer.
CARP's reference implementation is on OpenBSD, and it's shipped by default. DragonflyBSD, NetBSD and FreeBSD ship with an older version.
Free operating systems like OpenBSD and DragonflyBSD continously need to compile their ports tree in order to make snapshots available for download and testing. Compiling the whole tree takes quite a long time, especially with piece of software like OpenOffice.org. The currently can't build snapshots as often as they (and user) would like to.
Some other projects like Drizzle and GCC are also looking for remote build machines for regression testing.
Your unused servers can really help the open source community.
The presentation tells you the basics, but Tokyo Products are quickly improving, and there's already a bunch of useful new features since the presentation, as seen in the Mixi's Blog : http://alpha.mixi.co.jp/blog/
Tokyo Products + Flare ( http://labs.gree.jp/Top/OpenSource/Flare-en.html ) makes SQL relational databases totally useless for almost every web app, except for beginners or conservative people.
Also, with the raise of products like Terracotta (for Java) and Maglev (Ruby VM), getting back to SQL really seems retardated.
UTF-8 is actually a hell to work with. Variable-sized characters really makes everything more complicated that it should be.
Windows has support for code pages for backward-compatibility.
But Windows has also support for wide chars since Windows NT. That's quite a long time ago. Every function of the Win32 API that has to deal with strings has a wide chars version. And this is not a mess. It was an efficient way to have unicode-compatible apps without breaking old apps (+ the T* types if you really want your app to work with both).
Wide chars is easy to work with. In fact you don't have to worry much about it. Just use W* types, and the *w* functions and it's just as if you where using plain old ASCII. Every wide char has the same size.
Java followed the same path, and Unicode-support is a standard feature of any app. But Java, just like Windows, can also convert data in and out from/to single-byte chars and UTF8, for interoperability.
You can write Windows apps without any single function using code pages. In fact if you explicitely don't need to export/import data using non-wide chars, this is what you will do without any further effort. And it also applies to Windows CE.
So you can bash Windows, yes, Windows hasn't everything right, but when it comes to Unicode support, it's definitely not that bad. And I'm still waiting for OpenBSD to get Unicode support...
I don't complain about a bug in Neko, I complain about the general lack of testing before commit in FreeBSD.
Neko perfectly works on Windows, OSX and Linux. The issue is that someone merged it to the ports tree, with basic patches so that it "just compiles". But it never worked, trying to create a single thread makes it segfault. It's there, but it's unuseable, so what's the point? As said, a PR was open. No one looked at it. One release later, an unuseable port is still shipped. What's the point?
"Yes, STABLE may break things. I highly recommend you read the meaning of STABLE."... Ah? So, upgrading from 7.0 to 7.0-STABLE and having an unreachable host after reboot because the NIC driver has been broken is the way it should be for FreeBSD? What's the purpose of MFC then ?
FreeBSD 7.1 still ships ports/lang/neko while the software never worked on FreeBSD (nor on any other *BSD). And yes, there's an open bug for ages. Seriously, what keeps me off FreeBSD is the fact that it ships things that weren't tested. Remember when a commit to -STABLE broke Realtek drivers ? Remember when the ports tree had a completly broken pecl-APC, a critical component used by many web sites (and it lasted a long time before being fixed, waiting for an upstream update) ? That's not old, that with FreeBSD 7.0. Oh and of course the broken PHP 5.2.7 also got commited to ports.
Can't FreeBSD folks test things instead of rushing and remove unmaintained things or things that never worked and that they aren't able to fix?
Ruby is a very dynamic language, that makes it easy to extends and to customize classes. Rails itself is designed to be extended using plugins. You can write a plugin that won't define any new class, but that will just add or replace methods from Ruby, Rails or other plugins. This is really a great feature of Ruby, that avoids a lot of hassle.
Before anyone else, thanks to the KDE team. It looks like Apple and Google names shadow the developpers behind KHTML, but WebKit would probably never have existed as it is now without KHTML.
It looks like it still doesn't implement any kind of local storage.
A feature that other browsers have for years, including IE since IE 5.5.
No big improvement in their Javascript engine either.
And Dragonfly is still way behind Firebug and Web Inspector. Opera used to be great, it was ahead of time in the Mozilla Firebird days. But nowadays they seem to fall behing other browsers. Plus Opera is closed-source and there's even no NetBSD/OpenBSD/DragonflyBSD blob. Plus it used to be fast and light compared to other browsers, but according to recent stories published on/., it's now the opposite.
I was an Opera lover, but nowadays, I really see no point in using it over Firefox and Webkit.
Slashdot Mirror
Chromium is opensource.
Fork your git branch ... ...
Rewrite AdBlock plus for Chromium
???
Profit !
If your security scanner reports a vulnerability based on banners instead of testing the real flaw, they are flawed.
Such security scanners feed the myth that changing/removing banners magically makes your network secure.
Unlike Debian or even OpenBSD, ports in FreeBSD don't receive much testing.
Some ports haven't been updated for a while, some even never worked at all, but they are still in the tree for ages. For instance lang/neko never worked on FreeBSD. It compiles, but it was obviously never tested as creating a basic thread is enough to make it crash. Oh and it still has a knob to compile it with MySQL 4.x library (yes, 4.x ...).
Why not fund Coyotos ( http://www.coyotos.org/ ) or even CapROS ( http://www.capros.org/ ) instead of reinventing the wheel?
Funding is really what those projects are in need of. They already have working concepts.
Ubuntu is so all a complete replacement for Windows and OSX that Ubuntu's designs are all so made on OSX with Photoshop.
See below:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/357218
https://wiki.ubuntu.com/Artwork/Incoming/Jaunty/Colors%20of%20Ubuntu%20-%20wallpaper
"*is more secure"
FreeBSD is way behind every other modern operating system (yes, even Windows) when it comes to exploit mitigation techniques. It basically has nothing (at least in default configuration or in actual use).
It has become the main target to learn the basics of exploit coding. Seriously.
It doesn't mean that the FreeBSD team doesn't make a wonderful job at maintaining software up to date and at providing patches as soon as possible for vulnerabilities. Actually, they handle security reports in a very professionnal and effective way.
But that's reactive security. FreeBSD is really bad for proactive security. And it's way behind Linux, although some efforts have been made for FreeBSD 8 (like Propolice use).
FreeBSD can run Linux apps, but this is only through system calls translations. And that system is far from being perfect. FreeBSD-specific bugs and specific behaviors will remain for emulated executables.
Want an example? The Neko VM ( http://www.nekovm.org/ ) is in the FreeBSD ports tree, but never worked. It crashes with a segfault on any MP system as soon as you create a thread. Why? Because FreeBSD threads have a different behavior than OSX/Linux/Windows/OpenBSD. Neko VM is extremely reliable on Linux. But if you run the Linux version on FreeBSD, it will crash the same way as the native version.
Running userland software with another kernel is fun, and sometimes it can be useful in order to run blobs (Flash, RAID tools, etc). But it can only be less reliable than what the tools were originally designed for. Plus it lacks testing, and you can't expect upstream developpers of software to test their software on hybrid systems like that.
Also, it all depends on your own definition of "distro", but PKGSRC supports a lot of operating systems for a long time, with a huge collection of software. But while it's technically polished for that task, software is actually used and tested only on NetBSD and DragonflyBSD. Other systems just receive minimal testing (basically "it compiles". And that testing is mainly automatic).
Please mod parent up.
MplayerOSX Extended is by far the best media player for OSX.
VLC has a ugly and counter-intuitive GUI. Even going back and forward with the keyboard is not intuitive.
And VLC crashes a lot. And while it's supposed to be able to encode videos, except with a few set of settings, it either crash or it doesn't work (also on OSX, never tried on other OS).
Yup, it's rock solid.
CARP is a protocol that does automatic load balancing and IP failover.
Install your application on 2 (or more) servers, give them the same address virtual IP address using CARP, et voila. Nothing more do buy, and no need to install any load balancer.
CARP's reference implementation is on OpenBSD, and it's shipped by default. DragonflyBSD, NetBSD and FreeBSD ship with an older version.
We shave to design web sites for the lowest common denominator.
Free operating systems like OpenBSD and DragonflyBSD continously need to compile their ports tree in order to make snapshots available for download and testing.
Compiling the whole tree takes quite a long time, especially with piece of software like OpenOffice.org. The currently can't build snapshots as often as they (and user) would like to.
Some other projects like Drizzle and GCC are also looking for remote build machines for regression testing.
Your unused servers can really help the open source community.
It looks like the new release doesn't support any more 2.4 kernels, due to NTPL now being mandatory.
When upgrading to a 2.6 kernel is not an option, is there any workaround?
Just in case you never heard about them, have a look at Tokyo Products http://tokyocabinet.sourceforge.net/index.html by the wonderful guy who already wrote QDBM, Hyper Estraier, etc.
The presentation tells you the basics, but Tokyo Products are quickly improving, and there's already a bunch of useful new features since the presentation, as seen in the Mixi's Blog : http://alpha.mixi.co.jp/blog/
Tokyo Products + Flare ( http://labs.gree.jp/Top/OpenSource/Flare-en.html ) makes SQL relational databases totally useless for almost every web app, except for beginners or conservative people.
Also, with the raise of products like Terracotta (for Java) and Maglev (Ruby VM), getting back to SQL really seems retardated.
UTF-8 is actually a hell to work with. Variable-sized characters really makes everything more complicated that it should be.
Windows has support for code pages for backward-compatibility.
But Windows has also support for wide chars since Windows NT. That's quite a long time ago. Every function of the Win32 API that has to deal with strings has a wide chars version.
And this is not a mess. It was an efficient way to have unicode-compatible apps without breaking old apps (+ the T* types if you really want your app to work with both).
Wide chars is easy to work with. In fact you don't have to worry much about it. Just use W* types, and the *w* functions and it's just as if you where using plain old ASCII. Every wide char has the same size.
Java followed the same path, and Unicode-support is a standard feature of any app. But Java, just like Windows, can also convert data in and out from/to single-byte chars and UTF8, for interoperability.
You can write Windows apps without any single function using code pages. In fact if you explicitely don't need to export/import data using non-wide chars, this is what you will do without any further effort. And it also applies to Windows CE.
So you can bash Windows, yes, Windows hasn't everything right, but when it comes to Unicode support, it's definitely not that bad. And I'm still waiting for OpenBSD to get Unicode support...
Netcraft confirms it!
Here: https://rubyforge.org/frs/?group_id=181&release_id=23283
No need to stick with C++ and Java, the QT bindings for Ruby work like a charm.
Flying cars are great, you can now get revenge when a bird shits on you.
I don't complain about a bug in Neko, I complain about the general lack of testing before commit in FreeBSD.
Neko perfectly works on Windows, OSX and Linux. The issue is that someone merged it to the ports tree, with basic patches so that it "just compiles". But it never worked, trying to create a single thread makes it segfault. It's there, but it's unuseable, so what's the point? As said, a PR was open. No one looked at it. One release later, an unuseable port is still shipped. What's the point?
"Yes, STABLE may break things. I highly recommend you read the meaning of STABLE." ... Ah? So, upgrading from 7.0 to 7.0-STABLE and having an unreachable host after reboot because the NIC driver has been broken is the way it should be for FreeBSD? What's the purpose of MFC then ?
FreeBSD 7.1 still ships ports/lang/neko while the software never worked on FreeBSD (nor on any other *BSD). And yes, there's an open bug for ages.
Seriously, what keeps me off FreeBSD is the fact that it ships things that weren't tested. Remember when a commit to -STABLE broke Realtek drivers ? Remember when the ports tree had a completly broken pecl-APC, a critical component used by many web sites (and it lasted a long time before being fixed, waiting for an upstream update) ? That's not old, that with FreeBSD 7.0. Oh and of course the broken PHP 5.2.7 also got commited to ports.
Can't FreeBSD folks test things instead of rushing and remove unmaintained things or things that never worked and that they aren't able to fix?
Ruby is a very dynamic language, that makes it easy to extends and to customize classes. Rails itself is designed to be extended using plugins. You can write a plugin that won't define any new class, but that will just add or replace methods from Ruby, Rails or other plugins. This is really a great feature of Ruby, that avoids a lot of hassle.
Also have a look at that blog post, by a Sun employee, on the SUn blog :
http://blogs.sun.com/mrbenchmark/entry/scaling_mysql_on_a_256
The comments are insightful.
Before anyone else, thanks to the KDE team. It looks like Apple and Google names shadow the developpers behind KHTML, but WebKit would probably never have existed as it is now without KHTML.
I have great hopes in the YARV to LLVM compiler (yarv2llvm), even if you can't read japanese, have a look at the numbers: http://d.hatena.ne.jp/miura1729/20081012/1223785541
It looks like it still doesn't implement any kind of local storage.
A feature that other browsers have for years, including IE since IE 5.5.
No big improvement in their Javascript engine either.
And Dragonfly is still way behind Firebug and Web Inspector. /., it's now the opposite.
Opera used to be great, it was ahead of time in the Mozilla Firebird days. But nowadays they seem to fall behing other browsers. Plus Opera is closed-source and there's even no NetBSD/OpenBSD/DragonflyBSD blob. Plus it used to be fast and light compared to other browsers, but according to recent stories published on
I was an Opera lover, but nowadays, I really see no point in using it over Firefox and Webkit.