It's not silly. It actually lets you go faster, and more safely with less road congestion. Why? Because slower traffic ends up on the inner lane, going progressively faster to the outer lane. So it's actually not silly at all in heavy traffic. It means slow traffic doesn't impede faster traffic, and it means that the driver can make certain assumptions about the driving conditions, e.g. they won't be overtaken on the inside, which makes lane changes easier and safer. It makes driving on fast roads predicable since you know how the other traffic will behave.
Of course, there are some idiots who don't know how to drive and hog the middle lane, and are universally hated for it; they get pulled over by the police since it's actively dangerous to the other traffic--because it can force people to undertake.
When you look at footage of road accidents in countries without this rule, what's immediately clear is that the driving is far more erratic since it's an unconstrained free-for-all, and that makes accidents more likely, as well as reducing the effective safe speed on the road.
If you're not overtaking, you have no business being in that lane. That's what the outer lanes are *for*. It's people who don't understand that simple rule that cause accidents. Undertaking is illegal e.g. in the UK for a reason.
I've seen this too, it's definitely fishy and underhanded. The crazy thing about all this is that its main effect is to destroy my already limited trust in Microsoft. Before I at least trusted that, even if occasionally broken, the updates were at least generally beneficial and I had recommended updates installed automatically. I no longer have any trust that my machine is my own and that I'll be able to continue to use it. I already had to manually clean up and hide all the updates which trigger upgrades; what a waste of my time. And who knows how long it will last. I don't want to have to research and vet every update.
The other crazy thing is that if they hadn't forced the telemetry, cortana, and forced updates, I'd have been perfectly happy to upgrade to Windows 10 months ago. Merely having clear and obvious options to fully disable them all would have been sufficient. And some real transparency over what's really being collected. It's just too much to accept. There's no way they have any business collecting this information--I simply won't be allowing it.
So an own goal for MS here. As it is, as I type this I'm installing Windows 7 in a VM, where it can live safely off the net, and be snapshotted and backed up, and exist indefinitely whatever MS may do in the future. Daft that it's come to this, but it's entirely self-inflicted. Strange that they seemingly want to kill of any serious use of their stuff.
The behaviour of RedHat and Ubuntu and others for the last few years has appeared to be a kind of replay of the Unix wars of the '80s and '90s. A major factor in the rise of Linux. Vendor-specific programs and tools, or vendor-specific modifications of existing libraries and programs to lock you in (or preventing patches to add such being refused, which is the same thing in reverse). upstart, systemd, appindicators (and the games by upstream GNOME). There's plenty more besides. Intentions aside, these have all served to disrupt and fragment the Linux ecosystem, and have not done anything to help its long-term adoption and survival.
I thought they might be laser dots as well, but take a close look at all the pictures, and you can see purple random scattering on most of them to varying degrees, most intense on the ones with the machine in view. It's not the emission or reflection of light source(s) that I can see. Linear accelerators can apparently (just been reading up on it) also cause local activation of materials, though far less than proton and neutron beams, so it could potentially be recording very low level of decays from that.
Amazing machine and staff. Slightly worrying are the radiation spots on the CCD of his digital camera for the shots of the machine and the treatment room, which makes me wonder how much dosage the technicians who operate it pick up, and also how intense the beam is when the aperture is opened up.
I can definitely sympathise with the fear of confinement. I had a head MRI a few weeks back, and it was in a small mobile scanner. While I'm not claustrophobic, it was definitely confining, and this process where you're directly restrained looks like it could be really terrifying if you can't deal with confinement.
No, it's not electrical activity, it's even less direct. MRI is essentially measuring fluid (blood) flow, the assumption being that areas with higher flow are more active, due to having higher metabolic demands. Which is quite a reasonable assumption, but it's not a direct observation. It's not actually measuring flow, it's sampling the spin of nuclei aligned in a strong magnetic field; if it's solid the relaxation time will be slower than for molecules like water in a freely moving fluid. There's obviously much more to it than this basic description, but that's essentially what it's measuring in most typical applications.
"Anything is possible"? No, basic physics can't be worked around. More mass means more fuel to achieve an equivalent acceleration. You can make things more efficient, up to a point, but you can't make a heavy vehicle use less fuel than a lighter vehicle. Moving mass requires work proportional to the mass.
I think you're discounting the multi-year effort of strong-arming all the other distributions into adopting it. The "easier maintenance" is a talking point which ignores that the distributions already had done the work of writing the init scripts. This was a non-issue. It's not like the init script for a given package changes much once written.
The on-disk structures used by ReiserFS had some significant defects, as did its fsck tool. It might have been faster than ext, but not in my experience more reliable.
"significant amount of resources have been released"
Want to back that up with some facts? Given the vast size of the codebase compared with sysvinit, the fact that it has to main a complex dependency graph in memory, and do binary logging, and talk to other processes over dbus, and parse unit files, and run multiple other daemons, etc., I find it very hard to believe it could possibly use less resources. All that functionality has a cost.
Btrfs has more features than ZFS? Are you sure you didn't mean the opposite, because in the world I live in, ZFS is both vastly more capable than Btrfs and vastly more robust. I used to use Linux with mdraid+LVM and also used Btrfs for a period; I switched to FreeBSD specifically for ZFS and haven't looked back.
With respect to virtualisation, have you tried jails? I'm running multiple jailed servers on a single machine. It works just fine. There's also bhyve, which I haven't played with yet. No VMware host, but that doesn't stop you running FreeBSD guests on any VMware host platform--this also works just fine. Why not just do that?
With respect to video drivers, recent releases have decent DRI and KMS and you get decent graphics with radeon cards. The main annoyance I had was power/fan control. And since I upgraded my graphics card to an R9 390, I'm now have an unsupported graphics card. At least temporarily. While it's fine to criticise that it's behind the current state of the art for Linux, it's important to balance that with the acknowledgement that graphics support in FreeBSD has come on in leaps and bounds over the last 18 months, and it is continuing to improve. I'm sure my graphics card will be supported in the not too distant future, at which time running a BSD on the desktop will be fine for me. I could get an nVidia and use their proprietary driver, but I'm happy to wait for a decent open radeon driver.
For QC based on individual items, you might test a small percentage, for batch-based products you might also do tests on every batch as a whole at every stage of its production, plus randomised testing of individual packaged units. I used to work in a QC laboratory, doing testing of both. For some tests, we would also run known standards every time we tested an unknown sample, or set of samples to ensure that the results were always accurate, and always ran both multiple replicates of the standard and multiple replicates of each sample to ensure they were consistent within a certain standard deviation. This guards against calibration errors on the machines and errors on the part of the sample prep or operator. We would occasionally also send samples to external independent laboratories to verify the accuracy of our processes. In this case it wasn't forensics, and there was no need for anonymising the samples. For forensics, I would have hoped that they would also be running anonymous control samples through the pipeline as well (both negative and varying degrees of positive) to validate their process. The technicians don't even need to be aware of it--you simply introduce them as incoming test samples and then validate that the results matched the expectations after testing is done and logged.
Re:Why do you like KDE?
on
KDE Turns 19
·
· Score: 1
I tried out the trinity PCLinuxOS livecd last week. What a blast from the past! The unreal bit: it was faster to start up Trinity applications from the *DVD* than it is to start the equivalent current KDE application from an *SSD*. Click on Konsole, *bam, there it is. Do the same with current KDE and there's a noticeable multi-second wait.
I'm tempted to install PCLinuxOS or some other system providing Trinity. The only problem I had with PCLinuxOS was the older kernel and X11 couldn't support my GPU (R9 390) or displayport (it turned off the transmitter and the monitor switches off). That's an old bug that's been fixed a while.
While I haven't done accurate timings, I think the boot is a few seconds longer (with 15.04) on my work machine. Annoyingly, it also made the boot less reliable--it now sometimes fails to boot completely and just hangs; presumably it's a race of some sort but who knows?
With the Linux compatibility layer, it's quite likely that FreeBSD could run Linux LSB applications.
FreeBSD uses heir(7) which is analogous to the FHS, and it's this that Debian is retaining support for. The major difference is the lack of libexec in the FHS, the omission being down to some fairly unbelievable politicking way back when.
It was simply one example (of several similar examples) which happened over a long period of time. I've suffered every time I've used it, from its early days right up to last year. Yes, that particular bug is gone. But there are plenty more which took its place and were similarly awful.
The snapshot issues are the ENOSPC metadata/data block allocation bug; I didn't report it because it's well known. So much so that it's on the Btrfs wiki. I've not seen any evidence that it's been fixed in the meantime.
Regarding fsync, maybe it's been improved in the last year. I won't hold my breath though. It's a fundamental problem with using b-trees as the on-disk structure; you're forced to write out all prior pending transactions in addition to your own in order to maintain correct operation ordering and consistency within the tree. Maybe they found a way around that, if so I'd be interested in any pointers.
This isn't a problem with the tools though. Having immutable snapshots is a part of the design, and a good feature at that. Writable snapshots with Btrfs cause more problems than they solve; most of the time I want the snapshot to be an immutable snapshot of the state at a certain point in time and being writable removes that certainty.
If you have this requirement, then make a clone, delete the file and snapshot the clone; you now have a snapshot with the offending file removed. Slightly annoying, yes, but certainly possible.
You might think the layered approach would make sense, but actually the separation of concerns prevents the system from doing things intelligently. For example, consider what happens when a disk fails and is replaced. In the layered case, the md layer or the hardware RAID controller will resync the data. This will be a simple linear reconstruction of the data. In the ZFS case, it only copies the missing data; unused blocks are not uselessly synced. This is called "resilvering". This isn't just faster, it also increases the chances of successful resyncing since the probability of failure during reconstruction is reduced.
As others have mentioned in reply, there are a number of other useful practical advantages as well.
This particular incident was on a much older kernel; this bug is now fixed.
But I've been testing Btrfs regularly since the start. Every single time I've retried testing with it, I have hit a different bug or design flaw. It's been a repeated pattern since the start. It's gotten better for sure, but it's never reached the point of being truly solid, or performant. I can't trust it with my data, which is of course its primary purpose.
The last time I used it in anger, I was doing repeated whole-archive rebuilds of Debian. Guess how long it ran before failing? 36 hours. That's it. 1.5 days from pristine new filesystem to unusable wreck. I'm hitting the "totally unbalanced" bug which makes the filesystem go readonly, and is "fixed" by rebalancing. But this bug means that the filesystem could randomly go readonly *at any point in time* with no warning. You couldn't possibly rely on that in production if it could fail at any moment, but that's the awful reality of the design of Btrfs. Now this is thrashing the disk continuously with several snapshots being created and deleted in parallel every minute, but imagine how long it would take on a typical fileserver or desktop. I don't know, I guess it might be usage- or load-dependent. And that's the point, it's an unknown; it could happen at any time to anyone using Btrfs. This is not really a bug; it's a fundamental design flaw.
And apart from the bugs and design flaws, the performance is awful. For Debian package builds, while snapshotting was really fast, we had to deliberately disable all use of fsync due to this killing performance entirely while running dpkg. Arguably also a design flaw due to the way fsync forces a flush of the whole filesystem. No other filesystem has performance characteristics this bad.
It can certainly work when everything is working correctly. Have you tested its behaviour when things don't work correctly, for example by pulling the cable on one of the discs as it's running? Does it carry on running, does it transparently recover when you plug it back in? When I had a cable become unseated and the connection glitched, Btrfs happily toasted the data on the drive, and its mirror, and panicked the kernel whenever the discs were plugged in; I had to zero them out on another system before I could even try to reformat them. One of the major historical weak points has been that the failure codepaths were poorly tested, and this can come to bite you quite badly.
I mean the performance gains as you add more discs.
And regarding adding discs to an array, you certainly can. Just add addtional raid sets to the pool. That is, rather than adding discs to the existing array, you scale it up by adding additional arrays to the same pool. See the documentation.
It's really quite simple. ZFS is a great filesystem. It's reliable, performant, featureful, and very well documented. Btrfs has a subset of the ZFS featureset, but fails on all the other counts. It has terrible documentation and it's one of the least reliable and least performant filesystems I've ever used. Having used both extensively over several years, and hammered both over long periods, I've suffered from repeated Btrfs dataloss and performance problems. ZFS on the other hand has worked well from day one, and I've yet to experience any problems. Neither are as fast as ext4 on single discs, but you're getting resilience and reliability, not raw speed, and it scales well as you add more discs; exactly what I want for storing my data. And having a filesystem which works on several operating systems has a lot of value. I took the discs comprising a ZFS zpool mirror from my Linux system and slotted them into a FreeBSD NAS. One command to import the pool (zpool import) and it was all going. Later on I added l2arc and zil (cache and log) SSDs to make it faster, both one command to add and also entirely trouble-free.
Over the years there have been lots of publicity about the Btrfs featureset and development. But as you said in your comment that it's "rapidly getting there". That's been the story since day one. And it's not got there. Not even close. Until its major bugs and unfortunate design flaws (getting unbalanced to unusability, silly link limits) are fixed, it will never get there. I had high hopes for Btrfs, and I was rewarded with severe dataloss or complete unusability each and every time I tried it over the years since it was started. Eventually I switched to ZFS out of a need for something that actually worked and could be relied upon. Maybe it will eventually become suitable for serious production use, but I lost hope of that a good while back.
I'm in pretty much the same situation. Server-side, I'm now 100% FreeBSD; client-side I'm using a mixture of MacOSX/Windows/FreeBSD/Linux (Debian unstable w/ pinned sysvinit) but ideally I'd like a FreeBSD or Linux desktop with full graphics support. I currently have an AMD R9 390 GPU which would be excellent were it not for the lagging driver support on both platforms. I've been playing around with a few minor Linux distributions; shame all the mainstream ones are no longer suitable.
Slashdot Mirror
It's not silly. It actually lets you go faster, and more safely with less road congestion. Why? Because slower traffic ends up on the inner lane, going progressively faster to the outer lane. So it's actually not silly at all in heavy traffic. It means slow traffic doesn't impede faster traffic, and it means that the driver can make certain assumptions about the driving conditions, e.g. they won't be overtaken on the inside, which makes lane changes easier and safer. It makes driving on fast roads predicable since you know how the other traffic will behave.
Of course, there are some idiots who don't know how to drive and hog the middle lane, and are universally hated for it; they get pulled over by the police since it's actively dangerous to the other traffic--because it can force people to undertake.
When you look at footage of road accidents in countries without this rule, what's immediately clear is that the driving is far more erratic since it's an unconstrained free-for-all, and that makes accidents more likely, as well as reducing the effective safe speed on the road.
If you're not overtaking, you have no business being in that lane. That's what the outer lanes are *for*. It's people who don't understand that simple rule that cause accidents. Undertaking is illegal e.g. in the UK for a reason.
I've seen this too, it's definitely fishy and underhanded. The crazy thing about all this is that its main effect is to destroy my already limited trust in Microsoft. Before I at least trusted that, even if occasionally broken, the updates were at least generally beneficial and I had recommended updates installed automatically. I no longer have any trust that my machine is my own and that I'll be able to continue to use it. I already had to manually clean up and hide all the updates which trigger upgrades; what a waste of my time. And who knows how long it will last. I don't want to have to research and vet every update.
The other crazy thing is that if they hadn't forced the telemetry, cortana, and forced updates, I'd have been perfectly happy to upgrade to Windows 10 months ago. Merely having clear and obvious options to fully disable them all would have been sufficient. And some real transparency over what's really being collected. It's just too much to accept. There's no way they have any business collecting this information--I simply won't be allowing it.
So an own goal for MS here. As it is, as I type this I'm installing Windows 7 in a VM, where it can live safely off the net, and be snapshotted and backed up, and exist indefinitely whatever MS may do in the future. Daft that it's come to this, but it's entirely self-inflicted. Strange that they seemingly want to kill of any serious use of their stuff.
I did move on... to FreeBSD.
The behaviour of RedHat and Ubuntu and others for the last few years has appeared to be a kind of replay of the Unix wars of the '80s and '90s. A major factor in the rise of Linux. Vendor-specific programs and tools, or vendor-specific modifications of existing libraries and programs to lock you in (or preventing patches to add such being refused, which is the same thing in reverse). upstart, systemd, appindicators (and the games by upstream GNOME). There's plenty more besides. Intentions aside, these have all served to disrupt and fragment the Linux ecosystem, and have not done anything to help its long-term adoption and survival.
I thought they might be laser dots as well, but take a close look at all the pictures, and you can see purple random scattering on most of them to varying degrees, most intense on the ones with the machine in view. It's not the emission or reflection of light source(s) that I can see. Linear accelerators can apparently (just been reading up on it) also cause local activation of materials, though far less than proton and neutron beams, so it could potentially be recording very low level of decays from that.
Amazing machine and staff. Slightly worrying are the radiation spots on the CCD of his digital camera for the shots of the machine and the treatment room, which makes me wonder how much dosage the technicians who operate it pick up, and also how intense the beam is when the aperture is opened up.
I can definitely sympathise with the fear of confinement. I had a head MRI a few weeks back, and it was in a small mobile scanner. While I'm not claustrophobic, it was definitely confining, and this process where you're directly restrained looks like it could be really terrifying if you can't deal with confinement.
Thunderbird 2
No, it's not electrical activity, it's even less direct. MRI is essentially measuring fluid (blood) flow, the assumption being that areas with higher flow are more active, due to having higher metabolic demands. Which is quite a reasonable assumption, but it's not a direct observation. It's not actually measuring flow, it's sampling the spin of nuclei aligned in a strong magnetic field; if it's solid the relaxation time will be slower than for molecules like water in a freely moving fluid. There's obviously much more to it than this basic description, but that's essentially what it's measuring in most typical applications.
F=ma so a=F/m
"Anything is possible"? No, basic physics can't be worked around. More mass means more fuel to achieve an equivalent acceleration. You can make things more efficient, up to a point, but you can't make a heavy vehicle use less fuel than a lighter vehicle. Moving mass requires work proportional to the mass.
I think you're discounting the multi-year effort of strong-arming all the other distributions into adopting it. The "easier maintenance" is a talking point which ignores that the distributions already had done the work of writing the init scripts. This was a non-issue. It's not like the init script for a given package changes much once written.
The on-disk structures used by ReiserFS had some significant defects, as did its fsck tool. It might have been faster than ext, but not in my experience more reliable.
"significant amount of resources have been released" Want to back that up with some facts? Given the vast size of the codebase compared with sysvinit, the fact that it has to main a complex dependency graph in memory, and do binary logging, and talk to other processes over dbus, and parse unit files, and run multiple other daemons, etc., I find it very hard to believe it could possibly use less resources. All that functionality has a cost.
Btrfs has more features than ZFS? Are you sure you didn't mean the opposite, because in the world I live in, ZFS is both vastly more capable than Btrfs and vastly more robust. I used to use Linux with mdraid+LVM and also used Btrfs for a period; I switched to FreeBSD specifically for ZFS and haven't looked back. With respect to virtualisation, have you tried jails? I'm running multiple jailed servers on a single machine. It works just fine. There's also bhyve, which I haven't played with yet. No VMware host, but that doesn't stop you running FreeBSD guests on any VMware host platform--this also works just fine. Why not just do that? With respect to video drivers, recent releases have decent DRI and KMS and you get decent graphics with radeon cards. The main annoyance I had was power/fan control. And since I upgraded my graphics card to an R9 390, I'm now have an unsupported graphics card. At least temporarily. While it's fine to criticise that it's behind the current state of the art for Linux, it's important to balance that with the acknowledgement that graphics support in FreeBSD has come on in leaps and bounds over the last 18 months, and it is continuing to improve. I'm sure my graphics card will be supported in the not too distant future, at which time running a BSD on the desktop will be fine for me. I could get an nVidia and use their proprietary driver, but I'm happy to wait for a decent open radeon driver.
For QC based on individual items, you might test a small percentage, for batch-based products you might also do tests on every batch as a whole at every stage of its production, plus randomised testing of individual packaged units. I used to work in a QC laboratory, doing testing of both. For some tests, we would also run known standards every time we tested an unknown sample, or set of samples to ensure that the results were always accurate, and always ran both multiple replicates of the standard and multiple replicates of each sample to ensure they were consistent within a certain standard deviation. This guards against calibration errors on the machines and errors on the part of the sample prep or operator. We would occasionally also send samples to external independent laboratories to verify the accuracy of our processes. In this case it wasn't forensics, and there was no need for anonymising the samples. For forensics, I would have hoped that they would also be running anonymous control samples through the pipeline as well (both negative and varying degrees of positive) to validate their process. The technicians don't even need to be aware of it--you simply introduce them as incoming test samples and then validate that the results matched the expectations after testing is done and logged.
I tried out the trinity PCLinuxOS livecd last week. What a blast from the past! The unreal bit: it was faster to start up Trinity applications from the *DVD* than it is to start the equivalent current KDE application from an *SSD*. Click on Konsole, *bam, there it is. Do the same with current KDE and there's a noticeable multi-second wait. I'm tempted to install PCLinuxOS or some other system providing Trinity. The only problem I had with PCLinuxOS was the older kernel and X11 couldn't support my GPU (R9 390) or displayport (it turned off the transmitter and the monitor switches off). That's an old bug that's been fixed a while.
While I haven't done accurate timings, I think the boot is a few seconds longer (with 15.04) on my work machine. Annoyingly, it also made the boot less reliable--it now sometimes fails to boot completely and just hangs; presumably it's a race of some sort but who knows?
FreeBSD uses heir(7) which is analogous to the FHS, and it's this that Debian is retaining support for. The major difference is the lack of libexec in the FHS, the omission being down to some fairly unbelievable politicking way back when.
It was simply one example (of several similar examples) which happened over a long period of time. I've suffered every time I've used it, from its early days right up to last year. Yes, that particular bug is gone. But there are plenty more which took its place and were similarly awful.
The snapshot issues are the ENOSPC metadata/data block allocation bug; I didn't report it because it's well known. So much so that it's on the Btrfs wiki. I've not seen any evidence that it's been fixed in the meantime.
Regarding fsync, maybe it's been improved in the last year. I won't hold my breath though. It's a fundamental problem with using b-trees as the on-disk structure; you're forced to write out all prior pending transactions in addition to your own in order to maintain correct operation ordering and consistency within the tree. Maybe they found a way around that, if so I'd be interested in any pointers.
This isn't a problem with the tools though. Having immutable snapshots is a part of the design, and a good feature at that. Writable snapshots with Btrfs cause more problems than they solve; most of the time I want the snapshot to be an immutable snapshot of the state at a certain point in time and being writable removes that certainty.
If you have this requirement, then make a clone, delete the file and snapshot the clone; you now have a snapshot with the offending file removed. Slightly annoying, yes, but certainly possible.
You might think the layered approach would make sense, but actually the separation of concerns prevents the system from doing things intelligently. For example, consider what happens when a disk fails and is replaced. In the layered case, the md layer or the hardware RAID controller will resync the data. This will be a simple linear reconstruction of the data. In the ZFS case, it only copies the missing data; unused blocks are not uselessly synced. This is called "resilvering". This isn't just faster, it also increases the chances of successful resyncing since the probability of failure during reconstruction is reduced.
As others have mentioned in reply, there are a number of other useful practical advantages as well.
This particular incident was on a much older kernel; this bug is now fixed.
But I've been testing Btrfs regularly since the start. Every single time I've retried testing with it, I have hit a different bug or design flaw. It's been a repeated pattern since the start. It's gotten better for sure, but it's never reached the point of being truly solid, or performant. I can't trust it with my data, which is of course its primary purpose.
The last time I used it in anger, I was doing repeated whole-archive rebuilds of Debian. Guess how long it ran before failing? 36 hours. That's it. 1.5 days from pristine new filesystem to unusable wreck. I'm hitting the "totally unbalanced" bug which makes the filesystem go readonly, and is "fixed" by rebalancing. But this bug means that the filesystem could randomly go readonly *at any point in time* with no warning. You couldn't possibly rely on that in production if it could fail at any moment, but that's the awful reality of the design of Btrfs. Now this is thrashing the disk continuously with several snapshots being created and deleted in parallel every minute, but imagine how long it would take on a typical fileserver or desktop. I don't know, I guess it might be usage- or load-dependent. And that's the point, it's an unknown; it could happen at any time to anyone using Btrfs. This is not really a bug; it's a fundamental design flaw.
And apart from the bugs and design flaws, the performance is awful. For Debian package builds, while snapshotting was really fast, we had to deliberately disable all use of fsync due to this killing performance entirely while running dpkg. Arguably also a design flaw due to the way fsync forces a flush of the whole filesystem. No other filesystem has performance characteristics this bad.
It can certainly work when everything is working correctly. Have you tested its behaviour when things don't work correctly, for example by pulling the cable on one of the discs as it's running? Does it carry on running, does it transparently recover when you plug it back in? When I had a cable become unseated and the connection glitched, Btrfs happily toasted the data on the drive, and its mirror, and panicked the kernel whenever the discs were plugged in; I had to zero them out on another system before I could even try to reformat them. One of the major historical weak points has been that the failure codepaths were poorly tested, and this can come to bite you quite badly.
I mean the performance gains as you add more discs.
And regarding adding discs to an array, you certainly can. Just add addtional raid sets to the pool. That is, rather than adding discs to the existing array, you scale it up by adding additional arrays to the same pool. See the documentation.
It's really quite simple. ZFS is a great filesystem. It's reliable, performant, featureful, and very well documented. Btrfs has a subset of the ZFS featureset, but fails on all the other counts. It has terrible documentation and it's one of the least reliable and least performant filesystems I've ever used. Having used both extensively over several years, and hammered both over long periods, I've suffered from repeated Btrfs dataloss and performance problems. ZFS on the other hand has worked well from day one, and I've yet to experience any problems. Neither are as fast as ext4 on single discs, but you're getting resilience and reliability, not raw speed, and it scales well as you add more discs; exactly what I want for storing my data. And having a filesystem which works on several operating systems has a lot of value. I took the discs comprising a ZFS zpool mirror from my Linux system and slotted them into a FreeBSD NAS. One command to import the pool (zpool import) and it was all going. Later on I added l2arc and zil (cache and log) SSDs to make it faster, both one command to add and also entirely trouble-free.
Over the years there have been lots of publicity about the Btrfs featureset and development. But as you said in your comment that it's "rapidly getting there". That's been the story since day one. And it's not got there. Not even close. Until its major bugs and unfortunate design flaws (getting unbalanced to unusability, silly link limits) are fixed, it will never get there. I had high hopes for Btrfs, and I was rewarded with severe dataloss or complete unusability each and every time I tried it over the years since it was started. Eventually I switched to ZFS out of a need for something that actually worked and could be relied upon. Maybe it will eventually become suitable for serious production use, but I lost hope of that a good while back.
I'm in pretty much the same situation. Server-side, I'm now 100% FreeBSD; client-side I'm using a mixture of MacOSX/Windows/FreeBSD/Linux (Debian unstable w/ pinned sysvinit) but ideally I'd like a FreeBSD or Linux desktop with full graphics support. I currently have an AMD R9 390 GPU which would be excellent were it not for the lagging driver support on both platforms. I've been playing around with a few minor Linux distributions; shame all the mainstream ones are no longer suitable.