31

Vadimsky пишет:

У меня:
Мамка Asus P5QL PRO
RAM 4 Гб
два 32-х бт ядра одно дефолтное, видит 3,6 Гб, второе PAE видит 4 Гб.
До этого была материнка (не помню какая) на чипсете nForce. Так она видела 3,6 Гб при любом ядре (даже самосборном).
Бывают такие материнки, с которыми как не изголяйся, выше 3,6 не видит.

для того, что-бы использовать более 4х Гб нужно 3 вещи:
1) поддержка процессорм PAE (есть везде)
2) поддержка PAE материнкой
3) поддержка PAE системой

Если хоть один пункт не выполнен, то ядро системы увидит максимум 4Гб, из которых будет доступно ещё меньше.

А можно использовать 64х битные системы и процессоры. Вот только 64 вдвое больше 32х, и очевидно, 64х битный компьютер работает вдвое медленнее, при прочих равных.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

32 (19.02.2011 14:50:13 отредактировано Vadimsky)

drBatty пишет:

для того, что-бы использовать более 4х Гб нужно 3 вещи:
1) поддержка процессорм PAE (есть везде)
2) поддержка PAE материнкой
3) поддержка PAE системой

Если хоть один пункт не выполнен, то ядро системы увидит максимум 4Гб, из которых будет доступно ещё меньше.

Ну я собственно про это и сказал, на своём примере, просто вывод не сделал.  smile

Истина ускользает от тех кто отказывается её видеть обоими глазами.
Талантам нужно помогать, бездарности пробьются сами.
В Туле настолько суровые парни, что вместо пены для бритья, используют пену монтажную.
cat /broken/hands > /dev/null

33

drBatty пишет:

64х битный компьютер работает вдвое медленнее, при прочих равных.

это с чего вдруг-то?

34

Hrafn, тут на глаз меряют и сравнивают с третьим пнём исходя из PIII = Core2DUO smile

Linux Mint 19.3 Mate Edition
Windows 7

35

похоже на то

36

Hrafn, просто DrBatty как обычно расхваливает свой комп и всеми за за "downgrade" в технологиях wink

Linux Mint 19.3 Mate Edition
Windows 7

37

drBatty пишет:

64х битный компьютер работает вдвое медленнее, при прочих равных.

только вот, эти "прочие" не могут быть равными.

drBatty пишет:

RAM-диском тут не поможешь. Да и зачем это нужно-то?

Я могу привести пример, зачем это нужно:
/tmp у меня на tmpfs-диске, диск этот довольно большой, так, если собирать опеноффис, то он съедает почти всю память и большую часть свопа. Если бы у меня архитектура была x86, я бы предпочел просто отдать часть памяти на tmpfs, чем юзать PAE, который как не крути, а всеже костыль.

Йа тьомный эльф

38

Не имею ничего против tmpfs, но как часто вы собираете ОпенОфис, сколько раз в день?  smile

Истина ускользает от тех кто отказывается её видеть обоими глазами.
Талантам нужно помогать, бездарности пробьются сами.
В Туле настолько суровые парни, что вместо пены для бритья, используют пену монтажную.
cat /broken/hands > /dev/null

39

Vadimsky пишет:

Не имею ничего против tmpfs, но как часто вы собираете ОпенОфис, сколько раз в день?  smile

