Off On A Tangent

Archive for April, 2006

26 Apr

Wow! He looks kinda Hot!

As I get my mail today full of junk, a new Wired magazine with Al Gore in the front page winks at me. The man looks good in that shot.  Then I can help but wonder, what is he doing to deserve to be the main star on this edition of Wired?  So I am now forced to read the article while Mike tells me I am not paying attention to what has been going on with this dude and that he had a beard at some point. I am clueless about the world and I must be loosing my mind by thinking Al looks cute.

19 Apr

Going For Gold

Several months ago, I came to the gut-level conclusion that the markets (stock market, that is) were in real danger of collapsing in the fairly near-term future - as in anytime in the next 2 years.  I came to this belief from several angles - such as :

  • Soaring national debt and the pyramid scheme of Asian lending and investing in America it’s based on
  • The overall weakening trend of the dollar and the possibility of a very steep fall due either to a global switch to some other currency for oil sales or from a withdrawal of Asian funding
  • Rising oil prices due to possibly peak oil + demand from Asian outstripping production
  • Rising damages from natural causes due to an unstable climate (ie flooding, storms, rising sea levels, forest fires, etc)
  • Successful terrorist attacks against vulnerable oil supply bottlenecks like refineries in Saudi Arabia.
  • And lately, the possibility of a US/Israel attack on Iran - something I hadn’t even considered possible back when I made my conclusions

Now note, my conclusion isn’t that “the markets are going to collapse”, but rather “the risk of collapse is greater than the potential gains” in the next few years, IMO.  I think that in 2-3 years time, the energy situation and some of the political situations will be clearer - for better or worse.

Not coincidentally, I was, at this time, rolling over two 401k accounts into an IRA, and trying to decide how to invest the money.  My natural inclination was to dive into stock market research and start investing normally.  But, I kept seeing risk everywhere.  The market was risky mainly because of the rising debt, rising oil prices that threatened to curtail future growth that could have offset that debt.  Bonds were risky because interest rates will rise under those conditions, which means bond values will fall.  A money market seems safe, but not if the dollar tanks, which seems likely.  Then your 4% quickly falls short of the inflation that results.  Gold seemed like the safest bet, so I put my money into two different gold select mutual funds.

One of the funds has quickly gained 20% in the two months since I joined.  Afterward, I found out gold has been on a tear basically since 2003.  And it’s still going, just hitting new 25-year highs today.  Which might lead some to think it’s a good time to get out.  But get out to what?  All the above conditions still apply.  This getting out of the market, and getting out of dollars (ie, money markets) still looks like a good idea, and gold, and hard assets in general, seem like the best investment to hold value in the next couple years.

Today I read an article that showed the stock market if it were measured against gold instead of against dollars.  In other words, if our currency were still backed by gold, the markets might have looked like the graphs shown there - ie, in decline since 2000.  No rebound in 2003 happened compared to gold.

So, I’m staying in gold for the time being, and waiting to see what happens.

12 Apr

Coinjema Features

Coinjema needs to be able to merge dependencies in addition to simply overriding them. For instance, if context A has a property file, and context A/B also has that same property file, then objects created in context A/B get the properties defined in the A/B property file. It overrides the property file from A completely. Often that’s what you want for most dependencies, but property files are a special beast, and I’ve found I usually want all the properties from A plus the properties from A/B - ie I want the property files merged, with specific properties from A/B to overwrite just the specific properties from A.

I also need it to be able to resolve all kinds of circular dependencies. Right now it does a good job of resolving most, but if you mix dynamic dependencies with static, you can run into trouble. You can also run into trouble if you access a shared dependency from a groovy script file using registry.getSharedDep(), because this also goes outside the “safe” flow of dependency resolution. I’ve looked at this and it appears to be an extremely thorny problem. If Java supported continuations, it’s possible I could solve it that way. Of course, it that’s true, then there’s a way to solve it, I just have to implement my own continuations.

I’m going to need lifecycle control eventually. Doing initialization in the final dependency injection is just not good - causes too many problems. There needs to be a way to re-enter a routine to check for lifecycle needs after dependencies have been set and after the object is fully created, but before it is returned to the caller. Another tough problem. It means coinjema will have to keep track of all the objects it configured in any particular stack, and then go back through them and check for lifecycle needs.

11 Apr

Immigration and Social Security

I used to believe the common (mis)perception that Social Security was doomed from the start due to its “pay-as-you-go” nature. The argument being that since current earners are always paying current retirees, and since people are living longer and longer while having fewer and fewer children, it just stands to reason that eventually the burden of supporting too many retirees by too few workers will break the system.

This argument suffers from three problems. First, and least important, extrapolating current trends is nearly always an error. Counter-acting forces usually crop up that bring the trend to an end, or even reverse it. In this case, there is most likely a maximum ratio of retirees to workers that would be very difficult to exceed.

