No, I am correct, and you are incorrect. The story may have have been posted back then in another form, but since the episode where the individual was exposed as a traitor was aired for the first time only last week, "this article" could not have been posted more than six days ago. OOPSIE FOR YOU.
I am not arguing that it is not Bad for drives to be damaged by such things. Yes, ideally, you are right, the drives should gracefully fail by ejecting the problem discs, or something. I am saying, however, that when someone exploits that "bug" or "misfeature" or whatever you wish to call it -- even if is not an intent, but merely a known consequence, to damage the mechanism -- then the parties doing the damaging are to "blame." It's not like they are doing something that is supposed to be done. They are going outside the agreed-upon specs, with the full knowledge that it will cause damage to some mechanisms. Whether or not the damage could have been prevented by better engineering beforehand is irrelevant to the culpability of those employing the copy protection scheme. And I am not sure if a disclaimer about it not working on PCs is sufficient to absolve them.
If some black-hat hackers were stealthily distributing CDs designed to exploit the CD standards to make mechanisms fail, you'd probably say these guys were crooks. But if Sony does the exact same thing, it's the PC manufacturer's fault? Besides, Apple didn't design a one of their CD mechanisms, they are all third-party, and PC drives can be damaged too.
Sorry, but how is this fair? As to cost-effectiveness, that's irrelevant, since we all know that a $1200 Mac will be more cost-effective than a $500 PC in terms of maintenance and support, let alone resale value (or tax writeoff, but I don't know if they have those in this case:-). And to visibility, these are mostly for in-office staff. The reason 'iBook' was mentioned is because it was for a temporary office space, I imagine, so laptops made sense.
Perhaps visibility and cost-effectiveness at least could be argued, though not very convincingly, by the Windows crowd. But stability and security? Not even close. Windows has never been as secure as Mac OS was, and probably never will be as secure or as stable as Mac OS X is. Of course it has a proven track record in stability: overwhelmingly, most Mac OS X users have never had a system crash. What else do you want?
And if you want "proof" about security then the counterargument is that Windows has been proven to be entirely insecure, and can make no claims about anyone else not having a proven track record without totally destroying their own credibility. Windows is the most insecure OS ever.
"Any time you are *forced* to use the command-line to fix a problem (get something done?), it is a failure of the OS."
Bah. Any GUI that can provide everything that *I* need to get done is going to be unwieldy, at best. The GUI cannot perceive of everything that I might need to do. It's simply not possible. And if you call that a failure of the OS, then the very concept of GUIs is fundamentally flawed. The GUI should be as complete as possible/reasonable, but it cannot ever cover every need of the user.
Nowhere does it say I was using telnet anywhere. The program's name is NiftyTelnet. It can connect via ss1 or telnet protocols. It also doesn't say I've been a Unix geek for 15 years, but a Mac user for 15 years (I've been using Unix for about 10 years). Bah, who needs reading skills?
It only shows up on the main Slashdot page if you have "collapse sections" set. Yeah, it is not ideal. I think someone is working on code to allow you to assign a story to multiple sections. But until that happens... c'est la vie.
Yes, you can set it to that res, but it will look like crap. There's a fixed number of pixels; to get a lower res you have to use anti-aliasing, pixel doubling, etc.
I concede that the iBook 12" looks sharper than the TiBook in Mac OS X, but I dislike how Mac OS X looks *anyway*, and use Mac OS, where the TiBook looks just as good.
Even if it didn't look just as good: I use my laptop and its screen 10+ hours a day, sometimes as many as 16 hours or more, and the iBook resolution is just too small, unless I wish to go blind. Now, for graphic design this wouldn't be as much of an issue, but I am a coder, and I need to look at lots and lots of text, and on the iBook it is just too tiny. Sure, I could bump up the font size some, but then I lose the real estate I just gained, and everything else is still too small for my liking.
I would guess because most people don't care. I use BBEdit under Mac OS X to write Perl and am perfectly happy with it. I wouldn't ever use ProjectBuilder to do Perl projects... unless they are tied to something like this, where you're doing Perl to tie into Cocoa. Maybe I am abnormal, though.
Yes, "Collapse Sections" makes all section-only stories -- except for isolated sections, which Slashdot doesn't use, and sections you've specifically excluded -- show up on the home page. I do it. Apparently some people do it without knowing and so think that this is showing up on the home page for everyone. It isn't.
Hey javidb, I have one box running Mac OS X, but I use it only for IRC, web browsing (when my other Mac is busy), playing MP3s, shells, etc. And as a test box for Mac OS X when I need one (such as last night, when I was playing around some more with making Mac::Glue work with Mac OS X apps).
Yes, you are mischaracterizing it. It is not even clear to me exactly what you want "fixed," but let's make one thing clear: there is exactly NO REASON to port MacPerl to Mac OS X. The bulk of your post seems to be asking for this, and yet there is NO REASON to ever do it. That is why it is not being done.
What you want is not a ported MacPerl, it is access to the Carbon API from perl on Mac OS X. Those are two different things. And in your post you presume unreasonable presumptions about this. As you clearly don't understand quite a few things, perhaps you should ask questions -- and heck, even read the existing responses that answer many of the questions you should be asking -- instead of making such presumptions.
(It's odd you say you can't complain, and then you complain... what's up with that?)
Some things you got wrong: as noted, there is no reason to Carbonize MacPerl. Further, there is no such possible thing as a port to Cocoa. The MacPerl access to the Mac OS API is based on Carbon; anything related to Cocoa wouldn't be a port, it would be a separate project. There are also several other alternatives beside OSXMacPerl, including, as noted in other posts, a project I am involved in to provide the Carbon API, which would work in both Mac OS and Mac OS X. Some of the alternatives even have working code that you could use today.
You also presume that my time would be better spent on Mac OS X, that I am "hiding my head in the sand." This is, as a point of fact, completely false. I don't use Mac OS X regularly, and won't use it regularly for the forseeable future. I am, and will continue to be, far more efficient using Mac OS than Mac OS X, and until that changes, cannot consider moving to Mac OS X a viable option. In light of that fact, it is somewhat amazing that I have actually spent as much time on Mac OS X as I have, doing some of the things you say I've not been doing. But the main point is that it is unreasonable for me to spend the majority of my spare time developing for a platform that I won't be using regularly any time soon. My time is mine, and I cannot fathom why anyone would gripe about how I use it.
Yes, I was using "release" in a certain sense, such as what is hinted at with the phrase "release candidate". A production release. A final release. A non-beta, non-development release. A release. By that common definition, MacPerl is based on the most up-to-date sources available. Calling it the most "advanced" was a *joke*, since obviously by many definitions it is *less* advanced, being on a non-POSIX OS.
So anyway, I don't consider porting or upgrading MacPerl to 5.7.3 to be interesting; when I am working on MacPerl with the current development branch, it is to whatever the latest source is; before perl 5.7.3 was even announced, it was already older than the source I'd be working from. So I work from the development source, not any particular version of it.
MacPerl 5.8 *will* come out later than 5.8, and maybe even by a few months. The two biggest obstacles I see are just porting any new code (hopefully minimal, although there are a handful of new modules, although *most* of the new modules in 5.8 are already in MacPerl!) and testing. The test suite has been totally overhauled, and I'd like to make sure all the tests pass as much as possible before releasing, which means porting any part of the test suite that need porting. Michael Schwern has done a lot of work on this, so hopefully I'll get to hug him for the great work he's done instead of punching him inna nose for making my life more difficult.:-) We'll see!
Plus, we might want to add some new features to MacPerl itself, like a new and updated built-in editor and some other shiny things. I might want to get those to work simultaneously with getting the other stuff done, and test them in the regular beta cycle with everything else.
HOWEVER... if you want, you can just download the source and tools and build your own MacPerl 5.8.0. You can, today, download the source and build your own MacPerl 5.7.3! Just get the perl 5.7.3 source and the recent MacPerl source, drop the perl/macos/ directory from the latter into the former, and then just follow the instructions (except that you will first need to uncomment a few additional source files for 5.7/8 in Makefile.mk: numeric.c, locale.c, pp_pack.c).
So you want MacPerl 5.7.3? Go build it!:) Some things may not work, but them's the breaks. If (collective, nonspecific) you really want to help, your help is welcome; join the macperl-porters mailing list.
There are many things you cannot do under perl for Mac OS X yet. perl for Mac OS X cannot compile raw Apple events. It cannot control QuickTime movies or do handle graphics or custom windows or menus or controls or speech. Well, actually, those things CAN be done, but not yet in any available distribution in any completed fashion.
I've seen the wrapper module you speak of, as I was contacted regarding it when it was first released. It only handles a tiny portion of the wealth of API access the MacPerl modules provide.
If you need to use MacPerl, well, Classic can take a long time to load, depending on your system. Anywhere from under a minute to several minutes. Once running, the script can run in less than a second, or a few seconds, depending on your system. Classic is a memory pig, but its performance is mostly the same as running Mac OS 9 by itself.
Re:Why the hell would you run it under Classic?
on
MacPerl 5.6.1 Released
·
· Score: 3, Insightful
Actually, no sir: I answered the spirit of the question precisely. You are asking a separate question, which is why I, personally, spent time MAKING MacPerl. As to that, I can only say that it is odd that you would presume to have a reasonable opinion of what is the best use of my own time and efforts, since you, of course, cannot.:-) Suffice it to say that it is more than worth the time and effort, as a point of fact, regardless of your opinion on the matter.
As to Carbon/Cocoa bindings for Mac OS X: they are in progress. But they are irrespective of MacPerl, except that they will, eventually, obviate the need for MacPerl on Mac OS X, and the Carbon bindings will likely work on both Mac OS and Mac OS X.
Because, as noted above, perl doesn't have access to the Mac OS API under Mac OS X yet. This will change, hopefully, but for now, if you want to run your old scripts that call Mac::Windows, Mac::Events, etc., then you need MacPerl, even under Mac OS X. I hope that before the end of the year, there will be no reason to run MacPerl under Mac OS X.
Slashdot Mirror
No, I am correct, and you are incorrect. The story may have have been posted back then in another form, but since the episode where the individual was exposed as a traitor was aired for the first time only last week, "this article" could not have been posted more than six days ago. OOPSIE FOR YOU.
Is it me, or was this article posted on Wired about 3 months ago?
If May 16, 2002 was three months ago, then no, it's not just you.
I am not arguing that it is not Bad for drives to be damaged by such things. Yes, ideally, you are right, the drives should gracefully fail by ejecting the problem discs, or something. I am saying, however, that when someone exploits that "bug" or "misfeature" or whatever you wish to call it -- even if is not an intent, but merely a known consequence, to damage the mechanism -- then the parties doing the damaging are to "blame." It's not like they are doing something that is supposed to be done. They are going outside the agreed-upon specs, with the full knowledge that it will cause damage to some mechanisms. Whether or not the damage could have been prevented by better engineering beforehand is irrelevant to the culpability of those employing the copy protection scheme. And I am not sure if a disclaimer about it not working on PCs is sufficient to absolve them.
If some black-hat hackers were stealthily distributing CDs designed to exploit the CD standards to make mechanisms fail, you'd probably say these guys were crooks. But if Sony does the exact same thing, it's the PC manufacturer's fault? Besides, Apple didn't design a one of their CD mechanisms, they are all third-party, and PC drives can be damaged too.
Sorry, but how is this fair? As to cost-effectiveness, that's irrelevant, since we all know that a $1200 Mac will be more cost-effective than a $500 PC in terms of maintenance and support, let alone resale value (or tax writeoff, but I don't know if they have those in this case :-). And to visibility, these are mostly for in-office staff. The reason 'iBook' was mentioned is because it was for a temporary office space, I imagine, so laptops made sense.
Perhaps visibility and cost-effectiveness at least could be argued, though not very convincingly, by the Windows crowd. But stability and security? Not even close. Windows has never been as secure as Mac OS was, and probably never will be as secure or as stable as Mac OS X is. Of course it has a proven track record in stability: overwhelmingly, most Mac OS X users have never had a system crash. What else do you want?
And if you want "proof" about security then the counterargument is that Windows has been proven to be entirely insecure, and can make no claims about anyone else not having a proven track record without totally destroying their own credibility. Windows is the most insecure OS ever.
"Any time you are *forced* to use the command-line to fix a problem (get something done?), it is a failure of the OS."
Bah. Any GUI that can provide everything that *I* need to get done is going to be unwieldy, at best. The GUI cannot perceive of everything that I might need to do. It's simply not possible. And if you call that a failure of the OS, then the very concept of GUIs is fundamentally flawed. The GUI should be as complete as possible/reasonable, but it cannot ever cover every need of the user.
Nowhere does it say I was using telnet anywhere. The program's name is NiftyTelnet. It can connect via ss1 or telnet protocols. It also doesn't say I've been a Unix geek for 15 years, but a Mac user for 15 years (I've been using Unix for about 10 years). Bah, who needs reading skills?
It only shows up on the main Slashdot page if you have "collapse sections" set. Yeah, it is not ideal. I think someone is working on code to allow you to assign a story to multiple sections. But until that happens ... c'est la vie.
Incorrect. You lose! And I win!
It is not a sentence fragment. A sentence fragment contains no independent clauses.
Whoever told you that doesn't know what they are talking about.
Yes, you can set it to that res, but it will look like crap. There's a fixed number of pixels; to get a lower res you have to use anti-aliasing, pixel doubling, etc.
I concede that the iBook 12" looks sharper than the TiBook in Mac OS X, but I dislike how Mac OS X looks *anyway*, and use Mac OS, where the TiBook looks just as good.
Even if it didn't look just as good: I use my laptop and its screen 10+ hours a day, sometimes as many as 16 hours or more, and the iBook resolution is just too small, unless I wish to go blind. Now, for graphic design this wouldn't be as much of an issue, but I am a coder, and I need to look at lots and lots of text, and on the iBook it is just too tiny. Sure, I could bump up the font size some, but then I lose the real estate I just gained, and everything else is still too small for my liking.
I am glad I got my TiBook when I did. I dislike the new resolution; it's going to be too small to read easily.
I dunno ... I would hope FW too. Maybe that is why it is not yet available in the states. :-)
I would guess because most people don't care. I use BBEdit under Mac OS X to write Perl and am perfectly happy with it. I wouldn't ever use ProjectBuilder to do Perl projects ... unless they are tied to something like this, where you're doing Perl to tie into Cocoa. Maybe I am abnormal, though.
Yes, "Collapse Sections" makes all section-only stories -- except for isolated sections, which Slashdot doesn't use, and sections you've specifically excluded -- show up on the home page. I do it. Apparently some people do it without knowing and so think that this is showing up on the home page for everyone. It isn't.
Hey javidb, I have one box running Mac OS X, but I use it only for IRC, web browsing (when my other Mac is busy), playing MP3s, shells, etc. And as a test box for Mac OS X when I need one (such as last night, when I was playing around some more with making Mac::Glue work with Mac OS X apps).
Yes, you are mischaracterizing it. It is not even clear to me exactly what you want "fixed," but let's make one thing clear: there is exactly NO REASON to port MacPerl to Mac OS X. The bulk of your post seems to be asking for this, and yet there is NO REASON to ever do it. That is why it is not being done.
... what's up with that?)
What you want is not a ported MacPerl, it is access to the Carbon API from perl on Mac OS X. Those are two different things. And in your post you presume unreasonable presumptions about this. As you clearly don't understand quite a few things, perhaps you should ask questions -- and heck, even read the existing responses that answer many of the questions you should be asking -- instead of making such presumptions.
(It's odd you say you can't complain, and then you complain
Some things you got wrong: as noted, there is no reason to Carbonize MacPerl. Further, there is no such possible thing as a port to Cocoa. The MacPerl access to the Mac OS API is based on Carbon; anything related to Cocoa wouldn't be a port, it would be a separate project. There are also several other alternatives beside OSXMacPerl, including, as noted in other posts, a project I am involved in to provide the Carbon API, which would work in both Mac OS and Mac OS X. Some of the alternatives even have working code that you could use today.
You also presume that my time would be better spent on Mac OS X, that I am "hiding my head in the sand." This is, as a point of fact, completely false. I don't use Mac OS X regularly, and won't use it regularly for the forseeable future. I am, and will continue to be, far more efficient using Mac OS than Mac OS X, and until that changes, cannot consider moving to Mac OS X a viable option. In light of that fact, it is somewhat amazing that I have actually spent as much time on Mac OS X as I have, doing some of the things you say I've not been doing. But the main point is that it is unreasonable for me to spend the majority of my spare time developing for a platform that I won't be using regularly any time soon. My time is mine, and I cannot fathom why anyone would gripe about how I use it.
Yes, I was using "release" in a certain sense, such as what is hinted at with the phrase "release candidate". A production release. A final release. A non-beta, non-development release. A release. By that common definition, MacPerl is based on the most up-to-date sources available. Calling it the most "advanced" was a *joke*, since obviously by many definitions it is *less* advanced, being on a non-POSIX OS.
:-) We'll see!
... if you want, you can just download the source and tools and build your own MacPerl 5.8.0. You can, today, download the source and build your own MacPerl 5.7.3! Just get the perl 5.7.3 source and the recent MacPerl source, drop the perl/macos/ directory from the latter into the former, and then just follow the instructions (except that you will first need to uncomment a few additional source files for 5.7/8 in Makefile.mk: numeric.c, locale.c, pp_pack.c).
:) Some things may not work, but them's the breaks. If (collective, nonspecific) you really want to help, your help is welcome; join the macperl-porters mailing list.
So anyway, I don't consider porting or upgrading MacPerl to 5.7.3 to be interesting; when I am working on MacPerl with the current development branch, it is to whatever the latest source is; before perl 5.7.3 was even announced, it was already older than the source I'd be working from. So I work from the development source, not any particular version of it.
MacPerl 5.8 *will* come out later than 5.8, and maybe even by a few months. The two biggest obstacles I see are just porting any new code (hopefully minimal, although there are a handful of new modules, although *most* of the new modules in 5.8 are already in MacPerl!) and testing. The test suite has been totally overhauled, and I'd like to make sure all the tests pass as much as possible before releasing, which means porting any part of the test suite that need porting. Michael Schwern has done a lot of work on this, so hopefully I'll get to hug him for the great work he's done instead of punching him inna nose for making my life more difficult.
Plus, we might want to add some new features to MacPerl itself, like a new and updated built-in editor and some other shiny things. I might want to get those to work simultaneously with getting the other stuff done, and test them in the regular beta cycle with everything else.
HOWEVER
So you want MacPerl 5.7.3? Go build it!
If you need access to it, then I suppose it is important. I don't understand how this is difficult.
There are many things you cannot do under perl for Mac OS X yet. perl for Mac OS X cannot compile raw Apple events. It cannot control QuickTime movies or do handle graphics or custom windows or menus or controls or speech. Well, actually, those things CAN be done, but not yet in any available distribution in any completed fashion.
I've seen the wrapper module you speak of, as I was contacted regarding it when it was first released. It only handles a tiny portion of the wealth of API access the MacPerl modules provide.
If you need to use MacPerl, well, Classic can take a long time to load, depending on your system. Anywhere from under a minute to several minutes. Once running, the script can run in less than a second, or a few seconds, depending on your system. Classic is a memory pig, but its performance is mostly the same as running Mac OS 9 by itself.
Actually, no sir: I answered the spirit of the question precisely. You are asking a separate question, which is why I, personally, spent time MAKING MacPerl. As to that, I can only say that it is odd that you would presume to have a reasonable opinion of what is the best use of my own time and efforts, since you, of course, cannot. :-) Suffice it to say that it is more than worth the time and effort, as a point of fact, regardless of your opinion on the matter.
As to Carbon/Cocoa bindings for Mac OS X: they are in progress. But they are irrespective of MacPerl, except that they will, eventually, obviate the need for MacPerl on Mac OS X, and the Carbon bindings will likely work on both Mac OS and Mac OS X.
Because, as noted above, perl doesn't have access to the Mac OS API under Mac OS X yet. This will change, hopefully, but for now, if you want to run your old scripts that call Mac::Windows, Mac::Events, etc., then you need MacPerl, even under Mac OS X. I hope that before the end of the year, there will be no reason to run MacPerl under Mac OS X.