Slashdot Mirror

Heh, remember Cherry OS?

Unfortunately, according to Random Blogger #1, VMWare isn't much better.

CrossOver Mac will be the very best way to run your Windows applications on your Intel based Mac. It will let you install and run Windows programs as though they were native, all without having to buy or run a copy of Windows itself.

In other news, the guys over at CherryOS have announced that they have a new product...

Which web page? I'm genuinely curious. In my experience, Safari has handled everything the internet throws up (aside from some obscure image decoding bugs) much more snappily than Firefox, with much less disk swapping, and using much less memory. And if you're referring to these image decoding bugs, Firefox has had its share of those too. So if you can provide a link to something that chokes Safari but Firefox handles with grace, I'd appreciate the lesson.

Firefox is nice, but its developers suffer from a severe lack of good taste when it comes to UI and host OS features. If it works for you, great, sincerely, I'm happy for you. But for those of us concerned with the comprehensive aesthetics of behavior, usability, and integration, Firefox remains far from optimal.

Here's what I know of and/or could find for the ones I didn't.

• Aaron Hillegas
• Adam & Tonya Engst
• Amit Singh
• Andrina Kelly
• Andy Ihnatko
• Ben Wilson
• Brent Simmons
• Dan Frakes
• Danny Goodman
• David Pogue
• Drunkenbatman
• John Gruber
• John Siracusa
• Jonathan "Wolf" Rentzsch
• Josh Wisenbaker
• Michael Bartosh
• Mike Breeden
• Nigel Kersten
• Ray Barber
• Ric Ford
• Rich Siegel (Bare Bones SW)
• Rob Griffiths
• Rosyna Keller
• Scott Knaster
• Wil Shipley (Delicious Monster)

Unfortunately, it seems that Slashdot has a limitation on the minimum number of characters per line. So I can't just create a nice, simple list, but instead need a significant amount of text to pad out the list, so that I can make it past the filters being used. But I'm still not there yet... sooner or later I will (20.4 is still too few). I'm probably going to have to type a whole lot of crap in here just to deal with the 25 names that are only a few characters each. (and I tried removing returns from the message, but it didn't seem to help at all)

I have to agree. Even with OS X completely up to date (10.4.6), there remain a number of unpatched bugs, and I don't doubt that many (all?) of these could be used to run arbitrary code. It may require user interaction, but when user interaction is as simple as viewing an image in Safari or clicking a message in Mail.app--and given that we Mac users tend to cluster together--that's not much of a barrier to a virus or worm spreading like wildfire.

While I'm a Mac user, I don't think it helps anyone to run around proclaiming the Mac's invulnerability to exploits. It's worth remembering that malicious code doesn't need to run as root to ruin your day. Suppose a worm spread itself to all the emails in your Address Book, using that ImageIO vulnerability (this would work in Mail.app and any webmail in Safari). Even with unprivileged system access, it could forward your ~/Documents/ folder along with itself, and that would certainly unleash hell on earth. Surely malware authors could come up with something even more creative.

...enforcing the NX/XD bit and enforcing a non-executable stack...

...enforcing the NX/XD bit and enforcing a non-executable stack...

Still not secure enough to be immune from running malicious code. Nothing can ever be that secure. How do you know, for example, that the latest update of NetNewsWire doesn't install spyware? You can't. You just have to trust, and this is usually good enough. Usually, but not always.

Even with yesterday's 10.4.6 update, there remains in AppKit a likely remote command execution exploit when viewing malformed JPEGs. See here, for example. (DO NOT CLICK THIS IN SAFARI!) This affects every OS X app other than those which happen to implement their own JPEG decoders (including, thankfully, Camino and company). So if you download the evil JPEG to your desktop, and you have previews turned on, it sends the Finder into a crash-relaunch loop. Assuming this bug allows arbitrary code execution, Pierre MacProgrammer could easily craft a JPEG, today, to spread like wildfire among Mac users--hey, we're a tight-knit community--by emailing itself via Mail.app.

