HACK THE SYSTEM: 1/3/12

RSS

 Seguime por RSS

22 mar 2012

Linux Kernel 3.3 disponible para RHEL6 y Clones

Si instalaron elrepo-kernel, desde el dia de ayer, tendrian que tener actualizado, el kernel a la version 3.3.
De momento que la vengo usando, puedo decir que mejoró la velocidad de deteccion de redes wireless con placas Intel. Noto una mejoria en la administracion de energia, asi como en velocidad de acceso a disco.
Tambien puedo notar que el consumo de RAM inicial, es unos 10mb inferior al 3.2.10.
Bueno, ya saben, yum update y es todo!

Instalar Darktable en Fedora 14 / 15 / 16 | Editor de imagenes RAW

Algunos de ustedes, usarán imagenes en formato RAW, o sea, crudo, sobre todo, los que sean fotografos o simplemente tengan esta actividad para el tiempo libre. Algunas camaras, las mas profesionales, pueden sacar fotos en formato RAW, el cual es muy pesado y permite retocar ciertas cosas antes de darle los ajustes finales, en programas como GIMP.
Darktable, es un editor de imagenes RAW, totalmente Open Source.
Para instalarlo en Fedora 14-15-16, solo deben hacer esto (no se puede en RHEL por falta de dependencias):

1.- Abren un terminal
2.- Se loguean como root
3.- # cd /etc/yum.repos.d/
5.- # yum install darktable

Eso es todo, luego me cuentan si les parecio bueno o no ;)

18 mar 2012

Música hecha con componentes de PC, genial! || Music maked with PC parts!

Yo no me canso de verlos, no se ustedes. Vean todos por favor!, comenten cual les gustó más!
El ultimo es la música del Tetris, por eso el titulo en Ruso!.





Encuesta para saber que distribucion se adecua mas a ti

Es conocida esta web, pero no viene mal recordarla a los que recien estan comenzando en el mundo Linux, y aun no saben que distro les conviene mas.
Basicamente, les hará una serie de preguntas, previamente elegido el idioma, con las que les va a sugerir la o las distro que mas se adecuen a sus preferencias, basandose en las preguntas previas

Encuesta Distro Linux

17 mar 2012

Mark Shuttleworth miente, raro no? // ironic mode on

Hace unos dias, el lider del proyecto Ubuntu, dio a conocer un estudio y analisis, donde muestra que Ubuntu Server, supera a Red Hat en lo que es servidores.
Para la mala suerte de Mark, esto no es asi... dado que supera a Red Hat, porque este útimo es pago, pero no supera a CentOS, el clon binario de RHEL (o sea, es lo mismo eh!).
En la lista, se ve primero a Debian, le sigue CentOS, y luego Ubuntu. Yo confio mas en las estadisticas de W3techs que en las de Mark, ustedes?

Estadisticas de Mark: http://www.markshuttleworth.com/archives/1072?utm_source=twitterfeed&utm_medium=twitter

Estadisticas de W3techs: http://w3techs.com/technologies/details/os-linux/all/all

Una imagen, en este caso, grafico, vale mas que mil palabras...

Ubuntu, el niño tonto de Linux

13 mar 2012

Usar kernel 3.2 en CentOS - Scientific Linux - RHEL || Use Linux Kernel 3.2 on CentOS - Scientific Linux - RHEL

Spanish version

Primer Paso: Instalar el repositorio elrepo desde la web http://elrepo.org/tiki/tiki-index.php

Por defecto, RHEL y sus clones, vienen con el kernel 2.6.32.x de soporte extendido, el cual se va parcheando, mediante la tecnica de backporting.
Muchos usan, como yo, un clon de RHEL para desktop, y a veces, en ciertas cuestiones, es mejor tener un kernel 3.2 en el sistema.
Para esto, vamos a usar un repositorio, llamado elrepo.repo.

Abrimos un terminal, y editamos /etc/yum.repos.d/elrepo.repo

### Name: ELRepo.org Community Enterprise Linux Repository for el6
### URL: http://elrepo.org/
[elrepo]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/elrepo/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
piority=4

[elrepo-testing]
name=ELRepo.org Community Enterprise Linux Testing Repository - el6
baseurl=http://elrepo.org/linux/testing/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-testing.el6
enabled=0
gpgcheck=1
priority=4
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el6
baseurl=http://elrepo.org/linux/kernel/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=1
priority=2
[elrepo-extras]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/extras/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-extras.el6
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
priority=4
[synflag@darkstar ~]$ cat /etc/yum.repos.d/elrepo.repo 
### Name: ELRepo.org Community Enterprise Linux Repository for el6
### URL: http://elrepo.org/

[elrepo]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/elrepo/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
piority=4

[elrepo-testing]
name=ELRepo.org Community Enterprise Linux Testing Repository - el6
baseurl=http://elrepo.org/linux/testing/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-testing.el6
enabled=0
gpgcheck=1
priority=4
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el6
baseurl=http://elrepo.org/linux/kernel/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=1
priority=2
[elrepo-extras]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/extras/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-extras.el6
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
priority=4

Como se puede ver, elrepo-kernel esta activado, ahora, solo debemos hacer:

# yum install kernel-ml

Esto instalará el kernel 3.2 o superior, dado que ese repo siempre tiene el ultimo kernel compilado en RPM

Eso es todo!
Nota: El repositorio, debe instalarse desde su web, luego activar elrepo-kernel



English Version

First Step: Install elrepo repository from web site http://elrepo.org/tiki/tiki-index.php

By default, RHEL and their clones come with the kernel 2.6.32.x with extended support, which is patched through the technique of backporting.
Many people use, like me, a clone of RHEL as Desktop, and sometimes, in certain matters, it is better to have a 3.2 kernel.
For this, we use a repository, called elrepo.repo.

Open a terminal, and edit /etc/yum.repos.d/elrepo.repo

### Name: ELRepo.org Community Enterprise Linux Repository for el6
### URL: http://elrepo.org/
[elrepo]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/elrepo/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
piority=4

[elrepo-testing]
name=ELRepo.org Community Enterprise Linux Testing Repository - el6
baseurl=http://elrepo.org/linux/testing/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-testing.el6
enabled=0
gpgcheck=1
priority=4
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el6
baseurl=http://elrepo.org/linux/kernel/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=1
priority=2
[elrepo-extras]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/extras/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-extras.el6
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
priority=4
[synflag@darkstar ~]$ cat /etc/yum.repos.d/elrepo.repo 
### Name: ELRepo.org Community Enterprise Linux Repository for el6
### URL: http://elrepo.org/

