Sí, ya sé, un ‘Blogroll’ es una collección de enlaces a otros ‘Weblogs’
De momento, sin embargo, en este ‘Blog’ se utiliza indistintamente tanto para indicar los enlaces a otros ‘Blogs’ como para indicar los enlaces que estime pertinentes.
Dicho queda.
¡Qué gustazo da hacer las cosas mal! :-))
Como decía en mi anterior entrada, últimamente, he estado leyendo bastante documentación sobre el OS X proporcionada por Apple. Alguna me ha interesado especialmente. Así que, para no olvidarla, la incluiré aquí (una pura copia más… disculpas).
Execution Contexts
“If you’re familiar with traditional BSD programming, you will be familiar with the user IDs (UIDs) associated with a process (commonly referred to as the process’s owner). On a traditional BSD system, these UIDs control the capabilities of that process. You can, more or less, assume that two processes with matching UIDs have the same capabilities.
This is not true on Mac OS X. There are other elements of the process’s context that significantly alter its capabilities. So, for example, a daemon whose UIDs are set to that of the logged in console user is not equivalent to an application that has been launched by that user.
The following sections describe the elements of process’s context, and how they affect background programs.
UIDs
A process’s UIDs (its effective (EUID), real (RUID), and save (SUID) UIDs) are the most well known elements of the process’s context. These UIDs control various capabilities of the process, mostly centered on the BSD portions of the system (file system, networking, BSD process control). For example, a process’s ability to open a file is controlled by its EUID, and its ability to signal another process is controlled by its EUID and the EUID and RUID of the target.”
Más Información (Info de Apple salvo que se indique lo contrario)
security-overview-permissions-uids-acls.pdf
Últimamente, he estado leyendo bastante documentación sobre el OS X proporcionada por Apple. Alguna me ha interesado especialmente. Así que, para no olvidarla, la incluiré aquí.
Locations for Public Frameworks (infra: secciones literalmente copiadas)
“Third-party frameworks can go in a number of different file-system locations, depending on certain factors.
• Most public frameworks should be installed at the local level in /Library/Frameworks.
• If your framework should only be used by a single user, you can install it in the ~/Library/Frameworks subdirectory of the current user; however, this option should be avoided if possible.
• If they are to be used across a local area network, they can be installed in /Network/Library/Frameworks; however, this option should be avoided if possible.
For nearly all cases, installing your frameworks in /Library/Frameworks is the best choice. Frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime. Applications that link to frameworks in other directories, such as ~/Library/Frameworks or /Network/Library/Frameworks, must specify the exact path to the framework at build time so that the dynamic linker can find it. If the path changes (as it might for a user home directory), the dynamic linker may be unable to find the framework.
Another reason to avoid installing frameworks in ~/Library/Frameworks or /Network/Library/Frameworks is the potential performance penalties. Frameworks installed in network directories or in network-based user home directories can cause significant delays in compilation times. Loading the framework across the network can also slow down the launch of the target application.
Third-party frameworks should never be installed in the /System/Library/Frameworks directory. Access to this directory is restricted and is reserved for Apple-provided frameworks only.
When you build an application or other executable, the compiler looks for frameworks in/System/Library/Frameworks as well as any other location specified to the compiler. The compiler writes path information for any required frameworks in the executable file itself, along with version information for each framework. When the application is run, the dynamic link editor tries to find a suitable version of each framework using the paths in the executable file. If it cannot find a suitable framework in the specified location (perhaps because it was moved or deleted), it looks for frameworks in the following locations, in this order:
1. The explicit path to the framework that was specified at link time.
2. The /Library/Frameworks directory.
3. The /System/Library/Frameworks directory.
If the dynamic link editor cannot locate a required framework, it generates a link edit error, which terminates the application.
—-
(edit: lo que pasa no pocas veces… ¡¡Ojo!! Diferentes versiones del OS X y sus consecuentes diferencias…)
(edit: test: via CLI: ‘otool -L foo.*…’; et. al.; with Developer Tools; and so on… Yes!!, ‘otool’ it’s a great command…; ‘dump-class’ it’s ok…; an others; et. al. also…). Well, I will try to say something more when I have spare time to… But, remember, I’m a non-coder :(
Oh, well, I have done my own tests… But… Who am I to educate…? No one!!
So, alas, that’s “just” (I)MNCO (in my non-coder opinion).
I will try to tell you something more when I have spare time. But, don’t hold your breath!! In this case, RSN means… What usually means in sw language :)
And, besides, I don’t want to seem a coder, because I’m not. I’m just a person who likes to know… So, if I’m wrong, sorry in advance…