Ну, как известно, гентушник компилирует опеноффис как раз сотлько времени, сколько нужно, чтобы выпустить новый релиз опеноффис. (-;
Шутка. Это просто гипотетический пример. Если подумать, можно придумать и другой. А так, конечно, в большинстве случаев просто неважно, из какой памяти выделяется tmpfs. И, на мой взгляд, не так уж часто встречаются х86 процессоры (которых уже практически негде купить) с >4гб памяти. А уж ОС, неподдерживающую амд64, найти просто нереально. Кстати, одним из последних делать сборки под амд64 стал небезызвестный Патрег.

Йа тьомный эльф

40

Hrafn пишет:
drBatty пишет:

64х битный компьютер работает вдвое медленнее, при прочих равных.

это с чего вдруг-то?

очевидно, что пить пиво из пол-литровых кружек ровно в 2 раза дольше, чем из кружек по 0.25. Вы разве не знали? другое дело, что этих "прочих равных" обычно не получается. Но факт остаётся фактом: тыща указателей в 64 бита ровно в 2 раза больше и передаётся/обрабатывается ровно в два раза дольше. Исключение - это если процессор работает ТОЛЬКО с 64х битными указателями, тогда они только выедают лишнюю память, это приводит в частности к тому, что 64х битный код не влезает в кеш, и соответственно работает в разы дольше. Вообще всё это неоднозначно - огромному числу задач просто не нужны такие объёмы памяти, и для них 64 бита не нужно, им пойдёт и 2по32 сразу, а так умеют все процессоры, начиная с iP-MMX (это расширение как раз и использует 64х битные регистры и операции с ними.) Потому, 64х битность - задел на будущее, и хороший маркетинговый ход.

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

Дело вот в чём:

Изначально, много лет назад, процессор i8086 умел считать только целые числа, а вещественные не умел. Если кому-то надо было считать вещественные, то они считались перобразованием в целые и обратно. Что естественно очень долго. Потому сделали сопроцессор i8087, который имел вщсемь 80и битных регистров, и работал одновременно с основным. Во времена i80486 его наконец засунули на один кристалл с основным. Потом интелловцев заушила жаба - у них на кристалле 8 регистров с ALU, которые постоянно простаивают, ибо FP мало кому нужна. А если и нужна, то очень редко. Ну они и научили эти регистры работать как 64х битные целые. И назвали это MMX, ибо это здорово ускоряло графику, видео и звук (вообще-то там тоже FP, но она не очень точная, и её можно реализовать как целую). MMX изначально умела одновременно обрабатывать 8 байтов, или 4 слова, или 2 32х разрядных двойных слов, или одно 64х битное целое. Стало возможным смотреть сжатое видео, которое за счёт сжатия влезало на 1 CD. Потом MMX эволюционировала в SSE(1,2, и 3), правда это уже было не принципиально. Разве что с появлением HD.

Потому, современные процессоры уже много лет как 64х битные, и никакого увеличения производительности как при переходе от 8 к 16 битам ждать не следует. Скорее наоборот. Такие дела...

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

41

bobr пишет:
drBatty пишет:

64х битный компьютер работает вдвое медленнее, при прочих равных.

только вот, эти "прочие" не могут быть равными.

drBatty пишет:

RAM-диском тут не поможешь. Да и зачем это нужно-то?

Я могу привести пример, зачем это нужно:
/tmp у меня на tmpfs-диске, диск этот довольно большой, так, если собирать опеноффис, то он съедает почти всю память и большую часть свопа. Если бы у меня архитектура была x86, я бы предпочел просто отдать часть памяти на tmpfs, чем юзать PAE, который как не крути, а всеже костыль.

костыль. этот костыль помогает использовать маленькие и быстрые 32х битные указатели для адресации 64Гб. А без этого костыля вы вынужденны использовать большие и медленные 64х битные указатели, причём даже тогда, когда они вам не нужны. Причина, по которой 64х битные указатели медленнее очень проста - можно одновременно обработать 2 32х битных указателя, за тоже самое время, как и один 64х битный. Потому, часто оказывается, что система с 32я битами и PAE работает быстрее.

Но плюс от вынесения /tmp в память конечно очень значительный, ибо если она не влезет, заюзается своп, который в тыщу раз медленнее.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

42

drBatty пишет:

вы вынужденны использовать большие и медленные 64х битные указатели

bobr пишет:

Если бы у меня архитектура была x86

Будь у меня архитектура процессора х86, я бы не смог использовать 64х битные указатели в любом случае.
А скажем адресовать 5Гб с х86 процессором посредством PAE, чтобы из них 1.5Гб потом отдать на tmpfs было бы явно менее продуктивно, чем адресовать 3.5Гб памяти обычными указателями, а оставшуюся неадресованную память отдать tmpfs.
Только, пожалуйста, не рассказывайте мне, что нечасто такая необходимость возникает. Я и сам прекрасно понимаю. Еще раз повторюсь, это просто гипотетический пример.

И еще: все-таки сколько бит используется для адресации памяти в режиме РАЕ?

drBatty пишет:

этот костыль помогает использовать маленькие и быстрые 32х битные указатели для адресации 64Гб

Википедия пишет:

Physical Address Extension (PAE) — режим работы встроенного блока управления памятью x86-совместимых процессоров, в котором используются 64-битные элементы таблиц страниц (из которых для адресации используются только 36 бит)

Или это не одно и то же?

Йа тьомный эльф

43

bobr пишет:

3.5Гб памяти обычными указателями, а оставшуюся неадресованную память отдать tmpfs.
Только, пожалуйста, не рассказывайте мне, что нечасто такая необходимость возникает. Я и сам прекрасно понимаю. Еще раз повторюсь, это просто гипотетический пример.

дык проверьте, у меня сейчас под рукой нет компа такого, а сервера страшно трогать. ac

bobr пишет:

И еще: все-таки сколько бит используется для адресации памяти в режиме РАЕ?

программы используют 32 бита, потому каждый экземпляр программы может юзать не более 4Гб. Однако программисты могут раздвоить программу на 2 нити, каждая из которых будет юзать СВОИ 4Гб. Т.о., программа может адресовать все 64Гб.

Каждому процессу ядро выделяет некую виртуальную память, размером в 4Гб. При этом создаётся карта страниц отдельно для каждого процесса, потому каждый процесс может юзать свой кусок памяти. Это не занимает дополнительного времени, потому-что распределение памяти происходит внутри CPU, ОС за этим не следит, и следовательно времени не теряет. Изначально это надо было для безопасности - каждая программа получает свой кусок (куски) памяти, при этом, они могут иметь (и имеют) одни и те-же адреса. Например сама программа в WinNT начинается с адреса 0x406000 (если я не ошибаюсь). Конечно реальный адрес совсем иной, но об реальном адресе никому кроме CPU и памяти неизвестно. Ну ещё Ядро в курсе, ибо оно выделяет память и переключает процессы.

Как я уже говорил, при выделении памяти используется карта, так вот эта карта памяти 32х битная. Однако, со времён PentiumPro она стала 64х битной, правда в реальности используются лишь 36 битов. По этой причине ядро ОС может распределить до 64Мб памяти кусками максимум по 4Гб. Устаревшие ОС об этом не знают (например WinXP), а все линуксы знают конечно, только маинтейнеры не включают поддержку 64х таблиц, ибо её включение несколько замедляет запуск и переключение процессов, что критично для Linux на слабых машинах. Кроме того, 64Мб сейчас мало кому нужно. Если кому-то неймётся - ставьте семёрочку или ядро пересоберите. Пересобрать ядро может даже клинический идиот сегодня...

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

44

bobr пишет:

Physical Address Extension (PAE) — режим работы встроенного блока управления памятью x86-совместимых процессоров, в котором используются 64-битные элементы таблиц страниц (из которых для адресации используются только 36 бит)

Или это не одно и то же?

нет. это не одно и тоже. я-же вам специально рассказывал про "костыли", начиная с Z80!
Вы разве не поняли, что это один и тот-же костыль: сегментная организация памяти это развитие идеи "окна", а страничная организация - развитие сегментной модели. Просто назначение этого костыля изменилось - если раньше нужно было выйти за 16и битную шину памяти, то сейчас это нужно для стабильности и безопасности - программа просто не может выйти за свой сегмент. Хотя это и "костыль", но его отключение никак не ускорит работу - он просто не отключаем, можно разве что совместить все сегменты в один, Толку-то? CPU всё равно будет использовать свою карту, даже если она и не нужна. Поставьте MS-DOS, сравните быстродействие... Оно будет в точности такое, за вычетом времени переключения процессов.

Сейчас карты разметки памяти 64х битные, а вот указатели памяти 32х битные (в 32х битных системах). Всё это играет роль лишь при адресной арифметике, причём отрицательную роль (переход на 64х битные указатели). Когда мы обрабатываем массивы данных, мы уже используем 64 бита (MMX/SSE), а 64 бита в указателях нужны лишь для адресации массивов более 4х ГБ. Теперь расскажите, ЗАЧЕМ они вам? Вам нужны ГА что-ли?

64бита сейчас нужны лишь военным, атомные бомбы взрывать. ну а военной техники не бывает - невыгодно делать процессоры ТОЛЬКО для военных. потому задача маркетологов состоит в том, что-бы убедить вас использовать 64бита. Как они убедили вас в пользе многоядерности (ибо технологи зашли в тупик, и более не могут делать более быстрые CPU. А надо. Вот и наращивают ядра, ибо задачи военных обычно хорошо распараллеливаются. В отличие от задач гражданских. Но "два - больше чем одно"(С) реклама).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

45

кстати, сейчас (начиная с iPentiumIII) арифметика с данными уже 128и разрядная (естественно можно и 2 64х битных за раз обработать).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

46 (20.02.2011 15:08:23 отредактировано bobr)

Спасибо, drBatty. Позновательно и достаточно убедительно. Однако, могу заметить насчет многоядерности, что многие невоенные задачи также несложно распараллеливаются. Это и современные игры, и обработка видео/аудио, и, наконец, компиляция. Полагаю, в ближайшем будущем таких задач будет становится все больше, и потребности к аппаратным ресурсам будут только расти, а бесконечно наращивать частоту ЦПУ невозможно. Так что многоядерность, на мой взгляд, - лишь шаг к неминуемой незбежности.
И к вопросу о 64х битности: ведь отличия не только в размере указателей. ММХ далеко не везде используется. А целочисленная арифметика? Ведь размер int на х86 равен 32бита, а на амд64 - 64.  Ведь целые быстрее обрабатывать по 64 бита за такт, нежели по 32? Хотя, где-то я читал, что даже сейчас все пишется с оговоркой на то, что sizeof(int) равен 32 или по крайней мере, стараются не использовать целые, не помещающиеся в 32бита, для портируемости.
Но, так или иначе, очень скоро х86 процессоров не останется, хорошо это или плохо, работа маркетологов в том или инженеров.

Йа тьомный эльф

47

Я себе поставил новенький линукс RIPLinuX 11.4. Пока у меня на него жалоб нет. wink  Очень удобные возможности этой ОС - восстановление после сбоя, обслуживание систем и резервное копирование. Если кто заинтересовался - вот подробное описание дистрибутива http://www.linux4me.org/viewtopic.php?f=2&t=870

48

bobr пишет:

1)Это и современные игры,
2)и обработка видео/аудио,
3)и, наконец, компиляция.

1) во первых я тут не спец, во вторых, сейчас народ что-то в один флеш играет, в третьих, то что я видел грузит только видяху - там сюжет тупее чем в первой кваке.
2) вы не поверите - народ покупает навороченный комп с семёрочкой и плазменную панель в пол-стены. И смотрят там видео из "фконтакте". Ну в лучшем случае поганые авишки из торрентов.
3) не нужно (С)ЛОР. точнее, нужно только гентушникам. ab

bobr пишет:

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

ага. семёрочка, кде4, гном3...

bobr пишет:

ММХ далеко не везде используется.

конечно. там где не нужно много и быстро считать - не используется.

bobr пишет:

Ведь целые быстрее обрабатывать по 64 бита за такт, нежели по 32?

нет. потому-что используя SSE можно обработать за раз сразу 4 32х битных числа, или только 2 64х битных. Потому 64х битные числа ровно вдвое дольше обрабатывать. Когда переходили с 8и на 16 бит, и с 16 на 32 бита, то никакого MMX/SSE не было, и естественно, 8086 работал быстрее 8080.

Есть ещё один вопрос: ЗАЧЕМ вам обрабатывать такие большие числа? Есть-ли ПРАКТИЧЕСКИЕ примеры? Как писал Екклесиаст - чего нет, того нельзя считать. В какой практической области используются числа больше 4294967295? А значит, на практике это не нужно. Иногда нужно много мелких обработать чисел, дык для того уже много лет есть SSE. И если сейчас за секунду вы обработаете N указателей, то с приходом 64х битной архитектуры всего N/2. А как уже всем ясно, частота уже не увеличится. Многоядерность тоже не спасает, даже второе ядро увеличивает скорость не более чем в 1.5 раза, а на практике, обычно, вообще не увеличивает - память-то одна! Вот если-бы к каждому ядру засунули по 32х разрядной памяти, было-бы чудесно, а так выигрыш будет лишь при очень сложной обработке небольших массивов данных. Таких задач довольно мало, дома пригодится лишь конвертация видео в Fullhd. Тут многоядерность поможет. За то не поможет 64х битность. К чему применить 64х битность дома - вообще не представляю.

