Регулярно наблюдаю в техническом вузе такую картину: студенты сидят перед отдельными компьютерами, но методичку читают со смартфонов. На вопрос, why can't you just be normal почему, отвечают, что так удобнее. Возможно, не-айтишники воспринимают компьютер как нечто вроде станка, а не как средство потребления контента.
Могу ответить с цифрами в руках. Из 180 поступивших вместе со мной на факультет после первой сесии осталось 120, которые доучились примерно таким же составом. Но в группе кафедры, заведующий которой был деканом и мог позволить себе исключения, из ~25 поступивших выпустилось, кажется, 8. От многоопытных преподавателей я как раз слышал, что балласт в нормальной группе во все времена составлял около 70%.
Спасибо, но это надо объяснять не мне, а zVlad909. Он ниже предлагает расчеты исключительно в рублях, что, как мы видели в 2022, ведет к укреплению рубля.
Нет разницы в том смысле что правительство зависит от курса валюты на рынке.
Всё ваше сообщение, с которого началась эта ветка, не о предложении фиксировать курс валюты для расчета налогов (о чем я ответил в другой ветке и ниже), а о том, что если валюту будут продавать экспортеры, это "сделает более объективным процесс оценки рубля на валютном рынке".
вижу решение в том чтобы зафиксировать налог в рублях
Если зафиксировать курс валюты для расчета налогов, но не менять ставку налога, то поступления в бюджет все равно зависят от цены экспортированного товара в валюте на международном рынке. О проблемах изменения ставки налога и коррекции фиксированного курса написал в другой ветке. К тому же, если экспортер вынужден продать больше валюты, чтобы уплатить рассчитанный по фиксированному курсу налог, то курс упадет еще сильнее, усугубляя другие проблемы от сильного рубля.
При этом странным образом страдеют и внутренние проекты, которые почему то расчитывались в долларах.
Внутренние проекты рассчитывались в рублях. Но эти рубли экспортер берет от продажи валюты (на то он и экспортер). Поэтому расчет был такой: заработаем X валюты, продадим по 90, хватит рублей на внутренний проект. А вдруг удается продать только за 80, рублей не хватает.
А мотивируют ли? При сильном рубле может быть и мотивировали бы.
Зависит от пошлины. В целом, привлекательностью экспорта и импорта конкретных товаров управляют с помощью таможенных тарифов.
В других странах с бизнесами не миндальничают и все хорошо работает.
В этих странах основным источником доходов являются не бизнесы, а население, имеющее большие доходы и платящее большие налоги по реально прогрессивной шкале.
Вы буквально пишете о том, что бизнес добился налоговой системы, возлагающей нагрузку вместо бизнеса на наемных работников (не они же этого добивались, верно?).
Поэтому доход бюджета таких стран зависит от национальной валюты, а не от экспорта. Хотя конечно есть и экспорт.
Обсуждаемая проблема в принципе характерна только для стран с большой долей экспортной прибыли в экономике. Пример Канады нерелевантен.
Менять ставку налога, то есть Налоговый кодекс, может законодательная власть (Госдума), а не исполнительная (Правительство), так устроено именно для избежания произвола последнего. И даже при том, что у нас законопроекты умеют принимать очень быстро, на практике это работает: НК внезапно не меняется. А почему работает? Потому что государство — инструмент господствующего класса, в нашем случае — бизнеса, оно блюдет его интересы, в частности, снижение рисков. Вот и ответ на ваш последний вопрос.
Дефицит бюджета грозит, в конечном счете, инфляцией. Вы предлагаете способ избежать инфляции, причем лишь частично (бюджет не только экспортеры наполняют), ценой снижения экономической активности (от больших рисков) и, как следствие, снижением поступлений от налогов, что вновь вызовет дефицит бюджета. Сомнительная затея. Тем более, что для управления инфляцией есть ключевая ставка.
Сначала вы пишете "а вот когда каждый отдельный экспортер придет на рынок за рублями для оплаты налога..." в противовес тому, что все продает одно правительство, которому "имея большие объемы, можно рынком манипулировать", а теперь говорите, что нет разницы? Вы уж определитесь.
Экспортер расходы несет в рублях, налоги платит в рублях, а доходы получает в валюте. Чем выше курс, тем больше прибыль в рублях. Как же ему может быть фиолетово?
Экспортные пошлины делают экспорт менее выгодным, мотивируя продавать внутри страны за рубли, которые останутся внутри страны. Разницы не чувствую, потому что её нет.
сейчас правительство собирает доллары со всех экспортеров и тащит их на рынок
Нет, правительство получает в качестве налогов рубли, которые экспортеры выручили, продав валюту на рынке. Правительство недовольно тем, что продается фиксированный процент от валюты (ставка налога), но из-за текущего курса это получается меньше рублей, чем правительству хотелось бы.
Кроме того, это стимулирует экспортера часть экспортной массы реализовать напрямую в рублях продавая свой товар в России.
Налоги платятся в рублях, но исчисляются они по текущему курсу. "Фиксированной ставкой" вы называете фиксированный курс для исчисления налогов? Получается плавающая эффективная ставка налога = (фиксированная ставка налога) × (фиксированный курс) / (рыночный курс), которой ещё и "можно управлять в зависимости от обстановки". Итого к курсовым рискам добавляется риск произвола со стороны правительства. Бизнес лишние риски ох, как не любит.
Проблема опозданий преподавателей в российских вузах преувеличена. За мою учёбу в МЭИ в 2009—2015 было всего 2-3 случая, когда лектор опоздал бы. Никогда не слышал, чтобы это было массово.
Итоговая оценка в нашем вузе сейчас считается автоматически по заранее известным правилам. В мою учебу такое делали на некоторых предметах. Наверное, студентам это удобнее, особенно если влияет на стипендию. Но если привязано к графику, как у нас, то больно бьет по талантливым раздолбаям. А еще трочник может выполнить критерии, и ничего ты с ним больше не сделаешь. Я вообще против дифференцированных оценок. Либо студент подготовлен, либо нет, и меня наняли в качестве компетентного об этом судить человека. В том, чтобы быть лучше других, студент должен быть заинтересован сам.
Как уже сказали выше, большинству зантересованных в таком ПО нужна on premise версия. Дело не только в отдаче списка уязвимостей на сторону, но и в том, что инфраструктура разработки не должна зависеть от чьего-то сервера в интернете.
Очень важна автоматизация, потому что SCA нужно повторять регулярно. Кстати, если этим заниматься из CI, это еще один довод за on premise, так как CI зачастую от интернета отразан. Нужен документированный и стабильный API. Больше, чем загрузка простых текстовых списков версий, нужна загрузка SBOM в стандартных форматах, хотя бы в CycloneDX как в самом распространенном.
Поддерживается ли версионирование проектов? Обычно нужно знать уязвимости каждой выпущенной версии отдельно.
Жаль, что вы, как и многие разработчики средств SCA, приняли подход, что уязвимость сама по себе имеет уровень критичности. Мне кажется, разработчики govulncheck справедливо от него отказались; критичность есть только в контексте использования компонента с уязвимостью.
Вообще, поиск уявимостей по версиям зависимостей — лишь вершина айсберга управления зависимостями. Как не безопаснику, а старшему разработчику, мне интересно: зачем притащили зависимость? что мы из нее используем? какие зависимости притащили транзитивно? чего нам стоит избавиться от зависимости (лучший патч — выкинуть на мороз)? Графы зависимостей кое-кто умеет строить, но они не отвечают на все вопросы выше. Было бы интересно, если бы инструмент развивался в этом направлении. Мне кажется, это почти свободная ниша.
Гонка случается по факту. Программа некорректна, если гонка может случиться согласно математической модели. Но реальную программу с её размером, а еще внешними по отношению к go операциями, моделировать непрактично. Динамический анализатор проще, быстрее, надежнее в том смысле, что нет процесса моделирования и упущения важных деталей. Но, как любой тест, он может доказать только наличие проблем, а не их отсутствие.
Отношения существуют в рамках модели, в которой нет времени. В конечном счете мы хотим уверенности, что код будет вести себя корректно при любом program execution. На входе — гарантированные спецификацией отношения, на выходе — доказательство без необходимости перебрать все program executions. Рассуждать наоборот ("динамически") означает на входе вообразить program executions, которые не будут иметь формального обоснования, а на выходе получить отношения, которые сами по себе не нужны.
По-моему, определение четко значит первую трактовку. Но на чем основана ваша точка зрения, что между операциями над i есть отношение "happens before/after", о котором вы пишете? Определение конкуретности я искал, еще когда писал первый комментарий, но его в спецификации нет :(
После чтения спецификации мне кажется, что поведение в статье противоречит описанию операции отправки:
Both the channel and the value expression are evaluated before communication begins.
Что бы ни значило "communication begins", раз под капотом передается указатель, то значение по нему может быть изменено вообще всегда, в том числе в тот промежуток времени, пока рантайм будит ожидающую горутину (если значение менят третья). По-хорошему, рантайм должен всегда создавать локальную переменную, копировать туда значение и только потом отправлять, как в варианте с i+0.
Здесь доступ к переменной не происходит конкурентно. Наоборот, всё очень последовательно:
попытались записать переменную в канал
горутина заблокировалась
synctest.Wait() дождался этого момента
перезаписали переменную (увеличили значение)
прочли значение из канала (и напечатали)
Как видно, две записи строго разделены (happens before / after).
Конкуретность означает любое выполнение в разных горутинах. Модель памяти гарантирует, что "a send on a channel is synchronized before the completion of the corresponding receive from that channel", но это относится только к самим операциям с каналом, а не к операциям над другими переменными, каковые операции в каждой из горутин как-то упорядочены относительно операций с каналом в ней же. Иначе говоря, на каналах невозможно реализовать sync.Mutex, так как операция с каналом не является барьером для операций с другими переменными. Так что в вашем случае операции над i конкуретны и не синхронизированы ничем, это data race. Хотя и неочевидная, спасибо за разбор.
Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом? Если первое, то как гипервизор может транслировать неизвестные ему команды для произвольных устройств? Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не понял пассаж про IOMMU — ну да, он описанное делает. Гипервизор, очевидно, не должен выгружать страницы, отображение на которые он запрограммировал в IOMMU.
В той же статье следующим предложением после того, которое вы процитировали, написано, что VMWare внутри VMWare — это штатный сценарий. QEMU-KVM внутри QEMU-KVM тоже работает. Можно утверждать, и я согласен, что на МФ это организовано более стройно, но в статье вы пишете, будто на x86-64 гость-гипервизор невозможен, что неправда.
Я на процессоре i7-6700 с Linux-хостом запускал ESXi (VMWare) как гостя в QEMU-KVM, а в ESXi — виртуалку с Linux. Вот статья 2017, где автор делает то же: https://habr.com/ru/articles/325090/.
устройства могут просто полностью отдаваться в распоряжение гостевой ОС, умеющей с ними работать, а роль гипервизора сводится к преобразованию адреса устройства и адресов блоков памяти, участвующих в операциях ввода-вывода
Проброс устройств в вируталку с помощью IOMMU, разве нет?
Есть вопрос к модели работы самих устройств. Пример с диском удобный, потому что с любой его частью можно работать, как с целым диском, но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.
Регулярно наблюдаю в техническом вузе такую картину: студенты сидят перед отдельными компьютерами, но методичку читают со смартфонов. На вопрос,
why can't you just be normalпочему, отвечают, что так удобнее. Возможно, не-айтишники воспринимают компьютер как нечто вроде станка, а не как средство потребления контента.Могу ответить с цифрами в руках. Из 180 поступивших вместе со мной на факультет после первой сесии осталось 120, которые доучились примерно таким же составом. Но в группе кафедры, заведующий которой был деканом и мог позволить себе исключения, из ~25 поступивших выпустилось, кажется, 8. От многоопытных преподавателей я как раз слышал, что балласт в нормальной группе во все времена составлял около 70%.
Я бы хотел пропускать дальше только тех, кто мотивирован научиться, а не наскрести баллов и задержаться в институте.
Спасибо, но это надо объяснять не мне, а zVlad909. Он ниже предлагает расчеты исключительно в рублях, что, как мы видели в 2022, ведет к укреплению рубля.
Всё ваше сообщение, с которого началась эта ветка, не о предложении фиксировать курс валюты для расчета налогов (о чем я ответил в другой ветке и ниже), а о том, что если валюту будут продавать экспортеры, это "сделает более объективным процесс оценки рубля на валютном рынке".
Если зафиксировать курс валюты для расчета налогов, но не менять ставку налога, то поступления в бюджет все равно зависят от цены экспортированного товара в валюте на международном рынке. О проблемах изменения ставки налога и коррекции фиксированного курса написал в другой ветке. К тому же, если экспортер вынужден продать больше валюты, чтобы уплатить рассчитанный по фиксированному курсу налог, то курс упадет еще сильнее, усугубляя другие проблемы от сильного рубля.
Внутренние проекты рассчитывались в рублях. Но эти рубли экспортер берет от продажи валюты (на то он и экспортер). Поэтому расчет был такой: заработаем X валюты, продадим по 90, хватит рублей на внутренний проект. А вдруг удается продать только за 80, рублей не хватает.
Зависит от пошлины. В целом, привлекательностью экспорта и импорта конкретных товаров управляют с помощью таможенных тарифов.
Вы буквально пишете о том, что бизнес добился налоговой системы, возлагающей нагрузку вместо бизнеса на наемных работников (не они же этого добивались, верно?).
Обсуждаемая проблема в принципе характерна только для стран с большой долей экспортной прибыли в экономике. Пример Канады нерелевантен.
Менять ставку налога, то есть Налоговый кодекс, может законодательная власть (Госдума), а не исполнительная (Правительство), так устроено именно для избежания произвола последнего. И даже при том, что у нас законопроекты умеют принимать очень быстро, на практике это работает: НК внезапно не меняется. А почему работает? Потому что государство — инструмент господствующего класса, в нашем случае — бизнеса, оно блюдет его интересы, в частности, снижение рисков. Вот и ответ на ваш последний вопрос.
Дефицит бюджета грозит, в конечном счете, инфляцией. Вы предлагаете способ избежать инфляции, причем лишь частично (бюджет не только экспортеры наполняют), ценой снижения экономической активности (от больших рисков) и, как следствие, снижением поступлений от налогов, что вновь вызовет дефицит бюджета. Сомнительная затея. Тем более, что для управления инфляцией есть ключевая ставка.
Сначала вы пишете "а вот когда каждый отдельный экспортер придет на рынок за рублями для оплаты налога..." в противовес тому, что все продает одно правительство, которому "имея большие объемы, можно рынком манипулировать", а теперь говорите, что нет разницы? Вы уж определитесь.
Экспортер расходы несет в рублях, налоги платит в рублях, а доходы получает в валюте. Чем выше курс, тем больше прибыль в рублях. Как же ему может быть фиолетово?
Экспортные пошлины делают экспорт менее выгодным, мотивируя продавать внутри страны за рубли, которые останутся внутри страны. Разницы не чувствую, потому что её нет.
Нет, правительство получает в качестве налогов рубли, которые экспортеры выручили, продав валюту на рынке. Правительство недовольно тем, что продается фиксированный процент от валюты (ставка налога), но из-за текущего курса это получается меньше рублей, чем правительству хотелось бы.
Это делается экспортными пошлинами.
Налоги платятся в рублях, но исчисляются они по текущему курсу. "Фиксированной ставкой" вы называете фиксированный курс для исчисления налогов? Получается плавающая эффективная ставка налога = (фиксированная ставка налога) × (фиксированный курс) / (рыночный курс), которой ещё и "можно управлять в зависимости от обстановки". Итого к курсовым рискам добавляется риск произвола со стороны правительства. Бизнес лишние риски ох, как не любит.
Проблема опозданий преподавателей в российских вузах преувеличена. За мою учёбу в МЭИ в 2009—2015 было всего 2-3 случая, когда лектор опоздал бы. Никогда не слышал, чтобы это было массово.
Итоговая оценка в нашем вузе сейчас считается автоматически по заранее известным правилам. В мою учебу такое делали на некоторых предметах. Наверное, студентам это удобнее, особенно если влияет на стипендию. Но если привязано к графику, как у нас, то больно бьет по талантливым раздолбаям. А еще трочник может выполнить критерии, и ничего ты с ним больше не сделаешь. Я вообще против дифференцированных оценок. Либо студент подготовлен, либо нет, и меня наняли в качестве компетентного об этом судить человека. В том, чтобы быть лучше других, студент должен быть заинтересован сам.
Спасибо, что открыли новый продукт.
Как уже сказали выше, большинству зантересованных в таком ПО нужна on premise версия. Дело не только в отдаче списка уязвимостей на сторону, но и в том, что инфраструктура разработки не должна зависеть от чьего-то сервера в интернете.
Очень важна автоматизация, потому что SCA нужно повторять регулярно. Кстати, если этим заниматься из CI, это еще один довод за on premise, так как CI зачастую от интернета отразан. Нужен документированный и стабильный API. Больше, чем загрузка простых текстовых списков версий, нужна загрузка SBOM в стандартных форматах, хотя бы в CycloneDX как в самом распространенном.
Поддерживается ли версионирование проектов? Обычно нужно знать уязвимости каждой выпущенной версии отдельно.
Жаль, что вы, как и многие разработчики средств SCA, приняли подход, что уязвимость сама по себе имеет уровень критичности. Мне кажется, разработчики govulncheck справедливо от него отказались; критичность есть только в контексте использования компонента с уязвимостью.
Вообще, поиск уявимостей по версиям зависимостей — лишь вершина айсберга управления зависимостями. Как не безопаснику, а старшему разработчику, мне интересно: зачем притащили зависимость? что мы из нее используем? какие зависимости притащили транзитивно? чего нам стоит избавиться от зависимости (лучший патч — выкинуть на мороз)? Графы зависимостей кое-кто умеет строить, но они не отвечают на все вопросы выше. Было бы интересно, если бы инструмент развивался в этом направлении. Мне кажется, это почти свободная ниша.
Гонка случается по факту. Программа некорректна, если гонка может случиться согласно математической модели. Но реальную программу с её размером, а еще внешними по отношению к go операциями, моделировать непрактично. Динамический анализатор проще, быстрее, надежнее в том смысле, что нет процесса моделирования и упущения важных деталей. Но, как любой тест, он может доказать только наличие проблем, а не их отсутствие.
Отношения существуют в рамках модели, в которой нет времени. В конечном счете мы хотим уверенности, что код будет вести себя корректно при любом program execution. На входе — гарантированные спецификацией отношения, на выходе — доказательство без необходимости перебрать все program executions. Рассуждать наоборот ("динамически") означает на входе вообразить program executions, которые не будут иметь формального обоснования, а на выходе получить отношения, которые сами по себе не нужны.
По-моему, определение четко значит первую трактовку. Но на чем основана ваша точка зрения, что между операциями над
iесть отношение "happens before/after", о котором вы пишете? Определение конкуретности я искал, еще когда писал первый комментарий, но его в спецификации нет :(После чтения спецификации мне кажется, что поведение в статье противоречит описанию операции отправки:
Что бы ни значило "communication begins", раз под капотом передается указатель, то значение по нему может быть изменено вообще всегда, в том числе в тот промежуток времени, пока рантайм будит ожидающую горутину (если значение менят третья). По-хорошему, рантайм должен всегда создавать локальную переменную, копировать туда значение и только потом отправлять, как в варианте с
i+0.Конкуретность означает любое выполнение в разных горутинах. Модель памяти гарантирует, что "a send on a channel is synchronized before the completion of the corresponding receive from that channel", но это относится только к самим операциям с каналом, а не к операциям над другими переменными, каковые операции в каждой из горутин как-то упорядочены относительно операций с каналом в ней же. Иначе говоря, на каналах невозможно реализовать
sync.Mutex, так как операция с каналом не является барьером для операций с другими переменными. Так что в вашем случае операции надiконкуретны и не синхронизированы ничем, это data race. Хотя и неочевидная, спасибо за разбор.Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом? Если первое, то как гипервизор может транслировать неизвестные ему команды для произвольных устройств? Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не понял пассаж про IOMMU — ну да, он описанное делает. Гипервизор, очевидно, не должен выгружать страницы, отображение на которые он запрограммировал в IOMMU.
В той же статье следующим предложением после того, которое вы процитировали, написано, что VMWare внутри VMWare — это штатный сценарий. QEMU-KVM внутри QEMU-KVM тоже работает. Можно утверждать, и я согласен, что на МФ это организовано более стройно, но в статье вы пишете, будто на x86-64 гость-гипервизор невозможен, что неправда.
Я на процессоре i7-6700 с Linux-хостом запускал ESXi (VMWare) как гостя в QEMU-KVM, а в ESXi — виртуалку с Linux. Вот статья 2017, где автор делает то же: https://habr.com/ru/articles/325090/.
Проброс устройств в вируталку с помощью IOMMU, разве нет?
Есть вопрос к модели работы самих устройств. Пример с диском удобный, потому что с любой его частью можно работать, как с целым диском, но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.