Well at least I'm not the only one in my household. But it can be really fun. The past week has been a great example of this.
For our 4th anniversary last month, my wife and I bought a 56 gallon freshwater setup. At the time we had a 10 gallon setup and 2.5 gallon that we were using to house babies from our livebearers. (Platy/swordtail hybrids, I think.)
That was about 3 weeks ago.
Today, we have a 46 gallon bow front, a 20 gallon, and another 10 gallon. Plus the 56 gallon and original 10 gallon tank. (Now both my of my daughters have their own 10g freshwater setup, the wife has the 46 g for her community ... mostly she wants a home for more more mollies and a peacock eel, but also probably some angels and a few red-eye tetras.)
The pet store had a sale. We uhm, went a little crazy. (A complete 20G freshwater setup was only $40.)
The 56 gallon display tank (24" tall) got converted to saltwater. This is my first marine tank. I only got it filled up last night. (And let me tell you, at about $5/lb, live rock is expensive. Between live rock, live sand, and water -- 89 cents/gallon, I've already spent about $300, and I've not even put any fish in it yet! That doesn't include the tank and equipment of course.) The setup is going to be a FOWLR (fish-only with live rock) tank.
To really get the full picture though, you need to picture me standing out in the cold wind and rain, in wet jeans, barefoot, hosing the 56 gallon out to make sure I've flushed out any freshwater bacteria properly. I must be half nuts. But Debbie came out and helped me, so I'm not the only one.
What is really cool is that my wife has had as much fun with this as I have. I am fortunate indeed to be married to a woman who enjoys so many of the same things I do.
Now we just need to wait.... and wait... and wait.... (New salt water tanks need to "cycle" for about 3-4 weeks before adding fish.)
Monday, February 4, 2008
Friday, January 25, 2008
Brussels putback
This post discusses the 2nd flag-day putback yesterday, which is Brussels (phase I). Brussels also changes the way NIC drivers are administered, but it is focused on simplifying and centralizing the administration of network driver tunables -- these are the values used to tune the device itself, or in some cases, the link layer properties. The most common of these tunables are the values associated with duplex and link speed settings.
Historically these values have been configured with ndd(1M) or driver.conf(4). Many people know how I feel about those methods, but let me just reiterate: "ndd must die!" (And driver.conf, as well.)
The Brussels putback represents another opportunity for community members interested in kernel programming though. A lot of these NIC drivers need to be converted to use the property access methods that Brussels offers, and have the ndd support ioctls removed. (And yes, I strongly desire to see the ndd(1M) ioctl support removed from drivers. A follow-on phase for Brussels will offer ndd compatibility at the Brussels layer.)
Brussels provided a conversion of bge(7d), but many other NIC drivers remain. I plan on converting my two drivers, afe(7d) and mxfe(7d), as well as a few drivers that are still closed source (iprb(7d) and rtls(7d)). But there remain many others. And conversion of a driver to support Brussels is just the sort of bite-sized task that is great for learning how to develop in the kernel. Some possible drivers to convert are sfe(7d), rge(7d), and nge(7d). If you're interested in working on one of those, let me know (you need the hardware, though!)
Historically these values have been configured with ndd(1M) or driver.conf(4). Many people know how I feel about those methods, but let me just reiterate: "ndd must die!" (And driver.conf, as well.)
The Brussels putback represents another opportunity for community members interested in kernel programming though. A lot of these NIC drivers need to be converted to use the property access methods that Brussels offers, and have the ndd support ioctls removed. (And yes, I strongly desire to see the ndd(1M) ioctl support removed from drivers. A follow-on phase for Brussels will offer ndd compatibility at the Brussels layer.)
Brussels provided a conversion of bge(7d), but many other NIC drivers remain. I plan on converting my two drivers, afe(7d) and mxfe(7d), as well as a few drivers that are still closed source (iprb(7d) and rtls(7d)). But there remain many others. And conversion of a driver to support Brussels is just the sort of bite-sized task that is great for learning how to develop in the kernel. Some possible drivers to convert are sfe(7d), rge(7d), and nge(7d). If you're interested in working on one of those, let me know (you need the hardware, though!)
Clearview/UV putback
Folks watching Nevada putbacks will have noticed at least 3 flag days in the past 24 hours. I want to take a second to talk about the first of them. (I'll talk about the second in a follow up post.)
The first, Clearview/UV, is about providing GLDv3-like features to legacy NIC drivers, and about providing friendlier names to device drivers. I will confess that I've not had a chance to play with any of these features yet, but I think that they are likely to be one of the more important putbacks to OpenSolaris this year. This putback fundamentally changes network administration by offering the ability to use "logical naming" for network device drivers.
The other important thing here is that some folks may believe that the Nemo Unification offered by Clearview/UV means that those legacy drivers don't need to be converted. This is not true. Conversion to GLDv3 still offers significant and tangible benefits to network device drivers:
Folks that want help with such a conversion should contact me.
The first, Clearview/UV, is about providing GLDv3-like features to legacy NIC drivers, and about providing friendlier names to device drivers. I will confess that I've not had a chance to play with any of these features yet, but I think that they are likely to be one of the more important putbacks to OpenSolaris this year. This putback fundamentally changes network administration by offering the ability to use "logical naming" for network device drivers.
The other important thing here is that some folks may believe that the Nemo Unification offered by Clearview/UV means that those legacy drivers don't need to be converted. This is not true. Conversion to GLDv3 still offers significant and tangible benefits to network device drivers:
- Performance. The translation layer that Clearview provides adds a performance hit for legacy drivers. Its also the case that legacy NIC drivers are unable to benefit from several of the performance benefits that GLDv3 offered (direct function calls, mblk chaining, etc.)
- Full VLAN support. Legacy drivers that don't support the undocumented VLAN features aren't able to offer full size VLAN frames. VLANs still work, but you have to shrink your MTU by 4 bytes.
- Certain upcoming GLDv3/Crossbow features. Legacy drivers won't be able to take advantage of upcoming features in GLDv3 from Crossbow. These include various interrupt mitigation techniques and multiple hardware ring support.
Folks that want help with such a conversion should contact me.
Wednesday, January 9, 2008
making good on a promise (Velocity Networks == bad)
My former Internet service provider, OChosting, was recently purchased by a much larger company, Velocity Networks.
As part of that acquisition, they moved my e-mail to some more central server. However, they screwed it up really really badly. The DNS MX records for my domain pointed to an old server, but the CNAME I was using for IMAP was pointing to the old one. The helpdesk was completely useless/powerless to fix the DNS records. (As part of this they were transitioning the old systems to a new management system, ala CPanel, as well. The helpdesk people were only able to deal with accounts that had been transitioned.
Finally I told them they'd not only lose my business, but I'd post my negative experiences here if they didn't get someone to help me quickly. That much they did. But ultimately, the promise that DNS records would clear up when caches flushed never materialized. Two weeks later their servers are still giving out incorrect DNS information. I've been able to access my e-mail by manually editing my /etc/hosts file, supplying a workaround IP address. (I have noticed that their IMAP server has gotten significantly slower since the transition as well. It can take up to 2-3 seconds to delete a message sometimes. Typically it takes about 1 second for the IMAP delete to occur. On my other servers IMAP deletes appear to be "instantaneous".) This doesn't work well for my wife though, and I'm fed up with trying to force feed these guys a clue.
I will point out that I was paying these bozos over $20/month for very modest hosting needs, which is 2-3x the typical market rate. And I'd been doing this for about the last 5 years, with nary a service call in the interim.
Anyway, now I'm making good on my original promise to them.
Anyway, I've been able to recover all my old e-mails (at least the ones that didn't bounce, and who knows how many of those occured!), and I've given my business to Bluehost as of about two days ago. So far, it seems to be going quite well. My e-mail performance seems to be good, and the software they have deployed for CPanel is a bit more sensible as well. (For one, they seem to understand the problem of matching TLS/SSL certificates to hostnames when used for IMAP or SMTP.) I'm also paying $7.95 a month (full year paid in advance) instead of $19.95, and my disk and throughput quotas are much much higher (not that I need them).
I would strongly urge folks considering ISPs to avoid Velocity Networks or any of their affiliates if at all possible. My experience is that they are clueless, and their helpdesk staff are completely hobbled by a combination of restrictions on what they can perform and their own lack of ability.
A big kudos to Bluehost, as well.
As part of that acquisition, they moved my e-mail to some more central server. However, they screwed it up really really badly. The DNS MX records for my domain pointed to an old server, but the CNAME I was using for IMAP was pointing to the old one. The helpdesk was completely useless/powerless to fix the DNS records. (As part of this they were transitioning the old systems to a new management system, ala CPanel, as well. The helpdesk people were only able to deal with accounts that had been transitioned.
Finally I told them they'd not only lose my business, but I'd post my negative experiences here if they didn't get someone to help me quickly. That much they did. But ultimately, the promise that DNS records would clear up when caches flushed never materialized. Two weeks later their servers are still giving out incorrect DNS information. I've been able to access my e-mail by manually editing my /etc/hosts file, supplying a workaround IP address. (I have noticed that their IMAP server has gotten significantly slower since the transition as well. It can take up to 2-3 seconds to delete a message sometimes. Typically it takes about 1 second for the IMAP delete to occur. On my other servers IMAP deletes appear to be "instantaneous".) This doesn't work well for my wife though, and I'm fed up with trying to force feed these guys a clue.
I will point out that I was paying these bozos over $20/month for very modest hosting needs, which is 2-3x the typical market rate. And I'd been doing this for about the last 5 years, with nary a service call in the interim.
Anyway, now I'm making good on my original promise to them.
Anyway, I've been able to recover all my old e-mails (at least the ones that didn't bounce, and who knows how many of those occured!), and I've given my business to Bluehost as of about two days ago. So far, it seems to be going quite well. My e-mail performance seems to be good, and the software they have deployed for CPanel is a bit more sensible as well. (For one, they seem to understand the problem of matching TLS/SSL certificates to hostnames when used for IMAP or SMTP.) I'm also paying $7.95 a month (full year paid in advance) instead of $19.95, and my disk and throughput quotas are much much higher (not that I need them).
I would strongly urge folks considering ISPs to avoid Velocity Networks or any of their affiliates if at all possible. My experience is that they are clueless, and their helpdesk staff are completely hobbled by a combination of restrictions on what they can perform and their own lack of ability.
A big kudos to Bluehost, as well.
Sunday, December 2, 2007
live upgrade rocks
Trying to build the latest tree, I ran into the problem that my build machine is downrev (its b74.) So I had to update to 77 to get the latest tree to build.
For any other OS, or in past days for Solaris, this would be a major crisis, incurring numerous hours of downtime. (Or I could use bfu.) But I decided to finally try out live upgrade.
I had an ISO image of b77 stored on a local zfs filesystem (along with all my critical data). When I had installed this system, I had set it up with a spare empty slice matching the / slice in size, in anticipation of one day trying out live upgrade. Boy am I glad I did.
All I had to do was a few commands:
# lucreate -n b77 -m /:/dev/dsk/c1t0d0s3:ufs
(Wait about 20 minutes.)
# lofiadm -a /data/isos/sol-nv-b77-sx86.iso
# mount -F hsfs -o ro /dev/lofi/1 /mnt
# luupgrade -u -n b77 -s /mnt
(Wait another 20-30 minutes.)
# luactivate b77
# init 6
(That last step confused me. I tried "reboot" a few times, before I actually read the output from luactivate to realize that you CANNOT USE REBOOT.)
All in all, the total downtime was the cost of a single reboot. (Well, several in my case, but that's because I didn't follow the instructions and used the wrong reboot command. Doh!)
Total time to upgrade took less time than it took to download the iso in the first place. Using lofi and zfs made this even more painless. Yay. And now I'll never be afraid to upgrade Solaris again. Had this been Windows or Linux I was trying to upgrade, I'd probably have had to kiss off the entire weekend dealing with fallout, etc.
A big kudos to the LU team. (And shame on me for not discovering this cool technology in Solaris earlier... its been around since Solaris 10u1, at least.)
For any other OS, or in past days for Solaris, this would be a major crisis, incurring numerous hours of downtime. (Or I could use bfu.) But I decided to finally try out live upgrade.
I had an ISO image of b77 stored on a local zfs filesystem (along with all my critical data). When I had installed this system, I had set it up with a spare empty slice matching the / slice in size, in anticipation of one day trying out live upgrade. Boy am I glad I did.
All I had to do was a few commands:
# lucreate -n b77 -m /:/dev/dsk/c1t0d0s3:ufs
(Wait about 20 minutes.)
# lofiadm -a /data/isos/sol-nv-b77-sx86.iso
# mount -F hsfs -o ro /dev/lofi/1 /mnt
# luupgrade -u -n b77 -s /mnt
(Wait another 20-30 minutes.)
# luactivate b77
# init 6
(That last step confused me. I tried "reboot" a few times, before I actually read the output from luactivate to realize that you CANNOT USE REBOOT.)
All in all, the total downtime was the cost of a single reboot. (Well, several in my case, but that's because I didn't follow the instructions and used the wrong reboot command. Doh!)
Total time to upgrade took less time than it took to download the iso in the first place. Using lofi and zfs made this even more painless. Yay. And now I'll never be afraid to upgrade Solaris again. Had this been Windows or Linux I was trying to upgrade, I'd probably have had to kiss off the entire weekend dealing with fallout, etc.
A big kudos to the LU team. (And shame on me for not discovering this cool technology in Solaris earlier... its been around since Solaris 10u1, at least.)
Subscribe to:
Posts (Atom)