Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел. Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Не надо передёргивать и нагло вырывать фразу из контекста.
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
Я в свое время провел эксперимент - убрал из CV весь опыт до 2000 года (года рождения там и не было). Количество откликов от HR выросло в разы! Вообще ощущение, что в наше время самое сложное - пройти фильтр HR, на техническом собеседовании общаешься уже с инженерами, которым по фиг твое образование и возраст.
Это каким-то образом отменяет то, что я написал? Термина "липкая лицензия" нет, а к "вирусной" уже все привыкли, и этот термин по большей части потерял свою оригинальную негативную коннотацию
В большинстве случаев (пожалуй, только кроме 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, пропатчить бинарник, и потом его запустить. Во-вторых, тогда надо сразу все пропатчить, и тогда нет возможности контролировать правильный порядок вызова моков.
У меня для вас плохие новости...
ага, и домен getbox.ru на продажу выставлен. Непонятно, то ли это толстоватый троллинг, то ли какой-то неизящный скам
Мне кажется, тут просто обязательно надо упомянуть pass (https://www.passwordstore.org/)
Круто, с
defaut-features = falseкомпилится в Wasm и даже работает, спасибо!Таки это, именно в этом и было дело
Мне кажется, этот я тоже пробовал, и он у меня не захотел в wasm32-wasi компилиться, но я еще раз попробую. В любом случае спасибо
А для самого обычно zip нет нормальной pure Rust либы, чтобы можно было спокойно в Wasm скомпилить :(
Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел.
Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Автор, судя по тексту, отнюдь не бумер, а миллениал (https://ru.wikipedia.org/wiki/Поколение_Y)
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
С этим полность согласен.
То есть самому относиться презрительно к предыдущему поколению - нормально, а когда к тебе так, то вдруг что-то не нравится?
Я в свое время провел эксперимент - убрал из CV весь опыт до 2000 года (года рождения там и не было). Количество откликов от HR выросло в разы! Вообще ощущение, что в наше время самое сложное - пройти фильтр HR, на техническом собеседовании общаешься уже с инженерами, которым по фиг твое образование и возраст.
Согласен
Это каким-то образом отменяет то, что я написал? Термина "липкая лицензия" нет, а к "вирусной" уже все привыкли, и этот термин по большей части потерял свою оригинальную негативную коннотацию
В большинстве случаев (пожалуй, только кроме 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, пропатчить бинарник, и потом его запустить. Во-вторых, тогда надо сразу все пропатчить, и тогда нет возможности контролировать правильный порядок вызова моков.