 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Perl / June 2005CamelBones on Intel? Maybe not.
On the surface, today's announcement of a shift to Intel chips is great news for CamelBones developers - Perl code is not, after all, compiled for a specific CPU type. Given the presence of the appropriate supporting framework, Perl code should run just as well on a Mac/Intel as it does on a Mac/PPC. But there's the rub - the supporting framework. The problem is how Perl builds XS modules. The perl for which a module is targeted must be used to build it. So far, that's been workable - Copying the Jaguar and Panther perls to my Tiger partition was a bit of a nuisance, but once I had done that, they run just fine. An Intel-based perl interpreter is another matter entirely. My Mac is an old G4, and it won't run that. I won't be able to produce a supporting framework for Intel Macs without buying an Intel Mac. The question becomes, whether CamelBones by itself justifies such a purchase. To put it bluntly - no, it doesn't. I've been working on CamelBones for over three years now. Its original purpose was as a segue into a career as a Mac developer. That hasn't happened - I'm still unemployed. If anything, it has actually *hurt* my prospects - employers looking for a Perl developer have doubts because I haven't done any CGI work in 3-4 years, and those looking for Cocoa developers have doubts because I haven't published much Objective-C work. The handful of donations I've received (and to those few supporters, I extend a heartfelt "thank you"), have not been enough to purchase evan a Mac mini. Meanwhile, developers like Delicious are using Objective-C to write shareware apps that net them $250k in registrations in a single month. Reports like that have been making me *seriously* doubt the wisdom of what I'm doing. Sorry to vent folks, but this is seriously depressing. I've invested three years of my life into this, and the only result has been three years of unemployment and poverty. And now Apple tells me I have to make yet another major investment of money and time if I want to continue with it. I'm beginning to feel like Sisyphus, working on an endless and unrewarding task. This is not a decision to be made lightly, nor quickly. I'm not writing this to announce the end. But really, something's got to give here - I need to pay the rent, and so far, CamelBones isn't doing it. If something doesn't change - a job, serious financial backing, something - the end may not be very far off. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org I know what you mean, Sherm. Wish I could send you something to push into the iNTEL Mac world with, but I'm in the same position as you. Hope you can find a place that can see the value in understanding perl from the inside. If Perl 6 moves ahead, perl might go into the embedded world the way java hasn't yet really gone. For me, the computer industry just lost its last little bit of shine. I'm looking for a new career. Any general purpose computers I buy will run AMD since I doubt I'll be able to afford PPC hardware, and I'll be scratching Mac OS X from this old iBook this weekend. Not sure if I'll load Linux or openBSD on it, since it's my server. Jobs is insane. -- Joel Rees Nothing to say today so I'll say nothing: Nothing. > Jobs is insane. I'm not so sure about that. IBM seems unwilling or unable to produce mobile G5s, which is a market that Apple considers very important. They also are 2 years behind schedule on 3.0Ghz G5s, and appear to be focusing on video game processors instead of desktop and mobile processors. Apple might be OK in a speed comparison right now (on desktops, they are clearly losing in laptop comparisons), but how about in two years? Perhaps IBM has told Apple that they won't attempt a laptop chip, since the volume is way higher for video game consoles? What should Apple do? Personally, it looks like it will be a bit painful for a few years, but a far better move in the long run. Ian >> Jobs is insane. > [quoted text clipped - 8 lines] > Perhaps IBM has told Apple that they won't attempt a laptop chip, since > the volume is way higher for video game consoles? What should Apple do? They should have released Mac OS X for Intel as soon as they had it ready. Why wait? It seems Apple is too caught up in their own keynotes to understand volume sales. One thing M$ was definitely *always* better at. IBM will probably laugh this one to the bank, not exactly going to put a dent in that $99 billion in revenue... > Personally, it looks like it will be a bit painful for a few years, but > a far better move in the long run. Unless they become just another cheap clone maker with a pretty software interface. (Did I hear someone say Sun?) > Ian http://danconia.org >>> Jobs is insane. >> [quoted text clipped - 14 lines] > at. IBM will probably laugh this one to the bank, not exactly going to > put a dent in that $99 billion in revenue... Because it wasn't ready and obviously after watching the keynote they are still working on some things. They are trying (and it looks good so far) to make the transition as painless as possible. I think it is a good move. >> Personally, it looks like it will be a bit painful for a few years, but >> a far better move in the long run. > > Unless they become just another cheap clone maker with a pretty software > interface. (Did I hear someone say Sun?) Apple is not Sun in any sane comparison. >> Ian > > http://danconia.org >>>> Jobs is insane. >>> [quoted text clipped - 20 lines] > > Because it wasn't ready Five years and it still isn't ready? That's exactly why they shouldn't have kept it hidden in the lab if they were going to be doing it. > and obviously after watching the keynote they are > still working on some [quoted text clipped - 3 lines] > > I think it is a good move. If they were just saying, okay, we have had so many people begging for Mac OS X on iNTEL, we're going to give it to them and charge them double for running it on non-Apple hardware, that would be a good move. Moving everything to the monoculture is not a good move. >>> Personally, it looks like it will be a bit painful for a few years, >>> but [quoted text clipped - 5 lines] > > Apple is not Sun in any sane comparison. You think? >>> Ian >> >> http://danconia.org > I'm not so sure about that. IBM seems unwilling or unable to > produce mobile G5s, which is a market that Apple considers very [quoted text clipped - 12 lines] > > Ian I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. Secondly, it kept crashing. It destroyed the culture. It was like putting Haydn into the juke box at a disco. Everyone went home. The vice president of our division, who bet his career on NeXt, resigned and NeXt languished for years. It is the same scenario playing out again. Will Steve Jobs never learn? BTW, I have just installed Tiger and I am not pleased. It seems buggy. Try to print from the Mail.app, it takes my system about 60 seconds to have the print menu come up. And shameless marketing: do we really need to have the "order supplies from Apple" button in our face every time we print. Joe. > I used to be a NeXt developer. This announcement is very > reminiscent of the NeXt announcement to stop making those little [quoted text clipped - 8 lines] > It is the same scenario playing out again. Will Steve Jobs never > learn? Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Ian >> I used to be a NeXt developer. This announcement is very reminiscent >> of the NeXt announcement to stop making those little black boxes and [quoted text clipped - 12 lines] > will have a different CPU. You still won't be able to install OS X on > a commodity PC without jumping through a lot of hoops. Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI -> IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. > I think the only way that you look at it is that if IBM couldn't or > wouldn't deliver the processors Apple needed at a reasonable price, > what else could Apple do? Will definitely agree with you there. Though you have to love the media spin making it seem like this is Apple's choice to drop IBM, uh huh. > Ian I like Macs as much as the next person, but if they are going to go the Intel route, they might as well go the whole way. In fact being able to install on a normal Dell, would be one way for them to win back some huge user spaces, lots of companies would love to get out from the M$ licensing structure, but just aren't willing to fork out that much cash for all new hardware when they shouldn't need to, aka just to run another Intel based OS, and admittedly Linux is much harder to learn (or at least seems it). Not to mention theoretically (ask your lawyer, anyone know for sure?) they should be able to transfer over their Adobe/Office licenses which run natively. http://danconia.org > Why wouldn't you? Memory, drives, video, etc. are all the same right > now. Motherboard has pretty standard features, other than it is setup [quoted text clipped - 7 lines] > and won't let you install on a commidity PC then they really missed the > boat, in fact I would say they couldn't even find the dock. Quoting cnet <http://news.com.com/Apple+throws+the+switch%2C+aligns+with+Intel+- +page+2/2100-7341_3-5733756-2.html?tag=st.next> > After Jobs' presentation, Apple Senior Vice President Phil Schiller > addressed the issue of running Windows on Macs, [quoted text clipped - 6 lines] > "We will not allow running Mac OS X on anything other than an Apple > Mac," he said. Shades of Sony... > I used to be a NeXt developer. This announcement is very reminiscent > of the NeXt announcement to stop making those little black boxes and > bring NeXt OS on Intel chips. We had just bought a ton of hardware and > they demo this clunky 386 PC. First of all, it looked nasty. We were > used to that elegant design. I've got a NeXTStation and MegaPixel Display in my garage for anyone who wants to pay the shipping on it. ;) Pete > For me, the computer industry just lost its last little bit of shine. For me, it lost that shine years ago. When I began learning to program, everything was new. Every week, it seemed, someone was finding a new use for these gadgets. Games could be written by one person in two months. My heroes were people like Jobs, Wozniak, Nolan Bushnell, Eugene Jarvis, Richard Garriott, Sid Meier, and Roberta Williams - pioneers in every sense of the word. Shigeru Miyamoto deserves a place on that list too, but I didn't know his name back then, even though I greatly admired his work, without having a clue whose it was. These days, there's very little true innovation is going on. Most of the effort is put into squeezing a few more pennies from the bottom line. Games are designed and produced by the same committee-driven process that has reduced Hollywood and the music industry to mockeries of their former selves. Things have changed, and the Almighty Buck is king now. Pragmatically, that's a good thing; it's a sign of progress towards a mature, stable industry. In another way, I can't help feeling that something valuable has been lost along the way. > Any general purpose computers I buy will run AMD since I doubt I'll > be able to afford PPC hardware, and I'll be scratching Mac OS X > from this old iBook this weekend. Not sure if I'll load Linux or > openBSD on it, since it's my server. > > Jobs is insane. I'm not sure I'd go quite that far. There's a good business case to be made for switching, from Apple's perspective. It will help the supply-side problems they've been having, and broaden the appeal of their products. To most developers using Cocoa or Carbon, building a "fat" binary is painless - it's a matter of checking the right box in Xcode. The problem I'm facing is that for CamelBones, because of the way Perl builds its modules, the transition will be far more painful than it will be for most apps. I'm not seriously considering a switch to Windows or Linux, or anything along those lines. I doubt I'll ever truly and completely abandon CamelBones, either. Basically what I'm considering right now is whether I can continue making CamelBones my primary focus, or whether I should shift it to the back burner for a while and focus on something more likely to help me either find a job or make a living on my own. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org > To most developers using Cocoa or Carbon, building a "fat" binary is > painless - it's a matter of checking the right box in Xcode. The > problem I'm facing is that for CamelBones, because of the way Perl > builds its modules, the transition will be far more painful than it > will be for most apps. Why would it be painful to compile perl and its modules as a fat binaries? I see that perl's hints/darwin.sh override the $archname with this comment: # Since we can build fat, the archname doesn't need the processor type archname='darwin'; Has anybody ever tried to build a fat perl? --Gisle > Why would it be painful to compile perl and its modules as a fat > binaries? *If* Apple compiles a fat perl ... and *if* that fat perl doesn't require me to buy an Intel/Mac with money I don't have ... and *if* that fat perl is configured properly to produce fat XS modules ... and *if* the ffcall library that CamelBones uses is updated to support Darwin/x86 calling conventions ... If all that works out perfectly, then the problem's not fatal. But... that's a *lot* of ifs, and even if it's not fatal, it will still be a substantial amount of work, for a project that's already been a lot of work already. Please don't get me wrong folks! I'm profoundly grateful for the moral support you've given me over the past several years, but the plain fact is, I'm between a rock and a hard place. I have to take a cold hard look at what I'm doing, and decide whether it's helping me find a job and get out of the hole I'm in - and if it can't, whether the time spent doing it would be better spent doing something that will. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org Is there any reason you would NEED to compile it fat? Does anybody expect that the same partition will boot on both x386 and PowerPC macs? Ian >> Why would it be painful to compile perl and its modules as a fat >> binaries? [quoted text clipped - 6 lines] > and *if* the ffcall library that CamelBones uses is updated to > support Darwin/x86 calling conventions ... >>>>> "Ian" == Ian Ragsdale <ian@SKYLIST.net> writes: Ian> Is there any reason you would NEED to compile it fat? Does anybody Ian> expect that the same partition will boot on both x386 and PowerPC macs? The problem is distribution. If I want to upload my Cocoa program that happens to have Perl for its wiring, I can't presume whether the downloader has X86 or PPC needs. That is, it would make Perl-based programs require two versions, while Objective C or Java programs be fat binaries. That'd look "odd" in the marketplace.  SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > Is there any reason you would NEED to compile it fat? Does anybody > expect that the same partition will boot on both x386 and PowerPC > macs? No, but end users will expect a downloaded binary to be able to work on either one. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org Hi Sherm. For those who don't know me, I'm the perl maintainer at Apple, and I admit I keep a low profile on this list. But I wanted clear up a few things: >> Why would it be painful to compile perl and its modules as a fat >> binaries? > > *If* Apple compiles a fat perl ... As Steve said at the keynote, we've been building Mac OS X for i386 since the beginning, and that includes perl. As a matter of fact, the Darwin sources are the very source we use to build both ppc and i386. > and *if* that fat perl doesn't require me to buy an Intel/Mac with > money I don't have ... I forget which session it was in, but it said you can build both ppc and i386 on both platforms. Though I don't remember if it was mentioned in these terms, what they meant is that gcc-4.0 supports native and cross-compilation (and again from Steve's statement, previous versions of gcc did as well). It was just that we never shipped anything but the native ppc compilers. My understanding of the i386-based Mac development platform is that it will include all the native and cross-compliers, as well as all the frameworks, libraries and other binaries in fat form. While Apple could do this with a ppc machine, you couldn't then actually test that it really worked on an i386, so (I'm assuming) that is why it's shipping on i386. No promises, but if you want to work on CamelBones for i386, I can put out some feelers and see if we can help someway. > and *if* that fat perl is configured properly to produce fat XS > modules ... This is a little tricky, but doable. Because we build fat, we have to edit Configure.pm to remove that fact, otherwise it would always try to build fat, and fail for most people, since the cross-compiler is not available. But you can pass the appropriate flags to a perl module so it will build fat; that is what we do to build the things in /System/Library/Perl/Extras (on Tiger), for instance. > and *if* the ffcall library that CamelBones uses is updated to > support Darwin/x86 calling conventions ... For what it's worth, in my testing last year, I built CamelBones-0.2.3 fat, with a few changes to work with our build system. I never really got around to testing it on a i386, but it did compile. ------------------------------------------------------------------------ -- Edward Moy Apple >> and *if* that fat perl doesn't require me to buy an Intel/Mac with >> money I don't have ... > > I forget which session it was in, but it said you can build both > ppc and i386 on both platforms. That's very good to know - it takes some of the immediate pressure off. > No promises, but if you want to work on CamelBones for i386, I can > put out some feelers and see if we can help someway. There's been some discussion on the Perl 5 Porters' list as well, wondering if Apple could set up accounts on a 'net-accessible machine. Such a machine would be helpful to several others besides myself. The latest CB version supports standalone .pl scripts. So an account on a shared machine would be quite adequate to for me to run the CB self-tests. > This is a little tricky, but doable. Because we build fat, we have > to edit Configure.pm to remove that fact, otherwise it would always > try to build fat, and fail for most people, since the cross- > compiler is not available. But you can pass the appropriate flags > to a perl module so it will build fat; that is what we do to build > the things in /System/Library/Perl/Extras (on Tiger), for instance. Not a problem - As of the second 1.0 release, the Makefile I'm using is already set up to use the Xcode SDKs anyway. All of the release binaries - Jaguar, Panther, and Tiger - are built under Tiger using the appropriate SDK. In fact, there is already at least one place where a preprocessor flag is defined only for a specific SDK, to silence a particular warning. So the groundwork is all there already - if all that's involved is adding a few compiler and/or linker flags for the 10.4u SDK, that will be easy. >> and *if* the ffcall library that CamelBones uses is updated to >> support Darwin/x86 calling conventions ... > > For what it's worth, in my testing last year, I built > CamelBones-0.2.3 fat 2.3 didn't use ffcall. :-( Frankly, I'm not *too* worried on that score, although it's a critical piece of the puzzle. Either ffcall or ffi will be updated sooner or later, I'm sure. Switching to ffi would be a bit tedious, but not difficult. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org > There's been some discussion on the Perl 5 Porters' list as well, > wondering if Apple could set up accounts on a 'net-accessible machine. > Such a machine would be helpful to several others besides myself. The > latest CB version supports standalone .pl scripts. So an account on a > shared machine would be quite adequate to for me to run the CB > self-tests. Yeah, I was thinking the same thing. Access to a compile & test farm would be really nice for those of us who can do all of our testing in the shell environment. -Ken >> No promises, but if you want to work on CamelBones for i386, I can >> put out some feelers and see if we can help someway. [quoted text clipped - 5 lines] > an account on a shared machine would be quite adequate to for me to > run the CB self-tests. I doubt they are going to allow this, especially for a non-released product. I spoke with a few people in marketing, and it is already a touch sell, because there is no critical mass yet. They keep pointing to the success of PyObjC and how that community has gelled. Our resources are limited and we can't be throwing our money around for things that don't pay off. So what is really needed at this point is for the CamelBones community to get together and innovate. Create some killer apps with CamelBones. Get developer excited about this technology. Edward Moy Apple > So what is really needed at this > point is for the CamelBones community to get > together and innovate. > Create some killer apps with CamelBones. Get > developer excited about > this technology. I'll bite. Dunno if it'd count as "killer" or not but I have a F/OSS project I've been working on that's been looking for a GUI for a while. We were going to go with Python for cross-platformability, but I've been thinking about learning Cocoa for a while and have really wanted to use CB for *something*. Hey Sherm, I haven't toyed with CB since the days of 10.2, anything I should know before diving in again? Live well, ~wren __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Good evening, On 9/6/05 at 2:39 AM -0700, wren argetlahm <phreelance@yahoo.com> wrote: >Hey Sherm, I haven't toyed with CB since the days of >10.2, anything I should know before diving in again? And are there any licensing issues that would prevent using CB in a commercial app? Charlie SignatureCharlie Garrison <garrison@zeta.org.au> PO Box 141, Windsor, NSW 2756, Australia > And are there any licensing issues that would prevent using CB in a > commercial > app? No. I chose the Lesser GPL over the GPL for precisely that reason - the "viral" aspect of the license applies to the framework *only*, not to your apps. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org On Jun 9, 2005, at 4:39 AM, wren argetlahm wrote: >> So what is really needed at this >> point is for the CamelBones community to get [quoted text clipped - 11 lines] > about learning Cocoa for a while and have really > wanted to use CB for *something*. It seems like the Fink Commander application could also have been written well in CB. It's an example of a fairly broad category of applications: Cocoa interfaces to perl modules. What with the depth & breadth of CPAN, that's seems like it would be a pretty broad category. -Ken > Hi Sherm. For those who don't know me, I'm the perl maintainer at > Apple, and I admit I keep a low profile on this list. But I wanted > clear up a few things: Well, Ed, I'm not Sherm, and I don't have any claim to fame, but I wish you could clear up why Steve would do something as insane as inserting Apple into the x86 monoculture. I'd have no complaints if Apple were offering Mac OS X86 boxes as a second line. I don't buy the megahertz myth, so I have no problem paying a little higher price for the PowerPC Mac Mini compared with an x86 of similar clock, even with the FSB rate a tenth of the CPU clock instead of a half. On the contrary, low average power on the Mac Mini fits it into the Japanese power budget just fine. The most frustrating part of Mac OS X is the lack of product range. For instance, I'd love a PPC box the size of the Mac Mini at half the spec and loaded only with Darwin, but with an extra NIC, for $300. (I'd by three at $200 each, but I'm trying to make a point here.) The current speed/power is only a serious detriment to a bunch of critics who won't be buying Macs anyway. (And, just between you and me, but I don't see why Steve is so enamored of Pentium M, especially without seeing whether iNTEL can actually push that piece of junk up to 64 bits.) Anyway, if you by any chance have a communication path up high enough to reach whoever decided that PowerPC had to be dropped, I'd appreciate it if you could be so kind as to pass on a request to keep the PowerPC line going as long as it doesn't just totally bleed red ink across multiple quarters. -- Joel Rees The master plan in open source is simple: The user figures out what he or she needs and does it. I'm just a lowly engineer, so such decisions are way above me. I can only hope that the decision makers know what they are doing. If you believe that Apple can create products at the same price as a pc knockoff company down the street, you are going to be constantly disappointed. Apple does not build hardware; it builds systems. That includes the software. Our overhead (such as my paycheck ;-) is always going to be higher because we have to pay for all the development costs. And because are systems require unique parts, created at a much lower volume than in the pc world, our hardware costs are also going to be higher. We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. As you say this OT, so I should not comment further on this. Edward Moy Apple >> Hi Sherm. For those who don't know me, I'm the perl maintainer at >> Apple, and I admit I keep a low profile on this list. But I [quoted text clipped - 32 lines] > The master plan in open source is simple: > The user figures out what he or she needs and does it. >We hope that the additional price our customers pay is justified by >the fit-n-finish that we put into the systems. The beachballs in Tiger are terrific! If I'd paid the full price for the upgrade I'd be seriously considering demanding my money back. JD >> We hope that the additional price our customers pay is justified >> by the fit-n-finish that we put into the systems. [quoted text clipped - 3 lines] > > JD I am hating Tiger, it is so slow many places, I will reload Panther this weekend. The spotlight thing is nice but the performance overhead is unacceptable. Joe. How does directing this sort of thing at someone who worked on a tiny little bit of Tiger, which you guys seem to use personally, help anything at all? Unless you have complaints about perl on Tiger, these comments seem inappropriate. If anything, I'd be thankful to have an engineer who works on perl for Apple on this list. Personally, Tiger works great for me, and I'd like to thank everyone involved in working on it. Ian >>> We hope that the additional price our customers pay is justified >>> by the fit-n-finish that we put into the systems. [quoted text clipped - 7 lines] > this weekend. The spotlight thing is nice but the performance > overhead is unacceptable. Sorry to catch you between my irritations and Steve. This isn't aimed at you, this is aimed at the decision makers at Apple. I'm just hoping someone upstairs will see this in this archive. > I'm just a lowly engineer, so such decisions are way above me. I can > only hope that the decision makers know what they are doing. From where I stand, they seem not to see the forest for the trees. Maybe Dvorak should be banned reading on the Apple campus. One thing is guaranteed, he is always wrong. And when he is right, he is dead wrong. Giving in to the monoculture mindset is the last thing Apple should do. > If you believe that Apple can create products at the same price as a > pc knockoff company down the street, you are going to be constantly > disappointed. Apple does not build hardware; it builds systems. Two nics on a Mac Mini screams, "Systems!" Tweak the Mac Mini a little and it would be the perfect platform for any number of intelligent routers, and, yes, Apple is selling a router right now, so we know routers are on Apple's roadmap. Routers are a key point in any real systems solution, and routers that the customer can tweak would be a huge plus. "Intelligent router" means things like perl built in, by the way, so it isn't that far off topic. And, no, a wonderful OS is not a systems solution unless Apple can turn the corner here. You guys seemed to be turning straight into monoculture's defensive line, and those guys are huge and are going to tear you to pieces. > That includes the software. Our overhead (such as my paycheck ;-) is > always going to be higher because we have to pay for all the > development costs. Not all, not be any means. Apple needs to learn to use their user community more effectively, and one thing that is not effective is suddenly saying, "Hey, all you guys that were trying to avoid the monoculture by working with us, sorry, but you have to join us in the monoculture now." > And because are systems require unique parts, created at a much lower > volume than in the pc world, our hardware costs are also going to be > higher. Fine. But Apple has a nice capital reserve, and that reserve has not been shrinking. Nor has Apple been losing position in the market, for all the weeping, wailing, and gnashing of teeth on the part of the pundits. > We hope that the additional price our customers pay is justified by > the fit-n-finish that we put into the systems. You can't add fit-n-finish without help from the customers. (That is one way of describing the entire meaning of the open source community.) > As you say this OT, so I should not comment further on this. And neither should I have, but sometimes etiquette has to go by the board. Apple seems to be going backwards from the "listen to the customer" attitude that brought them this far. IBM may be paying too much attention to the game console market right now, and that may hurt Apple temporarily, but moving all the eggs to the iNTEL basket is a serious strategical error. > Edward Moy > Apple [quoted text clipped - 35 lines] >> The master plan in open source is simple: >> The user figures out what he or she needs and does it. -- Joel Rees Getting involved in the neighbor's family squabbles is dangerous. But if the abusive partner has a habit of shooting through his/her roof, the guy who lives upstairs is in a bit of a catch-22. >> For me, the computer industry just lost its last little bit of shine. > [quoted text clipped - 9 lines] > > These days, there's very little true innovation is going on. I hit that point with MSW3. The first tarnish was in realizing how few other people saw the magic I saw in FORTH. But it was MSW3 that opened my eyes to the fact that there really were a lot of people who really did want Bill Gates or somebody to do their thinking for them. > Most of the effort is put into squeezing a few more pennies from the > bottom line. Games are designed and produced by the same [quoted text clipped - 14 lines] > > I'm not sure I'd go quite that far. Monoculture. The only successful alternative OSses that run on x86 yet are entirely free (as in speech) and run on multiple platforms. Even FreeBSD is not just x86. I would not be going rabid if Steve had said, "Okay, due to popular request, we're going to add an architecture." or something similar. Apple has the resources to sell to multiple architectures, although it would likely mean that they would need to open up quite a bit of the userland beyond the command line. > There's a good business case to be made for switching, from Apple's > perspective. Only if they have blinders and and don't notice anything wrong with the picture being dangled in front of their face. > It will help the supply-side problems they've been having, and broaden > the appeal of their products. Oh, sure. What is this thing about iNTEL having some sort of appeal? That''s a strawman, and the people who have been arguing it will not be buying it. IBM made a few too many forward looking statements without knowing how much the fancy non-RISC address modes (etc.) were going to cost in heat and timing. But, except for certain server software where the context switch overhead (FreeBSD's giant lock, the way I read it) drags the system down, the speed is close enough when you put Macs side-by-side with x86 boxes. The server speed problems will not be fixed with iNTEL, because it's from the OS's context switching overhead. Pentium D looks good in the lab, but I'm not going to let it eat _my_ lunch in the real world. And I do not want monoculture buffer overflows killing my servers. And Cell should not be a bad option, particularly if Apple's looking at a re-compile anyway. > To most developers using Cocoa or Carbon, building a "fat" binary is > painless - it's a matter of checking the right box in Xcode. The > problem I'm facing is that for CamelBones, because of the way Perl > builds its modules, the transition will be far more painful than it > will be for most apps. It's going to be painful basically for everybody who isn't already compiling cross-platform, and, as you point out about Python, painful even with some that are compiling cross-platform. > I'm not seriously considering a switch to Windows or Linux, or > anything along those lines. I doubt I'll ever truly and completely [quoted text clipped - 3 lines] > something more likely to help me either find a job or make a living on > my own. Well, after all the rant, I have to admit that I hope you can get CamelBones moved onto the new platform okay. Just because I'm convinced it's going to crash and burn doesn't mean everybody should give up on it. -- Joel Rees (A FORTH dreamer imprisoned in a Java world) Hey Sherm, I have two suggestions. Since I know you to be a very good programmer with a very good knowledge of how things work under OS X, I suggest going straight to Apple and pitching the idea of developing CamelBones for them. It could work out quite well if the arrangement is crafted well enough. Or, set up a storefront and start charging some money for a "premium" version of camelbones, or charging a specific amount of money for support licenses. But to be honest, I'm not surprised you haven't received enough donations yet to keep afloat. A google search for "camelbones donate" gives no useful results, nor did I see any invitation to donate by browsing on your site. But even if it were there, I don't think donations make a business model. Support licenses and premium products can, though. -Ken > This is not a decision to be made lightly, nor quickly. I'm not > writing this to announce the end. But really, something's got to give > here - I need to pay the rent, and so far, CamelBones isn't doing it. > If something doesn't change - a job, serious financial backing, > something - the end may not be very far off. > I suggest going straight to Apple and pitching the idea of > developing CamelBones for them. Been there, tried that - three times now. The first time was before Jaguar's release; Apple opted to include their own in-house bridge instead. Again, before Panther, and again before Tiger. Each time, there was some interest - a lot of Apple engineers appear to like CamelBones - but not enough to push it through Apple's internal process to get it included. To Apple's credit, they *have* provided me with free access to beta OS releases. > Or, set up a storefront and start charging some money for a > "premium" version of camelbones, or charging a specific amount of > money for support licenses. I've thought about doing that, but I have my doubts. I was registered a couple of years ago to give a talk about CamelBones at O'Reilly's OSCON. Only three or four people registered for it, so it was cancelled due to lack of interest. O'Reilly had plans to publish a book about Cocoa/Perl development, but again the idea was shelved due to lack of interest. Realistically, if a major publisher can't drum up enough interest to warrant a single talk, or one book, I don't think my chances of making a living from support fees are very good. The primary use I imagined for CamelBones is for in-house databases, where it would be useful to be able to re-use a lot of the same code to build both web-based external interfaces and GUI internal interfaces. That space is filled with a lot of heavy hitters though - Sun, IBM, even Apple themselves, now that WebObjects is included with Xcode 2.1. I've thought of writing standalone shareware apps. But nothing I've thought of has really cried out to be written in Perl. I'm not at all religious about languages. There are a handful of scenarios (like the one I mentioned) where having the option to use Perl in a Cocoa project is a life saver. But most of the time, the native language of the toolkit is the best choice - Tcl for Tk, C++ for Carbon or Qt... and Objective-C for Cocoa. Bottom line is, CamelBones is a niche product. I've known that from the beginning, and I'm not complaining about it. It's a big enough niche to make CamelBones a fairly successful OSS project. But it's not a big enough niche to make a living, and making a living is what I need to focus on, at least in the short term. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org >>>>> "Sherm" == Sherm Pendley <sherm@dot-app.org> writes: Sherm> I've thought about doing that, but I have my doubts. I was registered Sherm> a couple of years ago to give a talk about CamelBones at O'Reilly's Sherm> OSCON. Only three or four people registered for it, so it was Sherm> cancelled due to lack of interest. O'Reilly had plans to publish a Sherm> book about Cocoa/Perl development, but again the idea was shelved due Sherm> to lack of interest. I'm giving a talk at WWDC on wednesday about "Perl as Glue on OSX", and I drool over CamelBones. I'll let you know if my drool is appropriate after wednesday. It'll be interesting to see if the comments in the room reflect the desire for Perl-wired Cocoa apps or not. In fact, the first thing I thought after hearing about the x86 announcement was "oooh, I hope CamelBones continues to work!". SignatureRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > In fact, the first thing I thought after hearing about the x86 > announcement was "oooh, I hope CamelBones continues to work!". Of the trouble points I mentioned - a "fat" perl, a tool chain that will build "fat" binaries while running on PPC, and "fat" perl being configured to use that tool chain to build "fat" XS modules - I think it's reasonable to think that either Apple or p5p will deliver those. The biggest sticking point is libffcall. That's truly key - it provides the crucial piece that allows me to take arguments from Perl's stack, and use them to build up a set of arguments to call objc_msgSend(). Ffcall will need to be updated to understand the Mach- O/x86 calling convention - whatever that is. (I don't think Apple has documented it yet.) If ffcall doesn't get updated, a switch to libffi is workable - it's not a drop-in replacement, but it works similarly. So really, the big question isn't really whether CB can continue - I'm pretty certain that it can. The question is whether *I* can afford to continue working on it. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org Hi Randal (I'm going to be on the panel that Randal will be speaking at). Let me say that PyObjC (the python equivalent to CamelBones) is getting a lot of attention recently, and the Python on Mac OS X session at WWDC on Wednesday morning talks a good deal about PyObjC (I also maintain python for Apple). I personally think that CamelBones hasn't quite reached the critical mass that PyObjC has, but it could still happen. So I hope that the CamelBones community doesn't give up hope so soon. We had wanted to ship both CamelBones and PyObjC with Tiger, but for various reasons, it was punted. But we are shipping wxWidgets with perl and python support, and tkinter for python, because we do have customers who want to do GUI applications with scripting languages. Edward Moy Apple >>>>>> "Sherm" == Sherm Pendley <sherm@dot-app.org> writes: > [quoted text clipped - 17 lines] > In fact, the first thing I thought after hearing about the x86 > announcement was "oooh, I hope CamelBones continues to work!". They say misery loves company - so here it is: "Python on Mac OS X for Intel is not going to be a seamless transition." <http://bob.pythonmac.org/archives/2005/06/06/python-on-mac-os-x- x86> sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org So, how can we help? I do doubt that long-term Camelbones can support you if it hasn't already, but specific one-time causes can often get quite a bit in the way of donations. If you need an Intel Mac to continue builds, post a goal and a link to donate. I bet you'll make your goal. Daniel T. Staal ------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------ > So, how can we help? > > I do doubt that long-term Camelbones can support you if it hasn't already, > but specific one-time causes can often get quite a bit in the way of > donations. If you need an Intel Mac to continue builds, post a goal and a > link to donate. I bet you'll make your goal. I just read an editor's note at Maccentral (it's listed under June 6) . . . apparently the development kit that Apple is offering for this transition gets you that 3.6GHz Pentium P4 Mac. Now, I know $999 is a lot of money for Sherm, with him being out of work for 3 years. But I think there is always a way to get out of any predicament, it just may involve "thinking out of the box". I sympathize with Sherm's dilemna. I'm a web programmer who's been working with ColdFusion for the past 4 years or so. Now Macromedia is going to be merging with Adobe, and the picture is very murky right now. One approach is to go in the LAMP direction so as to diversify, and in my recent performance review, we've agreed that I will have the opportunity to leran another programming language, like PHP. There are applications still waiting to be written that doesn't exist on the Mac platform. For instance, I'm a knitter. There's a lot of program out there to design sweater and sock patterns, and to design fair isle, aran, and intarsia designs. However, there's only two commercial (no shareware that I can locate) software that Cochenille Designs (http://www.cochenille.com/) and these programs are stuck in the "Classic" time warp and the company doesn't seem inclined in the near future to update these programs to work with OS X (no, I don't want to run Classic, and haven't done so for the past year or so). There's no competition in the picture that I can see. I wish I could create that application taht would run circles around Cochenille's products, but I don't the Objective-C programming language and it would take me quite a while before I could get up to speed (especially since I haven't created stand-alone applications). SignatureLola - mailto:lola@his.com http://www.lolajl.net | Blog at http://www.lolajl.net/blog/ Terrorismus delendus est! (Terrorism must be destroyed utterly!) I'm in Bowie, MD, USA, halfway between DC and Annapolis. > in my recent performance review, we've agreed that I will have the > opportunity to leran another programming language, like PHP. Ouch. That hurts. PHP? Did you tell them you already know a *sane* LAMP language - Perl? > There are applications still waiting to be written that doesn't > exist on the Mac platform. For instance, I'm a knitter. So, what you need is a Cocoa/Purl bridge, then? :-) > I wish I could create that application taht would run circles > around Cochenille's products, but I don't the Objective-C > programming language and it would take me quite a while before I > could get up to speed (especially since I haven't created stand- > alone applications). I think this is the most practical course for me to take. I won't be abandoning CamelBones, not by any stretch. But I do think I need to change my main focus, at least in the short term, from being the CamelBones maintainer to being a Cocoa developer. The reason is simple economics. A one-time fund raiser won't cut it - I'm worried about paying the rent, not about buying my next Mac. I need a job, or at least a source of some kind of income. I have modest needs and I live *way* off the beaten path, where rent is cheap. I think I can get by on shareware fees. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org My main question about the change to Intel is why the developer pack, whatever it was, costs so much? What do you get for your $999? I was expecting something free to download to developer members. > My main question about the change to Intel is why the developer pack, > whatever it was, costs so much? What do you get for your $999? I was > expecting something free to download to developer members. They throw in a Pentium4 / 3.x gHz computer with the deal. Phrase it that way and it's actually kind of cheap... :-/ SignatureChris Devers still baffled by what this all means > > My main question about the change to Intel is why the developer > > pack, whatever it was, costs so much? What do you get for your $999? [quoted text clipped - 3 lines] > > Phrase it that way and it's actually kind of cheap... :-/ Be careful to double-check the agreement. I hear you don't get to own the hardware and have to return it by the end of the year. I may have heard wrong, but you may want to make sure before you sign up for it. Cheers, -Jan >They throw in a Pentium4 / 3.x gHz computer with the deal. > >Phrase it that way and it's actually kind of cheap... :-/ Oops. I must have missed that part in the excitement! So that means IntelMacs (MacTels? PentiuMacs?) will be out in the wild very shortly, in that sense at least. How interesting. --As of Wednesday, June 8, 2005 9:02 AM +1000, John Horner is alleged to have said: > My main question about the change to Intel is why the developer pack, > whatever it was, costs so much? What do you get for your $999? I was > expecting something free to download to developer members. --As for the rest, it is mine. As others have said, they throw in a computer. However, you *can* download the latest version of XCode and it can compile fat binaries, if I recall correctly. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- >>My main question about the change to Intel is why the developer pack, >>whatever it was, costs so much? What do you get for your $999? I was >>expecting something free to download to developer members. > >As others have said, they throw in a computer. Keep in mind the Developer Transition System hardware is only on loan and needs to be returned (by the end of 2006 I think) and has other restrictions (basically, I think Apple is treating it like the normal Seed hardware which is loaned, not sold, and has lots of restrictions, like fixed location, etc). Not that I can find any actual details on this currently, but if you read: http://developer.apple.com/transitionkit.html You will note it says "Use of a Developer Transition System", not actual ownership of. Personally, I prefer the Be hardware seeding (they gave me a free box, and then another one later when they upgraded them), but then it didn't work out that well for Be in the end unfortunately... Peter. Signature<http://www.stairways.com/> <http://download.stairways.com/> |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.