Представляете, есть «ботнет на 100500 модемов», которые шлют данных на 100 кб в день. И там да, невыгодна такая фишка с обрезанием сессии и округлением до 100 кб. P.S. Это не спам-боты, а модемы для умных счетчиков.
наверно я неправильно понял, извиняюсь.
если стоит задача как-то хранить друзей, то наверно самый простой и быстрый вариант — хранить список друзей пользователя в поле(колонке) самого пользователя.
Живу не в Москве и использую другое приложение для вызова такси (определенного таксопарка). Никаких проблем вообще. Гораздо удобнее написать название улицы (или даже вообще выделить избранные маршруты), чем пытаться объяснить диспетчеру, куда нужно ехать. Пару раз было, что диспетчер не расслышал и такси приехало вообще не туда. Благо та улица, которую расслышал диспетчер, находилась в паре кварталов. А по поводу оплаты: приложение еще до оформления заказа выводит итоговую сумму поездки.
В разных таблицах хранить весело, особенно при добавлении нового типа.
Отдельная таблица с атрибутами. Ага. Будет огромная таблица не поддающаяся фильтрации
Текстовое(бинарное) поле. Опять же фильтрация, кроме того — это по сути и будет nosql.
Под оригинальной ОС есть драйвера как в x86, так и в ARM версии. В линуксе драйвера отсутствуют в обеих вариациях. То есть проблема не в архитектуре, а именно в самом модуле.
Кстати, если уж пошел такой разговор, то, во-первых, дезассемблирование под ARM должно быть проще в виду простоты самого ARM. И, во-вторых, дело не ограничивается только драйверами, наверняка присутствует некая прошивка.
Кстати loop перед spawn_link запускать не имеет смысла. loop будет крутиться в рекурсии(в вашем случае блокироваться, потому что сообщений нет), а spawn_link так и не вызовется. И никакие «взаимоотношения потоков» тут ни при чем.
Писать self()! R в вашем случае нельзя, потому что эта функция будет вызвана внутри нового процесса и self() для нее будет логично другим. Именно поэтому вы и замыкаете Supervisor.
Видно, что с общением процессов толком не разобрались.
В случае some_fun(...) -> some_fun(...) ++ some_fun(...). о хвостовой рекурсии можно забыть, вкупе с "++" получаем дикий расход памяти и проца на больших массивах данных. Спорить по поводу как быстрее сложить 2 списка не стану, но складывать списки на каждом шаге рекурсии явно быстро не будет
when length(Result) == Number лучше не использовать, почему — читать в доке.
Remain — [R] я не буду говорить, насколько это медленно на больших объемах
[R] ++ Result это вообще неприятно видеть, надо [R | Result]
some_fun(..) -> [some_fun(..) || Some < — Whatever]. — это кстати тоже не хвостовая рекурсия
Если вы нам рассказываете о своем опыте изучения erlang, то это похвально и на вашем месте я бы прислушался к комментариям. Если пытаете учить или подсадить кого-то на erlang, то лучше не стоит.
А ничего, что здесь порядок другой? Правда если начинать с красного и идти вверх, а потом продолжить снизу…
Выходить это пропаганда гомосексуализма, только тщательно завуалированная.
ru.wikipedia.org/wiki/Самоопыление
К самоопыляемым растениям относятся горох, фиалки, пшеница, помидоры, ячмень, фасоль, нектарин.
если стоит задача как-то хранить друзей, то наверно самый простой и быстрый вариант — хранить список друзей пользователя в поле(колонке) самого пользователя.
Отдельная таблица с атрибутами. Ага. Будет огромная таблица не поддающаяся фильтрации
Текстовое(бинарное) поле. Опять же фильтрация, кроме того — это по сути и будет nosql.
Кстати, если уж пошел такой разговор, то, во-первых, дезассемблирование под ARM должно быть проще в виду простоты самого ARM. И, во-вторых, дело не ограничивается только драйверами, наверняка присутствует некая прошивка.
Писать self()! R в вашем случае нельзя, потому что эта функция будет вызвана внутри нового процесса и self() для нее будет логично другим. Именно поэтому вы и замыкаете Supervisor.
Если вы нам рассказываете о своем опыте изучения erlang, то это похвально и на вашем месте я бы прислушался к комментариям. Если пытаете учить или подсадить кого-то на erlang, то лучше не стоит.
Выходить это пропаганда гомосексуализма, только тщательно завуалированная.