В каком-то смысле эта статья - эталон. Эталон непонимания того, что есть профессия программиста.
Начнем с середины: "Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей" - почти любой программист использует в своей работе библиотеки. Библиотеки - это те же самые кирпичи, которые надо сложить вместе и соединить кодом, чтобы получить стену. Если программист не может сложить из имеющихся "кирпичей" стену - это не программист. Равно как каменщик, который с точностью до килограммов не может назвать объем раствора, чтобы построить стену из имеющихся кирпичей - не каменщик.
Хорошо, идем дальше - "Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время" - нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать - и это нам говорится открытым текстом и преподносится, как откровение свыше. "Разработка ПО — это исследование" - ребята, вас обмвнули: исследованием является только создание нового "кирпича" (нового алгоритма). Все остальное является ремеслом. "как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?" - лично я гнал бы за такой вопрос даже джуна. С объяснением "учи кирпичи!"
А потом идет кромешный ужас под названием agile/scrum. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Это все понятно. Вот только у нас есть танковые войска, воздушно-десантные, железнодорожные, саперы отдельно, 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-компании или хотя бы команде, то нужен минимум один "полиглот", если речь об одиночке - ему придется самому стать "полиглотом".
Налицо конфликт интересов: Вы хотите работать, находясь не в России, но правила работодателя запрещают такую работу. Поскольку вы в разных весовых категориях, я бы не стал рассчитывать, что Ваш работодатель ради Вас изменит свои правила.
Запрет на работу для находящихся вне России. Тут есть три нюанса. Во-первых, если сотрудник принципиально важен, то нужно иметь хоть какую-то возможность связаться с ним или узнать о его судьбе в случае форс-мажора. Чтобы просто понимать, надо ли в авральном порядке вводить на его позицию кого-то другого, или человек в состоянии разрулить проблему сам. Во-вторых, человек имеет доступ во внутреннюю сеть работодателя, включая файлы с конфиденциальной информацией. Не фантастический сценарий - Вас ударили по голове, а потом скачали через Ваш ноут информации на 100 ярдов. ;) В-третьих, даже в самых детальных файлах обычно содержится не вся информация (возможно, она попадает с некоторой задержкой). Поэтому живое общение никто не отменял и не отменит.
Вы, возможно, с этим не сталкивались или этого не замечали, но увольняющимся сотрудникам уделяется несколько большее внимание - на случай, если они решат напакостить напоследок. Такое случается, поверьте. Так что Вам могли осознанно называть неправильную дату чтобы просто застраховаться от возможных Ваших деструктивных действий.
По итогу - с Вами вели себя удивительно корректно, учитывая ситуацию и работодателя. Я удивлен. Но вообще-то Вам следовало сразу расставлять все скобки над Ё, уведомлять начальников, что Вы в Россию в ближайшее время не вернетесь, чтобы они сразу начинали искать Вам замену (п. 1. правила не меняются под сотрудников). Если Вы это сделали, то Ваши бывшие начальники - идиоты. Если не сделали - то Вы подгадили людям, которые держали Вашу позицию, ожидая, что Вы приедете в Россию до .. марта.
Учим матчасть. Во-первых, советские ядерные боеголовки ВСУ мало помогут. Я где-то когда-то читал, что для них следует проводить регламентные проверки раз в 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. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Это все понятно. Вот только у нас есть танковые войска, воздушно-десантные, железнодорожные, саперы отдельно, 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.
:)
Таратынов, перелогиньтесь. :)
Разбор полетов от человека со стороны.
Налицо конфликт интересов: Вы хотите работать, находясь не в России, но правила работодателя запрещают такую работу. Поскольку вы в разных весовых категориях, я бы не стал рассчитывать, что Ваш работодатель ради Вас изменит свои правила.
Запрет на работу для находящихся вне России. Тут есть три нюанса. Во-первых, если сотрудник принципиально важен, то нужно иметь хоть какую-то возможность связаться с ним или узнать о его судьбе в случае форс-мажора. Чтобы просто понимать, надо ли в авральном порядке вводить на его позицию кого-то другого, или человек в состоянии разрулить проблему сам. Во-вторых, человек имеет доступ во внутреннюю сеть работодателя, включая файлы с конфиденциальной информацией. Не фантастический сценарий - Вас ударили по голове, а потом скачали через Ваш ноут информации на 100 ярдов. ;) В-третьих, даже в самых детальных файлах обычно содержится не вся информация (возможно, она попадает с некоторой задержкой). Поэтому живое общение никто не отменял и не отменит.
Вы, возможно, с этим не сталкивались или этого не замечали, но увольняющимся сотрудникам уделяется несколько большее внимание - на случай, если они решат напакостить напоследок. Такое случается, поверьте. Так что Вам могли осознанно называть неправильную дату чтобы просто застраховаться от возможных Ваших деструктивных действий.
По итогу - с Вами вели себя удивительно корректно, учитывая ситуацию и работодателя. Я удивлен. Но вообще-то Вам следовало сразу расставлять все скобки над Ё, уведомлять начальников, что Вы в Россию в ближайшее время не вернетесь, чтобы они сразу начинали искать Вам замену (п. 1. правила не меняются под сотрудников). Если Вы это сделали, то Ваши бывшие начальники - идиоты. Если не сделали - то Вы подгадили людям, которые держали Вашу позицию, ожидая, что Вы приедете в Россию до .. марта.
Учим матчасть. Во-первых, советские ядерные боеголовки ВСУ мало помогут. Я где-то когда-то читал, что для них следует проводить регламентные проверки раз в 5-10 лет, иначе бомба может превратиться в тыкву. Во-вторых, для всех этих работ нужна соответствующая промышленность, которой на Украине нет. Ну и в-третьих, что-то мне подсказывает, что Европа будет от такого решения совсем не в восторге - в свое время нас заставили вынести все производство ЯО в Сибирь, так что возвращение атомных бомб Украине вполне может закончиться парадным маршем пары-тройки дивизий бундесвера по Крещатику. Во избежание, так сказать. :)
2.5 суток спустя ни один объект в каталоге NORAD не помечен, как COSMOS-1408 DEB. Хотя количество неидентифицированных объектов увеличилось до 745. Могу только повторить: объективную картину мы получим где-то к новому году, не раньше. Оценивать риски мы сможем не раньше, чем в свободном доступе окажутся траектории обломков.
NORAD 13552
Самое смешное - это то, что противоспутниковое оружие - средство _демилитаризации_ космоса. Типа - вывел кто-то на орбиту спутник с оружием на борту, а мы - хренакс! - и превратили это оружие в облако обломков. :)
Далее, когда NORAD говорит про "по меньшей мере 1500 обломков" - он звездит, как Троцкий: по состоянию на 20:00 Мск в каталоге NORAD было 188 неопознанных объектов, обнаруженных за последние двое суток - 691 всего. Учитывая новые старлинки. Да, это хреново, не спорю, космический мусор - большая гадость. НО, замечу - еще НИ ОДИН из этих объектов не идентифицирован, как обломок "Космоса-1408". Где-то через один-два месяца, думаю, будет объективная картина.
Можете минусовать... :)
У меня один странный вопрос: если репитер глушит сигнал БС, то как он сам умудряется работать?
Зависит от квалификации установщика. При определенном опыте, сложность установки и настройки Винды и Линуха на произвольном железе - сравнимы. Если интересно - попробуй поставить "семерку", к примеру, на свой ноут с нуля. Узнаешь много интересного, обещаю. ;)
зы. привет от /37 :)