Cookie persistenti cotti al brevetto

F5 Networks ha già denunciato tre concorrenti per violazione di brevetto. Si brandisce il copyright e si minacciano i competitor per aumentare il fatturato. Viva la tecnologia


Roma – F5 Networks è un’azienda felice perché ha appena ottenuto il riconoscimento ufficiale del proprio brevetto sui cookie persistenti, quei micro-file che consentono ad un server web di riconoscere un computer desktop che torna sulle pagine web che gestisce.

L’azienda, che dal 1999 raccoglie royalty su una serie di tecnologie utilizzate quotidianamente negli scambi commerciali in rete, non ha perso tempo e ha già fatto causa a tre concorrenti che, secondo F5, violano il proprio brevetto proponendo tecnologie assimilabili ai cookie persistenti.

Per comprendere l’estensione del brevetto 6,473,802, di cui si trova notizia presso l’ ufficio dei brevetti americano , è bene dare un’occhiata alla sua descrizione ufficiale:

“Un metodo e un sistema per inserire e esaminare i cookie nel flusso di dati di connessioni HTTP allo scopo di indirizzare persistentemente connessioni HTTP alla stessa destinazione. L’invenzione consente ad un device di rete di indirizzare successive connessioni HTTP dallo stesso client allo stesso server per accedere a determinare risorse”. Il tutto è condito dalla copertura del brevetto per l’atto in cui il cookie viene “scritto”, riscritto, modificato, rimosso e via dicendo.

F5 , la cui attività principale è proprio la produzione di tecnologie destinate a siti di grandi corporation, ha per il momento ottenuto dai suoi tre competitor una dichiarazione di guerra. Radware e NetScaler hanno infatti già dichiarato che le proprie tecnologie non violano il brevetto di F5 mentre il terzo soggetto delle denunce di F5, Array Networks, ha scelto di non commentare facendo intendere che non cercherà un accordo con F5.

