we are planning to migrate our codebase from xI50 to xI52. Could anyone please let me know, how xI52 is different from XI50 ?I am just tryingt to figure out what kind of changes will need to be done to our existing codebase on xI50 to make it compatible on xI52?
Also, I have below two questions:
1) Is Xi52 the best hardware to which we should migrate from Xi50? What are the advantage of Xi52 from others?
2) What are the best practices to migrate the configuration from Xi50 to Xi52?
Regards,
Rahul
Good question Rahul!
As a rule of thumb, the compability of the codebase is essentially an aspect of the running firmware, not the model in itself.
So, figure out the firmware version of your XI50 and your target firmware, which probably is the latest. If you upgrade to the same firmware version (such as version 5), there should be no issues.
Here is a list of all firmwares.
http://www-01.ibm.com/support/docview.wss?uid=swg21237631
The release notes to look for information in each firmware, so go through the list (you may have to aggregate through several firmwares, such as 4.x to 5.x, 5.x to 6.x).
Sometimes, you have to look into individual technotes for info.
In general, DP contains compability rather well, and breaking changes resides mainly in details.
http://pic.dhe.ibm.com/infocenter/wsdatap/v5r0m0/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2FrelnotesXI.html
http://pic.dhe.ibm.com/infocenter/wsdatap/v6r0m0/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2FrelnotesXI.html
Related
I am new to Hadoop. So, please can anybody explain to me why we need cloudera or Hortonworks? We can download each Apache project and use those libraries to create Big Data project, right? And, also if I already use linux OS, do I have to use cloudera-quickstart vm ware? Thanks in advance.
Lets look at this in using a similar analogy.
Lets assume you are using OS 'D' of version 'v1'. In it you need different set of libraries - A,B and C.
A depends on B and also C depends on B. Across the versions of A and C, the dependencies are different versions of C.
Now if you need all the three libraries, it becomes your head ache to make sure you use/install libraries of each such that each are compatible and there's no clash.
Plus not everyone is expert in all the three libraries as well as the underlying system. So what happens if there some optimization needed in using these libraries while using them in your own tools? Also what about some issues that you face while using them.
That's where these "Stack Distributions" come into play. Each of these vendors provide a complete stack which is tested as a whole and are compatible with the different libraries that are packaged and not just only hadoop. This makes lives of lots of people easier. Also based on what plan or subscription you have with the vendor, you can get support/training and other auxiliary things.
Just to add as an extra, please remember, Open Source does not necessarily mean Free.(Please note that this is my personal opinion)
As to your other part of question wrt with linux do you need to use any vm ware image or so, for a beginner or learning purposes, this makes your life rather simpler.
We know all that JGraph is a very powerful graphic library and now we are in version 6 (JGraphx).
Me I have an application (by the way I am newbye in JGraph) coded in JGraph 5 and I want to migrate it to Graphx.
Is there any tut to know what is the main differences between these two versions?
That migration, is it easy to do (in general)?
JGraph (the last version of which was version 5) and JGraphX (which was originally going to be called JGraph 6) are completely different code-bases. JGraphX was a complete rewrite from scratch, which is why we made the naming change to avoid the idea you could upgrade from 5 to 6.
So no, there is no migration route, you'd need to re-write your part of the application that interfaces with JGraph(X).
I work on windows and I need a very simple version track software to be able to check in/out a folder project, no matter what's inside. I downloaded few programs, but most of them are very complicated, team work, cloud, thousands of options, etc.
I need some simple version track of my files, locally. Can you recommend me something useful?
i'd recommend using simpy rar with datetime. Or as an option - just parameter to update archive instead of creating new one
There are a number of reasons why version control software have the number of options that they do, without understanding the basics of how the particular version control system that you are trying to use functions these options can seem overwhelming. To be able to use version control you will have to put in a little bit of effort to understand how it works. That being said I find that Bazaar from Canonical makes a pretty good introduction to version control for beginners. It has a pretty nice download page for various platforms and comes with a GUI client and comes with beginner friendly documentation.
However, having used other version control systems I personally don't like to use Bazaar. The choice of version control system should not make a difference if you are only looking to use it yourself and don't need any of the more advanced features. If you are willing to invest some more time however, I would recommend trying Mercurial it has some documentation for beginners and a fairly nice beginner friendly GUI for Windows in the form of EasyMercurial.
I use Intellij Idea 7 for Java dev. My dev is 'limited' to all J2SE features plus light JSP, Servlets, and super light usage of JPA. No J2EE, no massive use of random frameworks, etc.
Is it worth upgrading to ver 8? "Worth it" to me means better "core functionality" in terms of speed (ESPECIALLY startup speed), memory utilization (seems like it starts having serious problems with four or more projects open), and auto bug-finding.
More frameworks supported and more languages supported (other than perhaps Haskell and C++), and more refactorings don't interest me at this time.
A while back, I installed a preview version of 8 and it seemed -exactly- the same as 7, as far as my needs were concerned.
Anyone loving the upgrade to 8, and if so, why?
Thanks
It also seems to be easier to configure a new project over top of a complex collection of existing code.
For example, something that you would naturally configure into 5 or more modules.
There is a really beautiful go to/create test wizard that is bound to ctrl-shift-T. Worth the upgrade by itself
The best way to tell is to check out the list of new features and decide for yourself. I haven't discovered any single feature so far that by itself is worth upgrading - the simplified UML view is quite nice, as is the improved Maven integration. The UI feels a bit more streamlined and faster. It seems like most of the attention has gone into non-Java features like better Flex support (which I am really thankful for as I don't like FlexBuilder but I haven't had a chance to use yet).
IntelliJ 8 has a configure plugins feature that allows you to disable plugins with dependencies. Nothing trial and error couldn't replicate, but it is nice.
Startup is only marginally slower. But indexing once opened is a lot faster than before, even unnoticeable for most projects, except after a commit to Subversion. It seems a commit to subversion triggers the indexing twice.
I am working on the Diana-EAP build - but 8 has git integration built in. The EAP has better git integration than the 8.0.1 release - it looks like that is something they are really focusing on.
Definitely not! Seems that the variables defined in our custom taglibs are no longer able to be used in the jsp (worked in 7.0.4). All red. No auto complete.
Oh, and the new settings menu is horrendous!
Some benefits of IntelliJ IDEA 8:
IDEA 8 supports Subversion 1.5 new functionality - e.g. merge tracking, which may be useful especially if your team (like ours) uses a lot of development branches and thus merging is frequent.
One detail I appreciated about IDEA 8: As you probably know, IDEA has had changelists for pretty long now, built on top of any underlying version control system - this is a really useful feature. So, now that Subversion itself supports changeslists, IDEA's changelist implementation has been changed so that it is perfectly compatible with Subversion's native changeslists. (For example, you'll be able to work with any changelists created in IDEA also when using svn command line tools directly.)
Edit: in your case, perhaps it is not worthwhile to upgrade. For me, at least, startup and file indexing seems to be somewhat slower in 8 than 7. [But for me personally the upgrade was definitely worth it, because it solved a long-standing VCS problem with IDEA 7 - it could hang "waiting for VCS sync to finish" for an hour or whatever after hitting Ctrl-K.]
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.