Предполагаю что мусор ввиду меньшей площади тормозится слабее МКС, а также что на место упавшего приходит новое от свежих запусков или старое с более высоких орбит. В статье про станцию на википедии есть раздел про мусор.
Но вообще МКС — это просто пример, любых спутников это касается в той же мере. Площадь спутника меньше, но спутников и больше, так что столкновения, если их специально не избегать — не вопрос «если» а вопрос «когда», и риск здесь — не потеря аппарата-двух, а угроза серьёзно загадить орбиту.
Вы забываете что космические аппараты не висят на месте. Скажем, МКС согласно википедии прошла ~3.79e12 м. Площадь только её солнечных батарей, согласно раскопаному в сети — 842 м², значит она уже прочесала ими ~3.2e15 м³ пространства. Величина того же порядка что ваши 8e15 м³ с кружкой.
Вообще-то, да — я думаю что каждый. У нас пока, к сожалению, не Европа, и даже в Москве во дворах шанс не найти в прямой видимости мусорный бак весьма велик, а шариться с какой-нибудь липкой обёрткой в руке — удовольствия мало, когда можно было бы ткнуть второй рукой в мобильник и обнаружить что можно зайти 20 метров вон за тот дом и всё спокойно выкинуть. Это не говоря о случаях когда вы на машине везёте полный багажник мусора с пикника, а надо его освободить потому что нужно срочно ещё что-то купить.
На самом деле реплики типа вашей, увы, часто звучат в проектах crowdsource картографии, в том числе и у нас в OpenStreetMap. Однако практика однозначно показала что всё, над чем в начале смеются и доказывают что «это не нужно на карте» кому-то когда-то обязательно надобится, на этой информации делают крутейшие сервисы, а недальновидным товарищам остаётся только прикусить язык. Кто-то не понимал зачем рисовать тротуары — потом внезапно оказалось что есть пешеходный роутинг, который не очень-то работает по автомобильному графу, а с тротуарами получается сказка. Кто-то не понимал зачем проставлять этажность и высоту у зданий, пока не появились 3D рендеры типа glosm и F4. Кто-то выпучивал глаза на схемы indoor маппинга — внезапно у google появился роутинг внутри зданий (в OSM оно, к сожалению, пока не взлетело). Зато где-то в целом городе пожарные занесли в базу каждый гидрант со всеми характеристиками (диаметр, давление и т.д.) и, видимо, успешно используют эти данные в работе. Где-то аналогично поступили сельские электрики (все столбы и опоры ЛЭП с номерами, линии, трансформаторы, напряжение и т.д.).
Так что теперь новичкам, которые не понимают зачем рисовать канализационные люки, поребрики, подъезды с номерами квартир, железнодорожные стрелки и светофоры, скамейки, отдельные деревья с видовой принадлежностью, муравейники, бобровые запруды и всё остальное что умеет OSM предлагают либо проявить фантазию и самостоятельно предположить как и кому это понадобится, либо, при отсутствии оной, отдать практическую демонстрацию на откуп времени.
Применительно к OSM, не забывайте об addr:place — туда вместо addr:street пишутся адреса не привязанные к линейным объектам (улицам), т.е., например, деревни и районы. Таких адресов в России довольно много. Так-же, по-хорошему, должны обозначаться адреса в Зеленограде.
если не получилось (нет пробела) — то к чертям все это не улица с домом
«Ленина,11»
if LastSpace < (len([]rune(str)) — 6) {
«11стр123»
case char_count > int_count: { result -= MARK_STEP }
«2корп2»
ILIKE $1 ", "%"+name+"%"
Это будет очень плохо работать — в OSM названия улиц приведены к одному полному виду («улица Ленина»), пользователь же может ввести статусную часть с другой стороны или с сокращением (Ленина улица, ул.Ленина) и в addr:street это не найдётся. Также всё сломается если пользователь допустит пробел в номере дома («11 корп 2» — «11 корп» будет отнесено к улице и также не найдётся ILIKE'ом).
\«addr:housenumber\» ILIKE $2"
А это, в случае когда в номере дома есть корпус/строение — ещё хуже. Пользователь может ввести «1Ас1», «1АС1», «1А стр1», «1А стр. 1», в OSM же будет только что-то одно (принято 1Ас1, но за этим никто особо не следит, так что возможны варианты).
ИМХО, алгоритм состоит из слабо обоснованной эвристики и в целом имеет низкую эффективность. Я, к сожалению, с разбором адресов пока не сталкивался, но руководствовался бы следующими соображениями:
1) Номер дома состоит из ограниченного набора токенов (\d+[: русская буква:]?, /, с\.?, к\.?, стр\.?, корп\.? и ещё немного редких), и, скорее всего, выделяется не слишком монструозной регуляркой (особенно если мы ожидаем его в фиксированной позиции — в конце строки).
2) Улицу можно выделить по словарю — у вас так и делается, но не учитывается всё богатство вариаций.
Я меня есть проект который как раз используется для приведения названий улиц в OSM к единому стилю (Ленина ул -> улица Ленина) (про который я обещал написать пост, но руки никак не дойдут). Его работа основана на приведении названий улиц к виду, инвариантному относительно встречающихся изменений в написании (сюда входит различное написание статусной части как-то «переулок», «пер.», «пер-к», регистр и порядок слов), таким образом и «пер-к. Ульянова» и «УЛЬЯНОВА ПЕРЕУЛОК» и «пер ульянова» будут приведены к одной и той же строке («переулок ульянова») по которой можно понять что это одно название и найти для него в словаре полное и правильное написание, причём за O(1) (а также определить что в названии отсутствует статусная часть и даже найти название с заданным количеством опечаток используя нечёткий поиск).
Но для вашего случая можно всё сильно упростить: просто взять все названия из OSM, разбить по словам, привести к нижнему регистру, добавить того чего нет в OSM но может ввести пользователь (сокращения статусных частей, «им.», «имени»), запихнуть в словарь (даже база для этого не нужна, он будет занимать единицы мегабайт), и искать в нём каждое слово из запроса.
Итого, выкусываем регуляркой как можно более длинный номер дома справа, то что осталось разбиваем по словам и ищем каждое в словаре — при достаточном совпадении считаем улицей и всё вместе — адресом. Если хочется дополнительно проверить его на существование в OSM, то и его и OSM нужно будет приводить к одному виду как описано выше. Номер дома, как было сказано, тоже.
Кстати, хороший вопрос. Нет, «лично про себя» я тоже могу рассказать почему никогда не куплю телефон ни на одной из приведённых систем и что кроме N900 мобильных устройств которыми можно пользоваться не было выпущено вовсе, но на одних гиках же разработку не окупить, а минусы для широкого рынка новая платформа определённо будет иметь — хотя бы отсутствие под неё популярных приложений.
А полей ввода там нигде не было? А то вспоминается классика с терминалами оплаты где можно было в качестве имени ввести <a href="..., нажать на ссылку и получить браузер (позднее это «починили» традиционно кривым образом так что при нажатии на ссылку терминал блокировался и показывал сообщение об ошибке до, скорее всего, перезагрузки).
> обычные оптические кабели в их минеральном масле работать скорее всего не смогут, по какой причине увы не указано, видимо масло аггресивно для них
Скорее всего банальнее — значение критического угла полного отражения сильно различается для границ сред волокно-воздух и волокно-масло. Так как масло намного плотнее, свет просто перестаёт отражаться от стенок волокна. Это, разумеется, при условии что на волокне отсутствует оболочка либо она негерметична.
Пока речь об обычном железе. С массовым распространением масляного, очевидно, и масляных ДЦ/колокейшонов появится больше, так что проблема потеряет остроту.
Масло водой? Сомнительно. Под напором? Опасно. Нужно учитывать что нужно кропотливо промыть подо всеми деталями, не повредив их. Также вода намного агрессивнее к электронным компонентам, а дистилированная быстро перестанет быть таковой набрав солей из самой же платы, как было сказано habrahabr.ru/company/ua-hosting/blog/222669/#comment_7583537. Получается дорого и хлопотно.
А что делать при массовой модернизации железа? Обычное можно было сбыть по дешёвке — это выгодно как старым хозяевам, т.к. возвращается часть затрат, так и новым, которые получают железо дешевле. А теперь, если в масляном ДЦ старое железо никому не пригодится — получается, только на цветмет?
Я правильно понимаю что однажды погруженное в масло железо становится, по сути, непригодным для использования на воздухе? Мне представляется что оно начинает всё пачкать этим маслом, а на остатки оного на платах быстро налипнет пыль ещё сильнее затруднив теплоотдачу.
С ужасом ждал Australis, но не думал что станет настолько неудобно. Classic Theme Restorer конечно must have, но и после него осталась одна неприятная штука: в отличие от других панелей, tab bar имеет выпуклые края, совершенно не вписывается в общий стиль и вкладки (любых типов из ассортимента Classic Theme Restorer) располагаются на нём криво. Это исправляется следующим css (нужно поместить в <директория профиля>/chrome/userChrome.css):
-moz-appearance выключает выпуклость, а height нужен для того чтобы «pinned» и обычные вкладки имели одинаковую высоту (у pinned вкладок она фиксирована, у обычных соответствует высоте панели, поэтому pinned по умолчанию вылезают на несколько пикселей за панель).
По мне так убрать наиболее часто используемый элемент (вкладки) в самую даль — это распасатсья в непрофессионализме, а интерфейс хрома вцелом был продиктован исключительно идеей оригинальности (ибо браузер с традиционным интерфейсом обыватель попробует с гораздо меньшей вероятностью) в ущерб юзабилити, а Mozilla глупейшим образом повелась потеряв и в том и в другом.
Учитывая как много людей думают что bash == sh и оный есть на любой системе, статью неплохо было бы начать с ремарки о том что большая часть указанных возможностей являются bash-специфичными расширениями над POSIX shell, в народе называется башизмами и избегается в кросс-платформенных скриптах. Самые часто встречающиеся башизмы — собственно #!/bin/bash вместо #!/bin/sh и, пожалуй, [[ foo == bar ]] вместо [ foo = bar ].
Что же до собственно статьи, в первой секции обязательно нужно добавить про set -o pipefail и про особенности генерации статусов завершения конвееров. Если в двух словах
Кстати, действительно интересно насколько вероятно получить исходники классических игр если попросить.
К слову, я не помню как мы получили исходники Вангеров — если ты помнишь я думаю это неплохая тема для возможно даже поста.
И что здесь плохого? Количество пользователей — не самоцель, самоцель — эффективность и возможности софта. От количества пользователей эти характеристики никак не повысятся. Это сильно утрировано, но мысль должна быть понятна.
на другой стороне поменять местами адреса в обеих парах.
Ещё можно gre0 заменять на gif0 — вместо GRE будет IP-IP инкапсуляция (к слову о провайдерах блокирующих GRE).
Но вообще МКС — это просто пример, любых спутников это касается в той же мере. Площадь спутника меньше, но спутников и больше, так что столкновения, если их специально не избегать — не вопрос «если» а вопрос «когда», и риск здесь — не потеря аппарата-двух, а угроза серьёзно загадить орбиту.
На самом деле реплики типа вашей, увы, часто звучат в проектах crowdsource картографии, в том числе и у нас в OpenStreetMap. Однако практика однозначно показала что всё, над чем в начале смеются и доказывают что «это не нужно на карте» кому-то когда-то обязательно надобится, на этой информации делают крутейшие сервисы, а недальновидным товарищам остаётся только прикусить язык. Кто-то не понимал зачем рисовать тротуары — потом внезапно оказалось что есть пешеходный роутинг, который не очень-то работает по автомобильному графу, а с тротуарами получается сказка. Кто-то не понимал зачем проставлять этажность и высоту у зданий, пока не появились 3D рендеры типа glosm и F4. Кто-то выпучивал глаза на схемы indoor маппинга — внезапно у google появился роутинг внутри зданий (в OSM оно, к сожалению, пока не взлетело). Зато где-то в целом городе пожарные занесли в базу каждый гидрант со всеми характеристиками (диаметр, давление и т.д.) и, видимо, успешно используют эти данные в работе. Где-то аналогично поступили сельские электрики (все столбы и опоры ЛЭП с номерами, линии, трансформаторы, напряжение и т.д.).
Так что теперь новичкам, которые не понимают зачем рисовать канализационные люки, поребрики, подъезды с номерами квартир, железнодорожные стрелки и светофоры, скамейки, отдельные деревья с видовой принадлежностью, муравейники, бобровые запруды и всё остальное что умеет OSM предлагают либо проявить фантазию и самостоятельно предположить как и кому это понадобится, либо, при отсутствии оной, отдать практическую демонстрацию на откуп времени.
«Ленина,11»
«11стр123»
«2корп2»
Это будет очень плохо работать — в OSM названия улиц приведены к одному полному виду («улица Ленина»), пользователь же может ввести статусную часть с другой стороны или с сокращением (Ленина улица, ул.Ленина) и в addr:street это не найдётся. Также всё сломается если пользователь допустит пробел в номере дома («11 корп 2» — «11 корп» будет отнесено к улице и также не найдётся ILIKE'ом).
А это, в случае когда в номере дома есть корпус/строение — ещё хуже. Пользователь может ввести «1Ас1», «1АС1», «1А стр1», «1А стр. 1», в OSM же будет только что-то одно (принято 1Ас1, но за этим никто особо не следит, так что возможны варианты).
ИМХО, алгоритм состоит из слабо обоснованной эвристики и в целом имеет низкую эффективность. Я, к сожалению, с разбором адресов пока не сталкивался, но руководствовался бы следующими соображениями:
1) Номер дома состоит из ограниченного набора токенов (\d+[: русская буква:]?, /, с\.?, к\.?, стр\.?, корп\.? и ещё немного редких), и, скорее всего, выделяется не слишком монструозной регуляркой (особенно если мы ожидаем его в фиксированной позиции — в конце строки).
2) Улицу можно выделить по словарю — у вас так и делается, но не учитывается всё богатство вариаций.
Я меня есть проект который как раз используется для приведения названий улиц в OSM к единому стилю (Ленина ул -> улица Ленина) (про который я обещал написать пост, но руки никак не дойдут). Его работа основана на приведении названий улиц к виду, инвариантному относительно встречающихся изменений в написании (сюда входит различное написание статусной части как-то «переулок», «пер.», «пер-к», регистр и порядок слов), таким образом и «пер-к. Ульянова» и «УЛЬЯНОВА ПЕРЕУЛОК» и «пер ульянова» будут приведены к одной и той же строке («переулок ульянова») по которой можно понять что это одно название и найти для него в словаре полное и правильное написание, причём за O(1) (а также определить что в названии отсутствует статусная часть и даже найти название с заданным количеством опечаток используя нечёткий поиск).
Проект тут, если интересно.
Но для вашего случая можно всё сильно упростить: просто взять все названия из OSM, разбить по словам, привести к нижнему регистру, добавить того чего нет в OSM но может ввести пользователь (сокращения статусных частей, «им.», «имени»), запихнуть в словарь (даже база для этого не нужна, он будет занимать единицы мегабайт), и искать в нём каждое слово из запроса.
Итого, выкусываем регуляркой как можно более длинный номер дома справа, то что осталось разбиваем по словам и ищем каждое в словаре — при достаточном совпадении считаем улицей и всё вместе — адресом. Если хочется дополнительно проверить его на существование в OSM, то и его и OSM нужно будет приводить к одному виду как описано выше. Номер дома, как было сказано, тоже.
При реальном перенаселении, в условии голода и войн за территорию и ресурсы не кончатся. Но остальное верно.
Скорее всего банальнее — значение критического угла полного отражения сильно различается для границ сред волокно-воздух и волокно-масло. Так как масло намного плотнее, свет просто перестаёт отражаться от стенок волокна. Это, разумеется, при условии что на волокне отсутствует оболочка либо она негерметична.
-moz-appearance выключает выпуклость, а height нужен для того чтобы «pinned» и обычные вкладки имели одинаковую высоту (у pinned вкладок она фиксирована, у обычных соответствует высоте панели, поэтому pinned по умолчанию вылезают на несколько пикселей за панель).
Почему вы так решили?
По мне так убрать наиболее часто используемый элемент (вкладки) в самую даль — это распасатсья в непрофессионализме, а интерфейс хрома вцелом был продиктован исключительно идеей оригинальности (ибо браузер с традиционным интерфейсом обыватель попробует с гораздо меньшей вероятностью) в ущерб юзабилити, а Mozilla глупейшим образом повелась потеряв и в том и в другом.
Что же до собственно статьи, в первой секции обязательно нужно добавить про set -o pipefail и про особенности генерации статусов завершения конвееров. Если в двух словах
К слову, я не помню как мы получили исходники Вангеров — если ты помнишь я думаю это неплохая тема для возможно даже поста.