Globalize 1.3.0 announcement

On July 3rd, we released Globalize 1.3.0. It is a special release, because it includes some very useful feature enhancements to support advanced date, time, timezone manipulation, and other long due fixes. We wanted to share more details on these improvements.

IANA/Olson Time Zone Support

This change was contributed by Kandaswamy Manikandan @rajavelmani (PayPal) and Rafael Xavier @rxaviers in #687 and #701.

In previous versions, Globalize had some partial time zone support for a user’s runtime time zone. However specific CLDR patterns (z, v, and V) that display strings such as PDT, Pacific Daylight Time, Pacific Time, and Los Angeles Time could not be displayed. The challenge we had to determine how costly a solution would be to provide full IANA/Olson time zone support due to the additional manipulation code and data (i.e., IANA database). Therefore, in the past, we encouraged users that needed to manipulate date in arbitrary time zones to use a separate library, like moment-timezone. Nevertheless, this solution never closed the gap between internationalization (i18n) implementations leveraging CLDR and having full maneuverability of time zones.

With the latest release 1.3.0, Globalize fully supports time zone. Simply put, by using Globalize 1.3.0, you now have full IANA support with the strength of CLDR for i18n!

Globalize.locale("en");
let date = new Date();

Globalize.formatDate(date, {datetime: "short", timeZone: "America/Los_Angeles"});
// > '3/19/17, 3:19 PM'
Globalize.formatDate(date, {datetime: "short", timeZone: "America/New_York"});
// > '3/19/17, 6:19 PM'
Globalize.formatDate(date, {datetime: "short", timeZone: "America/Sao_Paulo"});
// > '3/19/17, 7:19 PM'
Globalize.formatDate(date, {datetime: "short", timeZone: "Europe/Berlin"});
// > '3/19/17, 11:19 PM'

Globalize.formatDate(date, {datetime: "full", timeZone: "America/Los_Angeles"});
// > 'Sunday, March 19, 2017 at 3:19:22 PM Pacific Daylight Time'
Globalize.formatDate(date, {datetime: "full", timeZone: "America/New_York"});
// > 'Sunday, March 19, 2017 at 6:19:22 PM Eastern Daylight Time'
Globalize.formatDate(date, {datetime: "full", timeZone: "America/Sao_Paulo"});
// > 'Sunday, March 19, 2017 at 7:19:22 PM Brasilia Standard Time'
Globalize.formatDate(date, {datetime: "full", timeZone: "Europe/Berlin"});
// > 'Sunday, March 19, 2017 at 11:19:22 PM Central European Standard Time'

Globalize("pt").formatDate(date, {datetime: "full", timeZone: "America/Sao_Paulo"});
// > 'domingo, 19 de março de 2017 19:19:22 Horário Padrão de Brasília'
Globalize("de").formatDate(date, {datetime: "full", timeZone: "Europe/Berlin"});
// > 'Sonntag, 19. März 2017 um 23:19:22 Mitteleuropäische Normalzeit'
Globalize("zh").formatDate(date, {datetime: "full", timeZone: "Asia/Shanghai"});
// > '2017年3月20日星期一 中国标准时间 上午6:19:22'
Globalize("ar").formatDate(date, {datetime: "full", timeZone: "Africa/Cairo"});
// > 'الاثنين، ٢٠ مارس، ٢٠١٧ ١٢:١٩:٢٢ ص توقيت شرق أوروبا الرسمي'

We have solved this in a low footprint, high performance implementation using zoned-date-time under the hoods, which is a 0.6KB library for the time zone manipulations. We have leveraged the Globalize Compiler for precompling the IANA data base for production. For example, let’s say you are serving content in English (e.g. locale en-US) for America/Los_Angeles time using the following formatter:

var dateWithTimeZoneFormatter = Globalize.dateFormatter({
  datetime: "full",
  timeZone: "America/Los_Angeles"
});

The final size (for production) of this code will be:

