Re: бляяяя как в современном utf8 мире делают субстринг

[somnambulic]

On 4/6/21 7:06 PM, Зол Терентяк wrote:
> я так понмиай в современном utf8 мире субстринг это кащмаръ.
> видимо заради какой то великой цели
> https://habr.com/ru/company/ruvds/blog/551060/
>

херня. зато utf8 сравнение работает без никакого мозгоебства.

зачем ваще нужен субстринг в буквах? если парсер то там бинарный
субстринг нужен. все остальные зовут парсер.

[somnambulic]

On 4/7/21 7:36 AM, Зол Терентяк wrote:
>> херня. зато utf8 сравнение работает без никакого мозгоебства.
>

> что значит "зато"?
> сравниваем байтики что в обычном что в utf8

exactly

>
>
>> зачем ваще нужен субстринг в буквах? если парсер то там бинарный
>> субстринг нужен. все остальные зовут парсер.
>

> "бинарный субстринг"??
> а готовый парсер тебе Аллах написал?

как правило. если не написал, то один хрен это субстрб точнее даже
мемкопи. нах кому нужен субстр?

>
>
> да просто посчитать длину строки - надо обязательно ползти от начала последовательно по всей строке
>
>
>
>
зачем длина строки в байтах? считать пиксели?

[somnambulic]

в буквах, в байтах понятно зачем...

[somnambulic]

On 4/7/21 10:45 AM, Зол Терентяк wrote:
>>> а готовый парсер тебе Аллах написал?
>> как правило. если не написал, то один хрен это субстрб точнее даже
>> мемкопи. нах кому нужен субстр?
>>>
>>> да просто посчитать длину строки - надо обязательно ползти от начала последовательно по всей строке
>>>
>> зачем длина строки в байтах? считать пиксели?
>

> ты наверно произошол от коровы
>
> мемкопи?
> сколько байт?
>

букв, конечно, букв. зачем тебе длина в буквах?

[Dmitry Krivitsky]

Для анализа текстофф.

[somnambulic]

парсер? они все в байтах оперируют. конкретно, что?

[Dmitry Krivitsky]

Каких ещё байтах?!

> конкретно, что?

Ну, например, найти в русском тексте все слова из трёх букв.

[somnambulic]

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

[Dmitry Krivitsky]

Пшёл нах, мудак.

[somnambulic]

On 4/7/21 1:07 PM, Зол Терентяк wrote:
>
> ну вот кто то выделил на инторнет пейже кусок текста с целью нагло скопипастить
> нужно ли тут дурацкие субстринги, дурацкие длины дурацких сток?
>

обычно если человек руками чего делает, микросекунды не считают. но
сомнительный еще и потому что в пейджике курсор и пиксели, их скорее
всего странслируют в оффсеты в байтах, а не индексы букв.

кого реально все это ебет, что редко, работают в utf16. а то так можно
сказать какого хрена мне надо декомпрессировать зип файл чтобы взять два
байта по такому-то оффсету.

[somnambulic]

блин, имей совесть, мы же не рассказываем тебе как правильно кофе
банкирам подносить?

[Const]

somnambulic <somna...@yahoo.com> wrote:
> >> парсер? они все в байтах оперируют.
> >
> > Каких ещё байтах?!
> >
> >> конкретно, что?
> >
> > Ну, например, найти в русском тексте все слова из трёх букв.

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

Всё-таки математики грубые.

---
Const

[somnambulic]

https://www.reddit.com/r/WhitePeopleTwitter/comments/mlqic7/were_not_on_the_same_page/

[YuraS]

On 4/6/2021 10:06 PM, Зол Терентяк wrote:
> я так понмиай в современном utf8 мире субстринг это кащмаръ.
> видимо заради какой то великой цели
> https://habr.com/ru/company/ruvds/blog/551060/
>

Ты что, тоже Окраинец, которому нужен парсер?
Субстринг utf8 делается очень просто:

c#: "string".Substring(2,2);
python: "string"[2:4]

Чего тебе ещё надобно, старче?

Если кому-то понадобилось разбирать utf8 строчки на байтики, то это -
проблема разбирающих.

[Alexei Rezanov]

А как же с boolean работать? Если 4 буквы, то истина.
Лично видел в индусском скрипте от Оракла.

[Const]

Alexei Rezanov <gdet...@gdetotam.org> wrote:
> >
> > букв, конечно, букв. зачем тебе длина в буквах?
> А как же с boolean работать? Если 4 буквы, то истина.
> Лично видел в индусском скрипте от Оракла.

Ах-ха-ха.
Да чего тут далеко ходить.
Вот прямо сейчас, в этих авро-файлах присылают.

Вот, что у 3gpp:

