О как. А все закапывать кидались.
Впрочем, Xen актуален только на серверах.

добавлена поддержка систем с CPU более 255

О! Годно! Теперь можно и обновиться.

Вы сказали так, как будто это минус

> добавлена поддержка систем с CPU более 255 и страниц 1Gb/2Mb;

Переведите, пожалуйста, это предложение, на какой-нибудь язык.

>для загрузки по PXE теперь используется iPXE вместо gPXE;

iPXE is a superset of gPXE: any feature present in gPXE is also present in iPXE.

Что там такого-то, что стоило форкать, а тут ещё и менять на это?

> с CPU более 255

интересно, почему не 256? нумерация с единицы?

как раз накатил только опенсюзю с 4.0.2... ))

удачи

Нумерация с нуля, по-этому 255. Ъ считают с нуля.

Xen до сих пор пишется на OCaml?

неужели оно работает ?

К.О. подсказывает, что с 0 до 255 количество целых чисел 256

нужно

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

нах-нах

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

И это стабильный релиз...

Known issues in Xen 4.1

PVGRUB (based on MiniOS) seems broken for 32bit PV domUs, but works OK for 64bit PV domUs. This is a regression, since PVGRUB works in Xen 4.0.x for both 32b and 64b.

List of missing features from xl/libxl in Xen 4.1.0:

PVUSB PVSCSI

Кстати, кто-нибудь знает? У них stub domain работает нормально, или глючит, как в 4.0/4.0.1. И remus - работает ли?

> К.О. подсказывает, что с 0 до 255 количество целых чисел 256

Передайте КО, что часто одно из значений резервируют под недействительное или признак ошибки или другие аналогичные цели. Именно поэтому, например, getchar()/getc()/fgetc() возвращают int а не char.

Именно поэтому, например, getchar()/getc()/fgetc() возвращают int а не char.

Достаточно было сделать

bool getchar(char* out) {
   // bla-bla-bla 
   if(...) {
      *out = some_char;
      return true;
   }
   return false;
}

Во-первых, тогда bool в C не было. :)

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

> Во-первых, тогда bool в C не было. :)

И, вообще, в С этот тип называется _Bool

> Во-первых, тогда bool в C не было. :)

Не важно, есть int ;)

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

Соглашусь с вами.

>> Во-первых, тогда bool в C не было. :)

Не важно, есть int ;)

А если уж все равно использовать int для возврата true/false, то тогда уж лучше туда сразу возвращаемый символ запихнуть.

> Именно поэтому, например, getchar()/getc()/fgetc() возвращают int а не char

Вот она - отсталость C во всей красе, где понятие char и byte до сих пор синонимы.
Не говоря уже про дебильные имена функций.

>> Именно поэтому, например, getchar()/getc()/fgetc() возвращают int а не char.

Вот она - отсталость C во всей красе, где понятие char и byte до сих пор синонимы.

А что именно вас не устраивает? Используйте wchar_t, если хочется.

> Не говоря уже про дебильные имена функций.

Это вы о creat(2)? ;)

Или вы считаете, что fgetc(3), например, должен называццо так: ThisFunctionReturnsACharacterWhichItReadsFromStream()?

> А если уж все равно использовать int для возврата true/false, то тогда уж лучше туда сразу возвращаемый символ запихнуть.

Безусловно ;)

> Или вы считаете, что fgetc(3), например, должен называццо так: ThisFunctionReturnsACharacterWhichItReadsFromStream()?

Только не это. Имя функции должно быть осмысленной, но не стоит перебарщивать.

>> Или вы считаете, что fgetc(3), например, должен называццо так: ThisFunctionReturnsACharacterWhichItReadsFromStream()?

Только не это. Имя функции должно быть осмысленной, но не стоит перебарщивать.

Это я как бы и не вам отвечал, а d9d9. И, вообще, это называется сарказм. :)

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

И, да, на мой взгляд, fgetc – вполне осмысленное имя. Особенно в контексте остальных имен в stdio, более-менее укладывающихся в общий паттерн.

> А что именно вас не устраивает? Используйте wchar_t, если хочется.

Ну вопрос не в том что мне хочется, а в том что всякие «char *» на самом деле должны быть «byte *». А wchar_t должен быть просто char. char != byte. ASCII это просто частный случай. Да и не предназначен wchar_t для работы с тем же UTF-8. Без юникода щас никуда. А отсутствие четких стандартов даже в таких простых вещах ведёт к тотальному велосипедизму да и просто - не совместимости между либами. Вместо того чтобы брать и работать, людям приходится преодолевать ограничения, навязанные устаревшими конструкциями.

вы считаете, что fgetc(3), например, должен называццо так: ThisFunctionReturnsACharacterWhichItReadsFromStream()?

Зачем, Stream::Read(f) вполне достаточно.

>> А что именно вас не устраивает? Используйте wchar_t, если хочется.

