 |
 |
 |
|
|
In RHEL7 there are two log related daemons.
it reads its configuration from /etc/rsyslog.conf (this file specifies the default location for all system logs) and from files inside /etc/rsyslog.d, if any. Most of system log files are located in the /var/log directory due to SYSLOG default configuration (see /etc/rsyslog.conf file).
In RHEL they are working sequentially with output from syslogd forwarded to rsyslogd.
Some daemons maintain their own log infrastructure. For example all SELinux events are written into the /var/log/audit/audit.log file.
In the current state of RHEL 7 development, journald is not a replacement for rsyslog; it is just another way of viewing and processing system logs. That may change as Red Hat is pushing systemd down user throats like there is not tomorrow.
Rsyslogd daemon represents classic way to processing Linux logs and should probably be studied first.
It behaviour is controlled via the file the /etc/rsyslog.conf file. Doemos does not reread the file automatically if it changes. You need to sent it HUP signal and restart the daemon
Like many other services on RHEL 7, the configuration for rsyslogd is not defined in just one configuration file. The /etc/rsyslogd.conf file is the central location where rsyslogd is configured. From this file, the content of the directory /etc/rsyslog.d is included. This directory can be populated by installing RPM packages on a server. When looking for specific log configuration, make sure to always consider the contents of this directory also.
If specific options need to be passed to the rsyslogd service on startup, you can do this by using the /etc/sysconfig/rsyslog file. This file by default contains one line, which reads
SYSLOGD_OPTIONS=''
On this line, you can specify rsyslogd startup parameters. The SYSLOGD_OPTIONS variable is included in the systemd configuration file that starts rsyslogd. Theoretically, you could change startup parameters in this file, as well, but that is not recommended.
NOTE: Many RHEL subsystems and daemons store configuration files in two locations. For rsyslog it is /etc/rsyslog.conf and /etc/rsyslog.d directory.
The default rsyslog.conf file is shown below
[1] d620@ROOT:/etc # cat /etc/rsyslog.conf # rsyslog configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES #### # The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imjournal # provides access to the systemd journal #$ModLoad imklog # reads kernel messages (the same are read from journald) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # Provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Where to place auxiliary files $WorkDirectory /var/lib/rsyslog # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by default. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf # Turn off message reception via local log socket; # local messages are retrieved through imjournal now. $OmitLocalLogging on # File to store the position in the journal $IMJournalStateFile imjournal.state #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg :omusrmsg:* # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # ### end of the forwarding rule ###
rsyslog.conf consist of three main sections
#### MODULES ####: rsyslogd is modular. Modules are included to enhance the supported features in rsyslogd. See Chapter 29, “Configuring Advanced Log Features,” for more information about rsyslogd modules.
#### GLOBAL DIRECTIVES ####: This section is used to specify global parameters, such as the location where auxiliary files are written or the default timestamp format.
#### RULES ####: This is the most important part of the rsyslog.conf file. It contains the rules that specify what information should be logged to which destination.
To specify what information should be logged to which destination, rsyslogd uses facilities, priorities, and destinations:
A facility specifies a category of information that is logged. Rsyslogd uses a fixed list of facilities, which cannot be extended. This is because of backward compatibility with the legacy syslog service.
A priority is used to define the severity of the message that needs to be logged. When specifying a priority, by default all messages with that priority and all higher priorities are logged. Priorities are also fixed.
A destination defines where the message should be written to. Typical destinations are files, but rsyslog modules can be used as a destination as well, to allow further processing through an rsyslogd module.
Facilities and priorities are all listed in man 5 rsyslog.conf.
#### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg :omusrmsg:* # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log
When specifying a destination, a file is often used. If the filename starts with a hyphen (as in -/var/log/maillog), the log messages will not be immediately committed to the file but will be buffered to make writes more efficient.
Device files can also be used, as in /dev/console. If this device is used, messages are written in real time to the console. On modern servers, this often does not make sense, because administrators mostly log in remotely and do not see what is happening on the server console.
To enhance rsyslogd functionality, modules can be used for further processing of messages.
If this is required, the module name can be specified as :modulename:
The syslog facilities were defined in the 1980s for sendmail, and to guarantee backward compatibility, no new facilities can be added. The result is that some facilities still exist that basically serve no purpose anymore, and some services that have become relevant at a later stage do not have their own facility. As a solution, two specific facility types can be used.
Then you need to add a rule to the rsyslog.conf file to send messages that come in through that facility to a specific log file.
To determine which types of messages should be logged, different severities (called prooroes) can be used in rsyslog.conf lines.
When a specific priority is used, all messages with that priority and higher are logged according to the specifications used in that specific rule. If you need to configure logging in a detailed way, where messages with different priorities are sent to different files, you can specify the priority with an equals sign (=) in front of it, as in the following configuration file, which will send all cron debug messages to a specific file with the name /var/log/cron.debug. Notice the use of the hyphen (-) in front of the destination filename, which ensures that messages are buffered and not written immediately to disk (which is good for disk performance).
Consider the following line, where all cron messages with only the debug priority are written to a specific file. Notice the - in front of the line, which buffers writes so that information is logged in a more efficient way:
In this exercise, you learn how to change rsyslog.conf. You configure the Apache service to log messages through syslog, and you create a rule that logs debug messages to a specific file.
1. By default, the Apache service does not log through rsyslog, but keeps its own logging. You are going to change that. To start, type yum install -y httpd to install the Apache service.
2. After installing the Apache service, open its configuration file /etc/http/conf/httpd.conf and add the following line to it:
ErrorLog syslog:local1
3. Type systemctl restart httpd.
4. Now create a line in the rsyslog.conf file that will send all messages that it receives for facility local1 (which is now used by the httpd service) to the file /var/log/httpd-error.log. To do this, include the following line:
local1.error /var/log/httpd-error.log
5. Tell rsyslogd to reload its configuration, by using systemctl restart rsyslog.
6. All Apache error messages will now be written to the httpd-error.log file.
7. From the Firefox browser, go to http://localhost. As no index.html page exists yet, this will be written to the error log.
8. Now let’s create a snap-in file that logs debug messages to a specific file as well. To do this, type echo ''*.debug /var/log/messages-debug'' > /etc/rsyslog.d/debug.conf.
9. Again, restart rsyslogd using systemctl restart rsyslog.
10. Use the command tail -f /var/log/messages-debug to open a trace on the newly created file.
11. Type logger -p daemon.debug ''Daemon Debug Message''. You’ll see the debug message passing by.
12. Use Ctrl+C to close the debug log file.
To prevent syslog messages from filling up your system completely, the log messages can be rotated. That means that when a certain threshold has been reached, the old log file is closed and a new log file is opened. The logrotate utility is started periodically through the crond service to take care of rotating log files.
rsyslogd does not has its own log rotation capabilities so external utility called logrotate is used.
When a log file is rotated, the old log file is typically copied to a file that has the rotation date in it. So, if /var/log/messages is rotated on January 17, 2015, the rotated filename will be /var/log/messages-20150115. As a default, four old log files are kept on the system. Files older than that period are removed from the system automatically.
The default settings for log rotation are kept in the file /etc/logrotate.conf
[0]d620@ROOT:/etc # cat logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
dateext
# uncomment this if you want your log files compressed
#compress
# RPM packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0600 root utmp
rotate 1
}
# system-specific logs may be also be configured here.
This is way too primitive configuration that provides rotation of files on a weekly basis keeping four last versions of the file. It definitly can and should be improved with little efforts.
If specific files need specific settings, you can create a configuration file for that file in /etc/logrotate.d. The settings for that specific file overwrite the default settings in /etc/logrotate.conf.
The systemd-journald service stores log messages in the journal, a binary file that is stored in the file /run/log/journal. This file can be examined using the journalctl command.
The easiest way to use journalctl is by just typing the command. It shows you recent events that have been written to the journal since your server last started. Notice that the result of this command is shown in the less pager, and by default you’ll see the beginning of the journal. Because the journal is written from the moment your server boots, this is showing boot-related log messages. If you want to see the last messages that have been logged, you can use journalctl -f, which shows the last lines of the messages where new log lines are automatically added. You can also type journalctl and use (uppercase) G to go to the end of the journal. Also note that the search options / and ? work in the journalctl output. Listing 13.5 shows a partial result of this command.
Listing 13.5 Watching Log Information Generated by journald
Click here to view code image
-- Logs begin at Wed 2015-03-25 05:24:43 PDT, end at Wed 2015-03-25
05:46:46 PDT. --
Mar 25 05:24:43 localhost.localdomain systemd-journal[207]: Runtime
journal is using 6.1M (max 49.3M, leaving 74.0M of free 487.3M, cu
Mar 25 05:24:43 localhost.localdomain systemd-journal[207]: Runtime
journal is using 6.1M (max 49.3M, leaving 74.0M of free 487.3M, cu
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpuset
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpu
Mar 25 05:24:43 localhost.localdomain kernel: Initializing cgroup
subsys cpuacct
Mar 25 05:24:43 localhost.localdomain kernel: Linux version 3.10.0-123.
el7.x86_64 ([email protected]) (gcc version 4.8.2
Mar 25 05:24:43 localhost.localdomain kernel: Command line: BOOT_
IMAGE=/vmlinuz-3.10.0-123.el7.x86_64 root=UUID=432d640e-3339-45fa-a66
Mar 25 05:24:43 localhost.localdomain kernel: Disabled fast string
operations
Mar 25 05:24:43 localhost.localdomain kernel: e820: BIOS-provided
physical RAM map:
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x0000000000000000-0x000000000009efff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000000009f000-0x000000000009ffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000000dc000-0x00000000000fffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x0000000000100000-0x000000003fedffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003fee0000-0x000000003fefefff] ACPI data
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003feff000-0x000000003fefffff] ACPI NVS
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x000000003ff00000-0x000000003fffffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000f0000000-0x00000000f7ffffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fec00000-0x00000000fec0ffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fee00000-0x00000000fee00fff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: BIOS-e820: [mem
0x00000000fffe0000-0x00000000ffffffff] reserved
Mar 25 05:24:43 localhost.localdomain kernel: NX (Execute Disable)
protection: active
Mar 25 05:24:43 localhost.localdomain kernel: SMBIOS 2.4 present.
Mar 25 05:24:43 localhost.localdomain kernel: DMI: VMware, Inc. VMware
Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07
Mar 25 05:24:43 localhost.localdomain kernel: Hypervisor detected:
VMware
Mar 25 05:24:43 localhost.localdomain kernel: e820: update [mem
0x00000000-0x00000fff] usable ==> reserved
Mar 25 05:24:43 localhost.localdomain kernel: e820: remove [mem
0x000a0000-0x000fffff] usable
Mar 25 05:24:43 localhost.localdomain kernel: No AGP bridge found
Mar 25 05:24:43 localhost.localdomain kernel: e820: last_pfn = 0x40000
max_arch_pfn = 0x400000000
Mar 25 05:24:43 localhost.localdomain kernel: MTRR default type:
uncachable
Mar 25 05:24:43 localhost.localdomain kernel: MTRR fixed ranges
enabled:
Mar 25 05:24:43 localhost.localdomain kernel: 00000-9FFFF write-back
Mar 25 05:24:43 localhost.localdomain kernel: A0000-BFFFF uncachable
Mar 25 05:24:43 localhost.localdomain kernel: C0000-CBFFF write-
protect
Mar 25 05:24:43 localhost.localdomain kernel: CC000-EFFFF uncachable
Mar 25 05:24:43 localhost.localdomain kernel: F0000-FFFFF write-
protect
Mar 25 05:24:43 localhost.localdomain kernel: MTRR variable ranges
enabled:
Mar 25 05:24:43 localhost.localdomain kernel: 0 base 0000000000 mask
FFC0000000 write-back
In this exercise, you learn how to work with different journalctl options.
1. Type journalctl. You’ll see the content of the journal since your server last started, starting at the beginning of the journal. The content is shown in less, so you can use common less commands to walk through the file.
2. Type q to quit the pager. Now type journalctl --no-pager. This shows the contents of the journal without using a pager.
3. Type journalctl -f. This opens the live view mode of journalctl, which allows you to see new messages scrolling by in real time. Use Ctrl+C to interrupt.
4. Type journalctl and press the Tab key twice. This shows specific options that can be used for filtering. Type, for instance, journalctl _UID=0.
5. Type journalctl -n 20. The -n 20 option displays the last 20 lines of the journal (just like tail -n 20).
6. Now type journalctl -p err. This command shows errors only.
7. If you want to view journal messages that have been written in a specific time period, you can use the --since and --until commands. Both options take the time parameter in the format YYYY-MM-DD hh:mm:ss. Also, you can use yesterday, today, and tomorrow as parameters. So, type journalctl --since yesterday to show all messages that have been written since yesterday.
8. journalctl allows you to combine different options, as well. So, if you want to show all messages with a priority err that have been written since yesterday, use journalctl --since yesterday -p err.
9. If you need as much detail as possible, use journalctl -o verbose. This shows different options that are used when writing to the journal (see Listing 13.3). All these options can be used to tell the journalctl command which specific information you are looking for. Type, for instance, journalctl _SYSTEMD_UNIT=sshd.service to show more information about the sshd systemd unit.
In the preceding exercise, you typed journalctl -o verbose to show verbose output. Listing 13.6 shows an example of the verbose output. You can see that this is providing detailed information for all items that have been logged, including the PID, the ID of the associated user and group account, the command that is associated, and more.
Listing 13.6 Showing Detailed Log Information with journalctl -o verbose
Click here to view code image
-- Logs begin at Thu 2015-01-08 08:28:16 EST, end at Sun 2015-01-18
03:13:41 EST. --
Thu 2015-01-08 08:28:16.531278 EST [s=8759b876dde1477a801fa58ffb4bf0ce;
i=1;b=0eebc0595e384c56b9b4079dfc26918a;
PRIORITY=6
_TRANSPORT=driver
MESSAGE=Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of
free 241.0M, current limit 24.5M).
MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
_PID=80
_UID=0
_GID=0
_COMM=systemd-journal
_EXE=/usr/lib/systemd/systemd-journald
_CMDLINE=/usr/lib/systemd/systemd-journald
_CAP_EFFECTIVE=4402800cf
_SYSTEMD_CGROUP=/system.slice/systemd-journald.service
_SYSTEMD_UNIT=systemd-journald.service
_SYSTEMD_SLICE=system.slice
_SELINUX_CONTEXT=kernel
_BOOT_ID=0eebc0595e384c56b9b4079dfc26918a
_MACHINE_ID=223a4aa0398843c497ecff431a4f0567
_HOSTNAME=localhost.localdomain
Thu 2015-01-08 08:28:16.531445 EST
[s=8759b876dde1477a801fa58ffb4bf0ce;i=2;
b=0eebc0595e384c56b9b4079dfc26918a;
PRIORITY=6
_TRANSPORT=driver
MESSAGE=Runtime journal is using 4.0M (max 24.5M, leaving 36.7M of
free 241.0M, current limit 24.5M).
MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
By default, the journal is stored in the file /run/log/journal. The entire /run directory is used for current process status information only, which means that the journal is cleared when the system reboots. To make the journal persistent between system restarts, you should make sure that a directory /var/log/journal exists.
Even when the journal is written to the permanent file in /var/log/journal, that does not mean that the journal is kept forever. The journal has built-in log rotation that will be used monthly. Also, the journal is limited to a maximum size of 10% of the file system size that it is on, and it will also stop growing if less than 15% of the file system is still free. If that happens, the oldest messages from the journal are dropped automatically to make place for newer messages.
To change these settings, you can modify the file /etc/systemd/journald.conf.
Listing 13.7 Setting journald Parameters Through /etc/systemd/journald.conf
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
Systemd primary task is to manage the boot process and provides informations about it.
To get the boot process duration, type:
# systemd-analyze Startup finished in 422ms (kernel) + 2.722s (initrd) + 9.674s (userspace) = 12.820s
To get the time spent by each task during the boot process, type:
# systemd-analyze blame 7.029s network.service 2.241s plymouth-start.service 1.293s kdump.service 1.156s plymouth-quit-wait.service 1.048s firewalld.service 632ms postfix.service 621ms tuned.service 460ms iprupdate.service 446ms iprinit.service 344ms accounts-daemon.service ... 7ms systemd-update-utmp-runlevel.service 5ms systemd-random-seed.service 5ms sys-kernel-config.mount
Note: You will find additional information on this point in the Lennart Poettering's blog.
In addition, Systemd handles the system event log, a syslog daemon is not mandatory any more.
The reasons behind Journald creation are explained in this
Introduction to
Journald.
To get the content of the Systemd journal, type:
# journalctl
To get all the events related to the crond process in the journal, type:
# journalctl /sbin/crond
Note: You can replace /sbin/crond by `which crond`.
Altenatively, to get all the events related to the crond process, you can also type:
# journalctl -u crond
To get all the events since the last boot, type:
# journalctl -b
To get all the events that appeared today in the journal, type:
# journalctl --since=today
To get all the events with a syslog priority of err, type:
# journalctl -p err
To get the 10 last events and wait for any new one (like tail -f /var/log/messages), type:
# journalctl -f
By default, Journald logs are stored in the /run/log/journal directory and disappear after a reboot.
To store Journald logs in a more permanent way, type:
# mkdir /var/log/journal # echo "SystemMaxUse=50M" >> /etc/systemd/journald.conf # systemctl restart systemd-journald
Note: Setting the SystemMaxUse variable is necessary because otherwise 10% of the filesystem where the /var/log/journal directory is stored may be used at maximum by the journal.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
|
|
|
CertDepot
Permanent storage for systemd journal as per Red Hat training, they recommend the following steps:
# mkdir -p /var/log/journal
# chown root:systemd-journal /var/log/journal
# chmod 2755 /var/log/journal
and the last step is to reboot the system or issue the following special signal: killall -USR1 systemd-journalcan someone please explain what the main difference is and compare to the steps posted earlier:
# mkdir /var/log/journal
# echo "SystemMaxUse=50M" >> /etc/systemd/journald.conf
# systemctl restart systemd-journaldRedHatter
rsyslogd – In sander's book the chapter on Configuring Logging has 70% of material on rsyslogd and only a couple pages on journald. He also says in the chapter "In the current state of RHEL 7, journald is not a replacement for rsyslog; it is just another way of logging information." But since I don't see much on rsyslogd here on this site, does it mean I don't have to know it for the RHCSA/RHCE as long as I know journald? Trying to just focus on exams stuff for now.
The Syslog topic was removed from the RHCEv7 objectives (https://www.certdepot.net/rhel7-rhce-whats-new/).
You can still find some information through the 'Locate and interpret system log files and journals' RHCSA objective (https://www.certdepot.net/rhel7-interpret-system-log-files/).
In addition, you can find additional information through these two links: https://www.certdepot.net/rhel7-configure-system-log-remote-system/ and https://www.certdepot.net/rhel7-configure-system-accept-logging-remote-system/.itninja
Maybe it is worth of mentioning that we can find log paths of different types of messages in configuration file of /etc/rsyslog.conf – this daemon is modular and it accepts messages from journald daemon, but not detailed like in journal
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: December 13, 2020
