Раньше был Scaleway, который предоставлял dedicated ARM64, но они отказались из-за низкой надёжности. Где хостинги а ля Hetzner/Scaleway для ARM? Apple M1 даже найти уже намного легче (тот же Hetzner), чем Linux/aarch64.
В итоге остаётся только Amazon с их собственными Graviton, которые не сильно отличаются от того, что предлагает AMD, ну ещё и Oracle Cloud. Ещё есть куча китайских облаков, но там причина движения в сторону арма понятна, это отвязка от интела.
Для меня отсутствие предложений является хорошим индикатором, что нужно это мало кому. Даже на гитхабе приходится делать self-hosted раннеры, чтобы тестировать код на ARM64. На днях вот специально поднимал в оракловом облаке для опенсорс проектов.
Описание API будет чуть позже, я как раз разбираюсь с тем, как правильно работать с обновлениями.
Будет отдельная статья про это, в том числе про повторную отправку, систему диспетчеризации обновлений, ack-и, пинги, параллельные соединения их их пулинг, скачивание и загрузку файлов, соединения к CDN и т.д.
Чем дальше, тем больше будет упор на описание специфики Telegram.
Первоначально я действительно не тестировал на tmpfs, полагая, что файл целиком уместился в кеше. Сейчас специально сделал на tmpfs, результаты аналогичные:
$ time ./wc /tmp/space/test.txt
15000001 44774631 1841822210 /tmp/space/test.txt
real 0m2,842s
user 0m2,784s
sys 0m0,395s
$ time LANG=C LC_ALL=C wc /tmp/space/test.txt
15000000 44774631 1871822210 /tmp/space/test.txt
real 0m4,447s
user 0m4,226s
sys 0m0,209s
$ df -h | grep /tmp
tmpfs 3,0G 1,8G 1,3G 59% /tmp/space
А еще я сейчас заметил, что у моего варианта отличается и количество characters от вывода wc, наверное, где-то у меня ошибка или это те самые непечатные символы.
Я успел прочитать сообщение до редактирования и поэтому отвечу: я запускал тесты несколько раз, убедившись, что файл в кеше и программы находятся хотя бы примерно в одинаковых условиях.
Ну и я не ставил себе целью произвести абсолютно точные измерения, очевидно, что wc делает больше работы, да и ресурсов потребляет меньше (гошный рантайм ест несколько мегабайт + bufio.Scanner имеет довольно большой максимальный буфер). Ни в коем случае не хочу сказать что-то вроде "го побеждает си в 20 строчек".
Даже очень наивная реализация на го оказывается быстрее wc (скорее всего из-за буферизации или еще каких срезанных углов):
package main
import (
"bufio"
"fmt"
"os"
"flag"
"strings"
)
func main() {
flag.Parse()
file, err := os.Open(flag.Arg(0))
if err != nil {
panic(err)
}
scanner := bufio.NewScanner(file)
var lines, words, characters int
for scanner.Scan() {
lines++
line := scanner.Text()
characters += len(line)
words += len(strings.Split(line, " "))
}
fmt.Printf("%10d %10d %10d %s\n", lines, words, characters, file.Name())
}
$ time ./wc test.txt
15000001 44774631 1841822210 test.txt
real 0m2,897s
user 0m2,873s
sys 0m0,492s
$ time LANG=C LC_ALL=C wc test.txt
15000000 44774631 1871822210 test.txt
real 0m4,419s
user 0m4,196s
sys 0m0,213s
Откуда-то взялась лишняя строчка, но мне не интересно в этом разбираться, как и дальше оптимизировать этот код.
При этом мы честно поддерживаем юникод, программа переносима и кросс-компилируется в нативные статические бинари на все поддерживаемые платформы одной командой.
Прокси сохраняет значение в sum.golang.org, который по сути дерево Меркла, и сейчас там изменить хеш версии невозможно. Зато можно криптографически проверить все изменения версий :) Кстати, это всё работает по умолчанию в гошном тулинге начиная с версии 1.13, дополнительно устанавливать ничего не нужно.
удалить пакет из прокси
В общем случае невозможно, только если вручную мейнтейнером прокси в очень исключительных случаях.
UPD: забыл сказать, сам пакет прокси тоже хранит вечно, т.е. если даже удалить репо из гитхаба, пакет останется.
Не получится, там всё очень жестко.
Т.е. если вы задеплоили пакет v1.0.1 (по сути сделав git tag v1.0.1), то изменить или удалить его невозможно. Да и деплой происходит не явно, никто в прокси ничего не пушит, просто тегают новую версию в системе контроля версий и всё автоматически подтягивается при первой загрузке.
Вывезет, если это будет просто signaling, а трафик станет ходить по WebRTC. Сейчас ничего не мешает сделать эффектный peer-to-peer хостинг, все технологии есть, нужно просто правильно их собрать.
И чем больше людей одновременно смотрят одно видео, тем эффективнее эта система работает – да пусть хоть миллиард человек смотрит, будут просто тянуть кусочки видео друг от друга.
Но если такая альтернатива появится и станет сколько нибудь популярной, гугл начнет саботировать её, ведь он владеет самым популярным браузером на планете – достаточно всего лишь тихо испортить ICE механизм для этой платформы и всё. Даже если это обнаружат, гугл просто скажет "ой, это был баг" и выпустит новый "баг" через пару недель.
накрутка на товар все равно есть, независимо чем платить
Я не был бы так уверен в этом. Например, я заметил, что ритейлеры предлагают цену меньше, если из способов оплаты только наличка. Думаю, что это как раз из-за эквайринга.
Я думаю вы неправы, кредитки в основном бесплатны для пользователей
Возможно, я не специалист :) Мне кажется, что не все так просто, бывает же плата за нотификации, какая-то страховка, ну и банк мечтает, чтобы вы вышли за грейс период и начали платить проценты.
вбить номер кредитки в первом случае и забыть
или искать посредника, платить ему деньги, чтобы в итоге он вбил номер свей кредитки
Такие сложности излишни – например, торговая площадка может предоставлять гаранта по умолчанию, и по UX это вполне может не отличаться от оплаты по карте, может быть даже проще.
Возможно мы вообще придем к чему-то вроде банков, но в крипте. Само использование крипты не запрещает получать те же гарантии, не обязательно же всегда совершать прямые транзакции.
Теоретически можно воспользоваться услугами гаранта, например. Обратиться к арбитру с хорошей репутацией и купить товар через посредника.
И будет лучше, если таких арбитров будет несколько, и они будут конкурировать между собой :)
А откуда вы это взяли, кстати? Опять перепутали распределённый и децентрализованный?
Анонимный Телеграм
А это откуда взяли? Можно ссылку/цитату?
От анонимности там – возможность использовать псевдонимы, ну и необязательность шарить номер.
TON, где твой аккаунт могут заблокировать совершенно неизвестные дяди
В приложении Wallet, и деньги вы не потеряете. Это сделано исключительно для того, чтобы приложение не выпнули из маркетов. Никто не мешает использовать сторонний клиент.
А где можно найти эти сервера и виртуалки?
Раньше был Scaleway, который предоставлял dedicated ARM64, но они отказались из-за низкой надёжности. Где хостинги а ля Hetzner/Scaleway для ARM? Apple M1 даже найти уже намного легче (тот же Hetzner), чем Linux/aarch64.
В итоге остаётся только Amazon с их собственными Graviton, которые не сильно отличаются от того, что предлагает AMD, ну ещё и Oracle Cloud. Ещё есть куча китайских облаков, но там причина движения в сторону арма понятна, это отвязка от интела.
Для меня отсутствие предложений является хорошим индикатором, что нужно это мало кому. Даже на гитхабе приходится делать self-hosted раннеры, чтобы тестировать код на ARM64. На днях вот специально поднимал в оракловом облаке для опенсорс проектов.
Нет, только лишь библиотека на go, самый близкий аналог это tdlib.
Но на основе этой библиотеки можно будет сделать и графический интерфейс.
Описание API будет чуть позже, я как раз разбираюсь с тем, как правильно работать с обновлениями.
Будет отдельная статья про это, в том числе про повторную отправку, систему диспетчеризации обновлений, ack-и, пинги, параллельные соединения их их пулинг, скачивание и загрузку файлов, соединения к CDN и т.д.
Чем дальше, тем больше будет упор на описание специфики Telegram.
Спасибо, завёл issue.
Попробуем не раздувать бинарники там, где в этом нет необходимости.
Первоначально я действительно не тестировал на tmpfs, полагая, что файл целиком уместился в кеше. Сейчас специально сделал на tmpfs, результаты аналогичные:
А еще я сейчас заметил, что у моего варианта отличается и количество characters от вывода wc, наверное, где-то у меня ошибка или это те самые непечатные символы.
Я успел прочитать сообщение до редактирования и поэтому отвечу: я запускал тесты несколько раз, убедившись, что файл в кеше и программы находятся хотя бы примерно в одинаковых условиях.
Ну и я не ставил себе целью произвести абсолютно точные измерения, очевидно, что wc делает больше работы, да и ресурсов потребляет меньше (гошный рантайм ест несколько мегабайт + bufio.Scanner имеет довольно большой максимальный буфер). Ни в коем случае не хочу сказать что-то вроде "го побеждает си в 20 строчек".
Полностью с вами согласен, добавил свой вариант, чтобы сделать абсурдность сравнения еще более очевидной :)
Даже очень наивная реализация на го оказывается быстрее wc (скорее всего из-за буферизации или еще каких срезанных углов):
Откуда-то взялась лишняя строчка, но мне не интересно в этом разбираться, как и дальше оптимизировать этот код.
При этом мы честно поддерживаем юникод, программа переносима и кросс-компилируется в нативные статические бинари на все поддерживаемые платформы одной командой.
Было бы забавно тут увидеть ещё и статью Дуров не имеет никакого отношения к TON
:)
Прокси сохраняет значение в sum.golang.org, который по сути дерево Меркла, и сейчас там изменить хеш версии невозможно. Зато можно криптографически проверить все изменения версий :) Кстати, это всё работает по умолчанию в гошном тулинге начиная с версии 1.13, дополнительно устанавливать ничего не нужно.
В общем случае невозможно, только если вручную мейнтейнером прокси в очень исключительных случаях.
UPD: забыл сказать, сам пакет прокси тоже хранит вечно, т.е. если даже удалить репо из гитхаба, пакет останется.
Не получится, там всё очень жестко.
Т.е. если вы задеплоили пакет
v1.0.1(по сути сделавgit tag v1.0.1), то изменить или удалить его невозможно. Да и деплой происходит не явно, никто в прокси ничего не пушит, просто тегают новую версию в системе контроля версий и всё автоматически подтягивается при первой загрузке.Есть sum.golang.org, можно почитать описание, если кратко, это проверяемый прозрачный лог хешей для модулей.
Уже есть https://proxy.golang.org/, а для зеркал https://github.com/gomods/athens. Добро пожаловать в 2100!
Go вполне удобно кросс-компилируется под поддерживаемые платформы, например.
Вывезет, если это будет просто signaling, а трафик станет ходить по WebRTC. Сейчас ничего не мешает сделать эффектный peer-to-peer хостинг, все технологии есть, нужно просто правильно их собрать.
И чем больше людей одновременно смотрят одно видео, тем эффективнее эта система работает – да пусть хоть миллиард человек смотрит, будут просто тянуть кусочки видео друг от друга.
Но если такая альтернатива появится и станет сколько нибудь популярной, гугл начнет саботировать её, ведь он владеет самым популярным браузером на планете – достаточно всего лишь тихо испортить ICE механизм для этой платформы и всё. Даже если это обнаружат, гугл просто скажет "ой, это был баг" и выпустит новый "баг" через пару недель.
Я не был бы так уверен в этом. Например, я заметил, что ритейлеры предлагают цену меньше, если из способов оплаты только наличка. Думаю, что это как раз из-за эквайринга.
Возможно, я не специалист :) Мне кажется, что не все так просто, бывает же плата за нотификации, какая-то страховка, ну и банк мечтает, чтобы вы вышли за грейс период и начали платить проценты.
Такие сложности излишни – например, торговая площадка может предоставлять гаранта по умолчанию, и по UX это вполне может не отличаться от оплаты по карте, может быть даже проще.
Возможно мы вообще придем к чему-то вроде банков, но в крипте. Само использование крипты не запрещает получать те же гарантии, не обязательно же всегда совершать прямые транзакции.
Эквайринг не бесплатен. Кредитка часто тоже не бесплатна. Разницы особой я не вижу.
Теоретически можно воспользоваться услугами гаранта, например. Обратиться к арбитру с хорошей репутацией и купить товар через посредника.
И будет лучше, если таких арбитров будет несколько, и они будут конкурировать между собой :)
А откуда вы это взяли, кстати? Опять перепутали распределённый и децентрализованный?
А это откуда взяли? Можно ссылку/цитату?
От анонимности там – возможность использовать псевдонимы, ну и необязательность шарить номер.
В приложении Wallet, и деньги вы не потеряете. Это сделано исключительно для того, чтобы приложение не выпнули из маркетов. Никто не мешает использовать сторонний клиент.
Опять вы, потому что TON Wallet это клиент, и доступ к нему не равнозначен доступу к кошельку (контракту).
Вообще-то они после этого числа смогут запросить деньги назад. Но станут ли?
Это те, что "Дуров не имеет отношения к TON" которые? Я сомневаюсь в их аналитических способностях, если честно.