В гор. Уфа "Поиски" продавались в ТЦ "Башкирия" в том же отделе, где и телевизоры. Самые крутые модели были с 286 процессором и EGA-видеокартой, но мне покупали, вроде в 1994 году, минимальный "Поиск 1.06" из позднесоветских комплектующих, он почти совместим был с PC XT и CGA-видеоадаптером, но без аппаратного знакогенератора, так что текстовый режим был весьма уныл)) Поскольку собирали их в Киеве, то клавиатура имела расширенную украинскими символами Ґ, Ї, Є кириллицу. Дисковод тоже докупили позже отдельно, и тогда у меня появился доступ к Turbo Pascal 5.5 (можно сказать, ранний прародитель Delphi) и Turbo Assembler.
Позже уже, когда на втором курсе универа учился, полноценный ПК взяли на CPU AMD 5x86. Обошелся он, вроде в 1996г, примерно в $1000, отцу за доллары и продали в магазине (но формально принимали только рубли)).
У меня почти новый (порядка года в щадящей эксплуатации), SSD WD Blue WDS500G2BOB-00YS70 внезапно стал очень медленно (~11МиБ/с) читать существенную часть ранее записанного, SMART беспроблемный при этом был. Понемногу всё с него перенёс, форматнул (вроде и TRIM делал фирменной утилитой), и он как ни в чём не бывало стал опять нормально работать. Но система теперь на старом, проверенном годами PLEXTOR PX-128M5S (три штуки у меня таких беспроблемных M5S и M3S, каждый несколько компов пережил, а один на сервере 1С молодость потерял))... Ещё Intel SSD X25-V есть в работе примерно с 2010 года, тоже на СУБД был начальных пару лет, сейчас просто системный в тёщином компе :)
Использую autossh несколько лет под debian на BananaPi M1, прокидывает 443й порт с ультрадешевой VPS со статическим IP на домашний микросервер с динамическим IP.
Ну как использую... Настроил автозапуск в рутовом crontab и оно работает.
При указанном использовании никаких подводных камней или проблем за несколько лет. В debian ставится одной командой.
Имхо, если проводить больше времени с детьми только ради этого процесса, то дети лишаются стимула быть более самостоятельными/независимыми, привыкают к постоянному контролю и вниманию со стороны родителей. И при сколь-либо значительном кол-ве детей (от двух и более) такое времяпрепровождение будет отнимать много дефицитного свободного времени у итак занятых и "застрессованных" родителей. С другой стороны, если дети сопровождают родителей в процессе повседневной жизнедеятельности, то они естественным образом обучаются и перенимают соответствующие навыки. Но современным сложным процессам таким образом детей не обучить, это скорее про жизнь в естественной (не городской) среде и для процессов типа собирательства, охоты, приготовления пищи, строительства убежищ из подручных материалов и т.п..
Эпизодически что-то по мелочи может ломаться после обновлений.
Сейчас, например, страничка Transmission Web GUI (это torrent-клиент под linux) некорректно отображается в FF (действия и кнопки не работают), хотя раньше норм было. При этом в Edge и прочих Chrome-based браузерах нормально всё.
Я к тому, что в практической задаче, наверное, следовало бы вынести сложную арифметику дат из цикла/таймера планировщика, и работать с сортированным списком int64-таймстампов следующих срабатываний записей. При срабатывании записи вычислять время следующего её срабатывания и опять добавлять в список. Тогда каждый тик планировщика обычно обходился бы в O(1) и не потребовалась бы сверхоптимизация арифметики дат.
Описанный в исходной задаче API видится избыточным и ограничивающим достижимую производительность, ведь для реальной задачи реализации высокопроизводительного планировщика, имхо, хватило бы одного метода вида "получить DateTime следующего срабатывания по заданной маске относительно текущего DateTime". Если рассматривать как чисто академическую задачу - тогда вопросов никаких)
Делал давно что-то вроде RTOS для 80186-совместимых контроллеров, именно INT64-счетчик миллисекунд от старта системы был удобен для планировщика.
Для отложенных событий (обычно это было пробуждение заданного потока в заданный момент времени) вычисляется будущее время срабатывания и соответствующая запись добавляется в сортированный по возрастанию времени список. Вот соответствующий старый код, не особо читаемый.
В таймерной функции планировщика просто в цикле, пока время первой записи списка <= текущему времени, отрабатываем и удаляем голову списка (например, пробуждаем все потоки, которые должны проснуться в текущую миллисекунду). С частотой 1000Гц нормально всё планировалось на не особо быстром CPU.
Арифметика же на датах - это, имхо, скорее академическая задача, чем то, что нужно реализовывать на практике.
Икеевские РИЭТ самой малой мощности (эквивалент 40Вт накаливания) в подъезде светят внутри плафонов, самая ранняя уже года 2 стоит, остальные год, цены были от 50 до 33р в разное время. Сейчас цена 39р (но это уже следующее поколение).
Курсач в студенчестве делал — реализацию Prolog на Delphi.
Книжку толстую крутую давали по нюансам реализаций пролога, название не вспомню.
Тема неплохо зашла, ханойские башни и прочие примерчики решались, компилировалось в «шитый» x86-код, вот только реализацию GC не осилил (курсач и так приняли), прога работала до переполнения кучи.
Мечталось ещё реализовать кроме бинарной логики предикатов {0, 1} ещё и «вероятностную» (0..1) и соответствующе допилить механизм логического вывода, было бы что-то вроде Fuzzy Logic Prolog :-)
Такая "годнота", что машинально стал искать плашку [Перевод] :-)
В универе давно делал VM Пролога, тоже стековую, +шитый код.
Вы правы, в "Поиск 1", оказывается, стоял КМ1810ВМ88 с восьмибитной шиной данных.
Но с т.з. программной совместимости разницы особо не было.
В гор. Уфа "Поиски" продавались в ТЦ "Башкирия" в том же отделе, где и телевизоры. Самые крутые модели были с 286 процессором и EGA-видеокартой, но мне покупали, вроде в 1994 году, минимальный "Поиск 1.06" из позднесоветских комплектующих, он почти совместим был с PC XT и CGA-видеоадаптером, но без аппаратного знакогенератора, так что текстовый режим был весьма уныл))
Поскольку собирали их в Киеве, то клавиатура имела расширенную украинскими символами Ґ, Ї, Є кириллицу.
Дисковод тоже докупили позже отдельно, и тогда у меня появился доступ к Turbo Pascal 5.5 (можно сказать, ранний прародитель Delphi) и Turbo Assembler.
Позже уже, когда на втором курсе универа учился, полноценный ПК взяли на CPU AMD 5x86. Обошелся он, вроде в 1996г, примерно в $1000, отцу за доллары и продали в магазине (но формально принимали только рубли)).
У меня почти новый (порядка года в щадящей эксплуатации),
SSD WD Blue WDS500G2BOB-00YS70 внезапно стал очень медленно (~11МиБ/с) читать существенную часть ранее записанного, SMART беспроблемный при этом был.
Понемногу всё с него перенёс, форматнул (вроде и TRIM делал фирменной утилитой), и он как ни в чём не бывало стал опять нормально работать.
Но система теперь на старом, проверенном годами PLEXTOR PX-128M5S (три штуки у меня таких беспроблемных M5S и M3S, каждый несколько компов пережил, а один на сервере 1С молодость потерял))...
Ещё Intel SSD X25-V есть в работе примерно с 2010 года, тоже на СУБД был начальных пару лет, сейчас просто системный в тёщином компе :)
Использую autossh несколько лет под debian на BananaPi M1, прокидывает 443й порт с ультрадешевой VPS со статическим IP на домашний микросервер с динамическим IP.
Ну как использую... Настроил автозапуск в рутовом crontab и оно работает.
При указанном использовании никаких подводных камней или проблем за несколько лет. В debian ставится одной командой.
На сайте, указанном в тексте статьи, на данный момент картинки не прогружались, "красивостей" увидеть не удалось...
Имхо, если проводить больше времени с детьми только ради этого процесса, то дети лишаются стимула быть более самостоятельными/независимыми, привыкают к постоянному контролю и вниманию со стороны родителей. И при сколь-либо значительном кол-ве детей (от двух и более) такое времяпрепровождение будет отнимать много дефицитного свободного времени у итак занятых и "застрессованных" родителей.
С другой стороны, если дети сопровождают родителей в процессе повседневной жизнедеятельности, то они естественным образом обучаются и перенимают соответствующие навыки.
Но современным сложным процессам таким образом детей не обучить, это скорее про жизнь в естественной (не городской) среде и для процессов типа собирательства, охоты, приготовления пищи, строительства убежищ из подручных материалов и т.п..
Эпизодически что-то по мелочи может ломаться после обновлений.
Сейчас, например, страничка Transmission Web GUI (это torrent-клиент под linux) некорректно отображается в FF (действия и кнопки не работают), хотя раньше норм было.
При этом в Edge и прочих Chrome-based браузерах нормально всё.
На картинке в основании барабана не видно узла (подшипника или чего-то похожего), позволяющего ему вращаться относительно корпуса машины.
Из явных проблем - два идентичных (с одинаковым UUID) раздела нельзя будет одновременно к одной машине подключить.
У некоторых приводов, вероятно, линзы со временем мутнеют.
Вся механика вроде работает, а никакие диски "не схватываются".
А ещё у Firefox до сих пор есть 32bit сборки, которые кушают до двух* раз меньше памяти.
Я к тому, что в практической задаче, наверное, следовало бы вынести сложную арифметику дат из цикла/таймера планировщика, и работать с сортированным списком int64-таймстампов следующих срабатываний записей. При срабатывании записи вычислять время следующего её срабатывания и опять добавлять в список.
Тогда каждый тик планировщика обычно обходился бы в O(1) и не потребовалась бы сверхоптимизация арифметики дат.
Описанный в исходной задаче API видится избыточным и ограничивающим достижимую производительность, ведь для реальной задачи реализации высокопроизводительного планировщика, имхо, хватило бы одного метода вида "получить DateTime следующего срабатывания по заданной маске относительно текущего DateTime".
Если рассматривать как чисто академическую задачу - тогда вопросов никаких)
Делал давно что-то вроде RTOS для 80186-совместимых контроллеров, именно INT64-счетчик миллисекунд от старта системы был удобен для планировщика.
Для отложенных событий (обычно это было пробуждение заданного потока в заданный момент времени) вычисляется будущее время срабатывания и соответствующая запись добавляется в сортированный по возрастанию времени список. Вот соответствующий старый код, не особо читаемый.
В таймерной функции планировщика просто в цикле, пока время первой записи списка <= текущему времени, отрабатываем и удаляем голову списка (например, пробуждаем все потоки, которые должны проснуться в текущую миллисекунду). С частотой 1000Гц нормально всё планировалось на не особо быстром CPU.
Арифметика же на датах - это, имхо, скорее академическая задача, чем то, что нужно реализовывать на практике.
У гугла сейчас такие размеры и количество оборудования, что под свои нужды "железо" разрабатывают сами.
Прочитал с интересом,
но ожидал увидеть результаты по встроенной видеокарте, упомянутой в заголовке...
Книжку толстую крутую давали по нюансам реализаций пролога, название не вспомню.
Тема неплохо зашла, ханойские башни и прочие примерчики решались, компилировалось в «шитый» x86-код, вот только реализацию GC не осилил (курсач и так приняли), прога работала до переполнения кучи.
Мечталось ещё реализовать кроме бинарной логики предикатов {0, 1} ещё и «вероятностную» (0..1) и соответствующе допилить механизм логического вывода, было бы что-то вроде Fuzzy Logic Prolog :-)