They all focus on which one:

• Has best screen
• Has best virtual keyboard
• Has biggest number of applications
• Is more open
• etc…

These comparisons are nice, really, but they completely miss the target.

In my opinion, the real difference is the Google account (Mail, Calendar and Contacts) that is behind an Android device.

With ZERO configuration, you have for free, synchronization, over the air (no need for Outlook or even a computer), between your Google account and your phone for Contacts, Calendar and Email.

Compare that with the setup instructions for iPhone …  http://www.google.com/support/mobile/bin/answer.py?answer=138740&topic=14252

That is the real difference between the 2 devices. And it’s Android that wins for sure.

So if you want to buy a new phone, the choice between Android and iPhone is not on the device, but on the email account you have: GMail? Go for Android. It’s just amazing how well and easily it works!

Remember, there are at least those files that are potentially run:

• /etc/profile
• /etc/bash.bashrc
• /etc/bash_completion
• .profile
• .bash_profile
• .bashrc
• .bash_completion

Depending if you login interactively (getting a shell) or just running a command,some of these files are sourced.

Assumptions

We will take the case where:

• You login through SSH
• Or you change to a user using su
• You have an Ubuntu or Debian Linux machine

I suspect that Redhat/Fedora and others are not far away from these assumptions, but I have none to check…

There are in fact 6 scenarios

First Scenario : interactive shell with SSH

You login to a remote machine using SSH, getting a shell. This is the most current use of SSH.

With:

     ssh user@machine

You then get a shell.

The files that are sourced are:

• /etc/profile
• /etc/bash.bashrc
• .profile
• .bashrc
• /etc/bash_completion
• .bash_completion

That’s right only if there is no .bash_profile file in your HOME directory. Else the files sourced are:

• /etc/profile
• /etc/bash.bashrc
• .bash_profile

In fact, bash sources .bash_profile if it exists, else .bashrc

Note that

• /etc/bash.bashrc is sourced by /etc/profile if the shell is bash
• .bashrc is sourced by .profile
  
• /etc/bash_completion is in fact sourced by .bashrc (not bash itself directly)

So we could summarize this way.

When asking for an interactive shell, bash sources:

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Second scenario : running a command through SSH

You login to a remote machine using SSH, asking to run a command (no interactive shell)

     ssh user@machine "command to run" (Ex: ssh user@machine "ls /tmp")

The files that are sourced are:

• /etc/bash.bashrc
• .bashrc

Note that .bashrc is run in place of .bash_profile in this case.

Third scenario : getting an interactive shell using su -

You are logged with root and want to get a shell as another user:

     su - user

Note that the minus sign means that you want to source the config files for the target user.

The files that are sourced, are

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Fourth scenario : running a command using su -

You are logged with root and want to get a shell as another user:

     su - user -c "touch /tmp/file"

The files that are sourced, are

• /etc/profile
• .bash_profile
• Or .profile if .bash_profile is not found

Note that in this case, .bashrc is NOT run from /etc/profile since the shell is not interactve! (PS1 is not defined)

Fifth scenario : getting an interactive shell using su (without the minus sign)

You are logged with root and want to run a shell as another user:

     su user

Surprise! Even since you thought that the minus sign would source NO config files, the files that are sourced, are

• /etc/bash.bashrc
• .bashrc

Note that the sourced files are the same as running a command through SSH!

Sixth scenario : running a command using su (without the minus sign)

You are logged with root and want to run a shell as another user:

     su user -c "touch /tmp/file"

And this time, no surprise, the files that are sourced, are … NONE!

That’s exactly what the minus sign means. Become <user>, but don’t source its config files.

And the bonus scenario

What happens when you run a command from a crontab?

First, the default shell when running from a CRON, is /bin/sh. You can change this to bash putting:

     SHELL=/bin/bash

as the first line of your crontab file (crontab -e is your friend for this one).

Then sourced config files when the command is run are … NONE also.

Conclusion

Every time I need to run remote command on a machine or run a script as a user using su, I ask myself the same questions about those config files!

And we can see above that it’s not that clear which files are run when…

So now that’s done, for the posterity, on my blog so it should last for some time.

Comments of course welcome!

I work at « Etat de Vaud » in Switzerland and we have a lot of j2ee Servlet applications which run on Tomcat 6.0.x, that are multi-modules Maven projects.

