Estabilidade, Debian e uso de Linux no desktop.

RLFontan
(usa Red Hat)

Enviado em 19/04/2019 - 12:36h

Ola pessoal beleza?

Eu tenho alguns dúvidas antigas sobre o Debian que tocam nos conceitos de estabilidade e eu queria tentar encontrar um ponto final nessa brincadeira. Postei essa dúvida em alguns grupos do Telegram e também estou postando uma adatapção aqui.

Estive pensando uma complicação de usar Debian Testing para desktop, o fato de que o usuário tem que ficar de olho "manualmente" em alguns pacotes de segurança. Desse modo, existem programas para facilitar esse processo, mas no fundo todo usuário usando Testing, Sid e Experimental está fazendo parte do desenvolvimento do Debian... para o bem e para o mal.

Seguindo a linha do que foi dito, um exemplo seria o seguinte: alguns pacotes que ficam presos no SID, ficam esperando por correções de bug, e tem neles ao mesmo tempo correções de problemas de segurança existentes no Testing... logo, o usuário, se quiser resolver isso logo, acaba tendo que fazer essas verificações manualmente e decidir o que vai puxar para o Testing ou não, ou seja, se entendi bem, ele verifica se esses bugs não atingem sua máquina, e se esse for o caso, ele faz o update, caso contrário, ele espera.

O que eu não sei, é se isso é uma desvantagem inerente à usar Debian Testing como desktop, ou se em distribuições mais aceleradas eles tomam essas decisões em nome do usuário, trazendo eventualmente, problemas para uma minoria de usuários, que serão vantagens para uma maioria. O debate sobre estabilidade é um que até hoje eu não tenho uma opinião final, bem como tenho dificuldade de entender em que situações vale realmente a pena usar Debian independentemente de suas versões

Eu concordo com muitos usuários que sentar em cima de pacote velho não é solução, e que novos updates trazem correções de bugs e performance... mas também concordo que o ambiente de pacotes velhos, LTS e exaustivamente testados podem proteger usuário que vão herdar problemas inevitáveis com os novos pacotes que estão por vir.

Pegue o pessoal que tem placas velha da Nvidia por exemplo. Um belo dia a Nvidia dropou o suporte e tornou uma série de placas "legadas". O camarada que está no Debian Stable e no Slackware não terá problemas, uma vez que até hoje eles usam versões compatíveis do kernel e do Xorg. No próximo release certamente o problema virá. Desse modo, usuários de distribuições que atualizam com muita frequência já receberam a tela preta a muito tempo e estão chorando nos quatro cantos tentando fazer sua placa funcionar. O usuário que fez essa configuração no Debian Stable ou no Slackware, provavelmente estará de boa até o final da versão em questão.

Sinceramente, eu tenho muitas dúvidas em relação a essa complexidade do Debian, bem como qual o modelo de desenvolvimento ideal para o desktop. Conto com a ajuda de vocês para me ajudar a botar um ponto final nessas dúvidas!

Obrigado pela atenção.

clodoaldops
(usa Linux Mint)

Enviado em 19/04/2019 - 13:04h

Debian assim como o Centos não tem seu foco em servidores ???

Pebis
(usa Debian)

Enviado em 19/04/2019 - 14:30h

Acho que tudo depende da finalidade. Para o dia a dia o Debian serve muito bem, um usuário que utiliza somente o básico não necessita de pacotes novos.

edps
(usa Slackware)

Enviado em 19/04/2019 - 19:44h

Eu prefiro usar Stable + Backports.

Não acho o Testing confiável para usá-lo indefinidamente, até porque não existem AVISOS como em sistemas rolling-release tipo o Arch, já se o cara faz seus updates via terminal é mais simples de se ver o que ocorrerá, mas se usa aplicativos gráficos a coisa tende a ficar mais complicada.

Quando quero algo novo (ou que me permita empacotá-lo), sigo algo parecido com isto:

https://wiki.debian.org/SimpleBackportCreation

* pulo apenas a parte do dhc e do fakeroot

Exemplo de pacote que não existe nos repos Debian:

$ sudo apt install packaging-dev build-essential git

$  git clone --depth=1 https://github.com/johanmalm/jgmenu.git

$ cd jgmenu

$ mk-build-deps

$ sudo dpkg -i jgmenu-build-deps_2.2.1-1_all.deb

$ sudo apt -t stretch-backports -f install

$  dpkg-buildpackage -us -uc -b -tc

$ sudo dpkg -i ../jgmenu_2.2.1-1_amd64.deb 

E para remover as dependências de compilação:

$ sudo apt --purge remove mk-build-deps

$ sudo apt autoremove --purge 

log completo:

http://dpaste.com/38A0XA4

RLFontan
(usa Red Hat)

Enviado em 19/04/2019 - 21:49h

Esse esquema lida com as dependências do pacote que eu estaria fazendo pelo backports? Porque eu vi essa alternativa antes mas a desconsiderei justamente por pensar no meu caso que são os drivers da Nvidia, que os que preciso só tem no experimental. As dependências comuns dos drivers da Nvidia já são umas 10 imagine ao se incluir bibliotecas de compatibilidade 32-bits? Se for para fazer manualmente é uma loucura.

edps
(usa Slackware)

Enviado em 19/04/2019 - 22:00h

