Forgot to mention, if you've installed cursor themes in your home directory, you'll want to run
for i in ~/.local/share/icons/*/cursors; do arrow="$i/arrow"; test -e "$arrow" || ln -sv left_ptr "$arrow"; done
as well.

Many mouse cursor themes (eg. the Oxygen ones) are missing the "arrow" pointer.
When Steam starts up, for some retarded reason it sets the session pointer to that, which, if missing in the current theme will be substituted to that ugly cursor in GTK+ applications.

Until the cursor packages are fixed, you can run
for i in /usr/share/icons/*/cursors; do arrow="$i/arrow"; test -e "$arrow" || ln -sv left_ptr "$arrow"; done
as root once as a workaround. (You may need to rerun it after upgrading/installing a new mouse cursor theme).

I have an SIP phone at home, that is connected to my company's PBX through the internet.
When I call a landline number, the PBX sets up a data path directly from the SIP provider to my phone, without it being relayed through the PBX.

How would you implement that without in-band address signaling?

SSL's overhead is in the handshake: in this scenario, the client would only handshake once, on its first DNS request to its upstream resolver.
Your other concerns could be taken care of by DTLS.

First of all, under no circumstances do you throw AOL's user base at a single server, no matter the service.
Apart from that, Linux can handle millions of open file descriptors (up to 1million/process by default) nowadays, the bottleneck is elsewhere.
In any case though, DNS is mostly stateless and uses UDP by default, why would your protocol be any different?

Solaris?

I was one unlucky child at the time, as I wanted the awesome Amiga/DOS Lion King platform game, and instead my father got me the Windows animated presentation^W^W"game" version. Luckily I found it "from a friend" a year later.

What I remember from WinG (Myst used it as well IIRC) was a) forcing me to restart Windows in 8bit color to use it, and b) frequent screen corruption and the subsequent reboots to fix it.

I've been building multilingual brochure-type websites in Drupal since 4.7.

Drupal 7 delivers too little (DBTNG, fields, imagecache in core), too late.

The new admin overlay is so bugged that it's practically unusable, even with the (default) Bartik theme.

Worst part of it for me is there are major regressions, especially related to i18n functionality, and the "i18n" module doesn't help as it did in earlier versions of Drupal anymore.

There are opened bugs for the above, many of which were opened even before D7 was released. In many cases (usually with i18n issues), the core developers don't even bother answering. As for critical bugs opened before the release, they just downgraded their importance, just so that they wouldn't delay the release any longer. Needless to say, they weren't looked after after the release either.

If you think I'm trolling, for a spectacular example try using the "Global Redirect" module on a D7 site with more than one language enabled. Just try it.

What's killed it for me though, is the in many cases total lack of developer documentation apart from function prototypes.

I've started exploring Django (I know it's not a CMS) and its ecosystem now, hopefully I'll have better luck with that; it being written in Python doesn't hurt, either.

Are you fishing for idiots?

"Go find an unsecured AP in some other city and/or country" is the first step in getting some anonymity.

After that, there's a never ending list of precautions you should take, of which your advice is only one part.

<file grep something

There you go.

Thank you so much!

I've been assembling the "use Vim as an IDE" puzzle for the past few days and these were the remaining pieces...

Anything compiled against the kernel headers is automatically considered a derivative work of the kernel, so distributing it without full source code is a GPLv2 violation. It being in an initramfs or wherever else doesn't matter at all.

This means that the aforementioned Android vendors are indeed in violation at the moment (and they couldn't care less, as no Linux kernel coyright holder bothers to sue them).

Normal Linux distributions (in cooperation with other closed source driver vendors such as AMD & Nvidia) circumvent this by compiling a stub kernel module part at install/boot time (using DKMS for example). That rest of the (closed source) driver is then implemented as a userspace program/library, which the stub kernel module interfaces to.

Bundling all this stuff in a mobile phone distribution would be difficult at the moment, but not impossible, and in any case would allow us to modify the core kernel much easier.

This "The server must not know the user's password" requirement will bite you in the ass if you decide to integrate with different systems in the future (see the retarded LM & NTLM hashes).

Also, what's the password reset procedure for this system? Do you snail mail hashes to the users? Rolling back the hash/salt combo on the server would once again allow the attacker to login while the client hasn't reset the password, and, if the attacker can initiate apassword reset, they can essentially log in for as many times as they wish.

Lastly, don't forget to use TLS or some equivalent while you're at it - no point in allowing an attacker even one login.

FTFM.