The Market Ticker
Commentary on The Capital Markets- Category [Musings]

Really, it's not that important to get there 30 seconds faster.... especially when you might not get there at all!  (Fast-forward to about 1 minute in)

(H/t here)

View this entry with comments (registration required to post)
 

Oh cry me a river.

"Here I'm not going to name the senior person, but I was meeting with someone… This person told me that the Chinese had received a message from the Russians which was, 'Hey let's join together and sell Fannie and Freddie securities on the market.' The Chinese weren't going to do that but again, it just, it just drove home to me how vulnerable I felt until we had put Fannie and Freddie into conservatorship [the rescue plan for them, that was eventually put in place]."

So what?

Let's first assume Paulson is not lying, and if he won't name the person he might be.  It's pretty hard to refute a claim that some ghost said something, right?

But let's just go with that for a minute: By what right does anyone have to bitch if someone who buys something wishes to sell it, irrespective of terms, absent a contractual obligation not to do so?

In other words if you wanted to "prevent" such a "Bear Raid" the only legitimate way to do it is to not sell them the instrument in the first place, which is your right because you're the seller.

But having profited from the price support that having more demand (that is, buyers) for said issue at the outset, you accept with that demand and thus price support risk -- specifically, the risk that you might get cornholed down the road if you allow a concentration of those securities to go places where someone might do something like this.

Further, need I remind anyone of the rather clear disclaimer on the front of these securities?

Was it really all that difficult to parse those words?

**** you Hanky Panky for trying to play off geopolitical events many years down the road.  

Anyone who buys into the crap you're running here is bereft of cognitive ability.

View this entry with comments (registration required to post)
 

2014-03-17 09:18 by Karl Denninger
in Musings , 204 references
 

Way back when I used to write computer code more-or-less as the only thing I did to make money.  Over the last few years I've still written my fair share of it -- the software that runs this place, called "AKCS", is a third (or is it fourth?) generation version of computer-based messaging/conferencing that grew out of an original BBS package I wrote more than 30 years ago.

MCSNet ran on a somewhat-customized version of FreeBSD, enabling me to do things that weren't easy (or possible) at the time with the base code where it was.  Nowdays most of that (virtualization, etc) are all considered "standard" -- back then, not so much.

A couple of weeks ago I decided to move the system here from FreeBSD 9.2 to FreeBSD 10.  There were a couple of reasons to do it, most having to do with filesystem support.  The build and upgrade on my test system (yes, I keep a piece of hardware around that I can try things on and if I blow it up I don't curse all that much) went well.

So did the installation on the real machine -- for a bit.

There has always been an annoying part of the ZFS filesystem code on FreeBSD.  ZFS has a number of  very nice capabilities that other file storage paradigms do not.  It can take nearly-instantaneous snapshots, which means you can go back in time easily to retrieve something you damage or accidentally remove.  That same capability makes keeping backups up to date quite easy as well, and if you have to restore the backup (if it's to a disk) is directly mountable, which is no small consideration.  

It supports transparent compression, including in later versions LZ4, which is very fast.  For an operating system partition or typical user files this can double the effective space you have available.  Of course it doesn't do any good for things like media files (which are already compressed.)

And finally, it checksums every block on the disk when written and read -- allowing it to transparently detect and correct errors well beyond the usual RAID means of doing this with hardware or software.

The latter requires some explanation -- all disks have an error rate.  That is, there's a risk of them losing something -- just a tiny bit of something.  The larger the disk(s) the greater the risk because there's more data there.  We didn't used to worry about that so much in the consumer world, but as data set sizes grow into the terabytes (and beyond) it becomes a bigger and bigger problem, especially when you're using something like a database where one bad bit somewhere can render the data set unusable.  RAID can detect a bad block but then you are reliant on the other copy being ok, and what's worse is that if you suffer a second error during the rebuild you're utterly screwed.  Strategies to get around this get complex and fraught with even more risk rather quickly.

In addition ZFS allows transparent growth of a data set; if you are running out of room and can plug in more disks you can tell the system to use them for storage and the space you have magically gets larger.  That's really nice -- being able to grow the system's storage size without taking it down first or copy what could be terabytes of data around is a pretty big deal too.

But, the ZFS implementation on FreeBSD had a problem that has bugged me for a while -- it did some really annoying things with memory allocation.  Specifically it would slam the memory on the system under certain conditions to the point that the machine would slow way down, and refuse to release some of its cache memory until free space got critically low.

I dug into this a few days ago and discovered what was going on -- and fixed it.  The patch has been sent up to the FreeBSD folks (hopefully they'll want to include it); whether it shows up in the distribution or not, however, that problem is now resolved here and the intended "automatic" tuning of buffering space is working as designed.

So all is well, right?

Uh, no.

It appears that somewhere between 9.2 and 10.0 a bug crept into the NAT code.  NAT is what allows you to have an "inside" set of computers that are effectively "firewalled" from the Internet at large.  Unfortunately this bug appears to be a memory leak in the kernel space, which has the annoying impact of slowly exhausting all of the free system memory.  If nobody that has hacked on that part of the code pipes up first I'll probably take that one on next.

Fortunately there's a workaround for that bit of trouble in that an older, user-space NAT system remains available.

So why write on this stuff at all?

No reason, really, other than as a little musing for a Monday.  A personal note, if you will, in that I'm doing more of what I just plain like and less of what had become less enjoyable -- and more of a "job."

If you're running ZFS on FreeBSD from 9.x forward you can find the patch here -- and you probably want it.  Read the patch as it allows run-time tuning of desired free RAM, which is a fairly significant improvement; you formerly had to reboot to change the maximum allocation as it was not run-time tunable.  (Yes, the patch is "reversed" -- I had not had enough coffee when keyed in the command to generate it.  It's good as it is, just let patch apply it reversed and all is well.)

View this entry with comments (registration required to post)
 

Main Navigation
Full-Text Search & Archives
Archive Access
Get Adobe Flash player
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be reproduced or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media or for commercial use.

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.