|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
LAMP is an acronym for a solution stack of free, open source software, referring to the first letters of Linux (operating system), Apache HTTP Server, MySQL (database software) and PHP (or sometimes Perl or Python), principal components to build a viable general purpose web server.
In other words it is software development and run time environment which consist of the the OS, webserver, scripting language and database. Those four more or less standard software components created a real revolution in application software development.
It arrived on the software development scene in 1996 or so, so this is almost 20 years old technology. Almost as old as Linux.
But despite its age it is still a revolutionarily idea much like was Unix in 70th that created the whole new class of applications, a new development methodology and a new component architecture. In a way the represented the novel idea: operating system should be viewed as an integral part of application, the view which became especially interesting with the proliferation of virtual machines, and, especially, virtual appliances. I would say that virtual appliance represents an ultimate LAMP environment, as virual machine provide the necessary packaging for all components used.
Though the original authors of these programs did not design them all to work specifically with each other, the development philosophy and tool sets are shared and were developed with the awareness of other components existence. This approach to software combination has become popular because it is highly productive, free, open-source (and therefore adaptable in case of need), and because all the components are provided as packages and can be installed by default in most current Linux distributions, as well as Solaris, AIX or HP-UX. Which make installation a breeze, a task that can be accomplished in a couple of minutes.
When used together, components of LAMP forms a innovative, powerful and flexible web application development environment. It is important to understand that in case of LAMP whole is more then parts. So while each component in itself is not that important (and some, like PHP is of questionable quality as a programming language) their synergy creates a new, extremely powerful and flexible software development platform. In other word it represent new software development paradigm that is different from traditional software development approaches and explicitly contradicts ideas of object oriented programming. The leading scripting language used (PGP) did not have OO features until recently. The essence of this paradigm can be expressed as "Unix OS should serve both as the software development enjoinment and run time environment" and, in more recent form, "application is just a packages software appliance that includes OS and runs on virtual machine".
| It is important to understand that in case of LAMP whole is more then parts. So while each component in itself is not that important (and some, like PHP is of questionable quality as a programming language) their synergy creates a new, extremely powerful and flexible software development platform |
LAMP uses parts of Unix environment such a shell, scheduler, syslog daemon, cron daemon, etc as part of software platform. Application became merged with OS. And that is a very novel idea.
The power of this paradigm is well illustrated by its commercial success.
|
|
The exact combination of software included in a LAMP package is nor fixed and may vary depending of developer preferences. Of course using "classic" set of components (Linux, Apache,MySQL and PHP) provides the most well debugged environment with tremendous amount of literature and ready made components available. Still sometimes it is prudent to deviate from the classic set, especially with respect to the scripting language used:
Of the most widespread Linux distributions, as of 1 October 2013, 58.5% of web server market share is shared between Debian and Ubuntu, while RHEL, Fedora and CentOS together share 37.3%. See Advanced Linux Administration
Apache is a web server, the most popular in use. As of June 2013, Apache was estimated to serve
54.2% of all active websites and 53.3% of the top servers across all domains. As of June 2014,
Apache was estimated to serve 52.27% of all active websites, followed by nginx with 14.36% and
53.32% of the top servers followd by nginx with 18.16% (Wikipedia)
Apache is developed and maintained by an open community of developers under the auspices of the
Apache Software Foundation. Released under the Apache License, Apache is open-source software. A
wide variety of features is supported, and many of them are implemented as compiled modules which
extend the core functionality of Apache. These can range from server-side programming language
support to authentication schemes.
See Apache
MySQL is a multithreaded, multi-user, SQL database management system (DBMS) now owned by Oracle
Corporation.[4] MySQL has been owned by Oracle Corporation since January 27, 2010 through the
purchase of Sun Microsystems.[5][6] Sun had originally acquired MySQL on February 26, 2008. The
MySQL development project has made its source code available under the terms of the GNU General
Public License, as well as under a variety of proprietary agreements.
MariaDB is a fork of MySQL. MongoDB is a widely used open-source NoSQL database. MongoDB eschews the
traditional table-based relational database structure in favor of JSON-like documents with dynamic
schemas (calling the format BSON), making the integration of data in certain types of applications
easier and faster.
Other RDBM systems such as PostgreSQL (forming up the LAPP bundle) are also viable.
PHP is a the most popular scripting language for usage in the LAMP stack. PHP code is interpreted by a web server with a PHP processor module, which generates the resulting web page: PHP commands can be embedded directly into an HTML source document rather than calling an external file to process data. PHP is free software released under the PHP License, which is incompatible with the GNU General Public License (GPL) due to restrictions on the usage of the term PHP.[9]
Perl can be used as alternative to PHP althouth due to lack of development funds it fall into
background and does nto provided strong compertition anymore. But it remains a better, more powerful
scripting language.
Python is a widely used general-purpose, high-level programming language. Python supports multiple
programming paradigms, including object-oriented, imperative and functional programming or
procedural styles. Python recently picked up as software development language that can compete with
Java, so its usage in LAMP stack is growing.
As LAMP represent the idea "application is an OS" many OS tools can be used to enhance LAMP environment. For example while syslog daemon is not considered to be LAMP component is is used for logging in any LAMP applications. Log rotation is also performed within the operation system, not on application basis.
Similary while shell is not considered to be part of LAMP many LAMP applications provide a set of shell script for maintaning the application.
Additional software packages can be installed for monitoring application health and for configuration management of the server.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
IBM developerWorks
Use an opcode cache
The easiest thing to boost performance of any PHP application (the "P" in LAMP, of course) is to take advantage of an opcode cache. For any website I work with, it's the one thing I make sure is present, since the performance impact is huge (many times with response times half of what they are without an opcode cache). But the big question most people new to PHP have is why the improvement is so drastic.
... ... ...
Since PHP is an interpreted language rather than a compiled one like C or the Java language, the entire parse-compile-execute steps are carried out for every request. You can see how this can be time- and resource-consuming, especially when scripts rarely change between requests. After the script is parsed and compiled, the script is in a machine parseable state as a series of opcodes. This is where an opcode cache comes into effect. It caches these compiled scripts as a series of opcodes to avoid the parse and compile steps for every request.
... ... ...
So when the cached opcodes of a PHP script exists, we can skip by the parse and compile steps of the PHP request process and directly execute the cache opcodes and output the results. The checking algorithm takes care of situations where you may have made a change to the script file, so on the first request of the changed script, the opcodes will be automatically recompiled and cached then for subsequent requests, replacing the cached script.
Opcode caches have long been popular for PHP, with some of the first ones coming about back in the heyday of PHP V4. Today there are a few popular choices that are in active development and being used:
- Alternative PHP Cache (APC) is probably the most popular opcode cache for PHP (see Resources). It is developed by several core PHP developers and has had major contributions to it, gaining its speed and stability from engineers at Facebook and Yahoo! It also sports several other speed improvements for handling PHP requests, including a user cache component we'll look at later in this article.
- Wincache is an opcode cache that is most actively developed by the Internet Information Services (IIS) team at Microsoft® for use only on Windows® using the IIS web server (see Resources). It was developed predominately in an effort to make PHP a first-class development platform on the Windows-IIS-PHP stack, as APC was known not to work well on that stack. It is very similar to APC in function and sports a user cache component, as well as a built-in session handler to leverage Wincache directly as a session handler.
- eAccelerator is a fork of one of the original PHP caches, the Turck MMCache opcode cache (see Resources). Unlike APC and Wincache, it is only an opcode cache and optimizer, so it does not contain the user cache components. It is fully compatible across UNIX® and Windows stacks, and it is quite popular for sites that don't intend to leverage the additional features APC or Wincache provide. This is often the case if you will be using a solution like memcache to have a separate user cache server for a multi-web server environment.
Without a doubt, an opcode cache is the first step in speeding up PHP by removing the need to parse and compile a script on every request. Once this first step is completed, you should see an improvement in response time and server load. But there is more you can do to optimize PHP, which we'll look next.
While implementing an opcode cache is a big bang for performance improvement, there are a number of other tweaks you can do to optimize your PHP setup, based upon the settings in your php.ini file. These settings are more appropriate for production instances; on development or testing instances, you may not want to make these changes as it can make it more difficult to debug application issues.
Let's take a look at a few items that are important to help performance.
Things that should be disabled
There are several php.ini settings that should be disabled, since they are often used for backward-compatibility:
- register_globals - This functionality used to be the default before PHP V4.2, where the incoming request variables are automatically assigned to normal PHP variables. Other than the major security issues in doing this (having unfiltered incoming request data being mixed with normal PHP variable content), there is also the overhead of having to do this on every request. So turning this off will keep your application safer and improve performance.
- magic_quotes_* - This is another relic of PHP V4, where incoming data would automatically escape risky form data. It was designed to be a security feature to help sanitize incoming data before having it sent to a database, but it isn't very effective since it doesn't protect users against the more common types of SQL injection attacks out there. Since most database layers support prepared statements that handle this risk much better, turning this off will again remove an annoying performance problem.
- always_populate_raw_post_data - This is really only needed if for some reason you need to look at the entire payload of the incoming POST data unfiltered. Otherwise, it's just storing in memory a duplicate copy of the POST data, which isn't needed.
Disabling these options on legacy code can be risky, however, since they may be depending upon them being set for proper execution. Any new code should not be developed depending on these options being set, and you should look for ways to refactor your existing code away from using them if possible.
Things that should be enabled or have its setting tweaked
There are some good performance options you can enable in the php.ini file to give your scripts a bit of a speed boost:
- output_buffering - You should make sure this is on, since it will flush output back to the browser in a large chunk rather than on every echo or print statement, where the latter can very much slow down your request response time.
- variables_order - This directive controls the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing for the incoming request. If you aren't using certain superglobals (such as environment variables), you can safely remove them to gain a small speedup from not having to parse them on every request.
- date.timezone - This is a directive that was added in PHP V5.1 to set the default timezone for use with the DateTime functions introduced then. If you don't set this in the php.ini file, PHP will do a number of system requests to figure out what it is, and in PHP V5.3, a warning will be emitted on every request.
These are considered "low-hanging fruit" in terms of settings that should be configured on your production instance. There is one more thing you should look at as far as PHP in concerned. This is the use of require() and include() (as well as their siblings require_once() and include_once()) in your application. These optimize your PHP configuration and code to prevent unneeded file status checks on every request, which can slow down response times.
Manage your require()s and include()s
File status calls (meaning calls made to the underlying file system to check for the existence of a file) can be quite costly in terms of performance. One of the biggest culprits of file stats comes in the form of the require() and include() statement, which are used to bring code into your script. The sibling calls of require_once() and include_once() can be more problematic, as they not only need to verify the existence of the file, but also that it hasn't be included before.
So what's the best way to deal with this? There are a few things you can do to speed this up.
- Use absolute paths for all require() and include() calls. This will make it more clear to PHP the exact file you are wishing to include, thus not needing to check the entire include_path for your file.
- Keep the number of entries in the include_path low. This will help for situations where it's difficult to provide an absolute path for every require() and include() call (often the case in large, legacy applications) by not checking locations where the file you are including won't be.
APC and Wincache also have mechanisms for caching the results of file status checks made by PHP, so repeated file-system checks are not needed. They are most effective when you keep your include file names static rather than variable-driven, so it's important to try to do this whenever possible.
Database optimization can become a pretty advanced topic quickly, and I don't have nearly the space here to do this topic full justice. But if you are looking at optimizing the speed of your database, there are a few steps that you should take first which should help the most common issues encountered.
Put the database on its own machine
Database queries can become quite intense on their own, often pegging a CPU at 100 percent for doing simple SELECT statement with reasonable size datasets. If both your web server and database server are competing for CPU time on a single machine, this will definitely slow down your request. Thus I consider it a good first step to have the web server and database server on separate machines and be sure you make your database server the beefier of the two (database servers love lots of memory and multiple CPUs).
Properly design and index tables
Probably the biggest issues with database performance come as a result of poor database design and missing indexes. SELECT statements are usually overwhelmingly the most common types of queries run in a typical web application. They are also the most time-consuming queries run on a database server. Additionally, these kinds of SQL statements are the most sensitive to proper indexing and database design, so look to the following pointers for tips for optimal performance.
- Make sure each table has a primary key. This provides the table a default order and a fast way to join the table against other tables.
- Make sure any foreign keys in a table (that is, keys that link a record to a record in another table) are properly indexed. Many databases will enforce constraints on these keys automatically so that value actually matches a record in the another table, which can help this out.
- Try to limit the number of columns in a table. Too many columns in a table can make the scan time for queries much longer than if there are just a few columns. In addition, if you have a table with many columns that aren't typically used, you are also wasting disk space with NULL value fields. This is also true with variable size fields, such as text or blob, where the table size can grow much larger than needed. In this case, you should consider splitting off the additional columns into a different table, joining them together on the primary key of the records.
Analyze the queries being run on the server
The best tool for improving database performance is analyzing what queries are being run on your database server and how long they are taking to run. Just about every database out there has tools for doing this. With MySQL, you can take advantage of the slow query log to find the problematic queries. To use it, set the slow_query_log setting to 1 in the MySQL configuration file, then log_output to FILE to have them logged to the file hostname-slow.log. You can set the long_query_time threshold to how long the query must run in number of seconds to be considered a "slow query." I'd recommend setting this to 5 seconds at first and move it down to 1 second over time, depending upon your data set. If you look at this file, you'll see the queries detailed similar to Listing 1.
Listing 1. MySQL slow query log
/usr/local/mysql/bin/mysqld, Version: 5.1.49-log, started with: Tcp port: 3306 Unix socket: /tmp/mysql.sock Time Id Command Argument # Time: 030207 15:03:33 # User@Host: user[user] @ localhost.localdomain [127.0.0.1] # Query_time: 13 Lock_time: 0 Rows_sent: 117 Rows_examined: 234 use sugarcrm; select * from accounts inner join leads on accounts.id = leads.account_id;The key thing we want to look at is Query_time, which shows how long the query took. Another thing to look at is the numbers of Rows_sent and Rows_examined, since these can point to situations where a query might be written incorrectly if it's looking at too many rows or returning too many rows. You can delve deeper into how a query is written by prepending EXPLAIN to the query, which will return the query plan instead of the result set, as show in Listing 2.
Listing 2. MySQL EXPLAIN results
mysql> explain select * from accounts inner join leads on accounts.id = leads.account_id; +----+-------------+----------+--------+--------------------------+---------+--- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+--------+--------------------------+---------+-------- | 1 | SIMPLE | leads | ALL | idx_leads_acct_del | NULL | NULL | NULL | 200 | | | 1 | SIMPLE | accounts | eq_ref | PRIMARY,idx_accnt_id_del | PRIMARY | 108 | sugarcrm.leads.account_id | 1 | | +----+-------------+----------+--------+--------------------------+---------+--------- 2 rows in set (0.00 sec)The MySQL manual dives much deeper into the topic of the EXPLAIN output (see Resources), but the big thing I look at is places where the 'type' column is 'ALL', since this requires MySQL to do a full table scan and doesn't use a key for a lookup. These help point you to places where adding indexes will significantly help query speed.
As we saw in the previous section, databases can easily be the biggest pain point of performance in your web application. But what if the data you are querying doesn't change very often? In this case, it may be a good option to store those results locally instead of calling the query on every request.
Two of the opcode caches we looked at earlier, APC and Wincache, have facilities for doing just this, where you can store PHP data directly into a shared memory segment for quick retrieval. Listing 3 provides an example on how to do this.
Listing 3. Example of using APC for caching database results
<?php function getListOfUsers() { $list = apc_fetch('getListOfUsers'); if ( empty($list) ) { $conn = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass'); $sql = 'SELECT id, name FROM users ORDER BY name'; foreach ($conn->query($sql) as $row) { $list[] = $row; } apc_store('getListOfUsers',$list); } return $list; }We'll only need to do the query one time. Afterward, we push the result into the APC user cache under the key getListOfUsers. From here on out, until the cache expires, you will be able to fetch the result array directly out of cache, skipping over the SQL query.
APC and Wincache aren't the only choices for a user cache; memcache and Redis are other popular choices that don't require you to run the user cache on the same server as the Web server. This gives added performance and flexibility, especially if your web application is scaled out across several Web servers.
Tags: apache, lamp, linux, mysql, php,
|
|
|
HowtoForge
compiling error on 64 bit systemsSubmitted by horus.solaris on Wed, 2007-01-17 17:39.
On 64-bit systems, run:export LDFLAGS=-L/usr/lib64/mysql
before run configure and make. That will fix the following error during compiling:
/usr/bin/ld: cannot find -lmysqlclient
found on: http://www.zabbix.com/forum/showthread.php?t=3962&highlight=lmysqlclient
HS
login or register to post comments |email this page |
view as pdf
Put web frontend somewhere other than /home/... if using SELinux
Submitted by chrisrbailey on Fri, 2006-09-08 01:00.If you have the SELinux portion of Fedora on your system, you will need to put the PHP frontend somewhere other than the Zabbix user's home directory. For example, I have it in /usr/share/zabbix. Otherwise Apache will not be able to access it.
login or register to post comments |
Have someone else config it for you!
Submitted by Anonymous on Wed, 2006-04-12 20:14.If you don't feel like going through this kind of config (and the typical maintenance) that surrounds these kind of (great) OpenSource products, try out a service from TruePath Technologies (http://truepathtechnologies.com/)! They use opensource software like Zabbix. Nice part is that they setup, maintain it and you get to use it (the fun part!)
login or register to post comments |
I have always used big brother. I tried zabbix but ended up going back to big brother. Just my 2 cents.
Steve,
login or register to post comments |and php-mysql needs to be installed as well - of course
Submitted by Anonymous on Sat, 2006-03-18 03:16.yum -y install php-mysql
login or register to post comments |If you are running an RPM based system you can also use YUM to get the needed packages:
yum -y install mysql-server
yum -y install gcc
yum -y install net-snmp-develThis is necessary BEFORE you can successfully compile
login or register to post comments |apt-get install make gcc libsnmp5-dev
This solved the problems I had with compiling.... RayIT
|
|
|
Applications using the LAMP (Linux®, Apache, MySQL, PHP/Perl) architecture are constantly being developed and deployed. But often the server administrator has little control over the application itself because it's written by someone else. This series of three articles discusses many of the server configuration items that can make or break an application's performance. This first article covers the LAMP architecture, some measurement techniques, and some basic Linux kernel, disk, and file system tweaks. Successive articles investigate tuning the Apache, MySQL, and PHP components.
Linux, Apache, MySQL, and PHP (or Perl) are the foundation of many Web applications, from to-do lists to blogs to e-commerce sites. WordPress and Pligg are but two common software packages powering high-volume Web sites. This architecture has come to be known simply as LAMP. Almost every distribution of Linux includes Apache, MySQL, PHP, and Perl, so installing the LAMP software is almost as easy as saying it.
This ease of installation gives the impression that the software runs itself, which is simply not true. Eventually the load on the application outgrows the settings that come bundled with the back-end servers and application performance suffers. LAMP installations require constant monitoring, tuning, and evaluation.
Tuning a system has different meanings to different people. This series of articles focuses on tuning the LAMP components -- Linux, Apache, MySQL, and PHP. Tuning the application itself is yet another complex matter. There is a symbiotic relationship between the application and the back-end servers: a poorly tuned server causes even the best application to fail under load, and there's only so much tuning one can do to a server before a badly written application slows to a crawl. Fortunately, proper system tuning and monitoring can point to problems in the application.
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: July, 28, 2019
