Pull to refresh
0
0
Send message
Ооо, это формат OOXML, вот там действительно наркомания и упомянутый в статье формат zip даже рядом не стоял, одна часть описания формата в виде zip архива занимает 42Мб, сама спека на 5029 страниц и чёрт там ногу сломит, особенно когда пытаешься разобраться почему тот или иной офисный пакет не хочет этому стандарту следовать.
magnet:?xt=urn:btih:e34280de3707f36a2b8d99b66c5d5a9acb723308&dn=cp_no_password&tr=udp://tracker.openbittorrent.com:80&tr=udp://tracker.opentrackr.org:1337/announce
Просто: практически нигде нет накопительной пенсии в чистом виде. Она солидарная. То есть сейчас Вы платите пенсию поколению Ваших родителей, а Ваши (несуществующие) дети должнв были бы, по идее, платить её Вам.

Это в России так. Причем система устаревшая и не работоспособная. Не будет никаких пенсий, причем совсем скоро. Просто такое следствие из экономики. Забудьте про пенсии, все, кто родился примерно от 1965 года — забудьте об обычных пенсиях, их не будет.

Но вы сознательно переложили это бремя на плечи чужих детей

Я — не переложил. Я точно знаю, что пенсию никогда не получу. Не потому, что «дети… переложил...», а потому, что государственная пенсионная система рухнула.
От пенсии отказаться сможете?

А это по-фигу, сможете или нет. Пенсии просто не будет. Или сдохнуть — или самому как-то иначе жить. Забудьте про государственную пенсионную систему в России. Ее уже нет. Просто еще это плохо видно.
но факт остался — автоматизация ведёт к безработице
Автоматизация ведет к исчезновению одних специальностей и к созданию других. Кто не стал (не смог в силу возраста — Вы правильно отметили) переквалифицироваться — остался без работы. Переживать по этому поводу — чистый луддизм. Вам жаль извозчика ака «водитель кобылы»?
а в том, как распределяются блага от этой самой автоматизации
И как они, а главное кем распределяются? Кто этот нехороший, что не дает win-win?
Я не понимаю, отчего Вы сситаете дураком меня?

Почему только Moskus?
Я, например, тоже так считаю. Вы приводите неверные и примитивные суждения, о технологическом развитии. Например:
если машина/робот/аппарат с учётом стоимости покупки, внедрения и обслужиаания позволяет снизить расходы по сравнению с человеческим трудом, то людей увольняют, а машины покупают.

Это ненаучный бред, который не имеет к реальности никакого отношения.
Причем все совсем не так, как Вы описываете.
Причина не очевидная: Вы путаете причину и следствие. Сначала возникает потребность в большем выпуске продукции, например из-за увеличения рынка или спроса. И только потом, как следствие, возникает потребность в улучшении технологии. Люди и увольнения вообще никак не связаны ни с уровнем производства, ни с «наступлением машин».
Открою Вам важный секрет: любая новая технология всегда дороже старой при том же объеме производства. Нет исключений. Нигде и никогда.
Но бизнесмены — не идиоты! Поэтому каждая новая технология должна быть более производительная, чтобы доля технологических затрат в единице продукции стала меньше и прибыль увеличилась. А увеличение производительности должно быть поддержано рынком. Больше делаем — больше продажи. Поэтому никто не меняет технологию с бухты-барахты. Только от запросов рынка это происходит.

Это на микро уровне экономики.
А на макро уровне смотрите всегда на количество безработных. Оно во всех странах с мире примерно одинаковое, в процентах от населения. И всегда очень много вакансий и очень много безработных. Все просто: работники нужны, но не абы какие, а с разумом или квалификацией. А с этим проблемы: 95% населения — идиоты
Моя мысль очень проста: неважно, кто сколько денег приносит, если все довольны. Но морально недопустимо попрекать другого недостатком приносимых денег, если сам приносишь меньше (неважно, почему). «Отсутствие возможностей» всего лишь означает, что с другой стороны забора трава всегда зеленее, то есть вот у меня возможностей нет, а у тебя-то есть (как будто бы они из космоса падают), так что вперёд и с песней.

Деньги штука важная, что и говорить, но если человек обеспечивает разумный (относительно своей семьи и окружения, а не Билла Гейтса) вклад в семью, странно требовать от него, чтобы он превратился в чистую функцию добытчика и забыл о том, что он, вообще говоря, ещё и какая-никакая личность со склонностями и интересами.
Честно говоря, был удивлен тем, что самолеты с обратной стреловидностью не отличались стабильностью полета.
Тут вот подробнее

