Здравствуйте, Sharov, Вы писали:

Pzz>>9. Firewall не нужен. Но право пользоваться сетью должно быть привязано к каждой программе, которой это нужно, и выдаваться ей путем явного запроса разрешения у человека

S>От эксплойтов как будете защищаться?

Firewall не пропускает пришедшие пакеты на какой-то порт, или не выпускает их наружу. Однако если нет никакой программы, которая слушала бы на этом порту, firewall не делает ничего.

Поэтому просто не надо выпускать в сеть программы, для этого не предназначенные. А предназначенные все равно должны внутренне защищаться, firewall им ничем не помогает.

Здравствуйте, Sinclair, Вы писали:

S>>Если не правильно составил запрос -- логическая ошибка, как типизация поможет?
S>Точно так же, как она помогает в обычных языках. Это в K&R С можно было перепутать местами адрес строки и номер позиции в ней, и компилятор бы и бровью не повёл.
S>Современный C зачем-то отличает char* от int.

Как это поможет в случае когда я умножил на 2, а надо было на 5? Если ошибся с условием запроса и выбрал не то? А в остальном sql вполне типизированный язык запросов -- объдинить(union) курицы и яйца не получится.

Здравствуйте, lpd, Вы писали:

WH>>Я её своими глазами видел. Итаниум вообще сдох из-за этого.
lpd>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.

Линух для итаниума, насколько я помню, был. Потом поддержку викинули за ненадобностью.

Здравствуйте, lpd, Вы писали:

lpd>У ARM есть как значительные плюсы, так и некоторые минусы на мой взгляд неспециалиста(сложности с инициализацией констант и длиной branch). Не думаю, что популярности ARM на серверах мешает отсутствие софта.

У ARM'а основной рынок — смартфоны и т.п., и соответствующие решения при проектировании: экономить электричество, теряя в производительности. В частности, у ARM'а довольно маленькие кэши, на что в телефоне начхать, а на сервере может быть и не начпать, в зависимости от того, что делает этот сервер.

Именно это мешает популярности ARM на серверах: то, что он не под них разрабатывался.

Здравствуйте, Terix, Вы писали:

T>>>Ну как минимум одно достоинство у них всё-таки есть. В utf-8 cимвол по номеру в строке ищется за константное время,только если он английский. C utf-16 это распространяется на большинство языков, а с utf-32 — вообще на всё.

N>>Стандартная и грубая ошибка. Символ ты так не найдёшь. Ты найдёшь кодовый пункт. Символ может иметь модификаторы. Чтобы их достоверно подключить, всё равно надо вызывать умную читалку, которая по таблице свойств будет проверять, что идёт за первым пунктом. Если ты этого не делаешь, твой код тупо некорректен.

T>Для utf-16 есть вроде набор языков символы которых ложатся в 2 байта, как latin1 в utf-8. То есть если знаешь точно, что у тебя в строке символы одного из этих языков — можно за константу выбирать.

Увы, нет. Например, É (U+00C9) vs. É (U+0045 U+0301). Это таки злобный привнос Unicode по сравнению с 8-битками. Даже в английском есть слова, которые принято писать с такими символами (типа, fiancé).
Ты можешь попытаться нормализовать это, но нормализация полезна только для сравнения (она убивает многие характеристики символов), но не для неразрушающего анализа.

T> И я думал, что в utf-32 всё лезет в 4 байта, кроме всякой нечисти типа эмодзи, но похоже это неправда.

Эмодзи как раз большинство лезет (хотя к ним есть модификаторы для смены фона... )

Здравствуйте, WolfHound, Вы писали:

WH>Это не правда. Даже C# очень много что ловит. А дафна ловит почти всё.

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

Что, врут?

Здравствуйте, Pzz, Вы писали:

Pzz>У ARM'а основной рынок — смартфоны и т.п., и соответствующие решения при проектировании: экономить электричество, теряя в производительности. В частности, у ARM'а довольно маленькие кэши, на что в телефоне начхать, а на сервере может быть и не начпать, в зависимости от того, что делает этот сервер.
Pzz>Именно это мешает популярности ARM на серверах: то, что он не под них разрабатывался.

Это постепенно меняется, ещё пару лет и перестанет быть критичным.

Здравствуйте, Pzz, Вы писали:

WH>>>Я её своими глазами видел. Итаниум вообще сдох из-за этого.
lpd>>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.

Pzz>Линух для итаниума, насколько я помню, был. Потом поддержку викинули за ненадобностью.

Не выкинули.
[code]
$ du -sk arch/ia64/
3912 arch/ia64/
$ grep -A2 ^VERSION Makefile
VERSION = 4
PATCHLEVEL = 15
SUBLEVEL = 0
[/url]

И наверняка работает и сейчас (мумии не меняются)

Здравствуйте, Pzz, Вы писали:

Pzz>Поэтому просто не надо выпускать в сеть программы, для этого не предназначенные. А предназначенные все равно должны внутренне защищаться, firewall им ничем не помогает.

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

