Автор Тема: Было: Как в Альте правильно создать swap ?  (Прочитано 14414 раз)

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 908
    • Домашняя страница
    • Email
2Olej: не используйте эти пакеты, раз не нужно. В чём проблема?
Андрей Черепанов (cas@)

Оффлайн Olej

  • Давно тут
  • **
  • Сообщений: 201
Это же не браузер какой-нибудь, который должен успевать за изменениями в html к примеру.
Да, это не браузер какой-то...
Это утилиты, которые должны "успевать" за сменой версий динамических библиотек в дистрибутивах Linux.
Классика: история с Viber ... на 1-2 года они похерили его поддержку в Linux ... потом (в апреле 2019г.) вспомнили, переименовали старую версию 7 в новую версию 10 :-D ...
Теперь оно несовместимо (не устанавливается!) ни со старыми дистрибутивами (Mint 17.3), ни с новыми (Debian 10). Кино-о-о-о  ;-D

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
P.S. Это должно стать "правилом успеха" для молодых и начинающих ;-): если в опенсорсном проекте нет обновлений 3 года - его нельзя использовать в своих планах и проектах.

:-) Всё зависит от того, что это за код. Главное, чтобы он был написан руками линуксоида растущими не из жопы, что стало модным. А QA должно быть у него в голове, а не пинком под сраку где-то там.
Пример тому, браузер elinks. Единственная проблема у которого, это то, что гугл возвращает страницы в utf8 с набором символов cp1251. Так же, как и mplayer-vc, который до предела упрощает использование локального видео в консоли. Даже для тех, кто DOS видел три раза в жизни. В рамках задачи, для которой он предназначен, обновлять его некуда и незачем. Все ошибки выловлены ещё на этапе создания, со сменой алгоритма и кода, там, где это было необходимо. Ну разве что перевести комментарии к блокам на английский.

Но если у линуксового программиста, обновление ради обновления или самой новой версии, а не ради скорости, компактности, простоты и надёжности, то это уже диагноз. Что стало сегодня очень модным.
К тому же новое, не всегда лучшее.
Фольклор спектрумистов:
- Лучшее, враг хорошего.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
В этом, в частности, при общем очень благоприятном фоне, большая беда дистрибутивов ALT Linux
Вы забыли добавить IMHO. :-)

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Это утилиты, которые должны "успевать" за сменой версий динамических библиотек в дистрибутивах Linux.
за этим успевает auto rebuild
Классика: история с Viber ...
Проприетарщина - это вообще не классика ни разу. Это нельзя пересобрать с новыми библиотеками никогда. Сранно слышать это от человека с таким опытом.

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
С хламом и мусором нужно расставаться легко!  :-D

Для меня, хлам и мусор, это systemd. Вот попробуйте с ним расстаться. И не так, как это получается, а так, как это должно быть. Вопреки желаниям разных лобби. Наплодившихся как грибы после дождя. И прочих "виртуозов" пишущих код исключительно под Линукс, а не под *nix. И наплевавших на портабельность. Такого нашествия быдлокодерства, до 2008-го в Линукс не было. Это цена популяризации. Как среди пользователей, так и среди разработчиков. Часть из которых, считает просто своим долгом, побыдлокодить и пробить это апстрим.

Оффлайн Olej

  • Давно тут
  • **
  • Сообщений: 201
не используйте эти пакеты, раз не нужно.
Эти - это какие?
Как-раз Swapspace мне интересен, спасибо что подсказали, и для изучения его я какое-то время потрачу, для управления swap, о чём, собственно эта тема.
Но обязательно беру себе на заметку, что а). в GIT проекта уже около года не вносились правки, б). у него нет хозяина, его никто не сопровождает и в). основные отладки и тестирования его сделаны и показаны ещё для 32-бит архитектур.

А вот в отношении остальных "этих" проектов/пакетов я именно так и поступаю: если нет активного развития 2-3 года - в своих проектах/разработках не использую, и коллегам - отсоветываю.  ;-)
 

Оффлайн Olej

  • Давно тут
  • **
  • Сообщений: 201
Для меня, хлам и мусор, это systemd. Вот попробуйте с ним расстаться. И не так, как это получается, а так, как это должно быть. Вопреки желаниям разных лобби. Наплодившихся как грибы после дождя. И прочих "виртуозов" пишущих код исключительно под Линукс, а не под *nix. И наплевавших на портабельность. Такого нашествия быдлокодерства, до 2008-го в Линукс не было.
1. А много ещё живых *nix вы можете насчитать кроме Linux?
Sun Solaris, QNX, Minix, OpenBSD (которую пророчили в GNU OS) ... - это всё кладбище;
NetBSD - в близком к тому состоянии...
Не говоря уже о соответствующих предыдущих аппаратных платформах: DEC, PDP, VAX, ... - со своими разнообразными *nix.
Что ещё?
Между чем и чем собираетесь портировать? Для кого из них?

