Вот с чем мы работаем, по факту.

Красивое уничтожение танка дроном за 40тр. Война будущего - это очень много автономных леталок и ползалок и сеть реального времени, чтобы обмениваться информацией.
Если этого нет, то приходить только в качестве мишени.

В стандарте TETRA (Terrestrial Trunked Radio, используется в промышленности, транспорте, пожарными, полицией, военными) -- что бы вы думали - нашли бэкдоры в алгоритме шифрования.
Никогда такого не было и вот опять!

В Google человек пилит новую систему контроля версий. Выделю три момента:
1. она git-совместимая (промышленный стандарт, итд)
2. отходит от понятия коммита (каждое сохранение в редакторе создаёт коммит, оно и правильно, от бесконечных small fix никому не легче жить, а смотреть на коммиты можно, как на бранчи - это просто метка, указывающая на версию)
3. работают над тем, чтобы можно было работать с частичной копией репо (оно и понятно, это google)
Отмечу только, что 3 они пока думают, как сделать, а 2 в гитовой модели данных в полной мере (некостыльно) реализовать вряд ли возможно. 1 в теории хорошая идея, но опять же у git вполне определённая модель и для её эффективной работы пришлось написать фактически очень развесистую БД.

Написал пропозал на воркшоп, посмотрим как зайдёт. Пропозал пропозалом, но стал вспоминать зачем я год назад писал свой storage engine и это оказалось очень тяжёлой задачей на пол-дня - взвесить все за и против (готовое или своё?). Документа никакого не было по истории решения :)
Вывод: да, производительность на порядок лучше в результате. Ну и другой вывод - про устройство и биохимию мозга, его отдельно распишу.

Доклад про pijul вызвал смешанные чувства. Не увидел стройной системы, увидел ворох идей и недоделанных проектов.

С точки зрения бизнеса, конечно, криптография с открытым ключом-безобразие. Придумали вот хорошую мутку, keyless подпись. Клиент логинится в Google, о чем доверенная компания!!! выдает ему временный!!! сертификат!!!
Деньги из воздуха.
Какой то чувак карьерно зависит от этой инновации, интриговать будет, публикации в прессе организовывать…

Автор канала про БПЛА пришёл к тем же выводам: в России отсутствует прослойка инноваторов – людей, разбогатевших на инновациях. Зато есть обширный класс успешных отжиматоров.
И список пострадавших историй продолжим - Волож, Шафиров, Дуров, Опанасенко….
В общем, тот кто в Шарик не успел – на бутылочку присел.

Кстати, два месяца я буду full time на DaRWiN, вероятно будут занимательные апдейты.

Есть какой-то физический закон, что кусок кода, помещённый в монорепо, начинает зависеть от всего монорепо, и вне монорепы уже жить не может.
А монорепо втягивает в себя весь существующий код.
Напоминает черную дыру.
Задумывались ли вы над этим породным явлением?

Ну и ещё небольшой апдейт. Я говорил, что меня замучила оперативная разработка, или как это там называется у спецслужб (я называл пидоропадом).
Я то думал это какие-то стратегические соображения. Ха ха. Предполагаемый ДР Сатоши Накамото 5 апреля, как у меня. Я преподаю Дец Системы в ВШЭ. Ежу понятно, кто скрывается под моим именем (у этого лоха можно отжать десять ярдов!!!).
Но пока спецслужбы в минусе, этак на пару лямов. Действовать мне на нервы в 10 разных странах наверное недёшево.

Ещё я подозреваю, что история с 5 апреля это тщательно продуманная пакость от настоящих авторов BitCoin. Я же ещё тогда написал кг/ам про BitCoin, и текст широко разошёлся (HN, TechCrunch, итд) Они мне написали, спросили как исправить, я ответил это неисправимо.
Возможно, остро восприняли мою критику.

Так-то ДР это сужение круга подозреваемых на 1/365/100, и учитывая специфический набор компетенций, это как именем настоящим подписаться.
Там правда год отличается на -4, возможно по фейсбуку определили, я немоложав.

Селфи с настоящим Сатоши

Reconsidering file system interfaces

