krondor

Excellent, not sure what I missed before, but I have aptx and aac now! A good step in the right direction. Still would love LDAC and/or Aptx HD of course in the long run.

Thanks, it looks similar to what I've tried so far. I'll give it another run through and see if I missed something.

No, I meant AAC. The XM3s do not seem to negotiate AAC over BT on OSX. They fall back to SBC and obviously sound bad. AAC would be a step up, but AptX HD or LDAC would be ideal. They work fine in my case on both iPhone and Android.

So as I was saying I'm tempted to move back to Linux for my work laptop for LDAC over BT support as well as other reasons of course.

I have never been able to get it to negotiate AAC on OSX, though technically it does support it. iPhone works fine.

Even still LDAC seems superior from my comparison to my Android and iPhone audio.

See this thread for some discussion on it. https://www.reddit.com/r/MacOS/comments/bion53/force_macos_t...

Actually those Sony headphones are one of the reasons I am interested in Linux instead of OSX. LDAC support is not present on OSX, but it is for Linux.

It makes a huge difference in audio quality over bluetooth in my experience.

*edit: Just realized I posted the wrong link. https://eischmann.wordpress.com/2019/02/11/better-bluetooth-...

This is not so different actually, and has been done in the past by other auto manufacturers (some may even still be doing this today). The Ford River Rouge plant is the best example I can think of with literal Iron Ore going in one side and finished cars rolling out the other.

Musk may have been inspired by this plant. http://www.businessinsider.com/tesla-factory-like-ford-plant...

I'm not sure about FreeNAS, but I do want to point out this is possible in the btrfs filesystem (sharded raid across drives). I'm not aware of any FreeNAS equivalents though utilizing it, but rolling your own is certainly an option.

Thank you, this was a great reply. Reading the discussions have been interesting.

Canonical is doing so anyway and it seems they have a legal disagreement on the interpretation of the law with the Software Freedom Conservancy.

IANAL so I have no clue what is technically correct, but the fact is that Ubuntu is distributing zfs.ko in 16.04.

Yes, apologies, I did mean lzo. zlib seemed perhaps too much on the CPU side of the IO/CPU calculation. I am excited to see how btrfs snappy and lz4 support compares when they are added, however.

To the point of lzo performance though, btrfs is a tad smart with compression, it tries to compress an initial 128KiB and if the compressed segment is not smaller than the uncompressed it adds it to a list of no compress files, and will not try compression on that file again (unless of course you force it).

This was for our Hadoop use case, comparing to ext4, so nodatacow would work because we have no desire of snapshots in that environment. It still seems like we're better of compressing within the Hadoop framework (as jamesblonde is doing) and sticking with ext4 jbod, for now at least.

Btrfs is not beta, see the discussion re: maturity below.

ZFS is an excellent filesystem, btrfs is an excellent filesystem. There is room for both excellent options for users.

I believe you're misunderstanding the problems that occur on a cow filesystem. In fact btrfs already has an overcommit disk buffer, and is already doing many ENOSPACE handling tricks.

Have a look; https://btrfs.wiki.kernel.org/index.php/ENOSPC

Reading more for my own interest it seams ZFS uses ZIL to help convert random writes to sequential, which helps with fragmentation under low space. I am curious if bcache, can operate similarly. In addition, I should also point out that this is less of an issue on SSD, due to the nature of how random reads/writes work there anyway (btrfs does a good job of being SSD aware).

I'm going to disagree with you re: compression. Compression at the FS layer brings a lot of benefits, and generally most workloads are IO constrained not CPU constrained. Compression at the FS improves IO at the expense of CPU.

Hadoop is a completely different workload, and maybe not something for ZFS or btrfs. Our Hadoop nodes are not raid, just JBOD ext4 disks. We have been conidering btrfs with nodatacow mount option and lz4 compression, however. We haven't decided if it's better to compress within Hadoop or at the fs layer yet. I would be curious on your findings.

You are correct that btrfs and ZFS are sensitive to low disk space. This is also related to how cow filesystems function, they need that free space to commit writes and for snapshots because they, by nature, don't overwrite blocks.

See this for the ZFS example; http://serverfault.com/a/556892/79238

In both cases the exact amount of free space you desire is a mix of workload, fragmentation, and snapshots.

However, I disagree they waste a lot of space. I think both ZFS and btrfs more than make up for the overhead of free space commits through their space saving features. cp --reflink, block suballocation, compresssion, and efficient snapshots outweight the overhead, in my case. Your mileage may vary.

As zanny said, cow presents an issue for transactional workloads (databases, vm images, etc...) as each write fragments the file, by nature of the process of cow.

btrfs can handle database workloads but you have to disable cow for them (which you can do at the file, directory, or subvolume level in btrfs). You would specify the nodatacow mount option, or chattr +C (file/directory).

The btrfs autodefrag is still rather new, and needs some work. I expect that could be the long term fix (manual defrag is fine now, but you wouldn't want to call it frequently on a db file), I'm not sure how ZFS handles the fragmentation, but I do know in the past ZFS observed similar issues (seems to have been mostly resolved). I should also point out that disabling cow doesn't really fully disable it, snapshots can still function, etc... however, I'm sure that once you start to use the other cow functions you might observe slipping performance due to fragmentation of these types of files.

https://blog.pgaddict.com/posts/friends-dont-let-friends-use... https://bartsjerps.wordpress.com/2013/02/26/zfs-ora-database...

That seems ill advised, one of the benefits of btrfs is it obviates the need for lvm and mdadm.

I guess in your case you have a more stable raid5/6 opportunity, but you're losing many of the raid benefits present in btrfs natively. I'd also imaging it could be slower or introduce IO issues others haven't tested. Though I really have no idea, never seen anyone do that before.

ZFS is in Ubuntu 16.04 without a PPA, by the way.

Yes, thanks for catching that, I've edited the parent.

As you can tell I'm not that strong on ZFS other than what I've learned in some small tinkering and discussion with others.

Agreed, my workload is probably not representative of a small organization or user. I absolutely leverage resiliency in software, distributed computing, and mitigate single points of failure, etc... This is a good point.

Now, I do think these methods are increasingly approachable for all users, however. A lot of that is actually enabled by the feature sets of ZFS and btrfs. The default Ubuntu installer, for example, will create snapshots during OS upgrade for rollback if the upgrade fails. ZFS and btrfs send/receive feature allows for efficient DR clones (not to mention seed images and snapshots). LXD leverages ZFS if you choose to for rapid containerization and snapshots.

These intrinsic abilities of these two filesystems allow for smaller users and organizations to improve those workflows to be more risk averse in general (even while assuming some risk in a newer FS).

Just, if possible, be up to date on the known issues and run more recent kernels and userland utilities.

https://btrfs.wiki.kernel.org/index.php/Gotchas

I believe on Ubuntu 16.04 ZFS is not using dkms. You'd want to check, because I'm not currently running it, but that's what I have been told.

That's a fair point. I guess we can debate what 'mature' means.

In development since 2007, stable since 2014. ZFS, in development since 2001 (correction I erroneously listed 2005 earlier), stable since 2006 (or at least Solaris included since then). Do you consider the Solaris years or just the Linux years and then do you consider the Linux Debian/Ubuntu sanctioned years or the ZoL years?

I'm fine with mature since included in the default installer on Ubuntu/Redhat/Oracle/SUSE/etc... for my definition of btrfs maturity.

btrfs is most certainly not dead. I actually think it's really gaining traction presently. It only became stable near Ubuntu 14.04 or so, and it takes people awhile (understandably) to warm up to a new filesystem.

It's great to see ZFS on Linux get a more stable footing. It's an excellent filesystem. As others have said I think the use case differs slightly from btrfs (though they are very similar in capabilities).

ZFS, to my eyes, seems more resilient. It has more levels of data checksums, The RAIDz model allows for more redundancy, and it just feels like a stronger enterprise offering (meaning stable and built for large systems and disk quantities).

btrfs brings many of the ZFS features to Linux in a GPL wrapping. What it lacks in resiliency, it makes up for with flexibility. Raid in btrfs, for instance, occurs within data chunks across disks, not at the disk level, meaning mixed disk capacities, and on the fly raid changes. I also appreciate the way it divides namespace across subvolumes while maintaining block awareness within the pool (cp --reflink across subvolumes, snapshots across subvolumes). It also doesn't have the ram requirements of ZFS (which aren't much of a data center concern, but are definitely a client level concern for workstations).

