|
Posted by DoN. Nichols on May 4, 2008, 11:26 pm
Please log in for more thread options > On 3 May 2008 04:16:42 GMT, "DoN. Nichols"
>
><snip>
>>What is a mht file? I'm not familiar with those.
>
> Right-click on a page and choose "Save as" from the menu.
Hmm ... not in the right-click menu on this system (Solaris 10
on UltraSPARC CPUs).
> Now you should have another dialog box with an item called
> "Save as type".
O.K. I can find this in the "File" menu.
> Drop this box down to the item "Web archive
> (single file)". That should default to an ".mht" file
> extension.
So it does -- with a nasty (for unix systems at least), as it
saved by the file name: "D-AND_D.COM web pages.mht" instead of the
preferred "D-AND_D.COM_web_pages.mht". (I don't use spaces in filenames
as they are a pain on the unix command line.) For that matter,
Microsoft has discovered in some of their business/commercial
applications that they are a pain on the command line in Windows, too. :-)
> It is commonly thought of as a Microsoft thing, the whole
> page (html, css, images, js...) will be encoded into one
> file much like a raw email. Try doing this once on a web
> page and then looking at the file created (it will be a text
> file).
So it is -- and a convenient thing to know about. Thanks!
> Opera should be able to open this file and display it
> just like the original web page.
O.K. I blew it away before trying this. :-)
> Note I said should, there
> are some quirks to that method/display in Opera too.
:-)
>
> These files (mht) can also be decoded/extracted by WinZip
> and some other archive programs.
Winzip isn't going to do much on a system running Solaris 10 on
an UltraSPARC CPU. :-)
Any clues as to the others (which would handle the whole thing)?
I could, of course edit it into separate chunks and manually run
mimeencode -u
on it -- giving it my own choice of names if necessary.
> If you look them over they
> are pretty much self explanatory. I think Opera uses Base64
> for the binary items.
I think so.
><snip>
>>> problem when using the "Fit to Width" option.
>>
>> O.K. I think that option is on. I'll try turning it off next
>>time around.
>
> Just be aware that "Fit to Width" can cause some strange
> problems on some pages. Try viewing the page with it off if
> you are having troubles.
O.K. Thanks.
>>> You really should be using 100% for everyday viewing and
>>> only depend upon the zoom feature for special situations...
>>
>> I normally hit the puzzles as the last of a short set of blogs
>>after going through the morning's web comics, which I tend to find more
>>readable at 150% zoom, so that is the default.
>
> I can understand that, Opera's zoom has been a great feature
> ever since I started using it in the late 1990's. But it can
> cause some weird rendering problems. I do most of my
> browsing at 100% and only use zoom here & there.
O.K. While I often have to use zoom to be able to read the
pages (and even then is difficult with one of the dark-blue on black
pages. :-)
Wasn't it you who was curious about how well zfs worked? I've
got another bit of information. I got a newer set of fibre channel
housings (Eurologic) to replace the older EMC/Criiterion ones, and
wanted to migrate the whole pool to the newer drives (same 36GB
capacity, physically smaller) -- without shutting things down, since
both my wife and I depend on those filesystems (nine filesystems on the
pool in question). Well ... I had used the "replace" command to replace
bad drives, so I decided to try something else with it. The original FC
drives were 10-16, and the new ones were 40-46 (thanks to not being quit
sure where the drives would wind up based on the switch settings -- so I
set it high to be sure to clear the old ones).
So -- I did the following:
zpool replace -f fc-p c1t10d0 c1t40d0
(and waited for zpool status to tell me that the one drive was replaced
-- which took a little over an hour). "fc-p" was the name that I had
given the pool, and the c1t10d0 and such were the solaris way of
specifying a drive "controller, target (SCSI-ID), device (always zero
with modern drives), and a following 's' for slice, but this is not
specified to zfs or zpool.
Then after that,
zpool replace -f fc-p c1t11d0 c1t41d0
zpool replace -f fc-p c1t12d0 c1t42d0
zpool replace -f fc-p c1t13d0 c1t43d0
zpool replace -f fc-p c1t14d0 c1t44d0
which moved the active data from the old drives to the new ones, then I
issued the following commands
zpool add spare c1t45d0
zpool add spare c1t46d0
zpool delete spare c1t15d0
zpool delete spare c1t16d0
and the whole thing was migrated to the new drives without interrupting
service at all.
These drives were all 36 GB drives. I now have to try the same
trick moving another pool from 18 GB drives to more of the 36 GB drives.
I know that when there is a mix of sizes, zfs acts as though all drives
are no larger than the smallest one. What I don't know is whether once
the full transfer is made to 36 GB drives it will decide to expand to
the proper space for all 36 GB drives, or whether it will "remember" that
it was started on 18 GB drives and throw away half of each disk.
Needless to say -- I hope that it will expand. But I'm not going to do
this until tonight's backups run.
Enjoy,
DoN.
--
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html --- Black Holes are where God is dividing by zero ---
|
>depending on the size. I wonder what blogspot changed in the wrappers
>of the web page to bring up this sensitivity?