Besides having no real control over initialization, it has a really nasty side-effect. When shutting down your Application, order is very important. Especially with bigger software with multiple developers, you easily get into shutdown order issues, unintentionally reinitializing your singleton. I've witnessed this in two projects. In one case there was a thread running feeding a singleton manager with data. The singleton was shutdown, the thread however was still running, so it reinitialized the manager feeding it with data causing thousands of memory leaks. In the other case, a user went back to the mainmenu of the game, and wanted to continue/load a new savegame. Part of the system was shutdown and would be reinitialized depending on the user actions...
So what about the manually initialized singleton? Let's view an example in C++ note: google 'scott bilas singleton' for an example singleton-template implementation. In our example it would have to be extended with a function InstancePointer().
So we have an Application object, which initializes two singletons. The application object has a message loop which is called periodically. In the loop it calls the kernel-class to log its statistics. Kernel calls our statisticsManager-singleton to do the actual upload.
See the example C++ sourcecode below: There is one big difference however. With the second approach, we can create multiple application instances, each using their own kernel & manager instances.
The question which arises is: does this make sense? Well, it depends on the situation. Assume our system streams video. With the second approach, we would be able to instantiate multiple systems, and thus have multiple streams. Assume we add another class, a HttpPostManager, in which we can queue http-post-requests, which are executed in a thread. A callback can be triggered with the post-result. Since it's a Singleton, our Application-instances (and their Kernels and Managers) would use the same HttpPostManager. They would queue their request, which would get executed, and they would get a callback when it's finished. It would actually make sense to only have one, single HttpPostManager so this is a real singleton. Another class perfect for being a singleton would be a Flyweight class.
I prefer dependency injection, mainly because since you just can't get "everything" from "everywhere", you need to be much more aware of what you are doing, and you get a good feeling for which class-variables/functions should be in which class. If you don't you tend to end up passing "everything" as function-parameters, which is destined to end in a big mess.