[elrepo]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/elrepo/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
piority=4

[elrepo-testing]
name=ELRepo.org Community Enterprise Linux Testing Repository - el6
baseurl=http://elrepo.org/linux/testing/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-testing.el6
enabled=0
gpgcheck=1
priority=4
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el6
baseurl=http://elrepo.org/linux/kernel/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el6
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=1
priority=2
[elrepo-extras]
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/extras/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-extras.el6
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
priority=4

If you can see, the elrepo.repo repo, is enabled, then, after enable the elrepo-kernel item:

# yum install kernel-ml

This will install the last stable Linux Kernel.
That's all.
Note: The repo must be installed from the elrepo web site

Instalar LibreOffice 3.5 en Fedora - CentOS 6.2 - Scientific Linux 6.2 - RHEL6.2 | Install LibreOffice 3.5 on Fedora - CentOS 6.2 - Scientific Linux 6.2 - RHEL 6.2

Spanish Version

Hace algunos dias, al intentar abrir un archivo .xls de 40mb con OpenOffice, me di cuenta de que este se colgaba. Instalé Gnumeric, y lo abrio sin problemas, pero no mostraba las funciones del .xls, creado con MS-Office 2007.
Instalé LibreOffice 3.5, abre el documento, y tiene todas las funciones, asi que, voy a compartir el procedimiento con ustedes.

Nota: "user" es igual a la carpeta de usuario que posean

Paso a paso:

0.- Abra una terminal, como xterm, gnome-terminal, urxvt, konsole, ROXterm, etc
1.- cd /home/user/
2.- mkdir libreoffice
3.- cd libreoffice
4.- wget -c http://download.documentfoundation.org/libreoffice/stable/3.5.0/rpm/x86/LibO_3.5.0_Linux_x86_install-rpm_en-US.tar.gz http://download.documentfoundation.org/libreoffice/stable/3.5.0/rpm/x86/LibO_3.5.0_Linux_x86_langpack-rpm_es.tar.gz http://download.documentfoundation.org/libreoffice/stable/3.5.0/rpm/x86/LibO_3.5.0_Linux_x86_helppack-rpm_es.tar.gz

5.- tar zxvf LibO_3.5.0_Linux_x86_install-rpm_en-US.tar.gz
     tar zxvf LibO_3.5.0_Linux_x86_langpack-rpm_es.tar.gz
     tar zxvf LibO_3.5.0_Linux_x86_helppack-rpm_es.tar.gz

6.- cd LibO_3.5.0rc3_Linux_x86_install-rpm_en-US/RPMS/
7.- su -c 'rpm -Uvh *.rpm && cd /home/user/libreoffice'
8.- cd LibO_3.5.0rc3_Linux_x86_langpack-rpm_es/RPMS/
9.- su -c 'rpm -Uvh *.rpm && cd /home/user/libreoffice'
10.- cd LibO_3.5.0rc3_Linux_x86_helppack-rpm_es/RPMS/
11.- su -c 'rpm -Uvh *.rpm && cd /home/user/libreoffice/
12.- cd LibO_3.5.0rc3_Linux_x86_install-rpm_en-US/RPMS/desktop-integration/
13.- su -c 'rpm -ivh libreoffice3.5-freedesktop-menus-3.5-13.noarch.rpm && cd /home/user'

Eso es todo, ahora tienen instalado LibreOffice 3.5 en español, espero lo disfruten!


English Version

A few days ago, trying to open a .xls file of 40mb with OpenOffice, I realized that this was hung. Gnumeric installed and opened it without problems, but no functions showed (MS-Office). xls file created with MS-Office 2007.
I installed LibreOffice 3.5, open the document, and has all the functions, so, I will share with you the procedure.
Note: "user" is the folder of the user, for example /home/kevin/

Step by Step:


0.- Open a terminal, like xterm, gnome-terminal, urxvt, konsole, ROXterm, etc
1.- cd /home/user/
2.- mkdir libreoffice
3.- cd libreoffice
4.- wget -c http://download.documentfoundation.org/libreoffice/stable/3.5.0/rpm/x86/LibO_3.5.0_Linux_x86_install-rpm_en-US.tar.gz
5.- tar zxvf LibO_3.5.0_Linux_x86_install-rpm_en-US.tar.gz
6.- cd LibO_3.5.0rc3_Linux_x86_install-rpm_en-US/RPMS/
7.- su -c 'rpm -Uvh *.rpm && cd /home/user/libreoffice'
8.- cd LibO_3.5.0rc3_Linux_x86_install-rpm_en-US/RPMS/desktop-integration/
13.- su -c 'rpm -ivh libreoffice3.5-freedesktop-menus-3.5-13.noarch.rpm && cd /home/user'

That's it, now you have installed LibreOffice 3.5, I hope you enjoy!



12 mar 2012

VLC 2.0 is Out | Fedora - RHEL - CentOS - Scientific Linux

Ya está disponible VLC 2.0 para Linux.
Soluciona muchos problemas, leer aca:

# Core:
* Major Video Core and Outputs rework and rewrite:
- Subtitles, subpictures and OSD can now be sized and blent inside outputs
- x11 (Unix), OpenGL (Unix) and Direct3D (Windows) are such video outputs.
* Almost every video filter can now be transcoded
* Playback rate doesn't get resetted to 1 between items anymore
* Option --sub-filter was renamed --sub-source
* Port to Android, iOS, OS/2 and Win64.
# Access:
* Multiple files are now supported inside RAR files
* Experimental support for ClearQam devices in the BDA/DTV module
* DVB-S scanning support on Unix
* DVB-C scanning on Unix scans correct modulation/symbolrate if needed
* Support for freq and video standard selection in DirectShow
* Support for VDR recordings (http://www.tvdr.de/) folders
* Experimental Blu-Ray Discs support using libbluray
* HTTP Live Streaming (IETF draft) playback support
* Blackmagic DeckLink SDI cards input support (Linux only currently)
* Linear Systems (HD-)SDI cards input support (Linux)
* PulseAudio audio input support
* Support for RTP dynamic payload types by specifying the payload format in an option (no autodetection): only Theora supported for now
* Basic HTCPCP implementation for Coffee Pot control
* Support for all QTKit-compatible video input devices, aka QTCapture
* Support for all QTKit-compatible audio input devices, aka QTSound
* Support for capturing partially hidden windows in the X11 Screen input
* MPEG DASH (Dynamic Adaptive Streaming over HTTP) support
* Support for HTTPS is now fixed in the Windows port
# Codecs:
* One can now use ffmpeg-mt in conjunction with vlc, to split decoding load on multiple cores. H.264, VP3, VP8, JPEG-2000, Mpeg-4 ASP/DivX and RV3/RV4 are notably concerned.
* Important fixes for RealVideo 3.0 and 4.0 playback, notably in MKV
* Experimental Hardware decoding using Broadcom CrystalHD cards
* New module for decoding EBU subtitles (.stl)
* Support for 9bits and 10bits H.264/AVC decoding
* Support for 20-bits PCM and DAT-12 (digital magnetic tapes) from RTP
* New module for Dirac encoding, using the faster libschroedinger The Schroedinger module should be prefered to the Dirac one
* Support for WMV Images, aka WMVP and WVP2, as used by Photo Story
* Support for Lagarith Lossless video codec
* Support for ProRes 422 video codec in 10bits
* Support for DNxHD (VC-3) and JPEG-2000 in 10bits
* EIA-608 closed captions improvements
* Support for JPEG-2000 and Motion JPEG-2000 in the Windows and Mac binaries
* Experimental support of IOMX for OpenMAX IL codecs on Android
* One can use "mp2 " fourcc to encode in mpeg1/2 layer 2
# Demuxers:
* New images demuxer supporting jpeg, png, targa, xcf, git, tiff, bmp, pcx, lbm
* C64 SID file playback support of using sidplay2
* Support for images/cover art in wma/wmv/asf files
* Improvements in .ape files metadata reading and writing
* New demuxer module for EBU subtitles (.stl)
* Support for caf, mtv, awb, f4v, amr, vro (DVD-VR) files
* Ogg, flv, mxf, amr seeking improvements
* Major improvements in Matroska (mkv) chapters/segments handling and seeking
* Support for duration and better seeking in Mpeg-TS files (.ts, .m2ts, .mts)
* Mov improvements, notably for aspect-ratio handling and Audio DV tracks
* Improved support of tracker files
* Real Media (.rm and .rmvb) demuxer is now based on libavformat
# Interfaces:
* Qt: effects dialogs rework
* Qt: new CoverFlow-like view of the playlist
* Qt: port to MacOS X platform
* Qt: various interface improvements, notably on the seek bar
* Skins2 / Qt: misc improvements and usability fixes
* Skins2: fullscreen controller support, relative placement support and important cleanups and optimisations
* Mac OS X: re-written Main Window, which also includes the Video Windows It is available in 2 looks, one grey (Lion style) and one black (QTX style)
* Mac OS X: new Audio Effects panel adding Compressor and Spatializer filters
* Mac OS X: new Track Synchronization panel
* Mac OS X: new Video Effects panel for color and geometry adjustments
* Mac OS X: re-written Open Disc functionality with automatic media detection
* Mac OS X: support for the native fullscreen mode on OS X Lion
* Mac OS X: enhanced AppleScript support
* Mac OS X: support for lua extensions
* The rc and telnet lua interfaces were merged into a new "cli" interface
* lua: the recommended way to run custom interface scripts is now to pass -I luaintf --lua-intf myscript
* ncurses: heavy refactor of the complete interface
* dbus: Upgrade to an mpris2 compliant interface, see http://www.mpris.org
* dbus: Rewrite of the main loop to use a more efficient poll-based model
* webUI/http: Rewrite of the web interface, using jQuery
* webUI/http: some requests are now supported in JSON in addition to XML
* webUI/http: path values for input and output are deprecated in favour of uri
* Qt/Win32: the update system now downloads the updates in the temp folder
* Qt: preferences are now searchable
* Qt: the fullscreen controller is now stackable, full-width, at the bottom
# Video Output:
* New video output based on Direct2D for Windows 7 and Vista (with Platform Update)
* New video output for iOS platform
* Experimental work in progress on a video output using EGL
* Adaptation of the OpenGL layer for OpenGL ES 1.1
* Various vmem improvements
* OpenGL video output now accepts YUV as input and uses fragment programs for chroma conversion between YUV and RGB
* New video output for Android platform, based on Surface
* Support for 9/10bits output in the OpenGL output
* Updated OpenGL video output for Mac, requires a Quartz Extreme capable machine
* New video output based on kva API for OS/2
# Audio Output and Filters:
* New audio output based on AudioQueue API for iOS
* New audio output in memory (amem)
* Important simplification and improvements in the core audio output
* New audio output based on OpenSL ES API for Android
* New audio resampler using Speex (DSP)
* New audio resampler using the Secret Rabbit Code (a.k.a. libsamplerate)
* New Compressor filter, a dynamic range compressor
* New simplistic Karaoke filter
* New audio output based on kai API for OS/2
* Automatic handover from S/PDIF to PCM with PulseAudio 1.0
# Video Filter:
* New gradfun filter for debanding videos using dithering
* Rewrite of the grain filter, faster and with better quality
* New posterize filter for lowering the number of colors
* Atmo ambilight: improve Fnordlicht support up to 254 channels
* New sepia filter for creating sepia effect in videos
* New deinterlacer mode Phosphor, a framerate doubling CRT TV simulator
* New deinterlacer mode IVTC, to do live inverse telecine for NTSC films
* New subsdelay filter to change subtitles delay
* New anti-flickering filter
* New OpenMAX DL IPCS filter for color space conversion and resizing
* New video filter for denoising, based on the famous hqdn3d filter
* Major improvements in the freetype text-rendering module, notably supporting blackbox and customizable shadow.
NB: The freetype module is now used by default on the Mac OS X instead of the quartztext module, which can still be enabled manually. The Win32 font selection was improved too.
# Stream output:
* New livehttp-module for HTTP Live Streaming (IETF draft) output example: vlc inputfile :sout="#transcode{vcodec=h264,acodec=mp3, venc=x264{profile=baseline},width=320,vb=256,ab=96}:std{access=livehttp{index=public_html/iphonestream.m3u8,index-url=http://url-to-iphonestreamfile-###.ts},mux=ts{use-key-frames},dst=public_html/iphonestreamfile-###.ts}"
* Support for Vorbis and Theora in RTP
* Major rework of VoD support
* New delay module, to introduce delays of one ES, when streaming: #delay{id=12,delay=500}:standard...
* New setlang, setid modules to change lang or id of one ES, when streaming: #setid{id=12,new-id=42}:std...
* New langfromtelx module, to change lang of one ES, when streaming, based on a telextex page: #langfromtelx{id=12,magazine=7,page=0x99,row=1}:std...
* New select module, to replace an existing ES with another ES in the same track #duplicate{dst=bridge-out{id=1},select=video,dst=bridge-out{id=0xa3},select=audio} #transcode{...}:bridge-in{id-offset=0}:select{disable=0}:setid{id=0,newid=0xa3}:autodel:std{...}
* New libavformat/avio access_output module for network streaming
# Services Discovery:
* Search API to be able to query distant search APIs from the interfaces
* Upnp module was ported to Win32
# libVLC:
* New capabilities for libVLC:
- libvlc_media_player_navigate for DVD navigation
- libvlc_audio_filter_list_get, libvlc_video_filter_list_get to get the list of available audio and video filters
- libvlc_audio_set_format, libvlc_audio_set_format_callbacks,libvlc_audio_set_callbacks allow grabbing audio data from a chosen memory location in real-time.
# Removed modules:
* asademux, subsass: use libass
* fake, invmem: use the new image demuxers
* hal, v4l, gapi, omapfb, hd1000a, hd1000v: obsolete unmaintained modules
* id3tag: use taglib
* upnp: use upnp_intel
* removal of old telnet interface in favor of the new lua CLI
* removal of http interface in favor of luahttp
* removal of the noise filter
* removal of the SDL audio output, use the native outputs
* growl_udp: use Growl for local notifications on the Mac. UDP support will be removed in Growl's next release, too.
* removal of the OSSO screensave module, use the MCE one
# Translations:
* Update of translations for most languages.
* New Telugu and Kurmanji translations.


Pero el mas destacado, es la solución al sonido de fritura o entre-cortado con placas HDA-Intel y pulseaudio, ademas, de que ya no produce esa reproducción entrecortada, como trabada, con archivos RMVB.
Está disponible tanto para Fedora como para RHEL6 clones

Yum Update Error => Requires: libvpx.so.1 | CentOS - Scientific Linux

Hace unos dias (3), encontré un error, al intentar actualizar mi SL6.2.
Pese a buscar y buscar, encontre que no era un problema mio, sino de CentOS, el clon 100% compatible a nivel binario con RHEL.
El problema radica, en que la actualizacion de Audacious, implica un paquete que esta en el repo ATRPMS-TESTING, pero lo requiere desde STABLE (error de empaquetado, si).
Es un error de empaquetado, en la lista de mail, aun estan debatiendo sobre el tema, pero yo les traigo aquí la solucion. http://www.gossamer-threads.com/lists/atrpms/users/15930

El problema es el siguiente, libvpx pertenece al repo SL, o CentOS, y es parte del sistema base (RHEL), lo cual implica que no puede ni debe ser reemplazado.
Ahora bien, esta libreria, es el codec libre de reproduccion de VP8, con lo cual, no es un componente crítico, y si puede ser reemplazado. Nunca reemplazen un kernel o glibc con tanta ligereza!!.

Pasos a seguir para arreglar esto:

1.- Instalar yum priorities plugin
2.- Colocar prioridad "3" al repo RPMFORGE
3.- Colocar prioridad "2" al repo ATRPMS
4.- Activar el repo ATRPMS-TESTING con prioridad 4

Luego de esto, haremos:

# rpm -ev --nodeps libvpx gstreamer-plugins-bad-free gstreamer-plugins-bad
# yum remove ffmpeg vlc mplayer

Instalamos a mano la libreria que nos pide, la cual es:

libvpx-1.0.0-1.el6.i686 (si es de 64 bit, seria libvpx-1.0.0-1.el6.x86_64)

i686: ftp://ftp.pbone.net/mirror/atrpms.net/el6-i386/atrpms/testing/libvpx-1.0.0-1.el6.i686.rpm
x86_64: ftp://ftp.pbone.net/mirror/atrpms.net/el6-x86_64/atrpms/testing/libvpx-1.0.0-1.el6.x86_64.rpm

Hacemos wget -c con el RPM que corresponda según la arquitectura, y luego:

# rpm -Uhv --nodeps libvpx*

Luego:

# yum update

Actualizará muchas cosas, dado que ATRPMS posee cosas mas nuevas que RPMFORGE en cuanto a multimedia se refiere, incluso, VLC 2.0

Luego:

# yum install audacious ffmpeg mplayer vlc gstreamer-plugins-bad-free

Eso es todo!.

Porque sucedio esto?, facil, la nueva version de ffmpeg requiere la libreria libvpx version 1.x. En la lista de ATRPMS se discute si realmente RHEL6.2 necesita algo tan nuevo, total... es RHEL, no Fedora, y la respuesta, mia, es SI, dado que es un componente no critico, el nuevo ffmpeg trae muchas mejoras, y se empaqueto asi, dado que Fedora 15 y 16 ya lo estan usando con exito.
Mi consejo es que mantengan el repo RPMFORGE en prioridad 3, y ATRPMS en 2, dado que la mayoria de las cosas que usamos los usuarios de RHEL como desktop para multimedia, viene de RPMFORGE, pero las cosas mas nuevas, las tiene ATRPMS.

Espero les haya servido
Saludos!

4 mar 2012

UsrMove, La mentira y Error || UsrMove, the Lie and Mistake

Nota: Proximamente version en ingles, no quiero que Lennart se pierda esto



UsrMove, la mentira

Muy a mi pesar, es que hago este post. Digo esto, basicamente, porque no me gusta criticar la distro que uso y apoyo sus decisiones, pero en esta ocasion, debo hacer una crítica constructiva a la misma, asi como dar mi punto de vista sobre la gran mentira del verdadero motivo de usrmove. Para los que dijeron que no era objetivo, o era un fanboy, bueno, hasta aqui llego su fundamento.

Si no se dieron cuenta, si, estoy hablando de Fedora, mas precisamente, Fedora 17 que aun no sale, pero ya tienen un Alpha disponible.

Existe algo llamado vulgarmente «usrmove», que es uno de los «features» de F17, y consiste en mover /bin /sbin /lib /lib64 dentro de /usr/bin /usr/sbin /usr/lib /usr/lib64. O sea, todo lo que está historicamente en /, meterlo en /usr.

En esta entrada, explica desde mi punto de vista, porque esto no debe hacerse, y los motivos reales por los cuales creo que harán esto.

Primeramente, deberian leer, este documento que está en ingles en_US
http://fedoraproject.org/wiki/Features/UsrMove

Antes que nada, voy a pedir que lean bien las referencias de la wiki, asi como los motivos, aunque yo traduciré los importantes y los pondré aquí.

«Benefit to Fedora
--Simpler and cleaner overall file system layout, with full compatibility.
--Clear separation of operating system and host specific resources.
--Improve compatibility with other Unixes/linux, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work. All binaries will be available on both /usr and / thus minimizing compatibility problems.
--Improve compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place
--Minimize difference to other Unixes, such as Solaris, which already did the same move
--Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication»


Traduccion y Respuesta


«Beneficios para Fedora:


* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.»

Analizemos estos items uno a uno, y recordemos el nivel de importancia que conlleva cada punto, porque luego lo compararemos con la carga de trabajo que implica este cambio, y las contras.


* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
Realidad: La disposicion del sistema de archivos actual, es acorde al FHS standard. Es el mismo usado por NetBSD, FreeBSD y OpenBSD, los Unixes mas puros, y el ultimo, el mas seguro.

Limpia?, que tiene de limpio mezclar el «core» del sistema (/bin) con los archivos instalados por el usuario para sus aplicaciones?. La compatibilidad completa ya existe, los Linux y Unix mas conocidos usan este FHS Standard. Linus Torvalds tomo esta jerarquia de archivos de Minix, el cual es un OS basado en BSD, con fines educativos, por tanto, se podria decir que Linux, es Unix-Like.



* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
Realidad: La clara separacion, radica en que el «core» del sistema, se encuenta en / y las cosas del host o usuario en /usr, con la replicacion de los binarios importantes, como si de un chroot se tratase.


* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
Realidad: El unico Unix-like que usa este sistema es Solaris 11, acaso Fedora usa muchas cosas de Solaris 11?. Ni siquiera plan9 utiliza usrmove.

No existe confusion alguna en «donde se instalaran las herramientas» actualmente, justamente, por el motivo de que el actual FHS de Linux, es un standard identico a UNIX, y que siguen el resto de las distro GNU/Linux. Actualmente todos los PATH a un binario funcionan, solo que no es lo mismo /usr/local/bin que /bin, entienden el porque, no es verdad?, el primero es del o los usuarios, y el segundo de «rootfs».


Mentira!, todos los binarios no estarán disponibles en / como en /usr, ayer mismo me tome el trabajo de iniciar un Fedora 17, que segun se indica esto ya esta al 100% completo, y no existe UN solo binario en /, sino symlink hacia /usr. Porque mienten?.


* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
Realidad: Actualmente se usa GNU autotools y no hay problema alguno con / y /usr.


*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.
Realidad: No son mayormente read-only, y si inician un Fedora 17, veran que no esta montado en read-only, esto no es real. Aligerar en que?, en la no duplicacion de unos, 20mb?, creo que actualmente, eso no es problema, quiza lo era en el año 1993, hoy en dia, los discos rigidos y unidad de backup son mucho mas baratas.




Como pudieron leer hasta aqui, lo unico que se pueden ver, son excusas, asi es señores, son excusas, no veo un beneficio claro, pero en contraposicion, veo una horrenda asquerosidad, rompiendo el FHS Standard, y el mismo FHS que usan los Unixes. No sabia que los Unixes eran solo Solaris 11, que bueno saberlo, ire a modificar la wikipedia - sacarsmo on -



Aqui va la otra parte de los "motivos"

«Scope
--The ability to share /usr is especially useful for clusters and virtual machines.
--The ability to mount /usr read-only (e.g. on read-only media) can add to the security of the machine.
--The entire /usr can safely be snapshotted during upgrades.»


Traduccion y Respuesta


«* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
* El completo /usr puede ser snapshotted de forma segura durante upgrades»


Respuesta a las mentiras


* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
Realidad: Actualmente, los cluster no tienen el mas minimo inconveniente en compartir /usr, y tampoco las maquinas virtuales, por algo /bin y /sbin estan replicados dentro de el.


* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
Realidad: No lo hace, actualmente, se podia montar / y /usr por separado, como uno quisiera, sin perder el «core» del sistema, pero claro, systemd tiene problemas con ello, Ups!, se me escapó!.


* El completo /usr puede ser snapshotted de forma segura durante upgrades
Realidad: Actualmente el /usr tambien puede hacer eso


Como ven, otra vez, excusas y problemas irreales a cosas que no existen.


Trabajo a realizar por este cambio

Debido  a este cambio, deberán rediseñar el sistema de construccion de RPM, el archivo .spec, y hacer algunos hacks, para que los empaquetadores construyan RPM's que se acomoden a le jerarquia de directorios propuesta.
Modificar el metodo de construccion en Koji, el servidor build-system de Fedora.
Cruzar los dedos para que aplicaciones antiguas al ser compiladas usando make, funcionen.
Reescribir los documentos sobre construccion de RPM's
Ignorar todo PDF o guia de construccion de RPM que hayan aprendido (si, ustedes los usuarios)
Modificar YUM, el package manager de Fedora
Recompilar los RPM de Fedora 17


Mitos y verdades

Siguiendo con el analisis, a esta altura, se preguntaran, entonces, porque van a mentir y poner excusas irreales solo para hacer ese cambio?, bueno, antes de responder eso, debo mostrar algunas cosas mas, no dejen de leer y entender.

Uno de los link de referencia de la wiki de Fedora «usrmove», hace referencia a la wiki de openSUSE, donde en un apartado, explica el como y porque del cambio, algo que ellos tambien tienen en mente. Solo que esta mejor explicado y cita una fuente, de una lista de mail de BusyBox, donde un developer, explica el porque el spliteo de /bin /sbin /usr/bin /usr/sbin y asi, os dejo el link aqui mismo:

Link de openSUSE: http://en.opensuse.org/openSUSE:Usr_merge

Link al que refiere openSUSE y explica el porque: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html


Basicamente, y en resumidas cuentas, la explicacion del developer, dice que la situacion fue esta:


«En la epoca que Ken Thompson y Dennis Ritchie crearon UNIX, las unidades de disco, eran costosas y pequeñas, de tan solo 1.5MB, por lo cual, cuando terminaron de crear el sistema, este cabia en un disco entero, pero solo hasta el /, para continuar con los archivos de usuario, debieron atachar otro disco de 1.5MB, y crearon el /usr, con la replica de contenidos del primer disco.

Luego fue creado el /home de forma intencional, pero, segun la explicacion, si Dennis y Ken hubieran tenidos discos como los de hoy en dia, hubieran metido todo dentro de un solo /usr.

Segun la explicacion, durante años, se siguio tomando el mismo modelo, por cuestiones burocraticas, y nadie se cuestiono el porque de este spliteo, asi como tampoco se lo cuestiono la Linux Foundation, la cual tiene en mayoria, voz y voto sobre el FHS Standard.

Segun lo que dice, al dia de la fecha, no tiene sentido alguno este spliteo, que solo proviene de cuestiones historicas y burocraticas. Luego, AT&T y otros, encontraron excusas a esto, como que el core del sistema estaria en / y el resto que el cliente elija instalar, en /usr»


Esta es la famosa explicacion corta, que nadie explica realmente, sobre la «cuestion historica» del spliteo

Errores que provocará

Gracias al encargado del proyecto, por citar la discusion en debian-devel.
Lei toda la discusion, y pude observar que el 80% de las personas no estan de acuerdo, y comentan algo que nadie dijo, ni tampoco pensé.
Al meter un initramfs dentro del kernel, mas el firmware en /boot, aumentará el tamaño del kernel, asi como la cantidad de espacio necesario en /boot.
Esto no supone un problema en PC x86, pero en sistemas embebidos ARM, donde el espacio es a veces de solo 8MB, el tamaño de /boot es importante. Algunos dirán, pero /boot puede estar bajo /, sin separarse, y yo les contesto, que si uno decide encriptar un filesystem, es requerido que /boot esté en una particion separada.
Según el comentario de uno de los developer de Debian, esto es una estrategia de negocio, al menos asi lo supone el, en la cual, RedHat, tendrá mas pedidos de soporte, en clientes con estas limitaciones de espacio en sistemas ARM, asi que, probablemente, si se traslade a RedHat.


Errores en la historia y verdades


1) El pack de discos mencionado, no era de 1.5MB sino de 2.5MB, craso error, algo huele mal, no?

2) Alguna vez, Ken o Dennis dijeron eso?, no que yo sepa, entonces, como es que afirman algo sobre hipotesis y no sobre hechos reales?

3) La mayoria de los inventos y descubrimientos fueron por accidente. Y si realmente esto fue asi y luego si se le encontro utilidad a este spliteo y por eso se conserva?


Actualmente, HP-UX, OpenBSD, FreeBSD, NetBSD, IRIX, AIX, usan / y /usr, siendo estos, los mas puros UNIX que aun sobreviven, y siendo Linux, Unix-Like, creo que esta bien que copie la jerarquia del sistema de archivos de sus abuelos.

Tomo como referencia, una captura de pantalla que realice en un OpenBSD5, instalado por mi, en VirtualBox, en el cual se ve, el kernel, la existencia de /bin /sbin /lib, y el resto de directorios.

Ahora, los invito a la reflexion. Un tipo como Theo de Raadt, el cual ha insultado a Torvalds, a los Core2Duo de Intel, y dice lo que piensa, incluso eso le causo la perdida de donaciones de parte de US, creen que si el viera algo mal o que se pudiera mejorar, no lo habria hecho?, solo piensen eso


OpenBSD 5.0 corriendo


Notese la existencia de /bin /sbin /lib


Para continuar con las incongruencias, tenemos a freedesktop.org, donde comentan en sus «fact», que el UNIX original, tenia un /bin, si, pero era SOLO un symblink hacia /usr.

