So, how about your safety deposit box at the bank?

They can't just search that...

I liked the connection manager on windows XP, too.

It would let you set up profiles to turn off your firewall on certain networks, start printer sharing, and start file sharing.

It also let you setup static IP's VPNs, etc on certain networks....

Uhhh...dude. I run yum on my intranet. My yum repository is on my intranet.....The machines arn't pulling updates straight off the internet. Do you even understand what's going on here?

yum is very simple and there is a man/info page on it.

Installing a lamp stack is easy, and future yum updates will patch the entire stack. That being said, I'm assuming you're running an exernally facing lamp stack. What's your patch story? How are you getting your security fixes?

In my specific deployment, I drop packages on an http server, and I have yum clients running on a few hundred systems (I find these packages with a simple mirroring command rsync -avz rsync://mirrors.kernel.org/fedora/......). After I test the updates, I put them in a repository that all the systems know about. All of these systems poll my repository for updates every 2 hours, and autoinstall/patch.

As a standalone dev box, I'd assume you'd be running a gui, and fedora will automatically show you popup notifications to update, as a massive deployment, you can do something like I do (or pay for an up2date subscription, if you choose that route...).

I believe that the only problem you have is a refusal to any research/browsing whatsoever, and you are blaming your misunderstandings on the operating system.

"Most" users use intel integrated graphics (probably especially the ones that don't actually care about graphics)....

Most people I know (I'm not going to talk about "Most people") end up downloading the drivers directly from the nVidia site when they are using windows.

When I'm on linux I never download the drivers from the nvidia site, I use rpm fusion (for fedora).

I would say that most linux users probably do this for one important reason: A part of the nvidia driver has to be compiled to the specific kernel version that you are running (uname -r), if you update your system, and you don't compile a new copy of the driver, you will lose all accelerated graphics support....It's a pain.

If you use a package repository, your kernel will be held at the supported version for the nvidia driver, until the nvidia driver gets recompiled against your kernel. The people over at rpmfusion are pretty fast about doing this, so, you end up getting your kenel updates delayed by a few hours, in the same day.

Right before all the distributions started switching to PulseAudio, I remember thinking about how alsa was becoming stable (and "the" audio standard), and I wasn't seeing anyone with sound issues anymore.

Granted, alsa alone isn't as versatile as pulseaudio, but there is value in sticking to a 'pretty good' solution, even if it might not be the best.

An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png

Actually:
http://digg.com/odd_stuff/Huge_Cannon_Fires_Pumpkins_at_600_MPH_VIDEO

It hit the top of digg yesterday ;-) .

http://www.pettingers.org/code/sshblack.html

or, what I use in my workplace (execute via an init script/or add to /etc/rc.d/rc.local):

# create new chain "SSHRULES"
# if packet is NEW, coming in on eth0, on port 22 apply rules in "SSHRULES"
#
# SSHRULES:
# if is on our subnet, accept the connection, stop reading the chain
# record a connection attempt
# if has more than 2 connection attempts in the last 7 seconds, reject

iptables -N SSHRULES

#insert at the top of the "INPUT" chain
iptables -I INPUT 1 -p tcp -i eth0 -m state --state NEW --dport 22 -j SSHRULES

iptables -A SSHRULES -m iprange --src-range 129.65.0.0-129.65.255.255 -j ACCEPT
iptables -A SSHRULES -m recent --update --hitcount 2 --seconds 7 -j REJECT
iptables -A SSHRULES -m recent --set -j ACCEPT

I've seen stuff like this a bunch of times, and I've collected the data/tools that I have found on our infected systems, in my university department. For us, it seems like the main angle of attack is ssh, where our servers get hammered several times per second. Often, when we give students root access to some of these systems, they tend to make users like test/test, and in a matter of days, the computers are scanning large subnets looking for other systems to compromise. There is nothing new or first about these attacks.

I have written scripts for my job, which would break dns was hijacked by my isp. It's not acceptable.

I added a stub section to an article on wikipedia about this a while ago, it would be great if someone would lengthen it ;-)

http://en.wikipedia.org/wiki/DNS_hijacking#Use_by_ISPs

Actually, thats incorrects, Here's why:

When you calculate IOPS, a good portion small of reads and writes get executed at random places on the disks. When you you make one filesystem write on a raid0 set (depending on how smart the raid0 controller is), it will be locking up several or ALL the disk spindles for that individual read/write.

The IOPS are negligibly better on a 33 disk raid0 set, and depending on your disk controller, it might be worse (every write equates to 33 dma requests).

It is faster for reading large files though, but that is NOT what a fair IOPS test measures.

For read operations, you can double your read IOPS by using a mirror. This is because ony semi decent controller will split all the read requests between the drives in the mirror. When your issuing lots of read requests from several threads, the load should be approximately equal across the drives.

Welcome the Great Firewall of Australia!