One of my story fans is trying to send me a pic of herself. She doesn't
know much about computers and I know nothing about Macs. She's tried to
send me her pic twice. The first time it was 120 K and the second time
it was 220 K. In each case the final extension was .SIT even though she
thought she was creating a JPG. The last file name is
Melanie02.jpg.SIT
I wonder if anyone knows what is happening and how my friend can send me
her pic in JPG format from a Mac??
Thanks in advance for your help.
--
It's Me! Katie McN
<ka...@katie-mcnNOSPAM.com>
Read My Stories at:
www.katie-mcn.com
> Hi Mac Fans!
>
> One of my story fans is trying to send me a pic of herself. She doesn't
> know much about computers and I know nothing about Macs. She's tried to
> send me her pic twice. The first time it was 120 K and the second time
> it was 220 K. In each case the final extension was .SIT even though she
> thought she was creating a JPG. The last file name is
> Melanie02.jpg.SIT
The .sit files are Mac "StuffIt" files, like the .zip extension
for ZIP files. You might want to try
http://www.stuffit.com/expander/
they seem to have a free expander for Windows.
I have never dealt with these files under Windows; we used to have
a Mac in my previous job that we used solely for un-stuffing and
similar stupid jobs. I'm afraid I never cared much for the Mac
environment myself...
Hope this helps,
A.
------------------------------
http://www.asstr.org/~altan/
------------------------------
>> One of my story fans is trying to send me a pic of herself. She doesn't
>> know much about computers and I know nothing about Macs. She's tried to
>> send me her pic twice. The first time it was 120 K and the second time
>> it was 220 K. In each case the final extension was .SIT even though she
>> thought she was creating a JPG. The last file name is Melanie02.jpg.SIT
>
> The .sit files are Mac "StuffIt" files, like the .zip extension for ZIP
> files. You might want to try
> http://www.stuffit.com/expander/
> they seem to have a free expander for Windows.
The expander worked for windows a few years ago. I used to use it but
haven't in several years while I was supporting MACs.
She might take a look at the options in her email client and see if
there's something about compressing attachments. It sounds like a
default is set that needs to be unset.
If all else fails, she could get a web accessable email address and send
it that way. Juno, mail.com and others come to mind. Or, her own if she
can access it via a browser.
HTH
--
http://storiesonline.net/Stasya_T_Canine
no logins, no ads, no banners, no cookies--no other annoyances
Free, text, thanks to Lazeez at http://storiesonline.net
General audience furry stories: http://www.furnation.com/Nikkolai
As someone has already mentioned, the .sit ending indicates it was
compressed using StuffIt. It thought WinZip 8.x worked with that, but maybe
not.
The compression is not required for her to email you the pic. I don't
recall any of the email proggies I used on my old Mac compressing anything
into .sit. Course, I used Netscape Navigator/Communicator, so I dunno.
Ask her not to compress it. If she really wants to, ask her to use .zip.
It probably is either an option, or she can easily dl a .zip program.
Garylian
>On Fri, 21 Feb 2003 21:16:24 GMT, Katie McN <ka...@katie-mcnNOSPAM.com> wrote:
>
>> Hi Mac Fans!
>>
>> One of my story fans is trying to send me a pic of herself. She doesn't
>> know much about computers and I know nothing about Macs. She's tried to
>> send me her pic twice. The first time it was 120 K and the second time
>> it was 220 K. In each case the final extension was .SIT even though she
>> thought she was creating a JPG. The last file name is
>> Melanie02.jpg.SIT
>
>The .sit files are Mac "StuffIt" files, like the .zip extension
>for ZIP files. You might want to try
> http://www.stuffit.com/expander/
>they seem to have a free expander for Windows.
>
>I have never dealt with these files under Windows; we used to have
>a Mac in my previous job that we used solely for un-stuffing and
>similar stupid jobs. I'm afraid I never cared much for the Mac
>environment myself...
>
I downloaded the program and was able to extract the files it contained.
In case anyone wants to see Melanie's pictures and doesn't mind looking
at nudies, you can view them on my website at www.katie-mcn.com
There is a link to the pictures as the last entry on my home page.
If anyone has comments, I'll pass them along to the author if you send
them to me. I already commented to her about my favorite part of
melanie01.jpg ;-)
>On Fri, 21 Feb 2003 16:32:36 -0800, Altan wrote:
>
>>> One of my story fans is trying to send me a pic of herself. She doesn't
>>> know much about computers and I know nothing about Macs. She's tried to
>>> send me her pic twice. The first time it was 120 K and the second time
>>> it was 220 K. In each case the final extension was .SIT even though she
>>> thought she was creating a JPG. The last file name is Melanie02.jpg.SIT
>>
>> The .sit files are Mac "StuffIt" files, like the .zip extension for ZIP
>> files. You might want to try
>> http://www.stuffit.com/expander/
>> they seem to have a free expander for Windows.
>
>The expander worked for windows a few years ago. I used to use it but
>haven't in several years while I was supporting MACs.
>
>She might take a look at the options in her email client and see if
>there's something about compressing attachments. It sounds like a
>default is set that needs to be unset.
>
>If all else fails, she could get a web accessable email address and send
>it that way. Juno, mail.com and others come to mind. Or, her own if she
>can access it via a browser.
>
>HTH
Thanks for your help. Stuffit worked fine and the results are posted on
my website www.katie-mcn.com
She's using one of the large UK ISPs and I get binaries from that domain
all the time. I suspect that someone set up the process for her and she
is following it rote. She is limited in her knowledge of computers. Now
that I have the right program I can work with her files just fine. ;-)
Now that I have Stuffit on my system I see that ZIP is indeed an option
for the program. I kind of like stuffit since it also handles gz, tar
and other compression types from Unix and Linux in an easier way that
what I go through with the other programs I use so this has proved
beneficial in more ways than one.
melanie01.jpg looks just like someone I wish I knew.
cmsix
Yes, I understand what you mean. I didn't realize that Stuffit handled the gz.
I love gnu's stuff, because being able to tar and zip the file at the same time
is the best. Nothing like a little "gtar czvf <files> <tarfile name> to make
your day when you need to. Instead of having to create a full duplicate, you can
compress as you go!
Most of my Unix customers were floored when they found out about that trick. If
you aren't familiar, give me an email, and I will show you how it works. Though,
knowing you, you could probably show ME a few tricks with it!
Garylian
I have a comment. Yummers. Let her know that if she ever decides to try
the sex alternative, I'm available. Well, okay, probably not. I mean, that
would be rude. But still, yummers. More seriously, both pieces (no pun
intended) of art are great. I'm impressed.
Conjugate
She has a bunch more self portraits and I think she'll want me to put a
bunch of them on my website once she sees how much people like them. ;-)
> If anyone has comments, I'll pass them along to the author if you send
> them to me. I already commented to her about my favorite part of
> melanie01.jpg ;-)
Fun! I like both pictures. I do have a technical comment on
melanie02.jpg: it would work better if it would be saved as a
.gif instead of a .jpg file. The JPEG format is not well suited
for images with solid colors, resulting in ugly artifacts. This
image would probably compress well with GIF compression as well.
That is actually:
gtar czvf file.tgz files/directories ...
And extraction is
gtar xzvvf file.tgz
You can also cheat:
gtar czf - file-or-directory-list \
| ssh -l myself another.system.elsewhere 'cd /wherever ; tar xzvvf -'
Mind you, I'm a "tar" guy going well back though I've started to like
what find and cpio can do for me...
--
Jack C Lipton | cupa...@softhome.net | http://www.asstr.org/~CupaSoup/
"A life devoid of challenge hasn't been lived in yet." - me
GIF is encumbered by patents own by UnisSys, basically in the
Lempel-Ziv compression algorithm (which also screws with the
original "compress" utility); Unisys wants you to pay a license
to *create* a GIF...
I'm not sure how .PNG works out, though.
>Altan wrote:
>> Katie McN wrote:
>>> If anyone has comments, I'll pass them along to the author if you
>>> send them to me. I already commented to her about my favorite part
>>> of melanie01.jpg ;-)
>>
>> Fun! I like both pictures. I do have a technical comment on
>> melanie02.jpg: it would work better if it would be saved as a
>> .gif instead of a .jpg file. The JPEG format is not well suited
>> for images with solid colors, resulting in ugly artifacts. This
>> image would probably compress well with GIF compression as well.
>
>GIF is encumbered by patents own by UnisSys, basically in the
>Lempel-Ziv compression algorithm (which also screws with the
>original "compress" utility); Unisys wants you to pay a license
>to *create* a GIF...
Just use one of the apps which paid the license. Also, while jpeg
has its limitations, tweaking the encoder can help reduce artifacts.
Ulead's jpeg smart saver is pretty good at letting you play around
with the options (same with its GIF saver).
>I'm not sure how .PNG works out, though.
Similar file size and image quality, with more options. Only issue
is whether the browser supports it without a plugin. PNG beats out
GIF in the things that it does which GIF doesn't support -- it is a
more flexible format. GIF is so commonly used on the net, though,
that despite the licensing issues it remains in almost universal use.
--
Jeff
Web site at http://www.asstr.org/~jeffzephyr/
For FTP, ftp://ftp.asstr.org/pub/Authors/jeffzephyr/
There is nothing more important than petting the cat.
>On Sat, 22 Feb 2003 03:33:03 GMT, Katie McN <ka...@katie-mcnNOSPAM.com> wrote:
>
[ . . . ]
>Fun! I like both pictures. I do have a technical comment on
>melanie02.jpg: it would work better if it would be saved as a
>gif instead of a .jpg file. The JPEG format is not well suited
>for images with solid colors, resulting in ugly artifacts. This
>image would probably compress well with GIF compression as well.
>
Thanks for the tip. I noticed this myself and think that the color of
the letters also comes into play here. I'll pass your thoughts to
Melanie. She uses Photoshop so I have no idea how she adds the
lettering. I use Fireworks and set "no anti-aliasing" and try to stick
with basic web friendly colors for this type of picture which seems to
result in solid letters in JPG or GIF format.
As far as the patent on GIF goes, doesn't this end in the next year? In
any event I noticed that Unisys got a lot of bad publicity when they
said they might decide to enforce the patent and haven't seen them bring
anyone to court or other indications they are being aggressive in
protecting it. There are many reasons that Unisys is a niche player in
the computer industry and this is just one example of the bad decisions
they've made over the years.
In any event, the GIF format is not a problem for me. I would love to
tell the world that big bad Unisys was picking on a little West Texas
porn monger-ette. ;-)
>Altan wrote:
>> Katie McN wrote:
>>> If anyone has comments, I'll pass them along to the author if you
>>> send them to me. I already commented to her about my favorite part
>>> of melanie01.jpg ;-)
>>
>> Fun! I like both pictures. I do have a technical comment on
>> melanie02.jpg: it would work better if it would be saved as a
>> .gif instead of a .jpg file. The JPEG format is not well suited
>> for images with solid colors, resulting in ugly artifacts. This
>> image would probably compress well with GIF compression as well.
>
>GIF is encumbered by patents own by UnisSys, basically in the
>Lempel-Ziv compression algorithm (which also screws with the
>original "compress" utility); Unisys wants you to pay a license
>to *create* a GIF...
>
>I'm not sure how .PNG works out, though.
She uses Photoshop for Mac and I have no idea what it can do. She did
indicate that she could create files in GIF and it was my idea that she
use JPG. Neither one of us was considering the patent Unisys has on some
part of GIF. If I receive a letter from their attorneys, I will remove
any GIF files from my website and then post the letter everywhere I can
think of on the net to make sure people know how they spend their time.
;-)
BTW have you heard of any recent lawsuits filed by Unisys related to
their GIF patent?
I wouldn't mind if people who know about PNG comment on what Jack
mentions here and also how to optimize the size of the file. I use
Fireworks and it's basic format is PNG. I've never tried to have a
browser render a PNG graphic since PNG seems to produce a substantially
larger graphics that either the JPG or GIF files it exports. I'm
guessing it's a matter of me not knowing what I'm doing as usual.
You don't have to worry about the patents unless you create your
own GIF encoder or decoder. I'm sure that is not what you are
about to do (although it is a fun thing to do, not that hard at
all, and very instructive... done it twice and enjoyed it).
Almost all graphics tools suppport GIF, and do so with a licence
agreement with Unisys. The only one I know of that is different is
Gimp, which is free (and hence they can't pay royalty fees). The
GIF support for Gimp can be downloaded separately from a country
where the Unisys patent does not apply. It is strongly suggested
not to download that plug-in unless you either have a site license
from Unisys, or live in a place where the patent does not apply.
I guess that gets the developers off the hook.
> BTW have you heard of any recent lawsuits filed by Unisys related to
> their GIF patent?
Doesn't the patent expire sometime this year?
> I wouldn't mind if people who know about PNG comment on what Jack
> mentions here and also how to optimize the size of the file. I use
> Fireworks and it's basic format is PNG. I've never tried to have a
> browser render a PNG graphic since PNG seems to produce a substantially
> larger graphics that either the JPG or GIF files it exports. I'm
> guessing it's a matter of me not knowing what I'm doing as usual.
PNG is designed as the free alternative to GIF. It was intended
first of all as a Web format, echnically better than GIF (more
colors supported, better support of transparency and such). The
problem is that older browsers may not support PNG, or may not
support some features of PNG (e.g. the option of partial
transparency, which is very exciting if you want to use anti-aliasing
and still have your graphic blend with the background).
Whether or not to use PNG depends on your target audience. If
you have a site that uses Macromedia Flash and has high bandwidth
requirements, or if you rely heavilly on stylesheets and stuff,
or require a minimum browser version, PNG might be for you. Most
graphics tools nowadays support it. If you have a site directed at
a general audience, I wouldn't rely on PNG yet. But that is just my
gut feeling; I don't exactly know which browsers support PNG.
Thanks Altan. I appreciate you taking the time to provide the details.
Good clarifications and you gave me some new ideas.
Thanks
MK
***********************
On Sat, 22 Feb 2003 22:00:01 GMT I noticed your interesting post:
--
> Hi Altan <alt...@bigfoot.com>,
>
> On Sat, 22 Feb 2003 13:16:31 GMT I noticed your interesting post:
>
>>On Sat, 22 Feb 2003 03:33:03 GMT, Katie McN <ka...@katie-mcnNOSPAM.com> wrote:
>>
> [ . . . ]
>>Fun! I like both pictures. I do have a technical comment on
>>melanie02.jpg: it would work better if it would be saved as a
>>gif instead of a .jpg file. The JPEG format is not well suited
>>for images with solid colors, resulting in ugly artifacts. This
>>image would probably compress well with GIF compression as well.
>>
>
> Thanks for the tip. I noticed this myself and think that the color of
> the letters also comes into play here. I'll pass your thoughts to
> Melanie. She uses Photoshop so I have no idea how she adds the
> lettering. I use Fireworks and set "no anti-aliasing" and try to stick
> with basic web friendly colors for this type of picture which seems to
> result in solid letters in JPG or GIF format.
It has to do with they way the JPG format works. Roughly speaking,
JPG divides the picture in blocks and saves the "average" color for
the block. It then checks to see if that average is close enough for
all pixels in the block. If not, it subdivides the block into smaller
ones and repeats the process. This whole thing stops when the
desired compression level is reached. So if you use solid colors,
you are bound to get "artifacts," even though they may be small
(one pixel or so) at low compression levels (large file sizes).
This is why JPEG is better for photo-type images, where you don't
see small differences, and GIF gives better results with comic-type
images, line drawings and such, where you have large areas of a
single color and every litter disturbance shows up.
> As far as the patent on GIF goes, doesn't this end in the next year? In
> any event I noticed that Unisys got a lot of bad publicity when they
> said they might decide to enforce the patent and haven't seen them bring
> anyone to court or other indications they are being aggressive in
> protecting it.
As far as I know, they declared that only the encoder software
(which creates the GIF) needs to license their technology. I
understand that all the major graphics software companies pay
these license fees.
> There are many reasons that Unisys is a niche player in
> the computer industry and this is just one example of the bad decisions
> they've made over the years.
They just don't get it, do they? It is not as if they put a lot
of research into creating this technology, it just happened to
come with some stuff they bought.
And now I heard there were some questions about PNG as well,
that that may infringe on patents as well. Reminds me of
Grisham novels, lawyers out to make a buck...
:-(
> In any event, the GIF format is not a problem for me. I would love to
> tell the world that big bad Unisys was picking on a little West Texas
> porn monger-ette. ;-)
Oh, wouldn't that just be great :-)
Hubba-hubba. Want some candy, little girl?
Gary Jordan
"Old submariners never die; they just wallow in sunken tubs."
<I>"This communicating of a man's self to his friend works two contrary
effects, for it redoubleth joys, and cutteth griefs in half." - Francis Bacon,
Essays </I>
>Mind you, I'm a "tar" guy going well back
Just a jolly Jack Tar, huh?
--
-denny (curmudgeon)
"I'm full of good answers--sometimes it's the question that's wrong."
Miss Behavin'
I have actually referred to:
tar cvf ...
as tarring and
tar xvf ...
as feathering.
*SIGH*
A life! Where can I download one?
How about RLE BMP? That would also work with large regions of solid colors.
Conjugate
can throw around the TLAs too, ya know!
Here's a question for the experts at large. Once, back in The Deeps of Time
(TM), the GIF format was owned entirely by Compu$erve (if memory serves, or
$erves). Now, C$ went belly-up an ćon ago, but presumably its intellectual
properties were grabbed onto by various creditors. If so, wouldn't somebody
own the patent, or copyright, or whatever it is, to the whole GIF format
(and not just Unisys's claim on some chunk of the compression algorithm)?
Or not?
Conjugate
dimly remembers stuff like this
My understanding (meaning that I'm probably wrong) is that Unisys
(once known as Sperry and before that Sperry-UNIVAC) patented the
Lempel-Ziv compression algorithm before GIF was invented but that
GIF was wrapped around the Lempel-Ziv compression algorithm for the
various layers. Unlike JPEG, GIF is "lossless" so the original picture
(well, assuming 256 colors) is completely recoverable. (The 256 color
limit wasn't so bad 16 years ago but it's pretty awful now, eh?)
It's a standard who's time has come... ...and gone. Nowadays the
ability to animate a GIF is the whole reason it's popular for those
advertisements you see on web pages these days. (BTW, I found a nice
little animated .GIF that I now use on my index page, the "Any Damn
Browser" icon. Grab a copy if you use primitive HTML structures like
I do.)
If I remember right, Compuserve dropped the GIF spec into the public
domain, but the compression remains licensed. Using a different
compression on GIF wouldn't help, because the viewers have to
incorporate support for the original format, and most of the existing
tools which used the format were grandfathered in with licenses.
256 color remains perfectly fine, given that video cards generally
don't support palettes above that. For photos, they aren't so hot,
but for structured art they remain just fine. Note that you are
limited to 256 colors per picture, but if your viewer is smart, it can
handle many pictures, each with their own set of colors. Some
browsers in the past *weren't* so smart though.
>It's a standard who's time has come... ...and gone. Nowadays the
>ability to animate a GIF is the whole reason it's popular for those
>advertisements you see on web pages these days. (BTW, I found a nice
>little animated .GIF that I now use on my index page, the "Any Damn
>Browser" icon. Grab a copy if you use primitive HTML structures like
>I do.)
GIF is still fine for any structured line art sorts of things, which
are a *lot* of what is used. Buttons, markers, lots of things work
just fine with it. It also animates nicely, and transparent edges are
possible with it.
PNG is a nice alternative, but not universally supported. It is
pretty well supported now, though, and it offers larger palette sizes
and color depths. Picking it to use on a page means that some viewers
might not see it, but using it is generally going to work out.
find is nice, but usually you need superuser to do it, and when you don't have it, that
kills that idea. cpio is popular, but not good for creating quick archives for ftp
delivery<g>. Also, doesn't cpio vary its commands slightly based on Unix platform? I
mainly have to worry about SCO and AIX.
We usually use 'gtar czvf <filename.tar.gz> ./<files>' or ./directory, since the ./
gives you a relative directory.
To untar, we use 'gtar xzvf <filemame>. What does the 2nd v do?
Garylian
I thought CompuServe was bought out by someone else, and they either
discontinued it, or they themselves went belly up. And I am too tired to do a
Google search right now. (This is what playing Diablo II with the wife most of
the day does to you!)
Garylian
Ah, yes, but I'm the SysAdmin. *I* own root. I'm not sure I could still
cope with a job where all I have are "peasant" accounts. (Of course I'm
not stupid enough to *be* root...)
After all, if you can't be root, re-boot. :-)
> cpio is popular, but not good for creating quick archives for ftp
> delivery<g>. Also, doesn't cpio vary its commands slightly based on Unix
> platform? I mainly have to worry about SCO and AIX.
Yes, I understand that facility. find and cpio *do* vary somewhat but not
all that greatly. Admittedly AIX is the weird one (AIX AIn't uniX, or,
when using X on an AIX box, it's a matter of "AIX 'n Panes", but then I'm
a certified AIX SysAdmin and System Support geek) but it's been about 10
years since I last dealt with SCO (and it sucked pretty bad then).
> We usually use 'gtar czvf <filename.tar.gz> ./<files>' or ./directory,
> since the ./ gives you a relative directory.
Damn straight. I *hate* absolute directories and gtar (and only a few
others) will do it's damndest to convert to a relative format during
the archive creation phase.
> To untar, we use 'gtar xzvf <filemame>. What does the 2nd v do?
I'm a greppie from way back. The second v kicks verbosity enough
so you can see the file sizes and more. The extract phase with one
v only reports the filenames as they are restored whilst a toc
(tzvf) reports a lot more.
Yes, I'm a luddite.
Compu$erve was bought by AOL and, AFAIK, is where AOL tests new
client software. I was also told that the Compu$erve help-desk
responsibility is being transferred back to Tampa from India.
>Denny Wheeler wrote:
>> Jack C Lipton) wrote:
>>
>>>Mind you, I'm a "tar" guy going well back
>>
>> Just a jolly Jack Tar, huh?
>
>I have actually referred to:
>
> tar cvf ...
>
>as tarring and
>
> tar xvf ...
>
>as feathering.
>
>*SIGH*
>
>A life! Where can I download one?
You could try here:
http://www.getalife.com/
(yes, it's really a website)
BMP is not a standard supported Web format, and RLE BMP might
be even less supported.
RLE (Run Length Encoding: for a given color, indicate that the
next n pixels are all the same color) works for large areas of
solid colors, but does not handle other repetitive patterns well.
GIF is based on capturing repetitive information, and is able
to handle long strings of values that repeat.
Compuserv developed the GIF spec and, wisely, put that spec in
the public domain. After all, its goal was to standardize image
formats, which means getting as many people as possible to use
it. I think they got the LZW algorithm from a publication in Byte
or some magazine like that; nobody realized it was patented at
that time. Only when Unisys realized they owned the pattent on
something that was widely used did somebody start to see dollar
signs.
I thought the same was true for the original PKZIP utility, by the
way, but that seems to have been resolved by now. I'm sure WinZip
is not paying license fees to Unisys for each download of the
tool, and anyway, both ZIP and GZIP (free utilities) seem to be
able to handle ZIP files...)
PNG uses different compression techniques that were thought to
be in the public domain as well. I don't know what the status
of that one is.
> Garylian wrote:
> > Jack C Lipton wrote:
> >> Garylian wrote:
> >> > Yes, I understand what you mean. I didn't realize that Stuffit handled the gz.
> >> > I love gnu's stuff, because being able to tar and zip the file at the same time
> >> > is the best. Nothing like a little "gtar czvf <files> <tarfile name> to make
> >> > your day when you need to. Instead of having to create a full duplicate, you can
> >> > compress as you go!
> >>
> >> That is actually:
> >>
> >> gtar czvf file.tgz files/directories ...
> >>
> >> And extraction is
> >>
> >> gtar xzvvf file.tgz
> >>
> >> You can also cheat:
> >>
> >> gtar czf - file-or-directory-list \
> >> | ssh -l myself another.system.elsewhere 'cd /wherever ; tar xzvvf -'
> >>
> >> Mind you, I'm a "tar" guy going well back though I've started to like
> >> what find and cpio can do for me...
> >
> > find is nice, but usually you need superuser to do it, and when you don't
> > have it, that kills that idea.
>
> Ah, yes, but I'm the SysAdmin. *I* own root. I'm not sure I could still
> cope with a job where all I have are "peasant" accounts. (Of course I'm
> not stupid enough to *be* root...)
>
> After all, if you can't be root, re-boot. :-)
Unfortunately, while on my own test boxes, I can be root all I want, some company with
500-1000 stores is not going to allow me, Mr Support Guru, to tie in as a root user. They
will have me give the commands, run it past 4 people, and then maybe try it. lol
> > cpio is popular, but not good for creating quick archives for ftp
> > delivery<g>. Also, doesn't cpio vary its commands slightly based on Unix
> > platform? I mainly have to worry about SCO and AIX.
>
> Yes, I understand that facility. find and cpio *do* vary somewhat but not
> all that greatly. Admittedly AIX is the weird one (AIX AIn't uniX, or,
> when using X on an AIX box, it's a matter of "AIX 'n Panes", but then I'm
> a certified AIX SysAdmin and System Support geek) but it's been about 10
> years since I last dealt with SCO (and it sucked pretty bad then).
It still does, And while AIX 4.3x is pretty darn good, AIX 5.x stinks. They released it
and there was very little backwards compatability. In fact, IBM's own "Tivoli" (spelling
probably wrong) wouldn't work probably on it. One of my good friends worked for IBM's AIX
and Tivoli support desk when they did this. I still don't think anybody is using AIX 5.x.
And yes, SCO still sucks. It is the poor man's Unix, which is why so many of our
customers use it. At least IBM takes care of business.
> > We usually use 'gtar czvf <filename.tar.gz> ./<files>' or ./directory,
> > since the ./ gives you a relative directory.
>
> Damn straight. I *hate* absolute directories and gtar (and only a few
> others) will do it's damndest to convert to a relative format during
> the archive creation phase.
>
> > To untar, we use 'gtar xzvf <filemame>. What does the 2nd v do?
>
> I'm a greppie from way back. The second v kicks verbosity enough
> so you can see the file sizes and more. The extract phase with one
> v only reports the filenames as they are restored whilst a toc
> (tzvf) reports a lot more.
>
> Yes, I'm a luddite.
> --
> Jack C Lipton | cupa...@softhome.net | http://www.asstr.org/~CupaSoup/
> "A life devoid of challenge hasn't been lived in yet." - me
Thanks! I might have to start using that 2nd v. Would make my life a little easier when
I redirect the output and can check file sizes as I go.
Garylian
Whew, I am not going senile. I thought it was AOHell, but I was too tired to
trust it to putting the words onto the internet and prove myself a dumbass once
and for all. (Not that I don't do that on here as a regular thing, but I try to
keep it down.)
Garylian
Yes, I can understand that, though the 60+ machines I support are for S/W
development so the users are mostly shell (ab)users and usually screwing
things up, especially since some need root privs (so I finally rolled out
sudo).
A production environment like that is very different and the deployment
of a procedure usually has to be encapsulated in a script and then run
past QA.
>>> cpio is popular, but not good for creating quick archives for ftp
>>> delivery<g>. Also, doesn't cpio vary its commands slightly based
>>> on Unix platform? I mainly have to worry about SCO and AIX.
>>
>> Yes, I understand that facility. find and cpio *do* vary somewhat but not
>> all that greatly. Admittedly AIX is the weird one (AIX AIn't uniX, or,
>> when using X on an AIX box, it's a matter of "AIX 'n Panes", but then I'm
>> a certified AIX SysAdmin and System Support geek) but it's been about 10
>> years since I last dealt with SCO (and it sucked pretty bad then).
>
> It still does, And while AIX 4.3x is pretty darn good, AIX 5.x stinks.
> They released it and there was very little backwards compatability. In
> fact, IBM's own "Tivoli" (spelling probably wrong) wouldn't work probably
> on it. One of my good friends worked for IBM's AIX and Tivoli support
> desk when they did this. I still don't think anybody is using AIX 5.x.
I've got AIX5L on a couple of sandboxes and (so far) there are few complaints.
I'll have to do some more reading on 5L.
I also heard that 5.2 is dropping MCA and PReP boxes so that'll be a pain.
(I actually have 12 y/o AIX boxes still in use for development. Sheesh.)
> And yes, SCO still sucks. It is the poor man's Unix, which is why so
> many of our customers use it. At least IBM takes care of business.
I used to do porting of Business BASIC itself to the SCO Xenix environment
(286 mostly) and that tended to be entertaining. Ick.
AIX 4.3.3 is supposed to be sunset by the end of the year.
My main complaint is that FIXDIST is pretty much dead for AIX 5L (I didn't
like it all *that* much but the web-based stuff is way too manual for me.
If I have to do something more than once there'd damn well better be a
tool to automate it immediately- just one more reason I don't like GUIs
since you have to fly them at all times, they have no auto-pilot).
>>> We usually use 'gtar czvf <filename.tar.gz> ./<files>' or ./directory,
>>> since the ./ gives you a relative directory.
>>
>> Damn straight. I *hate* absolute directories and gtar (and only a few
>> others) will do it's damndest to convert to a relative format during
>> the archive creation phase.
>>
>>> To untar, we use 'gtar xzvf <filemame>. What does the 2nd v do?
>>
>> I'm a greppie from way back. The second v kicks verbosity enough
>> so you can see the file sizes and more. The extract phase with one
>> v only reports the filenames as they are restored whilst a toc
>> (tzvf) reports a lot more.
>
> Thanks! I might have to start using that 2nd v. Would make my life
> a little easier when I redirect the output and can check file sizes
> as I go.
I've also heard of a Windoze tool named 7zip that's supposed to be
very flexible (a free version of winzip). I burned a GNU-Win-II CD
and I'm still going through it.
Seriously, if you look at my asstr website maintenance script I would
probably hear you laughing at them even if you were in Seattle.
> I thought the same was true for the original PKZIP utility, by the way,
> but that seems to have been resolved by now. I'm sure WinZip is not
> paying license fees to Unisys for each download of the tool, and anyway,
> both ZIP and GZIP (free utilities) seem to be able to handle ZIP
> files...)
Zip and the programs PKZIP and PKUNZIP were released to the public domain
as soon as they were developed.
You may be thinking of ARC and SEA (Seadog Associates). Phil Katz (I
think that's who it was...) wrote the utilities PKARC and PKXARC to handle
ARC files. His utilities were smaller and quicker, too... SEA got upset
and took him to court. They won their lawsuit but Phil won the war by
developing the ZIP format, which was more efficient, and releasing it to
the public domain. In support, almost all of the BBS operators, archivers
and users switched to ZIP. The people who made cds for BBS archives even
put ARC files inside ZIPs in retaliation for SEA's arrogance. The
transition was very quick and as a result ARC as a common archiving tool
pretty much vanished into history in a matter of weeks.
--
http://storiesonline.net/Stasya_T_Canine
no logins, no ads, no banners, no cookies--no other annoyances
Free, text, thanks to Lazeez at http://storiesonline.net
General audience furry stories: http://www.furnation.com/Nikkolai
>On Sun, 23 Feb 2003 07:01:18 -0800, Altan wrote:
>
>
>> I thought the same was true for the original PKZIP utility, by the way,
>> but that seems to have been resolved by now. I'm sure WinZip is not
>> paying license fees to Unisys for each download of the tool, and anyway,
>> both ZIP and GZIP (free utilities) seem to be able to handle ZIP
>> files...)
>
>Zip and the programs PKZIP and PKUNZIP were released to the public domain
>as soon as they were developed.
>
>You may be thinking of ARC and SEA (Seadog Associates). Phil Katz (I
>think that's who it was...) wrote the utilities PKARC and PKXARC to handle
>ARC files. His utilities were smaller and quicker, too... SEA got upset
>and took him to court. They won their lawsuit but Phil won the war by
>developing the ZIP format, which was more efficient, and releasing it to
>the public domain. In support, almost all of the BBS operators, archivers
>and users switched to ZIP. The people who made cds for BBS archives even
>put ARC files inside ZIPs in retaliation for SEA's arrogance. The
>transition was very quick and as a result ARC as a common archiving tool
>pretty much vanished into history in a matter of weeks.
yah, I remember that vanishment. *poof*
>I've also heard of a Windoze tool named 7zip that's supposed to be
>very flexible (a free version of winzip). I burned a GNU-Win-II CD
>and I'm still going through it.
Ultimate Zip (freeware) is good.
>Seriously, if you look at my asstr website maintenance script I would
>probably hear you laughing at them even if you were in Seattle.
He knows about laughter from Seattle, you see....
Not quite; shareware is not quite the same as public domain. I believe both
were available free, but the PKZIP with encryption/password protection and a
few other bells and whistles was not free. But it seems to me that some of
my early copies of PKUNZIP did have copyright notices in them.
> You may be thinking of ARC and SEA (Seadog Associates). Phil Katz (I
> think that's who it was...) wrote the utilities PKARC and PKXARC to handle
> ARC files. His utilities were smaller and quicker, too... SEA got upset
> and took him to court. They won their lawsuit but Phil won the war by
> developing the ZIP format, which was more efficient, and releasing it to
> the public domain. In support, almost all of the BBS operators, archivers
> and users switched to ZIP. The people who made cds for BBS archives even
> put ARC files inside ZIPs in retaliation for SEA's arrogance. The
> transition was very quick and as a result ARC as a common archiving tool
> pretty much vanished into history in a matter of weeks.
Had not heard that; I knew that there were .arc and a few other old-type
compression files around, but didn't know that the arc and unarc utilities
were so strongly protected. I also may still have an old .arj file or two
someplace.
Conjugate
Fan of Huffman compression just because he likes the name