En el anterior post expliqué como sincronizar un proyecto PHP+MySQL alojado en una máquina GNU/Linux con Dropbox de tal modo que podamos tenerlo alojado en la nube.
Uno de los propósitos de esto podría ser el tener almacenada una copia de seguridad del mismo pero el objeto que nos ocupa es bien distinto, sincronizar un mismo proyecto entre dos máquinas, GNU/Linux y Mac.

Una vez que tenemos nuestro proyecto en la nube, pasaré a explicar como sincronizarlo con nuestro Mac.

Recordamos los directorios del Mac que utilizaremos en el experimento:

• /Users/manu/Dropbox – Directorio Dropbox
• /Users/manu/Sites – Directorio configurado en Apache para leer los proyectos web
• /Applications/MAMP/db/mysql – Lugar donde MySQL guarda las bases de datos

Lo primero que haremos será ejecutar la aplicación de Dropbox e inmediatamente empezará a descargar los directorios “proyecto” y “proyectoDB”, que son el código fuente y la base de datos de nuestro proyecto que anteriormente sincronizamos con la máquina GNU/Linux.

Para poder ejecutar el proyecto en el Mac, deberíamos situar el código PHP en el directorio /Users/manu/Sites y la base de datos en /Applications/MAMP/db/mysql, pero si movemos los directorios perderíamos sincronización con Dropbox así que esto lo resolveremos mediante enlaces simbólicos.
ln -s /Users/manu/Dropbox/proyecto /Users/manu/Sites
ln -s /Users/manu/Dropbox/proyectoDB /Applications/MAMP/db/mysql

Si tenemos arrancado Apache, en este momento ya podríamos ejecutar sin problemas la aplicación siempre y cuando el usuario y contraseña de MySQL esté configurado del mismo modo que en GNU/Linux.

También podremos modificar el código fuente del proyecto a nuestro antojo e insertar tablas y registros en la base de datos ya que todos los cambios serán sincronizados con Dropbox y a su vez con nuestro GNU/Linux.

Como este sistema no es perfecto tiene un pequeño problema, un mismo fichero no puede ser editado simultáneamente por dos personas diferentes, o más bien no se debe puesto que poder se puede pero Dropbox lo interpreta como un conflicto y lo almacena como dos archivos que son dos versiones distintas del mismo.

Hemos conseguido con máquinas distintas, con sistemas operativos diferentes y con kilómetros de distancia entre ellas sincronizar un mismo proyecto y base de datos de tal forma que modifiquemos código o datos en cualquiera de las dos máquinas, ambas estarán sincronizadas. El número de máquinas es por supuesto ampliable.

Por último recordar de nuevo en enlace para crear una cuenta con Dropbox, ambos seremos recompensados con espacio extra

Espero que os haya servido de ayuda.

Actualización: Se me olvidó comentar algo importante. Lo habitual en MySQL es utilizar tablas del tipo MyISAM en cuyo caso no pasaría nada. Si por el contrario utilizamos alguna tabla del tipo InnoDB y no lo hemos especificado en las opciones de configuración, esta se almacenará en los ficheros: /var/lib/mysql/ibdata1 /var/lib/mysql/ib_logfile0 y /var/lib/mysql/ib_logfile1 que habría que sincronizar también con Dropbox y Mac.

La situación es la siguiente, estoy desarrollando un proyecto con Apache-PHP-MySQL. Sobre este mismo proyecto, en el curro programo por la mañana y por la tarde en casa siendo obvio que necesito hacerlo sobre la misma versión de código.
A parte de necesitar trabajar sobre el mismo código en ambos sitios, necesito hacerlo también sobre la misma base de datos.

En principio se nos ocurriría pensar que lo más sencillo sería transportar en un pendrive (del trabajo a casa y de casa al trabajo) tanto el código fuente del proyecto como la base de datos, siendo esto un engorro por varias razones: tener que copiar a diario el código, tener que sobreescribirlo en el destino, posible pérdida del pendrive, confusión de versiones, etc…
Para evitar todo esto lo haremos de una forma mucho más sencilla y gratuita, utilizando Dropbox como repositorio de código y datos.

Como todos sabeis Dropbox nos ofrece 2GB de almacenamiento gratuito en la nube. Si todavía no tenéis una cuenta podéis crearla pulsando aquí, de este modo tanto a tí como a mí nos darán espacio extra.

Para el experimento vamos a utilizar dos máquinas, una GNU/Linux y una MacOS X, e identificamos los directorios implicados en cada una de ellas.

GNU/Linux:

• /home/manu/Dropbox – Obviamente el directorio de Dropbox
• /var/www/proyecto – Directorio donde ubicamos nuestro proyecto PHP
• /var/lib/mysql/proyectoDB – Directorio donde MySQL almacena la base de datos de nuestro proyecto

MacOS X:

• /Users/manu/Dropbox – Directorio Dropbox en nuestro Mac
• /Users/manu/Sites – Directorio configurado en Apache para leer los proyectos web
• /Applications/MAMP/db/mysql – Lugar donde MySQL guarda las bases de datos

