Agreed, if your goal is to remove CO2, then using a fuel cell by itself is not a helpful fuel cycle. However, the Fuel Cell based cycle is very promising and can help to improve the viability of remove solar farms where transmission loss is a significant detractor.
I wonder since the output of a fuel cell is pure heated CO2, this output can be fed back directly into the solar input side to further improve efficiency?
Maybe there are other absorption cycle that can be added to the chain after the fuel cell that leverages the heated and concentrated CO2?
Formic acid can be stored and used in a fuel cell to have a very good solar storage fuel. No need to worry about CO if kept within this fuel cycle.
Related Abstract: http://pubs.rsc.org/en/content...
I laugh until I cry when I see people saying that the blackberry infrastructure is old school, when the big corporations and users are throwing so much money and data at cloud computing.
Blackberry backend is cloud infrastructure in the purest form. The guarantee of the BB Cloud is that It offers a guarantee that your data will get through to the end customer. This is the essense of cloud computing. Yes, when it goes down your data gets held up but this is the same with any cloud infrastructure. In the case of this latest outage, I do not believe there was much if any lost transactions and it simply came down to long delays.
Yes, it is true that RIM can do a much better job at building and scaling their infrastructure to be future ready. Tripple fault tolerance on all infrastructure in any cloud computing is an absolute must and this should be the minimum that all companies adhere to. RIM will need to raise the bar a few more noches to ensure that their cloud maintains the highest possible level of quality of service.
Many argue that BIS and BES is too complex a model and needs to be simplified. This cannot be farther from the truth. In order to make large and complex solutions robust and scalable, you must add complexity by adding extra layers within the infrastructure in order to make it work. Stable, secure and light weight messaging and data transactioning can only be done with a cloud infastructure in between.
The biggest challenge with the blackberry cloud is not its instability but rather that when it fails, many users are affected and thus it is good news to post on blogs. In reality, the BB cloud is likely more stable on average than most other solutions out there for messaging and data transfer from mobile devices. The only reason you do not hear otherwise is that failures are localized and would only affect hundreds of users which does not make for very good news.
I have never thought that a Goldberg machine can be actually partially useful such as teaching history (albeit very loosely).
Maybe they should create a new class of Goldberg machines to provide some educational purpose
I purchased my first Mac at on a Blue and White at version 10.0.x. I did so because it looked like an awesome development platform. Over the years, I discovered that was not the case. Even after moving up through many other Macs, I have consistently come back to trying to develop on a Mac and it just does not work for me.
For doing complex Web development using Tomcat, Apache and a ton of DHTML, I have found that Mac OSX is just not user friendly enough for managing all the different tail windows, process start stop windows, code windows etc.. to build complex apps. The window management is to cluttered to manage so many tasks. I am not a fan of using IDE's and prefer to use programmers editors and standard open libraries. On Mac, the only way to use Progammers editor and edit multiple sources at one time, was to have many windows open. In windows any decent code editor has tabs to manage opened files. It has taken mac almost 8 years to get this right and now finally some editors support tabs. I think KDE is now finally including MDI frameworks OOTB but Gnome still is not so same issue there.
Another huge issue with development in Mac OSX is the inability to effectivley extend Finder like you can in Windows with windows explorer shell extensions. The ability to trick out Windows Explorer shortcut menus with tools like File Menu Tools and Tortoise SVN make it amazingly powerful development system. This is a problem of the Vanilla consumer base of Mac systems and is a huge problem in my mind. I am absolutely spoiled in windows with the dozens of tools I have extended in Windows Explorer. Linux has shell extensions but lack a ubiquitous file manager that crosses all apps which makes shell extensions less valuable to users. Hate to say it but Microsoft did the right thing when it comes to Windows Explorers ubiquitous nature in windows.
To make use of my Mac, I now use VMware Fusion running Windows and this has made me way more efficient by orders of magnitudue than using Mac directly. Windows on a Macbook is often better than Windows on a Windows laptop. Call it comfort level but I am always cursing my Macs when doing deveopment with stupid things like not being able to resize a window in the top left corner.
Don't get me wrong, I own 3 macs at home and am typing on a Macbook pro 17" right now but I do very little development on it unless through Fusion running Windows XP.
Hopefully some day, that will change but for now I have to be pragmatic and just pump out the code in the environment that is the most effective for me.
I have given it a go and compared it to QCad which I have a licensed copy and used heavily of late. Although, it is likely much more feature rich than QCad, it is missing one key feature of having a "Layers Pane" that is always visible. In DraftSight, you must open a modal dialog to manage the layers which IMO is kind of clicky for complex layer management. This is a pretty glaring usability miss for me and I am holding off for them to implement this before I jump on the band wagon.
On the bright side, hopefully this will like the fire under QCad developers to get 3.0 out there which has been "under development" for a couple of years now. QCad itself has some issues too such as poor workflows and some basic usability features and its well due for some improvements.
Good to see some progress in the free / reasonably priced 2D Cad world
I have not heard of anybody successfully hacking a password protected Blackberry. Even with physical access. Maybe there is a way but it is probably too costly and time consuming to even consider. Definitely no such hack has been documented.
If anyboyd has any examples where a password protected BB is cracked, I would be interested to hear about it
Thanks for the pointer. Right now I only maintain simple SVN depot's and with little collaboration so it is pretty light weight and little branching or merging required (if at all). My big Depot's are in P4 and required by my current employer and I maintain a strict Trunk=Prod Branch=Dev CR model. It is slow but steady as long as my team follows the rules
I will do some research on GIT for fronting SVN in the future when I have time to play outside in the OpenSource domain again.
I too have used Subversion since it was in pre-release (0.8) I think. When I started doing research on Source control, my managers said "Use VSS". I disliked MS at the time and still doo and thus avoided that path. I came across the thesis by the author of RCS (great read) and researched about RCS, PVCS, CVS and SVN. SVN was a dream come true when I saw it. Tortoise SVN was the icing on the cake. I have since continued to use SVN and have converted many others to SVN away from VSS and other tools. I love SVN still and use it daily and will not be switching any time soon.
Regarding the post, I don't really like hearing is that "All major open source projects" are moving away from SVN. Sorry but there are many still using SVN and will continue to do so. For instance FreeBSD, which is a huge project, who are still using SVN today. Also, saying that SVN is wrong is wrong. SVN is wrong for some groups but very right for others.
Also, people are constantly mis-reading Linus's comments on SVN. Linus was just dissing SVN for his uses and was tired of the evangelical SVNers nagging him to use it. I appreciate that his code models are different and require different SCM tools and that a SVN centralized model does not work. But this does not mean that SVN is wrong for everyone.
SVN is valid for many groups, teams, around the world and will continue to be so for the foreseeable future.
Check out the nice video on Youtube. http://www.youtube.com/watch?v=fg7J8P-uXqM&feature=related