CauseForRecClosing ::= INTEGER
{
normalRelease (0),
abnormalRelease (4),
cAMELInitCallRelease (5),
volumeLimit (16),


И что ты думаешь, находится в авро-файле ?

Разумеется, строка "VOLUME_LIMIT".
Заметь, не "volumeLimit".
Они и это "улучшили".

Про то, как эти люди пишут cell id (это, правда,
в более старых 4г свитчах) - я уж рассказывал,
это просто вершина какая-то.

---
Const

[Const]

А !
Так Вы тоже миллениал !

---
Const

[YuraS]

Я просто ещё пока не суперстар и соизмеряю задачу с инструментарием.

[YuraS]

On 4/8/2021 10:57 AM, Зол Терентяк wrote:
>> c#: "string".Substring(2,2);
>> python: "string"[2:4]
>>
>> Чего тебе ещё надобно, старче?
>
>

> могу попробовать ещо разъъ...
>
> итак у нас строчька в ДЕСЯТЬ ТЫЩ символов
> нам надо взять букву нумер СТО
> а потом букву номэр ДЕВЯТЬ ТЫЩ.
>
> в старопердунских Цэ обе операциии одинаково быстро.
> томущщо вычислил индекс и оппа.
>
> в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс быстро.
> нада перебирать последовательно.
> взять букву нумер СТО будет в сто раз медленнее чем у старопердунов.
> букву номур ДЕВЯТЬ ТЫЩ будет в девять тыщ раз медленнее
>

А нахуа передавать данные, в которых нужно "номер СТО и номер ДЕВЯТЬ
ТЫЩ" в УТФ8 вместо человеческих байтов?
Если ответ: потому что есть ещё СТО ТЫЩ пользователей, которым нужны
остальные 9998 символов, то тебе не пристало выпендриваться. Конвертируй
свой УТФ8 - с потерями и медленно - в ASCII, а потом используй свой
любимый [].

[YuraS]

On 4/8/2021 1:40 PM, Зол Терентяк wrote:
>>> могу попробовать ещо разъъ...

>
>> А нахуа передавать данные, в которых нужно "номер СТО и номер ДЕВЯТЬ
>> ТЫЩ" в УТФ8 вместо человеческих байтов?
>
>

> окей
> видимо не получилось
> некоторые люди совсем не понимают например что такоэ Уэб Бровзер
>

А что это такое?
Или ты хочешь сказать, что только сотый и девятысячный символы на
СЕКРЕТНОМ УЭБ САЙТЕ содержат ценную информацию?

[YuraS]

On 4/8/2021 1:49 PM, Зол Терентяк wrote:
>
>> остальные 9998 символов, то тебе не пристало выпендриваться. Конвертируй
>> свой УТФ8 - с потерями и медленно - в ASCII, а потом используй свой
>> любимый [].
>

> последняя китайская попытка...
> а вот скажи - как произойдет конвертирование в ASCII?
> ее сделает Небо и Аллах?
>

В изначальной статье изложена куча куча интересных алгоритмов.
Если они медленно работают на твоём i8080, то это мало кого волнует.

[Const]

Задачу максимально эффективно парсить строку ?
Вы ведь понимаете, что парсер (низкоуровневый инструмент)
должен быть максимально эффективным ?

---
Const

[Const]

Зол Терентяк <sergiy...@gmail.com> wrote:
> > c#: "string".Substring(2,2);
> > python: "string"[2:4]
> >
> > Чего тебе ещё надобно, старче?

> могу попробовать ещо разъъ...

> итак у нас строчька в ДЕСЯТЬ ТЫЩ символов
> нам надо взять букву нумер СТО
> а потом букву номэр ДЕВЯТЬ ТЫЩ.

> в старопердунских Цэ обе операциии одинаково быстро.
> томущщо вычислил индекс и оппа.

> в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс быстро.
> нада перебирать последовательно.
> взять букву нумер СТО будет в сто раз медленнее чем у старопердунов.
> букву номур ДЕВЯТЬ ТЫЩ будет в девять тыщ раз медленнее

Ну вот это, кстати, и есть моя проблема с авро.
То есть, реально с джейсон-типом организации данных.
Ну ладно, дерево и есть дерево.
Но его же уплощить невозможно эффективно.
А гулять по дереву с ключами типа строка 1024 символа,
различающаяся где-то в 800-х - тоже такое слабое
удовольствие.

Нет, ну я понимаю, что сейчас принято закинуть всё
говно целиком куда-то в облако и не думать.
Однако, пидоры, которые содержат облако, - таки имеют
привычку чаржить, основываясь на использовании.
Как объемов, так и процессорного времени.

Занятно всё же, как под влиянием моды даже соображения
простые экономические вылетают в окно.
Скажем, перевод нашей базы в Азур будет обходиться
где-то в пять раз дороже.
Да, учитывая содержание собственного датацентра.

Ну да хуйня, миллениалы же и заплатят.

---
Const

[Const]

YuraS <jupa...@gmail.com> wrote:
> > в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс быстро.
> > нада перебирать последовательно.
> > взять букву нумер СТО будет в сто раз медленнее чем у старопердунов.
> > букву номур ДЕВЯТЬ ТЫЩ будет в девять тыщ раз медленнее

> А нахуа передавать данные, в которых нужно "номер СТО и номер ДЕВЯТЬ
> ТЫЩ" в УТФ8 вместо человеческих байтов?
> Если ответ: потому что есть ещё СТО ТЫЩ пользователей, которым нужны
> остальные 9998 символов, то тебе не пристало выпендриваться. Конвертируй
> свой УТФ8 - с потерями и медленно - в ASCII, а потом используй свой
> любимый [].

То есть, завтрашнее похмелье уже сегодня.
Гарантированные потери производительности,
вне зависимости от нужды.

---
Const

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

>> в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс быстро.
>> нада перебирать последовательно.
>> взять букву нумер СТО будет в сто раз медленнее чем у старопердунов.
>> букву номур ДЕВЯТЬ ТЫЩ будет в девять тыщ раз медленнее

C> Ну вот это, кстати, и есть моя проблема с авро.
C> То есть, реально с джейсон-типом организации данных.
C> Ну ладно, дерево и есть дерево.
C> Но его же уплощить невозможно эффективно.
C> А гулять по дереву с ключами типа строка 1024 символа,
C> различающаяся где-то в 800-х - тоже такое слабое
C> удовольствие.

нахуя ты по дереву с глючами гуляешь?

--
Slawa Olhovchenkov

[Mikhail Kimmelman]

"Const" wrote in message news:rjp4kh-...@news.russian-z1.org...

> > > Я просто ещё пока не суперстар и соизмеряю задачу с инструментарием.
> >
> Задачу максимально эффективно парсить строку ?
> Вы ведь понимаете, что парсер (низкоуровневый инструмент)
> должен быть максимально эффективным ?

Я плохо понял, о чём спор, но с эффективностью парсинга
двоичного буфера в utf8 строку никаких проблем вроде нет.

Тут обсуждается другая проблема, а именно, что
двоичное представление utf8 строки не обеспечивает
произвольный доступ к "кодпойнту" за O(1).

Только зачем это нужно, пока неясно.

Миша

[YuraS]

Вот именно.

[YuraS]

Вам после этого комментария запрещено упрекать Вулаха в неспособности
прочесть текст. :)
Я же написал: если есть такое условие.

[Const]

Такого условия нет.

Или сегодня есть, а завтра нету.

---
Const

[Const]

А с чем мне по нему гулять ?

Мне нужно найти в записи какое-то конкретное поле.
Твои действия ?

---
Const

[media]

Ну сконвертируй смесь индусского и ивритского в аскии

[YuraS]

Мне это нафиг не нужно. Это - мечты Шпака и Окра

[YuraS]

Я же говорю: обычная экономика. Согласоваие изменения фиксированного
формата стоит гораздо дороже, чем распарсить самый дебильный JSON в
utf8. А завтра это ещё дешевле будет.

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

>> >> в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс быстро.
>> >> нада перебирать последовательно.
>> >> взять букву нумер СТО будет в сто раз медленнее чем у старопердунов.
>> >> букву номур ДЕВЯТЬ ТЫЩ будет в девять тыщ раз медленнее

>> C> Ну вот это, кстати, и есть моя проблема с авро.
>> C> То есть, реально с джейсон-типом организации данных.
>> C> Ну ладно, дерево и есть дерево.
>> C> Но его же уплощить невозможно эффективно.
>> C> А гулять по дереву с ключами типа строка 1024 символа,
>> C> различающаяся где-то в 800-х - тоже такое слабое
>> C> удовольствие.

>> нахуя ты по дереву с глючами гуляешь?

C> А с чем мне по нему гулять ?

C> Мне нужно найти в записи какое-то конкретное поле.
C> Твои действия ?

я же сказал -- преобразуешь поток авро в поток обычных записей.
с ними уже и работаешь.
по манифесту генеришь условно-обощенный байткод который собственно и разбирает авро в обычную запись.

--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

media <me...@server.site> wrote:

m> Ну сконвертируй смесь индусского и ивритского в аскии

и то и другое можно выкинуть без потери смысла?

--
Slawa Olhovchenkov

[Victor Alekhin]