Empezaremos por sincronizar el código y datos de nuestro proyecto situado en la máquina GNU/Linux con Dropbox. Para ello sería necesario situar los directorios del código PHP y de la base de datos en la carpeta Dropbox pero esto no es posible ya que como hemos comentado anteriormente, están situados en /var/www y en /var/lib/mysql respectivamente. Lo solucionaremos mediante Symbolic links o enlaces simbólicos.

Nos autenticamos como superusuario:
su

Cambiamos los permisos para que Dropbox tenga acceso a los datos:
chmod 755 /var/www/proyecto -R
chmod 755 /var/lib/mysql/proyectoDB -R

Y realizamos los enláces simbólicos:
ln -s /var/www/proyecto /home/manu/Dropbox
ln -s /var/lib/mysql/proyectoDB /home/manu/Dropbox

Para comprobar si tenemos realizados correctamente los symbolic links, lo haremos del siguiente modo:
cd /home/manu/Dropbox
ls -l

Y nos deberá aparecer algo como esto:
lrwxrwxrwx 1 root root 13 nov 12 13:02 proyecto -> /var/www/proyecto
lrwxrwxrwx 1 root root 20 nov 12 13:00 proyectoDB -> /var/lib/mysql/proyectoDB

Si tenemos arrancada la aplicación de Dropbox directamente empezará a sincronizar nuestro proyecto hacia la nube.
Pasados unos minutos podremos acceder a la web de Dropbox para comprobar que efectivamente tenemos nuestro proyecto correctamente alojado.

Esto es todo amigos, fácil y sencillo…
En el siguiente capítulo explicaré como sincronizar el proyecto ya alojado en Dropbox con nuestro Mac.

Oggi ho completato la sincronizzazione tra il mio Nokia 5800 xpress, il mio macbook ed il mio account Google.

Riporto uno schema veloce delle procedure:

Sincronizzazione del mac con il 5800:

• scaricare ed installare l’apposito plugin per isync fatto apposta apposta per il nostro nokia
• apire isync e selezionare “aggiungi dispositivo” nel menù dispositivi
• seguire la procedura guidata per sincronizzare contatti e calendario

Adesso cliccando sull’icona di iSync si può sincronizzare automaticamente ogni volta che se ne ha la necessità.

Sincronizzare il mac con l’account google, calendario e contatti:

• aprire iCal, cliccare su preferenze->aggiungi account->ecc
• aprire Rubrica indirizzi -> preferenze->account->sincronizza Google

da notare che comparirà dentro iCal un calendario col nome del vostro account Google, verranno d’ora in poi sincronizzati solo gli eventi segnati sotto questo account e non quelli al di fuori.

Ein kleines Vorwort: Vor diesem Beitrag habe ich mich etwas gedrückt. Das große Fazit. Teil 1 des Fazits war noch einmal der Versuch zu erläutern, warum ich nach 13 Jahren Apple den Rücken gekehrt habe. Im zweiten Teil geht es nun um die Alltagstauglichkeit von Ubuntu Linux. Kann ich den Wechsel wirklich guten Gewissens weiterempfehlen? Ich nutze ja erst seit einem Jahr Linux. Bin ich überhaupt “sachkundig” genug für ein Fazit? Ich denke, das bin ich nicht – mache es aber trotzdem.

Der Wechsel von seinem gewohnten Betriebssystem hin zu einem neuen ist eine gewichtige Entscheidung. In der Regel hat man sich ja über Jahre hinweg an das Handling des alten Systems gewöhnt. Nach 13 Jahren Apple kannte ich MacOS X ziemlich genau – die dunklen, wie die hellen Ecken. Und Lesern mit Windows Erfahrung wird es ähnlich gehen. Ihr kennt Eure DLLs, stimmts?

Das offizielle Ubuntu Logo

Weil ich niemanden kannte, der Erfahrung mit so einen Mac-Linux-Switch hatte, dachte ich mir: Ich behalte meinen Mac und setze ein Testsystem (mein Netbook) mit Linux auf. Allen die jetzt auch denken, das sei eine gute Idee, denen muss ich widersprechen. Den Switch kann man nur begrenzt proben. Man muss leider den Sprung ins kalte Wasser wagen. Man muss alle persönlichen Daten vom alten Betriebssystem aufs neue kopieren und den alten Rechner ausmustern. Wer Linux nur auf einer alternativen Partition der Festplatte installiert, der wird den Wechsel nicht hinbekommen.

Also habe ich meinen Mac mini zum Videorekorder degradiert und mir einen neuen PC gekauft, der mein Hauptrechner werden sollte. Ich habe die dunkle Magie der PC-Schrauberei gelernt. Ein Kapitel auf das ich jetzt nicht näher eingehe.

Die wichtige Frage, der dieses Blog implizit immer nachgegangen ist, lautet: Ist Linux bereit für den Schreibtischrechner? Im Serverbereich ist das ja keine Frage. Rechenzentren sind voll mit Linuxboxen. Aber im Desktopbereich? Glaubt man optimistischen Statistiken wie denen von W3Counter, dann setzen knapp 2 Prozent (Stand August 2009) aller Nutzer Linux ein. Nicht gerade viel.

Installation geschafft - das war mein erster Screenshot!

