You know that goes for the missile targeting the ship as well right? Radar doesn't magically work better for the attacker than for the defender.
Of course! All I was pointing out was that the same conditions that work against a laser also work against a shell. The laser might be affected more than the shell but both of them are going to be difficult to use under those conditions.
And actually, radar usually works better for the attacker than the defender - if the defender is running radar then the missile can just home in on that signal!
All of these designs use highly radioactive material as fuel and that will always work for a dirty bomb.
Also they use the same fuel grade uranium as other reactors use, which is very expensive and valuable and it can be stolen. It would be incredibly foolish to leave these reactors unguarded.
The type of fissionable material in these sorts of reactors is not of much use in constructing a dirty bomb, not to mention that the amount of material is relatively sparse and would result in more of a scare rather than an actual threat. The form of the material would generally only be of use for a specific type of reactor and wouldn't be anywhere near as useful as raw uranium, you'd basically have to re-refine it and then why go through all the trouble to steal it? Just steal it from a mine or mine it yourself.
As someone else pointed out, it would be extremely tough to break into the small reactors in the first place. They are being designed as sealed bunkers that are buried under ground and will most likely have monitoring equipment. Any attempt to break into these reactors would be expensive, take a considerable amount of time and effort, and by the time you succeeded you'd have authorities all over you. They just wouldn't make good targets, robbing bank would probably be a better way of making money!
If you think the only thing they are doing is mixing uranium with graphite then you haven't done your research and you don't understand exactly why they aren't the same as pure fuel grade uranium. A lot more goes into the construction of the fuel pellets and the entire process makes the fuel much more specialized and less valuable as bombs or fuel for other reactors.
Really? and how would keep anyone from taking the whole thing breaking it apart somewhere else and selling the valuable fuel grade uranium on the black market?
Or worse yet, using the uranium and all the radioactive parts of the reactor for a dirty bomb?
Or even worse yet, trying to do one of the above, but fucking up and letting all kinds of radioactive liquids drain in the drinking water underground?
In most of these small reactor designs the fissionable material has nearly no value as a weapon. For example, a Pebble Bed Reactor uses balls of graphite and fissionable material which can be difficult to re-process into something other than fuel. A dirty bomb is of little concern because, again, it's much easier to just mine new material rather than use the fuel for these reactors.
Lastly, the modern designs for reactors are extremely safe. They have less chance of contaminating groundwater supply than building solar panels (a process that requires tons of heavy metals, organic wastes, and wastewater) or operating a coal-fired power plant. Not to mention that once you are done using the fuel and reprocessing it into new fuel you are left with a small amount of concentrated waste with either extremely short (degrades quickly to harmless elements) or extremely long (emits nearly no radiation) lifetimes.
The modern nuclear reactor designs are vastly better than the units built 40+ years ago, it's a shame that we haven't been building them. Instead we are maintaining older units because the red tape is too much to bother building new units to replace the aging ones. THAT'S your recipe for disaster!
How well does a laser punch through heavy fog and rain that one will definitely run into at sea; especially in places like the North and South Atlantic? I am pretty sure a 20mm cannon shell will travel quite a distance through fog.
You're going to have a pretty hard time doing any targeting at all in heavy rain/fog so that cuts down on the differences between a laser and a shell under those conditions. Yes, you can still get some idea of where the target is through radar but remember that rain/fog also has a bit of an effect on radar - that's why they use it to detect rain and storm clouds.
Heavy rain and fog will also affect the range and accuracy of kinetic weapons, the denser the material that the shell goes through the more it will affect the trajectory. Shells go much further and are more accurate in hot, still desert air then they are be in a howling pea-soup storm at sea. Again, the laser will be affected even more by rough weather but getting a shell to hit the target under similar conditions is no easy task.
And why don't we deploy those kind of units in the municipal power grid?
Actually they do just that in case of an emergency. There are connectors and such that can attach to a power grid in times of emergency so that the ships can provide power to emergency services and so on. I believe they've actually used them a few times.
As to why they don't make these types of units a regular part of the grid it's because they have much different requirements than a land-based power plant. The price per watt is much higher for a power-plant on a ship than one on land due to size, weight, combat-worthiness, and many other factors.
Don't most email clients that display html format messages use one of the popular rendering engines, like Webkit? Presumably the html portion of the message is just passed to the rendering engine and the javascript magic happens
Which is exactly why I ONLY view my e-mail in plain text. If your message has anything other than plain text then it better be a MIME attachment that I can validate BEFORE I open it.
HTML (et al.) are just bolted onto e-mail and it shows. If you want your e-mail to be slow loading, poorly-formatted, tons of obnoxious graphics, and full of unnecessary data then by all means turn on the HTML-in-e-mail features in your e-mail client. Just don't expect me to read it if that client doesn't send me a e-mail that gracefully falls back to a text-only version.
Even better would be a means of pulling carbon from the air over at the generation plant, generating hydrogen gas
And how do you propose we convert this carbon into hydrogen? You may not realize this but most of the carbon in the air is in the form of CO2. There is NO workable manmade process which will convert CO2 into H2.
Now if you wanted to do some complex nuclear fission you MIGHT be able to turn carbon and oxygen into hydrogen but I bet it's gonna be much more trouble than it's worth...
Sure, but those aren't the products that are loved here. It's the Iphone and Ipad, which is the most closed (both in terms of source, and also control over who can develop for it) mobile platform.
Both of which run on Darwin, Apple's open-source operating system. In fact, a good chunk of iOS (the operating system that both the iPhone, iPod Touch, and iPad run on) is open source with really only the GUI proprietary. Also, development for iOS is completely open. You can develop and distribute source code completely for free.
Yes, to deploy binaries to an iPhone you need to be a registered developer but if you jailbreak your iPhone that restriction disappears. It also doesn't stop you from distributing your source code and allowing other people to register as developers and install your software on their phone. Apple's proprietary elements are, in most cases, a speed bump.
The other thing is ease of development for a platform. Many people have said that iOS is great to develop for. The SDKs are well organized and well thought-out, there is lots of documentation, the tools are great to work with, and Objective-C is a great language for getting stuff done. I've heard horror stories of developing on Symbian and Windows Mobile and Android currently has a problem with how diverse its platform is, it's tough to code for all the varying feature sets that might be out there. Not to mention that you can make a ton more money per development hour by targeting iOS over any other mobile platform.
He probably is talking about the closing down of the BSD kernel (even though it's permitted in its license agreement).
They don't use the BSD kernel, they use their own custom kernel called XNU which is based on Mach. Some elements of the BSD kernel are included in this kernel but it was never closed down. It's released under the Apple Public Source License (APSL) which qualifies as open source and the source code can be found here: XNU source
Seriously, for an Open Source community it's outstanding how many Apple fanatics here are, when they are obviously the largest abuser of OSS or open technology.
Blizzard should simply tie forum names to accounts in an opaque manner. You can only create a forum name if you have an account, and you can only create one per account and only if you have a game key activated on that account. The forum name can't be the same as the account username (to prevent disclosure), and once created you can't change it (CS can change it for you, but you have to give them a good reason to). That solves most of the problem without requiring real names anywhere.
I'd take it a bit further. I'd make it so that you sign up for the service with your real name/credit card/e-mail. You then create an account identity which cannot be your real name or e-mail. After that you can create characters, play the game, and use the forums as those characters as normal with one exception: anyone can see your account identity (not your real-life details) if they want to. They can also friend you and ignore you by that identity, and so on.
Way too many people hide behind the "create a normal character and a bunch of disposable trolling characters". This would curtail the practice and contribute a ton to the health of the community. Essentially you would have a solid, dependable identity for each person which wouldn't reveal real details about the person.
I'd like to see the text of the agreement. I suspect they could break it very easily by not calling the new phone an "iPhone"
Yes, I'm sure that AT&T's lawyers were dumb enough not to close the "Name it the vPhone and we can get around the agreement!" loophole or any of the other loopholes you mentioned.
Instead of assuming that AT&T hires stupid lawyers I think that it's more likely that the agreement between Apple and AT&T allows either company to break the contract by paying some sort of penalty. This is pretty standard between large corporations. Of course, it would have to be a large penalty so that the agreement couldn't be broken trivially.
Which is why I said that Objective-C is C with extensions, if you discount the extensions then what's left is C. I was trying to express it in layman's terms because it's very difficult to draw Venn diagrams in text!;-)
But yes, the intersection of the sets of Objective-C and C includes all of C but not all of Objective-C. You can write a pure C function or variable and use it within Objective-C code without any problems at all.
Didn't Apple have some anti-competitive rules that allowed only Objective-C to be used in programming for the iPhone?
Objective-C is C. Objective-C is a strict superset of C so there's no difference between C code and Objective-C except for the extensions that Objective-C has added.
Even if Objective-C didn't include all of C it would still be OK. Apple allows iOS apps to be written in Objective-C, C, and C++. These languages were chosen because they are supported under Apple's API for iOS.
Had we used your rules, we would have killed one for sure, and likely shot through the assailant and injured or killed the girl -- which would have defeated the purpose.
Had we used my rules the gun would not have been pulled out at all. You don't pull a gun out unless you intend to use it to kill someone AND you are pretty sure that no one else will be hurt.
I wasn't in the situation but I'm guessing the best answer would have been to use your fists or some handy blunt instrument instead of the gun. However, he did accomplish what he wanted so it all worked out in the end. I just don't like the risk of threatening with a gun, it runs counter to all the weapons training I've received.
Your 300dpi color inkjet (or laserjet) doesn't print halftoned images, and that's what GP was talking about.
True enough, I didn't look back far enough to see that an earlier post mentioned laser printers. Inkjet printers are another matter because there are many different types of technology and some of them do use different size pixels.
There's a huge difference between 300dpi in printing where your C,Y,M or K is either on or off, and 300dpi in systems where the C,Y and M or your R, G and B come in 256+ levels.
That's not actually how halftoning works in print. You have various levels of ink coverage at each "pixel" location, what they do is vary the dot size from large enough to cover all of the paper at that location to no ink at all. You easily achieve 256 levels of intensity at each location when halftoning.
I partly blame GE and hormone-treated food for many of the crappy allergies that have risen over the years
I blame the easter bunny and the tooth fairy. They clearly have a conspiracy to make us itchy, uncomfortable, and forced to avoid good food.
The problem is that we have a few whackjobs making unfounded allegations not backed by any sort of scientific evidence. We might as well go back to blaming illness on "bad humors" and witches cursing us. Until we have solid, reliable scientific studies as to the causes we harm ourselves more by grasping at straws than by taking small, sensible steps to treat the symptoms.
Perhaps Apple (and others) need to shift emphasis back towards the actual calling features of their phones. Who wants a phone that drops calls if you hold it wrong ?
Well I got my iPhone 4 this morning, upgrading from an old first generation iPhone. So far I've noticed a definite improvement in signal and call quality. I've also tested the method of holding which supposedly results in lower signal levels in one of the linked articles. I didn't see any difference in signal quality that correlated with any way I held the phone. I did see slight fluctuations in signal quality but it never corresponded to how I was holding the phone.
My test methodology was to place the iPhone in one place on a table for 5 minutes, observing average signal strength and variation. It hovered around 4 bars, sometimes going up to 5 or down to 3. I would then hold it by cradling each corner and each side for 5 minutes, doing the same observation. At all times I saw an average of 4 bars and approximately the same amount of variation. The variation appeared to be random and didn't exhibit any noticeable periodicity.
My 1st-gen iPhone would average around 3 bars under similar conditions and in the same location. In addition the sound quality is amazingly better with the latest phone over the old one.
It certainly seems to me that Apple has put emphasis on the calling features of the iPhone 4.
The 2 octaves overhead allows for subsequent processing, re-sampling, and pitch-shifting/time-stretching. Pitch-shifting 2 octaves down, for example, effectively converts a 192 kHz recording to 48 kHz; the extra bandwidth offers a sound designer flexibility.
No, it does not unless you are starting with frequencies ABOVE 20 kHz which would normally be inaudible to human ears.
If we are talking about sounds that a human can hear then you do not need the additional samples to shift the pitch down. Signals that are at 20 kHz and were captured at a sample rate of 40 kHz can be shifted down 2 octaves to 5 kHz without losing any quality since a 5 kHz signal would only need a sample rate of 10 kHz. It doesn't matter that your signal is effectively 10 kHz, that downshifted signal is 5 kHz and doesn't need a higher sample rate.
If, instead, you are pitch-shifting upward you don't want to go over 20 kHz anyways because no one could hear it! The maximum sample rate you need for anything that humans are going to listen to is 40 kHz. Yes, some overhead is nice because you will lose some resolution when manipulating the data but 192 kHz is absolutely ridiculous, even 96 kHz is overkill.
If you really need these huge sampling rates then I'd take a good, hard look at your equipment because something is wrong with it. I'm an instrumental/analytical chemist and I work with signal theory constantly in building and tuning instruments. We never have to resort to over 9 times the sampling frequency of the signal we want to capture, 2 or 3 times gives extremely accurate results no matter how much post-processing we need to do.
Just to put this all in perspective the highest note on a standard piano is C8. It has a frequency of 4,186 Hz (in 12 tone equal temperament) which means that you need a sample rate of 8,372 Hz to capture it. If you sample at 40 kHz you will not only get its first harmonic but also the second, third, AND fourth harmonics - and nearly the fifth! The only reason we need to sample at a rate of 40 kHz in the first place is that transient sounds like cymbals, buzzes, hisses, and clicks often include higher harmonics in the 15 - 20 kHz range and if you don't capture those then you lose some of the character of the music. By sampling at a rate over 40 kHz we accurately capture those signals and preserve the original recording in such a way that humans can fully enjoy it.
By having higher sampling rates, we can have have our low pass filters on the adc input have a more gradual effect, starting at a cutoff that is far above the range of human hearing. For example, at 196 kHz, our Nyquist frequency is 98 kHz. We could use a low pass filter with a cutoff of 40 kHz, which would roll off nicely before 98 kHz and would hardly affect any spectral content in the human hearing range.
192 kHz is still massive overkill. Nearly all humans can't hear above 20 kHz (in fact most can't hear over 16 kHz) and a 10% or 20% roll-off is pretty much just fine to cover most low pass filters. You can comfortably low-pass at 20 kHz and sample at 48 kHz (a DAT standard rate) and not notice any difference between the original signal and the sampled and reconstructed signal.
It also serves as some overhead for the Nyquist-Shannon sampling. There is no such thing as an ideal low-pass filter so you'll get some leakage of frequencies over 20k, plus the theorem states that you need infinite past and future data to 100% recover the waveform. Going to 44.1 kHz and getting 10% overhead is a good rule of thumb, although going to 48 kHz and getting 20% can't hurt.
If you're recording audio, you should probably sample at 96khz so that when you pass it through a plugin that does something temporally with the audio, there's less artifacts.
Yeah, if you're doing a lot of post-processing then going for an even higher sampling rate can help a bit but it's really diminishing returns. 96 kHz is definitely overkill and 192 kHz is just idiotic.
For playback, you don't need 96khz, unless you have thousand-dollar speakers. (I tried some out, the difference exists).
Some thousand-dollar speakers are worth the cost although there is a lot of snake oil at that price point. Caveat emptor on pricy acoustic gear! However, 96 kHz will sound almost exactly the same as 44.1 kHz no matter how expensive the speakers.
On the other hand, a bad audio player will have poorly designed digital to analog converters which won't interpolate the digital signal in such a way as to reconstruct the original signal faithfully. In that case a 44.1 kHz signal can sound worse than a 96 kHz signal because of zero-order hold, aliasing, and other factors.
This doesn't mean that expensive equipment is automatically better, just that a lot of times you get what you pay for on the extreme low-end. Most mid-range equipment does a decent job reproducing the original signal.
Pardon my ignorance, but what is the point of a 192KHz sampling rate? The maximum frequency you can push through that is 96Khz, which is way above human hearing. In fact, the human hearing range is between 20Hz and 20KHz, so even 44KHz sampling rate should be more than enough. Or am I missing something important?
A lot of people don't really understand how to apply the Nyquist-Shannon sampling theorem and so they look at the "jaggy" sampled waveform and think that it will sound horrible if it is output. It's true that if you output the samples directly then you are going to hear artifacts but if you apply the Whittaker-Shannon interpolation formula then you get back the original waveforms and the output will sound nearly identical to the original.
Of course this is all best-case and since we live in the real world with imperfect low-pass filters and non-infinite past and future data we will still get artifacts if we sample at the minimum rate. That's (part of) the reason why we sample at 44.1 kHz instead of 40 kHz, to allow some overhead to account for these non-ideal factors. You absolutely do NOT need to sample at 192 kHz, if you do you are just wasting storage space on your digital media. I believe the default for a DAT is 48 kHz and that's pretty much the maximum you should ever use.
That is, unless you are doing recordings for bats and dogs to listen to...
The main difference between Mac OS and iOS is you can't code on iOS. It's partly a security feature and partly an anti-complexity feature. iOS is for a non-coding approach to all tasks. You may not know this, but a Photoshop pro writes a ton of code. The home user working with their photos doesn't need to.
Huh? This makes no sense at all. Yes, Apple toyed with the idea of having no interpreted code in iOS 4 but they relaxed that restriction before it even came out of beta. You can now use interpreted code, such as LUA, in your apps.
There is absolutely no restriction in the iOS API itself that doesn't let you "code on iOS", it was a prohibition against your app being sold in the App Store and it was designed to stop people from subverting Apple's API by writing their program in another language with a thin translation layer on top. If Apple went ahead with the original restriction it would have been very heavy-handed, the current rules are much more reasonable.
Another feature of iOS is no custom drivers. The USB audio interfaces that work with iOS are the "class compliant" ones that work with the system's universal driver.
iOS can certainly have custom drivers if they needed it, its core is still Darwin. The thing is that right now iOS is only used on closed systems like the iPhone and the iPad. There's not much need to have a custom driver for a device that really can't have additional hardware installed on it. As such, Apple doesn't provide a way to install any custom drivers but you can certainly jailbreak your device and add custom drivers galore if you want to.
I can't imagine how a calendar developed for a 2" touchscreen could have the same interface as a calendar developed for a 21" keyboard-and-mouse, and not have it be terrible. Similarly, a copy of Word on the iPhone and a copy of Word on a PC would necessarily need to have very different interfaces... You can't get hover tips on a touchscreen, people don't gesture with keyboards, mice aren't multitouch, and iPhone screens are tiny.
Which is exactly why Apple based all of its APIs, both iOS and Mac OS, around the Model-View-Controller (MVC) design pattern. This way you can have your view logic separate from your model and controller logic and you can customize your view based on the device it is presented upon. It allows you to easily re-use your code between different devices and you can develop views specifically optimized to be shown on a certain type of device.
Since both iOS and Mac OS are Cocoa they share almost all of the same API with a couple of differences mostly related to the user interface. It's trivial to have a project with a target for iOS and a target for Mac OS that share the same model and controller code but that have different view code optimized for the target device.
Slashdot Mirror
You know that goes for the missile targeting the ship as well right? Radar doesn't magically work better for the attacker than for the defender.
Of course! All I was pointing out was that the same conditions that work against a laser also work against a shell. The laser might be affected more than the shell but both of them are going to be difficult to use under those conditions.
And actually, radar usually works better for the attacker than the defender - if the defender is running radar then the missile can just home in on that signal!
All of these designs use highly radioactive material as fuel and that will always work for a dirty bomb.
Also they use the same fuel grade uranium as other reactors use, which is very expensive and valuable and it can be stolen. It would be incredibly foolish to leave these reactors unguarded.
The type of fissionable material in these sorts of reactors is not of much use in constructing a dirty bomb, not to mention that the amount of material is relatively sparse and would result in more of a scare rather than an actual threat. The form of the material would generally only be of use for a specific type of reactor and wouldn't be anywhere near as useful as raw uranium, you'd basically have to re-refine it and then why go through all the trouble to steal it? Just steal it from a mine or mine it yourself.
As someone else pointed out, it would be extremely tough to break into the small reactors in the first place. They are being designed as sealed bunkers that are buried under ground and will most likely have monitoring equipment. Any attempt to break into these reactors would be expensive, take a considerable amount of time and effort, and by the time you succeeded you'd have authorities all over you. They just wouldn't make good targets, robbing bank would probably be a better way of making money!
If you think the only thing they are doing is mixing uranium with graphite then you haven't done your research and you don't understand exactly why they aren't the same as pure fuel grade uranium. A lot more goes into the construction of the fuel pellets and the entire process makes the fuel much more specialized and less valuable as bombs or fuel for other reactors.
Really? and how would keep anyone from taking the whole thing breaking it apart somewhere else and selling the valuable fuel grade uranium on the black market?
Or worse yet, using the uranium and all the radioactive parts of the reactor for a dirty bomb?
Or even worse yet, trying to do one of the above, but fucking up and letting all kinds of radioactive liquids drain in the drinking water underground?
In most of these small reactor designs the fissionable material has nearly no value as a weapon. For example, a Pebble Bed Reactor uses balls of graphite and fissionable material which can be difficult to re-process into something other than fuel. A dirty bomb is of little concern because, again, it's much easier to just mine new material rather than use the fuel for these reactors.
Lastly, the modern designs for reactors are extremely safe. They have less chance of contaminating groundwater supply than building solar panels (a process that requires tons of heavy metals, organic wastes, and wastewater) or operating a coal-fired power plant. Not to mention that once you are done using the fuel and reprocessing it into new fuel you are left with a small amount of concentrated waste with either extremely short (degrades quickly to harmless elements) or extremely long (emits nearly no radiation) lifetimes.
The modern nuclear reactor designs are vastly better than the units built 40+ years ago, it's a shame that we haven't been building them. Instead we are maintaining older units because the red tape is too much to bother building new units to replace the aging ones. THAT'S your recipe for disaster!
How well does a laser punch through heavy fog and rain that one will definitely run into at sea; especially in places like the North and South Atlantic? I am pretty sure a 20mm cannon shell will travel quite a distance through fog.
You're going to have a pretty hard time doing any targeting at all in heavy rain/fog so that cuts down on the differences between a laser and a shell under those conditions. Yes, you can still get some idea of where the target is through radar but remember that rain/fog also has a bit of an effect on radar - that's why they use it to detect rain and storm clouds.
Heavy rain and fog will also affect the range and accuracy of kinetic weapons, the denser the material that the shell goes through the more it will affect the trajectory. Shells go much further and are more accurate in hot, still desert air then they are be in a howling pea-soup storm at sea. Again, the laser will be affected even more by rough weather but getting a shell to hit the target under similar conditions is no easy task.
And why don't we deploy those kind of units in the municipal power grid?
Actually they do just that in case of an emergency. There are connectors and such that can attach to a power grid in times of emergency so that the ships can provide power to emergency services and so on. I believe they've actually used them a few times.
As to why they don't make these types of units a regular part of the grid it's because they have much different requirements than a land-based power plant. The price per watt is much higher for a power-plant on a ship than one on land due to size, weight, combat-worthiness, and many other factors.
Don't most email clients that display html format messages use one of the popular rendering engines, like Webkit? Presumably the html portion of the message is just passed to the rendering engine and the javascript magic happens
Which is exactly why I ONLY view my e-mail in plain text. If your message has anything other than plain text then it better be a MIME attachment that I can validate BEFORE I open it.
HTML (et al.) are just bolted onto e-mail and it shows. If you want your e-mail to be slow loading, poorly-formatted, tons of obnoxious graphics, and full of unnecessary data then by all means turn on the HTML-in-e-mail features in your e-mail client. Just don't expect me to read it if that client doesn't send me a e-mail that gracefully falls back to a text-only version.
Even better would be a means of pulling carbon from the air over at the generation plant, generating hydrogen gas
And how do you propose we convert this carbon into hydrogen? You may not realize this but most of the carbon in the air is in the form of CO2. There is NO workable manmade process which will convert CO2 into H2.
Now if you wanted to do some complex nuclear fission you MIGHT be able to turn carbon and oxygen into hydrogen but I bet it's gonna be much more trouble than it's worth...
Sure, but those aren't the products that are loved here. It's the Iphone and Ipad, which is the most closed (both in terms of source, and also control over who can develop for it) mobile platform.
Both of which run on Darwin, Apple's open-source operating system. In fact, a good chunk of iOS (the operating system that both the iPhone, iPod Touch, and iPad run on) is open source with really only the GUI proprietary. Also, development for iOS is completely open. You can develop and distribute source code completely for free.
Yes, to deploy binaries to an iPhone you need to be a registered developer but if you jailbreak your iPhone that restriction disappears. It also doesn't stop you from distributing your source code and allowing other people to register as developers and install your software on their phone. Apple's proprietary elements are, in most cases, a speed bump.
The other thing is ease of development for a platform. Many people have said that iOS is great to develop for. The SDKs are well organized and well thought-out, there is lots of documentation, the tools are great to work with, and Objective-C is a great language for getting stuff done. I've heard horror stories of developing on Symbian and Windows Mobile and Android currently has a problem with how diverse its platform is, it's tough to code for all the varying feature sets that might be out there. Not to mention that you can make a ton more money per development hour by targeting iOS over any other mobile platform.
He probably is talking about the closing down of the BSD kernel (even though it's permitted in its license agreement).
They don't use the BSD kernel, they use their own custom kernel called XNU which is based on Mach. Some elements of the BSD kernel are included in this kernel but it was never closed down. It's released under the Apple Public Source License (APSL) which qualifies as open source and the source code can be found here: XNU source
Seriously, for an Open Source community it's outstanding how many Apple fanatics here are, when they are obviously the largest abuser of OSS or open technology.
[Citation Needed]
I'd say that Apple actually is a pretty strong supporter of open source. Here's my citation on the subject:
Open source projects in which Apple is involved.
Blizzard should simply tie forum names to accounts in an opaque manner. You can only create a forum name if you have an account, and you can only create one per account and only if you have a game key activated on that account. The forum name can't be the same as the account username (to prevent disclosure), and once created you can't change it (CS can change it for you, but you have to give them a good reason to). That solves most of the problem without requiring real names anywhere.
I'd take it a bit further. I'd make it so that you sign up for the service with your real name/credit card/e-mail. You then create an account identity which cannot be your real name or e-mail. After that you can create characters, play the game, and use the forums as those characters as normal with one exception: anyone can see your account identity (not your real-life details) if they want to. They can also friend you and ignore you by that identity, and so on.
Way too many people hide behind the "create a normal character and a bunch of disposable trolling characters". This would curtail the practice and contribute a ton to the health of the community. Essentially you would have a solid, dependable identity for each person which wouldn't reveal real details about the person.
I'd like to see the text of the agreement. I suspect they could break it very easily by not calling the new phone an "iPhone"
Yes, I'm sure that AT&T's lawyers were dumb enough not to close the "Name it the vPhone and we can get around the agreement!" loophole or any of the other loopholes you mentioned.
Instead of assuming that AT&T hires stupid lawyers I think that it's more likely that the agreement between Apple and AT&T allows either company to break the contract by paying some sort of penalty. This is pretty standard between large corporations. Of course, it would have to be a large penalty so that the agreement couldn't be broken trivially.
Which is why I said that Objective-C is C with extensions, if you discount the extensions then what's left is C. I was trying to express it in layman's terms because it's very difficult to draw Venn diagrams in text! ;-)
But yes, the intersection of the sets of Objective-C and C includes all of C but not all of Objective-C. You can write a pure C function or variable and use it within Objective-C code without any problems at all.
Didn't Apple have some anti-competitive rules that allowed only Objective-C to be used in programming for the iPhone?
Objective-C is C. Objective-C is a strict superset of C so there's no difference between C code and Objective-C except for the extensions that Objective-C has added.
Even if Objective-C didn't include all of C it would still be OK. Apple allows iOS apps to be written in Objective-C, C, and C++. These languages were chosen because they are supported under Apple's API for iOS.
Had we used your rules, we would have killed one for sure, and likely shot through the assailant and injured or killed the girl -- which would have defeated the purpose.
Had we used my rules the gun would not have been pulled out at all. You don't pull a gun out unless you intend to use it to kill someone AND you are pretty sure that no one else will be hurt.
I wasn't in the situation but I'm guessing the best answer would have been to use your fists or some handy blunt instrument instead of the gun. However, he did accomplish what he wanted so it all worked out in the end. I just don't like the risk of threatening with a gun, it runs counter to all the weapons training I've received.
Your 300dpi color inkjet (or laserjet) doesn't print halftoned images, and that's what GP was talking about.
True enough, I didn't look back far enough to see that an earlier post mentioned laser printers. Inkjet printers are another matter because there are many different types of technology and some of them do use different size pixels.
There's a huge difference between 300dpi in printing where your C,Y,M or K is either on or off, and 300dpi in systems where the C,Y and M or your R, G and B come in 256+ levels.
That's not actually how halftoning works in print. You have various levels of ink coverage at each "pixel" location, what they do is vary the dot size from large enough to cover all of the paper at that location to no ink at all. You easily achieve 256 levels of intensity at each location when halftoning.
I partly blame GE and hormone-treated food for many of the crappy allergies that have risen over the years
I blame the easter bunny and the tooth fairy. They clearly have a conspiracy to make us itchy, uncomfortable, and forced to avoid good food.
The problem is that we have a few whackjobs making unfounded allegations not backed by any sort of scientific evidence. We might as well go back to blaming illness on "bad humors" and witches cursing us. Until we have solid, reliable scientific studies as to the causes we harm ourselves more by grasping at straws than by taking small, sensible steps to treat the symptoms.
Perhaps Apple (and others) need to shift emphasis back towards the actual calling features of their phones. Who wants a phone that drops calls if you hold it wrong ?
Well I got my iPhone 4 this morning, upgrading from an old first generation iPhone. So far I've noticed a definite improvement in signal and call quality. I've also tested the method of holding which supposedly results in lower signal levels in one of the linked articles. I didn't see any difference in signal quality that correlated with any way I held the phone. I did see slight fluctuations in signal quality but it never corresponded to how I was holding the phone.
My test methodology was to place the iPhone in one place on a table for 5 minutes, observing average signal strength and variation. It hovered around 4 bars, sometimes going up to 5 or down to 3. I would then hold it by cradling each corner and each side for 5 minutes, doing the same observation. At all times I saw an average of 4 bars and approximately the same amount of variation. The variation appeared to be random and didn't exhibit any noticeable periodicity.
My 1st-gen iPhone would average around 3 bars under similar conditions and in the same location. In addition the sound quality is amazingly better with the latest phone over the old one.
It certainly seems to me that Apple has put emphasis on the calling features of the iPhone 4.
The 2 octaves overhead allows for subsequent processing, re-sampling, and pitch-shifting/time-stretching. Pitch-shifting 2 octaves down, for example, effectively converts a 192 kHz recording to 48 kHz; the extra bandwidth offers a sound designer flexibility.
No, it does not unless you are starting with frequencies ABOVE 20 kHz which would normally be inaudible to human ears.
If we are talking about sounds that a human can hear then you do not need the additional samples to shift the pitch down. Signals that are at 20 kHz and were captured at a sample rate of 40 kHz can be shifted down 2 octaves to 5 kHz without losing any quality since a 5 kHz signal would only need a sample rate of 10 kHz. It doesn't matter that your signal is effectively 10 kHz, that downshifted signal is 5 kHz and doesn't need a higher sample rate.
If, instead, you are pitch-shifting upward you don't want to go over 20 kHz anyways because no one could hear it! The maximum sample rate you need for anything that humans are going to listen to is 40 kHz. Yes, some overhead is nice because you will lose some resolution when manipulating the data but 192 kHz is absolutely ridiculous, even 96 kHz is overkill.
If you really need these huge sampling rates then I'd take a good, hard look at your equipment because something is wrong with it. I'm an instrumental/analytical chemist and I work with signal theory constantly in building and tuning instruments. We never have to resort to over 9 times the sampling frequency of the signal we want to capture, 2 or 3 times gives extremely accurate results no matter how much post-processing we need to do.
Just to put this all in perspective the highest note on a standard piano is C8. It has a frequency of 4,186 Hz (in 12 tone equal temperament) which means that you need a sample rate of 8,372 Hz to capture it. If you sample at 40 kHz you will not only get its first harmonic but also the second, third, AND fourth harmonics - and nearly the fifth! The only reason we need to sample at a rate of 40 kHz in the first place is that transient sounds like cymbals, buzzes, hisses, and clicks often include higher harmonics in the 15 - 20 kHz range and if you don't capture those then you lose some of the character of the music. By sampling at a rate over 40 kHz we accurately capture those signals and preserve the original recording in such a way that humans can fully enjoy it.
By having higher sampling rates, we can have have our low pass filters on the adc input have a more gradual effect, starting at a cutoff that is far above the range of human hearing. For example, at 196 kHz, our Nyquist frequency is 98 kHz. We could use a low pass filter with a cutoff of 40 kHz, which would roll off nicely before 98 kHz and would hardly affect any spectral content in the human hearing range.
192 kHz is still massive overkill. Nearly all humans can't hear above 20 kHz (in fact most can't hear over 16 kHz) and a 10% or 20% roll-off is pretty much just fine to cover most low pass filters. You can comfortably low-pass at 20 kHz and sample at 48 kHz (a DAT standard rate) and not notice any difference between the original signal and the sampled and reconstructed signal.
I was under the impression that it was 44.1khz because of the video hardware they hacked together to see what they were doing while developing CDs?
Yes, 44.1 kHz was a multiple of the scan rate and the active lines in a field:
Explanation of 44.1 kHz CD sampling rate
It also serves as some overhead for the Nyquist-Shannon sampling. There is no such thing as an ideal low-pass filter so you'll get some leakage of frequencies over 20k, plus the theorem states that you need infinite past and future data to 100% recover the waveform. Going to 44.1 kHz and getting 10% overhead is a good rule of thumb, although going to 48 kHz and getting 20% can't hurt.
If you're recording audio, you should probably sample at 96khz so that when you pass it through a plugin that does something temporally with the audio, there's less artifacts.
Yeah, if you're doing a lot of post-processing then going for an even higher sampling rate can help a bit but it's really diminishing returns. 96 kHz is definitely overkill and 192 kHz is just idiotic.
For playback, you don't need 96khz, unless you have thousand-dollar speakers. (I tried some out, the difference exists).
Some thousand-dollar speakers are worth the cost although there is a lot of snake oil at that price point. Caveat emptor on pricy acoustic gear! However, 96 kHz will sound almost exactly the same as 44.1 kHz no matter how expensive the speakers.
On the other hand, a bad audio player will have poorly designed digital to analog converters which won't interpolate the digital signal in such a way as to reconstruct the original signal faithfully. In that case a 44.1 kHz signal can sound worse than a 96 kHz signal because of zero-order hold, aliasing, and other factors.
This doesn't mean that expensive equipment is automatically better, just that a lot of times you get what you pay for on the extreme low-end. Most mid-range equipment does a decent job reproducing the original signal.
Pardon my ignorance, but what is the point of a 192KHz sampling rate? The maximum frequency you can push through that is 96Khz, which is way above human hearing. In fact, the human hearing range is between 20Hz and 20KHz, so even 44KHz sampling rate should be more than enough. Or am I missing something important?
A lot of people don't really understand how to apply the Nyquist-Shannon sampling theorem and so they look at the "jaggy" sampled waveform and think that it will sound horrible if it is output. It's true that if you output the samples directly then you are going to hear artifacts but if you apply the Whittaker-Shannon interpolation formula then you get back the original waveforms and the output will sound nearly identical to the original.
Of course this is all best-case and since we live in the real world with imperfect low-pass filters and non-infinite past and future data we will still get artifacts if we sample at the minimum rate. That's (part of) the reason why we sample at 44.1 kHz instead of 40 kHz, to allow some overhead to account for these non-ideal factors. You absolutely do NOT need to sample at 192 kHz, if you do you are just wasting storage space on your digital media. I believe the default for a DAT is 48 kHz and that's pretty much the maximum you should ever use.
That is, unless you are doing recordings for bats and dogs to listen to...
The main difference between Mac OS and iOS is you can't code on iOS. It's partly a security feature and partly an anti-complexity feature. iOS is for a non-coding approach to all tasks. You may not know this, but a Photoshop pro writes a ton of code. The home user working with their photos doesn't need to.
Huh? This makes no sense at all. Yes, Apple toyed with the idea of having no interpreted code in iOS 4 but they relaxed that restriction before it even came out of beta. You can now use interpreted code, such as LUA, in your apps.
There is absolutely no restriction in the iOS API itself that doesn't let you "code on iOS", it was a prohibition against your app being sold in the App Store and it was designed to stop people from subverting Apple's API by writing their program in another language with a thin translation layer on top. If Apple went ahead with the original restriction it would have been very heavy-handed, the current rules are much more reasonable.
Another feature of iOS is no custom drivers. The USB audio interfaces that work with iOS are the "class compliant" ones that work with the system's universal driver.
iOS can certainly have custom drivers if they needed it, its core is still Darwin. The thing is that right now iOS is only used on closed systems like the iPhone and the iPad. There's not much need to have a custom driver for a device that really can't have additional hardware installed on it. As such, Apple doesn't provide a way to install any custom drivers but you can certainly jailbreak your device and add custom drivers galore if you want to.
I can't imagine how a calendar developed for a 2" touchscreen could have the same interface as a calendar developed for a 21" keyboard-and-mouse, and not have it be terrible. Similarly, a copy of Word on the iPhone and a copy of Word on a PC would necessarily need to have very different interfaces... You can't get hover tips on a touchscreen, people don't gesture with keyboards, mice aren't multitouch, and iPhone screens are tiny.
Which is exactly why Apple based all of its APIs, both iOS and Mac OS, around the Model-View-Controller (MVC) design pattern. This way you can have your view logic separate from your model and controller logic and you can customize your view based on the device it is presented upon. It allows you to easily re-use your code between different devices and you can develop views specifically optimized to be shown on a certain type of device.
Since both iOS and Mac OS are Cocoa they share almost all of the same API with a couple of differences mostly related to the user interface. It's trivial to have a project with a target for iOS and a target for Mac OS that share the same model and controller code but that have different view code optimized for the target device.