:w or :wq writes the file even when nothing has been changed.
ZZ or :x only writes when there was a change.
It is better to get in the habit of using ZZ or :x only, so that file modification dates are not touched when no change was made.

It is not really required to "just save your progress" as vi does that anyway. When it (or the system) crashes you
can normally recover your file from the tempfile it creates. Writing the file is only required when you want to pick it up in
some other program but not want to leave the editor.

Esc-ZZ

Do you run it for more than a single day at a time?
I have huge memory leak problems. Admittedly, my 2GB RAM is not a real lot today, but after 10 days
of uptime there is 1.4GB of swap in use and increasing. Processes like kded4 and kdeinit4 are huge.
More memory is on the way, but at this rate it is not going to help much.

With a previous (KDE3) install I could keep the system running (and logged in) for 6-12 months without
such problems.
I read that others using KDE4 have had this problem for several years, and nothing has been done.
What gives?

Users of the internet should send traffic from their assigned address.
When they have multiple addresses they should use the address that belongs to the interface they send it on.
Either they route the traffict to the interface that belongs to an address, or they assign the source address depending
on the interface they want to route on.
Don't adhere to this rule and you face blacklisting of your traffic.

It is similar to open SMTP servers. Used to be no problem, used to be common practice, is not acceptible anymore today.

This case mentions the use of NTP, but the idea of reflection attacks by now has propagated to TCP as well, even without amplification it seems worthwile.
Right now an attack is running on many webservers that sends SYN packets with source port 80 and 443 and destination port 80 from spoofed source address.
Apparently they want to overwhelm the victim with SYN ACK packets from reflectors.
However, those are the same size as the SYN packets sent by the attackers. Probably no issue, those attacks are likely sent from compromised systems and botnets as well.

It is about time that a blacklisting system is setup for providers that allow source address spoofing, similar to how providers running open SMTP servers were tarred and feathered until they fixed it.

That is called ip spoofing. They send a request with a sender address of a victim, and the server sends the reply to the victim.
This would not be possible when the attacker's ISP would not allow source address spoofing.

"I found-out the hard way, several of my customers were sending outbound traffic with source addresses not on my network."

You should lose those customers! Really.
No-one, I repeat no-one, has business sending packets with forged source addresses.
Refer them to a book on policy routing when they don't know how to route in a multihomed enviroment.

But that is not because it hasn't advanced much. It is because first it advanced a little bit, and then it mostly died
when internet came to the homes and the novelty of packet radio was taken over by internet applications.
What is now left are only the most stubborn users, the same ones that never advanced to higher speeds.
But the usage is not more than 1% of what it was in the nineties. Relative to what is left, 1200 baud still plays a
major role. But not relative to what there was in the nineties.
(at least that is the local situation here)

She mentioned that she used a spectral analysis to deduce that this was 1200/2200 Hz FSK, well I knew that by just listening to it!
This is exactly the same sound as 1200 baud AFSK amateur packet radio made in the eighties/nineties, indeed using Bell 202 AFSK modems.
I have heard so many of those packets while seeing them scrolling by on the screen that I can sometimes hear what kind of packet it is by just listening. (of course not the exact content)
Only in this case it is async serial data, while with packet radio it was HDLC NRZI-encoded sync data. And because in packet radio there are alternating transmissions from different transmitters, you hear a characteristic "leader" pattern similar to the idle pattern in this broadcast followed by a data packet and a keydown of the transmitter.
She probably was at an advantage not knowing about this, as she did not waste time to see if it was HDLC.

Of course there were very good reasons to do things contrary to American method in color-tv!

Unfortunately it issues warnings all the time, especially for google and twitter.
They occur so often that you (or at least me) get the habit of accepting them without further checking, to be able to continue working.
This largely defeats the usefulness of this add-on.

It appears that google twitter use different certificates on different servers around the world, and you get those warnings when
the loadbalancing mechanisms direct you to another server you were using last time (for the same domain name).
Either that, or their communications are intercepted by the local security agency who acts as a man-in-the-middle.

How would you know?

Highspeed rail in the Netherlands. We have a small country, so when a highspeed rail
is constructed every city wants a stop along it, and cities are only 30km apart here.
Furthermore, when they ask me "would you take the highspeed rail to Paris" I probably
would answer yes, but it would not be more often than once every 2 years or so. Not a
basis for a regular train service.
So what we got was a highspeed rail with a surcharge, nobody using it so they had to
stop the regular service to force the users over to it. There was a special train built for
"local" service, but it had so many defects that it was removed from service and there
now is a big dispute with the manufacturer.
The problem with trains is that everything is so close here, and people who can afford
the ticket price normally can afford to travel by car and have the advantage of door-to-door
travel. E.g. the highspeed rail would be ideal for government officials to travel to Brussels,
but I'm sure they use their car-with-driver instead.

Even those ideas for mass transit that did work out are not always a success.
It appears to be difficult to predict the usage of such a network.
We got a highspeed rail line but nobody is using it. Existing connections had to
be terminated before some people forcefully started using this train (at higher tariffs).
And specially built trains that were ordered for a lower priced service were a total disaster.

I had already blocked all ads served by openx servers (by URL regexp) long before this, after a couple of bad happenings on ad sites running openx.
It apparently is an unreliable platform. This finding only proves that.
However, I also think the ad platforms should make 5 steps back to become credible and acceptable again.
An ad server should be called from some customer-specific URL on the website and then serve a JPG or PNG with the ad. Period.
All the hoopla with javascripts fetched from different places, iframes, active content (like flash) etc has made it into an unreliable
piece of junk that just asks for being blocked. When I block it, they should not blame me but blame themselves.

For some time I plotted the jitter of reception of DCF-77 (a similar transmitter in Germany) and I found there was a clear cycle of increase and
decrease of the jitter of the pulses output by my receiver (measured over one minute) over the day.
At daytime the jitter is around 20us, at nighttime it is more like 200us.
This is most likely explained by path length variations that apparently are depending on propagation.
(although texts about such transmitters often boast that there is no propagation effect like the one seen at shortware at those frequencies)

The claimed accuracy is of course at the source, and maybe when you started receiving WWVB years ago and perform some kind of averaging
over a long interval, you could eventually get an accuracy like that, but there is no way it can be achieved over short intervals, let alone for
individual second pulses.