filename minified+gzipped size
i18n/en.js (includes CLDR and IANA data) 1.7KB
core, number, and date globalize runtime lib + zoned-date-time 7.0KB

See globalize compiler example or app-npm-webpack example for details.

Format Date To Parts

This change was contributed by Reza Payami @rpayami (PayPal) and Rafael Xavier @rxaviers in #697 and #700.

Modern user interfaces often need to manipulate the date format output, which is impossible via the existing format function that returns an opaque string. Making any attempt to do this can break internationalization support. Ecma-402 has recently added Intl.DateTimeFormat.prototype.formatToParts to fulfill that purpose, which at the time of this post, is at stage 4 and is implemented by latest Firefox and Chrome.

In Globalize, we introduced .dateToPartsFormatter and .formatDateToParts.

Globalize.locale( "en" );
Globalize.formatDateToParts(new Date(2010, 10, 30));
// > [
// { "type": "month", "value": "11" },
// { "type": "literal", "value": "/" },
// { "type": "day", "value": "30" },
// { "type": "literal", "value": "/" },
// { "type": "year", "value": "2010" }
// ]

The data is available separately and it can be formatted and concatenated again in a customized way. For example by using Array.prototype.map(), arrow functions, a switch statement, template literals, and Array.prototype.reduce().

let formatter;

Globalize.locale( "en" );
formatter = Globalize.dateToPartsFormatter({datetime: "short"});

formatter( new Date( 2010, 10, 30, 17, 55 ) ).map(({type, value}) => {
  switch ( type ) {
    case "year": return `<strong>${value}</strong>`;
    default: return value;
  }
}).join( "" );
// > "11/30/<strong>10</strong>, 5:55 PM"

See React Date Input as a demo of a UI component for React optimized for i18n and a11y.

Localized and smart date input Feb 28 in en, es, pt, de, zh, ko, and ar
en en-es-pt-de-zh-ko-ar

Dynamically Augmented Date Skeletons

This change was contributed by Marat Dyatko @vectart and Artur Eshenbrener @Strate in #462 and #604.

The style used to display a date format often varies depending on the application. CLDR offers data for certain presets like short (e.g., short date "7/1/17"), medium (e.g., medium date "Jul 1, 2017"), long (e.g., long date "July 1, 2017"), and full (e.g., full date "Saturday, July 1, 2017"). Although, we could need something different such as "Jul 1". For that CLDR offers data for individual date fields and their combinations, which are used by Globalize to synthesize an open-ended list of custom formats (called skeletons). But, what’s interesting is that it would be prohibitively large if CLDR provided data for every single possible combination. So, there’s an algorithm specified by UTS#35 to deduce missing data from the requested format.

For the "Jul 1" example, we should use {skeleton: "MMMd"}. Internally, Globalize finds a direct match in CLDR for the requested skeleton. This works fine in previous Globalize versions.

For that next example, let’s assume we want "July 1", i.e., {skeleton: "MMMMd"}. Internally, Globalize doesn’t find a direct match in CLDR. For this skeleton, Globalize needs to use the data for MMMd, which maps to "MMM d" in the English case, and then it needs to replace MMM with MMMM dynamically generating "MMMM d". This doesn’t work in previous versions of Globalize, but it works now on latest v1.3.0.

If we wanted "07/01" instead, we should use {skeleton: "MMdd"}. Internally, Globalize doesn’t find a direct match in CLDR for this skeleton and, therefore, it fais in globalize v1.2.3. Globalize needs to use the data for Md, which in the case of English maps to "M/d", and then replace M wtih MM and d with dd dynamically generating "MM/dd".

To make a long story short, the algorithm in globalize v1.3.0 has been significantly improved and it allows using virtually any skeletons.

// A skeleton not directly found in CLDR and that needs to be deduced by globalize.
// In English, globalize needs to use the data for GyMMMEd, and adjust MMM with MMMM,
// and E with EEEE. Then, it needs to find the data for hms and glue them together
// using the appropriate format.
// On globalize v1.2.3, an error is thrown saying this skeleton wasn't found.
let skeleton = "GyMMMMEEEEdhms";
Globalize("en").formatDate(new Date(), {skeleton});
// > 'Saturday, July 1, 2017 AD at 4:58:27 PM'
Globalize("pt").formatDate(new Date(), {skeleton});
// > 'sábado, 1 de julho de 2017 d.C. 5:01:20 PM'
Globalize("de").formatDate(new Date(), {skeleton});
// > 'Samstag, 1. Juli 2017 n. Chr. um 5:01:33 nachm.'
Globalize("zh").formatDate(new Date(), {skeleton});
// > '公元2017年七月月1日星期六 下午5:01:35'
Globalize("ko").formatDate(new Date(), {skeleton});
// > 'AD 2017년 7월 1일 토요일 오후 5:01:38'
Globalize("ar").formatDate(new Date(), {skeleton});
// > 'السبت، ١ يوليو، ٢٠١٧ م ٥:٠١:٤٠ م'
Globalize("ar-MA").formatDate(new Date(), {skeleton});
// > 'السبت، 1 يوليوز، 2017 م 5:04:29 م'
Globalize("it").formatDate(new Date(), {skeleton});
// > 'sabato 1 luglio 2017 d.C. 5:01:52 PM'

Read our getting started and play with it yourself.

Other Enhancements and Bug Fixes

Enhancements

  • Date: Show timezone offset optional minutes for O pattern (e.g., GMT-6:30 note the :30) #339 (via PR #729) (Rafael Xavier)
  • Date: Show timezone offset optional minutes and seconds for x and X patterns (e.g., -06:30 note the :30) #339 (via PR #729) (Rafael Xavier)
  • Date: Assert options.skeleton (PR #726) (Rafael Xavier)
  • Date parser: Make runtime phase lighter #735 (Rafael Xavier)
  • Date parser: Loose Matching PR #730(Rafael Xavier)
    • Allows, among others, parsing arabic dates as user types them (i.e., without control characters)
  • Number formatter: Amend integer and fraction formatter for small numbers like 1e-7 #750 (Rafael Xavier)
  • Number parser: Lenient about trailing decimal separator #744 (Rafael Xavier)
  • Runtime: Use strict #676 (Zack Birkenbuel)

Fixes

  • Date parser: invalid output by mixing numbering systems #696 (via PR #733) (Rafael Xavier)
  • Date parser: fails on Turkish full datetime with Monday or Saturday #690 (via PR #732) (Rafael Xavier)

Others

  • Compiler tests! #721 (via PR #727) (Nikola Kovacs)
  • Documentation style refactor #737 (Rafael Xavier)

Last but not least

Special thanks to other PayPal internationalization team members including Daniel Bruhn, Lucas Welti, Alolita Sharma, Mike McKenna for testing and helping integrate Globalize for PayPal products.

Special thanks to James Bellenger and Nicolas Gallagher for the React and Webpack integration enhancements for Twitter products, which certainly deserves its own blog post.

Many thanks to all of you who participated in this release by testing, reporting bugs, or submitting patches, including Jörn Zaefferer, Frédéric Miserey, Nova Patch, and whole Globalize team.

Source: https://github.com/globalizejs/globalize/blob/master/doc/blog-post/2017-07-xx-1.3.0-announcement.md

TC39: Ecma-402 updates

This Tuesday (March 21), we had a TC39 meeting (the committee responsible for evolving the ECMAScript language, the browsers’ programming language) where several JavaScript topics were discussed, including Ecma-402 (the Internationalization API Specification).

If you are an i18n engineer, this post might interest you…

Basically we had 4 proposals.

  • 3 about new API (Intl.ListFormat, Intl.UnitFormat, Intl.RelativeTimeFormat, Intl.Segmenter), and
  • 1 about an update to Intl.DateTimeFormat: date and time styles, basically what we call presets short|medium|long|full.

Overall, the Ecma-402 updates took a bigger slot than original planned. It seems it has gained enough traction to actually make TC39 intrigued and asking lots of questions. Allen Wirfs-Brock (former Ecma-262 editor) mentioned TC39 needs to invest more time into understanding about i18n and what Ecma-402 is doing.

By the way, below the terms stage 1, 2, 3, and 4 are mentioned. Find details about that at https://tc39.github.io/process-document/.

Intl.ListFormat

Presented by Zibi (Mozilla), this is a new API to allow the creation of localized lists. It’s currently at stage 1 (proposal) and seeks stage 2 (draft). It looks something like this:

new Intl.ListFormat("en").format(["John", "Mary", "Mike"]);
// > "John, Mary, and Mike"

TC39 agreed to advanced it to stage 2 (draft) despite some initial confusion about the use cases.

Intl.UnitFormat

New API to allow simple unit formatting. It’s currently at stage 1 (proposal) and seeks stage 2 (draft). It looks something like this:

new Intl.UnitFormat("en", {category: "duration"}).format(2, "hour");
// > "2 hours"

Remaining at stage 1 (proposal). The agreement was that it needs more experimentation and exploration. It was specially confusing for the TC39 the relationship between this formatter and others like relativeTimeFormat and Duration (this one by the way isn’t even elaborated).

Intl.RelativeTimeFormat

New API to allow simple relative time formatting. It’s currently at stage 1 (proposal) and seeks stage 2 (draft). It looks something like this:

new Intl.RelativeTimeFormat("en").format(-10, "second");
// > "10 seconds ago"

Remaining at stage 1 (proposal) pending more understanding. Similar to the UnitFormat.

Intl.DateTimeFormat dateStyle/timeStyle

Update to existing DateTimeFormat. It’s about the addition of preset styles that looks like the below.

let dtf = new Intl.DateTimeFormat("en", {
    dateStyle: “short”
}); // "3/21/17"

let dtf = new Intl.DateTimeFormat("en", {
    timeStyle: “short”
}); // "1:31 PM"

let dtf = new Intl.DateTimeFormat("en", {
    dateStyle: “short”,
    timeStyle: “long”
}); // "3/21/17, 1:31:47 PM PDT"

Advanced to stage 1 (proposal), which doesn’t necessarily mean the API was in agreement. It was discussed whether to use the current proposal or to follow using a different approach by breaking it down into two explicit steps like the below.

let options = Intl.DateTimeFormat.getOptionsForStyle("date", "short");
let dtf = new Intl.DateTimeFormat("en", options);

Intl.Segmenter

Presented by (Daniel Ehrenberg), It’s currently at stage 2 (draft) and seeking reviewers for stage 3 (candidate). It’s a new API that helps finding localized grapheme, word and sentence breaks (UTS 29) and line breaks (UAX 14). It looks something like this:

let segmenter = new Intl.Segmenter("fr", {type: "word"});
let segmentIterator = segmenter.segment("Ceci n'est pas une pipe");

It remains at stage 2. Stage 3 reviewers identified.

jQueryUI 1,000,000 custom downloads every quarter

I’ve been helping jQueryUI to port its DownloadBuilder into node.js. The rewrite is actually live and serving downloads since Oct/2012.

Today, I wrote my very first post in the jQueryUI Blog with insights into what we’ve built, and the trends we’ve noticed so far.

Good reading… (original at http://blog.jqueryui.com/2013/04/1000000-custom-downloads-in-four-months/)

We surpassed the millionth download of jQuery UI using our recent DownloadBuilder and ThemeRoller rewrite back on February. As of today, we have served 1,730,000 downloads and counting. Read on for some insights into what we’ve built, and the trends we’ve noticed so far.

The former server-side code was written in PHP. It’s been rewritten in JavaScript and runs on node.js, and it is much more integrated with jQuery UI release process overall. The client-side has been rewritten as well, although we didn’t make any big changes to the UI/UX.

On the client side, despite the few visual changes, we have some interesting updates. The DownloadBuilder now remembers what user selects and makes it linkable, so it’s easy to share or go back and modify a custom theme. We’re also shortening links automatically if they get too big, by zipping parts of the query string.

The backend in-memory-caches the source files and theme images to speed up the downloads. Since it serves custom downloads, the parts are not simply assembled, but rather modified on build-time and then assembled. The average build & package time is 1.3s.

The download traffic is pretty uniform and constant; we hit an average of 66,000 downloads per week, having more traffic during the weekdays and less traffic during the weekends. When we publish a new release, we see a 10% increase on traffic. Adoption of the new release is really fast, legacy downloads drop virtually immediately. Although, we still have a significant amount of 1.9.x downloads after the 1.10.x release, splitting the total as chart shows below.

Downloads per version

29% of users download the default components with the default theme. Other than that, we have all sorts of custom combinations happening. They choose different components, different themes, or a mix of both.

Among the component customizations (which represent 26% of all total downloads), 15% are only Datepicker (the winner by far), followed by No Components (8.5%), which packages the theme only, Autocomplete (4.5%), Dialog (4.25%), and Tabs (3.75%).

Custom component selection
Datepicker

- Datepicker and its dependencies

- Datepicker, mouse and position

14.95% (4.34% of all downloads)

- 12.72% (3.69% of all downloads)

- 2.23% (0.65% of all downloads)

No components (theme only) 8.55% (2.48% of all downloads)
Autocomplete and its dependencies 4.53% (1.31% of all downloads)
Dialog only 4.25% (1.23% of all downloads)
Tabs only 3.77% (1.09% of all downloads)
Accordion only 2.91% (0.84% of all downloads)
Slider only 2.58% (0.75% of all downloads)
All, but effects 1.87% (0.54% of all downloads)
Core components (no widgets or interactions) 1.60% (0.46% of all downloads)
Sort interaction only 1.37% (0.40% of all downloads)
Interaction and core (no widgets) 1.33% (0.38% of all downloads)
Draggable interaction only 1.22% (0.35% of all downloads)
Effects only 1.05% (0.30% of all downloads)
Tooltip only 1.04% (0.30% of all downloads)
The core component (solely) 1.02% (0.30% of all downloads)
total 100.00% (26.37% of all downloads)

 

Theme customizations (choosing something other than the default UI Lightness theme) represent 57.5% of all downloads. If we skip the base theme Smoothness too, theme customizations are actually 42.35% of all total downloads. 16% of all downloads are user created themes (Custom Themes), followed by the Redmond (4.86%), UI darkness (2.73%), and Start (2.38%) themes.

Within the users that create a Custom Theme, the majority of users (77%) download the full “all components” bundle, 5.5% download it with no components (theme only), and 17.5% do it with a custom component selection.

Themes
(top 11)
Default Component
Selection
Custom Component
Selection
UI lightness (default theme) 38.76% (28.53% of all DLs) 53.20% (14.03% of all DLs)
Custom Theme 17.10% (12.59% of all DLs) 14.11% (3.72% of all DLs)
Smoothness (base theme) 16.34% (12.03% of all DLs) 11.64% (3.07% of all DLs)
Redmond 5.13% (3.77% of all DLs) 4.13% (1.09% of all DLs)
UI darkness 2.80% (2.06% of all DLs) 2.54% (0.67% of all DLs)
Start 2.60% (1.91% of all DLs) 1.78% (0.47% of all DLs)
Cupertino 2.42% (1.78% of all DLs) 1.97% (0.52% of all DLs)
Blitzer 1.58% (1.16% of all DLs) 1.29% (0.34% of all DLs)
Flick 1.44% (1.06% of all DLs) 1.52% (0.40% of all DLs)
Sunny 1.41% (1.04% of all DLs) 0.91% (0.24% of all DLs)
Dark Hive 1.17% (0.86% of all DLs) 0.72% (0.19% of all DLs)
total 100% (73.63% of all DLs) 100% (26.37% of all DLs)

 

Thanks to clark and Splunk for helping us make sense of all this data!

As usual, if you find any bugs or if you have any ideas on how to make the DownloadBuilder or ThemeRoller even more amazing, we’d love to hear from you! But please, don’t use the comments, rather please file an issue here.

Quick script to fetch diff history [of a file] using svn

If you wanna see the whole history differences of some file in svn repository, you could use this:
$ svndiffhist file
Retrieving releases...
OK (found 17 steps)
## 908:895
diffs...
## 895:890
diffs...
## 890:880
... etc

Where svndiffhist is the following script:

function svndiffhist {
    FILE=$1

    echo -n "Retrieving releases..." >&2
    releases=$( svn log $FILE | grep '^r[^a-z]' | cut -d " " -f1 |
                cut -dr -f2- )
    num_steps=$( echo $releases | wc -w )
    echo -e "tOK (found "$num_steps" steps)" >&2

    # Sort them in ascrending order
    #releases=$( echo $releases | tr " " "n" | sort -n )
    # Group them as A:B B:C C:D
    releases=$( echo $releases | sed 's/ ([0-9]+)/:1 1/g' )

    for EACH_STEP in $releases; do
        #svn diff -r $EACH_STEP $FILE | gvim -
        echo "## $EACH_STEP" >&2
        svn diff -r $EACH_STEP $FILE
    done
}

A REST client interface for Python

The py-restlib: [http://code.google.com/p/py-restlib] is a GNU GPL library that implements a REST client interface for Python.

Here it goes its Getting Started section:

Introduction

Py-restlib is supposed to be a simple REST client interface for python. But, it also claims that writing a python client to communicate with RESTful applications on the Web should be an easy task.

Getting Started

Download

Check out the latest release using svn:
svn checkout http://py-restlib.googlecode.com/svn/trunk/ py-restlib
svn checkout http://py-restlib.googlecode.com/svn/trunk/ py-restlib

If you want support for translating JSON format into python structures, download json-py package, and unzip it to json-py subdir.

Examples

The REST client


from restlib import *

users = Resource("http://hostname/api/users")

# List all users (GET /api/users)
users.get()

# List user where id==1 (GET /api/users/1)
users.get(1)

# List user where id==1 && foo=='bar' (GET /api/users/1?foo=bar)
users.get(1, foo='bar', ...)

# Create a new user (POST /api/users)
users.create(foo='bar', ...)

etc...

# You are also able to use it that way:
api = BaseResource("http://hostname/api")
api.users.get()
api.users.create(foo='bar')
etc...

The REST server (in this case a Ruby on Rails application)


class Api::UsersController < ApplicationController
    protect_from_forgery :except => :create
    # GET /api/users
    def index
        @users = User.find(:all) # FIXME: if param[id] - under construction

        request.format=:json if request.format=:html
        respond_to do |format|
            format.xml {render :x ml => @users.to_xml}
            format.json {render :json => @users.to_json}
        end
    end

    # POST /api/users
    def create    # FIXME: under construction
        request.format=:json if request.format=:html
        respond_to do |format|
            format.xml {render :x ml => params.to_xml}
            format.json {render :json => params.to_json}
        end
    end
end

Python POST request

If you’re trying to send a python POST request with httplib, but it’s not working like example tells. Try this minor fix:

Here is an example session that shows how to “POST” requests:

>>> import httplib, urllib
>>> params = urllib.urlencode({‘spam’: 1, ‘eggs’: 2, ‘bacon’: 0})
>>> headers = {“Content-Type”: “application/x-www-form-urlencoded”,
… “Accept”: “text/plain”}
>>> conn = httplib.HTTPConnection(“musi-cal.mojam.com:80″)
>>> conn.request(“POST”, “/cgi-bin/query”, params, headers)
>>> response = conn.getresponse()
>>> print response.status, response.reason
200 OK
>>> data = response.read()
>>> conn.close()

Thanks to wireshark and the working command below, so example above could be compared.

curl -d foo=bar http://localhost

Criptografia em Linux, utilizando EncFS

Introdução (o que?)

Este tópico descreve o procedimento para criptografia de dados no GNU/Linux, utilizando o sistema de arquivos EncFS.

Público Alvo (pra quem?)

Este tópico deve ser útil para usuários de laptop.

Vantagens e Desvantagens de utilizar o EncFS

Modos de criptografia

TODO

Como utilizar

Instalação

Instalar os pacotes: (utilizar o gerenciador de pacotes de sua distribuição)

  • FUSE (Filesystem in Userspace)
  • EncFS

Criação do diretório criptografado

Na 1a tentativa de montar seu volume criptografado, ele é criado.

Existem várias opções de criptografia. Caso opte-se pela praticidade, siga os valores default.
$ mkdir ~/.pessoal.enc # dados criptografados (raw data)
$ mkdir ~/pessoal # ponto de montagem (dados legíveis)
$ encfs ~/.pessoal.enc ~/pessoal # na 1a tentativa de montagem, o volume criptografado é criado
Volume key not found, creating new encrypted volume.
Password: [password entered here]
Verify: [password entered here]

O diretório ~/pessoal, agora, é um ponto de montagem de ~/.pessoal.enc e todo o conteúdo que estiver dentro dele (~/pessoal) estará seguro quando offline.

Montando/Desmontando

Montando.

$ encfs ~/.pessoal.enc ~/pessoal
Password: [password entered here]

Diretório legível: (montado)

$ cd ~/pessoal
$ echo "hello foo" > foo
$ echo "hello bar" > bar
$ ln -s foo foo2
$ ls -l
total 8
-rw-r--r-- 1 vgough users 10 2003-11-03 21:44 bar
-rw-r--r-- 1 vgough users 6 2003-11-03 21:44 foo
lrwxrwxrwx 1 vgough users 7 2003-11-03 21:44 foo2 -> foo

Diretório criptografado: (de fato, armazenado)

$ cd ~/.pessoal.enc
$ ls -l
total 8
-rw-r--r-- 1 vgough users 6 2003-11-03 21:44 eEM4YfA
-rw-r--r-- 1 vgough users 10 2003-11-03 21:44 gKP4xn8
lrwxrwxrwx 1 vgough users 7 2003-11-03 21:44 i7t9-m,I -> eEM4YfA

Desmontando.

$ fusermount -u ~/pessoal

Criptografando os dados de seus aplicativos: Firefox, Thunderbird, etc.

Deseja ter criptografados seus emails, informações de calendário, conversas do instant messenger e informações de seu browser? Mova o diretório de configuração de cada aplicativo para dentro do volume criptografado e crie um link de volta. Como no exemplo abaixo:

Antes de iniciar os aplicativos (óbvio), mova seu diretório de configuração para dentro do volume criptografado e link-o de volta. Por exemplo:
cd ~
mv .mozilla ~/pessoal
ln -s ~/pessoal/.mozilla .

Faça o mesmo para mozilla-thunderbird, gaim, evolution, entre outros.

Ambiente Gráfico

Em ambiente gráfico, pode ser mais prático criar starers de aplicativos que, antes de inicializar o aplicativo em si, cheque se a unidade criptografada está montada. Caso não esteja, o próprio starter poderá montá-la, utilizando gtk2-ssh-askpass, x11-ssh-askpass ou zenity. Exemplo:
encfs --extpass=/usr/bin/zenity-encfs $ENC $MNT

http://gentoo-wiki.com/TIP_EncFS

Backup!

Uma vez que todos os dados estão concentrados no diretório criptografado ~/.pessoal.enc, torna-se fácil a realização de backup. Basta copiá-lo para uma mídia removível e, sim, o backup também estará criptografado.

Exemplos de como realizar o backup:

  1. Compactar o diretório tar -czf ~/pessoal.enc.tgz ~/.pessoal.enc e copiá-lo para um DVD (sugestão: k3b).
  2. Utilizar alguma forma de backup diferencial/incremental (é copiado apenas o que alterou), sem sugestões…

Links externos

Segue: