I guess i should say "can be vastly better" as the fact that power management on some laptops is bad under Linux, because of lack of documentation on hardware.

Linux certainly wasn't developed in the beginning with portable devices in mind, and it's vastly better in power savings. Most of the devices in TFA's chart are Android tablets.

RT and Windows 8 are an ARM port of NT.
What's interesting about this is that this is the first instance of ACPI and UEFI on an ARM platform.
Everything else running on ARM uses a custom bootloader or something like CFE or U-boot which isn't trying to be some pseudo-pre-OS pile of managed shit.

I think therein lies the answer, because Windows CE devices (running on Intel PXA ARM SoC's) of the day had battery life pretty comparable to their peers. At least from what I could remember. Perhaps ACPI is just a shitty interface for power management, or perhaps Nvidia (most of the Surface hardware is Nvidia based, isn't it) just provides shitty drivers.

Well, the video card of course will save power by not rendering a frame until the LCD is ready to take it.

I'm not keen on the low level details of HDMI, but I do know that HDMI and friends send the entire image per frame over the wire. The "RAMDAC" of HDMI is sending a full frame's worth of data over that wire regardless of any changes. It would save a bit of power to not send that if there are no changes.

Even if your videocard did nothing on a given frame, it's framebuffer still got shoved over the HDMI pipe. Every frame.

I guess the reason why you don't want to just send "deltas" over the wire is to avoid having to do the B and I frame junk MPEG does, and maybe to support it where communication between the monitor and source is not bi-directional (though HDCP demands it is such).

I'm not sure if HDMI can accept sending frames on demand. I do know I've seen some monitors in Windows accept low refresh rates like 40Hz. Maybe it's basically just automatically picking a low refresh rate or something when the image is static.

Images where there's a low difference of changes can operate at a much higher framerate.

I think this opens up interesting possibilities.

Of course I think the physical response time of the display will be a bottleneck, capping the rate at a maximum below what the GPU can pump out.

Also it can save power. If the GPU is creating frames lower than 60hz then that's less power it needs to spend to do it.

>Try to run W7 on 1GB -- it is a swap/page fest that will burn up the hard-drive before drawing the desktop.

It's not that bad. Windows 7 is actually efficient and decently responsive.

I had Windows 7 running for a long time on a 1GB 900Mhz Celeron netbook. Aero didn't work, and of course things were slow, but not unusably slow.

Now, I didn't run any real applications on it, like Photoshop, etc. but for basic browsing, etc. and even basic Office use it was OK.

Except for Flash. Flash videos would always stutter, even with plenty of free RAM.

Fortunately, there's Minitube, though I never used the Windows version (Linux is on that system now).

>Just put a "smoke and mirror entrance" system in front of the data center. When they come, lock them in there and call police.
This is illegal (illegal confinement or arrest) and will make you criminally liable. #IANAL.

Here's why the UID is 0 and should stay 0.

In most assembly languages, when you compare against a value, you have use a "compare" instruction that effectively does a subtraction, but throws away the result.
In most CPUs, there is a flags register with a zero (Z) bit, which is flipped whenever a value is loaded that is zero.
When you want to see if something like your accumulator or another register is an arbitrary value like 100, you need to do a "compare 100" and then "branch if equal to whatever..."
If it's zero, you can just load the value and skip the compare step. You get a "free compare" when the value you want to compare against is zero.
So if the superuser is not zero, there will be a performance penalty.

Besides, this dumb shit is C's fault for using = and == as operators. Pascal had it right with := being the assignment operator.

There's a really cool open source SSL VPN called Adito that allows you to do port forwarding over SSL via a browser-launched Java applet.

I've been using it awhile, haven't had any problems. Seems to be faster even if it makes my `ps aux` look scary with all those kernel processes.

Hmm ... that volume didn't have that much free space just a few minutes ago ...

> 1) Nobody's quite sure where "back" should go back to, and what menu "menu" should open
This is a good point. On my current phone, the back button exits out of some apps (those have a back button at the top), and on others, it goes to what I was doing previously.

Linux doesn't need a BIOS to boot off of. Windows does. Windows has all the dumb BIOS, UEFI and ACPI dependencies. Linux can use ACPI but certainly runs without support for it enabled. Windows versions starting with Vista won't install at all on a non-ACPI system AFAIK.

I run Linux on a Guruplug with the U-boot bootloader. And I know coreboot can directly load a kernel + initrd and hand over control like a good bootloader is supposed to do.

The problem with putting this at the heart of the IP protocol is that IP needs to know the source and destination so you can communicate. If you want to obfuscate the source, it's more involved than what IP is tasked with.

IP is meant to try to get data from source to destination, with the absolute minimum info built in to support the notion of routing and subnets. Because it's called an internetworking protocol after all, meaning your traffic will traverse networks.

Anything else is not IP's job. Because IP is so simple it allows high performance networks to be built and expanded easily. When you make things at the IP layer complex, you get something like the phone network, which is hard to expand when needed. You want the core lean, mean, dumb, and fast.

I played around with some of the Linux TPM tools on a Dell system.

Seems like all that it's meant to be is a way to sign stuff with a key locked to a machine that cannot be retrieved unless you know how to read the nonvolatile memory of the TPM chip.

The whole remote attestation crap is handled by something else, Intel's TXT being such an implementation I think. That would seem to be the feature you want to stay away from, or NICs that have an integrated TPM and I presume something with TXT also available ...

And on this system I could tell the TPM to create a new, revocable EK, which to my understanding is the "root" key in the whole TPM scheme.

I kinda like it. What's the big deal about the TPM other than I'm sure it has a hidden debug mode that reveals the EK to whoever the manufacturer wants to give that ability to.

will never be the same.

QNX isn't a UNIX derivative at all. I think it has some POSIX compatibility stuff thrown in but it's not a unix.