ocschwar: (Default)
Many companies these days have a new policy with regards to contacting liasons at other companies. If you work for Foo Corp and register with Bar Corp because your employer is a Bar Corp client, you're expected to enter your job title in their databases. Then they will some times send email to "Dear Systems Manager", so that if you leave Foo Corp and have your email forwarded to your successor, he will be addressed by his presumed title.

Which is why our office subscription to Linux Journal, which I signed up for, results in emails like this to our accounting team:

Which he then forwarded around the office:

Kept the name on the subscription the same.

Funny receiving emails addressed as such.

-----Original Message-----
From: Linux Journal Services [mailto:LinuxJournalServices@linuxjournalservices.com]
Sent: Friday, December 03, 2010 2:06 PM
To: Account Invoices
Subject: Linux Journal Payment Due

Dear Lord High Executioner,

You should be receiving the January copy of Linux Journal with the next 10 days. We hope that you will enjoy it.

Please take a few moments to pay the balance of $29.50 to continue receiving your monthly copies.

https://www.pubservice.com/subbillpay.aspx[ELIDED]

There's a reason Linux Journal has been the community's most widely read publication since 1994. Besides covering the best of today's tools, Linux Journal covers the most promising new technologies for Linux.

Be among our other readers who benefit from reading Linux Journal. To continue receiving your monthly copy, please visit:
https://www.pubservice.com/subbillpay.aspx?[ELIDED]

Please respond by December 13, 2010.

Thanks,
Your friends at Linux Journal


Linux Journal
2121 Sage Road, Ste 310
Houston, TX 77056

If you do not wish to receive further messages about the status of your Linux Journal subscription,
please click here: http://linuxjournalservices.com/portal/unsubscribe/?V77Dxgls%2FB1CYqUXY4WktE1jXTAD4xQBA

Linux Journal is published by Belltown Media, Inc.
ocschwar: (Default)
I'm wondering, do I know any IT professional among my friends who has not, at least once, fantasized about doing exactly what Julian Assange and the Wikileaks team did?

I know I sure as hell have had that fantasy, for at least 15 years now. Much as I'm dismayed by the damage the Wikileaks revalations will have to the ability of the US government to perform its legitimate functions over the next two years, I know I thought of diving right into that niche. And I'm pretty sure you have too. And... you, dear reader, or yours truly, dear reader, might have been able to do it without the collateral damage that Assange is causing.
ocschwar: (Default)
Having been bitten by LVM2 lately more than I ever care to, I got an idea thanks to a SIPB undergrad who asked the right question at the right time. If instead of merging drives with LVM, you merge filesystems using a variant of UnionFS, you can use the disk space on all the drives, but only lose the data on that drive if it goes *poof*, and not the whole filesystem.

It would be a UnionFS mount over ext3 systems on all the drives. Reads would do the obvious things. Write operations would be a little trickier. Writes on existing files would work on the drive that has them, unless that drive fills up, in which case the whole file gets copied elsewhere and the write proceeds there. File creation operations would get stored in the first member filesystem listed which has space available.

Would not take that much of a mod to UnionFS or AUFS. I'm tempted to make this my first attempt at kernel hacking.
ocschwar: (Default)
Of all the LVM2 command line utilities, only one lets you specify what you want to do by UUID. So say a motherboard dies on you on a Fedora system and you need the data. Well, if you move the drives to another Fedora machine, you now have two volume groups named VolGroup00. The kernel will use the second one for everything. But, when you look at the situation, you'll find both have been fully activated. So when you do "vgrename $UUID $NewName" to clear this up, it will complain that the logical volumes in $UUID are active. But you can't dl "lvchange -an " on them because their name refers to the other volume group. That's where Knoppix comes in.

Still, all that needs to happen is for lvchange to accept UUIDs as arguments. Or, the Fedora install process can start naming the volume groups something like "/dev/$FQDN-VolGroup00".
ocschwar: (Doggie)
I love fantasygoat
So there are contexts where hyperthreading can do more harm than good to your performance. Not all that surprising. But, um, a hyperthreading CPU using the same caches on two threads is in essence a NUMA processor. So programs that make use of it should be written with that sort of thing in mind. That said, how hard would it be to add a backend to GCC so that it scans the executable for dependencies at the machine code level, and splits the instructions between two or more threads, after putting the right threading library calls at the top?

That way each binary could start two threads that will always be trying to deal with the same segments of virtual memory (so no cache misses added unnecessarily), but with the instructions split between two threads, and reordered in compile time rather than run time, the program could be way the hell faster.

Okay, I'm a dilletante. I used to be worse. I was once a premed.
ocschwar: (Doggie)
thanks, fantasygoat
Observing how my mother uses the Internet (AOL keywords and Google; the DNS is dead to her) leads me to be thankful for all the political wrangling and litigation that has gone on about domain names. All that energy from lawyers and politicians directed to where it can do the least harm. No, really. All that energy could have gone into trying to force the taking away of IP address space, or to cut people off by way of routing tables, but didn't. And that's important, because the Internet's topology is more vulnerable than most folks notice, especially as far as transcontinental fiber goes. So much energy went into the contents of one mapping of names to IP addresses, leaving a much freer environment for others to go to, e.g. Google.

That said, if ever a protocol asked to be converted into a peer to peer variant, DNS is it, and I am amazed it isn't already done. A p2p DNS system would be way more robust than relying on your ISP's small list of DNS servers. It would also help make it difficult to employ DNS based censorship, which many countries do have in place.

Moreover, a p2p DNS system, with proper onion routing and freenet-style magic crypto fairy dust would not allow your ISP to keep logs of whether you wanted to go to www.osamashomobortionpotandcommiejizzporium.com.

Best of all, with such a system there would be a ludicrously low barrier to entry by a competing "dot in dotcom." Want to run your own .com registrar? Suck down the zone files you care about, assemble your own database, sign it with your own GPG key, and cast it on the p2p-DNS. If people care for your domain policies more than they care about whoever is running them at the moment, they can switch. But you don't even have to exist in any tangible physical form. People aren't too likely to make the switch unless Network Solutions does something really obnoxious, but the ease at which a competing registrar can move in will keep be a good incentive for NSI not to do it.

I'm imagining in my mind something like Freenet as far as crypto goes, but which uses just an LDAP schema for the domain name queries and the like, so it would not be a practical protocol for disseminating goatse or child porn or Gor novels or anything else people don't want to serve out of their hard drives. It would also not hog bandwidth. (Call it BitTrickle?) And by using LDAP it could easily be readapted for more uses.
ocschwar: (Doggie)
Several people I know have observed that Livejournal looks in many ways like Usenet of 10 years ago. Well, Usenet personality (in the good sense) James Nicoll has an active LJ. So I guess they are right.

Profile

ocschwar: (Default)
ocschwar

April 2017

S M T W T F S
      1
2345678
9101112131415
16171819 202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 27th, 2017 06:46 pm
Powered by Dreamwidth Studios