Mein erster Eindruck nach der Installation war zunächst: Natürlich ist Linux bereit für den normalen Schreibtischrechner! Wer schonmal einen Windows oder MacOS X Rechner neu aufgesetzt hat kennt das: Nach der Installation ist vor der Installation. Denn eine klassische Installations-DVD für Betriebssysteme installiert ja keine Programme mit. Die müssen dann erst mühsam Stück für Stück einzeln nachinstalliert werden. Ubuntu installiert man in der Regel von einer einzigen CD. Schon nach 20 Minuten hat man dann ein komplettes Linux auf seinem PC – komplett mit einer ganze Reihe an sinnvollen Programmen. Office, Bildbearbeitung, Foto- und Mp3-Managment und so weiter – alles ab dem ersten Start des Systems schon da.

Aber natürlich ist die Vorstellung “20 Minuten Installation und das war’s” eine Illusion. Denn es gilt ja auch der Satz: Nach der Installation ist vor der Konfiguration. Und die hat es in sich! Ein neues Betriebssystem kennenzulernen und es so zurecht zu biegen, dass man damit zufrieden ist… Bei mir hat das mehrere Monate gedauert. Einer der ersten Tweaks nach der Standardinstallation war die Aktivierung der Räumlichen Dateiverwaltung. Das ist der Modus, in dem der Dateimanager Nautilus für jeden Doppelklick ein neues Fenster öffnet. Ein Verhalten, das viele nervt. Ich bin hingegen schwer begeistert von der konsequenten Umsetzung der Schreibtischmethapher. Ebenfalls sehr clever gelöst ist unter Linux das Installieren und Aktualisieren von Software. In der Linux Welt ist es nicht üblich sich ein Programm mit dem Browser aus dem Netz herunterzuladen und dann per Installationsprogramm zu installieren. Stattdessen wählt man Programme und auch Pakete über eine Art Katalog aus und installiert und deinstalliert diese dann mit einem Klick. Dieser standardisierte Prozess ist sehr benutzerfreundlich.

Der Linux Softwarekatalog - Einfache Installation Jahre bevor Apple für das iPhone den AppStore "erfunden" hat

Weniger positiv fielen dann die ersten intensiveren Tests mit den verfügbaren Programmen aus. Für die Fotoverwaltung liefert Ubuntu F-Spot mit. Leider ist F-Spot sehr langsam und noch ziemlich unfertig. Rhythmbox – die GNOME MP3 Jukebox – hat wiederum ein ganz anderes Problem. Sie ist zwar schnell und einigermaßen elegant. Dummerweise ist die Weiterentwicklung ziemlich eingeschlafen. Im nächsten Ubuntu Release wird dann auch wohl Banshee und nicht mehr Rhythmbox mit dabei sein. Nun muss man entlastend sagen: Die Apple-Lösungen iPhoto und iTunes haben auch eine Menge Macken (- ich hab ja schon so meine Gründe gehabt Apple den Rücken zu kehren): iTunes hat im Laufe der Jahre immer mehr unnütze Funktionen hinzubekommn. Im Vergleich zu Rhythmbox ist iTunes ein fürchterlich behäbiges Programmmonster. iPhoto wiederum versteckt unter anderem meine Fotos in einer einzigen riesigen Bildarchivdatei. Dennoch war ich ein wenig enttäuscht von den Linux-Lösungen. So schwer kann es doch nicht sein eine gute MP3-Jukebox, oder eine gute Fotoverwaltung zu entwickeln.

GNOME Programme haben häufig viel große Navigationsleisten. Beispiel: Epiphany (3. v. links) - im Vergleich zu Safari und Firefox

Im Laufe meiner Tests ist mir am recht kleinen Netbook-Bildschirm eines aufgefallen: GNOME Programme verschwenden häufig zu viel Platz für Ihre Navigationsleisten. Das hatte dann wiederum meinen Blick darauf gelenkt, wieviel Apple auf  so kleine Dinge wie die Optimierung von Navigationsleisten verwendet. Mittlerweile gibt es Projekte wie Moblin oder den Netbook Remix von Ubuntu, die sich dieser Problemstellungen angenommen haben. Dennoch ist das ganze gar nicht primär ein Netbook-Problem. Ich finde auch auf einem 30 Zoll Bildschirm sollte man sich über jeden Pixel Gedanken machen. Ohne ein gewisses Maß an Pedanterie wird das GNOME Projekt nicht den Feinschliff erreichen, den der MacOS X Desktop zugegebenermaßen hat.

In einem weiteren Beitrag hatte ich einen etwas genaueren Blick auf den Ubuntu Desktop geworfen. Viele Konzepte scheinen mir Weiterentwicklungen aus der Windows 98 Zeit zu sein: Taskbar, Schnellstartleiste, Systray, Start-Menü. Das ist etwas enttäuschend. Ich hatte hier im Grund mehr Eigenständigkeit des Linux Desktops erwartet. Nichts gegen eine gute Kopie. Aber wenn Features wie Taskbar (immer überfüllt) und Systray (Sammelsurium) konzeptuell schlecht sind, dann muss was Neues her. Hier erwarte ich auch mehr Engagement vom Ubuntu-Sponsor Canonical. Es kann doch nicht sein, dass NotifyOSD die einzig sichtbare Weiterentwicklung des Desktops ist, die Canonical aktiv beisteuert. “Keine kleinen Brötchen mehr, Zeit zum Stollen backen” singen Kinderzimmer Productions. Sehe ich genauso.