Ну вопрос не в том что мне хочется, а в том что всякие «char *» на самом деле должны быть «byte *». А wchar_t должен быть просто char. char != byte.

Вам стоит осознать, что «the map is not the territory»©. Важны смыслы реальных сущностей, а выбор имен для них всегда произволен. Тем, кто смешивает обозначитель и обозначаемое, и чувствуют дискомфорт от необходимости привыкнуть к тому, что в одном контексте некий термин может иметь смысл отличный от того, к которому они привыкли в другом контексте, вообще не надо лезть в IT, IMHO.

ASCII это просто частный случай. Да и не предназначен wchar_t для работы с тем же UTF-8.

Естественно. UTF-8 это просто поток байтов.

Без юникода щас никуда.

Так вы определитесь, вы о юникоде, или о utf-8? Юникод – это просто чарсет, таблица соответсвий между символами и числами, их кодирующими. И wchar_t именно для юникода и предназначен.

А utf-8 – это *транспортный формат* для представления юникодных символов в виде потока байтов.

И нормальные люди для работы с юникодом используют именно UCS и wchar_t. utf-8 – это формат для передачи или хранения, он неоптимален (и не предназначен изначально) для обработки.

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

Это все претензии к конкретным библиотекам, и к квалификации их дизайнеров.

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

Лично я никаких ограничений не вижу. Может приведете конкретные примеры?

вы считаете, что fgetc(3), например, должен называццо так: ThisFunctionReturnsACharacterWhichItReadsFromStream()?

Зачем, Stream::Read(f) вполне достаточно.

Для человека, обладающего минимальными способностями к символическому мышлению выбор между fgetc и Stream::Read – это вопрос чисто эстетических предпочтений, принципиально субъективных. А всем остальным добро пожаловать в дворники.

У меня ровно два вопроса по сабжу.

1. Есть какой дистрибутив, где настроен Xen изкоробки? чтобы поставил дистрибутив, загрузил и можно виртуалочки гонять сразу.

2. Говорили о том, что можно выделять гостевому домену вторую видеокарту. Нужен ли для этого второй монитор?

И, да, я может быть недостаточно ясно выразил один важный момент. Ваша принципиальная ошибка вот где:

char != byte

Это неверно. В большинстве языков есть символьный тип(*), онтологически отдельный от других типов. В C такого типа нет, там char – это не символ, это именно что однобайтное целое, и, например, '*' – это просто одно из представлений числа 42 (если мы не о EBCDIC, естественно), как и 052 или 0x2a.

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

—

(*) Символьный в смысле character, а не в смысле, например, лисповых symbols.

> Тем, кто смешивает обозначитель и обозначаемое

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

И wchar_t именно для юникода и предназначен.

Да вы что? RTFM. В винде wchar_t вообще 16 бит. Переносимость великолепная xD.

Так вы определитесь, вы о юникоде, или о utf-8?

А utf-8 – это *транспортный формат*

Это транспортный формат ДЛЯ Юникода. Они не разделимы. Я лишь говорю что char != byte. Нет никакой необходимости смешивать эти понятия. А ввод/вывод разных кодировок в std не продуман.

Это все претензии к конкретным библиотекам, и к квалификации их дизайнеров.

Нет. Это всё претензии к разработчикам языка и std. Элементарные вещи должны быть доступны и продуманы из каробки. Не вышло продумать с 1й попытки? Ну выпустите v2. А не морозьтесь 20ть лет.

Для человека, обладающего минимальными способностями к символическому мышлению

Вам шашечки или ехать? Важно донести информацию максимально понятно. То что Stream::Read однозначно читабельнее fgetc и так ясно. Даже человек не знающий особенностей std* поймет о чем речь, а символическое мышление стоит оставить на решение реальных задач. Не верите - проведите соц.опрос.

А всем остальным добро пожаловать в дворники.

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

> И, да, я может быть недостаточно ясно выразил один важный момент

Не стоит выражать банальные вещи. Они и так понятны. Не тратьте время на буквоедство, оно лишь раздражает.

Тем, кто смешивает обозначитель и обозначаемое

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

При чем тут типизация? Это фундаментальный философский принцип.

И, да, мне нравится динамическая типизация. Но я предпочитаю не пых-пых, а перл и лисп. А C – это такой структурированный ассемблер для низкоуровневых задач, и там он незаменим.

И wchar_t именно для юникода и предназначен.

Да вы что? RTFM. В винде wchar_t вообще 16 бит. Переносимость великолепная xD.

Да мне в общем пофегу, если винда не следует стандарту, это проблемы MS. (К тому же, до сравнительно недавнего времени юникод таки был 16битным). А вот вам и RTFM:

The types are
[...]
wchar_t
which is an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales; the null character shall have the code value zero. Each member of the basic character set shall have a code value equal to its value when used as the lone character in an integer character constant if an implementation does not define __STDC_MB_MIGHT_NEQ_WC__.

ISO/IEC 9899:1999 TC3 пункт 7.17.2.

