That'd be the faster system bus, the faster/larger hard drive, better video card, external display connection (for FULL two headed video, not mirroring), S-Video port, faster processor, BETTER processor (with AltiVec), and three full inches of extra screen real estate (assuming you didn't get the 12"). Not much, really.
If you're getting kernel panics, you either have an odd kernel extension (device driver) or a hardware issue (usually a bad stick of RAM). Crashes on OS X should NOT happen without a compelling reason - thrice a week to me is screaming Bad RAM. It's VERY picky about its RAM - use a decent brand with a lifetime warranty. I you buy shit, expect shit. My system only reboots for system updates.
I haven't seen anybody mention this - but Apple has a page that describes a workaround for this for all you HTML developers out there. I checked it out, and almost spit coffee out my nose when I saw this:
Here's an example of code (a simple tag) that will not function as it did previously when loaded in the changed version of Internet Explorer for Windows:
Create and place the external JS file on your site. In this example, call it foo.js. This script needs to document.write the full object/embed tag that was previously in your HTML file:
So- in summary: Writing the code directly in HTML is a violation and will trigger IE to spit the silly dialog box. Having JavaScript (and therefore the browser itself) write the offending code is just kosher. Wow.
I just want to point out that the whole site is chock full of good information about doing this. Don't just grab the software and go - read through a few of the articles in the Deployment section.
Using NetBoot/NetRestore combined with Apple Remote Desktop, I can re-image, reconfigure and reboot any system from my laptop. User home directories live on the Xserve, so I really only have one system to back up.
All of this is very convenient:)
Also note that the applications on that site are mainly GUI wrappers for command line apps that Apple provides with every OS X Server system. You could accomplish much of the same with Perl if you were so inclined...
You can't hook up your wireless network point to a 56k modem and share that about.
Well, since we're talking about ad-hoc routing meshes anyway, why not have every user with a modem dial out and let the routing software handle bandwidth allocation.
While the average bandwidth for all people with modems would remain the same (56k), there would be an aggregate max speed of 56k*$users. Based on typical usage patterns, this would be percieved by each individual user as significantly faster than the single modem speed. Thus, the percieved average speed will increase without actually changing. Nothing would have really changed but the implicit contract of sharing 'spare' bandwidth with your local mesh.
Amazing - an example of the whole being greater than the sum of its parts. All it requires is cooperation. And WiFi hardware. But we've all got that already, right?
They call this stuff Symmetric Multi Threading, but I think that name is a bit misleading. While the thread scheduling itself is symmetric (all process threads are created equal and receive equal execution time), the shared resources on the CPU (cache, shared registers) are NOT symmetric. Since these shared resources are in essence handled on the way in to the execution unit, it becomes really easy to starve the processor when you have contention for one of those resources.
While proper application development can alleviate some of this issue, it will depend heavily on the actual usage patterns of the system. When you have a lot of overlap coming in from memory (like the file system cache on a web server), you don't worry too much about threads stepping on each others' registers. This sounds fantastic for data servers.
Desktop systems, on the other hand, almost never work this way. When you're playing MP3s in the background while web surfing and checking your email, you're already working with vastly different areas of data. Throw the OS and any various background processes into the mix and you've pretty much eliminated any gain and possibly slowed down due to cache contention.
While this was touched on at the end of the article, I don't think it was given enough weight. It doesn't just depend on what applications you're running and wether they were written to take advantage of it. It depends on what you want to do with the whole system. For serving data, this will certainly be good (especially with multiple CPUs!). For desktop systems, this is a non-starter.
I'm not disparaging the technology - far from it. I'm just waiting for Intel and Microsoft to market this to my mom as a way to have higher quality DVD playback - at twice the cost. And her buying it. Again.
Well, was there really an upsurge or did we simply discover what 'cancer' was? How many unexplained deaths back then were simply cases of cancer in one form or another?
A possible explanation for the upsurge of "new" diseases is that we now have names for them and know what causes them.
They have a 30 day trial period with a popup at startup being the only real annoyance.
Well, that's not really true. The mission threads will cap out at a certain point without the registration code. They don't really tell you this when you start playing, so it's a bit disconcerting when the missions just seem to dry up for no reason. If you play with any regularity, you'll hit the mission caps long before the 30 day limit.
Other than that, I'd have to say that Cap'n Hector is absolutely the coolest copy protection scheme I've ever seen... If you know the plugin architecture, you can rig up a ship for yourself that'll give you a chance. I just paid the registration - Ambrosia makes great games and has a good attitude for a 'commercial' software house (they're more like a co-op).
Well, yeah. The rendering engine is the same, therefore pages look the same. That's the point. However, the is a huge difference between running the the XUL skin that looks like a native app and actually running the Gecko engine in a native app.
Form elements on pages look and behave like native widgets (makes quite a difference for popup menus) while they don't if you simply skin the standard mozilla. Scroll bars are native. The tabs, sidebar, toolbar et al are all native, not just native looking.
If you have a fast machine, you won't really notice much of a difference. Run it on an old iMac, and the choice is quite clear. Mozilla skinned (with ANY skin) requires 100% of my CPU to type into text fields and doesn't even keep up with me. The 1.1beta tries to get around this by not updating the text in the field as frequently, but this leads to 'ghost typing' (not that I ever miss:).
This doesn't even get into the selection issues that have been driving me nuts in Mozilla for the last 3 years. Clicking in the location bar to change a URL shouldn't be a guessing game as to where the cursor and selection will end up.
All of these problems went away with Chimera - and it's entirely due to the actual Cocoa widgets. Use the framework, Luke.
Bull. Why would I, as a 'serious web developer', want to develop initially for a single browser, drop into another browser for testing purposes, then go back and fix what didn't work? I have an alternative: I write for the spec.
I develop in Mozilla, and if it looks good I know it'll look good in all browsers. I used to be completely anal about checking every single browser under the sun, but once I started using Mozilla as my primary dev platform I discovered that this was almost totally unnecessary. I'll run everything through the various platform checks before shipping to a client, but it boils down to this: if it works properly in Mozilla, it'll work fine everywhere.
Working in this business is all about producing as efficiently as possible (You have to when the client keeps changing ideas and deadlines on you). Why would I choose to write and revise when I can write once?
on Mac OS-X both IE and Moz are slow and broken in various ways though, so it's a matter of taste
Pick up the current (0.4) version of Chimera for OS X. I've been waiting patiently since the 0.1 days for it to stabilize - the idea of a native Cocoa front end makes me tingle.
Mozilla 1.0 does some 'odd' things (mainly related to text input) and if you don't have a zippy machine those things become very noticable (why does typing in the location bar need all of my processor time?!).
So, last Thursday, I downloaded the 0.4 version of Chimera to see how things were coming along. It's still running and Mozilla is no longer sitting in my dock. It's far from complete (very minimal prefs interface, but the prefs.js file is right where you'd expect it), but native Cocoa tabs, sidebar (it's a drawer) and widgets make it all worth it. And windows open at 'normal' speed.
Actually, he uses the sword in reality as well - I can't remember the scene exactly, but as one example he was in a large tent in the northwest looking for somebody (related to the raft). Ended up slashing a bit if I recall...
I know that some unsubscribe links are fake. What are you going to do? There are also fake breasts and fake watches.
That's not a fair comparison at all.
Hitting a fake unsubscribe link has the potential effect of making sure you get a lot more SPAM when my address gets promoted from the '60 Million Email Addresses' list to the '3 Million KNOWN GOOD Email Addresses' list. As a consequence, I'm not going to ever click on an opt-out link that came unsolicited - too risky.
Hitting a fake breast would result in a slap to the face - and would be worth it!
how insane must you be if you want to run a web server on an iMac
Well, depends. I've seen no instability when it comes to the unix layer (although my iBook has had trouble with sleep/screensaver issues) - but that's not the point. Think development platform.
Think development platform while sitting on the back deck watching the sun go down on the other side of the valley.
While connected to the staging server.
Re:In addition to, not instead of
on
Linux on the iMac G4
·
· Score: 5, Informative
there's not Apache/mod_perl build for Fink yet
While you are correct about the absence of apache/mod_perl for Fink, you might like to know that the mod_perl DSO for apache is included with the standard OS X install. Simply edit your apache.conf file to load it (actually, just un-comment the line that calls it).
I spent hours trying to get apache/mod_perl/mod_ssl compiled and installed before I realised it was alread done for me... and Software Update keeps it fresh, even!
If you know the area, I lived in the 110th and SE Stark area
You live in Oregon, in the 110th and SE Stark area?! As a resident of Eugene, I'd have to say you must live in Portland. Only a PDX resident would be so brash as to write off the possibility that there are other cities in Oregon. First you steal our area code, now you've stolen the whole state!
Geez - you only make up half the population up there...
Seems to me the major expense in a program such as this is the long-term storage of the 'data' - and there doesn't look like there's an easy way over that obstacle.
I wonder, however, given the current thrust of the genome mapping projects around the globe if this issue can become irrelevant. With the ability to codify the genes in a species comes the ability to store the information in a much less expensive manner - and for much longer periods of time. Simply back it up to tape!
I know it's a fairly far off vision, but hey...
Re:maya, photoshop, etc. on a cluster?
on
Macintosh Clustering
·
· Score: 5, Insightful
What would it involve to make Mac OS X and every program that runs natively on it to be able to take advantage of clustering right out of the box?
Actually, native Cocoa apps have the capability to be built using distributed objects quite easily. In fact, the mechanisms used for multithreaded communication (NSConnection, NSPort, etc) are the same classes you use to communicate with other processes - on ANY machine.
The mechanism they use relies heavily on the dynamic nature of Objective-C objects, so I'm guessing it's NOT based on some standard (SOAP,CORBA,RPC,.NET). That would make it hard to integrate it into any cross platform clusters, but we were talking about Photoshop, weren't we?
So, it boils down to simply this: If you write a Mac OS X app, write it threaded and use Cocoa. If you do that, you'd be amazed what sort of functionality you get for 'free' - including being able to distribute your app across clusters!
Slashdot Mirror
That'd be the faster system bus, the faster/larger hard drive, better video card, external display connection (for FULL two headed video, not mirroring), S-Video port, faster processor, BETTER processor (with AltiVec), and three full inches of extra screen real estate (assuming you didn't get the 12"). Not much, really.
If you're getting kernel panics, you either have an odd kernel extension (device driver) or a hardware issue (usually a bad stick of RAM). Crashes on OS X should NOT happen without a compelling reason - thrice a week to me is screaming Bad RAM. It's VERY picky about its RAM - use a decent brand with a lifetime warranty. I you buy shit, expect shit. My system only reboots for system updates.
OK - so far so good. Then they get to this part: I can see where this is going... So- in summary: Writing the code directly in HTML is a violation and will trigger IE to spit the silly dialog box. Having JavaScript (and therefore the browser itself) write the offending code is just kosher. Wow.
Using NetBoot/NetRestore combined with Apple Remote Desktop, I can re-image, reconfigure and reboot any system from my laptop. User home directories live on the Xserve, so I really only have one system to back up. All of this is very convenient :)
Also note that the applications on that site are mainly GUI wrappers for command line apps that Apple provides with every OS X Server system. You could accomplish much of the same with Perl if you were so inclined...
Oh, wait. We don't have any professional sports in this state (Well, we have the Blazers, but they hardly count).
While 17K is funny to those of us who aren't in school. Absolutely fuckin' hilarious!
OK - that was the funniest thing I've seen all day. And it's probably valid.
Well, since we're talking about ad-hoc routing meshes anyway, why not have every user with a modem dial out and let the routing software handle bandwidth allocation.
While the average bandwidth for all people with modems would remain the same (56k), there would be an aggregate max speed of 56k*$users. Based on typical usage patterns, this would be percieved by each individual user as significantly faster than the single modem speed. Thus, the percieved average speed will increase without actually changing. Nothing would have really changed but the implicit contract of sharing 'spare' bandwidth with your local mesh.
Amazing - an example of the whole being greater than the sum of its parts. All it requires is cooperation. And WiFi hardware. But we've all got that already, right?
OK, I just had to drop this in here. I found this quote from an AC here a long time ago and swiped it for my random quote database:
i'm going to become rich and famous after i invent a device that allows you to stab people in the face over the internet
Seems like this guy may finally get his wish! Hope he patented that idea
They call this stuff Symmetric Multi Threading, but I think that name is a bit misleading. While the thread scheduling itself is symmetric (all process threads are created equal and receive equal execution time), the shared resources on the CPU (cache, shared registers) are NOT symmetric. Since these shared resources are in essence handled on the way in to the execution unit, it becomes really easy to starve the processor when you have contention for one of those resources.
While proper application development can alleviate some of this issue, it will depend heavily on the actual usage patterns of the system. When you have a lot of overlap coming in from memory (like the file system cache on a web server), you don't worry too much about threads stepping on each others' registers. This sounds fantastic for data servers.
Desktop systems, on the other hand, almost never work this way. When you're playing MP3s in the background while web surfing and checking your email, you're already working with vastly different areas of data. Throw the OS and any various background processes into the mix and you've pretty much eliminated any gain and possibly slowed down due to cache contention.
While this was touched on at the end of the article, I don't think it was given enough weight. It doesn't just depend on what applications you're running and wether they were written to take advantage of it. It depends on what you want to do with the whole system. For serving data, this will certainly be good (especially with multiple CPUs!). For desktop systems, this is a non-starter.
I'm not disparaging the technology - far from it. I'm just waiting for Intel and Microsoft to market this to my mom as a way to have higher quality DVD playback - at twice the cost. And her buying it. Again.
And for the non-Japanese speaking folk, that link is here
You mean like this? It's right there at the top...
Was there a sudden upsurge in cancer?
Well, was there really an upsurge or did we simply discover what 'cancer' was? How many unexplained deaths back then were simply cases of cancer in one form or another?
A possible explanation for the upsurge of "new" diseases is that we now have names for them and know what causes them.
They have a 30 day trial period with a popup at startup being the only real annoyance.
Well, that's not really true. The mission threads will cap out at a certain point without the registration code. They don't really tell you this when you start playing, so it's a bit disconcerting when the missions just seem to dry up for no reason. If you play with any regularity, you'll hit the mission caps long before the 30 day limit.
Other than that, I'd have to say that Cap'n Hector is absolutely the coolest copy protection scheme I've ever seen... If you know the plugin architecture, you can rig up a ship for yourself that'll give you a chance. I just paid the registration - Ambrosia makes great games and has a good attitude for a 'commercial' software house (they're more like a co-op).
looked exactly like Mozilla to my eyes
Well, yeah. The rendering engine is the same, therefore pages look the same. That's the point. However, the is a huge difference between running the the XUL skin that looks like a native app and actually running the Gecko engine in a native app.
Form elements on pages look and behave like native widgets (makes quite a difference for popup menus) while they don't if you simply skin the standard mozilla. Scroll bars are native. The tabs, sidebar, toolbar et al are all native, not just native looking.
If you have a fast machine, you won't really notice much of a difference. Run it on an old iMac, and the choice is quite clear. Mozilla skinned (with ANY skin) requires 100% of my CPU to type into text fields and doesn't even keep up with me. The 1.1beta tries to get around this by not updating the text in the field as frequently, but this leads to 'ghost typing' (not that I ever miss
This doesn't even get into the selection issues that have been driving me nuts in Mozilla for the last 3 years. Clicking in the location bar to change a URL shouldn't be a guessing game as to where the cursor and selection will end up.
All of these problems went away with Chimera - and it's entirely due to the actual Cocoa widgets. Use the framework, Luke.
Bull. Why would I, as a 'serious web developer', want to develop initially for a single browser, drop into another browser for testing purposes, then go back and fix what didn't work? I have an alternative: I write for the spec.
I develop in Mozilla, and if it looks good I know it'll look good in all browsers. I used to be completely anal about checking every single browser under the sun, but once I started using Mozilla as my primary dev platform I discovered that this was almost totally unnecessary. I'll run everything through the various platform checks before shipping to a client, but it boils down to this: if it works properly in Mozilla, it'll work fine everywhere.
Working in this business is all about producing as efficiently as possible (You have to when the client keeps changing ideas and deadlines on you). Why would I choose to write and revise when I can write once?
on Mac OS-X both IE and Moz are slow and broken in various ways though, so it's a matter of taste
Pick up the current (0.4) version of Chimera for OS X. I've been waiting patiently since the 0.1 days for it to stabilize - the idea of a native Cocoa front end makes me tingle.
Mozilla 1.0 does some 'odd' things (mainly related to text input) and if you don't have a zippy machine those things become very noticable (why does typing in the location bar need all of my processor time?!).
So, last Thursday, I downloaded the 0.4 version of Chimera to see how things were coming along. It's still running and Mozilla is no longer sitting in my dock. It's far from complete (very minimal prefs interface, but the prefs.js file is right where you'd expect it), but native Cocoa tabs, sidebar (it's a drawer) and widgets make it all worth it. And windows open at 'normal' speed.
Really, go try it.
but the sword was in the Metaverse, not reality
Actually, he uses the sword in reality as well - I can't remember the scene exactly, but as one example he was in a large tent in the northwest looking for somebody (related to the raft). Ended up slashing a bit if I recall...
Hang on. Last time I checked, the 'pause' function on my player paused both the video and the sound.
'Paused' sound is eerily similar to 'muted' sound...
That's not a fair comparison at all.
Hitting a fake unsubscribe link has the potential effect of making sure you get a lot more SPAM when my address gets promoted from the '60 Million Email Addresses' list to the '3 Million KNOWN GOOD Email Addresses' list. As a consequence, I'm not going to ever click on an opt-out link that came unsolicited - too risky.
Hitting a fake breast would result in a slap to the face - and would be worth it!
Well, depends. I've seen no instability when it comes to the unix layer (although my iBook has had trouble with sleep/screensaver issues) - but that's not the point. Think development platform.
Think development platform while sitting on the back deck watching the sun go down on the other side of the valley.
While connected to the staging server.
While you are correct about the absence of apache/mod_perl for Fink, you might like to know that the mod_perl DSO for apache is included with the standard OS X install. Simply edit your apache.conf file to load it (actually, just un-comment the line that calls it).
I spent hours trying to get apache/mod_perl/mod_ssl compiled and installed before I realised it was alread done for me... and Software Update keeps it fresh, even!
You live in Oregon, in the 110th and SE Stark area?! As a resident of Eugene, I'd have to say you must live in Portland. Only a PDX resident would be so brash as to write off the possibility that there are other cities in Oregon. First you steal our area code, now you've stolen the whole state!
Geez - you only make up half the population up there...
NOTE: I'm just joshin'...
Seems to me the major expense in a program such as this is the long-term storage of the 'data' - and there doesn't look like there's an easy way over that obstacle.
I wonder, however, given the current thrust of the genome mapping projects around the globe if this issue can become irrelevant. With the ability to codify the genes in a species comes the ability to store the information in a much less expensive manner - and for much longer periods of time. Simply back it up to tape!
I know it's a fairly far off vision, but hey...
Actually, native Cocoa apps have the capability to be built using distributed objects quite easily. In fact, the mechanisms used for multithreaded communication (NSConnection, NSPort, etc) are the same classes you use to communicate with other processes - on ANY machine.
The mechanism they use relies heavily on the dynamic nature of Objective-C objects, so I'm guessing it's NOT based on some standard (SOAP,CORBA,RPC,.NET). That would make it hard to integrate it into any cross platform clusters, but we were talking about Photoshop, weren't we?
So, it boils down to simply this: If you write a Mac OS X app, write it threaded and use Cocoa. If you do that, you'd be amazed what sort of functionality you get for 'free' - including being able to distribute your app across clusters!
Down with Carbon!