Contenuti più votati

la navigazione del file system fa a cazzotti con le sandbox delle applicazioni.
C'era da preferire la voglia nerd di mettere le mani dappertutto alla certezza che le app non si influenzano tra di loro e puoi tranquillizzare così l'utente medio.
Han scelto la seconda.

 

Gli altri per cercare di farli usare di più devono attaccarsi a tutto quello che il loro riferimento non fa, a prescindere che gli piaccia o no.

In cosa farebbe a cazzotti con le sandbox? Applicazioni che si influenzano tra loro a causa del filesystem? FUD. Se fosse vero, OSX sarebbe inutilizzabile.

L'unico motivo per cui Apple vieta l'accesso low-level ai suoi gadget è per mantenere un controllo (economico in primo luogo da cui deriva quello sui contenuti) sulle applicazioni e sull'utilizzo. Nel momento in cui hai accesso al filesystem e quindi a tutto il toolbox che ci puoi costruire sopra, il device diventa tuo a tutti gli effetti e puoi farci quello che vuoi (entro limiti definiti esclusivamente da quello che sai fare). Questo non va ad intaccare minimamente l'utente medio che dipingi come quello tutelato da questa strategia. La stessa cosa accade su osx: il fatto che ci sia una shell non vuol dire che tutti gli utenti debbano utilizzarla (difatti è visto che un mostro incomprensibile dalla maggior parte degli utenti apple, che preferisce usare dei frontend e pigiare un bottone piuttosto che scrivere un comando).

Seriamente: ti pare il caso che io debba utilizzare una applicazione di terze parti (o, peggio ancora, un servizio cloud) per trasferire i miei file tra il mio computer ed il mio iphone? Cosa sarebbe cambiato se, nel momento in cui colleghi quel cazzo di cavo, assieme ad aprirsi il fantastisco supermercato della fuffa, ti fossi ritrovato anche il fottuto device montato in /Volumes come fanno tutti gli altri device? Suicidio di massa di "utenti medi"?

Per me è ignoranza totale per quanto riguarda la gestione tecnica dei forum, ma io lo vedo come uno stimolo piuttosto che come un impedimento ...
Per quanto riguarda invece la parte "economica" vorrei capire cosa si intende con licenze (questo sempre nell'ambito della mia ignoranza) per capire se sono spese facilmente, come dire ... eludibili ... . Se si tratta di software sicuramente lo sono, se non con l'open source perché ci sono problemi di sicurezza e/o qualità, con altri metodi.
Visto che siamo in momenti di crisi (e che dove sono io i salari non sono come i vostri) l'importante è non buttare via soldo alcuno per licenze o applicazioni facilmente ottenibili con altri metodi di cui io sono un avanzato praticante ...
In definitiva sono d'accordo a collaborare anche economicamente se non togliamo ai poveri (noi) per dare ai ricchi (le soft house) inutilmente.
Di tempo ne ho pochissimo in questi tre/quettro mesi a venire, ma cercherò comunque di rendermi utile.

ma c'è ancora qualche sventurato che usa libero per la mail?

5 sensi? Vorrà mica dire che non si possono mollare le puzze in santa pace? 

quanti mac hanno i lettori di SD incorporato?
si può installare l'OS da SD?
quanti formati esistono di queste memorie solide? E se a chi la porto non ha il lettore per quella che uso io?

Non sono contrario alla sostituzione di tecnologie vecchie, però prima me le sostituite con qualcosa di standard e che tutti possano usare.

...pertanto non posso circoscrivere un'area ben precisa dove definire un pulsante.

Non c'è bisogno di circoscrivere un'area ben precisa...

Un trigger su entrata campo ed il contemporaneo uso del Get ( ActiveSelectionStart ) ti renderà possibile riconoscere su quale parola è stato fatto il click 

Questa cosa mi interessa, ma trovo l'uso degli elementi di login la strategia sbagliata.

Meglio usare launchd ed un bel LaunchAgent, che sono fatti proprio per fare queste cose.

Proporrei come nome com.tevac.loginsound

0) Identificare il file audio che si vuole far suonare all'avvio. Nel mio caso il file è ~/Music/login.mp3. Se volete che la path sia diversa o che il file abbia diversa estensione, basta modificare la riga corrispondente nella plist.

1) Scrivere la plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.tevac.loginsound</string>
    <key>EnableGlobbing</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/afplay</string>
        <string>~/Music/login.mp3</string>
    </array>
    <key>RunAtLoad</key>
   <true/>
</dict>
</plist>

e salvarla come

~/Library/LaunchAgents/com.tevac.loginsound.plist

Per fare tutto in un colpo solo senza dover usare nessun editor, copiare il codice della plist e poi scrivere (non copiare altrimenti il contentuo della clipboard viene ovviamente sostuito):

