большая чапсть сетевого на чем угодно вызывает уныние

в JS насколько мне известно нет интов, только float64 (a.k.a. "number")

1<<31 -2147483648 1<<32 1

Вот интересно, я как раз хочу написать нормальный dhcpd сервер на go

хорошая идея

Нас C++ написаны монструозные продукты, которые разрослись и не понимаемы. Сетевые демоны на C++ невозможно понять средним умос

А на Go пишется что то вменяемое быстрое

Например wireguard vs strongswan и прочий ipsec

у wg же только userspace имплементации на go. А вообще сишечка

(1e+256) == (1e+256+1) true

А эти числа не выходят за максимальный инт?

В крипте тоже видно распределение в проектах, которые поддерживают несколько реализаций

А эти числа не выходят за максимальный инт?

браузер отображает их оба как 1е+256, когда выходит за пределы - Infinite

более того, я могу разделить эту бурду на 100

c++ отстает из-за сложности, питон - медленный, node.s - корявый. Остальные реализаци на других языках - экзотика.

c++ отстает из-за сложности, питон - медленный, node.s - корявый. Остальные реализаци на других языках - экзотика.

а как же кефир?

и хаскель-дрочеры, которые в топе по капитализации

не туда пишешь?

обсуждают языки опять

Я бы хотел посмотреть на хороший сетевой код на go

большая чапсть сетевого на чем угодно вызывает уныние

Это тоже верно :(

Например wireguard vs strongswan и прочий ipsec

Ну как бы ipsec простой, в отличие от всякого iked

Я в реальной жизни отказываюсь от использования ipsec в пользу OpenVPN. Глюков меньше и стабильность выше по итогу.

а я перешел на wireguard и выжал 100% из своего канала

Но wireguard просто песня по сравнению с обоими. И этот тот случай когда парадигма простоты и минимализма лежащая в основе языка порождает результат и в готовом творении

On Linux I measured the system call getuid(2), to take 87.77 ns and 201 CPU-cycles (TSC measurement) (the CPU efficiency were 1.42 insns per cycle, measured with perf stat). Thus, the syscall itself eats up the entire budget. Update: Most of the syscall overhead comes from kernel option CONFIG_AUDITSYSCALL, without it, the syscall overhead drops to 41.85 ns

Нас C++ написаны монструозные продукты, которые разрослись и не понимаемы. Сетевые демоны на C++ невозможно понять средним умос

должен ли я это принимать как комплимент моему уму?

должен ли я это принимать как комплимент моему уму?

Конечно

есть ли смысл указывать read timeout/deadline TCP сокету?

Конечно

монструозность проектов - это не к с++. это к людям

есть ли смысл указывать read timeout/deadline TCP сокету?

часто есть

более того, одна из проблем го в том, что в стандартном сахарке эти таймауты зачастую ненастраиваемы

есть ли смысл указывать read timeout/deadline TCP сокету?

Всегда

Кто бы сраный squid переписал

Очень в опенсоре не хватает годного прокси с митмом помимо сквида. А то в нем программирование на конфигах, при том очень медленное

Мужики вечер добрый

Хотел у вас узнать в какую сторону капать, для того что бы сделать анализ текста для получения суть этого самого текста.

Всегда

какой?)

Хотелось бы анализировать статьи и получить ее суть, а не 70% воды

Прошу хотя бы направить меня в нужное русло

Прошу хотя бы направить меня в нужное русло

Ща модно нейронки

Кто бы сраный squid переписал

а вам что от сквида надо? goproxy вполне ок

Ща модно нейронки

Это то что модно, а то что работает реально ?

а вам что от сквида надо? goproxy вполне ок

Да по сути проксю и митм

Смотрел да

Ща модно нейронки

А как такой анализ называется хотя бы ?

Я просто умничаю ?

А вообще это очень серьезная работа

Я просто умничаю ?

Понял, надеюсь будет ответ. А то я даже инфу не знаю как искать по этой теме

Тебе нужны гуманитарии для этой работы, как ни странно

а вам что от сквида надо? goproxy вполне ок

В идеале ещё на нетмапе это все завести . Сквид очень взрослый проект, много фич типа icap , так просто не перейдешь с него. Уже все отлажено, а вот в новом и передовом goproxy по любому будут нехданчики

Даёшь прокси на ebpf

Или даже наоборот, на юзерспейсном tcp-стеке

Будет супербыстрый

Эт точно

Хотел у вас узнать в какую сторону капать, для того что бы сделать анализ текста для получения суть этого самого текста.

В сторону питона, pymorphy2, nltk и gensim

И немного elasticsearch

Или даже наоборот, на юзерспейсном tcp-стеке

Да тестили, реальне в 8-10 раз быстрее, но потенциально много придётся реализовывать

Будет супербыстрый

Я в канал упираюсь, а не в проц

Да тестили, реальне в 8-10 раз быстрее, но потенциально много придётся реализовывать

Ну, готовое тоже частично есть. Главная проблема до сих пор - выделение целой отдельной сетевухи

Сквиду сколько лет 10 где-то, и все грабли придётся собирать самим

Ну, готовое тоже частично есть. Главная проблема до сих пор - выделение целой отдельной сетевухи

У нас это не проблема

Сквиду 25 минимум. Я его в начале 90-х юзал во всю

Сквиду 25 минимум. Я его в начале 90-х юзал во всю

А ну вот темболее. На порядок ошибся ))))

Я в канал упираюсь, а не в проц

А как ты измеришь скорость канала в обход ядра?

На свитче

А как ты измеришь скорость канала в обход ядра?

Netmap вам в помощь

Понял, надеюсь будет ответ. А то я даже инфу не знаю как искать по этой теме

Погуглите 'семантический веб', почитайте про ашмановский сервис 'Тургенев'...

Погуглите 'семантический веб', почитайте про ашмановский сервис 'Тургенев'...

Спасибо, буду изучать

Netmap вам в помощь

Ну разве что так

На свитче

На свиче, типа, не юникслайк?

Обычно нет

Свитчует там fpga, и она же репортит

Я всегда думал, что в основе цисковской айоси модифицированное никсовое ядро

Свитчует там fpga, и она же репортит

А, ну при таком раскладе да

Я всегда думал, что в основе цисковской айоси модифицированное никсовое ядро

Да, но на нем только управление

Свитчует там fpga, и она же репортит

Тогда норм, давно облизываемся на фпга

Да, но на нем только управление

То есть весь стек роутинга чисто аппаратный на каком-нибудь верилоге?

Круто

Хочу себе fpga

Хочу себе fpga

Его надо уметь готовить.

Его надо уметь готовить.

Читать доки вроде умею

ооп должно отвечать минимально этим требованиям а не содержать одну из вариаций)

оч мило, только никто не скажет точно что такое ооп

Читать доки вроде умею

Тогда гуд

Там очень много нюансов

Плохо, кстати. Профнепригодность...

Toml исправляет некоторые недостатки yaml. Yaml сейчас мейнстрим, так что и toml должен был хоть раз встретиться

Потому что это дефолтный формат для описания зависимостей для го в dep? Но не только

Потому что это дефолтный формат для описания зависимостей для го в dep? Но не только

Модули не понравились сообществу?)

Модули не понравились сообществу?)

А что, они уже не в альфа-версии и в проде?

В проде, в экспериментах

Мне томл показался каким-то неудобным. Но благо вайпер и кобра поддерживают сразу много форматов на любой вкус

Я вот так и не нашел отличий от yaml

может кто по докеру подсказать? чет совсем застрял, не пойму что не так FROM golang as builder COPY . $GOPATH/src/myserivce WORKDIR $GOPATH/src/myserivce/ RUN go build -o app . FROM golang:alpine COPY --from=builder /go/src/myserivce/app . ENTRYPOINT ["./app"] при попытке docker run говорит exec user process caused "no such file or directory" хотя в golang:alpine мой бинарник вроде попадает..

./ У вас отличается, наверное

может кто по докеру подсказать? чет совсем застрял, не пойму что не так FROM golang as builder COPY . $GOPATH/src/myserivce WORKDIR $GOPATH/src/myserivce/ RUN go build -o app . FROM golang:alpine COPY --from=builder /go/src/myserivce/app . ENTRYPOINT ["./app"] при попытке docker run говорит exec user process caused "no such file or directory" хотя в golang:alpine мой бинарник вроде попадает..

билдишь убунтой, запускаешь алпайном