Основная причина: фронтир сдвинулся дальше. В ту самую эпоху, о которой сожалеет автор, сожалел ли он, что электронщики пошли куда-то не туда, и никто больше не выдумывает новых схем управления заводом всего на 10 электронных лампах? Сомневаюсь. Когда-то фронтир пролегал по электронике, по новым схемам. Потом разработали наиболее универсальные решения, и на этом бурное развитие области "устаканилось". Это не значит, что перестали появляться новые схемы, это значит, что основной фокус сместился в другую область. Сейчас, например, экспериментов с архитектурами нейросетей ничуть не меньше, чем экспериментов с софтом в описываемую автором эпоху.
Бунтари. А куда делись бунтари, которые способны при помощи нескольких резисторов и ардуины дать новую функциональность какому-то девайсу? Да никуда не делись, продолжают заниматься своими экспериментами, только на них внимания обращают меньше. А то, что софт (кроме специализированного или хакерского) перестал лезть в недокументированные недра системы, чтобы что-то там для себя сделать - так это скорее благо, меньше проблем со стабильностью и совместимостью.
Автор сравнивает культуру стартапов/предприятий, где IT - не профильное направление, и современный энтерпрайз. Не надо идеализировать корпоративную разработку софта из прошлого, там и раньше было вряд ли сильно романтичнее. Большой бизнес любит предсказуемость, чтобы планировать шаги на месяцы и даже годы. А за последние 20-30 лет он серьёзно продвинулся в области управления человеческими ресурсами. Я думаю, автору имеет смысл обратить внимание на стартапы, где тот фрики-изобретатели делают тот самый автобус с тягой из двух фенов из анекдота.
Уход со сцены борьбы с нехваткой ресурсов. Выжимание максимума из железа - это, безусловно, здорово. И это искусство. Сейчас пути искусства и создания софта разделились - просто потому, что когда ты делаешь софт, лучше сконцентрироваться на создании софта, а не на героическом превозмогании проблем. Описанная на Хабре же история создания игры Crash Bandicoot (https://habr.com/ru/articles/260637/). Читается как захватывающая история. Но не было бы лучше, если бы вместо борьбы с нехваткой памяти они могли бы заняться непосредственно разработкой игры? Это напоминает мне лайфхаки времён СССР "если под рукой не оказалось" (https://germanych.livejournal.com/288841.html). Сейчас такие лайфхаки распространены куда меньше. Стоит ли об этом жалеть? Смекалка, способность решить проблему нестандартными методами - это хорошо. Но отсутствие необходимости её постоянно решать - тоже, безусловно хорошо. Кстати, в тех областях, где до сих пор приходится бороться за каждый такт (например, высокопроизводительные вычисления для нейросетей) - там до сих пор идёт борьба производительность. Только это делается в R&D-отделах буквально единиц компаний во всём мире.
Способность одного сверхценного специалиста остановить бизнес в случае неэтичного поведения последнего. Точнее, сильное сужение спектра возможностей сделать так. Тут причина в том, что появились средства разделения труда, предполагающие не завязываться на 1 человека. Т.е. из людей строят систему по тем же принципам, по которым программеры и админы строят отказоустойчивую систему из нескольких серверов. Также во многих энтерпрайз-компаниях разработка отделена от эксплуатации, в некоторых компаниях разработчики вообще не имеют доступа к данным с прода. Сейчас возможность критического специалиста нанести серьёзный вред бизнесу, скорее всего, есть, только чаще всего это выражается не в потере данных (т.к. системы бэкапа и облачные хранилища во многом позволяют автоматизировать архивацию), а в утечке конфиденциальных данных или в совершении через IT-инфраструктуру некоторых действий, которые нанесут серьёзный вред компании (например, использование оборудования в нештатном режиме и т.д.)
Превращение искусства в ремесло. Да, на мой взгляд, искусство - это высшая форма ремесла, соединённая со смыслом. И искусство постоянно переходит в ремесло. Когда-то фотореалистичный портрет был чем-то из ряда вон выходящим, его писали месяцами. Сейчас даже полностью написанный от руки фотореалистичный портрет никого не удивит, т.к. это уже давно массовое явление, и как натренировать этот навык - это тоже отчасти поставлено на поток.
Моё отношение к этому, в целом: Да, это была офигенная эпоха. Да, чувствовать себя героем на острие атаки было клёво. Я и сам изучал внутренности Windows 98 с SoftICE, и через Ida Pro и Hiew учил программы запускаться там, где они запускаться почему-то не хотели.
Но теперь фронтир передвинулся, и если хочется романтики фронтира снова, то пора передвигаться вслед за ним. Ну или же из охотника за сокровищами (или за головами) становиться строителем, водопроводчиком, врачом, инженером или рекламным агентом: вслед за фронтиром приходит цивилизация со своими особенностями жизни и потребностями. И там, где раньше требовалась меткая стрельба и умение скрытно ходить по лесу, теперь требуется умение качественно класть кирпичи, сваривать трубы, диагностировать болезни, чинить машины или продавать труд вышеозначенных профессий другим.
Вот многие тут смеются, но подобная ситуация у меня была однажды.
Я как-то не прошёл интервью в Яндекс, решая задачу в подобных условиях.
При этом:
1. Это была уже вторая "алгоритмическая" задача
2. Саму задачу я решил, это было её усложнение (чтобы она выполнялась за линейное время вместо n log n, если правильно помню)
3. Алгоритм я тоже предложил верный (на словах), уже при написании ошибся в инкременте/декременте переменной, связанной со скользящим окном
4. Запуск и тестовый прогон позволили бы выявить эту ошибку... но интервьюеры любезно предоставили лишь веб-версию блокнота без возможности запуска, отладки.
Самое интересное, это было интервью на позицию Solution Architect.
Не знаю, может, в яндексе solution architect'ы большую часть времени кодят "на бумажке" без среды разработки и отладчика.
Впрочем, я об этом отказе вообще не пожалел: через несколько дней уже успешно прошёл другое собеседование, где спрашивали про вещи, действительно связанные с архитектурой.
Человек, как известно, ходит, попеременно перемещая опору на каждую из ног. Особенности строения организма человека таковы, что его средняя скорость ходьбы — в пределах 3..6 км/ч, что заметно ниже скорости множества диких животных. При этом в течение дня человеку зачастую надо преодолеть расстояние в десятки километров.
Решение: универсальные места ожидания автотранспорта (остановки)
Подождав немного на остановке, вы можете сесть в автобус или электропоезд, который довезёт вас довольно близко к точке назначения.
К чему это я:
Ускоряется не любой код на питоне, ускоряется конкретно обработка больших унифицированных массивов.
Ускорить, например, сложную стейт-машину таким образом вряд ли получится.
Название, как минимум, некорректно, сравнение тоже некорректно, пакетная обработка на других языках с использованием такого же синтаксиса будет не менее быстрым.
И да, интересно: каким образом у такой статьи появились 46 плюсов?
Проблема не в том, что эти новые хунвейбины верещат в интернете.
Проблема в том, что их кто-то слушает — например, в США корпорация может уволить неугодного сотрудника в один день.
Если бы там было хорошее трудовое законодательство, по которому можно было бы засудить компанию за такое увольнение из-за неадекватов в интернете — рычагов воздействия у этих неадекватов бы сильно поубавилось.
Производители винды и некоторые другие софтовые корпорации как раз больше всего выигрывают от этой истерии.
Пока что временное решение я вижу в создании форков проектов, которые «скурвились», и в том, чтобы донатить «правильным» проектам и организациям. Чтобы не было зависимости от корпоративного бабла.
Я одобряю данную разработку, но только потому, что для борьбы снаряда и брони требуется, чтобы «преодолеваемая» часть была в свободном доступе (и, желательно, в как можно большем числе вариантов)
С большим распространением программ трекинга мимики и поворота головы появится больше способов изучить противодействие им.
Я работал с несколькими ToF-лидарами одновременно и могу сказать, что они могут начинать давать помехи друг на друга, в этом один из их главных недостатков по сравнению с «пассивными» камерами.
Облако точек объекта, освещённого несколькими ToF-лидарами, начнёт серьёзно «расплываться».
Для телефона такое ещё может прокатить (особой опасности нет, если картинка получится не особо чёткой), а вот для автомобилей — там уже нужны дублирующие решения
Оно именно что много даёт в плане понимания модели. В реальную модель очень сложно понатыкать датчиков к каждому нейрону, да ещё и смотреть, как растут новые dentridic spines.
Я уверен, что первая модель мозга какого угодно существа будет переусложнённой и чрезвычайно избыточной, но именно она позволит выяснить основные закономерности, как там всё происходит, и построить упрощённую и более реалистичную модель.
Картирование без определения синаптического веса каждого синапса бессмысленно, с этим согласен. Но это просто нужно более точное сканирование.
Я предполагаю, что срезание острым лезвием тут уже не поможет, нужно испарение лазером и считывание поверхности через микроскоп сверхвысокого разрешения (возможно даже атомно-силовой)
Про разные вещества в разных дендритах одного нейрона — есть ссылки, где про это можно почитать, как они влияют на функции самого нейрона?
За это отвечают 2 (ДВА) нейрона. А собственно память хранится в одном. Теперь вдумайтесь, есть огромный открытый мир, есть невероятное количество видов и штаммов бактерий и простейших. Один нейрон распознает несъедобных и ядовитых простейших и бактерий, и он же почти самостоятельно обучается и хранит в себе память о них. Без внешних сложных воздействий.
Сам нейрон распознаёт? Т.е. у него есть рецепторы, отвечающие за детект определённых соединений, на которые происходит реакция?
А насчёт одного нейрона памяти — если взаимодействие там чисто электрохимическое, т.е. на входе и на выходе только изменение AP, то можно описать этот нейрон и, чисто теоретически, вставить вместо него полностью синтетический нейрон с такой функцией зависимости выхода от входа.
А если кроме электрохимического взаимодействия присутствуют другие модели (например, химическое) — то имеет смысл в первую очередь искать их и пути их воздействия на нейрон.
Скорость работы с такой клавиатурой оставляет желать лучшего.
Поэтому иммет смысл ввести или хотя бы цифровую клавиатуру, и применять метод набора с телефона, или сделать последовательности нажатий.
У нас 4 кнопки направления. Если взять возможный набор из 64 символов, вполне можно уложиться, каждый символ будет вводиться 3 нажатиями. По мере привыкания пользователя к этому методу набора скорость ввода станет довольно высокой — как у набора СМС в кнопочных телефонах.
Для фотонов — да, дела обстоят именно так.
Но что, если облучать другими частицами?
Электронами или ещё чем-то (правда, вопрос, как там с линзированием?)
Мне кажется, предел стоит искать не в миниатюризации, а в увеличении энергоэффективности.
Возможно, охлаждённые до температуры сверхпроводимости материалы справятся с этим куда лучше
Ну а вообще, нужен баланс между стоимостью изготовления процессора и стоимостью энергии, которую он потребляет в процессе работы
Интересно, в каком состоянии сейчас исследования в области графеновых и прочих полупроводников, которые теоретически могут быть ещё меньше/ещё энергоэффективнее?
внутри бинари это будет привязано к определенной инит-системе, что противоречит духу платформы.
Это генерирует много ненужных костылей вокруг запуска этих скриптов.
И потом использование SCM вполне может быть опциональным — есть же виндовые программы, которые могут запускаться и как сервис, и как обычная программа.
Ну и да, совершенно необязательно повторять все косяки Win SCM. Я говорю о самой структуре управления сервисами, когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
Windows NT появился в 1993 году. Windows 2000 — в 2000.
И там уже была вполне вменяемая система запуска сервисов и довольно функциональный ServiceControlManager.
Неужели было настолько сложно взять это удачное решение (SCM API) за основу?
У него уже тогда было довольно много очевидных преимуществ над той системой, что тогда была в линуксе, расширенный контроль системы над состоянием сервисов и т.д.
Очевидно, что рейтинг каждый сервер должен составлять сам — иначе те, кто тем или иным образом могут влиять на таблицу рейтинга (например, на правила этого рейтинга), получают слишком большую власть — и новое состояние становится немногим лучше централизации в руках крупных игроков.
Тут же всё очевидно — если админ srv1 доверяет srv2, и при этом из srv2 сыпется спам — это проблемы srv1 и его пользователей.
Мне кажется, причин грусти автора несколько.
Основная причина: фронтир сдвинулся дальше. В ту самую эпоху, о которой сожалеет автор, сожалел ли он, что электронщики пошли куда-то не туда, и никто больше не выдумывает новых схем управления заводом всего на 10 электронных лампах? Сомневаюсь. Когда-то фронтир пролегал по электронике, по новым схемам. Потом разработали наиболее универсальные решения, и на этом бурное развитие области "устаканилось". Это не значит, что перестали появляться новые схемы, это значит, что основной фокус сместился в другую область.
Сейчас, например, экспериментов с архитектурами нейросетей ничуть не меньше, чем экспериментов с софтом в описываемую автором эпоху.
Бунтари. А куда делись бунтари, которые способны при помощи нескольких резисторов и ардуины дать новую функциональность какому-то девайсу? Да никуда не делись, продолжают заниматься своими экспериментами, только на них внимания обращают меньше.
А то, что софт (кроме специализированного или хакерского) перестал лезть в недокументированные недра системы, чтобы что-то там для себя сделать - так это скорее благо, меньше проблем со стабильностью и совместимостью.
Автор сравнивает культуру стартапов/предприятий, где IT - не профильное направление, и современный энтерпрайз.
Не надо идеализировать корпоративную разработку софта из прошлого, там и раньше было вряд ли сильно романтичнее. Большой бизнес любит предсказуемость, чтобы планировать шаги на месяцы и даже годы. А за последние 20-30 лет он серьёзно продвинулся в области управления человеческими ресурсами.
Я думаю, автору имеет смысл обратить внимание на стартапы, где тот фрики-изобретатели делают тот самый автобус с тягой из двух фенов из анекдота.
Уход со сцены борьбы с нехваткой ресурсов. Выжимание максимума из железа - это, безусловно, здорово. И это искусство. Сейчас пути искусства и создания софта разделились - просто потому, что когда ты делаешь софт, лучше сконцентрироваться на создании софта, а не на героическом превозмогании проблем. Описанная на Хабре же история создания игры Crash Bandicoot (https://habr.com/ru/articles/260637/). Читается как захватывающая история.
Но не было бы лучше, если бы вместо борьбы с нехваткой памяти они могли бы заняться непосредственно разработкой игры?
Это напоминает мне лайфхаки времён СССР "если под рукой не оказалось" (https://germanych.livejournal.com/288841.html). Сейчас такие лайфхаки распространены куда меньше. Стоит ли об этом жалеть?
Смекалка, способность решить проблему нестандартными методами - это хорошо. Но отсутствие необходимости её постоянно решать - тоже, безусловно хорошо.
Кстати, в тех областях, где до сих пор приходится бороться за каждый такт (например, высокопроизводительные вычисления для нейросетей) - там до сих пор идёт борьба производительность. Только это делается в R&D-отделах буквально единиц компаний во всём мире.
Способность одного сверхценного специалиста остановить бизнес в случае неэтичного поведения последнего. Точнее, сильное сужение спектра возможностей сделать так. Тут причина в том, что появились средства разделения труда, предполагающие не завязываться на 1 человека. Т.е. из людей строят систему по тем же принципам, по которым программеры и админы строят отказоустойчивую систему из нескольких серверов.
Также во многих энтерпрайз-компаниях разработка отделена от эксплуатации, в некоторых компаниях разработчики вообще не имеют доступа к данным с прода.
Сейчас возможность критического специалиста нанести серьёзный вред бизнесу, скорее всего, есть, только чаще всего это выражается не в потере данных (т.к. системы бэкапа и облачные хранилища во многом позволяют автоматизировать архивацию), а в утечке конфиденциальных данных или в совершении через IT-инфраструктуру некоторых действий, которые нанесут серьёзный вред компании (например, использование оборудования в нештатном режиме и т.д.)
Превращение искусства в ремесло. Да, на мой взгляд, искусство - это высшая форма ремесла, соединённая со смыслом. И искусство постоянно переходит в ремесло. Когда-то фотореалистичный портрет был чем-то из ряда вон выходящим, его писали месяцами. Сейчас даже полностью написанный от руки фотореалистичный портрет никого не удивит, т.к. это уже давно массовое явление, и как натренировать этот навык - это тоже отчасти поставлено на поток.
Моё отношение к этому, в целом:
Да, это была офигенная эпоха. Да, чувствовать себя героем на острие атаки было клёво. Я и сам изучал внутренности Windows 98 с SoftICE, и через Ida Pro и Hiew учил программы запускаться там, где они запускаться почему-то не хотели.
Но теперь фронтир передвинулся, и если хочется романтики фронтира снова, то пора передвигаться вслед за ним.
Ну или же из охотника за сокровищами (или за головами) становиться строителем, водопроводчиком, врачом, инженером или рекламным агентом: вслед за фронтиром приходит цивилизация со своими особенностями жизни и потребностями. И там, где раньше требовалась меткая стрельба и умение скрытно ходить по лесу, теперь требуется умение качественно класть кирпичи, сваривать трубы, диагностировать болезни, чинить машины или продавать труд вышеозначенных профессий другим.
Не надо всех под одну гребёнку. В России есть как адекватные компании, так и долбанутые.
Как, наверное, и в Америке, и в Азии.
Этот код станет ещё веселее, если сделать условие по дате-времени, после которого начинает проверяться random.
Вот многие тут смеются, но подобная ситуация у меня была однажды.
Я как-то не прошёл интервью в Яндекс, решая задачу в подобных условиях.
При этом:
1. Это была уже вторая "алгоритмическая" задача
2. Саму задачу я решил, это было её усложнение (чтобы она выполнялась за линейное время вместо n log n, если правильно помню)
3. Алгоритм я тоже предложил верный (на словах), уже при написании ошибся в инкременте/декременте переменной, связанной со скользящим окном
4. Запуск и тестовый прогон позволили бы выявить эту ошибку... но интервьюеры любезно предоставили лишь веб-версию блокнота без возможности запуска, отладки.
Самое интересное, это было интервью на позицию Solution Architect.
Не знаю, может, в яндексе solution architect'ы большую часть времени кодят "на бумажке" без среды разработки и отладчика.
Впрочем, я об этом отказе вообще не пожалел: через несколько дней уже успешно прошёл другое собеседование, где спрашивали про вещи, действительно связанные с архитектурой.
Человек, как известно, ходит, попеременно перемещая опору на каждую из ног. Особенности строения организма человека таковы, что его средняя скорость ходьбы — в пределах 3..6 км/ч, что заметно ниже скорости множества диких животных. При этом в течение дня человеку зачастую надо преодолеть расстояние в десятки километров.
Решение: универсальные места ожидания автотранспорта (остановки)
Подождав немного на остановке, вы можете сесть в автобус или электропоезд, который довезёт вас довольно близко к точке назначения.
К чему это я:
Ускоряется не любой код на питоне, ускоряется конкретно обработка больших унифицированных массивов.
Ускорить, например, сложную стейт-машину таким образом вряд ли получится.
Название, как минимум, некорректно, сравнение тоже некорректно, пакетная обработка на других языках с использованием такого же синтаксиса будет не менее быстрым.
И да, интересно: каким образом у такой статьи появились 46 плюсов?
Проблема в том, что их кто-то слушает — например, в США корпорация может уволить неугодного сотрудника в один день.
Если бы там было хорошее трудовое законодательство, по которому можно было бы засудить компанию за такое увольнение из-за неадекватов в интернете — рычагов воздействия у этих неадекватов бы сильно поубавилось.
Пока что временное решение я вижу в создании форков проектов, которые «скурвились», и в том, чтобы донатить «правильным» проектам и организациям. Чтобы не было зависимости от корпоративного бабла.
С большим распространением программ трекинга мимики и поворота головы появится больше способов изучить противодействие им.
Облако точек объекта, освещённого несколькими ToF-лидарами, начнёт серьёзно «расплываться».
Для телефона такое ещё может прокатить (особой опасности нет, если картинка получится не особо чёткой), а вот для автомобилей — там уже нужны дублирующие решения
Я уверен, что первая модель мозга какого угодно существа будет переусложнённой и чрезвычайно избыточной, но именно она позволит выяснить основные закономерности, как там всё происходит, и построить упрощённую и более реалистичную модель.
Я предполагаю, что срезание острым лезвием тут уже не поможет, нужно испарение лазером и считывание поверхности через микроскоп сверхвысокого разрешения (возможно даже атомно-силовой)
Про разные вещества в разных дендритах одного нейрона — есть ссылки, где про это можно почитать, как они влияют на функции самого нейрона?
А насчёт одного нейрона памяти — если взаимодействие там чисто электрохимическое, т.е. на входе и на выходе только изменение AP, то можно описать этот нейрон и, чисто теоретически, вставить вместо него полностью синтетический нейрон с такой функцией зависимости выхода от входа.
А если кроме электрохимического взаимодействия присутствуют другие модели (например, химическое) — то имеет смысл в первую очередь искать их и пути их воздействия на нейрон.
Поэтому иммет смысл ввести или хотя бы цифровую клавиатуру, и применять метод набора с телефона, или сделать последовательности нажатий.
У нас 4 кнопки направления. Если взять возможный набор из 64 символов, вполне можно уложиться, каждый символ будет вводиться 3 нажатиями. По мере привыкания пользователя к этому методу набора скорость ввода станет довольно высокой — как у набора СМС в кнопочных телефонах.
Кто пробовал новый гном — этот вариант сейчас работает?
Но что, если облучать другими частицами?
Электронами или ещё чем-то (правда, вопрос, как там с линзированием?)
Возможно, охлаждённые до температуры сверхпроводимости материалы справятся с этим куда лучше
Ну а вообще, нужен баланс между стоимостью изготовления процессора и стоимостью энергии, которую он потребляет в процессе работы
Это генерирует много ненужных костылей вокруг запуска этих скриптов.
И потом использование SCM вполне может быть опциональным — есть же виндовые программы, которые могут запускаться и как сервис, и как обычная программа.
Ну и да, совершенно необязательно повторять все косяки Win SCM. Я говорю о самой структуре управления сервисами, когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
И там уже была вполне вменяемая система запуска сервисов и довольно функциональный ServiceControlManager.
Неужели было настолько сложно взять это удачное решение (SCM API) за основу?
У него уже тогда было довольно много очевидных преимуществ над той системой, что тогда была в линуксе, расширенный контроль системы над состоянием сервисов и т.д.
Тут же всё очевидно — если админ srv1 доверяет srv2, и при этом из srv2 сыпется спам — это проблемы srv1 и его пользователей.