pbpaste >~/Library/LaunchAgents/com.tevac.loginsound.plist

2) Caricare la plist

launchctl load ~/Library/LaunchAgents/com.tevac.loginsound.plist

e testare che funzioni (eventuali errori andranno a finire in /var/log/system.log). Se si sente l'audio allora funziona. Se non si sente l'audio al 99.9% c'è un problema di path.

4) Fare logout/login e rallegrarsi se tutto funziona o inveire contro di me se non funziona nulla o peggio

(non ho testato una riga che sia una di quanto scritto). Ho testato e funziona.

5) Per disinstallare il tutto:

launchctl unload ~/Library/LaunchAgents/com.tevac.loginsound.plist

rm !$

(in risposta a cristiano)

iTunes? Quella oscena applicazione per sentire la musica? No grazie. L'unico motivo per cui esiste iTunes è per vendere beni digitali sotto stretto controllo di censura. Per me resta quello che era all'inizio: un player musicale. Un terribile player musicale. 

Per la Apple, una cosa che si chiama iTunes dovrebbe essere quella che si occupa di trasferire i miei dati tra i miei device. La stessa cosa dovrebbe essere quella che gestisce la mia identità digitale. Folle. Dal punto di vista UNIX (che, seppur violentato in ogni modo, è quella cosa che permette ad apple il suo impero, e che ha attratto una moltitudine di programmatori verso la sua piattaforma) è una bestemmia. Un programma deve fare una cosa, e deve farla bene (UNIX dixit). iTunes bene fa solo una cosa: fa fluire soldi nelle tasche della apple e delle lobby/multinazionali complici del suo gioco.

A proposito del "sandbox" di iOS: iOS usa Mach e BSD, esattamente come OSX. Mach è il kernel. Il kernel è quella parte del sistema operativo che supporta le applicazioni, fornendo l'accesso a basso livello alle sue risorse. Vuoi aprire un file? Chiedi al kernel, usando una system call, di fornirti un file descriptor che utilizzerai per lavorare con il file. Il punto base di un sistema UNIX è che tutto è un file. Il filesystem organizza questo "tutto" in modo gerarchico.

Precisato questo, in iOS, quando installi una applicazione, non installi solo l'application bundle (una applicazione è una cartella che contiene principalmente il binario e le resources che utilizza), ma una cartella che contiene il bundle ed una copia "segregata" dei documenti gestiti dall'applicazione, la sua libreria, etc.

In pratica, piuttosto che sfruttare la file system hierarchy propria di tutti i sistemi UNIX, questa viene replicata per ogni applicazione. Nulla di trascendentale. Io faccio lo stesso con i miei programmi perchè preferisco avere, per esempio, i file di configurazione in /usr/local/myapp/etc/myapp.conf piuttosto che in /etc/myapp/myapp.conf, in modo da avere un posto solo che contiene tutto quanto riguarda l'applicazione. Per il resto esistono i link simbolici (che hanno i loro problemi, ma anche le loro virtù). Sono programmatore prima di essere un sistemista, e preferisco mentalmente questa separazione. Un sistemista preferisce l'altra opzione, perchè deve operare su macchine di cui non conosce necessariamente la genesi.

Circa l'argomento sicurezza: Apple dice che il motivo principale dell'esistenza delle sandbox in iOS è per impedire ad una applicazione "compromessa" di fare danno al sistema (e alle altre applicazioni). Notare il termine "compromessa" (da chi?). In UNIX esiste un bellissimo sistema di gestione dei permessi che gli utenti hanno di operare sui file (che, ricordo, in UNIX sono qualsiasi cosa. anche una stampante laser o la scheda audio, per il sistema operativo sono dei file da cui leggere o su cui scrivere). Un'altra cosa bellissima che esiste in UNIX si chiama setuid/setgid, un flag che possono avere i file eseguibili, che setta lo user ed il group del processo al momento dell'esecuzione del file. 

Hai presente come funzionano i processi in UNIX? Sommariamente, è un rapporto padre-figlio (e orfani). Il processo figlio eredita dal processo padre i privilegi di accesso alle risorse di sistema. Ovvero, se esegui una applicazione che può fare solo determinate cose, e se questa applicazione genera altri processi, questi processi si troveranno impossibilitati a fare cose che il processo padre non è autorizzato a fare. E' il concetto di base che rende i sistemi UNIX molto sicuri, quando utilizzati correttamente. La "sandbox" già esiste, ed è integrata in UNIX. Funziona da quando UNIX è stato scritto, nonostante Apple.

Come per magia, un file, nel momento in cui lo straferisco sul device, secondo la Apple non è più mio, ma dell'applicazione, installata nel sistema passando per il suo store, che sarà autorizzata a gestirlo. Quello che accade in iOS sostanzialmente è questo:

• ogni applicazione dichiara al sistema operativo quali URL Scheme gestisce. Il termine URL, che mediamente viene associato al browser, ha una semantica molto più ampia. Vuol dire Universal Resource Locator, ovvero è un meccanismo per identificare univocamente una risorsa, qualunque essa sia, ovunque essa sia. Lo "schema" (http:// ftp:// file:// skype:// etc etc etc) permette di associare la path della risorsa ad un programma che ha dichiarato la sua capacità di gestirla.
• i "file" ovvero i "dati" sono contingentati all'interno dell'applicazione che li gestisce.
• quando una applicazione vuole utilizzare un file che non è segregato nel suo sandbox, l'applicazione deve chiederlo al sistema operativo, attraverso una URL. Per le limitazioni imposte dal "sandbox", risulta che l'applicazione non può ottenere il file dall'altra applicazione, e piuttosto risponde: "Questo file non è tuo. Se vuoi utilizzarlo non puoi. Ci penso io, tu fatti da parte. Eseguo l'applicazione che lo possiede."

Cosa vuol dire tutto ciò? Vuol dire che i file non sono più tuoi, ma delle applicazioni che li gestiscono, e del sistema operativo che delega le operazioni in base alle sue regole. Questa è sicurezza aggiunta? No. Questa è solo una scelta (sacrosanta) a livello di UI/UX. Io sono perfettamente d'accordo che il filesystem debba essere "nascosto" all'utente. E' un dettaglio di implementazione e deve restare tale. E' roba a basso livello. L'utente normalmente non deve vederli i file, ma deve lavorare con delle loro rappresentazioni. Non deve curarsi di dove i file siano collocati. Il paradigm shift non fa una grinza da questo punto di vista. Fa acqua da tutte le parti invece quando la apple argomenta queste scelte in termini di sicurezza aggiunta e per questo motivo preclude l'accesso al filesystem e l'interoperabilità dei dati tra applicazioni diverse. Non è una conseguenza della scelta fatta. Anche io seguo la stessa filosofia, e creo gli stessi sandbox, ma il filesystem lo posso continuare ad utilizzare (anzi, mi curo di rendere le operazioni fatte da interfaccia grafica o da filesystem/commanline simmetriche).

Vietare adducendo fantasione motivazioni è ipocrisia. E' una storia che si ripete, solo con facce diverse. Ricordate il bando della canapa? Vieti l'uso di cannabis perchè sotto effetto di cannabis le persone diventano violente e mangiano i bambini. Non è vero. La verità è che vieti la cannabis per difendere i tuoi business (carta, fibre tessili, petrolio, industria farmaceutica, ...). E sei talmente potente da riuscire a metterla al bando in tutto il mondo, quando fino al giorno prima, tutto il mondo ci mangiava, con la cannabis e le sue infinite proprietà.

Vietare vuol dire nascondere.

La Apple dica le cose come realmente stanno:

• non puoi accedere al filesystem perchè non voglio permetterti di avere controllo su quello che hai comprato.
• Voglio essere in grado di verificare ed autorizzare qualsiasi cosa che funziona sul "tuo" device, perchè quel device prima di errere tuo è mio, ed ha il mio logo stampato dietro, ed io non voglio metterti in condizione di farmi potenzialmente brutta pubblicità, perchè se sul "tuo" device c'è un programma che fa vedere biancaneve ed i sette nani mentre allegramente se lo mettono nel culo a vicenda, ed un possibile mio futuro cliente lo vede e per questo, per difendere la pudicizia sua e del suo amato figliolo, non comprerà il mio costoso gadget (prodotto ovviamente in paesi dove è ancora possibile sfruttare la manodopera), io ci perdo soldi (unica cosa che mi interessa). Ed io questa cosa proprio non la voglio permettere.
• Non ti faccio accedere anche perchè non voglio che tu possa scrivere, per esempio, un browser che supporti WebGL (nulla di tecnicamente problematico, visto che sono perfettamente supportate ed attivate, anche se **solo** se stai producendo un iAd), perchè altrimenti tutto il mio fiorente mercato dei giochini venduti dall'apple store rischia di andare a puttane, ed inoltre non posso più censurare le parolacce, le tette, culi e le mazze di biancaneve e dei suoi amici nani.
• Vuoi nonostante questo scrivere un browser? Puoi, solo che devi usare una UIWebView, che ti fornisco io, e che ti de-potenzio in modo tale che il mio Safari sia comunque un po' + veloce del tuo browser, e che tu non possa implementare nulla di quello che io ho marcato come "non conveniente per me".
• E non provare ad usare una di quelle API "segrete" perchè quelle le uso solo io, e se mi chiedi di vendere una applicazione così io non te la vendo (e rinuncio volentieri alla mia fetta del 30% e alla gabella annuale del programmatore, perchè tanto ho fatto i miei conti, e ci guadagno di più così). Vuoi vendertela da solo? Fottiti. Non ti permetto di farlo.
• ...

Per fortuna la soluzione a tutto questo schifo c'è, e si chiama web. Ma per fare in modo che non venga ucciso da player che fanno lo stesso gioco della Apple, sta a noi sforzarci di essere un po' più ingegneri e un po' meno larve (come ottimamente descritto dall'immagine postata da sauro). L'ignoranza e la comodità fanno il gioco di questi porci, che si ingrassano di denaro mentre noi ci ingrassiamo dei veleni che ci propinano.

