Começo a aprender Rust

Começo a aprender Rust

Neste final de semana comecei a estudar a linguagem de programação Rust. E para registrar o meu estudo, pretendo escrever alguns textos aqui, começando pelo motivo de ter escolhido esta linguagem, mas depois comentar o que estou achando e dificuldades que estou encontrando.

O principal motivo para eu escolher esta linguagem está ligando as principais linguagens que utilizo, sendo que existia um caso onde elas não atendiam. Para entender a necessidade vou listá-las.

De forma geral utilizo shell script (bash para ser mais específico) quando tenho que fazer automações, ou se já existe algum programa pronto, simplificar o seu uso. Sendo seu maior exemplo o Commit Rules, que permite executar comandos para validar o commit, onde leio o arquivo de configuração, executo alguns comandos e manipulo a saída e exit status dos mesmos.

Quando preciso desenvolver algo mais elaborado, opto pelo Python, que por ser uma linguagem bem geral e de rápido desenvolvimento, facilita bastante o meu trabalho, sendo desde programas em linha de comando, até aplicações web. Vou deixar aqui de exemplo o Deduplicated, que foi desenvolvido como uma biblioteca, tendo tanto uma interface por linha de comando, quanto web.

Porém Python não é uma linguagem que tem foco em performance, especialmente na versão 3. Este foi um dos principais motivos de algumas pessoas da comunidade Python ficarem de olho no Go, o que talvez seria o meu caminho, se tivesse tido necessidade de performance. Também cheguei a pesquisar sobre o Genie, porém por ser recente e a pouca documentação, fizeram eu a deixá-la de lado, até por nem ela, nem Vala terem tido um grande sucesso.

Tenho algum conhecimento de C, porém é mais teórico que prático, não tendo tanta confiança para escrever um software seguro nesta linguagem. Também já tentei estudar mais sobre algumas ferramentas, como Make e Autoconf, porém não encontrei bons materiais para o meu estudo.

Neste ponto encontrei Rust, que pode ser visto como uma alternativa ao C, porém verifica o acesso seguro a memória em tempo de compilação, aumentando minha confiança em escrever um software seguro. Ele também um tem gerenciador de pacotes, que pelos meus testes funcionou muito bem e sem espalhar vários arquivos pelo sistema inteiro, podendo ser excluídos ao apagar um único diretório.

Rust tem outras qualidades, porém esses dois pontos suprem minhas “dificuldades” do C. Se encaixando como uma opção de linguagem quando preciso de desempenho (tenho controle semelhante ao C, e sem garbage collector como outras linguagens), porém ainda é uma linguagem nova com recursos bem interessantes em suas expressões (comandos).

No próximo texto comentarei mais sobre materiais e primeiras impressões.

Recuperando arquivos apagados

Uma hora ou outra, todos perderão alguns arquivos, corrompidos pelo sistema de arquivos, ou simplesmente deletado sem intenção. Na linha de comando é necessário ter cuidados maiores com espaços em branco. Meu problema não foi muito grave, na verdade até fiquei bem tranquilo, porém como sempre, ainda queria saber quais arquivos foram apagados para que pudesse recuperá-los. Contarei a história do que foi possível fazer neste caso.

A primeira coisa, para evitar mais perdas, aumentando as chances de recuperação, é desmontar a unidade, ou colocá-la em somente leitura, o que poderia ser feito com um umount ou mont -o remount,ro. No meu caso como era no próprio /, desliguei o computador e usei um sistema num pendrive. Isso é importante, como serão alterados alguns dados do sistema de arquivos, evita mais percas ou o corrompimento total do sistema de arquivos.

Uma ferramenta fácil e simples para recuperar os arquivos é o extundelete (pacote extundelete no Debian). Para usá-la basta executar extundelete, caminho do sistema de arquivos e uma opção de recuperação, como --restore-file caminho_do_araquivo, --restore-directory caminho_do_diretorio, ou até mesmo um --restore-all para recupera todos os arquivos. Lembrando que todos esses caminhos são relativos a raiz do sistema de arquivos, se o arquivo for o “/home/user/arquivo.txt”, sendo “/home” o ponto de montagem da partição “/dev/sdb1” seria extundelete /dev/sdb1 user/arquivo.txt.

Na maioria dos casos essa ferramenta atende, porém se quiser ir mais a fundo para buscar algum pedaço de informação que não pode ser recuperado ainda existe o debugfs. No caso executei um debugfs /dev/sdb1, executei o cd até chegar no diretório desejado e usei os comandos lsdel e ls -d para listar os arquivos. Com o ls -d consegui o número do inode aonde está o arquivo, na posse desta informação é possível utilizar várias outras técnicas, ou simplesmente a lista de arquivos que estava ali e foram apagados, mesmo que não tenha sido possível recuperá-lo anteriormente com o extundelete.

Dividir arquivos em partes

Recentemente tive que copiar um arquivo de quase 6 GB entre dois computadores que utilizo. Esses computadores não estavam perto um do outro, muito menos na mesma rede. Solução simples: utilizar um pendrive.

Meu celular tem espaço na memória interna suficiente para copiar o arquivo, porém para minha surpresa não consegui copiar o arquivo inteiro. Quando vi a mensagem de erro lembrei que o sistema de arquivos do celular é FAT, com o limite do tamanho em quase 4GB. Ou seja, o tamanho do arquivo é maior que o suportado pelo sistema de arquivos.

Como trocar o sistema de arquivos não era a opção, procurei como dividir o arquivo em partes. A solução é extremamente simples, basta utilizar o comando split. Este comando permite dividir o arquivo baseado em alguns critérios como bytes e número de linhas. Meu caso como é um arquivo binário e o que me interessava era o tamanho, fiz a divisão por bytes.

O comando utilizado foi:
split -b 1G arquivo-original prefixo-das-partes

Explicando, -b diz para o split dividir por bytes e que cada parte terá 1GB. arquivo-original é o arquivo que desejo dividir. prefixo-das-partes é o nome dado a cada parte, seguido de sua numeração, caso seja arquivo. serão criados vários arquivos como arquivo.aa, arquivo.ab e assim por diante. Se quiser números em vez de letras basta adicionar o parâmetro -d no comando.

Não foi o meu caso, porém se tiver um arquivo de texto grande, como um log, e quiser dividi-lo, basta utilizar o parâmetro -l 1000 que gerará arquivos de 1000 linhas cada, sem o risco de dividir alguma linha em dois arquivos.

Com cinco arquivos de 1GB e outro de aproximadamente 700MB, finalmente foi copiado para o celular.

Porém ainda precisava juntar as partes no destino, que bastou um:
cat prefixo-das-partes* > arquivo-original

Explicando, o cat recebeu o nome de todas as partes por causa do “*”, que também foram passadas como argumento na ordem correta, mesma coisa que executar um cat arquivo.aa arquivo.ab ... > arquivo. E assim recuperando o arquivo original.

O cat também funciona com arquivos de texto dividido pelo número de linhas. Se quiser dividir vários arquivos basta gerar um “.tar.gz” ou “.tar.bz2” antes.

FLISOL 2015

Neste final de semana aconteceu o FLISOL em várias cidades da América Latina, e eu estive presente no evento organizado pelo grupo Colméia na cidade de Joinville.

Gostei bastante do evento deste ano, as palestras foram bem interessantes, começando com uma sobre Openstack, Fedora Next, programação funcional com Haskell, licenças de software livre e Fedora QA (processo de qualidade). Também foi oferecido dois minicursos, shell script e arduino, porém não participei de nenhum.

Eu destaco a palestra sobre licenças, que falou sobre as liberdades, porém de uma forma muito mais prática. Além de incentivar o uso das licenças da família GPL, mostrou particularidades de cada uma. Então mesmo que você já soubesse a diferença entre software livre, open source e software proprietário, valeria a pena para entender como licenciar seu código e qual a melhor variação a ser utilizada.

Outra que gostei bastante foi a de programação funcional. Apesar de eu já ter ouvido falar sobre, nunca cheguei a estudar muito a fundo ou utilizar realmente em algum projeto, a meu ver caberia mais uma palestra mostrando o uso prático, com código, ou até um minicurso que com certeza eu faria-o.

Para quem pode ir até o local foi oferecido o steam das palestras, porém não achei essa informação no site e também não sei se ficou gravado em algum lugar. Então marco um ponto negativo a esta divulgação.

Agora é esperar até ano que vem. Quem quiser mais informações sobre o evento pode entrar no site oficial (http://flisol.info/), que apesar de estar em espanhol, tudo o que é referente ao Brasil está em português. Também recomendo o episódio da volta do Opencast que foi uma entrevista com o coordenador nacional do evento neste ano.

Atualização do Deduplicated e aviso

Não consegui escrever um post semana passada, infelizmente estou com menos tempo livre do que imaginei que teria este ano.

Porém semana passada não foi improdutiva, consegui fazer alguns testes do Deduplicated, que com alguns ajustes agora está funcionando com todos seus recursos no Windows também. Quem quiser fazer a instalação pode dar uma olhada no histórico da Issue no GitHub. Aproveito para agradecer a todos que deram uma olhada no projeto e até as pessoas que entraram em contato para verificar alguma questão.

Também comecei a publicar o código do meu gerenciador pessoa, são todos os repositórios que começam com “ergo” no meu GitHub, ainda estou mexendo bastante e pode mudar muita coisa até ficar relativamente estável. Quando conseguir finalizar mais alguns módulos e ajustes, trago um texto explicando sobre o mesmo.

Estou querendo iniciar mais um projeto, uma série na verdade, já tenho os assuntos separados, porém ainda preciso estudar alguns softwares antes de iniciá-la, mas aguarde por novidades no futuro. O que posso adiantar é que será sobre Python, porém não exatamente sobre desenvolvimento em si.

Aproveito para avisar que o FLISOL está chegando, então entre no site e descubra qual o local que terá o evento mais próximo de você. Nos dois anos que participei foi bastante interessante com várias palestras e até minicursos. Se você não tem muito conhecimento sobre software livre é uma ótima oportunidade, conhecer a comunidade da sua região, ou até aprender uma tecnologia/ferramenta nova nas palestras. Lembrando que você pode utilizar software livre, mesmo se seu sistema operacional não for.

Por hoje são estes avisos curtos.

Criptografando HD/HD externo/Pendrive

Já comentei em vários textos anteriores ferramentas que utilizo para o meu backup e chegou a vez da criptografia, processo que precisei refazer quando chegou meu novo HD externo. Na criptografia temos duas opções, a primeira é criptografar o arquivo, que depende do suporte do programa, ou que o mesmo seja descriptografado toda vez que for utilizado e criptografado novamente no final do processo. A segunda opção é criptografar o sistema de arquivos, que depende do suporte do sistema operacional, porém é transparente para os programas e os processos de criptografar e descriptografar é automático.

Minha opção foi criptografar o sistema de arquivos, e utilizar o recurso chamado dm-crypt, que no Debian existe um programa de configuração chamado cryptsetup, podendo ser instalado com um apt-get install cryptsetup.

Como este método de criptografia é baseado no sistema de arquivos, o particionamento ocorre da mesma forma, porém em vez de criar um sistema de arquivos Ext4, criei uma partição com o LUKS (Linux Unified Key Setup). Para explicar os comandos e quem tiver vontade poder executá-los também, em vez de criptografar uma partição, farei isso com um arquivo, já que em sistemas Unix tudo é arquivo, porém vale lembrar que todos os dados do arquivo ou partição serão perdidos.

Primeiro, para este exemplo, precisamos de um arquivo grande e existe uma forma de gerá-lo com o comando dd, exemplo: dd if=/dev/zero of=/tmp/arquivo bs=1M count=1024, se for fazer o procedimento numa partição, este comando não é necessário e troque sempre que vir o /tmp/arquivo pelo caminho da partição, exemeplo: /dev/sdb2. O parâmetro if=/dev/zero é um arquivo especial que possui zeros infinitos, então toda vez que for lido retornará “0”. O of=/tmp/arquivo é o caminho do arquivo que criarei, se for utilizado o caminho de um HD como /dev/sdb ou partição como /dev/sdb2 toda esta área será preenchida com zeros. Os parâmetros bs=1M e count=1024 representam o tamanho do bloco que será copiado e quantas vezes esse processo será repetido respectivamente, ou seja, serão copiados 1 MB 1024 vezes, gerando um arquivo de 1 GB em branco no HD.

Para formatarmos com o LUKS, podemos utilizar o comando cryptsetup luksFormat /tmp/arquivo e digitando a senha, lembrando que todos os dados do arquivo ou partição serão perdidos. Para conseguirmos utilizar a partição criptografada é preciso abri-la primeiro com o comando cryptsetup open /tmp/arquivo arquivo1, o primeiro é o caminho do arquivo o segundo é um nome para o mapeamento que será criado em /dev/mapper.

Próximo passo é a formatação do sistema de arquivos, porém em vez de formatar a partição diretamente, é preciso usar o mapeamento, no caso /dev/mapper/arquivo1. Um exemplo de formatação com Ext4 é mkfs.ext4 /dev/mapper/arquivo1. Agora podemos montar este mapeamento e gravar os arquivos normalmente que tudo salvo nesta partição será criptografada.

Na hora de remover a partição, basta fazer o procedimento na ordem inversa, primeiro desmonte o sistema de arquivo do /dev/mapper/arquivo1. Depois feche o mapeamento com o comando cryptsetup close /dev/mapper/arquivo1. Para abrir a partição novamente basta abrir o mapeamento e depois montar a partição.

Uma coisa legal do LUKS é que ele permite o uso de até 8 chaves diferentes, para adicionar uma chave nova basta executar o comando cryptsetup luksAddKey /tmp/arquivo, e agora qualquer uma das duas senhas poderão ser utilizadas para acessar a partição. Além de senhas também é possível utilizar um arquivo como chave o que pode ser um recurso interessante também. Caso deseje ver mais informações a respeito do LUKS ou chaves desta partição também é possível executar o comando cryptsetup luksDump /tmp/arquivo, um exemplo de saída é:

LUKS header information for /tmp/arquivo

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      81 e6 1f 37 b2 5c 8d 97 a4 a9 57 c1 2b 1b 89 49 35 0e 59 8f 
MK salt:        3b e4 4b bc 0d 09 b1 2a 5c 38 ea e2 a1 67 e6 5e 
                39 97 05 1d d5 73 cf 33 da 08 e1 bc 73 9f d5 95 
MK iterations:  146750
UUID:           2013f2e3-1d73-429a-818d-b4a182d8658e

Key Slot 0: ENABLED
        Iterations:             587155
        Salt:                   23 e7 e8 73 a0 a5 a9 58 a6 58 ba ec 81 41 49 d1 
                                75 a8 51 89 99 fb 8d a9 87 cc e7 23 eb bf 44 cb 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Para quem formatou uma partição em vez do arquivo, o navegador de arquivos pode simplificar o processo de acesso a partição, no meu caso no Thunar consigo acessar meu HD externo da mesma forma como se o mesmo não estivesse criptografado clicando no ícone do mesmo, porém aparece uma janela solicitando a chave de acesso.

Para quem quiser mais informações, ou desejar criptografar partições do sistema, recomendo dar uma olhada no texto da wiki do Arch Linux, que apesar de estar na wiki de uma distribuição específica, os programas são os mesmos para todas e a lógica é a mesma, só confirmar se os parâmetros da wiki existem na versão instalada no seu sistema, que as vezes um dos dois podem estar uma versão mais antiga.

Remover arquivos duplicados

Há algum tempo, escrevi sobre o método que utilizo para fazer backup do meu hd externo. Porém quando comecei a utilizá-lo, tinha pouco mais de 500 GB de arquivos e muitos backups antigos, diretórios que quando iria formatava o computador, simplesmente olhava que faltava fazer backup de um diretório apenas, copiava-o inteiro, recuperar os arquivos mais importantes ou utilizados, enquanto os demais ficavam perdidos e ocupando espaço, mesmo já vindo de outro backup.

A questão é que eu tinha, pelo menos, uns seis backups, envolvendo formatação e cópias de pendrivers. Muitos desses arquivos estavam repetidos, significando que eu poderia deixar apenas uma cópia, apagando as demais e mesmo assim ter todos os meus arquivos.

O primeiro método que pensei foi gerar hash de todos os arquivos, e depois compará-los para encontrar duplicados, porém gerar hash de 500 GB é extremamente demorado e muitos desses arquivos não sobrem alterações, então não seria necessário recalcular toda execução. Olhando no sistema de arquivos, temos a informação de última alteração no arquivo, então bastava gerar um cache com informações de arquivo, hash e data da última alteração, toda vez que o for executado, poderia comparar primeiro a data de alteração e calcular o hash apenas se necessário.

Com o script pronto, a primeira execução foi demorada, uma vez que teria que calcular o hash dos 500 GB, levando algumas horas, encontrando 5 GB de arquivos que poderiam ser apagados sem que eu perdesse qualquer informação. Uma próxima execução foi muito mais rápida, não levando mais de dois minutos, desde que com modificações em arquivos pequenos.

Consegui logo apagar uns 2 ou 3 GB, porém a lista de arquivos duplicados, apesar de auxiliar no processo, não era algo muito prática, uma vez que teria que buscar o arquivo manualmente para apagá-lo. Com arquivos grandes o processo ia rápido, e liberava mais espaço, porém em arquivos de texto puro não dava um rendimento satisfatório. Como sou programador web, logo montei uma página para listar esses arquivos, com um checkbox para selecionar os arquivos que desejava apagar, deixando o processo todo muito mais prático. Hoje tenho menos de 5 MB de pequenos arquivos duplicados, que comparados aos 5 GB representa menos de 0,1%.

Reorganizei todo o código, aproveitando para montar uma interface web mais completa, e publiquei o código no github sobre licença MIT (https://github.com/eduardoklosowski/deduplicated), então quem quiser dar uma olhada, utilizar, ou até contribuir com o desenvolvimento do mesmo fique à vontade.

Uma explicação rápida para quem deseja utilizá-lo. Por ser escrito em Python, recomendo a instalação via pip com o comando pip install git+https://github.com/eduardoklosowski/deduplicated.git ou pip install git+https://github.com/eduardoklosowski/deduplicated.git#egg=deduplicated[web] caso deseje instalar as dependências da interface web. Com isto você terá o comando deduplicated, bastando utilizar os parâmetros update para atualizar o cache dos arquivos, duplicated para listar os arquivos duplicados ou check para atualizar o cache e exibir os arquivos duplicados, seguido de um ou mais diretórios que deseja verificar, exemplo deduplicated check /home/eduardo. Caso tenha instalado a interface web, basta executar o comando deduplicated-web e abrir o endereço http://127.0.0.1:5050/.

Também existe uma opção para verificar se um arquivo está no cache com o comando indir, exemplo deduplicated indir meuarquivo.txt /home/eduardo. A vantagem é que você não precisa ter os arquivos para fazer essa verificação, eu verificava se os arquivos do meu notebook estavam no hd externo desta forma, sem precisar estar com ele ligado.

Recentemente tive um problema com o meu hd externo, essa história está no hack ‘n’ cast (quando for publicado disponibilizo o link aqui). Como eu tinha o cache do meu hd externo, pude compará-lo com o meu backup, descobrindo o que não estava atualizado e se eu tinha perdido algo. Esse procedimento se resumiu a executar as funções de atualização do cache na manualmente para adaptar certas partes e listar determinados valores. Caso alguém deseje posso até montar o script como uma função extra.

Eu fiquei extremamente feliz ao conseguir economizar o espaço do meu hd externo, o que já valeu o programa. Quando tive problemas no hd externo, percebi que ter as coisas organizadas e automatizadas, podendo consultar alguns logs, torna tudo mais fácil e tranquilo, bastando efetuar o RMA e depois executar um rsync para resolver todo o problema, obviamente teve a parte de formatação e criptografia também.

Licença de software

Hoje irei falar de uma coisa muito importante referente a software, a licença. Não quero entrar no mérito de qual é a melhor ou se existe uma que é correta. A ideia é apresentar a importância que a mesma tem quando você publica um software.

Quando você publica algum código, por exemplo no GitHub, esse código está sujeito as leis de direitos autorais, da mesma forma como se você publicasse alguma música ou vídeo. Ou seja, caso alguém utilize o seu código, você poderia processar essa pessoa ou empresa, não sei quem ganharia, porém como você não deixou explicito o quem tem tiver acesso ao código pode fazer com o mesmo, isso está no seu direito.

Por este motivo é de extrema importância definir uma licença, permitindo à quem tiver acesso ao seu código, os direitos que você desejar. Um código sem licença pode ser lido, uma vez que foi publicado, porém para poder utilizá-lo em outros programas, ou até mesmo fazer alterações teria que entrar em contato com o autor para conseguir este direito. No caso do GitHub o código fica sujeito aos termos de uso do site, porém se ele estiver em outro lugar, um fork poderia não ser permitido.

Outra diferença menos sutil e que muitas pessoas confundem é software livre com open source. Open source são programas que tem seu código fonte abertos, ou seja, você pode ver o código do programa, praticamente tudo que está hospedado publicamente no GitHub é open source (a menos que tenha um arquivo binário sem seu código fonte). Para ser software livre é necessário que a licença permita as quatro liberdades. Não é apenas a GPL que é compatível com essas quatro liberdades, um exemplo é a licença MIT, porém ainda permite fechar o código em alguma versão futura. Caso queira uma lista de licenças compatíveis, no site do projeto GNU existe uma lista em português e indica quais as incompatibilidades da licença quando existem.

Como todo software livre tem como requisito acesso ao código fonte, além de serrem livres, também são open source, porém nem todo open source é livre. Um código open source poderia estar disponível, porém não permitir sua alteração, ou redistribuição, tornando-o assim não livre. Mesmo com acesso ao código a licença poderia impedir até a recompilação do mesmo, tornando impossível saber se o binário distribuído é realmente do código publicado e que não teve nenhuma alteração, como uma vulnerabilidade implantada.

Publicar um código sem licença pode gerar resultados totalmente opostos ao objetivo do quando foi publicado, por isso preste atenção neste detalhe. Caso não tem certeza de qual licença utilizar, de uma olhada nesse site, que mostra algumas alternativas e compara licenças, então você pode focar nos pontos que deseja e procurar uma que se adéque melhor ao seu caso.

Microframework contra “Baterias Incluídas”

Python é uma linguagem de programação que tem a fama existir mais frameworks web que palavras reservadas, isso se reflete em uma diversidade de opções para os mais diversos gostos. Talvez isso seja um reflexo da diversidade de pessoas que utilizam o Python para as mais diversas finalidades.

Quando iniciei no desenvolvimento web, comecei com PHP, da forma mais simples possível, montando cada página em arquivos separados com alguns includes para não repetir muito o código. Quando migrei para Python, o primeiro impacto foi ter que utilizar algum framework e não seguir a forma de cada página num arquivo, até poderia manter os arquivos utilizando CGI, mas não teria desempenho, ou escrever o WSGI diretamente, mas acabaria criando outro framework para facilitar o processo.

Comecei a aprender o Django, achei legal, porém foi complicado por ser muito diferente do que eu estava acostumado e passava mais tempo consultando a documentação que programando efetivamente. Com a filosofia de “baterias incluídas”, o Django tem incorporado bibliotecas para as funcionalidades mais comuns de uma página ou aplicação web pode precisar, como formulário, acesso a banco de dados relacionais, paginação, internacionalização…

Outra opção que temos é utilizar um microframework, que auxilie apenas no WSGI e utilizar outras bibliotecas para montar a base da aplicação, como no caso do Flask. Ele vem por padrão com outras bibliotecas, como o Jinja 2 para auxiliar a escrever o html das páginas e caso precise de banco de dados ou formulários, basta instalar alguma biblioteca como o SQLAlchemy e o WTForms.

A primeira coisa que pode ser notada ao comparar esses dois modelos é a complexidade, com certeza um microframework é mais simples e fácil de aprender, uma vez que você está focado apenas em como interagir com o servidor ou protocolo HTTP, não tem que se preocupar com banco de dados por exemplo.

O primeiro ponto contra o microframework é a necessidade do programador conheçer ou procurar outras bibliotecas para partes específicas da aplicação, como persistência de dados. Muitas vezes isso pode levar ao desenvolvimento de algo que já está pronto e disponível por desconhecimento. Porém o programador não fica restrito ao que o framework suporta, podendo adotar qualquer tipo de biblioteca, diferente do Django que por exemplo não suporta oficialmente nenhum banco NoSQL, é possível utilizá-los, porém você não conseguirá integrá-los nativamente com os models e forms. Além de que utilizar algum framework específico pode aproveitar melhor as funcionalidades de um banco de dados, em vez de funções genéricas suportada por todos.

Por outro lado, uma vantagem de você ter um framework que define as bibliotecas é a possibilidade de integração das mesmas, como no caso do Django, com um model escrito, é extremamente fácil criar um form baseado no mesmo, com validação, ou fazer a migração do esquema da tabela no banco sem precisar escrever tudo na mão ou duplicar o código e lógicas. Também não é necessário sair procurando bibliotecas na internet, e você terá tudo em apenas uma documentação, que na hora de buscar ajuda evita respostas do tipo com a biblioteca tal funciona ou ter que conhecer mais de uma biblioteca que fazem a mesma tarefa para decidir qual das duas utilizar.

Microframeworks e “baterias incluídas” são abordagens opostas, cada uma pode se sair melhor que a outra de acordo com o caso. Se você tiver que desenvolver um sistema que necessite de bibliotecas que o Django oferece e se encaixe na forma dele de resolver os problemas, com certeza é uma ótima opção, uma vez que você terá as bibliotecas integradas e tudo pronto para utilizar. Caso o sistema seja mais simples, não necessitando de todas as bibliotecas oferecidas pelo Django, ou tenha necessidades mais específicas, o Flask começa a ganhar vantagens, uma vez que o fato de ser reduzido pode deixá-lo mais leve ou até ter uma configuração inicial mais rápida.

Com certeza tem o conhecimento das duas abordagens é importante na hora da decisão do framework, nada pior que durante o desenvolvimento o framework ficar atrapalhando, por ele não ter foco para um determinado fim, ou ser tornar burocrático demais para coisas simples. Para quem estiver conhecendo um framework como o Django e acha que algumas coisas seriam mais práticas fazer na mão, tente visualizar todo o processo, que em algum ponto será facilitado por ser desta forma ou mais prático, porém vai necessitar de algum tempo para acostumar.