Поговорим чисто аэродинамически, оставляя в стороне вопросы прочности и даже малозаметности.

Один из основных источников потерь на крыле — вихрь, сходящий с его концов и срыв потока, опять же, на концах консолей. Применение обратной стреловидности заставляет воздух двигаться не от корня крыла к его концам, а наоборот. Корневая часть крыла шире, там больше свободы по выбору профиля, что уменьшает возможность срыва. А фюзеляж послужит ограничителем для потока сходить вихрю, получается, неоткуда. Сплошные выгоды. И это подтверждалось, не зря так популярны планеры с обратной стреловидностью
image
Ограничивала идею только необходимость делать такое крыло очень жёстким и прочным.

Но, когда скорости выросли и попытались сделать то же самое на около- и сверх- звуковых скоростях, начались аэродинамические неприятности. Вихри всё же образовывались и, что хуже всего, они нестатически взаимодействовали. Причём взаимодействовали не только друг с другом, но и с струёй из двигателя, что придавало эффектам дополнительную и крайне неприятную энергию.
Заднюю часть самолёта нещадно трясло, устойчивость и управляемость получались неприемлемыми. Пробовали «протягивать ласты», чтобы более упорядоченно сводить воздух с корня крыла назад:
image
Может, решить проблему в конце-концов удалось бы, но вспоминая ещё и о дивергенции крыла, необходимости делать его жёстким, тяжёлым и дорогим — все перешли к достижению тех же достоинств другими путями.
Opcache в стандартной поставке с PHP 5.5, до этого был APC. При большом желании его можно выключить или накриворучить настройками.
Стандартно, да, следит на временем изменения файла, если этот файл закеширован. Из кеша можно выпилиться засчет переполнения максимального отведенного объема памяти или количества файлов.
На проде устанавливают
opcache.validate_timestamps=0
и при деплое сбрасывают кеш, искренне считая, что тут код не должен меняться и нечего тратить время на проверки всякие.
Ну не знаю, я не контролирую электричество в железе (кремнии?), я контролирую изменение информации. Ведь программирование как раз про это, превращение одной информации в другую, ее хранение и контроль. Это нулевой уровень абстракции. А бегают там электроны по железу или фотоны по кристаллам меня не волнует пока проблема/задача не опускается на уровень железа (или я не опускаю ее туда). Потому что «железо» это просто еще один аспект, а не «основа всего». Это в стороне а не внизу. Завтра вы перенесете софт на другой сервер, это же не значит что его нужно полностью переписывать?

ЯП это инструмент. Само собой он влияет на носителя. Как и любой инструмент. Если в руках молоток то все вокруг кажется гвоздями. Но мышление первично, пусть и меняется под действием привычек, задач, используемого инструмента. Я вот про это «Это не гаечный ключ у тебя в гараже — это кусок твоего сознания. », это перебор. Если это действительно так, то это серьезная профессиональная деформация. Причем с привязкой к области и языку. Встречал не раз что-то подобное, обычно это была зависимость от инструментов уровня фреймворка, люди мыслили не задачей, информацией, другими критериями вроде надежности, масштабируемости, сложности, гибкости, а следует ли код духу фреймворка и мануалам/рекомендациям или нет, вот когда это было уже в ущерб задаче и другим важным параметрам — то это мешало. Фреймворк первичный у них был, а не всего лишь инструмент. С языком тоже часто встречал, но не настолько, все же любой ЯП достаточно гибок а мануалов как «истинно правильно» на нем делать не так уж и много.

Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.

Даже мир для нас черный ящик а мы для него, и общаемся мы с ним ( и с другими людьми) с помощью ограниченного количества входов-выходов (чувств и действий) и абстракций (язык, мимика, телодвижения). И в самом черном ящике нашего восприятия еще куча промежуточных слоев и наслоений из нашей памяти, чувств, отношений, образов, все что формирует мировоззрение и текущее настроение, и эти слои тоже меняют информацию, сильно меняют. Но эти слои в сумме и образуют наше создание и мышление. Без них мы бы просто и беспристрастно, как видеокамера, фиксировали бы входящую информацию. Только фиксировали. Отвлекся, вернемся к баранам.