Так вы определитесь, вы о юникоде, или о utf-8? А utf-8 – это *транспортный формат*

Это транспортный формат ДЛЯ Юникода.

Понятно, что не для EBCDIC.

Они не разделимы.

Они вполне разделимы. Можно использовать юникод исключительно в UCS (и, кстати, венда именно так и делает), без каких-либо UTF. И для обработки внутри приложения ucs удобнее и эффективнее, utf-8 – это костыль, придуманный Томпсоном (или Ритчи? не помню точно) для совмещения юникода и байт-ориентированной семантики имен файлов в юниксе.

Я лишь говорю что char != byte.

В си именно char ≡ byte.

Нет никакой необходимости смешивать эти понятия.

В контексте си эти понятия слиты изначально Ритчи. Я уже говорил, что в си вообще нет символьного типа, только целые. И char – это просто целочисленный тип длинной один байт.

А ввод/вывод разных кодировок в std не продуман.

Да вы что? А как же mbtowc(3) и компания? RTFM пункт 7.20.7 стандарта. А в Single Unix к тому же еще и iconv есть.

Это все претензии к конкретным библиотекам, и к квалификации их дизайнеров.

Нет. Это всё претензии к разработчикам языка и std. Элементарные вещи должны быть доступны и продуманы из каробки.

Спасибо, не надо. «If you want PL/I, you know where to find it.» © Ritchie. Язык и стандартная библиотека должны определять минимум абсолютно необходимого и независящего от преходящей моды, типа конкретных кодировок символов.

Для человека, обладающего минимальными способностями к символическому мышлению

Вам шашечки или ехать? Важно донести информацию максимально понятно.

А что непонятного в fgetc?

То что Stream::Read однозначно читабельнее fgetc и так ясно.

«Отучаемся говорить за всех» ™. Опытным сишным программистам например, fgetc читабельнее, точно так же, как foo++ читабельнее, чем foo+=1, которое, в свою очередь, читабельнее, чем foo=foo+1. И, да,

void (*sa_sigaction)(int, siginfo_t *, void *);

Даже человек не знающий особенностей std* поймет о чем речь, а символическое мышление стоит оставить на решение реальных задач. Не верите - проведите соц.опрос.

Демократия – не самый лучший способ установления истины. Особенно учитывая известный тезис про 95% :)

А всем остальным добро пожаловать в дворники.

Когда заканчиваются аргументы - начинаются оскорбления?

Это не оскорбление, а всего лишь утверждение очевидного факта, что в IT (как и в любом другом виде деятельности/профессии/etc) есть определенные необходимые врожденные способности и приобретенные навыки.

Я не жалуюсь на свою судьбу, а лишь константирую очевидный факт. «С» никак не развивается и не улучшается.

Этот «очевидный факт» очевиден далеко не всем, почему-то.

Так что скорее наоборот - дворники пилят проекты на «С», т.к. никем кроме опенсорса не востребованы ибо результат пыхтения низко продуктивен, малочитабелен и полон велосипедов.

Толсто.

> 1. Есть какой дистрибутив, где настроен Xen изкоробки? чтобы поставил дистрибутив, загрузил и можно виртуалочки гонять сразу.

Шапка 5я, в бесплатных редакциях. Что в самой шапке - не знаю.

Debian 5 и 6 тоже почти подходят под условие, пара движений apt-get и можно.

2. Говорили о том, что можно выделять гостевому домену вторую видеокарту. Нужен ли для этого второй монитор?

Нет, зачем? Но нужна поддержка процессором VT-d или iommu. Ещё желателен именно четвёртый XEN (в Debian 5 и Centos 5 - третий).

>нужна поддержка процессором VT-d или iommu

Зачем? я же не основную видеокарту в гостевой домен пробрасываю.

void (*sa_sigaction)(int, siginfo_t *, void *);

Или например

void (*signal(int, void (*)(int)))(int)

http://xgu.ru/wiki/%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%...

> Ещё желателен именно четвёртый XEN (в Debian 5 и Centos 5 - третий).

Сетевуха замечательно пробрасывалась в гостя еще в Debian etch (4.x). Вряд ли видюха существенно отличается. Правда в дебиановской вике писали, что на pvops-based ядрах для DomU в дебе проброс девайсов в гостя не работает (по крайней мере в Debian 5), если я правильно помню.

cobol

Stream::Read(f) вполне достаточно.

достаточно для кого? для того, для кого английский родной или как родной?
а не скатываетесь ли Вы в клуб старых пердунов - любителей кобола?
там тоже всё [было] «понятно и достаточно» и «семантически завязано на английский язык».
Хорошо, что Керниган со товарищи решили сделать по-людски.
меня даже creat не смущает...;)

> Хорошо, что Керниган со товарищи решили сделать по-людски.

s/Керниган/Ритчи/

Язык C проектировал/разрабатывал Ритчи, а Керниган ему помогал книжку писать. Что не умаляет его других заслуг, естественно, типа awk.