Either way it's a win, both great filesystems for Linux. With bcache supporting btrfs properly now, I personally don't have much of a reason for ZFS now. Two years ago I would have jumped easily to it. Your workloads and needs may differ, it's great to have choices!

Interesting findings. I'm curious also to see how fixed width stripes change the performance profile in btrfs (presently not supported). To be clear though, the raid5/6 write hole only applies to power failures with data in flight. It is still a concern, of course, but I think depending on your environment is acceptable to some (redundant PSUs, well engineered PDUs and UPS systems). Personally, I'm of increasing opinion that parity rebuilds aren't worth it anyway. I'd rather raid10, raid1, or raid0 depending on use. If I have to take a system out of production during parity rebuild (because IO activity is too intense for performant use), might as well not parity rebuild and simply reload the system on failure and rely on other cluster nodes.

btrfs is stable as of kernel 3.14 or so. The features in btrfs that are unstable at this point are raid56 (write hole on power failure risk), autodefrag (and mainly just with high transaction files like vm images and databases), and ext34/in place filesystem conversion.

We've been running btrfs in production since Ubuntu 14.04 with excellent results. The feature set vastly outweighs the few risks that remain.

Because that doesn't happen outside of the OSS world?

These lights FTA are OEM, though a lot of tuner cars and lifted trucks aren't I suppose.

I haven't looked in awhile, but ClamAV actually did very well in some third party virus tests. You shouldn't need a Linux specific product. Good AV systems detect viruses for multiple platforms irregardless of the host performing the scan. It's actually really hard to gauge AV effectiveness, so take those published tests with some healthy skepticism. ClamAV detects Linux and Windows viruses, but does not include an on access scanner. It's usually fired off manually or hooked via other programs (spam scanners).

There is however, a fuse FS ClamFS http://clamfs.sourceforge.net/ that provides on access scanning for Linux with ClamAV. I have no idea how much overhead that incurs, but it probably isn't a small amount. A lot of enterprise offerings provide on access scanning (McAfee, F-Prot, Kaspersky, and more).

I'd imagine there are Firefox and Chrome add ons as well.

I moved my blog to it some time ago and it's been excellent so far. I do kind of think this is out of scope for GitHub, and will probably move to S3 at some point.

I did switch from Jekyll to Octopress though (Octopress is a nice framework around Jekyll that automates the annoying manual bits involved with Jekyll). So far it's been great though!

Just a few nitpicks;

Drupal does have wysiwyg implemented as a module http://drupal.org/project/wysiwyg (actually several competing editors are possible),

Drupal also can do automated updates, though I wouldn't advise it. Drush works for it, http://drupal.org/project/drush and a lot of people use it with great success. You would want a carefully vetted rollback plan though. The better road is to forgo updates other than security until scheduled maintenance or a MUST have feature is present. The GUI /update process is actually quite nice if you've set everything up properly.

The thing about Drupal is doing everything doesn't have to be painful, but if you've approached it in a "non-Drupal" way it can get bad quickly. Drupal is complex and the hand off to a customer is never easy with complex software. Have you tried the same with Plone?