This is the first in the series of "position posts" documenting the development and inner workings of a CRDT based revision control system named DaRWiN (tentatively).
A revision control system is a pretty fundamental piece of software, comparable to databases and filesystems. Actually, DaRWiN's inner stack of abstractions looks like this:
1. internal filesystem,
2. storage engine (Causal Tree based),
3. source code revision control system.
Today we discuss the filesystem. Why file system, in the first place? Can't we use the normal one? Yes, we can, but that does not make our life any easier, as we need a bit more.
Actually, if we check the official git manual, we will learn that git is a "content-addressible filesystem". Yep, git. is a (versioned) filesystem. That looks perfectly natural if you think about it for. a minute.
Our situation is not much different.
Here, we have a rare chance to reconsider legacy interfaces and push a sizable portion of work down the stack, instead of reimplementing it on top of a POSIX filesystem that is doing things *wrong*, Consider POSIX ways to address a file:
1. file name (a string),
2. file path (a recursive string),
3. file descriptor (an integer),
4. a hash (not POSIX but git is doing that).
All these three ways are mostly independent of one another: file descriptors are highly transient, paths might be specific to a system and only the hash is *the true name of data*, albeit you can never pronounce such a name :)
We will make a joint interface using all the three constructs as three faces of the same thing (that is the Christian way!)
Namely,
1. we make descriptors persistent (once we create a file, it gets a 32 bit descriptor for its lifetime),
2. we use names and paths the normal way (except we limit names to 32 bytes for the sake of simplicity; early filesystems were pretty simple, by the way),
3. we maintain a filesystem hash table to address files by the *hash of their name* (not hash of data yet).
So, how do we do git/bittorrent/bitcoin like content addressing in this system? A blob is named by its hash; a hash of a hash we may use in the filesystem interfaces. Similarly, if the file is named by a public key, we may alternatively use its hash-of-a-public-key both locally and on the network (not to announce the actual public key to third parties).
There is a distinction here between local (like "READMEmd") and globally unique names, like for example
2facd7886631867c104a6d155fdd1b379aaaea24124395c88ccc4cc2a0761a
So, we can use this filesystem normally, a la 1s/rm/mv, only relying on names and paths. For normal files, these two methods are essentially the same: either an IPFS-like name like volumeid/dirl/dir2/file or its hash. All the files named in a globally unique way, like by a hash, a public key or an UUID, we imply to be *replicates* (blobs, streams, persistent files).
For those, we may skip the file tree entirely and reach them by the hash.
How do we distinguish local and global names? Well, for the sake of (extreme) simplicity we imply that every name of 32 bytes or longer is some sort of a global id (may do better later). What if we want two copies of a hash-named file? We don't.
Replicates are replicated, more on that in the next post.
But the most practically interesting feature is a persistent 32-bit file descriptor. Once we open() a file, we get a number back and that number is the same for the lifetime of the file.
Why is this so good? Well, we can cross-reference data in the files by using 64-bit handles. Imagine, we have no more than 2^24 files (16mln) and each file is up to 1TB (2^40) in size.
Then, a 64-bit handle points to a specific byte in a specific file anywhere in the system. File moves and directory renames do not break that link! (My greetings to Mr Theodor H. Nelson)
Well, our simplistic filesystem gets some content-addressed database abilities just by refactoring the API. So, is POSIX bad then? Not quite, but it is very dated.

It was codified before content-addressed systems and even before mass use of databases, so those had to reimplement their things on top of POSIX or (way more often) raw 4KB blocks.
What do I argue for, exactly? Well, it is typical in our industry to implement things on top of earlier things.
Sadly, we often *reimplement* things on top of an earlier implementation that is not good enough for our purposes.
We may not be able to change that in the general case, but let's see where this road leads us in this particular project.

Интересно. Кокс пишет, что Томпсон действительно написал атаку на компилятор С, но затея провалилась из за бага.
(Суть в том, что злоумышленно модифицированный компилятор добавляет бекдор, во все бинари, включая и следующую версию компилятора, те в исходниках бекдора нигде нет, а в бинарях везде есть)

Новости с YC Demo Day подтверждают тему про новое Средневековье:
- много фаундеров Стенфорд-Google (поувольняли)
- фокус на чисто коммерцию (нетрудовые доллары всё)
- фокус на американский рынок (глобализация всё)
Собственно, масштабирование «на весь мир» забуксовало ещё в эпопее с Uber.
Сдвига в стеке технологий пока не вижу, подождём пару лет (или сделаем сами 😉)

SPLASH PLF доклад приняли, интересно что рецензенты не анонимные, один из них Клеппманн.
Относительно же темы доклада, у меня есть общее ощущение, что с каузальными деревьями в Computer Science должны были разобраться тогда же, когда с B-деревьями разобрались, в 80х 90х.
Ну, может добавит в книжку с кабанчиком, нужно исправлять этот пробел.