Caixa Seca

O UPower pode ser útil em servidores que tenham UPS com comunicação USB (e serial talvez). Os modelos da APC costumam funcionar sem briga. Assim, você consegue desligar a máquina antes das baterias esgotarem-se. No Fedora 21, instale o pacote upower . O serviço é ativado por D-Bus e é iniciado sempre que algum outro programa requisitar suas interfaces . O pacote do Fedora não espera, contudo, e inicia-o incondicionalmente via graphical.target . Isso funciona quando existe a pilha gráfica. Não quando você está numa instalação mínima em modo texto, cujo target padrão é multi-user.target . Podemos adotar três caminhos: - Executar durante o boot algum programa que ative o daemon ( upowerd ), como uma invocação do binário upower . Gambiarra que descarto. - Alterar o target com systemctl set-default graphical.target . Essa é uma solução decente, mas não me agrada muito pois, se formos analisar minuciosamente, o único serviço pertencente ao graphical.target será upower.service . - Al

Cada coisa maluca... http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/26254 Isso me lembra outra discussão: pelo fato de não ter o hábito de ficar esperando e torcendo , o systemd expõe um monte de bugs desses scripts. Ainda sobre o assunto, o Squid upstream adicionou um arquivo .service ao repositório: Bug 3826: pt 2: Provide a systemd .service file for Squid . Deverá vir no 3.5.0.4. Não que faça grande diferença, pois cada distribuição está usando seu próprio arquivo faz tempo. Nem sempre iguais. Com a bênção upstream, a tendência é ficar uniforme daqui para frente. Estão usando Type=simple . Bom. Incompatível com o modo SMP por enquanto — nada impedirá, se até lá não for resolvido, substituir o .service oficial por um com as suas configurações voltando para Type=forking (e retirando o -N da invocação do binário).

O endereço MAC do adaptador de rede Attansic L2 da P5GC-MX fica armazenado na área DMI do BIOS. No post BIOS para Asus P5GC-MX rev. 3.04G da Positivo , recomendo atualizar programando essa área, o que leva o MAC a ficar com um valor inválido (ED-0B-00-00-E0-00), podendo ser rejeitado por alguns equipamentos de rede. Recolocar o MAC no lugar pode ser feito com o DMI Editor: dmi_2.00.44.zip No DOS , rode DMI /o 1"XXXXXXXXXXXX" colocando o código presente na etiqueta colada na placa no lugar dos X . Lembro de acontecer o mesmo nas Asus P5KPL-AM e P5VD2-MX . Talvez funcione nelas também. Ajuda do programa: ==================== DMI Editor V2.00.44 ======================= Usage : dmi </p|/s|/u|/a|/g|/n|/o|/sco # String> /p : get DMI using PnP functions /s : get DMI using memory search /u : set UUID /g : get informations in Type 1 and 2 /n : set Type 1 and 2 using the data which get from parameter /g /o # : se

Comecei a acompanhar o systemd quando Lennart Poettering anunciou em seu blog a criação do projeto em 2010. Me convenceu prontamente a ideia. Entrou como padrão no Fedora 15 operando basicamente aos moldes do Upstart no RHEL 6. Em grande parte lidando com scripts SysV no modo de compatibilidade. Não lembro ter enfrentando grandes bugs, porém eles existiam ao filtrar as flame wars da lista fedora-devel. No Fedora 17, a implementação já estava bem azeitada. Foi uma das poucas versões que durou bastante na minha máquina, praticamente até o dia em que foi descontinuada. Comecei a usar o openSUSE na versão 12.3 e da mesma forma não tive surpresas. Mais daemons rodavam com scripts SysV, mas a integração dos alemães foi boa. No ínterim entre o systemd 26 do Fedora 15 até o 210 que uso hoje no openSUSE 13.2, alguns componentes importantes foram adicionados. udevd foi incorporado ao repositório e passou a compartilhar código com o systemd. logind (30), o sucessor espiritual do descontinua

Mídia de instalação do openSUSE 13.2:

A forma de distribuição de aplicativos no GNU/Linux está quebrada . Ninguém desenvolve para o desktop Linux não só porque sua presença de mercado é baixa. Quem dera fosse apenas isso. É que disponibilizar aplicativos para as distribuições, sem colocá-los no repositório oficial das mesmas — linkando bibliotecas dinâmicas de variadas versões (com APIs diferentes) e seguindo o regramento e burocracia de cada uma —, é difícil. Mesmo quando o desenvolvedor aceita o fardo de manter o pacote no repositório, pode nem ser possível, pois as distribuições tendem a ser hostis com software proprietário por exemplo. Disponibilizar para várias distribuições? Pior. Matriz de teste gigante. Mais: pacotes RPM/DEB precisam ser instalados como root e podem fazer o que bem entenderem com o sistema. O bom sinal é que alguns desenvolvedores constataram que existe o problema: Why Package Managers are not my Ideal Software Distribution Mechanism O time do systemd está alinhavando um plano. Sinceramente

Windows 2000 Server em português do Brasil.

O Brasil é a lata de lixo dos gringos? (Clube do Hardware) Palmas para Gabriel Torres! Moramos no país dos preços absurdos . O que é triste? Não vejo a mais mínima possibilidade de algo mudar no curto prazo. Cada povo tem o governo que merece.