Интервью с Алексеем Брагиным, координатором проекта ReactOS

Нужно сказать это Кренигану и Ритчи. Они пока не знают.

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

>если есть оба, то выбирается только один всё равно, и зависимость должна быть только от одного.

Молодец, ты изобрёл виртуальный пакет.

Молодец, ты наверно знаешь что виртуальность пакета точно не опредяется автоматически. Так же ты наверно понимаешь что в зависимости от выбора, ./configure может включить/отключить некоторые участки кода, делая эти пакеты "взаимонезаменяемыми"...

> не оставили все как было

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

Основа для новой ОС яблочникам какая-то нужна была. Кусок винды Билли бы просто так не отдал, с линуксом начали бы вонять красноглазые, значит оставался только BSD. А всякие BeOS, QNX и т.д. просто были и есть недостаточно развиты.

>сама прога размазывается про всяким /usr/bin/, usr/lib и т.д... нах-нах такое счастье. Когда штатно в большинстве дистров будет наподобие /soft/firefox, /soft/openoffice и т.д., позовёте.

Чтобы каждая из них тащила за собой свой собственный экземпляр библиотеки? Нах-нах такое счастье.... Запусти на более-менее упакованной софтом Винде поиск в c:\windows да в Program files по шаблону "msvc*.dll" и поразись изобилию. Там одних вижуал-сишных рантаймовых либ (msvcrt*.dll) будет 3-4 разных версии, да по нескольку штук каждой.

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

Не знаю кто как, а дебиановский apt-get уже хз сколько времени это умеет. Сносишь что-то --- говорит "а вот такие-то пакеты никому не нужны, запустите apt-get autoremove для их удаления". А до того, как apt-get это научился, существовал (да и сейчас наверно продолжает существовать) пакет deborphan, ищущий "осиротевшие" библиотеки.

Жги ещё, огнемёт ты наш!

>Левые ключи в реестре тоже, мягко говоря, некому немешают, и места занимают - этож текст, байты. А тут целые пакеты валяются.

Эти "байты" грузятся в память и постоянно путаются под ногами, когда система шарится по реестру.

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

Дядя, ты уж определись: эти "лишние" пакеты используются кем-то или нет? Если используются, то с какого хрена они вдруг "лишние"? Если не используются, то каким хреном они загрузятся в память?

>Интересные люди... Почему в unix-ах программы ставятся не так как в windows? Почему структура папок (файловой системы) другая?

Подсказка для тех, для кого сделать простейший вывод --- проблема: потому что Linux (и остальные unix-like) --- это не Windows. Сюрприз?

>Вот собственно с таким подходом лучше за Linux не садиться.

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

>И самое интересное, что (утрированно) "я не знаю и знать не хочу почему жто сделано так, а не как в винде".

См. предыдущее предложение.

>Мы здесь о Linux, а не о дистрах.

О ядре что ли? Так у него пакетов нет. И ни один линуксоид не использует ядро. Он использует дистр. И софт ставит в дистре. А раз софт ставит в дистре, то именно про дистр и ведёт речь. Логично? Или разжевать на ещё более доступном языке, чтоб понял не только каждый школьник, но и каждый выпускник детсада?

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

А теперь внимание, фокус - у тебя 200 установленых приложений. Какой длины будет твоя переменная PATH?

> а все libы добавить в LD_LIBRARY_PATH

$ rpm -qa | grep lib | grep -v devel | wc -l
220

И сколько теперь будет длина LD_LIBRARY_PATH?

> Вот какие приемущества дадут тебе пакетные мненджеры

Dependency checking on remove, блин!

ну при сотне установленных приложений/либ длинна конечно будет большой, но приемлемой. систему это не убьёт.

при >200 мои методы это конечно бесспорно ССЗБ.

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

читай дальше по тексту.

> Основа для новой ОС яблочникам какая-то нужна была. Кусок винды Билли бы просто так не отдал, с линуксом начали бы вонять красноглазые, значит оставался только BSD. А всякие BeOS, QNX и т.д. просто были и есть недостаточно развиты.