On 09/04/21 21:33, YuraS wrote:
> On 4/9/2021 1:09 PM, Const wrote:
>> YuraS <jupa...@gmail.com> wrote:
>>> On 4/8/2021 10:44 PM, Const wrote:
>>>> YuraS <jupa...@gmail.com> wrote:
>>>>>> в Новых Молодежных Современных УТФ8 нивазможно вычислить индекс

> Я же говорю: обычная экономика. Согласоваие изменения фиксированного
> формата стоит гораздо дороже, чем распарсить самый дебильный JSON в
> utf8. А завтра это ещё дешевле будет.
>

Ну да, это жизнь такая, 20 лет назад я тыкал наших java-программеров в
truss log (типа, ну и чем занимается твоя джава эти 20 секунд ?),
сегодня "не морочь мне голову, купи еще памяти" :-)
Но все равно обидно ...

[Vladimir Abaturov]

Зол Терентяк <sergiy...@gmail.com> wrote:
>>
>> остальные 9998 символов, то тебе не пристало выпендриваться. Конвертируй
>> свой УТФ8 - с потерями и медленно - в ASCII, а потом используй свой
>> любимый [].
>

[Sergey Babkin]

On 4/7/21 7:38 PM, YuraS wrote:
> On 4/6/2021 10:06 PM, Зол Терентяк wrote:
>> я так понмиай в современном utf8 мире субстринг это кащмаръ.
>> видимо заради какой то великой цели
>> https://habr.com/ru/company/ruvds/blog/551060/
>>
>
> Ты что, тоже Окраинец, которому нужен парсер?
> Субстринг utf8 делается очень просто:
>
> c#: "string".Substring(2,2);

Это не utf-8. Это wchar.

-СБ

[Sergey Babkin]

On 4/8/21 7:43 PM, Const wrote:

> Но его же уплощить невозможно эффективно.
> А гулять по дереву с ключами типа строка 1024 символа,
> различающаяся где-то в 800-х - тоже такое слабое
> удовольствие.

А ты посчитай для них хэши, потом сравнивай хэши.

-СБ

[Const]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> C> Мне нужно найти в записи какое-то конкретное поле.
> C> Твои действия ?

> я же сказал -- преобразуешь поток авро в поток обычных записей.

Жизус крайст.

Содержание древовидное.
С ключами очень длинными.

---
Const

[Const]

Так себе занятие.
Но doable, конечно.

Но там еще и массивчики есть, висящие на узлах.

---
Const

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> C> Мне нужно найти в записи какое-то конкретное поле.
>> C> Твои действия ?

>> я же сказал -- преобразуешь поток авро в поток обычных записей.

C> Жизус крайст.

C> Содержание древовидное.
C> С ключами очень длинными.

при разборе потока к тебя все ключи локальные и короткие.
весь длинный префикс ты и так уже знаешь.
а уж что ты из этого будешь строить -- дело десятое.

--
Slawa Olhovchenkov

[YuraS]

Технически - да, но если ему дать строку в utf-8, то сработает.

[Const]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Const <rent...@gmail.com> wrote:
> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> C> Мне нужно найти в записи какое-то конкретное поле.
> >> C> Твои действия ?

> >> я же сказал -- преобразуешь поток авро в поток обычных записей.

> C> Жизус крайст.

> C> Содержание древовидное.
> C> С ключами очень длинными.

> при разборе потока к тебя все ключи локальные и короткие.
> весь длинный префикс ты и так уже знаешь.

И попытки сравнивать большой длинный ключ
поля, которое мы хотим найти, будут стоить
абсолютно те же деньги.

Проблема именно в древовидности и длинных ключах.
Нет, ну оно, конечно, не ужас-ужас.
Но неэффективность просто бросается в глаза.

---
Const

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Const <rent...@gmail.com> wrote:
>> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> >> C> Мне нужно найти в записи какое-то конкретное поле.
>> >> C> Твои действия ?

>> >> я же сказал -- преобразуешь поток авро в поток обычных записей.

>> C> Жизус крайст.

>> C> Содержание древовидное.
>> C> С ключами очень длинными.

>> при разборе потока к тебя все ключи локальные и короткие.
>> весь длинный префикс ты и так уже знаешь.

C> И попытки сравнивать большой длинный ключ
C> поля, которое мы хотим найти, будут стоить
C> абсолютно те же деньги.

поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.
зачем тебе сравнивать ключи?

C> Проблема именно в древовидности и длинных ключах.
C> Нет, ну оно, конечно, не ужас-ужас.
C> Но неэффективность просто бросается в глаза.

раз тебе не нужна древовидность, так избавься от неё.


--
Slawa Olhovchenkov

[Const]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> C> Содержание древовидное.
> >> C> С ключами очень длинными.

> >> при разборе потока к тебя все ключи локальные и короткие.
> >> весь длинный префикс ты и так уже знаешь.

> C> И попытки сравнивать большой длинный ключ
> C> поля, которое мы хотим найти, будут стоить
> C> абсолютно те же деньги.

> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

Это с чего бы это ?

---
Const

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

C> Это с чего бы это ?

потому что это удобно.
а делать себе неудобно -- удел идиотов и икутых.

--
Slawa Olhovchenkov

[Vladimir Abaturov]

Const <rent...@gmail.com> wrote:
> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Const <rent...@gmail.com> wrote:

>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>> Мне нужно найти в записи какое-то конкретное поле.

>>>>> Твои действия ?
>
>>>> я же сказал -- преобразуешь поток авро в поток обычных записей.
>

>>> Жизус крайст.
>
>>> Содержание древовидное.

>>> С ключами очень длинными.
>
>> при разборе потока к тебя все ключи локальные и короткие.
>> весь длинный префикс ты и так уже знаешь.
>
> И попытки сравнивать большой длинный ключ
> поля, которое мы хотим найти, будут стоить
> абсолютно те же деньги.
>
> Проблема именно в древовидности и длинных ключах.
> Нет, ну оно, конечно, не ужас-ужас.
> Но неэффективность просто бросается в глаза.
>
> ---
> Const
>

Разве кто-то использует для представления строк в оперативной памяти UTF-8?
Для этого больше подходят UTF-16 и UTF-32.

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
VA> Для этого больше подходят UTF-16 и UTF-32.

никакой разницы же.
http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.

--
Slawa Olhovchenkov

[Vladimir Abaturov]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:

> Vladimir Abaturov <v3...@mail.ru> wrote:
>
>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?

>> Для этого больше подходят UTF-16 и UTF-32.
>
> никакой разницы же.
> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.
>

То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.

Что это за такой символ? У меня и в браузере, и в консоли выводится
крокозябрами.

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>
>>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>>> Для этого больше подходят UTF-16 и UTF-32.
>>
>> никакой разницы же.
>> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.
>>

VA> То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.

VA> Что это за такой символ? У меня и в браузере, и в консоли выводится
VA> крокозябрами.

скорее всего браузер кодировку проигнориовал (у меня ff так поступает)
ок, оформил в виде html http://zxy.spb.ru/utflong.html


