Re: [U2] Why Pick U2?
Play nice now Rob,
This is bordering on a 'holy war'. You seem to want to reiterate previous
points, ones that no one has argued with you.
As I already said, U2 cannot target all markets, but you appear to want to
discount that and focus on the market of you choosing. I believe you grossly
underestimate the size of U2's market, so let us just leave that at that.
Brian Leach as released several books, but that is neither here nor there.
No one is making claims that it is mainstream with the general public. In
fact, this leads to the next point.
No, I did not overlook your Google trends link, I dismissed it as baiting.
You know as well as I do that it doesn't mean anything. If you wish to
disagree, discuss that one with your boss first:
http://programmers.stackexchange.com/questions/70606/trends-of-java-and-javascript/70607#70607
U2 is not marketed as a standalone product like MDB, it is embedded in it.
Most people running it wouldn't even know.
I highly doubt that there will be a new acquirer for U2. I think it is safe
to safe that Rocket U2 will stay as is for a very, very long time. If you
want to know why, have a look at RS and have a look at the discussions
around why U2 was sold by IBM.
Once again, to address the majority of your post, I am not arguing that
there are things we can do better and we are working on it.
Tell Joel it is about networking at U2U, there is a whole market out there
that might not have heard of FogCreek or their offerings. :)
If you want further discussion on anything, feel free to continue it with my
privately. Not because I don't want it discussed openly, but because I'm
sure the rest of the people on this list would like this put to rest
Best regards,
Dan
Dan,
Let me me re-phrase my statement:
"For 99% of software projects, MongoDB destroys U2 in every single aspect.
And it's free."
The fact is, most people aren't developing emergency systems. And even if I
were building a banking or emergency system today, despite U2's longevity,
I'd argue that up-time alone is not enough considering:
1. I can't find a book on U2 (how to administer, scale, interface, etc.).
2. I can't easily find technical talent who have experience with U2.
3. The technology has changed hands a number of times over the past decade.
(What prevents the next acquirer from ceasing development?)
Yes, you're right -- the people who have been using U2 for the last 20 years
successfully should probably stick with it for its reliability. But someone
searching for a new database solution is going to be met with a multiple
barriers to entry (the first being discovering that U2 even exists).
Up-time is one aspect. What about scaling? Rapid development? Community
support and involvement? Look at what Craiglist is doing with MongoDB. Did
you overlook my link to the Google search term comparison?
I browsed through the 116 page manual on EDA :-), but I don't want to have
to convert my data in order to access from anything but UniBasic.
It will be a big day for me when I can finally do something like I've
written below from programming language X and have a reasonably powerful,
user-friendly API for working with native U2 data.
db = UniData::Connection.new("localhost").db("mydb")
I digress.
I don't want to continue my argument in fear of sounding like I'm just here
to bash U2. That's not the case. I definitely interested in U2 at some
level even though I don't work with it much anymore.
Maybe it's something like Stockholm syndrome. I worked in the U2 bubble for
so long. Now that I'm out and benefiting widly from flexibility and
openness and thriving ecosystems, and I want U2 to be that way too.
The verdict is still out for me on Rocket, but I'd love to see the progress
you're talking about come to fruition. I don't know if I can justify U2U to
Fog Creek, but we'll see. :-)
All the best,
-Rob
--
View this message in context:
http://old.nabble.com/Why-Pick-U2--tp32061959p32075733.html
Sent from the U2 - Users mailing list archive at Nabble.com.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Why Pick U2?
This essentially is what I was working on with my perl routines to interface
with UV.
You would open a file giving the accout and filename and receive a token back
Then you could read items with an idname and the token getting an array back
pass a TCL command and be able to get back an array of ID's
Yes, it would be better if I could do these without having to write my own
API..I agree.
George Gallen
Senior Programmer/Analyst
Accounting/Data Division
ggal...@wyanokegroup.com
ph:856.848.9005 Ext 220
The Wyanoke Group
http://www.wyanokegroup.com
From: u2-users-boun...@listserver.u2ug.org
[u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
[rsob...@gmail.com]
Sent: Saturday, July 16, 2011 12:37 PM
To: U2 Users List
Subject: Re: [U2] Why Pick U2?
It will be a big day for me when I can finally do something like I've
written below from programming language X and have a reasonably powerful,
user-friendly API for working with native U2 data.
db = UniData::Connection.new("localhost").db("mydb")
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Why Pick U2?
Dan,
Let me me re-phrase my statement:
"For 99% of software projects, MongoDB destroys U2 in every single aspect.
And it's free."
The fact is, most people aren't developing emergency systems. And even if I
were building a banking or emergency system today, despite U2's longevity,
I'd argue that up-time alone is not enough considering:
1. I can't find a book on U2 (how to administer, scale, interface, etc.).
2. I can't easily find technical talent who have experience with U2.
3. The technology has changed hands a number of times over the past decade.
(What prevents the next acquirer from ceasing development?)
Yes, you're right -- the people who have been using U2 for the last 20 years
successfully should probably stick with it for its reliability. But someone
searching for a new database solution is going to be met with a multiple
barriers to entry (the first being discovering that U2 even exists).
Up-time is one aspect. What about scaling? Rapid development? Community
support and involvement? Look at what Craiglist is doing with MongoDB. Did
you overlook my link to the Google search term comparison?
I browsed through the 116 page manual on EDA :-), but I don't want to have
to convert my data in order to access from anything but UniBasic.
It will be a big day for me when I can finally do something like I've
written below from programming language X and have a reasonably powerful,
user-friendly API for working with native U2 data.
db = UniData::Connection.new("localhost").db("mydb")
I digress.
I don't want to continue my argument in fear of sounding like I'm just here
to bash U2. That's not the case. I definitely interested in U2 at some
level even though I don't work with it much anymore.
Maybe it's something like Stockholm syndrome. I worked in the U2 bubble for
so long. Now that I'm out and benefiting widly from flexibility and
openness and thriving ecosystems, and I want U2 to be that way too.
The verdict is still out for me on Rocket, but I'd love to see the progress
you're talking about come to fruition. I don't know if I can justify U2U to
Fog Creek, but we'll see. :-)
All the best,
-Rob
On Fri, Jul 15, 2011 at 6:14 PM, Daniel McGrath wrote:
> Thanks for the reply Rob,
>
> As to cherry picking, I wasn't calling out anyone in particular, but the
> thread in general. I believe some of our disagreement involves around the
> statement "MongoDB, which falls into the same class of database as U2.":
> MongoDB is *not* an enterprise class database. As per Charles Shaffer post,
> would you honestly use MongoDB for his system? I wouldn't. You would either
> go with a major SQL DB or an MVDB (such as a U2 system). As I and others
> have noted, U2 gives you a unique value proposition in that it generally has
> faster change turn-around, cheaper associated costs and stability of
> platform (it will still be fine in 20 years without major architectural
> changes). MongoDB just doesn't fit into this realm. It isn't enterprise
> class; it doesn't have the maturity to provide the guarantees needed in
> serious enterprise systems, even if only for the mere fact it hasn't been
> around long enough to prove it. As to FourSquare, please re-note the link to
> FS's 11 hour outage caused by MongoDB as an actual example. Can you imagine
> Bank of America having an 11 hour outage on all money transactions and how
> much money/customers they would lose? People have been conditioned to accept
> website outages from time to time. No-one is going to die because FS is down
> for a day. Other things in life are not forgiven/forgotten so easily.
> Emergency systems run on U2. I would consider myself insanely negligent if I
> convinced those emergency services to drop U2 and replace it with an
> immature (even if exciting) database such as MongoDB.
>
> I cannot really comment on your issues with UniData, not knowing when or
> what they were. We ran UD at a Bank and out of our 20+ systems (most on MS
> SQL) it was by far the most stable with the least down time. It had to be,
> lest it put us out of business.
>
> U2 does not (and cannot) target EVERY market out there. Comparing it to
> other databases outside of the its core markets and saying "MongoDB destroys
> U2 in every single aspect. And it's free" (http://goo.gl/7O5Hm) is a
> catchy, yet ultimately flawed statement.
>
> I don't think anyone would argue that 'Big Blue' and 'Agile' are the wine
> and cheese combination of the tech world. Please remember that U2 is now
> Rocket U2, not IBM U2. Rocket Software is an amazingly agile company in
> comparison. How long did it take them to release DataVu? Also remember that
> in the "company scale" of time U2 hasn't been with Rocket for that long.
> Take into account ramp up time for a new working environment, complete
> office move, rebranding of all products and documentation when determining
> how sluggish U2 is. Expect more developments to come out quicker. There are
> some exciting changes coming do