Don't bury your head in the sand just because we Mac users are better than our PC brethren (snicker). Eventually, I think Apple's going to have to implement a whitelist/blacklist of sites in Safari, or something like that SiteAdvisor plugin does for FireFox.

Still not secure enough to be immune from running malicious code. Nothing can ever be that secure. How do you know, for example, that the latest update of NetNewsWire doesn't install spyware? You can't. You just have to trust, and this is usually good enough. Usually, but not always.

Even with yesterday's 10.4.6 update, there remains in AppKit a likely remote command execution exploit when viewing malformed JPEGs. See here, for example. (DO NOT CLICK THIS IN SAFARI!) This affects every OS X app other than those which happen to implement their own JPEG decoders (including, thankfully, Camino and company). So if you download the evil JPEG to your desktop, and you have previews turned on, it sends the Finder into a crash-relaunch loop. Assuming this bug allows arbitrary code execution, Pierre MacProgrammer could easily craft a JPEG, today, to spread like wildfire among Mac users--hey, we're a tight-knit community--by emailing itself via Mail.app.

Don't bury your head in the sand just because we Mac users are better than our PC brethren (snicker). Eventually, I think Apple's going to have to implement a whitelist/blacklist of sites in Safari, or something like that SiteAdvisor plugin does for FireFox.

From TFA, file jumping will only happen "Based on what you have been listening to in the past and which files you already own".

Yeah, but we all know how well that type of system has worked in the past.

The way one local (and now powerful) company did it was by "hiring" people for pizza. If the product is cool, then you'll corral some college geeks to do the groundwork and free up your good coders for the cool work.

