The submitter mentioned that running twisted pair or coax was an option, so I was exploring the possiblity of running fiber instead. If you're going to be running cable, might as well go all out:)
<OFFTOPIC> Blah blah blah, can't post more than once every two minutes...makes it real easy to reply to comments in a thread you started, eh? </OFFTOPIC>
Oh yes, I know the problems with it. It's certainly not as easy as putting up a dish and making it work.
Notice also I was only referring to the in-the-lear channels (there are a few of them left, are there not?:)
It probably wouldn't even make up basic cable, though you could get some of the more interesting ones with enough dishes to cover the sats (I know my local cable co only has like 4 or 5 dishes tho (G5, G3, F3 and something else IIRC, it's enough to get all the basic channels).
Needless to say, you'd need a lot of equipment, I was just mentioning the possibility that if coax were run for a cable modem system, you could also run normal analog (and what the hell, digitial if you wanted to) cable over it.
If you're willing to run lines and fiber is possible, you can just run fiber from the most central place to everywhere else and run 100Mbit or GigE over it. Ethernet can go a very long distance over fiber.
If fiber is out of the option, you could run coax, get a CMTS (can be had on ebay for $5k-$10k) and run a cable modem system over your coax. You could also then get a big sat dish (not the DSS things, the C-Band things) and provide basic cable as well for a reasonable cost.
Failing coax, DSLAMs can also be had cheap and run over just about any kind of wire as long as it's twisted together:)
Basically, you're spread out enough that using the same technologies the telcos and cable services use is feasable. You could also start running T carrier, but that may get a bit expensive in terms of hardware.
As for wireless solutions, look into directional stuff (obviously). A mesh system may be most useful as it would allow the network to keep working even if one residence isn't reachable for repeating. Various 2.4GHz solutions exist, not just 802.11, or you could also look in to free-space optical. The RONJA project (google for it) is kidna neat, but probably not feasable in this situation.
Actually, the RFC specifies that in IPv6, not just a single bit, but rather multiple 128 bit "Strength Indicator" fields be present for packets with evil intent.
This provides firewall administrators with maximum flexibility in selecting which ill-intended packets to deny.
Yes indeed. I was at the HP Handhelds Developer Conference where the guy gave a presentation on this. He's very big on binaural microphone setups, where you have one mic by each ear, to completely replicate what your ears would hear. It's great when reproduced on headphones especially.
I know there is an h.323 conntrack module in the patch-o-matic, and I have various sources indicate that it does indeed work, at least for MS Netmeeting. There's also the option to use a h.323 proxy.
If you really want to do networking with your Linux box (I do it every day), 2.4 is superior in most ways. ipchains sucks compared to the Netfilter (iptables). The NAT is vastly improved, you can match based on just about any criteria (if the stateful matching isn't enough, you can also match randomly:), and the mangle table is also useful, especially when combined with traffic control. Oh, did I mention the whole host of traffic control facilities?
That's not to say there's no reason to stick with 2.2. I have yet to see a MS DirectPlay NAT helper module on 2.4. Also, 2.2 has been pretty well proven stable over the course of time. It's no longer a moving target, and it doesn't die. However, there's also a lot of compelling reasons to migrate to 2.4.
Linux 2.4 runs on my phone, my ipaq, my TV set-top box...
It also runs on tons of other things you wouldn't think it could possibly run on. uClinux (Linux for procs without MMUs) is even working with 2.5 now (in fact, I do believe it's merged into the vanilla 2.5 source tree).
The only reason I use 2.2 kernels anymore is when I need size. I can't get a very functional 2.4 kernel below about 500k, I can get 2.2 kernels down to about 400k easily, and I could probably make them smaller yet. Then again, I could always go get a copy of 2.0.39:)
Looks to me like all the hardware is supported. This means that you don't really need a keyboard attached, but you need one if you want a decent input method.
Here's the problem. Good handwriting recognition isn't easy to code. There's some projects, like xstroke (which is what is commonly used on ipaqs and other Pocket PCs running Linux with X11, not QTopia), but that's just a single stroke recognizer. It recognizes things very similar to Palm's Graffiti.
Basically, what he was trying to say was that it works great save the textual input functionality, which is still pretty much limited to external keyboard (you could also use an on screen keyboard, but then you give up valuable screen realestate).
VirtualDub isn't a realtime encoder. Your machine just happens to be fast enough to run the encoder in real time. A real time encoder will do whatever it takes to maintain sync with the input stream, including making it look unintelligable and/or dropping frames.
I believe mencoder has an option for this, or try possibly a webcam application of some kind (might end up with MJPEG, but that's more compressed than raw video).
Also, there is a port of VirtualDub to linux under way, though it wasn't usable last time I checked.
PKI has "Face Off". It's an inverted coaster with seats facing both directions. You get cranked out of the station "backwards" (relative to the direction where the rest of the track is) up a hill, then released. You then go around to another hill where you are held temporarily then released again to return to the station. It's certainly a roller coaster, but it isn't a closed circuit.
The wait time's horrible as the throughput is bad. The design only allows one train. However, it's a really cool ride as you get to do the same thing both backwards and forwards in one sitting.
Actually, with the blazing fast machines we have today, RAID 5 in software is sometimes faster than with a dedicated controller! Dedicated RAID controllers normally have i960s or ARM processors on them, which pale in comparison to the beast that is your 1GHz P3 CPU.
This doesn't mean that hardware RAID is bad or that software RAID is somehow better. A good RAID controller is sized to handle the expected load (there are some pretty beefy RAID controllers out there). However, RAID done entirely in hardware (unlike most IDE RAID systems, 3Ware being a notable exception) offers two distinct advantages.
1) No (or little) CPU overhead. Since all the checksumming and such is done in dedicated hardware, there is no CPU overhead. Of course sometimes (most of the time), this dedicated hardware is slower than your CPU (but with a properly chosen controller, one that fits the job at hand, you'll only notice it on reconstructions).
2) Big cache. The cheap hardware cards (that actually do everything in hardware) lack this, but there are RAID controllers that have battery backed cache RAM. I've seen cards with 64-128MB of cache! Since the data can be stored in cache while the checksumming is taking place (before it's transmitted to the disks), speed is dramatically improved on small (less than the size of the cache) bursts. Of course the problem here is when the power fails for so long that the battery on the cache drains completely. Choose your cache policy wisely.
The idea was to look at what these guys who put Linux in sub-64MB spaces and see what they use. These people spend a lot of their time making the system to making it fit in a reasonable amount of space. If size is a concern, chances are a project has addressed it before.
There are many efforts to putting Linux (and other UNIXes) in places with limited amounts of space.
handhelds.org is all about running Linux on ipaqs. Space is a concern, of course, so various things are done. The conversion to Busybox has recently been made, saving almost 2MB of space as I recall.
There's also uClibc. The smallest I've ever seen glibc is about 1.5-2MB. uClibc clocks in at about 200-700kB. That's small. This is used when you just don't have space available, such as on the TuxScreen with only 4MB of bootable flash and on many rescue disks and floppy based Linux systems.
Remember you don't want to cut corners all the time. On your desktop, it's probably best to run the full-blown GNU utilities. They have extra options that, while not commonly used, have obviously proven useful enough times to be included.
However, if you only have 16-64MB to work in, and you want to have lots of other stuff, busybox is a very viable option that I would reccomend if you have trouble fitting stuff in. Don't use it when you've got gigs of hard drive space to play with though.
You can run things other than IP over ethernet, and you certain don't have to run TCP over IP.
NetBEUI, the universally despised networking "protocol", is basically just passing raw SMB frames over ethernet. There is no reason you couldn't pass raw HDD data over ethernet.
However, ethernet is a VERY BAD option for this kind of thing. Unreliable protocol (data is not guaranteed to be delivered), collisions, etc. Just not a good idea.
For apps not running on the linux firewall itself, there's not much you can do as it's just network traffic like any other at this point. Any information regarding the app that generated it is only available from the system which created the traffic. However, creative use of the iptables string match may be useful, as could the queue target to queue the packet to userspace for further analysis.
For applications running on the box itself, the "ownercmd" module in the patch-o-matic may be useful for matching the name of the process. Unfortunately there is no guarantee that an app just hasn't changed it's process name to fake a more "trusted" app, but the base functionality is there.
I know this isn't exactly what you were looking for, as it uses iptables, but these are what I see as the options. Others may exist of course.
Twice a day? I put my iPAQ on the charger every night (pretty easy to do, just put it on the cradle before you go to bed) and it's fully charged in the morning.
I can easily get an entire day's worth of normal use (playing games like solitare for about 30min, doing normal work for a total of about 30min-1hr, suspended the rest of the time) out of it.
Running full tilt in full power mode, with backlight on but minimal, I can get 1.5-3hr out of it with no external battery. There are also sleeves that have an extra battery built in if you need more joice (and you get a PCMCIA slot or two, or a CF slot or two as a bonus:)
There has been some buzz regarding this recently from the handhelds.org crew as they port Linux to the H39xx series iPAQ. From what I gather, PocketPC is StrongARM optimized (and since you don't have the source, there's not much you can do about that).
The X-Scale (armv5) is completely backwards compatible with the StrongARM (armv4), but some instructions are faster than others. I believe the conclusion was that compiler optimizing for xscale would be beneficial to both platforms as the armv4 should run at about the same speed while the armv5 runs faster than before.
Note however that part of the reason you don't see huge performance increases is that (at least on the early xscales, possibly current ones too) the write-back cache is disabled due to some flaw in the chip. Oops:)
The kernel for these kinds of things is almost always crosscompiled (I know nobody who has actually done it natively). The xscale isn't really all that fast (and unless the fixed the bug, it also has write-back cache disabled) compared to your desktop. In addition to doing normal CPU bound activies, it also has to handle display and such, dragging it down even further. The integrated nature of the ARM makes it a great chip for PDAs, but it's not exactly a screamer in terms of performance (but it's pretty darned good!)
That absolutely cannot be true unless it's all RAM. If it were all RAM, you'd have to reload the OS every time you turned off the little power switch (including the bootloader, which would have to be done through some exotic means), so this is unlikely.
RAM and Flash are totally different things. For one, RAM is volitile and will lose it's state when power is removed; flash will not. You cannot somehow "redistribute" between them since they're physically separate and radically different chips.
However, if you're installing apps and such to your ram (a common thing to do), you may make a distinction between the ramdisk area (often implemented using Linux's tmpfs, which actually grows and shrinks dynamically up to a hard set limit at mount time) and system RAM, the area that programs run in.
Slashdot Mirror
Two words:
PEEK
POKE
ASCII stupid question, get a stupid ANSI I always say.
The submitter mentioned that running twisted pair or coax was an option, so I was exploring the possiblity of running fiber instead. If you're going to be running cable, might as well go all out :)
<OFFTOPIC> Blah blah blah, can't post more than once every two minutes...makes it real easy to reply to comments in a thread you started, eh? </OFFTOPIC>
Oh yes, I know the problems with it. It's certainly not as easy as putting up a dish and making it work.
:)
Notice also I was only referring to the in-the-lear channels (there are a few of them left, are there not?
It probably wouldn't even make up basic cable, though you could get some of the more interesting ones with enough dishes to cover the sats (I know my local cable co only has like 4 or 5 dishes tho (G5, G3, F3 and something else IIRC, it's enough to get all the basic channels).
Needless to say, you'd need a lot of equipment, I was just mentioning the possibility that if coax were run for a cable modem system, you could also run normal analog (and what the hell, digitial if you wanted to) cable over it.
If you're willing to run lines and fiber is possible, you can just run fiber from the most central place to everywhere else and run 100Mbit or GigE over it. Ethernet can go a very long distance over fiber.
:)
If fiber is out of the option, you could run coax, get a CMTS (can be had on ebay for $5k-$10k) and run a cable modem system over your coax. You could also then get a big sat dish (not the DSS things, the C-Band things) and provide basic cable as well for a reasonable cost.
Failing coax, DSLAMs can also be had cheap and run over just about any kind of wire as long as it's twisted together
Basically, you're spread out enough that using the same technologies the telcos and cable services use is feasable. You could also start running T carrier, but that may get a bit expensive in terms of hardware.
As for wireless solutions, look into directional stuff (obviously). A mesh system may be most useful as it would allow the network to keep working even if one residence isn't reachable for repeating. Various 2.4GHz solutions exist, not just 802.11, or you could also look in to free-space optical. The RONJA project (google for it) is kidna neat, but probably not feasable in this situation.
Actually, the RFC specifies that in IPv6, not just a single bit, but rather multiple 128 bit "Strength Indicator" fields be present for packets with evil intent.
This provides firewall administrators with maximum flexibility in selecting which ill-intended packets to deny.
Yes indeed. I was at the HP Handhelds Developer Conference where the guy gave a presentation on this. He's very big on binaural microphone setups, where you have one mic by each ear, to completely replicate what your ears would hear. It's great when reproduced on headphones especially.
One may also want to check out grsecurity.net.
Apparently AOL/TW have gotten a lot more agressive at cracking down on TOS violations.
I know there is an h.323 conntrack module in the patch-o-matic, and I have various sources indicate that it does indeed work, at least for MS Netmeeting. There's also the option to use a h.323 proxy.
:), and the mangle table is also useful, especially when combined with traffic control. Oh, did I mention the whole host of traffic control facilities?
If you really want to do networking with your Linux box (I do it every day), 2.4 is superior in most ways. ipchains sucks compared to the Netfilter (iptables). The NAT is vastly improved, you can match based on just about any criteria (if the stateful matching isn't enough, you can also match randomly
That's not to say there's no reason to stick with 2.2. I have yet to see a MS DirectPlay NAT helper module on 2.4. Also, 2.2 has been pretty well proven stable over the course of time. It's no longer a moving target, and it doesn't die. However, there's also a lot of compelling reasons to migrate to 2.4.
Linux 2.4 runs on my phone, my ipaq, my TV set-top box...
:)
It also runs on tons of other things you wouldn't think it could possibly run on. uClinux (Linux for procs without MMUs) is even working with 2.5 now (in fact, I do believe it's merged into the vanilla 2.5 source tree).
The only reason I use 2.2 kernels anymore is when I need size. I can't get a very functional 2.4 kernel below about 500k, I can get 2.2 kernels down to about 400k easily, and I could probably make them smaller yet. Then again, I could always go get a copy of 2.0.39
Looks to me like all the hardware is supported. This means that you don't really need a keyboard attached, but you need one if you want a decent input method.
Here's the problem. Good handwriting recognition isn't easy to code. There's some projects, like xstroke (which is what is commonly used on ipaqs and other Pocket PCs running Linux with X11, not QTopia), but that's just a single stroke recognizer. It recognizes things very similar to Palm's Graffiti.
Basically, what he was trying to say was that it works great save the textual input functionality, which is still pretty much limited to external keyboard (you could also use an on screen keyboard, but then you give up valuable screen realestate).
VirtualDub isn't a realtime encoder. Your machine just happens to be fast enough to run the encoder in real time. A real time encoder will do whatever it takes to maintain sync with the input stream, including making it look unintelligable and/or dropping frames.
I believe mencoder has an option for this, or try possibly a webcam application of some kind (might end up with MJPEG, but that's more compressed than raw video).
Also, there is a port of VirtualDub to linux under way, though it wasn't usable last time I checked.
PKI has "Face Off". It's an inverted coaster with seats facing both directions. You get cranked out of the station "backwards" (relative to the direction where the rest of the track is) up a hill, then released. You then go around to another hill where you are held temporarily then released again to return to the station. It's certainly a roller coaster, but it isn't a closed circuit.
The wait time's horrible as the throughput is bad. The design only allows one train. However, it's a really cool ride as you get to do the same thing both backwards and forwards in one sitting.
Actually, with the blazing fast machines we have today, RAID 5 in software is sometimes faster than with a dedicated controller! Dedicated RAID controllers normally have i960s or ARM processors on them, which pale in comparison to the beast that is your 1GHz P3 CPU.
This doesn't mean that hardware RAID is bad or that software RAID is somehow better. A good RAID controller is sized to handle the expected load (there are some pretty beefy RAID controllers out there). However, RAID done entirely in hardware (unlike most IDE RAID systems, 3Ware being a notable exception) offers two distinct advantages.
1) No (or little) CPU overhead. Since all the checksumming and such is done in dedicated hardware, there is no CPU overhead. Of course sometimes (most of the time), this dedicated hardware is slower than your CPU (but with a properly chosen controller, one that fits the job at hand, you'll only notice it on reconstructions).
2) Big cache. The cheap hardware cards (that actually do everything in hardware) lack this, but there are RAID controllers that have battery backed cache RAM. I've seen cards with 64-128MB of cache! Since the data can be stored in cache while the checksumming is taking place (before it's transmitted to the disks), speed is dramatically improved on small (less than the size of the cache) bursts. Of course the problem here is when the power fails for so long that the battery on the cache drains completely. Choose your cache policy wisely.
Hum, Looks like I forgot my conclusion :)
The idea was to look at what these guys who put Linux in sub-64MB spaces and see what they use. These people spend a lot of their time making the system to making it fit in a reasonable amount of space. If size is a concern, chances are a project has addressed it before.
There are many efforts to putting Linux (and other UNIXes) in places with limited amounts of space.
handhelds.org is all about running Linux on ipaqs. Space is a concern, of course, so various things are done. The conversion to Busybox has recently been made, saving almost 2MB of space as I recall.
There's also uClibc. The smallest I've ever seen glibc is about 1.5-2MB. uClibc clocks in at about 200-700kB. That's small. This is used when you just don't have space available, such as on the TuxScreen with only 4MB of bootable flash and on many rescue disks and floppy based Linux systems.
Remember you don't want to cut corners all the time. On your desktop, it's probably best to run the full-blown GNU utilities. They have extra options that, while not commonly used, have obviously proven useful enough times to be included.
However, if you only have 16-64MB to work in, and you want to have lots of other stuff, busybox is a very viable option that I would reccomend if you have trouble fitting stuff in. Don't use it when you've got gigs of hard drive space to play with though.
You can run things other than IP over ethernet, and you certain don't have to run TCP over IP.
NetBEUI, the universally despised networking "protocol", is basically just passing raw SMB frames over ethernet. There is no reason you couldn't pass raw HDD data over ethernet.
However, ethernet is a VERY BAD option for this kind of thing. Unreliable protocol (data is not guaranteed to be delivered), collisions, etc. Just not a good idea.
For apps not running on the linux firewall itself, there's not much you can do as it's just network traffic like any other at this point. Any information regarding the app that generated it is only available from the system which created the traffic. However, creative use of the iptables string match may be useful, as could the queue target to queue the packet to userspace for further analysis.
For applications running on the box itself, the "ownercmd" module in the patch-o-matic may be useful for matching the name of the process. Unfortunately there is no guarantee that an app just hasn't changed it's process name to fake a more "trusted" app, but the base functionality is there.
I know this isn't exactly what you were looking for, as it uses iptables, but these are what I see as the options. Others may exist of course.
Twice a day? I put my iPAQ on the charger every night (pretty easy to do, just put it on the cradle before you go to bed) and it's fully charged in the morning.
:)
I can easily get an entire day's worth of normal use (playing games like solitare for about 30min, doing normal work for a total of about 30min-1hr, suspended the rest of the time) out of it.
Running full tilt in full power mode, with backlight on but minimal, I can get 1.5-3hr out of it with no external battery. There are also sleeves that have an extra battery built in if you need more joice (and you get a PCMCIA slot or two, or a CF slot or two as a bonus
iPAQ is definately SA-1110 at 206MHz, same as the old Zaurus.
:) It's all emulated in software.
You may be thinking the older HP Jornadas, which had Hitachi Super-H procs?
Also, the reason for the bad floating point is that they lack hardware support for it
There has been some buzz regarding this recently from the handhelds.org crew as they port Linux to the H39xx series iPAQ. From what I gather, PocketPC is StrongARM optimized (and since you don't have the source, there's not much you can do about that).
:)
The X-Scale (armv5) is completely backwards compatible with the StrongARM (armv4), but some instructions are faster than others. I believe the conclusion was that compiler optimizing for xscale would be beneficial to both platforms as the armv4 should run at about the same speed while the armv5 runs faster than before.
Note however that part of the reason you don't see huge performance increases is that (at least on the early xscales, possibly current ones too) the write-back cache is disabled due to some flaw in the chip. Oops
Probably a very long time.
The kernel for these kinds of things is almost always crosscompiled (I know nobody who has actually done it natively). The xscale isn't really all that fast (and unless the fixed the bug, it also has write-back cache disabled) compared to your desktop. In addition to doing normal CPU bound activies, it also has to handle display and such, dragging it down even further. The integrated nature of the ARM makes it a great chip for PDAs, but it's not exactly a screamer in terms of performance (but it's pretty darned good!)
That absolutely cannot be true unless it's all RAM. If it were all RAM, you'd have to reload the OS every time you turned off the little power switch (including the bootloader, which would have to be done through some exotic means), so this is unlikely.
RAM and Flash are totally different things. For one, RAM is volitile and will lose it's state when power is removed; flash will not. You cannot somehow "redistribute" between them since they're physically separate and radically different chips.
However, if you're installing apps and such to your ram (a common thing to do), you may make a distinction between the ramdisk area (often implemented using Linux's tmpfs, which actually grows and shrinks dynamically up to a hard set limit at mount time) and system RAM, the area that programs run in.
It woudl appear so: simply don't use it.
You voluntarily use the entangled page to voluntarily give the info to the proxy.
In fact, the link to the original page is at the top of the entangled page, allowing you to browse without contributing to the stats in any way.
Just FYI, there is a port of GTK+ to Windows. Stability is a bit dodgy at times (especially with 2.0 versions), but it does exist.
The GIMP for windows makes heavy use of it (obviously, seeing how the GIMP would be the original app using GTK+).
Some GIMP and GTK+ for windows info can be found here and here.
--MonMotha
Didn't you forget Microsoft Works? That has got to be the biggest oxymoron of all time.