Рекомендую вам прочитать историю ;-) основа Mac OS X -- NextStep

> Например, долгое время основным способом получить под Linux безопасный доступ к NTFS-разделам с возможностью записи было использование "родного" Windows-драйвера. (Сейчас разработан полностью свободный ntfs-3g.) Чтобы запустить его под Linux, использовалась "обертка", представляющая собой ядро ReactOS, из которого убрали все лишнее и заставили компилироваться и запускаться под Linux.

O_O

Что-то его представление реальность немного отличается от http://www.ntfs-3g.org/about.html

Кто из них гонит ?

google Captive NTFS

> google Captive NTFS

ой ) да ) не проснулсо ещё =)

спасибо

> Чтобы каждая из них тащила за собой свой собственный экземпляр библиотеки? Нах-нах такое счастье.... Запусти на более-менее упакованной софтом Винде поиск в c:\windows да в Program files по шаблону "msvc*.dll" и поразись изобилию. Там одних вижуал-сишных рантаймовых либ (msvcrt*.dll) будет 3-4 разных версии, да по нескольку штук каждой.

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

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

Когда то будет штатно в убунтовском установщике-удаляторе иили в Synaptic, тогда посмотрим, а пока - неинтересно.

> основа Mac OS X -- NextStep

Всю жизнь BSD была, нет?

> google Captive NTFS

Зачем такие ужасы? В убунте вон почти из коробки ntfs-3g "пишет, читает, косит, режет и ломает". :)

Полезная штука, иногда принесут хард, просят переписать им чего-то, а там ntfs. А тут раз - и пишется всё.

>> google Captive NTFS

> Зачем такие ужасы?

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

> В убунте вон почти из коробки ntfs-3g "пишет, читает, косит, режет и ломает". :)

Captive была тогда, когда NTFS-3G еще не было в проекте.

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

> Когда то будет штатно в убунтовском установщике-удаляторе иили в Synaptic, тогда посмотрим, а пока - неинтересно.

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

> Установи aptitude(на убунту он нормально встанет)

Так он вроде и так есть... Оно консольное-убогое.

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

Предлагаю тебе пойти туда, где папки. Или прибить себя вместе с папкой.

> Оно консольное-убогое.

Это всего лишь тупое мнение анонимно-виндово-убогого.

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

попробуй в mc ввести "cd /#apt". тебе будет показан список пакетов, которые можно удалять по f8. выглядит очень похоже на то, что ты тут пропагандируешь :)

А оно там надо?

>Когда то будет штатно в убунтовском установщике-удаляторе иили в Synaptic, тогда посмотрим, а пока - неинтересно.

Да ясен пень тебе неинтересно. Тебе куда интереснее "папки" удалять и реестр чистить от всякого барахла. Но это уж каждому своё. Мне, например, совершенно неинтересно знать, где лежат программы и из каких файлов они состоят. Ну вот нафиг мне это не надо --- и всё тут! И про какие-то инсталляторы, которые надо откуда-то качать, на какие-то вопросы при установке отвечать --- тоже неинтересно.

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

>Мне, например, совершенно неинтересно знать, где лежат программы и из каких файлов они состоят.

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

А зачем мне список исполняемых файлов?

>А зачем мне список исполняемых файлов?

Немая сцена. Занавес.

Ну и хорошо. А то я уж думал, что достопочтенный господин анонимус начнёт мне рассказывать, что каждая домохозяйка знает имена файлов word.exe, acrobat.exe, notepad.exe и так далее, и только линуксовые ламеры тыпо тыцкают в пункты меню или вообще жамкают по файлам и приложения запускаются сами по себе исходя из того, какое из них ассоциировано с данным типом файла....

Анонимус пытается представить, с каким типом файлов ассоциирован mencoder, а также способ, позволяющий по имени пакета mplayer'а узнать, что вышеописанная тулза именно в нём содержится.

