Fedora Linux присоединился (http://www.raspberrypi.org/archives/805) к числу дистрибутивов (Debian и Arch Linux), сборки которых подготовлены для проекта Raspberry Pi, в рамках которого на базе SoC Broadcom BCM2835 700 МГц (ARM11 ARM1176JZF-S) создан одноплатный компьютер ценой 25 долларов. Сборка сформирована (http://www.raspberrypi.org/downloads) на базе пакетной базы Fedora 14 (последний релиз для ARMv5tel, Fedora 15 ограничился альфа-версией, а порт Fedora 16 так и не был выпущен), развиваемой Fedora ARM (http://fedoraproject.org/wiki/Architectures/ARM), базируется на ядре Linux 3.1.9 и дополнена некоторыми проприетарными драйверами, не входящими в состав Fedora Linux и позволяющими задействовать средства акселерации GPU (VideoCore). По заявлению разработчиков проекта, представленной сборке Fedora присвоен статус официально рекомендованного базового дистрибутива для повседневного использования на Raspberry Pi.
В качестве графического окружения можно использовать (http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedor...) LXDE и Xfce. В базовую сборку включено более 640 пакетов, среди которых AbiWord, Gnumeric, Gimp, Firefox, python, perl, ruby, bash, различные мультимедийные приложения. Из репозитория доступны для установки около 16 тысяч пакетов, собранных проектом Fedora ARM. Загрузка осуществляется с SD-карты. Версия на базе Fedora 17 будет выпущена (http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedor...) как только будет обеспечена работа графического окружения (пока сборка Fedora 17 работает только в консольном режиме). Более того, начиная с Fedora 18 планируется рассматривать ARM как первичную платформу, поддержка сборки пакетов для которой будет производиться с тем же приоритетом, что и для x86 и x86_64.URL: http://www.raspberrypi.org/archives/805
Новость: http://www.opennet.me/opennews/art.shtml?num=33319
Мде, могу себе представить как на этой мелочи работает yum например и какое "удовольствие" им там пользоваться.
yum - лишь удобная прослойка между пользователем и сишными либами типа rpm и sqlite.
Единственная проблема - писано на питоне. Поэтому при инсталле разлапистых пакетов на виртуалках с 128-256 RAM оно вызывает OOM только в путь. Ну и на этой фиговине будет, если гигазы свопа не подключить.
Хоть на баше, всеравно больщую часть времени исполняется сишный код.
Имеется ноутбук с п3 256 рам - полет нормальный.
> Имеется ноутбук с п3 256 рам - полет нормальный.Ну если там еще гиг свопа прицепить... тогда оно конечно как-то ползать будет, да. Натужно свопясь при установке разлапистых пакетов, особенно если там что-то еще было запущено.
не сгущайте краски. до свопа дело не дойдет.
юм конечно не подарок по производительности, но на 256 метрах работает без проблем.
> Мде, могу себе представить как на этой мелочи работает yum например и
> какое "удовольствие" им там пользоваться.Меня другое интересует - федора при установке требует 768 метров оперативы, как они выкручивались?
Какая установка? Там же образ.
> Меня другое интересует - федора при установке требует 768 метров оперативы, как
> они выкручивались?Это актуально лишь для Ф16, особенность установщика anaconda такая. В других версиях этого требования нет и в Ф17 обещают уменьшить.
К тому же там, видимо, установщик вообще не задействуется.
> Это актуально лишь для Ф16, особенность установщика anaconda такая.И yum. И вообще всего что на питоне накорябано.
>> Это актуально лишь для Ф16, особенность установщика anaconda такая.
> И yum. И вообще всего что на питоне накорябано.вообще-то, python - прекрасный, быстрый язык. там, где надо быстро - куски пишут на cython или же цепляют сишный код.
очень странная логика винить язык программирования в плохо написанной программе.
опять же, у авторов yum могли быть причины написать именно так(например, ради плагинов, которых нет больше ни в одном пакетном менеджере).
> вообще-то, python - прекрасный, быстрый язык.Несомненно, черепаха очень быстро бегает. Если ее сравнивать с улитками.
Hint: понятия о прекрасном бывают разные.> куски пишут на cython или же цепляют сишный код.
Господ с синдромом гусенка просьба не беспокоиться. Мы оцениваем то что есть на практике в реальных инкарнациях, а не как вы бы там чисто теоретически изгибались бы чтобы подставить костыли вашему любимому уродству. Я конечно понимаю что "свое - не пахнет", однако нюхайте это сами, плиз.
> (например, ради плагинов, которых нет больше ни в одном пакетном менеджере).
Какое мне дело до ваших долбаных плагинов если оно мне систему в OOM валит? Улучшайзеры это круто, но только не когда это ведет к MISSION FAILED, при том порой с довольно катастрофическими последствиями.
to sasha>Меня другое интересует - федора при установке требует 768 метров оперативы, как они >выкручивались?
Вранье!
Fedora требует 768 для установки в ГРАФИЧЕСКОМ режиме!
А что не так, по-вашему, с yum?
Вот делаю сейчас time sudo yum update -y на машине необновляющейся где-то пару недель.Install 4 Packages
Upgrade 62 Packages
Remove 2 PackagesTotal download size: 165 M
Основное время - скачка по двухмегабитному каналу.
Complete!
real 7m22.153s
user 3m21.063s
sys 0m25.169sОбъясните же, я не понимаю наездов на yum %)
> Объясните же, я не понимаю наездов на yum %)На раз ловит OOM на машинах с 128-256 памяти. И да, а что, по вашему вообще нормально что пакетный манагер сожрал 3 _минуты_ процессорного времени? Основное время?! Как я вижу по этому выводу, оно половину времени из 7 минут проц жрало как свинья помои. Это вообще нормально что работа пакетного манагера занимает столько же сколько скачка пакетов по 2 мбит каналу?! Ну тогда надо было диалап сразу уж брать - на фоне получаса скачки никто и не заметит 3 минут тупления пакетного манагера.
Иногда лучше эээ думать, чем говорить.rpm следит за целостностью файлов и подсчитывает контрольные суммы у каждого установленного файла, а так же выполняет много других операций. Благодаря этому, можно в любой момент отследить целостность любого пакета или всей системы, причем без каких-либо инструментов со стороны - иногда очень помогает в случае непонятных проблем. Так же он выполняет все операции, связанные с проверкой контрольных сумм самих скаченных пакетов, проверяет их подписи и так далее. Плюс синхронные транзакции, чтобы уметь продолжить операцию в любой момент после прерывания.
Все эти алгоритмы потребляют проц. А вы что хотели? Вдобавок, все скрипты, запускаемые rpm (обновились либы - запускаем ldconfig, и так далее) тоже дописали свое время к тому, что показано в выводе yum.В общем, не надо грязи - проц потребляет не yum "просто потому, что питон", а всякая криптография, следя за целостностью системы, базами данных rpm и yum и другие остро важные задачи.
Только почему-то арчевский пакман при той же проверке целостности так не тупит.
Потому что арчевский пакман по сравнению с редхатовским рпм - поделка, которая не умеет и десятой доли того, что может рпм.
> Потому что арчевский пакман по сравнению с редхатовским рпм - поделка, которая
> не умеет и десятой доли того, что может рпм.Вы с предыдущим комментатором точно сравниваете одинаковые программы? RPM - это низкоуровневый пакетный менеджер, а yum/apt-get/zypper - высокоуровневые. Вроде бы претензии именно к yum, который высокоуровневый.
Да, но замеряя вывод time для yum, так же суммируется все время, проведенное в вызовах rpm-libs и все время, проведенное в скриптах пакетов.
> yum, который высокоуровневый.Именно. Сам rpm не настолько прожорлив, но вы же не будете ставить какойнить там пыхпых через rpm, правда? А yum при попытке что-то подобное сделать на такой машине с заметной вероятностью просто положит ее нафигЪ, особенно если вы не дай боже своп на гиг отрастить забыли :)
> Потому что арчевский пакман по сравнению с редхатовским рпм - поделка,Но довольно резвая и не прожорливая, в отличие от вашего энтерпрайзного крапа на питоне, заметим.
> Все эти алгоритмы потребляют проц. А вы что хотели?Чтобы оно работало как минимум не хуже apt-get ;)
> а всякая криптография,
Криптографии не надо сотен мегабайтов. Не на что их там жрать. И тот же apt-get почему-то жрет в разы меньше оперативы, хотя обеспечивает проверку подписей и хэшей файлов в системе ничуть не хуже. А сотни мегазов на разлапистых пакетах лопает именно сам уродец yum, именно питоновская часть.
Вообще, вы прямо эпиграф к своему выступлению написали - "Иногда лучше эээ думать, чем говорить". Потому что я по итогам вашего выступления готов поспорить что вы еще и полный ноль в криптографии до кучи. Зато нести фигню с умным видом про сотни мегазов скушанных криптографией это не мешает.
Ну например, он еще считал и собирал из кусков deltarpm (57 пакетов из 65) заметное время. Не так уж и впустую потрачено время. Короче, надо сравнивать с deb на одних и тех же задачах. Но меня всегда в deb убивало, что надо использовать и apt-get и aptitude и dpkg для манипуляций. Слишком разнородно для меня. yum человечней. Если вы используете deb, не могли бы тоже продемонстрировать время time apt-get update -y ?
> Короче, надо сравнивать с deb на одних и тех же задачах.А при чём тут deb? Apt-get прекрасно работает и поверх rpm. Я никогда не мерял, но поскольку использовал yum и apt-get на похожих машинах, у меня сложилось мнение, что apt-get быстрее.
По крайней мере, там update и upgrade/install/remove разнесены. То есть, по-умолчанию он не перескачивает/проверяет репозитарии (я знаю, что в yum и zypper можно тоже какими-то ключами так сделать). Это несколько ускоряет работу.
> у меня сложилось мнение, что apt-get быстрее.Логично, блин. Перетормозить эту питоновскую тормозилку еще суметь надо. Но на raspberry pi будет намного приятнее поймать OOM или как минимум жестко положить систему в своп при установке разлапистых пакетов. Как бы 128...256 метров десктопной системе и так то еле-еле, а с кучей шита на питоне - там будет полный питонец. Нет, конечно кому-то и слайдшоу в системе - типа работа.
А вы так не делайте(ТМ)
ставьте туда уже SD c полностью сконфигурированной системой, а конфигурите там, где это удобно. когда я баловался и грузил свой ееепс freebsd с сд карты, мне в голову не приходило строить мир на нем же :)
> когда я баловался и грузил свой ееепс freebsdУ вас получается неполноценная железка с недосистемой. А мы хотим _компьютер_. Мы не против побаловаться, но результат должен быть серьезным и юзабельным. У этой штуки ресурсов больше чем у моего писюка 10-летней давности, с хрена ли она должна быть недо? Только потому что какие-то раздолбаи напихали тормозного скриптошита которому сколько ни дай - мало?
а он по нынешним меркам и есть недо. SoC с маломощным ЦПУ, менее 200М ОЗУ и крайне ограниченными возможностями I/O. Хотите с ней поковыряться - сразу это учитывайте. и учитывайте, что нормальной self-hosted среды разработки на ней вы без серьезного драчевого напильника не получите. тем более не следует думать, что современный мейнстримовский ИБэМэ ПэЦэ ориентированный дистрибутив со всеми своими пекидж- и прочими шит-китами сможет на ней заработать. на этой фитюльке и слакварь-то, говорят, еле еле без графики взлетает.Так что только кастомное ядро, только хардкор. с другой стороны - прекрасный повод поетись с железкой джастфофан :) но я не думаю, что следует трахаться с медленным и муторным self-hosted конфигурированием системы, если это можно сделать быстрее и удобнее в кросс-платформенной среде.
> а он по нынешним меркам и есть недо. SoC с маломощным ЦПУ,
> менее 200М ОЗУ и крайне ограниченными возможностями I/O.Ну да, конечно, 16-ядерный гроб с 128 гиг оперативы - лучше. Правда занимает дофига места, дико воет вентилями, жжет энергию как сверхновая и вообще нафиг не сдался домяшнему хомяку.
> Хотите с ней поковыряться - сразу это учитывайте.
Учту и не буду ставить туда фрибсд, поставив более подходящую систему. Способную ПОЛНОЦЕННО работать. Даже на телефоны с ведроидом можно доустанавливать программы а не куковать с фиксированным hardcoded набором программ. А тут даже яву пользовать не обязательно а железо примерно такое же.
> и учитывайте, что нормальной self-hosted среды разработки на ней вы без
> серьезного драчевого напильника не получите.Не вижу чем ARM принципиально отличается от х86 чтобы быть или не быть self-hosting. Единственный повод этого не делать - да, х86 с кучей ядер и дофига оперативы может компилировать быстрее. Правда вот это волнует только разработчиков и майнтайнеров. И если переть на принцип - так раньше на таких по мощности компьютерах и даже дохлее самохостились и не плевались вроде :)
> тем более не следует думать, что современный мейнстримовский ИБэМэ ПэЦэ ориентированный дистрибутив
> со всеми своими пекидж- и прочими шит-китами сможет на ней заработать.Как видим, в принципе - сможет. Там нет ничего такого предотвращающего это на фундаментальном уровне. Ну да, придется пересобрать пакеты под устаревшую архитектуру. Кому надо - пересоберут.
> на этой фитюльке и слакварь-то, говорят, еле еле без графики взлетает.
Без понятия насчет слаквари, а как минимум дебианообразным без графики такого проца с 256 метрами - чуть более чем дофига, если всякий жирный шит типа bind/apache не тянуть и ограничиться более скромными и менее монструозными программами.
> Так что только кастомное ядро, только хардкор.
Да нет никакого хардкора, если кернел майнтайнеры/разработчики уже собрали. Его даже пересобирать просто, когда все галочки в менюконфиге уже расставлены правильно за вас.
> с другой стороны - прекрасный повод поетись с железкой джастфофан :) но я не думаю, что
> следует трахаться с медленным и муторным self-hosted конфигурированием системы, если это
> можно сделать быстрее и удобнее в кросс-платформенной среде.Именно, поэтому на такой железке логично делать просто apt-get install WhatYouWant. И все. То что пакеты были собраны кросскомпилом на х86, если некоему конкретному майнтайнеру так удобнее и быстрее - всем как-то пофигЪ.
Нифига не понял, при чем тут отсылки к 16ядерному серваку и FreeBSD, ну да ладно.я совершенно не возражаю, хотите пользоваться сборкой на базе федоры - пожалуйста. но мне казалось, что предыдущий аноним как раз жаловался на жручесть федориной системы управления пакетами и на ООМ? тут уж что-то одно, или аноним лопает, что дают девелоперы, или девелопит сам.
далее, забудьте, какие 256 метров, о чом вы? там шаред память, минимум 32 метра отдать под графику и не грешить (и удачи поработать с GPU с таким объемом), а если хочется 3d какого-нито или видео, то и все 128М. посмотрите на дебиановские требования к системе для интереса.
не спорю, на этой системе можно построить и self-hosted разработку и конфигурирование. вопрос только в затратах времени на. то, что они для распберри будут больше, к бабке не ходи - медленный стораж, медленный или отсутствующий эзернет, медленное цпу. но если вы хотите, скажем так, собравшись на каток, одеть коньки еще дома и щемиться в них всю дорогу по асфальту, зачем мне вас отговаривать?
> Нифига не понял, при чем тут отсылки к 16ядерному серваку и FreeBSD, ну да ладно.Объясняю: ничему не противоречит вполне полноценное использование бинарного линевого дистра на такой штуке в режиме а-ля десктоп. Вопрос надо или не надо компилировать на такой штуке софт - вообще головная боль сугубо разработчиков. А у пользователей такая проблема просто не должна возникать совсем. Если ориентироваться на реальное использование этого всего в реальном мире потом, а не только пострадать немного фигней и забить. То что у конкретно взятой федоры тормознутый и ресурсожоркий манагер пакетов который в этот сценарий вписывается не более чем топор в задачу спасения утпающего - не доказывает что mission impossible.
А то что из такой штуки первичный компьютер разработчика или там билдсервер весьма так себе - вроде бы никто и не сомневался. Правда вот у компьютеров есть еще миллион применений, где этого ARM вполне хватит.
> или аноним лопает, что дают девелоперы, или девелопит сам.
Есть еще третий вариант - допинать девелоперов до состояния когда они перестанут страдать фигней и сделают что-то пригодное к использованию. Чаще всего даже получается, если девелоперы не совсем укурки и понимают что так конкуренты обойдут на повороте.
> далее, забудьте, какие 256 метров, о чом вы? там шаред память, минимум
> 32 метра отдать под графику и не грешитьЭто в каких-то официальных спеках прописано? Или с потолка взято? Нельзя ли пруф?
> (и удачи поработать с GPU с таким объемом),
А чего вы там собрались делать с GPU? Неужто в игры всерьез играть? Там от него основная фича - аппаратное декодирование видео, что делает данную железку пригодной для чего-то типа медиа-центра мизерного размера.
> а если хочется 3d какого-нито или видео, то и все 128М.
Ну да, а давайте лучше все 256 отдадим? Будем без программ, зато с 3D :)
> посмотрите на дебиановские требования к системе для интереса.
Не вижу в каком месте там что-то сказано про память GPU. И да, у меня дебиан прекрасно работает на виртуалке с 128 мег, из коих половина еще и свободна (без GUI разумеется). Ну да, минимальная такая системка. Но технически это полноценный дебиан с возможностью поставить любой из 20 000 пакетов. То что не все из этих 20 000 имеет смысл ставить - вопрос номер два.
> не спорю, на этой системе можно построить и self-hosted разработку и конфигурирование.
> вопрос только в затратах времени на. то, что они для распберри
> будут больше, к бабке не ходи - медленный стораж, медленный или
> отсутствующий эзернет, медленное цпу.Все правильно, без серьезной нужды использовать такую штуку как первичный комп разработчика или билдсервер - достаточно странно. Хотя если жизнь заставит - можно. Но смысл этого действа неочевиден. Наверное издержки bsd-style стиля мышления, когда пониже спины постоянно зудит самолично скомпилить файрфокс и опенофис даже если вы и не вносили туда никаких изменений.
> но если вы хотите, скажем так, собравшись на каток, одеть коньки еще дома
> и щемиться в них всю дорогу по асфальту, зачем мне вас отговаривать?По асфальту - это наверное про потуги использовать что-то bsd-like на таких штуках? Хорошая аналогия, надо будет запомнить.
>Это в каких-то официальных спеках прописано? Или с потолка взято? Нельзя ли пруф?эээ я правильно понимаю, что вы каментите новость, даже не сходив для приличия на сайт производителя и не посмотрев, о какой железке идет речь и из чего она состоит?
м-да. "Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма."
извините, я как-то не готов продолжать беседу :)
> На раз ловит OOM на машинах с 128-256 памяти.Кстати, apt-get ещё 7 лет назад прекрасно работал с Debian Stable на 486-й машине с 8-ю метрами памяти, а с 4-мя уходил в swap. Может быть сейчас оно как-то и ухудшилось, конечно.
> Может быть сейчас оно как-то и ухудшилось, конечно.LZMA может быть несколько более прожорлив к памяти но для декомпрессии надо только памяти по размеру словаря. Обычно размер словаря несколько Мб (более крупные размеры требуют чуть более чем дофига памяти при сжатии).
И не стоит забывать про http://people.freedesktop.org/~hughsient/zif/
Может появится в 18ой версии.
yum install zif-tools PackageKit-zifЕсть в 16-ой, 17-ой и даже в 15-ой и 14-ой, только старые.
http://koji.fedoraproject.org/koji/packageinfo?packageID=10991
> Может появится в 18ой версии.Ну вот когда и если появится, тогда и поговорим. А покуда федористы проталкивают свой крап хоть он и откровенно не подходит под задачу. Это нафига? Чтобы потом в нас виндузятники тыкали и рассказывали как оно тормозит и падает? Ну спасибо, блин.
Всегда знал, что Fedora 14 заруливает все последующие версии. Жалко своего потраченного времени на борьбу с gnome 3 :( Боженька, ну вразуми наконец уже гномерских разработчиков!
Похоже платформа x86 заканчивает свою жизнь на десктопах....
> Похоже платформа x86 заканчивает свою жизнь на десктопах....Массово так, возьмёт сразу завтра и вымрет, угу. Этот мамонт живее всех живых, пока для него существует всякий легаси вроде виндов.
Лол! Арм еще по производительности п4 не догнал. Какой там "заканчивает".
внезапно чтобы крутить сессию OnLive, не нужна даже производительность P4
Облака?
Нет, спасибо. Мне еще дороги личные данные.
> Лол! Арм еще по производительности п4 не догнал.GPU у этого арма заткнет на тяжелых операциях этот самый пень4 куда подальше, например там аппаратный декодинг FullHD есть. Пенек4 подавится тот же поток fullhd программно задекодировать, т.к. тот еще тормоз (тупиковая ветвь эволюции ака netburst). Вообще, все идет к тому что в будущем будет CPU + пачка SIMD-сопроцессоров (которые вы нынче знаете как GPU) для тяжелых операций и оценить вот так влобешник производительность старья vs это будет очень непростой задачей.
У п4 может быть такой же GPU. Да и вообще, 90% времени нагрузка падает на CPU, а видео крутить и в игрушки играть - это для любителей.
> У п4 может быть такой же GPU....но достоинство P4 это ВНЕЗАПНО не является :). Он вообще удивительно бестолковый проц, крайне тормозной для своего энергопотребления. Если например набирать ARMами такое же потребление питалова - у вас получится огроменный server farm который например можно сдавать в аренду заместо VDS'ок, как раз по параметрам как младжие тарифы, только не надо делить хост с толпой малопредсказуемых дятлов которые могут его пригрузить :)
> Да и вообще, 90% времени нагрузка падает на CPU,
В основном потому что стандартизированных методов работы с GPGPU до недавних пор тупо не было. С появлением OpenCL есть надежда что эта ситуация исправится.
> а видео крутить и в игрушки играть - это для любителей.
...поэтому появилось такое направление как GPGPU.
Спасибо друх, завтра же приобретаю вагон армов и начинаю кодить x264 10bit на них.
>gimp, firefox
>256MB
>>gimp, firefox
>>256MBgimp вроде не так много жрёт, хотя может это я ошибаюсь (до сих пор использую 2.4). Насчёт FF согласен - не жилец.
> gimp вроде не так много жрёт, хотя может это я ошибаюсьДовольно прилично если в полном виде со всеми плагинами. Плюс как бы еще и для обработки самой картинки надо памяти. А вы посчитайте сколько весит в разжатом виде весит ну хоть фото с 5...8 мпикс камеры. И подумайте что эти хренадцать мегов точно должны висеть в памяти + еще undo на все это и так далее. Конечно если вы собрались иконки 16х16 рисовать - сие как бы не проблема. А вот отредактировать фотку, даже с современного мобильника - так там чисто массив пикселей картинки более 10 мегз запросто может весить.
последнее предложение новости радует
Вообще, други, это классно, что сейчас появилось множество таких АРМоподелок, на которые разработчики всё-таки как-то ориентируются. Иначе бы требования десктопных программ возросли до каких-то диких гигабайт ОЗУ.Хочу отметить, что Х Window System + WindowMaker + TeX великолепно работали в своё время на Pentium 120 + 64 Mb памяти. И этой памяти было завались.
иначе бы? :)))
кдешники прямо предупреждают, что к их поделию без двух гиг минимум лучше и не подходить.>Х Window System + WindowMaker + TeX великолепно работали в своё время на Pentium 120 + 64 Mb памяти. И этой памяти было завались.
соглашаться. я, вообще должен заметить, что у некоторых разработчиков некоторых чиста пабочных программ наподобие DE возникают странные иллюзии, что я покупаю память в комп именно для их творений, а не для того, чтоб поиграть в ждалкер, например, или запустить в виртуалбоксе пару лишних VM.
запущать федору на этой игрушечке - это, конечно, пустая трата времени, как и гонять там gimp (omfg) с фаерфоксом. хотя не сомневаюсь, что найдутся сторонники этого мозохизма в 256М, равно и утверждающие, что свапиться на SD card легко и приятно. дебиановская сборка и то интереснее выглядит.
> иначе бы? :)))
> кдешники прямо предупреждают, что к их поделию без двух гиг минимум лучше
> и не подходить.Ну у меня как-то запускается и на 512-ти. Но я всё-таки переехал на WMaker. Ещё бы там были просмотрщик pdf подходящий и многозакладочный терминал.
> запущать федору на этой игрушечке - это, конечно, пустая трата времени, как
> и гонять там gimp (omfg) с фаерфоксом. хотя не сомневаюсь, что
> найдутся сторонники этого мозохизма в 256М, равно и утверждающие, что свапиться
> на SD card легко и приятно. дебиановская сборка и то интереснее
> выглядит.Debian, конечно, много интереснее.
>кдешники прямо предупреждают, что к их поделию без двух гиг минимум лучше и не подходитьИспользуй 3.5 как я
>соглашаться. я, вообще должен заметить, что у некоторых разработчиков некоторых чиста пабочных программ наподобие DE возникают странные иллюзии
поделись, как часто они стоят над тобой и заставляют использовать их код, я собираю статистику для психиатров
>а не для того, чтоб поиграть в ждалкер, например
А, игры отрицают линуховые ДЕ, интересный бред, учитывая что сталкер под вайном работает не на полную.
>как и гонять там gimp (omfg) с фаерфоксом. хотя не сомневаюсь, что найдутся сторонники этого мозохизма в 256М, равно и утверждающие, что свапиться на SD card легко и приятно.
Епт, открой для себя android например или дистрибутивы заточенные под слабое железо - откроешь много нового, я гарантирую это!
Ту часть, где вы разговариваете с голосами в вашей голове, я, с вашего позволения, скипну.>>как и гонять там gimp (omfg) с фаерфоксом. хотя не сомневаюсь, что найдутся сторонники этого мозохизма в 256М, равно и утверждающие, что свапиться на SD card легко и приятно.
> Епт, открой для себя android например или дистрибутивы заточенные под слабое железо
> - откроешь много нового, я гарантирую это!А вот тут не удержусь. Это какой андроид? Тот, который на гелакси табе с 512 метров памяти и на гигагерцовом ядре жрет батарею, как кот печенку, и тормозит так, что самсунгу срочно пришлось делать новую модель с гигом озу и на двухядерной тигре? Не, не слышал.
> новую модель с гигом озу и на двухядерной тигре? Не, не слышал.А о чем вы слышали? О *bsd которых на смартах нет совсем? О убогой и напрочь огороженной мобильной винде? О iOS которая подчиняется кому угодно кроме собственно обладателя аппарата и норовит постоянно подгадить или выцыганить еще бабла?
>> новую модель с гигом озу и на двухядерной тигре? Не, не слышал.
> А о чем вы слышали? О *bsd которых на смартах нет совсем?
> О убогой и напрочь огороженной мобильной винде? О iOS которая подчиняется
> кому угодно кроме собственно обладателя аппарата и норовит постоянно подгадить или
> выцыганить еще бабла?Еще больше ненависти, зайчик мой, еще. Твои возгласы несомненно поднимут продажи гелакси таб, а то в 2011 их даже HP со своим тачпадом обогнать умудрился.
Бедный самсунг, как у них все печально.. Новые модели они на старом железе они видишь-ли выпускать не хотят.
> Вообще, други, это классно, что сейчас появилось множество таких АРМоподелок, на которые
> разработчики всё-таки как-то ориентируются."It is what computers became".
Не понятно почему федора а не убута? Сколько людей пользуется федорой, а сколько убунтой?
> Не понятно почему федора а не убута? Сколько людей пользуется федорой, а
> сколько убунтой?Сколько людей пользуются arm, а сколько x86?
Сколько людей пользуются linux, а сколько windows?
и так далее.
Вы вообще к чему спрашиваете?
> Сколько людей пользуются arm, а сколько x86?ARM'ов на этой планете больше: в каждой мобилке и каждой второй мелкой железке - ARM :).Так что если вы думаете что не пользуетесь ARM, вы скорее всего просто обладаете наблюдательностью и интеллектом обычного носорога.
> Сколько людей пользуются linux, а сколько windows?
Linux'ом пользуется чуть более чем дофига. Если рассматривать его в том понятии которое изначально заложено (т.е. только ядро), 30% рынка мобил с ведроидом - уже в каком-то роде тянет на "пользуются Linux". А что, не пользуются? Или ядро - не Linux? А еще у каждого второго хомяка найдется роутер или точка доступа чтобы эти планшетики и телефончики в сеть выпускать, где без пингвина не обошлось. Вумный телеящик качающий торенты тоже понятно чего использует. Ну и так далее.
> и так далее.
Death comes silently...
> сколько убунтой?Ну дык. В убунте нет Дреппера и это - фича :)
http://people.freedesktop.org/~hughsient/zif/
> http://people.freedesktop.org/~hughsient/zif/Круто, когда будет в федоре по дефолту вместо ее тормозилки, тогда и поговорим. А то если смотреть на то что есть где-то сбоку, есть zypper и libzypper или как там ее правильно, в meego еще использовалось, потому что как вы понимаете, там никто не ушибался настолько чтобы юзвергам таких железок тормознутый yum втюхивать - ну не будет юзер мобилы терпеть свопеж полчаса.