Go look at the cables. It'll only be a problem if your name is xxxx xxxxxxx.

That "th3j35t3" guy appears to be a major idiot, admitting to various DDoS attacks and being very public about his actions and convictions.

He's even gone so far as to develop his own pretty DoS tool with green fonts on black background with twitter integration that exploits uber-secret knowledge, like opening many connections that slowly feed http headers to apache, thereby using up all available children.

What will be interesting, though, is his own encrypted insurance file, that supposedly contains various information about the people behind wikileaks, although - like the wikileaks insurance file - you can't really prove it contains anything but random garbage. I rather choose to believe that the guy is a bored, stupid teen who read too many articles about the fantasy anarcho-hacking world of the 90s...

The point is called efficiency. If you need to have a short discussion *right away*, a good old-fashioned phone call is still the way to go. Low latencies, rapid request/response cycle and unlike texting/IM, you'll know immediately whether the person on the other end is actually available right now.

And no, I'm not an old fart who just doesn't want to use modern stuff. I use texting, IM and email every day and they are useful things to communicate *asynchronously*. Want to inform me of something (one-way communication) or tell me something that doesn't warrant my immediate attention? Send a text or IM. If you need a response right away, why the hell contact me on an unreliable medium with high latencies? Yes, that *does* include IM. It's perfect for idle chit-chat or long stretches of discussing things while both parties are concurrently working on the same thing, but if you want require undivided attention, don't contact me over a medium where I spend most of my time waiting for you to type out a message.

If you really want to completely ignore calling as means of communication then feel free to do so. Just be aware that while you're still engaged in a staring contest with your phone trying to ask what to buy for dinner I'll already be on my way to the cashier.

I didn't mean to imply that one of those was better - I regularly use and am sysadmin for both of them. What I meant to say was that there are so few packages compared to debian because redhat's enterprise-class phone support will support bugs and configuration issues for all ~2500 packages and many of their engineers have deep understanding of or are involved with the upstream projects. You simply couldn't afford to have people available 24x7 with guaranteed response times for the number of packages in debian's repositories.

The number might seem small at first, especially compared to other distros. The main difference, though, is that those packages aren't just nice addons to the base system but rather supported 24/7 and kept updated for quite a few years from now.

This anecdote sums it up quite nicely. Now all we need is a few more of those and we have data :P

I congratulate the /. team for applying so many changes that would make the site more interesting and increase usability for a number of users. Also, I know that playing with all the new-fangled AJAX stuff is pretty and can be fun to develop.

On the other hand: Please don't ignore us users who still use the good old classic style. I simply like my /. without fancy effects and strange navigation bars. Threshold of 3, nested, oldest comments first, re-parenting comments and a link i can open in a new tab to read the stuff below my threshold is all I want and need.

Long story short: While developing all the exciting new stuff, please don't completely ignore or remove (*shock* *horror*) ye goode olde Slashdot layout. It works currently, has served many people well for quite a while now and hopefully doesn't cause too much work for you guys. Just please fix it every now and then in case you break it.

Oh great, now I won't only have to ignore those idiots but also go the extra mile and add a DROP rule in ip6tables.

That one seems like it took a lot of work and preparation. Better than the last 2 years, /. :)

"Web messages" should be indicated at the very top of the index page near "Idle is a waste of your time..." and similar announcements. Your messages are shown here and the preferences are here.

By the way, I'm using the old /. style without all the AJAX stuff, maybe that's got something to do with it?

I forgot to mention that although Open Source software has greatly advanced over the years, it apparently still won't protect you from forgetting to select the "Plain Old Text" formatting option.