Referencia: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Myth #6: A split /usr is Unix “standard”, and a merged /usr would be Linux-specific


Fact: On SysV Unix /bin traditionally has been a symlink to /usr/bin. A non-symlinked version of that directory is specific to non-SysV Unix and Linux.

Por si no lo notaron, esto es una mentira, no solo por la prueba real de algun UNIX que este corriendo en alguna casa o empresa, sino por el hecho, de que Dennis y Ken, contenian en / todas las herramientas necesarias para poder montar el segundo disco que contenia /usr, por tanto, si /bin es solo un symlink, como dice freedesktop, como es que montaba el segundo disco?, recuerden que un symlink, es un link simbolico a una ruta o destino real, pero si el disco no esta montado, como puede ser esto real?, wow, ahora si que metieron la pata con sus mentiras no es verdad?, claro que si.

Tomando en cuenta el error al mentir, en el articulo freedesktop, la explicacion sin la palabra de Dennis o Ken del developer de BusyBox, asi como las excusas falsas de Fedora, y si leen mas abajo, la evasion constante en las FAQ, todo me lleva a pensar que esto es por algo que aun nadie nos dice.

Aunque el «owner» en la wiki de Fedora, es Harald Hoyer, un empleado de RedHat, el iniciador de este cambio, y la idea principal, fue del creador de systemd, el mismo creador de pulseaudio (si, esa basura), el fantastico Lennart Poettering, adivinaron!, el chico maravilla.


