Нужно еще добавить, что в любой цивилизованной стране практика 2.1. ведет к тюрьме или к иным сопоставимым проблемам. В России тоже некоторых довела до этого.
Честно говоря, в России настолько низкие налоги для малого бизнеса, что я даже и не знаю, чего еще можно желать именно в этом плане. Может быть не стоит переживать из-за мизерных процентов, которые будут потеряны при сдаче наличных в банк?
По-моему реальные проблемы в России возникают вовсе не из-за банковских процентов и небольших налогов, а из-за криминала, из-за сложностей с получением разрешений на что-либо (произвол чиновников), из-за сложностей ведения отчетности (начиная с уровня ООО) и тому подобного. Но не из-за процентов как таковых.
Конечно я понимаю, что если бы отменить большинство существующих дурацких формальных правил и вообще подвергнуть жесточайшей ревизии банковские и налоговые системы, то людям на Земле стало бы легче жить.
Но если быть реалистами — то приходится играть по навязанным нам правилам, принимая множество досадных издержек как факт.
С Вашей логикой на счет государственных интересов я согласился — изначально я не учел, что РЖД это не обычная коммерческая организация (будь они просто коммерческой организацией им было бы выгоднее быстро получить дешевое и главное отлаженное готовое решение на базе GPS).
Первый аргумент принимается, учитывая, что железные дороги фактически полностью контролируются государством и тут обычная чисто коммерческая логика не подходит. А что касается поезда с боеголовками — то пусть лучше не доедет. :)
Зачем нужно точное знание координат более и менее понятно, но вот зачем для этого использовать именно «Глонасс», а не GPS? Чтобы поднять стоимость проекта и создать риски, связанные с неудачами в развертывании этой системы или с малым опытом коммерческой эксплуатации ее приемников? :)
Хороший редактор это не тот, который показывает хвостовые пробелы, а тот, который их удаляет автоматически при перезаписи файла и для которого во внутреннем представлении хвостовых пробелов не существует, как и табуляций.
Что касается табуляций, то существует единственная правильная их интерпретация — как выравнивание на следующую позицию, номер которой кратен восьми символам. Редактор вообще не должен интерпретировать или показывать табуляции во время работы. Он должен добавлять (или не добавлять) их автоматически при записи файла. Так как единственное их назначение – это сокращение объема файла при хранении.
Все вышедшие из дремучего прошлого unix-а форматы файлов, в которых символ табуляции является синтаксически значимым элементом по значению отличающимся от пробелов – сосут & must die!
Все не так тривиально, как может показаться на первый взгляд. Да, кто-то качает нелицензионную музыку. Но на каких основаниях провайдер мониторит трафик всех своих пользователей? Под видом борьбы с пиратством кто-то пытается установить тотальную слежку за гражданами. Поэтому большинство таких дел в самом начале можно прекратить, если достаточно четко и последовательно заявить, что все доказательства добыты преступным путем — де-факто с помощью перлюстрации персональной корреспонденции и электронной слежки. А в случае доведения дела до суда потребовать доказательств, что все логи не были умышленно подделаны, что сбор информации был санкционирован судом и так далее. Я не защищаю пиратов, но я вижу реальную опасность нарушения фундаментальных свобод под видом борьбы с пиратством. Лучше пусть украдут всю музыку мира и все фильмы, чем если мы будем жить в тоталитарном обществе.
В любом случае спасибо за интересную статью! Можно убрать накопление погрешности, это да. Но нельзя обеспечить четкую активацию в точное время с точностью до миллисекунд. Если Вы запустите Ваши программы с любым методом точных задержек параллельно с какой-нибудь ресурсо-жрущей игрушкой, то Вы увидите, что какой бы Вы не использовали метод задержки и какой бы приоритет для thread не выбрали, но время от времени будут происходить задержки в активации thread более чем на одну миллисекунду из-за свопинга или из-за того, что некоторые directx операции не прерываются ядром, и обеспечить мгновенную активацию прикладной программы для Windows в суб-миллисекундном диапазоне в общем случае невозможно.
Даже если выставить real-time приоритет для thread, то все равно из-за подкачки/откачки страниц или еще каких-то влияний ядро Windows не всегда мгновенно активирует пользовательскую программу, поэтому писать на прикладном уровне для Windows что-то зависящее от задержек в 1 миллисекунду и меньше — вообще неправильно и малореально. Как и для Linux. С такими вещами нужно или на уровне ядра работать, или использовать специализированные системы реального времени. Как минимум в Windows или в Linux нужно выключать своппинг и не запускать в параллель всякие мультимедийные программы. Но это уже превращает программу в пригодную к использованию только на выделенной машине. Вывод — не очень подходят ОС общего назначения для этого, на прикладном уровне…
Дополнительная информация:
1. На некоторых процессорах значение RDTSC может быть рассинхронизировано для разных ядер. Вы никогда не знаете, на каком именно ядре в данный момент выполняется Ваша программа (если только не выставили affinity mask, да и то, я бы не был на 100% уверен), поэтому чтение TSC процессорной командой иногда само вносит существенные искажения. В SMP системах RDTSC вообще по определению рассинхронизировано между процессорами. Поэтому думаю, что performance counters лучший метод для точных замеров времени в прикладных программах для Windows.
2. Программу для Windows не стоит писать так, чтобы она зависела от задержек в функциях типа Sleep. Если речь идет об управлении устройством в реальном времени, то нужно выносить все это в драйвер. В других случаях использовать мультимедийные функции для таймирования. А если кто-то пишет часы для desktop-а – вероятно лучше всего подойдут waitable timers.
Вообще спор был о том, что TCP с его handshake и свойством останавливать весь поток из-за потери или повреждения одного-единственного кадра уже не адекватен для большинства современных приложений. Раньше приложения были простыми и применение TCP позволяло не заморачиваясь быстро писать программы. Теперь имплементация пересылки байтов по сети составляет 1% от времени разработки приложения в целом. Поэтому пользы от той автоматизации, которую дает TCP, уже ОТНОСИТЕЛЬНО мало. А вот вносимое им принципиальное ограничение на задержку всего потока из-за единственного потерянного кадра — реально мешает быстрой загрузке страниц (например). Как и начальный handshake. Да и алгоритмы окна, алгоритм неселективных подтверждений в TCP, отсутствие ECN — все это уже устарело. Что-то улучшают совместимыми патчами, а что-то нельзя улучшить без нарушения совместимости. Поэтому было бы логичным вообще отказаться уже от массового использования TCP.
Алгоритмы масштабирования окна в стандартном TCP (понимаемом всеми операционными системами и роутерами) был придуман очень давно и морально устарел. Кое-что исправили новыми совместимыми патчами, но нельзя ведь выйти за пределы принципиальных ограничений, наложенных форматом пакета и его интерпретацией уже существующим оборудованием. А вот новые протоколы, которые реализуются поверх UDP, по определению свободны от таких ограничений, которые идут от необходимости поддерживать совместимость со всем старым железом и ОС.
В принципе для альтернативных протоколов (типа SCTP) не нужен даже UDP, они могут прекрасно работать и поверх чистого IP. Но на практике очень многие firewalls, провайдеры и т.п. убивают пакеты неизвестных им протоколов или сильно дискриминируют этот трафик. Поэтому в открытом Интернете использовать UDP надежней. В закрытых же сетях можно работать прямо поверх IP.
Если TCP работает быстрее, чем продвинутые дейтаграмм-ориентированные протоколы, то либо это плохие протоколы, либо проблема в шейпинге траффика недобросовестными провайдерами или оборудованием, которое специально отдает предпочтение TCP и дискриминирует UDP.
Если нет никакой дискриминации, то UDP в сочетании с умным протоколом работает быстрее, чем обычный TCP. Естественно речь идет о ситуации, когда часть пакетов теряется или повреждается. На идеальном канале без потерь, вариаций в задержке и искажений, «кондовый» TCP может быть быстрее — за счет поддержки на уровне ядра ОС и железа.
Тут крайне опасно высказывать мнение о том, что современная структура web ужасна. Сразу куча одминов начинает минусовать за неуважение к их любимым http-серверам, или, упаси Бог, к PHP или JS. :)
Аналогично и для web — посмотрите сколько картинок и баннеров на типичной странице — на каком-нибудь новостном сайте, например. Либо одна из них «застрянет» и все остальные не будут грузиться из-за нее, либо нужно устанавливать отдельное соединение на каждую картинку — а отдельное соединение это 1.5 rount-trip обмена в TCP handshake (SYN, SYN-ACK и ACK) плюс оно «отъедает» порт на сервере, кроме того, если нужно одну из картинок загрузить с другого сервера (заранее не известного для балансирования нагрузки), то нужно либо делать редирект, либо динамически генерировать все содержимое страницы, либо заниматься всякой фильтрацией и вмешательством в протоколы более высокого уровня.
Я не зря сказал про сигнальные протоколы. Поверх UDP делается какой-нибудь reliable datagram protocol. В идеале — даже вместо UDP, но это было бы хуже с точки зрения проникновения через современные firewalls. Использование UDP и прочих над ним навернутых протоколов без установления соединения позволяет сэкономить на паре обменов сообщениями.
Еще лет через 5 догадаются, что если выкинуть внизу TCP и заменить его на UDP, то можно ускорить еще вдвое :)
Кстати, телефонисты с VoIP signaling протоколами уже давным-давно прошли по аналогичным «граблям».
Давайте посмотрим на ФАКТЫ. В США прекрасно работает коммерческое высшее образование.
Конечно, российские «патриоты» могут рассказать Вам множество баек про «тупых америкосов», но эти байки не имеют никакого отношения к реальности. Ни одна страна в мире не добилась такого прогресса в науке и технике, как США. Не нужно далеко ходить, чтобы в этом убедиться. Подавляющее большинство всех новых технологий, которые мы обсуждаем на Хабре, созданы в США или при участии университетов или коммерческих компаний из США.
Вы зря беспокоитесь на счет финансирования. Например, если снизится количество студентов, то сократятся и затраты ВУЗа. Кроме того, спрос определяет предложение, поэтому рынок отрегулирует количество студентов в ВУЗах автоматически таким образом, чтобы ВУЗы самоокупались (если их все приватизировать). На эту тему можно было бы долго спорить, но есть работающий пример — система высшего образования в США, доказавшая свою состоятельность.
Добавлю, что человек рождается свободным, и никто не наделен правом силой заставлять его служить государству и умирать «ради интересов государства». Конечно, какие-то люди (правительство) заявляют, что будто бы они обладают такими правами. Но это ложь. Ведь люди не могут делегировать своему правительству те права, которыми они сами не обладают. Например, люди не обладают правом распоряжаться чужой жизнью и свободой, и поэтому они не могут делегировать своему правительству отсутствующее у них у самих право насильственно забирать в армию третих лиц. Значит все заявления о том, что государство (то есть чиновники) вправе заставлять людей служить в армии — это наглая ложь. Они могут придать своей лжи форму закона, но сути это не изменит.
Вы не правы, проблема и в общем призыве в том числе, так как всеобщий призыв — это грубое попрание прав человека.
Что касается американской профессиональной армии, то как ни крути, эта армия самая сильная в мире, а российская призывная – разложенная до молекул, погрязшая в тотальной дедовщине на низком уровне и в тотальной коррупции на высоком.
По-моему реальные проблемы в России возникают вовсе не из-за банковских процентов и небольших налогов, а из-за криминала, из-за сложностей с получением разрешений на что-либо (произвол чиновников), из-за сложностей ведения отчетности (начиная с уровня ООО) и тому подобного. Но не из-за процентов как таковых.
Конечно я понимаю, что если бы отменить большинство существующих дурацких формальных правил и вообще подвергнуть жесточайшей ревизии банковские и налоговые системы, то людям на Земле стало бы легче жить.
Но если быть реалистами — то приходится играть по навязанным нам правилам, принимая множество досадных издержек как факт.
Что касается табуляций, то существует единственная правильная их интерпретация — как выравнивание на следующую позицию, номер которой кратен восьми символам. Редактор вообще не должен интерпретировать или показывать табуляции во время работы. Он должен добавлять (или не добавлять) их автоматически при записи файла. Так как единственное их назначение – это сокращение объема файла при хранении.
Все вышедшие из дремучего прошлого unix-а форматы файлов, в которых символ табуляции является синтаксически значимым элементом по значению отличающимся от пробелов – сосут & must die!
1. На некоторых процессорах значение RDTSC может быть рассинхронизировано для разных ядер. Вы никогда не знаете, на каком именно ядре в данный момент выполняется Ваша программа (если только не выставили affinity mask, да и то, я бы не был на 100% уверен), поэтому чтение TSC процессорной командой иногда само вносит существенные искажения. В SMP системах RDTSC вообще по определению рассинхронизировано между процессорами. Поэтому думаю, что performance counters лучший метод для точных замеров времени в прикладных программах для Windows.
2. Программу для Windows не стоит писать так, чтобы она зависела от задержек в функциях типа Sleep. Если речь идет об управлении устройством в реальном времени, то нужно выносить все это в драйвер. В других случаях использовать мультимедийные функции для таймирования. А если кто-то пишет часы для desktop-а – вероятно лучше всего подойдут waitable timers.
В принципе для альтернативных протоколов (типа SCTP) не нужен даже UDP, они могут прекрасно работать и поверх чистого IP. Но на практике очень многие firewalls, провайдеры и т.п. убивают пакеты неизвестных им протоколов или сильно дискриминируют этот трафик. Поэтому в открытом Интернете использовать UDP надежней. В закрытых же сетях можно работать прямо поверх IP.
Если TCP работает быстрее, чем продвинутые дейтаграмм-ориентированные протоколы, то либо это плохие протоколы, либо проблема в шейпинге траффика недобросовестными провайдерами или оборудованием, которое специально отдает предпочтение TCP и дискриминирует UDP.
Если нет никакой дискриминации, то UDP в сочетании с умным протоколом работает быстрее, чем обычный TCP. Естественно речь идет о ситуации, когда часть пакетов теряется или повреждается. На идеальном канале без потерь, вариаций в задержке и искажений, «кондовый» TCP может быть быстрее — за счет поддержки на уровне ядра ОС и железа.
Кстати, телефонисты с VoIP signaling протоколами уже давным-давно прошли по аналогичным «граблям».
Конечно, российские «патриоты» могут рассказать Вам множество баек про «тупых америкосов», но эти байки не имеют никакого отношения к реальности. Ни одна страна в мире не добилась такого прогресса в науке и технике, как США. Не нужно далеко ходить, чтобы в этом убедиться. Подавляющее большинство всех новых технологий, которые мы обсуждаем на Хабре, созданы в США или при участии университетов или коммерческих компаний из США.
Что касается американской профессиональной армии, то как ни крути, эта армия самая сильная в мире, а российская призывная – разложенная до молекул, погрязшая в тотальной дедовщине на низком уровне и в тотальной коррупции на высоком.