This has been touched on recently in some blogs ( http://www.wilshipley.com/blog/ and http://www.drunkenblog.com/drunkenblog-archives/00 0713.html ) that college students, who were used and abused during the bubble, remain a good resource of, dare I say it, cheap labour. They like the prestige, need the experience, and are used to working in small project teams. And yeah, you can pay them peanuts.

And no, they don't even need to be in college. Two of the most impressive code monkeys I know dropped out of High School.....

Remember that disseminating false information about a company is libel, so for those of you getting ready to create webpages that list the included code, you'd better make sure your evidence and assumptions are accurate. Otherwise, you might be setting yourselves up for a nice fat lawsuit by Sony, reminiscent of Maui-X. Wouldn't that be ironic?

We see reports of companies misusing GPL'd code a lot, and we almost never hear about a successful prosicution. A great example that comes to mind is Maui X-Stream, who has been proven guilty of violating the GPL several times in most, if not all, of their products. However, we never hear about those people actually doing jail time for it. One has to ask, is the GPL effective at all?

He already did start banging his head against the desk... but some legal actions in progress are keeping him from delving too deep into this new product and its shady owners.

Too bad, he sure knows how to whip them doods.

Looking deeper into the linked article, there is some really very good evidence elsewhere on the site. http://www.drunkenblog.com/drunkenblog-archives/00 0534.html is a total dissection of the first few generations of this "Vx30" codec and suite -- which appears to be a direct lift of Xvid, mpg123, lame, and mplayer classic code, as well as code from the JPEG group and others.

Read this for a detailed account of the evidence of *ahem* borrowing from open source code projects by the VX30 project:

http://www.drunkenblog.com/drunkenblog-archives/00 0534.html

All I can say is I have a very strong opinion about the company and the people running it, take a look and decide for yourselves, their actions speak louder than words.

Just so you know, Drunkenbatman had this pegged.

Within the last few weeks, there appears to have been a meeting between MSN, Yahoo and AOL. They'd all been talking amongst themselves -- and sparsely with each other -- about how to respond to Google, but were still trying to make up their minds...

The Cow Abides

Tragically, Mac OS X actually has a chess program: Chess.app, which comes bundled with the OS.

(You even get "that puzzle game with the Apple logo" as a Dashboard widget in 10.4, the first time it's been bundled with Mac OS since OS X came out.)

"Unfortuantely you bought when Apple had just switched to Asus for their iBook's logic boards. Their first revs were complete crap."

The flawed computers were sold for more than two years, so I can conclude that Apple either did it knowingly or they don't pay much attention to failure rates. Either is cause for concern, IMO.

"It's a bummer that you ended up with a lemon, if you would've spent a bit more for a Powerbook(They do not use Asus boards.), or bought later on when the G4 iBook were released, chances are that you would've bought a machine that is truly reliable."

Other Apple computers have had problems recently, including the PowerBook you propose.

"Apple will replace all iBook logic boards free of charge."

I don't mind the occasional failure, but when the quality is so low that it leads to significant downtime you can bet I have a problem. That 10% I mentioned was over the course of 2 years, so that's a pretty big chunk of time.

There are also major bugs and issues with updates that proper testing would have caught.

Apple has been much better in the past, so I interpret these to be evidence of a declining commitment to quality and I am unwilling to risk another Apple purchase.

I'm also unwilling to even consider them because of the poor specs. minis are too slow, iMacs can't do dual displays and can't be substantially upgraded, and PowerMacs would be great if they had a single-CPU version that cost half as much. If I ignore the reliability problems and the slow CPU in the laptops, there's still the crapper screens (resolution, contrast ratio, etc), the slower hard drives (4200 with 5400 rpm for premium instead of 5400 and 7200 rpm), the shorter battery life, etc. These crappy specs have nothing to do with the CPU so I don't hold out much hope for an improvement post-Intel switch.

I've used OS X, and IMO it's just not worth the associated crap you have to put up with. I'm not basing this solely on my experience, I see ample evidence that I am not alone and that the quality is declining. Unless Apple improves, they're going to lose these switchers just like they lost me.

"Unfortuantely you bought when Apple had just switched to Asus for their iBook's logic boards. Their first revs were complete crap."

The flawed computers were sold for more than two years, so I can conclude that Apple either did it knowingly or they don't pay much attention to failure rates. Either is cause for concern, IMO.

"It's a bummer that you ended up with a lemon, if you would've spent a bit more for a Powerbook(They do not use Asus boards.), or bought later on when the G4 iBook were released, chances are that you would've bought a machine that is truly reliable."

Other Apple computers have had problems recently, including the PowerBook you propose.

"Apple will replace all iBook logic boards free of charge."

I don't mind the occasional failure, but when the quality is so low that it leads to significant downtime you can bet I have a problem. That 10% I mentioned was over the course of 2 years, so that's a pretty big chunk of time.

There are also major bugs and issues with updates that proper testing would have caught.

Apple has been much better in the past, so I interpret these to be evidence of a declining commitment to quality and I am unwilling to risk another Apple purchase.

I'm also unwilling to even consider them because of the poor specs. minis are too slow, iMacs can't do dual displays and can't be substantially upgraded, and PowerMacs would be great if they had a single-CPU version that cost half as much. If I ignore the reliability problems and the slow CPU in the laptops, there's still the crapper screens (resolution, contrast ratio, etc), the slower hard drives (4200 with 5400 rpm for premium instead of 5400 and 7200 rpm), the shorter battery life, etc. These crappy specs have nothing to do with the CPU so I don't hold out much hope for an improvement post-Intel switch.

I've used OS X, and IMO it's just not worth the associated crap you have to put up with. I'm not basing this solely on my experience, I see ample evidence that I am not alone and that the quality is declining. Unless Apple improves, they're going to lose these switchers just like they lost me.

Have a look at: http://www.drunkenblog.com/drunkenblog-archives/00 0637.html -- it's a bit on the long side but there's some interesting material for pondering over in there.

For those of you using OS X that have an interest in GIMP, I ran across Seashore the other day while reading Drunkenblog. It's a major improvement over GIMP for OS X. Definitely something to keep your eye on.

My shuffle hasn't had any problems, and it's actually recieved the coveted "ArbitraryConstant has no specific complaints" award, which means it meets my expectations in every way and is the highest praise I have to give.

But when Apple makes crap I'm going to call them on it. I don't know why people reply to posts like mine with "I've had X for Y years, no problems". Is it to balance out the public impression made when someone's been having issues? Drunkenbatman said it better than me, there's an instinct to try to keep issues "in the family", but I think that's dangerous. If they are protected from the fallout when bad things happen, they will be less likely to prevent them from happening in the future.

For more in-depth analysis of this statement, please read drunkenbatman's post MacWorld 2005 Keynote: Wag the Porn. A fine analysis of which format may win.

If I had mod points, you'd get them now. That comment made my day, thank you.

Have anyone read drunkenbatman's Ham Story?

http://www.drunkenblog.com/drunkenblog-archives/00 0331.html

When I picked up WO in 2000, I told pretty much anyone who listened that while WebObjects is the most advanced application server out there, that open source would catch up with it inside five years.

Yet here we are in 2005, and there's still nothing close. Believe me, I've been looking. Read the WebObjects developer mailing list for a recap of the treatment WebObjects developers got at WWDC 2004.

I would love to get off WebObjects and replace it with something open source. It would make web application development pitches easier if I never have to mention the dreaded "A" word. I have clients who will simply shut the door if I mention Apple's name, even today.

So I keep an eye on projects like Hibernate, Cayenne, Tapestry and Ruby on Rails. And yet, each time I start a new project, I do the math and rediscover WebObjects will deliver better software in less time. Lord, I wish it weren't true, but it is.

Nope.

And..

Ryan's heart was in the right place, but if you could please use one of the many mirrors to both get it and possibly create your own, we can hopefully avoid the server being destroyed again... :)

If you want to mirror my analysis archive, get it here:

http://www.drunkenblog.com/mxs/mxs_evidence.tar.gz

(i can't host it on my webserver yet due to legal issues - these originated from it though)

The archive can be browsed here:
http://www.drunkenblog.com/mxs/

Drunkenbatman said that there's over 20 mirrors of it, so I'll try to find out what those are.

-eventhorizon

If you want to mirror my analysis archive, get it here:

http://www.drunkenblog.com/mxs/mxs_evidence.tar.gz

(i can't host it on my webserver yet due to legal issues - these originated from it though)

The archive can be browsed here:
http://www.drunkenblog.com/mxs/

Drunkenbatman said that there's over 20 mirrors of it, so I'll try to find out what those are.

-eventhorizon

http://www.drunkenblog.com/drunkenblog-archives/00 0534.html Here is a very in depth comparison. gpl code everywhere in vx30

Moreover, they've written several times that SubEthaEdit leverages several OSX technologies, including both Bonjour and Cocoa, as well as makes (unorthodox?) use of open protcols like BEEP. From the sound of it, getting SEE to work without this toolkit would be very hard to do.

I'm a little more interested in support for the SEE protocol in an editor like Vim or Emacs. If they can add it, then it'll instantly be available to people using any platform at all, even if SEE never gets ported to anything else. From what I can tell, this is a lot more likely, but so far I haven't heard of anyone working on hacking up these editors to support SEE style collaborative editing. Oh well...

According to the PDF linked from TFA, a judgment was entered in favor of Apple. Sunny was permanently barred from possessing, controlling, copying, sharing, etc, any information or property belonging to Apple, and he had to return all information gained via his ADC account. BTW, the limitations do not apply to any Apple hardware or software purchased in a retail setting, so this doesn't limit him from remaining a Mac fanboy. It just means that he can't be in the early adopter club. It also means that he didn't have to pay anything, which is a big win for Sunny.

As discussed in this Drunkenblog interview. Of the Core fillintheblanks, it's easily the spiffiest.

The other feejurs, imo, are just fluff. Unless they've sunk some serious improvements into mail, ical and iphoto.

I don't want MORE features, I want the features they're shipping to be developed beyond vestigial buzzwords (re: OpenDoc in the OS 8 era).

I originally posted material on the PearPC developer list right after CherryOS was released (including some of my own comparisons of the binaries and stuff). One hilarious thing is that CherryOS has dialogs that say they're formatting an HPFS volume (and more windows that mention the filesystem HPFS) - the funny thing is that MacOS X uses the HFS+ filesystem (OS 9 uses HFS), so right there you know that these people have no clue about the operating system they're supporting. They also claimed that the whole software app was developed by a single guy in 4 months... any person who's familiar with architecture emulators knows that a statement like that is insane - writing an entire software-based PowerPC cpu emulator, along with the hardware emulation layers all by one guy in 4 months?! That is similar to a person saying that Bill Gates wrote Windows 95 all by himself back in '95 lol.

Here's my stash of comparisons; there's many other pages on other sites with info:
http://www.tliquest.net/ryan/cherryos

The in-depth article that features some of my research is here:
http://www.drunkenblog.com/drunkenblog-archives/00 0501.html

-eventhorizon

It might be worthwhile mentioning that CherryOS (PearPC) is not a "MAC" (sic) emulator, but rather a general PowerPC architecture and motherboard emulator. PearPC presents itself as such. However, CherryOS markets and specifically targets itself at Mac OS X. Unfortunately, Apple's Mac OS X license agreement specifically states it can only be installed on an Apple-branded computer. Aside from the PearPC issues, CherryOS is a commercial product actively encouraging its users to break Apple's Mac OS X license agreement. And yes, this license agreement is binding: that's why no one makes clones. (And no, Apple "ROMs" are no longer required. Haven't been for ages.)

Funnily enough, Maui X-Stream president Jim Kartes said:

We are building an emulator like they are that uses Mac language. PearPC uses Mac language and next thing you know, they say we are using their code. This is a totally different architecture.

This comment makes no sense. "PearPC uses Mac language" has no meaning, and is, if anything, indicative of the fact that this company does not fundamentally understand the operation of innards of their product, which isn't surprising, since they didn't create it. PearPC is essentially a PowerPC motherboard emulator, which emulates a PowerPC processor, and various necessary elements of a PowerPC motherboard. I think what Kartes is trying to claim is that because PearPC and CherryOS do the same thing, it's no surprise that they'd appear similar. This claim is absurd, because the evidence is overwhelming that CherryOS is using PearPC as the emulation engine. CherryOS is essentially a graphical wrapper for PearPC, which does nothing more than pass instructions to PearPC and execute PearPC within itself. It tries to conceal, rather poorly, that PearPC is what's running underneath. Aside from the proof of very unique shared strings and symbols above, CherryOS also shares PearPC's featureset, or lack thereof in the case of support for sound and networking, and even PearPC's specific bugs. In sum, any claim that CherryOS and PearPC would share unique strings, variable names, and symbols simply because they're both emulators is ridiculous. Also, saying "Mac language" is really irrelevant because, aside from not making sense, PearPC (and CherryOS) doesn't have anything to do with the Mac or "Mac language". It's a *PowerPC* emulator. The fact that a Mac operating system runs on it is incidental; PearPC (and CherryOS) doesn't contain or use anything that could be referred to as "Mac language".

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter (of which there are approximately 184884258895036416 different combinations), shared specific functionality, including bugs, and so on, not to mention code from other GPL projects:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

It might be worthwhile mentioning that CherryOS (PearPC) is not a "MAC" (sic) emulator, but rather a general PowerPC architecture and motherboard emulator. PearPC presents itself as such. However, CherryOS markets and specifically targets itself at Mac OS X. Unfortunately, Apple's Mac OS X license agreement specifically states it can only be installed on an Apple-branded computer. Aside from the PearPC issues, CherryOS is a commercial product actively encouraging its users to break Apple's Mac OS X license agreement. And yes, this license agreement is binding: that's why no one makes clones. (And no, Apple "ROMs" are no longer required. Haven't been for ages.)

Funnily enough, Maui X-Stream president Jim Kartes said:

We are building an emulator like they are that uses Mac language. PearPC uses Mac language and next thing you know, they say we are using their code. This is a totally different architecture.

This comment makes no sense. "PearPC uses Mac language" has no meaning, and is, if anything, indicative of the fact that this company does not fundamentally understand the operation of innards of their product, which isn't surprising, since they didn't create it. PearPC is essentially a PowerPC motherboard emulator, which emulates a PowerPC processor, and various necessary elements of a PowerPC motherboard. I think what Kartes is trying to claim is that because PearPC and CherryOS do the same thing, it's no surprise that they'd appear similar. This claim is absurd, because the evidence is overwhelming that CherryOS is using PearPC as the emulation engine. CherryOS is essentially a graphical wrapper for PearPC, which does nothing more than pass instructions to PearPC and execute PearPC within itself. It tries to conceal, rather poorly, that PearPC is what's running underneath. Aside from the proof of very unique shared strings and symbols above, CherryOS also shares PearPC's featureset, or lack thereof in the case of support for sound and networking, and even PearPC's specific bugs. In sum, any claim that CherryOS and PearPC would share unique strings, variable names, and symbols simply because they're both emulators is ridiculous. Also, saying "Mac language" is really irrelevant because, aside from not making sense, PearPC (and CherryOS) doesn't have anything to do with the Mac or "Mac language". It's a *PowerPC* emulator. The fact that a Mac operating system runs on it is incidental; PearPC (and CherryOS) doesn't contain or use anything that could be referred to as "Mac language".

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter (of which there are approximately 184884258895036416 different combinations), shared specific functionality, including bugs, and so on, not to mention code from other GPL projects:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

It might be worthwhile mentioning that CherryOS (PearPC) is not a "MAC" (sic) emulator, but rather a general PowerPC architecture and motherboard emulator. PearPC presents itself as such. However, CherryOS markets and specifically targets itself at Mac OS X. Unfortunately, Apple's Mac OS X license agreement specifically states it can only be installed on an Apple-branded computer. Aside from the PearPC issues, CherryOS is a commercial product actively encouraging its users to break Apple's Mac OS X license agreement. And yes, this license agreement is binding: that's why no one makes clones. (And no, Apple "ROMs" are no longer required. Haven't been for ages.)

Funnily enough, Maui X-Stream president Jim Kartes said:

We are building an emulator like they are that uses Mac language. PearPC uses Mac language and next thing you know, they say we are using their code. This is a totally different architecture.

This comment makes no sense. "PearPC uses Mac language" has no meaning, and is, if anything, indicative of the fact that this company does not fundamentally understand the operation of innards of their product, which isn't surprising, since they didn't create it. PearPC is essentially a PowerPC motherboard emulator, which emulates a PowerPC processor, and various necessary elements of a PowerPC motherboard. I think what Kartes is trying to claim is that because PearPC and CherryOS do the same thing, it's no surprise that they'd appear similar. This claim is absurd, because the evidence is overwhelming that CherryOS is using PearPC as the emulation engine. CherryOS is essentially a graphical wrapper for PearPC, which does nothing more than pass instructions to PearPC and execute PearPC within itself. It tries to conceal, rather poorly, that PearPC is what's running underneath. Aside from the proof of very unique shared strings and symbols above, CherryOS also shares PearPC's featureset, or lack thereof in the case of support for sound and networking, and even PearPC's specific bugs. In sum, any claim that CherryOS and PearPC would share unique strings, variable names, and symbols simply because they're both emulators is ridiculous. Also, saying "Mac language" is really irrelevant because, aside from not making sense, PearPC (and CherryOS) doesn't have anything to do with the Mac or "Mac language". It's a *PowerPC* emulator. The fact that a Mac operating system runs on it is incidental; PearPC (and CherryOS) doesn't contain or use anything that could be referred to as "Mac language".

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter (of which there are approximately 184884258895036416 different combinations), shared specific functionality, including bugs, and so on, not to mention code from other GPL projects:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

It might be worthwhile mentioning that CherryOS (PearPC) is not a "MAC" (sic) emulator, but rather a general PowerPC architecture and motherboard emulator. PearPC presents itself as such. However, CherryOS markets and specifically targets itself at Mac OS X. Unfortunately, Apple's Mac OS X license agreement specifically states it can only be installed on an Apple-branded computer. Aside from the PearPC issues, CherryOS is a commercial product actively encouraging its users to break Apple's Mac OS X license agreement. And yes, this license agreement is binding: that's why no one makes clones. (And no, Apple "ROMs" are no longer required. Haven't been for ages.)

