Slashdot Mirror

Except, like, you know:

http://www.nvidia.com/object/freebsd_180.51.html
But maybe a binary Nvidia driver from 21st april 2009 is too old an un-maintained for you?

And where would FreeBSD fail as a desktop OS?

http://www.freebsd.org/ports/
20.000+ ports not enough for you?

And they make a point of not binary closed drivers to, OpenBSD crew have made a lot of wifi progress by reverse engineering instead of having closed stuff, and Linux have been able to take lots of advantage of their work. They are proud of their drivers and open-source solutions vs accepting only having a closed solution.

So, very insightful of you... I seriously doubt you've got any idea whatsoever why BSD would be better as a server either, not to mention the BSDs out there are pretty different and it wouldn't make sense to group them together like that, they don't have the same advantages. I guess it's just something you've happened to have heard somewhere, but yes, FreeBSD used to be considered superior as "a server" a long time ago, FreeBSD 5 probably lost some of that but I would assume they have catched up by now. But it all depends on what you need and how you set the system up in general anyway.

I'm in a business where we welcome GPL-licensed apps with open arms. Of course, we don't sell software, we sell services and expertise.

Well, many people sell service and expertise and they use non-GPL products. For instance, the URLs below will take to people who sell services and expertise in *BSD systems.

http://www.freebsd.org/commercial/consult.html
http://www.openbsd.org/support.html
http://www.netbsd.org/gallery/consultants.html
http://www.ixsystems.com/

Sorry, I forgot to post the URL:

http://www.freebsd.org/commercial/hardware.html

Culture. Windows grew up on the desktop and moved into the server. Unix grew up on the server and is trying to make inroads on the desktop. "Normal users" will force unix systems to compromise some of their security to make life easier. Windows has had to compromise by removing the "everybody is an admin--free love for all" that existed all the way up to XP. By default, Vista users aren't running as root and the only way to become root is either a UAC dialog or a privilege escalation exploit.

That doesn't account for the server-end though. And why earlier versions of said products had so many holes I will attribute to culture.

Of course, Linux grew out of a culture that detested any kind of authority. Thus you find gems like this in early Linux documentation:

Why GNU su does not support the wheel group (by Richard Stallman)
Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keep- ing it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

Well we could just point him at the cut down installer for PC-BSD that lets him pick and choose his packages. You know, the one found at http://www.freebsd.org/

Is there any difference with respect to a PKCS#11 token?
I've been thinking of using one of these tokens as a "road warrior" SSH key, but then realised that since they need drivers to be useable, that wouldn't be practical to use on machines not owned by me.

Also, why not S/KEY instead of one of those yubikeys (or at least the random password)?

"a Linux binary would no more run under a BSD kernel than it would under DOS"

Errr... yeah... that's not completely accurate.

Actually NVIDIA has stated before that they wish to improve their FreeBSD support and would like it to achieve a feature parallel with Linux, as seen here.

They even did an interview with bsdtalk to try and drum up some support but it has yet to really materialize, here.

You can see current progress at the FreeBSD wiki.

Actually NVIDIA has stated before that they wish to improve their FreeBSD support and would like it to achieve a feature parallel with Linux, as seen here.

They even did an interview with bsdtalk to try and drum up some support but it has yet to really materialize, here.

You can see current progress at the FreeBSD wiki.

- BSD tar lacks the jz switches. Seriously. I want them.

http://www.freebsd.org/cgi/man.cgi?query=tar&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE+and+Ports&format=html

Do you see the -jz switches, cause I sure do. Maybe you could get a clue before you're put in a position of "teaching". Another sad mark reflecting the lack of rigor in our educational standards. Talk about the blind leading the blind.

Also on bsd utilities, -h(if it exists) assumes you have some basic knowledge of the command. Otherwise that is what man(1) is for.

In response to you syscall bs, you can reference this file: /usr/src/sys/kern/syscalls.master or this one for linux syscalls: /usr/src/sys/i386/linux/syscalls.master. Wow even easier than apropos returning jumbled garbage. Imagine that. I'm also going to share a really special trick, you can even use grep(or other utils) on those files to return specific info you're targeting.

