GP, that is what we call an "oh snap" rebuttal. Parent, nicely stated.

Split tunneling is a pretty trivial risk. Your typical home computer doesn't do forwarding (not to mention nothing would know how to route) and if the box is a zombie, it's a zombie - not talking to the C&C servers directly instead of via the corpnet isn't going to impair the bot software.

Split tunneling has nothing to do with the DNS issue. Configuring internal DNS servers is 100% solid if not essential advice for any VPN.

I dunno - will it really improve things if the FS driver has to talk to the disk driver on a different CPU? Sure, the kernel could maybe be smarter than that, but... I dunno. Either you use all those cores and take a hit on interprocess communication, or you don't use all the cores and waste some of that power.

Besides, is there any reason a macrokernel couldn't be threaded? I thought they already were.

The application to twitter anonymous accounts is creative, but otherwise it's a standard timing attack. If user A is active while anonymous data B is passed, user A has a higher chance of having generated data B than the rest of the population.

Looks like there's some number-crunching using timing of past tweets and whatnot to see if the user is likely to be on, too. I like that.

Or it could be I'm completely misreading it.

Actually, Active Directory is a REALLY nice configuration frontend for LDAP and Kerberos, among others. Of course, it uses a nonstandard schema and is a pain in the ass to integrate with because of it, but that doesn't change the fact that AD is nice to use, and is in fact a rather good implementation.

Can't speak to other distros, but Ubuntu has GDebi integrated into GNOME, which means your Skype install looks like this, with a base Ubuntu system:

1. Go to skype.com
2. Click the Ubuntu download link. The fact that you're using Linux is autodetected and the Ubuntu part is easy to figure out because the logo is visible at all times on the toolbar.
3. Double-click downloaded file (or tell Firefox to open it), which brings up a "Software Installer" window (GDebi, though that branding is hidden)
4. Click Install Software, then enter password when prompted.
4a. GDebi handles any missing dependencies via APT and installs the package.
5. Find Skype under Applications->Network

Only extra step beyond Windows there is entering your password when prompted, and that is, from a usability standpoint, equivalent to UAC.

Ah, certainly could be 2 on Tru64. I come from a Linux-x86 world, so I just know what's typical for that. Some systems don't even require a pass for maintenance mode - it depends on the init being used, but it usually does require the root password.

So you password either the BIOS or the bootloader, or both. And runlevel 2 won't help. You're thinking of runlevel 1, single-user mode - which usually requires the root password to get into.

The other option is doing something like init=/bin/bash as a boot option, which locking down the bootloader prevents, and booting a different OS, which locking down the BIOS prevents. This is not a difficult problem.

Oh, and Group Policy is no better than CFEngine or parrot, both of which can override the root password and system configuration back to what it was before the user mucked about. The workaround in both cases is to just disable the damn thing while having local admin, though for GP I think that does involve leaving the domain. Which doesn't block a knowledgeable user from anything anyway.

Which is not the same as 'sudo rvi'. You can set sudo to only allow certain commands, so if you allowed 'sudo rvi', you couldn't run 'sudo ~/vi'.

sudo filters by the command executed (I've seen things restricted to full command line - i.e. sudo killall -HUP ircd but not sudo killall ircd).

Actually 2-node active-passive can be a very good idea.

Let's say you have two nodes behind a load balancer (only way to replicate functionality active-active... you could do the thing where one server is static though, like youtube does). You need a shared filesystem, so you need another node to act as a NAS. What if your app is database-backed? You can stick that on the NAS, probably. But then it's not redundant.

It's really just simpler to have unidirectional replication, then script it to switch direction upon failover. The Linux-HA project makes it relatively easy, since they've been working on that for years.

The Sectera Edge is in no way a Blackberry. It runs Windows Mobile. Blackberry runs a proprietary OS which is completely different from WinMo.

So this is different from the current state of things... how? I guarantee every time you enter or leave almost any country, it's already logged. Particularly the more technologically advanced countries we know as the "First World".

Yeah, but they're expensive. I can build a tuna tin transmitter from a kit for less than the price of a single FPGA.

Actually, contacting the ISS out of the blue is fine. You can prearrange it too, turn it into a kind of publicity thing - like they did here - but you can track the ISS on a site like Heavens Above and then just use any Amateur Radio set on the right frequencies to talk to them when they're above - search for ARISS (Amateur Radio on the ISS) for details. It takes a bit of luck to catch them when they're awake and chatting though, and you only have a short window every 90 minutes or so.

I personally hate that naming scheme, it's confusing and produces long, hard to remember and typo-prone hostnames.

NS records exist for a reason. Your example could just as easily be:

windb002.syd

Since every Windows network (and that tends to be where I see domain names like that) is a real DNS domain, there's no reason you couldn't do this. This has the added benefit of being able to push a DNS search domain based on the location of the computer doing the DHCP request, then having certain hosts that are replicated in each area subdomain, for example a CMS or a DB. Does sydwindb002 replicate to nycwindb002? Have windb002.syd replicate to windb002.nyc (and vice versa) then let users just put in windb002, and traveling users will be able to automagically use the closest and probably fastest DB server.

Or, in the case of a CMS, have one top-level CMS that refers to local ones. Say you have cms.example.com and cms.xxx.example.com. Depending on your network location, typing in CMS will either take you to the top-level CMS or the local one, which might aggregate data from the top-level one.