bobr пишет:

Хотя, где-то я читал, что даже сейчас все пишется с оговоркой на то, что sizeof(int) равен 32

ну в С специально никто жёстко не задал размер int'ов. Что-бы программы стали 64х битными простой перекомпиляцией. Если какой-то кодер пишет иначе - его проблемы.

bobr пишет:

Но, так или иначе, очень скоро 32 процессоров не останется

не факт.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

49

Присоединяюсь.

drBatty пишет:

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

И даже этого мало! Посмотрите на ядро процессоров Cortex. Cortex-ы пока еще не набрали силу, хотя их пророчат на роль -- постепенно вытеснить интелловское ядро. При совеих 32-х разрядах и пока не очень Гигагерцовых частотах они уже по вычислительной мощи задвигают ядро от Интелл. Ладно, я много говорю в сторону. По делу там (в кортексах) кроме всего прочего еще и архитектура шин очень грамотно реализована. Ядро общается с памятью, и если память, находясь в едином адресном пространстве, тем не менее будет иметь несколько шин доступа (допустим, по одной шине на каждый банк), то истинная параллельность доступа к памяти будет обеспечена. Остается дело за малым -- нучаться писать программы с параллельными вычислениями. Всего-то!

По поводу Кортексов -- ценность их состоит в том, что обладая 32-мя разрядами, 4-гиговым адресным пространством и (пока не очень большими частотами) они потребляют очень мало энергии. Хотите смартфон с мощностью десктопа? -- Уже реально!

drBatty пишет:

К чему применить 64х битность дома - вообще не представляю.

Пижонство же!

Live Free or Die

50

zhevak пишет:

Пижонство же!

я и написал - маркетинг...

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

51

drBatty пишет:

ЗАЧЕМ вам обрабатывать такие большие числа? Есть-ли ПРАКТИЧЕСКИЕ примеры? Как писал Екклесиаст - чего нет, того нельзя считать. В какой практической области используются числа больше 4294967295? А значит, на практике это не нужно.

Скучно бредите, Доктор!

Мат.часть поучите, потом вернёмся к разговору.

Хотя вряд ли - это ж сплошной "матан".

Начиная с примитивности электронных схем инициации ядрёного бабаха...
Хоть бы попытались уяснить, что числодробилки высокой разрядности нужны при мат.моделировании всяко-разного?
А в частности, как замена натурным испытаниям для ЯО, турбин, социальных процессов, ...

Ах да - мы ж микрометр видели, и вообще все науки превзошли. Чисто микрометр осмыслив. Шибко творчески.

Или там - аппаратные логические матрицы. Зачем они, коли Великий Недоучка сказал - НЕ НУЖНО!!!

Потому что дальше - будет ещё хуже:

- арифметизация логических схем целочисленными полиномами и её профиты:

+  - параллельность не на уровне эвристик для десятка семафоров, но регулярным предсказуемым образом
для произвольного количества параметров, которые требуется оценить для адекватной реакции системы

+  - вы мне напишете, как ваять продукционную систему (набор правил поведения)
для предметной области с неустойчивой методикой обработки входных сигналов?
(когда правила меняются очень часто, и надо их переупорядочивать при добавлении -
если на основе ТФС всё это осмыслять - это конкретная [CENSORED], и крах системы - происходит очень быстро)

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

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

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

Извините, Доктор, но над вами даже издеваться как-то не интересно.

Не забудьте протереть лурк тряпочкой smile

Давно уже не забавно наблюдать торжество отрицательного отбора.

52

Chars67 пишет:

Или там - аппаратные логические матрицы. Зачем они, коли Великий Недоучка сказал - НЕ НУЖНО!!!

ну Великий Алконавт пускай расскажет, зачем НУЖНО.

Chars67 пишет:

Извините, Доктор, но над вами даже издеваться как-то не интересно.

над вами невозможно. опять бессмысленный словесный понос.  ac

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

53

Вы на название темы таки не обратили внимание? ab

54

drBatty пишет:

64бита сейчас нужны лишь военным, атомные бомбы взрывать.

Тут даже не имху надо ставить, а ТМСБ == Таково Мнение Самодовольного Болвана.

drBatty пишет:

ну Великий Алконавт пускай расскажет, зачем НУЖНО.

Если пью, то на свои - в отличие от некоторого господина Враля.

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

А чисто предметно, помимо
числодробилок, где чем выше разрядность - тем эффективнее/быстрее работа,

та же разрядность нужна и для корректной и шустрой реализации систем в очень широком диапазоне:

от серверной логики до машинного перевода,

да собственно, любая задача, где требуется учет контекста,

и при этом вариаций контекстов - весьма богато,

и они меняются непредсказуемым образом.

Для этого и аппаратные логические матрицы потребны, и весьма нетривиальная арифметика.

Давно уже не забавно наблюдать торжество отрицательного отбора.

55

mvt пишет:

Вы на название темы таки не обратили внимание?

Да.

Проблема в том, что количество идиотов в последнее время зашкаливает уже дальше некуда -

так что отчасти - из зависти к идиотам (счастливые же люди!),

а отчасти в надежде, что у кого-то и здравый смысл включится. Не, ну а вдруг?!

Такие дела.

Давно уже не забавно наблюдать торжество отрицательного отбора.

56

Господа, господа!
Пожалуйста выбирайте выражения и не переходите дозволенных границ.

Live Free or Die

57

drBatty, по поводу разрядности.
Прежде чем вопить на весь форум о тормозах полистайте ассемблер на досуге. Может, проймёт.
Заодно узнаете, для чего в современных машинах используется шифрование внутренней адресации, 8-битовый сдвиг флагов (на что ваш "пень третий" просто не способен, как его не разгоняй) и много других интересных вещей, о коих вы [CENSORED] не знаете.

Linux Mint 19.3 Mate Edition
Windows 7

58

zhevak пишет:

Пожалуйста выбирайте выражения и не переходите дозволенных границ.

Ну так изобретайте намордник для доктора.
Пока никто с его пассажей со смеху не помер.

Мне как-то кореша-менты на Сенной показали бомжиху,
у которой реально за душой знание шести европейских языков.

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

Мне неинтересно шпынять ущербного, просто хотелось бы, что бы на ЛФ не было докторова вранья.

Больше с ним ни обо что спорить не собираюсь - думайте сами.

Давно уже не забавно наблюдать торжество отрицательного отбора.