|
|
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 | |||||||
|
|
|
|
In recent versions of SUSE, the persistent naming of Ethernet devices is handled through the udev kernel device management subsystem. If you want that the devices eth0, eth1, to be named in the way you get used to them in Red Hat, look in the directory /etc/udev/rules.d/. Here you will find a file with a name similar to 70-persistent-net.rules (the numerical prefix in this filename may vary). In this file, the network devices are listed, with their PCI identifiers in a comment above each one, and with the MAC (hardware) address. By editing the associated NAME variable, you can force the kernel to give the device a different name at the next reboot.
An example of this file, /etc/udev/rules.d/70-persistent-net.rules is shown here:
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules fil e.
#
# You can modify it, as long as you keep each rule on a single line.# PCI device 0x14e4:0x1677 (tg3)
SUBSYSTEM=="net", DRIVERS==" ?*", ATTR{address}==" 00:15:c5:0c:2f:5a", NAME="eth0"
# PCI device 0x8086:0x4223 (ipw2200)
SUBSYSTEM=="net", DRIVERS==" ?*", ATTR{address}==" 00:16:6f:6f:62:30", NAME="eth1"
If you want the wireless card to be called wlan0 in the future, you can simply replace
NAME="eth1"
with NAME=" wlan0" in the second line.
All network interfaces are activated with the script /sbin/ifup. To halt the interface, use ifdown. To check its status, use ifconfig or ifstatus.
SuSE stores the configuration of all network interfaces in way too many files, but mostly in /etc/sysconfig/network directory. YaST accepts manual changes from valid files. For example, permanently to change MTU (you can change it "on the fly" via ifconfig, but this change does not survive reboot) you need edit the MTU line in the interface file, for example /etc/sysconfig/network/ifcfg-eth0 and then restart network layer with
service network restart
Subdirectory /etc/syconfig/hardware/* contains a separate file for every device (network card). These files contain the configuration parameters (kernel module, start mode, script associations, etc.).
The /etc/sysconfig/network directory contain a half-dozen of files (both "active files" and backups created by YAST (they have extension YaST2save) and four subdirectories. For example for Suse 11 SP1 :
-rw-r--r-- 1 root root 13243 2012-10-04 17:34 config -rw-r--r-- 1 root root 6481 2012-10-04 17:34 dhcp -rw------- 1 root root 194 2013-02-26 11:29 ifcfg-eth0 -rw------- 1 root root 190 2012-10-04 17:34 ifcfg-eth0~ -rw------- 1 root root 190 2012-10-04 17:34 ifcfg-eth1 -rw------- 1 root root 174 2012-04-19 20:33 ifcfg-lo -rw-r--r-- 1 root root 27909 2012-04-19 20:33 ifcfg.template drwxr-xr-x 2 root root 4096 2012-10-04 17:34 if-down.d/ -rw-r--r-- 1 root root 239 2012-04-19 20:33 ifroute-lo drwxr-xr-x 2 root root 4096 2012-10-04 17:34 if-up.d/ drwx------ 2 root root 4096 2010-05-05 10:04 providers/ -rw-r--r-- 1 root root 72 2012-01-12 15:16 routes -rw-r--r-- 1 root root 26 2012-01-12 15:16 routes.YaST2save drwxr-xr-x 2 root root 4096 2012-10-04 17:34 scripts/
The first important files are ifcfg-eth* files. Each of them corresponds to an installed Ethernet interface. In suse 10 they used to have suffixes equal to MAC addresses, but this unique to Suse arrangement was dropped in Suse 11.
Each ifcfg-eth* file contains a set of variables, one variable in the line. For example:
BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='10.101.105.9/24' MTU='' NAME='NetXtreme II BCM5709 Gigabit Ethernet' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no'
Each interface has to have an IP address. This address is stored in IPADDR variable.
All the SUSE system scripts use the ip command for network configuration. Most modern version of Suse (10 SP3 and 11) (with kernel > 2.6.17) support frames larger than 1500 bytes. Jumbo frames might be useful for reducing CPU load but whether the game worth the candles can be determined only by measurements. A properly setup gigabit host should see better file transfer rates (by a small percentage) on a jumbo frames enabled host and router (router should be able to accept jumbo frames too and need to be configured this way). If you are not starved for CPU on you server you probably can ignore their existence. Jumbo frames might make sense for high bandwidth, high latency connections (WAN links), but for the local LAN they are less attractive (see proper way to introduce jumbo frames into lan).
If you are adventitious you can try experiment with frame size just for fun. You need to have a gigabit or 10 gigabit NIC with sophisticated driver for example Intel driver (see Documentation) that supports such frames. You also need jumbo-frames clean switch (such as Cisco Catalyst 4000/4500 Switches with Supervisor III or Supervisor IV ). Upper limit is 9000 bytes (jumbo frames). They make sense only between hosts with high latency, so never do it on your local gigabit LAN. You will get a lot of headache with little (or no) return on investment. But WAN connections(site-to-site) can benefit from this setup. Set the following configuration directive, which specifies the size of the frame in bytes:
MTU='9000'
Close and save the file. Restart the Interface eth0:
/etc/init.d/networking restart
To confirm the MTU used between two specific devices. use ip command as follows:
ip route get {IP-address}
You can also specify this parameter in ifconfig command:
ifconfig eth0 mtu 9000
This setting is not saved across reboots.
Virtual interfaces are typically used for Web or ftp sites, so that each customer has its own IP address despite limited number of read Ethernet interfaces on the server.
A virtual interface involves assigning more than one IP address to a real interface. You simply take
one existing interface (which has to be real) and let it "listen" to additional IP addresses. This way,
you can configure your Web server can distinguish between traffic directed to these different IPs and
point the requests to separate document trees, depending on the IP address the request went to.
In Linux, virtual interfaces are specified by adding a colon (:)
and a number to the device name of the real interface. For example,
eth0:1 for the second address, eth0:2 for the third,
and so on. Nothing else is needed. You can use these devices just as you'd use any real device.. You
must set up the real device (in this case, eth0) before setting up the virtual interfaces. Here
is an example from SLES 10:
BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='10.29.129.8' IPADDR1='10.29.129.13' IPADDR2='10.29.129.17' MTU='' NAME='Broadcom NetXtreme II BCM5708 Gigabit Ethernet' NETMASK='255.255.255.0' NETMASK1='255.255.255.0' NETMASK2='255.255.255.0' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' UNIQUE='rBUF.swy66v437tA' USERCONTROL='no' _nm_name='bus-pci-0000:07:00.0'Virtual interfaces are also useful if your network is set up in such a way that different subnets share one network segment, and you like to have your host be part of both (or all) subnets. The conventional method requires that you have a separate Ethernet card for each subnet you want to participate, even if they run on the same wire. With the virtual interface option, you can configure one card to listen to each subnet by assigning it one address for each subnet. It's even possible to set this up for routing, or to masquerade from one subnet to the other so that hosts that don't support virtual interfaces can communicate to the host of another subnet through the Linux machine.
You specify static routing using route command.
To make routing entries permanent you need to put them into a static table of static routes that will be read on boot. It is stored in /etc/sysconfig/network/route file
For more information see Linux route command
/etc/sysconfig/network/ifcfg-*These are the systems's configuration files for every network interface where "*" can be the name of the inteface (eth0, eth1, lo, ppp0...), its MAC address (ex: 00c09f2dc8a4) or indicate what hardware is used (usb, pcmcia).
The main parameters used in these files are:
BOOTPROTO - Can be static (IP configured manually), dhcp (IP oubtained through DHCP)IPADDR BROADCAST NETMASK NETWORK - Define typical IP parameters: IP address, broadcast, netmask and network address
MTU - Defines the Maximum Transfer Unit (the size of every IP packet). Default on ethernet devices is 1500.
STARTMODE - Indicates the to activate the interface: onboot (at system's boot), hotplug (when a pluggable network device is inserted), manual (manually).
Other parameters can be used and can vary according to the interface type.
These files contain the hardware configurations of network cards and other devices. They contain
the needed parameters, such as the kernel module, start mode, and script associations. Refer to
the manual page of hwup for details. Regardless of the existing hardware, the hwcfg-static-* configurations
are applied when coldplug is started.
/etc/sysconfig/network/config Contains various, well commented, variables that
are applied to every interface, they include also what actions can be done when the interface status
is changed.
/etc/sysconfig/network/dhcp, similarly, sets parameters related to dhcp use (logging,
lease time, timouts, modification of system's settings, wait time at boot and so on).
/etc/sysconfig/network/wireless sets and describes the various parameters that
can be applied to wireless devices (wieless mode, essid, frequency, sensibility, encryption key...).
As usual they can be used in the ifcfg files of the single wireless devices, but it's useful to
know the options than can be used.
/etc/sysconfig/network/routes Defines generic (same for all interfaces) static
routes. It's possible to specify routes exclusively related particular interfaces using files
/etc/sysconfig/network/ifroute-interface.The format of this file is:
DESTINATION GATEWAY NETMASK|PREFIX INTERFACE [TYPE] [OPTIONS]
/etc/resolv.conf Defines, as in most Unixes, the address of one of several DNS
servers to be used by the system and list of domain used to append to unqualified names (keyword
search)Multiple domain names can be specified in serach statement. When resolving a name that is not fully qualified, an attempt is made to generate one by attaching the individual search entries.
Some services, like pppd (wvdial), ipppd (isdn), dhcp (dhcpcd and dhclient), pcmcia, and hotplug, modify the file /etc/resolv.conf by means of the script modify_resolvconf.
If the file /etc/resolv.conf has been temporarily modified by this script, it contains a predefined comment giving information about the service that modified it, the location where the original file has been backed up, and how to turn off the automatic modification mechanism. If /etc/resolv.conf is modified several times, the file includes modifications in a nested form. These can be reverted in a clean way even if this reversal takes place in an order different from the order in which modifications were introduced. Services that may need this flexibility include isdn, pcmcia, and hotplug.
If it happens that a service was not terminated in a normal, clean way, modify_resolvconf can be used to restore the original file. Also, on system boot, a check is performed to see whether there is an uncleaned, modified resolv.conf (e.g., after a system crash), in which case the original (unmodified) resolv.conf is restored.
YaST uses the command modify_resolvconf check to find out whether resolv.conf has been modified and will subsequently warn the user that changes will be lost after restoring the file. Apart from this, YaST will not rely on modify_resolvconf, which means that the impact of changing resolv.conf through YaST is the same as that of any manual change. In both cases, changes have a permanent effect. Modifications requested by the above-mentioned services are only temporary.
/etc/hosts As in most Unixes, in this file you can statically assign IP addresses
to host names. You can also use /etc/networks for IP networks. The resolver by default
first checks this file, before querying the DNS servers in /etc/resolv.conf. This order and other
settings about how the system assigns names to resources can be changed (as in every Linux) in
/etc/host.conf (old configuration file used by libc4 and libc5 linked programs) or
/etc/nsswitch.conf (used by every recent program linked with glibc libraries).
If name server is not used all hosts to which an IP connection will be set up must be listed here. It also makes sesnce to list here critical hosts connectivity to which needs to be preserved if DNS server is down (for example monitoring server)
/etc/HOSTNAME Contains the hostname of the system, used by various startup scripts.
Here, network names are converted to network addresses. The format is similar to that of the hosts file, except the network names precede the addresses
loopback 127.0.0.0 localnet 192.168.0.0
The introduction of the GNU C Library 2.0 was accompanied by the introduction of the “Name Service Switch” (NSS). Refer to man 5 nsswitch.conf and The GNU C Library Reference Manual for details.
The order for queries is defined in the file /etc/nsswitch.conf. Comments are allowed and start with # sign.
passwd: compat group: compat hosts: files dns networks: files dns services: db files protocols: db files netgroup: files automount: files nis
The “databases” available over NSS are listed below
Databases Available via /etc/nsswitch.conf
| aliases | Mail aliases implemented by sendmail; see man 5 aliases. |
| ethers | Ethernet addresses. |
| group | For user groups, used by getgrent. See also the man page for group. |
| hosts | For host names and IP addresses, used by gethostbyname and similar functions. |
| netgroup | Valid host and user lists in the network for the purpose of controlling access permissions; see man 5 netgroup. |
| networks | Network names and addresses, used by getnetent. |
| passwd | User passwords, used by getpwent; see man 5 passwd. |
| protocols | Network protocols, used by getprotoent; see man 5 protocols. |
| rpc | Remote procedure call names and addresses, used by getrpcbyname and similar functions. |
| services | Network services, used by getservent. |
| shadow | Shadow passwords of users, used by getspnam; see man 5 shadow. |
Configuration Options for NSS “Databases”
| files | directly access files, for example, /etc/aliases |
| db | access via a database |
| nis | NIS |
| dns | can only be used as an extension for hosts and networks |
| compat | can only be used as an extension for passwd, shadow, and group |
This file is used to configure nscd (name service cache daemon). See man 8 nscd and man 5 nscd.conf. By default, the system entries of passwd and groups are cached by nscd. hosts is not cached by default, because the mechanism in nscd to cache hosts causes the local system to be unable to trust forward and reverse lookup checks. Instead of asking nscd to cache names, set up a caching DNS server.
If the caching for passwd is activated, it usually takes about fifteen seconds until a newly added local user is recognized. Reduce this waiting time by restarting nscd with the command rcnscd restart.
SuSE features GNU variants of standard network utilities ifconfig, route, netstat. Several
linux specific commands like ip, ifstatus are also installed by
default.
Status of network daemon can be displayed of changed with the service. To register init script you ca use chkconfig script. command. Here is the list of useful commands:
Apart from the configuration files described above, there are also various scripts that load the network programs while the machine is booting. These are started as soon as the system is switched to one of the multiuser runlevels
Some networking start-up scripts
| /etc/init.d/network | the configuration of the network hardware and software when the system is booted. Restaring this script lean to rereading of all network-related configuration files. |
| /etc/init.d/inetd | Starts xinetd. Used only if there are xinetd services for example telnet. |
| /etc/init.d/portmap | Starts the portmapper needed for the RPC server, such as an NFS server. |
| /etc/init.d/nfsserver | Starts the NFS server. |
| /etc/init.d/sendmail | Controls the sendmail process. Postfix is default in Suse 10 |
| /etc/init.d/ypserv | Starts the NIS server. |
| /etc/init.d/ypbind | Starts the NIS client. |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
... ... ...
Changing the MTU size with ifconfig command
In order to change the MTU size, use /sbin/ifconfig command as follows:
ifconfig ${Interface} mtu ${SIZE} up ifconfig eth1 mtu 9000 upNote this will only work if supported by both the network interface card and the network components such as switch.
Changing the MTU size permanently under CentOS / RHEL / Fedora Linux
Edit /etc/sysconfig/network-scripts/ifcfg-eth0, enter
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
Add MTU, settings:
MTU="9000"
Save and close the file. Restart networking:
# service network restart
... ... ...
|
|
|
The routing table is set up in SUSE LINUX via the configuration files /etc/sysconfig/network/routes and /etc/sysconfig/neroute-*. All the static routes required by the various system tasks can be entered in the /etc/sysconfig/network/routes file: routes to a host, routes to a host via a gateway, and routes to a network. For each interface that needs individual routing, define an additional configuration file: /etc/sysconfig/network/ifroute-*. Replace * with the name of the interface. The entries in the routing configuration files look like this:
DESTINATION GATEWAY NETMASK INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION GATEWAY PREFIXLEN INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION/PREFIXLEN GATEWAY - INTERFACE [ TYPE ] [ OPTIONS ]To omit GATEWAY, NETMASK, PREFIXLEN, or INTERFACE, write - instead. The entries TYPE and OPTIONS may just be omitted.
- The route's destination is in the first column. This column may contain the IP address of a network or host or, in the case of reachable name servers, the fully qualified network or host name.
- The second column contains the default gateway or a gateway through which a host or a network can be accessed.
- The third column contains the netmask for networks or hosts behind a gateway. The mask is 255.255.255.255, for example, for a host behind a gateway.
- The last column is only relevant for networks connected to the local host such as loopback, ethernet, ISDN, PPP, and dummy device. The device name must be entered here.
The following scripts in the directory /etc/sysconfig/network/scripts/ assist with the handling of routes:
- ifup-route
- for setting up a route
- ifdown-route
- for disabling a route
- ifstatus-route
- for checking the status of the routes
|
|
|
Setting up static routing192.168.0.0 0.0.0.0 255.255.255.128 eth0 default 192.168.0.1This routing table is typical for a simple network host. It could be any host in Network A from Figure 9-2. As you can see, comment lines start with a hash sign (#) in the first column. Comment lines and empty lines are ignored when the route script sets up the kernel routing table.
The other lines represent routing table entries. The format is very close to the output of the route command, as we demonstrate in Chapter 9.
The first column specifies a destination. This can be either a network address, a host address, or the string default for the default gateway. Whether the given address is a host or a network is determined by the netmask given in the third column. The network mask for a host is always 255.255.255.255. Everything else specifies a network route. Network route means a route to a network, whereas a host route is a route to a single host. The second column gives either the IP address of the router, which should be used to reach the destination given in the first column, or the special value 0.0.0.0, which means that all traffic headed to the destination will be given to1 the device specified in the last column. If a gateway address is given, the device specification is optional.
To clearly illustrate this, we refer back to Figure 9-2 and have a look at the entries of the routing tables of the hosts and routers in this network.
Hosts in Network A These hosts use the table shown above. They can reach the subnet 192.168.0.0/25 directly over their ethernet card, and send everything else to Router A/B at 192.168.0.1.
Hosts in Network B Here we have two routers, Router A/B for traffic to Network A, and Router B/C for everything else:
# route to local subnet 'Network B' 192.168.0.128 0.0.0.0 255.255.255.128 eth0 # route to 'Network A' 192.168.0.0 192.168.0.130 255.255.255.128 # default gateway is 'Router B/C' default 192.168.0.129This example illustrates a very important point. All router addresses must be within a network that can be reached directly through an interface of this machine. This seems to be pretty obvious, because how should a host send packages to a router if it is not in the same network segment? And yet, this is a common mistake that is made when one is setting up routing tables. The address used for Router A/B must be 192.168.0.130 and not 192.168.0.1, because the latter one is not part of this subnet.
Hosts in Network C Same situation as in Network A. One router gets all the traffic not destined to the local subnet:
# route to local subnet 'Network C' 192.168.1.0 0.0.0.0 255.255.255.0 eth0 # default router is 'Router B/C'default 192.168.1.1Router A/B This machine is directly connected to two subnets and forwards all traffic destined to Router B/C:
# route to 'Network A' (local) 192.168.0.0 0.0.0.0 255.255.255.128 eth0 # route to 'Network B' (local) 192.168.0.128 0.0.0.0 255.255.255.128 eth1 # default gateway is 'Router B/C' default 192.168.0.129Router B/C This machine is your connection to the Internet. We assume that it uses an ISDN link (which also is a point-to-point connection) to some router located at the ISP. As we stated previously, this router has the IP address 204.179.13.1. So besides setting up the routes for the local environment, you need to set up a route to this machine and then you can use this machine as the default gateway:
# route to 'Network C' (local) 192.168.1.0 0.0.0.0 255.255.255.0 eth1 # route to 'Network B' (local) 192.168.0.128 0.0.0.0 255.255.255.128 eth0 # route to 'Network A' (via 'Router A/B') 192.168.0.0 192.168.0.130 255.255.255.128 # route to ISP router 204.179.13.1 0.0.0.0 255.255.255.255 isdn0 # default router is ISP's machine default 204.179.13.1Again you can see that you first need a route to the default gateway before you can use it as a hop to other hosts. Because the ISDN connection is point-to-point, this route is a host route. The netmask for a route to a single host is 255.255.255.255, which means that all bits of the netmask are set. There are no bits left to distinguish between different hosts in this address because it points to only one machine.
The basic principle of routing is to forward packages not destined to a local subnet to another router which knows how handle them. The example shown doesn't reflect this strategy, that is, the hosts in Network B could send all packages that don't go to machines in the same subnet to Router B/C. This router knows that traffic for Network A has to go to Router A/B. So why do you need the extra entry in the routing table for Network A? Well, you don't really need it; the setup would work without it. As soon as a host from Network B sends packages for a host in Network A to Router B/C (you still know what's going on?), it would get an ICMP redirect from Router B/C that tells it to send those traffic directly to Router A/B.
|
|
|
Jul 12, 2007 | nixcraft.com
Changing your Network Interface Speed, Duplex or Auto Negotiate settings on Suse Enterprise Linux server.
1 # Login as root user
2 # Change directory to /etc/sysconfig/network/scripts
Code:
cd /etc/sysconfig/network/scripts3 # Create a file called eth0-setup
Code:
vi eth0-setup4 # Set eth0 to 100 duplex full, add following config line:
Code:
#!/bin/sh /usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off5 # Softlink /etc/sysconfig/network/scripts/eth0-setup to /etc/sysconfig/network/if-up.d
Code:
ln -s /etc/sysconfig/network/scripts/eth0-setup /etc/sysconfig/network/if-up.d6 # More information - read man page
Code:
man ethtoolAlso chk out : Linux add ethtool duplex settings to a network card permanently | nixCraft
|
|
|
I do not know when this happened - but in the last couple of releases of SuSE Linux they have taken a weird dependency on the MAC address of the network card. To be precise - once you have configured your network card under SuSE - changing it's MAC address will cause SuSE to not initialize that network card (unless you remove and reconfigure it through YAST).
This is quite painful because - as I outlined here - Virtual PC can and will change the MAC address of the virtual network card from time to time. And in my case (as I regularly move my virtual machines between Virtual PC and Virtual Server on different physical computers) the MAC address is getting changed almost constantly.
Thankfully there is a relatively easy (though not intuitive) way to solve this. What you need to do is to get to a command prompt and type in the following commands:
- cd /etc/sysconfig/network
- ls
At this stage you should see a file called 'ifcfg-eth-id-00:03:ff:xx:xx:xx' (substitute the 'xx:xx:xx' appropriately). This is the cause of the problem.
- sudo mv ifcfg-eth-id-00\:03\:ff\:xx\:xx\:xx ifcfg-eth0
Once again you should substitute the 'x's appropriatelyOnce you have done this you should be able to reboot the virtual machine and have the networking continue to work no matter what the MAC address is of the virtual network card.
Cheers,
Published Tuesday, September 06, 2005 7:46 PM by Virtual PC Guy
BenFiled under: Operating Systems under Virtual PC / Virtual Server / Hyper-V
|
|
|
Changing Hostname Temporarly
Example: hostname newhostname.comChanging Hostname Permanently
Edit the file /etc/HOSTNAME and change the value in it, Save and exit
To avoid dns errors edit the file /etc/hosts and create a line as below
192.168.1.50 newhostname alias
Change ip with your server ip and newhostname and alias with anything you have setupChanging/Setting main ip
Edit the file /etc/sysconfig/network/ifcfg-eth0 and change the value of IPADDR, NETMASK , NETWORK and BROADCAST
Example ifcfg-eth0 file:
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
IPADDR=192.168.1.50
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
USERCTL=no
PEERDNS=no
TYPE=Ethernet
Description: Dont forget to restart network after the change with below command
/sbin/rcnetwork restart
Connect again using new ip if all is well.Adding more IPs
# Copy the config file to create an alias ip
cp /etc/sysconfig/network/ifcfg-eth0 /etc/sysconfig/network/ifcfg-eth0:1
#Now edit the new file /etc/sysconfig/network/ifcfg-eth0:1 and change "DEVICE=eth0" to "DEVICE=eth0:1" and change ip to the new ip you want to assign. Save and exit. Then use tbe below command to bring it live.
/sbin/rcnetwork restart
Linux Headquarters Network Configuration Using SuSE YaST
Network Performance Fine Tuning in openSUSE & SUSE SUSE & openSUSE
SuSE HowtoForge - Linux Howtos and Tutorials
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: March 12, 2019
