Uh, no. OS X provides a rich set of libraries as part of the base OS. Apple goes to great lengths to ensure compatibility between OS versions (libSystem is compatible to version 1). The only time any software includes a library inside their app bundle is if they wrote it or it is an OSS library that isn't in the base OS. Most apps don't need to.
That's why we have virtual address spaces. Each process gets a 4GB address space for a 32-bit OS. Only 2-3.5GB (depending on OS) will be available for actual program code (not shared libraries) and data. Of course, those virtual addresses get translated to physical addresses by the OS on a per-page (or at least per-range) basis, so all 4GB of physical RAM can be used assuming there is more than one process running.
That's all a simplification of how modern VM subsystems work, of course.
As to memory "stolen" by hardware, the big one there is video cards. A fair number of OSes still map the entire video memory into the physical memory address map. You might think this would be a problem, but on the x86 architecture at least, physical addresses have been 36 bits for a while. Even with a few video card with 1GB of video ram each, there is still enough space to address all 4GB of physical RAM.
Which, along with the inability for a single piece of even specialized networking gear to handle the bandwidth for an entire country, is why it isn't done that way. Firewalls can easily be sharded, load balanced, and put into failover configurations.
A controlling interest in Google is owned by the CEO and two founders. Their IPO stated that this would be the case and that public investors would be able to share in the financial gains, but not significantly in the direction or operation of the company. If those three have decided that China isn't worth it, there is little the investors can do to stop them.
Having spent 4 years being one of the primary developers of Apple's main performance analysis tools (CHUD, not Instruments) and having helped developers from nearly every field imaginable tune their applications for performance, I can honestly say that regardless of your performance criteria, you shouldn't be doing anything special for optimization when you first write a program. Some thought should be given to the architecture and overall data flow of the program and how that design might have some high-level performance limits, but certainly no code should be written using explicit vector operations and all loops should be written for clarity. Scalability by partitioning the work is one of those items that can generally be incorporated into the program's architecture if the program lends itself to it, but most other performance-related changes depend on specific usage cases. Trying to guess those while writing the application logic relies solely on intuition which is usually wrong.
After you've written and debugged the application, profiling and tracing is the prime way for finding _where_ to do optimization. Your experiences have been tainted by the poor quality of tools known by the larger OSS community, but many good tools are free (as in beer) for many OSes (Shark for OS X as an example) while others cost a bit (VTune for Linux or Windows). Even large, complex multi-threaded programs can be profiled and tuned with decent profilers. I know for a fact that Shark is used to tune large applications such as Photoshop, Final Cut Pro, Mathematica, and basically every application, daemon, and framework included in OS X.
What do you do if there really isn't much of a hotspot? Quake 3 was an example where the time was spread out over many C++ methods so no one hotspot really showed up. Using features available in the better profiling tools, the collected samples could be attributed up the stack to the actual algorithms instead of things like simple accessors. Once you do that, the problems become much more obvious.
What do you do after the application has been written and a major performance problem is found that would require an architectural change? Well, you change the architecture. The reason for not doing it during the initial design is that predicting performance issues is near impossible even for those of us who have spent years doing it as a full time job. Sure, you have to throw away some code or revisit the design to fix the performance issues, but that's a normal part of software design. You try an approach, find out why it won't work, and use that knowledge to come up with a new approach.
That largest failing I see from my experiences have been the lack of understanding by management and engineers that performance is a very iterative part of software design and that it happens late in the game. Frequently, schedules get set without consideration for the amount of time required to do performance analysis, let alone optimization. Then you have all the engineers who either try to optimize everything they encounter and end up wasting lots of time, or they do the initial implementation and never do any profiling.
Ultimately, if you try to build performance into a design very early, you end up with a big, messy, unmaintainable code base that isn't actually all that fast. If you build the design cleanly and then optimize the sections that actually need it, you have a most maintainable code base that meets the requirements. Be the latter.
I worked closely with the kernel and firmware engineers at Apple for the last 4 years. They have never intentionally disabled any hacks, unlocks, or unofficially supported hardware. The changes that cause them to stop working were done solely to fix other bugs or to enable new features. It's not vindictive. I know, I helped make some of those decisions.
No, I was referring to a number of employees being forced out or let go in the past year. In fact, many of the ASIC engineers laid off after the Intel switch were hired back less than a year later to work on the iPhone SoC designs.
Prove that they intentionally blocked it. You are assuming that since the new version no longer boots on it, they intentionally blocked it. The more likely case is that they simply removed the support for it.
Consider that code support for a processor is non-trivial. While they may have added support for the Atom at some point, there is a cost to keeping that support functional. When working on other features in the kernel, it may very well be easier to remove the support for a processor that isn't officially supported than to keep it working. This is especially true for OS X which frequently changes their power management scheme for Intel processors.
Speaking as a former Apple employee: so _that's_ why a bunch of senior engineers in the hardware devision were let go or put in such a horrible situation that they left. Apple isn't being that great to their engineers and is focusing more on how hard they can drive them to produce new products every 6 months.
Actually, all labels are restricted to the characters allowed for ARPANET hosts. The spec does state that implementations should store labels as a length octect followed by a sequence of octets, thus implying that any compliant software _should_ handle UTF8, but no one wants to take that chance.
Except when the defaults of a release candidate have a bunch of debug options turned on that aren't normally enabled for actual releases. This wasn't testing the 'Default Settings', it was testing the debugging settings.
... I've heard a 486 serving static pages can manage to fill a T1 line.
It isn't _that_ hard to saturate 1.544Mbps. Most cable/DSL downlink speeds are faster than that. Now, a T3 is a bit more challenging, but nothing a single decent machine can't handle.
And how does your system compare spec-wise to a fully decked out mac pro? It doesn't. A top of the line mac pro would include (2) Nehalem processors (8 cores total), 32GB of RAM, 4TB of disk.... Your system doesn't even come close.
In terms of the $4k mac pro, it still outspecs what you've listed. If you are going to do comparisons, at least use comparable parts.
Actually, it's fairly common to have international interference that prevents communication on the lower bands (160m/80m). So, yes, interference generated in China _can_ cause hams in the US to not be able to use that frequency range.
Yes, as a programmer, you can decide what comes into the cache. If not from C, you can certainly do so from assembly. Many architectures even include cache manipulation instructions so the program can better control cache reuse if it has sufficient external knowledge about the program's behavior.
Yes because a compiled, statically-typed, procedural language (C) has everything in common with an interpreted, dynamically-typed, object-oriented language.
Actually, I do have the schematics to my TV, microwave, washer, dryer, and car. I purchased these things called "service manuals." Sadly, they don't include the source code to the firmware.
Interface Builder lets you choose to specify offsets from either side for both axes (top/bottom for Y and left/right for X). Further it lets you defined resize behaviors. The only apps that will be bitten by a change in screen dimensions are those from developers who didn't bother to learn what those controls do and assumed that the screen size will just never change.
Cars and buses with LED tail lights are not running them at 60Hz. Nor are they being pulsed at any rate. The electrical system in a car is 12V DC. The LED assembly is either designed with enough LEDs in series such that the forward voltage drop over the set is 12V (roughly 10 LEDs) or they are in parallel with a buck-style switching power supply in front of it.
Now, before you go on about how the switching power supply causes flicker, you should research how they work. You will find that for cost and size reasons, it is better to run a buck topology as fast as possible. 250kHz, 500kHz, and 1MHz are common frequencies. Of course, the output from the switching portion is put through a LC filter such that the voltage ripple is reduced to a small percentage of the target output voltage. Besides, LED brightness is controlled by current. Even a 5% voltage ripple on a 2V output would trigger a few lumens of brightness difference.
So, if you are seeing flicker in car and bus tail lights, then you can see a 250kHz "flicker" with an average brightness delta of a few lumens. If you can, I'm sure there are plenty of researchers who would love to talk to you as you are the only person on the planet who can.
Of course, since cost is the driving factor in these types of devices, they probably aren't using the switcher at all and thus there is _no_ flicker due to electrical reasons. You are probably being more affected by the directionality of the LEDs and the lenses used being vibrated by the engine at idle speeds. You get the same effect watching a motorcycle headlamp on a rough road. The light isn't flickering, it is just vibrating enough that the beam is falling in and out of your eye.
That's an interesting interpretation of the law or morality but I don't think you'll find that it matches the real world even a little bit.
Forget to feed your baby and he cries a lot and shrugs it off: no consequences.
Forget to feed your baby and he dies: you go to prison for a very long time.
Go 25MPH over the speed limit and get caught by a cop: expensive speeding ticket.
Go 25MPH over the speed limit and kill a van full of girl scouts: you go to prison for a very long time.
The differentiating factor there is one of enforcement. In all four cases, a law has been violated. If said baby were to cry a lot and cause the neighbors to complain, the police would investigate and still find you neglegent.
Plan to kill somebody and screw it up: go to prison for a little while.
Plan to kill somebody and succeed: get the chair.
Here you've outlined two separate infractions. In the first case, conspiracy to commit murder and attempted murder apply. In the second, conspiracy and murder both apply. The actual act committed changed, not the outcome.
It has been Apple who released a revolutionary computer that is completely locked down.
Last I checked the iPhone is a cell phone, not a computer. The former is a tightly integrated system where the OS is coupled to the hardware. Running 3rd party applications on said cell phone does not make it a computer.
It took Android and the jailbreak community to force their hand, make them admit that a web browser was not an SDK.
Actually, having talked with the project leads for iPhone team, the SDK was always in the plan. It came after the OS simply because you really need to make an OS and then clean it up for others to use. Anyone who thinks they can write a public API from scratch and release it without any vetting period hasn't actually written a public API.
And still, over a year after they announced it would be a real platform, the iPhone is as bad as any console - you need Apple's favor to run on the device, you have to sell your work through their channel, and they can cut you off on a whim.
Did you see the support for ad-hoc distribution? Apparently not since it is a distribution method _supported_ by Apple that allows a developer to distribute an application directly to users without involving Apple, the AppStore, etc.
And the crapware that all the apologists said this was supposed to prevent still makes up the majority of the App Store. It has nothing to do with quality and everything to do with control.
While many of the apps available via the AppStore aren't anything I'll personally use and some may not be the best designs, they are not malicious and don't torture the cell phone network. Of course, I'm certain that that would have been the case if Apple hadn't enforced a review process.....
Slashdot Mirror
Uh, no. OS X provides a rich set of libraries as part of the base OS. Apple goes to great lengths to ensure compatibility between OS versions (libSystem is compatible to version 1). The only time any software includes a library inside their app bundle is if they wrote it or it is an OSS library that isn't in the base OS. Most apps don't need to.
Which only covers the filesystem layout and basic services. It says nothing about APIs or versions of libraries.
That's why we have virtual address spaces. Each process gets a 4GB address space for a 32-bit OS. Only 2-3.5GB (depending on OS) will be available for actual program code (not shared libraries) and data. Of course, those virtual addresses get translated to physical addresses by the OS on a per-page (or at least per-range) basis, so all 4GB of physical RAM can be used assuming there is more than one process running.
That's all a simplification of how modern VM subsystems work, of course.
As to memory "stolen" by hardware, the big one there is video cards. A fair number of OSes still map the entire video memory into the physical memory address map. You might think this would be a problem, but on the x86 architecture at least, physical addresses have been 36 bits for a while. Even with a few video card with 1GB of video ram each, there is still enough space to address all 4GB of physical RAM.
Which, along with the inability for a single piece of even specialized networking gear to handle the bandwidth for an entire country, is why it isn't done that way. Firewalls can easily be sharded, load balanced, and put into failover configurations.
A controlling interest in Google is owned by the CEO and two founders. Their IPO stated that this would be the case and that public investors would be able to share in the financial gains, but not significantly in the direction or operation of the company. If those three have decided that China isn't worth it, there is little the investors can do to stop them.
Having spent 4 years being one of the primary developers of Apple's main performance analysis tools (CHUD, not Instruments) and having helped developers from nearly every field imaginable tune their applications for performance, I can honestly say that regardless of your performance criteria, you shouldn't be doing anything special for optimization when you first write a program. Some thought should be given to the architecture and overall data flow of the program and how that design might have some high-level performance limits, but certainly no code should be written using explicit vector operations and all loops should be written for clarity. Scalability by partitioning the work is one of those items that can generally be incorporated into the program's architecture if the program lends itself to it, but most other performance-related changes depend on specific usage cases. Trying to guess those while writing the application logic relies solely on intuition which is usually wrong.
After you've written and debugged the application, profiling and tracing is the prime way for finding _where_ to do optimization. Your experiences have been tainted by the poor quality of tools known by the larger OSS community, but many good tools are free (as in beer) for many OSes (Shark for OS X as an example) while others cost a bit (VTune for Linux or Windows). Even large, complex multi-threaded programs can be profiled and tuned with decent profilers. I know for a fact that Shark is used to tune large applications such as Photoshop, Final Cut Pro, Mathematica, and basically every application, daemon, and framework included in OS X.
What do you do if there really isn't much of a hotspot? Quake 3 was an example where the time was spread out over many C++ methods so no one hotspot really showed up. Using features available in the better profiling tools, the collected samples could be attributed up the stack to the actual algorithms instead of things like simple accessors. Once you do that, the problems become much more obvious.
What do you do after the application has been written and a major performance problem is found that would require an architectural change? Well, you change the architecture. The reason for not doing it during the initial design is that predicting performance issues is near impossible even for those of us who have spent years doing it as a full time job. Sure, you have to throw away some code or revisit the design to fix the performance issues, but that's a normal part of software design. You try an approach, find out why it won't work, and use that knowledge to come up with a new approach.
That largest failing I see from my experiences have been the lack of understanding by management and engineers that performance is a very iterative part of software design and that it happens late in the game. Frequently, schedules get set without consideration for the amount of time required to do performance analysis, let alone optimization. Then you have all the engineers who either try to optimize everything they encounter and end up wasting lots of time, or they do the initial implementation and never do any profiling.
Ultimately, if you try to build performance into a design very early, you end up with a big, messy, unmaintainable code base that isn't actually all that fast. If you build the design cleanly and then optimize the sections that actually need it, you have a most maintainable code base that meets the requirements. Be the latter.
I worked closely with the kernel and firmware engineers at Apple for the last 4 years. They have never intentionally disabled any hacks, unlocks, or unofficially supported hardware. The changes that cause them to stop working were done solely to fix other bugs or to enable new features. It's not vindictive. I know, I helped make some of those decisions.
No, I was referring to a number of employees being forced out or let go in the past year. In fact, many of the ASIC engineers laid off after the Intel switch were hired back less than a year later to work on the iPhone SoC designs.
Prove that they intentionally blocked it. You are assuming that since the new version no longer boots on it, they intentionally blocked it. The more likely case is that they simply removed the support for it.
Consider that code support for a processor is non-trivial. While they may have added support for the Atom at some point, there is a cost to keeping that support functional. When working on other features in the kernel, it may very well be easier to remove the support for a processor that isn't officially supported than to keep it working. This is especially true for OS X which frequently changes their power management scheme for Intel processors.
Speaking as a former Apple employee: so _that's_ why a bunch of senior engineers in the hardware devision were let go or put in such a horrible situation that they left. Apple isn't being that great to their engineers and is focusing more on how hard they can drive them to produce new products every 6 months.
Actually, all labels are restricted to the characters allowed for ARPANET hosts. The spec does state that implementations should store labels as a length octect followed by a sequence of octets, thus implying that any compliant software _should_ handle UTF8, but no one wants to take that chance.
Except when the defaults of a release candidate have a bunch of debug options turned on that aren't normally enabled for actual releases. This wasn't testing the 'Default Settings', it was testing the debugging settings.
... I've heard a 486 serving static pages can manage to fill a T1 line.
It isn't _that_ hard to saturate 1.544Mbps. Most cable/DSL downlink speeds are faster than that. Now, a T3 is a bit more challenging, but nothing a single decent machine can't handle.
And how does your system compare spec-wise to a fully decked out mac pro? It doesn't. A top of the line mac pro would include (2) Nehalem processors (8 cores total), 32GB of RAM, 4TB of disk.... Your system doesn't even come close.
In terms of the $4k mac pro, it still outspecs what you've listed. If you are going to do comparisons, at least use comparable parts.
Actually, it's fairly common to have international interference that prevents communication on the lower bands (160m/80m). So, yes, interference generated in China _can_ cause hams in the US to not be able to use that frequency range.
Not to mention NT came out before 95.
Yes, as a programmer, you can decide what comes into the cache. If not from C, you can certainly do so from assembly. Many architectures even include cache manipulation instructions so the program can better control cache reuse if it has sufficient external knowledge about the program's behavior.
Yes because a compiled, statically-typed, procedural language (C) has everything in common with an interpreted, dynamically-typed, object-oriented language.
Actually, I do have the schematics to my TV, microwave, washer, dryer, and car. I purchased these things called "service manuals." Sadly, they don't include the source code to the firmware.
Interface Builder lets you choose to specify offsets from either side for both axes (top/bottom for Y and left/right for X). Further it lets you defined resize behaviors. The only apps that will be bitten by a change in screen dimensions are those from developers who didn't bother to learn what those controls do and assumed that the screen size will just never change.
Cars and buses with LED tail lights are not running them at 60Hz. Nor are they being pulsed at any rate. The electrical system in a car is 12V DC. The LED assembly is either designed with enough LEDs in series such that the forward voltage drop over the set is 12V (roughly 10 LEDs) or they are in parallel with a buck-style switching power supply in front of it.
Now, before you go on about how the switching power supply causes flicker, you should research how they work. You will find that for cost and size reasons, it is better to run a buck topology as fast as possible. 250kHz, 500kHz, and 1MHz are common frequencies. Of course, the output from the switching portion is put through a LC filter such that the voltage ripple is reduced to a small percentage of the target output voltage. Besides, LED brightness is controlled by current. Even a 5% voltage ripple on a 2V output would trigger a few lumens of brightness difference.
So, if you are seeing flicker in car and bus tail lights, then you can see a 250kHz "flicker" with an average brightness delta of a few lumens. If you can, I'm sure there are plenty of researchers who would love to talk to you as you are the only person on the planet who can.
Of course, since cost is the driving factor in these types of devices, they probably aren't using the switcher at all and thus there is _no_ flicker due to electrical reasons. You are probably being more affected by the directionality of the LEDs and the lenses used being vibrated by the engine at idle speeds. You get the same effect watching a motorcycle headlamp on a rough road. The light isn't flickering, it is just vibrating enough that the beam is falling in and out of your eye.
That's an interesting interpretation of the law or morality but I don't think you'll find that it matches the real world even a little bit.
Forget to feed your baby and he cries a lot and shrugs it off: no consequences.
Forget to feed your baby and he dies: you go to prison for a very long time.
Go 25MPH over the speed limit and get caught by a cop: expensive speeding ticket.
Go 25MPH over the speed limit and kill a van full of girl scouts: you go to prison for a very long time.
The differentiating factor there is one of enforcement. In all four cases, a law has been violated. If said baby were to cry a lot and cause the neighbors to complain, the police would investigate and still find you neglegent.
Plan to kill somebody and screw it up: go to prison for a little while.
Plan to kill somebody and succeed: get the chair.
Here you've outlined two separate infractions. In the first case, conspiracy to commit murder and attempted murder apply. In the second, conspiracy and murder both apply. The actual act committed changed, not the outcome.
It has been Apple who released a revolutionary computer that is completely locked down.
Last I checked the iPhone is a cell phone, not a computer. The former is a tightly integrated system where the OS is coupled to the hardware. Running 3rd party applications on said cell phone does not make it a computer.
It took Android and the jailbreak community to force their hand, make them admit that a web browser was not an SDK.
Actually, having talked with the project leads for iPhone team, the SDK was always in the plan. It came after the OS simply because you really need to make an OS and then clean it up for others to use. Anyone who thinks they can write a public API from scratch and release it without any vetting period hasn't actually written a public API.
And still, over a year after they announced it would be a real platform, the iPhone is as bad as any console - you need Apple's favor to run on the device, you have to sell your work through their channel, and they can cut you off on a whim.
Did you see the support for ad-hoc distribution? Apparently not since it is a distribution method _supported_ by Apple that allows a developer to distribute an application directly to users without involving Apple, the AppStore, etc.
And the crapware that all the apologists said this was supposed to prevent still makes up the majority of the App Store. It has nothing to do with quality and everything to do with control.
While many of the apps available via the AppStore aren't anything I'll personally use and some may not be the best designs, they are not malicious and don't torture the cell phone network. Of course, I'm certain that that would have been the case if Apple hadn't enforced a review process.....
That's true of OS X on Macs as well. Any application will link against libSystem.dylib which isn't licensed under the GPL.