Здравствуйте, netch80, Вы писали:

N>Это постепенно меняется, ещё пару лет и перестанет быть критичным.

Какая красивая плиточка!

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

Здравствуйте, Pzz, Вы писали:

Pzz>А я слышал, что хаскель ловит вообще все, и проще уговорить жену соседа сделать минет, чем уговорить хаскельный компилятор скомпилировать программу с ошибками.
Pzz>Что, врут?
Врут. Совсем всё не ловит никто.
Дафна ловит намного больше чем хаскель.

Здравствуйте, Sharov, Вы писали:

S>fw может же детектировать подозрительную активность и вроде даже немного траффик анализировать(сигнатуры эксплойта и проч.). Так вот, нашли уязвимость, патча нет. Не вырубать же бд для всех пользователей из-за потенциального взлома?

OK, убедил. Давай введем понятие домена, логически напоминающее понятие локальной сети, но с той разницей, что членство в домене зависит не от случайного соседства по сетевому проводу, а от того, приняли ли люди данное устройство в домен, или не приняли.

Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.

Здравствуйте, Pzz, Вы писали:

S>>fw может же детектировать подозрительную активность и вроде даже немного траффик анализировать(сигнатуры эксплойта и проч.). Так вот, нашли уязвимость, патча нет. Не вырубать же бд для всех пользователей из-за потенциального взлома?

Pzz>Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.

Это просто пример сервиса, выведенного наружу.

Здравствуйте, Pavel Dvorkin, Вы писали:

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

У твоей кофеварки должен быть логический адрес. не 05:ff:45:88:9a:e7, а "моя белая кофеварка".

Каким образом твоя стиральная машина познакомится с твоей кофеваркой (а кому еще с ней общаться по сети, как не стиральной машине?), это отдельный вопрос. Ну, например, ты поставишь один раз свою кофеварку на стиральную машину, и скажешь, "ребята, надо познакомиться", и они там между собой через какой-то условный NFC обменяются своими криптографическими идентификаторами — как эти идентификаторы выглядят, вообще не твое дело, они не для тебя предназначены. Ну или может кофеварку надо будет даже один раз постирать в стиральной машине, не суть. Но очевидно, что приемлимый способ знакомства зависит от физической природы вещей, которые надо познакомить между собой.

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

Вот этот вот временный транспортный адрес, наверное, должен выдаваться с учетом удобства иерархического роутинга. Только это все — богатая внутренняя жизнь сетевого стека, до которой тебе нет дела, если ты, конечно, не разработчик этого самого сетевого стека. А тебя интересует лишь, как одному физическому устройству показать пальцем на другое физическое устройство, чтобы они могли начать между собой коммуницировать.

Здравствуйте, Sharov, Вы писали:

Pzz>>Так вот, я не понимаю, зачем бд вообще иметь доступ к сети за пределами своего более-менее локального домена. В котором врагов нет.

S>Это просто пример сервиса, выведенного наружу.

И чем тебе фаирвол-то поможет, если ты выводишь сервис наружу?

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

Здравствуйте, lpd, Вы писали:

N>>Если бы переход на стиль ARM был прозрачен, Intel не цеплялась бы за совместимость с тараканами 8080. И даже если бы они сохранили свой CISC, им было бы значительно проще выкинуть кучу неактуального.
lpd>Не факт, что это legacy в Intel значительно замедляет процессор. Да, процессоростроители прилагают дополнительные усилия для поддержки 32-бит, потому что хотят иметь это конкурентное преимущество.

А 32 бита тут при чём? Как раз 32 бита в 64 не мешает. Мешают 16- и 8-битные команды, тем, что создают зависимости по регистрам. Мешают команды, которые требуют генерации длинных цепочек RISC-команд (как модификация аргумента в памяти). Мешают команды, которые не генерируются компиляторами (вроде rcl и xchg), но которые надо поддерживать ради чёртовой совместимости. Мешают целые устаревающие на глазах блоки вроде FPU.

lpd> Не считаю, что программисты и пользователи должны возиться с VM ради облегчения жизни Intel.
lpd>При большем числе конкурентов Intel процессоры могли бы подешеветь. Но вряд ли появились бы процессоры в разы быстрее.

Так и я не про скорость. Скорость сильно не разгонится. А вот цена операции в ваттах могла бы заметно сократиться.

lpd>У ARM есть как значительные плюсы, так и некоторые минусы на мой взгляд неспециалиста(сложности с инициализацией констант и длиной branch).

Длина условных переходов? Пары мегабайт недостаточно?
И что там такого особенного с константой, если это вполне удобно решалось даже на arm32 хранением константы рядом с функцией, а для arm64 ещё и альтернативно есть movk?
Эти две причины никак не противодействуют применению на серверах.

lpd> Не думаю, что популярности ARM на серверах мешает отсутствие софта.

