It's really not fun to drive a car near its maximum speeds. (Acceleration goes to hell). And, at some point, someone will probably want to go 75 up a hill.
The only downside is that you often have to throw more hardware at the problems. I really wish that Apple would either fix AFP or make everything work with NFS, because it caused me way too much pain, and it requires too much power.
The other thing I've run into is that things can get very difficult when you want to do something other than the approved apple way. I inherited a non kerberized ldap system, and I've run into lots of small issues.
That being said, I pretty much maintain somewhere around 300 workstations and 500 laptops mostly by myself. We have a small helpdesk (two FT people and usually a PT), but most of their issues are user error.
If you haven't played with radmind, you should look into it. It's the most amazing tool in the world.
Apple's documentation is wonderful..... if you already know Objective-C. It is pretty bad otherwise. Okay, It's really horrible otherwise, and not that great if you do.
I tend to use http://www.cocoadev.com/ more than anything else. You really should do the basic Apple Currency Converter tutorial first though, as it walks you through the interface. In general, trust the C that you know, but throw out the C++. Things tend to be done with a different approach, so if you can find other code that does a similar thing, the C part of your brain will understand it, but the C++ part will get angry. Eventually, I realized that the C++ part of my brain was also extremely masochistic, so it became easier to ignore it.
Did that help at all? More than anything else, just jump right in. Build and test often, and have fun with it.
While the intel iMac part is regrettable, I don't think that there would be enough demand for other platforms to warrant a port. While it is a stripped down version of OS X, it is still OS X and having a cross development toolchain would greatly complicate things. I get the feeling that the SDK is 90% internal tools.
Objective C is pretty easy to pick up. It really is the language that you want to use for OS X development. Everything fits together rather well, and it is designed to make the developer's life easier. If you know another C like language, you can pick up the basics of ObjC in a weekend. It is also a superset of C, so you can program straight C if you prefer.
You can also use the unofficial SDK. One of the big advantages of the official one is being able to distribute through Apple.
It's certainly not perfect, but it is better than what a lot of people are saying.
Turn it off in the application that embeds the engine, but be warned that "by disabling coalesced updates your application can suffer from issues ranging from visual correctness to tearing during window updates." I really don't want to know how many hours the WebKit team spent trying to limit the things that broke by their hack.
Yeah, that's pretty much exactly why I posted it. IMHO, Apple has been quite good with private APIs. In a major upgrade, they tend to all either become public (often after changing), or die. MS has had a less open history, and I think there are some very valid complaints there, but some are certainly overstated.
There is a public way to do the same thing. They just added a total hack to the API to automatically do something by default when WebKit is embedded, instead of requiring a configuration value to be set. They didn't want it to be publicly available since they want the call to die as soon as they figure out a better way to do it. This isn't MS style stuff. There is no hidden feature. You can run the exact same code in a public way, and the it won't break when your user upgrades WebKit.
David Hyatt Feb 28th, 2008 at 1:24 pm The programmatic disabling of coalesced updates should not be public API. It's actually a very dangerous thing to do. We aren't really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit. Technically it's wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn't even use WebKit.
As for the window display throttling, that was a pref designed for Safari (that we don't even use any more). It's not private or magic. It's nothing more than a pref that we can examine from Safari-land, so linking to that is just silly.;)
Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can't be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard.
As you yourself blogged, there was a totally acceptable public way of doing what you needed to do.
For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it's not public API just because we need to work on Tiger.
MacBooks are not built as well as PowerBooks. MacBook Pros are a bit better, but MacBooks aren't anywhere near as good. Sorry )-: (I support ~ 600 of them)
I just installed the 4.0 beta, and I've been hacking out unnecessary services and tweaking the network settings, which has helped a lot. Thanks for the other tips; I'll look into it.
I have an infrant. It is a piece of shit and the tech support is terrible. It "loses" drives after a week or so, and its NFS support is a joke. Maybe it is just a faulty model, but they refused to replace it.
My guess is that it'd be horrible. It isn't that hard to create a scheduler for a specific task. I wouldn't be suprised if dynebolic were to create a custom scheduler, perhaps even one based on BeOS's, but I wouldn't want to use it on my desktop, and certainly not on my server.
I go back in forth, but I think I agree with Linus that there should be one scheduler that is ordained and 'good' everywhere. If someone wants to make a custom one, they can, but it'd probably do more damage to have them be common.
Seriously, monoculture sucks. Let's get som geothermal, some solar, some nuclear, some tidal and whatever else.
You are mostly right though, we need to replace coal with mostly nuclear, and we need to figure out how to use the fuel more efficiently, because the waste issue is real.
That doesn't work. The market for a machine that requires Intel C and Intel Fortran to run fast is tiny because people use many different compilers and languages in the real world. Not if you're writing software for a supercomputer.
multicore is ultimately more flexible and easier to compile for than superscalar architectures. Do you have a source for this? I look at SMP as being quite a bit harder. Unless you think we should all learn erlang, threads are hard. You don't have to do anything different for superscalar. (At least people didn't)
Putting the work into software is a very good thing. We can change software and recompile, it's harder to change microcode and it is impossible to change silicon.
The biggest problem with EPIC is the hardware upgrade path.
Dude, when Itanium came out, it was the fastest FP core on the planet. It came out how many years late? Correct me if I'm wrong, but as far as I remember alphas were still kicking ass when Itanium came out, and there was a massive outcry of people swearing on everything that is dear to them that alphas have better architecture than Itanium. Anyhow, I won't disagree that there is something very interesting about the concept of Itanium... Hmm, the guy who taught me about the Itanium told it to me. I can't find a source right now; you may be right. Alpha has a beautiful structure. Doing spin-locks is a bitch though.
Anyways, RISC is quite a bit less efficient than CISC with memory bandwidth How come? With RISC, every instruction is the same length, so on the PPC, 32 bits. On CISC, it's anywhere from 8 to 108 (for x86, there may be some that are larger, but you get the idea).
The first thing you can do is play games where common instructions have shorter opcodes, and the second easy one is to not include unneeded register spots. (Adds need 3 registers, loads only need two). Not exactly a CISC thing by definition, but CISC is more likely to do stuff like having a load register and a load address register, so you can put say load as an 8 bit opcode instead of load r1 r2 to load the memory at location r1 into register r2. The net result is that you can more densly pack instructions, which saves disk space (worthless), some disk access (can be worthwhile) and memory bandwidth (very worthwhile). It's also a lot easier to expand the instruction set, so you can do crazy things like saying that this 5 bit opcode is followed by another to open up 32 new instructions that do this set of common OS tasks that take 5 registers and decode to 100 instructions each. The processing time might be the same as on a PPC, but you'd need to fetch fewer instructions from memory.
The downside is that you need to decode instructions everytime you see them, because they are stored as CISC in the caches. This makes your pipeline longer and makes missed branches, interrupts and the like much more expensive. Netburst saves the decoded instructions so that you can save that time (but you lose a bit in on chip memory). This is a pain to get working correctly though, hence some of the growing pains of the P4. It was a good idea, just really really hard.
Even RISC decodes instructions, it's just a lot easier to do, so I doubt that caching them will be worthwhile. Most can be done in one cycle, except for some weird ones. There is a PPC instruction that loads (this is from memory, details are fuzzy) 8 registers at once from memory. There used to be a sweet trick that made this an efficient operation. That was 15 years ago, these days the core just changes it to 8 single loads.
I love processor design. I wish I'd been a better student, but I don't really want to do boring stuff at Intel for 25 years so that they'd let me be on the team that designed some insignificant chipset.
Are you convinced? I can find some better examples if you'd like.
Slashdot Mirror
Merging in city traffic with crazy drivers requires decent acceleration.
In general, I agree with you though.
It's really not fun to drive a car near its maximum speeds. (Acceleration goes to hell). And, at some point, someone will probably want to go 75 up a hill.
One valid advantage of computerized voting is that it is much easier to support different languages and disabled persons.
The only downside is that you often have to throw more hardware at the problems. I really wish that Apple would either fix AFP or make everything work with NFS, because it caused me way too much pain, and it requires too much power.
The other thing I've run into is that things can get very difficult when you want to do something other than the approved apple way. I inherited a non kerberized ldap system, and I've run into lots of small issues.
That being said, I pretty much maintain somewhere around 300 workstations and 500 laptops mostly by myself. We have a small helpdesk (two FT people and usually a PT), but most of their issues are user error.
If you haven't played with radmind, you should look into it. It's the most amazing tool in the world.
Apple's documentation is wonderful..... if you already know Objective-C. It is pretty bad otherwise. Okay, It's really horrible otherwise, and not that great if you do.
I tend to use http://www.cocoadev.com/ more than anything else. You really should do the basic Apple Currency Converter tutorial first though, as it walks you through the interface. In general, trust the C that you know, but throw out the C++. Things tend to be done with a different approach, so if you can find other code that does a similar thing, the C part of your brain will understand it, but the C++ part will get angry. Eventually, I realized that the C++ part of my brain was also extremely masochistic, so it became easier to ignore it.
Did that help at all? More than anything else, just jump right in. Build and test often, and have fun with it.
The only thing they seem to have a monopoly on is fanboys.
There are some Pythonistas and emacs users out back playing D&D to determine who gets to kick your ass over that.
While the intel iMac part is regrettable, I don't think that there would be enough demand for other platforms to warrant a port. While it is a stripped down version of OS X, it is still OS X and having a cross development toolchain would greatly complicate things. I get the feeling that the SDK is 90% internal tools.
Objective C is pretty easy to pick up. It really is the language that you want to use for OS X development. Everything fits together rather well, and it is designed to make the developer's life easier. If you know another C like language, you can pick up the basics of ObjC in a weekend. It is also a superset of C, so you can program straight C if you prefer.
You can also use the unofficial SDK. One of the big advantages of the official one is being able to distribute through Apple.
It's certainly not perfect, but it is better than what a lot of people are saying.
So tell people who embed FF to use the plist option.
http://developer.apple.com/technotes/tn2005/tn2133.html
Turn it off in the application that embeds the engine, but be warned that "by disabling coalesced updates your application can suffer from issues ranging from visual correctness to tearing during window updates." I really don't want to know how many hours the WebKit team spent trying to limit the things that broke by their hack.
Yeah, that's pretty much exactly why I posted it. IMHO, Apple has been quite good with private APIs. In a major upgrade, they tend to all either become public (often after changing), or die. MS has had a less open history, and I think there are some very valid complaints there, but some are certainly overstated.
There is a public way to do the same thing. They just added a total hack to the API to automatically do something by default when WebKit is embedded, instead of requiring a configuration value to be set. They didn't want it to be publicly available since they want the call to die as soon as they figure out a better way to do it. This isn't MS style stuff. There is no hidden feature. You can run the exact same code in a public way, and the it won't break when your user upgrades WebKit.
So, no, you aren't getting it right.
David Hyatt
;)
Feb 28th, 2008 at 1:24 pm
The programmatic disabling of coalesced updates should not be public API. It's actually a very dangerous thing to do. We aren't really happy with that code in WebKit, but we had to do it to avoid performance regressions in apps that embedded WebKit. Technically it's wrong though, since we turn off the coalesced updates for any app that uses WebKit! This includes drawing they do that doesn't even use WebKit.
As for the window display throttling, that was a pref designed for Safari (that we don't even use any more). It's not private or magic. It's nothing more than a pref that we can examine from Safari-land, so linking to that is just silly.
Many of the private methods that WebKit uses are private for a reason. Either they expose internal structures that can't be depended on, or they are part of something inside a framework that may not be fully formed. WebKit subclasses several private NSView methods for example, and it cost us many many man hours to deal with the regressions caused by the internal changes that were made to NSViews in Leopard.
As you yourself blogged, there was a totally acceptable public way of doing what you needed to do.
For any private methods we use that we think should be public, we (the WebKit team) file bugs on the appropriate system components. Many of these methods have become public over time (CG stuff in Leopard for example). Be careful when you dig into WebKit code, since we may continue to use the WK method even though it's not public API just because we need to work on Tiger.
We're Winning!
How does this compare to the CCC crack? Can it do all of the encryption standards?
http://video.google.com/videoplay?docid=8955054591690672567&q=CCC+GSM&total=2&start=0&num=10&so=0&type=search&plindex=0
MacBooks are not built as well as PowerBooks. MacBook Pros are a bit better, but MacBooks aren't anywhere near as good. Sorry )-: (I support ~ 600 of them)
I just installed the 4.0 beta, and I've been hacking out unnecessary services and tweaking the network settings, which has helped a lot. Thanks for the other tips; I'll look into it.
Ep 3 was complete and total shite. Even being drunk couldn't make it watchable.
I have an infrant. It is a piece of shit and the tech support is terrible. It "loses" drives after a week or so, and its NFS support is a joke. Maybe it is just a faulty model, but they refused to replace it.
Infrant is crap. Don't buy it.
My guess is that it'd be horrible. It isn't that hard to create a scheduler for a specific task. I wouldn't be suprised if dynebolic were to create a custom scheduler, perhaps even one based on BeOS's, but I wouldn't want to use it on my desktop, and certainly not on my server.
I go back in forth, but I think I agree with Linus that there should be one scheduler that is ordained and 'good' everywhere. If someone wants to make a custom one, they can, but it'd probably do more damage to have them be common.
Let's do both!
Seriously, monoculture sucks. Let's get som geothermal, some solar, some nuclear, some tidal and whatever else.
You are mostly right though, we need to replace coal with mostly nuclear, and we need to figure out how to use the fuel more efficiently, because the waste issue is real.
Yeah, but how was it as a LAMP stack?
Yeah, I'm watching the AFL-CIO primary debates, and I'm glad that I didn't watch it live.
Any clue if the comedy central motherload thing makes money?
http://www.coda.cs.cmu.edu/
Putting the work into software is a very good thing. We can change software and recompile, it's harder to change microcode and it is impossible to change silicon.
The biggest problem with EPIC is the hardware upgrade path.
came out, and there was a massive outcry of people swearing on everything that is dear to them that alphas have better architecture than Itanium. Anyhow, I won't disagree that there is something very interesting about the concept of Itanium... Hmm, the guy who taught me about the Itanium told it to me. I can't find a source right now; you may be right. Alpha has a beautiful structure. Doing spin-locks is a bitch though. Anyways, RISC is quite a bit less efficient than CISC with memory bandwidth How come? With RISC, every instruction is the same length, so on the PPC, 32 bits. On CISC, it's anywhere from 8 to 108 (for x86, there may be some that are larger, but you get the idea).
The first thing you can do is play games where common instructions have shorter opcodes, and the second easy one is to not include unneeded register spots. (Adds need 3 registers, loads only need two). Not exactly a CISC thing by definition, but CISC is more likely to do stuff like having a load register and a load address register, so you can put say load as an 8 bit opcode instead of load r1 r2 to load the memory at location r1 into register r2. The net result is that you can more densly pack instructions, which saves disk space (worthless), some disk access (can be worthwhile) and memory bandwidth (very worthwhile). It's also a lot easier to expand the instruction set, so you can do crazy things like saying that this 5 bit opcode is followed by another to open up 32 new instructions that do this set of common OS tasks that take 5 registers and decode to 100 instructions each. The processing time might be the same as on a PPC, but you'd need to fetch fewer instructions from memory.
The downside is that you need to decode instructions everytime you see them, because they are stored as CISC in the caches. This makes your pipeline longer and makes missed branches, interrupts and the like much more expensive. Netburst saves the decoded instructions so that you can save that time (but you lose a bit in on chip memory). This is a pain to get working correctly though, hence some of the growing pains of the P4. It was a good idea, just really really hard.
Even RISC decodes instructions, it's just a lot easier to do, so I doubt that caching them will be worthwhile. Most can be done in one cycle, except for some weird ones. There is a PPC instruction that loads (this is from memory, details are fuzzy) 8 registers at once from memory. There used to be a sweet trick that made this an efficient operation. That was 15 years ago, these days the core just changes it to 8 single loads.
I love processor design. I wish I'd been a better student, but I don't really want to do boring stuff at Intel for 25 years so that they'd let me be on the team that designed some insignificant chipset.
Are you convinced? I can find some better examples if you'd like.