The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Началась разработка пакетного менеджера DNF 5 и замены Packa..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Началась разработка пакетного менеджера DNF 5 и замены Packa..."  +/
Сообщение от opennews (??), 06-Мрт-20, 13:39 
Дэниел Мах (Daniel Mach) из компании Red Hat сообщил о начале разработки пакетного менеджера DNF 5, в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++. Тестирование DNF 5 планируется начать в июне в процессе разработки Fedora 33, после чего в октябре 2020 года добавить в репозиторий Rawhide, а в феврале 2021 года заменить им DNF  4. Сопровождение ветки  DNF  4 будет продолжено Red Hat...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52494

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 06-Мрт-20, 13:39   +46 +/
Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его уже закапывают и пишут новое. Прям как в вёбе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4, #38

2. Сообщение от Аноним (2), 06-Мрт-20, 13:55   +3 +/
Так те же люди пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #73, #87

3. Сообщение от DerRoteBaron (ok), 06-Мрт-20, 13:59   +1 +/
Подход, конечно, своеобразный, но yum/dnf+rpm самая адекватная связка для бинарного дистрибутива, а а с dnf еще и не особо тормозящая, так что от переписывания на плюсы есть шансы, что хуже не станет
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #12, #30

4. Сообщение от Аноним (-), 06-Мрт-20, 14:00   –2 +/
> Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его
> уже закапывают и пишут новое.

Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика
> Благодаря packagekit, гномовские/кдешные/whatever инструменты работы с софтом (установка, обновление) одинаково работают на всех мейнстримовых дистрах.

а тут вон оказывается что то ли его уже много лет никто не развивает, то ли у шапки дистры маргинальные :-S

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #9, #21, #52, #72

5. Сообщение от анонимус (??), 06-Мрт-20, 14:05   –11 +/
> C++

Странный выбор.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #16, #96

6. Сообщение от Джонни Дырявый (?), 06-Мрт-20, 14:17   –3 +/
DNF будет такой же тормозной как в Федоре?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #43, #53

7. Сообщение от Аноним (7), 06-Мрт-20, 14:18   +10 +/
> перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++

Судьба-судьбинушка всех проектов, написанных на пихоне.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #23

8. Сообщение от DerRoteBaron (ok), 06-Мрт-20, 14:19   –15 +/
У них половина кода уже на C++, видимо, разгонять или переучивать команду на более адекватный нативный язык, а потом еще и весь код переписывать, слишком невыгодно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #13

9. Сообщение от Аноним (9), 06-Мрт-20, 14:25   +/
>> уже закапывают и пишут новое.
>Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика

Летели 2 кирпича, один красный, а другой - налево...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #101

10. Сообщение от leap42 (ok), 06-Мрт-20, 14:46   +2 +/
> yum/dnf+rpm самая адекватная связка для бинарного дистрибутива

это ещё почему? zypper пользовались? (лучшие части dnf как раз из него взяты)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #33, #56

11. Сообщение от leap42 (ok), 06-Мрт-20, 14:48   –3 +/
> Судьба-судьбинушка всех проектов, написанных на пихоне
> ... всех проектов ...
> ... всех ...

ну как всех, 0,05% от всех может быть...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #15

12. Сообщение от Аноним (12), 06-Мрт-20, 14:49   +5 +/
Чем это лучше pacman?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #20

13. Сообщение от Аноним (12), 06-Мрт-20, 14:50   +4 +/
> переучивать команду на более адекватный нативный язык

Это на какой? Хруст, может?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18

15. Сообщение от A.Stahl (ok), 06-Мрт-20, 14:57   +10 +/
Ок, всех полезных проектов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #27

16. Сообщение от заминированный тапок (ok), 06-Мрт-20, 15:01   +1 +/
ну там же нет любителей смузи, пока ещё
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #35

17. Сообщение от Fracta1L (ok), 06-Мрт-20, 15:02   +/
Нет, всё-таки это нифига не нормально, когда делают А, через 5 лет А выкидывают и пилят В, чтобы ещё через 3 года выкинуть В в пользу С.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #97

18. Сообщение от заминированный тапок (ok), 06-Мрт-20, 15:06   +3 +/
да уж сразу на JS :-D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #22

19. Сообщение от vz_2 (?), 06-Мрт-20, 15:11   –1 +/
Работать на ведро вполне нормально для opensource.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

20. Сообщение от А (??), 06-Мрт-20, 15:17   +/
Чем это лучше guix?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #24, #49

21. Сообщение от Аноним (21), 06-Мрт-20, 15:22   +4 +/
PackageKit - это один из инфраструктурных проектов редхата. Он не для пользователей. Он для того чтобы предоставить и стандартизировать API. Каким раньше был их же hal, ConsoleKit и другие вещи вроде PAM.

Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем система инициализации и собственный пакетный менеджер и то не все. Причина банальна - ресурсов нет. Вместо разработки инфраструктурных решений для ОС разработчики в основном пакуют пакеты и обслуживают совместимость и надёжность программного обеспечения. Спасибо им за это, безусловно, это важно, но не хватает единых API. Чем больше стандартизации тем меньше манипуляций нужно совершить с апстримным тарболом для поставки его в дистрибутив. НО! Чем больше стандартизации, тем меньше разнообразия (diversity если хотите) и тем больше дистрибутивы становятся похожи друг на друга. Особенно те из них которые предоставляют systemd как единственную опцию. Если из того же арча выкинуть пакман и всунуть рпм, то с некоторыми манипуляциями его можно будет уже анакондой ставить как и все редхатовские продукты. Это не хорошо и не плохо. Просто факт.

Ну вот настала очередь PackageKit, который перепишут как сервис dbus. И вот тут меня терзают смутные сомнения... Если вы писали что-то под dbus... эту штуку надо переделывать. Может не протокол, но реализацию точно переосмыслить. Оно работает, но... и этих "но" там много. Главное - производительность.

В целом, не имеет значения что случится с PackageKit, потому что никто вообще на это не повлияет.
1. Gentoo/Devuan и  аналогичные оставят его в той форме в которой он есть, взяв поддержку на себя.
2. Systemd-дистрибутивы применят новое.
3. На форумах устроят бурю в стакане 1 vs 2.

> Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика

Оставьте религию верующим. У "пингвинчика" есть одна единственная красная шапочка, которая хоть как-то заботится о нём как об ОС (серверной и для рабочих станций). И есть тысяча и один шизоид из "сообщества" рассуждающий о свободе и выборе под действием секты FSF, которая занимается политикой а не разработкой ПО. Причем часть тех шизоидов, которые всё же способны собрать пакет под свой велосипед, еще рассуждают об инфраструктурных инновациях, критикуют, будто видели в жизни поставленную перед собой задачу такого масштаба и, что характерно, реальную альтернативу собственного изготовления имеющемуся инфраструктурному решению от красной шапки предложить не могут. Только компоновать код из их же форков, которые любезно доступны под свободной лицензией, только GPL, только хардкор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #69, #84, #100

22. Сообщение от Аноним (21), 06-Мрт-20, 15:23   +3 +/
JS... вообще-то уже есть polkit
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

23. Сообщение от Аноним (23), 06-Мрт-20, 15:27   –1 +/
Полютос Что-то не особо спасло переписывание на плюсы. Он даже не стал быстрее работать. В чём смысл переписывания?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #28

24. Сообщение от iFRAME (ok), 06-Мрт-20, 15:30   –1 +/
> Чем это лучше guix?

Чем это лучше MSI?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #32, #95

25. Сообщение от Аноним (25), 06-Мрт-20, 15:30   +1 +/
Серьезно? На 7 год индеец Быстрый Как Ветер заметил, что тормознее dnf только портаж, который компилирует пакеты и неплохо бы переписать этот кусок говна на нормальном языке? Невероятная скорость реакции! Энтерпрайз!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40, #86

26. Сообщение от Аноним (26), 06-Мрт-20, 15:33   –3 +/
C++ будет одинаково работать на всех платформах? Теперь оно ещё и к железу привязано будет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

27. Сообщение от пох. (?), 06-Мрт-20, 15:50   +6 +/
как, обоих?!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

28. Сообщение от redgad (?), 06-Мрт-20, 15:51   +3 +/
No python dependency.

(задолбались мы менять по всем скриптам /usr/bin/python на /usr/bin/python3, а эти ненормальные того гляди - предложат менять на python4.2.1.0.0.22 в следующей версии)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #34

29. Сообщение от redgad (?), 06-Мрт-20, 15:55   +5 +/
kokokokoй ужос! Вы еще сейчас и обос.етесь, когда узнаете что у вас ядро линукса - вообще на си написано - оно еще и к железу привязано, представляете?!


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

30. Сообщение от evkogan (?), 06-Мрт-20, 16:05   +2 +/
попробуйте zypper и не надо будет изобретать велосипед dnf.
Я еще понимал использование yum, который брал начало примерно из тех же лет, но был свой.
Но вот вместо перехода на лучшее решение начать пилить очередное свое, а потом его перепиливать.
У RHEL последнее время подход использовать только свои решения не глядя вокруг. Еще и навязывая эти решения остальным. Но это не значит что решения лучшие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #39, #45, #60, #108

31. Сообщение от user90 (?), 06-Мрт-20, 16:14   +/
"из компании Red Hat" - и аж скулы сводит! Вспоминаешь ту же OpenSUSE: чем она была раньше, и чем она стала теперь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58

32. Сообщение от фу_быть_таким (?), 06-Мрт-20, 16:26   +2 +/
> Чем это лучше MSI?

ERROR: your package is not supported. Please use the correct package format!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

33. Сообщение от йо ж (?), 06-Мрт-20, 16:33   –3 +/
-- Грузины лучше, чем армяне.
-- Чем?
-- Чем армяне.

Уровень аргументации медианного комменатора опеньнета.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

34. Сообщение от Аноним (23), 06-Мрт-20, 16:40   –1 +/
Ну это говорит только о качестве скриптов и их авторов. Самая боль для меня была поддерживать 2 на венде (не cygwin, msvc пакет с компилятором для питона только у 2 был) и 3 на линуксе, в 1 кодовой базе. Мне кажется это проблема дистрибутива, просто дефолтный уже давно должен быть 3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #57

35. Сообщение от Lexemail (??), 06-Мрт-20, 17:02   –1 +/
Ну так на православном Си и писали бы..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

36. Сообщение от Аноним (45), 06-Мрт-20, 17:06   +/
«Мы решили заменить старый велосипед новым более современным велосипедом»
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от BlackRot (ok), 06-Мрт-20, 17:09   –2 +/
В каком месте он тормозит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #89

38. Сообщение от Аноним (38), 06-Мрт-20, 17:29   –2 +/
> Прям как в вёбе

Троцкисты. Зато все заняты и не ленинизмят )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

39. Сообщение от IRASoldier_registered (ok), 06-Мрт-20, 17:33   –1 +/
"(...) Где и как мне лучше купить надежный и красивый цуникримпель?

На что дорогие товарищи отвечают ему обычно следующее:

1. На кой тебе вообще сдался цуникримпель? Купи две крымзы. Стоит столько же, а объем побольше. Две крымзы делают все то же, что и один цуникримпель, только не свистят."

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

40. Сообщение от Аноним (45), 06-Мрт-20, 17:49   +/
DNF уже давно стал быстрым:

https://www.opennet.ru/opennews/art.shtml?num=47471

> 30.10.2017 20:35
> По сравнению с YUM 3 в YUM 4 наблюдается существенный прирост производительности, особенно при

разрешении зависимостей

И это реально стало заметно. Говорю как тот кто был вынужден пользоваться на работе федорой с 20 по 28.

На путаницу имени yum/dnf можно не обращать внимания, Red Hat меняет его туда-сюда.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #41, #81

41. Сообщение от Аноним (45), 06-Мрт-20, 17:52   +1 +/
Если не понятно: да, он жутко тормозил. А потом с очередным апгрейдом дистрибутива вдруг стал заметно живее даже на HDD. Самая медленная часть – обновление инфы о пакетах с репозиториев. Разрешение зависимостей в повседневных задачах почти моментальное, установка ничем не медленнее Zypper или APT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #82

42. Сообщение от псевдонимус (?), 06-Мрт-20, 17:53   +1 +/
И здесь уродский дбус.


Что еще упоротый бот считает ненлрмативной лексткой. В этот раз это сдово бастардский, в русском переводе.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59, #80

43. Сообщение от Аноним (45), 06-Мрт-20, 17:53   +/
https://www.opennet.ru/opennews/art.shtml?num=52494#40
#40 и #41
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #74

44. Сообщение от Аноним (44), 06-Мрт-20, 17:57   –4 +/
Странные там ребята сидят. Пишется за час с лишнем на Golang.
А тут годами что-то разарбатывают на Python и C++.
Короче странные ребята.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #83

45. Сообщение от Аноним (45), 06-Мрт-20, 17:58   –2 +/
DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM. В качестве фронтэнда мне больше нравится Zypper – он удобнее, у него приятнее синтаксис и больше фич (но есть несколько мелких багов), но его почему-то не взяли. Всегда интересовал вопрос "почему?", и только что возникла догадка – как раз для того, чтобы переход yum -> dnf осуществлялся почти без изменений (команды, ключи), т.е. можно было сделать yum алиасом dnf'а.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #46

46. Сообщение от Annoynymous (ok), 06-Мрт-20, 18:07   +1 +/
> DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM.

Это самый прекрасный бред, который я читал в 2020-м, спасибо!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #104

47. Сообщение от leap42 (ok), 06-Мрт-20, 18:55   +/
> Странные там ребята сидят. Пишется за час с лишнем на Golang.
> А тут годами что-то разарбатывают на Python и C++.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #75, #76

48. Сообщение от Ilya Indigo (ok), 06-Мрт-20, 19:36   –1 +/
> ...в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++.

С этого и нужно было начинать!
Тогда бы и переносить не нужно было.

Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Аноним (49), 06-Мрт-20, 19:39   –1 +/
ну гуикс, все же, немного о другом. Там же совсем "принципиально новый" способ организации пакетов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

50. Сообщение от mikhailnov (ok), 06-Мрт-20, 19:52   –2 +/
Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем, а графические "магазины приложений" продолжат уметь ставить нормальные пакеты через packagekit.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #61, #92

51. Сообщение от user90 (?), 06-Мрт-20, 20:09   –2 +/
О, как же блять это ненужно! Ты ж понимаешь, только сорцы и только сборка под конкретную платформу. Эт откуда вас столько выползло? Реально интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #54, #68

52. Сообщение от коржик (?), 06-Мрт-20, 21:35   +1 +/
а в чем проблема? превосходства пингвинчика никуда не делись
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

53. Сообщение от коржик (?), 06-Мрт-20, 21:41   –1 +/
пользуюсь dnf на домашнем ноуте, проблем не замечал. вы когда-нибудь накатывали сервис пак на десяточку или мак?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

54. Сообщение от анонимуслинус (?), 06-Мрт-20, 22:01   +/
а откуда все дистры то выплыли? все было так же раньше как примерно в слаке( не путать со словом через "р")). а потом.... мне рассказывать как появились рпм и деб пакеты и их системы установки?. короче даж в википедии быть должно почитай. а сборка прог с флагами под каждую платформу на каждом компе не многим реально то и нужна, хотя да выигрыш порой может и до 10% быть. а днф не пробовал ни разу. как слез в свое время на мандриву так про федорку и забыл. а нет помнится какой же там выпуск был, кажется 14 федорки в лайве гонял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #55

55. Сообщение от Аноним (23), 06-Мрт-20, 22:33   +/
10% чего? 10% безопасности, 10% меньше heartbleed, или чего? Тот же интеловский компилятор продуцировал в полтора более быстрый код даже на всяких кодировщиках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

56. Сообщение от DerRoteBaron (ok), 06-Мрт-20, 23:13   +/
> лучшие части dnf как раз из него взяты

А не лучших, но тем не менее полезных там не хватает. Например, банальное действие по выкачиванию  пакетов (в т.ч. src.rpm) превращается в пляску с весьма странными второстепенными флагами, правами рута и доставанием загруженного из /var/cache. И другие вроде мелкие, но тем не менее бросающиеся в глаза при долгом использовании косяки.

По мне он довольно неплох, но CLI у dnf куда логичнее, удобнее и полнее

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

57. Сообщение от пох. (?), 06-Мрт-20, 23:17   +2 +/
а причем тут "качество скриптов"?
Разработчики пихон заявили (и выпустили какой-то там PEP-2342425234534652 ) что пихон не должен ни в коем случае называться пихон, а обязан называться python3 - всем срочно переделывать свои скрипты. а не то.
Причем я уже раза три видел в разных проектах пулреквесты с подобными правками. Особенно здорово - в совместимых.

> Мне кажется это проблема дистрибутива

нет, это проблема пихона. Его реально пишут совсем поехавшие.

Весь смысл этого их выступления - намеренно сломать совместимость с python2 даже для тех программ, где ее героическим усилием сохранили. Никакого "дефолтного3" и возможности выбирать дефолтный - обязан быть гвоздем прибит в скрипте именно 3.

Можно понять желание редbm дистанционироваться от этих придурков любой ценой.

Потому что завтра они так же впихнут всем четвертый.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #63

58. Сообщение от пох. (?), 06-Мрт-20, 23:20   +/
Труп смердящий еси.

Да и была им же. Уже много-много лет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

59. Сообщение от пох. (?), 06-Мрт-20, 23:20   +1 +/
не уродский, а редхэтовский.
"наша корова, и мы ее доим".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

60. Сообщение от DerRoteBaron (ok), 06-Мрт-20, 23:26   –1 +/
dnf лучше zypper примерно в тех местах, что и yum лучше zypper: более удобный, логичный и дееспособный CLI
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #88

61. Сообщение от пох. (?), 06-Мрт-20, 23:30   +/
не, не обломаются.

Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.
Единственный способ сделать их хоть полу-работающими - очень тщательно завернуть в дерьмоконтейнер вместе со всем мусором, валяющимся вокруг.

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

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

Новый стандарт же ж, жрите, не обляпайтесь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #62, #67

62. Сообщение от анонимуслинус (?), 06-Мрт-20, 23:36   +/
честно говоря все это ничем не отличается от статической линковки обмазаной новым слоем)) история по спирали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #64

63. Сообщение от Аноним (23), 06-Мрт-20, 23:38   +/
Так они видимо научились на своих ошибках. 2 объективно надо было дропать сразу, продакшен бы подорвался и в темпе решил все проблемы. С python3 наверно подготавливают почву для python4, чтобы избавиться от всего этого крапа, через который пришлось проходить с 2 и 3. А что они сломали там в плане совместимости? Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет? Пусть хуже и медленней, да и код выглядит не очень, но работает же. Если пишешь для 3, просто берёшь версию старше той, для которой написано. В 4 собирались сломать совместимость, я надеюсь им хватит ума не повторить историю с 3. Но это ещё не скоро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #65

64. Сообщение от пох. (?), 06-Мрт-20, 23:40   +/
отличается. Не говоря уже о том что статическая сборка в gcc поломана двадцать лет как.

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

Причем вперемешку.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #70

65. Сообщение от пох. (?), 06-Мрт-20, 23:56   +2 +/
Вот редхат подорвался и решил проблему - нет пихона, нет проблемы.

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

> Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет?

нет. После 3.5 уже много чего не работает.
Некоторые подробности излагали авторы hg. b'string' vs 'string' особенно им доставила.

Надысь вон выяснилось, что пихон отменил 'None' - теперь нельзя его использовать в сортируемых списках.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #66, #90

66. Сообщение от Аноним (23), 07-Мрт-20, 00:17   +/
>авторы hg

Нужность hg ещё под большим вопросом. Какие ещё 'string'? Они ламеры, не иначе. Эти тоже зачем-то поддерживали 2?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

67. Сообщение от mikhailnov (ok), 07-Мрт-20, 00:20   +/
> Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #71

68. Сообщение от mikhailnov (ok), 07-Мрт-20, 00:21   +/
> О, как же блять это ненужно! Ты ж понимаешь, только сорцы и
> только сборка под конкретную платформу. Эт откуда вас столько выползло? Реально
> интересно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

69. Сообщение от GentooBoy (ok), 07-Мрт-20, 00:36   +/
Мы уже поняли что вас красношапка покусала, но зачем всем об этом рассказывать?
То что шапка пилит что бы диктовать всем стандарты какие она хочет вам видимо не очевидно.
Потому что если она может диктовать всем, то менеджер может приходить к потенциальному заказчику и бить в грудь что мы самые передовые и денежки нести нужно нам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #93

70. Сообщение от анонимуслинус (?), 07-Мрт-20, 00:49   +/
ну как факт переизобретают тоже. в свое время от статики стали уходить именно по причине уменьшения размера окончательного пакета и меньшему потреблению оперативной памяти при использовании разделяемых библиотек. так они опять за свое , только в еще более худшем варианте. так они линукс в винду помоечную превратят в 2 счета.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

71. Сообщение от анонимуслинус (?), 07-Мрт-20, 00:54   +/
это пока она есть. пока писателям всяким не станет удобно не париться сборкой под конкретную платформу, а выложить готовый пакет без исходников. кстати сменив при этом лицензию. или корпорациям заворачивать свои дрова с зондами вообще без возможности просмотра исходников. и получаем вуаля винукс в перспективе. а ведь все больше народа тащет проги в во всех этих контейнерных форматах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

72. Сообщение от колба (?), 07-Мрт-20, 01:25   +/
ну вот так получилось что они теперь одинаково работают на любом дистрибутиве и без ппакажкита..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

73. Сообщение от Аноним (73), 07-Мрт-20, 02:38   +/
Автор yum вроде угодил на велосипеде под автотранспорт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #109

74. Сообщение от Аноним (73), 07-Мрт-20, 02:41   +1 +/
python не тормозит (R)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

75. Сообщение от Аноним (73), 07-Мрт-20, 02:41   +/
Звучит на правду
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

76. Сообщение от Козульщик из RedHat (?), 07-Мрт-20, 02:42   +/
ДА!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

78. Сообщение от Аноним (78), 07-Мрт-20, 11:12   +/
>Hawkey Python API будет удалён и заменён на libdnf Python API.

Сначала удалят, а потом через 10 месяцев добавят?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91

80. Сообщение от Нонон (?), 07-Мрт-20, 12:11   +/
А тут DBus или DBus Broker?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

81. Сообщение от anonymous (??), 07-Мрт-20, 14:54   +/
Да вот я вынужденно сейчас пользуюсь yum/dnf после привычного apt. И каждый раз, когда пользуюсь пакетным менеджером, офигиваю насколько всё медленно (всё никак не привыкну). Ну и неудобно, конечно же, но это уже субъективно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

82. Сообщение от anonymous (??), 07-Мрт-20, 14:56   +1 +/
Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев". Я его просил? Я очень ценю свою время, и не люблю когда его так бесполезно растрачивают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #105, #110

83. Сообщение от Аноним (83), 07-Мрт-20, 17:47   +/
у голанга версии максимум два года поддерживаются, нет  LTS веток
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

84. Сообщение от Аноним (84), 07-Мрт-20, 18:25   +/
>Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем нескучные обои.

Поправил, не благодари.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

85. Сообщение от Аноним (84), 07-Мрт-20, 18:28   +/
Ну и где ты в десятке сервиспаки видел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #113

86. Сообщение от Аноним (84), 07-Мрт-20, 18:31   +/
>тормознее dnf только портаж, который компилирует пакеты

Зато у нас в процессе буковки с циферками красивше по экрану бегают. И ЧСВ растёт на порядки. Шестнадцатеричные.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

87. Сообщение от Аноним (-), 08-Мрт-20, 05:02   +1 +/
Алилуя, через цать лет доползло что картонный макет пакетного менеджера - не рулит. После того как даже фрибзда сделала какое-то подобие нормального этсамого... А у этих - бизнеслогика, клять, в пакетном менеджере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

88. Сообщение от Аноним (-), 08-Мрт-20, 05:05   –1 +/
> dnf лучше zypper примерно в тех местах, что и yum лучше zypper:
> более удобный, логичный и дееспособный CLI

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

89. Сообщение от Аноним (-), 08-Мрт-20, 05:09   +/
> В каком месте он тормозит?

В операционке. Достаточно посмотреть разок на какой-нить apt... :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

90. Сообщение от Аноним (90), 08-Мрт-20, 06:21   +/
> нет. После 3.5 уже много чего не работает.

Да там каждый минорный :D релиз ведет к эпопее. Так что единственное для чего оно годится - для наколенщины выданой на гора в режиме fire and forget.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

91. Сообщение от Аноним (-), 09-Мрт-20, 01:59   +/
> Сначала удалят, а потом через 10 месяцев добавят?

Я бы на их месте вообще питон дропнул из системы. Это столько человекочасов бы всему глобусу сэкономило...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

92. Сообщение от Аноним (92), 09-Мрт-20, 12:07   +/
> Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем

Если не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #98

93. Сообщение от RedhatBoy (?), 09-Мрт-20, 12:14   +2 +/
При чем тут покусала. Пока что я вижу по нику что вас Gentoo покусала. Покажите мне конкурирующие стандарты. Есть LSB, есть systemd и всё от красной шапки. Другие системные стандарты и API, конкурирующие с этими мне покажите.

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

Вы живёте в плену иллюзий. Стандарт на ряд системных компонентов один и он от красной шапки и никто палец о палец не ударил чтобы придумать другой и согласовать. В случае с systemd там еще хуже, там один недописанный стандарт и одна единственная реализация, потому что никто палец о палец не ударил, чтобы подготовить совместимое решение. Все сидят пакеты пакуют и сорцы в тарболы перезаворачивают разглагольствуя о том следовать им стандарту или объявить протест. Взять готовую реализацию или объявить протест. Чтобы что-то предлагать нужно что-то делать, а тут одни скандалы в пользу бедных.

Та же самая Gentoo ничего не разработала и не стандартизировала вне своей экосистемы. Люди в основном собирают и следят чтобы всё собиралось. За этим потребовался подёргать форками udev -> eudev systemd-logind -> elogind. Это не инновация, не ифраструктура и не стандарт. Это у нас у тарбола зависимость и оно не собирается без либы, которую мы по дефолту поставлять не хотим. Решение - форкнуть. Но не просто так форкнуть, а форкнуть кусками, чтобы даже в базовой либе предоставлялось не всё API, а только то что нужно внутри Gentoo. Сделай так проприетарная контора сразу бы про ЕЕЕ вспомнили...

И менеджеры если уж ходят рассказывать о том какие они передовые, то показывают хоть какие-то результаты работы. А про негативный подход "ой мне всё диктуют и навязывают, я не буду ничего своего делать, прикинусь жертвой корпорации, чьи продукты я форкаю" - такой подход только в леворадикальных организациях типа FSF в почёте.

Короче, вместо нытья о страшных заговорах корпораций, предлагаю сперва добиться и сделать лучше, но не троллинга ради, а чтобы были альтернативы хотя бы в реализациях, не то что в стандартах. А то когда кучка перешедших на systemd дистрибутивов будет принимать Linux Standart Base 6.0 вам кроме шизоидного бреда про диктовку стандартов, менеджеров, денежки и "не хочу systemd потому что не нравится" и сказать будет нечего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #111

94. Сообщение от Аноним (94), 09-Мрт-20, 12:33   +1 +/
dnf настолько тормоз, что даже представить себе не мог
был опыт с apt, pacman, xbps, может разница по скорости где и была, но внимание на то не обращал - работать нигде это не мешало
то ли дело dnf, запускаешь банальную команду а-ля search и сразу переключаешься на какие-то другие дела, дожидаться исполнения у меня лично терпения не хватает, особенно при первом запуске, когда сначала оно просто тупит, потом неторопливо посинхронизируется с серверами, потом опять потупит, ну его, в общем
Ответить | Правка | Наверх | Cообщить модератору

95. Сообщение от Gogi (??), 09-Мрт-20, 13:16   +/
Что MSI - это дичайший гибрид СУБД и "логики инсталляторов". Всемогутер, который проще выкинуть, чем понять.

Инсталлятор - это unzip + пара манипуляций с системой. Всё остальное - понты.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

96. Сообщение от Gogi (??), 09-Мрт-20, 13:17   +/
+1. Шёл 2020-ый год, мыши продолжали шаблонить бабушку, несмотря на то, что прямо перед носом развивается Ди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

97. Сообщение от Gogi (??), 09-Мрт-20, 13:19   +/
Ну так всё зависит от архитектора! Влезает в FOSS какой-то прыщедрот, вчера освоивший пестон по трём веб страничкам и поехали кошмакодить! Хотя казалось бы, таких на пушечный выстрел нельзя подпускать даже для "улучшения" софта. Отсюда и позорное качество большинства поделий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

98. Сообщение от mikhailnov (ok), 09-Мрт-20, 13:33   +/
>> Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем
> Если не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.

Не переживай, будет в ней flatpak и GUI для него, а вот где ты увидел "пожелания смерти", интересно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #99

99. Сообщение от Аноним (92), 09-Мрт-20, 14:11   +/
>>> Надеюсь, продвигатели flatpak обломаются
> Не переживай, будет в ней flatpak

Ты теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #102

100. Сообщение от Аноним (101), 09-Мрт-20, 15:32   +/
> Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем система инициализации и собственный пакетный менеджер и то не все. Причина банальна - ресурсов нет. Вместо разработки инфраструктурных решений для ОС разработчики в основном пакуют пакеты и обслуживают совместимость и надёжность программного обеспечения. Спасибо им за это, безусловно, это важно, но не хватает единых API.

Окститесь, вы пытаетесь донести это до фaнбоя BSD!
У них неприятие единых кросс-системных стандартов чуть ли не биологическое.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

101. Сообщение от Аноним (101), 09-Мрт-20, 15:35   +/
Ну, как бы, проект, который допиливают, не может претендовать на превосходство.
Превосходно лишь то, что не трогают десятилетиями, ведь отсутствие необходимости в изменениях означает полное совершенство! (Нет, оно не может быть обусловлено тем, что на проект все просто забили, скажете тоже.)
[/sarcasm]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #106

102. Сообщение от mikhailnov (ok), 09-Мрт-20, 16:14   +/
>>>> Надеюсь, продвигатели flatpak обломаются
>> Не переживай, будет в ней flatpak
> Ты теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.

Я лишь пытаюсь дать пользователям возможность пользоваться flatpak, если они хотят его или он им нужен. Да, это немного его продвигает. Но не навязывает. И в отличие от сабжа я не пытаюсь вынудить кого-то отказаться от традиционных пакетов в пользу контейнеров.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #103

103. Сообщение от Аноним (92), 09-Мрт-20, 16:16   +/
> а нас то за шо?

за то.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

104. Сообщение от Аноним (104), 09-Мрт-20, 23:25   +/
libsolv не тот же?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #107

105. Сообщение от Аноним (104), 09-Мрт-20, 23:27   +1 +/
К сожалению, zypper грешит тем же, более того – даже если он не обновляет информацию о пакетах, он всё равно связывается с репозиториями по неясной причине. У pacman, apt, portage и многих других ПМ такой херни нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

106. Сообщение от Аноним (-), 10-Мрт-20, 00:48   +/
Если софт перестают допиливать и он сложнее хелловорлда - этот софт, очевидно, сдох.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

107. Сообщение от Annoynymous (ok), 10-Мрт-20, 01:22   +/
> libsolv не тот же?

Не знаю, я отвечал про «под капотом у них rpm».

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

108. Сообщение от Annoynymous (ok), 10-Мрт-20, 01:24   +/
> попробуйте zypper и не надо будет изобретать велосипед dnf.

А zypper может выгрузить лог транзакций и проиграть их на другом сервере? А показать историю изменений по пакету?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

109. Сообщение от Аноним (109), 10-Мрт-20, 10:07   +/
2013 год, как то давно уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

110. Сообщение от КО (?), 10-Мрт-20, 11:15   +/
>Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев".

Если Вы просите установить локальный пакет, без сторонних зависимостей, то он этого и не делает. А в противном случае ему надо узнать откуда брать пакеты. И это нормально. А периодичность опроса - дело настраиваемое.

