Не то, что-то с таким подходом. Не доложно быть так. Не может нормальная технология лажать в методе из одной строки. Почему для обновления одного булевого поля вообще нужно знать про существование @DynamicUpdate? Почему простейшая операция зависит от таких нюансов? Почему, чтобы система работала надёжно, я должен помнить десятки подобных особенностей?
Тем не менее, такой код - совершенно идеоматический для исходников ядра BSD. Что мешает найти и проверить все случаи использования такого кода, добавив в компилятор (ну ОК, вменяемых статических анализаторов 30 лет назад не было)? Что мешало это сделать 30 лет назад?
Я, когда как раз в начале 90-х первый раз увидел, что так делают, меня сразу тригернуло. Мне было тогда 19 или типа того. Поэтому поверил на слово старшим товарищам. Но не всем же тогда было 19, кто видел этот код :)
В общем, это история обычного человеческого разгильдяйства. Однако включение в сценарий крутого ИИ делает эту историю увлекательной :)
Дальше — самое красивое. TCP sequence numbers — 32-битные целые. Они wrap around (переполняются). OpenBSD сравнивает их так: (int)(a - b) < 0. Это корректно работает, когда a и b находятся в пределах 2³¹ друг от друга — что в реальных условиях всегда так.
При всём при дом, знаковое переполнение в C - это UB. Сравнение целых, которые могут ходить по кругу, на больше/меньше, с помощью выражения (int)(a - b) < 0 - это идеоматическая конструкция в Сишном коде из 70-х - 90-х. В ядре BSD таких полно, в самых разных местах.
Осознать проблему и сделать соответствующую проверку в компиляторе можно было 30 лет назад. Без всякого там волшебного ИИ.
Почему не сделали? “Пока гром не грянет, мужик не перекрестится” - это не только про русских, это про вообще людей.
Статья на тему, “как мне продать неведомую хрень, про которую никто не знает, что это такое и зачем оно ему нужно”.
Если бы у меня был работающий рецепт бессмертия, я взял бы в долю санитара из ближайшего хосписа, и через него распространял бы это снадобье среди больных. За умеренные деньги, хотя бы поначалу, чтобы заработать репутацию.
У каждого компьютера есть внутренние часы, обычно управляемые кварцевым резонатором. При подаче напряжения на эти резонаторы они колеблются на определённой частоте. Для большинства компьютерных часов стандартом выбрана частота 32768 Гц, потому что она является степенью двойки и упрощает подсчёт с точностью до одной секунды.
Это как сказать, что настенные часы обычно управляются маятником, и при заведении пружины этот маятник начинает колебаться.
Глаза режет, извините.
Кварцевый резонатор - это и есть тот самый маятник. Сам по себе он никуда не будет колебаться.
Кварцевый генератор - это схема на основе кварцевого резонатора, которая, как раз, и заставляет его колебаться на его резонансной частоте, выдавая эти колебания в виде электрического сигнала наружу, где с ними можно сделать что-нибудь полезное (например, заставить комбинацию счётчиков и драйверов индикаторных ламп показывать время суток, или превратить в электронную мелодию и т.п.)
Бывают, и нередко, изделия, совмещающие генератор с резонатором в одном корпусе.
Частота 32768 выбрана в древних бытовых электронных часах как компромисс между энергопотреблением от батарейки, которое растёт при увеличении частоты, и физическим размером резонатора, который растёт при уменьшении частоты. В современном компьютере не используется. Даже на IBM PC XT системные часы работали от генератора на 1.193182 MHz
Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай
Наконец, хотя этот предмет не из приятных, я должен упомянуть PL/1, язык программирования, документация которого обладает устрашающими размерами и сложностью. Использование PL/1 больше всего напоминает полет на самолете с 7000 кнопок, переключателей и рычагов в кабине. Я совершенно не представляю себе, как мы можем удерживать растущие программы в голове, когда из-за своей полнейшей вычурности язык программирования — наш основной инструмент, не так ли! — ускользает из-под контроля нашего интеллекта. И если мне понадобится описать влияние, которое PL/1 может оказывать на своих пользователей, ближайшее сравнение, которое приходит мне в голову, — это наркотик. Я помню лекцию в защиту PL/1, прочитанную на симпозиуме по языкам программирования высокого уровня человеком, который представился одним из его преданных пользователей. Но после похвал в адрес PL/1 в течение часа он умудрился попросить добавить к нему около пятидесяти новых “возможностей”, не предполагая, что главный источник его проблем кроется в том, что в нем уже и так слишком уж много “возможностей”. Выступающий продемонстрировал все неутешительные признаки пагубной привычки, сводящейся к тому, что он впал в состояние умственного застоя и может теперь только просить еще, еще, еще. Если FORTRAN называют детским расстройством, то PL/1, с его тенденциями роста подобно опасной опухоли, может оказаться смертельной болезнью.
Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…
Это называется Leaky abstraction. https://en.wikipedia.org/wiki/Leaky_abstraction
Увы, из удобных высокоуровневых абстракций иногда подтекают их низкоуровневые детали реализации.
А если из ИИ подтечёт? :)
Ну т.е., VPS-ка в Беларуси нам поможет?
Лень спорить про UB
Тем не менее, такой код - совершенно идеоматический для исходников ядра BSD. Что мешает найти и проверить все случаи использования такого кода, добавив в компилятор (ну ОК, вменяемых статических анализаторов 30 лет назад не было)? Что мешало это сделать 30 лет назад?
Я, когда как раз в начале 90-х первый раз увидел, что так делают, меня сразу тригернуло. Мне было тогда 19 или типа того. Поэтому поверил на слово старшим товарищам. Но не всем же тогда было 19, кто видел этот код :)
В общем, это история обычного человеческого разгильдяйства. Однако включение в сценарий крутого ИИ делает эту историю увлекательной :)
При всём при дом, знаковое переполнение в C - это UB. Сравнение целых, которые могут ходить по кругу, на больше/меньше, с помощью выражения
(int)(a - b) < 0- это идеоматическая конструкция в Сишном коде из 70-х - 90-х. В ядре BSD таких полно, в самых разных местах.Осознать проблему и сделать соответствующую проверку в компиляторе можно было 30 лет назад. Без всякого там волшебного ИИ.
Почему не сделали? “Пока гром не грянет, мужик не перекрестится” - это не только про русских, это про вообще людей.
Статья на тему, “как мне продать неведомую хрень, про которую никто не знает, что это такое и зачем оно ему нужно”.
Если бы у меня был работающий рецепт бессмертия, я взял бы в долю санитара из ближайшего хосписа, и через него распространял бы это снадобье среди больных. За умеренные деньги, хотя бы поначалу, чтобы заработать репутацию.
Поэтому вменяемая реализация синхронизации времени не позволит взять, и разом перенести время на год.
При этом всё же непонятно, каким образом это может сломать антивирусы и позволить выполнить вредоносный код
Я про размер самого кристалла, а не корпуса. Размер же корпуса определяется, скорее, удобством монтажа (разумется, кристалл должен помещаться внутри).
У батареешной RTC, да, вполне возможно. Как раз как тот самый компромисс между экономией батарейки и разумным размером резонатора.
Это как сказать, что настенные часы обычно управляются маятником, и при заведении пружины этот маятник начинает колебаться.
Глаза режет, извините.
Кварцевый резонатор - это и есть тот самый маятник. Сам по себе он никуда не будет колебаться.
Кварцевый генератор - это схема на основе кварцевого резонатора, которая, как раз, и заставляет его колебаться на его резонансной частоте, выдавая эти колебания в виде электрического сигнала наружу, где с ними можно сделать что-нибудь полезное (например, заставить комбинацию счётчиков и драйверов индикаторных ламп показывать время суток, или превратить в электронную мелодию и т.п.)
Бывают, и нередко, изделия, совмещающие генератор с резонатором в одном корпусе.
Частота 32768 выбрана в древних бытовых электронных часах как компромисс между энергопотреблением от батарейки, которое растёт при увеличении частоты, и физическим размером резонатора, который растёт при уменьшении частоты. В современном компьютере не используется. Даже на IBM PC XT системные часы работали от генератора на 1.193182 MHz
Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
Я, обычно, свой код как деревце выращиваю
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай
Я - явный чистолист, но в целом обхожусь постоянным вялотекущим рефакторингом вместо многократного переписывания. В остальном всё сходится.
Отладчиком иногда пользуюсь в качестве калькулятора :)
Может его там надо включить где-то в меню? За братишками вроде не отмечено, чтобы интерфенсы 7/1/4 в принтере были, да не работали…
А если что-то чуть более серьёзное, то внезапно выясняется, что у него система типов сложнее, чем у C++
Угу. Ещё скажите, что Питон - простой язык.
Заглянул из любопытства в ваш проект на гитхабе.
Вижу, принтер поддерживает IPP over USB, IPP, eSCL. Всё это вместе называется Apple Bonjour Printing, он же Apple AirPrint.
Т.е., по идее он должен работать на маке из коробки и без всяких специфических драйверов.
Очень смешно, если не работает. Прошивку обновлять не пробовали?
Я считаю Go прекрасным языком.
И нет, это не мой первый язык, и я отнюдь не новичок в профессии.
Наконец, хотя этот предмет не из приятных, я должен упомянуть PL/1, язык программирования, документация которого обладает устрашающими размерами и сложностью. Использование PL/1 больше всего напоминает полет на самолете с 7000 кнопок, переключателей и рычагов в кабине. Я совершенно не представляю себе, как мы можем удерживать растущие программы в голове, когда из-за своей полнейшей вычурности язык программирования — наш основной инструмент, не так ли! — ускользает из-под контроля нашего интеллекта. И если мне понадобится описать влияние, которое PL/1 может оказывать на своих пользователей, ближайшее сравнение, которое приходит мне в голову, — это наркотик. Я помню лекцию в защиту PL/1, прочитанную на симпозиуме по языкам программирования высокого уровня человеком, который представился одним из его преданных пользователей. Но после похвал в адрес PL/1 в течение часа он умудрился попросить добавить к нему около пятидесяти новых “возможностей”, не предполагая, что главный источник его проблем кроется в том, что в нем уже и так слишком уж много “возможностей”. Выступающий продемонстрировал все неутешительные признаки пагубной привычки, сводящейся к тому, что он впал в состояние умственного застоя и может теперь только просить еще, еще, еще. Если FORTRAN называют детским расстройством, то PL/1, с его тенденциями роста подобно опасной опухоли, может оказаться смертельной болезнью.
Э.Дейкстра, Смиренный программист, 1972
Как известно, у редактора vi есть всего два режима. В одном он пищит, в другом портит текст.
Зачем же сходу отламывать полезный режим?
Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…