N>>Софт именно что выглядит проблемой. В Debian фактически живёт только то, что поставляется в исходниках. Исключений мало и они, даже если принципиальны в своих узких областях, не делают общей погоды.
lpd>Еще раз: для Itanium 9 DVD Debian-пакетов. Для Linux все поставляется в исходниках, кроме отдельных исключений, не являющихся уникальными.

Какой смысл говорить "ещё раз...", если это то же самое, что я сказал? Вы вообще читаете, на что возражаете?
И что это меняет, если доля заранее скомпилированного минимальна?

Здравствуйте, Pzz, Вы писали:

N>>Это постепенно меняется, ещё пару лет и перестанет быть критичным.

Pzz>Какая красивая плиточка!

Pzz>Я так понимаю, такой камень интересно ставить туда, где сверхвысокая вычислительная производительность не столь уж и нужна, а вот вопросы охлаждения/энергопотребления и общей цены изделия играют роль. Не зря в статье говорится про облака — как известно, облака нынче живут не в небе, а в плотно набитых дата центрах.

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

Здравствуйте, netch80, Вы писали:

N>Так это типа первая долетевшая ласточка. Получат денег, ещё оптимизируют и уже сравняются с x86.

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

Здравствуйте, WolfHound, Вы писали:

N>>Не из-за этого, а из-за своей изначальной инвалидности.
WH>А инвалидность заключалась в том, что он исполнял х86ой код в 10 раз медленнее конкурентов.
WH>Все остальные проблемы интел бы решил в течении пары лет.

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

То, что при этом Intel ещё и был настолько самонадеян, что вместо нормального x86 засунул туда слабый эмулятор — заслуга облаковитателей, поддержанная маркетолухами. Сколько их тогда было — видно по историям с Rambus и NetBurst. Ну да, время такое — если бы пузырь доткомов не схлопнулся, они могли бы и проскочить ещё лет пять. Но не больше.

Фактически, они нащупали работающий подход к этим вопросам только в SandyBridge.

N>>Но остаётся вопрос принципиально разных архитектур (CPU vs. GPU) и оптимизаций под конкретное железо. А вот тут большая загвоздка — те, кто для конкуренции вылизывает даже 1%, не пойдут на тотальный AOT, потому что в нём всегда будет меньше гибкости. А таких достаточно много.
WH>1)И все они сливают вот этой штуке http://halide-lang.org/

Посмотрю, но не сегодня.

WH>2)Если очень хочется, то код можно заточить под конкретный процессор.

Можно.

WH>Создаём библиотеку примитивов процессора. И учим ВМ для этого процессора транслировать эти примитивы в соответствующие машинные коды.

А вот именно примитивы процессора могут быть перебором. Скорее тут надо точить под общий подход и конкретные количественные особенности, типа "любой векторный кратный 128 битам".

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, lpd, Вы писали:

N>Длина условных переходов? Пары мегабайт недостаточно?
N>И что там такого особенного с константой, если это вполне удобно решалось даже на arm32 хранением константы рядом с функцией, а для arm64 ещё и альтернативно есть movk?
N>Эти две причины никак не противодействуют применению на серверах.

Решения, конечно, есть: также можно загружать константы результатом вычисления нескольких инструкций, а для переходов делают несколько branch один на другой. Я не говорю, что это значительные недостатки — для программиста плюсы ARM перевешивают минусы, на мой взгляд.
Однако для повсевместного использования вместо Intel я не могу назвать у системы построенной на ARM больших преимуществ, кроме меньшего энергопотребления. Это не оказалось достаточным для перехода на ARM на серверах, и дело не в отсутствии софта(его достаточно). Видимо, дело в инертности нежелании менять то, что нормально работает и всем знакомо. Кроме того, в ARM шина AMBA больше подходит для embedded, чем для PC, насколько я понимаю.

N>Какой смысл говорить "ещё раз...", если это то же самое, что я сказал? Вы вообще читаете, на что возражаете?
N>И что это меняет, если доля заранее скомпилированного минимальна?

Я не понимаю, что ты имеешь ввиду: почему доля заранее скомпилированного минимальна?
Если ты имеешь ввиду бинарные пакеты, то в Debian мы видим 9+ DVD уже скомпилированого софта под каждую процессорную архитектуру.
Если ты подразумеваешь closed-source софт, то его вообще для Linux мало и он не уникален — есть open-source аналоги.
Это подтверждает, что софт в данном вопросе не является большим ограничением.

Вот если бы сделали процессор, который не просто архитектурно содержит меньше legacy, а еще и быстрее хотя бы на 50% и значительно дешевле, то под него вскоре появился бы софт — open source точно.
Думаю, VM vs native — скорее вопрос предпочтений. Кому-то идея VM нравится, кому-то нет. Лично я привык к ассемблеру x86/arm, и скорее предпочту переучиться на программирование под новую архитектуру процессоров, чем возиться с VM, даже если бы последнее помогло процессоростроителям создать немного лучший процессор.