Funnily enough, Maui X-Stream president Jim Kartes said:

We are building an emulator like they are that uses Mac language. PearPC uses Mac language and next thing you know, they say we are using their code. This is a totally different architecture.

This comment makes no sense. "PearPC uses Mac language" has no meaning, and is, if anything, indicative of the fact that this company does not fundamentally understand the operation of innards of their product, which isn't surprising, since they didn't create it. PearPC is essentially a PowerPC motherboard emulator, which emulates a PowerPC processor, and various necessary elements of a PowerPC motherboard. I think what Kartes is trying to claim is that because PearPC and CherryOS do the same thing, it's no surprise that they'd appear similar. This claim is absurd, because the evidence is overwhelming that CherryOS is using PearPC as the emulation engine. CherryOS is essentially a graphical wrapper for PearPC, which does nothing more than pass instructions to PearPC and execute PearPC within itself. It tries to conceal, rather poorly, that PearPC is what's running underneath. Aside from the proof of very unique shared strings and symbols above, CherryOS also shares PearPC's featureset, or lack thereof in the case of support for sound and networking, and even PearPC's specific bugs. In sum, any claim that CherryOS and PearPC would share unique strings, variable names, and symbols simply because they're both emulators is ridiculous. Also, saying "Mac language" is really irrelevant because, aside from not making sense, PearPC (and CherryOS) doesn't have anything to do with the Mac or "Mac language". It's a *PowerPC* emulator. The fact that a Mac operating system runs on it is incidental; PearPC (and CherryOS) doesn't contain or use anything that could be referred to as "Mac language".

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter (of which there are approximately 184884258895036416 different combinations), shared specific functionality, including bugs, and so on, not to mention code from other GPL projects:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

