Я тоже в конце 80-х собирал "Специалиста" с друганом в сарайке у его бати (он были радиолюбителем-коротковолновиком). И Atari 130XE у меня есть - иногда играем в игры в офисе на нём, под пиво. :) Мне чертовски нравится дизайн корпуса этих 8-ми битных Atari. Купил его на eBay-е 10 лет назад, потому что в 80-х тоже с них начинал (ностальгия придушла).
Atari 130XE и Commodore C64 в офисе ООО "Фабмикро"
Ну вот я детям пытаюсь обьяснить работу машины на примере TD4 - там всего четыре 4-х битных регистра и ПЗУ на переключателях. У этого автомата всего 65536 состояний и память их число не увеличивает. Такое редуцированное представление автомата гораздо проще понять. Как только Вы вводите ОЗУ, всё становится слишком сложно. :)
Честно говоря я не совсем понял смысла статьи, но вижу что автору хочется пофилософствовать и, пожалуй, поддержу. :)
Как мне кажется Вы несколько ошиблись в определении компьютера запихнув в него память. Компьютер (вычислитель) это конечный автомат отделенный от памяти, так написано в книжках и так всегда учили в ВУЗе. У вычислителя есть своя внутрення память - регистры и различные флаги. И именно их совокупным состоянием определяется число состояний автомата-вычислителя. Условно, у MOS 6502 есть регистры A[7:0], X[7:0], Y[7:0], SP[7:0], PC[15:0] и F[6:0], всего - 55 бит (на самом деле там есть еще программно невидимые регистры, но не в этом суть). Итого 3.6028797019e+16 сосотяний из которых далеко не все являются валидными (в некоторые состояния автомат не может перейти). Память же это источник внешних событий и способ сохранения результата работы автомата, но не его часть. Рассматривать вычиситель+память как конечный автомат тоже можно, но зачем ? В этом нет никакого смысла.
Так в том и суть vSphere Fault Tolerance, что она сохраняет работоспособность ВМ именно в таком случае - за счёт того, что ровно те же вычисления с такой же памятью и состоянием регистров выполняются на "теневой" копии ВМ на втором гипервизоре, а поведение процессора детерминировано. Там, где что-то не детерминировано или может рассинхронизироваться, нужные данные подтягиваются в теневую ВМ по сети (минимум 10 Гбит), при необходимости основная или теневая ВМ чуть притормаживается до синхронизации.
AFAIK, ничего там не исполняется на "теневом процессоре". Гипервизор делает регулярные снепшоты памяти. В случае аварии, сдохший СPU выводится из оборота, а подверженные воздействию сбоя виртуальные машины откатываются на ближайший снепшот. Аналогичный алгоритм с данными - регулярные снепшоты файловой системы (ZFS позволяет) синхронизированные по времени со снепшотами памяти. Но как вся эта кухня должна работать в составе более крупной системы и при это не рассинхронизироватья (ведь еще есть клиенты, которые могут и не знать о сбое), мне честно говоря не понятно. :)
Когда появилась эта фраза, отцы основатели Orace еще писали в горшок. :) И у неё, кстати, есть продолжение: "But they should."
О том, что IBM это страшная монополия которая путем различных технических ухищрений (и избыточных усложнений) пытается удерживать свою поляну от посягательств со стороны, было известно еще в 70-х годах прошлого столения. Её несколько раз пытались разделить по типу Bell Labs, но не срослось. Однако волею случая она разделилась сама собой - "рынок порешал". :)
Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Ага, тривиальна, если не лезть в CMakeLists и не смотреть какие опции там используются,
Во-первых, в CMakeLists смотреть не надо, надо читать README.md, это если Вас интересуют какие-то специализированные опции. Во-вторых, там подефолту всё нормально отстроено, никаких опций крутить не требуется. Инструкция, которую я привел выше, рабочая! cmake автоматом подхватывает CUDA если он у Вас есть и собирает всё что требуется. Я вот буквально вчера запустил llama.cpp на RTX 4060, никаких опций не накручивал.
При запуске llama-server пришлось, правда, ограничить число слоёв для оффлоада на GPU (-ngl 20) из-за малого обьема VRAM памяти на карточке.
За свой небольшой опыт с линуксом, если я вижу make , я до победного ищу готовые бинарники.
Какой-то у Вас неправильный опыт. Если я вижу Makefile, то беру и собираю из исходников. Я вообще стараюсь держать всё в исходниках, кроме компилятора. Как раз потому, что когда-то их обязательно сломают и я смогу откатиться на требуемую мне версию (может быть даже исправить проблему самостоятельно), а не судорожно искать и качать новые бинарники ко всему стеку используемого софта со всеми его зависимостями.
Похоже что автор статьи "слышал звон". llama.cpp это давно уже не просто библиотека, а целая система с кучей плагинов и собственным Web сервером с поддерждкой различных API. Установка llama.cpp выглядить до боли тривиальна: cmake . && make install. Установка моделей полность автоматизирована, просто указываете название модели и он выкачивает её с Huggingface и запускает. Какое еще нужно продуктовое мышление ?
$ git clone https://github.com/ggml-org/llama.cpp.git
$ cmake .
$ make && make install
# далее
$ llama-cli --help
# Web сервер с чатом можно запустить вот так:
$ llama-server -m $MODEL --host 1.2.3.4 --port 8080
# далее подключаетесь Web браузером на 1.2.3.4:8080 и получаете
# полноценный интерфейс к ИИ чат-боту
И да, llama.cpp поддерживает FIM API позволяя подключать vim, vscode и прочие IDE.
Мы держим свой локальный сервер на базе llama.cpp с моделями DeepSeek для чата и для FIM. Спасибо Георгию за то, что сделал инферренс моделей простым и доступным для старпёров умеющих в make.
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
SDH это не только телефония, это транспорт для многих других систем цифровой связи, в том числе и для IP. Так как IP начал превалировать, а стоимость порта и оборудования для преобразования STM в Ethernet уходит далеко в космос, то операторы стали отказываться от такого вида сетей и строить сразу всё на Ethernet, благо MPLS подвезли вовремя, тут же телефония и телевидение переехали на IP.
Проблема в том, что синхронные сети типа SDH это очень неэффективное использование дорогостоящего ресурса. Пакетная коммутация потому и вытеснила коммутацию каналов, потому что позволяет более рационально использовать полосу пропускания и является более гибкой, с точки зрения управления сетью, технологией, не говоря уже о стоимости порта (STM1 в десятки раз дороже обычного GigabitEthernet, при том что скорость всего 155Мбит/с).
Пакетная коммутация, в общем-то, при грамотной настройке, не должна создавать проблем для передачи голоса и модема поверх голосового тракта, все технические средства для этого имеются. Беда в ленивости и низкой квалификации современных инженеров эксплуатирующих сети.
SDH очень чувствителен к ошибкам, повышенный BER может приводить к сбою синхронизации и развалу сети. SDH требует точного источника синхронизации - одного на всю сеть. Очевидно, что в Ethernet таких проблем нет, ошибки могут приводить к потере пакетов, которые решаются ретрансмитами или избыточным кодированием. Локальная ошибка на сети Ethernet не является глобалной для всей сети, как это часто бывает в SDH.
Я тоже в конце 80-х собирал "Специалиста" с друганом в сарайке у его бати (он были радиолюбителем-коротковолновиком). И Atari 130XE у меня есть - иногда играем в игры в офисе на нём, под пиво. :) Мне чертовски нравится дизайн корпуса этих 8-ми битных Atari. Купил его на eBay-е 10 лет назад, потому что в 80-х тоже с них начинал (ностальгия придушла).
Atari 130XE и Commodore C64 в офисе ООО "Фабмикро"
Ну вот я детям пытаюсь обьяснить работу машины на примере TD4 - там всего четыре 4-х битных регистра и ПЗУ на переключателях. У этого автомата всего 65536 состояний и память их число не увеличивает. Такое редуцированное представление автомата гораздо проще понять. Как только Вы вводите ОЗУ, всё становится слишком сложно. :)
Честно говоря я не совсем понял смысла статьи, но вижу что автору хочется пофилософствовать и, пожалуй, поддержу. :)
Как мне кажется Вы несколько ошиблись в определении компьютера запихнув в него память. Компьютер (вычислитель) это конечный автомат отделенный от памяти, так написано в книжках и так всегда учили в ВУЗе. У вычислителя есть своя внутрення память - регистры и различные флаги. И именно их совокупным состоянием определяется число состояний автомата-вычислителя. Условно, у MOS 6502 есть регистры A[7:0], X[7:0], Y[7:0], SP[7:0], PC[15:0] и F[6:0], всего - 55 бит (на самом деле там есть еще программно невидимые регистры, но не в этом суть). Итого 3.6028797019e+16 сосотяний из которых далеко не все являются валидными (в некоторые состояния автомат не может перейти). Память же это источник внешних событий и способ сохранения результата работы автомата, но не его часть. Рассматривать вычиситель+память как конечный автомат тоже можно, но зачем ? В этом нет никакого смысла.
Та не, это мозги дяде FEDOR-у отдельным эшелоном готовятся подвезти.
AFAIK, ничего там не исполняется на "теневом процессоре". Гипервизор делает регулярные снепшоты памяти. В случае аварии, сдохший СPU выводится из оборота, а подверженные воздействию сбоя виртуальные машины откатываются на ближайший снепшот. Аналогичный алгоритм с данными - регулярные снепшоты файловой системы (ZFS позволяет) синхронизированные по времени со снепшотами памяти. Но как вся эта кухня должна работать в составе более крупной системы и при это не рассинхронизироватья (ведь еще есть клиенты, которые могут и не знать о сбое), мне честно говоря не понятно. :)
Когда появилась эта фраза, отцы основатели Orace еще писали в горшок. :) И у неё, кстати, есть продолжение: "But they should."
О том, что IBM это страшная монополия которая путем различных технических ухищрений (и избыточных усложнений) пытается удерживать свою поляну от посягательств со стороны, было известно еще в 70-х годах прошлого столения. Её несколько раз пытались разделить по типу Bell Labs, но не срослось. Однако волею случая она разделилась сама собой - "рынок порешал". :)
"Nobody got fired for using IBM" (c) ...
Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
А их никто и не пишет для IBM кроме самой IBM.
Это не безопасность, это "security through obscurity".
Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Во-первых, в CMakeLists смотреть не надо, надо читать README.md, это если Вас интересуют какие-то специализированные опции. Во-вторых, там подефолту всё нормально отстроено, никаких опций крутить не требуется. Инструкция, которую я привел выше, рабочая! cmake автоматом подхватывает CUDA если он у Вас есть и собирает всё что требуется. Я вот буквально вчера запустил llama.cpp на RTX 4060, никаких опций не накручивал.
При запуске llama-server пришлось, правда, ограничить число слоёв для оффлоада на GPU (-ngl 20) из-за малого обьема VRAM памяти на карточке.
Какой-то у Вас неправильный опыт. Если я вижу Makefile, то беру и собираю из исходников. Я вообще стараюсь держать всё в исходниках, кроме компилятора. Как раз потому, что когда-то их обязательно сломают и я смогу откатиться на требуемую мне версию (может быть даже исправить проблему самостоятельно), а не судорожно искать и качать новые бинарники ко всему стеку используемого софта со всеми его зависимостями.
А это, постите, кто ?
80ГГц / 5ГБит/сек... да, далеко ускакал прогресс. В конце 90-х мы ставили "релейки" на 4-е порта E1 между узлами и радовались диким скоростям. :-)
Я думал, что Георгий Герганов наш соотечественник, оказывается - потомственный болгагин. :-)
Похоже что автор статьи "слышал звон". llama.cpp это давно уже не просто библиотека, а целая система с кучей плагинов и собственным Web сервером с поддерждкой различных API. Установка llama.cpp выглядить до боли тривиальна:
cmake . && make install. Установка моделей полность автоматизирована, просто указываете название модели и он выкачивает её с Huggingface и запускает. Какое еще нужно продуктовое мышление ?И да, llama.cpp поддерживает FIM API позволяя подключать vim, vscode и прочие IDE.
Мы держим свой локальный сервер на базе llama.cpp с моделями DeepSeek для чата и для FIM. Спасибо Георгию за то, что сделал инферренс моделей простым и доступным для старпёров умеющих в make.
Что такое Ollama - понятия не имею. Очень похоже, что это еще одни паразиты из лагеря питонистов. В который раз убеждаюсь, что питонисты без поддержки сишников и плюсоводов ничего толком сделать не могут, только обертку красивую нарисовать и вперед - клянчить деньги инвесторов. На Hacker News таких добрая половина, а в составе YC - все 100% стартапов.
SDH это не только телефония, это транспорт для многих других систем цифровой связи, в том числе и для IP. Так как IP начал превалировать, а стоимость порта и оборудования для преобразования STM в Ethernet уходит далеко в космос, то операторы стали отказываться от такого вида сетей и строить сразу всё на Ethernet, благо MPLS подвезли вовремя, тут же телефония и телевидение переехали на IP.
Проблема в том, что синхронные сети типа SDH это очень неэффективное использование дорогостоящего ресурса. Пакетная коммутация потому и вытеснила коммутацию каналов, потому что позволяет более рационально использовать полосу пропускания и является более гибкой, с точки зрения управления сетью, технологией, не говоря уже о стоимости порта (STM1 в десятки раз дороже обычного GigabitEthernet, при том что скорость всего 155Мбит/с).
Пакетная коммутация, в общем-то, при грамотной настройке, не должна создавать проблем для передачи голоса и модема поверх голосового тракта, все технические средства для этого имеются. Беда в ленивости и низкой квалификации современных инженеров эксплуатирующих сети.
SDH очень чувствителен к ошибкам, повышенный BER может приводить к сбою синхронизации и развалу сети. SDH требует точного источника синхронизации - одного на всю сеть. Очевидно, что в Ethernet таких проблем нет, ошибки могут приводить к потере пакетов, которые решаются ретрансмитами или избыточным кодированием. Локальная ошибка на сети Ethernet не является глобалной для всей сети, как это часто бывает в SDH.
У GSM 2G синхронные каналы только до коммутатора, дальше уже давно всё на пакете.