Завершился саммит разработчиков Ubuntu Linux, на котором были приняты решения, касающиеся подготовки релиза Ubuntu 12.04 LTS и рассмотрены некоторые предложения по дальнейшему развитию проекта. Ниже представлена подборка интересных обсуждений.- Размер традиционного iso-образа для Ubuntu 12.04 решено (http://www.phoronix.com/scan.php?page=news_item&px=MTAxMTM) увеличить до 750 Мб, что позволит вместить дополнительные компоненты GNOME 3 и приложения, но сделает невозможной запись данного образа на CD. Мотивом такого шага является является устаревание CD как носителя информации, в настоящее время трудно найти систему, не поддерживающую DVD или Flash-накопители. По расчетам разработчиков 750 Мб является оптимальным размером, с учетом обеспечения комфортного для пользователя времени загрузки. Предложение (https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-dvd-...) по распространению по умолчанию DVD-образа размером 1.5 Гб, включающего все языковые пакеты и некоторые дополнит...
URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=32233
>64-разрядная сборка работает быстрееС чего бы это?
флеш
http://www.google.ru/search?gcx=c&sourceid=chrome&ie=UTF-8&q...
>> 64-разрядная сборка работает быстрее
> С чего бы это?С того что проц может смолотить int64 вместо int32 за одну команду. В 32-битном режиме на это же действо компилером будет построена целая этажерка действий, делающая их 32-битной математики 64-битную "уж как получится". А поскольку файлы, диски и что там еще нынче большие - int32 часто перестает хватать.
Не говоря о том что регистров в 64-битном режиме больше, поэтому в отличие от х86, где половина программы состоит из сохранения и восстановления регистров и всяких там пересчетов адресов при старте (режима относительной адресации у 32-битной х86 дряни тоже не было) - тут программа больше работает и меньше тягает туда-сюда стек, и код в произвольный адрез перебазируется просто копированием, без патчинга всей программы по немеряной таблице релокаций как это надо х86-му делать.
>режима относительной адресации у 32-битной х86 дряни тоже не былоПриплыли.
Эффективные менеджеры атакуют? Только одна гастроль, проездом из Сколково?
Воообще то набор команд Intel x86_32 это самый сложный за всю историю процессоров, в нем есть практически все что придумал воспаленный мозг за период 1969-2011гг. И не только относительная адресация.
Со времен Klamanch ( Pentium 2) этот код видимый программистом вообще не имеет смысла, потому как сам микропроцессор скрыт от глаз программиста блоком перекодировки. Внутри P2 на самом деле RISC-подобный процессор, систему команд которого скрывают с секрете, а при выполнении "86" кода его на лету перекодируют и оптимизируют во внутренний код ( uops ).
Так что и относительная адресация есть, и малый размер регистрового пула тоже сглаживается оптимизитором, по крайней мере для простых коротких циклов.
Ну и со времен P2 тоже времени немало прошло, ситуация на данный момент такая что вместо микропроцессора у нас многомашинный комплекс с некоторым перекодировщиком, и что там на самом деле происходит как выбирабтся команды и какие режимы адресации можно только догадываться.
> Приплыли.Всю ночь гребли, а лодку отвязать забыли?
> Эффективные менеджеры атакуют? Только одна гастроль, проездом из Сколково?
Не знаю, вам виднее.
> Воообще то набор команд Intel x86_32 это самый сложный за всю историю
> процессоров, в нем есть практически все что придумал воспаленный мозг за
> период 1969-2011гг. И не только относительная адресация.К чему здесь этот маркетоидный буллшит? В x86-32 нет адресации относительно текущего места выполнения (относительно текущего значения program counter-а).Наследственная болячка x86. Поэтому в х86 программах есть такой костыльный лулз как большая таблица релокаций. Потому что программу просто так нельзя загрузить по иным адресам нежели было задумано изначально. В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода. Можно только абсолютный адрес ткнуть. Который имеет свойство меняться, что очень доставляет. Для того чтобы все-таки вгрузить программу в адреса отличные от дефолтных - загрузчик программ ОС читая программу до кучи разбирает таблицу релокаций (отдельная секция выполняемого файла) и на ходу патчит все адреса которые ссылаются на абсолютные адреса, пересчитывая все ссылки по абсолютному адресу под новый базовый адрес, отличный от исходного. Стоит ли говорить что фокусы типа ALSR при которых как раз программы грузят в разные адреса каждый раз, чтобы усложнить хакинг - тормозят загрузку этих самых программ, потому как приходится постоянно педалить огромные таблицы и на ходу хакать полпрограммы в памяти. В нормальных процессорах давно уже сделаны режимы адресации относительно текущего места выполнения. При этом не важно в какой адрес грузится программа - патчить ничего не надо: если сказано "от сих 60 байтов вперед" - при этом не важно какой там базовый адрес был.
> Со времен Klamanch ( Pentium 2) этот код видимый программистом вообще не
> имеет смысла, потому как сам микропроцессор скрыт от глаз программиста блоком перекодировки.Капитан информирует что на самом деле, microcode ROM - это неотъемлимая часть CISC-процессора. Этот ROM разваливает сложные команды CISC в более простые RISC-образные субкоманды для относительно простых блоков выполнения. Так было даже в 8086, просто менее явно светилось наличие микрокода и он был не обновляемым. Обновляемым его сделали после парочки годных фэйлов с Pentium (первым). Где часть камней пришлось пустить под пресс и бесплатно заменять, потому что во первых вылезла ошибка вычислений, а во вторых - определенная последовательность байтов намертво вешала проц, поэтому даже самый бесправный юзер в операционке мог поставить колом все вокруг. Интел высрал гору кирпичей и где-то немного опосля сделал microcode ROM обновляемый (биос содержит эти файлики, также они иногда встречаются отдельно, Linux умеет их вгружать в проц, если они у вас есть). Поэтому часть ошибок дизайна стало можно чинить после выпуска проца и не пуская его под пресс. Но на самом деле microcode ROM придумал не интел, это почти стандартная часть дизайна CISC. Просто потому что сделать блоки выполнения в которые напрямую можно пхнуть сложные CISC команды - очень сложно. И багов в них будет немеряно. А поскольку все это в железе - сколько процов пойдет под пресс? Microcode ROM упрощает дело, переводя по таблице сложные команды в простые для куда более простых блоков, типа обычного простого ALU и прочих. Вроде были психи которые пробовали делать в своих процах декод CISC команд прямо в железе, без перекодирующего ROM, но они потерпели дружный FAIL в силу нетривиальности затеи и сложности блоков. И в итоге все такие давно самовыпилились.
> Внутри P2 на самом деле RISC-подобный процессор, систему команд которого
> скрывают с секрете, а при выполнении "86" кода его на лету
> перекодируют и оптимизируют во внутренний код ( uops ).На самом деле - ничего нового там нет. Висит декодер, разваливающий (не без помощи microcode ROM) сложные CISC команды в RISC-подобные команды. RISC зачастую представляет собой то же самое, только декодер оторван, а упрощенный набор команд подается в блоки без преобразований через microcode ROM. Логично что ядро RISC априори проще ядра CISC. Потом дошло что можно в принципе пихать и побольше одинаковых блоков за декодер, так что за раз сможет выполняться и более одной команды.
Основная проблема всего этого: программам и компилерам не видно что там внутри. Поэтому оптимизация из очевидного действа превращается в то еще разгадывание ребусов архитектуры и укладывание костылей и подпорок.
> Так что и относительная адресация есть, и малый размер регистрового пула тоже
> сглаживается оптимизитором, по крайней мере для простых коротких циклов.На самом деле сглаживается оно в основном умным кешированием, так что стек первым делом оседает в кеше и не покидает его. Но это не отменяет того факта что даже так проц занимается глупой тасовкой регистров в стек и обратно (суммарный эффект от push + pop равно NOP, т.к. бесполезная служебная операция никак не связанная с реализацией логики программы). А вот х64 с его кучей регистров намного чаще может посчитать все вообще не лазя в стек. Там даже ABI построено так, что часть регистров - для передачи параметров в функцию, часть для локальных рассчетов, часть для возврата результата. На все хватает, в отличие от х86 уродца, который в этом месте обтасуется регистрами. Ну по крайней мере в типовых случаях. В том числе и поэтому часто дергаемые функции с 20 сложными параметрамми - плохая идея (если не хватит регистров - придется пушить в стек).
> Ну и со времен P2 тоже времени немало прошло, ситуация на данный
> момент такая что вместо микропроцессора у нас многомашинный комплекс с некоторым
> перекодировщиком, и что там на самом деле происходит как выбирабтся команды
> и какие режимы адресации можно только догадываться.Наружу вывешивается система команд х86. И потому - не важно что там внутри, танцевать приходится по этим правилам. Воспользоваться преимуществами указанного комплекса, даже если б они были - нельзя. Потому что рукояток наружу нет. И если вы в системе команд х86 не можете адресоваться относительно текущего места кода, вы это не можете и все тут. Это ограничение системы команд, а как система команд внутри реализована - да какая разница вообще?! Вы все равно за пределы возможностей системы команд не прыгнете. В х64 это тупое упущение исправили, сделав наконец относительную адресацию, как во всех нормальных процах. Которую, блин, программы, компилеры и программеры могут явно юзать на свое благо. Поэтому если мы хотим сгененить position-independent code - мы наконец то можем это делать и без отсыла в немеряные таблицы релокаций! Алилуя!
Знаний по архитектуре микропроцессоров у меня маловато (надо было Таненбаума читать и др. литературу по этой теме), но все же кое что я понял. Спасибо за такие подробные разъяснения. :)
Спасибо. Такие посты компенсируют месяц чтения комментов.
что за чушь про отсутствие команд относительной адресации в x86?
Ну "спец" же =) Вроде одни преумущества, но на практике 32-х битный (generic) код довольно часто почему-то быстрее 64х-битного: то ли лишний уровень в TLB даёт о себе знать, то ли префиксы кодманд и адресность становятся бутылочным горлышком для декодера - неизвестно, т.к. "спец" решил об этом умолчать =)
майн гот! относительная адресация еще в 70ч бфла реализована на процессорах DEC - еще 30 лет назад они по гибкости переплевывали х86 уродов
> майн гот! относительная адресация еще в 70ч бфла реализована на процессорах DEC
> - еще 30 лет назад они по гибкости переплевывали х86 уродовх86 в 32-битном режиме таскает за собой наследие ранних 80х. Например, почему интел не сделал нормальный набор регистров в 32-битном режиме - загадка природы. Так и был куцый уродец, пока не пришел АМД...
> х86 в 32-битном режиме таскает за собой наследие ранних 80хМожет быть потому что ia32 начали разрабатывать в этих ранних 80x? Вы об этом не задумывались?
> Может быть потому что ia32 начали разрабатывать в этих ранних 80x? Вы
> об этом не задумывались?Почему-то примерно в те же времена существовала куча других, более осмысленных архитектур. До создателей которых в частности дошло что полтора регистра на которых надо делать всю арифметику - не есть гуд.
> Ну "спец" же =) Вроде одни преумущества, но на практике 32-х битный
> (generic) код довольно часто почему-то быстрее 64х-битного: то ли лишний уровень
> в TLB даёт о себе знать, то ли префиксы кодманд и адресность становятся
> бутылочным горлышком для декодера - неизвестно,Не думаю. Декодер успевает распихивать команды на кучи блоков, изображая "как-бы 8-ядерный" х86 и прочие гипертрединги, так что в результате роялит именно распределение нагрузки на блоки, которые находятся за ним. Поэтому врядли он является узким местом. Например, недавний тест фороникса очень недвусмысленно демонстрирует поведение бульдозера, при том это поведение формируется распределением нагрузки на блоки. Ну то-есть скорость целочисленных операций перестает существенно расти после того как закончатся неозадаченные целочисленные блоки, что ожидаемо, ну и так далее ;). Гипертрединг тоже похоже преследует цель догрузить блоки за декодером. На изображение полноценного честного ядра конечно остатков возможностей блоков не хватает, но свои 15-20% на сильно многопоточных случаях получить все-таки удается. С чего бы быть хоть какому-то приросту, если в декодер все уткнулось?
> т.к. "спец" решил об этом умолчать =)
Не, плюсов совсем без минусов не бывает. Еще и код и данные жирнее, значит реже будут в кеш попадать целиком. С другой стороны, кеши нынче у х64 процов весьма жирные и наврядли это сильная проблема в большинстве случаев. И в целом по шинам надо передавать несколько больше данных, и это может упереться и в оперативку и в размер кеша. Ну и оперативку нынче понапихали многоканальную, с нехилым бандвизом. Наверное не для красоты.
Понятно что в целом есть возможности проиграть 32-битному коду в некоторых случаях. С другой стороны, годный алгоритм критичный к скорости - должен быть не сильно жирным и целиком влезать в кеш, а когда это случилось, наличие 64-битной арифметики, кучи регистров и гарантированное наличие SSE2 вполне могут обеспечить победу.
>Декодер успевает распихивать команды на кучи блоков
>Поэтому врядли он является узким местомАгнер Фог с вами несогласен, определённо, ознакомтесь с его "The microarchitecture of Intel, AMD and VIA CPUs"
>С другой стороны, кеши нынче у х64 процов весьма жирные и наврядли это сильная проблема в большинстве случаев.
x86_64 это ещё и x86_32, поэтому при прочих равных кеша в 32-х битном режиме больше
>вполне могут
лишь при наличии специфических вычислений, во всех остальных случаях - 32бита как правило быстрее
> лишь при наличии специфических вычислений, во всех остальных случаях - 32бита как
> правило быстрееПрактики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности (меньше нагрузка на CPU).
>Практики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности (меньше нагрузка на CPU)не вижу доказательств, - стоит ждать? :)
> не вижу доказательств, - стоит ждать? :)Зачем ждать? gcc -m32, gcc -m64, и вперёд.
> Практики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности
> (меньше нагрузка на CPU).core 2, основаные на conroe и сотоварищах, в x64 были медленее чем x86. Особености декодера и криворукость разрабов в amd, из-за чего в среднем длина комманды в x64 больше чем в x86 благодаря куче всяких новых префиксов.
Так что не надо тут ляля.
> core 2, основаные на conroe и сотоварищах, в x64 были медленее чем
> x86ЛПП отдельных продуктов отдельных вендоров мне мало интересны.
В сумме у меня на всех площадках прирост есть, он не может не есть.
Банальная пересборка пыха под x86-64 на хостингах высвобождает до 15% ресурсов.
> среднем длина комманды в x64 больше чем в x86А еще там адреса 64-битные - потоки данных в среднем больше. Но нынче и оперативка стала многоканальной, а кеши большими. Поэтому указанный факт изрядно нивелирован. Вон GPU вообще например успевают пачку VLIW-ов огроменными командами прокормить, и ничего, никто не бухтит что у VLIW команды слишком большие.
> Агнер Фог с вами несогласен, определённо, ознакомтесь с его "The microarchitecture of
> Intel, AMD and VIA CPUs"Реально эпичнейшая дока! Хоть частично и основанная на малопроверенных фактах и потому воспринимаемая с осторожностью. Те кто верит в инопланетян и неизвестно что работающее в проце - срочно читать!
> что за чушь про отсутствие команд относительной адресации в x86?Да нет никакой чуши - у x86-32 нет адресации данных относительно program counter.
>> что за чушь про отсутствие команд относительной адресации в x86?
> Да нет никакой чуши - у x86-32 нет адресации данных относительно program
> counter.Еще один.
У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.
У интела вообще вся адресация относительная.
Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.
>Еще один.верующий
> Еще один.
> У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.А это СОВСЕМ НЕ ТО. Когда говорят о относительной адресации, как правило имеют в виду адерсацию относительно текущего места выполнения (смещение относительно значения Program Counter в данный момент).
Зачем именно так? А чтобы можно было писать позиционно-независимые программы. Которые не делают _никаких_ допущений о том в каких адресах они работают. В случае сегментных регистров - без допущений уже не выходит, да? Федот, да не тот.
> У интела вообще вся адресация относительная.
У интела вообще вся адресация с сегментами - одно большое извращение. Плоская модель памяти рулит. Хотя у некоторых процессоров бывают и режимы явно ориентированные на работу с массивами и прочими, по типу mov R4, [R5+30], это по крайней мере менее похабно и более логично выглядит, но относительной адресацией в ее обычном понимании - не является.
> Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.
Да, хреново дело: вы не понимаете того простого момента что цель относительной адресации это как правило удобная генерация позиционно-независимого кода, не делающего никаких допущений о адресах и просто работающего одинаково, куда ни загрузи. А вот с этим у интеля по жизни было паршиво.
Сплошной поток мантр и заблуждений, даже читать до конца не хочетсяУсловные/безусловные переходы могут быть относительными, даже имеются короткие формы в случае близких(-128/+127) переходов, call инструкция с опкодом E8 тоже производит вызов по относительному смещению - это любой ассемблерщик знает, которым вы, и это очевидно, не являетесь
> Сплошной поток мантр и заблуждений, даже читать до конца не хочетсяДавайте прервём этот поток:
У x86 ЕСТЬ относительная адресация по смещению от EIP, или НЕТ?
Вот и всё.
Так какбе всегда было:> INTEL 80286 PROGRAMMER'S REFERENCE MANUAL 1987
> ...
> 3.6.1.1 Jump Instruction
> ...
> Direct JMP within the current code segment. A direct JMP that transfers control to a target location within the current code segment uses a relative displacement value contained in the instruction. This can be either a 16-bit value or an 8-bit value sign extended to 16 bits. The processor forms an effective address by adding this relative displacement to the address contained in IP. IP refers to the next instruction when the additions are performed.Здесь оно называется "прямым переходом", но по сути это то, о чём говорил Аноним - относительное смещение _добавляется_ к IP.
Блин, как же всё плохо. Direct JMP - это ни фига не "относительная адресация". Это регистровая операция сложения ADD IP/EIP,imm.
>>> что за чушь про отсутствие команд относительной адресации в x86?
>> Да нет никакой чуши - у x86-32 нет адресации данных относительно program
>> counter.
> Еще один.
> У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.
> У интела вообще вся адресация относительная.
> Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.ВСЕ ГОРАЗДО ХУЖЕ чем здесь кажется. Еще 3-5 лет таких инженеров повыпускают и нас даже завоевывать не нужно будет - они и так все всем отдадут со 100% уверенностью что так было всегда. :-(
Я тебе сказал, что еще в П2 УЖЕ НИКТО НЕ ЗНАЕТ КАК НА САМОМ ДЕЛЕ РАБОТАЕТ ПРОЦЕССОР.Кажется, что он что то адресует, что то записывает, что то читает. Ходят слухи (СЛУХИ!) что исполнение команд организовано по типу RISC. Слухи. На основе маркетоидного бреда.
Может быть там RISC. Может не RISC а какой то хитрый VLIW, или 100 нод 4 битного транспьютерного хренпойми как соеждиненного между собой массива. Почему нет? Этого НИКТО из не посвященных не знает.
Сейчас ни у кого нет П2.
Время прошло.
Что там сейчас - это лютый писец, я уверен даже имея послойно снятую топологию уже не разобраться за лет 20, а к тому времени они выпустят еще более сложную хрень. Просто посчитай какую площадь на бумаге займет чертеж одного слоя кристалла i5 2500.
Так что, фантазируй что угодно, а факты вещь упрямая.
Кстати если уж так сильно чешется, не подскажешь команду как там прыжок на небольшие расстояния делается? Ась? Относительный вы наш.
> Сейчас ни у кого нет П2.Прикинь у меня есть )))
Используем на работе П2 и в ноуте и на "сервере" (вариации убунт)
> Я тебе сказал, что еще в П2 УЖЕ НИКТО НЕ ЗНАЕТ КАК
> НА САМОМ ДЕЛЕ РАБОТАЕТ ПРОЦЕССОР.Да какая нахрен разница, как он там внутри работает? Снаружи то с ним можно работать лишь с тем набором команд (и ограничениями оного) которые вывешены нам. И если в этом наборе команд чего-то нет, этим не удастся воспользоваться. Представьте себе что у вас есть авто. У него замечательный двигатель, все дела. Только вот нет руля. Поэтому ездить можно только вперед и назад. Сильно ли вас при этом волнует тип двигателя? Какая разница, электрический он, дизельный или бензиновый? На возможность совершения поворотов это вообще не влияет.
> Кажется, что он что то адресует, что то записывает, что то читает.
> Ходят слухи (СЛУХИ!) что исполнение команд организовано по типу RISC. Слухи.
> На основе маркетоидного бреда.А это уже не важно. Потому что вы имеете дело с х86 "интерфейсом к процессору". Ну такой вот "пульт управления". И если в рамках этой системы нельзя указать процу "загрузи мне в регистр вон то число в 60 байтах впереди от текущего места" - это нельзя указать и все тут. При этом совершенно не важно, кто там "бэкэнд", потому что независимо от его типа, его нельзя проинструктировать сделать нужную операцию.
> Может быть там RISC. Может не RISC а какой то хитрый VLIW,
> или 100 нод 4 битного транспьютерного хренпойми как соеждиненного между собой
> массива. Почему нет? Этого НИКТО из не посвященных не знает.Да опять же - это по-фи-гу. Наружу вывешен интерфейс "я тут типа х86 процессор". Все взаимодействие - через него. Если через этот интерфейс чего-то сделать нельзя, очевидно, какой бы крутой бэкэнд там ни был, мы не сможем его проинструктировать в нужном виде. И он не сможет сделать нужную операцию независимо от своей крутизны. Нужной рукоятки то нет.
> Сейчас ни у кого нет П2. Время прошло.
И что? Если уж на то пошло, коры - это внучек ядра пентиум3. Когда Netburst ака пень4 себя дискредитировал и вчистую проиграл атлонам, из загашников был раскопан старый добрый пентиум 3. После вдувания порции стероидов это обозвали кором, и до сих пор обзывают. А изменения в основном количественные. Потоньше процесс? Побольше блоков выполнения воткнем! Побольше кешатины. И т.д. - и вот уже немолодой дизайн разгоняется до космических скоростей. А чего б ему не разогнаться, если блоков донавесили, частоты задрали, кеша целые мегабайты воткнули?
> Что там сейчас - это лютый писец, я уверен даже имея послойно
> снятую топологию уже не разобраться за лет 20,А производители не особо скрывают общую идею чипов, да и анализ чипов на общем уровне "вот тут у нас это, а вот тут это" - не так уж сложен. Это же не потранзисторный анализ с целью копирования 1 в 1 а общий анализ какие блоки есть. Производители даже порой не стесняются сами расчертить кристалл на фото на блоки и показать в презенташках в самом общем виде какие блоки где. Это позволяет понимать общее устройство конструкции и как с ней оптимальнее работать, но не позволяет скопировать 1 в 1.
> а к тому времени они выпустят еще более сложную хрень. Просто посчитай какую площадь
> на бумаге займет чертеж одного слоя кристалла i5 2500.К чему эта "умная" фраза вообще?
> Так что, фантазируй что угодно, а факты вещь упрямая.
Единственный момент где я слегка присвистнул (и задетектил это) - как тут верно заметили, у х86 все-таки есть относительная адресация переходов, хоть и убогая, но формально я все-таки был там не прав. Но у х86 напрочь нет относительной адресации данных. В наборе команд. При этом не важно какой "бэкэнд" будет выполнять этот набор команд: фичи нет в самом наборе команд. Ну и воспользоваться ей по этому поводу нельзя. Независимо от того что там за декодер впихнут. Какой двигатель в авто не пхай, если нет руля, то и поворачивать не сможешь. Независимо от того какой двигатель обеспечивает езду.
> Кстати если уж так сильно чешется, не подскажешь команду как там прыжок
> на небольшие расстояния делается? Ась? Относительный вы наш.Там уже подсказали, вплоть до опкода. Только вот:
1) Это только на малые дистанции. Не уложились? Будет абсолютный адрес (и его пересчет). У других архитектур лимиты бывают и больше. Но формально, камень в огород принимается.
2) Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter. Ну нету их у х86. При этом не важно какой там пепелац за декодером: его нельзя проинструктировать сделать это на уровне набора команд. Глупо, но факт.
Еще раз.Ты сказал, что x86_64 лучше чем i386(i686) потому что:
- есть относительная адрасация (в отличие от).
- больший пул регистров и сами регистры длиннее, а так же появились исполнительные устройства которве изначально спроектированы для оаботы с 64 битными данными (предположим это на саомм деле так, хотя какая разница 1 устройство с огромной площадью за такт умножающее 2 64 битных числа или 2 утсройства с 1/4 площадью делающих то же за 2 такта но тактируемые в 2 раза чаще)Со вторым спорить не стал, хотя там есть один подводный камень - вся радость увеличения регистрового пула только писателям компиляторов. Задача раскидывания переменных по регистрам она порядка NP, решается оптимально толко полным перебором, и если железо поддерживает больше регистров то это немного сглаживает принципиальную неоптимальность АЛГОРИТМА ОПРИМИЗАЦИИ КОМПИЛЯТОРА. К железу и скорости выполнения это никак не относится. Но факт есть - если больше регистров, то программы будут быстрее выполняться. Поправка только - это не недостаток архитектуры i3(6)86, а недоразвитость теории алгоритмов и компиляторов.
Но тут появилась 'относительная адресация'. Все, финиш.
В 4004 и ранних вариантах логики в программируемых калькуляторах еще можно было о чем то говорить, но СЕЙЧАС? Это что, троллинг такой?
Относительная адресация говорит об одном - что у этого процессора в отличие от предыдущих
есть еще один сумматор, который на лету добавляет к адресу содержимое другого регистра. Любого. Этим изобретением гордились в 60 года, "... и это еще не все, наш микропроцессор не только стирает и раскладывает носки по парам, но и имеет - вы только представьте - относительную адресацию ! Наши инженеры добавили еще дно уникальное устройство сложения, теперь для часто упортебляемой комбинации вы можете сразу выбрать смещение из кода операции и ОДНОВРЕМЕННО сложить с базовым регистром, ОТНОСИТЕЛЬНО которого вы и адресуетесь"Считаем.
Таблица страниц - 1 сложение с маскированием не считая проверки флагов и прочее.
Нахождение рального адреса путем суммирования базового регистра и смещения - еще 1.Итого - Любая адресация у интела ОТНОСИТЕЛЬНАЯ. Причем минимум ДАВЖДЫ ОТНОСИТЕЛЬНАЯ Любая. Из за сегментных регистров, и тем более таблиц виртуальной памяти MMU.
Более того, есть еще и ТРЕТИЙ УРОВЕНЬ по пути к физичемкому регистру - есть специальные коды операций, в которых под 3 битное поле регистра, ОТНОСИТЕЛЬНО которого идет выборка данных, эдакий "аппаратный ускоритель для доступа к массивам и структурам по смещению от их начала". Там адресация IP не предусмотрена. А ЗАЧЕМ нам адресовать в коде чтото относительно регистра программного счетчика? Мы уже не Гарвардскую архитектуру имеем? У нас что, допотопная Лента Тьюринга? Мы пишем самомодифицирующийся код который на лету меняет сам себя? Зачем выбирать данные в трехуровневой сегментноф стековой машине с физически разделенной памятью команд и данных отностиельно команд?
Итог - любой интеловский процессор имеет минимум 2 кратно относительную адресацию. Двухкратно, а для некоторых случаем и трехкратную.
И уж совершенно ненусветная глупость говорить что это как то ускоряет или замедляет, с чего собственно началось.
> Еще раз.
> Ты сказал, что x86_64 лучше чем i386(i686) потому что:
> - есть относительная адрасация (в отличие от).Да. Правда про выполнение я приврал - там все-таки номинально относительная адресация есть. Тупая (маленький диапазон смещений), что делает ее трудноюзабельной, но номинально я все-таки не прав. А кроме этого есть еще работа с данными. А вот с этим у х86 все еще хуже. Для тех кто тупит, поясняю: общепринято понимать под относительной адресацией адресацию по смещению относительно текущего значения program counter. По уму должно быть реализовн и для кода и для доступа к данным, иначе без диких костылей в позиционно-независимой программе не обойтись. Особенно смешно с учетом того что в современных реалиях очень желательно чтобы весь код такой и был, чтобы ALSR можно было делать просто и быстро, на радость хакерам (брутфорсить 2^64 адресов, особенно по сети - прикольное занятие).
> но тактируемые в 2 раза чаще)
Тактируется оно одинаково. А огромный там в основном кеш. Сомнительно что замена 32-битных ALU на 64-битные сильно меняет картину.
> Со вторым спорить не стал, хотя там есть один подводный камень -
> вся радость увеличения регистрового пула только писателям компиляторов.Да в общем то и програмеру, если ему приперло вот в именно этой пяди кода отыграть максимум, так что до асма снизошли - трах с полутора неравноправными регистрами х86 и их постоянным пушпопом совершенно не в кассу. А в кучке 64-битных регистров многое можно посчитать и без пхания промежуточных результатов в стек. В операциях регистр-регистр тормозить просто нечему, так что в лучшем случае регистровая математика пойдет на полной скорости которую вообще в принципе способен развить проц. А х86 неизбежно тормознется лишними пушпопами, которые как ни крути лишние команды, подлежащие выполнению + лишние доступы в память, хотя-бы в кеш. Вариант когда все удалось сделать чисто на регистрах - как правило самый ядреный. В основном потому что процу все регистры доступны в пределах того же такта и без дополнительных условий и оговорок.
> Задача раскидывания переменных по регистрам она порядка NP,
> решается оптимально толко полным перебором,Теория это здорово, но на практике достаточно посмотреть на то чем отличается х86 ABI от x64 ABI и прикинуть что на х64 вызов типовой функции с 1-2 параметрами и 1 результатом на выход выглядит в виде асма явно менее уныло чем пачка PUSH всего и вся а потом POP всего и вся на х86 ;)
> и если железо поддерживает больше регистров то это немного сглаживает принципиальную
> неоптимальность АЛГОРИТМА ОПРИМИЗАЦИИ КОМПИЛЯТОРА.Избыточные PUSH + POP не может быть оптимальным, т.к. это не часть логики программы а лишь технический костыль в ситуации когда "пороху^W регистров не хватило". Все переменные программы заведомо не влезут в куцые регистры х86.
Кстати в целом для компилеров (и програмеров :D) идеальным вариантом был бы проц с бесконечным числом регистров. Тогда можно засунуть практически все переменные в регистры и крайне быстро с ними всеми работать, вообще никогда не сохраняя в стек ничего. Правда, поскольку бесконечное число регистров сделать не получается, компилер вынужденно укладывается в тот бюджт который есть. Чем больше регистров - тем ближе к идеалу, когда все переменные максимально быстрые, а стек вообще насиловать не надо.
> К железу и скорости выполнения это никак не относится.
К железу напрямую относится сколько переменных удастся запихать в быстрые регистры и работать потом с ними быстрыми регистровыми операциями с минимальной латентностью. И сколько придется насиловать стек, разбавляя полезный код реализующий логику программы бесполезными пушпопами, суммарный эффект от которых равен нулю, а их втыкание обусловлено фактом "ой, блин, стало некуда считать - придется отложить в стек и расчистить регистры".
> Но факт есть - если больше регистров, то программы будут быстрее выполняться.
> Поправка только - это не недостаток архитектуры i3(6)86, а недоразвитость
> теории алгоритмов и компиляторов.Не, извини, дяденька, здравый смысл подсказывает, что если в алгоритме есть 10 переменных с которыми хочется одновременно делать интенсивно математику, хорошо если все 10 попадут в 10 независимых регистров, немедленно доступных процу на том же такте и допускающих математические операции. Тогда с ними удастся поработать быстро и без изгалений. Лобовыми математическими операциями с регистрами. А если регистров будет меньше, придется совершенно непроизводительно тасовать переменные между стеком и регистрами по причине "на всех регистров не хватило". Лишние пушпопы ну совсем никак не могут производительность добавить. На х86 компилеры усираются, пытаясь впихнуть в эту куцую хрень ну хоть чего нибудь. Оптимально раскидывать полтора регистра? Хаха, смешно. На х86 их постоянно приходится "оптимально" сливать в стек и доставать обратно. Чтобы вообще иметь возможность хоть чего-то считать. Ибо если регистр уже занят ценным промежуточным результатом, считать в нем что-то еще без потери результата уже как-то не получится, и надо его сохранить, да?
> Но тут появилась 'относительная адресация'. Все, финиш.
Ага, вот только чей?
> В 4004 и ранних вариантах логики в программируемых калькуляторах еще можно было
> о чем то говорить, но СЕЙЧАС? Это что, троллинг такой?Архитектура системы команд х86 настолько уныла что вполне заслуживает быть обтролленой. Пережитки идиотизмов чуть ли не времен 8080 лезут из всех щелей. Один из таковых - куцый набор регистров. Все более современные процы давно уже сделали выводы о том как компилерам и програмерам лучше. Ну а интел как обычно.
> Относительная адресация говорит об одном - что у этого процессора в отличие
> от предыдущих
> есть еще один сумматор, который на лету добавляет к адресу содержимое другого
> регистра. Любого.Спасибо, капитан. Только не "любого" а "program counter", а то что вы упоминаете - это индексированный доступ. А относительная адресация нужна затем чтобы можно было адресовать данные и код относительно текущего места выполнения, сделав блок кода некоей полностью самодостаточной сущностью в памяти. Тогда его просто будет в память вгрузить и просто перенести в другие адреса, в идеальном случае - тупым копированием/загрузкой в желаемое место в адресах. В случае program counter EPIC WIN состоит в том что в командах кодируется только относительное смещение, а программе не надо вообще ничего знать о том в каких вообще адресах происходит дело. Ну, program counter при выполнении неизбежно фигурирует и актуализуется, потому что иначе программа бы не работала. А вот о других регистрах этого не скажешь. А то что вы расписали - это скорее индексированный доступ, но это совсем не то. Потому что базу индекса надо явно задавать где-то. А в случае program counter "база" сама себя задает, и код генерить не сложно (указать "от сих на 60 байтов вперед" - невелика наука) ;)
> Этим изобретением гордились в 60 года, "...
Да, уже тогда некоторые господа придумали кое-что получше чем уродец на костылях с полутора куцыми регистрами. А интел настолько ушибся на своем 8080 и потом 8086, что так и таскал этот куцый набор регистров, чтобы было похоже на выпердыши конца 70-х и начала 80-х прошлого столетия и дальше :))).
> адресацию ! Наши инженеры добавили еще дно уникальное устройство сложения, теперь
> для часто упортебляемой комбинации вы можете сразу выбрать смещение из кода
> операции и ОДНОВРЕМЕННО сложить с базовым регистром, ОТНОСИТЕЛЬНО которого вы и
> адресуетесь"Ну так в интеле почему-то это не осилили. Только в амд64 появилось.
> Итого - Любая адресация у интела ОТНОСИТЕЛЬНАЯ. Причем минимум ДАВЖДЫ ОТНОСИТЕЛЬНАЯ Любая.
> Из за сегментных регистров, и тем более таблиц виртуальной памяти MMU.Ага, если не считать такой мелочи что
1) Сегментные регистры кто-то должен явно программировать, в отличие от program counter'а, который актуален "by design".
2) Обычная программа в ring3 вообще ничего не знает ни о каком paging ;)[del]
> адресация IP не предусмотрена. А ЗАЧЕМ нам адресовать в коде чтото
> относительно регистра программного счетчика?У него есть одно важное свойство: program counter актуализует себя сам, естественными методами, без заботы программы об этом. Если программа адресуется относительно него - ее можно в любой адрес запихнуть, а она не заметит разницы. Потому что для ее запуска всяко управление будет подано на старт, а потом PC сам же себя и апдейтит. А вот всякие там другие регистры таким полезным свойством не обладают, требуя к себе явного внимания и указания правильной базы в программе :P. Это не относительная а индексированная адресация получается. Только вот базовый адрес надо явно задавать, и программа должна это явно знать, поэтому ни о каком свободном переезде по адресам спич не идет.
> Мы уже не Гарвардскую архитектуру имеем?
Epic fail! В гарвардце такое как раз и было бы невозможно. У совсем злостного гарвардца адресные пространства кода и данных различны, поэтому program counter (описывающий адрес с точки зрения кода) не имеет физического смысла применительно к адресам в пространстве данных. Поэтому в 100% трушном гарвардце относительная адресация в ее обычном виде - а это вообще как? Другое дело что чистокровные гарвардцы по этому поводу довольно мучительны в програминге. Даже сама по себе идея "вгрузим бинарь с диска!" очень плохо ложится на парадигму гарвардца с четким разделением кода и данных. Начинаются всякие костыли "а давайте к коду все-таки можно будет обращаться как к данным?" и прочие веселости.
> У нас что, допотопная Лента Тьюринга? Мы пишем самомодифицирующийся код который
> на лету меняет сам себя? Зачем выбирать данные в трехуровневой сегментноф
> стековой машине с физически разделенной памятью команд и данных отностиельно команд?Простейший пример зачем это надо я привел: допустим простая, быстрая и безгеморная реализация ALSR.
> Итог - любой интеловский процессор имеет минимум 2 кратно относительную адресацию. Двухкратно,
> а для некоторых случаем и трехкратную.Агащаз. Федот да не тот. Скорее, это просто индексированная адресация. Только вот она ни разу не помогает писать программу не зависящую от адресов.
> И уж совершенно ненусветная глупость говорить что это как то ускоряет или
> замедляет, с чего собственно началось.Костылинг который приходится для х86 по этому поводу проводить - определенно замедляет процесс старта программы: при нужде передвинуть программу в новые адреса - патчится все что нельзя заадресовать относительным смещением, а можно только указанием конкретных адресов.
> Простейший пример зачем это надо я привел: допустим простая, быстрая и безгеморная
> реализация ALSR.Во-первых не ALSR, а ASLR (Address Space Layout Randomization), а во-вторых я таки понял зачем вам адресация относительно eip.
Так вот, сам по себе ASLR это такой необходимый костыль из-за использования flat memory model. Вы можете записать что угодно в память, а потом передать туда управление. Та security model которую проектировали для PM в 286+ делала использования ASLR банально не нужным т.к. модификацию сегментов кода можно ограничить где-то на ring0 вместе с vmm, планировщиком и обработчиками исключения. Всё остальное (дрова, системные сервисы, юзерленд) крутить на более низких уровнях.
> Во-первых не ALSR, а ASLR (Address Space Layout Randomization), а во-вторых я
> таки понял зачем вам адресация относительно eip.Затем чтобы грузить программу в произвольный адрес и не патчить потом полпрограммы, очевидно.
> Так вот, сам по себе ASLR это такой необходимый костыль из-за использования
> flat memory model.У этой самой flat memory model при наличии MMU как бы есть страницы и есть разные права на оные, из которых делается все что угодно. Из страниц и их атрибутов можно сэмулировать сегменты. Из сегментов страничная память не эмулируется. Вывод: MMU с страничной адресацией - это суперсет, а не subset технологий. Это шаг вперед. И линейная адресация, и возможность защиты памяти программ друг от друга и ОС от программ, и виртуальная память. Все и сразу.
> Вы можете записать что угодно в память, а потом передать туда управление.
На самом деле это ниоткуда не следует: все от атрибутов страниц зависит. NX бит - всего лишь логичное доразвитие идеи MMU и страничной адресации. А оно даже без NX бита как минимум вполне справлялось с изоляцией ОС от процессов и процессов друг от друга.
> Та security model которую проектировали для PM
> в 286+ делала использования ASLR банально не нужнымASLR не замена NX бита. А дополнение к оному. И да, я не вижу чем защита памяти через сегменты лучше защиты памяти через MMU и атрибуты страниц. MMU + атрибуты страниц может изобразить любой мыслимый сегмент с гранулярностью равной размеру страницы. А вот обратный вариант не катит.
> т.к. модификацию сегментов кода можно ограничить где-то на ring0 вместе
> с vmm, планировщиком и обработчиками исключения.А что не дает сделать то же самое с MMU и атрибутами страниц? Попробуйте из ring3 сунуться в память операционки или другого процесса влобовую, а не через услуги ОС, расскажите как получилось. Своп кстати является "штатным" исключением - если нужной страницы нет, случается эксепшн и его обработчик должен обеспечить догрузку с диска нужной страницы до возобновления работы задачи. А потом обработчик вернет состояние проца в вид "как было" и задача не узнает что оказывается был какой-то там page fault вообще :)))
> Всё остальное (дрова, системные сервисы, юзерленд) крутить
> на более низких уровнях.Внезапно, деление на кернел и юзер ничего такого не запрещает. Можно даже писать user-mode драйвер, который для того чтобы выполнить некое действие будет просить привилегированный кусок ядра отработать ему опасную операцию. Для этого достаточно 2 уровней, юзер и система. Больше - в принципе конечно лучше, но вот исторически все как-то забили на эту фичу х86 и дружно юзали ring0 и ring3, тем более что у других процов есть эквиваленты оных, что позволяет проще портировать операционку на другие процессоры ("kernel mode" и "user mode" в общем случае).
>> Так вот, сам по себе ASLR это такой необходимый костыль из-за использования
>> flat memory model.
> У этой самой flat memory model при наличии MMU как бы есть
> страницы и есть разные права на оные, из которых делается все
> что угодно.Фигня в том что страничная адресация это совершенно другой уровень управления памятью. О то что есть какие-то страницы приложения знать не обязательно. А сегментное разделение это логическая структура приложения.
> Из страниц и их атрибутов можно сэмулировать сегменты. Из
> сегментов страничная память не эмулируется.Ещё раз, сегменты и страницы это совершенно различные уровни абстракций.
> Вывод: MMU с страничной адресацией -
> это суперсет, а не subset технологий. Это шаг вперед. И линейная
> адресация, и возможность защиты памяти программ друг от друга и ОС
> от программ, и виртуальная память. Все и сразу.Защита через сегменты появилась в 82-м году, работает и не пробивается. NX bit - четверь века спустя и, по сути, не является гарантированым решением проблемы. Такой прямо мегаскачок :)
>> Та security model которую проектировали для PM
>> в 286+ делала использования ASLR банально не нужным
> ASLR не замена NX бита. А дополнение к оному. И да, я
> не вижу чем защита памяти через сегменты лучше защиты памяти через
> MMU и атрибуты страниц.Ну что я могу сказать. Лучше тем что она работала ещё когда вас в проекте не было, в отличии от.
> Своп кстати
> является "штатным" исключением - если нужной страницы нет, случается эксепшн и
> его обработчик должен обеспечить догрузку с диска нужной страницы до возобновления
> работы задачи. А потом обработчик вернет состояние проца в вид "как
> было" и задача не узнает что оказывается был какой-то там page
> fault вообще :)))Это к чему? Решили блеснуть знаниями? Какие ещё исключения знаете? :)
> Внезапно, деление на кернел и юзер ничего такого не запрещает.
Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы сразу оказываетесь в ring0 и можете делать что угодно, а при нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать не можете.
> Защита через сегменты появилась в 82-м году, работает и не пробивается. NX
> bit - четверь века спустя и, по сути, не является гарантированым
> решением проблемы. Такой прямо мегаскачок :)
> Ну что я могу сказать. Лучше тем что она работала ещё когда
> вас в проекте не было, в отличии от.Стеклодувы появились в 200 году до нашей эры. Где они? Почему они больше не требуются в массовом производстве?
К слову говоря: сегментная защита имеет _массу_ недостатков. "Работает и не пробивается" он только в том случае, как вы правильно заметили, если сегменты не пересекаются. Попробуйте увязать сегментную защиту с page sharing - и быстро поймете, что мир не такой уж и розовый. Запустить 100500 копий одного процесса в Linux без существенной потери памяти? Да легко. А в винде (которая выросла из сегментной защиты)?
> Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы
> сразу оказываетесь в ring0 и можете делать что угодно, а при
> нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать
> не можете.Достаточно того, что ring1/2 могут писать в память ring3. Далее с системой можно сотворить что угодно, в т.ч. и рута получить. А с рута уйти в ring0 - как делать нефиг, достаточно подгрузить ring0-модуль. Так что бестолково.
> Попробуйте увязать сегментную защиту с page sharing - и
> быстро поймете, что мир не такой уж и розовый.Да лехко. Страничная адресация это совершенно другой уровень абстракции.
> А в винде (которая выросла из сегментной защиты)?
Сегменты использовала только 3.x винда, если не ошибаюсь. NT их не использовала из-за того что взлетать нужно было на куче архитектур на старте.
> Достаточно того, что ring1/2 могут писать в память ring3. Далее с системой
> можно сотворить что угодно, в т.ч. и рута получить. А с
> рута уйти в ring0 - как делать нефиг, достаточно подгрузить ring0-модуль.ring1/2 может писать куда им разрешили. При грамотном разделении какой-нить драйвер сможет насрать только в какой-нить shared buffer, что не особо критично.
>> Попробуйте увязать сегментную защиту с page sharing - и
>> быстро поймете, что мир не такой уж и розовый.
> Да лехко. Страничная адресация это совершенно другой уровень абстракции.Серьёзно? Потрудитесь описать механизм, и объяснить, как оно после этого будет коррелировать с Вашим "сегменты не пересекаются"?
>>> Попробуйте увязать сегментную защиту с page sharing - и
>>> быстро поймете, что мир не такой уж и розовый.
>> Да лехко. Страничная адресация это совершенно другой уровень абстракции.
> Серьёзно? Потрудитесь описать механизм, и объяснить, как оно после этого будет коррелировать
> с Вашим "сегменты не пересекаются"?Да лехко. То что сегменты не пересакаются важно только в рамках одной задачи, и делается это всё в ldt. Т.е. с 0 по size идёт cs, потом данные, потом куча и с maxmem растёт вниз стек.
А дальше в общем-то всё просто. Механизм аналогичен тому что используется сейчас. Каждая задача таскает с собой свой каталог страниц (cr3 сохраняется в tss), и в нём настраивается что логический адрес с 0 (начало cs) и N соотв. страниц мапяться на участки физической памяти с кодом, и эту память все могут без проблем шарить.
> Да лехко. То что сегменты не пересакаются важно только в рамках одной
> задачи, и делается это всё в ldt. Т.е. с 0 по
> size идёт cs, потом данные, потом куча и с maxmem растёт
> вниз стек.И зачем в этой схеме сегменты?
Если есть
а) NX для данных и стека
б) RO для кода
>> Да лехко. То что сегменты не пересакаются важно только в рамках одной
>> задачи, и делается это всё в ldt. Т.е. с 0 по
>> size идёт cs, потом данные, потом куча и с maxmem растёт
>> вниз стек.
> И зачем в этой схеме сегменты?
> Если есть
> а) NX для данных и стека
> б) RO для кодаЭто сейчас есть. NX появился через четверть века после сегментов. А ro для страниц кода не спасает от инжекта оного в любую другую страницу с данными и передачи управления туда в текущей плоской модели памяти.
> Это сейчас есть. NX появился через четверть века после сегментов.Ну так сегменты окончательно стали не актуальны. О чём и речь.
> Это сейчас есть. NX появился через четверть века после сегментов.Ну так с его появлением нужны сегменты или нет?
Hint: архитектура x86-64 в native mode вообще не поддерживает при адресации никаких опционов в плане сегментов, кроме FS/GS, да и те весьма ограниченно - только для совместимости с маразматичностью винды.Ну и TSS в классическом виде (для переключения задач) тоже уже не поддерживается, как устаревший механизм. Только для задания кое-каких параметров на Ring'ах.
>> Это сейчас есть. NX появился через четверть века после сегментов.
> Ну так с его появлением нужны сегменты или нет?Идиотский вопрос, особенно в свете того что ими никто не пользуется.
> Hint: архитектура x86-64 в native mode вообще не поддерживает при адресации никаких
> опционов в плане сегментов, кроме FS/GS, да и те весьма ограниченно
> - только для совместимости с маразматичностью винды.fs/gs это не маразматичность винды. В fs винда держит tls (линупс для эти целей пользует gs), второй регистр использую системы виртуализации (vmware как минимум).
> Фигня в том что страничная адресация это совершенно другой уровень управления памятью.Да. Это сразу подразумевает нормальную изоляцию процессов друг от друга и от ядра ОС. То что там протупили с одним конкретным видом изоляции т.к. интернет тогда был уделом избранных и проблема не стояла, а телепаты были в отпуске - второй вопрос.
> О то что есть какие-то страницы приложения знать не обязательно. А
> сегментное разделение это логическая структура приложения.В нормальной многозадачной операционке приложение не должно само лезть в такие дебри.
[..]
> Ещё раз, сегменты и страницы это совершенно различные уровни абстракций.Из страниц можно изображать разные регионы-"сегменты" с разными правами доступа. То что один полезный вариант прав не предусмотрели - ну да, упущеньице.
[..]
> Защита через сегменты появилась в 82-м году, работает и не пробивается.А паровозы появились вообще более 100 лет назад и им было плевать на обрыв контактной сети. И чего теперь, на паровозах чтоли ездить до упора?
> NX bit - четверь века спустя и, по сути, не является гарантированым
> решением проблемы. Такой прямо мегаскачок :)На самом деле - в лобовую пробить аппаратно выставленный NX бит достаточно проблематично. MMU вполне честно энфорсит права на доступ в память. А то что хакеры находят разные веселые воркэраунды - так это еще вопрос что было бы с сегментами. Их нынче никто не юзает и поэтому проверки на практике не было.
[..]
>> не вижу чем защита памяти через сегменты лучше защиты памяти через
>> MMU и атрибуты страниц.
> Ну что я могу сказать. Лучше тем что она работала ещё когда вас в проекте не было,Кто сказал что меня не было в проекте? Мы тут шарлатанов не вызывали.
> в отличии от.
А вот паровозы изобрели когда меня не было в проекте. Они стало быть лучше скоростных поездов, правда? И чего это все от них дружно отказались?
> Это к чему? Решили блеснуть знаниями? Какие ещё исключения знаете? :)
Это лишь к тому что хорошо когда обычной программе не приходится заморачиваться с свопом, сегментами и прочими сущностями.
>> Внезапно, деление на кернел и юзер ничего такого не запрещает.
> Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы
> сразу оказываетесь в ring0 и можете делать что угодно, а при
> нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать
> не можете.Ага, вас послушать так в ring3 и вообще пукнуть нельзя. А поди ж ты, хаксоры умудряются оттуда полностью систему раздолбать. Наиболее очевидный вариант: можно там спокойно сидеть и патчить все что качает юзер, довешивая эксплойты на известные дыры для известных форматов файлов + втыкать вирусы в все скачиваемые EXE. Но это же сущие пустяки, да? :)
Кстати если драйверу нельзя опасные операции - он должен просить ос. И тут еще вопрос как там с безопасностью всего этого. А чем это принципиально отличается от того что ring3 просит ядро разрулить запросы?
> После вдувания порции стероидов это обозвали кором, и до сих пор обзывают.core/core 2 - это наследник p3, современная i-серия, это таки нехалемы.
> Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter.
Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно мощной для своего времени, и она достаточно мощна сегодня, ну существует туева хуча процов для бедных которые поддерживали только два уровня защиты и страничную адресацию с плоским линейным пространством без защиты из-за чего пришлось похерить такую мегавещь. В результате мы имеем такие бонусы как buffer overflow позволяющие загрузить и выполнить код, ведро костылей в виде nx/xd и, опять же, возможность пробить систему и вылезти в ring 0.
А возможность загружать данные относительно (e)ip она лишняя, сегмент кода в ring 3 (тобишь userland) похорошему должен иметь только execute, без всяких read.
> core/core 2 - это наследник p3, современная i-серия, это таки нехалемы.А i-серия - наследник коров2, еще более доработанный. Там еще больше блоков, еще больше кеша, etc. И что забавно, это в очередной раз позволило интелу взять новые высоты, эволюционным а не революционным методом. Что довольно предсказуемо.
>> Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter.
> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
> мощной для своего времени,Дейстивтельно, приплыли! В разговоре о режимах адресации откуда-то берется секурити модель. А она тут к чему?
> и она достаточно мощна сегодня, ну существует туева хуча процов для бедных
> которые поддерживали только два уровня защиты и страничную адресацию с плоским
> линейным пространством без защиты из-за чего пришлось похерить такую мегавещь.Не хочу ничего сказать, но MMU других процессоров (на плечи которых и ложится обеспечение защиты памяти) по общей своей идее почему-то довольно похожи на то что у х86. Примерно такие же страницы и что там еще. А плюс-минус 1-2 лишних кольца-уровня защиты - да вообще похрену, все-равно все современные операционки довольствуются 2-я, "ядром всемогущим" и "юзером бесправным". Все, включая ваш любимый MS на "лишние" кольца дружно забили и ограничились двумя. Ну и все остальные производители процов гляда на это тоже активно развивали эти 2 режима. Бывает и больше режимов, это у кого как. В этом плане тот же интел не так уж принципиально отличен от ARM или MIPS или там кого еще. Примерно как почти все легковые автомобили имеют более-менее похожий друг на друга дизайн, 4 колеса, руль и педали, так и здесь. Устоялся вот такой вот дизайн.
> В результате мы имеем такие бонусы как buffer overflow позволяющие
> загрузить и выполнить код,Не вижу как лишние кольца помогли бы борьбе с переполнением буфера. Если не брать в расчет приколы типа эксплойта на анимированные курсоры в вашей любимой винде (да, переполнение буфера в ядре это весьма лютый фэйл, а учтя что у вас там один только win32k.sys на 2 мега вгружается - наверное он не последний), код выполняется в наименее привилегированном 3-м кольце.
> ведро костылей в виде nx/xd и, опять же, возможность пробить систему и
> вылезти в ring 0.А вот тут стоит сказать особо. Сам по себе дизайн с разделением на кернел, юзер и страничным MMU, что у интела, что у остальных (он стал столь же типичен, как типовой дизайн автомобиля) - вполне честный и не имеющий очевидных изъянов: есть "система", которая рулит правами (ядро). И бесправный юзер который сам ничего не может и должен просить систему через сисколы делать потенциально опасные операции под чутким контролем системы. И если вдруг изоляция процесса от процесса или системы от процесса пользователя нарушилась, значит ... операционка обосралась при выполнении своей непосредственной задачи как то разделение ресурсов, управление их совместным использованием и энфорсинг прав доступа. Это - откровенный баг операционки. Сюрприз!
> А возможность загружать данные относительно (e)ip она лишняя, сегмент кода в ring
> 3 (тобишь userland) похорошему должен иметь только execute, без всяких read.На самом деле, execute без read - это из разряда "хочу есть, но не ртом". На такие извращения процессоры никто не рассчитывал и есть такое смутное подозрение что во первых, сломается половина программ, во вторых, это ограничение наверное можно попробовать обойти окольными путями, а в третьих - мне не понятно: а кого и от чего это защитит? Ну защита на запись - понятно. Защита областей типа стека от выполнения - тоже понятно. А вот защита от чтения - ???
> Не хочу ничего сказать, но MMU других процессоров (на плечи которых и
> ложится обеспечение защиты памяти) по общей своей идее почему-то довольно похожи
> на то что у х86.Уверены?
> Примерно такие же страницы и что там еще.
Вот-вот. Большинство разрабов процов хватило только на страницы.
> Все, включая ваш любимый MS на "лишние" кольца
> дружно забили и ограничились двумя.э? Винда на старте поддерживала x86, mips и alpha, потом добавили ppc. Какой там mmu в этих других процах можете сами почитать. А то что Линус не осилил сегментную модель памяти... что можно ожидать от эмулятора терминала.
>> В результате мы имеем такие бонусы как buffer overflow позволяющие
>> загрузить и выполнить код,
> Не вижу как лишние кольца помогли бы борьбе с переполнением буфера.Потому что о том как устроен PM в 286+ вы читали в журнале мурзилка (хотя сомневаюсь что вы этот журнал в глаза видели). Для выполнения задачи в PM необходимо LDT, TSS, и три сегмента: code, data, stack. Это уровень организации приложения. Каждый тип сегмента имеет свои уникальные свойства. Сегмент кода всегда RO, а на сегмент данных или стека нельзя сделать джамп. Так вот, для приложения эти три сегмента делаются непересекаемыми, в итоге в случае buffer overflow с загрузкой кода и попыткой перехода мы получим банальный GP.
О том как можно эффективно использовать 4 уровня привелегий подумайте сами.
> На самом деле, execute без read - это из разряда "хочу есть,
> но не ртом". На такие извращения процессоры никто не рассчитывал иЯ ж таки прав. О PM в 286+ вам явно Рабинович на хинди напел.
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm.> это ограничение наверное можно попробовать обойти окольными путями,
Обойти? Если влезть на уровень mmu то всё обойти можно, а так если сегменты не пересекаются, то никак.
> Уверены?Общая идея которая устаканилась у всех более-менее одинакова. Ну как говоря авто я ожидаю увидеть руль, 4 колеса, фары, двигатель и прочие стопсигналы, так говоря MMU я в обещм случае ожидаю увидеть вполне характерный агрегат для работы с страничной памятью, у которого на месте более-менее обычные "руль и 4 колеса" и так далее. Какая-то конкретика разумеется отличается, но общая концепция более-менее устаканилась.
>> Примерно такие же страницы и что там еще.
> Вот-вот. Большинство разрабов процов хватило только на страницы.Знаете, это интела к их чести хватило выбросить свой геморрой с сегментами и перейти на нормальный MMU. То что было в 80286 - лютый феерический пи...ц. Там даже компилеры не могли массивы адресовывать более чем на 64К без спецкостылей и подпорок. Совершенно кретинская модель памяти. К чести интела они решили похоронить это недоразумение и сделать нормальный MMU и линейную адресацию, как у всех вменяемых архитектур. Правда вот выбросить до конца останки наследия не смогли. И зачем-то оставили совершенно куцые регистры, хотя имели все шансы исправить и это упущение.
>> Все, включая ваш любимый MS на "лишние" кольца
>> дружно забили и ограничились двумя.
> э? Винда на старте поддерживала x86, mips и alpha, потом добавили ppc.
> Какой там mmu в этих других процах можете сами почитать.Не путайте MMU и кольца защиты. Это разные вещи. На самом деле MMU внедрили в основном для поддержки виртуальной памяти. А до кучи страницная организация памяти дает возможность вешать страницам атрибуты и защищать память всех ото всех, чтоб не шарились почем зря. NX-бит это лишь логичное доразвитие идеи. Никого же не удивляет память отмаркированная как read only например и лютый эксепшн по поводу попытки туда что-то записать.
> А то что Линус не осилил сегментную модель памяти... что можно
> ожидать от эмулятора терминала.Знаете, сегментная модель памяти юзалась только в 16-бит винде и это было редкостное угробище. Как и вся винда 3.х и 9х - там такая жесть в кернелмоде что линукс на фоне этих куч костылей и нескольких разрозненных кусков ядер разной битности густо подпертых костылями - просто эталон стройности. Не говоря о том что была куча методов испортить память системы из пользовательской программы так что система вставала колом при малейшем сбое программ DOS и т.п.. Linux более-менее на уровне современных ОС как раз потому что его не пытались строить под заведомо дефективную и ограниченную модель памяти и сразу забабахали под именно ту модель памяти которая покорила мир. Кстати современные версии NT-based вы тоже никогда не адаптируете к 80286 и его убогой модели памяти. Они тоже завязаны на страничные методы адресации и ни о каких сегментах и прочих костылях эпохи 286 знать ничего не желают. Потому что в отличие от самопального гумна 3.х/9х это нормальная команда ядерщиков писала, удачно скупленная MSом.
>>> В результате мы имеем такие бонусы как buffer overflow позволяющие
>>> загрузить и выполнить код,
>> Не вижу как лишние кольца помогли бы борьбе с переполнением буфера.
> Потому что о том как устроен PM в 286+ вы читали в
> журнале мурзилка (хотя сомневаюсь что вы этот журнал в глаза видели).Все эти сегменты в 286 - лютейший маздай. И весь PM - первый блин комом. Нечто вменяемое родили только в i386. И как ни странно, большая часть процессоров (даже всякие ARM и MIPS) используют довольно похожие подходы по части MMU и того что связано с страничной памятью. Сдохло фирменное уе...ство с сегментами - туда и дорога. Flat модель памяти тупо удобнее программить, а атрибуты на страницы вполне можно развесить.
> Для выполнения задачи в PM необходимо LDT, TSS, и три сегмента:
> code, data, stack. Это уровень организации приложения.А ничего что по хорошему, не все так просто?
Code бывает заведомо readonly, а бывает read-write. И по идее есть 2 разных случая: в идеале хорошо бы readonly, но тогда например в принципе не удастся делать jit компилеры, рантайм оптимизации и прочее. С другой стороны, полная либерастия "пусть код в память пишет кто угодно" чревато невкусными неожиданностями "ой, нас тут внезапно пропатчили без предупреждения и получения на это правов от ОС".
Данные тоже бывают как read-only статичные данные, так и read-write. Но ведь 640 кило хватит всем, правда? :)> Каждый тип сегмента имеет свои уникальные свойства. Сегмент кода всегда RO,
... и поэтому JIT, трансляцию кода и прочие рантайм оптимизации вообще делать нельзя? Как мило.
> а на сегмент данных или стека нельзя сделать джамп.
Что, и EXE-packers тоже дружно в пролете?
Кстати, теперь примерно то же самое делает NX бит. То что его сразу почему-то не предусмотрели - вот это слегка упущеньице. Но тут стоит вспомнить что в те поры интернет не был так популярен и переполнения буферов всем были до лампочки, а битва шла вокруг защиты ОС от поползновений задач и защиты задач друг от друга. С этим MMU справляется на ура и без NX бита в общем то. Какую задачу решали - ту и решили. А переполнения заткнули когда это стало актуально. Хотя теоретически никто не мешал и раньше это предусмотреть.
> Так вот, для приложения эти три сегмента делаются непересекаемыми, в итоге
> в случае buffer overflow с загрузкой кода и попыткой перехода мы получим банальный GP.Ну а сейчас получим исключение по поводу NX бита. То же самое, только для страничной модели.
> О том как можно эффективно использовать 4 уровня привелегий подумайте сами.
Что-то ваш любимый майкрософт не захотел на этот счет думать.
>> На самом деле, execute без read - это из разряда "хочу есть,
>> но не ртом". На такие извращения процессоры никто не рассчитывал и
> Я ж таки прав. О PM в 286+ вам явно Рабинович на хинди напел.
> http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm.Не вижу никакого смысла читать о 80286 и его сегментных моделях. Независимо от того какими хорошими и пушистыми были мамонты - они сдохли. Не вижу смысла тратить мое время на труп.
>> это ограничение наверное можно попробовать обойти окольными путями,
> Обойти? Если влезть на уровень mmu то всё обойти можно, а так
> если сегменты не пересекаются, то никак.Угу, только вся эта сегментная модель предполагает довольно жесткие ограничения на то как выглядит задача и что она вообще может. Взять вот типичный браузер. Он на ходу перегоняет куски скриптов в машинный код для ускорения. Как это делать если сегмент тотально RO? "Это не нужно"? Спасибо, про то что 640К хватит всем - уже слышали.
> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
> мощной для своего времениОна оказалась настолько неудобоваримой, что в итоге её никто толком так и не использовал в реализациях, и в конце концов от неё ушли в пользу Flat/NX.
>> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
>> мощной для своего времени
> Она оказалась настолько неудобоваримой, что в итоге её никто толком так и
> не использовал в реализациях, и в конце концов от неё ушли
> в пользу Flat/NX.ага
http://en.wikipedia.org/wiki/Ring_(computer_security)
For example, the reason Windows uses only two levels (ring 0 and ring 3) is that some hardware architectures that were supported in the past (such as PowerPC or MIPS) implemented only two privilege levels.
Аналогично было и с сегментами. Они поддерживались только на x86 и соотв. их никто не реализовывал. Правда не помню у кого читал это, может у Реймонда Чена, но гугль ссылок не даёт.
> For example, the reason Windows uses only two levelsОно до сих пор нормально не умеет NX, так что не пример. *nix'ы тоже особо лишние уровни не жаловали.
>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.месье, откройте для себя опкод 0xEB (емнип). да, в пределах +-127, и проблему не решает, но подсказывает, что не надо делать опрометчивых заявлений.
> месье, откройте для себя опкод 0xEB (емнип). да, в пределах +-127, и
> проблему не решает, но подсказывает, что не надо делать опрометчивых заявлений.Камень в огород принимается ;). Скорее, следовало припомнить отсутствие адресации данных относительно PC. Вот это уже надежно вбивает гвозди в крышку гроба позиционно-независимых программ.
> Скорее, следовало припомнить отсутствие адресации данных
> относительно PC. Вот это уже надежно вбивает гвозди в крышку гроба
> позиционно-независимых программ.это да. не понимаю, почему оно до сих пор живое? не по дарвину все это :)
А ещё можно открыть для себя опкод 0xE9 и префикс размера операнда 0x66, тогда, может быть, и в пределах 4-х гигов можно будет прыгать :)
> А ещё можно открыть для себя опкод 0xE9 и префикс размера операнда
> 0x66, тогда, может быть, и в пределах 4-х гигов можно будет
> прыгать :)Ещё раз: (0x66) 0xE9 - ADD IP/EIP,imm
Никакой относительной адресацией тут даже не пахнет.
Неправда.> IA-32 Intel® Architecture Software Developer’s Manual Volume 2: Instruction Set Reference
> ...
> JMP—Jump
> ...
> E9 cd JMP rel32 Jump near, relative, displacement relative to next instruction
> ...
> Near and Short Jumps. When executing a near jump, the processor jumps to the address(within the current code segment) that is specified with the target operand. The target operand specifies either an absolute offset (that is an offset from the base of the code segment) or A RELATIVE OFFSET (A SIGNED DISPLACEMENT RELATIVE TO THE CURRENT VALUE OF THE INSTRUCTION POINTER IN THE EIP REGISTER).
>И если вы в системе команд х86 не можете адресоваться относительно текущего места кода, вы это не можете и все тут.Было бы хорошо, если бы вы не несли бред столь самоуверенно:
http://en.wikipedia.org/wiki/X86_assembly_language
---
Each jump operation has three different forms, depending on the size of the operand. A short jump uses an 8-bit signed operand, which is a relative offset from the current instruction. A near jump is similar to a short jump but uses a 16-bit signed operand (in real or protected mode) or a 32-bit signed operand (in 32-bit protected mode only).
---
Школьники, как и полагается, путают относительную адресацию статических данных с относительным переходом...
> Школьники, как и полагается, путают относительную адресацию статических данных с относительным
> переходом...А данные адресовать нам что, не надо? Относительный переход - это круто, но что с ним делать без доступа к данным?! А относительной адресации данных у х86 нет.
Да, с данными ничего не поделаешь. Можно, конечно, изобрести костыль вродеmov esi, eip (не помню, можно ли вот так сразу, но не суть)
mov eax, [esi+var_1]но это именно что костыль.
> но это именно что костыль.Ну так о чем и речь, в х86 такого "счастья" - на каждом углу.
А что, товарищ где-то говорил про адресацию _данных_? Он говорил про относительную адресацию в общем. Он даже вот это упомянул:>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.
что не соответствует действительности. Мне следовало бы именно это процитировать, да, виноват.
ЗЫ Но красноглазым, как и полагается, что частное, что общее - все равно, лишь бы очередной патч к патчу на патч для свеженького ядреца наложился, да? ;-)
> А что, товарищ где-то говорил про адресацию _данных_? Он говорил про относительную
> адресацию в общем. Он даже вот это упомянул:Да-да, прогнал. У х86 все-таки есть зачаточная относительная адресация переходов. Нет относительной адресации данных, поэтому позиционно независимую программу сделать все-равно не выйдет без костылей.
>>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.
> что не соответствует действительности. Мне следовало бы именно это процитировать, да, виноват.Да-да, уже подправили, но не школьник почему-то ;). На самом деле - я х86 набор команд видел давно, проблевался и предпочел более вменяемые наборы команд. Поэтому знания оного - весьма так себе.
> ЗЫ Но красноглазым, как и полагается, что частное, что общее
Это слишком толсто - незачет.
>> ЗЫ Но красноглазым, как и полагается, что частное, что общее
>Это слишком толсто - незачет.Это было не вам адресовано :-) Вы вообще хороший комментарий написали, с интересом прочитал, только вот с относительной адресацией была неточность.
> У х86 все-таки есть зачаточная относительная адресация переходов.Почему зачаточная?
> 66E978563412 jmp +0x123456768
не достаточно?
> На самом деле - я х86 набор команд видел давно, проблевался и предпочел более вменяемые наборы команд.
Это какие, например?
>> У х86 все-таки есть зачаточная относительная адресация переходов.
> Почему зачаточная?
>> 66E978563412 jmp +0x123456768
> не достаточно?Блин. Всё, "специалисты" понабежали. JMP +x - это ни что иное, как ADD IP/EIP,x. Никакой относительной адресации тут нет, обычный ADD r,imm.
Смешной вы. У "обычного ADD r,imm" другой опкод. А что там процессор у себя делает, чтобы получить новый адрес, не имеет никакого значения. Вполне логично предположить, что он для этого выполняет ОПЕРАЦИЮ СЛОЖЕНИЯ :)
> Смешной вы. У "обычного ADD r,imm" другой опкод. А что там процессор
> у себя делает, чтобы получить новый адрес, не имеет никакого значения.
> Вполне логично предположить, что он для этого выполняет ОПЕРАЦИЮ СЛОЖЕНИЯ :)C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.
Ну и еще раз перечитайте себя - ОПЕРАЦИЯ СЛОЖЕНИЯ и операция взятия данных по относительному адресу - это одно и то же?
> C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др., с помощью которых можно косвенно изменить EIP/IP, но это не "операции с EIP/IP".
> Ну и еще раз перечитайте себя - ОПЕРАЦИЯ СЛОЖЕНИЯ и операция взятия данных по относительному адресу - это одно и то же?
Нет. А я разве где-то утверждал обратное? :) Я лишь, вслед за другими, не согласился с утверждением, что в x86 отсутствует операция перехода относительно текущего EIP/IP. И подтвердил это цитатами из двух интеловских мануалов. Читайте внимательнее и таки учите матчасть :)
> С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др.,
> с помощью которых можно косвенно изменить EIP/IP, но это не "операции
> с EIP/IP".Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,imm
Да, она стала чуть хитрее - различные сбросы очередей, конвееров, оптимизации и т.п.
Да, она бывает условной. Но она не имеет НИКАКОГО отношения к относительной адресации.
Учите матчасть, еще раз повторяю.
Если уж быть последовательным до конца, у x86 есть (возможны условия в условных переходах и загрузка сегментных регистров в дальних переходах):1. Операция прямого перехода с прямой адресацией: JMP imm
2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm
3. Операция прямого перехода с регистровой адресацией: JMP reg
4. Операция прямого перехода с косвенной регистровой адресацией: JMP [reg]
> Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,immТаких инструкций не существует, вы бредите :)
> 2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm
Перехода относительно ЧЕГО? Сосредоточьтесь и попытайтесь подумать: относительно ЧЕГО осуществляется переход. А потом ещё раз перечитайте, что писал Аноним и что ему отвечали. Тогда, может быть, настанет проблеск :) Все вменяемые уже давно поняли... :)
>> Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,imm
> Таких инструкций не существует, вы бредите :)То, что вы их без очков не видите, предпочитая упереться в книжки - ваши ЛПП.
>> 2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm
> Перехода относительно ЧЕГО?Вы - идиот. Относительная адресация и относительный переход - разные вещи.
>> C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.
> С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др.,
> с помощью которых можно косвенно изменить EIP/IP, но это не "операции
> с EIP/IP".Да ну бросьте. По факту - это именно они и есть. Кстати на ARM например можно влобовую с аналогичным по смыслу регистру операции делать. Потому что по свойствам он как РОН. Сразу, без извращений.
> В x86-32 нет адресации относительно текущего места выполнения (относительно текущего значения program counter-а).Наследственная болячка x86.Наглая лож. Смотрим старый добрый asm86 для 8086, команда JMP (0xEB).
> Наглая лож. Смотрим старый добрый asm86 для 8086, команда JMP (0xEB).Ещё один. См. выше.
>за период 1969-2011ггСейчас сложно найти бинарный пакет, скомпилированный для Intel SuperMegaProc 100500 Cores. Пакеты собирают для i486, i586, максимум - это i686. А 686 был выпущен в 1995 году.
Ну и вообще, зачем вы рассказываете о том, что может быть возможно есть во внутреннем RISC-процессоре? Ведь для программиста всё равно доступна только система команд x86. Да и вряд ли этот RISC умеет больше, чем нужно для выполнения x86-программ.
Регистров больше.
как-то так
http://tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benc...
так и не понял, есть ли смысл в 64 битах или нет? Что ставить-то на систему с 2G, 4G и больше?
> так и не понял, есть ли смысл в 64 битах или нет?
> Что ставить-то на систему с 2G, 4G и больше?На 4G -- 64 почти однозначно лучше, чем морока с PAE.
На 2G -- я бы в этом году ставил уже 64-bit по умолчанию.Могут найтись блокирующие обстоятельства, но мой кратенький список уже обнулился.
>> так и не понял, есть ли смысл в 64 битах или нет?
>> Что ставить-то на систему с 2G, 4G и больше?
> На 4G -- 64 почти однозначно лучше, чем морока с PAE.
> На 2G -- я бы в этом году ставил уже 64-bit по
> умолчанию.
> Могут найтись блокирующие обстоятельства, но мой кратенький список уже обнулился.премного благодарен
Конечно есть. Вот несколько плюсов:
1.) Целая куча дополнительных регистров.
2.) Если вы используете не самосборную систему, а просто какую-нибудь стандартную i386 сборку, то там используется достаточно небольшое кол-во возможностей вашего процессора, для совместимости с другими процессорами.
3.) 64-битные операции делаются быстрее, как нетрудно догадаться.
4.) Нет проблем с поддержкой большого кол-ва ОЗУ.
и Вам - спасибо
> - Размер традиционного iso-образа для Ubuntu 12.04 решено (http://www.phoronix.com/scan.php?page=news_item&px=MTAxMTM) увеличить до 750 МбЧто называется, не 2, не 1,5. Отказываемся от устаревшего носителя, но при этом выигрываем жалкие 50 МБ (7% выигрыша). Сейчас уже не найти в продаже флэшку меньше 2ГБ, так почему бы образ не раздуть до соответствующего размера?
>> - Размер традиционного iso-образа для Ubuntu 12.04 решено (http://www.phoronix.com/scan.php?page=news_item&px=MTAxMTM) увеличить до 750 Мб
> Что называется, не 2, не 1,5. Отказываемся от устаревшего носителя, но при
> этом выигрываем жалкие 50 МБ (7% выигрыша). Сейчас уже не найти
> в продаже флэшку меньше 2ГБ, так почему бы образ не раздуть
> до соответствующего размера?А ты пробуй загрузить какуето DVD на канале в 512....
P.S. Я за net install
>А ты пробуй загрузить какуето DVD на канале в 512....Его можно купить/скачать у друга. Зато потом неспешно поставить на даче, где интернетом вообще не пахнет.
> Его можно купить/скачать у друга. Зато потом неспешно поставить на даче, где
> интернетом вообще не пахнет.В моем компьютере нет DVD, за ненадобностью. На моих серверах тоже.
> В моем компьютере нет DVD, за ненадобностью. На моих серверах тоже.А образ нынче гибридный, его можно на флеху записать. На флехах лимита в 700Мб нету. Скорее, есть 512Мб, 1Гб и 2Гб. Ежику понятно что 512 не судьба, а вот 1Гб - в самый раз.
> интернетом вообще не пахнет.Да вообще-то GPRS а порой и 3G бывает даже в медвежьих углах. И анлимные тарифы стали более-менее вменяемые, скачать исошку уже вполне можно.
>> интернетом вообще не пахнет.
> Да вообще-то GPRS а порой и 3G бывает даже в медвежьих углах.
> И анлимные тарифы стали более-менее вменяемые, скачать исошку уже вполне можно.Вот только понятия "медвежий угол с GPRS" и "вменяемый анлимный тариф" как-то плохо пересекаются. Я живу возле МКАДа, но и сам порой вылезаю во всякие Кукуевы, и отзывы имею. Не всё так шоколадно, как это кажется владельцам толстого канала в Сеть дома и на работе.
Подтверждаю. Для некоторых разница между 750 и 1500 метров это 2-4 дня закачки...
> Не всё так шоколадно, как это кажется владельцам толстого канала в Сеть дома и на работе.Спасибо, автор данной фразы регулярно пользуется этим самым GPRS. Может там и не так шоколадно, но по крайней мере появились не сильно наглые по цене анлимы, работающие на территории всей страны, ну и как правило есть хотя-бы EDGE, хотя нынче не редкость и 3G/HSPA, при том почему-то даже в полном захолустье (видимо способствует подписке на анлим, ARPU увеличивается -> PROFIT).
> А ты пробуй загрузить какуето DVD на канале в 512....Зажрался народ. Ну пустил качаться торент на ночь, утром болванка уже ждет тебя.
>> А ты пробуй загрузить какуето DVD на канале в 512....
> Зажрался народ. Ну пустил качаться торент на ночь, утром болванка уже ждет
> тебя.Насчёт 512 зажрался. Но по сути он прав, 512 для отдельных мест - это самая настоящая неподъёмная роскошь.
> Насчёт 512 зажрался. Но по сути он прав, 512 для отдельных мест
> - это самая настоящая неподъёмная роскошь.Вы так говорите, как будто вы байты лично ведрами при этом таскаете. Ну блин, пустил торент в фон, процентов на 50-70 канала (подобрать до состояния когда не мешает остальной активности и не вызывает рост пинга). Ну скачает он. Гарантированно целостную болванку. За неделю? Ну и пусть себе. Работает то машина а не человек. Пустить в фон и не париться, докачается постепенно.
В случае хилого аплоада (DSL suxx) - да пофиг, у убунтов перевес сидеров над личерами столь дикий, что от вас никто даже не будет требовать аплоадить особо. Сидеры и без этого вам весь канал с удовольствием профлудят, сколько ни попроси.
>> Насчёт 512 зажрался. Но по сути он прав, 512 для отдельных мест
>> - это самая настоящая неподъёмная роскошь.
> Вы так говорите, как будто вы байты лично ведрами при этом таскаете.
> Ну блин, пустил торент в фон, процентов на 50-70 канала (подобрать
> до состояния когда не мешает остальной активности и не вызывает рост
> пинга). Ну скачает он. Гарантированно целостную болванку. За неделю? Ну и
> пусть себе. Работает то машина а не человек. Пустить в фон
> и не париться, докачается постепенно.Мсье будет пускать торренты на GPRS/EDGE? Для месье в нашем заведении есть особое обслуживание... Да и хвалёный 3G выдаёт далеко не то, что обещают товарищи маркетологи, по вполне понятным каждому, кто физику учил в школе, причинам.
> В случае хилого аплоада (DSL suxx) - да пофиг, у убунтов перевес
> сидеров над личерами столь дикий, что от вас никто даже не
> будет требовать аплоадить особо. Сидеры и без этого вам весь канал
> с удовольствием профлудят, сколько ни попроси.Ещё раз, DSL - это для некоторых мест роскошь (в виде, например, протягивания телефонной линии на энцать километров от ближайшего населённого более чем на пару десятков тысяч человек города).
Россия Москвой-то, может, и начинается, но отнюдь не заканчивается. А ещё есть и другие страны, где со связью ещё хуже.
> на GPRS/EDGE?а для этих вообще пофигу - что 700, что 750, что 1000. Все оно неподъемное для GPRS
> особое обслуживание... Да и хвалёный 3G выдаёт далеко не то, что
> обещают товарищи маркетологи, по вполне понятным каждому, кто физику учил в
> школе, причинам.Мы очень запоздали с внедрежом 3G и ... лютый FAIL превратился в лютый WIN. Потому что обычно ставится не просто 3G cота, а сразу HSPA. А вот это вполне ядреная штука.
> Ещё раз, DSL - это для некоторых мест роскошь (в виде, например,
> протягивания телефонной линии на энцать километров от ближайшего населённого более чем
> на пару десятков тысяч человек города).Нынче довольно часто тыкают HSPA вышку, чуть ли не в чистом поле. Удивительно но факт. Вот реально, видел несколько HSPA сот буквально в чистом поле, цать километров до бэкбона пробивают по радио опять же. Каких они там медведей и колхозников обслуживают я не в курсе, но мне такой расклад вполне по вкусу :)
> Россия Москвой-то, может, и начинается, но отнюдь не заканчивается. А ещё есть
> и другие страны, где со связью ещё хуже.В москве, чтоб вы знали, одно из наиболее жопных покрытий 3g/hspa, потому что в свое время военные зубами впились в диапазон частот и отдавать его не хотели. Насколько я знаю, на это у них были вполне разумные причины.
>> особое обслуживание... Да и хвалёный 3G выдаёт далеко не то, что
>> обещают товарищи маркетологи, по вполне понятным каждому, кто физику учил в
>> школе, причинам.
> Мы очень запоздали с внедрежом 3G и ... лютый FAIL превратился в
> лютый WIN. Потому что обычно ставится не просто 3G cота, а
> сразу HSPA. А вот это вполне ядреная штука.Минус вам в карму. 3G в России появился давно, в том числе в Москве (это к комментарию ниже). Только не на базе GSM/UMTS. "СкайЛинк" был де-факто монополистом на этом рынке, ну и как часто это бывает с монополистам, обленился. В итоге, когда "Альфа" и "Система" раскачались и начали интенсивно развивать своих мобильных дочек в этом направлении, "СкайЛинк" начал терять рынки. Хотя покрытие в сельской местности у них местами отличное, и немало предприятий - заводов, экс-колхозов и т.д. - пользуются именно их связью. К тому же CDMA вообще более толковый, чем GSM... Но - пролюбили в "Связьинвесте" своё счастье, не стали вторым Verizon'ом.
(впрочем, я последние год-два мало следил за ними, может, чего и поменялось в лучшую сторону)
>> Ещё раз, DSL - это для некоторых мест роскошь (в виде, например,
>> протягивания телефонной линии на энцать километров от ближайшего населённого более чем
>> на пару десятков тысяч человек города).
> Нынче довольно часто тыкают HSPA вышку, чуть ли не в чистом поле.
> Удивительно но факт. Вот реально, видел несколько HSPA сот буквально в
> чистом поле, цать километров до бэкбона пробивают по радио опять же.
> Каких они там медведей и колхозников обслуживают я не в курсе,
> но мне такой расклад вполне по вкусу :)Именно HSPA? UMTS/HSPA-покрытие используется прежде всего в крупных населённых пунктах, и вообще местах с повышенной плотностью населения. Так как дальнобойность у UMTS ниже, как следствие потенциальная плотность покрытия больше. По той же причине в городах всё больше GSM 1800/1900 сейчас, а за городом - 900/850. И по той же причине 450 МГц - не будем показывать пальцем, чьи - рулят. :) Ну да это это уже совсем оффтопик.
>> Россия Москвой-то, может, и начинается, но отнюдь не заканчивается. А ещё есть
>> и другие страны, где со связью ещё хуже.
> В москве, чтоб вы знали, одно из наиболее жопных покрытий 3g/hspa, потому
> что в свое время военные зубами впились в диапазон частот и
> отдавать его не хотели. Насколько я знаю, на это у них
> были вполне разумные причины.В курсе. У меня есть с чем сравнивать за пределами Нерезиновой. Насчёт причин - были-то были, вот только решить их можно было намного раньше, но до пинка от старшого царя никто не хотел этим заниматься. У нас же народ для военных, а не наоборот. :-\
>> сразу HSPA. А вот это вполне ядреная штука.
> Минус вам в карму. 3G в России появился давно, в том числе
> в Москве (это к комментарию ниже). Только не на базе GSM/UMTS.
> "СкайЛинк" был де-факто монополистом на этом рынке,Ну и кого интересуют всякие экзоты под левые нестандартные отпрыски технологий? Уродские аппараты. Странные тарифы. Невозможность выбора оператора. Хреновое покрытие. В общем выбор новых русских которым интернет на дачу около границы нерезиновой - любой ценой. Лично для меня такой сервис напрочь бесполезен.
> ну и как часто это бывает с монополистам, обленился. В итоге, когда "Альфа" и "Система"
> раскачались и начали интенсивно развивать своих мобильных дочек в этом направлении,
> "СкайЛинк" начал терять рынки.А еще мир, как минимум европейский, выбрал WCDMA который описан ETSI в качестве стандарта, и мы знаем это как 3G и HSPA в результате. Что довольно пресказуемо сказывается на доступности оборудования (как клиентского так и операторского) ну и ценах на оное. Под нестандарт скайлинка оборудование выпускалось лишь парой малоизвестных контор, поэтому шансы покрыть таким манером значительные области и приобрести популярность у населения заведомо близки к нулю. GSM или даже 3G/HSPA телефон - есть у каждого первого. Потому что делается всеми, от американской моторолы, давшей направлению старт, до совсем нонейм-китая.
> Хотя покрытие в сельской местности у них местами отличное,
Проблема именно в том что местами. В порядке прикола - знаю о вышке билайна работающей на солнечных батареях ажно (они у себя в блоге писали, стоит это чудо в горах, где инфраструктуры - ноль, даже кабель питания не протянуть).
> и немало предприятий - заводов, экс-колхозов и т.д. - пользуются именно их связью.
В процентном отношении они против билайна, мтс и мегафона без шансов.
> К тому же CDMA вообще более толковый, чем GSM...
... поэтому в 3G внедрили его подвид, известный как WCDMA и избавились от фирменных тупняков GSM, основными из которых являются никакая скорость передачи данных и ненадежная процедура handover'а ;)
> Но - пролюбили в "Связьинвесте" своё счастье, не стали вторым Verizon'ом.И замечательно, в результате у нас победит таки нормальный стандарт, разработанный ETSI, адекватно документированный и поддерживаемый всеми производителями оборудования. Поэтому у операторов будет выбор оборудования для БС а у юзеров - выбор модемов, мобилок и прочая. Не надо нам местечковых самопалов. Задрали уже.
> (впрочем, я последние год-два мало следил за ними, может, чего и поменялось
> в лучшую сторону)Могу сказать только за обычные 3G и HSPA. Их эра все-таки настает и у нас. И да, в деревне Кукуевка мухосранской области вполне 8может оказаться сота HSPA, как бы это странно ни звучало.
[..]
>> Каких они там медведей и колхозников обслуживают я не в курсе,
>> но мне такой расклад вполне по вкусу :)
> Именно HSPA? UMTS/HSPA-покрытие используется прежде всего в крупных населённых пунктах,Видимо стали производить относительно дешевые микросоты, которые рентабельно воткнуть даже в деревне Кукуевка, тем более что интернет анлим ценой в ~300 рублей - это весьма приличная прибавка к среднему ARPU по району + интернет для народа. Редкий случай когда интересы опсосов и пользователей совпадают.
> и вообще местах с повышенной плотностью населения. Так как дальнобойность у
> UMTS ниже,А операторы читерят: они покрывают именно населенный пункт или его окрестности. Что там будет дальше их не волнует ни с 3G, ни с GSM. В общем то логично. Гвоздить тайгу вышками по любому никакого бабла не хватит, а оценить это смогут только медведи ну и полтора охотника. Хотя иногда ветер доносит обрывки сигнала GSM и в такую глушь что просто диву даешься.
> как следствие потенциальная плотность покрытия больше.
Да ну бросьте. Втыкается сота посреди населенного пункта. Плотность покрытия - почти все население пункта. А полтора медведя в тайге никому не интересны, на них все-равно сот не напасешься.
> По той же причине в городах всё больше GSM 1800/1900 сейчас, а за городом - 900/850.
В городах сейчас все больше HSPA @ 2100, если уж на то пошло.
> И по той же причине 450 МГц - не будем показывать пальцем, чьи - рулят. :)
Ага, не считая того момента что в половине мухосрансков вышки наглухо забыли поставить и поэтому рулит оно лишь в отдельно взятых локациях, а GSM а теперь все чаще и HSPA есть вообще везде где есть человек.
В общем как обычно: затея хорошая, но реализация - на единицу. Ни с чем не совместимый стандарт под который есть пара убогих производителей оборудования и нет симкарт? Это каменный век.
>> В москве, чтоб вы знали, одно из наиболее жопных покрытий 3g/hspa, потому
>> что в свое время военные зубами впились в диапазон частот и
>> отдавать его не хотели. Насколько я знаю, на это у них
>> были вполне разумные причины.
> В курсе. У меня есть с чем сравнивать за пределами Нерезиновой. Насчёт
> причин - были-то были, вот только решить их можно было намного раньше,Там вроде как противоракетная оборона вещает. Обнаруживающая пуски баллистических ракет. Какое предлагается решение? "Ну и хрен с ней, нехай американцы и китайцы по московии ракетами шмаляют, накрыв верховного главнокомандующего и штаб"? Ну вот они и сопротивлялись, что логично.
> но до пинка от старшого царя никто не хотел этим заниматься. У нас же народ
> для военных, а не наоборот. :-\В конкретно этом случае я даже до некоторой степени могу понять их опасения. Если десяток летающих мегатонн не будет обнаружен вовремя - это как-то фиговато.
>> Хотя покрытие в сельской местности у них местами отличное,
> Проблема именно в том что местами. В порядке прикола - знаю о
> вышке билайна работающей на солнечных батареях ажно (они у себя в
> блоге писали, стоит это чудо в горах, где инфраструктуры - ноль,
> даже кабель питания не протянуть).Угу, помню, был такой понт. Вообще пиар-служба исторически у "Вымпелкома" на отлично работает. ;)
>> и немало предприятий - заводов, экс-колхозов и т.д. - пользуются именно их связью.
> В процентном отношении они против билайна, мтс и мегафона без шансов.Не всё решают проценты. "Бентли" и "Феррари" на порядки меньше, чем "Фольксвагенов" и "Рено", но никто из перечисленных загибаться не собирается. ;)
Не то чтобы я "СкайЛинк" сравнивал с "Феррари", нет. Хотя в своё время они были на порядок прогрессивнее прочих. Их связью, например, пользовались по соображениям безопасности - слушать CDMA2000 на порядки сложнее, чем GSM. Но - не осилили конкуренции, став более нишевым оператором... Впрочем, я повторяюсь.
> [..]
>>> Каких они там медведей и колхозников обслуживают я не в курсе,
>>> но мне такой расклад вполне по вкусу :)
>> Именно HSPA? UMTS/HSPA-покрытие используется прежде всего в крупных населённых пунктах,
> Видимо стали производить относительно дешевые микросоты, которые рентабельно воткнуть
> даже в деревне Кукуевка, тем более что интернет анлим ценой в
> ~300 рублей - это весьма приличная прибавка к среднему ARPU по
> району + интернет для народа. Редкий случай когда интересы опсосов и
> пользователей совпадают.Тут мне сложно судить, не считал. Но таки да, раз втыкают, значит, выгодно.
>> как следствие потенциальная плотность покрытия больше.
> Да ну бросьте. Втыкается сота посреди населенного пункта. Плотность покрытия - почти
> все население пункта. А полтора медведя в тайге никому не интересны,
> на них все-равно сот не напасешься.Нет, я о другом: пропускная способность внутри каждой соты имеет свой предел. Поэтому чем меньше размеры соты, тем больше сот можно воткнуть и тем больше, соответственно, народу обслужить. Плюс чем больше частота, тем больше по ней можно пропихнуть данных.
>> По той же причине в городах всё больше GSM 1800/1900 сейчас, а за городом - 900/850.
> В городах сейчас все больше HSPA @ 2100, если уж на то
> пошло.Через пару лет, думаю, так и будет, а пока что 3G в РФ заметно распространён по ЦФО, большей части Урала и ещё кое-где.
>[оверквотинг удален]
>> причин - были-то были, вот только решить их можно было намного раньше,
> Там вроде как противоракетная оборона вещает. Обнаруживающая пуски баллистических ракет.
> Какое предлагается решение? "Ну и хрен с ней, нехай американцы и
> китайцы по московии ракетами шмаляют, накрыв верховного главнокомандующего и штаб"? Ну
> вот они и сопротивлялись, что логично.
>> но до пинка от старшого царя никто не хотел этим заниматься. У нас же народ
>> для военных, а не наоборот. :-\
> В конкретно этом случае я даже до некоторой степени могу понять их
> опасения. Если десяток летающих мегатонн не будет обнаружен вовремя - это
> как-то фиговато.Это-то понятно. Просто так можно любую технологию зарезать на корню, ибо угроза безопасности. Самое забавное, в случае сотовой связи, что благодаря ей, среди прочего, улучшаются бизнес-процессы, от этого повышается ВВП страны, а с ним и налоговые отчисления, на которые эти самые военные и существуют. Но, как известно, кто в армии служил, тот в цирке не смеётся. :(
> Угу, помню, был такой понт. Вообще пиар-служба исторически у "Вымпелкома" на отлично работает. ;)Еще бы они сделали работающий Личный Кабинет наконец! А то это ASPшное глюкало - чаще просто висит нежели успешно логинится в ЛК. Windows Server обгоняяяяяяяяет Linux. По эээээстоооонскиииии, мммать! Более галимого ЛК я не встречал ни у кого. Ну и покрытие 3G развивают слабо, начали шевелиться только когда конкуренты прижучили. По поводу чего у МТС покрытие HSPA в нерезиновске явно лучше. Да еще и анлим у МТС есть анлим который действует по всей россии. А у билайна как всегда можно удобно... обломаться и попасть на бабки. Хотя на сайте утверждается что анлимный гпрс по всей россии, по факту оказывается что хрен с два. По-моему, их пиар служба местами не успевает.
>> В процентном отношении они против билайна, мтс и мегафона без шансов.
> Не всё решают проценты. "Бентли" и "Феррари" на порядки меньше, чем "Фольксвагенов"
> и "Рено", но никто из перечисленных загибаться не собирается. ;)И опять же, феррари - нишевая штука, мало полезная в повседневной жизни. Отличная аналогия с этим самопальным CDMA-450.
> Не то чтобы я "СкайЛинк" сравнивал с "Феррари", нет. Хотя в своё
> время они были на порядок прогрессивнее прочих. Их связью, например, пользовались
> по соображениям безопасности - слушать CDMA2000 на порядки сложнее, чем GSM.
> Но - не осилили конкуренции, став более нишевым оператором... Впрочем, я повторяюсь.Они всегда таковым и были: CDMA2000 как-то не сложился как отраслевой стандарт: по некоторым аспектам (доступность спеков, сменные симкарты, а потому широкое принятие производителями и покупателями) CDMA был хуже. И проиграл. Тем более что там квалком бряцал своими патентами от души и хотел со всех бабло. И хотел делать чипы для этого стандарта чуть ли не единолично. Ну и просрались все полимеры в пользу GSM, а потом и 3G/HSPA которые являются его эволюцией от той же конторы-разработчика стандарта.
>> [..]
>> району + интернет для народа. Редкий случай когда интересы опсосов и
>> пользователей совпадают.
> Тут мне сложно судить, не считал. Но таки да, раз втыкают, значит, выгодно.Операторы в принципе утверждают что еще есть вопрос престижа. Т.е. если оператор есть даже в глухой кукуевке - это удобно например дачникам всяким, приезжающим в кукуевку на целое лето. И для них отсутствие на все лето сотовой связи - вполне аргумент не в пользу данного оператора, если его там нет.
>> все население пункта. А полтора медведя в тайге никому не интересны,
>> на них все-равно сот не напасешься.
> Нет, я о другом: пропускная способность внутри каждой соты имеет свой предел.У HSPA сот пропускной способности - немеряно. Хотя вы знаете, в мелкой кукуевке и обычная GSM сота обычно справляется. Хотя интернет вечером на GPRS/EDGE сотах конечно же нещадно тупит.
> Поэтому чем меньше размеры соты, тем больше сот можно воткнуть и
> тем больше, соответственно, народу обслужить. Плюс чем больше частота, тем больше
> по ней можно пропихнуть данных.Обычно кукуевки мелкие и там любой соты достаточно. Одной. HSPA при прочих равных прокачает намного больше по эфиру чем GPRS/EDGE/GSM. Модуляция эффективнее, скорости выше, деление эфира кодом а не таймслотами - лучше работает.
> Через пару лет, думаю, так и будет, а пока что 3G в
> РФ заметно распространён по ЦФО, большей части Урала и ещё кое-где.На самом деле картинка очень пятнистая. Вот реально - бывает что воткнут HSPA в чистом поле. Обслуживает какие-то местные кукуевки. Могу предположить что производители сот почти свернули производство gsm-only как устаревших и что-то отличное от гибрида "HSPA + 3g/gsm как fallback" попросту никто уже не продает. Ну вот и втыкают то что можно купить у производителей.
[..]
>> В конкретно этом случае я даже до некоторой степени могу понять их
>> опасения. Если десяток летающих мегатонн не будет обнаружен вовремя - это
>> как-то фиговато.
> Это-то понятно. Просто так можно любую технологию зарезать на корню, ибо угроза безопасности.С другой стороны, если вы хотите нагадить потенциальному противнику - надо сделать так чтобы ему стало максимально неудобно. Можно почитать например про терки сша и европы на почве того что европеоиды хотели вещать в галилео на все том же диапазоне что и gps так что избирательно удавить галилео не положив свой же gps не вышло бы. Правда в результате вроде как янки L1 просто окончательно отдали гражданским и решили для военных сделать другую частоту, с шахматами и поэтессами, а европеоиды все-таки поюзают L1. Но любовь США к возможностям по контролю всего радиоэлектронного - прослеживается.
> Самое забавное, в случае сотовой связи, что благодаря ей, среди
> прочего, улучшаются бизнес-процессы, от этого повышается ВВП страны, а с ним
> и налоговые отчисления, на которые эти самые военные и существуют. Но, как известно,
> кто в армии служил, тот в цирке не смеётся. :(Ну, понимаешь, противоракетная оборона нужна круглосуточно. А не когда там еще налоги с этих улучшенных ВВП накапают. Вот это и представляет из себя некую проблему. Получается некий pkunzip.zip
> А ты пробуй загрузить какуето DVD на канале в 512....P.S. Я за net install
А по сети на таком канале сколько ставится будет? А что если при установке связь с интернетом временно оборвётся? Не легче всё скачать, а потом ставить в off-line?
>> А ты пробуй загрузить какуето DVD на канале в 512....
> P.S. Я за net install
> А по сети на таком канале сколько ставится будет? А что если
> при установке связь с интернетом временно оборвётся? Не легче всё скачать,
> а потом ставить в off-line?apt-get всё равно так и делает: сначала всё скачивает, потом ставит.
> apt-get всё равно так и делает: сначала всё скачивает, потом ставит.Дык, какая тогда разница -- качать 2 дня iso-шку или ставить пакеты те же 2 apt'ом? ISO-шку качать торрентом понадёжнее будет, ибо после временного разрыва и восстановления соединения закачка возобновляется. А apt всё время идёт вперёд и при разрыве интернет-канала установка прервётся или потребует вмешательства юзера (подтвердить продолжение установки).
Короче, netinstall больше рулит на хороших и скоростных каналах. На плохих и медленных ставить через netinstall ещё тот гемор.
Разница в том, что нетинсталл тянет ТОЛЬКО устанавливаемые пакеты.
aptitude докачивает без проблем, сколько раз были разрывы и ничего - работает как надо... можно даже контрол-цэ нажать и еще раз пустить - будет работать с места разрыва. емнип работает с ленни (а то и с этча - проверить не на чем).
> будет работать с места разрыва. емнип работает с ленни (а то
> и с этча - проверить не на чем).Если интернет не очень стабильный, жать ctrl+c можно и устать.
Ну так это у нас не найти, а они ориентируются на другие страны, где много жителей и поближе к ним. Индию, африку, ну куда там ещё. В общем где безлимитка дорогая, а DVD-ROM-ов до недавнего времени не было. Значит и флешек на 8 гигабайтов хотя бы, дешёвых там тоже нет.
По моему опыту медленные каналы стимулируют развитие "флопинета". Если канал толстый на каждом шагу, проще нужную инфу скачать чем таскать за собой флешку или винт рискуя его потерять вместе с важной, а зачастую ещё и с конфиденциальной, инфой.
Я понимаю, что чем меньше образ тем проще скачать. Но +50м это смешно. Если всеравно не лезет на сд уже б остановились на обкатаном 1.2.
ЗЫ сам ставлю по PXE либо из нетинсталов.
> Если всеравно не лезет на сд уже б остановились на обкатаном 1.2.Зато на гиговую флешку влезет...
>> Если всеравно не лезет на сд уже б остановились на обкатаном 1.2.
> Зато на гиговую флешку влезет...На гиговую флешку влезет не только 750, но и 1000. Изо всего списка планируемых изменений это действительно самое идиотское. Хотя, конечно, жираф большой...
Цитата из новости:
> По расчетам разработчиков 750 Мб является оптимальным размером, с учетом обеспечения комфортного для пользователя времени загрузки.
И что с того?
> Цитата из новости:
>> По расчетам разработчиков 750 Мб является оптимальным размером, с учетом обеспечения комфортного для пользователя времени загрузки.Скорее, задача стояла так: обеспечить потерю совместимости с минимальным выигрышем по остальным параметрам.
да-да, злой коварный Шатлворд решил сам себе убытки сделать с минимальным выигрышем по остальным параметрам. Параноя перешла в маразм.
Да уж. Феерический бред. Непонятно, почему уже не успокоиться и не перейти на одну сборку вместо двух.
Такое впечатление что у них там засела группа ретроградов, которые не сдаются до последнего.
> Размер традиционного iso-образа для Ubuntu 12.04 решено увеличить до 750 МбСделали бы 3 - 4,5 гигабайтов, как у всех. Я бы не назвал это отказом от CD: в режиме Overburn или на специальный диск в 800 мегабайтов записать можно.
> Из базовой поставки Ubuntu 12.04 решено удалить Mono
Позитивно конечно, но какая разница.
> Начиная с Ubuntu 12.04 официально будет рекомендовано использовать сборку для 64-разрядных систем
По-умолчанию галочка будет стоять у 64-битного iso? Ну хорошо.
> Более тесная интеграция с Ubuntu One
Это хорошо, а то уже казалось, что не работают люди.
> В Ubuntu 12.04 будут улучшены средства Unity для работы на нескольких мониторах
Кстати, довольно-таки тяжело им придётся работать: всю жизнь если не nvidia, на двух мониторах Compiz глючил.
> В Ubuntu планируется задействовать GNOME-фреймворк Zeitgeist для отслеживания активности пользователя и организации поиска документов и пользовательской информации.
В том смысле что по-умолчанию? Ну неудивительно: Mono убрали, значит и Beagle уже не задействовать.
> Стабилизация и обеспечение неизменности API, а также средств разработки графических приложений для Ubuntu
API чего. Чего?!?! Они решили GUI сами писать?! Не прошло и 10 лет как до них дошло, что в их дистрибутиве нет GUI, и всё приходится настраивать из консоли!
> Улучшение интеграции специфичных для Ubuntu процессов (bzr, Launchpad) и инструментов со средствами разработки Qt
Скандал с гноммерами даёт свои последствия
> Планируется добавить в репозиторий неофициальный пакет с ядром Linux "lowlatency", в котором будут задействованы оптимизации, направленные на увеличение отзывчивости и уменьшение задержек
А вот это позитивно. Когда ядро с -rt в репозитарии вернут?! Ну всегда же было.
> Продолжение улучшения поддержки системы виртуализации KVM, добавление поддержки протокола SPICE и адаптация для платформы ARM
Иногда мне кажется, что убунту предназначался для энтерпрайса и для продвинутых пользователей изначально, но позиционирует себя всегда как дистрибутив для новичков почему-то. Наверное потому что гонится за популярностью (смотри "Баг 1").
> В Ubuntu 12.04 планируется полностью избавиться от появления текстовой консоли в процессе перехода в спящий режим, обеспечив только работу в графическом режиме
Да толку-то, если у них настроечных GUI почти нет.
> Будет проведена работа по уменьшению времени загрузки
Ну это обещают каждый раз.
> Планируется обеспечить определённый уровень интеграции с Systemd и PackageKit, в частности компонентов данных систем, которые используются в GNOME. В основном речь ведётся о помещении в репозиторий main некоторых интерфейсов Systemd
Хорошо что не по-умолчанию.
>А вот это позитивно. Когда ядро с -rt в репозитарии вернут?! Ну всегда же было.rt не связано с низкой отзывчивостью
Те, кто минусуют, не знают разницы между низкой и гарантированной отзывчивостью.
> rt не связано с низкой отзывчивостьюЯ знаю. Однако ещё в релизе 7.10 -rt было, а сейчас нет. Пользуясь случаем, спросил у пользователей, может кто-нибудь слышал.
> Сделали бы 3 - 4,5 гигабайтов, как у всех.Чтобы у них после релиза сервера упали и больше вообще не очухались целый месяц? :)))
> Я бы не назвал это отказом от CD: в режиме Overburn или на специальный
> диск в 800 мегабайтов записать можно.Проблема только в том что CD дисков которые на 750 мегов без проблем нарежутся - не густо.
>> Из базовой поставки Ubuntu 12.04 решено удалить Mono
> Позитивно конечно, но какая разница.Торжество здравого смысла!
>> Сделали бы 3 - 4,5 гигабайтов, как у всех.
> Чтобы у них после релиза сервера упали и больше вообще не очухались целый месяц? :)))У других же не падают.
Сейчас раздаю торрентами свой дистрибутив. В данный момент 800 раздающих. Разумеется торрент запущен не только для этого.>> Я бы не назвал это отказом от CD: в режиме Overburn или на специальный
>> диск в 800 мегабайтов записать можно.
> Проблема только в том что CD дисков которые на 750 мегов без проблем нарежутся - не густо.Недавно я копировал CD-диски объёмом 800 мегабайтов на CD-R. Зашёл в магазин за CD-R в 800 мегабайтов, было два. А мне столько и надо было. Даже в провинции продаётся.
>>> Из базовой поставки Ubuntu 12.04 решено удалить Mono
>> Позитивно конечно, но какая разница.
> Торжество здравого смысла!Раньше Mono так не ненавидели и он не был встречен негативно. И даже на опеннете - -50 новости набирали усилиями накрутчиков, и я думаю это очевидно. Мне кажется, выгодно это кому-то. В подтверждение своих слов скажу, что последняя новость о Mono вообще в плюсе.
Что писали, например, о нём. "Вот раньше Microsoft заимствовал у всех технологии, и ничего своего у них не было. Теперь они сделали, наконец, что-то хорошее, и мы у них это позаимствовали".
Как вы каждое предложение откомментировали-то. А главное, ваши комментарии очень важны, насущны и интересны. Вам бы литературным критиком работать, с таким-то талантом рецензии делать. Думаю, многим будет интересно прочитать ваши "годно", "хорошо", "позитивно", "не нужно".
> Как вы каждое предложение откомментировали-то. А главное, ваши комментарии очень важны,
> насущны и интересны. Вам бы литературным критиком работать, с таким-то талантом
> рецензии делать.В Ubuntu тоже хорошие литературные таланты пропадают. Такие, знаете ли, мастера расписать, как все хорошо будет очень скоро. Еще бы им мастеров, которые смогли бы действительно так хорошо сделать...
> В Ubuntu тоже хорошие литературные таланты пропадают. Такие, знаете ли, мастера распиаритьВот так лучше.
>Размер традиционного iso-образа ... решено увеличить до 750 Мб
>...решено удалить Mono и связанные с ним приложения...Скромненько так... Надо решительнее быть!
Размер исошника увеличить до 2-8GB, и выкинуть всё, что не-GPL-ное и потенциально не свободное, пакетный менеджер заменить на portage.
Смеялся долго :)
Начните выкидывание с иксов :-) Причем прямо сейчас.
Убей в себе не-GPL!
> Смеялся долго :)
> Начните выкидывание с иксов :-) Причем прямо сейчас.
> Убей в себе не-GPL!Иксы уже успели закрыть?
Поинтересуйтесь под какой они лицензией. Подсказываю: не GPL.
Лицензия X11 не является копилефтом. Так-то.
>В настоящее время едётся работа по переписыванию Zeitgeist с Python на Vala, что позволит решить проблемы с излишним потреблением ресурсов и производительностью.Правильно!
Никакого постоянстваGnome - Unity
Xorg - Walyand
Mono удален,
Rhuthmbox -> удален -> возвращен
tomboy -> gnote
Xorg - Wayland
Evolution - thunderbirdтуда-сюда-обратно.. Это конечно крутая видимость работы, но пользователи Ubuntu - вам нравится такие изменения каждый год;) Администраторам и программистам это не в тягость, но домохозяйкам нужна стабильность.
Домохозяйкам пофигу, что там, да как
Нет не пофигу. С каждым новым обновлением определенный файл будет открываться в другой программе. Они в отличие от тебя (хотя и ты возможно это не делаешь) Release-Notes не читают, как и новости о развитие Ubuntu
> С каждым новым обновлением определенный файл будет открываться в другой программе.С чего бы вдруг? Это при новой установке по умолчанию будут другие программы, а при обновлении что было, то и останется.
О, да! Если после такого апдейта что-нибудь не отвалиться! =)))
Пока открывается - пофигу.
Про Xorg - Wayland аж два раза написал.
>>Администраторам и программистам это не в тягость, но домохозяйкам нужна стабильность.Я плакаль! :D
> Gnome - UnityГномеры не оставили выбора. Их гномошит - ужасен.
> Xorg - Walyand
А он где?
> Mono удален,
Давно пора!
> Rhuthmbox -> удален -> возвращен
Ну, попробовали какашку на дотнете и поняли что с ней мучений еще больше. Хотя и так понятно было чем закончится.
> tomboy -> gnote
Давно пора! Переть ради 2 вшивых программок, стартующих по 20 сек более 100 Мб рантайма - нафиг-нафиг-нафиг-нафиг! Как говорят буржуи - kill it with fire!
> Xorg - Wayland
Что, еще раз? Или два раза - для солидности?
> Evolution - thunderbird
И правильно сделали. Сразу надо было.
> туда-сюда-обратно.. Это конечно крутая видимость работы, но пользователи Ubuntu - вам нравится
> такие изменения каждый год;) Администраторам и программистам это не в тягость,
> но домохозяйкам нужна стабильность.Лично я как пользователь убунтов все перечисленные изменения одобряю. Кроме разве что вэйланда, который вы написали 2 раза, а я его видел только на картинке.
> Гномеры не оставили выбора. Их гномошит - ужасен.На самом деле они не осознали правильный выбор. Для 3-го Гнома Марку можно было запилить свою африканскую красно-оранжево-малиново-коричневую тему и набросить на Гномошелл несколько дополнений, которые сделали бы из 3-го Гнома Юнити. Скорее всего, это было бы дешевле, чем пилить на основе GTK+3 свою оболочку.
> На самом деле они не осознали правильный выбор. Для 3-го Гнома Марку
> можно было запилить свою африканскую красно-оранжево-малиново-коричневую тему и набросить
> на Гномошелл несколько дополнений,Они высказывали гномерам некоторые мысли по части чего бы им хотелось от UI. Гномеры забили. Ну и на гномеров забили и пошли писать юнити. Все вроде бы честно. Хотя как по мне - оба интерфейса годны в основном для планшетов. Планшеты - это не есть плохо, но на них мир не кончается. Поэтому лично я предпочитаю хубунту. Оно с интерфейсом для писюка с клавой и мышкой, а не этих чертовых планшетов. Пытаться сделать из мощного писюка планшетку меня что-то не прет. К тому же у меня монитор без сенсорного экрана.
> которые сделали бы из 3-го Гнома Юнити. Скорее всего, это было бы дешевле,
> чем пилить на основе GTK+3 свою оболочку.Гномеры проявили себя некооперативными и пофигистичными субъектами, которым плевать на проблемы и пожелания убунтоидов. Поэтому убунтуи вырулили как умели сами. Вроде бы логично.
А ещё они от ихней либы clutter до сих пор открещиваются. Вон Totem планируют оставить от Gnome 3.0, например. Может с переходом гномошелла на llvm-перекомпилятор для систем без 3D-ускорителей они его и обновят, а пока вот так.
> А ещё они от ихней либы clutter до сих пор открещиваются. Вон
> Totem планируют оставить от Gnome 3.0, например. Может с переходом гномошелла
> на llvm-перекомпилятор для систем без 3D-ускорителей они его и обновят, а
> пока вот так.Честно говоря я вообще не понимаю какой смысл в этом их totem. На редкость унылая и бесполезная программа, которую лично я после инсталла сношу к чертям одной из первых. Лично я пользуюсь vlc или mplayer, до которых тотему как пешком до пекина. Наверное там какие-то патентные дела мешают, т.к. указанные поддерживают множество кодеков, включая и патентованные :(.
Существует аналог тотема в кедах - драгонплейер, такой же убогий. Их убогость происходит из следования гайдлайнам для идиотов - HIG.
> Их убогость происходит из следования гайдлайнам для идиотов - HIG.You sould KISS;)
По крайней мере, следование вышеупомянутым гайдам уберегает разработчика от глупости аля "а давайте одно и то же продублируем везде" — захламить интерфейс так, что при виде всего этого так и хочется закрыть всё к чертям и больше не видеть.
Лично я полностью согласен с принципом продуманного функционала — реализуй самое главное, да так, чтобы довольными остались все, или почти все (давно не секрет, что всем на свете не угодить).
IMHO, яркий пример полнейшего забивательства на HIG — KDE.
Пусть будет как в KDE, не надо окон настроек с одной кнопкой - сами таким пользуйтесь. Минимализм в функционале - это нежелание продумывать дизайн, делают полторы кнопки чтобы пользователь уж точно не смог ошибиться, а то что остальные "плюшки" можно добыть только ручной правкой конфигов это считается нормальным.
> Пусть будет как в KDE, не надо окон настроек с одной кнопкой
> - сами таким пользуйтесь.Особенно прикольно когда например у некоего драйвера opengl вывод видео в 2 раза быстрее xv или наоборот, а куда выводить - выбрать низзя и так уж получилось что оно через тормозной интерфейс играет. И выбор между наслаждением слайдшоу и "снести эту гадость и поставить нормальный плеер", понимающий все форматы и умеющий нужные настройки имхо очевиден.
В идеальном мире автоматическая подтиралка задницы может не так уж плохо. В реальном мире, если она будет каждые 5 минут по таймеру подтирать на случай "а вдруг вы обосретесь?" - а может ну его такое, да?
>> Их убогость происходит из следования гайдлайнам для идиотов - HIG.
> You sould KISS;)
> По крайней мере, следование вышеупомянутым гайдам уберегает разработчика от глупости аля
> "а давайте одно и то же продублируем везде" — захламить интерфейсА еще оно меня оберегает от проигрвания имеющихся у меня форматов видео и элементарных настроек, нужных чтобы просмотр видео не превращался в мучение и слайдшоу.
> Честно говоря я вообще не понимаю какой смысл в этом их totem.Честно говоря, я не вижу столь явных причин для ярого троллинга сего приложения: вполне себе юзабельная вещь, которая(!) при смене аудиодорожки не начинает воспроизведение с начала, в отличии от хвалёных вами vlc или mplayer.
Да, не умеет подцеплять внешние аудиодорожки и прочее, не очень часто пользуемое. Хотя я даже не копал в этом направлении (может для этого плагин есть какой, — не проверял).
>без непосредственного использования systemd в системеой да хватит ломаться. Взяли бы полностью перешли, хотя наверное на следующем LTS уже перейдут.
Нет.
> ой да хватит ломаться. Взяли бы полностью перешли, хотя наверное на следующем
> LTS уже перейдут.А зачем им? У них свой вполне годный апстарт есть. Умеет конечно поменьше systemd, зато не обладает массой проблем с которыми героически борятся федористы.
> А зачем им? У них свой вполне годный апстарт есть. Умеет конечно поменьше systemdДело даже не в фичах. Архитектура upstart, с ее завязанностью на события, изначально ущербна по сравнению с архитектурой launchd (используемой в systemd).
> массой проблем с которыми героически борятся федористы.
Это каких например? Только не надо повторять сказку про проблемы с /usr на отдельном разделе - философы с таким незнанием матчасти сразу идут лесом.
> Дело даже не в фичах. Архитектура upstart, с ее завязанностью на события,
> изначально ущербна по сравнению с архитектурой launchd (используемой в systemd).Не вижу ничего такого ущербного в завязанности на события. Оно конечно требует некоей перестройки мышления, но не фатально, имхо. Во всяком случае, когда стало актуально - лично я написал своим кастомным сервисам за целых 10 минут :))) знакомства с апстартом аж 3 конфига (вообще не читая маны, просто погуглив как это делают другие и на лету врубившись). Вроде все прозрачно и понятно, никакой особой ущербности не ощутилось и работает как мне было надо.
>> массой проблем с которыми героически борятся федористы.
> Это каких например? Только не надо повторять сказку про проблемы с /usr
> на отдельном разделе - философы с таким незнанием матчасти сразу идут лесом.Да что-то федористы бросились файловые системы перетрясать как раз при внедреже systemd. Совсем случайное совпадение. А нытье про то что в стартовом рамдиске нет того, нет сего и вообще слишком гиморно туда переть всю диру такую-сякую, поэтому давайте мы лучше все до основанья - наверное мне вообще приснилось, а вовсе не федористами было высказано.
>Evolution - thunderbird... домохозяйкам нужна стабильность.домохозяйкам хватит веб-интерфейса за глаза. Подключить свою почту через почтого клиента они скорее всего не осилят.
Thunderbird-у, например, достаточно сказать только почтовый адрес и пароль, остальное он сам определит.https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
статья старая, пишут что gnote намного быстрее стартует и ест меньше оперативной памяти чем tomboy. http://techrights.org/2009/05/01/gnote-vs-tomboy-test/
А разве для программы, переписанной с C# на С это не очевидно?
нет
> нетСудя по тому что писаное на C# не стартует менее 20 8-\ секунд на моем _четырехядернике_ - это как раз вполне очевидно. При том что томбой, что ф-спот, что какая там еще блевотень. При том сишные программы, даже очень тяжелые, стартуют в разы быстрее. Знаете, господа дотнетчики, сами ждите 20 секунд запуска гребаного менеджера заметок. Совсем упоролись!
>> нет
> Судя по тому что писаное на C# не стартует менее 20
> 8-\ секунд на моем _четырехядернике_ - это как раз вполне очевидно.
> При том что томбой, что ф-спот, что какая там еще блевотень.
> При том сишные программы, даже очень тяжелые, стартуют в разы быстрее.
> Знаете, господа дотнетчики, сами ждите 20 секунд запуска гребаного менеджера заметок.
> Совсем упоролись!Ты его с микросд носителя чтоли запускаешь? давай пруфы на такие резкие высказывания
> Ты его с микросд носителя чтоли запускаешь? давай пруфы на такие резкие высказыванияПробовал с лив-флешки, с ливцд, с винча. Время старта может задолбать даже слона во всех трех случаях.
неочевидно насколько, там конкретные цифры
Когда переключение задач в Unity станет таким же органичным, как это было в GNOME2, вернусь. А пока лучше-ка я пересижу эту планшетную эпидемию в KDE - хоть нервов себе сберегу ;)
Пересиживать не надо. Просто используй КДЕ. :) В 4.8 будет реактивный dolphin , а плазму уже победили, квин уже достаточно шустрый. Да и ваще видно что оно хорошеет и при этом не выпиливается функционал (попробуйте найти настройку про реакцию на кнопку повер в гном3),а потом посмотрите менеджер питания в кде. А для мобильных девайсов есть\будет Plasma Active.
замочили Mono. давно ждал, предлагаю отметить. до этого всегда руками вычищал проприетарное г-но в виде жабы и моны
> г-но в виде жабы и моныЖабы там к счастью и так не было :). Но за вычистку моны им большое спасибо. Меньше гемора при инсталле убунты другим.
Скорее всего, что 64 бита будут работать так же как и 32, только памяти можно использовать от 4-х и более гигабайт, а все эти слова о производительности, скорее маркетинговый ход, да даже если и производительнее, то это будет не шибко заметно.
> эти слова о производительности, скорее маркетинговый ход, да даже если и
> производительнее, то это будет не шибко заметно.Как бы от алгоритмов зависит. Например алгоритмы активно использующие 64-битные числа на 64-битном проце работают быстрее. И, допустим, любая современная файловая система величиной в 4Гб как-то не ограничивается, что вынуждает активно оперировать с числами крупнее 2^32.
позитивные изменения, имхо.
> позитивные изменения, имхо.s/изменения/намерения/
Да вот только чего я на своем i686, не могу запустить 64-разрядный Ubuntu, а Archlinux запускаеться без проблем?
лол щито? Оо
> Да вот только чего я на своем i686, не могу запустить 64-разрядный
> Ubuntu, а Archlinux запускаеться без проблем?А у меня подводная лодка ну совсем никак не хочет взлетать. Даже с рельсов!
Поздравляю проект с обретением мудрости!
С этим рано поздравлять. Если выберут KDE как основное де - тогда будет пора.
Согласен, я и сам на KDE сижу ;) но про Mono, 64 бита и замену тормознутых прог аналогами на плюсах - уже неплохо для начала; да с приложениями на Qt вроде они лучше будут дружить. Так что да, надеюсь, когда-нибудь они перейдут на KDE, и наконец окончательно. Хотя лично мне не сильно важно - мне уже под Дебианом хорошо живется :) но далеким от компа людям дебиан не поставишь (если нет хорошего технического мышления), а вот Mint/Ubuntu - пожалуйста
> - MONO + 64bitВот теперь я их уважаю :)
>> - MONO + 64bit
> Вот теперь я их уважаю :)Да уж. Единственное что это надо было сделать лет 5 назад, чтобы поменьше распостранять MSовскую заразу. MS все-равно поматросил-бросил в пользу HTML5.
>Вот теперь я их уважаюОне счастливы.
А Wayland не напрягает? Не хочу разводить очередной холивар на тему Wayland vs X11/X12, но лично меня пугает этот Wayland. Пугает опасность того, что глюпые людишки не понимая красоты клиент-серверной прозрачности полюбят эту путьземлю, а в след за пользователями и дистрибьюторы начнут делать на него акцент.
> А Wayland не напрягает?Да мне как-то пофигу, я Убунту все равно не юзаю.
Я про то, что на них смотрят остальные дистрописатели,
и под это дело снесут у себя МОНО и задумаются над 64 битами.
С образом 750 Мб они явно погорячились. Между 750 Мб и 2 Гб разницы никакой, всё равно записывать на 4,7 гиговую болванку. Разница только в скорости скачивания. Для скоростного канала это не принципиально. А на медленных каналах тем более, ибо какая разница -- 2 дня будет качаться или 4, всё равно долго ждать. Сделали бы уж 1 универсальный DVD-образ для каждой платформы.Отказ от Моно - верный шаг. Зачем из-за пары-тройки программ, которые можно заменить аналогами, тащить в систему большую и прожорливую до ресурсов прослойку?
Что касается 64/32-разрядной сборки, видимо, Убунту в её нынешней комплектации уже бессмысленно ставить на слабые машины с RAM < 2 Гб, поэтому решение достаточно очевидное.
>Что касается 64/32-разрядной сборки, видимо, Убунту в её нынешней комплектации уже бессмысленно ставить на слабые машины с RAM < 2 Гб,Я тоже так думал. А потом оказалось, что Убунта 11.04 на моем нетбуке (Atom N270, 1GB) бегает быстрее, чем стоявшая там до нее ХРюша.
>>Что касается 64/32-разрядной сборки, видимо, Убунту в её нынешней комплектации уже бессмысленно ставить на слабые машины с RAM < 2 Гб,
> Я тоже так думал. А потом оказалось, что Убунта 11.04 на моем
> нетбуке (Atom N270, 1GB) бегает быстрее, чем стоявшая там до нее
> ХРюша.LOL!!! Ну насмешил!!! Ты бы хоть какие-нибудь доказательства привел, а то похоже балабольство.
Не знаю как привести сюда доказательства. Но Асус с виндой MCI с убунтой 11.10 оба напротив меня. Платформа одна atom 270 intel. Обе машинки из первых 10'. Но то что MCI летает, Asus так себе, это видно на глаз. Если включить антивирус Asus ползает. Время загрузки ubunta быстрее. Подключение к wifi - windows быстрее. Просмотр интернета - ubuntu существенно быстрее, хотя немного проигрывает при первом запуске ff. Просмотр pdf ubuntu быстрее. Где реально проигрывает ubuntu это просмотр каталога с большим количеством файлов. То есть С:\windows\systems32 видно быстрее чем /usr/bin .
Это то что я сейчас наблюдаю.
Днями поставил Mint 11 на старый ноут с 1GB ram , в замен XP, которая жутко тормозила, минут по пять минут после загрузки винт жужжал без умолку.
Как не удивительно Mint оказался намного отзывчивые, при старте с gnome2 отъел 300 метров.
Многие на флэшку записывают, а не на болванку. Причем не на всю емкость.
> Причем не на всю емкость.Какая разница на всю ли, таблица разделов все равно слетит ?(или ее бэкапят, а образ сразу удаляют?)
Речь о том, что на флешке не Убунтой единой...
Как пример, использоваться Ubuntu.iso из-под загрузчика grub4dos. Тут уже есть смысл рассуждать о соотношении "размер образа"/"оптимальный набор программ".
> Из базовой поставки Ubuntu 12.04 решено удалить Mono и связанные с ним приложения, такие как Banshee и Tomboy...
> В качестве источников данных в Zeitgeist будут использованы Banshee...че-то непонятно, удалят Banshee или нет...
> Другой важный аргумент в пользу Rhythmbox - готовность порта для GTK3+, в то время как портирование Banshee на GTK3+ пока не завершено.
т.е. отказываются от приложения только потому, что нет порта под GTK3+
может просто помоч ребятам запилить этот порт?
непонятно...
>> В качестве источников данных в Zeitgeist будут использованы Banshee...
> че-то непонятно, удалят Banshee или нет...Читай до конца и думай! Возможность не является необходимостью.
3-го Гном и Unity - две вещи на которые не могу смотреть.
очень привык к GNOME2, придется ставить KDE:(
А что, XFCE, LXDE или там на худой конец какой-нибудь WM религия не позволяет ставить?
> А что, XFCE, LXDE или там на худой конец какой-нибудь WM религия
> не позволяет ставить?Пусть сначала попробует КДЕ , оно того стоит. Хфце\лхде как последний вариант ,если ресурсы беречь надо\мало.
> очень привык к GNOME2, придется ставить KDE:(Try XFCE, Luke!
>Вместо Banshee в качестве музыкального проигрывателя будет возвращён Rhythmbox, что позволит упростить адаптацию пользователей, переходящих с прошлого LTS-релиза (Banshee был интегрирован в Ubuntu 11.04).[Vanga-mode ON]
Наверняка в планах на 12.10 будет включено выпиливание Rhythmbox и возвращение Banshee.
[Vanga-mode OFF]
>>Вместо Banshee в качестве музыкального проигрывателя будет возвращён Rhythmbox, что позволит упростить адаптацию пользователей, переходящих с прошлого LTS-релиза (Banshee был интегрирован в Ubuntu 11.04).
> [Vanga-mode ON]
> Наверняка в планах на 12.10 будет включено выпиливание Rhythmbox и возвращение Banshee.
> [Vanga-mode OFF]И ещё Mono вернут...
не планируют ли ни уменьшить количество критических багов. У меня сложилось впечатление, что они что-то добавляют забывая о стабильной системе без критических багов
> не планируют ли ни уменьшить количество критических багов. У меня сложилось впечатление, что они что-то добавляют забывая о стабильной системе без критических баговЭто задача Debian. Для Ubuntu важнее все-таки свежий софт.
>> не планируют ли ни уменьшить количество критических багов. У меня сложилось впечатление, что они что-то добавляют забывая о стабильной системе без критических багов
> Это задача Debian. Для Ubuntu важнее все-таки свежий софт.Свежий софт - это Арч, для убунту важнее пиар.
> В настоящее время ведётся работа по переписыванию Zeitgeist с Python на Vala, что позволит решить проблемы с излишним потреблением ресурсов и производительностью.Неужели питон стал медленный и толстый?
> Неужели питон стал медленный и толстый?Он всегда таковым и был. Потому что интерпретер галимый.
>> В настоящее время ведётся работа по переписыванию Zeitgeist с Python на Vala, что позволит решить проблемы с излишним потреблением ресурсов и производительностью.
> Неужели питон стал медленный и толстый?Питон здесь отработал сполна и завершил свою миссию, Теперь очередь vala.
Блин! Вот это я понимаю, новости! Еще бы и роллинг-релиз! А то LTS для для офисного планктона, а им все эти новшества по барабану.
роллин не роллинг а все равно нужно будет ставить с нуля. Как показала ЛТС то длительный срок не означат качество и отсутствие критичных багов.
Чудесато всё - стандартного образа в 700 мег на базовую установку хватало с кепкой, тем более, что собрались ещё и "выпиливать" оттуда кучу всего... (Руками вынести - тоже не проблема. Выношу FireFox, Tomboy, кучу мессенджеров, OOo... Доставляю LibreOffice, Opera, SMPlayer...)
Имея носитель на 4,7 гига ограничиться объёмом в 750 мег?!!! А говорят, что природа не терпит пустоты...
> Чудесато всё - стандартного образа в 700 мег на базовую установку хватало
> с кепкой, тем более, что собрались ещё и "выпиливать" оттуда кучу
> всего... (Руками вынести - тоже не проблема. Выношу FireFox, Tomboy, кучу
> мессенджеров, OOo... Доставляю LibreOffice, Opera, SMPlayer...)
> Имея носитель на 4,7 гига ограничиться объёмом в 750 мег?!!! А говорят,
> что природа не терпит пустоты...Это ваши действия чудесатые - внезапно, последние релизы и так не содержат OOo. Ну и очевидные вещи надо напомнить - opera не нужна, не надо нам проприетарного "интернета".
> Чудесато всё - стандартного образа в 700 мег на базовую установку хватало
> с кепкой, тем более, что собрались ещё и "выпиливать" оттуда кучу
> всего... (Руками вынести - тоже не проблема. Выношу FireFox, Tomboy, кучу
> мессенджеров, OOo... Доставляю LibreOffice, Opera, SMPlayer...)
> Имея носитель на 4,7 гига ограничиться объёмом в 750 мег?!!! А говорят,
> что природа не терпит пустоты...Незнаю как природа, а мне куда больше по душе формат business-card, а вот его никто не предлагает. Очень жаль.
Вот не пойму почему они приняли как стандартный образ 750 мб, а не 1500. Оба же на CD не влазят
750 влазит
Это.Зависит.От.Размера.Тех.Мегабайтов!
Я обновил свою "11.04" до "11.10" и пожалел об этом. И говорят что многие- тоже. Если бы я общался с разработчиками и указал бы им на все те недостатки и если бы они это учли, то тогда всех этих проблем было бы намного меньше. Что будет с "12.04"? (насколько высок риск ошибок, если ОС на новый релиз обновляется через сеть а не ставится на чистый диск с нуля? (если такие ошибки есть то легко ли их выправить без переустановки?)
> Я обновил свою "11.04" до "11.10" и пожалел об этом. И
> говорят что многие- тоже. Если бы я общался с разработчиками и
> указал бы им на все те недостатки и если бы они
> это учли, то тогда всех этих проблем было бы намного меньше.
> Что будет с "12.04"?Зависит от того, будете ли вы общаться с разработчиками _теперь_.
> Я обновил свою "11.04" до "11.10" и пожалел об этом. И
> говорят что многие- тоже. Если бы я общался с разработчиками и
> указал бы им на все те недостатки и если бы они
> это учли, то тогда всех этих проблем было бы намного меньше.
> Что будет с "12.04"? (насколько высок риск ошибок, если ОС на
> новый релиз обновляется через сеть а не ставится на чистый диск
> с нуля? (если такие ошибки есть то легко ли их выправить
> без переустановки?)Миша, таких версий венды не было.
Unity это продукт для домохозяек которые видели и хочут Apple,
Gnome2 собсна для хозяюшек с стокгольмским синдромом после XP..
Молодцы!!!
Приняли направление и идут вперед. Я очень рад за них и за себя, так как мне импонирует новая Ubunta.
Наконец то моно выкинут из поставки по умолчанию.
Здорово, что они стараются сделать максимально целостной систему, а дополнительные технологии не выкидывают, но оставляют опцией.Единственное, чего бы от них еще хотелось, чтобы их технологии типы Ubuntu One тоже легко исключались из системы в случае не надобности.
>Unity это продукт для домохозяек которые видели и хочут Apple,
>Gnome2 собсна для хозяюшек с стокгольмским синдромом после XP..на работе работаю на Маке,- ничего похожего и даже отдаленно напоминающего Unity не видел. Gnome2 более похож на Мак чем на XP
Да уж, никак не приладят 64 бита, т.к. он практически ненужен. В идеале нужно только ядро 64 бита и несколько тяжелых преложений + gzip/bzip2/etc., а остальное оставить как 32 бита. Великого перехода с 32 на 64, как это было с 16/32 уже не будет. Это я вам как доктор с 15-летним стажем работы с 64-ми системами скажу.Вот бы еще ядро по-оптисали бы получше, а то такое тормозное.
> Да уж, никак не приладят 64 бита, т.к. он практически ненужен.Хз. У меня на боевых серверах в CentOS 6 нет ни одного x32 приложения и ни одной x32 библиотеки. Что я делаю не так?
>Это я вам как доктор с 15-летним стажем работы с 64-ми системами скажу.15 лет назад? Что там было 64-битного? Альфы? Ну да, на них софта нет как и их самих.