Wrong - T-Mobile, who doesn't act like a traditional carrier, is SINGLE HANDEDLY driving down rates.
Before they went on their marketing blitzes to let people know, AT&T and Verizon kept raising rates, or suckering people into plans that they'd then drop and replace with more expensive things at the earliest contract excuse.
Not every market has a T-Mobile. The insurance industry is one such market.
If they employ these methods, their risk should reduce significantly, as well as repo costs, and therefore be reflected in nice big loan rate drops. OTOH, if it enables a person who otherwise would not qualify for a loan to get one, it could be argued as a 'good thing'. I personally shudder at this level of what feels invasive.
Or increase, when someone can no longer go to work and loses their job.
It's like they didn't even try to come up with a defensible or plausible reason. Reminds me of the old TV commercial parody with Lily Tomlin in it "We're the phone company..."
Bravo to Google and Wikipedia for trying to be transparent about this. The law used seems absurd, and is open for much abuse (think politics, for one).
So much for "Whale Wars" and the gang of the Sea Shepard. Ah well.
Seriously though, laudable as the decision (that would require others to enforce) is, I'm baffled that it took this long (almost 4 years) to make a decision on something that clearly wasn't scientific in nature.
Gears-Plural, more than one Gear-Singular, only one
It has a gear. It does not have gears.
I'm sure you'll now come in asking about reverse.
Wow, so many of you who can't count to two? A gear is useless without ANOTHER gear coupled to it. A single ratio gear driven coupling transmission system requires at least TWO gears to work. One connected to the output. One connected to the input. Those gears are coupled (teeth of one drive the teeth of the other).
Yet there are a dozen posts by transmission and gear experts who seem to think that one free floating gear magically transfers power to someplace without another gear meshed to it. Wow. Just... wow.
That doesn't demonstrate that it's all about the money. Some preachers know that they're selling BS, others actually believe their derp. I think Ham is an emotional thinker, and actually believes the nonsense he spouts.
I don't. He cherry picks too much - especially when confronted with conflicting biblical "evidence" where he either ignores the conflict or cherry picks himself off into a different direction.
Very cool! I wrote a script a long while ago which you might like (or find a use for).
https://web.archive.org/web/20...
It's a next-gen script but could be adapted. It's got good pacing and it's an easy read.
Cool - please contact me via the Facebook link in my sig or via our startreknewvoyages.com website's contact page.
"(including *SUN* libraries that don't work in Java 6/7)"
You know that com.sun.* was never intended to be a stable API, right? You were using private APIs, now complaining that they broke, and blaming Java? That's some misdirected anger IMHO.
I used no such thing. I inherited the code when the company I work for bought another company and their infrastructure.
Cool. It just reminds me of a talk someone gave about a big project in C++ which had a hellish 20 hour build.
It's great stuff. One of the things I am enjoying the most about it is cutting the number of needed interlinking systems and technology down to a bare minimum using methods in one messaging system that everything can connect to (with MQ once again giving the assist where needed). Also wrapping EVERY vendor function from EVERY vendor library I deal with - in the end, with everything compiled with that one new wrapping library, it means all we ever have to do is deploy a new vendor library with an updated wrapper library - instead of changing code across hundreds of projects.
What's your relationship with Star Trek Phase II? It looks like you write a number of articles for them on their site.
One of the producers and the lighting guy (Gaffer). One new episode out this past Dec 31st, and another coming soon (once we manage the daunting task of color correcting from the original raw footage).
And here's more...
...was deprecated in J2SE 5.0. It has been disabled in Java SE 6, and it will be removed in the next release.
There are a lot of those if you step through the Java versions. Most people don't realize it ever. I ran into it first hand.
Either way, I love this job, especially since part of my project is to make sure this gets done correctly (instead of what happened under the previous code owners).
Well dude if you're maintaining an app this complex what do you want? To be baby sat or something? Java is the least awful thing about your situation.
I'm NOT complaining. I love this job - when I am done, this problem will never happen again. I was pointing out that the OP was grossly wrong. That's all. Nothing more. And the ACs comparing what we have to some little dinky web app or 80,000 lines of code (after I spelled out how large this project was) is ridiculous at best.
Actually:
(1) The earlier compiler logs show no errors or warnings (neither does compiling it with the target version of Java).
(2) This seems to indicate all sorts of problems, and doesn't even touch Java 7: http://www.oracle.com/technetwork/java/javase/compatibility-137541.html
(3) Some Java 1.3 and earlier functions that were earlier deprecated have been removed (in Java 7) for security reasons (the reasons they were deprecated to begin with).
I believe your organisation is doing something strange.... You should either pay for Oracle support, and receive bug fixes early, or pay developers who can quickly fix JRE bugs themselves, and that will be still a tiny fraction of your IT budget.
WE didn't create the problem, and we are well versed on fixing it. When the previous code owners had to pay IBM to fix custom code for FileNet (written by a company kicked off the project), it cost half a million. I think you missed the part above where I mentioned we got stuck with this disaster during a purchase of another company and their antiquated infrastructure. Also, what I didn't note was that the project was actually started around 2002 on Java 1.3 and possibly earlier.
That's not been my experience. We've been maintaining a large web app under tomcat with Struts for 12 years and have upgraded from Java 3 though Java 7 without any significant compatibility issues. Basically at the beginning of our release cycle we put in the new Java and the new Tomcat and deploy and get to work....
a large web app - how nice. Half of FileNet is a massive collection of FileNet provided, and previous company modified Java Server apps - not a web app. Much of the underlying server stuff are Java Server apps running across a multitude of servers and Java Application Servers, on various operating systems and very diverse hardware.
You knew the job was dangerous when you took it, Fred. -- Superchicken
