OpenScape > OpenScape - Business

OpenScape Business: considerazioni Off Topic su tecnologia e metodo

<< < (2/2)

Kimera:
No problem.

Dubito di essermi incaponito permalosamente per ciò che hai scritto solo perchè hai citato Linux (sono critico con tutti...anche con alcuni aspetti delle distribuzioni Linux, ma in altre sedi)...ma ancora mi sfugge il motivo per il quale hai scritto quello che hai scritto come l'hai scritto...solo per dire che in Siemens non progettano/realizzano delle sciocchezze che invece un "cantinaro" è più predisposto a fare (sperimentando con Linux, ovvio!)...e, guarda un pò, portando ad esempio un'associazione "sistema operativo" (Linux, è ovvio!) + "servizio" (SAMBA) che può o meno essere frutto di esperimenti abbozzati da "cantinari" o essere invece la scelta dettata da precise feature ideate da "corporation" (questo però l'ho aggiunto Io)...mai che viene in mente, quando si tratta di tirar fuori paragoni, di (1) dissociare gli esperti/inesperti dagli strumenti messi loro a disposizione e (2) di andare a vedere "altrove" cosa combinano gli esperti/inesperti tenendo conto del fatto che (3) quanto più un sistema (ed i suoi componenti) sono "liberi" tante più combinazioni esso fornisce agli sperimentatori e dunque gli esperti/inesperti possono creare combinazioni sensate o meno, ottenendo ovviamente risultati sensati o meno.

Sinceramente l'unica distinzione che farei (per poi usarla come termine di paragone generico) è: da una parte, esperto (o gruppo di esperti o azienda) che sperimenta/realizza un sistema con componenti complessi (open/closed...non importa) ben armonizzati in funzione di uno scopo specifico e definito e, dall'altra, tutto il "rumore" (il sottofondo che sperimentano i "cantinari") che rimane..."rumore" che ha un suo ruolo, passami il termine, quasi necessario...se non addirittura essenziale e benefico...perchè aiuta, nel medio/lungo periodo, le varie comunità (esperto, gruppo di esperti, aziende, mega-corporations) a capire cosa far emergere e come fare a realizzarlo al di là di (e prima di) certi classici schemi di marketing (magari questo non vale per le aziende...).

Fine OT. Lunga vita a tutti.

Hunter:

--- Quote from: Kimera on April 19, 2014, 06:59:27 pm ---...ma ancora mi sfugge il motivo per il quale hai scritto quello che hai scritto come l'hai scritto...solo per dire che in Siemens non progettano/realizzano delle sciocchezze che invece un "cantinaro" è più predisposto a fare (sperimentando con Linux, ovvio!)

--- End quote ---

Non ho parlato di "sciocchezze" ho detto che non abbiamo a che fare con un "cantinaro" che sta mettendo su una paittaforma telefonica e che non avendo un, chiamiamolo così, "controllo qualità", in genere mette in giro distribuzioni buggate risolvendole (se è in grado) man mano che i clienti acquistano il suo prodotto e lo provano, spesso e volentieri lasciando anche dei "bachi giganteschi" nella sicurezza o nell'utilizzo per giorni, settimane, mesi...

Ti faccio un esempio pratico.

Qualche tempo fa abbiamo acquistato un APP su Google Play, in Java compilato con l'SDK Android. Ebbene utilizzandolo il software presentava diversi BUG, alcuni abbastanza insignificanti, altri ne rendevano praticamente impossibile l'utilizzo corretto.

Ho segnalato i bug allo sviluppatore, per i bug semplici ci è voluto qualche giorno, per i bug "complessi" ci è voluto più di un mese...e alla fine senza risolverlo e sai cosa mi sono sentito dire!? "Io non sono uno sviluppatore Java, lo faccio nel tempo libero quindi..." (non rompermi i coglioni) l'ultima parte l'ho aggiunta io anche se era sottointesa.

Quindi: ho dovuto decompilare il codice dell'APK e cercare di capire dove stesse il problema. Ci ho messo giorni, rottura di scatole, e sbattimento, perchè JAVA sembra qualcosa che nessuno sa bene che forma abbia, quindi facendomi aiutare da dei tutorial trovati su internet e da altri sviluppatori più o meno esperti su dei forum, e armato di una pazienza biblica, e della consueta sagacia del tecnico (ossia continuo a provare e a sbagliare finchè non lo faccio giusto) alla fine ho risolto il problema autonomamente.

Ora capisci a cosa mi riferisco!?

Riesci ad immaginarti una persona che si mette a decompilare il codice del sistema operativo (chiamiamolo così) dell'HiPath 3500 o dell' OSBiz per risolvere un bug!? Io no. Avrei aperto un ticket sul portale di Unify e avrei atteso la soluzione o una risposta di un work around.

Questa è la differenza tra un "cantinaro" e un grande distributore.

Kimera:
Inizio ad appassionarmi a questo Thread che deve andare in OT!

Guarda che l'esempio (iniziale) che hai fatto è proprio l'esempio di uno che fa sciocchezze (colui che mette assieme "pezzi" senza un senso e senza preoccuparsi delle conseguenze o senza fornire un adeguato supporto tecnico).

Riguardo l'esempio della App, ancora, non è utilizzabile come termine di paragone...perchè, in primis, penso che (1) il mondo delle App (relativo ad Android soprattutto visto il modello "lasco" rispetto ad iOS) sia una galassia (ben incasinata a mio avviso) a sè stante e, in secondo luogo, perchè (2) non ha nulla a che vedere con il mondo di chi costruisce "sistemi" (infatti non stai parlando di una smartphone ROM più o meno buggata realizzata da un "cantinaro" cosa che, per altro, con gli SDK che ci sono in giro non è infrequente...e si avvicina di più all'esempio di chi realizza un "sistema" accozzando pezzi di software realizzati da altri/da aziende rispetto a quello che fa Google stessa o qualche altro Vendor quando rilascia la "sua" versione di Android per un "suo" modello specifico di Smartphone).

