Я очень хорошо помню 1986..7..9-го года. И некоторые утверждения в статью кажутся мне не совсем точными. ГДР производила вполне годные компьютеры. Например тот же Роботрон делал клоны IBM PC/XT. К тому же у нас в Болгарии тоже делали и клоны Apple II и клоны PC/XT. Которые наверное в ГДР тоже экспортировали. (А у нас кстати импортировали принтеры Роботрон — вполне годные).
Так что, писать, что C64 был лучше, это сугубо личные пристрастия, но никак не факт. Как домашняя игровая приставка, может быть. Но никак больше.
Это не прогноз. Это простое наблюдение. Экспоненциального роста уже нет. И давно. Не заметили что ли? Производительность увеличивается в лучшем случае полиномиально. И степень полинома (мне кажется) не намного больше единицы.
Ну, так глубоко я не думаю и тем более не намекаю. Но понравилось.
… надо делать кодек для тех вычислительных устройств которые есть сейчас.
А вот это надо на камне вытесать и поставить на вход факультетов ИТ:
«Пиши программы для существующих компютеров, ибо в будущем смотреть тебе не дано!»
А авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будет в будущем. Было, да сплыло. Недолго музыка играла… Ну и так далее. :D
К тому же, как и другие наверх отметили, для видеокодека важно не только чтобы компрессия была выше. Дешевая декомпрессия, не побоюсь сказать, намного важнее. А с этом у авторов прямо беда какая-то — дешевая декомпрессия даже и не предвидится.
Интересно понял что-то не так в середине статьи. Смотрю, а она на английском. :D
Но претензии все-таки есть:
To provide the 25MHz clock for the camera we used Phase-Locked Loop (PLL) which is a closed-loop frequency-control system to provide the needed clock from the 50MHz provided from the board.
Чтобы сделать из 50МГц, 25МГц, не нужен PLL. Нужен просто делитель на 2 — простой триггер. Или "Over-engineering is our lifestyle"?
Не поняли. Здесь не вопрос в том хватит — не хватит. Конечно не хватит. Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
У меня предложения есть. Ведь, я тоже разработчик свободного ПО. Только карма немного осталась… Но с другой стороной – делай что надо и будь что будет. :D
Вся идея npm очевидно порочная. Автоматическое управление пакетов совершенно не решает ад зависимостей, только усугубляет его, потому что легче становится работать с очень глубокими графами зависимостей.
А надо научится уменьшать эту глубину. И ветки этого графа обязательно надо проходить через библиотеки которые контролируются правильно и большим сообществом. Тогда и риски понижаться значительно.
Вот у меня например зависимостей в текущем проекте от: 1. MUSL; 2. SQLite; 3. И все.
Я очень хорошо помню 1986..7..9-го года. И некоторые утверждения в статью кажутся мне не совсем точными. ГДР производила вполне годные компьютеры. Например тот же Роботрон делал клоны IBM PC/XT. К тому же у нас в Болгарии тоже делали и клоны Apple II и клоны PC/XT. Которые наверное в ГДР тоже экспортировали. (А у нас кстати импортировали принтеры Роботрон — вполне годные).
Так что, писать, что C64 был лучше, это сугубо личные пристрастия, но никак не факт. Как домашняя игровая приставка, может быть. Но никак больше.
Только что именно они покупают на те 17%? Ведь не все поголовно хронически больные.
Праздновать активно не буду. Открою пиво, возьму котлеты и почитаю еще раз код проекта насчет дыры в безопасности. :)
Я что-то подобное писал на базе XML и тоже для борьбы с ботами. Кстати с неясным результатам. :D
Иду по ссылке. Если не вернусь, считайте коммунистом....
П.П. Упал только таб — FF63.0.3, Linux, 4GB RAM и 8GB swap. Упал сравнительно быстро через 1..2 минуты интенсивного выделения памяти.
Согласен. Тогда так: MUSL зависит только от ничего. И так как ничего с открытым кодом (пустой файл) то он тоже может быть проверен на уязвимости. :P
Но не экспоненциально же! А это важно и меняет все!
А кстати, люди смотрят видео не на серверах и даже не на десктопах, а на телефонах.
А я бы взял. 12 рублей с вас, раз хочете жуликов кормить. Гарантирую что второй раз предлагать не будет.
Это не прогноз. Это простое наблюдение. Экспоненциального роста уже нет. И давно. Не заметили что ли? Производительность увеличивается в лучшем случае полиномиально. И степень полинома (мне кажется) не намного больше единицы.
А люди будут обмениваться файлами обучения. И конечно появится проект "decoder34.rules" – коефициенты для сетки, декодирующую каждый фильм в порно. :D
Ну, так глубоко я не думаю и тем более не намекаю. Но понравилось.
А вот это надо на камне вытесать и поставить на вход факультетов ИТ:
«Пиши программы для существующих компютеров, ибо в будущем смотреть тебе не дано!»
А авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будет в будущем. Было, да сплыло. Недолго музыка играла… Ну и так далее. :D
К тому же, как и другие наверх отметили, для видеокодека важно не только чтобы компрессия была выше. Дешевая декомпрессия, не побоюсь сказать, намного важнее. А с этом у авторов прямо беда какая-то — дешевая декомпрессия даже и не предвидится.
Это сигнал, которой подается на внешную камеру. И конечно, решения можно всякие, но PLL всетаки перебор. ИМХО.
Я вас не минусовал. И вообще я очень, очень редко минусую кого нибудь. И никогда как ответ на шутку или иронию.
Интересно понял что-то не так в середине статьи. Смотрю, а она на английском. :D
Но претензии все-таки есть:
Чтобы сделать из 50МГц, 25МГц, не нужен PLL. Нужен просто делитель на 2 — простой триггер. Или "Over-engineering is our lifestyle"?
Наверное сарказмы у нас разные. Мне кажется, что и вы не так умелы. :P
Не поняли. Здесь не вопрос в том хватит — не хватит. Конечно не хватит. Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
Не, не будет больше увеличения мощности.
Ну, SQLite зависит от MUSL, a MUSL от ничего не зависит. Как то так. :P
Так что да, имею возможность.
Тот коммент – оформит в статью!
Очень даже имеет.
У меня предложения есть. Ведь, я тоже разработчик свободного ПО. Только карма немного осталась… Но с другой стороной – делай что надо и будь что будет. :D
Вся идея npm очевидно порочная. Автоматическое управление пакетов совершенно не решает ад зависимостей, только усугубляет его, потому что легче становится работать с очень глубокими графами зависимостей.
А надо научится уменьшать эту глубину. И ветки этого графа обязательно надо проходить через библиотеки которые контролируются правильно и большим сообществом. Тогда и риски понижаться значительно.
Вот у меня например зависимостей в текущем проекте от: 1. MUSL; 2. SQLite; 3. И все.