La scelta di brandire un brevetto di questo tipo per aumentare il fatturato, in un anno nel quale quello di F5 è calato di non poco, fa ormai parte del DNA di un numero sempre maggiore di imprese legate alle nuove tecnologie, e questo nonostante i problemi di immagine in cui queste aziende possono incorrere. Recentissima, peraltro, la clamorosa iniziativa di SCO (ex Caldera) contro IBM sulle tecnologie UNIX-Linux.

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:
    Il caro Bill cerca manodopera a basso...
    costo?Oppure vuole gia' indottrinare i futuri dottori all'uso dei suoi prodotti?Infatti e' dalle Universita' che e' nato Linux e li occorre stroncarlo utilizzando per i proprio scopi quelle capacita' che molti programmatori "regalano" al software Open Source.Perche' non sottopagarli e sfruttarli? Tanto lavorano gia' gratis :-)
  • Anonimo scrive:
    imparare a programmare?
    NO EH?!?!?!?!?non dico senza bug... ma perlomeno con i check sui buffer!!!!!!!M$ sempre + ridicola.
    • Anonimo scrive:
      Re: imparare a programmare?
      - Scritto da: Anonimo
      Stiamo parlando di un kernel. Il c in questo
      caso è utilizzato come sostituto portabile
      per l'assembler, e mettere una variabile in
      più (leggi "while not uscita") significa
      introdurre inefficienze che in un kernel non
      sono beneaccetteE' alquanto ridicolo parlare di efficienza con un kernel monolitico di dimensioni ciclopiche. Inutile impiccarsi con una architettura balorda e poi cercare di risparmiare una variabile.Se avessero voluto efficienza (e.g. se torvalds fosse stato in grado, quando Tanenbaum glie lo fece presente) AVREBBERO SENZ'ALTRO SCELTO UN MICROKERNEL.
      • Anonimo scrive:
        Re: imparare a programmare?
        - Scritto da: Anonimo

        - Scritto da: Anonimo

        Stiamo parlando di un kernel. Il c in
        questo

        caso è utilizzato come sostituto portabile

        per l'assembler, e mettere una variabile
        in

        più (leggi "while not uscita") significa

        introdurre inefficienze che in un kernel
        non

        sono beneaccette

        E' alquanto ridicolo parlare di efficienza
        con un kernel monolitico di dimensioni
        ciclopiche. Qua veramente viene fuori l'esperienza e la cultura del vero... ignorante.Quindi secondo te, il kernel è monolitico =
        grande =
        pesante? Guarda che non è un elefante, è un kernel, e PROPRIO il fatto di essere monolitico (così come anche i vari BSD) gli consente di essere efficiente, perchè la sincronizzazione fra processi del kernel (ovvero driver) avviene con memoria condivisa.Au contrarie, mon ami, i microkernel hanno il problema della comunicazione che li rende necessariamente più lenti.
        Inutile impiccarsi con una architettura
        balorda e poi cercare di risparmiare una
        variabile.Non una. E' il kernel intero che è scritto in quel modo.
        Se avessero voluto efficienza (e.g. se
        torvalds fosse stato in grado, quando
        Tanenbaum glie lo fece presente) AVREBBERO
        SENZ'ALTRO SCELTO UN MICROKERNEL.Si, certo. Torna a studiare, per favore.
        • Anonimo scrive:
          Re: imparare a programmare?
          - Scritto da: AnonimoEh sì... infatti QNX e tutti i microkernel RTOS sono lenti, ma così lenti nella IPC e nella sincronizzazione con i driver guarda...Torna a smanettare su linuzzo nel tuo sottoscala, per cortesia e non rompere i maroni a chi ha studiato un bel pezzo prima (e assai più) di te.
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo

            - Scritto da: Anonimo
            Eh sì... infatti QNX e tutti i microkernel
            RTOS sono lenti, ma così lenti nella IPC e
            nella sincronizzazione con i driver
            guarda...

            Torna a smanettare su linuzzo nel tuo
            sottoscala, per cortesia e non rompere i
            maroni a chi ha studiato un bel pezzo prima
            (e assai più) di te.bravo che dire di più bisogna punire questi linauti che ci spacciano il loro so come il più avanzato e potente, ma che in fondo e solo un pachidermico ammasso di immondizia scopiazzata.quello che era e doveva diventare linuz era solo uno dei soliti (e neanche ben fatti) so universitari, che a decine popolano il panorama didattico, purtroppo IBM e le altre a forza di finanziare per un solo scopo questo so gli hanno permesso di arrivare fino a noi.
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo

            quello che era e doveva diventare linuz era
            solo uno dei soliti (e neanche ben fatti) so
            universitari, che a decine popolano il
            panorama didattico, purtroppo IBM e le altre
            a forza di finanziare per un solo scopo
            questo so gli hanno permesso di arrivare
            fino a noi.Non credo che sia colpa di IBM (che peraltro avrebbe potuto scegliere un qualche BSD), ma della ostinata tendenza all'anarchia e al finto alternativismo di certa gente che ha riempito di significati "politici" uno dei tanti SO in circolazione, neppure uno dei migliori. Il resto è un normale fenomeno di aggregazione di massa ben noto agli astrofisici, se uno vuole sviluppare il suo accrocco lo sviluppa più volentieri per linux invece di contribuire a OpenBSD o EROSos per banali motivi numerici, magari sul suo sistema preferito il BSD non ci gira. Va da sè che le paroline magiche GRATIS e ROVESCIAMO IL SISTEMA fanno sempre miracoli...
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo
            linux invece di contribuire a OpenBSD o
            EROSos per banali motivi numerici, magari
            sul suo sistema preferito il BSD non ci
            gira. qual è l'hardware su cui netbsd NON gira ?
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo


            linux invece di contribuire a OpenBSD o

            EROSos per banali motivi numerici, magari

            sul suo sistema preferito il BSD non ci

            gira.
            qual è l'hardware su cui netbsd NON gira ?OpenBSD (di QUELLO parlava il post) non gira sulle vecchie Sun di classe 3 che abbiamo noi, per esempio. Oppure sui DEC MIPS, SGI MIPS, PA-RISC... ma era solo un esempio, inutile fare tanto i puntigliosi. Secondo Theo non ci sono più di 7.000 persone che girano attorno a OpenBSD, è evidente che su sourceforge e freshmeat c'è molto più "giro" e preferenza. Che poi questo sia un male, vista la superiorità dei *BSD su linux, è tutt'altro discorso...........
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo

            Che poi questo sia un male, vista la
            superiorità dei *BSD su linux, è tutt'altro
            discorso...........secondo me è soprattutto questione di licenza ..la maggior parte della gante preferisce la GPL alla lic. bsde comunque esiste anche linuxulator per freebsd , quindi se la gente sviluppaper linux non vedo dove sia il problema.
          • Anonimo scrive:
            Re: imparare a programmare?

            Torna a smanettare su linuzzo nel tuo
            sottoscala, per cortesia e non rompere i
            maroni a chi ha studiato un bel pezzo prima
            (e assai più) di te.Vi siete allargati talmente tanto in caz*ate in questo thread... che non vale più neanche la pena rispondere.
        • Anonimo scrive:
          Re: imparare a programmare?
          - Scritto da: Anonimo

          Au contrarie, mon ami, i microkernel hanno
          il problema della comunicazione che li rende
          necessariamente più lenti.Dopo questa enorme cazzata puoi anche andare a letto.FATTO: Un microkernel come QNX, sulla macchina di riferimento (i86 Pentium MMX 200 MHz) è in grado di servire interrupt consecutivi con periodi inferiori a 5 microsecondi, senza perderne uno. Linux sullo stesso HW si pianta miseramente con periodi dell'ordine di 70 microsecondi. Chi sarebbe più veloce ed efficiente ? Non farci ridere, non sai di cosa parli.FATTO: la comunicazione interprocess in linux fa ridere. I messaggi devono essere copiati dallo spazio di memoria di un processo all'altro, non possono essere passati per riferimento, cioè un ordine di grandezza più velocemente, come fanno TUTTI i microkernel message passing, che tra l'altro usano pipes specializzate ed ottimizzate per la comunicazione tra processi. Altro che maggiore lentezza, espertone.FATTO: anche RTlinux con la sua architettura dual-domain fa ugualmente ridere i polli. Il message passing è affidato a una FIFO e non a pipes specializzate (che sono la norma per i microkernel RTOS). L'idiozia più grande è che a queste fifo si accede solo con le primitive del filesystem, leggendo UN carattere per volta con get() e put(). Suicidio. Nessun genere di supporto è presente per l'accodamento, la priorità dei messaggi, il blocking dei task in attesa di messaggio. CONSIGLIO: precipitati su Amazon e cerca almeno i seguenti autori: Liu, Nissanke, Shaw, Calvez, Buttazzo. A seguire Silberschatz, Tanenbaum e Maestrini sui SO in generale. Compra tutti i testi, studiateli a fondo, fatti magari un 5-6 anni di esperienza nel realtime industriale, e poi vieni a riparlarmi delle differenze architetturali di un microkernel con i monolitici.

          Inutile impiccarsi con una architettura

          balorda e poi cercare di risparmiare una

          variabile.

          Non una. E' il kernel intero che è scritto
          in quel modo.Sottotitolo per non comprendenti: ARCHITETTURA DEL KERNEL, i.e. la scelta tra monolitico o microkernel.
          • Anonimo scrive:
            Re: imparare a programmare?
            nessuno ti ha spieagato che Linux eà un kernel Half Time mentre QNX e' Real Time ? non puoi paragonare cose diverse... prova piuttosto a fare il paragone con RTLinux ...
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo
            nessuno ti ha spieagato che Linux eà un
            kernel Half Time mentre QNX e' Real Time ?
            non puoi paragonare cose diverse... prova
            piuttosto a fare il paragone con RTLinux ...Ma imparare a leggere no, eh ?
            FATTO: anche RTlinux con la sua architettura
            dual-domain fa ugualmente ridere i polli. Il
            message passing è affidato a una FIFO e non
            a pipes specializzate (che sono la norma per
            i microkernel RTOS). L'idiozia più grande è
            che a queste fifo si accede solo con le
            primitive del filesystem, leggendo UN
            carattere per volta con get() e put().
            Suicidio. Nessun genere di supporto è
            presente per l'accodamento, la priorità dei
            messaggi, il blocking dei task in attesa di
            messaggio. Se ne vuoi ancora, RTlinux ha delle pesanti inefficienze anche nella gestione degli interrupt, dato che introduce un overhead per sospendere quelli "non critici" da passare al kernel linux, non avendo una gestione a code di priorità separate per ogni livello di interrupt. Non serve a niente mettere uno scheduler "figo" come EDF se poi il resto dell'architettura fa pena e non è nato per il realtime.RTLinux infatti non ha alcuna certificazione full code coverage, niente PSE52-54, MIL-STD-498, ESA PSS05, RTCS/DO* quindi non può volare o essere impiegato in sistemi altamente critici, life-dependable e simili. In due parole non è neppure hard realtime.Tra l'altro, si discute di confronto tra monolitici e microkernel perchè un simpatico decerebrato aveva affermato che il monolitico linux è "più veloce" dei microkernel (ROTFL).Half Time poi è una definizione che ti sei inventato te di sana pianta... esistono sistemi non realtime, soft realtime e hard realtime, punto.
          • Anonimo scrive:
            Re: imparare a programmare?


            FATTO: anche RTlinux con la sua
            architettura

            dual-domain fa ugualmente ridere i polli.
            Il

            message passing è affidato a una FIFO e
            non

            a pipes specializzate (che sono la norma
            per

            i microkernel RTOS).Si va bene, ok, ma continua ad essere che l'efficienza di un message passing, in potenza, non può raggiungere quella della memoria condivisa.Senza bisogno di esaltarsi. Tra parentesi (sono sempre quello del post iniziale) a me piacciono di più i microkernel. Però se uno ha bisogno di efficienza prima che di eleganza, e deve scegliere come implementare il kernel, sceglie un monolitico, sulle architetture attuali.
          • Anonimo scrive:
            Re: imparare a programmare?
            - Scritto da: Anonimo
            Però se uno
            ha bisogno di efficienza prima che di
            eleganza, e deve scegliere come
            implementare il kernel, sceglie un monolitico,
            sulle architetture attuali.Sulle architetture attuali (per la precisione, su macchine mediamente inferiori ai Pentium/Geode 200) tutti i RTOS implementano microkernel. Escluso solo ed unicamente VxWorks (e si è visto che bel lavoro col Pathfinder). Dato che i RTOS hard realtime sono in assoluto il massimo dell'efficienza, la tua asserzione contiene una pesante contraddizione in termini.
          • Anonimo scrive:
            Re: imparare a programmare?

            CONSIGLIO: precipitati su Amazon e cerca
            almeno i seguenti autori: Liu, Nissanke,
            Shaw, Calvez, Buttazzo. A seguire
            Silberschatz, Tanenbaum e Maestrini sui SO
            in generale.Maestrini mi ha dato 30 e lode. Hai citato TANTI controesempi allo scopo di dare una dimostrazione. Anche freebsd è più veloce di hurd, ma non è questo che dimostra che i microkernel siano più lenti!
    • Anonimo scrive:
      Re: imparare a programmare?
      - Scritto da: Anonimo


      Stiamo parlando di un kernel. Il c in questo
      caso è utilizzato come sostituto portabile
      per l'assembler, e mettere una variabile in
      più (leggi "while not uscita") significa
      introdurre inefficienze che in un kernel non
      sono beneaccettequello che dici sono tutte giustificazioni, ti basti sapere che in c esiste un istruzione apposita per uscire dai loop, (break) che non richiede nessuna variabile temporanea o altro, il problema e semplicemente l'incapacità degli sviluppatori di riscrivere intere parti del kernel al fine di renderle più lineari e facili da capire.
      • Anonimo scrive:
        Re: imparare a programmare?
        - Scritto da: Anonimo

        - Scritto da: Anonimo






        Stiamo parlando di un kernel. Il c in
        questo

        caso è utilizzato come sostituto portabile

        per l'assembler, e mettere una variabile
        in

        più (leggi "while not uscita") significa

        introdurre inefficienze che in un kernel
        non

        sono beneaccette


        quello che dici sono tutte giustificazioni,
        ti basti sapere che in c esiste un
        istruzione apposita per uscire dai loop,
        (break) che non richiede nessuna variabile
        temporanea o altro, il problema e
        semplicemente l'incapacità degli
        sviluppatori di riscrivere intere parti del
        kernel al fine di renderle più lineari e
        facili da capire.Beh, allora? Quanto può essere difficile, è solo un sistema operativo, scrivilo tu.
      • Anonimo scrive:
        Re: imparare a programmare?
        - Scritto da: Anonimo
        quello che dici sono tutte giustificazioni,
        ti basti sapere che in c esiste un
        istruzione apposita per uscire dai loop,
        (break) che non richiede nessuna variabile
        temporanea o altro, il problema e
        semplicemente l'incapacità degli
        sviluppatori di riscrivere intere parti del
        kernel al fine di renderle più lineari e
        facili da capire."break" si traduce in un salto, una volta compilata.Posso dire due parole? E` abbastanza ridicolo tutto il discorso sui salti che indicherebbero cattiva struttura, e` un discorso vecchio, accademicamente molto diffuso ma poco significativo. Fai come ti pare, se vuoi saltare salta, spero basti ricordare che le switch/case non sono parte del set d'istruzioni di un microprocessore, mentre i salti si, quelli sono strettamente necessari. Io un microkernel l'ho scritto. (e` di 31.5 Kb, 512 bytes del bootstrap loader in assembly i8086, 2 kb dell'interrupts controller in i386 assembly a 16 bit, e il resto e` i386 assembly a 32 bit con modello flat, quindi il problema della struttura non si pone)...
  • Anonimo scrive:
    mmm...
    Fare una cernita di tutto quello che veramente serve e semplificare il software? Incoraggiare lo sviluppo di standards per il dialogo con l'hardware? Trattare ogni distribuzione, almeno intorno al proprio nucleo operativo, come se fosse mission-critical? Togliere i fronzoli a meno che l'utente non li voglia? (anche la GUI e` un fronzolo, in quest'ottica, per intenderci) Far evolvere poche centinaia di migliaia di righe di codice di cui si sa vita, morte e miracoli, invece di crearne a milioni di continuo? Almeno, considerazioni sulla competenza dei programmatori a parte, questa strada proprio non la si puo` provare? Non costerebbe molto, credo, come progetto alternativo.
  • Anonimo scrive:
    Le tecniche per scrivere codice sicuro?
    Le insegnano da anni nell'università, ma ora grazie alla riforma non le insegneranno più. Sto parlando di specifica, di semantica, di interpretazione astratta. Sto parlando di controllo di tipi forte.Chi ha orecchie per intendere, non ha bisogno di me per aver tristemente inteso... Mi fa ridere che si pensi che ci sia bisogno di una azienda per insegnare nelle università quali siano le tecniche per scrivere codice corretto.Ora non verranno a pretendere che sia merito loro, se si diffondono queste tecniche, quando per tanti anni, per colpa di c++, visual basic e altre tecnologie idiote siamo andati per la strada sbagliata, e principalmente è colpa della pubblicità idiota delle aziende?E invece si, pretendono proprio questo. Che le scoperte siano le loro. E tra un po' brevetteranno pure tutto.
    • Anonimo scrive:
      Re: Le tecniche per scrivere codice sicuro?
      La microsoft e' vettore di ingnoranza, inettitudine e disinformazione tanto quanto le mosche Tze Tze della malaria in Africa.
      • Anonimo scrive:
        Re: Le tecniche per scrivere codice sicuro?
        - Scritto da: Anonimo
        La microsoft e' vettore di ingnoranza,
        inettitudine e disinformazione tanto quanto
        le mosche Tze Tze della malaria in Africa.Ti vedo obiettivo
      • Anonimo scrive:
        Re: Le tecniche per scrivere codice sicuro?
        - Scritto da: Anonimo
        La microsoft e' vettore di ingnoranza,
        inettitudine e disinformazione tanto quanto
        le mosche Tze Tze della malaria in Africa.Allora significa che Microsoft è portatore di grande intelligenza etc. etc. visto che la mosca in questione è portatrice della malattia del sonno e non della malaria.... ;-)
      • Anonimo scrive:
        Re: Le tecniche per scrivere codice sicuro?
        - Scritto da: Anonimo
        La microsoft e' vettore di ingnoranza,
        inettitudine e disinformazione tanto quanto
        le mosche Tze Tze della malaria in Africa.Quanto a ignoranza e disinformazione ti vedo assai ferrato, dato che la mosca Tze-tze (diffusa in Africa e Asia) è portatrice del tripanosoma che causa la narcolessi, mentre la malaria è diffusa da alcune specie di zanzare............
      • cico scrive:
        Re: Le tecniche per scrivere codice sicuro?

        La microsoft e' vettore di ingnoranza,
        inettitudine e disinformazione tanto quanto
        le mosche Tze Tze della malaria in Africa.Torna in IDL va trollone
    • fDiskolo scrive:
      Re: Le tecniche per scrivere codice sicu
      - Scritto da: Anonimo
      Ora non verranno a pretendere che sia merito
      loro, se si diffondono queste tecniche,
      quando per tanti anni, per colpa di c++,
      visual basic e altre tecnologie idiote siamo
      andati per la strada sbagliata, e
      principalmente è colpa della pubblicità
      idiota delle aziende?parole sante. Gli inventori del visual basic dovrebbero essere castrati e i loro figli uccisi, per evitare che i loro geni possano diffondersi ancora...Hanno voluto fare in modo che gli utonti si avvicinassero all'uso del pc? E questo va bene.Hanno voluto che i cretini fossero in grado di programmare? (vedi i famigerati programmatori in html....) E questo invece è un _grande_ male.
      • Zeross scrive:
        Re: Le tecniche per scrivere codice sicu
        - Scritto da: fDiskolo
        parole sante. Gli inventori del visual basic
        dovrebbero essere castrati e i loro figli
        uccisi, per evitare che i loro geni possano
        diffondersi ancora...

        Hanno voluto fare in modo che gli utonti si
        avvicinassero all'uso del pc? E questo va
        bene.

        Hanno voluto che i cretini fossero in grado
        di programmare? (vedi i famigerati
        programmatori in html....) E questo invece è
        un _grande_ male.Peccato poi che alla fine della fiera si scopre che molti di quei cretini non usano il VB ma il C per fare le loro immani cagate.E per inciso, non ho mai visto un "buffer overflow" in un programma VB...Che si fa mo? Si taglia le palle anche agli inventori del C per par condicio?Io credo sia meglio farlo ai cretini...Zeross
        • Scody scrive:
          Re: Le tecniche per scrivere codice sicu
          - Scritto da: Zeross
          - Scritto da: fDiskolo
          Peccato poi che alla fine della fiera si
          scopre che molti di quei cretini non usano
          il VB ma il C per fare le loro immani
          cagate.
          E per inciso, non ho mai visto un "buffer
          overflow" in un programma VB...

          Che si fa mo? Si taglia le palle anche agli
          inventori del C per par condicio?
          Io credo sia meglio farlo ai cretini...


          ZerossForse perchè non c'è niente di "Grande" scritto in VB..o hai deciso di scrivere le tue applicazioni mission-critical in vb?..poverini noi che dobbiam studiare il c++...
          • Zeross scrive:
            Re: Le tecniche per scrivere codice sicu
            - Scritto da: Scody

            Forse perchè non c'è niente di "Grande"
            scritto in VB..
            o hai deciso di scrivere le tue applicazioni
            mission-critical in vb?"grande" mi sembra un po' generico.Pur con tutti i suoi limiti e difetti il VB classico ha anche lui le sue "grandi" applicazioni in settori specifici.Ovvio che difficilmente vedrai mai ad esempio videogiochi scritti in VB6.Poi molto dipende sempre dall'abilità dello sviluppatore. Si possono fare delle gran belle cose anche in VB.Basta non fermarsi alla scorza; ovvio però che per farlo è richiesta cmq una buona dose di studio... cosa che a quanto vedo giornalmente non stà molto a genio alla maggior parte di coloro che si dilettano col VB.
            ..poverini noi che dobbiam studiare il c++...Si, su questo concordo... poveretti voi...Zeross
      • Anonimo scrive:
        Re: fDiskolo ti devo bacchettare ma alcu

        I programmi realizzati in VB (fino alla 6)
        non possono in qualsiasi caso generare
        problemi di sicurezza, tutto e gestito dal
        runtime, allocazioni di memoria tipi ecc...
        se il problema c'è e nel runtime, lo stesso
        capita con java c# ecc... Scusa, non ho capito. Un programma vb non può crashare a causa di una operazione su tipi dinamici? A me parrebbe proprio di si.
        • Anonimo scrive:
          Re: fDiskolo ti devo bacchettare ma alcu
          - Scritto da: Anonimo


          I programmi realizzati in VB (fino alla 6)

          non possono in qualsiasi caso generare

          problemi di sicurezza, tutto e gestito dal

          runtime, allocazioni di memoria tipi
          ecc...

          se il problema c'è e nel runtime, lo
          stesso

          capita con java c# ecc...

          Scusa, non ho capito. Un programma vb non
          può crashare a causa di una operazione su
          tipi dinamici? A me parrebbe proprio di si.se dichiari una variabile di un certo tipo, ma non crei l'oggetto e poi usi una sua funzione certo che scoppia, ma certamente non potrai usare cio per imbastire un exploit, tutta la vita del programma e gestita dal runtime che impedisce questo tipo di attivita
          • Anonimo scrive:
            Re: fDiskolo ti devo bacchettare ma alcu
            - Scritto da: Anonimo

            - Scritto da: Anonimo




            I programmi realizzati in VB (fino
            alla 6)


            non possono in qualsiasi caso generare


            problemi di sicurezza, tutto e gestito
            dal


            runtime, allocazioni di memoria tipi

            ecc...


            se il problema c'è e nel runtime, lo

            stesso


            capita con java c# ecc...



            Scusa, non ho capito. Un programma vb non

            può crashare a causa di una operazione su

            tipi dinamici? A me parrebbe proprio di
            si.


            se dichiari una variabile di un certo tipo,
            ma non crei l'oggetto e poi usi una sua
            funzione certo che scoppia, ma certamente
            non potrai usare cio per imbastire un
            exploit, tutta la vita del programma e
            gestita dal runtime che impedisce questo
            tipo di attivitaCerto. Quello che dico è che altri aspetti, come la robustezza, sono completamente fregati da tecnologie che in fondo sono state diffuse dalle stesse persone che poi di robustezza ci vengono a parlare.Si, ok, ho fatto un po' di confuzione :)
      • Anonimo scrive:
        Re: fDiskolo ti devo bacchettare ma alcu
        mi pare molto difficile che qualcuno senza basi riesca a programmare in c ....
        • Anonimo scrive:
          Re: fDiskolo ti devo bacchettare ma alcu
          - Scritto da: Anonimo
          mi pare molto difficile che qualcuno senza
          basi riesca a programmare in c ....ahahahahhaaahahahahahahahahahhaahhaamico c'è gente che non sa che cosa e malloc calloc (e in particolare free) e viene messo a lavorare in importanti progetti, a modificare codice (che poi si impianta ogni due secondi).si vede che sei uno che non ha mai lavorato nel mondo dell'informatica ciao.
      • Giambo scrive:
        Re: fDiskolo ti devo bacchettare ma alcu
        - Scritto da: Anonimo
        potrei essere concorde ma a me fa più paura
        l'openaro da universita, o da rivista che
        si diletta a realizzare parti di programmi
        open in c senza avere nessuna conoscenza di
        base, amico a me quello fa molta più pauraFortuna che il codice dell'"openaro" e' sotto gli occhi di tutti, e puo' essere corretto, pensa se invece fosse un "windowsa(u)ro" !
    • Anonimo scrive:
      Re: Le tecniche per scrivere codice sicuro?
      - Scritto da: Anonimo
      Le insegnano da anni nell'università, ma ora
      grazie alla riforma non le insegneranno più.
      Sto parlando di specifica, di semantica, di
      interpretazione astratta. Sto parlando di
      controllo di tipi forte.E model checking, linguaggi formali, logiche temporali, verifica alle equazioni di Hoare... con una massiccia quantità di metodologie forti, coerenti, complete che coprano dall'analisi al testing.
      Mi fa ridere che si pensi che ci sia bisogno
      di una azienda per insegnare nelle
      università quali siano le tecniche per
      scrivere codice corretto.La cosa più assurda è che tutto si muove da un sottoproblema della robustezza, che è lo sbandierato settore della "sicurezza". Come se gli altri punti fondamentali del sotfware engineering non fossero ugualmente importanti.Potrei comprendere se l'azienda in questione fosse un colosso del mondo embedded industriale, aerospaziale, medicale o automotive, che sicuramente ha qualcosa da insegnare sull'applicazione concreta e rigorosa delle metodologie che consentono la creazione di software mission-critical, error-tolerant, perfettamente aderente alle specifiche. Ma il fatto che un'azienda del mass market priva di qualsiasi certificazione critica (dalle MIL-STD a RTCS/DO, alle Posix PSE52-54) pretenda di dare lezioni ai teorici è semplicemente una pagliacciata.
Chiudi i commenti