Подтверждаю, что randomness depletion есть и у обычных линухов.
Выражается в жутких тормозах, если пытаться запустить несколько приложений, правильно инициализирующих свою криптографию. Линух ест по несколько байт энтропии для генерации случайных адресов, потом крипто модуль ест по несколько десятков байт для инициализации генератора псевдослучайных чисел.
Дела обстоят лучше у платформ с дешёвым оборудованием. Платформы с дорогим и надёжным оборудованием не имеют достаточно энтропии ни в работе диска, ни в работе HCA.
Дотнетовский async сам по себе говнокод. Внезапно "ужас, разработчики не умеют выделять GUI-тред" и выложили неразборчивую кучу кирпичей, результат предсказуем.
EDIT: в смысле, апи таки должно быть асинхронным. Но конкретно такое языковое решение - имхо больше запутывает, чем помогает.
А вот программирование явно надо преподавать по-другому. Уже давно гуи стоит классифицировать как системы реального времени, серверы - как системы массового обслуживания, ну и со всеми вытекающими последствиями.
Низкоуровневый API таки да. Но прикладной синхронный нужен - спокойно осуществлять подгрузку ресурсов во втором треде.
А программирование... Если поставить адекватные требования к софту, то большинство программистов придётся заново учить, а из вебдевелоперов 90% сразу в дворники, ибо безнадёжны. Увы, мечты.
> прикладной синхронный нужен - спокойно осуществлять подгрузку ресурсов во втором треде.
кстати да. а то наблюдаю тенденцию - заворачивать каждый ресурс в отдельный асинхронный загрузчик. looks nice до тех пор, пока не возникают dependencies, или их мало. как только их много, загружать всё последовательно в отдельном треде становится гораздо предпочтительнее в плане readability.
У тебя слабые аргументы. Хотя, начать надо с того, что "лучшая мобильная ос" - это оценочное суждение :)
Блокирование /dev/random тут вообще не при чём, она элементарно решается прямыми руками, ты же это понимаешь. У разрабов руки кривые, что они не позаботились об обработке ситуации блокировки или о запуске локального CSRNG, если это их устроит.
> а когда людям дают человеческий асинхронный апи - они > ОПЯТЬ строят из него говнокод
единственное преимущество асинхронного апи - это скорость. Кооперативная многозадачность таки вычислительно эффективнее вытесняющей. Поэтому низкоуровневый апи должен таки быть асинхронным. В этой связи можно вспомнить, что в линуксе нет асинхронных примитивов ядра для работы с файловой системой.
Конечные библиотеки должны быть синхронными, если только не ставится задача производительности любой ценой.
>У тебя слабые аргументы. я утверждаю не то, с чем ты пытаешься спорить
>Блокирование /dev/random тут вообще не при чём, она элементарно решается прямыми руками, ты же это понимаешь. У разрабов руки кривые Вообще-то, я именно об этом и пишу. Одна из многих мелочей, которые много лет портят репутацию платформе без каких-то особенных на то причин.
> В этой связи можно вспомнить, что в линуксе нет асинхронных примитивов ядра для работы с файловой системой. imho POSIX, к которому некоторые зачем-то стремятся, вообще один из худших стандартов, если уж на то пошло
> Конечные библиотеки должны быть синхронными для GUI-приложений? really?
Comments 50
Подтверждаю, что randomness depletion есть и у обычных линухов.
Выражается в жутких тормозах, если пытаться запустить несколько приложений, правильно инициализирующих свою криптографию. Линух ест по несколько байт энтропии для генерации случайных адресов, потом крипто модуль ест по несколько десятков байт для инициализации генератора псевдослучайных чисел.
Дела обстоят лучше у платформ с дешёвым оборудованием. Платформы с дорогим и надёжным оборудованием не имеют достаточно энтропии ни в работе диска, ни в работе HCA.
Reply
Об этот феномен я уже головой приложился недавно, ага. Идеальный компьютер имеет ноль энтропии.
Reply
Reply
Reply
Reply
EDIT: в смысле, апи таки должно быть асинхронным. Но конкретно такое языковое решение - имхо больше запутывает, чем помогает.
А вот программирование явно надо преподавать по-другому. Уже давно гуи стоит классифицировать как системы реального времени, серверы - как системы массового обслуживания, ну и со всеми вытекающими последствиями.
Reply
А программирование... Если поставить адекватные требования к софту, то большинство программистов придётся заново учить, а из вебдевелоперов 90% сразу в дворники, ибо безнадёжны. Увы, мечты.
Reply
кстати да. а то наблюдаю тенденцию - заворачивать каждый ресурс в отдельный асинхронный загрузчик. looks nice до тех пор, пока не возникают dependencies, или их мало. как только их много, загружать всё последовательно в отдельном треде становится гораздо предпочтительнее в плане readability.
Reply
Блокирование /dev/random тут вообще не при чём, она элементарно решается прямыми руками, ты же это понимаешь. У разрабов руки кривые, что они не позаботились об обработке ситуации блокировки или о запуске локального CSRNG, если это их устроит.
> а когда людям дают человеческий асинхронный апи - они
> ОПЯТЬ строят из него говнокод
единственное преимущество асинхронного апи - это скорость. Кооперативная многозадачность таки вычислительно эффективнее вытесняющей. Поэтому низкоуровневый апи должен таки быть асинхронным. В этой связи можно вспомнить, что в линуксе нет асинхронных примитивов ядра для работы с файловой системой.
Конечные библиотеки должны быть синхронными, если только не ставится задача производительности любой ценой.
Reply
я утверждаю не то, с чем ты пытаешься спорить
>Блокирование /dev/random тут вообще не при чём, она элементарно решается прямыми руками, ты же это понимаешь. У разрабов руки кривые
Вообще-то, я именно об этом и пишу. Одна из многих мелочей, которые много лет портят репутацию платформе без каких-то особенных на то причин.
> В этой связи можно вспомнить, что в линуксе нет асинхронных примитивов ядра для работы с файловой системой.
imho POSIX, к которому некоторые зачем-то стремятся, вообще один из худших стандартов, если уж на то пошло
> Конечные библиотеки должны быть синхронными
для GUI-приложений? really?
Reply
System.IO.File нахрена гуи-приложению, скажи. Пусть шлет себе мессаджи бекенду и всё.
Reply
Reply
Дривен же.
Reply
Алсо, Для прослушивания музыки необходимо установить Flash Player
Reply
Для Ютюба тоже нужен?
Reply
Reply
Leave a comment