--
Slawa Olhovchenkov

[Dmitry Krivitsky]

On 4/11/2021 4:53 PM, Slawa Olhovchenkov wrote:
> Vladimir Abaturov <v3...@mail.ru> wrote:
> VA> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>
>>>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>>>> Для этого больше подходят UTF-16 и UTF-32.
>>>
>>> никакой разницы же.
>>> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.
>>>
>
> VA> То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.
>
> VA> Что это за такой символ? У меня и в браузере, и в консоли выводится
> VA> крокозябрами.
>
> скорее всего браузер кодировку проигнориовал (у меня ff так поступает)
> ок, оформил в виде html http://zxy.spb.ru/utflong.html

За включение таких символов в unicode нужно расстреливать.

[Slawa Olhovchenkov]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:

DK> За включение таких символов в unicode нужно расстреливать.

The Unicode Consortium is a 501 non-profit organization incorporated and based in Mountain View, California.

можешь кинуть туда ядерную бомбу.

--
Slawa Olhovchenkov

[Vladimir Abaturov]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Vladimir Abaturov <v3...@mail.ru> wrote:
>
>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>
>>>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>>>> Для этого больше подходят UTF-16 и UTF-32.
>>>
>>> никакой разницы же.
>>> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.
>>>
>

>> То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.
>

>> Что это за такой символ? У меня и в браузере, и в консоли выводится

>> крокозябрами.
>
> скорее всего браузер кодировку проигнориовал (у меня ff так поступает)
> ок, оформил в виде html http://zxy.spb.ru/utflong.html
>
>

Это не один символ, это один знак (или два, непонятно), представленный
несколькими символами. Это нормально для юникода. Там разные части этих
человечков (ручки, головы и прочее) -- отдельные символы. Так же, как любой
амляут -- отдельный символ.

Кстати, в разных текстовых редакторах по-разному смешно разваливается на
части.

Тут видимо речь идет о какой-то функции подсчета знакомест. Тогда
действительно, только хэши городить.

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>
>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>>
>>>>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>>>>> Для этого больше подходят UTF-16 и UTF-32.
>>>>
>>>> никакой разницы же.
>>>> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется ни в 16 ни в 32 бита.
>>>>
>>
>>> То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.
>>
>>> Что это за такой символ? У меня и в браузере, и в консоли выводится
>>> крокозябрами.
>>
>> скорее всего браузер кодировку проигнориовал (у меня ff так поступает)
>> ок, оформил в виде html http://zxy.spb.ru/utflong.html
>>
>>

VA> Это не один символ, это один знак (или два, непонятно), представленный
VA> несколькими символами. Это нормально для юникода. Там разные части этих
VA> человечков (ручки, головы и прочее) -- отдельные символы. Так же, как любой
VA> амляут -- отдельный символ.

символ не символ а знак... не, это какое-то словоблудие.
в ff выделяется как единое целое за один клик -- короче это один символ. или один знак.
похуй, это сущность которая должна целиком таскаться. а не так, что ручка на одной строке,
а ножка -- на другой.

VA> Кстати, в разных текстовых редакторах по-разному смешно разваливается на
VA> части.

да, новые веяния в стандартостроении провоцируют новые глюки

VA> Тут видимо речь идет о какой-то функции подсчета знакомест. Тогда
VA> действительно, только хэши городить.

--
Slawa Olhovchenkov

[Dmitry Krivitsky]

Mountain View - это там, где компьютерный музей?
Не, бомбу не надо, музей жалко. Но тех, кто этот символ в unicode
включил - расстрелять.

[Sergey Babkin]

Он ее сначала разберет в wchar.

-СБ

[Sergey Babkin]

Если тебе очень хочется вот прям таки плоской таблицы вообще без иерархии, то
ничего не мешает построить хэш всего пути, включая индекс массива. Очевидная
проблема в этом - что для поисков в поддереве придется все равно строить полный
путь.

-СБ

[Sergey Babkin]

On 4/11/21 12:24 PM, Vladimir Abaturov wrote:
> Const <rent...@gmail.com> wrote:
>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Const <rent...@gmail.com> wrote:
>>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>>> Мне нужно найти в записи какое-то конкретное поле.
>>>>>> Твои действия ?
>>
>>>>> я же сказал -- преобразуешь поток авро в поток обычных записей.
>>
>>>> Жизус крайст.
>>
>>>> Содержание древовидное.
>>>> С ключами очень длинными.
>>
>>> при разборе потока к тебя все ключи локальные и короткие.
>>> весь длинный префикс ты и так уже знаешь.
>>
>> И попытки сравнивать большой длинный ключ
>> поля, которое мы хотим найти, будут стоить
>> абсолютно те же деньги.
>>
>> Проблема именно в древовидности и длинных ключах.
>> Нет, ну оно, конечно, не ужас-ужас.
>> Но неэффективность просто бросается в глаза.
>>
>> ---
>> Const
>>
>
> Разве кто-то использует для представления строк в оперативной памяти UTF-8?

Весь Линукс использует. Wchar - это более виндовсный подход (кстати, да, смешно
оказалось, когда в Джаве думали, что 16 бит хватит для wchar, а потом пришлось и
в нем городить UTF).

> Для этого больше подходят UTF-16 и UTF-32.

Если там UTF, то никакой разницы, какая в нем ширина символа - все равно надо
сканировать последовательно. Но более широкий символ означает исользование
большего количества байт, так что сканирование будет медленнее.

-СБ

[YuraS]

Именно это я и имею в виду под "тенически". Суть в том, что программиста
это уже не волнует. На всякиэ ЭНИАКах нужно было знать, что там в каком
регистре, а сейчас это только кубушиных касается.

[Vladimir Abaturov]

>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>
> Весь Линукс использует. Wchar - это более виндовсный подход (кстати, да, смешно
> оказалось, когда в Джаве думали, что 16 бит хватит для wchar, а потом пришлось и
> в нем городить UTF).

Ну, не весь.
Perl - utf8
Tcl - utf16
Python - utf16, в последних версиях utf-32
Java, опять же.

Ядро не знаю, но что-то подсказывает, что вряд ли там utf-8. Какой смысл,
если любой юникодный символ помещается в 4 байта, т.к. их всего чуть больше
миллиона (т.е., четырех-то байт уж точно хватит навечно). К тому же,
максимальный размер символа в utf-8 также 4 байта.

Файловые системы и сами файлы -- да, но то не оперативная память.

>
>> Для этого больше подходят UTF-16 и UTF-32.
>
> Если там UTF, то никакой разницы, какая в нем ширина символа - все равно надо
> сканировать последовательно. Но более широкий символ означает исользование
> большего количества байт, так что сканирование будет медленнее.

В UTF-32 длина символа постоянна, можно работать как с массивом всегда. В
UTF-16 почти всегда постоянна, т.е. для большинства применений тоже можно.