Horatio, one of us here doesn't know what the fuck we're talking about and I'm betting it's not me.

Yes, it's a joke but it has an answer too. It might depend on how you define a "package manager" but all BSDs can do:

• Automatic dependency resolving (i.e. install a package, it pulls in its depenancies)
• Package removal (with dependencies)
• Package searching (both installed and available)

And this is not new - it's been there more than 13 years!

ZFS is nice, but thus far FreeBSD's port isn't.

After the demise of SGI, one has to wonder about the future of traditional Unix.

Sun is going the way of SGI because of traditional Unix!

You are funny. Did you read that page? Pretty much every damn license in existance is incompatible with the GPL. But the "fun" one is this:

OpenSSL license .... ...We recommend using GNUTLS instead of OpenSSL in software you write. However, there is no reason not to use OpenSSL and applications that work with OpenSSL.

Yeah, right. Reminds me of this gem buried in the old man pages for the GNU implementation of su :

This program does not support a "wheel group" that restricts who can su to super-user accounts, because that can help fascist system administrators hold unwarranted power over other users.

Yeah, screw security! Who needs passwords! Down with sysadmins!!

I might as well quote the rest of it because it is so juice and nobody will bother to follow the link above:

Why GNU su does not support the wheel group (by Richard Stallman)
Sometimes a few of the users try to hold total power over all the rest. For
example, in 1984, a few users at the MIT AI lab decided to seize power by
changing the operator password on the Twenex system and keep- ing it secret from
everyone else. (I was able to thwart this coup and give power back to the
users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual su
mechanism, once someone learns the root password who sympathizes with the
ordinary users, he can tell the rest. The "wheel group" feature would make
this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to
supporting the bosses and sysadmins in whatever they do, you might find this
idea strange at first.

PS: Just realized that the FreeBSD man-page thingy offers way more man pages than just for FreeBSD. Check it out!

Conficker Eye Chart

Conficker Eye Chart

How to interpret:

If you see this above:It probably means this:

= Normal/Not Infected by Conficker (or using proxy)
= Possibly Infected by Conficker (C variant or greater)
= Possibly Infected by Conficker A/B variant
= Image loading turned off in browser?
Any other combination= Poor Internet connection?

Explanation:

Conficker (aka Downadup, Kido) is known to block access to over 100 anti-virus and security websites.

If you are blocked from loading the remote images in the first row of the top table above (AV/security sites) but not blocked from loading the remote images in the second row (websites of alternative operating systems) then your Windows PC may be infected by Conficker (or some other malicious software).

If you can see all six images in both rows of the top table, you are either not infected by Conficker, or you may be using a proxy server, in which case you will not be able to use this test to make an accurate determination, since Conficker will be unable to block you from viewing the AV/security sites.

F-Secure and the F-Secure Logo are trademarks of F-Secure Corporation.

SecureWorks and the SecureWorks Logo are registered trademarks of SecureWorks Inc.

Trend Micro and the T-Ball logo are trademarks or registered trademarks of Trend Micro Inc.

Quite to the contrary, the FreeBSD guys have been building with clang+llvm for a while now, and they seem to like it. The kernel boots, init inits, filesystems mount, the shell runs.

What other platforms, Darwin? Apple employs the largest number of LLVM developers. Windows? Both MinGW and Visual Studio based builds are tested for each release.

It's still not as portable as the python interpreter, but that will come if and when developers who are interested in working on it start to contribute.

FreeBSD has ZFS. My understanding is while ZFS is a good filesystem, it isn't without issues. It doesn't work well on 32-bit architectures because of the memory requirements, isn't reliable enough to host a swap partition, and can't be used as a boot partition when part of a pool. Here's FreeBSD's rundown of known problems: http://wiki.freebsd.org/ZFSKnownProblems.

On the other hand, the new filesystems in the Linux kernel - ext4 and btrfs - are taking the lessons learned from ZFS. I'm excited about next-generation filesystems, and I don't think ZFS is the only way to go.

Linux is the best open source OS there is, and anyone who cares about software freedom ought to care about it.

OHAI!

Seriously though, that's where flamewars come from...

Have you ever used, um, open source software before?

Yes, as a matter of fact, I have. And I not-so-humbly think, I know more than 99.9% of Slashdot users (including yourself) about such things...

Porting well-written open source apps is mostly just a matter of recompiling these days.

Did I say "well written" somewhere? Or "open source"? I did not... Even if we are talking about a vendor porting their own app (which is "open source" to them), it is far from certain, that it is "well written". And even if it were, they are likely to charge a non-trivial sum for a port to a new hardware architecture. Which means, a person, who bought an older OLPC will have to pay for using the same application on the new hardware.

And, boy, is "well written" a high benchmark to clear! A big portion of applications breaks, for example, when people move from one major GCC release to another. If you told their authors, that the apps are not "well written", you would've been flamed to crisp...

see UVIDEO(4) for usb cameras

'man uvideo' on FreeBSD 7.1 returns nothing. It doesn't appear to on 8-CURRENT either. On OpenBSD, it gives me a man page listing supported cameras.

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

don't have the right hardware

It is almost more difficult to find wrong hardware for FreeBSD. Granted, it doesn't support quite as many systems as NetBSD, but unless you are running something quite odd it is likely you can run FreeBSD on it. Hell, most systems that are being thrown away right now can run it just fine.

FreeBSD 7.1 was released for:

• 64bit AMD
• 32bit x86
• 64bit Intel (Itanium)
• PC98
• PowerPC
• 64bit SPARC

And if you happen to be running an Alpha, you can still run FreeBSD 6.3

If you wanted to try FreeBSD but didn't have the right hardware

Yes, because FreeBSD is so picky about what kind of hardware you use.

Not bad for a "dead" OS:

http://wiki.freebsd.org/AsusEee

Who the hell is Jordan Hubbard?

One of the founders of the FreeBSD project.

BTW, OS X uses a Mach kernel, not *BSD. OS X has much more in common with NEXTStep than FreeBSD.

Mac OS X uses a kernel that combines Mach code and *BSD code. It also has some userland "core OS" libraries (e.g., libSystem) that combine *BSD code with code developed at NeXT and/or Apple.

So, no, it's not as much like 386BSD as 386BSD's more direct *BSD descendants, but it's still closer to *BSD than to other flavors of UN*X.

Thank you, jeaton. You have taught me a little more about the specs. To think that I'm a network admin, running a mail server (with a policy requiring port 465 but accepting 587) for a decently large company, and I didn't know that.

The funny thing is that MS Outlook doesn't know about 465 (when you push to SSL + authentication on outgoing mail, the port doesn't change from 25) whereas Mozilla Thunderbird changes the port to 465 automatically. Also, running grep 465 /etc/services in Debian returns "ssmtp" with alternate name "smtps" and description "SMTP over SSL" rather than your correctly cited official IANA "URL Rendesvous Directory for SSM," implying that at least Debian, FreeBSD, and others who maintain their own lists are also propagating this issue.

