Automatically mounting an NTFS partition on Linux

This is the fstab line I'm currently using to mount my NTFS partitions on Linux.

1. Copy the blkid of the partition you want to mount:
sudo blkid

2. Add to /etc/fstab:
UUID= /media/ ntfs-3g defaults,windows_names,uid=1000,gid=1000,umask=022,locale=en_US.utf8 0 0

3. Done!

Using a US layout keyboard to type in PT-BR (Portuguese Brazil) in Xubuntu

Since Xubuntu 14, when using the US layout with dead keys, pressing acute accent (') and then c results in ć instead of the expected ç when writing in PT-BR. There are two solutions for this:
1. Use alt-gr + , (which is inconvenient)
2. Do the workaround below

I can't remember who originally wrote this, I believe it was someone in the Ubuntu bug tracker.

"1) Editing the files:

for 64 bits:
sudo gedit /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules.cache
sudo gedit /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules.cache

for 32 bits:
sudo gedit /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/immodules.cache

changing the line

"cedilla" "Cedilla" "gtk20" "/usr/share/locale" "az:ca:co:fr:gv:oc:pt:sq:tr:wa"

to

"cedilla" "Cedilla" "gtk20" "/usr/share/locale" "az:ca:co:fr:gv:oc:pt:sq:tr:wa:en"

2) replacing "ć" to "ç" and "Ć" to "Ç" on /usr/share/X11/locale/en_US.UTF-8/Compose

sudo cp /usr/share/X11/locale/en_US.UTF-8/Compose /usr/share/X11/locale/en_US.UTF-8/Compose.bak
sed 's/ć/ç/g' < /usr/share/X11/locale/en_US.UTF-8/Compose | sed 's/Ć/Ç/g' > Compose
sudo mv Compose /usr/share/X11/locale/en_US.UTF-8/Compose

3) add two lines on /etc/environment

GTK_IM_MODULE=cedilla
QT_IM_MODULE=cedilla

4)restart your computer"

Emscripten: Linking to boost libraries with CMake

On Linux, C++ Boost headers usually reside in /usr/include. However, when letting CMake automatically find those headers for you it ends up including "-i/usr/include" which contains all the system headers.

This results in all sorts of weird compilation errors since the emscripten headers must be used instead of the system headers. The errors are something like "sys/cdefs.h: not found" and "__gnuc_va_list is not valid".

The file "includes_CXX.rsp" in the cmake build directory contains all the includes being passed to the compiler and you can look at it to identify such mistakes.

My present workaround was:
1. Create a boost_includes folder in my home
2. Create a symlink to /usr/include/boost inside the boost_includes folder.
3. Add the environment variable: BOOST_INCLUDEDIR="/home/x/include/boost_includes"

This workaround is useful for any other library you need to link that resides in the system headers folders.

There is no such thing as C/C++

C/C++. Although this term is frequently used, it's incorrect and is often a source of confusion for newcomers.

Here are some major differences between the two languages:

C	C++ (>=11)
#define	const X
malloc, calloc, free	new/delete
Raw pointers	RAII and smart pointers
Procedural	Procedural, modular, object-oriented and generic
Return large resources by pointers	Return large resources by value (rely on RVO and move semantics)
Raw array	std::vector, array
char* strings	std::string
stdio.h	iostream
void*	templates
setjmp/longjmp/goto	Exceptions
. . .	. . .

One can write C in almost every language. You can write C in Java by only using static methods (equivalent of functions) and beans (dumb objects with no behavior, equivalent of struct).  However, that's far from ideal.

If a software engineer wants to be good at a certain programming language, he should first strive to learn the idiomatic way of doing things in that language. Individual features should be a secondary concern.

Considering how different the idiomatic way of doing things in each language is, the term C/C++ is not appropriate and learning C before C++ is not recommended.