Mac OS X includes a feature called Apple System Restore. You can access it through Disk Utility and use it to create an image of a partition or a whole disk, and replicate that image to another partition or whole disk - even over a network. There's also a command-line version in/usr/sbin/asr. I think Mac OS X Server will even let you NetBoot a system on your network and have it automatically restore its local disk from an ASR image.
I have not done this, but I assume you'd be able to set up a system exactly as you want it to be set up - with both Mac OS X and Windows partitions - and create an ASR image from that, which you can then restore and use at will.
If there's something that's particularly hairy in your existing codebase, the next time you need to modify it, spend just a little time refactoring it first so you can make your modification more easily. You don't need to do a six-month rewrite, just a little bit of refactoring to remove local duplication and confusion. And remember this about refactoring: It's not just about improving the design of existing code by making careful transformations of it, it's about rigorous removal of duplication.
Write unit tests for the code you're refactoring immediately before you do so, in order to verify that your refactoring isn't actually changing the functionality. In other words, if you're extracting a method Foo::ExtractedMethod from the method Foo::BigMethod, start by writing a couple unit tests for Foo::BigMethod and verify that they pass. Then write a unit test for Foo::ExtractedMethod and watch it fail (because you haven't done the extraction yet). Then actually perform the extraction.
Once you've added a new feature, don't consider it completed until you've done another small round of refactoring to remove any duplication that adding the feature introduced to your codebase. Do the same thing as above, writing unit tests for any code that you're refactoring that doesn't have any yet, and ensuring that your new feature's tests all continue to pass. After a few feature additions your codebase should actually start getting cleaner and your test coverage should go way up.
Another tip: Try not to have interface-layer (View in MVC termonology) code do too much work. Try to keep the application's business logic in the Model layer and its interaction logic as much as possible in the Controller layer. This will make it much easier to write unit tests; your View layer will be very thin and mostly serve as a wiring-up of your Controller layer to various human interface widgets. The end result is that you can then write a test to validate that entering one value here and another value there doesn't invalidate your assumptions simply by tickling the appropriate Controller-layer code, rather than by trying to "fill in" text fields and "push buttons" via test code.
If you currently have a lot of logic built into your human interface widgets, those are prime candidates for refactoring the next time you need to touch them (or notice they contain some duplication relative to the code that you're currently touching).
And as others have said, check out the Extreme Programming mailing list at Yahoo! Groups. It's a great list with a lot of great people who are very willing to answer questions and help any way they can.
Conference of the year? Ha!
on
GnomeDex 3.0
·
· Score: 1
Gnomedex is fun and all, but if any developer thinks it's the "conference of the year" they need to get out more.
Check out MacHack. MacHack is the conference Gnomedex desperately wishes it could be. Just ask Eric Raymond.
The Macintosh has had a "real hacker culture" since its release in 1984. Similarly, NeXT has had a "real hacker culture" since the release of the original NeXT Computer in 1989.
If you don't believe me, check out MacHack. Check out the thousands of products being created by small developers on VersionTracker. Check out the number of Mac OS X-related projects on SourceForge. Check out the community on the Mac OS and Mac OS X developer mailing lists, among developers with both Mac OS and NeXT backgrounds.
Don't assume that just because it's not in your face and it's not identical to the Unix hacker culture you're used to that it doesn't exist.
Get a tape drive and Retrospect from Dantz. If you only have one NT server, you can get Retrospect Workgroup; otherwise, you'll need Retrospect Server. You install the client software on each workstation or server you want to back up, and install the server software on the machine with the tape drive. Then you just activate all the clients, create a couple backup scripts, and change the tape every night before you leave. All this is really simple to administer because Retrospect was originally designed and written for the Macintosh. It's also fairly inexpensive, at least compared to (a) the cost of your time trying to roll your own backup solution and (b) the other backup systems on the market (which are often harder to administer and less functional).
Retrospect can easily be configured to yell at users that haven't been backed up in a certain amount of time, to either back up their entire machine or just a part of it, etc. You'll still have to get users to leave their computers on, but that'll be the extent of it.
I prefer whole-machine backups; everywhere I've used Retrospect, that's what we've done. Retrospect is smart, so it won't back up 10 copies of an identical file just because each one is on a different computer. And Retrospect also does incremental backups out of the box, so you're only backing up what changed *and* you can restore a machine to exactly the state it was at at the time of any given backup.
Sorry for the commercial, but I've been using Retrospect for my own network for 6 years now and have done work for shops that use it for 9, and I have yet to see a better backup solution.
Amory Lovins, along with Paul Hawken and Hunter Lovins, wrote a book a couple years ago called Natural Capitalism. Read it. It'll change the way you think about renewable energy and efficiency.
The central thesis of the book is that while getting incremental improvements in resource/energy efficiency may be expensive, radical improvement that comes from leveraging synergies within a system can often be more cost-effective than the status quo. Companies and individuals who realize this will profit significantly in the 21st century.
Read the book. Even if you disagree with it, you'll learn a lot about systems thinking and optimization. And maybe even wind up saving a few bucks (and a few barrels) down the line.
Not only does GIMP have Photoshop for competition on the Macintosh, it will also be competing with tools like TIFFany3 from Caffeine Software.
It should be good for innovation, though the results of the competition between the three may surprise some GIMP advocates.
(Hint: User-centered design is paramount on the Macintosh. Focus on what users want and need and how they work with their tools if you want to gain any share.)
...but as Unix originally derived its strength from treating everything as a file, doesn't it now make sense to create a software environment in which everything is an object?
There have been environments where everything is an object for decades.
Lisp machines were essentially objects all the way down. (For loads of fun, read up on Symbolics and their Genera operating system & development environment).
Smalltalk-76 and beyond were also objects all the way down. Check out Squeak; it's a modern implementation of Smalltalk-80.
The nice thing about Smalltalk and modern Lisp systems is that it isn't just the human interface that's object-oriented; everything about them is object-oriented. It's very powerful, particularly when combined with the fact that most of these systems also have their source code available.
Say you suddenly need to be able to reverse strings. In many Smalltalk systems, you just add an instance method named 'reverse' to the String class. Bam! Now you can send the #reverse message to any instance of String and it will be reversed. If you implement it correctly (relying on the public interface to String rather than any private implementation details) you can even send #reverse to any subclasses. And all without taking down a running system. This is a trivial example; you could do the same kind of tricks with the scheduler and the file system in a Smalltalk-based operating system.
I guess my point here is that you probably shouldn't give these "Athena" guys too much credit; instead, look at Common Lisp and Smalltalk systems for truly pioneering work in object-oriented systems.
I strongly suggest checking out WebObjcts (at www.webobjects.com). It's what Dell used to create their online store before Microsoft developed a replacement in ASP as a showcase for their mediocre technology. There are thousands of other companies large and small using WebObjects to build web applications for both internal and external use.
The big advantage of WebObjects over systems like the ArsDigita Community System, PHP, ASP, and JSP is that it provides nice layers of abstraction. You never have to write SQL (if you don't want to) to get database-backed persistence for your business objects. Your application logic is separate from your business logic which is separate from your presentation logic. It also has nice graphical tools for doing entity-relationship modeling and laying out your dynamic pages and so on.
There are also some great third-party add-ons available for doing things like electronic comerce, wireless access (e.g. WAP), PDF report generation, etc. There is even a large, dynamic developer community.
Of course, WebObjects is a commercial solution, not an Open Source one, but it's a good solution and it's relatively inexpensive considering its capabilities.
Email me if you'd like more information; my company does web application development with WebObjects.
My company recently submitted Macintosh support to the Vorbis project; they're in the CVS tree as of sometime earlier tonight.
I did most of the initial work at MacHack this June, and I finally found the time to clean it up and contribute it to the project.
If you have a CVS client and CodeWarrior Pro 5.3 you can build the Vorbis CODEC shared library, the WAV encoder example, and the raw PCM audio decoder example and use them on the Macintosh. It's not a complete, do-everything QuickTime CODEC, but it's a start.
Many thanks to Christopher Montgomery for giving such a cool gift to the world.
"getattr" and "setattr" are the API; they shouldn't be that difficult to emulate on Linux.
As for the "how do we cp/mv/tar the whole file" issue, cp, mv, tar, and such tools could just iterate over all of the file's attributes while doing their thing.
Another idea would be to add a "copy file" system call to the kernel. I think this would be a great idea; it wouldn't just handle attributes properly, but copying from one folder on a server to another on the same server could be more intelligent and not actually send the bits through the client at all.
Really, adding a little bit of abstraction to the kernel would not be a bad thing...
I've seen a bunch of followups asking me "What's your problem?!"
(Of course, this being Slashdot, it was in much less polite terms.)
I ask you to read my message again. Where the hell do I say it's bad that it's not Open Source? I don't actually give a damn! I think it's great that the source is being released, however it's being released.
I just care that the term "Open Source" is being misapplied to something that doesn't meet the Open Source Definition. I don't think it's due to malice, I don't think it's evil, I just think it's a linguistic bug that we should all be more conscious of.
If a product's source code is available but you have to pay a royalty for particular uses, it's not Open Source. (See Section 1 of the Open Source Definition.) Rather, it's source-available software. A lot of Sun software is like this now, for instance, including Java and Solaris.
Companies should be applauded for making their source code available, but making source code for a product available and making a product Open Source still need to be treated as different things.
How long did you develop for the Macintosh? What did you try to write? How much time did you spend learning the system, and how much depth did you go into?
Just because it's different than what you're used to doesn't make the Macintosh operating system any less "real."
Also, to say that there's no way applications can run as well on MacOS as they can on other platforms is patently false. As with writing any software, it's a matter of using the appropriate tools during your development. When you were working on a Mac application, did you bother to find out what tools were available to help your debugging? Did you use Jasik Designs' "The Debugger"? Did you try Onyx's QC and Spotlight (a memory debugger like Purify but easy to use and 1/10 the price)? Did you actually ask Mac developers for help with problems you encountered on Usenet, IRC, or mailing lists? Did you read the tech notes on Apple's web site? Did you join an Apple developer program and use a support incident with Developer Technical Support? Or did you just throw up your hands when you encountered difficulties and shout "Macs are crashy and hard to program so our code will crash, too bad! MAC SUX D00DZ!!111"
I see the latter happen a lot among PC coders who're tasked with writing Mac software. It'd be far better for everyone involved if companies that decide they want to support the Macintosh just hire real Macintosh developers such as myself to do the work.
Apple's Darwin operating system -- the kernel and utility layer of Mac OS X -- is Open Source.
Therefore, if you want to know how Apple's hardware works, download the Darwin source code and read it!
The Darwin source code might even have helpful comments about working around hardware bugs and the like. Very useful for people implementing support for other operating systems.
So what's the problem? That this information is not all codified in a Hardware Reference Manual? That would cost money, probably at least $100K-$200K per machine. Can you prove it will sell $200K-$400K more hardware -- net, not gross! -- for Apple to put together such a manual rather than just continue to make the details available through their Darwin source code? If so, I bet you could convince Apple to do it.
Be's failure, I think, was that they didn't have this kind of business case when they went to Apple and demanded a nice, complete hardware reference manual.
Ameritech has had unlimited personal local calling for as long as I can remember. I believe there's a 5 cent connect charge within band A (anybody whose CO is within 8 miles of yours), and that's it.
There's also cheap cable modem and/or xDSL service everywhere now (my T1-speed cable modem is $40/month), companies in the area pay well, the cost of living is reasonable even in affluent suburbs like Schaumburg and Hoffman Estates and Palatine (all near Motorola), there's lots of big high-tech companies...
Don't knock Chicago for high tech. As a resident, the Silicon Prairie plan really seems to be working. The biggest problem I have with the area is the lack of coffeeshops that are open late at night.
(PS - Contact me if you're interested in doing Mac/Windows development in the Chicago suburbs...)
Sounds like what NeXT has been doing with NetInfo for years. It's a distributed configuration database. Between NetInfo (for centrally-administered machine configuration information) and the NSUserDefaults mechanism (for end-user configuration information) you could implement roaming support pretty easily.
NetInfo is part of Apple's Darwin and thus Open Source now. I believe someone's even ported it to Linux.
Does GTK+/GNOME support interface resources like MacOS, Windows, OPENSTEP/GNUstep, etc. do? In other words, can I define most of my interface without writing code that says "place a button here, place another button here, create a toolbar, put this button and this button in the toolbar..."
Anyone who says Macs aren't for geeks should go to MacHack next year. (Alternative OS developers -- including Linux developers -- are welcome there too.) You would not believe the creative energy there is among Mac developers.
Just because we don't like using command lines, makefiles, emacs, etc. doesn't mean we're any less geeks. We just have different tool and environment preferences.
Oh, please. Have you actually read the PDF 1.3 specification? You can download it for free from Adobe's web site; that seems pretty open to me.
You can have JPEG-compressed images in PDF documents already. As for "PNG compression", there's no such thing. If you're talking about Flate, PDF 1.3 supports that too.
PDF and PostScript -- at least as of versions 1.3 and Level 3 (respectively) -- both support Flate compression in addition to LZW, RLE (PackBits), CCITT Group 3 Fax, and CCITT Group 4 Fax.
Nothing in PostScript or PDF requires you to compress your images (or other data) at all. Learn a little bit about these technologies before getting all freaked out. The documentation is all on Adobe's "partners" web site.
Slashdot Mirror
Mac OS X includes a feature called Apple System Restore. You can access it through Disk Utility and use it to create an image of a partition or a whole disk, and replicate that image to another partition or whole disk - even over a network. There's also a command-line version in /usr/sbin/asr. I think Mac OS X Server will even let you NetBoot a system on your network and have it automatically restore its local disk from an ASR image.
I have not done this, but I assume you'd be able to set up a system exactly as you want it to be set up - with both Mac OS X and Windows partitions - and create an ASR image from that, which you can then restore and use at will.
Not true.
You have to turn it on using the info window for your project if you want it to happen automatically. It's a performance thing.
Otherwise, to invoke completion -- in any Cocoa text view, not just the Xcode editor -- you just hit option-escape.
Actually, MousePaint was a port of LisaPaint.
//c as well, in 1985 or 1986 I think, and I also happen to own a used Apple Lisa 2/10.)
Look at the title bar of the window, and the items in the menu bar, and then look at some screen shots of the Apple Lisa.
The giveaways: The File menu is called "File/Print" and the stripes in the window title bar are vertical, not horizontal as on the Mac.
(My first mouse was for my Apple
If there's something that's particularly hairy in your existing codebase, the next time you need to modify it, spend just a little time refactoring it first so you can make your modification more easily. You don't need to do a six-month rewrite, just a little bit of refactoring to remove local duplication and confusion. And remember this about refactoring: It's not just about improving the design of existing code by making careful transformations of it, it's about rigorous removal of duplication.
Write unit tests for the code you're refactoring immediately before you do so, in order to verify that your refactoring isn't actually changing the functionality. In other words, if you're extracting a method Foo::ExtractedMethod from the method Foo::BigMethod, start by writing a couple unit tests for Foo::BigMethod and verify that they pass. Then write a unit test for Foo::ExtractedMethod and watch it fail (because you haven't done the extraction yet). Then actually perform the extraction.
Once you've added a new feature, don't consider it completed until you've done another small round of refactoring to remove any duplication that adding the feature introduced to your codebase. Do the same thing as above, writing unit tests for any code that you're refactoring that doesn't have any yet, and ensuring that your new feature's tests all continue to pass. After a few feature additions your codebase should actually start getting cleaner and your test coverage should go way up.
Another tip: Try not to have interface-layer (View in MVC termonology) code do too much work. Try to keep the application's business logic in the Model layer and its interaction logic as much as possible in the Controller layer. This will make it much easier to write unit tests; your View layer will be very thin and mostly serve as a wiring-up of your Controller layer to various human interface widgets. The end result is that you can then write a test to validate that entering one value here and another value there doesn't invalidate your assumptions simply by tickling the appropriate Controller-layer code, rather than by trying to "fill in" text fields and "push buttons" via test code.
If you currently have a lot of logic built into your human interface widgets, those are prime candidates for refactoring the next time you need to touch them (or notice they contain some duplication relative to the code that you're currently touching).
And as others have said, check out the Extreme Programming mailing list at Yahoo! Groups. It's a great list with a lot of great people who are very willing to answer questions and help any way they can.
Gnomedex is fun and all, but if any developer thinks it's the "conference of the year" they need to get out more.
Check out MacHack. MacHack is the conference Gnomedex desperately wishes it could be. Just ask Eric Raymond.
The Macintosh has had a "real hacker culture" since its release in 1984. Similarly, NeXT has had a "real hacker culture" since the release of the original NeXT Computer in 1989.
If you don't believe me, check out MacHack. Check out the thousands of products being created by small developers on VersionTracker. Check out the number of Mac OS X-related projects on SourceForge. Check out the community on the Mac OS and Mac OS X developer mailing lists, among developers with both Mac OS and NeXT backgrounds.
Don't assume that just because it's not in your face and it's not identical to the Unix hacker culture you're used to that it doesn't exist.
Get a tape drive and Retrospect from Dantz. If you only have one NT server, you can get Retrospect Workgroup; otherwise, you'll need Retrospect Server. You install the client software on each workstation or server you want to back up, and install the server software on the machine with the tape drive. Then you just activate all the clients, create a couple backup scripts, and change the tape every night before you leave. All this is really simple to administer because Retrospect was originally designed and written for the Macintosh. It's also fairly inexpensive, at least compared to (a) the cost of your time trying to roll your own backup solution and (b) the other backup systems on the market (which are often harder to administer and less functional).
Retrospect can easily be configured to yell at users that haven't been backed up in a certain amount of time, to either back up their entire machine or just a part of it, etc. You'll still have to get users to leave their computers on, but that'll be the extent of it.
I prefer whole-machine backups; everywhere I've used Retrospect, that's what we've done. Retrospect is smart, so it won't back up 10 copies of an identical file just because each one is on a different computer. And Retrospect also does incremental backups out of the box, so you're only backing up what changed *and* you can restore a machine to exactly the state it was at at the time of any given backup.
Sorry for the commercial, but I've been using Retrospect for my own network for 6 years now and have done work for shops that use it for 9, and I have yet to see a better backup solution.
The central thesis of the book is that while getting incremental improvements in resource/energy efficiency may be expensive, radical improvement that comes from leveraging synergies within a system can often be more cost-effective than the status quo. Companies and individuals who realize this will profit significantly in the 21st century.
Read the book. Even if you disagree with it, you'll learn a lot about systems thinking and optimization. And maybe even wind up saving a few bucks (and a few barrels) down the line.
-- Chris
It should be good for innovation, though the results of the competition between the three may surprise some GIMP advocates.
(Hint: User-centered design is paramount on the Macintosh. Focus on what users want and need and how they work with their tools if you want to gain any share.)
--
Chris Hanson
bDistributed.com, Inc.
There have been environments where everything is an object for decades.
Lisp machines were essentially objects all the way down. (For loads of fun, read up on Symbolics and their Genera operating system & development environment).
Smalltalk-76 and beyond were also objects all the way down. Check out Squeak; it's a modern implementation of Smalltalk-80.
The nice thing about Smalltalk and modern Lisp systems is that it isn't just the human interface that's object-oriented; everything about them is object-oriented. It's very powerful, particularly when combined with the fact that most of these systems also have their source code available.
Say you suddenly need to be able to reverse strings. In many Smalltalk systems, you just add an instance method named 'reverse' to the String class. Bam! Now you can send the #reverse message to any instance of String and it will be reversed. If you implement it correctly (relying on the public interface to String rather than any private implementation details) you can even send #reverse to any subclasses. And all without taking down a running system. This is a trivial example; you could do the same kind of tricks with the scheduler and the file system in a Smalltalk-based operating system.
I guess my point here is that you probably shouldn't give these "Athena" guys too much credit; instead, look at Common Lisp and Smalltalk systems for truly pioneering work in object-oriented systems.
--
Christopher M. Hanson
President
The big advantage of WebObjects over systems like the ArsDigita Community System, PHP, ASP, and JSP is that it provides nice layers of abstraction. You never have to write SQL (if you don't want to) to get database-backed persistence for your business objects. Your application logic is separate from your business logic which is separate from your presentation logic. It also has nice graphical tools for doing entity-relationship modeling and laying out your dynamic pages and so on.
There are also some great third-party add-ons available for doing things like electronic comerce, wireless access (e.g. WAP), PDF report generation, etc. There is even a large, dynamic developer community.
Of course, WebObjects is a commercial solution, not an Open Source one, but it's a good solution and it's relatively inexpensive considering its capabilities.
Email me if you'd like more information; my company does web application development with WebObjects.
--
Christopher M. Hanson
President
My company recently submitted Macintosh support to the Vorbis project; they're in the CVS tree as of sometime earlier tonight.
I did most of the initial work at MacHack this June, and I finally found the time to clean it up and contribute it to the project.
If you have a CVS client and CodeWarrior Pro 5.3 you can build the Vorbis CODEC shared library, the WAV encoder example, and the raw PCM audio decoder example and use them on the Macintosh. It's not a complete, do-everything QuickTime CODEC, but it's a start.
Many thanks to Christopher Montgomery for giving such a cool gift to the world.
--
Christopher M. Hanson
President
As for the "how do we cp/mv/tar the whole file" issue, cp, mv, tar, and such tools could just iterate over all of the file's attributes while doing their thing.
Another idea would be to add a "copy file" system call to the kernel. I think this would be a great idea; it wouldn't just handle attributes properly, but copying from one folder on a server to another on the same server could be more intelligent and not actually send the bits through the client at all.
Really, adding a little bit of abstraction to the kernel would not be a bad thing...
I'm pretty sure it has happened.
(Of course, this being Slashdot, it was in much less polite terms.)
I ask you to read my message again. Where the hell do I say it's bad that it's not Open Source? I don't actually give a damn! I think it's great that the source is being released, however it's being released.
I just care that the term "Open Source" is being misapplied to something that doesn't meet the Open Source Definition. I don't think it's due to malice, I don't think it's evil, I just think it's a linguistic bug that we should all be more conscious of.
Companies should be applauded for making their source code available, but making source code for a product available and making a product Open Source still need to be treated as different things.
Just because it's different than what you're used to doesn't make the Macintosh operating system any less "real."
Also, to say that there's no way applications can run as well on MacOS as they can on other platforms is patently false. As with writing any software, it's a matter of using the appropriate tools during your development. When you were working on a Mac application, did you bother to find out what tools were available to help your debugging? Did you use Jasik Designs' "The Debugger"? Did you try Onyx's QC and Spotlight (a memory debugger like Purify but easy to use and 1/10 the price)? Did you actually ask Mac developers for help with problems you encountered on Usenet, IRC, or mailing lists? Did you read the tech notes on Apple's web site? Did you join an Apple developer program and use a support incident with Developer Technical Support? Or did you just throw up your hands when you encountered difficulties and shout "Macs are crashy and hard to program so our code will crash, too bad! MAC SUX D00DZ!!111"
I see the latter happen a lot among PC coders who're tasked with writing Mac software. It'd be far better for everyone involved if companies that decide they want to support the Macintosh just hire real Macintosh developers such as myself to do the work.
Actually, the NanoKernel has existed as long as the PowerPC-based Macs.
Therefore, if you want to know how Apple's hardware works, download the Darwin source code and read it!
The Darwin source code might even have helpful comments about working around hardware bugs and the like. Very useful for people implementing support for other operating systems.
So what's the problem? That this information is not all codified in a Hardware Reference Manual? That would cost money, probably at least $100K-$200K per machine. Can you prove it will sell $200K-$400K more hardware -- net, not gross! -- for Apple to put together such a manual rather than just continue to make the details available through their Darwin source code? If so, I bet you could convince Apple to do it.
Be's failure, I think, was that they didn't have this kind of business case when they went to Apple and demanded a nice, complete hardware reference manual.
There's also cheap cable modem and/or xDSL service everywhere now (my T1-speed cable modem is $40/month), companies in the area pay well, the cost of living is reasonable even in affluent suburbs like Schaumburg and Hoffman Estates and Palatine (all near Motorola), there's lots of big high-tech companies...
Don't knock Chicago for high tech. As a resident, the Silicon Prairie plan really seems to be working. The biggest problem I have with the area is the lack of coffeeshops that are open late at night.
(PS - Contact me if you're interested in doing Mac/Windows development in the Chicago suburbs...)
NetInfo is part of Apple's Darwin and thus Open Source now. I believe someone's even ported it to Linux.
Does GTK+/GNOME support interface resources like MacOS, Windows, OPENSTEP/GNUstep, etc. do? In other words, can I define most of my interface without writing code that says "place a button here, place another button here, create a toolbar, put this button and this button in the toolbar..."
Just because we don't like using command lines, makefiles, emacs, etc. doesn't mean we're any less geeks. We just have different tool and environment preferences.
You can have JPEG-compressed images in PDF documents already. As for "PNG compression", there's no such thing. If you're talking about Flate, PDF 1.3 supports that too.
Nothing in PostScript or PDF requires you to compress your images (or other data) at all. Learn a little bit about these technologies before getting all freaked out. The documentation is all on Adobe's "partners" web site.