Tem casos e causos, esses da Nvidia o melhor mesmos seria pegar o driver .bin e instalar manualmente.

Muita coisa fica impossibilitada de ser empacotada por causa de dependências, a maioria delas por causa da libc, glibc, etc

Por exemplo, no Stretch o NANO é de versão 2.7.4-1, enquanto que no SID é a 3.2-2, no MX Linux que deriva-se do Stretch eu consigo empacotar uma versão mais recente do NANo vinda do Debian SID/Unstable, a 3.2.2:

$ dget -x -u http://deb.debian.org/debian/pool/main/n/nano/nano_3.2-2.dsc

$  cd nano-3.2

$  mk-build-deps

$  sudo dpkg -i nano-build-deps_3.2-2_all.deb

$  sudo apt -f install

$  dpkg-buildpackage -us -uc -b -tc

$  sudo dpkg -i ../nano_3.2-2_amd64.deb

$  sudo dpkg -i ../nano-tiny_3.2-2_amd64.deb



~/nano-3.2 » nano --version

 GNU nano, versão 3.2

 (C) 1999-2011, 2013-2018 Free Software Foundation, Inc.

 (C) 2014-2018 os contribuidores do nano

 Email: nano@nano-editor.org	Web: https://nano-editor.org/

 Opções compiladas: --disable-libmagic --disable-wrapping-as-root --enable-utf8



~/nano-3.2 » uname -a

Linux mx 5.0.0-7.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.0-6~mx17+1 (2019-04-06) x86_64 GNU/Linux



~/nano-3.2 » cat /etc/os-release 

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

NAME="Debian GNU/Linux"

VERSION_ID="9"

VERSION="9 (stretch)"

ID=debian

HOME_URL="https://www.debian.org/"

SUPPORT_URL="https://www.debian.org/support"

BUG_REPORT_URL="https://bugs.debian.org/"

~/nano-3.2 » 

 

às vezes dá, noutras não!

edps
(usa Slackware)

Enviado em 19/04/2019 - 22:10h

Até o Nano 4.0 do Debian Experimental dá para empacotar e instalar no Debian Stretch e|ou Mx Linux!:

http://dpaste.com/248F36Y

Delusion
(usa Debian)

Enviado em 19/04/2019 - 22:11h

Pra mim o ramo testing é o melhor para desktop/notebook, sem sombra de dúvida.
Se você usa DE gordo, leia-se gnomeshell ou plasma (não é meu caso, rsrs), é quase impossível viver sem o SID, aí compensa definir a prioridade dos repos por pin.
Problema você vai ter sim, cedo ou tarde, principalmente porque o APT fora do stable é carente de atenção e às vezes ele surta; mas é fácil evitar transtornos se você ficar atento.
IMHO, Debian sempre vale a pena, se a alma não é pequena.
Debian é um sistema muito fluido, estou usando buster desde o lançamento como testing e, paradoxalmente as únicas duas chateações que tive foram depois do full-freeze (vai entender...). Elas foram: o maldito driver de touchpad desconfigurando e a estabilidade do libreoffice no nível de um Archlinux da vida:( . Como eu uso muito o impress, tive de me ancorar no openSUSE-leap (xfce é claro!), que nem sempre é tão fluido, mas até agora tem sido 101% confiável.

Distros prediletas: Debian/testing, openSUSE, Fedora.
Linux User # 624552

edps
(usa Slackware)

Enviado em 19/04/2019 - 22:17h

Isso também é verdade, sempre usei ambientes leves no Debian, nunca quebrei o Testing ou o SID.

Quanto a setar pinagens só fiz isso para fugir do SystemD, do PulseAudio e do Network Manager, isso quando o Debian era o meu SO principal.

RLFontan
(usa Red Hat)

Enviado em 19/04/2019 - 22:19h

Puts, aí é osso, esse .run não bagunça com a organização e confiabilidade do sistema?

edps
(usa Slackware)

Enviado em 19/04/2019 - 22:36h

Nos últimos tempos com meu velho PC em preteri o driver NVIDIA em favor do NOUVEAU, porque não jogo e para não ter que ficar resolvendo problemas com drivers de vídeo, depois passei a usar esse mesmo instalador .run no Debian, Slack e Gentoo, agora uso outro PC com vídeo intel

O que você deve saber é qual driver ou pacote precisa, por exemplo, se instalando o pacote nvidia-driver resolve, você pode ir até a página:

https://packages.debian.org/stretch/nvidia-driver # STRETCH
ou
https://packages.debian.org/experimental/nvidia-driver # EXPERIMENTAL

e catar o arquivo .dsc com o dget, isso requererá que ao menos você instale os pacotes: build-essential dpkg-dev equivs dh-make dkms ou de modo completo o meta-pacote packaging-dev, exemplo:

$ dget -x -u http://deb.debian.org/debian/pool/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_418.56-... 

Isso baixará o código fonte do driver para você compilar, mas não pense que é fácil, numa das URLs acima constam as dependências do tal pacote e nelas há uma pancada de micro-pacotes nvidia-*, simplesmente talvez você tenha trabalho em vão.

à vezes é melhor criar um FrankenDebian:

1. adicionando o repo do pacote que quer instalar;
2. rodando um apt install pacote; e
3. e removendo o repo

E obviamente não rodar um upgrade ou dist-upgrade.