Most people want a computer that is expandable, and can accomodate things internally (or at least have the option to).
No. Most people want a computer that just does the job. They don't know and don't want to know what is inside. Most people are closer to the person whom I overhead on the bus when the original iMacs came out, who said "It doesn't have a disk drive" because his mental model of a computer had two components: a screen (that shows you stuff) attached to a disk drive (that saves your stuff).
I use Privoxy (version 3.03 on OS X) and the content of that site appears just fine - and without the annoying ads. Only one small ad near the bottom seemed to escape the Privoxy filters.
If your code makes sense as an entity seperate from the GPLed code (eg, a program/driver that could run on other OSs), it probably isn't derivative.
So couldn't someone distribute their binary patch as a "work of art" - e.g. as a rather unmusical MP3 format "song" that has this amusing extra feature when used as input to the patch utility?
First of all, usability issues are rarely things that can be fixed with a "patch". You usually need to design the software with the users and their tasks in mind from the beginning. And you need to realize that the users are often very different from you - e.g. they are far less knowledgeable about your project domain.
And I think ESR is trying to change the value system of the open source world - trying to get it to value usability as much as performance, security, maintainability, etc. If the "economics" of open source has developers getting "payback" in the form of acknowledgement from their peers, perhaps we need to change the "exchange rate" so that the feedback from non-technical users (Aunt Tilly) is valued more highly.
Three points:
1) You definitely need lots of RAM. Compilation speed is just fine on my lowly 600 Mhz G3 iBook (20 seconds to rebuild all 100 or so classes (10 K LOC) and create a JAR file) but my IDE (JBuilderX) typically takes up 120 MB of real RAM, 500 MB of virtual memory. I have a total of 384 MB RAM and so if I am using any other RAM-hungry apps, my machine is running the disk a lot (swapping).
2) The latest release of JBuilder (JBuilder X) is much improved from previous versions. Lots of refactoring support. It is not yet officially available for OS X but I managed to get the trial version of JBuilder X Enterprise to install with the help of a note on the Borland community pages, and it runs fine. Details of how to get it running on OS X are here
3) Java GUI applications look so much better on OS X (Panther, Mac look & feel) compared to other platforms. This is an advantage because you will get an esthetic boost from looking at your app while developing, but it might be considered a disadvantage if (as is likely) the main target platform is Windows (where your beautiful GUI won't look nearly so nice).
Actually, mach_init is originally process #1 but that process forks and then the parent process (#1) does an exec of/sbin/init. The child process from the fork is process #2 and continues running as mach_init. The thing that makes this a bit hard to understand is that it is the parent process that does the exec whereas it is usually the child that does that.
If you have a user account that was present in 10.2, it stays as it was in 10.2 - i.e. the password is world readable and limited to 8 significant characters. If you make a new account in 10.3 or even change the password of an existing account that was brought over from 10.2 to 10.3, then the new password handling will take effect: shadow passwords and a larger number (I don't recall how many) of significant characters.
Well, the $130 is the upgrade price. It's just that Apple is being nice and letting everyone (even those with only OS 9) upgrade for the same price.
I.e. the hypothetical "full price" would be something like $260
It seems from your comments that you have missed out on the "news" that the current Mac OS is OS X. All of your comments seem to apply to previous versions of Mac OS - as far as I can see, none of them apply to OS X. You should try it some time.
I think that what you "recall" is that Kasparov made outrageous claims about the IBM team cheating during the match. Changing the program while a game was in progress would certainly be considered cheating since the programmers could inject expert chess players' judgement on the specific positions of the game. There was zero evidence of anything like this happening.
Note that changing the program between games is generally not considered cheating unless it is specifically proscribed, as I believe is the case in the current match.
I don't know how many freakin times I've been hacking away at a perl script, as root and had to actually log in as a different user just to read the damn documentation.
You could have read the doc as root just by using the "-U" option to perldoc. That option basically says "I know it's insecure but do it anyway!".
My boss knows about Jaguar, but his opinion is that he shouldn't have to upgrade only a year after purchasing the Mac
As others have said, it is likely that there will be a security patch for 10.1 soon.
But I would say that it isn't a question of having to upgrade - your boss ought to want to upgrade to Jaguar (and soon to Panther). I don't know what you pay your staff, but in most environments, $129 is a very cheap price to pay for the increased productivity (and worker satisfaction) you get with each OS X upgrade.
Now if I can replace FileMaker Quark with MySQL Quark that would seriously rock.
You can call AppleScript from other scripting languages (Python/Perl/Bash, etc) and call other scripting languages from AppleScript, so you can do each manipulation in whatever language you find most convenient. I usually find it easiest if you keep AppleScript for manipulating objects within your application (Quark) and do the backend data manipulation in Perl etc.
# getTextOfFrontWebPage: Gets the text of the frontmost web page from Safari sub getTextOfFrontWebPage() {
my $ascript =<<" EOT";
tell application "Safari"
text of document 1
end tell
EOT
my $text = runAppleScript($ascript);
return $text; }
Often the errors are rounded away before displaying the result, but they are still lurking in the floating point values. Take your example: 3.083-3.014. In most programs, (Calculator apps, Excel, etc) the result is probably displayed as 0.069. However, if you calculate 3.083-3.014-0.069 you will not get 0. You will see the rounding error.
This is indeed true for most programs.
But it doesn't have to be that way. It is really a user-interface issue.
It is clear that what the user of a calculator program wants when they enter 3.083-3.014 is the mathematically correct answer, not the closest approximation to the difference between closest_floating_pt(3.083) and closest_floating_pt(3.014). So the program should do the extra work to make it so whenever possible. In most cases, it is possible.
And the original poster was talking about the fact that the rounding error (from 3.083-3.014) showed up in the paper-tape printout. That would seem to be a bug, pure and simple.
Unless you are talking about one of the first generation iBooks (the coloured ones), something is wrong. As far as I recall (I don't do it too often since I just sleep it most of the time) my iBook 600 boots in under 2 minutes. You should restart using verbose mode (hold Command + V after the chime) to see what is taking all that time. E.g. some people have reported a delay when their system was configured to talk to a directory server that is no longer there. Easy to fix.
[...] I finally get enough money to buy an iPod, go get it, and then suddenly there are brand new ones out about a month or two later [...]
Otherwise, who cares about a roadmap? Are you really going to put off some major hardware provisioning decision because a roadmap claims (key word) that they will have such and such a product out by a certain time? They are almost always adjusted.
Well, you seem to be saying that you would have delayed your purchase had you known that some new models would be out in a month or two. So, at least in this case, it was in Apple's best interest to keep its roadmap to itself. They got your money earlier than they might have, and your time-to-trade-in-for-new-model clock started a bit earlier.
Since you seem to accept that roadmaps are often works of fiction, why not make up your own roadmap? Hmm, the interval between previous generations of iPods was x, so I project the next revision will be in the month of y. Then, if you delay a purchase after looking at your roadmap, you will be happy if the roadmap was accurate and new models arrived when you projected them. And if your roadmap was inaccurate, you have only yourself to blame.
If Apple published a roadmap that they didn't live up to, everybody would be unhappy about it. And there are lots of reasons why they might not introduce new models by the projected date. A manufacturer always incurs additional costs in introducing a new model so they would prefer to keep selling the old model as long as they can. If the old model is still selling well, why bother introducing a new model at all?
Apple is afraid that if they lowered their prices, the "we paid a premium price for a premium product" crowd would be pissed and Apple would lose that niche.
You imply that Apple customers are buying their computers for the status value. I think this is an idiotic statement. Yes it is theoretically possible, but I have seen zero evidence of this. To me it seems obvious that people buy Macintoshes because they feel they are a better value for money. Perhaps slightly more expensive but the time and aggravation saved easily justifies paying for better quality.
It'd also be a nice touch if they'd have put USB ports on the keyboard, that could "tunnel" through the bluetooth back to the computer.
yeah, but since a USB port supplies power to any connected device, that would up the power requirements for the keyboard. And of course it would run down those batteries a lot faster if you actually used such a port.
Yes - his test program was just that - a test.
It shows that if a buffer overflow exists in an existing setuid program (e.g. sendmail) then the techniques explained in the article could be used to get a root shell.
and then I wonder why you would spend $5mil dollars over the next 5 years to build a supercomputer? It seems like a better idea would be to reach out to the slahsdot/linux communities and see what kind of equipment they could get donated/free and then build a semi-super computer with that - or hell even just buy a shitload of cheap pc's to do it with....
maybe i'm just missing something...
Yes - you are missing that they want to have a top-notch supercomputer and they want it now, and they don't want to be fiddling with a mismatched bunch of cheap or donated equipment, and that the funding for this likely comes out of a different purse than that used for regular ongoing expenses.
Slashdot Mirror
No. Most people want a computer that just does the job. They don't know and don't want to know what is inside. Most people are closer to the person whom I overhead on the bus when the original iMacs came out, who said "It doesn't have a disk drive" because his mental model of a computer had two components: a screen (that shows you stuff) attached to a disk drive (that saves your stuff).
I use Privoxy (version 3.03 on OS X) and the content of that site appears just fine - and without the annoying ads. Only one small ad near the bottom seemed to escape the Privoxy filters.
So couldn't someone distribute their binary patch as a "work of art" - e.g. as a rather unmusical MP3 format "song" that has this amusing extra feature when used as input to the patch utility?
First of all, usability issues are rarely things that can be fixed with a "patch". You usually need to design the software with the users and their tasks in mind from the beginning. And you need to realize that the users are often very different from you - e.g. they are far less knowledgeable about your project domain.
And I think ESR is trying to change the value system of the open source world - trying to get it to value usability as much as performance, security, maintainability, etc. If the "economics" of open source has developers getting "payback" in the form of acknowledgement from their peers, perhaps we need to change the "exchange rate" so that the feedback from non-technical users (Aunt Tilly) is valued more highly.
If you haven't seen it already, go to the Three Dead Trolls in a Baggie web site and watch their "Welcome to the Internet Help Desk" video.
1) You definitely need lots of RAM. Compilation speed is just fine on my lowly 600 Mhz G3 iBook (20 seconds to rebuild all 100 or so classes (10 K LOC) and create a JAR file) but my IDE (JBuilderX) typically takes up 120 MB of real RAM, 500 MB of virtual memory. I have a total of 384 MB RAM and so if I am using any other RAM-hungry apps, my machine is running the disk a lot (swapping).
2) The latest release of JBuilder (JBuilder X) is much improved from previous versions. Lots of refactoring support. It is not yet officially available for OS X but I managed to get the trial version of JBuilder X Enterprise to install with the help of a note on the Borland community pages, and it runs fine. Details of how to get it running on OS X are here
3) Java GUI applications look so much better on OS X (Panther, Mac look & feel) compared to other platforms. This is an advantage because you will get an esthetic boost from looking at your app while developing, but it might be considered a disadvantage if (as is likely) the main target platform is Windows (where your beautiful GUI won't look nearly so nice).
A few more details are available here.
If you have a user account that was present in 10.2, it stays as it was in 10.2 - i.e. the password is world readable and limited to 8 significant characters. If you make a new account in 10.3 or even change the password of an existing account that was brought over from 10.2 to 10.3, then the new password handling will take effect: shadow passwords and a larger number (I don't recall how many) of significant characters.
Yes - the Apple knowledge base article (that was posted this evening) says to turn off LDAP if not needed.
Have you looked at Mike Bombich's tips on deployment? He covers NetBoot there. And his "Carbon Copy Cloner" can make a NetBoot image.
Well, the $130 is the upgrade price. It's just that Apple is being nice and letting everyone (even those with only OS 9) upgrade for the same price.
I.e. the hypothetical "full price" would be something like $260
It is fully explained there, complete with examples.
It seems from your comments that you have missed out on the "news" that the current Mac OS is OS X. All of your comments seem to apply to previous versions of Mac OS - as far as I can see, none of them apply to OS X. You should try it some time.
Note that changing the program between games is generally not considered cheating unless it is specifically proscribed, as I believe is the case in the current match.
But I would say that it isn't a question of having to upgrade - your boss ought to want to upgrade to Jaguar (and soon to Panther). I don't know what you pay your staff, but in most environments, $129 is a very cheap price to pay for the increased productivity (and worker satisfaction) you get with each OS X upgrade.
You can call AppleScript from other scripting languages (Python/Perl/Bash, etc) and call other scripting languages from AppleScript, so you can do each manipulation in whatever language you find most convenient. I usually find it easiest if you keep AppleScript for manipulating objects within your application (Quark) and do the backend data manipulation in Perl etc.
Apple has a page about using 'do shell script' to invoke UNIX scripts from AppleScript
To go in the reverse direction, you invoke the AppleScript using
But it doesn't have to be that way. It is really a user-interface issue.
It is clear that what the user of a calculator program wants when they enter 3.083-3.014 is the mathematically correct answer, not the closest approximation to the difference between closest_floating_pt(3.083) and closest_floating_pt(3.014). So the program should do the extra work to make it so whenever possible. In most cases, it is possible.
And the original poster was talking about the fact that the rounding error (from 3.083-3.014) showed up in the paper-tape printout. That would seem to be a bug, pure and simple.
Since you seem to accept that roadmaps are often works of fiction, why not make up your own roadmap? Hmm, the interval between previous generations of iPods was x, so I project the next revision will be in the month of y. Then, if you delay a purchase after looking at your roadmap, you will be happy if the roadmap was accurate and new models arrived when you projected them. And if your roadmap was inaccurate, you have only yourself to blame.
If Apple published a roadmap that they didn't live up to, everybody would be unhappy about it. And there are lots of reasons why they might not introduce new models by the projected date. A manufacturer always incurs additional costs in introducing a new model so they would prefer to keep selling the old model as long as they can. If the old model is still selling well, why bother introducing a new model at all?
Give a man a song title and he'll hum it all day. Teach a man to google and ...
Yes - his test program was just that - a test. It shows that if a buffer overflow exists in an existing setuid program (e.g. sendmail) then the techniques explained in the article could be used to get a root shell.
Yes - you are missing that they want to have a top-notch supercomputer and they want it now, and they don't want to be fiddling with a mismatched bunch of cheap or donated equipment, and that the funding for this likely comes out of a different purse than that used for regular ongoing expenses.