2. systemd - это далеко не единственное, что полностью отличает Linux от POSIX стандартов и UNIX переносимости:
- udev & sysfs ... и всё, как следствие, что касается /dev/*, mkdev, libusb и мн.
- v4l и всё-всё-всё, что касается модели видеообработки онлайн...
- ALSA (Advanced Linux Sound Architecture) и всё что касается аудио ... не говоря уже о более позднем PulseAudio...
- ... да и мн.мн.другое...
О какой портабельности теперь можно думать? 

3. ... зато Wine и целые разделы форумов (здесь тоже ;-)) относительно этого "кю" - это, наверное, самое что ни есть "UNIX way", соответствует духу *nix?  ;-D
« Последнее редактирование: 18.06.2019 12:23:06 от Olej »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
А вот в отношении остальных "этих" проектов/пакетов я именно так и поступаю: если нет активного развития 2-3 года - в своих проектах/разработках не использую, и коллегам - отсоветываю.  ;-)
Это, как минимум, не сильно дальновидно. А так-то мой опыт поболее Вашего вероятно, с Б3-34 в середине 80-ых. ;-) Но вот Linux плотно да, года с 2001-2002 где-то.

Оффлайн Olej

  • Давно тут
  • **
  • Сообщений: 201
Проприетарщина - это вообще не классика ни разу. Это нельзя пересобрать с новыми библиотеками никогда.
А вот это, как-раз, совершенно не важно: проприетарщина или опенсорс.
Эта история с Viber - смешная и очень показательная о том, когда продукт остаётся (на значительное время) без сопровождения.
Самые что ни на есть опенсорсные проекты не собираются с библиотеками обновлённых версий, как только API этих библиотек хотя бы незначительно поплыли (один параметр в вызове поменялся/добавился  ;-)) ... а такое происходит совсем таки не редко.
P.S. И я это говорю не для красного словца, а по опыту "через руки" - мне по должностным обязанностям как-то приходилось компилировать по 10-50 опенсорсных проектов в 1 рабочий день ... и так 1-2 года.  ;-)

Оффлайн Olej

  • Давно тут
  • **
  • Сообщений: 201
А так-то мой опыт поболее Вашего вероятно, с Б3-34 в середине 80-ых.
С середины 80-х говорите, вьюношо?  ;-D
Гм-м-м ... нет, не поболее, это не тянет... с середины 70-х - это будет в самый раз: 5Э-92б (БЭСМ-6 в гражданском наименовании), МИР-2 (академика Глушкова), "Наири" ... в конце-концов ... ЕС-ЭВМ 10-22, 10-33, 10-45 ... СМ-2 (которая HP), СМ-4 (которая PDP-11), "Электроника-79", но про такую вы врд ли слышали (которая PDP-11/70M).  :-o


Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
А вот это, как-раз, совершенно не важно: проприетарщина или опенсорс.
Важно: проприетарщину невозможно пересобрать без владельца ни при каких условиях. Единственный путь - держать под каждый случай свой набор библиотек и подсовывать при запуске. Более правильный путь - статическая сборка конечно, но идите им расскажите.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
"Электроника-79", но про такую вы врд ли слышали (которая PDP-11/70M).  :-o
Ага, конечно. RSX-11 на СМ-4 совсем другое, да... ;-) И переставайте тогда нести чушь про умирающий код (законченный код для статической ситуации; я не зря html упоминал) и про проприетарщину. А то смешно выглядит, право слово.
« Последнее редактирование: 18.06.2019 13:10:03 от asy »

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
OpenBSD (которую пророчили в GNU OS) ... - это всё кладбище;

Не вам решать, что кладбище, а что нет.

1. А много ещё живых *nix вы можете насчитать кроме Linux?

Количество не имеет значения. Правило одно: Вынь руки из жопы и напиши портабельный код.
Иначе вердикт будет однозначным:
http://www.ipfw.ru/quotes/8670

Оффлайн Александр Ерещенко

  • Завсегдатай
  • *
  • Сообщений: 1 153
не используйте эти пакеты, раз не нужно.
Эти - это какие?
Как-раз Swapspace мне интересен, спасибо что подсказали, и для изучения его я какое-то время потрачу, для управления swap, о чём, собственно эта тема.
Но обязательно беру себе на заметку, что а). в GIT проекта уже около года не вносились правки, б). у него нет хозяина, его никто не сопровождает и в). основные отладки и тестирования его сделаны и показаны ещё для 32-бит архитектур.

А вот в отношении остальных "этих" проектов/пакетов я именно так и поступаю: если нет активного развития 2-3 года - в своих проектах/разработках не использую, и коллегам - отсоветываю.  ;-)
Итак, имеем заброшенный, но всё ещё востребованным кем-либо, проект. Заброшен он мог быть по разным причинам - автору стало неинтересно, некогда, да и просто по причине смерти автора.
Но преимущество открытых проектов как раз в том, что любой, кто заинтересован в этом проекте, может его подхватить и поддерживать самому, если есть возможность связаться с автором, или форкнуть и развить самостоятельно далее.

Вот пример с Swapspace.
Проект заброшен, его есть куда развивать - поддержка 64-битности, Вы заинтересованы в проекте, у Вас есть возможности/способности его развивать. Вы можете: а) форкнуть проект и развить его, добавив необходимую Вам функциональность; б) создать проект с нуля, реализовав необходимый функционал; в) ничего не делать и ждать, когда кто-нибудь реализует пункты а и б.

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