If you're worried that the possibility someone is going to perform an MITM attack on you is greater than infinitesimal
...or the DNS cache gets poisoned, as I once saw. (Thankfully, SSH does a reverse lookup as well and checks the result matches the input, and bails if they don't.)
That and certain drives also have a mind of their own and ignore any hdparm APM setting after a short while in favour of their own, absurdly aggressive setting. One I have (by default) unloads after 8 seconds of inactivity and the only way to change it is by some obscure DOS utility that I can't get to work. 8 seconds is crazy-low, and because the typical interval for disc activity on a Linux system under enthusiastic use is typically 10-15 seconds (or even when a bit idle, as lots of other things touch the filesystem in the backgrounds), the heads spend a lot of time loading and unloading. It's possible to tune the Linux VM subsystem to ouch the disc less often, but in practise doesn't make much of a difference. Windows XP does exactly the same. The disc manufacturer says Linux should not wake up the disc so frequently, but I don't see how that squares with the way a modern, multitasking operating system works; things touch the filesystem, and this must be synced in good time (I don't want 30 seconds' worth of dirty data just sitting in RAM). And besides, disc manufacturers should just make discs and leave VM policy to kernel designers.
ACPI does not normally (and from what I've seen, never) export any controls over battery charging, or even allow the user to choose power supply. The job of handling power is usually done by the embedded controller and its firmware, which also handles any charging (along with circuitry designed specifically for the job). This is designed for optimal performance of the system in mind and usually works very well. The operating system just monitors the state of the power supply and can make demand-related decisions (CPU power-state, screen brightness, sleep/shutdown) based upon a chosen policy. If batteries really are packing up early in the manner suggested, this is more likely down to a hardware/firmware/miscellaneous-ACPI-EC-horkage defect in the notebook itself, not the operating system.
Well given (I think, though may be wrong on this) that pretty much any finite sequence of digits will show up in the decimal expansion of pi at some point, there should be a raster image of a circle in 1s and 0s buried in it somewhere. Along with a greyscale raster of Goatse.
Sarah O'Connor? Would she be the mother of Jonny O'Connor from County Cork, who'll lead humanity to victory in the war against the machines and the English?
OK, so it takes nigh-on 150,000 processors to simulate a moggie brain at 1/100th of the usual speed. So now I have a handle on what such a brain can pull. See, I have some physics problems to solve, and there's the stray cat that hangs around outside my flat...
Windows is a hybrid kernel. Linux puts a lot more into kernel mode/real mode than Windows does.
Oh come on now, "hybrid" kernel is nonsense marketspeak; all the high-level services such as networking and filesystems and drivers run in the same address space. How they chat to each other is irrelevant here, NT is a monolithic kernel. And what the hell is a configuration database, the Registry, doing as a kernel service? And then there's GDI etc. --- (up until recently used to be) a kernel service.
The only thing I can think of that runs in kernel mode in Windows and not in Linux is the graphics system
The thinnest end of the graphics wedge (namely, modesetting, GPU multiplexing and memory management) is now being pushed into the Linux kernel, where such low-level hardware stuff should be. The GL heavy lifting and provision of a high-level graphical system (e.g. windowing, viz. X) is done in userspace, where it should be. The problem with Windows used to be that a lot of the latter was also a kernel service. Flickering displays are quickly becoming a thing of the past these days as typically the optimal resolution is chosen early on when the relevant DRI module (i915 or radeon, so far) loads.
I believe fan control in a protected-mode operating system operates in one of the following ways.
ACPI embedded controller, a separate microprocessor in the chipset that runs its own firmware (typically packaged alongside the BIOS) that monitors the temperature and controls fans in manner orthogonal to the goings-on of the rest of the system.
System-management mode where, upon detecting some thermal condition, the chipset puts the CPU into a special operating mode that executes a particular piece of BIOS code presumably to emulate the above. In this case, SMM BIOS code is executed. This happens without the knowledge or control of the operating system.
Protected-mode ACPI control whereby the OS kernel runs the ACPI tables (read from the BIOS on boot) on a virtual machine. These tables include some bytecode to activate the fan once a trip-point is reached. x86 binary found in the BIOS is not invoked here.
The first is clearly the most desirable, as SMM is just plain wrong, and hardware protection should not rely upon the stability of the operating system.
What's happening in your case could be a problem with the EC somehow becoming confused, which is likely either a BIOS or EC firmware bug.
Hi, I'm posting from the future. At first I thought, "Don't worry, be happy", but then it was more like, "It's gonna be a hard days night" and now it's pretty bad, almost "Heaven knows I'm miserable @#%^H!*( NO CARRIER
Shit, are people still listening to The Smiths in the future?
Slashdot Mirror
That and certain drives also have a mind of their own and ignore any hdparm APM setting after a short while in favour of their own, absurdly aggressive setting. One I have (by default) unloads after 8 seconds of inactivity and the only way to change it is by some obscure DOS utility that I can't get to work. 8 seconds is crazy-low, and because the typical interval for disc activity on a Linux system under enthusiastic use is typically 10-15 seconds (or even when a bit idle, as lots of other things touch the filesystem in the backgrounds), the heads spend a lot of time loading and unloading. It's possible to tune the Linux VM subsystem to ouch the disc less often, but in practise doesn't make much of a difference. Windows XP does exactly the same. The disc manufacturer says Linux should not wake up the disc so frequently, but I don't see how that squares with the way a modern, multitasking operating system works; things touch the filesystem, and this must be synced in good time (I don't want 30 seconds' worth of dirty data just sitting in RAM). And besides, disc manufacturers should just make discs and leave VM policy to kernel designers.
ACPI does not normally (and from what I've seen, never) export any controls over battery charging, or even allow the user to choose power supply. The job of handling power is usually done by the embedded controller and its firmware, which also handles any charging (along with circuitry designed specifically for the job). This is designed for optimal performance of the system in mind and usually works very well. The operating system just monitors the state of the power supply and can make demand-related decisions (CPU power-state, screen brightness, sleep/shutdown) based upon a chosen policy. If batteries really are packing up early in the manner suggested, this is more likely down to a hardware/firmware/miscellaneous-ACPI-EC-horkage defect in the notebook itself, not the operating system.
Because 3D requires a lot more complex heavy lifting that I don't want in the kernel when it fucks up. Teletype is quite lightweight by comparison.
Install a wire cage in exchange for getting my leg over?
Yeah, I'd do it.
1980
Well given (I think, though may be wrong on this) that pretty much any finite sequence of digits will show up in the decimal expansion of pi at some point, there should be a raster image of a circle in 1s and 0s buried in it somewhere. Along with a greyscale raster of Goatse.
I believe a filesystem with tail-packing support would overcome this.
The entry-level model has two processors. That's, like, much less than 4096!
Sarah O'Connor? Would she be the mother of Jonny O'Connor from County Cork, who'll lead humanity to victory in the war against the machines and the English?
So don't load the DRI modules. Or are they doing away with the video BIOS all together?
I don't think you should be finding much aluminium in your piss.
I didn't know there was actually anybody living in Llanelli. Went there a few months ago, I thought it was the town The Specials were singing about.
Heheh, yeah... way to flush out all the FreeBSD zealots.
They're called orders of magnitude.
Yeah, that's a whole lot of por—oh, dear God, no!
OK, so it takes nigh-on 150,000 processors to simulate a moggie brain at 1/100th of the usual speed. So now I have a handle on what such a brain can pull. See, I have some physics problems to solve, and there's the stray cat that hangs around outside my flat...
Oh come on now, "hybrid" kernel is nonsense marketspeak; all the high-level services such as networking and filesystems and drivers run in the same address space. How they chat to each other is irrelevant here, NT is a monolithic kernel. And what the hell is a configuration database, the Registry, doing as a kernel service? And then there's GDI etc. --- (up until recently used to be) a kernel service.
The thinnest end of the graphics wedge (namely, modesetting, GPU multiplexing and memory management) is now being pushed into the Linux kernel, where such low-level hardware stuff should be. The GL heavy lifting and provision of a high-level graphical system (e.g. windowing, viz. X) is done in userspace, where it should be. The problem with Windows used to be that a lot of the latter was also a kernel service. Flickering displays are quickly becoming a thing of the past these days as typically the optimal resolution is chosen early on when the relevant DRI module (i915 or radeon, so far) loads.
So what does it do if I allocate a couple of hundred megabytes and then don't use them?
Dunno. Think it's something the "need-a-machine-to-run-my-life" types use.
Whoa, what kind of room service are you getting?!
The first is clearly the most desirable, as SMM is just plain wrong, and hardware protection should not rely upon the stability of the operating system.
What's happening in your case could be a problem with the EC somehow becoming confused, which is likely either a BIOS or EC firmware bug.
Shit, are people still listening to The Smiths in the future?
stfud, in Python:
import socket
stfusock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
stfusock.bind(('', 8))
while True:
stfusock.listen(1)
conn, addr = stfusock.accept()
data = conn.recv(0)
conn.send("STFU!\n")
conn.close()
And RPL. Probably the best-engineered calculator run-time ever.