Не ожидал увидеть такую статью на хабре, но прочитал большим с удовольствием.
Огромное спасибо за работу (за миксы и статью)!
Тоже считаю, что лучше слушать качественные миксы, а не альбомы или одинарные треки.
В свое время поставил в крон скрипт, который качает всё новьё из dnbshare.com/download/
Для разгребания тонн шлака другой скрипт, интерактивный, жаль, не нашел хорошего опенсорс софта для построения спектрограмм, была идея автоматизировать и этот процесс ))
Зато всегда есть чего послушать, даже не успею за скачкой )
Уважаемый, ну не думаете же Вы, в самом деле, что ssh клиент получит данные от sshd-сервера только когда этих данных наберется полный буффер для передачи?
Что касается DPI vs packet match — мой исходный пост как раз о том, что магистральные нагрузки не предполагают использования полноценной DPI.
А кто говорит использовать это для всех сайтов по умолчанию?
Кнопка — она кнопка и есть: видишь что сайт заблокирован — жми кнопку и заходи, пусть и медленнее обычного.
А колбасу эту складывать TCP с рождения умеет, тут волноваться нечего.
Странно, почему в браузерах до сих пор нет кнопки «пересылать http-запрос по одному байту в пакете». Не думаю, что есть DPI магистрального уровня, способные такое отловить — слишком большие скорости и нагрузки.
По ссылке http://golang.org/doc/faq#csp слово «process» встречается только в названии модели конкурентного исполнения кода
One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP
В платформе Go используется термин goroutine. Общепринятое значения термина «процесс» в программировании я Вам не буду обьяснять за отсутствием необходимости (искренне надеюсь на это).
fork() может работать на платформе Go и работает успешно, за исключением того, что goroutine-ы не могут быть перезапущены в потомке, если они заблокированы в другом треде в родителе. Технически, для шедулера Go нет проблемы перезапустить треды для горутин и возобновить в них исполнение запущеных горутин, за исключением случая, упомянутого выше. Если бы os/signal не требовал бы горутины для своей работы, либо давал возможность перезапустить её явно, то все было бы в порядке.
Прошу прощения, но то, что Вы написали выше, не соответствует действительности.
Во первых, fork() — это операция, а процесс — примитив (обьект, сущность) ОС — сравнивать их и искать разницу просто не корректно.
Во вторых, никакой процесс не имеет возможности повлиять напрямую на контекст родителя — для связи процессов можно использовать только IPC.
Если вы под «процесс» имеете ввиду «тред» — то так и пишите, будет понятно о чем дискуссия.
Исходная проблема возникла откуда — из того факта, что до фактически запуска кода программы платформа Go запустила (неявно) goroutine по обработке сигналов. Если бы не эта особенность, то и этой статьи не было бы за ненадобностью.
Если бы все именно так и было (без изменения импульса), то можно было бы построить следующий безинерционный двигатель:
— испускаем фотоны в одну сторону — получаем импульс в обратную
— фотоны отражаем обратно чудо-зеркалом без изменения его импульса
— отраженные фотоны теперь движутся в нашем направлении — поглощаем их и получаем ещё одну прибавку импульса
С другой стороны, если перейти в систему отсчета, в которой зеркало двигалось им навстречу, а после отражения фотонов — остановилось, получается — кинетическая энергия зеркала перешла к фотонам.
Вечные двигатели все ещё не патентуют? Жаль… )
Честно говоря, не понимаю, чем демонизация мешает конкурентности и наоборот.
В гугле ведь (да и не только) все конкурентные сервисы только в виде демонов и работают, поди.
fork() изначально и не задумывался как средство обеспечения конкурентности при обработке запросов, другое дело, что он худо-бедно удовлетворяет потребность в этом. Но как ни крути — без fork-а ОС не обойтись, и то, что на платформе Go есть проблемы с fork() — это конкретный недосмотр (отнюдь не умаляю преимуществ Go, сам обожаю этот язык).
Технически, Google как раз позиционирует Go как системный язык (к вопросу «делать вещи для которых он изначально не предназначался»). Поэтому я даже немного удивился, что в языке, заточенном под написание многопоточных (ок, пусть много-гороутинных ;) ) демонов возникли такие проблемы собственно с демонизацией. Скорее всего, этот момент просто упустили при проектировке, возможно исправят в какой-то версии языка, если девелоперам Go указать на эту проблему.
Хотел все то же самое написать, но не успел )
Хранилище фактов это конечно лучше, чем ничего, но без системы для их процессинга (т.е. движка ИИ) это просто набор байт.
Шифрование на эллиптических кривых основано на трудности дискретного логарифмирования. Тот самый Шор показал, что существует эффективный квантовый алгоритм для дискретного логарифирования, так что шифрование на эллиптических кривых взламывается точно так же.
Имхо, вполне правильно. Эволюция квантовой системы происходит детерминированным образом согласно уравнениям КМ (опровергнуть их пока никому не удалось, хотя и есть вопросы совместимости с ТО, например). Вопрос измерения итогового состояния (редукции) опускаем, пока нет консенсуса относительно интерпретации этой редукции — будем обходиться вероятностной, она тоже (как и уравнения КМ) может быть просчитана на классическом компе.
Так что все что нам насчитает квантовый комп (т.е. эволюция его квантового состояния) — все это может быть посчитано и на обычном компе, но (особенно для специфических квантовых алгоритмов) — гораздо медленнее.
Совершенно верно. ОС оставляет данные в файловом кеше, и последующие запросы на чтение отрабатываются мгновенно.
Последовательное чтение файлов базы данных происходит гораздо быстрее (почти на полной скорости диска, в зависимости от уровня фрагментации, т.е. около 100МБ/c), чем если бы базе пришлось бы поднимать данные постранично для каждого запроса (в этом случае все упирается в IOPS, около 150 req/s для sata-дисков, итого 300 req/s для raid1). И хотя такое кеширование (разумеется, памяти на сервере должно быть больше, чем занимают файлы базы) требует некоторого времени — в итоге оно окажется гораздо меньше того времени, которое понадобилось бы постгресу на прогрев под нагрузкой.
Крайне неэкономный подход, оправданный только в том случае, когда Вам нужно, чтобы файлы гарантированно были доступными из RAM (в общем случае для файлового кеша такой гарантии, разумеется, нет).
Вместе с тем, что в памяти будут теперь страницы, которые никогда больше не будут прочтены (просто за ненадобностью), часть страниц будет с дублированным контентом, ведь винда захочет самостоятельно прокешировать те файлы, что лежат на RAM-диске…
Подход сравним с «а давайте сделаем ram-диск для файлов базы данных, и будем время от времени делать бекапы на диск» — пока памяти вагон — то все будет работать быстро, но ведь все и так будет работать быстро, если данные будут закешированы в памяти, причем в последнем случаее даже быстрее, т.к. будет исключено двойное кеширование и оверхед на копирование страниц в страницы.
К примеру — я в rc.local держу строчку /usr/bin/tar -cf /dev/null /usr/local/pgsql
которая поднимает скорость запуска и работы pgsql до уровня, как если бы этот раздел был на RAM-диске ))
Странно, неужели было так сложно сделать систему ориентации «прямо на Солнце по максимальной яркости» вместо «сейчас посчитаю, где должно быть Солнце»
Огромное спасибо за работу (за миксы и статью)!
Тоже считаю, что лучше слушать качественные миксы, а не альбомы или одинарные треки.
В свое время поставил в крон скрипт, который качает всё новьё из dnbshare.com/download/
Для разгребания тонн шлака другой скрипт, интерактивный, жаль, не нашел хорошего опенсорс софта для построения спектрограмм, была идея автоматизировать и этот процесс ))
Зато всегда есть чего послушать, даже не успею за скачкой )
Что касается DPI vs packet match — мой исходный пост как раз о том, что магистральные нагрузки не предполагают использования полноценной DPI.
Кнопка — она кнопка и есть: видишь что сайт заблокирован — жми кнопку и заходи, пусть и медленнее обычного.
А колбасу эту складывать TCP с рождения умеет, тут волноваться нечего.
Продолжайте в том же духе, пожалуйста.
В платформе Go используется термин goroutine. Общепринятое значения термина «процесс» в программировании я Вам не буду обьяснять за отсутствием необходимости (искренне надеюсь на это).
fork() может работать на платформе Go и работает успешно, за исключением того, что goroutine-ы не могут быть перезапущены в потомке, если они заблокированы в другом треде в родителе. Технически, для шедулера Go нет проблемы перезапустить треды для горутин и возобновить в них исполнение запущеных горутин, за исключением случая, упомянутого выше. Если бы os/signal не требовал бы горутины для своей работы, либо давал возможность перезапустить её явно, то все было бы в порядке.
Во первых, fork() — это операция, а процесс — примитив (обьект, сущность) ОС — сравнивать их и искать разницу просто не корректно.
Во вторых, никакой процесс не имеет возможности повлиять напрямую на контекст родителя — для связи процессов можно использовать только IPC.
Если вы под «процесс» имеете ввиду «тред» — то так и пишите, будет понятно о чем дискуссия.
Исходная проблема возникла откуда — из того факта, что до фактически запуска кода программы платформа Go запустила (неявно) goroutine по обработке сигналов. Если бы не эта особенность, то и этой статьи не было бы за ненадобностью.
— испускаем фотоны в одну сторону — получаем импульс в обратную
— фотоны отражаем обратно чудо-зеркалом без изменения его импульса
— отраженные фотоны теперь движутся в нашем направлении — поглощаем их и получаем ещё одну прибавку импульса
Вечные двигатели все ещё не патентуют? Жаль… )
В гугле ведь (да и не только) все конкурентные сервисы только в виде демонов и работают, поди.
fork() изначально и не задумывался как средство обеспечения конкурентности при обработке запросов, другое дело, что он худо-бедно удовлетворяет потребность в этом. Но как ни крути — без fork-а ОС не обойтись, и то, что на платформе Go есть проблемы с fork() — это конкретный недосмотр (отнюдь не умаляю преимуществ Go, сам обожаю этот язык).
Хранилище фактов это конечно лучше, чем ничего, но без системы для их процессинга (т.е. движка ИИ) это просто набор байт.
Кстати, в списке 45 запрограммированных квантовых алгоритмов этот вопрос идет сразу вторым пунктом )
Так что все что нам насчитает квантовый комп (т.е. эволюция его квантового состояния) — все это может быть посчитано и на обычном компе, но (особенно для специфических квантовых алгоритмов) — гораздо медленнее.
Последовательное чтение файлов базы данных происходит гораздо быстрее (почти на полной скорости диска, в зависимости от уровня фрагментации, т.е. около 100МБ/c), чем если бы базе пришлось бы поднимать данные постранично для каждого запроса (в этом случае все упирается в IOPS, около 150 req/s для sata-дисков, итого 300 req/s для raid1). И хотя такое кеширование (разумеется, памяти на сервере должно быть больше, чем занимают файлы базы) требует некоторого времени — в итоге оно окажется гораздо меньше того времени, которое понадобилось бы постгресу на прогрев под нагрузкой.
Вместе с тем, что в памяти будут теперь страницы, которые никогда больше не будут прочтены (просто за ненадобностью), часть страниц будет с дублированным контентом, ведь винда захочет самостоятельно прокешировать те файлы, что лежат на RAM-диске…
Подход сравним с «а давайте сделаем ram-диск для файлов базы данных, и будем время от времени делать бекапы на диск» — пока памяти вагон — то все будет работать быстро, но ведь все и так будет работать быстро, если данные будут закешированы в памяти, причем в последнем случаее даже быстрее, т.к. будет исключено двойное кеширование и оверхед на копирование страниц в страницы.
К примеру — я в rc.local держу строчку
/usr/bin/tar -cf /dev/null /usr/local/pgsqlкоторая поднимает скорость запуска и работы pgsql до уровня, как если бы этот раздел был на RAM-диске ))