Como habrán visto, systemd tiene problemas con / y /usr, y seguramente, cuando fue programado y pensado, Lennart, asumio que todo el mundo seguia el esquema de particionado sugerido por Anaconda, el instalador de Fedora, pero seguro comenzo a ver bug report en bugzilla, acerca de informes de error, en sistemas instalados con / y /usr por separado.


La gran estafa

Ahora, pensemos, que es más facil?, arreglar systemd; que quiza no se pueda, y reconocer que lo que se coloco en Fedora 15 y 16 esta mal y tiene un bug enorme, utilizado para reemplazar Upstart. Liberar Fedora 17 con Upstart de nuevo?, o con init en el peor de los casos, o mover todo a /usr para arreglar el bug de systemd?. Cubrir a Lennart, y quedar bien con todos?, yo me inclino a pensar, quiza me equivoque, que el motivo de «usrmove» es ese, cubrir el error de Lennart.

Segun dice la wiki de Fedora, estará presente en RHEL7, realmente, lo dudo y me rio en sus caras (a menos que quieran perder clientes), dado que un bien sysadmin, con LPI y demas certificados, no va a permitir que conviertan su Unix-Like en un Windows-Like.

Segun el encargado de «usrmove», para reemplazar lo que habia en /, se creara un initramfs de mas tamaño, que contenga los comandos basicos para recuperar un sistema, o bootear en modo monousuario, y solo necesitar el / (algo que si hago y creo que muchos hacen para tareas administrativas).

Y el mismo estaria contenido en /boot. La explicacion de esto, es que conservar / para reparar /usr en caso de corrupcion, no tiene sentido, dado que dependemos de /boot para el inicio y /, con lo cual, es mas optimo (esto si lo comparto), que todo este en /boot, donde vive el kernel, para poder asi reparar / y /usr o lo que fuera, con un initramfs engordado que contenga los comandos que estan en /bin y /sbin. Mi pregunta es, que pasa con las updates que actualizan algunos de esos comandos?, ahora debera actualizar un initramfs?, que debe ser compatible claro, con el kernel del sistema, a la larga, este modelo, va a ser mas complejo.

Desde mi punto de vista, seria mejor un initramfs con los modulos necesarios para montar y cargar binarios de /boot/system por ejemplo, donde se alojen los binarios que ahora se encuentran en /bin y /sbin. Algo mas parecido a GoboLinux.

Mas pruebas de que este cambio se debe a un Bug en Systemd

Los que entienden algo de ingles, no van a tener problema, los que no, usen Google Translate, dado que es ingles técnico mas que nada y facil de traducir.
Lo que van a leer ahora, es la confirmacion, por parte de la misma gente de Fedora en sus listas de mail, de que el cambio se debe a un Bug en systemd. Por ese motivo, las distros que adoptaron systemd, deben cambiar tambien (openSUSE), y las que no (Debian, Arch), pueden optar. Debian por el momento, decide que es mala idea, y la wiki de ArchLinux, aclara que NO se debe usar / y /usr en caso de usarse systemd, al menos no mueven todo, no?.
Lo que dicen los mail, basicamente, es que es una excusa rara y estupida, tener mas compatibilidad con Solaris 11, si es una broma, y Lennart, contesta ironicamente, que su idea es llegar a C:\Programas files\
Realmente, es muy decepcionante ver esto, mails de Fedora-Devel

http://lists.fedoraproject.org/pipermail/devel/2012-January/161823.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161833.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161817.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161781.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161788.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161789.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161801.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161832.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161856.html

-----------------------------------------------------------------------------------------------------------
On Fri, Jan 27, 2012 at 7:43 PM, Jef Spaleta <jspaleta at gmail.com> wrote:
> If you haven't read the new summary write-up on the benefits of the
> /user feature that I think you would benefit from reading it.
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> If you have read it, then I fear you either don't fully understand or
> do not value the long term benefits associated with the filesystem
> snapshotting nor the utility of having read-only shared vendor
> supplied /usr across many guest instances.

Apart from fixing things that are not a problem[1], the
stateless/snapshotting benefits are, AFAIK, just vaporware promises.
I can't see they can work as stated because /etc and /var are quite
strongly bound to the details of contents of the newly proposed /usr -
and these objections were raised back when FESCo first discussed this
feature.

Actually getting a stateless system would require first defining what
is "state" and what is "OS" (and that question will have several
different answers, for good reasons!), and then doing the actual work
of separating the two.  We already have a readonly-root facility in
initscripts, and I think that one is doing it right - giving the
people that want to use these (non-default, comparatively rarely-used
and site-specific) features the power to create a stateless system
without burdening the most common users with it.
    Mirek

[1] Improved compatibility with Solaris - Seriously? We didn't need
that level of compatibility back when Linux was a small niche, why
would we care now? I feel mildly insulted by that argument.

------------------------------------------------------------------------------------------------
On 01/28/2012 10:47 AM, Miloslav Trmač wrote:
>
> [1] Improved compatibility with Solaris - Seriously? We didn't need
> that level of compatibility back when Linux was a small niche, why
> would we care now?

> I feel mildly insulted by that argument.
Why stop with Solaris compatibility and not mimick Windows?
No /usr, no /bin => /redhat. Seems to be the spirit behind all this.
 
Ralf
-----------------------------------------------------------------------------------------------
On Sat, 28.01.12 11:29, Ralf Corsepius (rc040203 at freenet.de) wrote:

> On 01/28/2012 10:47 AM, Miloslav Trmač wrote:
> >
> >[1] Improved compatibility with Solaris - Seriously? We didn't need
> >that level of compatibility back when Linux was a small niche, why
> >would we care now?
> 
> >I feel mildly insulted by that argument.
> Why stop with Solaris compatibility and not mimick Windows?
> No /usr, no /bin => /redhat. Seems to be the spirit behind all this.

Actually we originally wanted to rename "/usr" to "C:\PROGA~1\" but we
feared FESCO might not agree to that, on grounds that backslashes might
be too hard to type on the shell prompt! But we'll propose that for F18,
OK?

Lennart

--  
Lennart Poettering - Red Hat, Inc.
------------------------------------------------------------------------------------------------
2012/1/28 Ralf Corsepius <rc040203 at freenet.de>:
>
> Why stop with Solaris compatibility and not mimick Windows?
> No /usr, no /bin => /redhat. Seems to be the spirit behind all this.
>
> Ralf
>

The rhetoric spoils the argument. Various people inside of Red Hat are
either for this, against this, wanting to see where the train wreck
will end, thinking this is the greatest innovation since Unix, etc.
All the rhetoric does is cause people (inside and outside of Red Hat)
to rally more around that idea no matter how silly than allow the idea
to be looked at, valued for its merits and then discarded or kept.