То что компьютер все больше становится черным ящиком и для нас, программистов, это нормально, это специализация. Это непривычно, нам немного стыдно признавать что мы уже ничерта не понимаем в деталях в работе процессора и вряд ли сможем починить материнскую плату если что-то пойдет не так, не говоря уже о том что не спаяем компьютер в гараже из набора простейших деталек и чипов из ближайшего магазина радиотехники. Но это нормально, суммарно контроль не утерян, он просто стал глубже и разделился на десятки специализаций, ни у одного человека уже не хватит знаний чтобы быть экспертом во всем что связано с компьютерами. Обьем «эксперта» во всей области давно уже перевалил за 10 тысяч часов и исчисляется миллионами часов, и скорость роста знаний превышает скорость освоения, а сложность растет. Один человек просто не способен разобратся во всей области. Он не будет успевать поддерживать актуальный уровень. И даже опуститься вниз до процессора по отдельной области. Даже поддерживать 100% информированность по всем связанным с узкой областью инструментов не получиться, даже популярных, не то что опускаться вниз.
Будте хороши на одном, своем уровне, и своей области, пусть другие занимаются остальными, каждый своей.

Кстати вот эта практика, которую вы описали, с мультиязычностью меня немного удивила, имхо, плохо это. На простых задачах и проектах в принципе нормально, но на сложных начинают тащить привычки и принципы одного языка в другой, и такой плохоподдержвиваемый ад со временем получается…
Если язык не важен — почему их так много? Разве что действительно одну и ту же библиотеку на разных языках, для пользователей того же API. Ну это редкость и достаточно законченная задача, там если что и «выбросить все и написать заново» не страшно.

А полноценно контролировали и софт и железо только в 50-е, когда еще и разделения толком не было и софт писался под конретный экземпляр компьютера. Вот там контроль. Вот там постоянно открытый капот. Вот там заточка кода под железо а железа под код. Вот там знание компьютера до каждого резистора и понимание каждого байта и каждого сигнала. Вот только это совсем не эффективно и не надежно, и замена «винчестера» (не говоря уже о «процессоре») могла превратить весь софт в ненужный хлам.

Извиняюсь за многобукв, во всем виноваты абстракции, человеческий язык слишком несовершенен, и из-за этого приходиться использовать дополнительные слои в виде тех же примеров и аналогий, чтобы передать изначальную мысль с минимумом искажений внутренними фильтрами наших черепушек. Вот бы где нам действительно «языки низкого уровня» пригодились бы. Когда там уже мыслеречь допилят и общение образами?
Линукс_дома,_но_зачем.jpg

У офисных приложений есть два следующих неубиваемых преимущества:
1) Они уже есть везде, их не надо докупать.
2) Сотрудники уже знают, как с ними работать, их не надо дообучать или донанимать.

Чтобы писать то же самое на шарпе, нужно поставить шарп, то есть заплатить за это (если ты пишешь для коммерческой компании, то бесплатная версия будет нелегальной).

Потом нужно найти сотрудника, который умеет писать на шарпе — и заинтересовать его, чтобы он не ушёл туда, где пишут именно программы, а занимался обычным документооборотом. То есть опять платить за это.

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

Просто статью написал представитель так называемого «высокого программирования», который сидит в своей башне из слоновой кости и применяет машинное обучение на биг дата к диджитализации аджайла. Читатели на хабре в основном тоже из этой категории.

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

Рассуждения о смерти VBA сродни рассуждениям о смерти часов.

Да, почти у каждого человека сейчас есть смартфон, а вокруг на улице и в помещениях, в общественном транспорте — всюду есть часы.

Но рынок часов не падает, и вовсе не за счёт элитных марок.
Почему гиганты, а-ля Google/Microsoft/Facebook любят брать выпускников хороших тех ВУЗов? Ответ был на Quor'е, мысль такая, что в этих компаниях, много чего используется самописного, даже система контроля версии. Да, в последнее время, эти компании выпускают свои наработки в свет, но все еще под капотом остается много технологии. И им легче обучить этим технологиям Junior'ов с хорошей тех базой, чем бывалого разраба, который на каждый чих говорит: «а вот в моей предыдущей компании было не так», «это вы делаете не правильно». Как говорится, тяжело научить старую собаку новым трюкам. Вот вам и cost economic джуна.
Появляется какой-нибудь интернет с биткоинами, и модель становится неадекватной.

Разумеется! Тогда мы заменяем старую модель на новую. Адекватную.

Модель же, адекватную любым исходным условиям, но при этом дающую практически полезные предсказания, построить невозможно.
> Проведём маленький эксперимент, если Вы не против — мне любопытно чего такого я не знаю на фундаментальном уровне, из того, что преподают в ВУЗах в качестве базы.

Ну я вот писал программу по нескольким курсам, один из основных — «Алгоритмы и структуры данных», вот база (не все, особенно и последнего семестра, нужно знать и доказывать, но основные свойства полезно знать).

Вот примерный список, я надеюсь, он после обкатки скорректируется. Общий объем 225 часов (чисто лекции, практика Python-C-C++ идет отдельными часами).

Поиск в массиве
1.1 Линейный поиск
1.2 Двоичный поиск
1.3 Троичный поиск
1.4 Интерполяционный поиск
Структуры данных
1.5 Массив
1.6 Стек
1.7 Очередь, двусторонняя очередь
1.8 Словарь
1.9 Хеш-таблица

Сортировки, анализ алгоритмов
2.1 Bubble sort (пузырьковая сортировка)
2.2 Merge sort (сортировка слиянием)
2.3 Quick sort (быстрая сортировка)
2.4 Bucket sort (блочная сортировка)
2.5 Heap sort (пирамидальная сортировка)
2.6 Insertion sort (сортировка вставками)
2.7 Counting sort (сортировка подсчетом)
2.8 Radix sort (порязрядная сортировка)
2.9 Timsort и другие гибридные алгоритмы сортировки

Рекурсия, математическая индукция
3.1 Хвостовая рекурсия
3.2 Обратная польская запись
3.3 Числа Каталана
3.4 Вычисление биномиальных коэффициентов
3.5 Метод градиентного спуска
3.6 Метод сопряженных градиентов
3.7 Принцип динамического программирования
3.8 Метод ветвей и границ
3.9 Методы Gradient boosting
3.10 Алгоритм Кадана
3.11 Поиск методом золотого сечения
3.12 Производящие функции
3.13 Запаздывающие генераторы Фибоначчи
3.14 Memoization
3.15 Корекурсия
3.16 Задача 3-SAT
3.17 Алгоритм фрактального сжатия
Структуры данных (рекурсивные)
3.18 Список
3.19 Дерево
3.20 Граф

Строки
4.1 Z-функция
4.2 Алгоритм Кнута-Морриса-Пратта
4.3 Алгоритм Ахо-Корасик
4.4 Алгоритм Бойера-Мура
4.5 Алгоритм Бойера-Мура-Хорспула
4.6 Сходство Джаро-Винклера
4.7 Расстояние Левенштейна, алгоритм Укконена
4.8 Расстояние Дамерау-Левенштейна
4.9 Алгоритм Карпа-Миллера-Розенберга
4.10 Алгоритм Каркайнена-Сандерса
4.11 Алгоритм Арикавы-Аримуты-Касаи-Ли-Парка
4.12 Алгоритм Ву-Менбера
4.13 Алгоритм Ландау-Вишкена
4.14 Алгоритм Майерса
Структуры
4.15 Префиксное дерево
4.16 Суффиксный массив
4.17 Суффиксное дерево

Порядковые статистики, потоковые алгоритмы
5.1 Алгоритм BFPRT
5.2 Алгоритм Манро-Патерсона
5.3 Алгоритм Канна-Гринвальда
5.4 Алгоритм большинства голосов Бойера-Мура
5.5 Алгоритм Lossy Count

Деревья
6.1 Эйлеров обход дерева, DFS, BFS
6.2 Двоичное дерево поиска
6.3 Декартово дерево
6.4 Красно-черное дерево
6.5 АВЛ-дерево, дерево Фибоначчи
6.6 Splay tree (расширяющееся дерево)
6.7 B, B+, B* дерево, 2-3 дерево
6.8 PQ-дерево
6.9 Дерево отрезков
6.10 Дерево Фенвика
6.11 Алгоритм двоичного подъема (задача LCA)
6.12 Алгоритм Фарах-Колтона и Бендера (RMQ, LCA)
6.13 Sqrt-декомпозиция
6.14 Центроидная декомпозиция
6.15 Heavy-light декомпозиция
6.16 Фибоначчиева куча
6.17 Куча, 2-3 куча
6.18 Очередь с приоритетами
6.19 Множество
6.20 Система непересекающихся множеств
6.21 Лес непересекающихся множеств
6.20 Ассоциативный массив

Графы
7.1 Обход в ширину (BFS)
7.2 Обход в глубину (DFS)
7.3 Топологическая сортировка
7.4 Алгоритм Munagala-Ranade
7.5 Алгоритм Mehlhorn-Meyer
7.6 Задача о динамической связности
7.7 Алгоритм поиска точек сочленения графа
7.8 Алгоритм поиска мостов графа
7.9 Алгоритм Косараю
7.10 Алгоритм Тарьяна
7.11 Задача 2-SAT
7.11 Алгоритм Брона-Кербоша
7.12 Конденсация графа
7.13 Раскраска графа
7.14 Задача о назначениях
7.15 Венгерский алгоритм
7.16 Алгоритм Ульмана
Структуры
7.17 Матрица смежности
7.18 Матрица достижимости
7.19 Матрица сильной связности
7.20 Матрица Лапласа
7.21 Матрица Инцидентности
7.22 Список смежности
7.23 Список ребер

Графы: циклы
8.1 Алгоритм поиска Эйлерова цикла
8.2 Алгоритм поиска Эйлерова пути
8.3 Алгоритм поиска Гамильтонова цикла
8.3 Алгоритм поиска Гамильтонова пути
8.4 Задача Коммивояжера

Графы: остовное дерево
9.1 Теорема Кирхгофа
9.2 Теорема Кэли о числе деревьев, код Прюфера
9.3 Лемма о безопасном (минимальном) ребре
9.4 Алгоритм Краскала
9.5 Алгоритм Примы
9.6 Алгоритм Борувки
9.7 Задача устранения петель в сети Ethernet (STP)
9.8 Задача Штейнера

Графы: кратчайший путь
10.1 Алгоритм Дейкстры
10.2 Алгоритм Best-First
10.3 Алгоритм A*
10.4 Алгоритм Левита
10.5 Алгоритм Беллмана-Форда
10.6 Алгоритм Флойда-Уоршелла
10.7 Алгоритм ALT
10.8 Алгоритм Reach-based pruning

Графы: потоки в сетях
11.1 Алгоритм Форда-Фалкерсона
11.2 Алгоритм Эдмонса-Карпа (алгоритм Диница)
11.3 Алгоритм поиска потока минимальной стоимости
11.4 Сети Петри
11.5 Алгоритм проверки графа на двудольность
11.6 Алгоритм раскраски двудольного графа
11.7 Алгоритм Хопкрофта-Карпа
11.8 Венгерский алгоритм
11.9 Blossom алгоритм (алгоритм Эдмондса)
11.10 Алгоритм Штор-Вагнера

Геометрия
12.1 Метод Гаусса
12.2 Поиск точек в прямоугольнике
12.3 Алгоритм Бентли-Оттмана
12.4 Алгоритм Грэхема
12.5 Алгоритм Джарвиса
12.6 Алгоритм Чана
12.7 Алгоритм Киркпатрика
12.8 Метод трассировки луча
12.9 Метод суммирования углов
12.10 Диаграмма Вороного и триангуляция Делоне
12.11 Алгоритм Форчуна
12.12 Рекурсивное построение диаграммы Вороного
12.13 SLERP
Структуры
12.13 R, R+, R* дерево
12.14 K-мерное дерево
12.15 BSP, VP дерево
12.16 Дерево покрытий

Персистентные структуры
13.1 Метод копирования пути
13.2 Метод толстых узлов
Структуры
13.3 Персистентный стек
13.4 Персистентная очередь
13.5 Персистентное дерево

Консенсус в сетях
14.1 Алгоритм Paxos
14.2 Задача Византийских генералов
14.3 Кворум
14.4 CAP-теорема
14.5 PACELC-теорема
14.6 Королевский алгоритм
14.7 Алгоритм Zyzzyva
Структуры
14.8 Blockchain

