Slashdot Mirror

• sshd / ssh access on a machine "at work" (preferably, don't use port 22)
• Install rabbit
• Tunnel the port 9666 to your browsing machine

This could be quite useful if you connect via GPRS and pay data by the megabyte... or if you're travelling to an unfriendly country and don't want unfriendly people to snoop on your browsing habbit.

Pretty centralized compared to this.

Why is this map any more controversial than any other network map?

Why... A beowulf cluster of this size

Seriously though, if the next Playstation is going to rely on distributed computing this would be the thing that makes it a reality.

Seriously, imagine p2p networks that spring up to and combine computing power to solve any math problem.

We can all build nukes! Forcast weather for the whole planet!

Imagine the cool "beowulf live" distributions that spring up - boot and enjoy holographic video (rendered on demand!)

It's not the connection speed, it's the potential to combine computer power that makes me drool.

Ok, yes this is a pretty robust setup. But how hard would it be, for example, for thirteen well co-ordinated individuals who can physically get to the locations of these servers to deliberately cause widespread disruption for everyone who relies on DNS? Or if software was the weapon of choice, how hard would it be for a group of people to DDoS the networks housing the servers?

Yes I realise these are unlikely scenarios, but my point is that there are a relatively small number of key servers which we all rely on, and as such the network (not just DNS) could be vulnerable.

I can't suggest any way you could create a truely decentralized network, I'm just saying the internet is not one. Take a look at a map; there is not one single central point, but there are some nodes which connect large portions of the network together. If enough of those were disrupted it could cause problems for quite a few people.

In any case, we've gone off topic here. I think the main point of the article is that it's a bad idea for a number of large sites to rely on one company for DNS services. With that, I think we can all agree.

As a side comment, now I understand why my connection got so slow.

[Internet Mapping Project's] mapping also takes nearly six months to generate a single map. My comment was that, "I can write a program that can map the entire net in a single day."

The Internet Mapping Project maps the Internet in under two hours (105 minutes for this morning's run). I'm not certain where the six months came from. The rate limitation is the packet rate limit we set (500 packet per second).

Map layout time is not included in that time, but that is not done on a daily basis. A map layout take about six hours, as I recall. It only took a couple weeks to produce all the layouts necessary for a movie of the Internet from Aug 1998 to Jan 2001 based on the daily runs.

CAIDA also creates daily maps of the Internet as part of their Skitter project. Their schedule varies between measurement points. In addition, other projects, such as the Mercator project and the RocketFuel projects, also map or did map the Internet.

Each project has slightly different goals. Skitter focuses on paths to major web and DNS servers. Mercator attempted to discover networks with limited pre-knowledge. RocketFuel wants a very accurate map of a particular ISP. The Internet Mapping Project is focused on the router connectivity within and between public backbones.

Here (for free)

Here too (for free)

This one too (for free)

This one also (free)

And don't forget this classic ($30 poster)

-T

Considering that the Internet has been designed to withstand atomic holocaust, it would be ludicrous to predict its death just because of some media control on the ISPs. The points made to support the claim fall down under scrutiny. They seem to apply only to a a very limited range of ignorant users (I'm not being elitist, I'm talking the "I broke my cup holder" kind):

1 - "email unusable because of spammers"
A point which ignores the simple possibility of creating filters in any modern mailer to move your "trusted" sources to a specific directory, and ignore the rest. Of course, if you keep your modem connection your downloads will be slow. Time to upgrade.

2 - Google has problems with crap content
Time to stop clicking the "I'm feeling lucky" button and browse through results. Also, it would help to use advanced tools to refine your search. Site is bad? Click back on your 4th mouse button and keep looking.

3 - Popup blocking:the vast majority of IE users don't have that luxury, and their patience has already been tested to the limit
So, they are saying that because users don't have a clue, they will stop using the Internet? Suddenly this reminds me of the survey made in the US some weeks ago...

4 - Internet means sitting at noisy and unreliable machines
Mini-ITX 500Mhz fanless motherboards, customized linux distro (locked) for reliability. Voila, safe, noiseless, reliable netbox!

And finally:

5 - What's dying is the idea that the Internet would be a tool of universal liberation
Freedom requires a minimum of effort and knowledge. You have to program that VCR to be free to see the show at a specific time.

So, in short, this article is predicting the death of the Internet for people who doesn't have a clue on how to turn on a computer and have no intention to learn it (reference to the US survey done a while back, obviously)... I'll let you draw your own conclusions.

Bonus: map of the internet :-) The Internet could live without the US. And at worst, some underground ISPs will still remain. It would be slow maybe, but it would work.

As others have mentioned, disabling accounts is significantly better than deleting them. A very good paper on the process of dealing with the termination of a system administrator is Matthew Ringel and Tom Limoncelli's Adverse Termination Procedures.

Is that ability ever utilized to any extent in legitimate, day-to-day operations?

Yes. My company, Lumeta, does scans of corporate networks, connecting to hundreds to thousands of new machines every second. Of course, if this is done at the OS-level, this is a non-issue, since we do not use connect() anyway (does not give us enough information, reactivity, or control), but rather construct packets from scratch and, regardless, we can play with the OS, since it runs on FreeBSD.

If, on the other hand, this is done on the network-level, this would cause problems, and we would have to be put on exclude lists on every router up to the corporate backbone. We balance the load across the corporation's entire IP space, but it takes a lot of divisions to get from even 100/second to 1/second.

We already run into issues where a certain router vendor has an odd "cache" that is not reaped when memory starts to become low. This would make things much worse.

Unfortunately, if this can be disabled in the OS programatically, it is useless, so the network is the obvious place to put such a restriction. Of course, now the network is retaining state about all connections going through it. Most firewalls already do this, however.

In this article I write about some of the most common mistakes that I see on resumés, and how you can avoid them.

I proofread resumés for friends... a lot. With the economy heating up I'm getting asked to more frequently. I find that technical people often have difficulty "selling" themselves. While "The Practice of System and Network Administration" (co-authored with Christine Hogan) has tips on hiring sysadmins, we didn't include specific resumé-writing tips. Therefore, I thought it might be useful to write down the thoughts I have in this area. (Our negotiation section does have tips on how to negotiate your salary, but that's putting the cart ahead of the horse.) How do employers process resumés?It's important to write your resumé to be useful from the perspective of your potential employer. In writing they say, play to your audience.

That is, an action film is expected to have an explosion or something major in the first scene, a romance is expected to introduce at least one of the main people in the first 5 minutes, Steven King always includes the elements that his fans expect. A resumé has to be written for its audience too. What are the audiences of a resumé?What makes writing a resumé difficult is that there are two audiences.

First is the non-technical HR clerk that receives the resumé. If it gets past the clerk, it will arrive at the desk of the person that will be your future boss. Your resumé has to have the elements that will please both of these people: The HR clerk The first person to see your resumé, sadly, is a non-technical clerk who is handed 10,000 resumés a day and a list of positions that need to be filled. This person does the first level of sorting. Your job is to make sure you get through this person's selection criteria. The problem here is that this person doesn't know the difference between UNIX and Solaris, or that if someone knows Solaris 2.5 then they are hirable for a Solaris 2.6 job. Luckily, this person only reads the top part of every resumé, so you make make sure that you have "Objective" and "Skills" sections made just for him/her. Don't say "Solaris 2.6", say "Solaris 2.x" or just "Solaris" (people have forgotten about Solaris 1.x by now).

The Hiring Manager Each pile that the clerk created is handed to an appropriate "Hiring Manager." This person does understand the technology that you'll be working with, or at least they think they do. The rest of the resumé must be in their language. The most common mistake that I see is that people don't write anything for the clerk. Therefore, their resumé never gets to the hiring manager.

The "Objective Statement" and "Skills" section at the top of your resumé is what the clerk reads. Make sure your resumé has these sections and make them clear. Typically I see resumés without an "Objective Statement" at all! Tip 1: A good "Objective" statementA good objective statement tells a plainly-stated title you would like ("UNIX programmer", "CGI Developer", "Project Manager", etc.) and a couple skills that you have ("excellent writing skills", "experience with digital audio technology", "experience with large development projects", etc).

If you aren't sure what your title is called, look at a couple job advertising web sites to fill you in.

You can also specify what industry or department you want to be in ("financial services", "telecommunication", ".COM", etc.).

Here are some good ones that I've seen:

1. Objective: A position as a Senior UNIX/Linux Developer that lets me utilize my years of experience in the TDM cellular technology.
2. Objective: A position as a Project Manager in the EDA industry that lets me utilize my excellent communication and presentation skills.
3. Objective: A position as a Junior UNIX/Solaris Sysadmin (SAGE Level II) in the financial services industry that lets me utilize my superior Solaris knowledge.
4. Objective: An entry-level position as a HP-UX/UNIX Sysadmin that enables me to demonstrate my ability to learn on the job.

• Objective: I am an expert in building large, scalable services based on open protocols.

How could the clerk classify such a resumé?

A better statement would have been: "A senior architect of UNIX-based email and web services that lets me utilize my experience in building extremely scalable systems with high up-times." He did change his resumé to something similar, and soon started getting phone calls. Tip 2: A good "Skills" sectionUse buzzwords. There is a reason for them, it makes communication faster. I hate "buzzword compliant" presentations, but only when they aren't adding any value to the statement. When they appear on a resumé they do add value because the clerk undestands them. Better-trained clerks are given a list of synonyms. For example: they might be told "We need a Solaris sysadmin... but that means anyone that mentions Sun, SunOS, or UNIX should be considered. Oh, other synonyms for UNIX are: AIX, Linux, IRIX... a person that knows any of those but wants to learn Solaris is fine for this position." However, that doesn't always happen so it is ok to be a little redundent: I include the word UNIX in addition to the name the vendor uses (i.e. "Solaris/UNIX" or "Red Hat/Linux/UNIX").

List the best skills first. I see many "skills" sections that list 20 operating systems or 20 languages or 20 vendors and that's a fine way to show that you have a lot of experience over many years. However, the person reading your resumé is only going to read the first 3-4, so make sure those are the ones you want to work in.

A friend listed the languages she knew in the order she learned them. Which of the these two would a clerk find most useful if he/she was told to find a "Windows C++ programmer"?

BASIC, Pascal, C-64 BASIC, AppleBasic, Cobal, Fortran, C, awk, C++, Visual C++, Perl

Perl, Visual C++, C++, awk, C, Fortran, Cobal, AppleBasic, C-64 Basic, Pascal, BASIC.

While I'm at it, I believe one should delete the super-old technologies like Commodore 64 and Apple II unless, of course, you are applying to work someplace that still uses those technologies.

A concise way to list skills is to group them. The first example below is the most concise, the others are longer.

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, and others.

Here are some other good examples of "Skills" listings that I've seen:

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, Cisco IOS 7.x-12.x, plus some experience with AIX, HP-UX, OpenVMS, NetBSD, OpenBSD and others.

Programming Languages: Perl/CGI/mod_perl, C/C++, HTML, Unix shells and tools, awk/sed, SQL, Python, Pascal, BASIC.

Network Products: Cisco Routers, Cisco Switches, Cisco PIX Firewalls and Cisco IP Telephony equipment (ICS7750); Checkpoint FW-1; Linux/Unix firewalls (IPFilter, IPFW); Avaya Cajun products; Network General Sniffer, tcpdump, Ethereal, Snort.

Network Technologies: FastEthernet, Gigabit Ethernet, FDDI, OSPF, BGP, ATM.

Tip 3: ClassificationsIf you are a sysadmin, use the SAGE Job Classifications to describe yourself and/or the position you are looking for. More and more HR departments are using them, and certainly the cool companies that you want to work for are using them. However, explain enough so that someone that hasn't read http://sageweb.sage.org/resources/publications/8_j obs/ will understand what you mean. That's why the above example was redundant: "a Junior UNIX/Solaris Sysadmin (SAGE Level II)". Tip 4: Pick a good filenameNever use a filename like resume.doc when sending your resumé as an attachment. Name the file something like resume_tom_limoncelli.doc so that if the HR person saves it, he or she will be able to easily tell yours from someone else's...and your resumé won't be overwritten the next time someone else sends them a file called resume.doc. (Thanks to my friend Tina for this tip.) ConclusionA good resumé is your key to finding a new job. However, you'll never find a job if your resumé doesn't reach the right people. Making your "Objective" and "Skills" sections complete and accurate is how you make sure it reaches the right people. Tom Limoncelli is co-author of The Practice of System and Network Administration with Christine Hogan, Director of Network Operations at Lumeta Corp. and maintains www.EverythingSysadmin.com. He can be reached at talsagewire@whatexit.org.

http://www.lumeta.com/ We help by performing a scan of your network and show you the holes in it. If you're familiar with the Internet Mapping Project, and Bill Cheswick, then you'll have a good idea of some of the stuff we do here.

It's also interesting to check how the internet have expanded just over some years, thinkgeek has some cool maps over how internet looked in the years 1999, 2000 and also for the year 2001. These are graphs of how the Internet might look if you were a packet of data that were sent thru the bulk of the Internet infrastructure.

Also read more about the company Lumeta that has a long-term research project to collect routing data on the Internet, it's called The Internet Mapping Project. They have some information there about how it is done too.

It's also interesting to check how the internet have expanded just over some years, thinkgeek has some cool maps over how internet looked in the years 1999, 2000 and also for the year 2001. These are graphs of how the Internet might look if you were a packet of data that were sent thru the bulk of the Internet infrastructure.

Also read more about the company Lumeta that has a long-term research project to collect routing data on the Internet, it's called The Internet Mapping Project. They have some information there about how it is done too.

It doesn't allow you to pick the host, and it's only a subset of the Internet (since otherwise the rendering is slow and not very pretty), but this VRML file does show the 'Internet as it looks to a packet.' (the moving viewpoint may not be the default one).

Actually, it's
http://research.lumeta.com/ches/map/index.html