Quarta legge della robotica

Agli inizi degli anni ’40, nella mente di Isaac Asimov, si insidiò la grande concezione delle  Tre leggi della robotica. Esse riferiscono grandemente a 3 concetti che riguardano la necessità di sicurezza (la Prima Legge), servizio (la Seconda Legge) e prudenza (la Terza Legge). Gli enunciati sono i seguenti:

  1. Un robot non può recar danno a un essere umano né può permettere che, a causa del proprio mancato intervento, un essere umano riceva danno.
  2. Un robot deve obbedire agli ordini impartiti dagli esseri umani, purché tali ordini non contravvengano alla Prima Legge.
  3. Un robot deve proteggere la propria esistenza, purché questa autodifesa non contrasti con la Prima o con la Seconda Legge.
  4. Un robot non deve privare del pane l’uomo con il proprio operato, pena la distruzione o la messa in condizione di non economicità.

La quarta legge l’ho inserita io, che per certi aspetti può essere considerata un corollario della prima. Ma dargli una connotazione chiara, esplicita, secondo me ne aiuta la comprensione. Vero che si parla di fantascienza, ma la realtà supera sempre qualunque fantasia. E nel mondo reale comincia a succedere che l’uomo non abbia più nulla da fare perchè c’è un robot che lavora al posto suo. Le macchine hanno la loro importanza, ma l’uomo è più importante.

 

Quanto è grossa una tabella su SQL Server? come si monitorizza?

La grandezza di una tabella, anche in SQL Server (2005, 2008 e 2012) è sempre un dato da considerare, soprattutto se la tabella ha milioni di righe. Nel caso di decine di colonne, anche qualche migliaio di righe può però inputare degli oneri computazionali. Questo articolo offre un interessante spunto di riflessione, oltre che un valido strumento per calcolare la dimensione delle tabelle e dei database. Si fa sempre uso delle viste di sistema e delle procedure (funzioni) di sistema, in questo caso dbo.sysobjects che restituisce l’elenco delle tabelle e sp_spaceused che restituisce informazioni circa la tabella che viene passata come primo parametro. Non si tratta di nulla di trascendentale, ma che può essere utile in ambienti Enterprise.

XP_cmdshell su SQL Server

XP_cmdshell è il super accrocchio che permette di mescolare il Database con il sistema operativo. Infatti potrebbe essere necessario dover mescolare interrogazioni al sistema operativo con informazioni contenute in Tabelle. Il grande Pinal Dave ci fornisce la sua versione, e i comandi (da SQL 2005 in poi) sono i seguenti:
EXEC sp_configure ‘show advanced options’, 1
GO
RECONFIGURE
GO
EXEC sp_configure ‘xp_cmdshell’, 1
GO
RECONFIGURE
GO
Per SQL Server 2000 (8.0) invece non serve eseguire questi comandi perchè XP_cmdshell è acceso di Default. Personalmente preferisco tenerlo disabilitato, perchè può generare problemi, non perchè funzioni male, anzi, ma perchè è una porta aggiuntiva lasciata ai bontemponi che si dilettano a buttare giù sistemi. Avete letto bene, questo arnese, molto potente, è una fantastica Back Door per poter derubare o peggio distruggere il sistema informativo. Ad esempio è possibile lanciare il Format c: ! Prima di accenderlo, insomma, ci penserei bene…

Microsoft dice che…