No, but I bet if you check with Apple System Profiler, that there is a 'kext', or kernel extension, that is responsible for the responsiveness of your scrollie wheel....
Hate to break it to you, but I think *you* missed the point.
For those few times that you need, or want, to futz with the config files, you are in for a world of confusion. See, OS X uses the normal "flat files" some of the time. The rest of the time it looks things up in its massive obfuscated NetInfo database. Sure there are command line tools to go between the two, but it just adds to the possible confusion, n'est-ce pas?
Just one more step down this line of reasoning, and you will start sounding like the BeOS crowd. "We had to drop development for the PPC since we couldn't get the specs..."
Seems like the LinuxPPC crowd never complained about "missing specs", etc....they just went ahead and did it. If they haven't got as polished a product as Apple, maybe the real reason is the amount of $$$ thrown at the project?
I love that attitude....I mean, it just wins over so many people! "Hey, we don't support your hardware, but we would love it if you did!"...
So energetic/enthuiastic users develop drivers so that larger companies can "sell" support to less energetic/enthusiastic users. This is a great business model.
Hate to tell you this, but Apple isn't using the BSD kernel...they use Mach. Of course, all the rest of the BSD binaries are there, but not the kernel...
Next time spend "mush" more time analysing the scenario...
Dude,
Either you are an Apple employee, in which case you should be divulging a whole lot more, or you should pass some of that sh*t you're smoking my way and shut up....
Hell, even Nostradamus couldn't accurately tell you if Terminal.App would be included in what finally ships in OS X. Unless he was a time traveller to MWSF...
Yup, it's a RTOS that offers protected memory and pre-emptive multitasking....how much more value added poop do you need?
So you will have the GUI of a mac, the security of a BSD, and if you need more you can run any of the crufty X apps that would fulfill your desire....
Hah...
At any given time, I can walk down the hall and fall over three people who know what a Fourier transform is....and I am at a small technical college. Then picking out how to weight the coefficients so your ear doesn't know what's missing has got to be found in some journal of acoustics. This is not rocket science for chrissakes.
In three months, you could write your own.
I tried to use it on a small 6 node Beowulf cluster, but it kept falling over and killing my job...I moved to NFS for its stability (believe it or not).
I don't mean to slam the Arla guys at all, but I would have to believe that once the IBM-AFS makefile gets set up for later kernels that it would be *much* better. I was running 2.2.16, and the makefile was set up for kernels up to 2.2.14 (maybe 15, I have a bad case of CRS).
Probably, relativistically speaking, you can essentially make a parsec a unit of time instead of space. At least when physicists start talking amongst themslves.
I took a couple semesters of quantum mechanics, and the typical unit of "mass" used is the eV (electron volt). Remember, e=mc^2?
Mac OS X uses DisplayPDF. At least IBM's AIX uses (or used last time I touched it...) DisplayPostscript. We all know that Postscript is a subset of PDF. So a recompile of IBM's X server would run under the Quartz layer of OS X.
So we just have to wait for IBM to open source their X server. *grin*
Reflective memory?
This sounds like it would inhibit performance, unless you are totally unconcerned about cache coherency (the fact that what is in cache accurately represents the current state of main memory. Or that if x=5 in memory then x=5 in cache. And if it isn't halt whatever it is that you are doing, flush that cache line, and get the correct value...)
People have pointed out that the network latency and bandwidth are often the limiters in this kind of setup. I would like to point out the next bottle neck to scaled speed-up would be memory bandwidth and cache-reuse. Fetching from main memory (RAM) costs on the order of 300 clock cycles, while using stuff in cache only takes 1.
Not to get caught up in the holy war of "Geesh, I am so stupid I can't write...", and "Damn, is Apple lame..."...but here I go.
Couldn't you type on a tablet? Leave an outline of where the "keys" belong, and let the tablet sense where you have tapped. Seems like then you simplify the whole process of getting the best of both worlds. Sure you don't get the physical feed back that we are Pavlovianly trained to crave...but hey, it would work
I honestly don't know about the IBM/Microchannel squeeze, but Apple and FireWire? What's the next generation that's going to replace Firewire? Don't see that one coming soon. Heck, Firewire isn't even that widespread yet, and they are working on getting the 800 Mbps out the door. Time for the master to check his reality.
keep it quiet about Hotline? Once the Linux users find out about a lightweight protocol for file distribution, it's over... Trying to find a pron, warez, or mp3 server will be like finding a needle amongst the haystack of sourceforge/tarball servers!
the AmigOS runs inside your favoriteOS and also runs a JVM? Huhn? What good is that? It sounds like BeOS, with still fewer applications! (decidedly not a Good Thing...). Or like a reallly slow implementation of Blackdown's work.
to have Steve Woston on the panel. I mean, after his *really* important contributions to the world standard Google, this is a severe oversight and should be corrected. Glad to see that he will be helping out on Doom III though.
It sounds to me like a bunch of sys admins are caught up in the terms of the jargon of their field... This "real time" mathematical calculation is a simple concept. I will type slowly so you can understand... 1) Simple case: say Joe drives his car at a constant velocity of 40 mph due west. Where is Joe now? I need to know where Joe is, at the precise moment he is there, not days later. If I can find out earlier, no sweeat. This allows me to put up a red blinking dot in a map, and track him "real time". 2) Research case: say you want to model the waves that radiate from someone dropping a pebble in a pool, using the equations of motion. So you pick some way of solving partial differential equations, and look at the time dependent solution. And when I say look at the solution, I mean just that. Watch the pretty pictures generated by say some OpenGL rendered isosurface of the waves radiating out from the dropped pebble. For kicks, you could start the simulation at the same time as you drop a real pebble into real water, and check for similarities! This guy needs straight flat out FPU power, with some decent speed hard drives to write the data to, and good video performance so he can render the results to the screen. He also needs a good compiler. gcc ain't gonna cut it. Sorry. My thumbs up recommendation would be most likely: a nice Sun enterprise system, with a gob of processors in it, and SunWorks compiler set (which has a nice auto-paralleliztion option to it). But if money were no object get you hands on a box from IBM with Power4 chips in it. The real oxymoron here is fast vs. price.
Don't believe the BeOS hype..."Oh, big Bad Apple wouldn't release the documentation on their hardware, so we just *can't* support them, waah..." If that is the case, then why is LinuxPPC so successful where Be failed? I mean, come on, if you can't figure out how open firmware works, maybe you shouldn't run with the big boys. And what little good will I had is being sent out to Jason to speed his recovery.
Mach. Avi Tevanian is in love with the Mach kernel he helped develop at Carnegie Mellon. It allows slicker implementation of emulation environments, which is what Apple is pushing. Old apps run, new apps run with benefits of dynamic memory allocation, etc.
Slashdot Mirror
Really? Can I get your IP?
The list of patches that have been issued for Solaris in the past couple of months is pretty long.
Or are these run as honeypots?
No, but I bet if you check with Apple System Profiler, that there is a 'kext', or kernel extension, that is responsible for the responsiveness of your scrollie wheel....
Hate to break it to you, but I think *you* missed the point.
For those few times that you need, or want, to futz with the config files, you are in for a world of confusion. See, OS X uses the normal "flat files" some of the time. The rest of the time it looks things up in its massive obfuscated NetInfo database. Sure there are command line tools to go between the two, but it just adds to the possible confusion, n'est-ce pas?
XML is generally used in the preference files....
Just one more step down this line of reasoning, and you will start sounding like the BeOS crowd. "We had to drop development for the PPC since we couldn't get the specs..."
Seems like the LinuxPPC crowd never complained about "missing specs", etc....they just went ahead and did it. If they haven't got as polished a product as Apple, maybe the real reason is the amount of $$$ thrown at the project?
I love that attitude....I mean, it just wins over so many people! "Hey, we don't support your hardware, but we would love it if you did!"...
So energetic/enthuiastic users develop drivers so that larger companies can "sell" support to less energetic/enthusiastic users. This is a great business model.
Oh really?>
Did Apple try to ruin Java, or break Kerberos?
Get a grip. Microsoft isn't known as the evil empire for nuthin'....
Hate to tell you this, but Apple isn't using the BSD kernel...they use Mach. Of course, all the rest of the BSD binaries are there, but not the kernel...
Next time spend "mush" more time analysing the scenario...
Dude,
Either you are an Apple employee, in which case you should be divulging a whole lot more, or you should pass some of that sh*t you're smoking my way and shut up....
Hell, even Nostradamus couldn't accurately tell you if Terminal.App would be included in what finally ships in OS X. Unless he was a time traveller to MWSF...
Yup, it's a RTOS that offers protected memory and pre-emptive multitasking....how much more value added poop do you need? So you will have the GUI of a mac, the security of a BSD, and if you need more you can run any of the crufty X apps that would fulfill your desire....
Hah... At any given time, I can walk down the hall and fall over three people who know what a Fourier transform is....and I am at a small technical college. Then picking out how to weight the coefficients so your ear doesn't know what's missing has got to be found in some journal of acoustics. This is not rocket science for chrissakes. In three months, you could write your own.
Motorola and IBM. Toasters will come with x86 chips in them. Everything else will be RISC based.
Depends on what you mean by "well working"...
I tried to use it on a small 6 node Beowulf cluster, but it kept falling over and killing my job...I moved to NFS for its stability (believe it or not).
I don't mean to slam the Arla guys at all, but I would have to believe that once the IBM-AFS makefile gets set up for later kernels that it would be *much* better. I was running 2.2.16, and the makefile was set up for kernels up to 2.2.14 (maybe 15, I have a bad case of CRS).
Probably, relativistically speaking, you can essentially make a parsec a unit of time instead of space. At least when physicists start talking amongst themslves.
I took a couple semesters of quantum mechanics, and the typical unit of "mass" used is the eV (electron volt). Remember, e=mc^2?
'nuff said.
Mac OS X uses DisplayPDF. At least IBM's AIX uses (or used last time I touched it...) DisplayPostscript. We all know that Postscript is a subset of PDF. So a recompile of IBM's X server would run under the Quartz layer of OS X.
So we just have to wait for IBM to open source their X server. *grin*
Reflective memory? This sounds like it would inhibit performance, unless you are totally unconcerned about cache coherency (the fact that what is in cache accurately represents the current state of main memory. Or that if x=5 in memory then x=5 in cache. And if it isn't halt whatever it is that you are doing, flush that cache line, and get the correct value...)
People have pointed out that the network latency and bandwidth are often the limiters in this kind of setup. I would like to point out the next bottle neck to scaled speed-up would be memory bandwidth and cache-reuse. Fetching from main memory (RAM) costs on the order of 300 clock cycles, while using stuff in cache only takes 1.
Not to get caught up in the holy war of "Geesh, I am so stupid I can't write...", and "Damn, is Apple lame..."...but here I go.
Couldn't you type on a tablet? Leave an outline of where the "keys" belong, and let the tablet sense where you have tapped. Seems like then you simplify the whole process of getting the best of both worlds. Sure you don't get the physical feed back that we are Pavlovianly trained to crave...but hey, it would work
I honestly don't know about the IBM/Microchannel squeeze, but Apple and FireWire? What's the next generation that's going to replace Firewire? Don't see that one coming soon. Heck, Firewire isn't even that widespread yet, and they are working on getting the 800 Mbps out the door.
Time for the master to check his reality.
You are surprised when an industry mouthpiece has nothing to say? Harumphh...
keep it quiet about Hotline? Once the Linux users find out about a lightweight protocol for file distribution, it's over... Trying to find a pron, warez, or mp3 server will be like finding a needle amongst the haystack of sourceforge/tarball servers!
sounds a lot like: 1) Apple's Copland OS 2) Intel's Merced chip. But at least Apple had the sense to cut it's losses.
the AmigOS runs inside your favoriteOS and also runs a JVM? Huhn? What good is that? It sounds like BeOS, with still fewer applications! (decidedly not a Good Thing...). Or like a reallly slow implementation of Blackdown's work.
to have Steve Woston on the panel. I mean, after his *really* important contributions to the world standard Google, this is a severe oversight and should be corrected. Glad to see that he will be helping out on Doom III though.
It sounds to me like a bunch of sys admins are caught up in the terms of the jargon of their field... This "real time" mathematical calculation is a simple concept. I will type slowly so you can understand... 1) Simple case: say Joe drives his car at a constant velocity of 40 mph due west. Where is Joe now? I need to know where Joe is, at the precise moment he is there, not days later. If I can find out earlier, no sweeat. This allows me to put up a red blinking dot in a map, and track him "real time". 2) Research case: say you want to model the waves that radiate from someone dropping a pebble in a pool, using the equations of motion. So you pick some way of solving partial differential equations, and look at the time dependent solution. And when I say look at the solution, I mean just that. Watch the pretty pictures generated by say some OpenGL rendered isosurface of the waves radiating out from the dropped pebble. For kicks, you could start the simulation at the same time as you drop a real pebble into real water, and check for similarities! This guy needs straight flat out FPU power, with some decent speed hard drives to write the data to, and good video performance so he can render the results to the screen. He also needs a good compiler. gcc ain't gonna cut it. Sorry. My thumbs up recommendation would be most likely: a nice Sun enterprise system, with a gob of processors in it, and SunWorks compiler set (which has a nice auto-paralleliztion option to it). But if money were no object get you hands on a box from IBM with Power4 chips in it. The real oxymoron here is fast vs. price.
Don't believe the BeOS hype..."Oh, big Bad Apple wouldn't release the documentation on their hardware, so we just *can't* support them, waah..." If that is the case, then why is LinuxPPC so successful where Be failed? I mean, come on, if you can't figure out how open firmware works, maybe you shouldn't run with the big boys. And what little good will I had is being sent out to Jason to speed his recovery.
Mach. Avi Tevanian is in love with the Mach kernel he helped develop at Carnegie Mellon. It allows slicker implementation of emulation environments, which is what Apple is pushing. Old apps run, new apps run with benefits of dynamic memory allocation, etc.