I can't really say anything about the cost of proprietary software, so I thought you might appreciate some information about what Open Source can be used for: My university has many thousands of students in all kinds of maths, engineering and technology-related fields. There's a custom zope installation for managing your schedule and course registration that's also used for other things like a secure central authentication gateway for professors who want to roll their own systems yet still need to interface with the main system. Every student has an account on an HP-UX Server, although this could also be done with cheap Linux servers. There's a public_html directory for your student website and a maildir for your mail in your home directory. There's also many cheap SUN/Intel terminals strewn across the entire campus (hallways, computer rooms, learning rooms, etc.) which can pxe boot into either kiosk mode (a browser that can only access the university's website) or pxe boot into a login screen. Once logged in, it will PXE boot yet again into an environment suitable for your profile or the location you're at (e.g. certain labs might have different kinds of environments). Your default environment is a basic KDE desktop system with your home directory mounted, kmail set up to read your .maildir, OpenOffice.org and many other productivity features. Now that I have described it to some degree, I hope the advantages are becoming apparent. By utilizing the nature of Open Source software and the fact that you can freely combine them into something that suits your specific needs you can provide your students and staff with a high degree of flexibility. I can simply log in from any computer on campus or anywhere in the world and check my mails with any mail client I prefer, work from anywhere on my stuff, can forward X sessions so I can access restricted resources with Firefox running on the internal network but displayed on my computer at home, etc etc. The administrative costs are also pretty low since all you'll have to do is go and replace or install a cheap PXE booting terminal and it's ready to boot. Since there's only few PXE environments in use your ongoing maintenance cost is pretty much approaching zero. All you need to implement this kind of setup is some resource planning and a few experienced UNIX admins to implement it and keep it running. No more expensive maintenance contracts with 20 different companies, no more fighting with vendors who are completely unable to have their proprietary stuff talk to each other and no more proprietary interfaces and protocols that prevent you from running a well-integrated infrastructure.

You're right, CentOS isn't really much of a desktop distro, but you should still give it a chance. I've been using it as a desktop for the last year (switched from FreeBSD) and I'm pretty happy with it. It's a stable base system (no PulseAudio or other beta-quality stuff) with a basic [kde|gnome] desktop environment and all of your additional needs (multimedia, etc) can be satisfied by a handful of external repositories you can add to yum. You can even simply use all the stable base stuff from CentOS and simply use fedora repositories for most other things.

First off, RTFM. CentOS is pretty much a RedHat clone, and their documentation is great and easy to understand.

Some general hints in no specific order:

- Go through all files in /etc/sysconfig, learn what they're doing and configure them as needed.
- Run chkconfig --list, find out what each and every one of those services do and enable/disable them as required.
- Don't plug in the network cable before you've done a rough setup of iptables. There's even a console based GUI for that.
- Never, never ever use easy passwords like root:root123, test:blah and similar. Believe me, if your sshd is accessible from the outside you *will* have a Brazilian script kiddie on it within minutes.
- After installing a service like apache or ntpd immediately find the config files and read through and try to understand all of them. Getting everything only half-working is of no use.
- Take your time and don't let anybody stress you about getting that server ready for production. Once there's stuff running on it any oversight will cost you.
- Do *not* optimize for performance. The server's probably fast enough as it is. Unless you know exactly what you're doing you'll probably only screw up and/or waste your time by optimizing a server that has a load of 0.02 anyway.
- Before moving to configure a different piece of software test everything as well as possible. Try logging in to your new ftpd as anonymous and start a warez archive. See if apache leaks configuration information. Use your mail server as anonymous relay.
- Learn whatever you can about the server itself. Install vendor-provided administration utilities and try to set up system event logging and notifications.
- Run yum update (or even upgrade) *before* going into production.
- Trust most default values of packages you've installed, but don't trust them blindly. If in doubt, read the man page or documentation.
- Most security stuff will be adequate out-of-the-box. Take precautions but don't be too paranoid. Trying to implement your own perfect security measures without knowing enough about the details, modifying perfectly good default PAM settings and similar will probably only decrease security.
- Don't forget why you're running a Linux distribution and not Linux From Scratch. Their packages, configuration subsystem, file paths, init scripts and so on are probably not according to the way you would have done it but customizing everything will only cause you tons of additional work down the road. Only customize when you have a good reason, no way around it or need to deploy your own setup to many servers.
- Last but not least, play with it as long as possible. Toying around and with and exploring a non-production server without breaking too much will teach you more real-life experience than any book could provide.