В каком-то смысле эта статья - эталон. Эталон непонимания того, что есть профессия программиста.
Начнем с середины: "Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей" - почти любой программист использует в своей работе библиотеки. Библиотеки - это те же самые кирпичи, которые надо сложить вместе и соединить кодом, чтобы получить стену. Если программист не может сложить из имеющихся "кирпичей" стену - это не программист. Равно как каменщик, который с точностью до килограммов не может назвать объем раствора, чтобы построить стену из имеющихся кирпичей - не каменщик.
Хорошо, идем дальше - "Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время" - нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать - и это нам говорится открытым текстом и преподносится, как откровение свыше. "Разработка ПО — это исследование" - ребята, вас обмвнули: исследованием является только создание нового "кирпича" (нового алгоритма). Все остальное является ремеслом. "как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?" - лично я гнал бы за такой вопрос даже джуна. С объяснением "учи кирпичи!"
А потом идет кромешный ужас под названием agile/scrum. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Повод отличный, но статья ужасная - автор не понимает, о чем пишет. Про оверлеи уже сказали, но меня еще до них царапнуло, что TP 1.0 умел .com и .exe. Ровно наоборот - он умел только .com, а с версии 4.0 TP стал делать .exe, но разучился .com. Много инфы надергано из буржуйской вики, но невладение предметом привело к тому, к чему привело.
А началось все в Калифорнии в 1981 году, когда трое "понаехов" из Дании замутили там свой стартап. Пару лет дела у них шли ни шатко, ни валко, пока они не встретили такого же "понаеха", только из Франции - Филипа Кана. Кан играл в свободное время на саксофоне и не знал такого слова "стартап", поэтому он переименовал Borland в корпорацию. А еще он когда-то учился у Вирта (правда, Профессор его не оценил - "мой самый тупой студент"), и у него была работающая бизнес-идея, что средства разработки не должны быть дорогими. Отцы-основатели были знакомы с Андерсом Хейлсбергом, и судьба мира была решена: любой школяр, сэкономивший несколько долларов на завтраках, мог почувствовать себя полноценным программистом.
Техническое отступление: хотя формально первые три Турбо Паскаля были компиляторами, но ноги у них росли, на мой взгляд, из транслятора Вирта - скомпилированный код линковался с рантаймом компилятора. Полноценные компиляторы Borland выпустил, уже став успешной компанией - Turbo Pascal 4.0, Turbo C, Turbo Basic, Turbo Prolog.
Существенным прорывом стал выпуск четвертого Паскаля, который позволил разделить процесс разработки на модули (unit-ы). И это же решение заложило под Паскаль бомбу, которая несколько лет спустя стала его убивать - скомпилированные модули (.tpu) разных версий компилятора были бинарно несовместимы между собой, и при переходе с одной версии на другую надо было либо брать (покупать) у сторонних разработчиков их библиотеки под новую версию, либо искать замену. Положение немного спасали компании, которые продавали свои библиотеки в исходных текстах - Turbo Professional, Turbo Power.
Введение объектов в 5.5 ситуацию усугубило - народ писал так, как привык, и красивый и компактный Turbo Professional превратился в монструозный Object Professional. Ситуацию немного поправил Turbo Pascal 6.0 с Turbo Vision. Кстати, это был первый компилятор Turbo Pascal, написанный на нем самом. До этого его писали на ассемблере и, вроде бы, четверка была написана на Turbo C 1.0 (но это не точно). Собственно, Turbo Pascal 6.0 является тем стандартом, на который все смотрят и повторяют.
Потом все пошло плохо. Появилась винда, которая постепенно начала задавать новую парадигму. Плюс руководство Borland хотело расшириться и сделало несколько неудачных покупок, в первую очередь Ashton Tate с Dbase. Вместо привычного всем Паскаля была изобретена формошлепная Delphi, где Паскаль играл вспомогательную роль. Кан разошелся во мнениях с остальным руководством и покинул Borland. Хейлсберг, который довольно комфортно работал под руководством Кана, тоже ушел, но в Micro$oft. Дальнейшее известно.
А те ребята, которые не захотели смириться с тем, что их Turbo Pascal'я больше нет, затеяли несколько проектов по его дальнейшему развитию. Не все выжили, но free pascal живет и развивается. Причем с обратной совместимостью там все замечательно: когда несколько лет назад мне понадобилось собрать pascal-программу, написанную под dos, в линуксе - правки были минимальные и касались только системно-зависимых кусков.
Это все понятно. Вот только у нас есть танковые войска, воздушно-десантные, железнодорожные, саперы отдельно, etc. На стройке - бетонщики льют монолит, каменщики - выкладывают внутренние стены, штукатуры и плиточники занимаются отделкой. Электрики, водопроводчики, разнорабочие - у каждого есть свое занятие, которое он знает.
Я ведь сразу выделил - "не имеет значения, чем руководить". А так - да, если знаешь предметную область, можешь писать код на уровне продвинутого мидла, рулишь процессами внутри (хотя там еще проект-менеджер и архитектор присутствуют) и общаешься с руководством - тимлид.
Резюмирую: тимлид - это эффективный менеджер от программирования. Не имеет значения, чем руководить - машиностроительным заводом или сельским хозяйством, относится проект к небесной механике (баллистике) или к финансовым рынкам. Вы же "много разбирались в разных проектах по долгу службы, и значит, разобраться еще в одном для вас не составит серьезного труда". Гораздо важнее понять ожидания руководства.
Для поездок по относительно старым веткам, введенным до 2000 (2010) года, я использую эмпирическую формулу 3-3-1.5, где 3 минуты - время между станциями, 3 минуты - время на вход/выход в метро или переход, 1.5 минуты - время ожидания поезда (в часы пик обычно 1 минута, но там может увеличиться время на переход). Формула дает хорошую оценку сверху времени в пути с превышением на 5-10 минут на длинных маршрутах.
Для новых веток и станций за МКАДом можно добавить 5 минут и еще 3-5 минут ожидания для Ольховки и Бутовской ветки. Солнцевскую я пока толком не исследовал.
МЦК/МЦД - время перехода 10 минут, время ожидания - 5-10 минут.
Я начал думать примерно также: сначала, на первом проходе, мы строим индекс, который потом сортируем, а потом, используя индекс, читаем строки и пишем их в нужном порядке в выходной файл, дополнительно сортируя строки с одинаковым ключом. Проблема в том, что для сравнительно коротких строк (50-80 символов в строке) размер индекса будет сравнимым с исходным файлом. Я заложился на то, что индекс содержит - первые четыре байта строки (uint32), смещение от начала файла (uint64), длина строки (допустим, максимум 65535 - uint32), crc32 (uint32). Итого - 20 байт. Если средняя длина строки - от 250 байт и память 8 Гб, то максимум за 2 прохода мы получим количество необходимых блоков (уникальных ключей) и их размеры.
А вот дальше начинается самое интересное: нам надо как-то выбрать количество и размеры входных и выходных буферов, чтобы минимизировать количество операций чтения-записи на диск. Тут я слегка подзавис... Пока, навскидку, надо сначала найти ключи, для которых выходные блоки будут с 1) максимальным количеством строк и 2) максимальным объемом, потом отсортировать эти ключи, чтобы строки с ними попадали в минимальное количество входных блоков... после первой итерации отсортировать оставшиеся ключи...
В-общем, интуитивно все кажется понятным и простым, но при реализации, боюсь, возникнут нюансы. :) Интересно было бы посмотреть это все на какой-нибудь модели (если будет время).
Закономерный итог для модерируемой "социальной сети". Если кто-то еще не в курсе: содержание Вашей френдленты в FB определяете не Вы, а господин Цукерберг. Именно он решает, какие посты Ваших френдов следует показать Вам, а какие - нет. Вместо этого Вы прочитаете несколько постов от людей, на которых не подписаны. Марк лучше знает, что Вам следует читать.
Когда нет возможности передать что-то (программу или данные) по модему, они оставались единственной альтернативой. У меня коллега в 1990 году раз в месяц ездил на Ленинский в Диалог-Науку, кажется, чтобы купить у них очередной выпуск "Софтпанорамы" Безрукова. В гости к друзьям-программистам было неприлично приходить без коробки дискет, еще 5-дюймовых, в кармане. Шутка из примерно тех времен: "рынок софта в России - это кража, кража со взломом и обмен краденым".
Если вернуться к теме, то 5-дюймовые были все-таки поустойчивее, несмотря на хлипкий конверт, ко всяким стрессам. Лет 10 назад, когда я решил попробовать перегнать на современные носители старый архив, который мне достался в наследство от нашей лаборатории, то большинство пятидюймовок все-таки прочиталось. А к ним до этого не прикасались лет 20. Трехдюймовки тоже читались, как правило, но с ними у меня был в свое время печальный опыт: после того, как два или три раза подряд у меня не прочитались две копии, записанные на "флопики", после поездки в метро, я стал писать две копии, а для надежности клал в карман еще жесткий диск. :)
Еще интересная тема, которая, кажется, не получила нужного освещения, что были два разных типа 3-дюймовых приводов - от Apple и IBM. IBM вращали дискету с одинаковой скоростью, а Apple меняли скорость вращения в зависимости от дорожки. Поэтому на дискету Apple влезало 2 мегабайта информации, а не 1.44. И при этом они умели читать формат IBM. Или это была особенность не дисковода, а контроллера от Apple? Я тогда не вдавался в подробности.
зы. Интересно, сколько флопов 5 1/4 и 3 1/2 прочитается из моей коллекции сейчас? Если отнормировать выборку - 100 и 100 произвольно выбранных. :)
Исходно BSD (Berkeley Software Distribution) родилась, как набор патчей к оригинальному коду ATT, который начал распространять на лентах аспирант Беркли по имени Билл Джой. Когда Джой ушел в Sun, его дело продолжил Кирк МакКузик. Пока ATT распространяли Unix сами, все было нормально, но после выделения в отдельную фирму USL, начали возникать патентные проблемы, поэтому было принято решение очистить код BSD от проприетарных файлов. В Net/2 задача была практически выполнена, оставалось переписать 6 файлов, что и сделал Билл Джолиц.
Насчет конфликта - сильно сказано. Мне кажется, что Джолицу его проект понемногу надоел, поэтому он не стал возиться с патчами, которые ему присылали пользователи. Поскольку он никак не объяснил свое решение, то группа хакеров (в прежнем значении этого слова) форкнула 386BSD и стала развивать его самостоятельно.
Достаточно подробно эта история (включая юридический конфликт с ATT) изложена в первой главе книги МакКузика и Джорджа Невилл-Лина "FreeBSD: архитектура и реализация".
Заказчик как раз обычно знает, чего он хочет. Как бы это странно ни звучало. Просто свои пожелания он выражает на своем языке. Условно говоря, один говорит на хинди, другой на суахили, а для общения между собой они используют google переводчик.
Сейчас же я хотел сказать о другом, что путь "пусть узнает и приходит" - тупиковый изначально. Потому что грамотный заказчик найдет толкового тематика - именно так раньше назывались люди, которые писали ТЗ для конкретной задачи. Потом это стало называться, вроде бы, проект-менеджером. Как сейчас, не знаю. Архитектор - это тот, кто проектирует решение по готовому заданию. Так вот, тематик напишет ТЗ, в котором будет предусмотрено все, что только возможно, все варианты интерфейса, все алгоритмы обработки данных - садись и кодируй. Только (surprise!) 80-90% бюджета уйдет тематику, а кодеру - 10-20%.
Поэтому вариантов нет: если речь идет об IT-компании или хотя бы команде, то нужен минимум один "полиглот", если речь об одиночке - ему придется самому стать "полиглотом".
Учим матчасть. Во-первых, советские ядерные боеголовки ВСУ мало помогут. Я где-то когда-то читал, что для них следует проводить регламентные проверки раз в 5-10 лет, иначе бомба может превратиться в тыкву. Во-вторых, для всех этих работ нужна соответствующая промышленность, которой на Украине нет. Ну и в-третьих, что-то мне подсказывает, что Европа будет от такого решения совсем не в восторге - в свое время нас заставили вынести все производство ЯО в Сибирь, так что возвращение атомных бомб Украине вполне может закончиться парадным маршем пары-тройки дивизий бундесвера по Крещатику. Во избежание, так сказать. :)
2.5 суток спустя ни один объект в каталоге NORAD не помечен, как COSMOS-1408 DEB. Хотя количество неидентифицированных объектов увеличилось до 745. Могу только повторить: объективную картину мы получим где-то к новому году, не раньше. Оценивать риски мы сможем не раньше, чем в свободном доступе окажутся траектории обломков.
Самое смешное - это то, что противоспутниковое оружие - средство _демилитаризации_ космоса. Типа - вывел кто-то на орбиту спутник с оружием на борту, а мы - хренакс! - и превратили это оружие в облако обломков. :)
Далее, когда NORAD говорит про "по меньшей мере 1500 обломков" - он звездит, как Троцкий: по состоянию на 20:00 Мск в каталоге NORAD было 188 неопознанных объектов, обнаруженных за последние двое суток - 691 всего. Учитывая новые старлинки. Да, это хреново, не спорю, космический мусор - большая гадость. НО, замечу - еще НИ ОДИН из этих объектов не идентифицирован, как обломок "Космоса-1408". Где-то через один-два месяца, думаю, будет объективная картина.
Зависит от квалификации установщика. При определенном опыте, сложность установки и настройки Винды и Линуха на произвольном железе - сравнимы. Если интересно - попробуй поставить "семерку", к примеру, на свой ноут с нуля. Узнаешь много интересного, обещаю. ;)
Пишу с J3455/6/64+256/13.3"/FullHD — вполне себе тянет под Debian. Узкое место — firefox, память потихоньку утекает, и его приходится перезапускать, примерно раз в сутки. web+почта+libre office+несложная разработка.
В каком-то смысле эта статья - эталон. Эталон непонимания того, что есть профессия программиста.
Начнем с середины: "Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей" - почти любой программист использует в своей работе библиотеки. Библиотеки - это те же самые кирпичи, которые надо сложить вместе и соединить кодом, чтобы получить стену. Если программист не может сложить из имеющихся "кирпичей" стену - это не программист. Равно как каменщик, который с точностью до килограммов не может назвать объем раствора, чтобы построить стену из имеющихся кирпичей - не каменщик.
Хорошо, идем дальше - "Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время" - нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать - и это нам говорится открытым текстом и преподносится, как откровение свыше. "Разработка ПО — это исследование" - ребята, вас обмвнули: исследованием является только создание нового "кирпича" (нового алгоритма). Все остальное является ремеслом. "как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?" - лично я гнал бы за такой вопрос даже джуна. С объяснением "учи кирпичи!"
А потом идет кромешный ужас под названием agile/scrum. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Повод отличный, но статья ужасная - автор не понимает, о чем пишет. Про оверлеи уже сказали, но меня еще до них царапнуло, что TP 1.0 умел .com и .exe. Ровно наоборот - он умел только .com, а с версии 4.0 TP стал делать .exe, но разучился .com. Много инфы надергано из буржуйской вики, но невладение предметом привело к тому, к чему привело.
А началось все в Калифорнии в 1981 году, когда трое "понаехов" из Дании замутили там свой стартап. Пару лет дела у них шли ни шатко, ни валко, пока они не встретили такого же "понаеха", только из Франции - Филипа Кана. Кан играл в свободное время на саксофоне и не знал такого слова "стартап", поэтому он переименовал Borland в корпорацию. А еще он когда-то учился у Вирта (правда, Профессор его не оценил - "мой самый тупой студент"), и у него была работающая бизнес-идея, что средства разработки не должны быть дорогими. Отцы-основатели были знакомы с Андерсом Хейлсбергом, и судьба мира была решена: любой школяр, сэкономивший несколько долларов на завтраках, мог почувствовать себя полноценным программистом.
Техническое отступление: хотя формально первые три Турбо Паскаля были компиляторами, но ноги у них росли, на мой взгляд, из транслятора Вирта - скомпилированный код линковался с рантаймом компилятора. Полноценные компиляторы Borland выпустил, уже став успешной компанией - Turbo Pascal 4.0, Turbo C, Turbo Basic, Turbo Prolog.
Существенным прорывом стал выпуск четвертого Паскаля, который позволил разделить процесс разработки на модули (unit-ы). И это же решение заложило под Паскаль бомбу, которая несколько лет спустя стала его убивать - скомпилированные модули (.tpu) разных версий компилятора были бинарно несовместимы между собой, и при переходе с одной версии на другую надо было либо брать (покупать) у сторонних разработчиков их библиотеки под новую версию, либо искать замену. Положение немного спасали компании, которые продавали свои библиотеки в исходных текстах - Turbo Professional, Turbo Power.
Введение объектов в 5.5 ситуацию усугубило - народ писал так, как привык, и красивый и компактный Turbo Professional превратился в монструозный Object Professional. Ситуацию немного поправил Turbo Pascal 6.0 с Turbo Vision. Кстати, это был первый компилятор Turbo Pascal, написанный на нем самом. До этого его писали на ассемблере и, вроде бы, четверка была написана на Turbo C 1.0 (но это не точно). Собственно, Turbo Pascal 6.0 является тем стандартом, на который все смотрят и повторяют.
Потом все пошло плохо. Появилась винда, которая постепенно начала задавать новую парадигму. Плюс руководство Borland хотело расшириться и сделало несколько неудачных покупок, в первую очередь Ashton Tate с Dbase. Вместо привычного всем Паскаля была изобретена формошлепная Delphi, где Паскаль играл вспомогательную роль. Кан разошелся во мнениях с остальным руководством и покинул Borland. Хейлсберг, который довольно комфортно работал под руководством Кана, тоже ушел, но в Micro$oft. Дальнейшее известно.
А те ребята, которые не захотели смириться с тем, что их Turbo Pascal'я больше нет, затеяли несколько проектов по его дальнейшему развитию. Не все выжили, но free pascal живет и развивается. Причем с обратной совместимостью там все замечательно: когда несколько лет назад мне понадобилось собрать pascal-программу, написанную под dos, в линуксе - правки были минимальные и касались только системно-зависимых кусков.
Такие дела.
Это все понятно. Вот только у нас есть танковые войска, воздушно-десантные, железнодорожные, саперы отдельно, etc. На стройке - бетонщики льют монолит, каменщики - выкладывают внутренние стены, штукатуры и плиточники занимаются отделкой. Электрики, водопроводчики, разнорабочие - у каждого есть свое занятие, которое он знает.
Я ведь сразу выделил - "не имеет значения, чем руководить". А так - да, если знаешь предметную область, можешь писать код на уровне продвинутого мидла, рулишь процессами внутри (хотя там еще проект-менеджер и архитектор присутствуют) и общаешься с руководством - тимлид.
Резюмирую: тимлид - это эффективный менеджер от программирования. Не имеет значения, чем руководить - машиностроительным заводом или сельским хозяйством, относится проект к небесной механике (баллистике) или к финансовым рынкам. Вы же "много разбирались в разных проектах по долгу службы, и значит, разобраться еще в одном для вас не составит серьезного труда". Гораздо важнее понять ожидания руководства.
У Alinx есть своя учетка на гитхабе (alinxalinx), а плата называется - AX4010.
Для поездок по относительно старым веткам, введенным до 2000 (2010) года, я использую эмпирическую формулу 3-3-1.5, где 3 минуты - время между станциями, 3 минуты - время на вход/выход в метро или переход, 1.5 минуты - время ожидания поезда (в часы пик обычно 1 минута, но там может увеличиться время на переход). Формула дает хорошую оценку сверху времени в пути с превышением на 5-10 минут на длинных маршрутах.
Для новых веток и станций за МКАДом можно добавить 5 минут и еще 3-5 минут ожидания для Ольховки и Бутовской ветки. Солнцевскую я пока толком не исследовал.
МЦК/МЦД - время перехода 10 минут, время ожидания - 5-10 минут.
Я начал думать примерно также: сначала, на первом проходе, мы строим индекс, который потом сортируем, а потом, используя индекс, читаем строки и пишем их в нужном порядке в выходной файл, дополнительно сортируя строки с одинаковым ключом. Проблема в том, что для сравнительно коротких строк (50-80 символов в строке) размер индекса будет сравнимым с исходным файлом. Я заложился на то, что индекс содержит - первые четыре байта строки (uint32), смещение от начала файла (uint64), длина строки (допустим, максимум 65535 - uint32), crc32 (uint32). Итого - 20 байт. Если средняя длина строки - от 250 байт и память 8 Гб, то максимум за 2 прохода мы получим количество необходимых блоков (уникальных ключей) и их размеры.
А вот дальше начинается самое интересное: нам надо как-то выбрать количество и размеры входных и выходных буферов, чтобы минимизировать количество операций чтения-записи на диск. Тут я слегка подзавис... Пока, навскидку, надо сначала найти ключи, для которых выходные блоки будут с 1) максимальным количеством строк и 2) максимальным объемом, потом отсортировать эти ключи, чтобы строки с ними попадали в минимальное количество входных блоков... после первой итерации отсортировать оставшиеся ключи...
В-общем, интуитивно все кажется понятным и простым, но при реализации, боюсь, возникнут нюансы. :) Интересно было бы посмотреть это все на какой-нибудь модели (если будет время).
Закономерный итог для модерируемой "социальной сети". Если кто-то еще не в курсе: содержание Вашей френдленты в FB определяете не Вы, а господин Цукерберг. Именно он решает, какие посты Ваших френдов следует показать Вам, а какие - нет. Вместо этого Вы прочитаете несколько постов от людей, на которых не подписаны. Марк лучше знает, что Вам следует читать.
О! "Флопы" - это тема.
Когда нет возможности передать что-то (программу или данные) по модему, они оставались единственной альтернативой. У меня коллега в 1990 году раз в месяц ездил на Ленинский в Диалог-Науку, кажется, чтобы купить у них очередной выпуск "Софтпанорамы" Безрукова. В гости к друзьям-программистам было неприлично приходить без коробки дискет, еще 5-дюймовых, в кармане. Шутка из примерно тех времен: "рынок софта в России - это кража, кража со взломом и обмен краденым".
Если вернуться к теме, то 5-дюймовые были все-таки поустойчивее, несмотря на хлипкий конверт, ко всяким стрессам. Лет 10 назад, когда я решил попробовать перегнать на современные носители старый архив, который мне достался в наследство от нашей лаборатории, то большинство пятидюймовок все-таки прочиталось. А к ним до этого не прикасались лет 20. Трехдюймовки тоже читались, как правило, но с ними у меня был в свое время печальный опыт: после того, как два или три раза подряд у меня не прочитались две копии, записанные на "флопики", после поездки в метро, я стал писать две копии, а для надежности клал в карман еще жесткий диск. :)
Еще интересная тема, которая, кажется, не получила нужного освещения, что были два разных типа 3-дюймовых приводов - от Apple и IBM. IBM вращали дискету с одинаковой скоростью, а Apple меняли скорость вращения в зависимости от дорожки. Поэтому на дискету Apple влезало 2 мегабайта информации, а не 1.44. И при этом они умели читать формат IBM. Или это была особенность не дисковода, а контроллера от Apple? Я тогда не вдавался в подробности.
зы. Интересно, сколько флопов 5 1/4 и 3 1/2 прочитается из моей коллекции сейчас? Если отнормировать выборку - 100 и 100 произвольно выбранных. :)
Исходно BSD (Berkeley Software Distribution) родилась, как набор патчей к оригинальному коду ATT, который начал распространять на лентах аспирант Беркли по имени Билл Джой. Когда Джой ушел в Sun, его дело продолжил Кирк МакКузик. Пока ATT распространяли Unix сами, все было нормально, но после выделения в отдельную фирму USL, начали возникать патентные проблемы, поэтому было принято решение очистить код BSD от проприетарных файлов. В Net/2 задача была практически выполнена, оставалось переписать 6 файлов, что и сделал Билл Джолиц.
Насчет конфликта - сильно сказано. Мне кажется, что Джолицу его проект понемногу надоел, поэтому он не стал возиться с патчами, которые ему присылали пользователи. Поскольку он никак не объяснил свое решение, то группа хакеров (в прежнем значении этого слова) форкнула 386BSD и стала развивать его самостоятельно.
Достаточно подробно эта история (включая юридический конфликт с ATT) изложена в первой главе книги МакКузика и Джорджа Невилл-Лина "FreeBSD: архитектура и реализация".
Заказчик как раз обычно знает, чего он хочет. Как бы это странно ни звучало. Просто свои пожелания он выражает на своем языке. Условно говоря, один говорит на хинди, другой на суахили, а для общения между собой они используют google переводчик.
Сейчас же я хотел сказать о другом, что путь "пусть узнает и приходит" - тупиковый изначально. Потому что грамотный заказчик найдет толкового тематика - именно так раньше назывались люди, которые писали ТЗ для конкретной задачи. Потом это стало называться, вроде бы, проект-менеджером. Как сейчас, не знаю. Архитектор - это тот, кто проектирует решение по готовому заданию. Так вот, тематик напишет ТЗ, в котором будет предусмотрено все, что только возможно, все варианты интерфейса, все алгоритмы обработки данных - садись и кодируй. Только (surprise!) 80-90% бюджета уйдет тематику, а кодеру - 10-20%.
Поэтому вариантов нет: если речь идет об IT-компании или хотя бы команде, то нужен минимум один "полиглот", если речь об одиночке - ему придется самому стать "полиглотом".
А я вот без Вашего комментария вряд ли бы Владу вспомнил.
Владимир Таратынов, косисоп 5020/13, считалось, что именно он создал Vlada Stavsky.
:)
Таратынов, перелогиньтесь. :)
Учим матчасть. Во-первых, советские ядерные боеголовки ВСУ мало помогут. Я где-то когда-то читал, что для них следует проводить регламентные проверки раз в 5-10 лет, иначе бомба может превратиться в тыкву. Во-вторых, для всех этих работ нужна соответствующая промышленность, которой на Украине нет. Ну и в-третьих, что-то мне подсказывает, что Европа будет от такого решения совсем не в восторге - в свое время нас заставили вынести все производство ЯО в Сибирь, так что возвращение атомных бомб Украине вполне может закончиться парадным маршем пары-тройки дивизий бундесвера по Крещатику. Во избежание, так сказать. :)
2.5 суток спустя ни один объект в каталоге NORAD не помечен, как COSMOS-1408 DEB. Хотя количество неидентифицированных объектов увеличилось до 745. Могу только повторить: объективную картину мы получим где-то к новому году, не раньше. Оценивать риски мы сможем не раньше, чем в свободном доступе окажутся траектории обломков.
NORAD 13552
Самое смешное - это то, что противоспутниковое оружие - средство _демилитаризации_ космоса. Типа - вывел кто-то на орбиту спутник с оружием на борту, а мы - хренакс! - и превратили это оружие в облако обломков. :)
Далее, когда NORAD говорит про "по меньшей мере 1500 обломков" - он звездит, как Троцкий: по состоянию на 20:00 Мск в каталоге NORAD было 188 неопознанных объектов, обнаруженных за последние двое суток - 691 всего. Учитывая новые старлинки. Да, это хреново, не спорю, космический мусор - большая гадость. НО, замечу - еще НИ ОДИН из этих объектов не идентифицирован, как обломок "Космоса-1408". Где-то через один-два месяца, думаю, будет объективная картина.
Можете минусовать... :)
У меня один странный вопрос: если репитер глушит сигнал БС, то как он сам умудряется работать?
Зависит от квалификации установщика. При определенном опыте, сложность установки и настройки Винды и Линуха на произвольном железе - сравнимы. Если интересно - попробуй поставить "семерку", к примеру, на свой ноут с нуля. Узнаешь много интересного, обещаю. ;)
зы. привет от /37 :)