Вообще не понимаю с чем вы спорите, с тем что в Росатом не входят предприятия ядерного оружейного комплекса? Тем что там не занимаются разработкой и производством ЯО? Вот вам выше вики. Конечно вы можете дальше спустится в уровне спора, что вики это не аргумент, и требовать от меня пруфов.
А товарищ майор, потому что если бы я имел доступ к подобным пруфам(чисто теоретически), то вы подвели бы меня под статью.
Какое законодательство? Это описание того, чем занимается федеральное министерство. По поводу Росатома, хороша попытка товарищ майор, но нет. Могу только поделится той же википедией.
В состав «Росатома» входят все гражданские атомные компании России, предприятия ядерного оружейного комплекса, научно-исследовательские организации, а также атомный ледокольный флот. «Росатом» управляет атомными электростанциями России.
В состав госкорпорации «Росатом» входят предприятия оборонно-промышленного значения. Дирекция по ядерному оружейному комплексу включает ядерные центры в Сарове (ВНИИЭФ) и Снежинске (ВНИИТФ), ПО «Маяк» в городе Озёрске Челябинской области, комбинат «Электрохимприбор» в городе Лесном Свердловская области, Приборостроительный завод в городе Трёхгорном Челябинской области и другие[52].
Разработку ядерных зарядов осуществляют ВНИИЭФ и ВНИИТФ, разработку ядерных боеприпасов — ВНИИЭФ, ВНИИТФ и ВНИИА, серийное производство ядерных боеприпасов — «Электрохимприбор» и «Приборостроительный завод».
The United States Department of Energy (DOE) is an executive department of the U.S. federal government that oversees U.S. national energy policy and manages the research and development of nuclear power and nuclear weapons in the United States. The DOE oversees the U.S. nuclear weapons program, nuclear reactor production for the United States Navy, energy-related research, and domestic energy production and energy conservation.
Росатом так же как Министерство Энергетики в США является основным государственным оператором ЯО, дальше можете сами додумать. (это все из википедии, товарищ майор)
Опять же поделюсь наблюдениями почему так происходит, в данном "секторе". Либо все эти специалисты не особо то и нужны. Либо есть главный инженер либо его помощник, которые получают те самые 150-200 тыщ, и дальше всю систему клинет - "разве может этот сопляк получать столько же".
Технология оптимизации для VLIW сильно отличается от классических RISC/CISC. Переделывать llvm под VLIW это очень долгий, трудный и не благодарный процесс. При этом вы никогда не сможете влить это в апстрим, потому что поддерживать существенную разработку под мертвую архитектуру, никому не нужно. Самый реалистичный и простой вариант, это сделать "бэкенд" для LLVM, который будет транслироваться в C код, и дальше уходить в их проприетарный бэкенд.
Подобный бэкенд для llvm существует, но находится в слабо поддерживаемом состоянии. Так же это поможет избавится от EDG, который насколько я понимаю стал "санкционным".
А расскажите как она работает? ну там за пределом папок, файлов и путей в PATH. (все тоже самое, что есть в любой ОС) Потому что минимальное копание дальше приводит к: реестру, COM интерфейсам и бинарникам/библиотекам о которых практически ничего не известно, если это конечно ни какая-то распространенная библиотека с официальной документацией. Это мы даже еще не спустились на уровень ядра и драйверов.
Да я плохо прочитал статью, каюсь, второй параграф с оценкой СКО, как вероятность болезни одного человека не применим. Все остальное верно, необходимо либо задать функцию полезности отношения к риску, либо исходить из того, что это повторяющийся эксперимент.
На самом деле это все имеет смысл, в рамках широко известного mean-variance tradeoff, эта задача в принципе не имеет решения, пока не задана функция полезности нашего отношения к риску. За исключением случая, когда единственное решение лежит на границе эффективности (нет смысла рассматривать варианты, с меньшим или равным мат.ожиданием и большей дисперсией). И это довольно часто бывает на практике.
Но в этом случаи. Для 90% на тысячу, мы имеем мат. ожидание 900, и СКО(сигму) +/- 9.5(бернуллиевская случайная величина, с очевидным применением ЦПТ). Плохо то что второй вариант дает нулевую дисперсию, но при любых разумных предположениях о функции полезности, мы приходим к тому что чтобы получить больше смертей для первого случая, чем для второго, нам надо вылететь за 10 сигм, что практически "невозможно".
PS: ну и довольно очевидно, что если это повторяющийся эксперимент, то при любом значительно бОльшем мат. ожидании, и разумных предположениях об дисперсии, надо выбирать именно этот вариант. Так как в долгую это спасет больше людей. (СКО/сигма растет как корень из n). Опять же мы очевидно исходим из этого предположения, если хотим побольше убить(а не спасти), то действовать надо ровно противоположно.
Нужны реалистичные оценки "доверительного интервала" (не важно фрекюционистского или баесовского) и модель перевода в фактическую летальность на популяции для этих "90% молодых людей не заразились в течении месяца", без этого это просто задача не имеющая смысла. В духе что лучше, яблоки или апельсины.
Не 10 миллиардов, а 700 миллионов. 10 это бумажная оценка стоимости всей компании, рассчитываемая от стоимости проданной доли. Да и реальный ущерб, был скорее всего в районе 450 миллионов, так как на балансе что-то да осталось.
Это довольно сложно назвать зиц-председательством, мошенничеством - да. Да и деньги по масштабам индустрии, там не такие чтобы сильно большие, на самом деле.
"Оболочка" и прочее это просто приложения Java VM(да в андройде она переделанная но не будем вдаваться в подробности) использующие стандартное системное API, и совсем немножко более интегрированные в систему. Чтобы поддерживать, их надо просто модифицировать для следующих версий API. Сама "система" начинается с уровня ниже, там где лежит реализация этих системных API, Java кода, его JNI интерфейсов к нативному, нативных сервисах, HAL и Linux ядре(и конечно драйверах, которые там по большей части, совсем не от ванильного десктопного линуха).
Судя по тому что написано про GrapheneOS у них на сайте, это ни просто оболочка, вопрос лишь в том насколько масштабные их изменения на уровне системы.
"Эксперт" из подкаста сам видимо ничего кроме приложений под андройд не разрабатывал. И имеет довольно посредственное представление как это устроено внутри. (чего стоит разговор про SDK, который из того же AOSP и собирается)
Если что сам собирал AOSP + BSP(то есть полностью из сырцов), для одного китайского железа, и оно работало в первом приближении(да там были некоторые косяки с дровами, но у меня была задача просто посмотреть это все в принципе).
GMS сервисы тоже не настолько сложная штука. Почему из производителей никому не нужна Harmony OS, тоже довольно очевидно. Потому что продаются девайсы не только в Китае, и потребители ожидают увидеть "полный андройд" а ни какую-то переделку. А фрагментирвать(андройд/harmony os) просто так за спасибо, тоже никому не нужно.
Вообще не понимаю с чем вы спорите, с тем что в Росатом не входят предприятия ядерного оружейного комплекса? Тем что там не занимаются разработкой и производством ЯО? Вот вам выше вики. Конечно вы можете дальше спустится в уровне спора, что вики это не аргумент, и требовать от меня пруфов.
А товарищ майор, потому что если бы я имел доступ к подобным пруфам(чисто теоретически), то вы подвели бы меня под статью.
Какое законодательство? Это описание того, чем занимается федеральное министерство. По поводу Росатома, хороша попытка товарищ майор, но нет. Могу только поделится той же википедией.
https://ru.wikipedia.org/wiki/Росатом
https://en.wikipedia.org/wiki/United_States_Department_of_Energy
Возможно, товарищ майор )
Росатом так же как Министерство Энергетики в США является основным государственным оператором ЯО, дальше можете сами додумать. (это все из википедии, товарищ майор)
Опять же поделюсь наблюдениями почему так происходит, в данном "секторе". Либо все эти специалисты не особо то и нужны. Либо есть главный инженер либо его помощник, которые получают те самые 150-200 тыщ, и дальше всю систему клинет - "разве может этот сопляк получать столько же".
Технология оптимизации для VLIW сильно отличается от классических RISC/CISC. Переделывать llvm под VLIW это очень долгий, трудный и не благодарный процесс. При этом вы никогда не сможете влить это в апстрим, потому что поддерживать существенную разработку под мертвую архитектуру, никому не нужно. Самый реалистичный и простой вариант, это сделать "бэкенд" для LLVM, который будет транслироваться в C код, и дальше уходить в их проприетарный бэкенд.
Подобный бэкенд для llvm существует, но находится в слабо поддерживаемом состоянии. Так же это поможет избавится от EDG, который насколько я понимаю стал "санкционным".
Классика жанра, "нам нужны высоко квалифицированные, мало оплачиваемые специалисты".
Не то чтобы я докапываюсь, мне действительно интересно. Но что такое "широкое API" ?
Или его не было, в таких случаях если хотят докопаться, отследят все, в том числе финансовые связи.
А расскажите как она работает? ну там за пределом папок, файлов и путей в PATH. (все тоже самое, что есть в любой ОС) Потому что минимальное копание дальше приводит к: реестру, COM интерфейсам и бинарникам/библиотекам о которых практически ничего не известно, если это конечно ни какая-то распространенная библиотека с официальной документацией. Это мы даже еще не спустились на уровень ядра и драйверов.
В данном случаи, крайне вероятно, что организатор и мошенник это одно лицо. Каких-то других внятных версий я не видел.
Да я плохо прочитал статью, каюсь, второй параграф с оценкой СКО, как вероятность болезни одного человека не применим. Все остальное верно, необходимо либо задать функцию полезности отношения к риску, либо исходить из того, что это повторяющийся эксперимент.
На самом деле это все имеет смысл, в рамках широко известного mean-variance tradeoff, эта задача в принципе не имеет решения, пока не задана функция полезности нашего отношения к риску. За исключением случая, когда единственное решение лежит на границе эффективности (нет смысла рассматривать варианты, с меньшим или равным мат.ожиданием и большей дисперсией). И это довольно часто бывает на практике.
Но в этом случаи. Для 90% на тысячу, мы имеем мат. ожидание 900, и СКО(сигму) +/- 9.5(бернуллиевская случайная величина, с очевидным применением ЦПТ). Плохо то что второй вариант дает нулевую дисперсию, но при любых разумных предположениях о функции полезности, мы приходим к тому что чтобы получить больше смертей для первого случая, чем для второго, нам надо вылететь за 10 сигм, что практически "невозможно".
PS: ну и довольно очевидно, что если это повторяющийся эксперимент, то при любом значительно бОльшем мат. ожидании, и разумных предположениях об дисперсии, надо выбирать именно этот вариант. Так как в долгую это спасет больше людей. (СКО/сигма растет как корень из n). Опять же мы очевидно исходим из этого предположения, если хотим побольше убить(а не спасти), то действовать надо ровно противоположно.
Нужны реалистичные оценки "доверительного интервала" (не важно фрекюционистского или баесовского) и модель перевода в фактическую летальность на популяции для этих "90% молодых людей не заразились в течении месяца", без этого это просто задача не имеющая смысла. В духе что лучше, яблоки или апельсины.
Не 10 миллиардов, а 700 миллионов. 10 это бумажная оценка стоимости всей компании, рассчитываемая от стоимости проданной доли. Да и реальный ущерб, был скорее всего в районе 450 миллионов, так как на балансе что-то да осталось.
Это довольно сложно назвать зиц-председательством, мошенничеством - да. Да и деньги по масштабам индустрии, там не такие чтобы сильно большие, на самом деле.
"Её отец, Кристиан Расмус Холмс IV, занимал пост вице-президента в энергетической компании Enron."
С такими генами, грех чтобы не получилось. (/s)
"Оболочка" и прочее это просто приложения Java VM(да в андройде она переделанная но не будем вдаваться в подробности) использующие стандартное системное API, и совсем немножко более интегрированные в систему. Чтобы поддерживать, их надо просто модифицировать для следующих версий API. Сама "система" начинается с уровня ниже, там где лежит реализация этих системных API, Java кода, его JNI интерфейсов к нативному, нативных сервисах, HAL и Linux ядре(и конечно драйверах, которые там по большей части, совсем не от ванильного десктопного линуха).
Судя по тому что написано про GrapheneOS у них на сайте, это ни просто оболочка, вопрос лишь в том насколько масштабные их изменения на уровне системы.
"Эксперт" из подкаста сам видимо ничего кроме приложений под андройд не разрабатывал. И имеет довольно посредственное представление как это устроено внутри. (чего стоит разговор про SDK, который из того же AOSP и собирается)
Если что сам собирал AOSP + BSP(то есть полностью из сырцов), для одного китайского железа, и оно работало в первом приближении(да там были некоторые косяки с дровами, но у меня была задача просто посмотреть это все в принципе).
GMS сервисы тоже не настолько сложная штука. Почему из производителей никому не нужна Harmony OS, тоже довольно очевидно. Потому что продаются девайсы не только в Китае, и потребители ожидают увидеть "полный андройд" а ни какую-то переделку. А фрагментирвать(андройд/harmony os) просто так за спасибо, тоже никому не нужно.