I would like to think that after 8 years of this same argument, and
its ineffectiveness it would time to do something else.



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I 
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
---------------------------------------------------------------------------------------------
On 01/27/2012 06:33 PM, Bill Nottingham wrote:
> Ralf Corsepius (rc040203 at freenet.de) said:
>> On 01/27/2012 06:05 PM, Bill Nottingham wrote:
>>> Toshio Kuratomi (a.badger at gmail.com) said:
>>>> Actually... we will "always" need the compat symlinks (for a finite but
>>>> definitely long value of "always").  Third party scripts, scripts that have
>>>> been in use on local systems, written by people who have long since passed
>>>> on (to new jobs), people targetting FHS compliant systems (unless the FHS
>>>> changes), etc will all depend on those symlinks being present.  Even third
>>>> party software that users want to compile and run may try to install into
>>>> /bin, /sbin, and /lib so we may have that problem even there.
>>>
>>> And things like /bin/sh are compiled into glibc...
>>
>> And hard coded into 1000s of scripts and packages.
>>
>> I seriously think, Fedora has many urgent problems to address than
>> the churn this "Feature" causes.
>
> ? There's no churn required due to packages having /bin/sh in them.

Sure there is - It's really sad you don't see it.

This feature is drain of energy and time of the already scarce resources 
Fedora has and contribute to pushing Fedora more into the niche it  
already is in.
---------------------------------------------------------------------------------------------------------
Am 27.01.2012 18:00, schrieb Toshio Kuratomi:
> On Fri, Jan 27, 2012 at 02:27:59PM +0100, Nils Philippsen wrote:
>> On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote:
>>> Toshio Kuratomi wrote:
>>
>>> I don't understand why we absolutely HAVE to change directories to symlinks 
>>> when we KNOW RPM doesn't support this, and that in directories as essential 
>>> as /bin etc.
>>
>> We could wait until you have convinced people, maintainers and users
>> alike, to fix their packages and scripts all in one go over to using the
>> new paths, so we get by without compat symlinks. But I don't think we
>> want to wait for that. Agreed, it'd be a whole lot nicer if RPM could
>> handle symlink <-> non-symlink transitions without crutches like this
>> one, but right now it can't.
>>
> Actually... we will "always" need the compat symlinks (for a finite but
> definitely long value of "always").  Third party scripts, scripts that have
> been in use on local systems, written by people who have long since passed
> on (to new jobs), people targetting FHS compliant systems (unless the FHS
> changes), etc will all depend on those symlinks being present.  Even third
> party software that users want to compile and run may try to install into
> /bin, /sbin, and /lib so we may have that problem even there.

yes, and this is one reason why i do not understand the rush doing this
"feature" now in one big step with a lot of possible pitfalls instead
start it slowly with change the install locations of the packages in
F17 and file bugs for every package who does still install files there
and place symlinks in /bi, /sbin

this is a change which can be done over more releases because it
does nothing change now for the users and in the meantime FHS
maybe updated and third-party packages are also adopted

there is no need doing such change in any rush and completly with
one release especially nobody was interested to do the systemd
transition in one step which would have made much more sense
and solved many many problems, bugreports and a lot of time
in the first step

why in the world is a currently useless "feature" much more forced 
than the change of the init-system?
-----------------------------------------------------------------------------------------------------------
On 01/27/2012 12:09 PM, Reindl Harald wrote:
> 
> 

> 
> why in the world is a currently useless "feature" much more forced
> than the change of the init-system?
> 

 perhaps this change is wanted/needed by the new init system for some
reason that may not be apparent at the moment ...

 resource usage aside, even if its not a 'good idea' it doesn't seem
like a 'bad idea' does it?

On 01/27/2012 07:32 PM, Genes MailLists wrote:
>   perhaps this change is wanted/needed by the new init system
 
No, systemd does not care.
----------------------------------------------------------------------------------------------------------
Toshio Kuratomi wrote:
> people targetting FHS compliant systems (unless the FHS changes)

That's the biggest flaw of this "feature": It violates the FHS!
 
        Kevin Kofler
----------------------------------------------------------------------------------------------------------
On Fri, 27.01.12 22:40, Kevin Kofler (kevin.kofler at chello.at) wrote:

> Toshio Kuratomi wrote:
> > people targetting FHS compliant systems (unless the FHS changes)
> 
> That's the biggest flaw of this "feature": It violates the FHS!

You know, not even its former editor seems to to believe that (or that
it was a problem), judging by the message this sarcastic posting of his sends:

http://rusty.ozlabs.org/?p=236

;-)

Lennart

--  
Lennart Poettering - Red Hat, Inc.
----------------------------------------------------------------------------------------------------------
Lennart Poettering wrote:
> You know, not even its former editor seems to to believe that (or that
> it was a problem), judging by the message this sarcastic posting of his
> sends:
> 
> http://rusty.ozlabs.org/?p=236
> 
> ;-)

Hey, my arguments are not the 2 "anti" arguments he quotes. ;-)

I have nothing against you personally. I have something against pointless 
changes to the standard file system we've been using for decades (and which 
is still working fine), causing pointless trouble when upgrading.

As for "There are precedents in Solaris and Fedora.", the latter is what 
this thread is aiming at preventing. :-p

        Kevin Kofler

-----------------------------------------------------------------------------------------------------------

Kevin Kofler, es un reconocido programador y parte del KDE Spin. El cual aplica parches y reparar cosas en C++ en cuestion de horas.
Usen Google Translate y saquen sus propias conclusiones.
Los responsables de este cambio, no diré la fuente son:

Harald Hoyer
Kay Sievers

Y ahora?

Que haremos?, nada, cruzar los dedos para que las soluciones de Fedora funcionen como antes, que no traiga problemas de seguridad, y convivir con un Windows-Like.

Pero... siempre tendremos Paris, perdón, quise decir, RHEL.

Y si RHEL tambien se convierte en eso?, bueno, siempre tendremos *BSD y Gentoo!


PD: Muchos usuarios de UNIX y Linux, con mas de 50 años, incluso en los canales de #fedora y #rhel, gente que usa *nix desde el año 92, me comentaron acerca de su descontento con esto, y que si pudieran votarian en contra, pero claro, nadie les consulto, todo sea por tapar el error de Lennart

PD2: Solaris, hace 15 años que viene trabajando en esto, y recien se implemento en Solaris 11. Pero posee una cantidad de mecanismos de recuperacion, diagnostico y analisis, que no posee Linux, sin contar, con el soporte nativo de ZFS, lo que implica, una falla casi imposible en su sistema de archivos, algo que Linux no posee. Por el momento, solo tiene Ext4, y el futuro BTRFS que esta en la rama experimental, propuesto para Fedora 18, otro gran error.


Eso es todo, agradeceria comentarios, pero con fundamentos y razones, luego de haber leido todo el post y la documentacion que cito en el mismo.