Обновить
18

Пользователь

1
Подписчики
Отправить сообщение
Вендоры будут ставить внешнее отлаженное решение. Что плохого?

Ну обычно дешевле в производстве и места занимает меньше если нужно на плату всего одну микросхему распаять вместо двух. А купить IP блок и встроить в процессор конечно можно, но это уже не так просто и дешево сделать, как если бы этот IP блок разрабатывали люди из того же Intel.


Ну и у кого купить у Apple или у Qualcomm, оба крупные игроки на мобильном рынке, даже если и продадут то мягко говоря не дешево/

Так уже давно выпускают. https://en.wikipedia.org/wiki/Surface_Pro_X вышел в 2019

Вроде Интел продал своё подразделение которое разрабатывало микросхемы для работы с сотовой сетью чуть ли не Apple? А без встроенного 3/4/5 g в Soc как-то печально по нынешним временам

И пришли почти туда же что забавно. По крайней мере air разогревается до 90 градусов при долгой загрузки CPU из-за очень слабой системы охлаждения. Понятно конечно что его покупают не для того чтобы сильно нагружать CPU, да и такой тонкий корпус не позволяет сделать многого.

И самое главное: теперь все компьютеры MacBook будут выпускаться на собственных чипсетах

Не совсем понятно написано, чипсет материнской платы будет от Apple или все-таки процессор?

Спутники получают сигнал с Земли, после чего уже ретранслируют пользователям.

Ну формально говоря в gps есть в точности такой же механизм. Наземный сегмент обновляет эфемериды спутников отправляя эти данные с земли на спутники. А потом спутники транслируют эти эфемериды потребителям, прямо как телевидение. Правда скорости я думаю не сопоставимы — где-то 50 бит в секунду и покупка «контента» дешевле обходиться, но всё-таки принцип один и тот же. И как-то за скобками остался факт что для непрерывной во времени и пространстве навигации нужно спутниковую группировку обновлять, а это очень дорого как сами gps спутники так и их вывод на орбиту.

А что с неявным использованием? Например может при просмотре списка писем веб-интерфейс прокешировать "предпросмотр" вложений у новых писем так как пользователь скорее всего зайдет посмотреть новые письма? Или при наведении курсора на письмо и т.п.? Или отсылка документов в США работает только при явно клике на вложение?

Я ставил на macbook pro ~2013 года, первый в общем с retina дисплеем. Именно по причине привычности. Все работало и тачбар и выход из спящего режима и wifi, но не сразу конечно. По мере выхода новых ядер все постепенно исправлялось.

Если мы углубимся в эту тему аргументированно — получится длинная статья, которая никому нафиг не нужна.

Я бы прочитал такую статью, да и ИМХО самим авторам котлина тоже было интересно

борьба с терроризмом и конфиденциальность данных не исключают друг друга

А как это работает? Нужно же отлаживать фильтрующие алгоритмы на реальных данных, и потом как-то проверять его эффективность время от времени. Пусть идентификаторы пользователей при этом будут убраны, но в самих сообщениях может быть достаточно информации чтобы понять кто это написал.

например, более современная технологя QML не позволяет рендерить видео с использованием произвольного OpenGL-контекста

А можете более подробно описать эту проблему или ссылку дать?

Хотя бы расшифровали ВКС вначале. А то я ожидал описание разработки терминала для военно космических сил на С++ в пику Маску с его chromium и JavaScript для космонавтов.

Ну судя по поиску проблема была в том что pam_securetty запрещал логиниться root на ненастоящем терминале, а для контейнера не возможно создать терминал подходящий для pam_securetty. Тут либо pam_securetty отключить внутри контейнера или одно из двух. А какая у разработчиков systemd должна быть реакция на эту ситуацию?

Количество багов это все-таки так себе метрика. У тех же компиляторов которыми не только все софт собирается, но и ядро багов многие тысячи и у gcc и у clang. Количество багов определяется также популярностью продукта.

По-моему journald это один из тех компонентов который тянет systemd вниз.
Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач, на самом деле нет:


time sudo journalctl -n 10 --no-pager
real    0m8,817s
user    0m0,020s
sys     0m0,059s

в то время как с того же диска и точно так же с "холодным" дисковым кэшем:


time tail -n 10 /var/log/pacman.log
real    0m0,022s
user    0m0,004s
sys     0m0,000s

Все бы ничего, но systemctl status использует journald и поэтому тоже дико тормозит: https://github.com/systemd/systemd/issues/2460


Или захочется использовать центрилизованный сбор логов и можно поиметь кучу проблем: https://habr.com/ru/company/southbridge/blog/317182/, некоторые не решаются годами: https://github.com/systemd/systemd/issues/1387

Как-то в последней части совсем плохо, одна « библиотека стандартов Go» чего стоит, пришлось английский вариант читать, так как сама по себе заметка в блоге интересная.

На самом деле такой софт разрабатывать именно на позиции кодера проще. По процедуре все алгоритмы описывают специалисты и кодерам приходит точная и подробное описание, одновременно с кодом пишутся по этой спецификации тесты для 100% покрытия описанного куска кода. В общем для кодера почти нет возможности для шага влево или вправо.

Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++
Qt на мобильных платформах — это QML,

Ну если хочется кросплатформенности, то и на Desktop QML неплохо работает,
и во многом уже лучше Qt/Widgets к сожалению.


Так что я бы C++ назвал преимуществом, вряд ли ffi Dart также просто сделать
как интеграцию C++ и QML/JavsScript.


У Qt на мой взгляд другие проблемы:


  • Намного слабее маркетинг
  • Типизация, здесь Dart выигрывает по сравнению с QML, но вроде в Qt 6.x собираются поправить
  • Направленность на "Embedded Linux", такое чувство что остальные платформы тестируются
    намного меньше

Это же жидкостный двигатель. Военные их не используют — слишком большое время подготовки старта, а заправленным на дежурство не поставишь

Какая-то стремная цепочка. Широковещательные UDP пакеты поверх Ethernet как я понимаю — нет никаких гарантий что из-за коллизий пакет дойдёт вовремя, потом Go с GC, потом PostgreSQL у которого нет никаких жестких гарантий на время записи и наконец JavaScript с GC. Понятно что обычно все доходит и отображается вовремя, но как в такой сложной системе доказать что с момента обнаружения проблемы прибором у кровати больного до показа оповещения в дежурной комнате пройдёт точно не более X секунд?


По-моему дорогая цена у существующих систем, о чем сказано в начале статьи, оправдана.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность