/*
This Code Snippet shows shadowing an Instance Variable by declaring a local variable of the same name either directly or in the argument
*/

class Person
{

static int age=20;
static void adjustAge(int age)
{

age=age+20;
System.out.println("The Age in adjustAge() is "+ age);

}
public static void main(String[] args)
{

Person p = new Person();
System.out.println("Age is: " +age);
adjustAge(age);
System.out.println("Adjusted Age is: " +age);

}

}

The above code snippet is trying to change the age of the person, adding 20 to the existing age, which is done by the static method adjustAge(). So what will be the output? Any Gusses?

Output:

Age is: 20
The Age in adjustAge() is 40
Adjusted Age is:20

Code Demystified:

The line in the code which is bold and read in color is the main culprit i.e "age=age+20;". Can anyone guess what is the line exactly doing? It is actually updating the local variable "age" and not the instance variable "age", i.e the instance variable is shadowed by the Local Variable. And the scope of the Local Variable is the block of code in which it is declared. So, the last Print Statement actually access the unchanged instance variable "age". Shadowing can also involve object references, in which case it becomes even more interesting to deal with.

For people preparing for SCJP, you can expect few questions on Shadowing.

Just a quick recap in case someone was too much in a choma to look at those links:

1) Get a recorded text.

2) Put it on your mp3-player.

3) Listen to it WHILE repeating what the person says. At the same time or as best you can.

4) Walk fast and talk loudly, don't sit still and mumble.

Of course, it helps tremendously to know the text by heart first ;)

I'm kind of guessing this does wonders for your intonation!

I've noticed that when I ride my bicycle to work, I listen more attentively to the songs/texts on my iPod than when I take the tram. I only dare listen to music in the morning though, when I'm practically alone on the road. In the afternoon the cruel car drivers of Oslo will just run me down if I don't respectfully stay on my 20 cm of allocated space. >:[

Now, the Scriptorium. Look here. Speak, write + speak, speak. Focus. I like this technique as well, even though it does get a bit tedious. However, when you only write down something, you do tend to rush it. Unless you're an extreme beginner, cause then you have to look at every letter of the word ;) With Russian I tend to rush it. Trying to slow down now, to get it to enter my brain and perhaps... stay there? I did this for Мошенники поневоле yesterday, and I'm going to listen to the audio five times now. Yes, you heard me.

And oh! Do note that I would never have discovered these things without the excellent Forum, which now has a Wiki (unofficial, I know) attached to it!

• What is the average salary for someone running an assisted-living center?
• Do you have any books about running a non-profit?
• I want to learn more about starting a co-op.
• Do you have any Boxcar Children books?
• I need non-fiction books about hunting ghosts.
• I'm looking for plays I could do with a group of 3rd graders.

I paid attention to how Pamela and the other librarians handled these and other questions so that I can start answering questions in the near future. The library was super busy, so I felt a little guilty standing around while people waited in line for help. Pamela picked up on how this might look (i.e., like I'm lazy) and told a staff member that I wasn't really "there" I was just shadowing. This turned into quite the joke. Now, I'm officially The Shadow. Doesn't this look just like me:

Mr Daniel
Thank You
Charleston Parks and Recreation

Dear Mr Daniel:
Thank you for allowing to shadow you at Charleston County Parks enjoy meeting with you and learning about your position as a James Island office/campground. I understand that your responsibilities include answering phones and making reservations.

During my shadowing experience, I learned: that u have to have a good attitude, and a good personality. I need to develop my skills in the following areas to be successful in this career fields: Nursing.

I would like to continue studying in this field because it is what I need.

Name of Student

Again, I'm not lying. However, it is hard working being an office/campground at the same time.

And I feel I need to explain the final sentence of the second paragraph. This was the girl who thought that Hospitality dealt with Hospitals. That's all I'm going to say about that.

I also liked the header for the letter. Classy.

There are some out there who would like for you to believe that Linux is unsafe. What better way to instill fear than to form doubt in your mind about a system's abilities to protect your data?

A reason for the supposed lack of security often cited in FUD is the origin and maintenance of Linux in the “hacker” community. The term “hacker” has evolved from a term of endearment to one associated almost exclusively with cybercrime. To say that Linux was created and is supported by hackers gives the impression that the OS and its related applications are riddled with built-in security holes, backdoors for gaining system access, spyware for purposes of identity theft, hidden network tools that help intruders cover their footprints as they travel from machine to machine through cyberspace, and any other sort of malicious software for various and sundry purposes. To “hack” no longer means to “tinker” or to “fiddle with”, but to “break into” and “cause harm”. The term may conjure mental images of a scene from a horror movie, an evil man with an axe about to hack his way through the door to the house protected by the dark of night. Such is the imagery used to spawn fear.

Let's examine Linux security by answering two questions. Do security components exist? And, can they be trusted?

The components required to make a system secure depends on many factors, because different systems are used in different ways by different people. Moreover, a weakness in a system's security may be mitigated by strengths in some other compensating controls. There are some basic options that are commonly used to secure systems, all of which are available on Linux.

Password protected login is the hallmark form of authentication. It is easy to implement, easy to use, can be highly effective, doesn't require additional/expensive hardware and the expectations and conventions surrounding it are already present in modern culture. Sure, there are more advanced biometric devices such as palm readers and retina scanners, but the relative cost in money and effort of implementing these safeguards for the average home user and for most business desktops is prohibitively high. There are two aspects to password security: the strength of the password itself, and the authentication scheme behind it. Password strength is the responsibility of the user, not the OS. Most Linux distros either require password protection or at least have it enabled by default. Usually, the passwords are protected on the local system by shadowing and various schemes such as Kerberos can be used to protect the transmission of login information over a network.

Related to password authentication is the file system permissions granted to users once they've logged in. Linux and Unix use file-based permissions, denoting how the owner, members of the owner's primary work group and the “world” of users on the system can interact with each file or directory. Privileges do not cascade as they do with other operating systems that use Access Control Lists.

Network security is a broad topic encompassing the combined abilities of the OS, applications, network devices, administrators and users to detect and/or prevent a breach attempted across a network connection. A basic way to accomplish this is to disallow certain types of messages from reaching the computer; this function is usually performed by a firewall server or program that monitors network traffic and filters communications based on predefined rules. Every computer that communicates over the Internet uses the TCP protocol, which allows for approximately 65,000 possible “ports”. These ports are similar to radio stations or TV channels; each application that needs to communicate does so using one port. Ports that are not used by an application but are still available for use (“open”) can be exploited. Port scans are a good way to determine if a system has any open ports that are not being used. Firewall capabilities are built into the Linux Kernel and several good front-end packages are available for configuration, monitoring and reporting purposes.

All of the safeguards discussed above constitute protection around the data. What about protection of the data? A data file can be encrypted thereby changing the contents to an encoded, unreadable format. The content is usually restored using a key or a password. E-mail can also be encrypted prior to transmission. GNU Privacy Guard (GPG) is a Pretty Good Privacy (PGP) compliant application that implements public key cryptography on multiple OS platforms, including Linux. Of course, constantly having to decrypt and encrypt every individual data file before and after use would be painful; instead, entire file systems can be encrypted by the system and several cryptographic file systems exist for Linux. It is also possible to create a loopback device, which is a file that can be mounted as an encrypted file system similar to the commercial product Cryptainer LE by Cypherix.

So, the components do exist. Now, the question remains, can these components be trusted?

FUDsters will argue that any security software for which the source code is freely available to the public is inherently not secure. This is based on the assumption that the source code will either reveal the secret functionality that makes the security software work or expose bugs in the security software itself that can be exploited as well.

First, if someone cannot open their source because they are afraid it may reveal secret functionality, then it wasn't properly designed from the start. The worst-possible example of this is hardcoding passwords in programs, especially if they are scripts stored in clear text. Good security schemes, such as encryption, rely directly on information the user provides, and often make use of one-way functions.

Second, Open Source software is available for public scrutiny. If you cannot read and understand the code yourself, rest assured that there are many folks out there that can and do. Why? Because many businesses do actually use Open Source software and have everything to lose if they don't test it out first. That being said, I consider many corporate “testimonials” sponsoring one OS or another based on security or other factors to be FUD, mainly because they often appear in paid advertisements and seldom reveal the details of tests performed to lead to such conclusions. Independent certification and research performed by government or other nonprofit entities are usually the most objective and reliable.

Aside from learning the code, another way to test an application's security strength or to see if it transmits private data is to watch (or “sniff”) the port on which it communicates using a network monitoring tool. Such data may be encrypted, but the (data) size and timing of requests made by the client software should be consistent and reasonable. This is a technical task, but a bit easier than learning how the code works. Just remember, sniffing outside of your own network may be considered illegal.

Finally, there are many Linux opponents that would jump at the chance to expose real security weaknesses in Linux and its applications. These are often vendors of competing software and have both the money and channels to make themselves heard. When such a claim appears on the Web, look for specific details about the vulnerability. If there are none, it may be FUD. Also, check the software website to see if the vulnerability has been acknowledged or refuted as well as any status on its repair. Never take such claims at face value.

Here's a few tips to remember to help protect yourself.

Any security expert worth his salt will tell you that physical security is the most important aspect of system security. If physical access to a computer is available, then it is usually just a matter of time before the system will be compromised, regardless of operating system. Obviously, the probability of such breaches skyrockets for laptop users, especially when so few (based on my own observations) choose to utilize even the most primitive of safeguards, cable locks. Also, I've not seen any major headlines on this so far, but Live CDs, as wonderfully useful as they can be, are ginormous threats to the security if physical access is available. This is because most Live CDs provide superuser access to a system and all of its devices. It is best to keep computers under lock & key whenever possible.

One of my friends from university used to work in an engineering lab on campus. He had set up a Linux box on the network, with full consent of the administrators of course. But one of the the permanent staff members approached him one day, asking how he managed to cloak his machine from the nightly SATAN network scans. The answer was simple! He turned the machine off before he left each day! Turning a machine off or at least disconnecting it from the Internet when not in use will deprive the would-be attacker the time needed to successfully break in using a brute force attack.

And, as always, be careful what you download. There is always a chance that someone will write spyware or malware for Linux. Stick with applications that have large communities and good reputations if you can. Search the Internet for evidence that an app may not be secure before downloading it. To quote the the Gipper, “trust, but verify”.

Cheers!
-Brandon