Целочисленное программирование
15.1 Каноническая форма, сложность решения
15.2 Алгоритмы полного перебора
15.3 Алгоритм Нарайаны
15.4 Задача о ранце
15.5 Алгоритм Meet-in-the-Middle
15.6 Задача раскроя
15.7 Метод обратного поиска
15.8 Задача планирования производства
15.9 Задача оптимизации телекоммуникационных сетей
15.10 Метод секущих плоскостей, алгоритм Гомори
15.11 Алгоритм Альфа-Бета отсечений
15.12 Жадные алгоритмы
15.13 Матроиды, алгоритм Радо-Эдмонса

Быстрые вычисления
16.1 Умножение Карацубы
16.2 Алгоритм Шенхаге-Штрассена
16.3 Алгоритмы возведения числа в степень
16.4 Алгоритмы возведения в степень числа по модулю
16.5 Алгоритм Кули-Тьюки
16.6 Алгоритм Штрассена

Факторизация
17.1 Алгоритм Евклида (НОД)
17.2 Алгоритм факторизации Ферма
17.3 Метод квадратичных форм Шенкса
17.4 Ро-алгоритм Полларда
17.5 Метод квадратичного решета
17.6 Общий метод решета числового поля
17.7 Факторизация с помощью эллиптических кривых
17.8 Тест Агравала-Каяла-Саксены
17.9 Алгоритм Берлекэмпа

Дискретное логарифмирование
18.1 Алгоритм Гельфонда-Шенкса
18.2 Алгоритм COS

Обработка очередей
18.1 Семейство алгоритмов Round-robin
18.2 Алгоритм EDF
18.3 Алгоритм SRTF
18.4 Алгоритм Fixed-priority pre-emptive scheduling
18.5 Задача составления расписания (JSP, OSSP)
18.6 CFS планировщик
18.7 BFS планировщик

Кеширование
19.1 T-дерево
19.2 Алгоритм Белади
19.3 FIFO, LIFO кеширование
19.4 LRU, PLRU кеширование
19.5 MRU кеширование
19.6 RR кеширование
19.7 LFU кеширование
19.8 MQ кеширование
19.9 ARC кеширование

Рандомизированные алгоритмы
20.1 Метод Монте-Карло
20.2 Поиск наименьшего набора ребер, разрезающего циклы
20.3 Муравьиный алгоритм
20.4 Алгоритм Каргера
20.5 Изоморфизм графов (алгоритм Blum-Kanan)
20.6 Rapidly exploring random tree
20.7 Тасование Фишера-Йетса
20.8 Алгоритм Karloff–Zwick

Вероятностные тесты на простоту
21.1 Тест Ферма
21.2 Тест Миллера-Рабина
21.1 Тест Бейли-Померанца-Селфриджа-Уогстаффа

Вебграфы
22.1 Модель Болобаша-Альберта
22.2 Модель Болобаша-Риордана
22.3 Модель Бакли-Остгус
22.4 Модель копирования
22.5 PageRank, Google matrix
Структуры
22.1 MapReduce
22.2 Apache GiGraph
22.3 Pregel

Хеширование
23.1 Двойное хеширование
23.2 Фильтр Блума
23.3 Count-min sketch
23.4 Универсальное хеширование
23.5 SWIFFT
23.6 MD5
23.7 SHA-2
23.8 SHA-3 (Keccak)
23.9 Дерево Меркла
23.10 Подпись Меркла
23.11 Хеш-функции, учитывающие близость (LSH)
23.12 Хеширование на основе расстояния Хэмминга
23.13 MinHash
23.14 SimHash
23.15 Поиск ближайшего соседа c помощью LSH

** При этом стоит учесть что запланированы еще курсы по Теории графов, Дискретной математике, Экстремальным задачам, Машинному обучению, Теории сложности и пр.пр.пр. Т.е. это просто фундаментальный курс по алгоритмам и структурам данных, который является точкой отсчета для всего остального (ну как курс по Математическому анализу).

*** Это несколько больше чем я сам знаю, так что это еще и мой план для себя подтянуть неизвестные/забытые темы. Обсудив его с коллегами, на предмет кто будет читать мы пришли к выводу, что мы все были бы рады и сейчас прослушать такой курс.
Защелок нет, уши на крышке бока ноута не закрывают, финклайта нет, экран не тех пропорций, порты не там и не те, петли не те, процессор задушенный U, видеокарта странновата, слива для воды нет, корпус подозрительный, дорого. Я ждал не этого.