Quello che ti è capitato con una App (che è una applicazione user land e non un componente essenziale di sistema, leggi ancora "Android") è quello che ti può capitare quando utilizzi degli applicativi (più o meno complessi) fatti da singoli per necessità specifiche...applicativi che possono o meno essere manutentati a dovere e che possono o meno avere un ciclo di vita serio alle spalle, ciclo che potrebbe non coincidere con il ciclo di vita del sistema sul quale sono installati.

Ti faccio invece Io un esempio in tema di sistemi telefonici: IP-PBX per un cliente, stavo orientandomi prima su Gigaset T300/T500 Pro ma ho visto che i rilasci sono infrequenti, non c'è un Forum, non c'è un portale TRAC o similare (c'è però un buon Wiki), sembra non esserci supporto in Italia (nè un Partner che li apprezzi, ed Io ho avuto modo di apprezzarli almeno in linea teorica)...questo mi ha spinto ad orientarmi verso la fonte, Starface (Germania)...poi ad osservare i relativi Forum (tedesco ed inglese) si scopre che ci sono bug (o problematiche), sollevate soprattutto da utenti non tedeschi, che sembra non abbiano mai ricevuto risposta o che non abbiano avuto un loro seguito con esito positivo...oppure si scopre che il tutto è molto orientato al mercato tedesco ed austriaco...questo nonostante il fatto che il ritmo dei rilasci è molto più "intenso" rispetto ai rebranded Gigaset Pro. Interessante la sezione in cui gli utenti registrati possono eprimere le loro Feature Requests (qui). La sensazione di "colla" però non mi molla...eh eh...scusa la rima.

Lascio stare...poi mi sono messo a studiare FreePBX Distro (non FreePBX ma proprio una appliance fornita come Distro specifica)...ambiente CentOS (con il quale mi sento a mio agio almeno per risolvere le problematiche più superficiali), Asterisk e FreePBX (con moduli commerciali anche a pagamento) e più di un anno fa ho iniziato a fare qualche esperimento (AKA studio) su un sistema prototipo: il passaggio ad un sistema di produzione (con 15 utenti) è stato indolore ed il traguardo dei 2 anni senza alcun problema è alle porte.

Nota bene che non sto paragonando il prodotto A con il prodotto B o l'azienda X con l'azienda Y nè la feature N offerta da A con la feature M offerta invece da B, ma cosa sta dietro tutto questo.

Il punto infatti non è tanto la scelta del prodotto o del singolo (o dell'azienda che lo supporta/realizza)..ma del tipo di comunità (che include gli sviluppatori) che si prende cura delle migliorie e della risoluzione delle anomalie (e non è questo un controllo qualità? ...quando hai centinaia di occhi puntati su di te...): su questo punto non potevo che far la scelta che ho fatto...ho un contatto diretto (segnalazione bug -> risposta developers -> soluzione...loop che si può chiudere anche nel giro di ORE) con gli sviluppatori e mi sono accorto che non c'è cosa migliore (un rapporto simile è anche migliore del prodotto stesso, in sè) perchè se vuoi che venga introdotta una miglioria non hai che da proporla in modo sensato (in tema FAX Server ne ho richieste non poche ed alcune sono già state implementate), documentando lo stato di fatto e quello che sarebbe bene ci fosse o venisse rivisto.

Quindi esperienza totalmente positiva (con altri prodotti/sistemi mi sono invece trovato malissimo) ma non dipende dal prodotto o dal team di sviluppatori (o dall'azienda che c'è dietro)...dipende dalle persone che ci sono e dalla passione che ci mettono. E qui si potrebbe aprire un bel dibattito...infatti mi piacerebbe vedere (anche se non vi è il modo) qualche statistica relativa al sistema di Ticketing (Issue, Feature Request) di Unify per le SMB...mi piacerebbe tanto...per poter concordare con te che conviene (a prescindere) attendere una soluzione o una risposta dal supporto tecnico (qui qualcuno potrebbe dire che ha anche contatti diretti con sviluppatori o con Product Manager ma sono contatti speciali e non valgono - non sono di beneficio - per la maggior parte di tutti gli altri user/tecnici). Mi piacerebbe poi sapere se c'è un Regression Testing serio, con che statistiche...e visto che tutto è Linux based (ovviamente sarebbe interessante sapere qual'è il contributo che torna alla comunità dall'uso così intensivo di Linux in prodotti commerciali così altamente closed), sarebbe interessante sapere anche come è possibile che ci siano certe instabilità di sistema (sfoglia le R.N. e valuta tu...) nonostante il tutto sia realizzato da una azienda che ha una "potenza di fuoco" tecnologia così elevata.

Di per sè questo NON vale solo per Unify/Siemens (sono corporation e non scoprono i loro meccanismi interni esattamente come non scoprono il codice closed che utilizzano nei loro prodotti) ma vale per tantissime altre realtà che non hanno (nel loro DNA) un certo modello di sviluppo del prodotto che non assimili l'utente ad un mero cliente ma lo tratti come una parte integrante ed attiva del prodotto stesso.

Sono personalmente conscio di un limite invalicabile (invalicabile da entrambi i lati alle volte): parlando di me, mi sento un Amministratore di sistema, forse anche un utente avanzato...ma so di non poter essere (o diventare) uno sviluppatore (non ho conoscenze di Java, C, di reverse engineering o di cross-compiling, ottimizzazione del codice, profilazione di sistemi embedded, ecc.)...quindi arrivo fino all'analisi (alle volte anche profonda) di un problema o di una esigenza...dall'esterno di un sistema...ma il compito di provvedere internamente ad esso lo lascio a personale che ne ha la qualifica (e qui ritorna l'importanza del contatto con - e della presenza diretta degli - sviluppatori). Ovviamente tanto più un sistema è aperto tanto meglio è...perchè posso usare le mie competenze di Linux come sistemista per tentare di capire a che livello è la problematica, se il codice è chiuso allora è obbligatorio affidarsi a chi ha le chiavi del castello.

A questo livello non centrano più i cantinari o le aziende strutturate...qui entra in gioco un certo tipo di modello di sviluppo che riguarda una certa classe di prodotti (bella ampia direi visto che si spazia dalle App per Android fino ai sistemi di telecomunicazioni, dai sistemi operativi fino alle appliance specifiche).

P.S. I
Vedremo riguardo l'OpenSSL bug noto come HeartBleed in che termini ed in che tempi si muoveranno...visto che è un baco il cui impatto ha effetti potenzialmente enormi (trovami un sistema che non lo usi per implementare l'SSL) e potrebbe essere presente in più di un loro sistema/applicativo (tanto per citarne uno: il ComWin 5.0 è già stato aggiornato...mentre pare che in HiPath Xpressions V6 siano al riparo causa versione "obsoleta"). Follow-Up...sto pensando infatti che, magari, sono pure fortunati...magari utilizzano una versione di OpenSSL non affetta da quel bug in particolare (Ad esempio la OpenSSL 0.9.8)...da un lato ciò è ottimo...perchè elimina il problema alla radice, dall'altro però vai poi a spiegare perchè sistemi in funzione (magari da anni) non vengono aggiornati a dovere su componenti così sensibili (benchè non deprecabile è altrettanto vero che l'uso di un componente OpenSSL in versione pre-1.0.1 sia poi così tanto auspicabile...). Una bella lama a doppio taglio.

P.S. II
HiPath 3000 e OpenScape Office hanno basi tecnologiche ben differenti: HiPath 3000, come d'altra parte i predecessori Hicom 150E/150, è una piattaforma con un suo sistema operativo che definire closed è davvero eufemistico, è intrinsecamente closed perchè è embedded ed è essenzialmente legato all'Hardware (ed è talmente aderente all'ecosistema Hardware - CPU Motorola Coldfire RISC, I/O boards - che non è considerabile come un OS General Purpose come, ad esempio, può essere pensato un sistema "Linux Kernel based"...anche se proprio nell'ambito dei sistemi "Linux Kernel based" - o "BSD Kernel based" - ci sono sistemi altrettanto "embedded" che non sono certo stati creati con l'intento di essere dei sistemi operativi General Purpose...soprattutto quando si tratta di sistemi che devono operare in Real Time nei confronti delle sollecitazioni che provengono dal mondo esterno).
Esempi: HiPath Cordless IP, HiPath Xpressions Compact (meno), OpenScape Mobile, HiPath 2000, HiPath Wireless (stand-alone), ecc. ...tanto per citare linee di prodotto per piccoli sistemi.
Per OpenScape Office (e, in una certa misura, credo lo stesso discorso valga per OpenScape Business) il discorso è molto diverso...come lo è stato da HiPath 2000 in avanti...infatti tali sistemi sono leggermente meno vincolati ad Hardware specifico dei loro predecessori (prova ne è che puoi anche simularli tramite macchine virtuali...hai mai visto un simulatore per HiPath 3000? c'è per l'HG1500 - che gira grazie a VxWorks - ...ma non per HiPath 3000...anche se penso che in Siemens ce l'abbiano per ovvi motivi di engineering); per tali sistemi il solo fatto che siano Linux Kernel based apre una miriade di opzioni (tutte però negate all'utenza esperta/sistemistica) di gestione, anche a basso livello...se gira su Linux allora deve sottostare, in User Space, alle stesse regole che una distribuzione General Purpose di Linux rispetta. Ci saranno inevitabilmente delle differenze di architettura...ma se arrivi ad una Bash...scopri che molti servizi sono gestiti alla stessa maniera. Di qui nasce una considerazione: a questo "livello" è ammissibile fare sviluppo allo stesso modo in cui esso è ammesso in altri prodotti/sistemi Linux based...il punto è che NON è consentito e non è nemmeno una cosa che è mai stata presa in considerazione dal Vendor (esporre il "nocciolo del sistema" non è cosa buona per un'azienda che basa una linea di prodotto su queste premesse: software applicativo closed source che poggia su un sub-strato software - Kernel e Servizi - misto open source e closed source).
Per OS Office o OS Business, termini come "decompilare il codice del sistema operativo" non hanno gran senso mentre ha molto più senso (perchè sarebbe possibile benchè non sia appunto ammesso) effettuare uno sviluppo del sistema esponendo parti che sono celate all'utenza avanzata proprio perchè (1) si può e (2) tale utenza già è abituata a tali "esposizioni" in altri prodotti/sistemi. Pensa se Siemens/Unify permettesse di correggere (cosa banale) errori di traduzione nell'interfaccia web (sono stringhe!) come avviene normalmente in altri ambiti, il tutto tramite un portale web...pensa quanto velocemente simili aspetti di un sistema sarebbero stati migliorati...pensa poi a tutto il resto (servizi, analisi dei Log di sistema, hardening, profilazione...). Pensa se, esplorando il sistema, un utente esperto riesce a scovare una anomalia prima che questa si trasformi in un bug che colpisce il sistema (i bug possono emergere anche prima che inizino a manifestare i loro effetti negativi). Tutto è fatto all'oscuro dell'utenza, dentro il castello e se hai un problema devi inserire la "letterina dentro la cassetta postale" (il Ticket nel portale) ed aspettare che qualcuno ti risponda nei tempi e nei modi più opportuni.

P.S. III
Tutto quanto detto però, nel caso specifico di prodotti Siemens/Unify, ed in particolare (ma non solo) per HiPath 3000 V9 (immaginatevi voi per tutto il resto...), non si può applicare SENZA CONSIDERARE seriamente (per le conseguenze Legali che comporterebbe un sua infrazione) la relativa EULA: il sistema stesso (il Software/Firmware...non tanto l'Hardware) è di proprietà di Unify (formerly Siemens Enterprise Networks) e viene concesso in licenza da Unify o da terze parti per far funzionare l'Hardware sottostante (il cui engineering, comunque, è evidentemente coperto da Copyright e/o da Brevetti).
La relativa EULA, che qui allego, offre la "misura" di cosa resta ad un utente (o ad un amministratore/tecnico) da poter fare quando usa il sistema o quando deve affrontare un problema. Altro che "decompilazione del codice"...di che ci stiamo lamentando? che stiamo paragonando?

Lucky:
Non so se qualcuno di unify ha letto i connenti nel forum, sta di fatto che nell' ultima release (v1 r3.1.0) hanno tolto la condivisione samba, fornendo link ai software e togliendo la possibilità di scaricare i backup locali.
Ciao

Kimera:
Mi pare che la cosa sia stata indicata nella "Unify - Technical Newsletter SME - July 2014":


* New Default SSL certificate in OpenScape Business V1 R3.1.0
* New CMA module
* Samba Share
* Slot for OCAB in wall mount systems
* Remote Access
Edit: dubito che la rimozione del servizio Samba abbia a che fare con le nostre elucubrazioni...forse si sono accorti che, di per sè, è un servizio che comporta una maggior superficie di vulnerabilità (insicurezza del sistema): quindi meglio eliminarlo.

Navigation

[0] Message Index

[*] Previous page