I had learned anecdotally (from the above sources and others) that 465 requires SSL (rather than STARTTLS, which makes it optional), and that it was therefore an easier way to require encryption in addition to authentication. Very interesting.

That said, I still find it unacceptable that most ISPs fail to offer SSL encryption for mail over HTTPS, POP3S/IMAPS, and Submission/SMTP/SMTPS.

And why does Windows let random applications install whatever they want, wherever they want, instead of enforcing or at least publishing some standards?

For the same reason that when you install a program on a Unix system, let's say using sudo rpm/apt-get/emerge/whatever, there isn't anything stopping said program from dumping everything in /bin, or /lib, when things should really be put under various directories in /usr/local. The thing is, this doesn't happen, because Unix systems have had a well defined directory hierarchy for a long time that explains where different types of data should go, the programmers generally respect it, and follow it. A good example is the FreeBSD hier(7) manpage. It beautifully lays out where everything should go.

You mention publishing some standards and this is _exactly_ what Microsoft should have done early on. Several MS developers have said they screwed up with this. I think where most things are meant to go is fairly obvious personally, but you can't make assumptions that people will just "figure it out themselves", history has shown that time and time again, especially in computing. A well defined set of "rules" (I don't believe they should be strictly enforced in software, for the same reasons Unix doesn't, or any other OS to my knowledge) that points out where various types of data are meant to be placed in both the filesystem and the registry would go a long way to cleaning up the mess.

The only time I can think of when Unix puts stuff in system directories is when I tell it to.

For the purposes of this discussion, I'd describe a system directory as a directory that requires Administrator/super-user privileges to modify. In this case, whenever something is installed anywhere outside of /home (which does happen) and /var, /tmp (I hope not), then something has been put in a system directory. Frankly, the overwhelming majority of things installed do go in system directories, whether non-privileged users can actually use the programs, is of course, a separate issue. As above, when you type in that magic command to install a package, you take it on faith that it will put its files in the right place, and most of the time it will. Windows needs to do the same.

How is any NT-based desktop a multi-user system? Because someone else can log in once I log out? By that metric, my bicycle is a multi-passenger vehicle.

At this point I'm worried I'm getting trolled. But assuming I'm not, what's even worse is that someone feels they are in a position to criticise an OS they quite clearly so poorly understand. From wikipedia article: Multi-user

Multi-user is a term that defines an operating system or application software that allows concurrent access by multiple users of a computer.

Windows NT quite clearly meets this definition. Have you heard of Terminal Services? One example of many. You clearly need to do some serious research into Windows to better understand what you are criticising.

Next, you'll be telling FreeBSD to drop the Linux-compatibility layer.

Wine is always seen as a bridge. Having developers officially support their applications when running under Wine is just another platform available to them, not double-think. Winelib used to be more important than running Windows binaries using Wine, but that changed in the 90s. The hope was that having more commercial applications available would knock down barriers to adoption.

That's happened in some cases, but not in the general case.

Just visit http://www.freebsd.org/ ... you will find BOTH logos, but Bestie is four times bigger and "important". The other anodyne logo seems more like a decoration element of the stylesheet.

Then why are you using Debian and not using an actually secure OS OpenBSD or FreeBSD?

hmm, reminds me of the description in the comment in http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/pci/if_rl.c (just below the license header)

"The 8139 supports bus-master DMA, but it has a terrible interface that nullifies any performance gains that bus-master DMA usually offers."

Also, Open Source does not neccisarily mean Linux.

Surely there are no other open source operating systems other than Linux!!

*cough* http://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001057.html

You do know that manpages are not really ASCII only? That is only how the 'man' command makes them look.

With the same source files you can get beautiful typeset documents. In fact, that is how the manuals of old where made.

Check out the different formats, even HTML is included.

There are more important things in the world then how well an operating system does in some assholes random benchmark. If you are standardizing your servers around an operating system based solely on "speed", I question your abilities as a server dude.

I'll just name one thing, out of many, that are vastly more important than "speed". Stability. No, not "never blue-screens". I'm "does the maintainers of the system make major changes in every single release and then stop supporting older releases". Under this definition of stable, FreeBSD wins over linux hands down. Especially after the "we can't be bothered to maintain a stable branch of the linux kernel, so we will add new shit in with the old all the time". You might get a dozen exciting new bugs and security fixes when you "upgrade" between 2.6.1114492 and 2.6.1114493. In fact, this was one of the major reasons for me dumping linux in the first place. The 2.4.x kernels are the last stable linux kernels out there.

That is just one example of something more important than "passes 4*10^30 fps in WoW" benchmark.

As for security? Which is easier to audit and verify? A random pool of code and libraries distributed across hundreds of websites and maintainers, or a cohesive operating system whos entire codebase is in exactly one place?

And don't be nervous about making contributions either. My first ports looked like shit, but the port guys were patient and over time I've gotten the hang of the system.

