Потеря коммитов в моей практике не встречалась, а вот повреждение репы — это очень печально. Это когда содержимое не соответствует хешу и git fsck говорит «бида-бида». Это почти нельзя восстановить без бекапа.
Я о том что база данных — это блоб, слияние нельзя (вернее — нетривиально) выполнить вручную. Если fossil умеет разрешать конфликты на уровне двух хранилищ — это хорошо. Если нет, то с дропбоксом у него может возникнуть более существенна проблема чем у git.
Пример несколько неудачен, так как там конфликт между GitHub (приложением) и dropbox. У git вполне простая и понятная иерархия файлов, в случае конфликта на уровне dropbox можно разве что «потерять хеш правильного коммита», что тривиально решается используя «резервную» копию, которую дропбокс делает при «мерже» разных версий.
А если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
RC — это модель управления временем жизни данных. ООП — это парадигма программирования. RC используется в коде без ООП, ООП используется в коде без RC. Я не очень понимаю ваш аргумент. Кроме того, RC — это не примитив синхронизации, к чему тут еще и семафоры появились? RC не избавляет вас от синхронизации доступа к данным.
Но RC несколько ортогонально ООП, вы не находите? Собственно, RC успешно применяется в С, в том коде, где нет понятий объектов или классов, а есть «общедоступные» структуры.
Я не понял, а зачем вы сравниваете «коллекции» в user-space и kernel-space? Там же принципиально разные подходы к управлению ресурсами. Если уж на то пошло, то больше смысла будет в сравнении с IOKit.
У графаны — graphite, influxdb. У graphite есть очень много потенциальных источников для данных. Еще есть graphite-api который реализует API графита поверх influxdb как хранилища.
Copy-on-write, в принципе, плохо совместим с файлами-дисками виртуалок, где постоянно происходят небольшие изменения. Обычно, для этого рекомендуют chattr +C file для отключения CoW для конкретного файла (или директории).
Не знаю, я не очень силен в запросах к Google BigQuery, вы можете попробовать сами: www.githubarchive.org/. Но если поменять событие «создание репозитория» на «пуш», то существенно порядок не меняется.
Потеря коммитов в моей практике не встречалась, а вот повреждение репы — это очень печально. Это когда содержимое не соответствует хешу и git fsck говорит «бида-бида». Это почти нельзя восстановить без бекапа.
git reflogбывает полезен в таких случаяхА если конфликт будет на уровне «вот у нас один файл с sqlite, и второй файл, разруливай», то ситуация звучит несколько сложнее.
Наверно наоборот, обфускация кода?
chattr +C fileдля отключения CoW для конкретного файла (или директории).@exprтеперbox(GC) exprИ разработчики очень просят не писать так нигде, а использовать
std::rc::Rc;-)Впрочем дочитал до
sudo chmod 777 /и проникся. Не публикуйте такие гайды, пока сами не понимаете, что вы делаете.1 JavaScript 534943
2 Ruby 408076
3 Java 331224
4 PHP 258187
5 Python 212943
6 C++ 155682
7 C 138852
8 CSS 122017
9 Objective-C 73129
10 C# 70700
11 Shell 64398
12 Perl 32764
13 CoffeeScript 28642
14 Scala 18690
15 Go 17530
16 VimL 14236
17 Haskell 10287
18 Clojure 10181
19 Lua 9117
20 Puppet 8790