Softpanorama

May the source be with you, but remember the KISS principle ;-)
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

Differences between RHEL 8 and RHEL 7

RHEL 8 might be a better version to jump from RHEL 6 then RHEL 7 as it has longer period of support.

News The tar pit of Red Hat overcomplexity RHEL8 documentation Recommended Links Systemd Systemd Cheatsheet DNF - Fedora Project Wiki Chapter1.Using AppStream Red Hat Enterprise Linux 8 Red Hat Customer Portal
Registering a server using Red Hat Subscription Manager (RHSM) Migrating systems from RHN to RHNSM Kickstart Installation Red Hat Enterprise Linux 8 Image Builder Building custom system images RPM Anaconda Log rotation in RHEL/Centos/Oracle linux
Networking Linux ip command Network Manager overwrites resolv.conf Linux route command RHEL handling of DST change RHEL subscription management Log rotation Xinetd
RPM YUM Anaconda VNC-based Installation in Anaconda Cron Wheel Group PAM Disk Management
Apache NTP SSH rsync NFS Samba Sendmail Midnight Commander
vim Virtualization Tips Systemd Tips bash Sysadmin Horror Stories Humor Etc

Introduction

Release of RHEL 8 gives opportunity for those who still are using RHEL 6 to skip RHEL 7 completely for new server installations. RHEL 7 has five years before EOL (June 30, 2024) while many severs last more then five years now.

RHEL 8 theoretically will be able to withstand more heavy loads due to optimized TCP/IP stack and improvements in memory handling. Among notable changes

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index

On command line level you do not feel much change. Systemd is omnipresent like in RHEL 7.

Some highlights

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Mar 10, 2019] Common Administrative Commands for RHEL 7, 6, 5

Mar 10, 2019 | www.pawanbahuguna.com

Must know Command Difference in RHEL 7, 6 and 5

1. Shutdown system

RHEL 5 & 6: # shutdown
RHEL 7: # systemctl shutdown

2. Reboot system

RHEL 5 & 6: # reboot or # init 6
RHEL 7: # systemctl reboot

3. Configure default run level/target

RHEL 5 & 6: # /etc/inittab
RHEL 7: # systemctl set-default

4. Configure GRUB bootloader

RHEL 5 & 6: # /boot/grub/grub.conf
RHEL 7: # /etc/default/grub, grub2-mkconfig, grub-set-default

5. List running services

RHEL 5 & 6: # service –status-all
RHEL 7: # systemctl -t service –state=active

6. Check if service is enabled

RHEL 5 & 6: # chkconfig name
RHEL 7: # systemctl is-enabled name

7. View run level/target

RHEL 5 & 6: # runlevel or who -r
RHEL 7: # systemctl get-default or who -r

8. Enable/disable service

RHEL 5 & 6: # chkconfig name on and # chkconfig name off
RHEL 7: # systemctl enable name.service and # systemctl disable name.service

9. View service status

RHEL 5 & 6: # service name status
RHEL 7: # systemctl status name.service

Note: I have tried few RHEL6 command and they are working perfectly fine in RHEL7 also.

This chart is freely available at Red Hat website , you can just Google it or click below download link to download. Go and try these commands on your test environment.

Download Chart

[Mar 01, 2019] Creating symlinks instead of /bin /sbin /lib and /lib64 directories in RHEL7

That change essentially means that /usr should be on the root partition, not on a separate partition which with the current sizes of harddrive is a resobale requirement.
Notable quotes:
"... On Linux /bin and /usr/bin are still separate because it is common to have /usr on a separate partition (although this configuration breaks in subtle ways, sometimes). In /bin is all the commands that you will need if you only have / mounted. ..."
Mar 01, 2019 | unix.stackexchange.com

balki ,May 2, 2015 at 6:17

What? no /bin/ is not a symlink to /usr/bin on any FHS compliant system. Note that there are still popular Unixes and Linuxes that ignore this - for example, /bin and /sbin are symlinked to /usr/bin on Arch Linux (the reasoning being that you don't need /bin for rescue/single-user-mode, since you'd just boot a live CD).