По пунктам:
1. Защелки нужны. В рюкзаке разнообразная мелочь типа зажигалок, карандашей и ножей имеет свойство попадать в щель, приоткрывать крышку и царапать экран. Бортики на крышке были хороши по той же причине плюс от пыли защищали. Напяливать на ноут чехол — да, можно. Но зачем плодить сущности, если можно сделать чехол ненужным?
2. Финклайт хорошо, можно сделать и его, и подсветку клавиатуры. Особенно с учетом того, что светодиод стоит копейки. Отраженный свет лучше для глаз, он освещает тачпад, опять же бумажку рассмотреть какую.
3. Широкоформатный экран имхо для большинства видов работы неудобен. Подавляющее большинство типов работы с компьютером — обработка текста того или иного вида, неважно, статья это, код или таблицы. Текст принято разбивать на строки, которых много, следовательно, актуальна высота экрана, а не ширина. Кто-то высказывал предположение, что сейчас не производятся матрицы квадратоподобных соотношений, но это не так. QXGA и QSXGA используются в медицинском оборудовании, а там надо ехать, а не шашечки. Поэтому эти матрицы будут производиться, покуда Ктулху не фхтагн. Летом я в свой T60 вкорячил 2048х1536, датой производства которой был первый квартал 2017. Даже с алиэкспрессом не заморачивался, было в наличии в Питере.
4. Кабели зарядки, видео и сети сбоку — бесят. Они плохо гнутся и мешаются. Да, есть док, решающий эти проблемы и он удобен. Но тем не менее развести как минимум питание назад — проблема не требующая финансовых вложений вообще, это просто другой шажок в проектировании.
5. С процессором и так понятно, впрочем это на любителя. Кому-то время работы от батарей важней.
6. Видеокарта действительно устаревшая. Она неплохая, но устаревшая. Новая стоит так же или ненамного дороже.
7. Влагозащита — понятно.
8. Фото девайса со снятым корпусом навело меня на мысль, что рамы там нет, а конструкция такая же, как и изделий «референсного дизайна», которые страшно поднимать за угол, т.к. материнская плата там — самый жесткий компонент.
9. Дорого. Девайс со сравнимыми характеристиками неименитой марки стоит более чем в два раза дешевле, а за указанную сумму можно рассматривать практически любые Dell Latitude и даже Precision с комплектациями победней (но даже в эту бедную комплектацию влезет дисплей UHD), у которых хотя бы части косяков этих нет, да и даже сами финкпады не «ограниченных» серий за те же деньги гораздо интересней.

Вывод — просто еще одна модель в текущем модельном ряду с логотипом другого цвета и почему-то дорогая.
Забыли посчитать, сколько будет стоить масло-фильтры-свечи, а так же, например, ремень ГРМ. Это вторая статья расходов на ДВС после, собственно, бензина.
Даю примерный подсчет для пробега 100к км для средней иномарки с небольшим двигателем 1.3...1.6л.
Дальше много текста и цифр, может быть скучно
100к км это как минимум одна замена ГРМ (лучше 2, если этот пробег накатывается за 4-6 лет и\или имеем дело с крупными городами, где частые пробки, т.е. перегревы мотора, а так же куча реагентов на дороге), 6-8 замен масла с соответствующей заменой масляного фильтра (и не верьте слвоам производителя, дескать, на одной замене хоть 100к катайся. Брехня это. 10, ну 15 тысяч это предел ресурса для масла, если стоит задача продать машину на вторичке, а не выкинуть после 100-120к км), 5-8 замен воздушных фильтров, 2-4 замены свеч.

На круг сии операции выходят 2х100 у.е. за ремни, как минимум 500-700 у.е. суммарно за масло, еще около 150 у.е. суммарно за свечи и воздушки. Да, еще я бы порекомендовал при сроке эксплуатации больше 3 лет сменить ВВ провода, это около 30 баксов, но на расход топлива влияет очень сильно, вплоть до 1л\100км, хотя на легковушках обычно 0.3..0.5л\100км разница между старыми и новыми проводами.

Значит, 200+600+150+30 — округленно около 1000 у.е. дополнительных трат к бензину за 100к км пробега. Сам бензин, кстати, стоит порядка 0.8 у.е.\литр, т.е. каждые 100км по городу будут обходится в среднем в 6 у.е., а значит за 100к км набежит 6000 у.е.
Итого стоимость владения средней легковушкой с двс на 100к пробега составит 7000 у.е.

Для электромобиля все эти расходы выбрасываем, остается только чистая электроэнергия и все такое. Цену на электричество возьмем 5р\кВтч (это по курсу 0.08 у.е.), чтоб проще считать, расход чуть выше указанного вами — 30кВтч\100км + заложим перерасход на КПД зарядника — еще 30% сверху. Получается, что электроэнергии израсходуется за тот же пробег 30кВтч * 1000 * 0.08 = 2400 у.е. + заложенный мной процент погрешности 30% = 3200 у.е.



Итоговая разница при раскладе по полочкам более чем в два раза. Да, можно взять какой-нибудь экобуст с объемом 1 литр или даже 0.6...0.8 л, никакущей динамикой (попробуйте в горку с двумя крепкими парнями в салоне заехать, да еще и при включенном кондиционере) и расходом где-то в 3,5-4,5 литра даже по городу, соотношение сильно выровняется. Но такой авто с ДВС после 100 тысяч пробега можно просто сдавать в утиль или разбирать на запчасти, т.к. мотор полностью выработает свой ресурс, работая постоянно на пределе. Это идеальный вариант для девушки кататься на работу и возить на пассажирском сиденье сумочку и пакет с продуктами, не более.

В принципе еще можно посчитать, что авто с ДВС можно через 3-5 лет неплохо продать, потеряв при пробеге около 100 тысяч км буквально 30% от рыночной цены. Но ведь и электромобиль возрастом в 3-5 лет весьма котируется, пусть и потеряет немного больше в цене, разница не более 45-50% выходит. К тому же, ЕМНИП, есть вознаграждение за сдачу старого АКБ при покупке нового, что есть неплохой бонус (трейд-ину и не снилось).
Поясняю — я затрагивал только аспекты, уникальные для ДВС и электромобилей. Все, что вы привели, есть и там, и там, поэтому учитывать это бессмысленно. Да, будет разница в стоимости обслуживания за счет разных классов, и это логично — никто ведь не требует, чтоб оригинальный фильтр на мерседес Е-класса стоил столько же, сколько и на какой-нибудь Cherry QQ.

Салонный фильтр — это не фильтр воздуха для ДВС. Отдельная тема, его и в обычной машине в общем-то менять надо каждые год-два максимум, а лучше при резкой смене сезона в условиях нашего климата, ибо легионнелез не дремлет, особенно если часто пользоваться кондиционером.

масло в редукторах — я не считал расходы на КПП и всякое сопутствующее трансмиссионное для ДВС. И не нужно говорить, что масло в КПП рассчитано на весь срок службы — это так, если срок службы подразумевает 3-4 года или 80-120тысяч пробега до списания машины на металлолом. Нормативно масло в МКПП менять надо каждые 40-60 тысяч, в АКПП в зависимости от типа от 30 до 50 тысяч.

Охлаждайка меняется и в ДВС, да ее там поменьше, но литров 10-12 точно набирается. Так что можно не учитывать, этот аспект, ибо канистра тосола стоит порядка 10 у.е. за 10 литров, и менять его надо не так часто — года 2-3 тосол служит спокойно, ну или 30-50 тысяч пробега. В электромобиле, где режим работы не такой жесткий в плане температур, может и дольше прослужить, кстати, так что вероятно, в плане стоимости замены то на то и выйдет.

фреон в кондиционере нужно добавлять и в машине с ДВС, как не крути.

Официальные цены на ТО для Теслы в США — в среднем около 600 долларов в год или 12500 миль. Что, как ни странно, дороже, чем ТО Мерседеса S500 в Москве.


Можно сравнительные списки, что в это ТО входит и там, и там? Тесла, емнип, меняет дворники и тормозные колодки вроде за эту сумму, + смена фильтра салона, ОЖ и диагностика всех систем
Никогда природа не брала верх — самолеты летают быстрее птиц, атомная электростанция имеет большую удельную энергию, чем растения, итд.
Не согласна Вами — природа это просто оператор random(); по коду DNA. Она убога, и примитивна. Человечество добилось во многом большего за какую-то сотню-другую лет существования науки, а у природы было 4.5 миллиарда лет.
Несомненно, мы выиграем, по тому, что нам противостоит примитивная, бездушная, не осознающая себя стихия
На Хабре у CodeRush есть прекрасные статьи про UEFI, а такой мусор клепают для накрутки трафика из поисковиков.

Information

Rating
Does not participate
Registered
Activity