This is a comparative analysis from a personal viewpoint and experience about different programming environments based upon CPU architectures and Operating Systems.
This will not cover CPU michroarcitectures nor OS release numbers and/ or names for the most part.
Versions of software will not be covered for the most part.
And I will be honest about what I have not used.
I do not use my knowledge for unethical activities. Keep this in mind.
I do not and will not assume nor presume that you know as much as me. For whatever is posted here, I encourage and ask you to research everything in this most posty post of posts.
I will not tell you, "RTFM" (Read the fine/ f*ng* manual) because you may not know for what to search. Doing, saying, inferring, assuming, or presuming such about others is rude, disrespectful, insulting, and arrogant. No one in their right mind will beat an infant for crying; and, you are not the other person; so, why are you, do you, and will you treat others in such a certain manner when you do not want want it yourself?
Morality, ethics, compassion, and understanding are important in all areas of Life within creation.
With that hopefully being understood, let us all together venture upon this quest for some weeby and goodly knowledge.
Let's start, shall we.
A. Environmental Variables.
.1. File system hierarchy.
The more ordered the file system the more of ease it is for you or the program to find what you need.
2. Read, write, and execute permissions.
If one is limited in these areas, it is more difficult to install or anable program features from the binary suite or the source code from which it was compiled.
B. CPU architecture.
Microarchitectures will not be covered for reason that registry values and cache properties play a different role according to the type of compiler. Bus speed and CPU hertz frequency do play an important part; yet, I will not dwell upon these.
1. CISC architecture.
I have only worked with two types, that is X86 and AMD64 - also known as X86_64.
Instructions are usually sent as a type of binomial or linearly link set of commands. Open registers may have to wait for other instructions to finish to be able to uitilize a free register. This is one reason why the developers and manufacturers of such design faster CPU hertz rates and smaller transistors - and other micro/ nano electronics - at such scales.
They will still bottleneck if the load is too great. The OS type and version will not matter.
2. RISC architecture.
Depending upon the workload and system resources, each of the following will be described independent of OS release and flavor.
a. ARM architectures.
1. ARM32 or aarch32.
I have only worked with the installation of a modified environment. The system will process according to the available instructions. There has been less experience for myself as to the load-store type and register values and accepting on this architecture.
2. ARM64 or aarch64.
This is the current active programming environment. Details will be covered in the OS/ operating system section.
3. PowerPC 32bit.
According to the CPU hertz speed, the load-store processing, and registry values, this architecture is able to "learn" or "memorize" values with less latency and quicker processing time. At a rate of 500MHz, a G3 processor is able to be used to compile four to five simultaneous and independent binaries or suites. Functions of the OS take precedence and priority according to what is necessarily demanded.
4. SPARC64 or UltraSPARC.
Compilation of binaries and suites usually are not as quickly processed as those of the PowerPC32 architecture based machines; yet, the CPU is able to scale and simultaneously process more compilations and builds with less affect on the OS itself.
C. Operating System or OS.
Knowing your operating system environment is what I perceive as a requirement.
1. File system hierarchy.
If the system is not built with a structured and ordered environment, the install paths and install locations of the binaries, libraries, and other required parts may be duplicated. Finding the right path to such may require a more in-depth knowledge.
2. Directory and file permissions.
Free and/ or OPen Source systems will usually allow you the right to gain access and modify these values much quicker - but not easier at times - than those of propriety/ closed source systems.
3. Path values.
As mentioned in section C1 of this post, the hierarchy layout affects the known paths.
4. OS / Operating System types.
a. Proprietary
1. Atari.
I am only including this because I first did programming on the Atari 800.
It used a sixteen kilobyte cartridge, had split screen so that one could see the code being processed. I did simple graphics, sound, string variables, and question-answer type of programming on it.
2. Windows.
Both 32bit and 64bit environments.
CISC architecture only.
B. Open Source.
1. Linux.
Kernel version and userland environment will not be covered
The same applies to distribution release.
a. Debian.
X86, AMD64, PowerPC32.
b. Fedora
X86, AMD64.
c. Ubuntu.
X86, AMD64, PowerPC32.
I have only done programming and compilation on these distributions.
My preference is for Debian for reason that the system is very versatile and adaptable.
2. BSD UNIX derivatives.
a. OpenBSD.
X86, AMD64, PowerPC32, UltraSPARC.
Do your research first.
Go to http://daemonforums.org/
and join it to ask questions about OpenBSD.
I am forewarning you about some of the community members. Do not ask anything before reading the manual, searching through mailing lists, or asking on public forums.
Be very careful about asking any question on the mailing lists. Just trust me on this one.
b. FreeBSD.
X86, AMD64, PowerPC32, UltraSPARC.
This is my preferred programming environment. In my experience, one has more control over what is needed for compiling, building, and developing.
After understanding and compiling software, you are also encouraged to make a port of the software or to work on a current port.
Now, how much more cooler, dope, and weeby could it be then that?
D. Build environment requirements and values.
1. Open and closed source differences.
If the build environment is open source, you are able to affect configure and other variables because of read write and execute permissions within the directory and source code itself. Closed source environments are limited according to what those developers of such desire to allow the public to have.
This applies to most within section D - and others parts if applicable - of this post.
If the compiling,building, and installing binaries and access points are developed for an open source system, you have more control over the processes.
2. Individual configure, make, and other values.
If there is a section listed as "README", "Readme", "readthis" or similar within the directory, do such with whatever text editor or similar reading application of such that you desire to use. These files may inform you of certain values that you may be able to change.
a. Configure options.
I suggest using Scite or a similar editor to search for and possibly change or add basic environmental variables. Basic variables may be added with -- or - for control of the ./configure command.
b. Make options.
If not described within the ./configure environments, us the same or a similar method as the Scite one described above to affect and change these values.
The most commonly known - by the general public, platforms would be Windows, MacOSX, Android, and IOS.
I have never used MacOSX nor IOS for any type of programming environment.
On Windows, I have used CygWin, an odd programming suit named Lynx - not the browser. I have also used a program that would strip the GIF/ PNG protection layer from the Windows kernel.
This environment is not conducive for those who desire more exact control over the environmental variables.
I started this post at my friend's place.
I am making it short because I am now outside and the mosquitoes are hungry.
Itchy itchy skin, peoples.
Why did I not include Android?
I am learning that one must root the OS and build many of the required software for the compilers and make/ build environments.
I firmly believe in "bare metal" and "native environment" for software and hardware development.
You, however, are free to choose the use of cross-compiling and virtual machines.
There is no single standard, method, or way of learning programming. Each individual has her or his own way of processing information. Try to do that which is best for you; and, find a way of encouraging others.
May you have a goodly and blessed day.
Tchau, tchau.
No comments:
Post a Comment
Thank you for expressing yourself. Have a blessed day.