Já entendeu como? Basta utilizar um redirect
Como exemplo, vamos tentar automatizar o fdisk, algo um tanto quanto complexo não? Vamos supor que você queira criar uma partição primária com todo o espaço disponível em /dev/sdb, pode fazer com o seguinte script:

#!/bin/sh
cat << EOF | fdisk /dev/sdb
n
p
1

w
EOF
partprobe

Agora basta  salvar e executar o script, ele ira inserir os comandos ‘n’,'p’,’1′,’Enter’,'w’ no fdisk, como faria uma pessoa de forma iterativa. No final irá chamar o partprobe para reler as tabelas dos discos.

1. Cria uma variável do tipo pthread_mutex_t
2. Inicializa
3. Dentro da thread, efetue um lock na área crítica da memória
4. Trabalhe na memória
5. Efetue um unlock da área crítica.

Vamos ao exemplo mais simples possível:Em nosso programa temos uma estrutura chamada “tst”, ela possui alguns dados que são populados pela thread create(), e lidos pela thread consume().

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <string.h>
#include <time.h>

typedef struct tst{
  int id;
  char nome[80];
  float valor;
  int valid;
  int qtd;
}TST;

Agora, vamos criar o mutex como sendo uma variável global mesmo (podíamos ter colocado dentro da estrutura)

pthread_mutex_t data_mutex = PTHREAD_MUTEX_INITIALIZER;

(A utilização da PTHREAD_MUTEX_INITIALIZER evita algumas linhas de código e inicializa o mutex mais simples possível)

Agora, vamos à função responsável por popular os dados:

void *create(void *data){
  int i;
  TST* lData = (TST*)data;
  int amount = lData[0].qtd;
  pthread_mutex_lock(&data_mutex);
  for(i=0;i<amount;i++){
    lData[i].id = i;
    snprintf(lData[i].nome,80,"Struct %d",i);
    lData[i].valor=i*i;
    lData[i].valid = 1;
  }
  pthread_mutex_unlock(&data_mutex);
  return NULL;
}

Em si, não tem nada de especial nessa função, ela recebe um void* (padrão de threads), transforma o mesmo no tipo TST declarado acima, efetua o lock da mutex com

pthread_mutex_lock(&data_mutex);

Trabalha nos dados normalmente e de forma segura e, finalmente, libera o lock:

pthread_mutex_unlock(&data_mutex);

Agora, vamos ver a função responsável por ler os dados:

void *consume(void *data){
  int i=0;
  TST *lData = (TST*)data;
  int amount = lData[0].qtd;
  for(i=0;i<amount;i++){
    fprintf(stderr,"%03d:%d\t%s\t%.2f\t%d\t%d\n",i,lData[i].id,lData[i].nome,lData[i].valor,lData[i].valid,lData[i].qtd);
  }
  return NULL;
}

Também nada de especial, como estamos apenas lendo, não existe motivo para efetuar um lock dos dados nesse momento, então a função é bem fácil, apenas pega os dados os mostra.

O resto do programa não é nada novo para ninguém, cria os dados iniciais, cria as duas threads e aguarda o fim das mesmas:

int main(int argc, char *argv[]){
  pthread_t threads[2];
  TST data[100];
  int i;
  memset(data,'\0',sizeof(TST)*100);
  for(i=0;i<100;i++)
    data[i].qtd=100;
  for(i=0;i<2;i++){
    if(pthread_create(&threads[i],NULL,(i==0?&create:&consume),data)!=0){
      perror("pthread_create");
      return 1;
    }
  }
  for(i=0;i<2;i++){
    if(pthread_join(threads[i],NULL)!=0){
      perror("pthread_join");
      return 1;
    }
  }
  fprintf(stderr,"Finished!\n");
  return 0;
}

Claro que existe muito mais que se pode fazer com mutex, mas isso fica para outro dia

PS: Obviamente, para compilar basta incluir a lib pthread:

$ gcc -o consumer consumer.c -lpthread