Of course, the limit of this ratio could still conceivably be high enough to break Social Security. The second problem is that the argument ignores productivity increases. As productivity increases, it means fewer workers can accomplish the same work, which essentially means the same overall wealth can, in fact, be generated by fewer and fewer workers. For this reason, Social Security could remain solvent indefinitely if productivity keeps pace with the ratio.

The third problem with the argument, and its implicit conclusion that Social Security could work if only it had been set up as an individual retirement savings scheme, whereby each generation saves and invests money for its own retirement, is that whether the money is being drawn from current workers’ incomes or from stock market pension plans, the value of that money can only be supported by the efforts of current workers. In other words, if the ratio gets too high for the workforce to keep up, then the value of the stock market either crashes, or loses ground to rampant inflation. Whether you’re getting your money from income tax or from capital gains, you’re dependent on the current workforce producing enough to support the entire population - workers and retirees alike. Individual savings accounts is no solution to the problem.

Productivity increase is the only real solution to allowing people to retire in the future. And if productivity doesn’t keep up, then retirees will be forced back out of retirement, either by hardship, or by salaries so high they can’t refuse.

But what’s that have to do with immigration? IMO, it’d be ideal if there were no immigration quotas, and anyone who wanted to, could come to the US, work for a few years, and become a citizen. I see only two obstacles to that ideal: entitlement programs, whereby the working force supports non-workers, new immigrants included (think education, medicare, medicaid, social security, welfare, etc); and the basic ability of our economy to absorb new workers.

If we allow infinite immigration but keep all our entitlement programs, it could become impossible to keep up with the costs, as people come here and go on welfare until they can find a job, send their kids to schools, and wind up in the emergency rooms without health insurance. One can limit the entitlements that green card holders are entitled to, but we seem to have already decided, as a society, that there are some entitlements we are unwilling to withhold.

Of course, if the economy could absorb and employ infinite numbers of new workers each year, there’d be no problem, as everyone would have a job and the increase in the tax base and in the wealth produced would solve all the problems with the entitlements. But I know the economy can’t do that, though I’m not sure what it can absorb, exactly.

Even if everyone who comes doesn’t immediately get a job, our system can support some number of jobless immigrants. If we had fewer entitlements, that number would be greater. And the more immigrants come that eventually find jobs, the greater would be our resources to fund the entitlement programs.

Including Social Security.

I hope my point is clear: limit immigration at your own future economic risk. I do feel allowing as much immigration as possible is a moral issue, in addition to being an economically beneficial one. I think there are entitlements we would be better off without - education could be greatly trimmed, welfare could be phased out I think (I’m ignoring all other wasteful gov spending, such as much of the military and corporate welfare as being irrelevant to the issue of immigration). And if doing so allows more poverty-stricken people to come to the US and find new lives, I think there’s a good moral argument for doing so. But even though moral arguments are rarely persuasive, I’m not sure why the basic economic argument isn’t.

11 Apr

What a Jini Needs

The Java Browser will not be a web browser written in Java. It will browse a peer-to-peer network of mobile java code and data. It will work like a normal web browser, except that instead of hopping from web page to web page via hyperlinks, users will hop from rich gui app to rich gui app via menus and buttons and commands. It will be the undesktop app, with all the power and flexibility of apps that fully live on your desktop, with all the ease and connectedness of thin-client apps.

To work, several things need to be made possible:

  1. Transparent download and installation of the JRE. One will have to do an initial download and install of the application and a JRE (perhaps with Webstart’s help), but thereafter, keeping up-to-date with the latest JRE should happen automatically. The JRE should be bundled with the app and should be independent of whatever system JRE might be installed elsewhere.
  2. The main container application will be a jini browser that can get proxies from jini services. It will provide a sandbox for jini proxies to run in. The jini proxies will be entrance points to rich apps.
  3. Jar dependencies should be tracked per app (per jini proxy) and cached on individuals machines for frequently used applications. Mobile apps will have to have some way of declaring their dependencies (jars and versions) and the container will have to have some means of finding and downloading (automatically of course) those third-party jars.
  4. Will need custom class loaders to handle the dependency issues to allow multiple code bases to use differing versions of third-party libs.
  5. Mobile code will have to declare their dependencies - not just libs, but JRE dependencies
  6. The container will have to require that all downloaded mobile code be signed.
  7. Security will have to be set up to disallow use of system resources unless the user allows it, and disallow net connections to multiple external ips, unless the user allows it. Preferably, these permissions can be bundled into a few simple-to-understand settings that allow users to grant permissions easily to the apps they like to use.
  8. Would be nice if the container could require that any downloaded code is either open source and comes with the source for inspection, or licensed, such that the creator of the mobile code has bought and paid for a license to use the jini web.

© 2010 Off On A Tangent | Entries (RSS) and Comments (RSS)

Your Index Web Directorywordpress logo