My main concern is about development time, about the time the developer spend (or loose) compiling, packaging, deploying and running the application between 2 « tests »

Of course, we use unit tests extensively here, to develop Services, DAOs and other classes, but when it comes to pure web development (understand JSP) the « round-trip » time can become huge.

For example, on one of our project, when the developer change code in a controller (Spring MVC), it must

• Run maven to compile the code and package the war (~30-60 seconds)
• Copy the war to webapps of the Tomcat server (or have a symlink if on Linux)
• Then tomcat redeploy the application, including the Spring context (DAOs, Services, SessionFactory) which takes around 30 seconds

One code modification, round-trip time = ~1 minute…

Compare that to PHP, Ruby on Rails or even Grails which are quite instantaneous!

Multi-modules Maven projects

If you have single modules Maven projects, this is not a problem. Say we have:

myapp/webapp

which contains JSP and static contents:

myapp/webapp/css/...
myapp/webapp/images/...
myapp/webapp/WEB-INF/jsp/...

You have all your code in one location, say

myapp/src/main/java/...

then Eclipse can output compiled classes to

myapp/webapp/WEB-INF/classes/...

and have your libs in

myapp/webapp/WEB-INF/lib/...

Then you can start tomcat on

myapp/webapp/

And that’s all.

But when you have Multi-modules Maven projects, then you have Java source files in 2-3 places and Eclipse is unable to write all the compiled classes in one place (myapp/webapp/WEB-INF/classes)

Embedding Tomcat in Eclipse to the rescue!

The idea is to embedd Tomcat in Eclipse, so Tomcat is in the same JVM/ClassLoader of Eclipse and Tomcat « sees » all the projects, and also all the compiled classes and all the libs that are configured in Eclipse.

Step by step:

• Create a muli-modules Maven project that have, say, 2 modules : business and web (web depends on business)
• Import them in Eclipse using the Maven plugin for Eclipse (http://m2eclipse.codehaus.org/)
• You then have 3 projects in Eclipse: base, business and web
• At this point, the web project sees all the classes and libs from business and web
• Create a class to Embed Tomcat in Eclipse as I’ll show below
• Run your webapp using that class and you have instantaneous view of your modifications

Embedded Tomcat, with JNDI data sources

Tomcat 6.0.x is totally able to Embed itself in your code. The idea, is to create a java main() in the test part of the web project (in myapp/src/test/java). It’s important to create it in the test part, so it won’t be in your generated WAR, and the needed dependencies (catalina.jar, jsp-api, …) won’t be neither in your packaged WAR.

Step by step:

• Create a class that implements the Embedded part of Tomcat (See below)
• Debug it as Java Application (It’s important to « Run as Debug » so Eclipse is able to « feed » the webapp with the modified code without restarting the whole application)

Embedded class:

public class TomcatRunner {

 private static final Logger log = Logger.getLogger(TomcatRunner.class);

 private Embedded embedded;
 private String catalinaHome;
 private String pwd;

 public TomcatRunner(String contextPath, String webappDir, String contextXmlPath) throws Exception {

 // Current dir => ..../myapp/web
 final File file = new File(".");
 pwd = file.getCanonicalPath();

 // Create CATALINA_HOME
 File catalinaHomePath = new File(pwd+"/target/CATALINA_HOME");
 if (!catalinaHomePath.exists()) {
 Assert.isTrue(catalinaHomePath.mkdirs());
 }
 catalinaHome = catalinaHomePath.getCanonicalPath();

 // Create an embedded server
 embedded = new Embedded();
 embedded.setCatalinaHome(catalinaHome);

 // Create an engine
 final Engine engine = embedded.createEngine();
 engine.setDefaultHost("localhost");

 // Create a default virtual host
 final Host host = embedded.createHost("localhost", pwd /*Bas dir for webapps*/);
 engine.addChild(host);

 // The context of myapp
 // myapp/default-web.xmlis the default web.xml used for the context.
 // It contains the JSP and "static content" servlets. You can find that file in apache-tomcat-6.0.18/conf/web.xml
 final Context context = createContext(contextPath, pwd+"/"+webappDir, pwd+"/"+contextXmlPath, "myapp/default-web.xml");
 host.addChild(context);

 // Install the assembled container hierarchy
 embedded.addEngine(engine);

 // Assemble and install a default HTTP connector
 final Connector connector = embedded.createConnector(""/*Default to localhost*/, 8080/*Port to listen*/, false/*Secure*/);
 embedded.addConnector(connector);
 }

 public void start() throws Exception {
 // Start the embedded server
 embedded.start();
 }

 private static Context createContext(String path, String docBase, String contextFilePath, String defaultWebXmlPath) {
 log.debug("Creating context '" + path + "' with docBase '" + docBase + "'");

 StandardContext context = new StandardContext();

 context.setDocBase(docBase);
 context.setPath(path);

 ContextConfig config = new ContextConfig();
 config.setDefaultWebXml(defaultWebXmlPath);
 config.setCustomAuthenticators(null);
 context.addLifecycleListener(config);
 // This is the config of the JDNI datasources
 if (StringUtils.isNotBlank(contextFilePath)) {
 File configFile = new File(contextFilePath);
 context.setConfigFile(configFile.getAbsolutePath());
 }
 return context;
 }

}

Then you can use it with:

 // A global property configured for the server
 System.setProperty("myapp.appDir", "appDir/devel");

 TomcatRunner runner = new TomcatRunner("/my/app", "webapp", "webapp/META-INF/context.xml");
 runner.start();

And then start it as « Debug ». That’s it!

JNDI

If you have JNDI data sources, you can configure them in the file

webapp/META-INF/context.xml

Example of context.xml:

<Context debug="true" reloadable="true" crossContext="true" antiJARLocking="true">
   <Resource name="jdbc/myAppDataSource" auth="Container" type="javax.sql.DataSource"
     maxActive="100" maxIdle="30" maxWait="10000"
     validationQuery="select sysdate from dual"
     username="WEB_USER" password="pwd" driverClassName="oracle.jdbc.OracleDriver"
     url="jdbc:oracle:thin:@<server>:1521:orcl"/>
</Context>

Usage

The goal is to be able to modifiy static content, JSPs or java code and that it is used instantaneously without needing a restart or a manual operation.

To be able to use that Embedded tomcat thing, you need to start it as debug, then browse to http://localhost:8080/my/app

You should then be able to access your application, through the embedded tomcat.

Static content (CSS, images):

Say you modify myapp/webapp/css/myapp.css, the file is directly in the webapp folder so it is reloaded next time you load a page that use that CSS. Idem for images.

JSPs

If Tomcat is configured to recompile JSPs when they are modified (which is the default), then as soon as you modify a JSP, it’s recompiled the next time you access it.

Java code

This is the greatest part. If you modify java code in Eclipse, eclipse recompiles the java file to the corresponding .class, then also feed it to the debugger so the JVM sees the new version. (That works only if you « Run as Debug » from Eclipse)

So when you reload your page, the new class is used and the modified code is used. Magic!

Limitations

There is one limitation, which is not due to this setup, eclipse or Tomcat. It’s due to the fact that Java debugger can’t be feed a class that has « changed too much ». Changing too much means that as long as you change code in a method, that’s normally fine. But if you add/remove/rename a class, a class method or a class member, then the debugger is unable to feed it to the JVM through the debugger. Eclipse warns by saying: « Hot code replaced failed », saying that your modified code is not available in the JVM (the old code stays there) and that you should restart your application.

You then need to simply stop the TomcatRunner and restart it.

Another limitation is that if the modified classes was already run and loaded, then it won’t be reloaded before a server restart. One example, is if you have a class that set up some values in a Singleton, changing the singleton code won’t change the singleton already in memory. Idem for the spring context.

Conclusion

Using this setup change the round-trip time from ~60 seconds to instantaneous, which is great. Due to the limitations above, we must restart the webapp every 3-10 minutes depending which code we are changing, but that’s acceptable. And remember we use Unit tests for all development, we use that setup only for pure web development (JSPs)

References:

http://www.onjava.com/pub/a/onjava/2002/04/03/tomcat.html

http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/startup/Embedded.html

Fini le site jesc.ch de mon travail indépendant et vive mon (notre) blog sur wordpress.

Ce changement est important parce qu’li met un terme à mon travail indépendant, terminé effectivement en décembre 2006 sur burn-out, mais le site restait. Il est maintenant down, voila, ça c’est fait, comme dirait brice.

Pour votre info, JeSC ca voulait dire « Jean-Eric Software et Consulting »

Et maintenant ça veut tout simplement dire: « Jean-Eric et Sara Cuendet »

A bientot donc pour de nouvelles aventures.

En Suisse, le système d’assurance maladie (LaMAL) fonctionne de la manière suivante:
- Le patient paie une prime mensuelle obligatoire. Son montant dépend de la franchise qu’il choisit.
- Il paie ensuite les frais médicaux qu’il engendre (consultation chez le médecin, séjours à l’hopital, médicaments, …) jusqu’à concurrence de la franchise qu’il a choisie.
- Il paie ensuite 10% des frais médicaux jusqu’à concurrence de 700.- (soit 10% de 7000.- de frais en plus de la franchise)

Attention:

1. Ce comparatif ne s’occupe pas et ne tient pas compte des assurances complémentaires. Il s’agit uniquement d’une analyse des primes et des franchises de l’assurance de base, obligatoire.
2. De plus, les montants des frais médicaux utilisés dans les exemples sont purement fictifs
3. Les primes sont prises de la caisse Progrès, pour un homme domicilié dans le canton de Vaud, sans couverture accident
4. Les montant pour d’autres cantons sont différents mais les principes sont identiques et les conclusions probablement semblables

Cas concret
M. Truc est affilié à la caisse maladie « TropCher ». Il opte pour une franchise à 300.- et paie une prime mensuelle de 324.-
M. Truc paie donc chaque mois 324.-, qu’il soit malade ou non.
M. Truc attrape une grippe et il va chez le médecin.
Cout:
- 180.- pour la consultation chez son médecin
- 37.- pour les médicaments prescrits
Total: 217.-
M. Truc s’acquitte donc de ces frais (le total de 217.-) puisque que la franchise de 300.- n’est pas atteinte.
Dans ce cas, la caisse maladie ne rembourse rien. M. Truc paie les 217.-

2 mois plus tard, M. Truc se plaint d’une douleur dorsale. Il consulte son médecin qui l’envoie faire un scanner, suspectant une hernie discale. M. Truc se rend ensuite de nouveau chez son médecin pour l’analyse des résultats du scanner.
Cout:
- 210.- de consultation médicale
- 1200.- pour le scanner
- 150.- pour la 2ème conultation chez le médecin
Total: 1560.-
Cette fois la franchise est dépassée. M. Truc va donc payer:
- Le reste jusqu’à la franchise: 300 – 217 = 83.- (reste de la franchise impayé)
- 10% du reste des couts. Le reste est donc de: 1560 – 83 = 1477.- Il va en payer 10% donc 147.-
- M. Truc va donc débourser 83 + 147 = 230.- pour ce problème dorsal, l’assurance maladie prenant en charge le reste, à savoir 1560 – 230 = 1330.-

On peut définir 2 cas extrêmes de patients: ceux qui ne sont jamais malades et ceux qui sont toujours malades (ou suffisamment malades pour qu’il ne paient plus du tout les frais médicaux qu’ils engendrent).

1. Dans le premier cas, si M. Truc n’est jamais malade, il va payer:
   • - sa prime maladie: 3888.-
2. Dans le 2ème cas, si M. Truc est très malade (une grippe + douleurs dorsales + ablation d’un kyste dans le genou + burnout, coût total: 17′900.-), il va payer:
   • sa prime maladie: 3888.-
   • sa franchise: 300.-
   • 10% de la suite (jusqu’à concurrence de 700.-): 700.-
   • Ce qui nous donne un total de 4888.- sur l’année.

Prenons le même cas, sauf que M. Truc a pris une franchise de 2500.- au lieu de 300.- Coût de la prime: 196.- au lieu de 324.- / mois. Coût par année: 12x 196 = 2352.-

1. Dans le premier cas, si M. Truc n’est jamais malade, il va payer:
   • - sa prime maladie: 2352.-
2. Dans le 2ème cas, si M. Truc est très malade (une grippe + douleurs dorsales + ablation d’un kyste dans le genou + burnout, cout total: 17′900.-), il va payer:
   • sa prime maladie: 2352.-
   • sa franchise: 2500.-
   • 10% de la suite (jusqu’à concurrence de 700.-): 700.-
   • Ce qui nous donne un total de 5552.- sur l’année.

Récapitulons:

Economie dans le cas 1 entre une franchise à 300.- et une franchise à 2500.- : 3888 – 2352 = 1536.-
Perte dans le cas 2 entre une franchise à 300.- et une franchise à 2500.- : 3888 – 2352 = 664.-

On se demande bien à quoi servent les franchises à options si la « perte&quote; n’est que de 664.- sur 5000.- environ! Dans le pire des cas!

En fait, on peut établir un seuil qui est le coût à partir duquel on « perd » de l’argent avec une franchise à 2500.-.
Ce coût s’établit empiriquement. Pour les chiffres ci-dessus, il s’agit d’un montant de frais médicaux de 2010.-

La question est donc de savoir si on prévoit de « coûter » plus que 2008.- de frais médicaux par année, et de savoir si on peut payer 664.- de plus sur l’année en cas de « coup dur ».
Tout cela pour économiser 1536.- tout de même …

Intel made several families of microprocessors:
- Pentium
- Pentium II
- Pentium 3
- Pentium 4
- Pentium M (for laptops, also known as Centrino)
- Intel Core
- Intel Core 2

These are families, based on different micro-architectures.
In 2000, Intel introduced the new P4, a completely new processor family, with a new micro-architecture called NetBurst. It was designed to be able to go very high in frequency. At the expense of a bad instruction/cycle rate. This had also the drawback that it used a lot of power, since the frequency was very high (as high as 4GHz). And also become very hot, needing BIG fans to cool it.

In parallel, Intel developped its Pentium 3 processor into the Pentium M, known as Centrino, for laptops. The P4 used too much power for laptops, so Intel used that good old P3 and redesigned it to be very power efficient.

Intel also has the Xeon family of processors, used in servers. It is based on the P4 design. The differences between a P4 and a P4 Xeon is the quantity of cache memory on the processor chip and the ability to be run as multi-processors.

Then Intel unveiled the « Intel Core » processors, which is a Pentium-M (aka Centrino) redesigned to be more powerful. They were used in laptops, but also in desktops, for not too demanding applications. Apple Intel based Macs use the « Intel Core » processors. These processors are available in 2 flavors:
- Intel Core Solo : 1 processor
- Intel Core Duo : 2 processors
The DUO is just like a Dual-processor computer (it’s like having 2 « Core Solo » processors), but the 2 processors are in the same chip (In the same piece of silicon).

So Intel has 3 lines of processors:
- Desktops (P4)
- Laptops (Centrino)
- Servers (P4 Xeon)

Since 3 years, AMD, the other microprocessor firm, has the lead in performance over Intel, with its Opteron and Athlon64 series of processors. They are more powerful, and use less power to do it. That’s all that companies want for servers. Less power means less climatisation and smaller power bill at the end of month! And that’s also all that gamers want for best FPS in games! So AMD got +16% market share from Intel last year only!
AMD has the lead in servers and desktops computers, but are quite insignifiant in laptops.

But now, Intel strikes back! They unveil the « Core 2″ microarchitecture. This is not the same as « Core Duo », this is a new architecture based on the « Intel Core ». So you have:
Intel Core
Core Solo (One « Intel core » processor)
Core Duo (Two « Intel core » processors)
Intel Core 2
Core 2 Solo (One « Intel core 2″ processor)
Core 2 Duo (Two « Intel core 2″ processors)

These processors are designed to get the lead back from AMD. After the first benchmarks (based on Games like Quake or UnrealTournament), they seem to be around 30% faster that AMD Athlon64 at the same clock speed! Done by independent reviewers of course:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2795 http://reviews.cnet.com/Intel_Core_2_Duo_E6700/4505-3086_7-31973836.html
http://www.tomshardware.com/2006/07/14/core2_duo_knocks_out_athlon_64/

« Core 2″ processors are declined in 3 versions:
- Laptops (Code name Merom)
- Desktops (Code name Conroe)
- Servers (Code name Woodcrest)
They are all based on « Core 2″ architecture, and they all come in Solo or Duo versions (which is 1 or 2 processors on the same chip). Core 2 processors are available now for Desktops and Servers, while laptops ones will arrive in september.

Voila. The goal of this (lengthy) mail was to explain that « Core 2″ and « Core Duo » are not the same thing as a lot of people tend to believe.

See you.

Jean-Eric Cuendet
Perso : http://www.jesc.ch