~marado's tildelog

a tildelog on tildeverse

Happy 20th birthday, ANSOL!

09 de outubro de 2021 — ~marado

Today we celebrated the 20th anniversary of ANSOL, the Portuguese Free Software Association. It has been an honor to be part of the history of this still young association, and here's hope for an active 20 years more - I'll gladly celebrate its 40th!

Image of the round table where I've participated

In these past 20 years, ANSOL worked on many issues, but if I had to highlight 3, I'd point out:

But there are many more challenges ahead... and our victories aren't closed books.

So, what now? Well, there is plenty to do: we should ensure we don't loose the Freedoms we have achieved, and we should strive to get those we still didn't get.

There is plenty more to do, and you can help.

If you're in Portugal, join ANSOL. If you're in Europe, FSFE will appreciate your contribution. If you're in Latin America, here's your link. In India, join here. Based in North America, with worldwide mission, there's FSF.

Of course, as we could see in those who have joined ANSOL in today's celebration, there is plenty beyond the realm of software. Consider getting to know Wikimedia Portugal or the Wikimedia Foundation, Direitos Digitais in Portugal and EDRI in Europe or EFF overseas.

Let's shape the future, together.

tags: ANSOL, Free Software, Digital Rights, EN

comentários? tweetar  

Are Cassette tapes dead? (again)

31 de maio de 2021 — ~marado

Tired of reading people saying that one or another mature technology was dead, ten years ago I decided to act upon one of those claims (saying that cassette tapes were dead) and write a blog post, where, using the data available on Discogs, I made a graph showing the percentage of cassette releases related to all of the releases on that database.

That blog post had more success than I thought would have, with some people, once in a while, wondering how were things progressing (not only regarding the cassette tapes market on current days, but also the growth of discogs' database and its knowledge of past releases). I did update the graph a few times since the initial blog post, but today, to mark the 10th anniversary of the initial post, I decided to actually write a script that automatically generates such a graphic, and generate one of those graphs, once again.

And, guess what!, turns out cassette tapes aren't dead, or even dying.

graph showing the percentage of cassette tape releases

tags: discogs, stats, cassette, tape, compact cassette, music, data, software, music business, music market, en

comentários? tweetar  

O manifesto das cebolas na era da transição digital

11 de maio de 2021 — ~marado

Ocorre-me com regularidade que eu escrevo demasidos comentários em redes sociais efémeras por natureza, ideais que rapidamente se perdem em eternos scrolls. Este é um texto que escrevi numa thread no twitter e que agora republico aqui, para mais fácil guardar para a posteridade.

Em 2012, a ANSOL - Associação Nacional para o Software Livre, lançou o seu manifesto do campo das cebolas. Aí criticava o esbanjar de dinheiros públicos na aquisição - frequentemente ilegal - de software.

A ESOP - Associação de Empresas de Software Open Source Portuguesas, fez de um desses contratos exemplo: levou a Câmara Municipal de Almada a tribunal e ganhou. Mas de que serve uma vitória, num caso, se a prática se mantém?

Em 2013, observaram um aumento de 143% no valor destes contratos ilegais. Tinha já, entretanto, entrado em funcionamento o mecanismo de pareceres prévios da AMA. Ainda assim...

Em 2017, numa investigação do Público, chega-se à conclusão que, neste aspecto, nada mudou para melhor. Diz-se, então, que esta prática "deveria merecer uma acção da Comissão Europeia." Hoje fala-se de transição digital, mas sobre isto nada foi feito.

Hoje lembrei-me disto, porque alguém reclamava deste contrato, em que o SNS gasta perto de 300 mil euro em licenças de Office 365. Dir-me-ão que o SNS, agora, não tem alternativa noutro fornecedor. Já estava previsto no manifesto da ANSOL:

"provavelmente dirão que não têm conhecimento de alternativas ou que têm conhecimento mas não têm capacidade para as implementar e gerir. Ou pior, dirão que devido às decisões que eles mesmo tomaram no passado - que os deixaram enredados num esparguete de dependências"

Mas, convém sublinhar, também diz o manifesto das cebolas, "quem paga somos nós", e há alternativa.

Estes milhões são nossos. Até quando estaremos dispostos a esbanjá-los assim?

tags: PT, ANSOL, ESOP, SNS, Microsoft, Licenças, Office-365, Office, manifesto, contratos, públicos, ilegais, contratos-públicos, contratos-ilegais, transição, digital, transição-digital

comentários? tweetar  

Voto electrónico em Portugal - mais do que um problema técnico, um problema legal

11 de maio de 2021 — ~marado

O debate do voto electrónico tem décadas, mas, ainda que a investigação na área tenha apresentado evoluções, a discussão sobre a temática nem por isso. Pilotos atrás de pilotos, e tentativas de implementar o voto electrónico em Portugal vieram e falharam, mas pode-se sempre apontar o dedo a uma coisa: uma fraca implementação. Esse problema tem duas facetas: se, por um lado, aqueles que se opõe na generalidade ao voto electrónico têm uma forma fácil de apontar o dedo à má impementação e dizer "vêm?, não presta!", esse argumento acaba por não convencer aqueles que são a favor do voto electrónico, com o argumento de que "lá porque este foi mal feito, não quer dizer que não se possa fazer bem".

Também foi assim nas últimas Europeias, que em Portugal incluiram um piloto de voto de electrónico, que correu francamente mal - porque (adivinhe-se) tinha uma implementação má. Mas se a experiência serviu para alguma coisa, no que diz respeito à comunicação social e ao debate político, foi para por o tema outra vez na agenda política, e nunca se falou em portugal sobre o voto electrónico como hoje. Em vez que servir como prova de que o voto electrónico é uma má ideia, o exemplo serviu para aguçar apetites.

Mas, para o debate - se alguém o quiser efectivamente ter, e de forma séria - sobre a implementação de um sistema de voto electrónico em Portugal, o melhor contributo deste exemplo piloto que tivemos foi o post-mortem feito pela CNPD. O documento, que fez headlines nos jornais, e que demonstra que a implementação da solução usada era má, foi, mais uma vez, usado por vários como ponto de partida para dizer "a solução é má, mas podem haver boas." Contudo, parece-me, quem diz isso não olhou para o documento como um todo.

O parecer da CNPD é uma leitura no total interessante, mas há um segmento em particular que me parecem muito útil. Mas, para quem pensava que ia ler um artigo a falar blockchain ou de consenso bizantino... lamento. O excerto do parecer que me parece valer a pena destacar é o que demonstra que o problema do voto electrónico em Portugal é, mais do que um problema técnico, um problema legal. Não me refiro à parte que diz "qualquer solução precisa de ser legislada exaustivamente, o que não tem acontecido" (o que é verdade, mas é resolúvel apenas com a criação de mais legislação), mas sim à parte que diz:

a questão da transparência elencada no n.º 1 do artigo 5.º do RGPD tem de ser tida à luz da possibilidade de os titulares dos dados (leia-se "eleitores") poderem compreender, de forma completa (ainda que não exaustiva), como decorrem as operações de tratamento que incidem sobre os seus dados pessoais, entre as quais se encontra a votação.

É importante, porque declara que, à luz do RGPD (em vigor não só em Portugal mas nos diversos estados membros), obriga-se a que um sistema eleitoral - que por natureza lida com eleitores e seus votos - seja compreensível pela generalidade dos eleitores, coisa que não pode acontecer num sistema da complexidade exida por um sistema fiável de voto electrónico.

A CNPD aponta para o exemplo da Alemanha, em que este conflicto entre os sistemas de voto electrónico e a compreensão pelo cidadão comum do seu funcionamento foi levado ao seu Tribunal Constitucional, levando à decisão de não implementação de voto electrónico, mas não é só na Alemanha que esta questão precede o RGPD. No texto da associação D3 - Defesa dos Direitos Digitais - sobre o voto electrónico, escrito em antecipação às europeias - quando a última experiência de voto electrónico decorreu em Portugal - lê-se:

todo o cidadão deve poder compreender ele próprio o funcionamento do sistema eleitoral do país, qualquer que seja o sistema, por forma a ter suficiente confiança de que este está em conformidade com a lei. Uma solução digital será sempre uma solução demasiado complexa, mesmo para os eleitores mais esclarecidos, o que irá inevitavelmente trazer desconfiança ao processo legislativo e aos seus resultados por parte de quem tenha resultados inferiores ao que esperava.

Mas será assim? Bem, em Portugal existem vários actos eleitorais, cada um com a sua Legislação aplicável. Temos, por exemplo, na Lei Eleitoral dos Órgãos das Autarquias Locais (que rege as Autárquicas que em breve decorrerão em território nacional), o Artigo 52.º que diz:

Cabe à Comissão Nacional de Eleições promover, através de meios de comunicação social, públicos e privados, o esclarecimento objectivo dos cidadãos sobre o significado das eleições para a vida do País, sobre o processo eleitoral e sobre o processo de votação.

Terá a CNE os meios necessários para cumprir tal artigo - no que diz respeito ao esclarecimento objectivo sobre o processo eleitoral - se o processo for por via electrónica?

Em jeito de conclusão

Tem-se discutido cada vez mais sobre o voto electrónico em Portugal. Contudo, tem-se falado do tema como se ele fosse maioritariamente um desafio técnico, quando, a meu ver, os entraves são legislativos. Não estou a defender que o "direito ao esclarecimento" deve ser posto de parte, mas acredito que é aí que o debate se deve centrar. A legislação actualmente em vigor - tanto nacional como comunitária - defende esse direito ao esclarecimento, que é incompatível com um sistema de voto electrónico(1). Acredito que haja quem ache que ter voto electrónico é mais importante - mas então é esse o argumento que deve ser feito por quem assim o acha, em particular devendendo as alterações legislativas necessárias. Esse debate pode trazer algum fruto. O técnico, parece-me, está ao mesmo nível em 2021 que estava há duas décadas atrás, e assim continuará.

ler mais...

comentários? tweetar  

repo: using a local manifest

28 de fevereiro de 2021 — ~marado

One of the useful and rarely mentioned configurations of repo is the use of local manifests.

See, repo is a powerful tool when you need to deal with a project that uses several git repositories at the same time, and those are controled by a manifest file. However, on your local development environment, you will often want to extend or change something on the environment described on the manifest, either by removing, adding or more often replacing one of the entries with a slightly different configuration.

You can do that by using a local manifest, that will be applied on the top of the other manifest files. The CyanogenMod project used to have a pretty nice documentation about this, but that's one of the contents that were not migrated into Lineage OS's wiki, so I decided to make this blog post, reproducing the old wiki's content.

The local manifest

Creating a local manifest allows you to customize the list of repositories used in your copy of the source code by overriding or supplementing the default manifest. In this way, you can add, remove, or replace source code in the official manifest with your own. By including repositories (which need not even reside on GitHub) in a local manifest, you can continue to synchronize with the repo sync command just as you would have previously. Only now, both the official repositories from the default manifest and the additional repositories you specify will be checked for updates.

Adding and replacing repositories

To add to the contents of the default manifest, create a folder called local_manifests under the .repo directory, then create an XML file (text file with .xml extension) inside that directory. You can call the XML file anything you like, as long as it ends in .xml. The default however is roomservice.xml. Also, you can create separate XML files for different groups of repositories. e.g. mako.xml for Google Nexus 4 related repositories and cat-eater.xml for an unofficial device on which you're working.

Let's start with an example which we can use to describe the syntax:

<?xml version="1.0" encoding="UTF-8"?>

<manifest>

<remote name="omap" fetch="git://git.omapzoom.org/" />

<remove-project name="CyanogenMod/android_hardware_ti_omap3" />

<project path="hardware/ti/omap3" name="platform/hardware/ti/omap3" remote="omap" revision="jb-dev"/>

</manifest>

The first line containing <?xml version="1.0" encoding="UTF-8"?> is a standard XML declaration, telling interpreters this is an eXtensible Markup Language file. Once this is established, the <manifest> and </manifest> tags enclose some contents which the repo command will recognize.

First, a remote for git is declared and given the name "omap". In git, a remote essentially refers to a place and method for accessing a git repository. In this case, omapzoom.org is a site that contains special up-to-date repositories for Texas Instrument's OMAP platform. This is equivalent to the following git command:

git remote add omap git://git.omapzoom.org/

The next line removes a project (specifically, cyanogenmod/android_hardware_ti_omap3) declared in the default manifest. After running repo sync, it will no longer be available in the source tree.

The next line defines a new project. In this case, it replaces the removed project android_hardware_ti_omap3 with one from Texas Instruments, using the "omap" remote that was defined above.

When adding a new project that replaces an existing project, you should always remove that project before defining the replacement. However, not every new project need replace an existing cyanogenmod project. You can simply add a new project to the source code, such as when you want to add your own app to the build.

Note that when adding new projects, there are at least three parts defined:

  • remote -- the name of the remote. this can be one that was defined in either the default manifest or local_manifest.xml.
  • name -- the name of the git project-- for github it has the format account_name/project_name.
  • path -- where the git repository should go in your local copy of the source code.
  • revision -- (optional) which branch or tag to use in the repository. If this attribute is omitted, repo sync will use the revision specified by the <default ... /> tag in the default manifest.

After creating .repo/local_manifests/your_file.xml, you should be able to repo sync and the source code will be updated accordingly.

Note: You can use local repositories in the manifest by creating a remote that points to file:///path/to/source. For example: <remote name="local-omap" fetch="file:///home/username/myomap" />

License

All textual content of the CyanogenMod Wiki was released under the Creative Commons Attribution-Share Alike 3.0 Unported license (CC-BY-SA), and so this blog post should be considered licensed under the same terms.

tags: repo, manifest, local-manifest, local_manifests, git, en

comentários? tweetar  

Dia Mundial da Internet

17 de maio de 2020 — ~marado

Feliz dia mundial da Internet! Sabias que...

  • Há 30 anos atrás (1990) foi organizada a 1ª Convenção Portuguesa de Unix.
  • Há 29 anos atrás (1991) foi montado o ".PT" ...
  • Há 28 anos atrás (1992) o tld "PT" foi reconhecido. O primeiro talker Português foi criado.
  • Há 27 anos atrás (1993) a EUNET era assim.
  • Há 26 anos atrás (1994) teve lugar no LNEC, o seminário "Portugal na Internet". Ligar à internet em Portugal era assim:

ligar à Internet em Portugal, em 1994

  • Há 25 anos atrás (1995) foi fundado o SAPO, na Universidade de Aveiro.
  • Há 24 anos atrás (1996) existem 10 entidades com licença para prestação de Serviços de Telecomunicações Complementares Fixos, no âmbito dos quais se pode enquadrar o acesso à Internet.
  • Há 23 anos atrás (1997) a PTNET, a maior rede de IRC Portuguesa, foi criada. Pulhas, Toxyn e KaotiK iniciam a sua campanha de hacktivismo por causa da ocupação a Timor.
  • Há 22 anos atrás (1998) a Saber & Lazer - Informática compra o SAPO.
  • Há 21 anos atrás (1999) a Sonaecom cria a Novis, resultante da compra da IP Global, e a marca Clix para o mercado residencial. A Esoterica é comprada pela VIA NET.WORKS.
  • Há 20 anos atrás (2000) a EUnet Portugal passa a KPNQwest.
  • Há 19 anos atrás (2001) a ANSOL - Associação Nacional para o Software Livre, é anunciada, durante a edição de 2001 do "Porto, Cidade Tecnológica".
  • Há 18 anos atŕas (2002) tanto o SAPO como o Clix lançam as suas ofertas de ADSL.
  • Há 17 anos atrás (2003) a moda dos blogs chega em força a Portugal, com a criação do serviço SAPO Blogs.
  • Há 16 anos atrás (2004) a Novis adquiriu a KPNQwest Portugal (antiga EUNet Portugal), ficando assim com o legado do primeiro ISP em Portugal (ainda enquanto PUUG).
  • Há 15 anos atrás (2005) o Clix lançou no mercado uma oferta de 16Mbps utilizando a tecnologia ADSL2+.
  • Há 14 anos atrás (2006) o Clix lançou para o público a SmarTV, um serviço de Televisão Digital e Home Video utilizando o sistema IPTV sobre a tecnologia ADSL2+, sendo a primeira oferta em Portugal a utilizar esta tecnologia.
  • Há 13 anos atrás (2007) a marca Novis foi incorporada pela marca Optimus. O evento SAPO Codebits teve a sua primeira edição.
  • Há 12 anos atrás (2008) apareceu a Clix Fibra, a primeira oferta comercial em Portugal de ligação à internet através de fibra óptica.

tags: pt, internet, history

comentários? tweetar  

Contact Tracing

09 de maio de 2020 — ~marado

Pensei fazer um tweet, e quando dei conta tinha monologado uma thread bem grande. Para facilitar a sua leitura, decidi publicar essa thread aqui.

O Ricardo Lafuente escreve mais um interessantíssimo artigo no seu blog, desta vez sobre Contact Tracing.

Todo o artigo é bom (e leitura recomendada), mas gosto principalmente por estas duas frases que, em meu entender, são as que metem o dedo bem mesmo na ferida:

Seria ótimo termos em mãos a informação sobre o que se pretende implementar em Portugal, mas não existe ainda qualquer documento formal a descrever o que se está a preparar, apenas comentário de imprensa. Não pode ser assim, se estamos a falar de uma decisão sócio-política com implicações que ainda não conseguimos quantificar enquanto sociedade, mas cujo desfecho definirá as nossas existências nos tempos que aí vêm.

A meu ver, não podemos continuar a estar nesta situação em que aparentam estarem a testarem-se águas sobre várias soluções e a tentar formar opinião pública, sem que todas as cartas sejam postas em cima da mesa. É assim que temos coisas como este artigo da DECO, ao mesmo tempo que temos a admissão, mesmo dos proponentes deste tipo de apps, que, na realidade, a privacidade não está garantida, apesar dos riscos estarem minimizados (supostamente: nos promenores, encontram-se diversos compromissos a serem tomados mas várias soluções).

O artigo da DECO tb é apresentado como "país quer ARCs", quando na realidade os números que lá se vêm falam do inverso: afinal, "a maioria" pouco importa neste discurso, menos de 60% da população se voluntaria para o uso, e sem 60% estas apps são inúteis, dizem os estudos.

De notar que, pelo que se vai sabendo pela imprensa, a "app oficial", apoiada pelo Governo, será a StayAway, do INESC TEC. Mais uma vez, só se sabe dessa app o que vai aparecendo na imprensa, mas já com detalhes que levantam muitas questões.

Mas será mesmo assim? Urge que o Governo seja claro e transparente. Vai mesmo adoptar uma ferramenta? Haverá ainda espaço para o debate público sobre esta matéria? A adoptar, será mesmo a StayAway? Se sim, há ainda espaço para debate sobre as decisões de arquitectura da solução?

Urge termos respostas para estas perguntas. Até lá, será útil ler o artigo de ontem da ACM sobre o tema. Destaco três frases:

No known tracing applications can fully preserve individual privacy and anonymity, while multiple technical issues hinder the ability to prove or assume the apps' accuracy.

Moreover, high technical quality and functionality are insufficient for ensuring their efficacy.

Mechanisms should be employed for seeking the public’s and civil society representatives’ comment on proposed contact tracing technology and all aspects of its intended deployment.

tags: pt, tracing, COVID-19, privacy

comentários? tweetar  

Decentralized Privacy-Preserving Proximity Tracing -- is it really?

29 de abril de 2020 — ~marado

DP-3T, as it is known, stands for Decentralized Privacy-Preserving Proximity Tracing. It tries to be a decentralized, privacy-preserving solution to a problem: to make phone applications help mitigate the current COVID-19 pandemic.

OK, let me take a step back. There have been talks (and in some contries already actions) about having an app to use phones in order to help track down the spread of COVID-19. I am not focused, in this article, to argue that the idea, in general is bad (tip: I think it is, due to privacy concerns), or to point out that relying on big companies like Google or Apple to "take care of it" using closed and opaque methods is a really bad idea (tip: it should be obvious: it is). I also don't plan to discuss what is each country proposing, adopting, or doing: not even the Portuguese case, where the Prime Minister and President announce they are against geolocalization, one week later the same Prime Minister consider it a possible solution, and one other week later the adoption of a platform for that is announced. I am not even focused on the discussion between the adoption of DP-3T or one of the proposals of PEPP-PT: much was already written about it, and if you still don't know that DP-3T is a better design than any of the PEPP-PT endorsed solutions.

Instead, this article is about something I didn't see yet anything making the case for: DP-3T, the best protocol/architecture for a solution out there, claims to be Privacy-Preserving. But is it?

Not yet

My first take on this issue is to consider DP-3T as it is right now. It is, we understand, an ever-evolving specification, that, due to the time constraints inherent to the demand for applications of this sort, need to adopt a 'release early, release often' approach. Still, in the moment I am writting this, there are 14 open issues to the spec tagged as 'privacy risks'. Privacy, like security, or life, in certain cases is quite binary: there only needs to be one privacy issue with a certain protocol, format or tool, to make it not be privacy-preserving, so the answer to the question of DP-3T is privacy perserving is... "not yet."

Not really

But is that it? If you take a closer look, things get even grimmer. From the "privacy risk" issues previously opened and now closed on the project, we can see that several of them (nine, at this moment) were closed because they stopped having input. While a manual reading of each of them will show a status of them, and most of them were dealt (partially or entirely) one way or another, the struggle of the maintainers of the project to keep the number of issues low is clear, the reference to future versions of the documents leave things unclear of wether the issues have been addressed or not, and the way some things are not solved, but only mitigated shows that there is a "best effort" sort of approach to privacy, the idea that "let's see how privacy-preserving can we be in a rushing development cycle", instead of what it should be: a firm stance that no privacy-risk can exist in a privacy-preserving solution.

I do understand that the critic here so far is vague enough that one could argue that we're still on the 'not yet' field: after all, after all the privacy-related issues are closed, after all the documents still being prepared are published, one can go through all of those issues, check the latest version of the document, and verify if all of the privacy issues were indeed solved. Arguably, they could. But we do not need to stay on the theoretical field here, not when the "best effort" approach, even in partial sacrifice of privacy, is actually documented. My favorite example of this, is the FAQ's 5th point, about the use of anonymous communication systems.

Why not use mixnets or other anonymous communication systems to query the server?

In the answer to this question, DP-3T stipulates, first, that this is a valid question and concern. Then, they explain that they decided not to for three reasons: a solution would increase complexity, anonymity would cost latency and bandwidth, and it would widen the field of research necessary to take protocol decisions.

In the end, the answer is a claim that there currently is no system ready to use DP-3T could piggy back on and simply use to this purpose, mature enough to the scale DP-3T aims to be deployed -- if there was, they'd use it.

While I do not disagree - such anonymous communication system is a need we, as a society, have for a long time, but an itch we did never focus on scratching, and the solutions so far are far from a stable and consolidated state - I also believe that this is clear proof that DP-3T is, by design, not 'Privacy-Preserving', but only 'as Privacy-Preserving as we can be, with these time constraints'.

Why does it matter?

The difference between "private" and "as private as possible" is not small, no matter how tiny it is: it is the difference between a solution that respects your privacy, and a solution that doesn't. While I can understand DP-3T and its interesting properties as an academic project, it is, IMO, a dangerous assumption to think that, because this is the best someone has came up to, that it is good enough for us, and that we should adopt it. In fact, my belief is that, since DP-3T is the best we aim to be able to achieve during this outbreak, it should not be used. On the other hand, this can and should be used as a learning experience, proof that there is a need to serious public investment on the development of real Privacy-Preserving technologies, of which anonymous communication systems are just an example.

What could have been

This article is long enough already, and I could go on and on about what can be done, if the serious effort is made to make it happen. The first paper I wrote about GNUnet was more than 15 years ago: since then many things have happened, extraordinary developments in many technological fields, a decade and half has passed... but GNUnet seems to me as being still the most promising privacy-centric project out there, and, quite unfortunately, it is still in an early alpha stage. The latest incarnation of its website has a tagline that is quite fitting for this article: "The Internet of tomorrow needs GNUnet today". In 2020, technology failed us in many ways: when a worldwide event like COVID-19 hit, we searched for technological solutions that still did not exist. 2020 was tomorrow, and we did not have GNUnet (or any other solution of choice -- take your pick, there is plenty around to do). My biggest fear on this subject is not to see solutions like DP-3T (or worse) being adopted, affecting the privacy of real lives, real people. My biggest fear that we will step out of the current sittuation, and decide not to learn from the evidences of past mistakes. Let's build the Internet of tomorrow, now.

tags: en, DP-3T, COVID-19, privacy, tracking, tracing, localization, PEPP-PT, gnunet

comentários? tweetar  

multi-aspell: a treat for alpine users

09 de abril de 2020 — ~marado

Probably more useful to users of tilde.pt, but maybe others of the tildeverse who speak more than one language and use alpine as a mail client, today wrote a very small shell script called multi-aspell.

multi-aspell is an helper script that shows you a list of (pre-defined) language options to run aspell with.

It was written with the purpose of replacing the aspell invocation from alpine, in order to let you choose which language you want your e-mail to have its spell checked (useful if you're used to write mails in more than one language).

Now, before sending an email, alpine will ask me wether I want to spell check it in Portuguese or English, and then use that language to check the e-mail with.

Of course, comments, issues, patches or feature requests are more than welcome. Enjoy!

tags: pine, alpine, tilde.pt, tilde, tildeverse, aspell, multi-aspell, en

comentários? tweetar  

From ~marado to @marado

04 de abril de 2020 — ~marado

Speaking yesterday with someone about tilde.pt, which he found out about due to my contributions to botany, it took me a while but I did realize that there is a generational issue recognizing a ~, or, in particular, recognizing it as a way to refer to someone.

Once upon a time, before @username was the common way to refer to a person (who came with that first? twitter?), ~username was so. UNIX users will still be probably used to do things like cd ~ to go to their $HOME, or even ~user to refer to some other person's home. But I do not think that's where the most common ~ recognition comes from: instead, what people will most remember is the number of websites of "white pages" (as some other person refered about them to me as), that had, as an address, http://institution/~username.

So, where does this ~ come from? Well, there was a time where every machine connected to the web was more or less expected to have Apache's httpd running, and it had a useful module, called mod_userdir. UserDir actually was inherited: Apache's httpd started in 1995 as a continuation of the NCSA HTTPd webserver, and NCSA not only had the UserDir directive, it was actually active by default. What does all this means? Well, it means that, by default, UNIX machines with a webserver running would probably have NCSA or later Apache's httpd, which, by default, would be allowing each of that server's users to have their own website, at the address http://server.address/~username , and to have something in there they'd just have to put some html pages into their public_html directory.

tags: history, tilde, UNIX, username, apache, httpd, userdir, en

comentários? tweetar