Was the offendor coerced into making a public apology and serving as a scary example to others? You bet he was.

Uh, no, he wasn't.

But remember, the GPL itself is not specifically "tested", per se, because GPL software developers assert them rights granted to them via copyright on an individual basis. This makes it a sometimes long and arduous process to assert rights and/or prove infringement, but hopefully more precedent will help.

Since the provisions of the GPL have been upheld in a case in Germany as well, maybe PearPC will be able to more easily defend itself against CherryOS, which has blatantly taken GPL code, without release of source code or attribution, from PearPC and several other GPL projects:

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter, shared specific functionality, including bugs, and so on:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

http://starport.dnsalias.net/index.php?show=articl e&id=348

http://forums.pearpc.net/viewtopic.php?p=16178#161 78
http://www.tliquest.net/ryan/cherryos/
http://dhost.info/kourge/en/projects/frauds/cherry os.php

Additionally, PearPC project authors are already asserting their rights under the GPL:

http://sourceforge.net/mailarchive/message.php?msg _id=11116974

And a general compilation of some of the evidence so far against CherryOS:

http://sourceforge.net/mailarchive/message.php?msg _id=11125509

But remember, the GPL itself is not specifically "tested", per se, because GPL software developers assert them rights granted to them via copyright on an individual basis. This makes it a sometimes long and arduous process to assert rights and/or prove infringement, but hopefully more precedent will help.

Since the provisions of the GPL have been upheld in a case in Germany as well, maybe PearPC will be able to more easily defend itself against CherryOS, which has blatantly taken GPL code, without release of source code or attribution, from PearPC and several other GPL projects:

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter, shared specific functionality, including bugs, and so on:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

http://starport.dnsalias.net/index.php?show=articl e&id=348

http://forums.pearpc.net/viewtopic.php?p=16178#161 78
http://www.tliquest.net/ryan/cherryos/
http://dhost.info/kourge/en/projects/frauds/cherry os.php

Additionally, PearPC project authors are already asserting their rights under the GPL:

http://sourceforge.net/mailarchive/message.php?msg _id=11116974

And a general compilation of some of the evidence so far against CherryOS:

http://sourceforge.net/mailarchive/message.php?msg _id=11125509

But remember, the GPL itself is not specifically "tested", per se, because GPL software developers assert them rights granted to them via copyright on an individual basis. This makes it a sometimes long and arduous process to assert rights and/or prove infringement, but hopefully more precedent will help.

Since the provisions of the GPL have been upheld in a case in Germany as well, maybe PearPC will be able to more easily defend itself against CherryOS, which has blatantly taken GPL code, without release of source code or attribution, from PearPC and several other GPL projects:

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter, shared specific functionality, including bugs, and so on:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

http://starport.dnsalias.net/index.php?show=articl e&id=348

http://forums.pearpc.net/viewtopic.php?p=16178#161 78
http://www.tliquest.net/ryan/cherryos/
http://dhost.info/kourge/en/projects/frauds/cherry os.php

Additionally, PearPC project authors are already asserting their rights under the GPL:

http://sourceforge.net/mailarchive/message.php?msg _id=11116974

And a general compilation of some of the evidence so far against CherryOS:

http://sourceforge.net/mailarchive/message.php?msg _id=11125509

But remember, the GPL itself is not specifically "tested", per se, because GPL software developers assert them rights granted to them via copyright on an individual basis. This makes it a sometimes long and arduous process to assert rights and/or prove infringement, but hopefully more precedent will help.

Since the provisions of the GPL have been upheld in a case in Germany as well, maybe PearPC will be able to more easily defend itself against CherryOS, which has blatantly taken GPL code, without release of source code or attribution, from PearPC and several other GPL projects:

eWeek has a general overview of the situation:

http://www.eweek.com/article2/0,1759,1775386,00.as p

Below is a comprehensive collection of evidence, which runs the gamut from CherryOS including original PearPC graphics, extremely unique strings and error messages, debug code from PearPC, the same unique MAC address as PearPC's default network adapter, shared specific functionality, including bugs, and so on:

