В большинстве случаев (пожалуй, только кроме AGPL) код надо раскрывать только при РАСПРОСТРАНЕНИИ производного продукта. И нет такого понятия "липкая лицензия", есть понятие "вирусная" - https://ru.wikipedia.org/wiki/Вирусная_лицензия
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
С опенсорсом будет точно также - если и возьмут, то поддерживать будут сами и никаких PR никто никуда отправлять не будет. Потому что дефект надо закрыть в кратчайшее время, а ждать пока согласуют PR времени ждать нет. А если не согласуют, то откатывать назад никто тут не станет и начнется расхождение в версиях.
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.
Значит, кто-то в банке садится и исправляет ошибку в библиотеке, а потом засылает PR в upstream. Open source работает так. В этом смысле ситуация намного лучше, чем с закрытой библиотекой.
Я исходил из предположения, что поскольку для data cache'ей это работает (а иначе в принципе многопроцессорная/многоядерная обработка была бы невозможна, ну только если всегда пинить ядра на процессы), то и для instruction cache'а оно тоже так, то есть раз механизм инвалидации кэша есть, почему бы его не использовать везде. Но я действительно слабо знаком с другими архитектурами (когда-то работал с PowerPC и PA-RISC'ами, но не на таком низком уровне), возможно, я испорчен X86
Интеграционные тесты - не замена unit-тестам, это разные инструменты. Unit-тесты позволяют быстро убедиться, что новая функциональность ничего не сломала, они отрабатывают быстро и не требуют никакой особой среды, у меня это уже на уровне рефлексов - поменял что-то, запустил unit-тесты. И с помощью unit-тестов намного легче тестировать какие-то ненормальные ситуации, которые при нормальной эксплуатации случаться не должны. По поводу ресурса - для интеграционного тестирования тоже надо писать кейсы, и не факт, что они будут проще моков, особенно когда надо проверить какие-то вещи с параллельной обработкой
Для моей задачи это не годится. Во-первых, это лишает возможности тестировать в один шаг, например, прямо из VS Code - надо сначала вызвать go test -c, пропатчить бинарник, и потом его запустить. Во-вторых, тогда надо сразу все пропатчить, и тогда нет возможности контролировать правильный порядок вызова моков.
Спасибо! А что не так с концовкой? У меня есть пара идей, что там может не понравится, но я так часто не угадывал мнение бета-ридеров, что больше не пробую :)
В большинстве случаев (пожалуй, только кроме AGPL) код надо раскрывать только при РАСПРОСТРАНЕНИИ производного продукта. И нет такого понятия "липкая лицензия", есть понятие "вирусная" - https://ru.wikipedia.org/wiki/Вирусная_лицензия
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.
Значит, кто-то в банке садится и исправляет ошибку в библиотеке, а потом засылает PR в upstream. Open source работает так. В этом смысле ситуация намного лучше, чем с закрытой библиотекой.
Я исходил из предположения, что поскольку для data cache'ей это работает (а иначе в принципе многопроцессорная/многоядерная обработка была бы невозможна, ну только если всегда пинить ядра на процессы), то и для instruction cache'а оно тоже так, то есть раз механизм инвалидации кэша есть, почему бы его не использовать везде. Но я действительно слабо знаком с другими архитектурами (когда-то работал с PowerPC и PA-RISC'ами, но не на таком низком уровне), возможно, я испорчен X86
Интеграционные тесты - не замена unit-тестам, это разные инструменты. Unit-тесты позволяют быстро убедиться, что новая функциональность ничего не сломала, они отрабатывают быстро и не требуют никакой особой среды, у меня это уже на уровне рефлексов - поменял что-то, запустил unit-тесты. И с помощью unit-тестов намного легче тестировать какие-то ненормальные ситуации, которые при нормальной эксплуатации случаться не должны. По поводу ресурса - для интеграционного тестирования тоже надо писать кейсы, и не факт, что они будут проще моков, особенно когда надо проверить какие-то вещи с параллельной обработкой
Для моей задачи это не годится. Во-первых, это лишает возможности тестировать в один шаг, например, прямо из VS Code - надо сначала вызвать go test -c, пропатчить бинарник, и потом его запустить. Во-вторых, тогда надо сразу все пропатчить, и тогда нет возможности контролировать правильный порядок вызова моков.
Ну и на фига? И, судя по release notes, это нельзя отключить.
У меня в проекте большой сгнеренный файл в отдельном пакете, и если его тоже начнут считать, то coverage упадет процентов на 15-20 :(
Скорее всего подойдет "изговниться", возвратная форма словарного глагола изговнить
Спасибо! А что не так с концовкой? У меня есть пара идей, что там может не понравится, но я так часто не угадывал мнение бета-ридеров, что больше не пробую :)
спасибо!
Спасибо! Сначала было намного больше технических деталей, но бета-ридеры не справлялись, так что пришлось упростить.
В одной из ранних версий было около 120 сносок (пояснения для не-ИТшников), а сейчас "всего" 35 :)
Не хватает асимметричной установки колков в две линии, типа 4+2, как у Music Man
Таки да. https://russkiiyazyk.ru/orfografiya/ne-s-prilagatelnyimi.html
У Mikrotik'ов есть, кажется начиная с RouterOS 7.5
Согласно Wikipedia, это все SQL:
И стоит упомянуть, что некоторые особо одаренные RDBMS'ы (привет, Oracle!) трактуют пустую строку как NULL, что жутко раздражает.
Понял, спасибо. Не знал, что Rust на macOS не так работает, как на Linux. Для меня еще один аргумент против перехода на Мак.
А чем не устраивает
?
Мне казалось, что как раз кросс-компиляция в Rust делается просто, я на Linux спокойно собираю под другие платформы
И как же он смог обеспечить синхронизацию часов в то время?