Io ho l'impressione che quest'approccio totalmente prono alla comodità-e-nessun-pensiero-per-utente e poco - diciamo - maieutico, ci fa somigliare sempre più a loro (opinione strettamente personale):

Per avere informazioni più dettagliate (ed aggiornate in realtime):

nettop

Al solito, consultare la pagina del manuale per informazioni su opzioni e flags:

man nettop

http://wiki.tevac.co...ione_a_Internet

lsof -P -i -n | cut -f 1 -d " " | uniq
 

Ma c'è il limite di 250 MB per documento. Non vi risulta seccante?

 

D

Il problema si aggira con facilità:

# compress & split

tar cz a-big-file | split -b 250M - a-big-file_splitted.tgz_

# concatenate & uncompress

cat a-big-file_splitted.tgz_* | tar xz

In Germania è nato Foodsharing che rende diffuso il recupero del cibo, in Italia attualmente molte catene distributive hanno accordi con associazioni di volontariato, etc. con Foodsharing la pratica viene estesa alla cittadinanza anche al di fuori delle associazioni e la cosa mi piace anche perché in passato non sono state poche le associazioni speculavano sulle donazioni, meglio evitare intermediari.. Personalmente non ho nulla contro i prodotti prossimi alla data di scadenza che è in genere molto prudenziale, se i prodotti sono stati correttamente conservati possono essere tranquillamente consumati anche tempo dopo, da distinguere la dicitura "scade il" da quella "consumare preferibilmente entro il", sono due cose diverse, la prima è più stringente mentre la seconda ha molto più margine..

[OT]

Aaaah, le 3 forme normali dei database relazionali! Erano almeno un paio d'anni che non mi passavano per la mente.

Oramai per tutte le mie esigenze di persistenza uso redis. Disorientante all'inizio, ma poi è come giocare con i mattoncini lego, piegati al servizio del db.

E come linguaggio di scripting, per rendere atomiche anche le operazioni più complesse (leggi transazioni in gergo *SQL), utilizza lua, che per quanto a livello di sintassi mi fa lo stesso effetto di un pugno di sabbia gettato negli occhi, è eccellente.

Magari per alcune cose i database relazionali hanno ancora il loro posto, ma fortunatamente è finito il tempo in cui erano l'unica opzione possibile (in quanto per moltissime cose intrinsecamente scomodi, macchinosi e non performanti). Inoltre, per quanto la teoria della normalizzazione dei dati è quasi universalmente riconosciuta come pratica buona e giusta, presenta dei problemi (che nel contesto di filemaker magari non sono così rilevanti).

Per chi fosse interessato ad approfondire l'argomento, una rapida ricerca su google mi ha prodotto questo essay:

http://www.ibm.com/d...tion/index.html

http://www.ibm.com/d...art2/index.html

[/OT]

Salve

 

continua la mia esplorazione di questo prodotto tanto accattivante, ma forse da comprenderne meglio la filosofia.

Mi chiedevo come sia possibile effettuare una ricerca su più formati.

 

Esempio:

ho una tabella Allevatori, una Agricoltori ed una Pescatori.

 

<Ricerca tutti i signori Rossi...come si fa ?>

Si fa come ti ha consigliato Threedance.

Pero' se ti trovi con questa esigenza, probabilmente il database non è strutturato correttamente. I valori "Rossi", che sono cognomi, devono stare tutti nella stessa tabella "Persone". Non ce ne possono essere anche in altre tabelle! Come ora hai un problema di ricerca, domani potresti avere un problema di modifica. Il dato deve essere in un posto solo, per rispettare la "prima forma normale" dei database.

Stessa cosa, se hai "Pescatori", "Agricoltori", "Allevatori", penserei di creare una tabella "generi" con i campi: "Genere" (valori possibili: Allevatore, Pescatore, Agricoltore, Cacciatore... ), e "CodicePersona" che rimanda alla tabella "Persone" per i dettagli (Cognome, Nome, Numero di scarpe) di ciascuna persona. A questo punto i dati sono unici e correlati. Ricerche e modifiche funzioneranno correttamente.  Inoltre, se il sig. Rossi va a caccia, pesca, e coltiva l'orto, il tutto comparirà nel portale della sua  scheda Persona.