a Quinta 's weblog : un Blog di Stefano Quintarelli

Tribunale tedesco blocca il piano anti-neutralità di Deutsche Telekom

Vi ricordate il video sulla neutralità della rete che faceva la parodia di Deutsche Telekom ?

Bene, la notizia è che un tribunale di Colonia ha vietato a Deutsche Telekom di ridurre la banda dopo i 75GB (fase 1 del progetto)

La notizia è qui.

Il nuovo datacenter dell'ENI da record

Inaugurato oggi il nuovo datacenter dell'ENI in provincia di Pavia che è il fratello più moderno di quello della I.NET

E' un'opera enorme ed estremamente sofisticata. Complimenti a Gianluigi e soprattutto a Marco (mio ex socio)

Ecco i dati caratteristici:

Superficie area: 100.000mq
Superficie costruita lorda: 45.000mq
Superficie utile sale IT (6 sale): 5.200mq
Superficie utile sala TLC (2 sale): 500mq
Superficie uffici: 1.600mq
Volumetria complessiva: 400.000mc
Volumetria vasche acqua emergenza: 5.200mc
Potenza utile IT/TLC massima (in TIER IV): 30MW
Consumo totale massimo (stima): 315 GWh/anno
PUE L3,YC < 1,2 (medio annuo, per qualsiasi livello di carico)
Configurazione impianti (elettrici e meccanici): TIER IV (non certificato da Uptime Institute)
Ricambio di aria totale (6 sale): 8,4ml mc/h
Densità energia IT:     media 5,7 kW/mq
in sala HPC 10kW/mq
max 50kW/mq
Ferro utilizzato complessivo: 6.000 ton
lunghezza travi prefabbricate utilizzate per sale IT: 9,7 km
Calcestruzzo gettato in opera: 41.000mc
Superficie casserata totale: 135.000mq
Canaline per cavi : 20.000m
Cavi vari di rame : 210km
Cavi di alluminio per la MT: 8.000m
Polveri raccolte con filtri (6 sale, 30MW): 3.000 kg/anno

In particolare segnalo quel PUE <1,2 su base media annua,

• ottenuto in mezzo alla val padana (non sulle montagne rocciose, nello stato di washington o in irlanda dove le condizioni ambientali sono decisamente più favorevoli per un DataCenter o vicino a una diga per usare l'acqua per raffreddare)
• e per ospitare computer commerciali (non computer special-purpose, fatti apposta per minimizzare il calore emesso)

per capirci, nonostante Google abbia datacenter fatti per ospitare macchine specifiche appositamente progettate e possa beneficiare di condizioni ambientali (e regolatorie per l'ambiente) molto piu' agevoli, fa 1,12.

fa una grande differenza... per capirci, il primo è come considerare una media di consumo in guida urbana, mentre il secondo è in autostrada a velocità costante.

non ho dati aggiornati ma, per un Datacenter general purpose in un intorno del 45esimo parallelo, mi sa che e' record.

hat tip!

Superficie area: 100.000mq

Superficie costruita lorda: 45.000mq

Superficie utile sale IT (6 sale): 5.200mq

Superficie utile sala TLC (2 sale): 500mq

Superficie uffici: 1.600mq

Volumetria complessiva: 400.000mc

Volumetria vasche acqua emergenza: 5.200mc

Potenza utile IT/TLC massima (in TIER IV): 30MW

Consumo totale massimo (stima): 315 GWh/anno

PUE _L3,YC < 1,2 (medio annuo, per qualsiasi livello di carico)

Configurazione impianti (elettrici e meccanici): TIER IV (non certificato da Uptime Institute)

Ricambio di aria totale (6 sale): 8,4ml mc/h

Densità energia IT:         media 5,7 kW/mq

in sala HPC 10kW/mq

max 50kW/mq

Ferro utilizzato complessivo: 6.000 ton

lunghezza travi prefabbricate utilizzate per sale IT: 9,7 km

Calcestruzzo gettato in opera: 41.000mc

Superficie casserata totale: 135.000mq

Canaline per cavi : 20.000m

Cavi vari di rame : 210km

Cavi di alluminio per la MT: 8.000m

Polveri raccolte con filtri (6 sale, 30MW): 3.000 kg/anno

Saving energia (vs DC con PUE 3,3): 550 GWh/anno

Saving di CO2 (vs DC con PUE 3,3): 335.000 ton/anno

Amici triestini e dei dintorni... non perdetevelo.

Dalla regolamentazione delle TLC a Bruxelles al pianoforte. imperdibile.

ACLU: Lavabit 'fatally undermined' by US request for encryption keys | World news | theguardian.com

ACLU: Lavabit 'fatally undermined' by US request for encryption keys | World news | theguardian.com.

The US government "fatally undermined" Lavabit, the secure email service used by whistleblower Edward Snowden, when it demanded access to encryption keys that kept the service secure, the American Civil Liberties Union said in court filings on Friday.

The ACLU has filed a "friend of the court" briefing in defence of Lavabit and its founder, Ladar Levison, who faces contempt of court charges after his decision to close down his service rather than co-operate with US authorities.

ACLU lawyer Catherine Crump said the government's "unreasonably burdensome" demands "fundamentally destroyed the company as a whole".

"Lavabit's business was predicated on offering a secure email service, and no company could possible tell its clients that it offers a secure service if its keys have been handed over to the government," Crump said.

Lavabit closed its service in August after the US authorities demanded he hand over the encryption keys for its entire service – a move Levison said would have compromised the personal details of his 40,000 clients.

Levison had previously offered the FBI access to the account that is believed to have been used by Snowden. The name of the FBI's target is redacted in court documents, and Levison is gagged by a court order from commenting.

...

Lavabit is currently fighting its contempt charges and has filed briefs arguing that the US investigation violated its constitutional fourth amendment right to protection from unreasonable searches. The company has set up a legal fund to help with the costs that has so far raised $96,000.

Diebold avrebbe corrotto per aggiudicarsi contratti per i bancomat

chissà se se ne sono accorte le banche italiane loro clienti...

Diebold charged with bribing officials, falsifying records in China, Russia, Indonesia; fined nearly $50 million | cleveland.com.

CLEVELAND, Ohio – Federal prosecutors Tuesday filed charges against Diebold Inc., accusing the North Canton-based ATM and business machine manufacturer of bribing government officials and falsifying documents in China, Indonesia and Russia to obtain and retain contracts to provide ATMs to banks in those countries.
...

Federal prosecutors acknowledged that Diebold officials voluntarily disclosed the criminal activity, cooperated with government investigators, and conducted its own extensive internal investigation.

Un sistema di messaggistica P2P, molto interessante

Bitmessage Wiki.

Bitmessage is a P2P communications protocol used to send encrypted messages to another person or to many subscribers. It is decentralized and trustless, meaning that you need-not inherently trust any entities like root certificate authorities. It uses strong authentication which means that the sender of a message cannot be spoofed, and it aims to hide "non-content" data, like the sender and receiver of messages, from passive eavesdroppers like those running warrantless wiretapping programs. If Bitmessage is completely new to you, you may wish to start by reading the whitepaper.

Apple vuole i tuoi dati.

Te(m)ppismo | eDue.

Apple decide¹ che con OS X 10.9 Mavericks aggiunge degli asterischi:
...

Quindi non c’è più modo di sincronizzare via USB o Wi-Fi Segnalibri, Contatti, Calendari e Note. Ce li avete a trenta centimetri, sulla stessa scrivania, ma dovete passare per i server del North-Carolina di Apple.

LinkedIn 'Intro'duces Insecurity - una pessima idea

da leggere LinkedIn 'Intro'duces Insecurity | Bishop Fox.

Irresistibile.. le scuse per non fare innovazione nelle telco

ma ROTFL!

la 16 mi ha fatto smascellare... (grazie E!)

chi ci lavora, sa che sono vere!!!

The Litany of Excuses Stifling Communication Innovation Part 1 | Alan Quayle Business and Service Development.

Discussed in the previous article is the fact that as an industry we’re not innovating on our core service: communication.  I hear a litany of excuses as to why communication innovation has stopped, I show below a sample for your amusement and frustration.  In the next articles I’ll go through how those excuses can be solved or avoided or ignored.

It won’t work excuses:

• We tried that service (or similar service) in our market and it failed (and we’re never ever going to try again)
• It will not work in our market (because I’m a 50 year old guy who understands all my customers better than they know themselves)
• We have a similar service already launched (and are not going to experiment in trying to make it better or address other customer segments with a similar service)
• A feature of your service overlaps with an existing service
• Our network can not support such as service (even though such services are going over the top today)
• It looks a bit like RCS (Rich Communication Suite), which we’re not sure we want to launch, but because it looks a bit like something we may do in the future we’re not going to do it

Impossible requirement excuses:

• It must work across all devices (even though most devices will never use it)
• We need additional (random) features included before we could consider it
• It must work on IMS (even though it doesn’t need to)
• It must work across all our customers from day one (even though most will never use it)
• It must conform to our process and design norms (but we’re not going to tell you what they are, and when you find them out you’ll have to build it on your dime)
• It must integrate with all our existing platforms (even though it can work fine in the current configuration)
• It must be delivered through our preferred SI or NEP (who will copy / kill the service immediately)
• It must launch and be immediately successful with no chance of revision given market learning
• You must work through our app store / portal (which will immediately reject the service because its communications centric)

We can’t do anything at the moment excuses:

• We can only focus on 4 service launches per year (because we only back major successes like Video Telephony, Mobile TV, Push To Talk, See What I See, Mobile IM, etc.)
• We just don’t have the bandwidth (to do our job)
• We have a network lock-down as we launch LTE so cannot do anything for the next 6-9 months
• Bob has left the business and we’re waiting on his replacement (who never comes)
• We’re waiting on budgets to be confirmed (sometime in the next 6 months)
• We’re re-organizing or laying off people (again this year)
• Someone in the organization doesn’t like such services

Our processes / business structure won’t let us excuses:

• That cannot be implemented without changing our IN / product catalog / CRM / billing / network
• We cannot bill / sell services under $5 per month
• We have a backlog of 24 months on billing updates (even though the service doesn’t need to be in that pipeline)
• You must work through our innovation group (which has no track record of launching services in its 5 years of operation as they’re not product managers who make the decisions)
• You must talk with Bob who will then pass you to Bill, who will then pass you to Mary, who will then pass you to Paul, who will then pass you back to Bob.

- See more at: http://alanquayle.com/2010/09/the-litany-of-excuses-stifling/#sthash.KYRZLkA8.dpuf

Discussed in the previous article is the fact that as an industry we’re not innovating on our core service: communication.  I hear a litany of excuses as to why communication innovation has stopped, I show below a sample for your amusement and frustration.  In the next articles I’ll go through how those excuses can be solved or avoided or ignored.

It won’t work excuses:

• We tried that service (or similar service) in our market and it failed (and we’re never ever going to try again)
• It will not work in our market (because I’m a 50 year old guy who understands all my customers better than they know themselves)
• We have a similar service already launched (and are not going to experiment in trying to make it better or address other customer segments with a similar service)
• A feature of your service overlaps with an existing service
• Our network can not support such as service (even though such services are going over the top today)
• It looks a bit like RCS (Rich Communication Suite), which we’re not sure we want to launch, but because it looks a bit like something we may do in the future we’re not going to do it

Impossible requirement excuses:

• It must work across all devices (even though most devices will never use it)
• We need additional (random) features included before we could consider it
• It must work on IMS (even though it doesn’t need to)
• It must work across all our customers from day one (even though most will never use it)
• It must conform to our process and design norms (but we’re not going to tell you what they are, and when you find them out you’ll have to build it on your dime)
• It must integrate with all our existing platforms (even though it can work fine in the current configuration)
• It must be delivered through our preferred SI or NEP (who will copy / kill the service immediately)
• It must launch and be immediately successful with no chance of revision given market learning
• You must work through our app store / portal (which will immediately reject the service because its communications centric)

We can’t do anything at the moment excuses:

• We can only focus on 4 service launches per year (because we only back major successes like Video Telephony, Mobile TV, Push To Talk, See What I See, Mobile IM, etc.)
• We just don’t have the bandwidth (to do our job)
• We have a network lock-down as we launch LTE so cannot do anything for the next 6-9 months
• Bob has left the business and we’re waiting on his replacement (who never comes)
• We’re waiting on budgets to be confirmed (sometime in the next 6 months)
• We’re re-organizing or laying off people (again this year)
• Someone in the organization doesn’t like such services

Our processes / business structure won’t let us excuses:

• That cannot be implemented without changing our IN / product catalog / CRM / billing / network
• We cannot bill / sell services under $5 per month
• We have a backlog of 24 months on billing updates (even though the service doesn’t need to be in that pipeline)
• You must work through our innovation group (which has no track record of launching services in its 5 years of operation as they’re not product managers who make the decisions)
• You must talk with Bob who will then pass you to Bill, who will then pass you to Mary, who will then pass you to Paul, who will then pass you back to Bob.

- See more at: http://alanquayle.com/2010/09/the-litany-of-excuses-stifling/#sthash.KYRZLkA8.dpufDiscussed in the previous article is the fact that as an industry we’re not innovating on our core service: communication.  I hear a litany of excuses as to why communication innovation has stopped, I show below a sample for your amusement and frustration.  In the next articles I’ll go through how those excuses can be solved or avoided or ignored.

Discussed in the previous article is the fact that as an industry we’re not innovating on our core service: communication.  I hear a litany of excuses as to why communication innovation has stopped, I show below a sample for your amusement and frustration.  In the next articles I’ll go through how those excuses can be solved or avoided or ignored.

It won’t work excuses:
1.- We tried that service (or similar service) in our market and it failed (and we’re never ever going to try again)
2.- It will not work in our market (because I’m a 50 year old guy who understands all my customers better than they know themselves)
3.- We have a similar service already launched (and are not going to experiment in trying to make it better or address other customer segments with a similar service)
4.- A feature of your service overlaps with an existing service
5.- Our network can not support such as service (even though such services are going over the top today)
6.- It looks a bit like RCS (Rich Communication Suite), which we’re not sure we want to launch, but because it looks a bit like something we may do in the future we’re not going to do it

Impossible requirement excuses:

7.- It must work across all devices (even though most devices will never use it)
8.- We need additional (random) features included before we could consider it
9.- It must work on IMS (even though it doesn’t need to)
10.- It must work across all our customers from day one (even though most will never use it)
11.- It must conform to our process and design norms (but we’re not going to tell you what they are, and when you find them out you’ll have to build it on your dime)
12.- It must integrate with all our existing platforms (even though it can work fine in the current configuration)
13.- It must be delivered through our preferred SI or NEP (who will copy / kill the service immediately)
14.- It must launch and be immediately successful with no chance of revision given market learning
15.- You must work through our app store / portal (which will immediately reject the service because its communications centric)

We can’t do anything at the moment excuses:
16.- We can only focus on 4 service launches per year (because we only back major successes like Video Telephony, Mobile TV, Push To Talk, See What I See, Mobile IM, etc.)
17.- We just don’t have the bandwidth (to do our job)
18.- We have a network lock-down as we launch LTE so cannot do anything for the next 6-9 months
19.- Bob has left the business and we’re waiting on his replacement (who never comes)
20.- We’re waiting on budgets to be confirmed (sometime in the next 6 months)
21.- We’re re-organizing or laying off people (again this year)
22.- Someone in the organization doesn’t like such services

Our processes / business structure won’t let us excuses:
23.- That cannot be implemented without changing our IN / product catalog / CRM / billing / network
24.- We cannot bill / sell services under $5 per month
25.- We have a backlog of 24 months on billing updates (even though the service doesn’t need to be in that pipeline)
26.- You must work through our innovation group (which has no track record of launching services in its 5 years of operation as they’re not product managers who make the decisions)
27.- You must talk with Bob who will then pass you to Bill, who will then pass you to Mary, who will then pass you to Paul, who will then pass you back to Bob.

- See more at: http://alanquayle.com/2010/09/the-litany-of-excuses-stifling/#sthash.KYRZLkA8.dpuf

Discussed in the previous article is the fact that as an industry we’re not innovating on our core service: communication.  I hear a litany of excuses as to why communication innovation has stopped, I show below a sample for your amusement and frustration.  In the next articles I’ll go through how those excuses can be solved or avoided or ignored.

It won’t work excuses:

• We tried that service (or similar service) in our market and it failed (and we’re never ever going to try again)
• It will not work in our market (because I’m a 50 year old guy who understands all my customers better than they know themselves)
• We have a similar service already launched (and are not going to experiment in trying to make it better or address other customer segments with a similar service)
• A feature of your service overlaps with an existing service
• Our network can not support such as service (even though such services are going over the top today)
• It looks a bit like RCS (Rich Communication Suite), which we’re not sure we want to launch, but because it looks a bit like something we may do in the future we’re not going to do it

Impossible requirement excuses:

• It must work across all devices (even though most devices will never use it)
• We need additional (random) features included before we could consider it
• It must work on IMS (even though it doesn’t need to)
• It must work across all our customers from day one (even though most will never use it)
• It must conform to our process and design norms (but we’re not going to tell you what they are, and when you find them out you’ll have to build it on your dime)
• It must integrate with all our existing platforms (even though it can work fine in the current configuration)
• It must be delivered through our preferred SI or NEP (who will copy / kill the service immediately)
• It must launch and be immediately successful with no chance of revision given market learning
• You must work through our app store / portal (which will immediately reject the service because its communications centric)

We can’t do anything at the moment excuses:

• We can only focus on 4 service launches per year (because we only back major successes like Video Telephony, Mobile TV, Push To Talk, See What I See, Mobile IM, etc.)
• We just don’t have the bandwidth (to do our job)
• We have a network lock-down as we launch LTE so cannot do anything for the next 6-9 months
• Bob has left the business and we’re waiting on his replacement (who never comes)
• We’re waiting on budgets to be confirmed (sometime in the next 6 months)
• We’re re-organizing or laying off people (again this year)
• Someone in the organization doesn’t like such services

Our processes / business structure won’t let us excuses:

• That cannot be implemented without changing our IN / product catalog / CRM / billing / network
• We cannot bill / sell services under $5 per month
• We have a backlog of 24 months on billing updates (even though the service doesn’t need to be in that pipeline)
• You must work through our innovation group (which has no track record of launching services in its 5 years of operation as they’re not product managers who make the decisions)
• You must talk with Bob who will then pass you to Bill, who will then pass you to Mary, who will then pass you to Paul, who will then pass you back to Bob.

- See more at: http://alanquayle.com/2010/09/the-litany-of-excuses-stifling/#sthash.KYRZLkA8.dpuf

Un paper da leggere, per chi si occupa di reti

Andrew Odlyzko, che mi onora della sua amicizia, ha appena pubblicato
questo articolo. che consiglio a tutti di leggere. solo un estratto sotto:

Will smart pricing finally take off?, A. Odlyzko

True streaming video is, and will remain, a very small fraction of traffic.
Video does dominate current Internet traffic by volume, but it is almost exclusively transmitted as faster-than-real-time progressive downloads. That is the only method that makes sense technologically. (Video conferencing is completely different, but we now have enough experience to be able to predict with safety that it will not be contributing giant amounts of traffic.) Furthermore, this was easily predictable and was predicted a long time ago.
George Gilder wrote about it two decades ago, for example, and he attributes the idea to Nicholas Negroponte even earlier. Their prediction has come true, yet almost everyone thinks that the floods of video they consume are true streaming video. This skewes business decisions and public policy discussions, since networks dominated by real-time long-lived data flows of predictable size and with tight latency constraints do indeed lend themselves to many of the pricing and network management techniques that are so beloved by both top managers and telecom researchers, cf. [40].
The myth of real-time streaming video is so pervasive and strong that it also affects networking researchers. For the last decade, this author has been taking polls asking those in the audience to raise their hands if they saw any advantage at all, for anyone, in transmitting video faster than real time. Usually, even among networking researchers, at most 10% have responded. The highest positive response rates were around 40%, among a couple of audiences packed with researchers working on wireless ad-hoc networks, who understand that on connectivity being maintained, but can use buffers to compensate. (While one can envisage ultra-reliable wired networks, in the wireless arena this is simply not achievable,there are far too many unpredictable sources of impairments.)
This demonstrates that even networking researchers don’t know what is happening in today’s networks, nor why it is happening.
The preoccupation with real-time streaming video leads to the constant questioning about the potential demand for high speed access. Who needs gigabit to the home, is being asked, since the most that most observers can imagine is a few streams that might possibly come to 20 Mbps each in some future high-definition TV. This perfectly illustrates the lack of vision not just on the future, but on the present, that afflicts this industry. After all, why are people buying 300 Mbps home WiFi access points, if all they are after is streaming a few movies? Yet such routers are selling, and high speed home access is also selling (when offered at reasonable cost), because they allow for low transaction latency

...

Substantial improvements in [wireless] capacity could be achieved just by building more facilities, but that would require greatly increased capital spending. That could come from either higher revenues from users, or from restructuring the industry so it spends less on marketing, lobbying, and other activities, and more on construction. Since neither is likely to happen, we are likely to see traffic limited by available capacity. Combined with the wide disparity of various types of bits, this suggests that pricing will play a significant role in balancing demand and supply