WirelessMAN Станислав, вы можете провести небольшой эксперимент? Открыть корпус, сфотографировать плату и способ подключения к блоку питания?
Идея очень простая — выкидываем блок питания AC-DC и подводим питание DC48 вольт на вышку. Получаем идеальные коммутатор для питания любых радиоустройств POE — 24 Вольт или 802.3af — 48 Воль.
Кстати, не мешало бы указать в заметке эту главную особенность свича — два напряжения питания.
У меня к вам вопрос — ведь функция go выполняется, как "зеленый"/софтпроцесс или это процесс на аппаратном уровне?
Гоурутины — наиболее легковестный процесс из всех других альтернативых реализаций многопоточности. Не силен в деталях, но при запуске горутины выделяется 4 кб памяти и переключаются несколько регистров. Сравните с полным переключением контекста или вообще с потоками операционной системы. В результате декларируется возможность на сервере запускать легко до 100 тысяч горутин, лишь бы памяти хватило.
На Go получится 100 процессов запустилось, первый из них, кому шедулер даст — залочит мутекс. Остальные будут ждать. Произойдет изменение данных, анлок. После этого тот какой-то (скорее всего вообще неведомо какой) из оставшихся 99 процессов, по команде шедулера продолжит работу, залочит мап, Остальные будут ждать. И так далее.
Все верно. Вопрос в том что начиная с версии 1.6 это не только работает быстро, но еще и компилятор выдаст предупреждение, если не дай бог программист не сделает блокировку разделяемые данные. Причем речь именно о хеш-масивах, с обычными массивами даже этого не потребуется, операция будет атомарна.
На Erlang получится 100 процессов запустилось и отправило сообщение процессу-хранилищу об изменении данных. Все сообщения попадут в очередь принятых сообщений процесса-хранилища.
Основная фича Go — каналы, она именно так работает, как вы рассказали на примере Эрланга, я подозреваю что даже синтаксис <- и -> от туда взят.
не буду объяснять проще дать ссылку на туториал: http://golang-book.ru/chapter-10-concurrency.html
Может быть вы посоветуете материал по Go, который стоит изучить в первую очередь?
Потратьте один вечер на эту книжку: http://golang-book.ru/
Если будет интересно, я дам в личку еще ссылок и одну полноценную книгу.
Если резюмировать про многопоточность, то в Go есть самые легкие сопроцессы, три вида работы с данными в многозадачности — каналы, мутексы, и атомарные апдейты. Кстати и системные треды вроде есть, просто они никому не нужны. Так же Го — это компилятор, а не виртуальная машина как Эрланг. И что важно, это императивный язык программирования, который понятен с первой секунды. В отличие скажем он парадигмы функционального программирования, к которой люди приходят с багажом знаний.
Тематика статьи — мы решили попробовать что-то новенькое. И вот цитата автора
Архитекторы не против попробовать и другие варианты: язык Go, один из JVM-языков, еще что-то – но пока желающие нашлись только на Elixir, и об этом ниже.
Не будь этой цитаты, никто бы не упомянул Go ни разу! Я в этом уверен, за себя ручаюсь на 100%.
каков, по вашему мнению, профессиональный уровень автора
и объем его профессионального опыта?
Я начал свой пост с благодарности автору за статью. Достаточно для оценки авторитета?
сколько лет Go и является ли сообщение о нем благой вестью,
которую вам с утра сообщил горящий терновый куст?
Сколько лет Эрлангу и является ли сообщение о нем благой вестью?
Демагогия.
насколько сильно разработчики таких проектов придают значение
комфортности обработки строк при выборе инструментария?
Не знаю какие мысли в голове у разработчиков, лучше наверно их спросить, но мне кажется одна из причин интереса к Go, это прежде всего простота и красота кода, которая в результате повышает продуктивность. Это не один и не два и не три отзыва от разработчиков на других языках. Erlang совершенно точно ценят не за простоту, вспомним хотя бы парадигму функционального программирования. Самый лучший совет от гуру Эрланга звучал так — если вы не понимаете заечем вам нужен Эрланг, значит он вам не нужен.
Потом перечитайте свой комментарий и задайте себе последний вопрос,
что вам было бы лучше:
Мне было бы лучше никогда не читать эту статью и не знать о склочности Erlang комьюнити. Я обратил внимание что хабре чрезвычайно мало информации о Go, статьи старые переводов мало. Почти всю информацию о Go я получаю из англоязычных ресурсов, немного с пары русскоязычных сайтов.
Признаюсь, что у меня даже проскочила мысль немного восполнить этот пробел и написать что то для этой аудитории. Однако, благодаря, вашей трогательной заботе, я сохранил кучу времени и нервов, а хабр не получил какой то статьи.
Спасибо вам и удачи!
Спасибо, не надо меня знакомить. Не убедили меня ни в простоте ни красоте Erlang. Но это неважно, главное что бы сами в это верили, а другой взгляд на вопрос всегда можно заминусовать до невидимости, здорово же!
Зато я познакомился с go хейтерами, узнал чего больше всего на свете боятся Эрлангеры и как функционирует сегодняшний хабр.
Я просил обновление ассоциативного массива, вы дали пример с atomic update. Просто ответьте пожалуйста, поддерживает ли storage etc ассоциативные массивы, они же hash они же map. Вы знаете ответ сразу, а мне для этого весь документ читать.
И да, ваш пример на Go будет выглядеть так:
func main() {
var ops uint64 = 0
for i := 0; i < 100; i++ {
go func() {
for {
atomic.AddUint64(&ops, 1)
runtime.Gosched()
}
}()
}
time.Sleep(time.Second)
opsFinal := atomic.LoadUint64(&ops)
Несколько месяцев назад я решил изучить какой нибудь перспективный язык для сетевых вещей. Я выбирал между Javascript/Node.js и Erlang. В итоге остановился… на Go.
Я перечитал еще раз свой комментарий. Могу заново написать каждую строчку и доказать каждое утверждение не только ссылками но и личным опытом. Но не буду!
Вместо этого я выпущу код из презентации релиза Go 1.6:
func count(n int) {
var wg sync.WaitGroup
wg.Add(n)
m := map[int]int{}
var mu sync.Mutex
for i := 1; i <= n; i++ {
go func(i int) {
for j := 0; j < i; j++ {
mu.Lock()
m[i]++
mu.Unlock()
}
wg.Done()
}(i)
}
wg.Wait()
}
Просто напишите код, который запустит n = 100 конкурентных процессов и инкрементирует единственную переменную в разделяемом ассоциативном массиве.
Хотелось бы увидеть код Erlang, Python, ну быть может даже на C++ И, да, никаких библиотек, только системные. Это вызов!
Посмотрим, считается ли булшитом и код на сегодняшнем Хабре.
Интересная статья, редкий отзыв с живым впечатлением!
Для разработки многопоточных приложений советую попробовать еще язык Go. Его синтаксис ближе всего к Pyton, так что вашим разработчикам не придется напрягаться.
Если брать пример со строками — то ка раз в Go отличная работа со строками, все нативно обрабатывается в UTF8, можете переменные на китайском или русском в коде писать, и как угодно обрабатывать строки без боли.
Я не знаю как будет восприниматься Go после Pyton, но во всяком случае в каждом отзыве пишут что скорость разработки в 10 раз быстрее чем на C/C++. Это действительно очень простой язык и комфортный.
Цена 500$ за две версии с поддержкой 48 вольт не обоснованны ничем!
За половину этих денег можно поставить гермобокс и набить его рассыпухой. Больше 8 портов наверху очень редко требуется.
4 сектора + 2 канала + 1 SFP еще и 2 порта останется
С моей точки зрения пропущен самый востребованный вариант — свич 8 портов за половину цены 16 портового.
Покупаю почти все свичи для малых баз серий ER/TS и все время какие то косяки и недоделки.
Единственный достойный вариант — ToughSwitch PoE Pro, покупаем, разбираем, выкидываем нафиг встроенный блок питания 220 вольт и включаем на питание 48 Вольт. Вот им можно питать 24/48 вольтовые железки.
Подскажите, поддерживает ли модуль при вещании в HLS или MPEG-DASH паузу на live потоках?
Насколько я понимаю сервер, то бишь искомый модуль, должен сохранять во временной директории нарезанные потоки, чтобы клиент после паузы мог начать воспроизведение с того же места.
Есть ли поддержка? На какую глубину по времени? Что в настройках модуля об этом сказано?
Если вы оказались на северном полюсе, у вас даже не ловит сигнала телефон, а вам позарез нужен интернет, то… зайдите в какое нибуь кафе и подключитесь к бесплатному интернету.
Люди спутниковый интернет ставят не потому что его любят или он дешевый, а потому что другой возможности просто нет.
Так я вам рассказываю про подход Гугла. Большинство операторов с радостью поставят ваш кэш, потому что они точно так же платят магистралу со своей стороны. Вы же покупаете новые сервера, планируете бюджет на их покупку, при этом установка серверов у оператора сокращает ваши и его операционные расходы на каналы.
Пишу я из Европы, на вашей карте сети такого места судя по всему не существует. Обидно не за уровень международного развития крупных национальных игроков, типа Яндекса или Рутуба. Обидно, что сама мысль о необходимости развития вызывает раздражение.
В статье рассказано о том как решить проблему масштабирования — вкраце, разбивать данные на блоки.
Интереснее почитать про разработку схему данных. У меня есть ощущение, что 95% всех проектов никогда не упруться в ограничение памяти для Redis, а вот модель данных станет проблемой с первой секунды проектирования.
WirelessMAN Станислав, вы можете провести небольшой эксперимент? Открыть корпус, сфотографировать плату и способ подключения к блоку питания?
Идея очень простая — выкидываем блок питания AC-DC и подводим питание DC48 вольт на вышку. Получаем идеальные коммутатор для питания любых радиоустройств POE — 24 Вольт или 802.3af — 48 Воль.
Кстати, не мешало бы указать в заметке эту главную особенность свича — два напряжения питания.
Гоурутины — наиболее легковестный процесс из всех других альтернативых реализаций многопоточности. Не силен в деталях, но при запуске горутины выделяется 4 кб памяти и переключаются несколько регистров. Сравните с полным переключением контекста или вообще с потоками операционной системы. В результате декларируется возможность на сервере запускать легко до 100 тысяч горутин, лишь бы памяти хватило.
Все верно. Вопрос в том что начиная с версии 1.6 это не только работает быстро, но еще и компилятор выдаст предупреждение, если не дай бог программист не сделает блокировку разделяемые данные. Причем речь именно о хеш-масивах, с обычными массивами даже этого не потребуется, операция будет атомарна.
Основная фича Go — каналы, она именно так работает, как вы рассказали на примере Эрланга, я подозреваю что даже синтаксис <- и -> от туда взят.
не буду объяснять проще дать ссылку на туториал: http://golang-book.ru/chapter-10-concurrency.html
Потратьте один вечер на эту книжку: http://golang-book.ru/
Если будет интересно, я дам в личку еще ссылок и одну полноценную книгу.
Если резюмировать про многопоточность, то в Go есть самые легкие сопроцессы, три вида работы с данными в многозадачности — каналы, мутексы, и атомарные апдейты. Кстати и системные треды вроде есть, просто они никому не нужны. Так же Го — это компилятор, а не виртуальная машина как Эрланг. И что важно, это императивный язык программирования, который понятен с первой секунды. В отличие скажем он парадигмы функционального программирования, к которой люди приходят с багажом знаний.
Тематика статьи — мы решили попробовать что-то новенькое. И вот цитата автора
Не будь этой цитаты, никто бы не упомянул Go ни разу! Я в этом уверен, за себя ручаюсь на 100%.
Я начал свой пост с благодарности автору за статью. Достаточно для оценки авторитета?
Сколько лет Эрлангу и является ли сообщение о нем благой вестью?
Не знаю какие мысли в голове у разработчиков, лучше наверно их спросить, но мне кажется одна из причин интереса к Go, это прежде всего простота и красота кода, которая в результате повышает продуктивность. Это не один и не два и не три отзыва от разработчиков на других языках. Erlang совершенно точно ценят не за простоту, вспомним хотя бы парадигму функционального программирования. Самый лучший совет от гуру Эрланга звучал так — если вы не понимаете заечем вам нужен Эрланг, значит он вам не нужен.
Мне было бы лучше никогда не читать эту статью и не знать о склочности Erlang комьюнити. Я обратил внимание что хабре чрезвычайно мало информации о Go, статьи старые переводов мало. Почти всю информацию о Go я получаю из англоязычных ресурсов, немного с пары русскоязычных сайтов.
Признаюсь, что у меня даже проскочила мысль немного восполнить этот пробел и написать что то для этой аудитории. Однако, благодаря, вашей трогательной заботе, я сохранил кучу времени и нервов, а хабр не получил какой то статьи.
Спасибо вам и удачи!
Зато я познакомился с go хейтерами, узнал чего больше всего на свете боятся Эрлангеры и как функционирует сегодняшний хабр.
Это был очень полезный опыт, спасибо друзья!
И да, ваш пример на Go будет выглядеть так:
Я перечитал еще раз свой комментарий. Могу заново написать каждую строчку и доказать каждое утверждение не только ссылками но и личным опытом. Но не буду!
Вместо этого я выпущу код из презентации релиза Go 1.6:
Просто напишите код, который запустит n = 100 конкурентных процессов и инкрементирует единственную переменную в разделяемом ассоциативном массиве.
Хотелось бы увидеть код Erlang, Python, ну быть может даже на C++ И, да, никаких библиотек, только системные. Это вызов!
Посмотрим, считается ли булшитом и код на сегодняшнем Хабре.
Тут больше не принято уважать чужое мнение или это топик Go-хейтеров?
Для разработки многопоточных приложений советую попробовать еще язык Go. Его синтаксис ближе всего к Pyton, так что вашим разработчикам не придется напрягаться.
Если брать пример со строками — то ка раз в Go отличная работа со строками, все нативно обрабатывается в UTF8, можете переменные на китайском или русском в коде писать, и как угодно обрабатывать строки без боли.
Я не знаю как будет восприниматься Go после Pyton, но во всяком случае в каждом отзыве пишут что скорость разработки в 10 раз быстрее чем на C/C++. Это действительно очень простой язык и комфортный.
Я бы его сегодня сделал учебным в школах.
За половину этих денег можно поставить гермобокс и набить его рассыпухой. Больше 8 портов наверху очень редко требуется.
4 сектора + 2 канала + 1 SFP еще и 2 порта останется
С моей точки зрения пропущен самый востребованный вариант — свич 8 портов за половину цены 16 портового.
Покупаю почти все свичи для малых баз серий ER/TS и все время какие то косяки и недоделки.
Единственный достойный вариант — ToughSwitch PoE Pro, покупаем, разбираем, выкидываем нафиг встроенный блок питания 220 вольт и включаем на питание 48 Вольт. Вот им можно питать 24/48 вольтовые железки.
Жаль, что с выходом EP ничего не изменилось :(
Насколько я понимаю сервер, то бишь искомый модуль, должен сохранять во временной директории нарезанные потоки, чтобы клиент после паузы мог начать воспроизведение с того же места.
Есть ли поддержка? На какую глубину по времени? Что в настройках модуля об этом сказано?
Скажите, не было ли возможности или желания проверить как работает DVBlast?
www.videolan.org/projects/dvblast.html
Если вы оказались на северном полюсе, у вас даже не ловит сигнала телефон, а вам позарез нужен интернет, то… зайдите в какое нибуь кафе и подключитесь к бесплатному интернету.
Люди спутниковый интернет ставят не потому что его любят или он дешевый, а потому что другой возможности просто нет.
Интереснее почитать про разработку схему данных. У меня есть ощущение, что 95% всех проектов никогда не упруться в ограничение памяти для Redis, а вот модель данных станет проблемой с первой секунды проектирования.