http://www.ht-technology.com/cherryos-pearpc/cherr yos-pearpc.html

http://www.drunkenblog.com/drunkenblog-archives/00 0501.html
http://www.drunkenblog.com/drunkenblog-archives/00 0503.html
http://www.drunkenblog.com/drunkenblog-archives/00 0504.html
http://www.drunkenblog.com/drunkenblog-archives/00 0507.html

http://starport.dnsalias.net/index.php?show=articl e&id=348

http://forums.pearpc.net/viewtopic.php?p=16178#161 78
http://www.tliquest.net/ryan/cherryos/
http://dhost.info/kourge/en/projects/frauds/cherry os.php

Additionally, PearPC project authors are already asserting their rights under the GPL:

http://sourceforge.net/mailarchive/message.php?msg _id=11116974

And a general compilation of some of the evidence so far against CherryOS:

http://sourceforge.net/mailarchive/message.php?msg _id=11125509

I'd love it if they'd knock down some doors at Maui X-Stream. Unfortunately, that's probably what it will take.

Personally, I am amazed ThinkSecret is still publishing these rumours despite the lawsuit hanging over them. Nick Ciarelli certainly has balls ;)

Plenty of actual Mac developers would.

Wozniak does.

Woz is even contributing to the poor boy's legal fund.

No, you're thining of another case: three gentlemen who leaked a Tiger dev seed onto BitTorrent. This has nothing to do with this ThinkSecret case.

What I find really odd is the number of developers that DrunkenBatman has got coming out in support of Desicanuk. Quite useful though -- I now know whose software I can safely neglect to pay for.

Going by what [Apple's] asking for in the court papers, this isn't an area where they are planning on being particularly merciful when it comes to damages.

For the record, the supplied document lists Apple's requests as follows:

• Compensatory and examplary damages to be determined at trial
• Injunctions restraining the distribution of the software
• Injunctions restraining the breach of the agreements (not clear what that means)
• An accounting of any profits the defendants have derived from their distribution of the software
• The cost of the suit
• Any other relief the court deems just and proper.