My Nokia N800, running 2.6.21 was running with a high load for no obvious reason this morning (well, yesterday actally), and kept draining its battery. I uninstalled some recent package updates but the problem remained. After a few reboots it seems to be back to normal.
Do you guys remember the April bug in the older SE phones? It happened on two succesive models, two years running. If you accessed the Calendar at any time during April, using the hotkeys to get there, it locked up and needed the battery pulling. If you accessed the Calendar via the longer approach, delving into the menu, it worked fine. When May came around, the hotkey access to Calendar returned to normal.
It was quite bizarre, but I was actually looking forward to the following April to see if the bug was still there;-)
Funny you should mention that, but I've been writing an AX.25 convergence layer to run the DTN bundling protocol over connected mode AX.25 on Linux. It's still in testing though and seems to have some issues. Hopefully I'll get it fed upstream into the sourceforge DTN2 code-base soon.
Anybody want to try it out?
I understand where the argument that digital modes like psk31 are better comes from, but I've often wondered about the total power efficiency of using a computer as the modem, as opposed to just adding a few more watts of RF power to a CW transmitter. For portable operations, when you have to carry batteries for the radio and the computer, I'm not convinced that you can communicate better for longer, for the same total power budget. On the other hand, though, morse relies on the human ear and I'm not sure about the relative power consumption of a human operator compared to a laptop, but then I guess there will need to be an operator to carry all the gear anyway, and I don't think those that know morse expend more energy than those that don't. I wouldn't like to transmit JPEG-2000 pictures as morse (or psk31 for that matter), so its definitely a case of horses for courses.
Regarding the noise resistance, have you ever tried using auroral propagation on VHF. CW is great for that, as the the normal single tone ends up sounding like a switched noise source, but is still readable when voice (SSB) turns into ghostly incomprehensible whispers. I can't imagine psk31 working in that kind of environment, although admittedly it seems designed for HF use and there may be other specialised modes ow designed for working through aurora. I haven't really dabbled in the VHF bands for a few decades, so I'm not sure.
Well, I would say, based on the following recommendation from the PILC working group, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations"- RFC 3135, that they should all be aware of what you are doing, at least if they're technically minded enough to run pcapdiff.
In any environment where
one might consider employing a PEP for improved performance, an end
user (or, in some cases, the responsible network administrator)
should be aware of the PEP and the choice of employing PEP
functionality should be under the control of the end user, especially
if employing the PEP would interfere with end-to-end usage of IP
layer security mechanisms or otherwise have undesirable implications
in some circumstances. This would allow the user to choose end-to-
end IP at all times but, of course, without the performance
enhancements that employing the PEP may yield.
Here they are, at the home of the Delay Tolerant Networking Research Group: http://www.dtnrg.org/
Whilst the Delay Tolerant Network Architecture (a store-and-forward overlay network, see RFC 4838) and Bundling Protocol are mainly there to solve different problems (mostly the potential lack of a known end-to-end path) the Licklider Transmission Protocol (LTP), is designed primarily to run efficiently over single link-hops with considerable round-trip times (typically introduced by light speed constraints) but also deals with bandwidth asymmetry and mixed reliable or best effort delivery.
Deploying BP over LTP on these kind of links seems to be the plan. Then BP can extend from the orbital node down to the ground over TCP or SCPS-TP (http://www.scps.org/) or similar. BP is designed to have a shim-like Convergence Layer (CL) to interface with the whatever stack underpins it on any specific link. The open source reference implementation (Apache 2.0 licence) currently supports TCP and Bluetooth (Linux only). I've implemented a mostly working CL for AX.25 which I hope to try out using ham radio gear soon.
Oh how true. My favourite line goes something like this (if my memory serves me well, which it often doesn't):
"I need to know everything. Not because I need to know, but because I need to know whether or not I need to know; and if I don't need to know, I still need to know, so that I know there was no need to know."
I think old Humpy must have inspired the Americans a little in their recent domestic surveillance escapades. I'm not saying that it's any better in the UK, mind you, but then I don't know.
Who's to say they are not talking to Microsoft to get the WMV DLLs shipped with a Linux version and link into them? That'll help on my Nokia Internet Tablet won't it? Don't just think x86 binaries for Linux are going to be good enough.
NIST? Those guys? I found a 16dB discrepancy in their RF link budget calculator a few years ago. I often wonder how many over-specified systems that caused to be deployed. Still, you can't grumble about a better link margin if you can afford the costs of the design.
Hmmm. I wonder if there is a serialisation delay, as the information regarding each atom is transmitted sequentially, or is all the information conveyed concurrently?
If the former, it might be a problem if your head slowly turned into a bowl of petunias stuck on a dying body at the source end, whilst the system slowly materialises a dead body out of grey goop at the destination.
Comfortably? The article on BoingBoing says "He cannot walk, has a hard time talking and swallowing, is extremely frail and needs full time care that is being provided by several friends-fans-volunteers and family." I doubt if it will make him comfortable, other than that he can avoid being homeless too.
RAW's writings offer real enlightenment. RAW taught us how to hack our brains and detect the fnords in the matrix. There's probably more of interest in the name of his paypal account than there is in your whole post.
Slashdot Mirror
My Nokia N800, running 2.6.21 was running with a high load for no obvious reason this morning (well, yesterday actally), and kept draining its battery. I uninstalled some recent package updates but the problem remained. After a few reboots it seems to be back to normal.
fnord
Does this mean that Zunes run Linux?
fnord
Do you guys remember the April bug in the older SE phones? It happened on two succesive models, two years running. If you accessed the Calendar at any time during April, using the hotkeys to get there, it locked up and needed the battery pulling. If you accessed the Calendar via the longer approach, delving into the menu, it worked fine. When May came around, the hotkey access to Calendar returned to normal.
It was quite bizarre, but I was actually looking forward to the following April to see if the bug was still there ;-)
fnord
Flatter, thinner and shorter tails make me think of beaver.
fnord
Hmm. I guess I'm not the first to notice this, but an anagram of masochist is:
mac os shit
Note that this is not my view. Perhaps we should use the term viatschist instead of masochist?
fnord
Funny you should mention that, but I've been writing an AX.25 convergence layer to run the DTN bundling protocol over connected mode AX.25 on Linux. It's still in testing though and seems to have some issues. Hopefully I'll get it fed upstream into the sourceforge DTN2 code-base soon. Anybody want to try it out?
They must have been on the reindeer piss again.
In the UK, the law requires drivers to be paying attention Is it not the same over there?
I understand where the argument that digital modes like psk31 are better comes from, but I've often wondered about the total power efficiency of using a computer as the modem, as opposed to just adding a few more watts of RF power to a CW transmitter. For portable operations, when you have to carry batteries for the radio and the computer, I'm not convinced that you can communicate better for longer, for the same total power budget. On the other hand, though, morse relies on the human ear and I'm not sure about the relative power consumption of a human operator compared to a laptop, but then I guess there will need to be an operator to carry all the gear anyway, and I don't think those that know morse expend more energy than those that don't. I wouldn't like to transmit JPEG-2000 pictures as morse (or psk31 for that matter), so its definitely a case of horses for courses.
Regarding the noise resistance, have you ever tried using auroral propagation on VHF. CW is great for that, as the the normal single tone ends up sounding like a switched noise source, but is still readable when voice (SSB) turns into ghostly incomprehensible whispers. I can't imagine psk31 working in that kind of environment, although admittedly it seems designed for HF use and there may be other specialised modes ow designed for working through aurora. I haven't really dabbled in the VHF bands for a few decades, so I'm not sure.
The word "is" seems arguably worse in that respect.
Well, I would say, based on the following recommendation from the PILC working group, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations"- RFC 3135, that they should all be aware of what you are doing, at least if they're technically minded enough to run pcapdiff.
In any environment where
one might consider employing a PEP for improved performance, an end
user (or, in some cases, the responsible network administrator)
should be aware of the PEP and the choice of employing PEP
functionality should be under the control of the end user, especially
if employing the PEP would interfere with end-to-end usage of IP
layer security mechanisms or otherwise have undesirable implications
in some circumstances. This would allow the user to choose end-to-
end IP at all times but, of course, without the performance
enhancements that employing the PEP may yield.
Hey, then you'd never need to turn the light switch on, thus saving electricity. Cool!
How can you be sure they are virus and malware free with a scanner?
Here they are, at the home of the Delay Tolerant Networking Research Group:
http://www.dtnrg.org/
Whilst the Delay Tolerant Network Architecture (a store-and-forward overlay network, see RFC 4838) and Bundling Protocol are mainly there to solve different problems (mostly the potential lack of a known end-to-end path) the Licklider Transmission Protocol (LTP), is designed primarily to run efficiently over single link-hops with considerable round-trip times (typically introduced by light speed constraints) but also deals with bandwidth asymmetry and mixed reliable or best effort delivery.
Deploying BP over LTP on these kind of links seems to be the plan. Then BP can extend from the orbital node down to the ground over TCP or SCPS-TP (http://www.scps.org/) or similar. BP is designed to have a shim-like Convergence Layer (CL) to interface with the whatever stack underpins it on any specific link. The open source reference implementation (Apache 2.0 licence) currently supports TCP and Bluetooth (Linux only). I've implemented a mostly working CL for AX.25 which I hope to try out using ham radio gear soon.
I think old Humpy must have inspired the Americans a little in their recent domestic surveillance escapades. I'm not saying that it's any better in the UK, mind you, but then I don't know.
Oh, and don't you mean Weisel
?You might wish to consider the use of the word "their" under these cicrumstances.
Doesn't that mean I can't watch the BBC on my BBC Model B computer? How's that for backwards compatibility?
Who's to say they are not talking to Microsoft to get the WMV DLLs shipped with a Linux version and link into them?
That'll help on my Nokia Internet Tablet won't it? Don't just think x86 binaries for Linux are going to be good enough.
An ISDN B-channel is 64kb/s, with 8-bit samples at 8kHz.
It works much better than space based sonar!
NIST? Those guys? I found a 16dB discrepancy in their RF link budget calculator a few years ago. I often wonder how many over-specified systems that caused to be deployed. Still, you can't grumble about a better link margin if you can afford the costs of the design.
fnord
Hmmm. I wonder if there is a serialisation delay, as the information regarding each atom is transmitted sequentially, or is all the information conveyed concurrently? If the former, it might be a problem if your head slowly turned into a bowl of petunias stuck on a dying body at the source end, whilst the system slowly materialises a dead body out of grey goop at the destination.
Comfortably? The article on BoingBoing says "He cannot walk, has a hard time talking and swallowing, is extremely frail and needs full time care that is being provided by several friends-fans-volunteers and family." I doubt if it will make him comfortable, other than that he can avoid being homeless too.
RAW's writings offer real enlightenment. RAW taught us how to hack our brains and detect the fnords in the matrix. There's probably more of interest in the name of his paypal account than there is in your whole post.
RAW received some of my money. You won't! Bye.
P.S. Hope the Vogons like your poetry.
"Another 650,000 will be employed in the IT departments of businesses that rely on Vista"
I wonder what that says about Vista TCO? It can't be good, surely.
You've obviously never been in the cockpit of a Dakota (DC-3)...