ThomasWaldmann
Joined 5 years ago
Joined 5 years ago
Maybe Apple could attach more flash chips in parallel, increasing the bus width and thus the overall bandwidth?
Considering the age of that stuff, one would usually expect that to be very cheap.
Apple dropped "Target Display Mode" in 2014 with the 5K iMac — and it never came back.
TargetBridge brings it back via software, streaming your screen to the iMac at up to 5K over a direct Thunderbolt cable.
Since v2.0.0, you can now even connect multiple iMacs to get multiple gorgeous 5K displays!
FOSS, under the MIT license.
Disclaimer: I am a project contributor, but not the original author of this project.
I don't know about any show-stoppers in borg 1.x.
Design limitations?
Yes, there are some, that's why borg2 will be quite different. But these are no easy or small changes.
Also, borg2 will be a breaking release (offering borg transfer to copy existing archives from borg 1.x repos). It takes long because we try to put all breaking changes into borg2, so you won't have to transfer again too soon after borg2 release.
TL;DR: don't panic, all is good. :-)
Longer version:
- borg 1.x style “append-only” was removed, because it heavily depended on how the 1.x storage worked (it was a transactional log, always only appending PUT/DEL/COMMIT entries to segment files - except when compacting segments [then it also deleted segment files after appending their non-deleted entries to new segments])
- borg 2 storage (based on borgstore) does not work like that anymore (for good reasons), there is no “appending”. thus “—append-only” would be a misnomer.
- master branch (future borg 2 beta) has “borg serve —permissions=…” (and BORG_PERMISSIONS env var) so one can restrict permissions: “all”, “no-delete”, “write-only”, “read-only” offer more functionality than “append only” ever had. “no-delete” disallows data deleting as well as data overwriting.
- restricting permissions in a store on a server requires server/store side enforced permission control. “borg serve” implements that (using the borgstore posixfs backend), but it could be also implemented by configuring a different kind of store accordingly (like some cloud storage). it’s hard to test that with all sorts of cloud storage providers though, so implementing it in the much easier to automatically test posixfs was also a motivation to add the permissions code.
Links:
- docs: https://github.com/borgbackup/borg/pull/8906/files
- code: https://github.com/borgbackup/borg/pull/8893/files
- code: https://github.com/borgbackup/borg/pull/8844/files
- code: https://github.com/borgbackup/borg/pull/8837/files
Please upvote, so people don't get confused.
it was implemented for "file:" (which is also used for "ssh://" repos) and there are automated tests for how borg behaves on such restricted permissions repos.
after the last beta I also added cli flags to "borg serve", so it now also can be used via .ssh/authorized_keys more easily.
so it can now also be used for practical applications, not just for testing.
not for production yet though, borg2 is still in beta.
help with testing is very welcome though!
For low-latency storage (like file: and maybe ssh:) it already works quite nicely, but there might be a lot to do still for high-latency storage (like cloud stuff).
This is the summary of the major changes (more details are in the change log):
Works on borgbackup, nsupdate.info, bepasty, ...