А мне нравится С++ и чем дальше на нем пишу, тем больше нравится. Сфера его применения достаточно специфична: «надо вложить много времени, но получить очень производительную и гибкую систему» и вместе с тем «пару неверных движений и простреленная нога обеспечена». На С++ невозможно писать идеальный код сразу. Его будешь переписывать и переписывать и каждый раз он будет получаться лучше. Т.е. возможностей и фишечек столько, что в момент написания сознательно половиной из них не пользуешься, чтобы не усложнять то что рано еще усложнять. А потом когда очертания системы уже видны — можно и подкрутить где надо или переписать что смотрится плохо.
Хороший пример применения языка можно посмотреть в CGAL или кошмар из страшного сна, это зависит от подготовки. :) Если в 3 слова: быстро, гибко и сложно.
Они еще как функциональны. Мобильный интернет банкинг очень удобен и заменяет собой мобильное приложение. Мобильный магазин позволяет заказать то что надо, пока ноутбука нет рядом. Причем это сделать можно удобней. Да и о чем вобще спор? Вам не удобно, мне удобно. Откройте тот же amazon.com с телефона. Отлично смотрится. Только нужная информация, всё необходимое под пальцем и крупный шрифт. не надо всматриваться и решать какой блок надо приблизить.
Для мобильных надо делать отдельную версию магазина. Т.к. читать все привыкли с телефона, Reader тот же спасает, а вот когда от пользователя требуются какие-то действия, лучше сделать их удобными. Большие кнопки, подобраный для мобильных шрифт и проч. Ну или как минимум такие вот косяки поправить, чтобы прилепленый к верху страницы объект не занимал полезное место при приближении.
Для десктопа-же такая плашка вполне уместна и удобна.
Вопрос цены. Энтузиасты всегда пробуют что-то новое, а потом приходят на работу и говорят: «Надо купить то-то и то-то, это серьезно улучшит стабильность нашего кода и сэкономит нам время на написание не тривиальных тестов».
Я SIMD код люблю и уважаю в 2х случаях.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.
Вы невнимательно читали документ NASA. В шапке написано «Page 1 of 179». В паблик выложили не всё. Тойота реально лажанулась с контроллером педали газа. Реально отказывалась признать это в суде долгое время, пока обращений стало не слишком много. И теперь они отзывают миллионы авто и выплачивают больше миллиарда компенсаций. Это не вымысел. Если автор и добавил красок и эмоций в статью, то я его за это не виню.
Ситуация на самом деле пугающая. Потому что если я в программе допущу ошибку, тестировщик ее не заметит, и приложение попадет к пользователю, оно вылетит. И максимум что пользователь потеряет — час работы. С производством машин, которые могут навредить пользователям совсем другое дело. Их тестировать надо как это делают в NASA или sqlite вдоль и поперек и несколько раз. Но с увеличением спроса на электронику не всем производителям хватает бюджета и/или специалистов, чтобы проводить тестирование ПО так же старательно, как это делают в NASA.
Хорошо что в Tesla понимают эти риски, и сделали возможным обновлять прошивку узлов автомобиля по воздуху, и я очень надеюсь что у них с тестированием дела обстоят лучше чем у конкурентов.
Какие это цветочки по сравнению с ситуацией у Toyota. Там случай вобще феерический. Да еще пострадавшим пришлось бодаться в суде несколько лет, чтобы доказать что виноват не коврик под педалью газа.
А вы видели ценник сегодня? :) Когда я удивлялся ценнику в 450, я не знал что еще через 5 дней цена будет уже 780. И даже слив 18к биткоинов не помешало курсу быстро восстановиться и укрепиться на позиции $780.
Да, все верно. Но это обходные пути, которые надо подключать к bcache вместо прямого доступа к диску. У bcache в документации сказано, что они работают с cache set-ами. Но на текущем этапе развития проекта в cache set-e может быть только один SSD.
Четкого ответа на этот вопрос у меня нет. Есть только практические наблюдения: У btier есть такой параметр как allocated size — обьем блоков, в которые файловая система уже что-то писала. Когда этот allocated size рос — он записывал на SSD в первую очередь. Когда я почистил файлы на диске — allocated size остался прежним. И новые файлы писались уже без роста allocated size. В моем случае все они попали на hdd.
Объем btier = ssd + hdd как на крайней правой схеме в начале статьи. Можно записывать файлы без ограничений по размеру. Хоть в 2 раза больше чем ssd. Только вы не можете насильно сказать системе что должно быть на ssd, а что нет. Она сама решает.
Хороший пример применения языка можно посмотреть в CGAL или кошмар из страшного сна, это зависит от подготовки. :) Если в 3 слова: быстро, гибко и сложно.
Для десктопа-же такая плашка вполне уместна и удобна.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.
Ситуация на самом деле пугающая. Потому что если я в программе допущу ошибку, тестировщик ее не заметит, и приложение попадет к пользователю, оно вылетит. И максимум что пользователь потеряет — час работы. С производством машин, которые могут навредить пользователям совсем другое дело. Их тестировать надо как это делают в NASA или sqlite вдоль и поперек и несколько раз. Но с увеличением спроса на электронику не всем производителям хватает бюджета и/или специалистов, чтобы проводить тестирование ПО так же старательно, как это делают в NASA.
Хорошо что в Tesla понимают эти риски, и сделали возможным обновлять прошивку узлов автомобиля по воздуху, и я очень надеюсь что у них с тестированием дела обстоят лучше чем у конкурентов.
Со стороны приложений падение кэша осталось незамеченым.