FreeBSD (and probably the other BSD's) are much easier to work on then the other guys. For starters, since you are using a *system* and not a collection of libraries, all your patches and bug-reports go to the same place. In other words, you aren't talking to "the website and the people who maintain the 'tar' utility", you are talking to "the freebsd guys". Your patch for "tar" goes to the same repository as the code for "libc".

Plus since it is licensed as BSD, you can actually contribute modifications and not worry about the nasty side effects found in other licenses. I've never contributed to a GPL project, but I've contributed tons to BSD projects.

Bottom line, FreeBSD is a great place to get your feet wet contributing to open source stuff. Good times.

All the BSD's win for man pages that actually contain more information then "man pages are obsolete, please use the info documentation". In FreeBSD the entire core system has documentation. All of it written in the format god intended--roff.

Did you mention all the man pages are online and can be searched by version? Comes in handy when you are still using FreeBSD 6.1-RELEASE.

And did you mention the fact that BSD's aren't like Linux distros? FreeBSD isn't just a pooling of libraries and code from random people, the core of FreeBSD (shell and userland tools) are all done by the same large team. FreeBSD, OpenBSD and NetBSD are *cohesive systems*, not collections.

Want my year 2009 prediction? This will be the year of the BSD's in the data-center. There is a lot going for BSD based systems, and quite frankly the only reason I can see to go back to a random collection of tools and kernel code (i.e. a Linux distrubtion) is for running code that requires vendor support (Oracle, Dell, etc...). In 2009, I predict (hope) more of these big-name vendors officially support FreeBSD and friends.

There seem to be a few BSD tools with the aim of building smaller collections of binaries in a similar fashion to BusyBox.

You've mentioned crunchgen but there is also embutils (which can be smaller than busy box but requires dietlibc) and there also seems to be something called beastiebox (which allows different amounts of linking). Finally there is Cauldron which seems to be a collection of tools for creating embedded BSD environments.

I just tested this one.

While it's good for Linux adoption, what's the point here?

One of the main reason for using an open source OS is for its owners to inspect its source code and be confident enough that no backdoor is being hidden in there. But why would a visitor of a cyber cafe want to inspect the machine he'll be using there? After all, such machines are by definition unsecure public terminals par excellence, in free and non-free countries alike, no matter what OS they are running. Stuff like OPIE et. al. has been invented for exactly this purpose.

And as to fears from the Chinese government of US government spying on them: I could understand they'd forbid the use of Windows on their own military, or civil installations, and even enact a policy to encourage their private companies to avoid it, but internet cafes? Seriously, what kind of secrets are hidden on those machines besides credit card numbers of unsuspecting visitors and the whole enchilada of malware, keyloggers, viruses, trojans and worms?

6.4 included official DVD images! (For i386 and amd64.) See the release announcement. You can get them via ftp. Or some torrents are here.
.

That's interesting! I'm using the most recent BIOS version available though, so no chance for improvement here. What's puzzling, is that qemu-0.9.1_10 with kqemu-kmod-1.3.0.p11_9 actually don't BSOD XP as often when I run i386. On amd64, it does. Perhaps it's related to this? I don't know, but it's strange.

There's an extention to TCP called ECN (explicit congestion notification) that marks packets as experiencing congestion rather than dropping them, you can see before and after graphs here:

http://people.freebsd.org/~rpaulo/throughput-withecn.png

http://people.freebsd.org/~rpaulo/throughput-withoutecn.png

There's an extention to TCP called ECN (explicit congestion notification) that marks packets as experiencing congestion rather than dropping them, you can see before and after graphs here:

http://people.freebsd.org/~rpaulo/throughput-withecn.png

http://people.freebsd.org/~rpaulo/throughput-withoutecn.png

I wish VMWare would consider FreeBSD for host-support, however, I think Qemu is catching up with VMWare. This is referring to Workstation. For servers, FreeBSD jails are advancing quite a bit. If the plan is to run FreeBSD servers, I would prefer jails over VMWare.

Speaking of jails, they now have support for multiple IP's per jail as of revision 185435. It also adds support for IPv6 addresses to jails.

For a nice front-end to Qemu, I recommend AQemu.