"And both of them do raw MPEG-2 to Divx/XviD encoding at nearly the same rate."
There's any number of ways performance can be affected. Are you using a codec that's optimized for Altivec but not SSE? Those chips would not demonstrate such a wide performance gap without something slowing the Athlon down.
"The G5 is better however, because of its addressing and memory management (the two areas PC chips were still "winning" in). The only negative is the total GHz for PPC CPUs available is lower."
What exactly is "addressing and memory management"?
G5s have a bus comparable to Pentium 4s, but Athlon64s and Opterons have on-die memory controllers. That gives them significantly better memory performance, particularly better latency. Better than G5s and better than P4s.
"Not exactly. About half the non-cache die area of a modern Pentium or Athlon CPU is spent on the various stages of decoding and scheduling i386 bytecode"
Perhaps with the original Pentiums, but it's much smaller than that now.
There's also disadvantages to RISC; binaries tend to be bigger (x86 has variable sized instructions) and that uses up some of the larger cache that RISC chips tend to have. Also, the really highly performing RISC chips spend a LOT of die space on scheduling instructions (G5 is a good example of this).
Evidence is strong that x86 chips are competitive in terms of power consumption and performance. For example, the strongest mobile processor is currently the Pentium M, which uses less power than G4s and performs almost as well as desktop processors. Opterons are comparable to G5s for server tasks. POWER scales to much bigger machines, but machines that big are quite rare.
Except for a very few areas, one should choose a platform based on other criteria (you like MacOS better, you need to use Windows specific software, etc).
"The CISC-based Intel/AMD processors are not as efficient at getting work done as the RISC-based PowerPC processors."
Unfortunately, you're completely wrong. Socket 370 celerons suck, but because they have a slow bus and not enough cache. G4s beat them handily by just about any measure, but they're not comparable to any of the other chips available these days.
I've said this so many times I should probably just write it once and post it whenever appropritate: The CISC/RISC divide stopped being such a big deal with the release of the original Pentiums because they decoded CISC instructions into RISC-like internal instructions, allowing them most of the same advantages. As technology progressed, the extra burden of supporting x86 compared to RISC dropped. At the moment, the difference is hardly worth considering.
G4s are slower than just about every desktop/server chip today. One of the exceptions are SPARC processors, which are also RISC.
Performance is about 60% to do with the company behind the processor and the resources they command, 35% to do with whether or not they make boneheaded decisions (such as Intel's decision to go with Pentium 4's instead of Pentium 3 derivatives like the Pentium M (aka Centrino)), and 5% to do with the architechture they have to work with.
Thus, companies like IBM, and AMD have the best processors, Intel fucked up and is a step or two down for the moment, and Motorola and Sun/Fujitsu are pretty close to dead last.
"Even if you *could* get SMP aware versions of your software, would it be worth it? Lots of problems are harder to solve when you add SMP to the mix."
For the time being, dual-core chips will be primarily for people that stand to benefit. Video, graphics, compiling, servers that have multiple processes or threads, etc.
"Gamers will be put off by the fact that games can't take advantage of SMP."
Games have been updated to take advantage of hyperthreading. Not only does that allow some games to benefit immediately, but it also implies that games will be updated in the future.
"Buisness user may take advantage of this in servers, but there's only so much cooling and power you can provide to a 1-U server."
There's dual-processor 1U servers...
Also, I can't speak for Intel, but AMD has committed to keeping their dual-processor chips under 100 watts.
"So, how is dual core going to ever be anything bigger than Itanium, Xeon, or any of the other technologies that fail to meet customer expectations?"
What, like Opterons?
Yeah, nothing new ever works out.
Every single manufacturer of server or workstations or desktop chips is moving towards multi-core designs. The ones that I specifically know are going to use multi-core designs include Intel (Itanium and x86), AMD, IBM, Freescale (aka Motorola), Sun, and Fujitsu.
Software vendors had better optimize for SMP. Because that's all there's going to be in a few years.
"IMHO "restrictions" would be a better word then "protection". Only a very small number of people benefit from Digital Restrictions Management. For others it is just something restricting what they can do with the art they have bought. "Protection" really is one of the words the big media wants you to use. DRM is for their "protection", not yours."
"Restrictions" are policy. "Protections" are mechanism. They don't refer to the same thing. For example, Apple could loosen or strengthen the restrictions in iTunes without changing the protection technology they use.
If you can suggest a synonym for "protection" that has a negative spin, I'll consider using it.
"If it's digital, and the end user can see / hear it, it can be copied. Perfectly."
The act of stripping the DRM puts the user in a different legal position. I think the industry's threshold is the point where users must go to significant lengths to get around it. For projection that, for example, is based on a CD that autolaunches DRM software, users can reasonably argue that they didn't even realize there was protection (they use Mac or Linux, or have autolaunch turned off or something).
I don't think you can really get significnatly better (read: harder to copy) than FairPlay on a general purpose computer. Until you can (eg, DRM hardware is standard), the industry will probably allow the current situation to continue.
The dual-core MPC8641D will apparently use 15 watts (probably for the slowest one). Assuming that number is running flat out (the information site is for the embedded version so I assume it is flat out), it's about as much fully loaded as the slowest G5 uses idle. More suitable for a laptop.
Even the single core one would be better, as the bus speed isn't quite so hilarious.
Also, I think the G5s are already cheaper for Apple to buy...
PowerBooks are not currently fast enough for CPU-bound tasks that they're supposed to be able to do*. The only question in my mind is whether Apple decided to fasttrack G5s into the PowerBook line or if they decided it would be better to do the non-trivial redesign required for the new chips** from Freescale (aka Motorola).
I'm on the fence.
On the one side, using the new Freescale chips would require a lot of design work that will go out the window when G5s become low power enough to go in laptops. That might not be this year, but it will be in the next few years.
On the other side, maybe that work won't go out the window. Even though PowerBooks will be 64-bit in the next few years no matter what, the chipsets and other design work can be recycled in the budget lines, which will no doubt be using 32-bit chips for some time into the future.
One thing is certain: PowerBooks are not currently competitive in areas that are primarily CPU-bound (heavy graphical work, video editing/encoding, etc). They're falling behind now and when Centrino II comes out they won't even be worth mentioning. Apple needs something very soon. Therefore, it is reasonable to assume they are currently doing their best to move heaven and earth to make something happen before it's too late.
Now, I believe it's time for me to get modded down for being critical of an Apple machine. Better get started before too many people read this.
* - I know your PowerBook is more responsive than a much faster Windows machine. I'm talking about CPU bound tasks that aren't necessarily interactive. Any responses involving day-to-day user experience will be ignored because I'm not addressing that.
** - Freescale has a slightly faster PowerPC chip that's pin-compatible but doesn't upgrade the bus. They also have single and dual-core chips that scale to higher clock speeds and have on-die memory controllers, eliminiating most of the need for a fast bus. These faster chips are not pin-compatible and would also require a new chipset due to the on-die memory controller. None are 64-bit.
"I can see both sides. Everything you're saying makes perfect sense, but I can also imagine an influx of new users on the mailing lists complaining that some freak glitch in their ISA sound card won't let them install FreeBSD."
That's why you have a "safe mode" or something functionally equivilant. Problem drivers can be disabled in the one case in ten thousand where they misbehave.
"They don't have the installation base of Linux (and the huge number of fault-finding eyes that goes with it), or the "if you don't like it, fix it and send a patch" attitude of some of the OpenBSD support forums."
bah. I think that's a red herring. Linux 2.6 still breaks something new with every release (libata is a disaster), while OpenBSD works very nearly perfectly with all supported hardware. Granted OpenBSD doesn't support as much hardware, but FreeBSD has vastly more resources in terms of developers, funds, and users for testing. Particularly desktop users.
The "if you don't like it fix it" attitude is mostly for features or design issues. For things like driver bugs, the developers really don't like them existing at all. I've had developers get so annoyed that a bug even exists that they hounded me to get details past what I was originally willing to provide.
However, I don't agree with all the attitudes of OpenBSD developers so please don't respond as though I'm unconditionally supporting their conduct because I'm not.
"Maybe, I am waxing "intellectual", but the fact that the x86 with its ugly instruction set and gross addressing modes has dominated the market really disappoints me."
Partly because you're wrong, and partly because it doesn't matter.
To elaborate:
I will concede that the x86 instruction set is not pretty, but I would argue that it doesn't matter. Specifically, it only matters a little bit to people that program in assembly, and it doesn't matter at all to people that use compilers (the vast majority). As transistor counts have gone up, the added difficulty of supporting x86 has dropped to less than 5% of the transistors on the chip, probably less than that now that everyone has giant caches. Also, x86 binaries tend to be smaller (as x86 doesn't have to use fixed size opcodes) which saves a not-insignificant amount of cache and memory bandwidth.
The "gross addressing modes" are only relevant in real mode. In 32-bit protected mode or 64-bit mode, the address space is flat just like PowerPC. None of the popular OSes being distributed for x86 uses real mode (*BSD, Linux, Windows 2000 and later). Sure, the computer spends a few seconds in real mode after you turn it on and before the OS loads... but who cares?
"Why can't the better (from an engineering point of view) instruction set architecture (i.e. PowerPC) win in the desktop market?"
"FreeBSD tends to leave such decisions to the user, and isn't as cautious about providing modules as OpenBSD."
Yeah. That's why it's annoying. If the driver causes problems, fix it. If it doesn't cause problems, why not load the module automatically when the relevant hardware is present? Give users the option of opting out, fine, but all it does is make life difficult for users at the moment.
When I refferred to OpenBSD being easier to use, this is the sort of thing I meant.
"While I believe you, I'd be interested to know how you know that."
It's obvious from the performance of the thing. I know the OS is capable of high network performance because it's used in high performance areas. I assume the rest of the machine is not hobbled in some other way, as the machine performs okay in other respects. The only likely candidate is the network interface itself.
"how does one learn the manufacture of the low-level components of a MLB, when that info is not available from the vendor?"
The BSDs and Linux people generally figure that stuff out pretty quick. Even if a device identifies itself differently, if it has the same interface and the same bugs as a known chipset, it's pretty obvious what it is.
"I'm honestly not sure what you're talking about. There are quite a few ports that accept environmental variables to decide with optional dependencies to compile in. For example, if you set "WITHOUT_X11='YES'", then ports will avoid requiring xorg (or xf86 on 4.x) whenever possible. Ports are pretty good about letting you know which options you can select, and you can put all of those definitions in a single file so that you don't have to remember them each time."
The only case I specifically remember was kuickshow not being part of kdegraphics (to avoid adding a dependency) unless a certain variable was set. I guess I just didn't have enough experience with FreeBSD to know where to look, but it was pretty annoying. And even then, it would be annoying to have to read a bunch of docs to find out what optional stuff I need to do, when I don't necessarily know what I want (eg I haven't used the software before).
"To enabling the drivers for my SB Live! card, I added this to/boot/loader.conf:
snd_emu10k1_load="YES"
which would be analogous to adding an entry to/etc/modules on a Linux system."
I didn't have to mess with anything to get sound working on the same machine with OpenBSD or Linux. Besides, "same as Linux" is not a particularly lofty standard.
"That is such an understatement.:-) I host a few webservers, a Freenet/Gnutella/IRC server, and my ISP's newsserver inside their own jails on my server at home with almost zero CPU overhead. The only downside is that you can only assign one IPv4 address to each jail right now, although that's being worked on"
Can't you do NAT for the various jails? The firewall is global to all jails.
Theo says jails aren't the way to go, but it keeps OpenBSD out a lot of areas that FreeBSD is currently popular. Same goes for the lack of jails on Linux.
I've tried them all and they're so different from each other that one won't really give you a very good idea of what the others are like.
OpenBSD is probably the easiest. Most things are in a working configuration by default, they just need to be switched on. FreeBSD has more software and better performance, but it's never been worth it for me because you have to mess around with the kernel and stuff (We're not on Linux, after all). I had to manually enable modules to get things like sound and set all sorts of environment variables to get some of the ports to work right. On OpenBSD it pretty much works the first time you boot it if it's going to work at all. The security is a bonus, but mostly I like how little work it takes to maintain.
FreeBSD is a bit more up to date, and has more powerful features (I love jails). I usually fall back on it if I need one of the features.
I don't really see much point in NetBSD, but given the number of people that use it and like it it's probably worthwhile to take a look.
DragonFly is still close enough to FreeBSD in terms of user experience that you might be able to skip it if you don't like FreeBSD.
They're all pretty easy to install. Give 'em a shot.
"Why not? Or is this yet another empty "marketting-statement?""
The Gentoo developers do not make any guarantees that the Portage tree will be in a consistent state at any given time.
Anyone that's used Gentoo for any period of time has had breakage. Usually, it's a matter of a quick update or at worst a stop by the forums. However, sometimes the breakage exists for longer or is harder to fix. Businesses cannot afford to take this risk.
I no longer use Gentoo because breakage almost caused me to miss deadlines on more than one occasion. It's my ass when it goes wrong, so I won't put myself in a position where I'm taking responsibility for an OS that doesn't guarantee me that they'll even test something before it's released. One of the instances of breakage (IIRC, the required version of fam was masked for the KDE-3.2 update) would have been caught if anyone had tried it on a stable system before release.
Portage is a very powerfull tool, and if someone would take a snapshot of the portage tree and then spend 6 months working the kinks out of it I'd give it a shot. But that hasn't happened.
The thing with a jail is that it'll be running on a very high end machine (unfortunately FreeBSD doesn't have a decent PowerPC port yet, otherwise an Xserve would be ideal for this) (also unfortunately, MacOS doesn't seem to have the jail facility, so you can't do the jails with MacOS would would also be ideal), and it's probably set up to failover onto another machine if it goes down. You're paying for the reliability.
If your Mac mini goes down, you could be SOL for weeks.
The value you place on reliability is of course completely up to you.
Apple doesn't tend to use very good network chipsets in their low end desktop machines. They eat a lot of CPU time and don't go very fast. Doesn't matter in a desktop machine, but it hurts in a server, even at slow colo speeds.
Probably doesn't hurt as much as the laptop drive anyway. Besides, people probably don't want these as high-load servers. The probably just want something off-site.
I think people want to use them because sometimes you just need something online all the time, even if the hardware can't support a high load. It's still a bad position to be in because the laptop drives don't need high load to kill them, but as you say there aren't a lot of options.
For cluster computing, it's gigabit minimum. Preferably something better. For example, the Big Mac cluster uses Infiniband, a low-latency network technology.
100 is good enough for desktop use, and good enough as a web server, but it's not good enough for cluster computing.
Slashdot Mirror
"And both of them do raw MPEG-2 to Divx/XviD encoding at nearly the same rate."
There's any number of ways performance can be affected. Are you using a codec that's optimized for Altivec but not SSE? Those chips would not demonstrate such a wide performance gap without something slowing the Athlon down.
"The G5 is better however, because of its addressing and memory management (the two areas PC chips were still "winning" in). The only negative is the total GHz for PPC CPUs available is lower."
What exactly is "addressing and memory management"?
G5s have a bus comparable to Pentium 4s, but Athlon64s and Opterons have on-die memory controllers. That gives them significantly better memory performance, particularly better latency. Better than G5s and better than P4s.
"Not exactly. About half the non-cache die area of a modern Pentium or Athlon CPU is spent on the various stages of decoding and scheduling i386 bytecode"
Perhaps with the original Pentiums, but it's much smaller than that now.
There's also disadvantages to RISC; binaries tend to be bigger (x86 has variable sized instructions) and that uses up some of the larger cache that RISC chips tend to have. Also, the really highly performing RISC chips spend a LOT of die space on scheduling instructions (G5 is a good example of this).
Evidence is strong that x86 chips are competitive in terms of power consumption and performance. For example, the strongest mobile processor is currently the Pentium M, which uses less power than G4s and performs almost as well as desktop processors. Opterons are comparable to G5s for server tasks. POWER scales to much bigger machines, but machines that big are quite rare.
Except for a very few areas, one should choose a platform based on other criteria (you like MacOS better, you need to use Windows specific software, etc).
"The CISC-based Intel/AMD processors are not as efficient at getting work done as the RISC-based PowerPC processors."
Unfortunately, you're completely wrong. Socket 370 celerons suck, but because they have a slow bus and not enough cache. G4s beat them handily by just about any measure, but they're not comparable to any of the other chips available these days.
I've said this so many times I should probably just write it once and post it whenever appropritate: The CISC/RISC divide stopped being such a big deal with the release of the original Pentiums because they decoded CISC instructions into RISC-like internal instructions, allowing them most of the same advantages. As technology progressed, the extra burden of supporting x86 compared to RISC dropped. At the moment, the difference is hardly worth considering.
G4s are slower than just about every desktop/server chip today. One of the exceptions are SPARC processors, which are also RISC.
Performance is about 60% to do with the company behind the processor and the resources they command, 35% to do with whether or not they make boneheaded decisions (such as Intel's decision to go with Pentium 4's instead of Pentium 3 derivatives like the Pentium M (aka Centrino)), and 5% to do with the architechture they have to work with.
Thus, companies like IBM, and AMD have the best processors, Intel fucked up and is a step or two down for the moment, and Motorola and Sun/Fujitsu are pretty close to dead last.
In summary: stop being a fanboy.
I assume someone's going to try this with the iPod shuffles.
I guess they'll have to use the LED lights to blink the signal out. Hell, they'll probably have to use the LEDs to blink the interface out too.
I was addressing the utility of dual-core chips in general, not Intel's specific implementation.
"Even if you *could* get SMP aware versions of your software, would it be worth it? Lots of problems are harder to solve when you add SMP to the mix."
For the time being, dual-core chips will be primarily for people that stand to benefit. Video, graphics, compiling, servers that have multiple processes or threads, etc.
"Gamers will be put off by the fact that games can't take advantage of SMP."
Games have been updated to take advantage of hyperthreading. Not only does that allow some games to benefit immediately, but it also implies that games will be updated in the future.
"Buisness user may take advantage of this in servers, but there's only so much cooling and power you can provide to a 1-U server."
There's dual-processor 1U servers...
Also, I can't speak for Intel, but AMD has committed to keeping their dual-processor chips under 100 watts.
"So, how is dual core going to ever be anything bigger than Itanium, Xeon, or any of the other technologies that fail to meet customer expectations?"
What, like Opterons?
Yeah, nothing new ever works out.
Every single manufacturer of server or workstations or desktop chips is moving towards multi-core designs. The ones that I specifically know are going to use multi-core designs include Intel (Itanium and x86), AMD, IBM, Freescale (aka Motorola), Sun, and Fujitsu.
Software vendors had better optimize for SMP. Because that's all there's going to be in a few years.
"IMHO "restrictions" would be a better word then "protection". Only a very small number of people benefit from Digital Restrictions Management. For others it is just something restricting what they can do with the art they have bought. "Protection" really is one of the words the big media wants you to use. DRM is for their "protection", not yours."
"Restrictions" are policy. "Protections" are mechanism. They don't refer to the same thing. For example, Apple could loosen or strengthen the restrictions in iTunes without changing the protection technology they use.
If you can suggest a synonym for "protection" that has a negative spin, I'll consider using it.
RFID chips use milliwatts of power, barely enough to carry the signal a few meters. Cell phones use thousands of times more power.
Someone using a cell phone in your immediate vacinity is much worse.
"If it's digital, and the end user can see / hear it, it can be copied. Perfectly."
The act of stripping the DRM puts the user in a different legal position. I think the industry's threshold is the point where users must go to significant lengths to get around it. For projection that, for example, is based on a CD that autolaunches DRM software, users can reasonably argue that they didn't even realize there was protection (they use Mac or Linux, or have autolaunch turned off or something).
I don't think you can really get significnatly better (read: harder to copy) than FairPlay on a general purpose computer. Until you can (eg, DRM hardware is standard), the industry will probably allow the current situation to continue.
The dual-core MPC8641D will apparently use 15 watts (probably for the slowest one). Assuming that number is running flat out (the information site is for the embedded version so I assume it is flat out), it's about as much fully loaded as the slowest G5 uses idle. More suitable for a laptop.
Even the single core one would be better, as the bus speed isn't quite so hilarious.
Also, I think the G5s are already cheaper for Apple to buy...
PowerBooks are not currently fast enough for CPU-bound tasks that they're supposed to be able to do*. The only question in my mind is whether Apple decided to fasttrack G5s into the PowerBook line or if they decided it would be better to do the non-trivial redesign required for the new chips** from Freescale (aka Motorola).
I'm on the fence.
On the one side, using the new Freescale chips would require a lot of design work that will go out the window when G5s become low power enough to go in laptops. That might not be this year, but it will be in the next few years.
On the other side, maybe that work won't go out the window. Even though PowerBooks will be 64-bit in the next few years no matter what, the chipsets and other design work can be recycled in the budget lines, which will no doubt be using 32-bit chips for some time into the future.
One thing is certain: PowerBooks are not currently competitive in areas that are primarily CPU-bound (heavy graphical work, video editing/encoding, etc). They're falling behind now and when Centrino II comes out they won't even be worth mentioning. Apple needs something very soon. Therefore, it is reasonable to assume they are currently doing their best to move heaven and earth to make something happen before it's too late.
Now, I believe it's time for me to get modded down for being critical of an Apple machine. Better get started before too many people read this.
* - I know your PowerBook is more responsive than a much faster Windows machine. I'm talking about CPU bound tasks that aren't necessarily interactive. Any responses involving day-to-day user experience will be ignored because I'm not addressing that.
** - Freescale has a slightly faster PowerPC chip that's pin-compatible but doesn't upgrade the bus. They also have single and dual-core chips that scale to higher clock speeds and have on-die memory controllers, eliminiating most of the need for a fast bus. These faster chips are not pin-compatible and would also require a new chipset due to the on-die memory controller. None are 64-bit.
"I can see both sides. Everything you're saying makes perfect sense, but I can also imagine an influx of new users on the mailing lists complaining that some freak glitch in their ISA sound card won't let them install FreeBSD."
That's why you have a "safe mode" or something functionally equivilant. Problem drivers can be disabled in the one case in ten thousand where they misbehave.
"They don't have the installation base of Linux (and the huge number of fault-finding eyes that goes with it), or the "if you don't like it, fix it and send a patch" attitude of some of the OpenBSD support forums."
bah. I think that's a red herring. Linux 2.6 still breaks something new with every release (libata is a disaster), while OpenBSD works very nearly perfectly with all supported hardware. Granted OpenBSD doesn't support as much hardware, but FreeBSD has vastly more resources in terms of developers, funds, and users for testing. Particularly desktop users.
The "if you don't like it fix it" attitude is mostly for features or design issues. For things like driver bugs, the developers really don't like them existing at all. I've had developers get so annoyed that a bug even exists that they hounded me to get details past what I was originally willing to provide.
However, I don't agree with all the attitudes of OpenBSD developers so please don't respond as though I'm unconditionally supporting their conduct because I'm not.
"Maybe, I am waxing "intellectual", but the fact that the x86 with its ugly instruction set and gross addressing modes has dominated the market really disappoints me."
Partly because you're wrong, and partly because it doesn't matter.
To elaborate:
I will concede that the x86 instruction set is not pretty, but I would argue that it doesn't matter. Specifically, it only matters a little bit to people that program in assembly, and it doesn't matter at all to people that use compilers (the vast majority). As transistor counts have gone up, the added difficulty of supporting x86 has dropped to less than 5% of the transistors on the chip, probably less than that now that everyone has giant caches. Also, x86 binaries tend to be smaller (as x86 doesn't have to use fixed size opcodes) which saves a not-insignificant amount of cache and memory bandwidth.
The "gross addressing modes" are only relevant in real mode. In 32-bit protected mode or 64-bit mode, the address space is flat just like PowerPC. None of the popular OSes being distributed for x86 uses real mode (*BSD, Linux, Windows 2000 and later). Sure, the computer spends a few seconds in real mode after you turn it on and before the OS loads... but who cares?
"Why can't the better (from an engineering point of view) instruction set architecture (i.e. PowerPC) win in the desktop market?"
Because there's no significant benefit.
"FreeBSD tends to leave such decisions to the user, and isn't as cautious about providing modules as OpenBSD."
Yeah. That's why it's annoying. If the driver causes problems, fix it. If it doesn't cause problems, why not load the module automatically when the relevant hardware is present? Give users the option of opting out, fine, but all it does is make life difficult for users at the moment.
When I refferred to OpenBSD being easier to use, this is the sort of thing I meant.
"Sure (although that won't help for IPv6)."
Doesn't PF support IPv6?
"While I believe you, I'd be interested to know how you know that."
It's obvious from the performance of the thing. I know the OS is capable of high network performance because it's used in high performance areas. I assume the rest of the machine is not hobbled in some other way, as the machine performs okay in other respects. The only likely candidate is the network interface itself.
"how does one learn the manufacture of the low-level components of a MLB, when that info is not available from the vendor?"
The BSDs and Linux people generally figure that stuff out pretty quick. Even if a device identifies itself differently, if it has the same interface and the same bugs as a known chipset, it's pretty obvious what it is.
"I'm honestly not sure what you're talking about. There are quite a few ports that accept environmental variables to decide with optional dependencies to compile in. For example, if you set "WITHOUT_X11='YES'", then ports will avoid requiring xorg (or xf86 on 4.x) whenever possible. Ports are pretty good about letting you know which options you can select, and you can put all of those definitions in a single file so that you don't have to remember them each time."
/boot/loader.conf:
/etc/modules on a Linux system."
:-) I host a few webservers, a Freenet/Gnutella/IRC server, and my ISP's newsserver inside their own jails on my server at home with almost zero CPU overhead. The only downside is that you can only assign one IPv4 address to each jail right now, although that's being worked on"
The only case I specifically remember was kuickshow not being part of kdegraphics (to avoid adding a dependency) unless a certain variable was set. I guess I just didn't have enough experience with FreeBSD to know where to look, but it was pretty annoying. And even then, it would be annoying to have to read a bunch of docs to find out what optional stuff I need to do, when I don't necessarily know what I want (eg I haven't used the software before).
"To enabling the drivers for my SB Live! card, I added this to
snd_emu10k1_load="YES"
which would be analogous to adding an entry to
I didn't have to mess with anything to get sound working on the same machine with OpenBSD or Linux. Besides, "same as Linux" is not a particularly lofty standard.
"That is such an understatement.
Can't you do NAT for the various jails? The firewall is global to all jails.
Theo says jails aren't the way to go, but it keeps OpenBSD out a lot of areas that FreeBSD is currently popular. Same goes for the lack of jails on Linux.
I've tried them all and they're so different from each other that one won't really give you a very good idea of what the others are like.
OpenBSD is probably the easiest. Most things are in a working configuration by default, they just need to be switched on. FreeBSD has more software and better performance, but it's never been worth it for me because you have to mess around with the kernel and stuff (We're not on Linux, after all). I had to manually enable modules to get things like sound and set all sorts of environment variables to get some of the ports to work right. On OpenBSD it pretty much works the first time you boot it if it's going to work at all. The security is a bonus, but mostly I like how little work it takes to maintain.
FreeBSD is a bit more up to date, and has more powerful features (I love jails). I usually fall back on it if I need one of the features.
I don't really see much point in NetBSD, but given the number of people that use it and like it it's probably worthwhile to take a look.
DragonFly is still close enough to FreeBSD in terms of user experience that you might be able to skip it if you don't like FreeBSD.
They're all pretty easy to install. Give 'em a shot.
Google doesn't have those phrases... do you know where I could find the full text?
"Why not? Or is this yet another empty "marketting-statement?""
The Gentoo developers do not make any guarantees that the Portage tree will be in a consistent state at any given time.
Anyone that's used Gentoo for any period of time has had breakage. Usually, it's a matter of a quick update or at worst a stop by the forums. However, sometimes the breakage exists for longer or is harder to fix. Businesses cannot afford to take this risk.
I no longer use Gentoo because breakage almost caused me to miss deadlines on more than one occasion. It's my ass when it goes wrong, so I won't put myself in a position where I'm taking responsibility for an OS that doesn't guarantee me that they'll even test something before it's released. One of the instances of breakage (IIRC, the required version of fam was masked for the KDE-3.2 update) would have been caught if anyone had tried it on a stable system before release.
Portage is a very powerfull tool, and if someone would take a snapshot of the portage tree and then spend 6 months working the kinks out of it I'd give it a shot. But that hasn't happened.
The thing with a jail is that it'll be running on a very high end machine (unfortunately FreeBSD doesn't have a decent PowerPC port yet, otherwise an Xserve would be ideal for this) (also unfortunately, MacOS doesn't seem to have the jail facility, so you can't do the jails with MacOS would would also be ideal), and it's probably set up to failover onto another machine if it goes down. You're paying for the reliability.
If your Mac mini goes down, you could be SOL for weeks.
The value you place on reliability is of course completely up to you.
Apple doesn't tend to use very good network chipsets in their low end desktop machines. They eat a lot of CPU time and don't go very fast. Doesn't matter in a desktop machine, but it hurts in a server, even at slow colo speeds.
Probably doesn't hurt as much as the laptop drive anyway. Besides, people probably don't want these as high-load servers. The probably just want something off-site.
I think people want to use them because sometimes you just need something online all the time, even if the hardware can't support a high load. It's still a bad position to be in because the laptop drives don't need high load to kill them, but as you say there aren't a lot of options.
;)
Any comment on how unreliable macslash is?
For cluster computing, it's gigabit minimum. Preferably something better. For example, the Big Mac cluster uses Infiniband, a low-latency network technology.
100 is good enough for desktop use, and good enough as a web server, but it's not good enough for cluster computing.
"except for the few proprietary bits of Firefox which don't really add to the functionality"
I assume you are refferring to the name and logo?
(I'm still getting used to the icon Debian uses)
Interesting that they're building ties to Firefox, a browser that also provides a developer-friendly framework for extensions. :)