АКТУАЛЬНЫЕ ТЕМЫ:
|
|
|
|
|
Автор
|
Тема: Выбираем Linux нах и ниипёт ! (Просмотрено 27037 раз)
|
|
|
nastyusha2
|
а как теперь выпилить эти кеды, через терминал не идет - пишет что и так ничего не установлено
|
|
Можно выпилить пакет, содержащий kdelibs, от него зависят кеды и все его компоненты.
|
|
ок, а он ничего там не потянет лишнего?
|
|
Нет, только приложения, использующие kdelibs.
|
|
вроде нормально выпилилось, но менеджер обновлений намекает опять все установить, вообщем ошибка: остались пакеты с неразрешенными зависимостями
|
|
|
|
Sa1raX
|
После того, как я начал по-немногу осваивать Убунту на работе я решил поставить её у себя дома, ибо Винда врай заебала со своими синими экранами смерти. пытался на винде слить во единое 2 раздела жёсткого диска. с акронисом дружу, с партишином дружу, но во время процесса слияния выскакивала ошибка в файловой системе. короче слил сгорем по полам. но после этого стал появляться синий экран с типичной ошибкой 0х00000008 тобиш траблы в оперативной памяти. после 7-часово теста в memtest стало ясно, что оперативка цела и это очередной глюк оси, который должен лечиться переустановкой, искать глубже проблему у меня уже не было сил. я поставил Убунту 11.10. всё работает. НО я добрался до своей папки с музыкой и каково было моё удивление, когда вместо одной компзиции играла совершенно другая, с другой папки! тоже самое с видео! включаешь один мувик, название файла правильно, длительность, а при проигрывании играет совершенно другое. хз что это...может из-за некорректного слияния разделов в винде такая фигня случилась? или что-то в убунту не то?
|
|
|
|
Ахтунгшвайнэ
|
Народ, посоветуйте лучший дистрибутив для фирмы.
Чтобы по удобнее и лучше был...
Федора шляпа какая-то...
|
|
|
|
|
ch.a.sh
|
Где работает Линус Торвальдс: ходячее рабочее место, 3d принтер и много жестких дисков
Линус Торвальдс показал The Linux Foundation своё рабочее место, на котором немало интересного. Например, он в буквальном смысле пошёл дальше модных в последнее время «стоячих» столов для работы и установил около своего беговую дорожку в медленном режиме — так, что у него место оказалось рабочее.
В видео ещё можно увидеть его 3d принтер, услышать о том, что ему тоже бывает лень избавляться от старых жёстких дисков и другое:
http://habrahabr.ru/post/230403/
|
|
|
|
rekcuFniarВ
|
хспди причём тут конфиги служб? а говорю про скрипты run демонов в init.d |
|
а что это ты вдруг съехал на скрипты init.d, если мы говорили именно про конфиги служб, а именно про upstart vs. systemd и про то что systemd говно в частности? Init.d это legacy, он был когда тебя ещё не было и оно в нормальных дистрах, уже перешедших на systemd обычно присутствует чтобы не ломать обратную совместимость.
например, поместить в ~15 строк сервиса ~150 строк init-скрипта
|
|
Ты так говоришь, будто это твоё ненужноd избавляет от необходимости писать скрипты Если есть необходимость перед запуском демона производить какие нибудь предварительные действия, проверки и прочее, скрипты писать придётся всё равно, а бывает необходимость в pre-start, post-start, pre-stop, post-stop скриптах.
https://help.ubuntu.com/community/UpstartHowto слово parallel сам найдёшь, я надеюсь
К слову, init.d скрипты тоже умеют запускаться параллельно.
откуд upstart возьмёт локал-сокеты для служб? может она ещё и сериализацию поддерживает? |
|
не нужно. Это не задача систем инициализации.
upstart запускает сразу и серверные и клиентские приложения |
|
Что ты несёшь? Какая разница что запускать?
|
|
|
|
trigger woods
|
больше нравится systemd в дистрах убунты 15.10 и центоси 7, чем апстарт - гораздо проще автомитизировать,
а вот под апстарт нужно всегда велосипед на bash'е городить
а вообще лучше бы поставили везде runit для хардкора ;D, а туториалов сейчас нет подробных для него
|
|
|
|
Kariy_Z?lupkin
|
лаймерский оспект!
Есть ли современный линукс с более менее адекватной тач функцией
так чтоб встал на железо 2012 года
|
|
|
|
Lex
|
хспди причём тут конфиги служб? а говорю про скрипты run демонов в init.d |
|
а что это ты вдруг съехал на скрипты init.d, если мы говорили именно про конфиги служб, а именно про upstart vs. systemd и про то что systemd говно в частности? Init.d это legacy, он был когда тебя ещё не было и оно в нормальных дистрах, уже перешедших на systemd обычно присутствует чтобы не ломать обратную совместимость.
|
|
Где я конкретно говорил про конфиги?
Я не съехал на скрипты, а продолжаю тред - ибо init.d нет в systemd, но есть другое, которое я пытался описать. И я не уходил от темы, в то время как ты несколько уводил тему куда-то не туда.
Ещё раз:
Думаю не стоит объяснять да что в /etc/init.d или там /etc/rc.d/init.d/ располагаются скрипты инициализации систем SysV или Upstart и то что эти скрипты пишутся на bash и управляют демонами системы? Мы же вроде как общаемся про Upstart vs systemd? Тогда я тебе и пишу в защиту systemd о том что что в ней эти скрипты заменены юнитами, которые удобней конфигурировать, чем скрипты. Где я съехал?
Объясни, пожалуйста, доступно, без цитат - Почему systemd говно в частности? Я вот не считаю upstart говном.
Ты не привёл ни одного существенного довода. Ведь эта система уже опережает upstart, и не просто так, об этом можно очень много прочитать. Мне достаточно прочитать описание разработчика и мнение комьюнити. Провести небольшие тесты, например на томже nginx или mysql, на основе заявлений и признать факт. Зачем разводить бред?
например, поместить в ~15 строк сервиса ~150 строк init-скриптаТы так говоришь, будто это твоё ненужноd избавляет от необходимости писать скрипты Если есть необходимость перед запуском демона производить какие нибудь предварительные действия, проверки и прочее, скрипты писать придётся всё равно, а бывает необходимость в pre-start, post-start, pre-stop, post-stop скриптах. |
|
|
|
Снова уходишь от темы. Попробуй преобразовать любой init-скрипт в сервис файл, И ты без проблем сможешь использовать этот сервис на любой другой системе с ОЧЕНЬНУЖНОd. А потом попробуй перенести init-срипт на другою платформу, той же архитектуры.
докажиhttps://help.ubuntu.com/community/UpstartHowto слово parallel сам найдёшь, я надеюсь |
|
|
|
и это твоё доказательство?
где там объясняется то, что ты опровергал тут?
"Some init.d scripts...". И то сетевые.
откуд upstart возьмёт локал-сокеты для служб? может она ещё и сериализацию поддерживает? не нужно. Это не задача систем инициализации.
|
|
|
|
это был сарказм
upstart запускает сразу и серверные и клиентские приложения |
|
Что ты несёшь? Какая разница что запускать? |
|
Всмысле какая разница? WTF?
Выбор схемы активации для служб приложения это большая разница
- в системных службах важна параллелизация - нужно чтобы сокеты создались на старте, и чтобы единственная служба принимала все поступающие запросы. и важно, чтобы они пускались параллельно! d-bus и syslog, пожалуйста.
- в единичных службах: когда сокеты создаются также при загрузки, и нужно чтобы единственная служба запускалась только при получении входящих запросов,чтобы сэкономить ресурсы и уменьшаем время загрузки - вот в чём разница, и когда мне служба понадобится я тогда и активирую её. cups тебе в пример
- для служб, активирующих свой сокет на каждое соединение, т.е. есть активация при каждом входящем соединении, запускаеют отдельный свой экземпляр, (слушающий сокет при этом остается у сервера, inetd или systemd). в пример ssh.
И важно - любой вид перезапуска службы - не приводит к недоступности сокета.
ты вообще обслуживал серверные приложения?
|
|
|
|
trigger woods
|
а когда Лекс переквалифицировался в линуксойда, ты ж вроде, если не ошибаюсь, барыжил недвижкой
|
|
|
|
rekcuFniarВ
|
Где я конкретно говорил про конфиги? |
|
А то что вы называете «юнитами» у ненужноd, это что по твоему? Это конфигурационные файлы в формате, похожем на ini.
Съехал и не только на скрипты, а вообще. Я хз причём тут говноd вообще, я всего лишь написал что рачлинукс говно, а ты начал "ОЛОЛО ПЫЩЬ ПЫЩЬ SYSTEMD АЗАЗА!!!11"
То что в твоём прыщедистре чего-то нет, это не показатель. В серьёзных дистрах, таких как Debian, поддержку init.d не собираются выпиливать. Это только в детских дистрах вроде рачлинукса школьникам мейнтейнерам пофиг и они могут ломать совместимость в любой момент.
Думаю не стоит объяснять да что в /etc/init.d или там /etc/rc.d/init.d/ располагаются скрипты инициализации |
|
И что?
или Upstart и то что эти скрипты пишутся на bash |
|
Во-первых, конфиги upstart располагаются в /etc/init (/etc/init.d при этом существует параллельно как legacy, в серьёзных системах обратную совместимость ломать не принято), во-вторых, они не являются скриптами, пример такого конфига я приводил выше. О разнице между upstart, sysvinit (init.d) и systemd можешь почитать здесь, например. Там хорошо разложено по полочкам.
Почему systemd говно в частности? |
|
В частности потому что Леннарт Поттеринг мудак. Во-вторых, он упорот и пихает в свою поделку что попало. В третьих, агрессивная политика Red Hat, на который он работает, по пропихиванию systemd везде. Ради этого они сливают кодовую базу других проектов с systemd, таких как udev и прочего, вынуждая этим другие дистры переходить на это говно, потому что выковыривать эти важные функции из systemd чтобы они работали без него как и раньше, им надоело. Да они даже вроде Gnome сделали зависимым от systemd, упоролись совсем Зачем это делается? А всё очень просто, Red Hat хочет быть монополистом, иметь больше контроля над системой. Ради Systemd они много чего привычного переломали, даже FHS.
Ведь эта система уже опережает upstart |
|
В количестве ненужных свистоперделок. Эта толстая вундервафля однажды лопнет.
Мне достаточно прочитать описание разработчика и мнение комьюнити. |
|
В основном состоящее из Леннарта Поттеринга и фанбоев, ага
Снова уходишь от темы. Попробуй преобразовать любой init-скрипт в сервис файл, И ты без проблем сможешь использовать этот сервис на любой другой системе с ОЧЕНЬНУЖНОd. А потом попробуй перенести init-срипт на другою платформу, той же архитектуры. |
|
Внезапно, скрипт работает везде без перевода, на то он и скрипт. Баш есть везде (на самом деле обычно используется dash, а не bash, но не важно, они совместимы).
де там объясняется то, что ты опровергал тут? |
|
А что я опровергал тут?
это был сарказм |
|
Не ври.
Всмысле какая разница? WTF?
Выбор схемы активации для служб приложения это большая разница |
|
Хуйню несёшь. Выбор «схемы активации» (условия запуска) лежит на разработчике, на практике, этим занимаются мейнтейнеры дистра (пишут init.d скрипт или конфиг для upstart или «юнит» для говноd). А уж чем является запускаемый процесс, системе инициализации пофиг, что прописано в конфиге, то и запускается, в соответствии с прописанными там условиями.
- в системных службах важна параллелизация - нужно чтобы сокеты создались на старте, и чтобы единственная служба принимала все поступающие запросы. и важно, чтобы они пускались параллельно! d-bus и syslog, пожалуйста.
- в единичных службах: когда сокеты создаются также при загрузки, и нужно чтобы единственная служба запускалась только при получении входящих запросов,чтобы сэкономить ресурсы и уменьшаем время загрузки - вот в чём разница, и когда мне служба понадобится я тогда и активирую её. cups тебе в пример
- для служб, активирующих свой сокет на каждое соединение, т.е. есть активация при каждом входящем соединении, запускаеют отдельный свой экземпляр, (слушающий сокет при этом остается у сервера, inetd или systemd). в пример ssh.
И важно - любой вид перезапуска службы - не приводит к недоступности сокета. |
|
Тут уже какая-то упоротая феерия пошла в стиле DX.
"Some init.d scripts...". |
|
Что тебе непонятного в слове some? Естественно нельзя абсолютно всё запускать параллельно, некоторые службы зависят от других и должны ожидать их запуска или других событий, например поднятия сетевого интерфейса. Как и в говноd, собственно.
Не ври, нет там про то что якобы только сетевые. Там на примере сети описывается зачем нужна возможность параллельного запуска (ожидание поднятия сети какой либо службой не тормозит запуск остальных служб). С английским совсем у тебя плохо, как же ты мануалы читаешь?
И нахуй это нужно? Допустим, сервер БД упал, а сокет открыт на запись и приложение, использующее БД думает что всё нормально и продолжает в него передавать запросы. А ответа нет В результате приложение (например сайт) подвисает и пользователь ожидает ответа Лучше бы сокет при этом был недоступен как обычно, чтобы приложение могло обработать исключение, а не ждать ответа. А на серьёзных проектах это ещё и бесполезно, там сервер не один и используется балансировщик, так что удержание сокета системй иницаилизации там нахрен не усралось Опердень для локалхоста, короче.
|
|
|
|
Lex
|
Где я конкретно говорил про конфиги? |
|
А то что вы называете «юнитами» у ненужноd, это что по твоему? Это конфигурационные файлы в формате, похожем на ini.
Съехал и не только на скрипты, а вообще. Я хз причём тут говноd вообще, я всего лишь написал что рачлинукс говно, а ты начал "ОЛОЛО ПЫЩЬ ПЫЩЬ SYSTEMD АЗАЗА!!!11"
То что в твоём прыщедистре чего-то нет, это не показатель. В серьёзных дистрах, таких как Debian, поддержку init.d не собираются выпиливать. Это только в детских дистрах вроде рачлинукса школьникам мейнтейнерам пофиг и они могут ломать совместимость в любой момент.
Думаю не стоит объяснять да что в /etc/init.d или там /etc/rc.d/init.d/ располагаются скрипты инициализации |
|
И что?
или Upstart и то что эти скрипты пишутся на bash |
|
Во-первых, конфиги upstart располагаются в /etc/init (/etc/init.d при этом существует параллельно как legacy, в серьёзных системах обратную совместимость ломать не принято), во-вторых, они не являются скриптами, пример такого конфига я приводил выше. О разнице между upstart, sysvinit (init.d) и systemd можешь почитать здесь, например. Там хорошо разложено по полочкам.
Почему systemd говно в частности? |
|
В частности потому что Леннарт Поттеринг мудак. Во-вторых, он упорот и пихает в свою поделку что попало. В третьих, агрессивная политика Red Hat, на который он работает, по пропихиванию systemd везде. Ради этого они сливают кодовую базу других проектов с systemd, таких как udev и прочего, вынуждая этим другие дистры переходить на это говно, потому что выковыривать эти важные функции из systemd чтобы они работали без него как и раньше, им надоело. Да они даже вроде Gnome сделали зависимым от systemd, упоролись совсем Зачем это делается? А всё очень просто, Red Hat хочет быть монополистом, иметь больше контроля над системой. Ради Systemd они много чего привычного переломали, даже FHS.
Ведь эта система уже опережает upstart |
|
В количестве ненужных свистоперделок. Эта толстая вундервафля однажды лопнет.
Мне достаточно прочитать описание разработчика и мнение комьюнити. |
|
В основном состоящее из Леннарта Поттеринга и фанбоев, ага
Снова уходишь от темы. Попробуй преобразовать любой init-скрипт в сервис файл, И ты без проблем сможешь использовать этот сервис на любой другой системе с ОЧЕНЬНУЖНОd. А потом попробуй перенести init-срипт на другою платформу, той же архитектуры. |
|
Внезапно, скрипт работает везде без перевода, на то он и скрипт. Баш есть везде (на самом деле обычно используется dash, а не bash, но не важно, они совместимы).
де там объясняется то, что ты опровергал тут? |
|
А что я опровергал тут?
это был сарказм |
|
Не ври.
Всмысле какая разница? WTF?
Выбор схемы активации для служб приложения это большая разница |
|
Хуйню несёшь. Выбор «схемы активации» (условия запуска) лежит на разработчике, на практике, этим занимаются мейнтейнеры дистра (пишут init.d скрипт или конфиг для upstart или «юнит» для говноd). А уж чем является запускаемый процесс, системе инициализации пофиг, что прописано в конфиге, то и запускается, в соответствии с прописанными там условиями.
- в системных службах важна параллелизация - нужно чтобы сокеты создались на старте, и чтобы единственная служба принимала все поступающие запросы. и важно, чтобы они пускались параллельно! d-bus и syslog, пожалуйста.
- в единичных службах: когда сокеты создаются также при загрузки, и нужно чтобы единственная служба запускалась только при получении входящих запросов,чтобы сэкономить ресурсы и уменьшаем время загрузки - вот в чём разница, и когда мне служба понадобится я тогда и активирую её. cups тебе в пример
- для служб, активирующих свой сокет на каждое соединение, т.е. есть активация при каждом входящем соединении, запускаеют отдельный свой экземпляр, (слушающий сокет при этом остается у сервера, inetd или systemd). в пример ssh.
И важно - любой вид перезапуска службы - не приводит к недоступности сокета. |
|
Тут уже какая-то упоротая феерия пошла в стиле DX.
"Some init.d scripts...". |
|
Что тебе непонятного в слове some? Естественно нельзя абсолютно всё запускать параллельно, некоторые службы зависят от других и должны ожидать их запуска или других событий, например поднятия сетевого интерфейса. Как и в говноd, собственно.
Не ври, нет там про то что якобы только сетевые. Там на примере сети описывается зачем нужна возможность параллельного запуска (ожидание поднятия сети какой либо службой не тормозит запуск остальных служб). С английским совсем у тебя плохо, как же ты мануалы читаешь?
И нахуй это нужно? Допустим, сервер БД упал, а сокет открыт на запись и приложение, использующее БД думает что всё нормально и продолжает в него передавать запросы. А ответа нет В результате приложение (например сайт) подвисает и пользователь ожидает ответа Лучше бы сокет при этом был недоступен как обычно, чтобы приложение могло обработать исключение, а не ждать ответа. А на серьёзных проектах это ещё и бесполезно, там сервер не один и используется балансировщик, так что удержание сокета системй иницаилизации там нахрен не усралось Опердень для локалхоста, короче.
|
|
кароче, заебал
если щас начну отвечать, тема улетит во флэйм, ибо у меня остался только мат
скажу одно везде есть плюсы и минусы, и иногда важно что и для чего использовать оптимальней.
|
|
|
|
Lucky_Ganesh
|
Почему бы всем разработчикам всех этих разных дистрибутивов не объедениться и не сделать реально конкурентноспособную ОС? Прям маразм какой-то - каждый пилит свой 25-ый вариант убунту. Сделайте наконец реального конкурента винде и маку.
|
|
|
|
rekcuFniarВ
|
Почему бы всем разработчикам всех этих разных дистрибутивов не объедениться и не сделать реально конкурентноспособную ОС? Прям маразм какой-то - каждый пилит свой 25-ый вариант убунту. Сделайте наконец реального конкурента винде и маку.
|
|
Вряд ли это возможно, линукс изначально был создан как конструктор, потому что изначально пилился энтузиастами хакерами для себя. Поэтому и пилят каждый для себя свой под свои нужды, даже после того как подключились и корпорации. Немцы пилят SuSe, американцы Red Hat, русские свои велосипеды специфичные... У Гугла тоже есть своя сборка для внутренних нужд (в паблике нет, известно только что на базе убунты). И ещё куча всяких узкоспециализированных сборок под конкретные задачи и устройства. Так что продолжать пилить будут всегда.
Что касается конкурентоспособности, чтобы создать такую систему, пригодную для современных хомячков (то есть со всеми присущими недостатками венды или макоси), разработчик должен в это вложить немало средств. Ну вон космонавт это и попытался сделать, продал свою компанию и начал пилить Убунту. Но до идеала там всё равно далеко. Интерфейс сильно упростили, так чтобы неайтишники могли пользоваться, но косяков всё равно полно. Вообще основные проблемы линуксов это поддержка железа. Дрова не все производители официально выпускают, поэтому для некоторых их нет, для некоторых пилят опять же энтузиасты путём реверс инжиниринга (поэтому некоторые дрова бывают глючные). Проблемы с железом чаще на ноутах возникают. Ну и софт. Кому-то нужен профессиональный коммерческий софт, многого под линуксы не выпускают.
Так что без поддержки сторонних разработчиков ПО и железа ни о какой конкурентоспособности не может быть речи.
Ну а другим корпорациям развитие десктопного линукса не очень интересно. Так-то вклад в линукс много кто вносит, там и IBM, и Intel, Google и даже Microsoft некоторый вклад делает. Но у них интерес в другой сфере (серверы, embedded и тому подобное). Вкладывать в десктоп им особого смысла нет, всё равно тенденция такая что постепенно всё перенесётся в облака, SAAS и всё такое.
|
|
|
|
|
Kariy_Z?lupkin
|
Компания RealEase из Гонконга разработала Интернет планшет на базе Linux. RealEase занимается разработкой портативной компьютерной техники для сторонних заказчиков. Новый интернет планшет на базе Linux получил название Shogo. Новинка претендует на версию бизнес класса и ориентирована в основном на применение в сфере бизнеса. Подробных характеристик о интернет планшете Shogo пока нет. Известно только, что он оснащен 10-дюймовым сенсорным дисплеем, выполненным на основе емкостной технологии, и одним из процессоров Freescale: i.MX37 (ARM11) или i.MX51 (ARM Cortex A8). Также новинка содержит веб-камеру, сетевой интерфейс Ethernet, один внешний порт USB и два внутренних порта USB (для возможности подключения 3G модема или другого дополнительного оборудования), сенсор движения и сенсор освещенности окружающего пространства. Программная оболочка основана на ядре Linux 2.6.28. Все базовые приложения и файловая система могут обновляться через интернет. При этом заявлена поддержка HTML5, JavaScript, QT 4.6.2, Adobe Flash 10, баз данных SQLite. Еще один плюс так это то, что платформа Shogo полностью открыта для OEM сборщиков оборудования и сторонних разработчиков. В качестве дополнительных инструментов разработчикам доступны также Perl и C/C++. За счет открытости платформы можно создавать любые специализированные приложения под конкретные задачи применения. Интернет планшет Shogo может найти свое применение в сфере медицины, в гостиничном бизнесе, во время перелетов в самолетах и в других сферах бизнеса. Когда появится устройство на рынке пока не известно.
|
|
|
|
trigger woods
|
сейчас сижу с xcfe - доволен, поскольку предпочитаю оболочки без излишнего свисто-перделия, но и без фанатизма (пока не собираюсь отдавать душу бесмысленным экспериментами всяких генту, хуярч), и это единственная оболочка которая нормально запустилась с харда на моем уже старом ноуте (удивительно, но простоубунта 15.04 с его гномом запукается с LiveUSB, а поставленая после запуска - нет)
"собери все окна на рабочем столе, типа я кранслоглазый-гик-линкусойд"
хотя есть такая фигня, например: я хочу сделать так, чтобы ноут шарил ethernet по wi-fi (Access point) - мне приходится ставить гномовский NetworkManager чтобы это сделать (скорее всего можно просто конфиг-файл ручками переделать, но что-то времени на это нет) стандартный же аналог от Xubuntu - слишком примитивный для этого, следоватально установщик пакетов скачал дофига мегабайт зависимостей.
Кстати, на windows 7 я решил проблему c wi-fi гораздо быстрее - написал BAT-файл в одну строчку и поставил его в автозагрузку
|
|
|
|
Показать последних комментариев к сообщениям в теме
|
|