я имел в виду, с какой суммы нужно выплачивать 27%? с очищенных от накладных или с оборота. Для, примера, на упрощёнке налог был 15% с суммы за вычетом расходов или 6% с оборота, выбирает организация сама. Если у меня продукция и 70% уходит на накладные расходы, я выбираю ставку с оборота (налоговый учет намного проще) 6% итого у меня остаётся 24% очищенных доходов, то сколько я должен отчислять Эпплу? Нужно ли мне платить 6% налогов с отчислений Эппл?
ps: если, что я не разработчик софта под мобилы, я разработчик железа, но экономика интересует, так как реальность, когда нельзя будет поставить софт на свой "Этот компьютер" уже близко.
27%? эээ, а с них нужно отчислять налоги или это 27% с остатка после уплаты всех налогов? И как учитывать себестоимость? то есть это после учета затрат?
в обычном бизнесе предположим 70% затраты и 30% то, что остается на развитие, часть из 30% уходит на закупку оборудования, непрофильные затраты и что-то формирует прибыль, а какая модель бизнеса тут?
а вам не кажется, что цель ВУЗа, в том числе и обучить порядку подачи патентов? возможно мы в статистике видим перегиб, когда отдельные вузовские работники подают десятки заявок, но большая часть заявок от ВУЗов это разные авторы. Студенты/аспианты учатся формулировать заявки совместно с преподами, проходят все необходимые процедуры, выпускаются и имеют хотя бы какое-то понимание об авторском плане.
качество низкое, но это как сравнивать курсовые или магистрские работы с практическими работами уже на производстве.
сужу по себе, будучи человеком со стороны, пришел в свой ВУЗ в патентный отдел, сказал, что хочу подать патент от себя и друзей, за два года оформили на ВУЗ три патента (два прошли рецензию, одно нет) и одно изобретение, естественно не продлевали, но нам это было интересно и очень полезно для понимания в области авторского права, а так же в части оценки полезности изобретения. И да ВУЗу и патентному отделу большое спасибо.
ps: по изобретению и ПМ создано два разных устройства, которые успешно выпускаются, но их авторское право мы не отстаиваем по организационным причинам, да и некогда, очень узкоспециализированные изделия.
никто не ограничивает только отечественной элементной базой, проблема то паркомата в том, что он удаленно отключается производителем (как и ЧПУ станки и много другого "современного" оборудования), по этому собрать из китайских комплектующих, корпус собрать здесь, а поверх накатить свой софт,поставить сервер. Собственно софт - самый ответственный момент, который потребует больше всего времени отладки и поддержки.
на всю страну нужно даже не одна, а несколько групп/организаций производителей паркоматов. И да, даже одни работы по установке паркоматов и их последующего обслуживания кратно перекрывают зп разработчиков. Просто в современном мире шаблонное мышление у эффективных менеджеров срабатывает: купить-продать, а на перспективу никто задумываться не хочет.
в чем сложность разработать было паркомат самим?.. полгода разработки/отладки, ну и производство полгода... коллектив разработчиков 5-7 человек, поддержка 2-3 человека... На современной элементной базе - вообще конструктор. Софт да... но тоже конструктор для программиста.
на старте, наиболее вероятно, топливо/топливная сборка будут в защищенном контейнере выдерживающем взрыв и нештатное возвращение с орбиты. Есть отчет/уведомление в ООН по ядерным материалам на Луне-25, там такие нештатки были предусмотрены. Да опасность есть, но она минимизирована.
с этими определениями нацизма и фашизма очень сложно, в общем случае это фашизм: "фашизм характеризуется централизованной автократией, милитаризмом, жёсткой социальной иерархией, силовым подавлением оппозиции и индивидуальных свобод, а также стремлением к мобилизации общества и к тотальному контролю над обществом и экономикой." Автократия в данном случае трансформированг в главенство одной партии конкретной страны над другими странами, подчинение этой партии общества и экономики других стран. Фашизм это краняя правая ветвь традиционном лево-правовом политическом спектре.
я абсолютно не в курсе, как проверятся бортовая аппаратура, но исходя из смысла программной модели миссии - в неё загружаются оригиналы программного обеспечения (в том виде, в котором они программируются в изделие), которые исполняются на программной модели блока (движке), программная модель блока взаимодействует через модели каналов связи и модели внешних воздействий с остальными элементами изделия. В целях обеспечения отработки различных вариантов изменяются внешние воздействия и состояния блоков (вплоть до эмуляции отказов, сбоев, ошибочного поведения). В случае если все варианты перебрать не возможно (а их действительно адски много) выполняется симуляция миссии со случайными (в пределах) параметрами входных воздействий (по сути метод Монте-Карло). Симуляций, к счастью, можно провести очень много, можно сохранять промежуточные результаты и повторять с любой точки, проводить симуляции параллельно или изолировано. Естественно в вариант симуляции в обязательном виде попадают отказы, сбои отдельных блоков.
Теперь возвращаясь почему ошибка указанная в статье 100% выявляется на симуляции и не является программной ошибкой, а является организационной ошибкой. Если бы в модель КПА загружались оригинальные коды, тогда при симуляции отказа блока "БИУС-Л" мы бы получили то, что случилось в реальности. В данном случае программист не виноват - ему дали неполный алгоритм, он его реализовал, потом сдал ВП, его прогнали на КПА в котором реализуются исключительно штатные ситуации - все ок, претензий к "карманам и пуговицам" нет, но пиджак не сидит...
этого нет, если я правильно понимаю как головной исполнитель работает по ЕСКД и ГОСТ, то есть пункты ТЗ и их сдают как они там они написаны, не запариваясь на то, что должно происходить в случае отклонения данных от смежников.
«Согласно протоколу, при подлёте «Луны-25» к Луне бортовой компьютер станции должен был подать на «БИУС-Л» команду на включение акселерометров. Программисты эту команду подали (это было видно по циклограмме), то есть, по сути, тоже все сделали правильно, за исключением одного. Их программное обеспечение не проанализировало ответную реакцию «БИУС-Л»
Теперь, как нужно было, на мой очень диванный взгляд проверять на программной модели (даже не стенде). Запускать 100500 реализаций и случайным образом в каждой реализации отключать програмные модули (а также менять внешние параметры) и оценивать результат и варианты нештаток. В данном случае цифровой модели небыло, так как смоделированный отказ БИУС-Л, сразу бы указал на ошибку в алгоритме работы бортового компьютера с последующим крушением (на любой стадии проектирования). Я уверен, что цифровой модели миссии у головного исполнителя нет(((
ps: и обратно уверен, что в миссиях китайцев она есть, в современном проектировании без модели никуда(
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе Virtex в статье ниже. Добавлю, к ответу Spaceoddity, что такие схемы мажоритирования позволяют парировать одиночные сбои в логике. Насколько я знаю, такие подходы к реализации отказоустойчивой техники есть и у ПЛИС производителей Actel, Altera, Xilinx и других...
" Таким образом, в ПЛИС Virtex фирмы Xilinx при реализации троирования (Triple Module Redundancy – TMR) с целью повышения радиационной стойкости используются встроенные схемы выбора 2 из 3-х или мажоритирования (голосования по большинству голосов – Majority Voter Circuit). Для выдачи мажоритированного сигнала на контакты ПЛИС Virtex используется функция минорити. При этом она реализуется в трёх LUT, причём единичный сигнал формируется только в случае отличия данного входа от двух других, что обеспечивает на выходе буферов, не находящихся в третьем состоянии, всегда 0 или 1 без «смешения» и без использования подтягивающего резистора, то есть конфликты исключены. "
чтобы не повредило, есть троирование, проблема, как мне видится, именно в зашоренности при проектировании на "жесткой логике", вместо полноценного функционального программирования, когда на каждом этапе результат сверяется с моделью, при этом не только исполнительным модулем, но и контрольным.
ps: про то, что наши до сих пор проектируют блоки управления на БМК, можете мне не рассказывать, как они решают вопрос модификации софта, мне не ведомо... видимо ориентируясь на выполнение циклограммы по табличке...
я имел в виду, с какой суммы нужно выплачивать 27%? с очищенных от накладных или с оборота. Для, примера, на упрощёнке налог был 15% с суммы за вычетом расходов или 6% с оборота, выбирает организация сама. Если у меня продукция и 70% уходит на накладные расходы, я выбираю ставку с оборота (налоговый учет намного проще) 6% итого у меня остаётся 24% очищенных доходов, то сколько я должен отчислять Эпплу? Нужно ли мне платить 6% налогов с отчислений Эппл?
ps: если, что я не разработчик софта под мобилы, я разработчик железа, но экономика интересует, так как реальность, когда нельзя будет поставить софт на свой "Этот компьютер" уже близко.
27%? эээ, а с них нужно отчислять налоги или это 27% с остатка после уплаты всех налогов? И как учитывать себестоимость? то есть это после учета затрат?
в обычном бизнесе предположим 70% затраты и 30% то, что остается на развитие, часть из 30% уходит на закупку оборудования, непрофильные затраты и что-то формирует прибыль, а какая модель бизнеса тут?
скорее всего у предыдущего клиента, когда была вскрыта упаковка, залез баг еще мошкой, потом там под бга вырос из мелкого бага в большой...
так это же отлично? модуль съемный, значит можно будет демонтировать и разобраться с причиной утечки
лес рубят - щепки летят
90% подают ради того, чтобы подавать, 10% чему-то учатся, альтернатива только 0/0
вообще, если посмотреть со стороны, то 90% в ВУЗ поступает ради диплома, а не учиться, альтернатива - закрыть ВУЗы.
а вам не кажется, что цель ВУЗа, в том числе и обучить порядку подачи патентов? возможно мы в статистике видим перегиб, когда отдельные вузовские работники подают десятки заявок, но большая часть заявок от ВУЗов это разные авторы. Студенты/аспианты учатся формулировать заявки совместно с преподами, проходят все необходимые процедуры, выпускаются и имеют хотя бы какое-то понимание об авторском плане.
качество низкое, но это как сравнивать курсовые или магистрские работы с практическими работами уже на производстве.
сужу по себе, будучи человеком со стороны, пришел в свой ВУЗ в патентный отдел, сказал, что хочу подать патент от себя и друзей, за два года оформили на ВУЗ три патента (два прошли рецензию, одно нет) и одно изобретение, естественно не продлевали, но нам это было интересно и очень полезно для понимания в области авторского права, а так же в части оценки полезности изобретения. И да ВУЗу и патентному отделу большое спасибо.
ps: по изобретению и ПМ создано два разных устройства, которые успешно выпускаются, но их авторское право мы не отстаиваем по организационным причинам, да и некогда, очень узкоспециализированные изделия.
зачем гадать, если в вестнике НПОЛ есть описание языка программирования
никто не ограничивает только отечественной элементной базой, проблема то паркомата в том, что он удаленно отключается производителем (как и ЧПУ станки и много другого "современного" оборудования), по этому собрать из китайских комплектующих, корпус собрать здесь, а поверх накатить свой софт,поставить сервер. Собственно софт - самый ответственный момент, который потребует больше всего времени отладки и поддержки.
тем более, зачем ставить было, если уже есть опыт того, что монстроидальные паркоматы уже устарели как концепт оплаты парковки...
на всю страну нужно даже не одна, а несколько групп/организаций производителей паркоматов. И да, даже одни работы по установке паркоматов и их последующего обслуживания кратно перекрывают зп разработчиков. Просто в современном мире шаблонное мышление у эффективных менеджеров срабатывает: купить-продать, а на перспективу никто задумываться не хочет.
в чем сложность разработать было паркомат самим?.. полгода разработки/отладки, ну и производство полгода... коллектив разработчиков 5-7 человек, поддержка 2-3 человека... На современной элементной базе - вообще конструктор. Софт да... но тоже конструктор для программиста.
на старте, наиболее вероятно, топливо/топливная сборка будут в защищенном контейнере выдерживающем взрыв и нештатное возвращение с орбиты. Есть отчет/уведомление в ООН по ядерным материалам на Луне-25, там такие нештатки были предусмотрены. Да опасность есть, но она минимизирована.
с этими определениями нацизма и фашизма очень сложно, в общем случае это фашизм: "фашизм характеризуется централизованной автократией, милитаризмом, жёсткой социальной иерархией, силовым подавлением оппозиции и индивидуальных свобод, а также стремлением к мобилизации общества и к тотальному контролю над обществом и экономикой." Автократия в данном случае трансформированг в главенство одной партии конкретной страны над другими странами, подчинение этой партии общества и экономики других стран. Фашизм это краняя правая ветвь традиционном лево-правовом политическом спектре.
я абсолютно не в курсе, как проверятся бортовая аппаратура, но исходя из смысла программной модели миссии - в неё загружаются оригиналы программного обеспечения (в том виде, в котором они программируются в изделие), которые исполняются на программной модели блока (движке), программная модель блока взаимодействует через модели каналов связи и модели внешних воздействий с остальными элементами изделия. В целях обеспечения отработки различных вариантов изменяются внешние воздействия и состояния блоков (вплоть до эмуляции отказов, сбоев, ошибочного поведения). В случае если все варианты перебрать не возможно (а их действительно адски много) выполняется симуляция миссии со случайными (в пределах) параметрами входных воздействий (по сути метод Монте-Карло). Симуляций, к счастью, можно провести очень много, можно сохранять промежуточные результаты и повторять с любой точки, проводить симуляции параллельно или изолировано. Естественно в вариант симуляции в обязательном виде попадают отказы, сбои отдельных блоков.
Теперь возвращаясь почему ошибка указанная в статье 100% выявляется на симуляции и не является программной ошибкой, а является организационной ошибкой. Если бы в модель КПА загружались оригинальные коды, тогда при симуляции отказа блока "БИУС-Л" мы бы получили то, что случилось в реальности. В данном случае программист не виноват - ему дали неполный алгоритм, он его реализовал, потом сдал ВП, его прогнали на КПА в котором реализуются исключительно штатные ситуации - все ок, претензий к "карманам и пуговицам" нет, но пиджак не сидит...
этого нет, если я правильно понимаю как головной исполнитель работает по ЕСКД и ГОСТ, то есть пункты ТЗ и их сдают как они там они написаны, не запариваясь на то, что должно происходить в случае отклонения данных от смежников.
Теперь, как нужно было, на мой очень диванный взгляд проверять на программной модели (даже не стенде). Запускать 100500 реализаций и случайным образом в каждой реализации отключать програмные модули (а также менять внешние параметры) и оценивать результат и варианты нештаток. В данном случае цифровой модели небыло, так как смоделированный отказ БИУС-Л, сразу бы указал на ошибку в алгоритме работы бортового компьютера с последующим крушением (на любой стадии проектирования). Я уверен, что цифровой модели миссии у головного исполнителя нет(((
ps: и обратно уверен, что в миссиях китайцев она есть, в современном проектировании без модели никуда(
датчики дублирования стараются делать на разных физических принципах, если один волоконно-оптический, то другой мемс и/или гироскопический
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
не начинать маневр, остались бы на орбите, это мог быть сбой, а не отказ, тогда маневр бы выполнили на следующем витке
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе Virtex в статье ниже. Добавлю, к ответу Spaceoddity, что такие схемы мажоритирования позволяют парировать одиночные сбои в логике. Насколько я знаю, такие подходы к реализации отказоустойчивой техники есть и у ПЛИС производителей Actel, Altera, Xilinx и других...
http://vestnik.rsreu.ru/images/archive/2017/1-59/11_.pdf
чтобы не повредило, есть троирование, проблема, как мне видится, именно в зашоренности при проектировании на "жесткой логике", вместо полноценного функционального программирования, когда на каждом этапе результат сверяется с моделью, при этом не только исполнительным модулем, но и контрольным.
ps: про то, что наши до сих пор проектируют блоки управления на БМК, можете мне не рассказывать, как они решают вопрос модификации софта, мне не ведомо... видимо ориентируясь на выполнение циклограммы по табличке...