If you grant sudo for a user to execute vi as root, it simply means you give that user a root shell. This is because user can use vi to invoke a shell by using ":!" vi command. Moreover, user can also use vi to open any abritary file as vi does not restrict the files to be read/written to its file list parameters upon invokation.
The best ways to grant sudo to user to edit a file are:
#1 find a text editor that cannot invoke a shell and can open files that are provided as command line arguments upon invokation only
Or #2 chgrp that file to be group editable and add that user into that group
First off, thank you very much everyone in this post, I got my same problem resolved. I resolved this problem by going to the 'view log' in 'application manager' and uninstalling one-by-one the applications I had installed in descending order (by date). For each uninstallation, I switched off and on the phone to see the effect.
The application that made this annoying popup upon turning on the phone is the Thai Language Pack for Nokia Dictionary that I had installed it into memory card.
I uninstalled it and reinstalled it but now into the phone memory and everything is good now.
Today is Mother's day in Bangkok. It's a holiday here, though, my mom has to work, still. I will have a dinner with her in the evening.
I just spent time today with nothing other than lying on bed and enjoying my new phone, the E71. This is my second E71 though. I lost my first one at a food stall. There are a lot of thieves in my country. I don't know whom to blaim. We just have to take care of our own safety all the time.
Now, it's time for writing down my next short note.
Oracle is a very expensive software. Its performance is very high, hence. However, when it works with other software component, we cannot expect to see the same result.
In my case, I use Perl with Oracle. Although the stored procedure in Oracle executes code very fast, when a large result is sent to Perl, who makes call to that stored procedure, it is crapping slow. The problem is that if a large result is transferred from Oracle to Perl by Oracle refcursor, it will be slow based on what kind of sql select query we use to fill that refcursor. Supposedly, I think the sql select query that at least one column is a result from a call to a function which inside that function has a call to something that also uses refcursor. This problem does not occur with Java though, for example. It looks like there are some bugs in DBD::Oracle perl module and the API Oracle provides to Perl. This issue has long been there for ages and noone is going to fix it yet.
To resolve this problem, there is a workaround that I also have applied to my project. By using a single sql select statement sending directly from Perl to Oracle to get a table through DBD::Oracle binding with data types other than refcursor. Then port the code in PL/SQL (stored procedure) into Perl. This way, the data transferring from Oracle to Perl will be extremely fast by comparing with returning data from stored procedure through refcursor. And that Perl is also super fast from its origin, the performance issue is resolved!
We cannot use the latest version of Mail For Exchange (current version is 2.9.158 S60 3.1 HS). The problem is that MfE will just keep being unable to connect to the Exchange server. This definitely is a bug.
As far as I know, the only working version for Nokia E71 is Mail For Exchange 2.7.0 S60 3.1 which you cannot get it from Nokia's official site anymore.
I did a lot of Googling until I found this working version which you can get it from here