En las últimas semanas he trabajado en un proyecto donde hacemos uso del cálculo de fechas. Como ya han de deducir, uno de esos cálculos está relacionado a la redacción de esta entrada.

Pues bien, es algo sencillo. Primero tendremos que declarar nuestras dos fechas como un tipo de dato DateTime:

$fechainicial = new DateTime('2012-01-01');


$fechafinal = new DateTime('2013-01-01');

Ahora usaremos el método diff que poseen los objetos DateTime para saber la diferencia de tiempo entre nuestras dos fechas:

$diferencia = $fechainicial->diff($fechafinal);

El método diff nos devuelve un objeto del tipo DateInterval, que almacena la información sobre la diferencia de tiempo entre fechas (años, meses, días, etc.).

Bueno, para calcular los meses tendremos que multiplicar el atributo «y» por 12 (número de meses que contiene un año). Luego le sumamos el valor que hay en el atributo «m«, quien contiene el número de meses en nuestro intervalo de tiempo.

$meses = ( $diferencia->y * 12 ) + $diferencia->m;


Y listo, si hacemos la impresión de nuestra variable $meses, debe aparecer el número 12.

Oi pessoALL!

Se você instalou o openSUSE 12.2 mas está sem permissão para escrever em sua partição NTFS (Seu windows XP, 7, etc.) essa dica pode te ajudar.

O que se deve fazer é editar o arquivo fstb que fica em /etc/fstab. Como root você pode abrir seu editor de texto preferido, eu uso o Geany. Não esqueça de fazer um backup deste arquivo por via de dúvidas…

No meu caso o conteúdo do fstb estava assim:

/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part5 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part6 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part7 /home                ext4       acl,user_xattr        1 2
/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part1 /windows             ntfs-3g    user,users,gid=users,fmask=133,dmask=022,locale=pt_BR.UTF-8 0 0
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

Então altere a linha que corresponde a partição NTFS:
/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part1 /windows             ntfs-3g    user,users,gid=users,fmask=133,dmask=022,locale=pt_BR.UTF-8 0 0

Para:
/dev/disk/by-id/ata-Hitachi_HTS541612J9SA00_SB2D04E4C2VTBE-part1 /windows             ntfs-3g    defaults,locale=pt_BR.UTF-8 0 0

Feito isto, salve o arquivo e reinicie o computador. Após reiniciar você já deve poder ler/escrever em sua partição NTFS.

Espero ter ajudado. Fiquem com Deus!

Es ist jetzt wieder möglich Steam per 1-Klick-Installation auf openSUSE zu installieren. Die passenden Links findet man über die SUSE Software Suche.

Steam war bereits kurz nach Start der offenen Beta im OpenSUSE Build Service verfügbar, dort aber im Januar aufgrund rechtlicher Problem wieder herausgeflogen. Im Endeffekt lief es darauf hinaus, dass es von Valve keine offizielle Genehmigung für das openSUSE-Projekt gab Steam zu verbreiten. Jetzt hat Steam seine Lizens so geändert, dass jeder Steam-Pakete weiterverbreiten darf, und prompt ist Steam auch wieder für openSUSE verfügbar. Es ist sind zwar mit SUSE wohl noch nicht alle Formalitäten für die Verbreitung von kommerzieller Software über die SUSE-Infrastruktur geklärt, aber da jetzt klar ist, dass Valve die Verbreitung in dieser Form erlaubt gehe ich davon aus, dass Steam weiterhin offiziell für SUSE verfügbar sein wird. Wer weiß, vielleicht ist es dann ja bei openSUSE 12.3 von Anfang an ganz offiziell dabei.

During the discussions for the release of openSUSE 12.3, the topic of update notifications and applets was brought up again. Originally openSUSE shipped with a custom update applet, but since it was basically unmaintained, the decision was made to switch to Apper for openSUSE 12.2

The original Apper used in that version had a number of issues, which the upstream developer (Daniel Nicoletti) fixed in a newer version, which also had a lot of other improvments. However we originally couldn’t switch because it depended on a newer, API-incompatible version of PackageKit, meaning that the PK bindings for libzypp (the heart of openSUSE’s package management) needed to be adjusted and ported.

So, for a while it was not clear on how to proceed, until at the recent hackathon, Stephan “coolo” Kulow ported the PK zypp backend to the newer PackageKit version. Once that issue was solved, the KDE team was able to update Apper to the latest version (0.8) and push it to the distribution. So openSUSE 12.3 (KDE) will make use of Apper as main method of notification for updates.

I would like to stress that Apper is not meant as a full blown replacement of YaST or zypper, but mainly as a way to handle distro and maintenance updates, integrated with the KDE Workspaces.

The Apper program is actually divided into two pieces: the main application itself and a plasmoid. We’ve been testing the plasmoid the past weeks and consensus is that it’s not yet ready to be pushed to users, so only the main application will get installed by default. When you have new updates, an icon will pop in the system tray informing you:

[]({{ site.url }}/images/2013/02/apper-notification.png)

Clicking on it will bring up the main interface, where you can review and select the updates:

[]({{ site.url }}/images/2013/02/apper-updates1.png)

Afterwards, the update process will start.

Of course, such an addition means that more testing is required, to ensure that outstanding bugs get fixed before the openSUSE 12.3 release. Therefore, if you are willing to test - jump aboard!

In a couple of hours, I'll be taking the train and heading to Brussels for FOSDEM. I've lost counts of how many FOSDEM I've attended, which is probably a good indication of how great the event is!

As usual, this will be a good place to catch up with friends, but also to talk with tons of different people about so many topics. If you want to chat about OpenStack, SUSE Cloud, openSUSE or GNOME, I'll be glad to join you.

The schedule is quite packed, but from what I can tell so far, I'll be sitting in the cloud devroom on Sunday (don't hesitate to join in order to learn about what's happening in the OpenStack world!). Oh, I'll also give a talk in Janson about challenges that the GNOME project is facing, just before the closing keynote.

And no, I won't have my blue hat, so you'll need to find another way to catch me (hint: I have a SUSE backpack nowadays) ;-)

In a recent discussion among php core developers, Zeev Suraski of Zend Technologies offered to open source their proprietary byte cache “Zend Optimizer+”. The main objective is to get a bytecode cache into the PHP distribution and finally into the core. There is a lot of discussion if the 5.5 release should be delayed by two months to include the open-sourced Optimizer+. Some advocate that PHP 5.5 should stick to its original release schedule and Optimizer should go into the master instead, eventually becoming PHP 5.6 : While there is strong support for getting a byte code cache into PHP Core, some are questioning why the php.net project’s native cache extensions “APC” is not the preferred option. PHP Leader Rasmus Lerdorf says ”

You also have to take into account that most sites can’t actually move
to the next release of PHP until APC is stable with it. So effectively
the PHP 5.4 release didn’t happen until APC 3.1.13 in September 2012
which was a full 6 months after PHP 5.4.0. I don’t foresee this getting
any better for PHP 5.5.

In order for PHP releases to actually mean something this is a problem
we have to fix. I honestly don’t care which opcode cache implementation
we base a core version on, what I care about is developer buy-in. Dmitry
and Stas being familiar with the code already outnumbers the number of
active core devs working on APC today.

I understand some of the skepticism and hurt feelings around this from a
few old-timers, but let’s move on and see if we can finally push out a
release with solid opcode caching right at the release date. From my
perspective anything up to a 6-month delay would beat the current situation.

The APC would then be reduced to a userspace data cache. For Optimizer+ to get into the core, some cleanup and compatibility with ZTS (Thread Safety) needs to be achieved. Traditionally, Zend products only run in PHP’s non-threadsafe mode.

It is no secret I like version control systems(VCS). As most SysAdmins i believe that pretty much everything should be versioned, any file that we tinker with must always be backed up and versioned somewhere.

I am pretty sure that by now you maintain a lot of stuff in modern vcs like Git repos (or whatever floats your boat), the point is you already use version control. However as you might have guessed even though systems like Git sound (and for certain situations ARE awesome) they tend to not work well for a SysAdmin’s purposes, especially when talking about configurations.

Programmers tend to work on things and files that are interrelated thus it makes lots of sense to have everything under a directory versioned under VCS, which is the way it is currently done by “modern VCS”. In systems administration however that is not the case, most of the time the files in a directory have nothing to do with one another, but are there by convention and you rarely want to version and manage ALL of them.

The best example illustrating the above is the /etc directory. You rarely want to have it all versioned and many of the files there need special treatment (certain exact permissions etc…) making the use of “modern huge full directory oriented VCS” a real pain.

Enter RCS! Despite it’s many and significant disadvantages RCS is a simple and solid VCS with the great virtue of controlling individual files instead of directories or hierarches of them. Thus, its trivial and mindless to use for a file in some system dir (like /etc) and almost forget about it.

here is a list of common operations, done the RCS way.

#    RCS operation
#    $ Command line

#Initial check-in of file (leaving file active in filesystem)
$ ci -u filename

#Check out with lock
$ co -l filename

#Check in and unlock (leaving file active in filesystem)
$ ci -u filename

#Display version x.y of a file
$ co -px.y filename

#Undo to version x.y (overwrites file active in filesystem with the specified revision)
$ co -rx.y filename

#Diff file active in filesystem and last revision
	
$ rcsdiff filename

#Diff versions x.y and x.z

$ rcsdiff -rx.y -rx.z filename

#View log of check-ins

$ rlog filename

#Break an RCS lock held by another person on a file
$ rcs -u filename