/bin

contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts

/usr/bin/

This is the primary directory of executable commands on the system.

essentially, /bin contains executables which are required by the system for emergency repairs, booting, and single user mode. /usr/bin contains any binaries that aren't required.

I will note, that they can be on separate disks/partitions, /bin must be on the same disk as / . /usr/bin can be on another disk - although note that this configuration has been kind of broken for a while (this is why e.g. systemd warns about this configuration on boot).

For full correctness, some unices may ignore FHS, as I believe it is only a Linux Standard, I'm not aware that it has yet been included in SUS, Posix or any other UNIX standard, though it should be IMHO. It is a part of the LSB standard though.

LawrenceC ,Jan 13, 2015 at 16:12

/sbin - Binaries needed for booting, low-level system repair, or maintenance (run level 1 or S)

/bin - Binaries needed for normal/standard system functioning at any run level.

/usr/bin - Application/distribution binaries meant to be accessed by locally logged in users

/usr/sbin - Application/distribution binaries that support or configure stuff in /sbin.

/usr/share/bin - Application/distribution binaries or scripts meant to be accessed via the web, i.e. Apache web applications

*local* - Binaries not part of a distribution; locally compiled or manually installed. There's usually never a /local/bin but always a /usr/local/bin and /usr/local/share/bin .

JonnyJD ,Jan 3, 2013 at 0:17

Some kind of "update" on this issue:

Recently some Linux distributions are merging /bin into /usr/bin and relatedly /lib into /usr/lib . Sometimes also (/usr)/sbin to /usr/bin (Arch Linux). So /usr is expected to be available at the same time as / .

The distinction between the two hierarchies is taken to be unnecessary complexity now. The idea was once having only /bin available at boot, but having an initial ramdisk makes this obsolete.

I know of Fedora Linux (2011) and Arch Linux (2012) going this way and Solaris is doing this for a long time (> 15 years).

xenoterracide ,Jan 17, 2011 at 16:23

On Linux /bin and /usr/bin are still separate because it is common to have /usr on a separate partition (although this configuration breaks in subtle ways, sometimes). In /bin is all the commands that you will need if you only have / mounted.

On Solaris and Arch Linux (and probably others) /bin is a symlink to /usr/bin . Arch also has /sbin and /usr/sbin symlinked to /usr/bin .

Of particular note, the statement that /bin is for "system administrator" commands and /usr/bin is for user commands is not true (unless you think that bash and ls are for admins only, in which case you have a lot to learn). Administrator commands are in /sbin and /usr/sbin .

[Jan 31, 2019] How to Disable Bluetooth in CentOS-RHEL 5,6,7

Jan 31, 2019 | www.thegeekdiary.com

Disabling Bluetooth service at startup

Additionally, once the kernel modules are disabled, if you have the bluez (Bluetooth utilities) package installed you will want to have the Bluetooth service disabled at startup.

On CentOS/RHEL 7 execute the following commands as root:

# systemctl disable bluetooth.service
# systemctl mask bluetooth.service
# systemctl stop bluetooth.service

On CentOS/RHEL 5 and 6 , execute the following commands as root:

# chkconfig bluetooth off
# service bluetooth stop
Uloading Bluetooth Modules

If the above kernel modules are already loaded, you can manually unload them with the rmmod command. Depending on what Bluetooth hardware is discovered on the system, there is expected to be slight variations on which Bluetooth modules are loaded. The rmmod command will display information about additional Bluetooth modules loaded when attempting to use it. You will want to rmmod any additional Bluetooth modules it notifies you are also loaded. Execute the following as root to unload these modules from the running kernel:

On CentOS/RHEL 6 and 7 :

# rmmod bnep
# rmmod bluetooth
# rmmod btusb

On CentOS/RHEL 5 :

