BlueDSL sposa Bluetooth, ADSL e... Linux

Inventel ha annunciato un nuovo punto d'accesso Bluetooth basato su Linux che affianca alla connettività wireless quella ADSL e LAN


Parigi – Inventel , un produttore francese di dispositivi wireless, ha annunciato la disponibilità di BlueADSL, quello che a suo dire è il primo punto di accesso Bluetooth ad integrare un modem ADSL.

Oltre alla connettività wireless Bluetooth 1.1 e alla connettività a larga banda ADSL, Inventel ha integrato sul proprio punto di accesso una porta Ethernet, una porta USB, un router e una base DECT (voce).

L’azienda sostiene che BlueADSL può essere direttamente collegato ad una linea telefonica analogica (PSTN) o digitale (ISDN) con contratto ADSL e consentire la creazione di una rete domestica privata wireless che permette l’accesso ad Internet e le comunicazioni telefoniche: il tutto senza uso di cavi.

BlueDSL supporta le Personal Area Network (PAN) e consente di effettuare comunicazione wireless in un perimetro che può arrivare fino a 100 metri per le apparecchiature Bluetooth di Classe 1 o raggiungere distanze maggiori con i dispositivi di Classe 2 e 3.

BlueDSL integra anche un sistema operativo Linux che gira su chipset ARM ed una memoria ripartita fra 8 MB di Flash e 16 MB di SDRAM. Questa caratteristica, insieme al kit di sviluppo acquistabile sul sito di Iventel, fa di BlueDSL una piattaforma su cui poter sviluppare applicazioni.

BlueDSL può essere aggiornato dall’utente finale attraverso un semplice telecaricamento da un sito FTP disponibile a tutti. Questa operazione consente di aggiungere nuove funzionalità, attivare nuovi servizi o migliorare le prestazioni di BlueDSL.

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Anonimo scrive:
    ANTI IBM E SUN UNITEVI non vogliamo mai
    più la pubblicita di ibm su punto-informatico.oltre a dar fastidio con quel colorito verde (verde come le tasche di chi ha compra i loro prodotti)ma quello che fa girare ancora di più le gonadi e la promessa di maggior sicurezza specifichiamo please, sicurezza dagli hacheronzoli (ma se non erro i db dovrebbe per loro stessa natura stare dietro una DMZ quindi fuori da qualunque attacco poi c'è sempre il pir.. che lo istalla sul server web ma questi sono casi pietosi) oppure sicurezza nel non perdere i dati peccato che lavoro in un ced dove sfortunatamente sta ca.... viene usata e le notti che ho passato per ripristinare dati persi le metterei tutte in conto alla IBlemme.scalabilità ma avete mai visto un database db2 scalare e poi cosa il monte bianco.
  • Anonimo scrive:
    Potrebbero fare società con Xerox
    dato che produrranno portali-fotocopia di qualità superiore
    • Anonimo scrive:
      Re: Potrebbero fare società con Xerox

      dato che produrranno portali-fotocopia di
      qualità superioreSarebbe pure l'ora delle fotocopie a colori no? :)
  • Anonimo scrive:
    Perdite di tempo
    La vita dello sviluppatore sta diventando un incubo: escono fuori continuamente nuove tecnologie, protocolli, ecc. che dovrebbero migliorarne la vita ma nella realtà la complicano e servono solo a gonfiare d'orgoglio i relatori aziendali con le loro ridicole slides.Java sembra sempre più un'operazione commerciale.. anziché perdere tempo perché non si decidono a realizzare un vero compilatore?
    • Anonimo scrive:
      Re: Perdite di tempo
      Sarebbe carino un compilatore che dai .class possa compilare degli eseguibili, vero ?Ma sarebbe troppo facile e bello: bisogna che sia compilato il tutto "al volo" con il JIT e -poi- dopo l'esecuzione, buttato tutto via (per sprecare -al prossimo avvio dell'applicazione-, un'altra volta la stessa CPU ... altrimenti che te ne fai ?).Java è un ottimo linguaggio ed una splendida tecnologia (.NET è semplicemente una copia rivista e corretta) lanciati però prevalentemente per scopi commerciali (cioè senza alcune features che possono risultare "scomode").E' per questo che ci sono delle iniziative OpenSource che stanno lavorando per risolvere questo serio problema: gcj, classpath, ecc. ti dicono nulla ?Nessuno a carattere commerciale potrebbe fare cose simili senza incorrere nelle ire di Sun.Dai un'occhiata.Gano
      • Anonimo scrive:
        Re: Perdite di tempo


        Java è un ottimo linguaggio ed una splendida

        tecnologia (.NET è semplicemente una copia

        rivista e corretta) lanciati però

        prevalentemente per scopi commerciali (cioè

        senza alcune features che possono

        risultare "scomode").potresti motivare _tecnicamente_ le tue affermazioni? potrebbe venirne fuori un dialogo costruttivo ed interessante...
      • Anonimo scrive:
        Re: Perdite di tempo
        - Scritto da: Gano
        Sarebbe carino un compilatore che dai .class
        possa compilare degli eseguibili, vero ?

        Ma sarebbe troppo facile e bello: bisogna
        che sia compilato il tutto "al volo" con il
        JIT e -poi- dopo l'esecuzione, buttato tutto
        via (per sprecare -al prossimo avvio
        dell'applicazione-, un'altra volta la stessa
        CPU ... altrimenti che te ne fai ?).Guarda che è impossibile compilare java. Ci sono delle problematiche che ne impediscono una vera compilazione. In particolare le metodologie di controllo della sicurezza e soprattutto il meccanismo di caricamento delle classi prevedono che la compilazione sia fatta al volo. Quindi non si potrà andare oltre il JIT a meno di troncare alcune sue caratteristiche intrinseche che lo rendono interessante per applicazioni come gli agenti mobili ed altro.Purtroppo non si può avere tutto.Ciao
  • Anonimo scrive:
    un altra volta?
    E' dal 98 (se non ricordo male) che partecipo alle Java COnference, ed è sempre la stessa storia: ora facciamo lo standard, write once run everywhere etc all'inizio ero molto entusiasta, ora non ci credo più
    • Anonimo scrive:
      Re: un altra volta?
      Comunque era ora che si rendessero conto che non era possibile continuare a scrivere una servlet o una jsp per un application server e ritrovarsi a doverlo/a correggere totalmente se bisogna portarlo/a su un'altro.Fino ad oggi era molto furbo scriversi in proprio dei wrappers e "fregare" in questo modo i fornitori dei vari appserver: se vuoi rimanere indipendente (cambiare l'appserver), reimplementi il wrapper ed il gioco è fatto.Di sicuro la prossima volta sarà per i web services, dove -ancora una volta- ognuno ha deciso di andare per la sua strada.Personalmente anch'io ne ho abbastanza: quando dovrò implementare il primo web service i casi sono due: o tutti gli application server avranno già tutti le stesse API (100% compatibili) o tanto vale che affronti i web services con altre tecnologie Gano
Chiudi i commenti