It's what I run at work, runs well but have to know what you intend on using it for. Also IME KDE 4 is easier to install and has less quirks than on linux.
Virtualbox runs vista quite well for me so it takes care of that problem to.
If you run 64 bit, use the nouveau driver, it's far better than nv.
Of course this is in response to the legal situation, but DHT is a better method provided users get their clients configured correctly and ports forwarded. Your comment implies they are switching to an inferior technology which is certainly not the case. It's far more fault tolerant and less prone to bottlenecks, it simply requires more from the user. As more sites switch to this method, swarms will increase in size and throughput with less liability for all. I'm glad this finally happened.
Congrats, you've successively cut off a head from the hydra.
Now if mdadm only had the ease use gmirror/geom does in freebsd, then it might be more widely adopted.
mdadm is a perfectly functional package, but it's setup is quite awkward. gmirror however is a breeze to setup, and it's performance kicks the crap out of most hardware controllers I've tried(admittedly few). I imagine OpenBSD implementation is also a good performer as software raid. This states a 30% speedup for certain cases. http://www.openbsd.org/plus.html
VM's are great for many things. First off, know that most hardware is severely under-utilized. Then factor in the ease of replication, testing, security(via sandboxing and other methods), ability to scale horizontally quickly. There are downsides too of course which is why we prefer to run our own XEN setup, then use http://www.eucalyptus.com/ light up more VM's in case of load need or disaster.
VM are a huge cost saver, and the fastest development environment.
I'm not really sure, but I do remember this was right around the time 7.0 was released, and was shortly after the introduction of the completely fair scheduler.
I suppose that's a bit closer, but it still doesn't address the differences between fs defaults. ext4 is far more aggressive than ufs2 is by default. A closer comparison would have be to gjournal ufs and mount async which would have been a relatively close comparison to ext4, but that still would not be a fair io comparison as gjournal scales incredibly well but can double write time on single write. I am struggling to comprehend ext4 as a default filesystem in a server(or anywhere) however, considering it still has crash corruptions issues.
That's to be expected considering the defaults of ext4 vs ufs2. You can increase flush time on ufs2 and expect a similar increase. Revert to ext3 and it would be a completely different outcome. Interesting to see all the chest pounding on choice for default settings in a desktop enviro vs a traditionally server one. Would have been a been comparsion to use the upcoming PCBSD's release vs Ubuntu's, but we've seen the bias from Phoronix before.
Um no that's incorrect by demonstration. Generally speaking, heavy committers to a project have a heavily vested interest in it. How much bigger of a stick do you need than your livelihood? Fringe contributors may fall under your critism, but fringe contributors also exist in proprietary development with the same lack of consequence.
I'm not saying opensource can't develop bloat, because as it happens I agree with Linus's comments. However, more centrally managed projects like the BSD's and Horde are excellent examples of solid widescale development techniques. To accept the premise those projects are good examples, then go back and say opensource is a flawed development model is nothing short of FUD.
In FreeBSD, you chose to accept a project. If you fail to perform, you are replaced with another volunteer. It doesn't matter if you're a core committer or a port maintainer, it all works that way. There are occasional problems but overall a successful approach. Many other opensource projects do the same. That's why hierarchies work in opensource--they hold people accountable just like in a proprietary project.
I've never experienced "shakiness" under high load on 6.x, but 7.x saw the introduction of a much improved SMP, and a new scheduler which saw dramatic performance increases under many usage types.
Early 5.x was a bit flaky, though it was fairly stable by the end of the line. 6.x was late in coming though, so many were eager to migrate. 5.x is in many ways too old to be a valid comparison anymore though, as I don't see many complaints about linux kernel 2.4.x even though they had their own set of issues. Every OS I've ever used has had it's own sets of gotchas, but stability on BSD has never been one with proper planning.
My lifetime oil changes cost me $350. Seems like a decent deal to me, as DIY style leaves me with a disposal conundrum. My dealership experience has actually been much better than anticipated, that being said I still prefer my small mechanic shop for most stuff.
If Chrome ever gets the necessary add-ons, such as AdBlock Plus, I'm guessing that people will abandon Firefox. There seems to be no hope that Mozilla Foundation will ever be managed well.
If Chrome ever gets the necessary add-ons, it's performance will be on par with FF.
If you're suggesting the reason behind my 4 returns, 3 under warranty, were due to poor ventilation, you're incorrect. My thermostat is set to 68F despite complaints from the GF and my 360 sits in open air ps and console. Only 2 of my returns where due to ROD, the preeminent heating/manufacturing issue with the 360. I don't know about upright useage either, I've heard enough complaints about that as well.
Re:Karma burning for fun and profit
on
KDE 4.3 Released
·
· Score: 1
Q. What does plasma have to do with your video driver?
Re:7 million new lines of code?
on
NetBSD 5.0 Released
·
· Score: 3, Informative
xorg-server-1.5.3 isn't really stable yet, especially for NetBSD, but we're on the cusp of the migration. If NetBSD is including 1.3 then all the fixing and configuring admins will have to do will be wasted when 1.5.3 breaks everything again.
I've got no idea about NetBSD, but xorg server 1.6 has worked great on my system for months on FreeBSD 7.1 and 7-stable. 1.5.x was fine too except for a few conf changes.
midco# pkg_info | grep xorg-server xorg-server-1.6.0,1 X.Org X server and related programs
It's what I run at work, runs well but have to know what you intend on using it for. Also IME KDE 4 is easier to install and has less quirks than on linux.
Virtualbox runs vista quite well for me so it takes care of that problem to.
If you run 64 bit, use the nouveau driver, it's far better than nv.
Of course this is in response to the legal situation, but DHT is a better method provided users get their clients configured correctly and ports forwarded. Your comment implies they are switching to an inferior technology which is certainly not the case. It's far more fault tolerant and less prone to bottlenecks, it simply requires more from the user. As more sites switch to this method, swarms will increase in size and throughput with less liability for all. I'm glad this finally happened.
Congrats, you've successively cut off a head from the hydra.
Yeah, you'd really be an idiot to pay retail and avoid dealing with Verizon.
I assume you've never had service with them. Reason they can raise termination rates is all supply and demand. Demand goes up, so do the prices.
galacticdominator% uname -a /home/adam/.mozilla/plugins/npwrapper.libflashplayer.so /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so
FreeBSD galacticdominator.com 8.0-RC2 FreeBSD 8.0-RC2 #2: Sun Nov 1 19:42:17 CST 2009 adam@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC amd64
galacticdominator% nspluginwrapper -l
Original plugin:
Wrapper version string: 1.2.2
for bloated, hard customize, even harder to build pig zimbra is, may as well use exchange.
Try Horde and maintain system requirements more inline with *nix standard workloads on a per user basis.
By failing to regulate it. Then again, the CEO didn't either.
Do you have any clue who is responsible for developing Common Address Redundancy Protocol?
You have other options too,
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/heartbeat/
or for a DRBD eqiv, try ggated + gmirror
http://serverbbs.ccw.com.cn/thread-14564-1-1.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html#INTRODUCTION-NUTSHELL-USERS
Many, many not listed, one example is php.net.
Now if mdadm only had the ease use gmirror/geom does in freebsd, then it might be more widely adopted.
mdadm is a perfectly functional package, but it's setup is quite awkward. gmirror however is a breeze to setup, and it's performance kicks the crap out of most hardware controllers I've tried(admittedly few). I imagine OpenBSD implementation is also a good performer as software raid. This states a 30% speedup for certain cases. http://www.openbsd.org/plus.html
VM's are great for many things. First off, know that most hardware is severely under-utilized. Then factor in the ease of replication, testing, security(via sandboxing and other methods), ability to scale horizontally quickly. There are downsides too of course which is why we prefer to run our own XEN setup, then use http://www.eucalyptus.com/ light up more VM's in case of load need or disaster.
VM are a huge cost saver, and the fastest development environment.
I'm not really sure, but I do remember this was right around the time 7.0 was released, and was shortly after the introduction of the completely fair scheduler.
A bit dated,
http://people.freebsd.org/~kris/scaling/os-mysql.png
I suppose that's a bit closer, but it still doesn't address the differences between fs defaults. ext4 is far more aggressive than ufs2 is by default. A closer comparison would have be to gjournal ufs and mount async which would have been a relatively close comparison to ext4, but that still would not be a fair io comparison as gjournal scales incredibly well but can double write time on single write. I am struggling to comprehend ext4 as a default filesystem in a server(or anywhere) however, considering it still has crash corruptions issues.
http://en.wikipedia.org/wiki/Ext4
http://onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=3
That's to be expected considering the defaults of ext4 vs ufs2. You can increase flush time on ufs2 and expect a similar increase. Revert to ext3 and it would be a completely different outcome. Interesting to see all the chest pounding on choice for default settings in a desktop enviro vs a traditionally server one. Would have been a been comparsion to use the upcoming PCBSD's release vs Ubuntu's, but we've seen the bias from Phoronix before.
Um no that's incorrect by demonstration. Generally speaking, heavy committers to a project have a heavily vested interest in it. How much bigger of a stick do you need than your livelihood? Fringe contributors may fall under your critism, but fringe contributors also exist in proprietary development with the same lack of consequence.
I'm not saying opensource can't develop bloat, because as it happens I agree with Linus's comments. However, more centrally managed projects like the BSD's and Horde are excellent examples of solid widescale development techniques. To accept the premise those projects are good examples, then go back and say opensource is a flawed development model is nothing short of FUD.
In FreeBSD, you chose to accept a project. If you fail to perform, you are replaced with another volunteer. It doesn't matter if you're a core committer or a port maintainer, it all works that way. There are occasional problems but overall a successful approach. Many other opensource projects do the same. That's why hierarchies work in opensource--they hold people accountable just like in a proprietary project.
Properly managed opensource projects deal with this appropriately, some do not.
Properly managed proprietary projects deal with this appropriately, some do not.
I've never experienced "shakiness" under high load on 6.x, but 7.x saw the introduction of a much improved SMP, and a new scheduler which saw dramatic performance increases under many usage types.
Early 5.x was a bit flaky, though it was fairly stable by the end of the line. 6.x was late in coming though, so many were eager to migrate. 5.x is in many ways too old to be a valid comparison anymore though, as I don't see many complaints about linux kernel 2.4.x even though they had their own set of issues. Every OS I've ever used has had it's own sets of gotchas, but stability on BSD has never been one with proper planning.
My lifetime oil changes cost me $350. Seems like a decent deal to me, as DIY style leaves me with a disposal conundrum. My dealership experience has actually been much better than anticipated, that being said I still prefer my small mechanic shop for most stuff.
If Chrome ever gets the necessary add-ons, such as AdBlock Plus, I'm guessing that people will abandon Firefox. There seems to be no hope that Mozilla Foundation will ever be managed well.
If Chrome ever gets the necessary add-ons, it's performance will be on par with FF.
If you're suggesting the reason behind my 4 returns, 3 under warranty, were due to poor ventilation, you're incorrect. My thermostat is set to 68F despite complaints from the GF and my 360 sits in open air ps and console. Only 2 of my returns where due to ROD, the preeminent heating/manufacturing issue with the 360. I don't know about upright useage either, I've heard enough complaints about that as well.
Q. What does plasma have to do with your video driver?
A. Nothing.
What about Rod Johnson's Perl necklace?
xorg-server-1.5.3 isn't really stable yet, especially for NetBSD, but we're on the cusp of the migration. If NetBSD is including 1.3 then all the fixing and configuring admins will have to do will be wasted when 1.5.3 breaks everything again.
I've got no idea about NetBSD, but xorg server 1.6 has worked great on my system for months on FreeBSD 7.1 and 7-stable. 1.5.x was fine too except for a few conf changes.
midco# pkg_info | grep xorg-server
xorg-server-1.6.0,1 X.Org X server and related programs
That would be under the NEVER category.