Mein Fazit nach einem Jahr Ubuntu Linux ist gemischt. Einige Dinge funktionieren unter Linux besser, als unter MacOS – in anderen Bereichen wiederum ist der Mac ganz klar vorn. In den allermeisten Bereichen ist der Unterschied aber gar nicht so groß. Der Wechsel zwischen den Systemen ist möglich, ohne dass man das Gefühl hat auf etwas verzichten zu müssen. Im Umkehrschluss bedeutet das aber auch: MacOS X ist ein gutes Betriebssystem. Es gibt keinen zwingenden technischen Grund Apple den Rücken zu kehren. Wer sich aber (wie ich) mit der Apple Software- und Hardware-Politik der letzten Jahre schwer schwer getan hat, wer auch das ungute Gefühl hat, dass Apple schon lange nicht mehr zu den “Guten” gehört, dem kann ich nur empfehlen zu wechseln.

Ebbene si, ho pagato l’obolo di 30€ per avere il non nuovo sistema operativo made in Apple, l’han chiamato Snow Leopard, come dire che la neve ci mette poco a raffreddare gli entusiasmi.

L’installazione è stata facile, giusto un paio di clic, tutto configurato come nel precedente Leopard. L’unica cosa che ho notato sono stati i tre pallini per chiudere/ridimensionare la finestra di un colore più vivo. Per il resto nessuna novità ancora riscontrata.

Il problema si è presentato quando il gioco si è fatto duro, ossia con la connessione wireless del politecnico. Ovviamente pensavo che anche questo sarebbe rimasto sostanzialmente uguale e invece mi sbagliavo. Dopo due ore di tentativi mi sono dovuto arrendere, Snow Leopard per qualche arcano motivo non vuole saperne della rete del poli: WPA Enterprise con autenticazione TLS.

Le possibili candidate cause sono tre:

1. Gestione dei certificati a muzzo
2. Gestione delle impostazioni proxy a muzzo
3. Associamento alle reti nascoste a muzzo

In ogni caso non posso lasciare la situazione cosi, come membro del direttivo del POuL nonchè autore della guida wifi a prova di scemo, ho il dovere di trovare una soluzione, ammesso che ci sia…sigh!

————————————————————————————————

Bene, il problema era dei server DNS, Snow Leopard a differenza di Leopard non mi permette, impostando il proxy del poli, di usare automaticamente i DNS del politecnico invece dei soliti openDNS che avevo impostato come default. Il risultato era che nè firefox nè safari riuscivano a risolvere nessun indirizzo. Ho comunque dovuto togliere gli openDNS, più avanti proverò a fare delle posizioni preimpostate.

Just a quick note to let you know that Websaver should now work on 10.6 64bit. The recompiled version is available here:

• websaver-2.3.dmg

As you can see, I have moved the source to Google Code, and so any issues can be reported on the issues page.

Cheesy disclaimer: I don’t have a 10.6 64bit capable machine for testing . Please let me know if it works.

Wow, hoy si fué un dia para Apple, por que hubo muchas , por ejemplo, el robo de 31 segundos, o la extraña función tactil de Snow Leopard, claro, tambien hay noticias de  Microsoft, pero no es de lo que vamos a hablar en esta entrada.

*Robo record:

En 31 segundos, 5 maleantes se robarón de un Apple Store (y cuenten): 23 MacBook Pro, 9 Ipods touch y 14 Iphones.

Esto sucedio en EEUU, en el AppStore de Marlton, en el estado de Nueva Jersey. Si hubieran tenido los rostros al descubierto, estarían en la carcel, pero, con un record guinness.

*El extraño teclado de  Snow Leopard:

Algunos ya descubrieron que el nuevo sistema operativo de Apple, ya soporta pantalla multitactil, gracias a que alguien lo probó con el teclado en pantalla (keyboard-on-screen), para que puedan interactuar masomenos con naturalidad (Les recuerda algun dispositivo de la serie “I”?) Esto revoluciono un poco las cosas y la mayoria pensamos que se viene el Itablet (o como lo quiera llamar Apple). En el Wall Street, Jobs desmintio esta posibilidad, y dijo que “era basicamente un error”, cuando el CEO de Apple estaba volcada sobre el desarrollo del dispositivo.

Forse chi usa un mac è poco propenso ad usare la shell, con un desktop cosi completo…cosi intuitivo…cosi…

A quelli come me invece, che vengono da Linux e che hanno voglia di capire come funziona lo strumento che usano, anche professionalmente parlando, piace aprire la shell e scoprire quanto è rimasto di unix in quella X.
E’ noto a tutti gli utenti Linux che per aprire un programma dal terminale basta digitare semplicemente il nome del programma e premere invio, la shell ti tipo “bash” (che è quella di default) cerca il nome del programma richiamato nella posizione attuale e nelle posizioni del nostro computer indicate nella variabile chiamata PATH, visibile digitando un:

$echo $PATH   dove $ è il sombolo che ci dice “non sei superutente”, echo dice “manda al video l’elemento che segue”, $PATH è il valore di una delle tante variabili che corredano la shell che stiamo usando, e ci dice che vogliamo il valore “dentro PATH”

Problema: MacOS X non permette di aprire Firefox semplicemente digitando “firefox” , ma permette di aprirlo spostandosi nella cartella /Applications e digitando

$open Firefox.app          questo perchè in macos tutto ciò che serve ad un programma non sta in nessuna altra parte se non dentro il pacchetto con estensione .app, tipo Firefox.app

Problema 2: ma io voglio poter digitare solo “Firefox” oppure al massimo “apri Firefox” e voglio imparare a usare gli script, e questo mi sconfinfera.

Soluzione:

1.Includo la posizione /Applications tra quella in cui la shell cerca il comando digitato, da qualunque posizione esso venga lanciato, perchè dentro metterò il mio script per fare in modo che sia sempre reperibile:

$ PATH=$PATH:/Applications    cioè”rendi la nuova PATH uguale al contenuto della PATH che hai adesso e aggiungici il campo /Applications in coda

2. Creo un file di testo semplice in cui metto i comandi in grado di Cercare se l’applicazione da aprire si trova in /Applications e il comando open che, appunto, apre l’applicazione

$cd             quando si da un Change Directory senza niente si vuole sottointendere di spostarsi nella propria cartella home, e noi ci spostiamo proprio lì.

$ touch scriptcheapre.sh      il comando touch crea un file con il nome scriptcheapre.sh,l’estensione .sh serve solo per bellezza,fa capire a noi che è un script shell, poteva anche non esserci. Il file nuovo compare nella nostra cartella home.

Adesso apriamo scriptcheapre.sh con un editor di testo a piacere( word,blocco note, textedit…). Nel caso di textedit fate attenzione che di default salva i file in rtf(rich text format) che NON è testo semplice e che quindi renderà il file non leggibile come serie di comandi del terminale, vanificando i nostri prossimi sforzi…

A questo punto ci dobbiamo inventare la serie di comandi e scriverli dentro il file, io l’ho pensata cosi:

#! /bin/bash          IMPORTANTE:la prima riga di uno script indica con cosa aprilo, in questo e in quasi tutti i casi l’eseguibile che vogliamo fargli usare è situato in /bin/bash che è un file in una cartella che “veramente” esiste sul nostro computer…
# script apri.sh
##apri programmi in /Applications con sintassi ‘apri <nomeprogramma>’##   le righe che iniziano con un cancelletto # non vengono lette dalla shell e quindi vengono usate per scrivere commenti, indicazioni all’utente, aiuti, reminder ecc. In questo caso serviranno a ricordarmi cosa fa questo script.

