Don't you see how that's painfully unsustainable? There's either going to be a time when we don't need as much stuff, or a time when there is not enough raw resources left to make stuff.

I feel comfortable with "no ability to access cell network = not a cell phone".

++1 Yup, FreeSWITCH is great. Asterisk is powerful but leaks memory at high loads and in my real world experience doesn't handle 100+ calls well on a pure SIP setup on average hardware. I really enjoy the completely different way FreeSWITCH handles things. It feels more UNIX-y and hardened out of the box.

The biggest problem out there causing SIP toll fraud is people's extension passwords being set to things like "1234" in trixbox/asterisk/freepbx etc. It is "user error" but also "user ignorance" because these frontends and pbx software packages do not really bother telling their users to use secure extension passwords. In a perfect world extension passwords would be autogenerated to be very strong, but in FreePBX for example the extension password is called a 'secret' but since it is not called a password, I have had users set up Asterisk boxes with 1234 as the 'secret' who don't realize that actually means they are opening up UDP 5060 for connections to users who supply 1234 as their password. Hello, 50000+ calls to China/UK international DIDs! Goodbye, bank account :(

I do consulting for a VoIP PSTN gateway company and we are seeing a large amount of bruce force SIP registration attacks against our IPs all the time. We have implemented some DDOS protection to stop the abuse of our precious CPU cycles but the problem continues. It is more user related than Asterisk related. trixbox/freepbx/and the other frontends out there need to do more to make security their focus, rather than "omg look at the flash operator panel" and "look at the shiny bar graph showing live calls". Unfortunately the users of these frontends are not looking for that, so the shiniest frontend wins....

My current setup includes FreeSWITCH running on FreeBSD with the very nice FusionPBX frontend, which is based on the FreeSWITCH pfSense Firewall module. With these tools, a properly secured apache, and properly configured IP ACLs in place, I am seeing zero toll fraud on the system.

What he is (I think) saying is that nobody sane would use RAID on the host machine as their only backup, and feel safe. Integrating RAID with a backup strategy whereby the RAID is not the only copy of the data being backed up, i.e. if RAID is on the backup server, and not just on the main machine being backed up, then you essentially have a combination of backup (the second box) and high availability (the RAID on the second box). Which is a Good Thing.

When implementing RAID I like to use RAID + LVM + hot swappable SATA discs. That's a nice high availability option.

No, "ps -aux nginx" is not simple enough. nginx is a legitimate, powerful little web server and there is a good chance an admin would have it running on a server for something. For example, it is used by Wordpress.com as a load balancer. Don't confuse nginx with the malware, it is no different than if they were using apache to serve the malware. In this case they use nginx because it is smaller, faster, runs well in virtualized environments and is easily configurable/deployable en masse. But it's just a neutral party in all of this... of course hackers are going to use the most efficient web server available for the task they are trying to accomplish.

Actually, iTunes has the ability to use multiple libraries. Start up iTunes on a Mac while holding down Option, or Shift in Windows, and it will let you choose from an existing library or create a new one. See here for more info.

Thanks for posting that link. Much better to read Joel's tips than this retarded "article".

It's curious to me that so far as I am reading this three people have responded telling you exactly what you did that is not allowed and you haven't addressed their replies yet. Hmmm. Are they wrong?

Seems like a lame feature request to me. I can understand not wanting to implement that. VLC already has a problem with feature sprawl (or as someone else called it an identity crisis). It's already a streaming client and a video player and a transcoder/converting tool. Why does it need to be a de-archiver as well? Bloat bloat bloat. The developers should be focused at this point on increasing its performance on Win32 if anything (at least according to the general sentiment of the comments here and pretty much everywhere online).

I guess someone could always fork the project to implement archive-extraction-before-playing if they wanted it badly enough, though. So all is not lost.

If anyone understood how RAR files work they wouldn't ask for VLC to be able to play them as if they were video files.

I also only used the Apple Remote with VLC until I found this little tool: http://gravityapps.com/sofacontrol/

I am a happy registered user of Sofa Control, which allows you to program your Apple Remote to pretty much do anything. And it highly extends/replaces the Front Row functionality without borking it up if you still want to use it, while simultaneously taking over "full control" of the remote away from Front Row. You can even use it to remotely control Safari which I imagine might come in handy (presentations etc).

Yup, Sofa Control + Apple remote = useful. Sorry for the off-topic-ness.

You're hilarious.

(typo - should have wrote "it's not hypothetical" not "it's hypothetical" above.)

You are sure angry about something that I can't quite figure out. You've got some serious attitude, buster. Why are you resorting to profanity and name calling? Argument fall apart much?

This is false. Name one.

Ahhh, right, it's hypothetical. OK, so be specific. Google upgraded their existing platform and all of their applications to be compatible with IPv6. So, I have an example of a legacy system that WAS replaced without any downtime and without having to create new solutions.

Just 'cuz some dusty old server in a corner at some corporation hasn't been touched in 20 years and nobody knows what it does anymore, doesn't mean the world will implode and all will go down in flames if the server is decommissioned. Analyze, brainstorm, plan, and create a replacement that encompasses the input and output of that legacy system using existing tools ... and ta-da!

CAN NOT be done is not the same as WILL NOT BE DONE.

Replacing a legacy system is re-inventing an existing wheel, not creating a new wheel that "SIMPLY CANNOT BE IMAGINED!!! OMG!"

No, I don't "not get it", I just think you're wrong. It's not that there is NO REPLACEMENT for this completely hypothetical Fortran code. It's that there is nobody paying anyone to WRITE the replacement code. If the code is not currently available, it does not mean that the solution does not exist. Therefore, the currently available solution in your example is to WRITE THE CODE. Which is 100% possible.

Since you asked: Why would you replace a legacy system? Lots of reasons. I guess that if one is finding themselves in the situation where they are considering replacing a legacy system, that perhaps there may be a few reasons already on their mind. We are talking about replacing legacy systems with systems that are compatible with IPv6 which to me would mean that a compelling reason to convert a legacy system in this example would be 'to regain/retain future network connectivity'. For example. Is the ability for your old legacy app to remain on the network worth your company's time? At some point it is going to be UNLESS YOU REPLACE IT with something non-legacy. Either way you are addressing the same problem, it's just a matter of when.

To stick with your example further, it's not like Fortran does something that is absolutely inimitable by any other language or platform. But who cares? Fortran can exist on a non-legacy platform, and fulfill the legacy function without legacy hardware. GNU Fortran compiler, for example, doesn't even compile machine code directly, it compiles assembly language. So one could write the replacement for the legacy Fortran system in optimized assembler if one wanted to. Just because nobody is paying for that to happen does not mean that it is not possible.

Again: "TONS of legacy systems out there that can NOT be replaced with any currently available 'solutions'" is simply not true. The solutions are there (i.e. write/build/outsource a replacement), they are just not being pursued because of a lack of business incentive. This is shortsighted, and will change, when considering IPv6.