Para relembrar como se programa em CUDA, resolvi utilizar a versão 5.0, recém lançada, e entender como funciona a biblioteca CURAND para a geração de números aleatórios em GPU (extremamente importante ao utilizarmos AG). Os resultados que obtive foram, extremamente satisfatórios, veja dois exemplos de execução:

• Geração de 787.021.824 números aleatórios utilizando uma distribuição binomial

*********INFO********
*min:0
*max:100
*qtd:787021824
*output:binomial.csv
*distribution: BINOMIAL
*Verify? NO
********************
[*] Initializing host memory…OK (0.00000 ms)
[*] Initializing GPU memory…OK (1.76182 ms)
[*] Creating random numbers…OK (3018.16577 ms)
[*] Accumulatting…OK (1090.85291 ms)
[*] Writing accumulatted values to ‘binomial.csv’…OK
[*] Cleaning up memory…OK

Geração de 787.021.824 números aleatórios utilizando uma distribuição uniforme:

[*] Initializing host memory…OK (0.00000 ms)
[*] Initializing GPU memory…OK (1.76829 ms)
[*] Creating random numbers…OK (36.34749 ms)
[*] Accumulatting…OK (707.11194 ms)
[*] Writing accumulatted values to ‘/home/zarnick/tmp/uniform.csv’…OK
[*] Cleaning up memory…OK

Essa velocidade, convence?

Apesar da velocidade ser extrema, honestamente o código ainda está muito ruim, mas lá vai mesmo assim.
Todo o código foi baseado em 2 funções que utilizam a biblioteca CURAND para gerar os números:

__device__ int dBinomialRand(int n, float p, curandState *s);

__global__ void createRandomNumbers(int *vet, int dist, int min, int max, int qtd);

E 1 função que utiliza as funções atómicas (extremamente mais fácil do que criar e cuidar de MUTEX) para efetuar a acumulação (contagem de quantas vezes um número aparece):

__global__ void accumulate(int *vet, int *dest, int min, int max, int qtd);

Sem mais delongas, vamos aos códigos.

__global__ void createRandomNumbers(int *vet, int dist, int min, int max, int qtd){
  int tid = threadIdx.x + blockIdx.x*blockDim.x;

  curandState s;

  curand_init(tid,0,0,&s);
  while(tid < qtd){
    switch(dist){
      case UNIFORM: vet[tid] = min + curand_uniform(&s) * (max-min);
      break;
      case BINOMIAL: vet[tid] = dBinomialRand(max,0.5,&s);
      break;
      default: break;
    }
    tid += blockDim.x * gridDim.x;
  }
}

O funcionamento é bem simples, para cada thread, é utilizada uma semente (que é o próprio id da thread), é então criado uma estrutura do tipo curandState que é a responsável por iniciar a sequência de números aleatórios em curand_init() (para os preguiçosos, os parâmetros são, semente, início da sequência, offset e o curandState).
Uma vez feito isso, caso seja uma distribuição do tipo uniforme, apenas cria um número para cada thread em cada bloco do grid, entre os valores min e max passados, caso seja binomial, chame a outra função para fazer isso.
É simples assim para criar um número aleatório.
E para criar um número binomial…

__device__ int dBinomialRand(int n, float p, curandState *s){
  int x = 0;
  int i;
  for(i=0;i<n;i++){
    if(curand_uniform(s) > p )
      x++;
    }
  return x;
}

A função de acumulação é tão simples, que vou apenas mostrá-la:

__global__ void accumulate(int *vet, int *dest, int min, int max, int qtd)
{
  int tid = threadIdx.x + blockIdx.x*blockDim.x;
  while(tid < qtd){
    if(vet[tid] >= min && vet[tid] < max)
      atomicAdd(&dest[vet[tid]-min],1);
    tid += blockDim.x*gridDim.x;
  }
}

E a qualidade dos números? Bom, aqui está um pequeno gráfico que plotei com as duas funções:

A qualidade me parece correta não?

Como “sempre”, o código fonte e uma descrição mais detalhada pode ser encontrada em http://trac.geekvault.org/cuda/wiki/cuRand.

Para quem não sabe, é possível trocar as cores do ViM (Vi-iMproved) para alguns temas. Primeiramente veja quais são os temas disponíveis em /usr/share/vim/vim72/colors (ou diretório equivalente).
Para escolher algum tema, coloque em seu .vimrc (ou no /etc/vimrc) o comando

:colorscheme <tema>

Por exemplo, para utilizar o tema “darkblue”, coloque:

:colorscheme darkblue

O mesmo pode ser feito apenas para uma seção, porém não ira ser permanente.

Fica a dica.

Pessoalmente ainda não fiz o download (falta de tempo para analisar direito), mas para quem quiser, você pode fazer o download diretamente da App Store.

Error calling sqlite3_step (21: out of memory) rs

Desnecessário falar que, como o aplicativo ainda está em início de desenvolvimento, o erro “out of memory” não faz o menor sentido, a tabela em questão possui pouco mais de 6 linhas com 7 colunas cada, não fazia sentido.

Pois bem, aparentemente, no que o FMDB é muito bom em trabalhar com o banco, simplificando a criação da query, ele não é muito bom em mostrar erros. O problema em sí não é estouro de memória, mas sim que, na query que eu utilizo para montar o objeto, eu tento efetuar uma nova busca em uma outra tabela, na mesma conexão, ou seja:
 
FMResultSet *result = [[self database] executeQuery:@"select * from tabela"];
NSMutableArray *models = [[NSMutableArray alloc] init];
while([result next]){
  GVModel *model = [[GVDrinkModel alloc] init];
  [model setCampo1:[result stringForColumn:@"campo1"]];
  [model setCampo2:[result stringForColumn:@"campo2"]];
  [model setCampo3:[result stringForColumn:@"campo3"]];
  [model setCampo4:[result stringForColumn:@"campo4"]];
  [model setCampo5:[result stringForColumn:@"campo5"]];
  [model setCampo6:[result dateForColumn:@"campo6"]];
  NSData *imageData = [result dataForColumn:@"campo7"];
  [model setCampo7:[UIImage imageWithData:imageData]];
  [model setCampoExt8:[self getCampo8WithModel:model];
  [model setCampoExt9:[self getCampo9WithModel:model];
  [model setCampoExt10:[self getCampo10WithModel:model];
  [models addObject:model];
}

Para resolver esse problema, temos duas formas:

1. Alterar a query para efetuar um join com as outras tabelas externas e montar o resultado de acordo com as tabelas, ou
2. Após pegar apenas os campos internos, finalizar e abrir o banco de dados novamente.

Ambas as formas tem seus prós e contras, a vantagem de utilizar um join é a simplificação no acesso ao banco de dados, porém o mesmo deve estar bem estruturado. Caso você não saiba fazer um join, ou simplismente queira algo de desenvolvimento rápido, utilize a segunda opção. Porém atenção, se o banco estiver estruturado corretamente, um join quase sempre será mais rápido.

No meu caso específico, como 2 acesso externos geram dois arrays de n valores, optei (por desenho) uma mistura das soluções:

FMResultSet *result = [[self database] executeQuery:@"select t1.campo1, t1.campo2, t1.campo3, t1.campo4, t1.campo5, t1.campo6, t1.campo7, t2.campo8 from tabela t1, tabela t2 where t1.pk = t2.fk"];
NSMutableArray *models = [[NSMutableArray alloc] init];
while([result next]){
  GVModel *model = [[GVDrinkModel alloc] init];
  [model setCampo1:[result stringForColumn:@"campo1"]];
  [model setCampo2:[result stringForColumn:@"campo2"]];
  [model setCampo3:[result stringForColumn:@"campo3"]];
  [model setCampo4:[result stringForColumn:@"campo4"]];
  [model setCampo5:[result stringForColumn:@"campo5"]];
  [model setCampo6:[result dateForColumn:@"campo6"]];
  NSData *imageData = [result dataForColumn:@"campo7"];
  [model setCampo7:[UIImage imageWithData:imageData]];
  [model setCampoExt8:[result dataForColumn:@"campo8"];
  [models addObject:model];
}
for(GVModel *model in models){
  [model setCampoExt9:[self getCampo9WithModel:model];
  [model setCampoExt10:[self getCampo10WithModel:model];
}

Problema resolvido.

Provavelmente deve existir alguma opção no SQLite3 para permitir multiplos acessos e queries em uma mesma conexão, porém as 3 da manhã, esse tipo de pesquisa se torna inviável

• Sempre estruturar um bloco na ordem: declarações->código, nunca colocar uma declaração depois de iniciar um código.
• Sempre tomar cuidado com o tamanho do que vai na Stack.

E por verdade, sempre levei que o seguinte código não funciona:

#include <stdio.h>
int main(int argc, char *argv[]){
  int qtd;
  scanf("%d",&qtd);
  int vet[qtd];
  int i;
  for(i=0;i<qtd;i++) vet[i]=i;
  return 0;
}

Pois bem, esse código quebrava tudo que eu tomava por verdade, estou declarando uma variável depois de inicializar um código e, estou tentando alocar um vetor de tamanho desconhecido em tempo de compilação, na memória stack, não deveria funcionar certo?

Mas funciona!

Eis que veio o C99 e atualizou o padrão do C, agora (desde 1999), É possível criar um vetor de tamanho desconhecido em tempo de compilação. Enquanto alguns compiladores já faziam isso, mas não era padrão, após 1999, essa funcionalidade virou padrão do C. Que ótimo, quer dizer que agora eu posso criar vetores de tamanho n, sem precisar me preocupar com malloc() e cia?

Não exatamente, apesar de funcionar, a memória ainda é alocada na stack, ou seja, é muito fácil de estourar o tamanho da stack e, além disso, uma vez criado o vetor, ai sim o tamanho dele fica imutável. Então não, você não se livrou de malloc() e cia.

Pessoalmente, eu não considero isso uma boa prática, principalmente pois você não sabe o que o usuário vai pedir, vejo sua utilidade e simplicidade, mas, provavelmente, não vou adotar.

Obs: Para ver o padrão C99, veja esse PDF.

Não é nenhum dragão de sete cabeças, basta seguir os seguintes passos nessa mesma ordem:

1. Desmontar as partições.
2. Verificá-las com e2fsk -f.
3. Efetuar o resize2fs na partição que se deseja diminuir.
4. Efetuar o lvreduce no volume lógico que se deseja diminuir.
5. Efetuar o lvextend no volume lógico que se deseja aumentar.
6. Efetuar o resize2fs na partição que se deseja aumentar.
7. Efetuar, novamente, o  e2fsck -f em ambas as partições.
8. Montá-las e utilizá-las normalmente.

Importante frisar que a ordem dos passos, principalmente a 3 e 4, não podem ser alteradas, caso contrário você poderá render o seu sistema inoperante na partição a ser diminuída!

Nada melhor do que mostrar com um exemplo certo? Vamos então redimensionar a partição /usr/local de 27Gb para 25Gb, e aumentar a /tmp com o diferença:

1. Verificando o tamanho e desmontando as partições
   
[root@localhost ~]# df -h /usr/local/ /tmp/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sys-local
27G 173M 25G 1% /usr/local
/dev/mapper/sys-tmp 3.9G 69M 3.7G 2% /tmp
[root@localhost ~]# umount /usr/local /tmp

2. Verificação com o e2fsk -f
   
[root@localhost ~]# e2fsck -f /dev/sys/local
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sys/local: 42/7077888 files (2.4% non-contiguous), 265736/7077888 blocks
[root@localhost ~]# e2fsck -f /dev/sys/tmp
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sys/tmp: 14/1048576 files (7.1% non-contiguous), 50276/1048576 blocks

3. Efetuando o resize2fs na partição a ser diminuida
   
[root@localhost ~]# resize2fs /dev/sys/local 25G
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/sys/local to 6553600 (4k) blocks.
The filesystem on /dev/sys/local is now 6553600 blocks long.

4. Efetuando o lvreduce na partição a ser diminuida
   
[root@localhost ~]# lvreduce /dev/sys/local -L -2G
/dev/hdc: open failed: No medium found
WARNING: Reducing active logical volume to 25.88 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce local? [y/n]: y
Reducing logical volume local to 25.88 GB
Logical volume local successfully resized

5. Efetuando o lvextend no volume lógico a ser aumentado
   
[root@localhost ~]# lvextend /dev/sys/tmp -L +2G
/dev/hdc: open failed: No medium found
Extending logical volume tmp to 6.00 GB
Logical volume tmp successfully resized

6. Efetuando o resize2f na partição a ser extendida
   
[root@localhost ~]# resize2fs /dev/sys/tmp 6G
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/sys/tmp to 1572864 (4k) blocks.
The filesystem on /dev/sys/tmp is now 1572864 blocks long.

7. Efetuando o e2fsk -f nas partições, novamente
   
[root@localhost ~]# e2fsck -f /dev/sys/local
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sys/local: 42/6553600 files (2.4% non-contiguous), 249320/6553600 blocks
[root@localhost ~]# e2fsck -f /dev/sys/tmp
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sys/tmp: 14/1572864 files (7.1% non-contiguous), 66692/1572864 blocks

8. Montando e correndo para o abraço
[root@localhost ~]# mount /usr/local/
[root@localhost ~]# mount /tmp
[root@localhost ~]# df -h /usr/local /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sys-local
25G 173M 23G 1% /usr/local
/dev/mapper/sys-tmp 5.9G 69M 5.5G 2% /tmp
[root@localhost ~]# touch /tmp/a
[root@localhost ~]# ls /tmp/
a hsperfdata_daemon lost+found
[root@localhost ~]# ls /usr/local/
bin etc games include lib lib64 libexec lost+found sbin share src


Nnovamente, atenção na ordem, se diminuir o volume lógico ANTES de diminuir a partição, você pode perder tudo nesse partição. Caso isso aconteça, a única solução que encontrei até hoje foi:

1. Antes de efetuar o resize2fs, ele irá pedir para rodar o e2fsck -f, que irá falhar, esse é o indício de que algo aconteceu errado.
2. Então efetue o inverso, um lvextend e comece novamente.

Vamos mostrar na prática:


[root@localhost ~]# umount /tmp/
[root@localhost ~]# lvreduce /dev/sys/tmp -L -2G
/dev/hdc: open failed: No medium found
WARNING: Reducing active logical volume to 4.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce tmp? [y/n]: y
Reducing logical volume tmp to 4.00 GB
Logical volume tmp successfully resized
[root@localhost ~]# resize2fs /dev/sys/tmp 4G
resize2fs 1.39 (29-May-2006)
Please run 'e2fsck -f /dev/sys/tmp' first.
[root@localhost ~]# e2fsck -f /dev/sys/tmp
e2fsck 1.39 (29-May-2006)
The filesystem size (according to the superblock) is 1572864 blocks
The physical size of the device is 1048576 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

Ok, aqui vimos que algo muito feio aconteceu, vamos tentar voltar:

[root@localhost ~]# lvextend /dev/sys/tmp -L +2G
/dev/hdc: open failed: No medium found
Extending logical volume tmp to 6.00 GB
Logical volume tmp successfully resized
[root@localhost ~]# e2fsck -f /dev/sys/tmp
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sys/tmp: 15/1572864 files (6.7% non-contiguous), 66692/1572864 blocks
[root@localhost ~]# mount /tmp/
[root@localhost ~]# df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sys-tmp 5.9G 69M 5.5G 2% /tmp
[root@localhost ~]# touch /tmp/a
[root@localhost ~]# ls /tmp/
a hsperfdata_daemon lost+found

E tudo volta ao normal, agora volte e faça na ordem certa!

• Instalação
• X11
• MacFUSE
• macports
• Como utilizar direito o Notification Center com o Mail
• Drag n’ drop no trackpad

Mais para frente eu faço um review completo, mas por enquanto vamos ao que aconteceu e como resolvi:

Instalação

O problema da instalação, posso falar que foi uma parte minha culpa, outra parte a dificuldade de resolver o problema pela Apple, basicamente, o que aconteceu foi que o meu HD tinha alguns erros de I/O e não instalava o Mountain Lion nem por reza brava, assim como o Disk Utility não conseguia reparar e, essa é a pior parte, eu não conseguia sair da instalação e voltar para o Lion!

Isso me fez perder mas boas 8 horas tentando reparar, verificar permissões e o raio que o parta no HD para, no final, formatar e restaurar do Backup via TM, uma vez restaurado (havia feito um backup segundos antes de iniciar a instalação), consegui instalar normalmente, mas só ai foram mais umas 5 horas (4 para restaurar e 1 para instalar).

Ok, minha culpa não ter verificado o HD antes (até por que, ele era praticamente novo, quem ia imaginar?), mas pow Apple, não poder sair da instalação é fogo ein?

X11

Uma vez instalado, logo fui testar se continuava funcionando tudo, uma das coisas que costumo utilizar, muito é o SSH, e o SSH com suporte a X para subir uma ou outra interface gráfica dos servidores externo, e foi ai que fiquei pasmo, não tinha mais X11. Depois de procurar (o que poucos fazem), encontrei que a Apple realmente retirou o X11 do Mountain Lion, e trocou pelo XQuartz. Ok, acontece, mas o que me deixou fulo foi outro fato relacionado a isso, uma coisa é não suportar, ou até mesmo, toda santa vez que for utilizar, avisar para utilizar o XQuartz no lugar, mas não, a Apple simplesmente retirou, não avisou ninguém e deixou quieto exceto por uma pequena nota no site dela. Achei meio sacanagem, sabe-se lá o que mais eles retiraram de vez.

MacFUSE

Ta ai outra coisa que uso, e uso muito que, simplesmente não funcionava mais. Ok, eu sabia que não iria funcionar, pesquisei antes, mas também me falaram que bastava reinstalar…e quem diz que reinstalava? Depois de muito tenta e retentar, a solução foi…veja o próximo item.

macports

Então chegamos no macports, quem não conhece, deve conhecer, é o ports do BSD portado para Mac, funciona perfeitamente e, muitas vezes (*cough* *cough* GIMP) funciona melhor que o pacote feito para o Mac. Enfim, cheguei no macports por causa do MacFUSE, sempre funcionou pelo macports e resolvi reinstalar. Tive tanto problema de bibliotecas e todo o resto, que resolvi fazer o impensável (utilizo macports desde que tenho mac…), retirar tudo do macports e reinstalá-lo, não é que funcionou? Inclusive o MacFUSE.

Sei que esses dois não são coisas do Mountain Lion, mas me deixou fulo.

Como utilizar direito o Notification Center com o Mail

Para esse ainda não encontrei uma solução, a única coisa que eu realmente gostaria, era de poder selecionar as pastas de dentro do Mail para aparecer no Notification Center, no chance, apenas o Inbox, um pouco de customização cai bem não? E não acredito que seja complexo fazer uma coisa dessas…thanks Apple, for not letting me do the way I want!

Drag n’ drop no trackpad

Esse para mim, foi o mais sem noção, sabe quando você tem o MacBook ou um Magic Trackpad externo e da um duplo clique com um dedo para ativar o drag? Então, não tinha mais essa opção. COMO ASSIM??? Pelo menos foi o que eu pensava, eu procurei, procurei, e procurei mais um pouco, mas pelo visto não havia procurado direito, esse post do suporte da Apple me fez ver onde estava escondida essa opção, dentro de Universal Acces! Ai você me fala, mas isso vem desde o Lion, como você usava antes? Pois bem, no Snow Leopard ficava nas opções do trackpad, no Lion vinha ativado por default, no Mountain Lion não!

Essa mania da Apple de tentar deixar tudo que nem o iOS me deixa P*** da vida, não faz sentido, uma coisa é um celular/tablet, outra coisa é um computador…vamos ver quantas mais coisas vão retirar ou mudar no próximo lançamento!