x=/Applications/*       qui la shell “bash” prende tutti gli elementi della cartella /Applications e li schiaffa nella variabile x, adesso la x è proprio l’elenco dei programmi in Applications

for y in $x  ;      il ciclo for è una brutta bestia, la variabile y assume uno ad uno tutti gli elementi del “contenuto di x”

do         al “do” segue il comando che deve essere eseguito per ogni y in $x

if [ "$y" == "/Applications/$1.app" ];then  la condizione per entrare nell’if è che il contenuto di y a questo giro(for) sia uguale (==) a /Applications/$1.app dove $1 è il valore dentro la variabile chiamata “1″

-IMPORTANTE!!- se scrivi qualcosa subito dopo uno script(come vedremo) telo ritrovi nella variabile numerica in sequenza!

echo “e che cacchioletta!!”               stampa a video l’espressione di soddisfazione per aver trovato il nome scritto appena dopo lo script tra i programmi in /Applications

exec open $1.app    esegue il comando open con come argomento il valore dentro 1 che è il nome della applicazione da aprire,ci aggiungo .app perchè altrimento il nome, per macos è incompleto, e quindi sbagliato.A questo punto voi vedrete l’applicazione aprirsi…

fi       fa uscire dall’if

done     fa terminare il ciclo for

echo “nessuna applicazione con quel nome ciccio…”  nel caso in cui non trova nessun applicazione con quel nome stampa a video un severo messaggio di rimprovero.

Devo ammettere che non so ancora come mai l’ultimo echo non venga eseguito anche nel caso in cui si apra il programma desiderato, secondo quello che sapevo avrebbe dovuto stamparne uno in qualsiasi caso…fatemi sapere se trovate il motivo…

3. Adesso per aprire firefox (ad esempio) dovremmo dare

$sh scriptcheapre.sh Firefox

ma è troppo lungo, io voglio qualcosa di più veloce allora mi creo un alias, cioè una abbreviazione tramite equivalenza:

$alias apri=’sh scriptcheapre.sh’

perchè l’alias si conservi anche per le altre sessioni bisogna solamente scriverlo dentro il file /Users/<nomeutente>/.bash_profile, attenziona perchè dovrete cercarlo ed aprirlo tramite shell poichè macos non permette di vedere i file noscosti, cioè quelli che iniziano con un punto.

Allora scriviamo dentro questo .bash_profile la riga

alias apri=’sh scriptcheapre.sh’

eccofatto, ora per chiamare firefox vi basterà digitare

$apri Firefox

ta dah!!

Manchmal kann es passieren, dass Hintergrundprozesse im MacOS X die CPU-Last hochtreiben, was in einem langsamen, heißen Computer mit blasenden Lüftern endet (besonders bei Laptops). Zu diesen Prozessen gehören u. a. verschiedene Indizierungs-Utilities wie z.B. mds und mdworker. Einer dieser Prozesse ist das aslmanager-Utility, der System-Log-Files -Manager für den “ASL Data Store”, der neu ins OS X eingefügt wurde.

In vergangenen Versionen des MacOS X wurden die System- und Prozess-Log Nachrichten von “syslogd” und dem “syslog” Utility empfangen und verwaltet. Mit MacOS X 10.5.6 hat Apple einen neuen Satz Log Funktionen durch die “ASL” Logging Methode und die API hinzugefügt. Um diese neuen Funktionen kümmert sich der “aslmanger”-Prozess, der direkt nach syslogd gestartet wird.

Apple migriert in zukünftigen Versionen von OS X das bisherige Log Management in die neuen ASL Logging Funktionen, aber es scheinen noch einige bugs in der aktuellen Version der ASL Utilities zu stecken. Während genaue Angaben darüber nicht bekannt sind, sieht es so aus, als bleibt der aslmanager bei bestimmten Funktionen hängen.

Eine Möglichkeit, diesen Umstand zu beseitigen, wäre den Prozess über die Aktivitätsanzeige zu beenden. Das ist aber nur eine vorrübergehende Lösung des Problems und kann Speicher korrumpieren. Anstatt den Prozess also “rauszuschmeißen” wird empfohlen, den Log Management Prozess nach dem Löschen des ASL Data Store Verzeichnisses neu zu starten.

Hoffentlich werden die Bugs im alsmanger in zukünftigen Updates beseitigt.

Lösung

Öffnen Sie das Terminal und geben Sie die folgenden Kommandos ein, um die Log Manager zu stoppen:

• sudo launchctl stop com.apple.syslogd
• sudo launchctl stop com.apple.aslmanager

Legen Sie dann einen Ordner namens temp auf Ihrem Schreibtisch an und geben danach das folgende Kommando in das Terminal ein, der den Inhalt des ASL Data Store in den neuen temporären Ordner verschiebt:

• sudo mv /var/log/asl/* ~/Desktop/temp/

Starten Sie dann den syslogd Prozess mit dem folgenden Kommando (der aslmanager wird erst wieder gestartet, wenn er von syslogd benötigt wird, also braucht er nicht explizit neu gestartet zu werden):

• sudo launchctl start com.apple.syslogd

Dieser Artikel ist die Übersetzung des folgenden Artikels: aslmanager taking up 99% of CPU

In den kommenden Wochen wird Apple eine neue Version seines Betriebssystem MacOS X herausbringen. Gut zwei Jahre nach “Leopard” kann man sich als Apple Nutzer dann für günstige 29 Euro das neue “Snow Leopard” kaufen. Die (verdammt kurze) Liste der neuen Funktionalitäten der dieser Version von MacOS verdeutlicht: Momentan lehnt man sich in Cupertino ganz lässig weit zurück, verschränkt gähnend die Arme hinter dem Kopf und beobachtet das Geschehen auf dem PC Markt. Genau das war einer der Hauptgründe für mich im vergangenen Jahr mal einen Blick in die Linux Welt zu werfen. Im Macintosh-Bereich herrscht bei Apple Stillstand.

Alle interessanten Aktivitäten scheinen sich exklusiv im iPhone-Bereich abzuspielen. Und – das muss man der Entwicklungsabteilung von Apple auch ganz klar zugestehen – im das iPhone ist ein großartiges Gerät. Von meinem iPod touch kenne ich das iPhone OS ganz gut. Es ist anderen MobileOSes wie etwa Maemo von Nokia in Bereichen wie Bedienkomfort, Schnelligkeit und Energiesparen um Längen überlegen. Viel Licht, aber noch viel mehr Schatten. Mit seiner Softwarepolitik rund um iPhone und iPod touch offenbart Apple auch sehr deutlich seine dunkle Seite. Das iPhone ist eine schwerstens abgeschottete Plattform. Mit jedem Firmware-Update wird die weiter Abschottungsschraube gedreht. Die feste unbrechbare Kopplung an den iTunes Musikshop ist die zentrale Strategie für die Plattform iPod/iPhone. Ohne iTunes geht gar nichts. Eine leidvolle Erfahrung insbesondere für alle Linux-Nutzer.

Crab Apple Monster! - Wie passend. Ein Fundstück von Flickr-Nutzerin Juli Shannon (jk5854) CC BY-NC 2.0

In den vergangenen zwölf Monaten machte Apple negative Schlagzeilen, weil es immer wieder die Inhalte des Software-Stores zensierte. Abstrus erscheinen die Zensurmaßnahmen, die Apple im Namen des Jugendschutzes betreibt. Da wird ein Wörterbuch aus dem Programm genommen, das so schlimme Wörter wie “Cunt” enthält. Unangenehm wird’s wenn Apple Konkurrenzprodukte zensiert. Beispiele hier wären: MailWrangler und Podcaster. Das muss man mal in Perspektive setzen. Bei Microsoft wird seit Jahren bemängelt (und vor EU-Gerichten geklagt), dass der Internet Explorer so eng mit Windows verzahnt ist. Man stelle sich vor, Microsoft ginge noch einen Schritt weiter und würde eine Installationsmöglichkeit von Firefox komplett blockieren.

Nun – genauso handelt Apple. Wo es nur geht, wird Kontrolle geübt. Ein Grund dafür ist das Bestreben, die eigene Marktposition zu sichern. Der zweite Grund für den Zensur- und Kontrollwahn ist das Betreben, die User-Experience der eigenen Produkte stimmig zu halten. Die Produkte aus Cupertino sollen möglichst rund sein. Ich würde aber lieber ein paar Ecken und Kanten in Kauf nehmen, wenn Apple darauf verzichten würde mich zu entmündigen. Es muss möglich sein, auf meinem iPod auch Programme zu installieren, die Apple nicht gut findet.

Aber diese Art von Offenheit ist nicht von Apple in den kommenden Jahren nicht zu erwarten. Man muss kein Hellseher sein, um vorauszusagen, dass alle zukünftigen Produkte aus Cupertino geschlossene Betriebssysteme haben werden. Der gute alte Personal Computer, so scheint es, war ein bedauerliches Missverständnis. Die Ingenieure haben Anfang der 1980er Jahre in ihrem jugendlichen Leichtsinn eine Plattform etabliert, die das freie Ausführen von Code ermöglichte (Hui!). Damals hatte man nicht bedacht: Nutzer sind dämlich und müssen vor sich selbst geschützt werden. Ich bin mir sicher: Wenn man Steve Jobs in eine Zeitmaschine setzten würde, dann würde His Steveness (mit seinem De Lorean?) ins Jahr 1984 zurückfliegen und diesen Geburtsfehler des Macintosh korrigieren.

Ja, liebe Apple Fanboys, der einstmals schöne Apfel ist faul geworden. Und ich sehe keine Anzeichen, dass sich daran in den kommenden Jahren etwas ändern wird. Dass im Bereich MacOS momentan Stillstand herrscht, ist da fast noch ein gutes Zeichen. Denn eines ist sicher: Freier wird die Plattform Macintosh in den kommenden Jahren sicherlich nicht werden. Es steht eher zu befürchten, dass Apple das erfolgreiche Geschäftsmodell AppStore auf MacOS portiert, damit das Betriebssystem “sicherer” wird.

Zeit also für einen Wechsel. Der zweite Teil des Rückblicks auf ein Jahr Bye-bye Apple Computer wird wohl Ready When You Are betitelt werden – und widmet sich dann meinen Erfahrungen mit dem Umstieg auf Ubuntu Linux.

Desde el último post ha pasado un año, durante el cual he tenido el blog abandonado. Podría poner alguna excusa, como que me estaba esperando a que funcionara el LHC, o cualquier otra chorrada, pero simplemente no había ganas y punto

Pero ahora que vuelvo a ello quiero compartir con muchos de vosotros, maqueros que me leeis, la forma más efectiva de comprobar que vuestros vecinos utilizan un sistema de cifrado lo suficiente seguro para su conexión WiFi. Obviamente, la finalidad de este post es meramente educativa, para que el lector sea consciente de la fortaleza de un sistema WiFi, ya sea WEP o WPA.

Para empezar necesitamos capturar paquetes de las redes existententes. KisMAC es la herramienta perfecta para ello, ya que captura paquetes de todo tipo de redes, incluso las ocultas. La primera vez que abrimos el programa deberemos configurar el driver para la tarjeta de red, que en todos los portátiles actuales de Apple es una Airport Extreme, y elegimos el driver para el modo pasivo (promiscuo). Una vez añadido, lo seleccionamos y en el apartado Dump filter seleccionamos Keep everything, eligiendo el destino donde queremos que se guarde el log.

KisMAC permite hacer inyección de paquetes para descifrar la contraseña con otros drivers, pero no con Airport Extreme. Así que utilizaremos el programa descifrador por excelencia, la suite Aircrack, que ya se puede compilar en MacOS. La forma más cómoda es tener el gcc y el Subversion instalado (el gcc instalando las XCode Tools y el Subversion vía web), e instalar y compilar desde Terminal:

$ svn co http://trac.aircrack-ng.org/svn/trunk/ aircrack-ng
$ cd aircrack-ng
$ make
$ sudo make install

Después de reiniciar la Terminal ya tendremos los comandos de Aircrack en el path (y si no pues se añade /usr/local/bin/), así que sólo tendréis que pasarle el log creado por KisMAC como primer parámetro $ aircrack-ng Log. ya sabéis, a más paquetes capturados más fácil sacar la contraseña. También es recomendable echarle un ojo al manual de aircrack y las diferentes opciones que ofrece.

Por cierto, no me he enrollado mucho en la parte técnica para que no quedara muy largo, pero cualquier duda es bienvenida

NSInvocation certainly gets a bad rap at times. If you use it naively, you will get some horrible performance with it. Doubly so on the iPhone where there is much less CPU power than on MacOS X. But for some things, it is very useful. For example, say you want to pass a field name to a method and then call the setter and getter for that field on an object. Using a selector and an NSInvocation object, you can dynamically call them:

-(float)invokeGetSelectorForField:(NSString *)fieldName inObject:(id)o {
    float value;
    SEL fieldGetSelector = NSSelectorFromString(fieldName);
    NSInvocation *i = [NSInvocation invocationWithMethodSignature:
        [[o class]
        instanceMethodSignatureForSelector:fieldGetSelector]];
    [i setSelector:fieldGetSelector];
    [i setTarget:o];
    [i invoke];
    [i getReturnValue:&value];
    return value;
}

But what if you need to call this getter multiple times? Maybe hundreds or thousands of times? In this case, you can keep your NSInvocation object around and then simply invoke and then call getReturnValue: on it anytime you need to make the call. You can change the target of the NSInvocation to point to a completely different object. Or even change the selector. Pretty much anything you want to change you can. So instead of the above code, do something like this instead:

In your init method:

    SEL fieldGetSelector = NSSelectorFromString(fieldName);
    fieldGetInvocation = [[NSInvocation invocationWithMethodSignature:
        [[o class]
        instanceMethodSignatureForSelector:fieldGetSelector]] retain];
    [fieldGetInvocation setSelector:fieldGetSelector];
    [fieldGetInvocation setTarget:o];

In your dealloc method:

    [fieldGetInvocation release];

And then when you need to call it:

    float value;
    [fieldGetInvocation invoke];
    [fieldGetInvocation getReturnValue:&value];

Doing this can easily end up saving a lot of CPU usage in your application, depending on how often you are calling the method. In my current project, I went from 20% usage in calling the setter and getters down to effectively 0% when measured with Instruments. All of that time was being eaten up in creating and destroying NSInvocation objects. Certainly not the best usage of the limited resources on the iPhone.

For more information on the NSInvocation class, please take a look at the documentation on Apple’s site: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/nsinvocation_Class/Reference/Reference.html

Todo parece que Apple esta dando ya los ultimos toques finales al nuevo Mac OS X Snow Leopard, pues a enviado a los desarrolladores la ultima Built. En ella hay algunos cambios visuales como nuevos Wallpapers. En uneasysilence encontramos la galeria completa de estos wallpapers. Vemos algunos que tambien encontramos en el iPhone, como Noche Estrellada de Van Gogh por mensionar solo alguno. Puedes ver la galeria completa con la liga al final de esta entrada.

Mas Informacion | Uneasaysilence

In preparazione ad un futuro possibil talk del sottoscritto riguardo alla popolare distribuzione linux per gli studenti del politecnico di milano PoLinux, sto provando a fare qualcosa di serio con octave invece che con il matlab fornito dal poli. Provando a far girare octave sotto macos ho avuto due problemi:

Il comando plot(x,y) non tornava nessun errore ma non compariva nessuna finestra con il mio grafico.

Il comando gplot(x,y) tornava qualche errore strano riguardante il file gnuplot.m

Per non arrovellarvi vi passo la procedura funzionante:

1. Scaricate Octave 3.2.o per Mac intel dal sito ufficiale. Al suo interno troverete Octave.app da spostare nella cartella Applicazioni ed una cartella “Extras” dentro cui troverete Gnuplot.app, applicazione indispensabile per disegnare grafici con Octave, anche questa, una volta scompattata nella forma Gnuplot.app, va spostata nella cartella Applicazioni.

2. A questo punto Octave e Gnuplot avranno bisogno di Aquaterm, una applicazione che permette a Gnuplot di aprire un terminale grafico in cui schiaffare quello che Octave vuole fargli disegnare. Una specie di lavagna al servizio di Gnuplot per intenderci. Scaricate Aquaterm 1.0.1 , scompattatelo e spostate Acquaterm.app nella cartella Applicazioni.

Il vostro Octave sarà adesso pienamente funzionante, senza spendere spropositi in Matlab.

Western Digital presentó hace ya un tiempo su disco duro de 3.5 pulgadas y 2 TB de capacidad, que es ahora el elegido para servir en el My Book Studio Edition II de 4 TB de capacidad.

Esta revisión del producto, que llega para sumarse a los anteriores modelos de 1 y 2 TB, utiliza dos discos de 3.5 pulgadas internamente, que pueden cambiarse fácilmente y sin necesidad de tornillos o complejos mecanismos. El My Book Studio Edition II trae conectividad Firewire 400 y 800, USB 2.0 y eSATA, y puede utilizarse para el sistema de copias de seguridad Time Machine de MacOS X, el sistema operativo de Apple.

Una desventaja del equipo es la falta de conectividad WiFi o red Ethernet, sobretodo esta última, ya que se conseguirían tasas de transferencia de datos mucho mayores que con las conectividades que incluye el dispositivo. Es por esto por lo que los WD My Book Studio Edition II son discos duros externos más que dispositivos NAS, Network-attached storage.

El precio de este modelo de 4 TB es de 699 euros, estando ya disponible en la tienda online de WD y en unos días en tiendas físicas.

Más información | WD.
Vía | Xataka