my newest release: BZ Soundboard 0.2. I might put up the source for 0.1 too at some point. the program is explained thoroughly on the webpage.
Domain of the Bored (old blog)
The old personal weblog of Peter Hosey, aka Mac-arena the Bored Zo. The new one is at http://boredzo.org/blog .
the current release version of Troy Stephens's IconFamily class, 0.5.1, uses FSSpec for all I/O. I updated it in July 2005 to use FSRef instead, and also fixed a memory leak and cleaned up a few minor code details. on 2005-07-19, I emailed the patch and a changelog to Troy Stephens.
so far, he has not applied the patch (or at least not put it on his website), nor has he even responded to my email. AFAIK, he simply threw it away (or never received it in the first place). I have the email archived, but I took no further action.
today, a user on IRC msged me and said that he had heard that I had written this, and he asked me for a copy. so I have zipped up the patch and the changelog (removing my ancient, recently-defunct email address from it), and posted it on my website. enjoy the IconFamily FSRef patch.
here's one I ran into while writing BZ Soundboard.
#0 0x9073fba4 in CFRetain () #1 0x92964b60 in _NSKeyValueObservationInfoCreateByRemoving () #2 0x92964938 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] () #3 0x92964828 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] ()
I solved this one on a hunch — that the
NULL being CFRetained (print $r3 in gdb to see the first function argument) was the result of some kind of lookup with the proposed ex-observer as the key. if the ex-observer was not actually observing anything, the lookup would return
NULL, and apparently that result is not checked before it is passed to CFRetain.
executive summary: if you get this crash, it means that you were not actually observing anything (or at least not that key path).
I submitted a new bug: NSFileManager does not accept NSString values for HFS types. it follows, edited only for HTMLification.
The following keys access file attribute values contained in NSDictionary objects used by changeFileAttributes:atPath:, fileAttributesAtPath:traverseLink:, createDirectoryAtPath:attributes:, and createFileAtPath:contents:attributes::
Steps to Reproduce:
/*1*/ NSDictionary *attrs = [NSDictionary dictionaryWithObjectsAndKeys: NSFileTypeForHFSTypeCode('FOO!'), NSFileHFSTypeCode, NSFileTypeForHFSTypeCode('BAR!'), NSFileHFSCreatorCode, nil]; /*2*/ [[NSFileManager defaultManager] createFileAtPath:@"strings are our friends.txt" contents:[NSData data] attributes:attrs];
the file is successfully created and imbued with both of the desired attributes.
NSString throws an exception because it does not respond to -unsignedLong (yes, I know I got this selector wrong when I filed it — oops —ed), as assumed by NSFileManager.
NSFileTypeForHFSTypeCode appears to be the canonical way to create, effectively, an 'instance' of an HFS file type to be passed around in Cocoa, but NSFileManager only accepts NSNumbers. NSNumber seems to me to be more of a 'raw' representation. besides which, this usage of it definitely assumes the length of an unsigned long.
I just looked some more, and they also have:
- Audio Units Validation Tool
- CameraCheck (no, I don't know what it does)
- test matrices for iPhoto and iMovie
- free embedded code to put into your FireWire device
- a Bonjour Conformance Test for software (running on Mac OS X < 10.2) and hardware that advertises itself using Bonjour
I wish all blog-spammers imprisonment.
henceforth, when you try to comment on my blog, it will be sent to me to be moderated. I promise I'll be judicious, only deleting spam and never editing a legitimate comment.
from an AIS commercial on the radio: 'More than 30 insurance companies compete for AIS clients' business.'
taken literally: duh. AIS is an insurance company. insurance companies compete for each others' business. otherwise they wouldn't run commercials.
but if you read into it a little bit: why would insurance companies be so keen to compete for AIS clients' business specifically? the only reason I can think of is that AIS clients are more willing to pay more than clients of other companies, making them more desirable objects of competition.
not a good inference. you might want to rewrite that one, AIS.
recently, I went to Apple’s games site and downloaded a bunch of puzzle/arcade games. I was dismayed to find that many of these games were distributed in formats other than UDIF (the .dmg format). so clearly this matter bears some explanation.
this is the second part of a two-part post. part 1 came previously; it discussed the difference between compression, archive, and disk-image formats and described the different specific formats in each category. part 2 covers why you should use a plain dmg (no StuffIt or *zip sprinkles) to distribute your software. this was originally one long post, but I Kill Billed it.
Part 2: How to distribute your software
The sad current state of affairs is that much software is not distributed in a plain dmg. Here’s a brief hall of shame, in increasing order of silliness:
I’m not singling any of these products out (especially for .dmg.gz, .zip, and .sit, as these are absurdly common), nor am I critiquing the quality of the software; these are just examples of how not to distribute your application.
Regarding the last one: StuffIt format? WHY?!?!?! Mac OS X doesn’t even come with StuffIt Expander anymore!
And it’s not even StuffIt X (that would be .sitx); .sit is the older StuffIt 5 format, that doesn’t properly support application packages! Worse: because StuffIt 5 format does not support storage of UNIX permissions, StuffIt Expander relies on a preference setting to know whether to set a file as executable or not. So if you UnStuff an application from a StuffIt 5 archive, it might not even run. Doesn’t that make a great first user impression? And who’s going to suspect that their unarchiver is the cause of the problem?
In fact, it isn’t the cause of the problem at all. If you are still distributing your software in StuffIt format, you are to blame.
Panther added support in the Finder for zipping and unzipping files. Tiger added support in the Finder for gunzipping, bunzip2ing, and untarring files. All of these features are the wrong way to distribute an application.
First off, tarring a dmg is pointless. tar files exist to put multiple files into one file. A dmg is already a single file. There is no need to tar it.
Second, if you created your dmg correctly, it is already compressed (probably with zlib). ‘Correctly’ means making a read-only compressed image, either from a folder or from another (read/write) image. There is no need to compress it further. Be very surprised if the additional savings exceed 20 K. (the .dmg.tar.gz listed above is particularly egregious — hello, Mr. Redundancy Man!)
Third, if somebody on Jaguar (or earlier) downloads your zip file, and you created it using Finder, it will not unpack correctly in StuffIt Expander. Specifically, it will create ugly ‘__MACOSX’ folders. Your application might work (unless you actually did intend to use the resource fork for something, in which case it’s gone then), but littering a user’s system is not a way to build goodwill.
Fourth, the purpose of Finder’s zip support is to allow you to send files to Windows users. Distributing Mac software does not count.
There is only one valid use for zip: getting around stupid web servers that either don’t allow dmgs (*shakes fist at GeoCities*) or that don’t have a proper media type (application/octet-stream) set for it. If you have access to add that media type, do so, and distribute a plain dmg; otherwise, politely badger your admin. And until such time as they fix it, you should include a note on your downloads page acknowledging that having to zip your dmgs is lame.
Lest this article sound completely negative, let me explain the upsides of using UDIF.
The major advantage is that it sandboxes your application. An application shouldn’t install anything outside of its bundle (are you listening, Adobe?). If your application is written correctly, it is self-contained (everything it needs is in the .app bundle — this is what bundles are for) and does not require write access to the volume it is on. If your application can be run without problems from the dmg, then you are doing all right.
The second advantage is that a dmg does not require proprietary software (i.e. StuffIt). This seems to be a bigger advantage than it should be — StuffIt does not come with the OS anymore, and requiring people to download other software in order to use your software at all is not a good way to make them fans of it. Disk Copy/Disk Utility has always come with Mac OS X.
(Before you bring up Growl: Growl isn’t required by most of the applications that use it; it’s just value-added. Those applications that do require Growl are aimed specifically at existing Growl users.)
Third: with a dmg, you can easily embed a licence agreement. There is no need for an installer to display it; Disk Copy/Disk Utility will do it for you.
That gives me an idea. Here are a couple of points about installers.
Unless you are installing a framework (that really needs to be installed into a Library directory) or a kernel extension, do not create an installer or an Installer package. There is no point.
The user should be able to try your application without installing it (remember what I said about it being usable from the dmg?). An installer is a barrier to this. You should make it as easy as possible for people to try your app.
recently, I went to Apple's games site and downloaded a bunch of puzzle/arcade games. I was dismayed to find that many of these games were distributed in formats other than UDIF (the .dmg format). so clearly this matter bears some explanation.
this is going to be a two-part post. part 1 follows. part 2, which I will probably post tomorrow, will cover why you should use a plain dmg (no StuffIt or *zip sprinkles) to distribute your software. this was originally one long post, but I Kill Billed it.
UPDATE 2006-01-15: changed the initials to capital letters (sentence case), so it reads better; changed to smart quotes. also added mention of Compact Pro and a link to ESR's article on The Art of UNIX Programming.
UPDATE 2006-02-17: linkified Compact Pro.
Part 1: A brief history of compression and archiving
First, a couple definitions:
A compression format contains compressed data: data that has been fit into less space than it would without compression. gzip format is a good example of this; a gzip file is nothing but compressed data. It doesn’t even contain a filename — that’s worked out from the name of the gzip file. (for example, if you download Foo.tar.gz, and rename it Bar.tar.gz, and gunzip it, you will get a file named Bar.tar.)
An archive format aggregates one or more files into a single file. USTAR format (the format used by tar and pax; see below) is a good example of this. It isn’t compressed (unless you compress it with gzip, bzip2, or something else), but it is an archive format.
On Mac OS (that is, before Mac OS X), almost all software was distributed in StuffIt format. StuffIt was software developed by Aladdin Systems (now Allume Systems). (Before StuffIt caught on, the Mac market was majorly ruled by Compact Pro. But StuffIt, combined with apathy from the author, defeated it.)
The StuffIt format was both an archive format and a compression format: a StuffIt file was an archive of files whose contents were compressed. StuffIt achieved its greatest popularity with the advent of the internet — Mac OS applications could not be transmitted over networks, because most of their essential parts were in the resource fork, which was omitted when a file was sent to another operating system or copied to another file system. StuffIt, being data-fork only, kept everything intact. (MacBinary was another archive format, developed separately, that served that purpose, but did not offer compression.)
In the interest of being thorough, I should mention that MacBinary and BinHex were also used on top of StuffIt files (.sit.bin and .sit.hqx, respectively). MacBinarying a StuffIt file accomplished exactly nothing: you were wrapping what was already wrapped. BinHex was useful if the file was believed likely to undergo newline conversion (conversion between CR, which indicated a newline on the Apple II and Mac OS; LF, which indicated a newline on UNIX; and CRLF, which indicated a newline on DOS and Windows), but I think such situations were really the minority.
Eventually, Allume completely replaced the old StuffIt formats (there are at least four versions) with StuffIt X. StuffIt X supported much more detail in how the compression was specified, as well as Unicode filenames, 64-bit dates, packages (folders that behave as files, e.g. .app bundles) and stronger encryption. But it never achieved popular usage, for two reasons.
The first reason was simply that StuffIt 6-8 sucked. The larger reason is that OS X has its own facilities for archiving, compressing, and expanding files.
Mac OS had for many years (I used it on a Mac Plus and an SE/30, among other models) an application called Disk Copy. You’d open Disk Copy, then insert a floppy disk (80mm [aka 3.5"] disks were the prevailing medium of the day). Disk Copy would read from the disk, then prompt you to insert a blank disk or cancel. You could do this as many times as you wanted; thus, Disk Copy was a disk-duplication (i.e. copying) program.
In Disk Copy version 4.2 (I think), Apple added the ability to create disk images. A disk image is literally a snapshot of the contents of a disk. Disk Copy was able to both create and apply these disk images.
The idea was that you could make an image of a disk, make a hundred copies, sell them all, then come back with another box of disks and make a hundred more copies. Resumable duplication, in effect, without having to read the disk in each time. It was also possible to distribute disk images (by compressing them and/or sending them over the internet), so that the image could be applied to floppy disks by separate individuals.
Disk Copy also had the ability to ‘mount’ these images. This was the equivalent of putting the disk in, as it would show up on the desktop, but you could have incinerated the original real disk and it would still work — everything was read from the disk image. Once the internet got popular, it was possible to send a disk image to somebody else, and they could make their own floppy disks from the disk image.
Around the time of System 7.5, Apple began distributing SMIs: Self-Mounting Images. Regular disk images were Disk Copy documents, so when you opened one, Disk Copy would launch to take care of it. An SMI had the disk-mounting code in it, so you didn’t need Disk Copy anymore. I think Disk Copy was made a custom-install option at this point.
Disk Copy 6 introduced a new format called NDIF (New Disk Image Format), which came in several variants: a read/write format, a read-only uncompressed format, and two read-only compressed formats (one using an unknown codec, and the other using a proprietary Apple codec named KenCode).
Independently of all of this, UNIX in all its flavours (and later GNU operating systems as well) had a program called tar. tar is a tape archive program, designed for recording and playing back backup tapes.
At some point, tar gained the ability to make tape-archive files (now colloquially known as tarballs). This is the -f part of tar -cf. Tarballs, in this way, are analogous to disk images. The tar format was eventually standardised as USTAR.
The UNIX philosophy of software design is ‘do one thing well’. So the tar format (and its companion application, in all its various separate implementations) never gained any sort of compression. Instead, various compression programs are used in series upon the tar data. The original way to do this was tar -cf - <files> | compress > foo.tar.Z.
With Mac OS X, Disk Copy came back, and SMIs went away, and a new disk image format was introduced: UDIF. Like StuffIt X, UDIF was created to handle all the new and improved metadata supported by HFS+ — most conspicuously, Unicode filenames — as well as strong (AES-128) encryption. The old disk images had a filename extension of .img; this, unfortunately, was quite a common extension (used by at least one other imager and at least one picture format), so UDIF was given the filename extension of .dmg.
UDIF is a very flexible format. It comes in many variants. As of Mac OS X 10.4.3, these include:
- Read-only, uncompressed
- Read/write, uncompressed
- Read-only, ADC compression (another Apple codec)
- Read-only, zlib compression
- Read-only, bzip2 compression
- Entire device (?)
- UDIF stub (?)
- DVD/CD master
(These were also taken from the manpage for hdiutil.)
Numerous other formats have existed for many years — specifically zip (on Windows) and gzip and bzip2 (on UNIX and Linux) — and StuffIt Expander has supported all of them since 3.0 (bzip2 since maybe 5).
But in OS X, StuffIt Expander (which came with the OS until Tiger) showed its age. Versions 6-8 were slow and ugly. This got better with version 9, but by that time, StuffIt Expander lost to the alternative that also came with the OS: Disk Copy (which merged with Disk First Aid and Drive Setup to form Disk Utility in Jaguar).
For several years, most software for Mac OS X was distributed in the form of a zlib-compressed dmg.
But now things have deteriorated.
there's a website (probably not the one you've seen) that tells you how to fold your shirt. unlike the one that usually gets linked, this one does not have Japanese narration or text, the video quality is much higher, and most importantly, the motion is slower so that you can actually see what's going on. a very nice job.
they have a step-by-step photo tutorial too, but it's not very useful. the MPEG movie is the better demonstration.
so I've been pursuing new webspace (but not very much, I admit — flipping through hosting providers' websites all day is not my idea of fun). Colin turned me onto a provider called DreamHost, during their '777' promotion — an entire year of shared hosting for under $10 (following which year, the price went up to the regular price of $9.99/month). sounded like a good deal, so I investigated.
I found a couple of clauses in their TOS and their domain registration agreement that concerned me. so I emailed them, one issue per email, and got replies stating that they would fix the problems. that was in November 2005.
this month, seeing that neither issue had been fixed (I had been checking from time to time during that span), I emailed them again. following is the email I got back from them, in full, unedited (except that I HTMLised it and removed their sales address). it includes my email, quoted in full, which provides all the details.
On Wed, 11 Jan 2006, you wrote:
I emailed you on 2005-11-15 or 2005-11-16 (I'm not sure which, as I used the website form) regarding two issues with your agreements:
the TOS says that there is a $49.95 set-up fee for all shared hosting packages. the shared hosting packages comparison page says that several of the packages have no set-up fee. one or the other needs to be changed.
the domain-registration agreement says:
22. GOVERNING LAW
THIS AGREEMENT SHALL BE GOVERNED BY AND INTERPRETED AND ENFORCED IN ACCORDANCE WITH THE LAWS OF PROVINCE OF ONTARIO AND THE FEDERAL LAWS OF CANADA APPLICABLE THEREIN WITHOUT REFERENCE TO RULES GOVERNING CHOICE OF LAWS. ANY ACTION RELATING TO THIS AGREEMENT MUST BE BROUGHT IN ONTARIO AND YOU IRREVOCABLY CONSENT TO THE JURISDICTION OF SUCH COURTS.
when I emailed you about this previously, 'Jeff' replied:
We're actually based in Los Angeles, California.
when I challenged this statement by citing the above quote, 'Micki' replied:
Thank you for pointing that out becasue at one time we did have canadian empolyees I will go ahead and have the devlopers edit that.
when will these issues be fixed?
I have passed this information along to our Abuse team for you.
run from them. (btw, in case it's not clear: I am not, nor have I ever been, a DreamHost customer. but I was planning to be.)
UPDATE 2006-01-27: I just checked, and they have fixed their domain-registration agreement. it now says the State of California and the 'Federal laws of United States of America'. still no progress on the TOS, though.
my first ever. yay!
in iTunes, there is a 'Browse' display, activated by clicking a 'Browse' button in the upper-right corner of the ⌘1 window. this provides a hierarchical display of the contents of the currently-selected source. in the iTunes Music Store, one of the top-level selections is 'TV Shows'.
you would expect that selecting 'TV Shows' here would show you a list of all the TV shows available to be bought on the iTunes Video Store. and you would be wrong, because it only lists some of them.
the full list of displayed shows is:
- Adam 12
- Alfred Hitchcock Presents
- Battlestar Galactica
- Commander in Chief
- Desperate Housewives
- Knight Rider
- Law & Order
- Night Stalker
- The Office
- The Suite Life of Zack & Cody
- The Tonight Show with Jay Leno
this leaves out a number of shows, including well-known ones like Late Night with Conan O'Brien and Saturday Night Live.
filed as rdar://4407769.
UPDATE 2006-01-30: it seems fixed now, although the bug isn't closed yet.
I had to delete a couple of spam comments on the previous post. so if you're wondering why there are two deleted comments there, that's why.
if this keeps up, I'm going to enable word verification, which I don't like because it's a barrier to screen-reader users. spammers begone!
I've heard a lot of mentions of the free Flip4Mac for WMV since it was announced. I want to point out a danger in its EULA:
Section 3. Audit Permitted.
Telestream shall have the right, upon reasonable prior notice to You and during Your normal business hours, to audit Your use of the Licensed Materials and to inspect Your records related to any copies of the Software, or portions thereof, made by You.
Apple's Core Image documentation doesn't clearly state how to make a CPU-executable Image Unit, as opposed to a non-executable (GPU-only) one.
the answer is simple: don't make a .cikernel file. you should start with one when you're running the validation tool over your Image Unit, but if you want to make a CPU-executable Image Unit (and please do, so I can use it on my Cube), move the kernel code into your Obj-C code once it compiles, and then delete the .cikernel file.
(btw, yes, I am testing MarsEdit. hence the two posts today. ;)
some of you may know that I've been studying Apple's Core Image API — specifically, how to write an Image Unit. I just found this, buried in Apple's website: Software Licensing & Trademark Agreements: Image Units.
what's special about that? read the page closely:
it's actually a command-line tool, and the agreement is displayed when the image is mounted rather than when the tool is run, but nonetheless — it's a tool that examines your Image Unit and attempts to compile its CI kernel, and tells you if it finds anything wrong. highly useful.
EXAMPLE 2 The type designated as “struct tag (*)(float)” has type “array of pointer to function returning struct tag”. The array has length five and the function has a single parameter of type float. Its type category is array.
I was reading the C99 standard (because, you know, I'm Bored) and found a couple of interesting tidbits. read on and see…
EXAMPLE The constructions
- int *
- int *
- int (*)
- int (*)[*]
- int *()
- int (*)(void)
- int (*const )(unsigned int, ...)
name respectively the types (a) int, (b) pointer to int, (c) array of three pointers to int, (d) pointer to an array of three ints, (e) pointer to a variable length array of an unspecified number of ints, (f) function with no parameter specification returning a pointer to int, (g) pointer to function with no parameters returning an int, and (h) array of an unspecified number of constant pointers to functions, each with one parameter that has type unsigned int and an unspecified number of other parameters, returning an int.
EXAMPLE 1 The declaration
int f(void), *fip(), (*pfi)();
declares a function f with no parameters returning an int, a function fip with no parameter specification returning a pointer to an int, and a pointer pfi to a function with no parameter specification returning an int. …
see also part II.
'distributed piloting' is a term invented by Mac-arena the Bored Zo in 2006 (i.e. made up by me just now) for websites like Control Our Junk (which I found on Digg) that promise to let you control some real-world object from the internet. in the case of Control Our Junk, the objects to be controlled are a radio-controlled car, a train, and an airsoft gun.
the problem with it is that in any such system, you either have nobody controlling it (nobody's heard of your website) or thousands of people trying to control it (front page of Digg). in the latter case, either people get kicked off, or all the control commands mix together into discord. the car goes every which way, the gun fires at everything, and the train is constantly going back and forth, with no apparent pattern. I guess you could call it a form of entropy.
I think a better system might be to get ~200 (maybe more) RC cars, and put them in a big arena, and give everybody at least five (or maybe ten) minutes of time. if there are <200 cars in use, a new user simply gets one of the free cars. otherwise, if at least one person has been using a car for more than five minutes, the person who's been on the longest is kicked off. otherwise, the new user waits in a queue for somebody to hit their five-minute limit.
OK, now somebody go do that. I want to play with an RC car over the internet. ☺
I just want to point out one thing, regarding something said by a family member (Anna Kasto [sp?]) of one of the dead miners (Otto Withers). I heard her say this on the 2006-01-04 edition of NBC Nightly News:
We're Christian people, ourself. We have got some of us is right down to sayin', that we don't even know if there is a Lord anymore. We had a miracle, and it was taken away from us.
not so. the miracle she's talking about is the survival of 12 of the 13 miners, instead of just one. she basically says that this miracle was somehow withdrawn, but in fact, it never occurred. human misreporting is not the same as the divine repossession of a miracle.
the quote starts at 8 minutes and 8 seconds in the Nightly News podcast for that night.
UPDATE 2006-01-06: I just corrected the date above. I did not hear her say this one year before it happened. (yes, I'm still used to writing '2005'.)
looks like both sides of the music-downloading debate have their stupid moments. consider this lame article from p2pnet, which I shall fisk below.
p2p news / p2pnet: Sony BMG, Vivendi Universal, Warner Music and EMI, the Big Four Organized Music cartel members, aren't the only ones to have New York attorney general Eliot Spitzer breathing down their necks.
so far, so good.
"A trade group for digital-music services said Tuesday that its members have now also received information requests," says CNET News, quoting Jonathan Potter, executive director of the Digital Media Association, which represents companies including Yahoo, Apple Computer and America Online.
AHHH! run-on sentence!
Potter says the inquiry could become, "full-blown" —
— and, "Everybody expects to be contacted, and some already have been".
At this point in time, there's no viable corporate online music business.
what? huh? what about iTunes?
This reality is surprising given that hundreds of millions of people around the world regularly and routinely use the p2p networks —
— and independent artist and download sites for their music fixes, —
how many of those hundreds of millions do you figure are going to the independent artist sites? not to diminish the independent artists, but I honestly don't believe the percentage is all that high.
— and that thousands of new music lovers are logging on and tuning in every day.
thousands every day? for that matter, hundreds of millions? care to back these figures?
Reading Big Four Organized Music cartel press releases, always faithfully reproduced as-is, and without question or verification, by the mainstream media, one could be forgiven for thinking significant numbers of people are hitting the various sites backed and supported by the Big Four, and paying handsomely for the privilege.
so, who exactly are the Big Four Organized Music cartel?
However, it's all pure PR baloney.
new from Oscar Mayer.
Organized Music —
— is wholesaling identical, —
(as opposed to illegally-downloaded songs, which vary widely)
— low-fidelity, heavily compressed versions of songs —
that NEVER happens on P2P networks.
— its owners have already created for CD releases to the same companies, such as Apple, RealNetworks and Napster, —
wait, huh? CD releases to the online music stores?
This forces Apple, et al, to try to off the tracks for a dollar and more each, depending on which countries they're selling in. And the Big Four apparently want to introduce variable pricing with something in the region of $1.50 for 'premium' product at the top end.
worth more, costs more. I'm not seeing the flaw in this plan. (FTR, I do prefer the flat 99-cent price.)
No one in his right mind is going to pay upwards of $1 for lossy, inferior quality, cookie-cutter corporate 'product' drawn from tightly limited catalogues —
— when for pennies, they can —
— tap into not only everything the Big Four have to offer online, but also millions of other tracks, new and old, from allofmp3.com and similar sites.
They can also buy from the many independent sales pages set up by new artists as well as established star performers who've discovered they can do much better for themselves and their fans online and off without the "help" of the major labels.
Meanwhile, nine times out of ten, —
more made-up statistics.
— music industry 'premium' product, going out at $1 and more, isn't worth a light, —
candle-light? incandescent light? halogen light?
— which is one of the reasons OM is reporting plummeting sales. …
Currently, the Big Four spending most of their marketing resources on a bizarre sue 'em all campaign through which they're trying to blackmail people into buying 'product'.
actually, they're trying to punish them for stealing 'product'. if you don't steal music, you don't get sued, whether you buy the music or not. also, I haven't heard of the RIAA withdrawing a lawsuit because the defendant turned around and legally bought the music that was stolen.
I agree that the tactic won't work in the long run, but this characterisation of it is inaccurate.
They're doomed to fail on all fronts …
tell me more about your crystal ball.
The Big Four have already been found guilty of numerous dirty tricks designed to boost sales and keep prices high.
they have? please cite cases.
also, um, isn't boosting sales kind of the idea? same with keeping prices as high as the market will bear. I believe it is called 'making a profit', and it is the end goal of every business.
same bat-time. same bat-website.
my main problem with this article (and others like it on p2pnet) is that the site bills itself as 'news', but it is really just an editorial platform. serves to remind you that this is the internet — take everything with a grain of salt.
so last night, we had KFC for dinner. we went to a different KFC from the one we usually go to. this didn't work out so well.
Give me the wrong order
part of our order was three crispy strips, chicken only. we got three barbecue strips. smelled good, but it wasn't what I ordered.
Give somebody else half their order
the person who was in line ahead of us ordered two meals — one for him, one for his wife. he got one meal — and an empty plate. how does THAT happen? he complained, and received the second meal that he was owed.
Be apathetic towards customers' property
specifically, their car batteries. I saw that the car next to us had its lights still on. I went in and told them about it. their response was essentially 'so what do you want us to do about it?' I suggested that they could make an announcement or something, but they didn't seem interested. (yes, I know I could have made the announcement myself. I thought of this on the way out of the parking lot.)
we shall be going to our usual KFC from now on.
even better, it accepts line noise as input. from the manpage:
To put two pages on one sheet (of A4 paper), the pagespec to use is:2:0L@.7(21cm,0)+1L@.7(21cm,14.85cm)
To select all of the odd pages in reverse order, use:2:-0
To re-arrange pages for printing 2-up booklets, use4:-3L@.7(21cm,0)+0L@.7(21cm,14.85cm)
for the front sides, and4:1L@.7(21cm,0)+-2L@.7(21cm,14.85cm)
for the reverse sides.
pstops is part of psutils.
Mac OS X Hints has an article on adding the standard feed icon to Safari. of course, I already created one and put it on my website. I also sent in my own hint linking to my icon; my hint was not accepted.
the Mac OS X Hints post has several mentions of different Safari feed icons in the comments, including me mentioning my own. one problem with the hint's instructions is that the generated TIFF file will not have an alpha channel, leading to the ugly black corners that you see in the screenshot. AFAIK, none of the other renditions have this. another problem is that it doesn't affect the 'Hide' button - when you go to a feed page, the button will change to say 'RSS' again.
you should try all the versions, as everybody seems to have a different taste for how the 'Hide' button should work. if you can't find one you agree with, feel free to make your own interpretation.