# rmmod bnep
# rmmod bluetooth
# rmmod hci_usb

[Apr 15, 2015] Is Modern Linux Becoming Too Complex

One man's variety is another man's hopelessly confusing goddamn mess.

Feb 11, 2015 | Slashdot

An anonymous reader writes: Debian developer John Goerzen asks whether Linux has become so complex that it has lost some of its defining characteristics. "I used to be able to say Linux was clean, logical, well put-together, and organized. I can't really say this anymore. Users and groups are not really determinitive for permissions, now that we have things like polkit running around. (Yes, by the way, I am a member of plugdev.) Error messages are unhelpful (WHY was I not authorized?) and logs are nowhere to be found. Traditionally, one could twiddle who could mount devices via /etc/fstab lines and perhaps some sudo rules. Granted, you had to know where to look, but when you did, it was simple; only two pieces to fit together. I've even spent time figuring out where to look and STILL have no idea what to do."

Lodragandraoidh (639696) on Wednesday February 11, 2015 @11:21AM (#49029667)

Re:So roll your own. (Score:5, Insightful)

I think you're missing the point. Linux is the kernel - and it is very stable, and while it has modern extensions, it still keeps the POSIX interfaces consistent to allow inter-operation as desired. The issue here is not that forks and new versions of Linux distros are an aberration, but how the major distributions have changed and the article is a symptom of those changes towards homogeneity.

The Linux kernel is by definition identically complex on any distro using a given version of the kernel (the variances created by compilation switches notwithstanding). The real variance is in the distros - and I don't think variety is a bad thing, particularly in this day and age when we are having to focus more and more on security, and small applications on different types of devices - from small ARM processor systems, to virtual cluster systems in data centers.

Variety creates a strong ecosystem that is more resilient to security exploitation as a whole; variety is needed now more than ever given the security threats we are seeing. If you look at the history of Linux distributions over time - you'll see that from the very beginning it was a vibrant field with many distros - some that bombed out - some that were forked and then died, and forks and forks of forks that continued on - keeping the parts that seemed to work for those users.

Today - I think people perceive what is happening with the major distros as a reduction in choice (if Redhat is essentially identical to Debian, Ubuntu, et al - why bother having different distros?) - a bottleneck in variability; from a security perspective, I think people are worried that a monoculture is emerging that will present a very large and crystallized attack surface after the honeymoon period is over.

If people don't like what is available, if they are concerned about the security implications, then they or their friends need to do something about it. Fork an existing distro, roll your own distro, or if you are really clever - build your own operating system from scratch to provide an answer, and hopefully something better/different in the long run. Progress isn't a bad thing; sitting around doing nothing and complaining about it is.

NotDrWho (3543773) on Wednesday February 11, 2015 @11:28AM (#49029739)

Re: So roll your own. (Score:5, Funny)

One man's variety is another man's hopelessly confusing goddamn mess.

Anonymous Coward on Wednesday February 11, 2015 @09:31AM (#49028605)

Re: Yes (Score:4, Insightful)

Systemd has been the most divisive force in the Linux community lately, and perhaps ever. It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.

Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.

Re:
Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.

People are loath to publish new projects because keeping them running with systemd and all its dependencies in all possible permutations is a full time job. The whole "do one thing only and do it well" concept has been flushed down the drain.

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7, but install new systems with RHE

gmack (197796) <[email protected] minus caffeine> on Wednesday February 11, 2015 @11:55AM (#49030073) Homepage Journal

Score:4, Informative)

Who modded this up?

SystemD has put in jeopardy the entire presence of Linux in the server room:

1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.

Formal code testing is pretty much what Redhat brings to the table.

2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.

At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.

3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.

Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.

4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.

Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.

5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.

Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.

6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.

Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does.

As for SystemD: It allows booting on more complicated hardware. Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest. As a side affect of the primary problem it was meant to solve, it happens to be faster which is great for desktops and uses a lot less memory which is good for embedded systems.

So, all and all, SystemD is the worst thing that has happened with Linux, its reputation, and potentially, its future in 10 years, since the ACTA treaty was put to rest. SystemD is not production ready, and potentially can put every single box in jeopardy of a remote root hole.

Riight.. Meanwhile in the real world, none of my desktops or servers have any SystemD related network services running so no root hole here.

Dragonslicer (991472) on Wednesday February 11, 2015 @12:26PM (#49030407)

Score:5, Insightful)

3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program.

Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.

Because of course it's been years since anyone found any security holes in well-tested software like Bash or OpenSSL.

Anonymous Coward on Wednesday February 11, 2015 @08:24AM (#49028117)

Score:5, Interesting)

I was reading through the article's comments and saw this thread of discussion [complete.org]. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away.

The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today. I don't use Debian, but I do use another distro that switched to systemd, and it is in fact the problem here. My workstation doesn't work anywhere as well as it did a couple of years ago, before systemd got installed. So when somebody blames systemd for these kinds of problems, that person is totally correct. I don't get why John would censor the discussion like that. I also don't get why he'd label somebody who points out the real problem as being a 'troll'.

John needs to admit that the real problem here is not the people who are against systemd. These people are actually the ones who are right, and who have the solution to John's problems!

The comment I linked to says 'Systemd needs to be removed from Debian immediately.', and that's totally right. But I think we need to expand it to 'Systemd needs to be removed from all Linux distros immediately.'

If we want Linux to be usable again, systemd does need to go. It's just as simple as that. Censoring any and all discussion of the real problem here, systemd, sure isn't going to get these problems resolved any quicker!

Re:Why does John shut down all systemd talk? (Score:5, Insightful)

[Aug 27, 2014] Review RHEL 7 lands with a jolt

Aug 27, 2014

There's a lot to like in the next Red Hat Enterprise Linux, but some fundamental changes may prove problematic By Paul Venezia,

Open Source, Linux, Red Hat Enterprise Linux

One of the hallmarks of Red Hat Enterprise Linux is that it overwhelmingly favors stability over currency. As such, RHEL generally ships with packages and frameworks that are years behind the current releases. This is by design, to ensure that the RHEL distribution is as solid as possible. As an example, Red Hat's slow and steady approach saved RHEL 6.4 users from the OpenSSL Heartbleed vulnerability because all RHEL versions up to and including that version shipped with a two-year-old version of OpenSSL that was not affected.

If you follow the Fedora distribution, which serves as the icebreaker for the more stable RHEL distribution, you've seen many changes coming down the pike for RHEL 7. Many of these changes are the most fundamental we've seen in quite some time. Several are to be heralded, but others -- notably the replacement of Init and Upstart with Systemd -- are likely to chafe longtime RHEL users and potentially curb adoption.

[ Systemd: Harbinger of the Linux apocalypse | Prove your expertise with the free OS in InfoWorld's Linux admin IQ test round 1 and round 2 | Download InfoWorld's beginner's guide to Docker to get started on this red-hot technology. ]

What's new in RHEL 7There is a long list of changes in RHEL 7, but only a few are fundamental. RHEL 7 now uses Systemd rather than Init scripts for service startup and management -- more on that later. The new default file system is XFS rather than Ext4, with support of XFS file systems up to 500TB in size. To that end, RHEL 7 now supports Ext4 file systems as large as 50TB.

Brace for impact Of the myriad changes found in RHEL 7, a few are certain to cause consternation. First and foremost of those is the move to the Systemd system and process manager. This represents a major departure from Red Hat's -- and Linux's -- history and from the tried-and-true Unix philosophy of using simple, modular tools for critical infrastructure components. Systemd replaces the simplicity of Init scripts with a major management system that offers new features and capabilities but adds significant complexity.

Some of the benefits to Systemd are the parallelized service startup at boot and centralized service management -- and it certainly shortens boot times.

However, there are decades of admin reflexes to overcome by introducing Systemd, and those tasked with maintaining servers running RHEL 6 and RHEL 7 releases will quickly tire of the significant administrative differences between them. Red Hat has replicated many original commands to Systemd commands to address this issue (see the Fedora project's SysVinit to Systemd Cheatsheet). But at the heart of the matter, an extremely fundamental part of RHEL server administration is now wildly altered.

To take one example, for 20 years we've been able to issue the chkconfig -list command to show what services are set to start and at what run level. That command is now systemctl list-unit-files --type=service. For the moment, chkconfig -list still works, but chides you for not using the systemctl call. In /etc/init.d you'll find only a few scripts and a README.

Both sides of the Systemd divide have their adherents, but in RHEL 7, the Systemd argument has clearly won. I believe, however, that this will ultimately rankle many veteran Linux admins, and we may be on the road to a real schism in the RHEL community and in the Linux world at large.

Smoother sailing RHEL7 will integrate Docker, the Linux containers solution. Docker is built around the Linux kernel-based virtualization method that permits multiple, isolated virtual systems, or containers, to run on a single host system. Docker makes it easy to deploy applications and services inside containers and move them between host systems without requiring specific dependencies or package installations on the target host.

For example, you could create a container on an Ubuntu server that's running a Memcached service and copy that container to an RHEL server where it would run without alteration. Linux containers and Docker can also run on physical, virtual, or cloud infrastructures, generally without requiring anything more than the Docker binary installed on the host.

Docker-managed containerization is a big deal for computing in general, and the quick adoption in RHEL 7 shows that Red Hat is interested in getting on the forefront of this change, rather than backing into it in a later release.

Direct support for Active Directory authentication is another significant update, one that may cause more than a few environments to finally ditch NIS and existing LDAP authentication mechanisms. RHEL 7 can now function with cross-domain trusts to Microsoft Active Directory. This means that a user existing only in Active Directory can authenticate to an RHEL 7 server without requiring any synchronization of user data between the realms.

Thus, environments that have been maintaining multiple authentication mechanisms for their Windows and Linux infrastructures can now combine them without jumping through too many hoops. There are many shops that still run NIS on Linux, either maintaining a completely separate authentication realm, or using one of several rather funky methods of combining the two (such as identity synchronization or using a Windows server as the NIS master).

The addition of Performance Co-Pilot (PCP) should also find many supporters. PCP can collect all kinds of performance metrics on a server and make them available to any local or remote viewer, even running on other platforms. PCP can also be used to provide detailed information on application performance. Thorough use of PCP will make troubleshooting intractable server-side problems easier and offer heightened visibility into the operating state of a server.

Finally, the graphical installation tool Anaconda has received a face-lift. It's much flatter, allowing all pertinent configuration elements to be set within one screen, rather than through a series of screens separated by Next buttons. Within a few clicks you can configure the system as you require, then click Install and walk away while that work is done.

On the downside, the package selection is somewhat restricting, separating certain packages by base server selection. For instance, you can't easily select MariaDB server and client in the Web server grouping, so selecting the elements of a LAMP server will need to be done after install.

That said, the new installer is clean and slick, and let's face it -- we're not likely to use the installer much these days. We'll create some templates or images and use those.

RHEL 7 is a fairly significant departure from the expected full-revision release from Red Hat. This is not merely a reskinning of the previous release with updated packages, a more modern kernel, and some new toolkits and widgets. This is a very different release than RHEL 6 in any form, mostly due to the move to Systemd.

Though this change has been visible for some time, it will still cause integration problems in a large number of sites with a significant RHEL installed base. You can expect the adoption of RHEL 7 to be slowed quite a bit in these places, which may push out the lifecycle of RHEL 5 and RHEL 6 longer than Red Hat may like.

This article, "Review: RHEL 7 lands with a jolt," was originally published at InfoWorld.com. Follow the latest developments in Linux, data center, virtualization, and open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Read more about data center in InfoWorld's Data Center Channel.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Etc

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, 22, 2020