Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)

Впрочем, я так понимаю, что мы выходим на более крупный вопрос. А что вообще происходит с этой картинкой передачи прав, если разработчик хочет использовать какую-то чужую библиотеку? С технической стороны — не писать же свой велосипед для, скажем, парсинга XML, правильно использовать устоявшуюся библиотеку. А во что это выливается с юридической стороны? Должны ли документы упоминать что-нибудь в стиле "служебное произведение использует библиотеку такую-то авторства таких-то, прилагаемую к служебному произведению в соответствии с условиями лицензии такой-то"? Или где-то в служебном задании просто пишется фраза в стиле "разрешается использование ПО сторонних разработчиков, распространяемого по следующему списку лицензий"? Или разрешение на это получать от юр. отдела нужно, но отдельным документом, не входящим в список оформляемого выше?

Заранее прошу прощения, если ответ очевиден и должен быть известен всем — как научный работник я пока что не сталкивался с полноценным оформлением прав на ПО.

Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)

Если работодатель оформит с работником все документы, права на допиленную библиотеку будут принадлежать ему (работодателю). На то, в какое время он это делал, смотреть не будут.

Дело ясное, что дело тёмное. Верно ли это будет сформулировать так: "если разработчик с оформлением всех документов разрабатывает некоторое ПО, то права на любые произведённые им в этот период изменения, которые входят в сдаваемое им ПО, принадлежат работодателю"?
Или критерий более жёсткий — например, если для нужд работодателя допиливается версия, выпущенная до получения задания, может ли он параллельно в свободное время работать в отдельной ветке над новой версией, или права на неё тоже могут перейти работодателю?
Должно ли задание и документы отдельно упоминать существование изменений в проект такой-то, чтобы возникли проблемы?
Или, например, если разработчик в ходе разработки ПО по заданию работодателя (в смысле с оформлением документов) нашёл баг в использующейся открытой библиотеке и написал патч, может ли он этот патч предложить апстриму, или для этого нужно идти через лицензионный договор?

Просто статья выше обсуждает вопросы "что будет, если я не программист и ничего не оформлено" и "что делать, если я работодатель и хочу всё оформить". А меня интересует вопрос "что делать, если я программист, работодатель требует оформления, а я хочу продолжать в свободное время работать над открытыми проектами (в том числе, возможно, и теми, которые у нас используются) и не бояться подставить эти проекты под юр. отдел работодателя".

Безумный план SpaceX полета на Луну? Оценка программы от U/S_Hirangy (reddit)

По логике здесь нужно было бы работать в обратном порядке: запустить танкер, несколькими запусками залить танкеру полные баки, затем запустить пассажирский корабль и заполнить его за одну заправку из заранее подготовленного танкера.

Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)

Исходя из текста статьи, я так понимаю, что любая работа над пет-проектом, не связанным с работой, проблем вызывать не должна. А что с точки зрения законодательства произойдёт в том случае, если работа и пет-проекты соприкоснутся?
Допустим, разработчик получает служебное задание и понимает, что может эффективно использовать в нём библиотеку, которую разрабатывает сам в свободное время, если её чуть-чуть допилить. Безопасно ли это? Может ли оказаться в итоге, что права на изменения библиотеки, произведённые им в период работы по этому заданию, не принадлежат ему? Или здесь уже будут смотреть, делал ли он это в рабочее время или в личное?
Обратная сторона вопроса. Предположим, разработчик получил задание и понимает, что некоторый кусок этого задания можно было бы оформить в хорошую библиотеку. Какие документы ему нужно оформить (в какой форме согласовать это с руководством), чтобы иметь возможность выложить эту библиотеку под нормальной лицензией?

Осторожнее с редактированием bash-скриптов

Для данной задачи? Никак, любой способ проверки подвержен проблеме "был запущен между проверкой и сохранением". Правильный подход здесь — скопировать, отредактировать, переместить на место скрипта.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Только вот использовать их в такой комбинации невозможно в принципе. Если точнее:

• два явных импорта с одним именем конфликтуют;
• если конфликтует явный импорт и use module::*;, всегда используется явный;
• если явного нет, а глоб-импортов, содержащих это имя, больше одного, всегда выдаётся ошибка.

Что в совокупности значит, что в любой точке программы имя типа/трейта всегда однозначно сопоставляется конкретному трейту, и сигнатура для этого сопоставления значения не имеет.

Если вы и правда считаете что это лишняя ифнормация и можно сделать лучше, откройте pre-RFC обсуждение на IRLO, я думаю там вам смогут привести куда более веские аргументы.

А при чём здесь, собственно, internals и pre-RFC? Мы же обсуждаем не изменение языка, а то, как имеющимися фичами языка наиболее точно выразить трейт Map крейта dashmap, нет? Если уж здесь что-нибудь и имело бы смысл открывать, так это PR в dashmap, рефакторящий его на другой вариант… но я не уверен, стоит ли лезть со внутренним рефакторингом без намерения становиться долгосрочным контрибьютором.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Просто раст не запрещает объявление типов с одинаковым именем.

Вообще-то запрещает, можете проверить сами :-)

Кроме того, теперь запись (...) и (...) это совершенно разные вещи...

Нет, не разные, по-прежнему Key (K) в скоупе и Self::Key — это независимые типы (хотя да, строчка type Key = Key; будет выглядеть забавно).

… и переименование генериков в библиотеке становится ломающим изменением (по этим же причинам).

Во-первых, это не генерики, а ассоциированные типы. Во-вторых, да, в отличие от генериков они именованные и это не бага, это фича. Использование вместо них генериков — это как out-параметры: порой так делают, но обычно это считается не особо идеоматичным.

И разница как раз в том, что

… зато теперь нельзя сразу понять, сколько параметров.

Понять можно и параметров здесь — кроме типа, для которого он реализован — нет. И на мой взгляд так правильнее, чем вводить искусственные параметры, которые для заданного целевого типа всё равно обязаны иметь одно-единственное значение.

Для сравнения давайте посмотрим в стандартную библиотеку на пару похожих трейтов: AsRef и Deref. У обоих есть единственный метод с одинаковой сигнатурой fn(&Self) -> &Something. Тем не менее, они принципиально отличаются.
AsRef имеет параметр типа, что позволяет ему иметь много реализаций. Один и тот же строковый тип String удовлетворяет сразу многим конкретным реализациям: AsRef<[u8]>, AsRef<str>, AsRef<OsStr>, AsRef<Path> — и это только в стандартной библиотеке.
Deref же параметров не имеет, а имеет взамен ассоциированный тип. Для каждого типа, реализующего Deref, жёстко задано, в какой именно тип он переводит (и в случае String это именно str). У пользователя нету выбора, какую именно реализацию использовать.
Вот этот служебный трейт Map, на мой взгляд, ближе ко второму варианту. Логика его использования не предусматривает вариант, в котором один и тот же тип имеет несколько реализаций, различающихся параметрами, из которых пользователь выбирает нужную — а именно в этом и есть разница.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Я не вполне понял постановку вопроса. Это три разных варианта того, как можно было бы сделать один и тот же трейт?

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Как есть

pub trait Map<'a, K: 'a + Eq + Hash, V: 'a, S: 'a + Clone + BuildHasher> {
    fn _shard_count(&self) -> usize;
    ...
}

impl<'a, K: 'a + Eq + Hash, V: 'a, S: 'a + BuildHasher + Clone> Map<'a, K, V, S>
    for DashMap<K, V, S>
{
    #[inline]
    fn _shard_count(&self) -> usize {
        self.shards.len()
    }
    ...
}

Как должно бы быть лучше

pub trait Map<'a> {
    type Key: 'a + Eq + Hash;
    type Value: 'a;
    type RandomState: 'a + Clone + BuildHasher;

    fn _shard_count(&self) -> usize;
    [...]
}

impl<'a, K: 'a + Eq + Hash, V: 'a, S: 'a + BuildHasher + Clone> Map<'a>
    for DashMap<K, V, S>
{
    type Key = K;
    type Value = V;
    type RandomState = S;

    #[inline]
    fn _shard_count(&self) -> usize {
        self.shards.len()
    }
    [...]
}

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Вот потому я и говорю, что у трейта изначально неоптимальное определение, на мой взгляд.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Примерно вот так

impl<'a, 'i, M: Map<'a>> Iterator for Iter<'a, 'i, M>
 {
    type Item = RefMulti<'a, M::Key, M::Value, M::State>;

если там дальше пробем не возникнет.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Не "магически вывелись", а прописаны как ассоциированные типы в трейте Map и его реализации. Примерно вот так:

type Item = RefMutMulti<'a, M::Key, M::Value, M::S>;

если вообще не сделать параметром тип M, а не эти три по отдельности.

C++ быстрее и безопаснее Rust, Yandex сделала замеры

Вообще, я бы сказал на первый взгляд, что лишнее здесь всё, кроме 'a и M — просто потому, что трейт Map определён неправильно. K, V, S должны бы быть ассоциированными типами, а не параметрами.
Параметры имеют смысл в основном тогда, когда реализаций с несколькими параметрами может быть несколько… но я очень сильно сомневаюсь в структуре, для которой имели бы смысл реализации Map с разными K, V, S.

Осторожнее с редактированием bash-скриптов

Увы, да — я открыл себе исходный код на посмотреть когда-нибудь потом, не подумав, что это должно бы быть задокументировано.

Безумный план SpaceX полета на Луну? Оценка программы от U/S_Hirangy (reddit)

По-моему, все планы с полётом на Марс и возвращением кораблей (а тем более людей) подразумевают разворачивание там завода по производству топлива. Обсуждаемая программа этого не подразумевает.

Ключевых момента в этой таблице два. Во-первых, автор утверждает, что полностью заправленный Starship на орбите имеет 9.5 км/с запаса скорости (delta V), что, по его оценкам, недостаточно для перелёта к Луне, посадки, взлёта и возвращения на Землю. Отсюда необходимость дозаправки на окололунной орбите, следовательно, возникает танкер, который тоже нужно заправлять на околоземной орбите.
Во-вторых, "после дозаправки". Автор оценивает количество топлива, выводимое одним Starship, в 100 тонн (заявленная полезная нагрузка на низкую околоземную орбиту) и приходит к выводу, что каждая дозаправка на орбите — это десяток запусков танкеров, а не дозаправка от одного танкера, как в красивых демо-видео. Соответственно, в случае Марса "после дозаправки" — это тот же десяток запусков.

Осторожнее с редактированием bash-скриптов

Забавно, мой vim 8.2 номер инода не меняет никогда. Возможно, какие-то детали настроек — у меня он практически без кастомных настроек, я им не пользуюсь особо.

Осторожнее с редактированием bash-скриптов

Самый простой способ проверки, что именно делает редактор:

$ ls -i test.sh
33702972 test.sh
$ vim test.sh # edit the file
$ ls -i test.sh
33702972 test.sh
$ sed -e 's/10/20/' -i test.sh
$ ls -i test.sh
33717589 test.sh

если inode изменяется, то редактор заменил старый файл новым; если остаётся прежним — отредактировал файл на месте.

Осторожнее с редактированием bash-скриптов

А я о чём:

sed - запись временного файла и замена

./ OPEN test.sh
./ CREATE sedGpzLhh
./ OPEN sedGpzLhh
./ ACCESS test.sh
./ ATTRIB sedGpzLhh
./ ATTRIB sedGpzLhh
./ CLOSE_NOWRITE,CLOSE test.sh
./ MODIFY sedGpzLhh
./ CLOSE_WRITE,CLOSE sedGpzLhh
./ MOVED_FROM sedGpzLhh
./ MOVED_TO test.sh

vim - изменение содержимого файла

./ OPEN test.sh
./ CREATE .test.sh.swp
./ OPEN .test.sh.swp
./ CREATE .test.sh.swx
./ OPEN .test.sh.swx
./ CLOSE_WRITE,CLOSE .test.sh.swx
./ DELETE .test.sh.swx
./ CLOSE_WRITE,CLOSE .test.sh.swp
./ DELETE .test.sh.swp
./ CREATE .test.sh.swp
./ OPEN .test.sh.swp
./ MODIFY .test.sh.swp
./ MODIFY .test.sh.swp
./ ATTRIB .test.sh.swp
./ CLOSE_NOWRITE,CLOSE test.sh
./ OPEN test.sh
./ ACCESS test.sh
./ CLOSE_NOWRITE,CLOSE test.sh
./ OPEN,ISDIR
./ CLOSE_NOWRITE,CLOSE,ISDIR
./ OPEN,ISDIR
./ CLOSE_NOWRITE,CLOSE,ISDIR
./ OPEN,ISDIR
./ CLOSE_NOWRITE,CLOSE,ISDIR
./ MODIFY .test.sh.swp
./ MODIFY .test.sh.swp
./ OPEN test.sh
./ MODIFY test.sh
./ ATTRIB test.sh
./ CLOSE_WRITE,CLOSE test.sh
./ ATTRIB test.sh
./ MODIFY .test.sh.swp
./ CLOSE_WRITE,CLOSE .test.sh.swp
./ DELETE .test.sh.swp

Извините, gedit не проверю — у меня Plasma, он не установлен.

Осторожнее с редактированием bash-скриптов

(промахнулся местом ответа)

Осторожнее с редактированием bash-скриптов

Рискну предположить, что у тех, у кого не воспроизводится, редактор пишет изменённый код в новый файл, который затем переименовывает поверх старого (чтобы гарантировать атомарность обновления). В таком случае у баша останется дескриптор старого файла, содержимое которого не менялось.