Wow. I remember reading about Hotmail servers running BSD back in the day, but not quite like this.
FreeBSD 10.1-RELEASE is also available on these cloud hosting platforms:
- Amazon(R) EC2(TM) FreeBSD/amd64
- Microsoft(R) Azure(TM) FreeBSD/amd64, FreeBSD/i386
Well hotmail was not owned by Microsoft originally. The urban legend is that after they acquired it they had to keep running it on FreeBSD a lot longer than they wanted to because Windows was not up to the task at the time.
Edit: After a moment's thought... wasnt Hotmail originally running on Solaris or SunOS?
"Hotmail initially ran under Solaris for mail services and Apache on FreeBSD for web services, before being partly converted to Microsoft products, using Windows Services for UNIX in the migration path."
* Does not work with certain hardware / UEFI firmware implementations
(due to bugs in either our implementation, or the firmware).
* No support for UEFI nvram variables.
* No integration or documentation for dual-boot configurations.
Basically, if you can boot the UEFI-enabled USB stick image, UEFI booting an installed FreeBSD should also work fine.
Basically, if you can boot the UEFI-enabled USB stick image, UEFI booting an installed FreeBSD should also work fine.
I remember seeing a bug report about a system where the BIOS treated USB and non-USB disks differently resulting in one working and the other not. There's really no guarantees when you're dealing with broken BIOSes...
I always wanted to try FreeBSD, but during install, after I picked the software I wanted it would ask me for disk 10, then disk 7, then disk 5... I proceeded to giving up and installing Slackware instead (this was back in 2007 when I was new to Linux). I hope they've fixed this since, or maybe I did something wrong, who knows? Oh well...
I suspect you probably selected CDROM at the time as your software source, which can be confounding for new users. The best solution in this case is to either install binary packages via selecting FTP as your source or (better) via ports. Also, I generally avoid installing extra software outside the base packages until after the system is installed, as this was a problem that could crop up when installing earlier versions (not really a problem per se as much as if it's something you weren't familiar with, it may do unexpected things).
If you install some of the tools in ports-mgmt (portupgrade, for instance, which includes portinstall), you can make the ports collection far easier to manage and use, and it might be more approachable for new users. Not that it's difficult to do a make && make install from the port you want.
I haven't touched FreeBSD in years, so I'd imagine the installer is a bit more forgiving now. That said, my experience with the ports collection was what lead me to select Gentoo for my Linux preferences (later, and more presently, Arch). But, I have very fond memories of using ports, and I think everyone has their preferred methods. The trick is to neither give in or give up and play around with it until you're familiar and have picked tools you're comfortable with (this holds true for almost anything)! I'd suggest giving it another shot.
Edit: I lied. Apparently I have a FreeBSD 10 vm, so it hasn't been years. I don't remember the new installation procedure at all, sadly.
I have FBSD 10.x running in VM and production, and I'd agree it's probably best to install the OS first before trying to add applications. In my experience following this policy leaves fewer ways for things to get screwed up.
Re: the ports collection, as a former Gentoo/Funtoo user I felt as you describe. But I think the current FBSD package system is better. Unless there's a special use case, it's generally quite satisfactory and a whole lot easier to download and install apps using the "pkg" utility, rather than messing with ports at all.
IMO the FBSD developers have been doing a terrific job of making the OS better without making it tons harder to administer. There's still a learning curve for sure (e.g., ZFS) but it's not insurmountable.
> In my experience following this policy leaves fewer ways for things to get screwed up.
Definitely. I still do this for exactly that reason. Unnecessarily complicating the installation process is just a recipe for frustration unless you have a well tested build script.
> But I think the current FBSD package system is better.
This is true. I don't have much experience with the "new" package system, because I (mostly) stopped using FreeBSD ~5.x with some more recent usage in the 8.x and 9.x series. I've dabbled in it since, rarely, but I think the old habit of "install everything via ports" is so ingrained in some of us whose FreeBSD use dates back that it's a bit difficult to overcome. :) I'll familiarize myself with it one of these days, perhaps, but the disenchantment with Gentoo is largely the reason I use Arch now and it'd be great to use something similar under a BSD. Rolling release + binary packages = vastly nicer than waiting for hours for Xorg/KDE/Gnome/whatever to build. As a fellow former Gentoo user, I hope that if you read this, I won't have triggered unfortunate flashbacks or painful memories as a consequence of mentioning this. ;)
If new(ish) users come across this thread, follow jrapdx3's suggestion and learn pkg--it's supposed to be really nice and circumvents some of the old ways of doing things. FreeBSD has, IMO, done a great job of mixing something like a rolling release platform with a well-tested and stable kernel/environment. It's almost the best of both worlds, though some things might be a bit tedious to get running. (Is Java still a colossal pain?)
> IMO the FBSD developers have been doing a terrific job of making the OS better without making it tons harder to administer.
Here's another thing: FreeBSD is consistent. So much so that even if you return to using it after years, things still* work more or less the same, and that old knowledge transfers well (within reason).
I can't really say the same for Arch, for instance, because there's usually a hugely disruptive change every 6-12 months. I love Arch (I'm using it right now), but sometimes the drastic changes can be ... surprising.
> ... I've dabbled in it since, rarely, but I think the old habit of "install everything via ports" is so ingrained in some of us whose FreeBSD use dates back that it's a bit difficult to overcome. :) ...
Ports is still fundamental, but often enough a problem. Not only do some ports take a long time to compile (like Firefox) but a little too often won't compile--maddening when that happens 2 hours after entering "make".
OTOH "pkg" is stable and convenient to use, lately showing no glitches, certainly fewer complications vs. portage, rpm, dpkg, et. al. (Don't know enough about Arch to comment on it.) On the whole pkg is pretty painless.
> (Is Java still a colossal pain?)
Yes and no. I installed openjdk 8.x the other day using 'pkg search', then 'pkg install'. Quite simple. However, if for some reason the Oracle version is necessary, then you'd have the hassle of getting it from their site.
> ... I (mostly) stopped using FreeBSD ~5.x ...
Maybe I should feel a little embarrassed that I still have one DB server which has been running FBSD 6.0 since 2005 (I think). And it's been running continuously, only stopping here and there because of power outages. Haven't changed any of the software, the only maintenance has been backing up the DB, rotating logs, and so on.
I keep meaning to update that system but I don't seem to get around to doing it. After 80,000 hrs on the job I guess we might call it "stable".
> Not only do some ports take a long time to compile (like Firefox) but a little too often won't compile--maddening when that happens 2 hours after entering "make".
I've only once tried using FreeBSD for a desktop machine, and lengthy compilation times (followed by the occasional failure) were one of the reasons I didn't, and another one of the reasons why I eventually dumped Gentoo as my choice for workstations. I remember building Xorg overnight once on Gentoo only to discover that it had failed about 30 minutes after I went to bed.
I'm still a little upset over that, thinking back on it.
> (Don't know enough about Arch to comment on it.) On the whole pkg is pretty painless.
Arch is a rolling release distribution with binary packages; it seems that pkg operates in a manner similar (identical?) to this. It really is the best of both worlds: New packages, when updates are released upstream--usually within days--without the need to compile.
Though, I wouldn't recommend Arch for much other than a workstation (partially due to the nature of rolling releases--breakage happens), it has actually been a fantastic distro for someone whose nix history went something like OpenBSD -> FreeBSD -> Gentoo. You update the system periodically, new packages are downloaded and installed, and updates occur frequently. Compilation is mostly limited to the AUR (Arch User Repository), but the benefit with Arch is that its build tools create binary packages by default that you can then use on other machines of the same architecture. Gentoo allows the same thing, but IIRC it's not something it'll do by default and it's a bit fussier. If you do have to build something, Arch will build the package first, then install from that. But the main repositories have essentially everything you'd want, so compilation truly is limited to less popular/common packages. Everything else is just a download + install away.
But again, Arch is susceptible to some breakage at times, although I've had pretty good luck avoiding this. I guess it's like anything else: If you're careful and apply some meticulous scrutiny to the process, you're less likely to break things in a manner that's difficult to fix. Updating regularly (as with other rolling releases, like Gentoo) is also helpful. Too long between updates can create a bit of a difficult situation to get out of.
> Yes and no. I installed openjdk 8.x the other day using 'pkg search', then 'pkg install'. Quite simple. However, if for some reason the Oracle version is necessary, then you'd have the hassle of getting it from their site.
Okay, that's not too bad. I vaguely* recall it being painful back during 5.x-6.x, but I never had much need for Java on FreeBSD either outside some odds and ends.
> Maybe I should feel a little embarrassed that I still have one DB server which has been running FBSD 6.0 since 2005 (I think).
NOPE! (I wouldn't.)
When I ran FreeBSD (all the way back through the latter 4.x days, probably 4.5-4.6 at the absolute earliest, but I think we had a 4.7/4.8 machine running for a number of years), the beautiful thing about it was definitely its stability. You could do exactly that: Go for ages without updating it and as long as it wasn't Internet-connected, there wasn't really much you needed to worry about. And even if it was, you could just update whatever software you had listening on open ports, within reason, and not worry (I'd do this with Apache or BIND). I know this goes counter to much of the philosophy here, but sometimes if it ain't broke...
The curious thing regarding FreeBSD was the more conservative upgrade path you'd often feel compelled to take, and you seldom felt guilty for leaving a machine untouched. You could always take comfort in the fact that it'd Just Work and remain fairly secure.
That's funny, I had the exact opposite experience. Back in 2002-ish I was trying to install Slackware and LILO kept failing for some reason I couldn't understand. That turned me off to Linux distro. So I went looking for an alternative and came upon FreeBSD. For personal computer *NIX installations, I haven't looked back. Though of Linux dominated sever installations in the subsequent years, I think the tides are changing and will be using FreeBSD for my next project. Say hello to dtrace and zfs. Can't wait.
You can install from a flash drive or single dvd. They've been working fairly heavily on the install process in versions 9 and 10.
EDIT:
I thought about this more after submitting. The many disks are likely for seeding the ports tree. If you have an internet connection available or opt to not install the ports tree you can install off much smaller media.
I don't think the ports tree is quite that big, at least when it's compressed (presently ~220ish megs for FreeBSD 10 as a tgz), because ports only contain Makefiles and descriptive metadata.
It used to be the case, I think, that the extra disc images were for installing applications outside the base distributions and the likes as they themselves contained a snapshot of some of the binary archives for a given release. I don't know for sure, though, because I always used ports (which is better and obviously more up to date).
I plan to try out PC-BSD (which is basically FreeBSD with all the desktop GUI stuff set up for you) when they get their 10.1 version out. I've been told by actual FreeBSD folks that it's the least painful way to get into FreeBSD.
Security patches and errata updates. The criterion I set down when I was security officer for what would go into this was "people should be able to install these blindly without ever worrying that it will break anything".
I believe these are the major problems of FreeBSD: no minor releases to give users fixes from STABLE or HEAD, no packages for the base system to make update installation trivial, TCP and networking stacks lag behind those found in modern Linux kernels, many features lag behind those found in Linux, pf lags behind OpenBSD's pf, some tools and problems haven't changed in years, bhyve isn't production ready, CAM target is a toy when compared to what COMSTAR is providing for iSCSI and SRP (no LUN masking, per-port configuration or initiator grouping), jails are no match for Solaris zones.
PC-bsd, pfsense and freenas use patches from STABLE and HEAD to get things done, they can't use unpatched FreeBSD because it's not meeting their needs.
You seem to be working on 8.5, 9.4 or 10.2 and the others don't see a release until you're done with the one you're focusing on.
I'm using 9.3 right now. I had to wait until you were done with 10.1, hoping FreeBSD 9.4 will be next.
There's no way to plan anything around FreeBSD's release or development process. There's no telling if your new FreeBSD version is going to be stable or not, a driver from STABLE might be more stable than the same driver from RELEASE.
Many live systems are lagging behind with FreeBSD updates because updating those systems can lead to extended downtime due to potential bugs in drivers or a potential breakage caused by the merging of conf files.
8-14 months between any significant update for the particular FreeBSD you're running is too much. Severe bugs get fixed only in a release, not in your patches.
8-14 months for bugfixes to what exactly? All the serious packages you use in most servers are installed via packages/ports. What's actually in the base system that isn't (a) also in ports or (b) needs upgrades more frequent than to as frequent as Fedora (which is 6 months btw).
We never accepted OpenSSL patches into our tree without looking at them very carefully. At least 50% of the time we would end up committing a different patch because OpenSSL had either introduced new bugs or had failed to fix the reported vulnerability.
No, they're right. Linux systems don't panic because of broken drivers after an update, they keep running properly.
FreeBSD sometimes completely stops booting on your hardware or turns unstable for no good reason. (search on google for posts from people who can't boot FreeBSD 8.x on hardware which was running 6.x or 7.x without the slightest bug)
FreeBSD can crash your system because of an unstable driver after a major upgrade like 9.2 to 9.3.
You can see they're right, "FreeBSD doesn't take your system down like Linux", it's much worse.
I must give FreeBSD another spin. The last time I used it in anger was circa 2000 (4.0) to build a route collector for a small internet exchange point using GNU Zebra [0].
You don't give a lot of detail to work with, but my best stab in the dark is that in X by default the font renderer will sometimes use bitmap fonts (and stretch them) when what you really want are vector fonts. You can edit fonts.conf to avoid this, if you like. (Unfortunately, I'm booted into Windows at the moment so I can't copy and paste my configuration.)
Or perhaps you've got something else going on entirely. It's hard to say from your post.
Has them. You caould watch your family home movies which you haven't uploaded to the cloud yet with mplayer and the dependencies that install when you compile it! It also has aalib and libcaca if your so inclined to geekout with seeing your flick directly in the terminal console.