Достаточно знать, как называется исполняемый файл программы(если это не либа). Для этого можно даже один(!) раз запустить dpkg -L. А вообще принято, что програмы(даже консольные), записывают информацию о себе в /usr/share/menu или какое-то подобное место. Например, у меня весьма консольные links, lynx и minicom сидят в менюшке debian/applications/communication/network.

в вся виндузяческая привязанность к тому, что установленная программа - это обязательно каталог в c:\progra~1 - это лишь от неумения мыслить абстракциями, что косвенно наталкивает на мысль о скудости сознания. Но, как я уже писал выше, подобное _отображение_ списка установленных пакетов может обеспечить виртуальная фс из комплекта mc.

>А вообще принято, что програмы(даже консольные), записывают информацию о себе в /usr/share/menu или какое-то подобное место.

Просто название программы может мало что дать. ужно название в связи с пакетом. Да и потом, в /usr/bin - более тысячи файлов. Это как же раздуется меню?

>> А вообще принято, что програмы(даже консольные), записывают информацию о себе в /usr/share/menu или какое-то подобное место.

> Просто название программы может мало что дать. ужно название в связи с пакетом. Да и потом, в /usr/bin - более тысячи файлов. Это как же раздуется меню?

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

а вот не нужно знать название пакета, когда программа уже установлена. знать при запуске программы, в каком она лежит пакете. надо только админу и то при выявлении неполадок. а обычному юзеру(шапку которого я надеваю при uid!=0, знать название пакета необязательно.

>а обычному юзеру(шапку которого я надеваю при uid!=0, знать название пакета необязательно.

А если пользователь по apt-search нашёл пакет с нужными ему функциями, установил его, то как ему запускать программу при условии, что он не знает её названия, когда имя программы не совпадает с именем пакета?

>остальное - уже внутреннее.

Это "внутреннее" - большинство неинтерактивных программ + несколько интерактивных, ещё не описанных в меню - майтайнёры тоже люди, за всем уследить не могут.

> А если пользователь по apt-search нашёл пакет с нужными ему функциями, установил его, то как ему запускать программу при условии, что он не знает её названия, когда имя программы не совпадает с именем пакета?

давно пользователь имеет права устанавливать пакеты? а получить список файлов: dpkg -L $pkgname. во всяких сюнаптиках и кпацкадже тоже такое есть.

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

Ах, ну да. Домашние пользователи вызывают админов для этого. Пардон, забыл.

>а получить список файлов: dpkg -L $pkgname. во всяких сюнаптиках и кпацкадже тоже такое есть.

Вот это и есть список файлов, против знания которого выступал Mymur. Есть, правда, одна проблема - некоторые пакеты так заумно называются, что проще пройти в /var/cache/apt, чем пытаться набрать имя пакета.

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

> Ах, ну да. Домашние пользователи вызывают админов для этого. Пардон, забыл.

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

>> а получить список файлов: dpkg -L $pkgname. во всяких сюнаптиках и кпацкадже тоже такое есть.

> Вот это и есть список файлов, против знания которого выступал Mymur.

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

> Есть, правда, одна проблема - некоторые пакеты так заумно называются, что проще пройти в /var/cache/apt, чем пытаться набрать имя пакета.

меня спасает автокомплишен и поиск в bash и aptitude соответственно

>красноглазого слакоизобретателя

сам дурак.

zort, напиши мне, пожалуйста, на avova собака rbcmail dot ru

Этот пароль есть, но его знают только в Микрософте. Кстати, в Win95 можно было войти под SYSTEM, подменив winlogon.scr

Кстати, вы знаете, что пользователь System с одной вындовой машины может заходить на другие вындовые машины без пароля?

>В бубунте ставлю синаптиком прогу, она просит зависимости, ставит >их. Поигрались, снесли, зависимости остались. Можно прибить через >тот же синаптик, да, но для этого надо ещё надо вспомнить как они >назывались. Поэтому и хочется хотя бы одна прога - одна папка, чтобы >в mc по F8 прибить 1 папку и больше не возиться ни с чем.

Так в PC-BSD.