I'll start by saying that the answer you linked already summarizes all the optimizations you may need.
Next, to answer your questions:
1. Which file system (ext2/3/4 or something else)? (consider SSD life)
ext4 is a good filesystem even for SSD, so that would be my suggestion.
(If you want performance so bad you should try XFS )
2. Can it be changed after installation?
Yes, but it is not trivial, so choose well from the start :)
3. Should I partition the disk? (as we do in traditional HDD) for now, no plan of dual booting. Only Ubuntu will live on scarce space of 80GB SSD.
This is really not a matter of SSD, but your personal choice. If you were to ask me I'll say no; don't partition the disk you will end in loosing useful space.
(If you end with a partition with 2GB free and another with 1GB free, you theoretically have 3Gb free but cannot copy a 3GB file... that space is wasted )
4. I have 2 GB RAM, should I still allocate swap space (if I dont allocate swap space, can i still hibernate the machine)? will swap space impact SSD life?
I wouldn't worry so much about the SSD life ( modern one can run for decades ), however 2GB of RAM are enough not to need the swap partition.
Finally the swap partition is needed in order to hibernation, so if you want to hibernate the machine then you need the swap partition.
5. Should I consider putting additional 1GB RAM to avoid swap space?
1GB more or ram is always useful :) do it if you can.
6. What is partition aligning? is it needed to be done before installing the Ubuntu OS or can be done later?
That is the procedure where you align clusters, blocks and chunks. IMHO it is only needed on servers with a lot of data throughput. A good tool to do partition alignment is GParted. Of course this should be done before installing Ubuntu.
Hope this helps :)
Currently there's no way to securely erase files on SSD without erasing the content of the whole drive or access to the firmware of the SSD.
It's impossible to know where the SSD may store previous copies of a logical block.
To make matters worse, due to journalling and copy-on-write mechanisms of the file system it may be impossible to know which logical blocks may hold a previous copy of a particular file.
The only way to prevent the leakage of deleted files to someone with direct access to the drive is to encrypt them in the first place and keep the encryption key safe from prying eyes.
Addendum:
I did some research and found out that you can sort-of erase all previously deleted files if you manage to learn all the unoccupied sectors of a file system, which is generally possible and offered by some file system tools (e. g. for the ext* family), and then discard them (e. g. with blkdiscard(8)
as outlined in this answer to the linked question), which returns the blocks for garbage collection until they're used again and overwritten in the process.
This is secure against everyone who cannot access the flash cells directly, so everyone who
- doesn't have a suitable flash cell reading device and
- cannot talk the drive firmware into revealing the content of unassigned blocks (which would require a meaningful modification of the firmware in most cases and custom ATA commands since there's no standardised way).
Best Answer
the disk is very likely to distribute wear evenly, as they are usually engineered to do so, but it is not an ubuntu issue, it is mainly about the hardware. Don't really worry about it, but don't blame ubuntu if it fails.