[Vladimir Abaturov]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
> On 4/11/2021 5:12 PM, Slawa Olhovchenkov wrote:
>> Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
>>
>>> On 4/11/2021 4:53 PM, Slawa Olhovchenkov wrote:
>>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>>>>
>>>>>>> Разве кто-то использует для представления строк в оперативной памяти UTF-8?
>>>>>>> Для этого больше подходят UTF-16 и UTF-32.
>>>>>>
>>>>>> никакой разницы же.
>>>>>> http://zxy.spb.ru/utflong.txt -- это один символ и он не кодируется
>>>>>> ни в 16 ни в 32 бита.
>>>>>>
>>>>

>>>>> То есть, вся юникодная таблица не лезет в 4 байта? Вот это да.
>>>>

>>>>> Что это за такой символ? У меня и в браузере, и в консоли выводится

>>>>> крокозябрами.
>>>>
>>>> скорее всего браузер кодировку проигнориовал (у меня ff так поступает)
>>>> ок, оформил в виде html http://zxy.spb.ru/utflong.html
>>

>>> За включение таких символов в unicode нужно расстреливать.
>>
>> The Unicode Consortium is a 501 non-profit organization incorporated and
>> based in Mountain View, California.
>> можешь кинуть туда ядерную бомбу.
>
> Mountain View - это там, где компьютерный музей?
> Не, бомбу не надо, музей жалко. Но тех, кто этот символ в unicode
> включил - расстрелять.
>

Да ладно, вы еще скажите, что IPv6 -- зло.

[Dmitry Krivitsky]

Зло. :-)

[Sergey Kubushyn]

И таки да, зло.

---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************

[Const]

Тебя трудно понять.
После разбора - да, конечно, будет.
Но разбор до'рог - это раз.
И если начинать городить по-настоящему такую
вот переразборку - теряется flexibility и
легкие перемены в случае модификации того,
что шлют.

Проведши где-то 15 лет за разборкой разных
идиотских форматов, я должен сказать, что
абсолютно, совершенно оптимальным с точки
производительности является ама.
Исторический фиксированный формат, исходно придуманный Т
для простых старых телефонных записей.
Но да, модифицировать сложно.
Если бы мне дали порулить, я бы сделал модификацию
ама с гибкими правилами.

---
Const

[Const]

Sergey Kubushyn <k...@koi8.net> wrote:
> >> включил - расстрелять.
> >
> > Да ладно, вы еще скажите, что IPv6 -- зло.

> И таки да, зло.

Это тривиально очевидно.

А что, кто-то его пользует ?

---
Const

[Const]

Sergey Babkin <sab...@hotmail.com> wrote:
> On 4/10/21 2:54 AM, Const wrote:
> > Sergey Babkin <sab...@hotmail.com> wrote:
> >> On 4/8/21 7:43 PM, Const wrote:
> >
> >>> Но его же уплощить невозможно эффективно.
> >>> А гулять по дереву с ключами типа строка 1024 символа,
> >>> различающаяся где-то в 800-х - тоже такое слабое
> >>> удовольствие.
> >
> >> А ты посчитай для них хэши, потом сравнивай хэши.
> >
> > Так себе занятие.
> > Но doable, конечно.
> >
> > Но там еще и массивчики есть, висящие на узлах.

> Если тебе очень хочется вот прям таки плоской таблицы вообще без иерархии, то
> ничего не мешает построить хэш всего пути, включая индекс массива. Очевидная

Если ты думаешь, что открыл мне хеши, то ты ошибаешься.
Разумеется, я рассматривал все возможности.
И всё еще рассматриваю.
Ну, то есть, я сделал там что-то, оно работает,
но я сам недоволен.
Это всё некрасиво.
Но я начинаю думать, что с этими джейсонами красивых
и эффективных решений попросту не существует.

---
Const

[Const]

Это заблуждение.

---
Const

[Sergey Kubushyn]

Ты будешь смеяться, но, прости г-ди, Андроид, например, ПРИНЦИПИАЛЬНО не
принимает ничего кроме адреса от DHCP. DNS ему передать невозможно и сделано
это СПЕЦИАЛЬНО. Он его принимает только от DHCPv6. А если не v6, то гвоздями
насмерть 8.8.8.8. Ответ юных дарований из, прости г-ди, гУгля на вопрос
"какого мужского полового уя и когда будет исправлено" был "все вж, v6 наше
будущее и мы ПРИНЦИПИАЛЬНО не поддерживаем и не будем поддерживать
устаревшее дерьмо мамонта, а кому не нравится могут go fuck theirselves".
Это практически дословно, в оригинале оно ещё культурнее.

[Sergey Babkin]

Тормозить оно будет как у гуглопрограммистов.

-СБ

[Sergey Babkin]

Он нынче везде.

-СБ

[Vladimir Abaturov]

Очевидно как раз другое, что всем нормальным людям жизненно необходимо,
чтобы он взлетел. Ipv6, может, местами технически и некрасив, но, если быть
реалистами, в него вложено уже слишком много, другого ничего уже не
появится и поэтому либо взлетит, либо навечно nat и скучный мир с облаками,
подписками и соцсетями.

А технически некрасив он в основном в двух вещах:

1) То, что должно быть на втором уровне модели OSI, дублировано на третьем
(NDP кэши вот эти все)

2) Нерациональная утилизация адресного пространства (минимум /64 на каждого
юзера)

Первый пункт можно оправдать тем, что теперь нет бродкастов, можно
создавать плоские сегменты любого размера (на практике ограниченные
размером ndp cache, т.е. порядка нескольких тысяч хостов).

По второму пункту: с другой стороны, есть что-то глубоко философское в том,
что юзеру выдается кусок адресного пространства размером с весь интернет,
или там 256 интернетов. Типа как микрокосм и макрокосм. Возможно, в будущем
еще придумают, как это красиво использовать (например, для внутренней
адресации чего-нибудь в peer-to-peer протоколах).

Но вместе с этим есть и киллер фичи. Чего стоит только ipsec, включающийся
как опция сокета, обеспечивающий человеческое end to end шифрование на
сетевом уровне, а не как в SSL, от которого можно будет наконец избавиться.

Или возможность забыть о nat чего стоит.

А гугл, если бы всерьез считал, что это будущее, а не только на словах,
форсил бы его нормально, как он умеет, и это сейчас действительно было бы
везде. Как HTTPS. А так, с точки зрения бизнес-модели гугла, юзеру как
придатку к его сервисам ip-адрес, наоборот, не нужен.

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Const <rent...@gmail.com> wrote:

>> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> >> >> C> Содержание древовидное.
>> >> >> C> С ключами очень длинными.

>> >> >> при разборе потока к тебя все ключи локальные и короткие.
>> >> >> весь длинный префикс ты и так уже знаешь.

>> >> C> И попытки сравнивать большой длинный ключ
>> >> C> поля, которое мы хотим найти, будут стоить
>> >> C> абсолютно те же деньги.

>> >> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

>> C> Это с чего бы это ?

>> потому что это удобно.
>> а делать себе неудобно -- удел идиотов и икутых.

C> Тебя трудно понять.
C> После разбора - да, конечно, будет.
C> Но разбор до'рог - это раз.

да не дорого он.
у тебя есть мета в виде jsonа в начале файла.
ты ее парсишь и генеришь условный байткод для себя (как вариант -- массив/список указателей на функцию которую надо сейчас вызвать и возможно какие-то дополнителльные аргументы).
когда читаешь данные используешь этот условный байткод из которого и следует что
следующее значение идет в такое-то поле, или у тебя появляется массив. или рождается
следующий потом у дерева (и вся дальнейшая локальная работа будет идти уже с ним)

ну как-то так.

ну в конце концов getopt примерно так же argc/argv разбирает.

C> И если начинать городить по-настоящему такую
C> вот переразборку - теряется flexibility и
C> легкие перемены в случае модификации того,
C> что шлют.

нет, не теряется.

--
Slawa Olhovchenkov

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> 1) То, что должно быть на втором уровне модели OSI, дублировано на третьем
VA> (NDP кэши вот эти все)

модель оси к реальности отношения не имеет, это вообще тендерный выблядок для американских тендеров.

VA> Но вместе с этим есть и киллер фичи. Чего стоит только ipsec, включающийся
VA> как опция сокета, обеспечивающий человеческое end to end шифрование на
VA> сетевом уровне, а не как в SSL, от которого можно будет наконец избавиться.

какая еще опция? что значит человеческое?

VA> Или возможность забыть о nat чего стоит.

вот как раз совершенно не хочется. да и не выйдет.

VA> А гугл, если бы всерьез считал, что это будущее, а не только на словах,
VA> форсил бы его нормально, как он умеет, и это сейчас действительно было бы
VA> везде. Как HTTPS. А так, с точки зрения бизнес-модели гугла, юзеру как
VA> придатку к его сервисам ip-адрес, наоборот, не нужен.

ну так https не потому что будущее, а потому что возможность рубильника.
плюс всех заставляют обязательно надрачивать свою хуйню.

--
Slawa Olhovchenkov

[YuraS]

Относительно, конечно, будет. И в real-time систему такое впихивать,
естествено, нельзя. Но для обасучивания прачечных - самое то.

[Const]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Const <rent...@gmail.com> wrote:

> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> Const <rent...@gmail.com> wrote:

> >> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> >> >> C> Содержание древовидное.
> >> >> >> C> С ключами очень длинными.

> >> >> >> при разборе потока к тебя все ключи локальные и короткие.
> >> >> >> весь длинный префикс ты и так уже знаешь.

> >> >> C> И попытки сравнивать большой длинный ключ
> >> >> C> поля, которое мы хотим найти, будут стоить
> >> >> C> абсолютно те же деньги.

> >> >> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

> >> C> Это с чего бы это ?

> >> потому что это удобно.
> >> а делать себе неудобно -- удел идиотов и икутых.

> C> Тебя трудно понять.
> C> После разбора - да, конечно, будет.
> C> Но разбор до'рог - это раз.

> да не дорого он.
> у тебя есть мета в виде jsonа в начале файла.
> ты ее парсишь и генеришь условный байткод для себя (как вариант -- массив/список указателей на функцию которую надо сейчас вызвать и возможно какие-то дополнителльные аргументы).
> когда читаешь данные используешь этот условный байткод из которого и следует что
> следующее значение идет в такое-то поле, или у тебя появляется массив. или рождается

Вот чтобы понять, куда оно идет или нет - мне нужно сравнивать ключи.
Длинные.
All the time.

> ну в конце концов getopt примерно так же argc/argv разбирает.

Getopt, я полагаю, известен своей жуткой эффективностью.
Не зря же на ем атомные бомбы испокон веков рассчитывают.

---
Const

[Vladimir Abaturov]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Vladimir Abaturov <v3...@mail.ru> wrote:
>

>> 1) То, что должно быть на втором уровне модели OSI, дублировано на третьем

>> (NDP кэши вот эти все)
>
> модель оси к реальности отношения не имеет, это вообще тендерный выблядок
> для американских тендеров.
>

>> Но вместе с этим есть и киллер фичи. Чего стоит только ipsec, включающийся

>> как опция сокета, обеспечивающий человеческое end to end шифрование на

>> сетевом уровне, а не как в SSL, от которого можно будет наконец избавиться.
>
> какая еще опция? что значит человеческое?
>

PF_KEY, наверное.

Теоретически, любое приложение может же создать сокет с ней и шифровать
свой коннекшен. Реализация ipsec уже есть.

Человеческое, значит в основе не лежит криптографический алгоритм,
основанный на доверии к центрам сертификации. Хотя и ipsec можно
использовать с X.509 сертификатами, но не только.

>> Или возможность забыть о nat чего стоит.
>
> вот как раз совершенно не хочется. да и не выйдет.
>

Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально
работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и
расшариваются без всяких там дропбоксов?

Сейчас засилье HTTP отчасти именно из-за того, что кроме него через нат
почти ничего без костылей (fixup) не работает, да и с костылями работает
как повезет.

>> А гугл, если бы всерьез считал, что это будущее, а не только на словах,

>> форсил бы его нормально, как он умеет, и это сейчас действительно было бы

>> везде. Как HTTPS. А так, с точки зрения бизнес-модели гугла, юзеру как

>> придатку к его сервисам ip-адрес, наоборот, не нужен.
>
> ну так https не потому что будущее, а потому что возможность рубильника.
> плюс всех заставляют обязательно надрачивать свою хуйню.
>

Видение будущего и возможность рубильника связаны. А ipv6 возможностей для
рубильников не дает, а наоборот, создает только препятствия. Поэтому он
никому не нужен, кроме народа (и то, маленькой сознательной его кучки). Ни
гуглам, ни провайдерам.

[Slawa Olhovchenkov]

C> Вот чтобы понять, куда оно идет или нет - мне нужно сравнивать ключи.
C> Длинные.
C> All the time.

нет. порядок ключей у тебя фиксирован в схеме и дальше транслируется в байткод.
в самом пайлоаде ключей нет, только данные.

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>
>>> 1) То, что должно быть на втором уровне модели OSI, дублировано на третьем
>>> (NDP кэши вот эти все)
>>
>> модель оси к реальности отношения не имеет, это вообще тендерный выблядок
>> для американских тендеров.
>>
>>> Но вместе с этим есть и киллер фичи. Чего стоит только ipsec, включающийся
>>> как опция сокета, обеспечивающий человеческое end to end шифрование на
>>> сетевом уровне, а не как в SSL, от которого можно будет наконец избавиться.
>>
>> какая еще опция? что значит человеческое?
>>

VA> PF_KEY, наверное.

VA> Теоретически, любое приложение может же создать сокет с ней и шифровать
VA> свой коннекшен. Реализация ipsec уже есть.

ты кажется все перепутал.
это сокет для конифгурирования ipsec рулезов. требует рута, кстати.

VA> Человеческое, значит в основе не лежит криптографический алгоритм,
VA> основанный на доверии к центрам сертификации. Хотя и ipsec можно
VA> использовать с X.509 сертификатами, но не только.

чё-чё-чё?
x.509 это о вопросе аутентификации, а не криптовании.

>>> Или возможность забыть о nat чего стоит.
>>
>> вот как раз совершенно не хочется. да и не выйдет.
>>

VA> Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально
VA> работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и
VA> расшариваются без всяких там дропбоксов?

мне совершенно не приятно когда каждая сранная мыльница мало того что шпионское облако срет всяким,
так еще и к ней можно оказывается напрямую подключиться и попросить её что-то сделать

--
Slawa Olhovchenkov

[Vladimir Abaturov]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Vladimir Abaturov <v3...@mail.ru> wrote:
>
>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Vladimir Abaturov <v3...@mail.ru> wrote:
>>>
>>>> 1) То, что должно быть на втором уровне модели OSI, дублировано на третьем
>>>> (NDP кэши вот эти все)
>>>
>>> модель оси к реальности отношения не имеет, это вообще тендерный выблядок
>>> для американских тендеров.
>>>
>>>> Но вместе с этим есть и киллер фичи. Чего стоит только ipsec, включающийся
>>>> как опция сокета, обеспечивающий человеческое end to end шифрование на
>>>> сетевом уровне, а не как в SSL, от которого можно будет наконец избавиться.
>>>
>>> какая еще опция? что значит человеческое?
>>>
>

>> PF_KEY, наверное.

>
>> Теоретически, любое приложение может же создать сокет с ней и шифровать

>> свой коннекшен. Реализация ipsec уже есть.
>
> ты кажется все перепутал.
> это сокет для конифгурирования ipsec рулезов. требует рута, кстати.
>

Вот тут мне самому захотелось практически поресерчить эту тему. Попытаться
создать зашифрованное соединение средствами native ipv6 с правами обычного
юзера. Много раз видел во всяких статьях, что можно, что есть какие-то
новые опции. А сам не проверял.

>> Человеческое, значит в основе не лежит криптографический алгоритм,

>> основанный на доверии к центрам сертификации. Хотя и ipsec можно

>> использовать с X.509 сертификатами, но не только.
>
> чё-чё-чё?
> x.509 это о вопросе аутентификации, а не криптовании.
>

Да, но аутентификация -- тоже часть криптования. С открытого ключа в
сертификате начинается хэндшейк. Аутентификация может происходить и
по-другому. Существуют способы обмена открытыми ключами и хэндшейка без CA
и они доступны в ipsec.

>>>> Или возможность забыть о nat чего стоит.
>>>
>>> вот как раз совершенно не хочется. да и не выйдет.
>>>
>

>> Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально

>> работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и

>> расшариваются без всяких там дропбоксов?
>
> мне совершенно не приятно когда каждая сранная мыльница мало того что
> шпионское облако срет всяким,
> так еще и к ней можно оказывается напрямую подключиться и попросить её что-то сделать
>

Это давно уже не проблема. У меня самый что ни на есть говнороутер d-link
dir-615s, по умолчанию входящие соединения закрыты. В общем-то, чтобы
открыть порт для ipv4, надо заходить на роутер настраивать проброс порта, а
для ipv6 аналогично надо заходить открывать порт.

[Vladimir Abaturov]

>>> Человеческое, значит в основе не лежит криптографический алгоритм,
>>> основанный на доверии к центрам сертификации. Хотя и ipsec можно
>>> использовать с X.509 сертификатами, но не только.
>>
>> чё-чё-чё?
>> x.509 это о вопросе аутентификации, а не криптовании.
>>
>
> Да, но аутентификация -- тоже часть криптования. С открытого ключа в
> сертификате начинается хэндшейк. Аутентификация может происходить и
> по-другому. Существуют способы обмена открытыми ключами и хэндшейка без CA
> и они доступны в ipsec.
>

Извиняюсь, по этому пункту я понял свою дурь. Если мы хотим отказаться от
доверия к удостоверяющим центрам, то нужна какая-то другая аутентификация:
по паролю, какому-то ключу, собственный удостоверяющий центр и т.д. Т.к.
само по себе шифрование не заменит аутентификацию, всегда может встать
кто-то посередине с самого начала соединения и притвориться другой
стороной. Без этого проблема MITM нерешаема.

[Slawa Olhovchenkov]

Vladimir Abaturov <v3...@mail.ru> wrote:

VA> Да, но аутентификация -- тоже часть криптования. С открытого ключа в
VA> сертификате начинается хэндшейк. Аутентификация может происходить и
VA> по-другому. Существуют способы обмена открытыми ключами и хэндшейка без CA
VA> и они доступны в ipsec.

нет.

--
Slawa Olhovchenkov

[Const]

Vladimir Abaturov <v3...@mail.ru> wrote:
> Очевидно как раз другое, что всем нормальным людям жизненно необходимо,
> чтобы он взлетел.

Не встречал ни разу.

> Ipv6, может, местами технически и некрасив, но, если быть
> реалистами, в него вложено уже слишком много, другого ничего уже не

Мало кто чего куда вложил.
Я вон и в подобие МММ некогда влагал деньги.
Ну, правда, выигранные в карты и четко осознавая,
что я могу уже быть опоздавшим.
И таки был !

> появится и поэтому либо взлетит, либо навечно nat и скучный мир с облаками,
> подписками и соцсетями.

А какая связь у ipv6 с соцсетями ?

> А технически некрасив он в основном в двух вещах:

> 1) То, что должно быть на втором уровне модели OSI, дублировано на третьем
> (NDP кэши вот эти все)

> 2) Нерациональная утилизация адресного пространства (минимум /64 на каждого
> юзера)

Всё проще.
Он нахуй не нужен.

> Или возможность забыть о nat чего стоит.

Э, мнэ, ЗАЧЕМ ?

---
Const

[Const]

Vladimir Abaturov <v3...@mail.ru> wrote:
> Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально
> работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и
> расшариваются без всяких там дропбоксов?

Я, признаться, чего-то тут даже теряюсь.
Вроде слова какие-то знакомые.
Но смысла не вижу.

Вы случайно не ебанутый ?

> Сейчас засилье HTTP отчасти именно из-за того, что кроме него через нат
> почти ничего без костылей (fixup) не работает, да и с костылями работает
> как повезет.

А я-то думаю, из-за чего же это засилье http.

Скажите, а Вы прививались уже ?

---
Const

[Const]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> >> >> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

> >> >> C> Это с чего бы это ?

> >> >> потому что это удобно.
> >> >> а делать себе неудобно -- удел идиотов и икутых.

> >> C> Тебя трудно понять.
> >> C> После разбора - да, конечно, будет.
> >> C> Но разбор до'рог - это раз.

> >> да не дорого он.
> >> у тебя есть мета в виде jsonа в начале файла.
> >> ты ее парсишь и генеришь условный байткод для себя (как вариант -- массив/список указателей на функцию которую надо сейчас вызвать и возможно какие-то дополнителльные аргументы).
> >> когда читаешь данные используешь этот условный байткод из которого и следует что
> >> следующее значение идет в такое-то поле, или у тебя появляется массив. или рождается

> C> Вот чтобы понять, куда оно идет или нет - мне нужно сравнивать ключи.
> C> Длинные.
> C> All the time.

> нет. порядок ключей у тебя фиксирован в схеме и дальше транслируется в байткод.
> в самом пайлоаде ключей нет, только данные.

Слава, мы чего-то тут где-то кардинально расходимся.
Во-первых, я не понимаю, какой нахуй байткод.
Это с-программа, которая спускается по дереву, для каждой записи.

---
Const

[Vladimir Abaturov]

Const <rent...@gmail.com> wrote:
> Vladimir Abaturov <v3...@mail.ru> wrote:
>> Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально
>> работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и
>> расшариваются без всяких там дропбоксов?
>
> Я, признаться, чего-то тут даже теряюсь.
> Вроде слова какие-то знакомые.
> Но смысла не вижу.
>
> Вы случайно не ебанутый ?
>

Что тут непонятного? Мысль была предельно простая (хотя, не совсем в тему,
да): при наличии у юзера нормального коннективити облака объективно не
нужны. А ipv6 это нормальное коннективити обеспечивает. Можно хранить свои
данные у себя, обрабатывать у себя и с себя расшаривать, при нынешних-то
дурных интернетах и вычислительных мощностях. Но как же? Все устройства
голой жопой в интернет, это опасно. Гораздо безопаснее доверить все не
пойми кому.

>> Сейчас засилье HTTP отчасти именно из-за того, что кроме него через нат
>> почти ничего без костылей (fixup) не работает, да и с костылями работает
>> как повезет.
>
> А я-то думаю, из-за чего же это засилье http.
>
> Скажите, а Вы прививались уже ?
>

Понятно. Еще и голосовать, небось, ходите. А ебанутый я. Действительно,
дичь какую-то несу.

[Const]

Vladimir Abaturov <v3...@mail.ru> wrote:
> Const <rent...@gmail.com> wrote:
> > Vladimir Abaturov <v3...@mail.ru> wrote:
> >> Почему не хочется? Разве не приятно, когда обычный sip-телефон нормально
> >> работает, rtp-трафик ходит без проксирования через сервер? Файлы льются и
> >> расшариваются без всяких там дропбоксов?
> >
> > Я, признаться, чего-то тут даже теряюсь.
> > Вроде слова какие-то знакомые.
> > Но смысла не вижу.
> >
> > Вы случайно не ебанутый ?

> Что тут непонятного? Мысль была предельно простая (хотя, не совсем в тему,
> да): при наличии у юзера нормального коннективити облака объективно не
> нужны.

Эта мысль мне недоступна.
Я не вижу абсолютно, совершенно никакой связи
между коннективити и облаками.
Более того, связь такая, буде она существовала бы,
имела бы обратные свойства, чем лучше коннективити -
тем привлекательнее облако.

> А ipv6 это нормальное коннективити обеспечивает. Можно хранить свои

Чё за блядская бессмысленная хуйня ?
Мне ipv4 обеспечивает совершенно прекрасную коннективити.
До совершенно ненужных практически пределов.
Более того, никакой связи между системой адресации
и коннективити вообще не существует.

И я просто вынужден повторить свой вопрос.
Вы ебанутый ?

> данные у себя, обрабатывать у себя и с себя расшаривать, при нынешних-то
> дурных интернетах и вычислительных мощностях. Но как же? Все устройства
> голой жопой в интернет, это опасно. Гораздо безопаснее доверить все не
> пойми кому.

То есть, все-таки Вы какой-то невменяемый мудак.

Во Всемирную Лигу Сексуальных Реформ пробовали писать ?

> >> Сейчас засилье HTTP отчасти именно из-за того, что кроме него через нат
> >> почти ничего без костылей (fixup) не работает, да и с костылями работает
> >> как повезет.
> >
> > А я-то думаю, из-за чего же это засилье http.
> >
> > Скажите, а Вы прививались уже ?

> Понятно. Еще и голосовать, небось, ходите. А ебанутый я. Действительно,
> дичь какую-то несу.

Да, несете.
Абсолютную дикую бессвязную дичь.

Но не ссыте.
У нас еще один тут есть такой, Кривицкий.
Только он чутка поумнее, хотя приблизительно
такой же, э, альтернативно умный.

Если Вы его убедите - он Вам поможет.

---
Const

[Vladimir Abaturov]

Сами вы блядская бессмысленная хуйня. Идите лесом. Надо мне больно вас в
чем-то убеждать.

Мнение я свое высказал, другие мнения тоже услышал. Тема эта исчерпана,
думаю.

[Slawa Olhovchenkov]

Const <rent...@gmail.com> wrote:

C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> >> >> >> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

>> >> >> C> Это с чего бы это ?

>> >> >> потому что это удобно.
>> >> >> а делать себе неудобно -- удел идиотов и икутых.

>> >> C> Тебя трудно понять.
>> >> C> После разбора - да, конечно, будет.
>> >> C> Но разбор до'рог - это раз.

>> >> да не дорого он.
>> >> у тебя есть мета в виде jsonа в начале файла.
>> >> ты ее парсишь и генеришь условный байткод для себя (как вариант -- массив/список указателей на функцию которую надо сейчас вызвать и возможно какие-то дополнителльные аргументы).
>> >> когда читаешь данные используешь этот условный байткод из которого и следует что
>> >> следующее значение идет в такое-то поле, или у тебя появляется массив. или рождается

>> C> Вот чтобы понять, куда оно идет или нет - мне нужно сравнивать ключи.
>> C> Длинные.
>> C> All the time.

>> нет. порядок ключей у тебя фиксирован в схеме и дальше транслируется в байткод.
>> в самом пайлоаде ключей нет, только данные.

C> Слава, мы чего-то тут где-то кардинально расходимся.

да, похоже.

C> Во-первых, я не понимаю, какой нахуй байткод.
C> Это с-программа, которая спускается по дереву, для каждой записи.

байткод можно сделать в любой программе.

возможно лучше перейти к конкрентым примерам?

--
Slawa Olhovchenkov

[Victor Alekhin]

On 14/04/21 11:32, Slawa Olhovchenkov wrote:
> Const <rent...@gmail.com> wrote:
>
> C> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>>>>>> поле, которе ты хочешь найти, будет у тебя лежать по фиксированному смещению.

> C> Слава, мы чего-то тут где-то кардинально расходимся.
>
> да, похоже.
>
> C> Во-первых, я не понимаю, какой нахуй байткод.
> C> Это с-программа, которая спускается по дереву, для каждой записи.
>
> байткод можно сделать в любой программе.
>
> возможно лучше перейти к конкрентым примерам?
>

Хм, от меня тоже что-то ускользнуло, какой нахуй байткод?
Старопердунство, это, наверное, заразно :-)
Ну давай пример