P.S. Другое дело скажем Мавен. Сначала выкачяать метадату с репозиториев. Потом разложить ее по кучи мест. А затем начать выкачивать все пакеты из всех серверов. После чего свалиться по фатальной ошибке, что "связи с левым сервером нет, но версия пакета уже есть в кеше Мавена". Вот это я понимаю подход к пакетному менеджеру. :(

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

111. Сообщение от anononim (?), 10-Мрт-20, 14:48   +/
>Другие системные стандарты и API, конкурирующие с этими мне покажите

Ну если уж systemG стандарт, то openrc, upstart, SystemV-init
>никто палец о палец не ударил чтобы придумать другой и согласовать

Их много, вы не вкурсе в силу узости кругозора, а про согласовать, просто никто ногами свои варианты в другие дистрибутивы не пропихивает, в отличии от...
>Gentoo ничего не разработала и не стандартизировала вне своей экосистемы

Мда, а с виду адекватны, вам кто-то запрещает использовать portage или openrc?
>Но не просто так форкнуть, а форкнуть кусками

А вот и подтверждение, что у индивидуума не психологические проблемы, а повреждение мозга на физическом уровне, может форкали кусками потому, что от монолита systemG невозможно оторвать отдельные компоненты?
>предлагаю сперва добиться и сделать лучше

Так уже, те же связки openrc, runit/monit по удобству эксплуатации превосходят комбайн systemG, но они не модные/молодежные, и денег на них не заработаешь.
>сказать будет нечего

Для вас, фанатиков systemG, аргументы приводили десятками, но вы их упорно игнорируете, поэтому адекватные люди с вами давно не ведут полемики, любитель systemG с аппеляцией к скорости, современности, надежности, безопасности или наглядности  = клинический идиот.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #112

112. Сообщение от Аноним (21), 10-Мрт-20, 17:56   +/
> Ну если уж systemG стандарт, то openrc, upstart, SystemV-init
> Их много, вы не вкурсе в силу узости кругозора, а про согласовать, просто никто ногами свои варианты в другие дистрибутивы не пропихивает, в отличии от...

Это не стандарты и API, а системы инициализации с сервисной моделью разной степенью успешности. Красная шапка формирует системные API такие как HAL (переделали на systemd-udev), ConsoleKit (systemd-logind) PackageKit (переделают как сервис dbus) и PAM и очень много чего еще. Единственное что имеет серьёзную альтернативу - это их SELinux, который нравится далеко не всем меинтейнерам ввиду технической сложности сопровождения targeted-policy и можно использовать AppArmor и другие.

Я не спорю тут про системы инициализации не о них речь идёт, скандалы вокруг systemd в соседней теме. И вот это вот точно неадекватное поведение:
> А вот и подтверждение, что у индивидуума не психологические проблемы, а повреждение мозга на физическом уровне, может форкали кусками потому, что от монолита systemG невозможно оторвать отдельные компоненты?
> Так уже, те же связки openrc, runit/monit по удобству эксплуатации превосходят комбайн systemG, но они не модные/молодежные, и денег на них не заработаешь.
> Для вас, фанатиков systemG, аргументы приводили десятками, но вы их упорно игнорируете, поэтому адекватные люди с вами давно не ведут полемики, любитель systemG с аппеляцией к скорости, современности, надежности, безопасности или наглядности  = клинический идиот.

Заканчивайте гадания на кофейной гуще. Меня не интересуют ни скорость (особенно в сравнении с инициализацией дисков это смешно), ни современность (мне не нравится смузи), ни безопасности системы инициализации (это вне зоны её ответственности она тут сама под управлением), ни надёжности...
Не ошибается тот, кто ничего не делает, собственно, поэтому в вопросах системных API ни один дистрибутив не может ошибиться, потому что нету ничего. Как я и писал раньше сделать свою систему инициализации, сделать пакетный менеджер и собрать пакеты в дистрибутив - это предел по ресурсам.

RedHat делал продукты для себя и любезно предоставлял их под GPL, также как и Торвальдс поставляет Linux под GPL таково решение автора. Решение остановить поддержку старых решений и переписать их все в кучу в виде одного нового - это тоже решение автора. То что люди переходят с их старых продуктов на их новые продукты меня не удивляет, видимо нравится, видимо чем-то хороши и удобны. А то что у gentoo получилось или не получилось оторвать часть модулей - это как отодрать часть модулей от ядра линукс и потом жаловаться, что они не работают без самого ядра дескать оно монолитное... как будто в этом есть что-то плохое.

> Мда, а с виду адекватны, вам кто-то запрещает использовать portage или openrc?

Мне как системному администратору глубоко начхать, какая у меня система инициализации. Я их знаю абсолютно все и писал и скрипты и юниты. Главное тут задача, которую нужно решить.
Как пользователю мне вообще не важно какая у меня система инициализации.
Система инициализации и пакетный менеджер - это дистрообразующие подсистемы. "вам кто-то запрещает использовать portage или openrc" означает "вам кто-то запрещает использовать Gentoo". Да, иногда запрещает, корпоративный стандарт, например может запрещать, или здравый смысл. Source based дистрибутив с BSD-образными портами в проде или даже дома нужно аргументировать хоть как-то кроме "люблю куплю и полетим".
Как разработчику корпоративного ПО под линукс мне всё равно какая там в дистрибутиве система инициализации. Дайте SDK, API и документацию с примерами. Но чем меньше телодвижений и мыследеятельности (истинная причина популярности systemd) тем лучше.

Вот вы всё про деньги в чужих карманах разглагольствуете... а знаете ли вы что средний разработчик корпоративного ПО обходится дороже чем любой средний никс-администратор. Так вот, если у админа работы становится больше, а у девелопера меньше, то ваш работодатель получает прибыль путём экономии на дорогом труде. Ненависть к админам и продажа платной или даже франчайзинговой техподдержки вместо содержания своего админа это старая как мир бизнес модель. 1С, МС, Редхат, тысячи их, все на ней. Если вам это не нравится, рекомендую ехать в экспедицию на Марс.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

113. Сообщение от коржик (?), 11-Мрт-20, 21:59   +/
> Ну и где ты в десятке сервиспаки видел?

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

Забавно, что если у вас ноутбук, то он всю подковёрную деятельность десятки выдаёт шумом вентилятора.

Вот блокирую я экран, отхожу на 5 минут, а ноут начинает гудеть как ошпаренный. Это проснулась мафия

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру