@alterelefant @Heidi As of now, we can see stuff like the #ExaDrive, a 100TB 3,5" SSD for #online - #archival storage.

• As #Helium-filled #SMR-#HDD|s struggle to meet the demand for storage at an acceptable thermal & power envelope and price, #SSD|s will inevitable take over as not only the more robust media but also cheaper, more dense and easier to use.

As for the #NeoFloppy that thing could be made - I'm just not good enough layouting PCBs with the precision needed for #PCIe signalling...

• Needless to say if constant write speed and lifetime in writes is secondary, then a stack of cheap #SATA-SSDs already beats #LTO-9 tapes unless you need to backup literal #Petabytes and need the fancy features like #WORM media.

That being said, it's inevitable that even WORM as a feature may be copied over.

• In fact #ZFS can already offer many features of #LTFS, including read-only snapshots and thus append-only #archives.

Until there are #COTS solutions tho, LTO #Tape and other options will OFC remain dominant and relevant.

• Still I'd happily see storage vendors take up the NeoFloppy and build something off it.

@GnuPG @todd_a_jacobs Using #LTFS to store #encrypteddata outside of hyper scaler environments without the dedicated #KMS components expensive tape libraries use to enable #LTO9 drives' built-in, hardware #AES256GCM support is an area the institute is evaluating, and thinking about how #GPG might fit in has been a facet of our research process.

All recent generations of #LTO drives support strong, on-the-fly, hardware-accelerated encryption on the drives themselves. Sadly, it's essentially useless in the standalone drives sold to individuals, the #SOHO market, or to other non-enterprise customers because of the high cost of the tape library hardware required to activate it.

In some ways, the situation is much like the early Intel 386 computers that shipped with missing or disabled math coprocessors even when it stopped being a cost issue. In part, that was a strategic market segmentation decision, and the institute currently believes the lack of accessible LTFS encryption for all encryption-capable drives is no different.

Even though #GnuPG is usually thought of as primarily an email tool, it's actually an important "Swiss Army knife" for a variety of #infosec use cases. It's also on a tragically short list of #OpenPGP and telatrd #cryptography tools that remains fully #opensource.

We're putting this topic on our agenda for further exploration and discussion. Meanwhile, these community conversations and the viewpoints of respected tool developers is an invaluable resource to everyone.

#TIL that @GnuPG appears to use the #ustar tar archive format, likely the version from POSIX.1-1988, for #gpgtar rather than either the #POSIX or Star formats from POSIX.1-2001. Since ustar has serious limitations on filename and pathname lengths, can't store certain file types or metadata, and has a 2GB file size limit, it seems unsuitable for most modern use cases.

If gpgtar is actually using star, pax, or the GNU tar POSIX mode, it's not in the #GnuPG user documentation which explicitly says it uses ustar. I have a lot of respect for the #GPG devs, so I hope this is either just a documentary oversight or something that they can easily fix by linking with newer libraries. In either case, ustar is totally unsuitable for writing large archives to tape, and doesn't even offer the options GNU tar does for creating a separate index file, encrypted or not.

The gnutar command line doesn't offer the option to write a separate index, and requires a separate pass to list out the index. For example if you wanted to encrypt a 20TiB archive with a separate, encrypted index to make finding files easier, you'd either have to pipe tar through gpg (which can cause shoe-shining or buffering issues on #LTFS) and then encrypt GNU/BSD tar's index, or have triple the online HDD/SDD capacity of your archived data so you can tar up your files, run another pass with GnuPG to extract the index, and then encrypt both the tarball and index separately before writing them out to tape.

That seems...unreasonable. #OpenPGP doesn't support the AES-256-GCM mode built into current #LTO drives, so gpgtar needs to keep up with the massive growth of data storage capacity rather than remaining an afterthought utility. Especially for #SOHO LTO drives, the ability to write encrypted gpgtar archives and indexes directly to LTFS could be a real game-changer!

The #SMB market lacks affordable, off-the-shelf solutions for encrypted #LTO9 backups. However, there are effective #DIY options if you have basic knowledge of encrypted filesystems and #LTFS. While self-service requires more effort, cloud providers are all vastly more expensive at scale—and often still use the same basic equipment, minus robotic tape libraries and #keymanagement capabilities. You also won't need to trust your cloud provider with secret keys, manage third-party key escrow, or courier physical tapes for large-scale ransomware recovery operations.

If you don't already have a cost-effective plan for ransomware recovery, it's never too late to start—unless you wait until after your online systems have been compromised, of course. Please don't do that!

Split the pomace from the pressing so everyone gets to enjoy the spoilage spoils. The humans got 3.3lb/1.5kg frozen for winter baking and the wassail. Another pound mixed with cinnamon sugar I worked into paste. Once the flavors meld it transform streusel topping, oats, and tea.

Our goat herd gets the fallens and remaining pomace. I made pomace pellets for the hens to chase into the leaf piles. Pups get a jar of puree.

#appleday #apple #pomace #zerowaste #dog #goat #chicken #ltfs #falldrink

@roman78 @jamesrylandmiller @neurovagrant doesn't change the fact that it's also copyrighted and even then I've yet to see any #Android - #ROM that didn't remove it from it's #Kernel...

After all it's unlikely a need for users similar to how most Desktop users don't need #LTFS because even if they knew what #LTO #TapeDrive|s are they are even less likely to own one...

https://mstdn.social/@kkarhan/111049300825272471

@animemer @thecatcollective
- #ZFS, #Ceph, #IPFS and espechally #LTFS are FLOSS & Industry Standards.
- #CinemaDNG & #OpenEXR as well as #TIFF are #OpenFormats.
- #FLAC is the go-to for #Audiophiles
- #SIP & #ZRTP are the only #MultiVendor #VoIP protocols and run every #IP phone that isn't a #SCIP or #GSMK #CryptoPhone...
- #OpenVPN, #WireGuard, #IPsec & #L2TP are the only major #VON rptocols, also #OpenSource
- #LibreOffice ofc.

@fuchsiii also you propably should consider using at least #DUP, #RAID6 / #ZRAID2 or #mdraid10 (in redundant striping configuration)...
https://en.wikipedia.org/wiki/Non-standard_RAID_levels#DUP_profile
https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6
https://en.wikipedia.org/wiki/ZFS#ZFS's_approach:_RAID-Z_and_mirroring
https://en.wikipedia.org/wiki/Linux_MD_RAID_10

Or a file-based (de)duplication approach as well as a database similar to #LTFS indexes and #TapeLibraries do.
https://en.wikipedia.org/wiki/Linear_Tape_File_System
https://en.wikipedia.org/wiki/Tape_library
https://en.wikipedia.org/wiki/Hierarchical_storage_management
https://en.wikipedia.org/wiki/Amanda_(software)