A number of TurboPower's components (such as AsyncPro) are already available for Kylix. Also TurboPower were known for helping out Borland with Kylix, particularly by helping pioneer a number of components moving to Kylix.
One problem with running cable in some places is when the building is old and Heritage listed (or covered by some protection scheme). When you aren't allowed to put holes in the walls, dig up the floors, cut through the ceilings, or even as much as scratch the paint, you have to look at using things like HomePlug, HomePNA or Wireless.
I know a number of Catholic (and other) schools that have deployed HomePNA and/or Wireless so they can use computers in such buildings. Some of the buildings don't even have normal phone lines in them, and instead they use VoIP phones hanging off a Wireless Ethernet Bridge.
Depends on the equipment. Some cards have a connector for a second "receive only" antenna, and can (in most cases) be configured to use them for the purpose you're after. These cards aren't cheap though, so expect to pay a bit more for them.
Cards that support this sort of thing are usually noted as being capable of "Diversity", which is used mainly for noise cancellation in reflective environments, but could be used for a send/receive antenna scheme. You would want to separate your antennas by a big margin though, to avoid any sort of interference. Separation by something that reduces 2.4 Ghz signals would be best.
So many people take anti-biotics for everything, and don't complete their prescribed courses, that people forget the other tried and true methods of helping your body and immune system fight a cold.
1. Inhalation of steam and an antiseptic agent.
Eucalyptus oil or Tea Tree oil in water, then heated/boiled is a great way to kill off bugs in the air. Very good for throat/nasal infections. Scented burners are good value for this.
2. Acidic foods/liquids.
This includes oranges, lemons, apples, grapefruit and tomato, including juices of those. Vinegar, particularly cider and malt vinegar, can be good if used as a mouth wash/gargle or ingested (if you can). Salt is also a good thing to ingest when ill, but as always, too much is bad for you. Yes, I am advocating salt'n'vinegar potato chips here. *grin*
3. Mouth washes.
Cider and malt vinegar work well, as does salt water. Iodine throat wash (commonly found under the "Betadine" brand) is also very good, but don't swallow it. Listerine and other mouth washes (for teeth care/plaque) are also good value. And brush your teeth too.
4. Suppliments/herbal treatments.
Echinacea, and other herbal suppliments can help, though be warned that some may have bad or deadly side affects for some people. Ginger is used lots in Chinese medicine, and is apparently quite good for helping someone overcome a cold, but some people are allergic to it. Vitamin suppliments are also good if you haven't been eating right, or can't keep a lot of food down.
5. Fluids.
The kidneys are a primary place for a virus to be flushed from the human body. Don't drink too much though, as it is possible to kill yourself from taking too much fluids.
6. Regular wash/shower.
Sweat is another way for fluids to leave the body, and regular washing helps remove some viruses.
This is not a definitive list. But I'm hoping someone out there might find it useful. There are a lot of NATURAL ways to fight a cold. The goal is to help out the body. If that is by helping to remove the virus or most of the things the body fights against on a regular basis (air-born contaminants, throat bourne virii, etc), then you body will have more resources to chuck at other areas. Just think of the whole thing as a resource based game, where you are the resource. Remember though that too much of something can be bad though, so balance things out.
There are already CD images of Sarge about (pre-release of course, and at the moment they are not bootable - waiting on the new installer).
Something else of note to look at Re: Debian is Jigdo.
Jigdo basically downloads all the individual files from Debian mirrors, and "makes" the CD image. Jigdo can be used on mirrors to avoid having to transfer the whole CD image (and if you run a mirror, you'll probably have all the *.deb's on hand anyway), while still being available for use by end users. As the *.deb's are more likely to be cached, wether in a proxy or via a mirror, this can result in a speed-up for downloading an image. It also supports upgrading only the files that have changed (eg: for keeping up-to-date images of stable), without downloading the whole CD image. Much better than trying to do something silly like rsync against the old image.
PS: I don't believe that Jigdo is limited to use with Debian, but like apt, it's another tool that was produced to address a specific need within the Debian community.
Not that you'd probably want to use the water afterwards, but there is no reason you can't use it beforehand.
Using waste water could work. Wether reclaimed from air, or from body fluids, this would only have been jettisoned into space or reprocessed (and reprocessed water tastes like crap!) anyway.
For that matter, waste biomatter may actually be good at shielding radiation, but you wouldn't want a leak anywhere on the inside of the station! Ewwwww!
Also, you could generate oxygen and hydrogen from water by electrolysis (well you'd have big solar panels anyway). You could use these as a propellant, since any craft at the L1 point still would need some sort of station keeping thrusters (any craft docking/departing the station, or small impacts from space debris, will change the station's balance and momentum, knocking it out of the "perfect centre" it should be sitting at), and this could provide some of the required fuel. Or you could use some of the oxygen to add to the air mix, and the hydrogen in fuel cells.
Only problem with using a liquid as a shield is that when the station is in darkness it'll be frozen, and when it's in light it'll be warm or boiling. Water changes a LOT in volume with heat, so the hull would have to be able to stand that change. And any leak where there is liquid or steam would have to be plugged, otherwise you'd end up with the liquid ejecting into space and propelling the station out of it's nice stable placement.
In the meantime, just make sure the astronauts dose up on their caffiene and they'll be fine. *grin*
I notice a lack of Debian in there. I could guess a number of Debian sys admins would find this reassuring.
No, I'm not advocating that they should be slack about updates, but it's interesting to see that Debian isn't listed. Remember to "apt-get update ; apt-get upgrade" all you Debian admins!
I would also guess this may be due to the way Debian package numbering works. Where possible, Debian will not upgrade a version number of a package when they fix a problem in the stable distribution. Instead, they will patch the existing version, and release a sub-version of the software to solve the exploit. This means that you can't simply look at the version (eg: whatever Apache returns) and determine if the program is exploitable.
The build system in Apache 2, while being vastly improved over the Apache 1 build system, is rather complicated, and has lead to a number of packagers simply not bothering, or having a hell of a time packaging it.
There is no RedHat or Debian packages of Apache 2.0 (offical as in from RedHat or Debian, and part of their stable distribution). There are a few Debian people who are packaging Apache 2.0 (namely Thom May, who is the current package bunny...err...maintainer *grin*), but last I heard they were having a horrible time getting it working, and it's still only in unstable (sid), and hasn't made it to testing (sarge).
If it gets into RedHat and Debian's stable distributions, chances are it'll make a higher percentage mark on site usage. Till then, I don't think things are going to change much.
CueCats aren't the only barcode scanners that will handle the longer formats. In fact, any company that sells barcode scanners outside of the US will be able to scan the EAN formats. It's simply a matter of reprogramming the scanner (which may require a small piece of software on a PC or just a matter of scanning programming codes into the scanner). And what other brands are out there probably use the scan engines from other companies, so at the most it'd be a software change, or possibly (at the worst) a rom upgrade.
Also many barcode scanners can be programmed to spit out a leading 0 on UPC 12 digit codes, so that the output is ALWAYS 13 digits, wether it's a UPC or EAN code that is scanned. UPC and EAN are basically the same format barcode, with subtle differences in what constitutes the 13th character in the code. It's not I2of5 or Code 39, which are other symbology types. The 14 digit ones are a mixed barcode type, but I don't know how popular they will be.
EAN has already specified EAN-128, which is the EAN code standard using the Codabar 128 barcode format. This allows VERY LONG barcodes, and many of these are for packaging in the warehouse, where you are marking boxes of items, or a shipping crate full of boxes, etc.
So the bogus comment in the NYT that everyone would have to upgrade their scanners is just that. Bogus. If anything, it's the sightless people that developed the databases behind the scenes that will be the problem. Now what does this remind me of..... oh yeah. Y2K. *sigh*
I'll only touch on Magnetic and Tilt switches, as the others have adequately been covered by a number of people.
Magnetic switches are easily and cheaply bought anywhere you can get house alarm parts. They are very simple, last a lifetime, and work really well. Using a tiny magnet strapped to a finger allows you to use a number of reed switches so there is a choice of "what to do".
Tilt switches are easily worn on the finger, or on the head. Some care must be taken to encase the deadly mercury as the glass container may be easily broken, and mercury is poisonous. The way I would encase such switches would be by first finding a glue that is capable of sticking to GLASS and plastic, and coating the glass covered mercury switch in it. This way, if the glass cracks, the pieces will usually stay together. Let it dry, then dip it in hot plastic a number of times. You can then put it inside a piece of dense foam rubber (use a glue that sticks to rubber and plastic to keep it in place). The goal is that if you accidently stand on it, it won't break.
I've used both methods before to provide something that a disabled child can use, usually to encourage them to make some sort of movement. One Example: Mercury tilt sensor attached to a head strap with velcro (for position adjustment), to encourage the child to 'lift' their head (helps build up the neck muscles and train the brain). The mercury switch was usually wired into a radio or tape deck, switching it on or off. It also provided some real insight into what sort of music some of the kids liked, as after a little training, they would drop their head when something they didn't like would come on, and then every now and then raise their head to "check" what was playing now.
Suggestions:
Hook up a touch or contact switch (this has already been mentioned to death in here) to some sort of wireless remote. The receiver can then be worn by the husband allowing contact while not physically in the room. At night the husband can put it on a bedside table or something.
Better is to use a pair of (cheap) walkie talkies, that have a morse code option. This still allows the husband mobility, and he can actually respond to his wife without being physically present. This can allow some very simple but effective "Yes, No, I don't know, Help" conversations, as the husband can ask questions, while say, doing stuff in the back yard or garage, and can easily respond to allieve his wife's fears (eg: "I'll be there in a minute", "I'm coming!", etc). The only issue might be one of frequency use (by kids and so on), but you could always go to some of the commerical variants that have their own band/use digital transmission to avoid interference, or maybe modify the walkie talkies to use a different frenquency.
If you give her 3 or 4 touch sensors, then she can (technically) type easily. Remember how you enter your name in a video arcade game? Exactly the same idea. You could also use multiple buttons to scroll between pre-canned answers or words, such as "drink", "help", etc. You could even combine this with some sort of voice synthesis program to generate speech. And there is no reason you couldn't integrate this with the walkie talkie idea, so that she and her husband can communicate over a distance. Hell, she could send SMS's this way, use a phone, or even web browse, use e-mail or perhaps IRC. Might help her relieve some of the (potential) boredom in her life, that being so limtied in mobility would probably create. There are a number of easy ways to interface input into a PC, such as the joystick, parallel or serial ports, and lots of documentation. There are also a fairly large number of devices that will convert serial input into PS/2 keyboard or USB keyboard input, which allows use of a PC in a somewhat normal manner.
If you do go for something complicated (eg: a PC System), ALWAYS have a backup (preferrably battery operated) like the walkie talkie idea. Systems fail, the power goes off, etc, and the last thing you want is it to fail when she needs it most.
You may want to look at the fnk (or cipherfunk) kernel tree (no this is not carried on kernel.org). The link at freshmeat for cipherfunk kernels has connections for downloading and so on. His kernel tree contains the GRSecurity patches, a fair number of other patches (eg: FreeS/WAN), and any fixes he's made to get the lot running.
Basically this guys motivation is security and stability. He puts the whole lot through a barrage of tests, and makes sure things work, or at least determines if there is a problem and makes note of it.
Well, there are a number of factors that are misleading here. Unfortunately a lot of people don't get the real picture. Here are some useful things to know about Debian and HP.
1. Debian's current "Project Leader" is now Bdale Garbee, who works for HP, making sure that Debian (and the Linux Kernel) runs quite happily on the IA64 platform. Most of Bdale's changes have gone back upstream to developers, and have since filtered down to RedHat. I would not be surprised if RedHat actively watches Bdale's code changes to speed this process up. A number of other HP employees work on Debian, and in some cases, were hired by HP after already starting work on Debian.
2. Woody is the only version of Debian that will work properly on IA64, and for the IA64 architechure it uses a 2.4 series kernel. If you haven't used Woody, or used the installer, don't even bother to comment.
3. HP provide a "base system" installed on their machines. They also provide a software loader, that allows you to "choose" what version of Linux is installed. This then copies a pre-installed copy of the chosen OS over the existing system. At least on IA64, the distributions that were going to be bundled were: Debian, RedHat, Suse, Mandrake. The reason I say were, is that I last heard about this directly from Bdale at LCA 2002 (Brisbane, Australia) and there is this whole United Linux thing that may have changed what will happen with Suse somewhat.
4. HP has put it's money where it's mouth is concerning Debian. A number of HP IA64 and HPPA machines have been GIVEN to the Debian community to use as development systems and package builders. They also paid the legal bill to find out just where the legal stance is on having crypto software directly in the main archive.
5. If you want to see JUST how many packages work under Debian (particularly in reference to the IA64 architecture), you should probably look at the Debian Builder Statistics page. Approximately 94% of all of packages in Woody build on IA64. There is over 8000 packages in Debian Woody.
6. Interestingly in reference to your "support" comment, perhaps you may not know that Debian's package update for the recent Apache "Chunked Transfer Encoding" vunerability was released by the security team recently. The update message I recieved from the Apache announce list and the Debian security mailing list (both announcing fixes for the bug) were within 90 minutes of each other, and in both cases files were on the mirrors at the time the notification was released. I personally think this is pretty efficient.
I use Debian in my workplace. It works very well for us. We used to use RedHat and it caused us lots of problems, particularly with upgrading and maintenance, but also when it came to configuration. This is my personal opinion, but I believe my reasons of choice are valid. YMMV.
With point to point links you really need to evaluate antennas and your area. Many people use antennas with a wider radiation distribution pattern than is necessary, simply because it does the job. A number of cheaper antennas also have terrible front-to-back noise ratio, so noise from behind or the side of the antenna can really affect the signal. Also remember that many antennas allow you to orient the polarisation of the signal by the way they are mounted, and some antennas even have circular polarisation.
With general network setups (eg: an office) many people have a tendancy to put an AP on the edge of the building, particularly in warehouses (simply because there is little else to support it). Semi-directional antennas (with 60-180 degree coverage patterns) are VERY useful for walls and corners, and usually have a higher gain in the direction you want (away from the wall or corner, into your business). The less signal that escapes your premesis, the less chance of interference, and also the harder it is to get an outside connection (ie: war driving).
If your setup doesn't allow for outside interference, and is very succeptable to it, you'll always have problems.
Phase matching the antennas is the biggest pain, simply due to the high frequency (and therefore small wavelength). Many AP's and some cards provide 2 antenna sockets for a system called diversity.
Diversity actually is best used to reduce multipath signals, as the radio listens to both signals, and "picks" the best signal to use from the 2 it received. Since both antennas are in different physical locations (from a few inches to about 2 feet is best), each antenna gets a different signal. Do not place these antennas in largely disparate locations, or seperated by some interfering object (like a steel support beam), as diversity works best when it can see the signal at BOTH antennas.
There are a huge variety of antennas out there, that produce different polarisation and radiation patterns. Some antennas have receiving amplifiers that produce huge (30+ dB) gain on receive, while only producing about 7dB gain on transmit. Semi-directional (from 60 degree to 180 degree coverage) antennas are great for outside walls. Some have clockwise or counter-clockwise "Circular" polarisation patterns instead of the average horizontal or vertical (circular polarisation tends to be better for point to point applications, and your antennas should match each other - CW will talk to CCW).
I think you missed his original idea, which is that you should implement a VPN, and still turn on WEP and ACL matching. This way, they'll break the ACL match, break WEP, and then go "Ahh crap! A VPN!", which at that point they may decide it's just too much to break. A VPN by itself, makes the job to break it easier, (even if not too much easier).
Would you still leave your car doors unlocked if you had an engine immobilizer?
You may consider deploying BOTH 802.11b and 802.11a. There are devices that support both, such as the Cisco 1200, but no wireless cards for 802.11a yet (due August/September 2002). There are also devices that work with your existing Access Point, such as Symbol's Mobius 5224, which sits over an existing Symbol 802.11b access point, uses the same network cable (provides a second network port for the 802.11b AP) and even provides power for the old AP.
If you go with 802.11a for any reason though, be warned, the cell sizes are MUCH smaller. The slowest 802.11a speed of 5 Mbit/s gives you coverage to about the same distance as 802.11b does at 5.5 Mbit/s. At least with 802.11b you can go slower in areas where the coverage is marginal.
Antennas can make a big difference to your coverage pattern, and should not be underestimated. Using semi-directional antennas is also a good way to avoid or reduce outside coverage on a building, which makes it that little bit harder for carpark hackers to get in. If you have a lot of metal around, look at using diversity (2 antennas seperated by a small distance - each antennas signals are compared and the best signal is used), which will improve coverage and reduce dropouts.
You will also want to consider the number and type of client radio's connecting to your 802.11b network. While 2 AP's might provide coverage, you may find the density of users brings everything to a crawl. Decent AP/Client card combo's will load balance across multiple AP's if the signal strength is there. Some AP's (particularly Cisco's) have a real problem delivering speed to more than 2 clients from a single AP at the same time, as they don't load balance (internally) properly. You will find 2 clients will get almost all the bandwidth, and the rest will get a tiny amount (eg: 4-10Kbit/sec). This is totally unacceptable for high user densities.
As for security, there are a number of authentication systems out there that seem reasonable, such as EAP/TLS, and Kerberos based implementations, all implemented in the AP. Authenticating using DHCP and MAC addresses is not worth it, as you can fake MAC addresses easily, and you can always use a fixed IP. That said, if the AP has MAC level Access Lists, USE THEM where possible, with other security methods. Just makes it that little bit harder.
EAP/TLS is the newcomer on the market, and usually relies on a Radius server for it's back end authentication. This is OK, as long as your users don't roam about at all. If they roam from one AP to the next, you will get delays of ~300ms as the AP re-authenicates itself with the Radius server. This might be OK if your users don't move around much, but is totally unacceptable if they are mobile in any way. All the Kerberos authentication systems I have seen distribute details to all the AP's at authentication time, so that roaming is about 50ms or less.
With encryption, if you have WEP, enable it. Once again, like with MAC level ACL's, it's just one more thing for them to get through. Many AP's now support Dynamic WEP, or TKIP (Temporal Key Integrity Protocol). There are also some devices that support AES based encryption methods, and I wouldn't be surprised to see TKIP implemented with AES instead of WEP out there as well.
Of course, you could also use a VPN solution like IPSec. I'd also recommend to use large keysizes, simply because you can. If you do use a VPN, STILL use WEP/TKIP/AES and ACL's, as it'll make it just that little bit harder to try and get into.
Remember, the object is deter them from trying to break into your network. If they try long enough, they'd probably still eventually break in. But if they can break into another system in 1/100th of the time, then unless they have a major grudge or very specific reason, they'll go that way.
This might be a good reason to look at the Symbol offering. Symbol have been working in the hand held computing area for a long time, and have developed a lot of very power-efficient hardware, particularly in the wireless arena. All of their radio cards have various power saving modes, many that you don't/won't see supported by other vendors.
Just like most Point Of Sale machines, they are just PC's with extra hardware. That is, if they bother. Many are just plain jane PC's, with things like the pole display and cash draw all driven by the printer, while the barcode scanner is plugged in through a keyboard wedge, so it emulates keyboard input.
If you're so interested in this, try developing a whole graphical (note: graphical as in has to look similar to their existing Windows setup) Point Of Sale system that will be using FrameBuffer, that will end up running on 486-dx33's, with 16 meg of RAM, and a whopping 420 meg of h/drive space. The place I work for is doing this for an Australia wide chain so that they can install it on their existing hardware. They are in a 'contract' with the old POS supplier to keep the hardware on the desks for a few more years. Poor bastards!
We have most of the extra hardware working (a whole 2 extra serial ports - and while it has a PCMCIA flash card reader, it isn't even worth the worry). The Point Of Sale program itself is written in Kylix (was originally a Delphi app on Windows), using SDL as an interface between the FrameBuffer and Kylix. Fun fun fun!!
You still really don't want any sort of radiation or radiation leak in Antartica, even if the risk might be low. One thing history has taught us is that statistics might make us feel safe, but we rarely are. We also grow complacent, and then disaster befalls us.
However Antartica and the Artic would be an ideal place to build a rail-gun transport system, using magnetism to build up speed and takeoff velocity. Getting up to speed from nothing is by far the most fuel consuming part of the process.
Once you leave the launch ramp, you can use conventional Liquid Oxygen/Hydrogren fuels to get out of the atmosphere. LOx & LH are probably the BEST choices for use, simply because the byproduct is water, and not a pollutant like most of the other propellant mixes. And dropping water vapor over the polar cap is not going to do it any harm, more likely do it some good.
The cold is a useful ally for such a setup. Less energy required to put oxygen and hydrogen into a liquid form, an abundance of water for producing oxygen and hydrogen via electrolysis, and a huge amount of wind and solar energy that can be harvested for power (in the right locations). There is also the semi-conductor properties that some substances exhibit in cold conditions that could be exploited.
Once launched, an orbiting docking facility can then fuel up a craft for longer hauls. With decent designs, the propulsion unit would be separate (and have a standard docking system) allowing changeover in orbit for another unit more suited for the job at hand, such as a nuclear propulsion unit for intra-solar missions, or one of the many other propulsion systems that are in the works.
If someone comes up with a smaller or more efficient engine design, a standard docking system between the propulsion unit and the craft allows easy retrofitting and upgrading. Craft returning to the Earth can bring back propulsion units so they can be tested, retrofitted, refueled and relaunched on the next craft.
There is this wonderful thing that people say when their package doesn't compile on another platform...
"But it works on my Pentium!"
So many apps out there are not 64 bit clean, and they will need to be in the not so far future. A hell of a lot of the Debian package people have been doing a brilliant job to make the packages available compile and work on 64 bit platforms. Bdale Garbee is probably the most well known identity working on this effort and has put a lot of effort into porting to Debian to new architectures.
Not all packages are destined to get ported to every architectures (eg: there is no sound device on an S/390, so no real need to have certain sound packages: But don't forget things like network sound architectures!), but most are, and a lot of it is developers who have no understanding of the issues caused by a 64 bit environment.
"But who cares about Alpha?"
If you think Alpha is the only platform that will benefit from 64 bit clean code, think again! There are a fair number of 64 bit platforms, like ia64 and PA-Risc. Fixing such problems will make such software work on all 64 bit platforms.
One last thing to note is that sometimes it's good to have a different perspective on things occasionly. Not everything revolves around the ia32 (i386, etc) platform like everyone generally seems to think.
I think that the people at Blizzard are real assholes when it comes to Linux... And that really gets to me, because I definately would have bought a Starcraft port.
Same, and I know a lot of people who currently dual-boot to play games like StarCraft who have said they would happily buy such a port.
I don't have Windows installed on my machine at home (thankfully!) and I've only used Wine to run the installer for Return To Castle Wolfenstein. Every install of Windows I've had has had 'issues' (particularly video and motherboard drivers), which I am glad to say I have not had under Linux. And since I didn't have to pay for Windows (since I don't use it), I got to spend just that little extra on my machine so I could buy decent, quality components - makes all the difference for stability, no matter what OS you run.
maybe if they had ported some halfway decent games they wouldn't be in this situation. Where is CounterStrike or Starcraft?
I'd ask this question of Valve & Sierra (re: Half-Life/CounterStrike) and of Blizzard (re: StarCraft). Loki only ported games, and unless they got the code and the permission to port the game from the authors, then they couldn't do it.
I'm really somewhat surprised that Sierra/Valve dissed the idea of a Linux client port. They had OpenGL code already, and they had a Linux server port. The audio shouldn't have proved that much of a problem, and I'm pretty sure it would have done QUITE well with Linux gamers. Almost all of Blizzard's stuff was Direct3D only, which does make it harder to port.
I'll miss 'em. I own Q3A (metal box), Unreal Tournament, Tribes2, Soldier of Fortune, Rune, and Kohan. I paid for every damn one of them, and I'm glad I did.
Slashdot Mirror
A number of TurboPower's components (such as AsyncPro) are already available for Kylix. Also TurboPower were known for helping out Borland with Kylix, particularly by helping pioneer a number of components moving to Kylix.
One problem with running cable in some places is when the building is old and Heritage listed (or covered by some protection scheme). When you aren't allowed to put holes in the walls, dig up the floors, cut through the ceilings, or even as much as scratch the paint, you have to look at using things like HomePlug, HomePNA or Wireless.
I know a number of Catholic (and other) schools that have deployed HomePNA and/or Wireless so they can use computers in such buildings. Some of the buildings don't even have normal phone lines in them, and instead they use VoIP phones hanging off a Wireless Ethernet Bridge.
Depends on the equipment. Some cards have a connector for a second "receive only" antenna, and can (in most cases) be configured to use them for the purpose you're after. These cards aren't cheap though, so expect to pay a bit more for them.
Cards that support this sort of thing are usually noted as being capable of "Diversity", which is used mainly for noise cancellation in reflective environments, but could be used for a send/receive antenna scheme. You would want to separate your antennas by a big margin though, to avoid any sort of interference. Separation by something that reduces 2.4 Ghz signals would be best.
So many people take anti-biotics for everything, and don't complete their prescribed courses, that people forget the other tried and true methods of helping your body and immune system fight a cold.
1. Inhalation of steam and an antiseptic agent.
Eucalyptus oil or Tea Tree oil in water, then heated/boiled is a great way to kill off bugs in the air. Very good for throat/nasal infections. Scented burners are good value for this.
2. Acidic foods/liquids.
This includes oranges, lemons, apples, grapefruit and tomato, including juices of those. Vinegar, particularly cider and malt vinegar, can be good if used as a mouth wash/gargle or ingested (if you can). Salt is also a good thing to ingest when ill, but as always, too much is bad for you. Yes, I am advocating salt'n'vinegar potato chips here. *grin*
3. Mouth washes.
Cider and malt vinegar work well, as does salt water. Iodine throat wash (commonly found under the "Betadine" brand) is also very good, but don't swallow it. Listerine and other mouth washes (for teeth care/plaque) are also good value. And brush your teeth too.
4. Suppliments/herbal treatments.
Echinacea, and other herbal suppliments can help, though be warned that some may have bad or deadly side affects for some people. Ginger is used lots in Chinese medicine, and is apparently quite good for helping someone overcome a cold, but some people are allergic to it. Vitamin suppliments are also good if you haven't been eating right, or can't keep a lot of food down.
5. Fluids.
The kidneys are a primary place for a virus to be flushed from the human body. Don't drink too much though, as it is possible to kill yourself from taking too much fluids.
6. Regular wash/shower.
Sweat is another way for fluids to leave the body, and regular washing helps remove some viruses.
This is not a definitive list. But I'm hoping someone out there might find it useful. There are a lot of NATURAL ways to fight a cold. The goal is to help out the body. If that is by helping to remove the virus or most of the things the body fights against on a regular basis (air-born contaminants, throat bourne virii, etc), then you body will have more resources to chuck at other areas. Just think of the whole thing as a resource based game, where you are the resource. Remember though that too much of something can be bad though, so balance things out.
There are already CD images of Sarge about (pre-release of course, and at the moment they are not bootable - waiting on the new installer).
.jigdo files for debian at http://www.debian.org/CD/jigdo-cd/.
Something else of note to look at Re: Debian is Jigdo.
Jigdo basically downloads all the individual files from Debian mirrors, and "makes" the CD image. Jigdo can be used on mirrors to avoid having to transfer the whole CD image (and if you run a mirror, you'll probably have all the *.deb's on hand anyway), while still being available for use by end users. As the *.deb's are more likely to be cached, wether in a proxy or via a mirror, this can result in a speed-up for downloading an image. It also supports upgrading only the files that have changed (eg: for keeping up-to-date images of stable), without downloading the whole CD image. Much better than trying to do something silly like rsync against the old image.
You can find jigdo at http://home.in.tum.de/~atterer/jigdo/, and the pointers for
PS: I don't believe that Jigdo is limited to use with Debian, but like apt, it's another tool that was produced to address a specific need within the Debian community.
Not that you'd probably want to use the water afterwards, but there is no reason you can't use it beforehand.
Using waste water could work. Wether reclaimed from air, or from body fluids, this would only have been jettisoned into space or reprocessed (and reprocessed water tastes like crap!) anyway.
For that matter, waste biomatter may actually be good at shielding radiation, but you wouldn't want a leak anywhere on the inside of the station! Ewwwww!
Also, you could generate oxygen and hydrogen from water by electrolysis (well you'd have big solar panels anyway). You could use these as a propellant, since any craft at the L1 point still would need some sort of station keeping thrusters (any craft docking/departing the station, or small impacts from space debris, will change the station's balance and momentum, knocking it out of the "perfect centre" it should be sitting at), and this could provide some of the required fuel. Or you could use some of the oxygen to add to the air mix, and the hydrogen in fuel cells.
Only problem with using a liquid as a shield is that when the station is in darkness it'll be frozen, and when it's in light it'll be warm or boiling. Water changes a LOT in volume with heat, so the hull would have to be able to stand that change. And any leak where there is liquid or steam would have to be plugged, otherwise you'd end up with the liquid ejecting into space and propelling the station out of it's nice stable placement.
In the meantime, just make sure the astronauts dose up on their caffiene and they'll be fine. *grin*
I notice a lack of Debian in there. I could guess a number of Debian sys admins would find this reassuring.
No, I'm not advocating that they should be slack about updates, but it's interesting to see that Debian isn't listed. Remember to "apt-get update ; apt-get upgrade" all you Debian admins!
I would also guess this may be due to the way Debian package numbering works. Where possible, Debian will not upgrade a version number of a package when they fix a problem in the stable distribution. Instead, they will patch the existing version, and release a sub-version of the software to solve the exploit. This means that you can't simply look at the version (eg: whatever Apache returns) and determine if the program is exploitable.
You simply have to "suck it and see".
The build system in Apache 2, while being vastly improved over the Apache 1 build system, is rather complicated, and has lead to a number of packagers simply not bothering, or having a hell of a time packaging it.
There is no RedHat or Debian packages of Apache 2.0 (offical as in from RedHat or Debian, and part of their stable distribution). There are a few Debian people who are packaging Apache 2.0 (namely Thom May, who is the current package bunny...err...maintainer *grin*), but last I heard they were having a horrible time getting it working, and it's still only in unstable (sid), and hasn't made it to testing (sarge).
If it gets into RedHat and Debian's stable distributions, chances are it'll make a higher percentage mark on site usage. Till then, I don't think things are going to change much.
CueCats aren't the only barcode scanners that will handle the longer formats. In fact, any company that sells barcode scanners outside of the US will be able to scan the EAN formats. It's simply a matter of reprogramming the scanner (which may require a small piece of software on a PC or just a matter of scanning programming codes into the scanner). And what other brands are out there probably use the scan engines from other companies, so at the most it'd be a software change, or possibly (at the worst) a rom upgrade.
Also many barcode scanners can be programmed to spit out a leading 0 on UPC 12 digit codes, so that the output is ALWAYS 13 digits, wether it's a UPC or EAN code that is scanned. UPC and EAN are basically the same format barcode, with subtle differences in what constitutes the 13th character in the code. It's not I2of5 or Code 39, which are other symbology types. The 14 digit ones are a mixed barcode type, but I don't know how popular they will be.
EAN has already specified EAN-128, which is the EAN code standard using the Codabar 128 barcode format. This allows VERY LONG barcodes, and many of these are for packaging in the warehouse, where you are marking boxes of items, or a shipping crate full of boxes, etc.
So the bogus comment in the NYT that everyone would have to upgrade their scanners is just that. Bogus. If anything, it's the sightless people that developed the databases behind the scenes that will be the problem. Now what does this remind me of..... oh yeah. Y2K. *sigh*
Having done some work with the disabled, here are some suggestions for sensors.
Touch (Capactive switches)
Beam (light, ultrasound, IR triggers)
Magentic (Reed switches)
Tilt (Mercury switches)
I'll only touch on Magnetic and Tilt switches, as the others have adequately been covered by a number of people.
Magnetic switches are easily and cheaply bought anywhere you can get house alarm parts. They are very simple, last a lifetime, and work really well. Using a tiny magnet strapped to a finger allows you to use a number of reed switches so there is a choice of "what to do".
Tilt switches are easily worn on the finger, or on the head. Some care must be taken to encase the deadly mercury as the glass container may be easily broken, and mercury is poisonous. The way I would encase such switches would be by first finding a glue that is capable of sticking to GLASS and plastic, and coating the glass covered mercury switch in it. This way, if the glass cracks, the pieces will usually stay together. Let it dry, then dip it in hot plastic a number of times. You can then put it inside a piece of dense foam rubber (use a glue that sticks to rubber and plastic to keep it in place). The goal is that if you accidently stand on it, it won't break.
I've used both methods before to provide something that a disabled child can use, usually to encourage them to make some sort of movement. One Example: Mercury tilt sensor attached to a head strap with velcro (for position adjustment), to encourage the child to 'lift' their head (helps build up the neck muscles and train the brain). The mercury switch was usually wired into a radio or tape deck, switching it on or off. It also provided some real insight into what sort of music some of the kids liked, as after a little training, they would drop their head when something they didn't like would come on, and then every now and then raise their head to "check" what was playing now.
Good luck.
Suggestions:
Hook up a touch or contact switch (this has already been mentioned to death in here) to some sort of wireless remote. The receiver can then be worn by the husband allowing contact while not physically in the room. At night the husband can put it on a bedside table or something.
Better is to use a pair of (cheap) walkie talkies, that have a morse code option. This still allows the husband mobility, and he can actually respond to his wife without being physically present. This can allow some very simple but effective "Yes, No, I don't know, Help" conversations, as the husband can ask questions, while say, doing stuff in the back yard or garage, and can easily respond to allieve his wife's fears (eg: "I'll be there in a minute", "I'm coming!", etc). The only issue might be one of frequency use (by kids and so on), but you could always go to some of the commerical variants that have their own band/use digital transmission to avoid interference, or maybe modify the walkie talkies to use a different frenquency.
If you give her 3 or 4 touch sensors, then she can (technically) type easily. Remember how you enter your name in a video arcade game? Exactly the same idea. You could also use multiple buttons to scroll between pre-canned answers or words, such as "drink", "help", etc. You could even combine this with some sort of voice synthesis program to generate speech. And there is no reason you couldn't integrate this with the walkie talkie idea, so that she and her husband can communicate over a distance. Hell, she could send SMS's this way, use a phone, or even web browse, use e-mail or perhaps IRC. Might help her relieve some of the (potential) boredom in her life, that being so limtied in mobility would probably create. There are a number of easy ways to interface input into a PC, such as the joystick, parallel or serial ports, and lots of documentation. There are also a fairly large number of devices that will convert serial input into PS/2 keyboard or USB keyboard input, which allows use of a PC in a somewhat normal manner.
If you do go for something complicated (eg: a PC System), ALWAYS have a backup (preferrably battery operated) like the walkie talkie idea. Systems fail, the power goes off, etc, and the last thing you want is it to fail when she needs it most.
Good luck!
You may want to look at the fnk (or cipherfunk) kernel tree (no this is not carried on kernel.org). The link at freshmeat for cipherfunk kernels has connections for downloading and so on. His kernel tree contains the GRSecurity patches, a fair number of other patches (eg: FreeS/WAN), and any fixes he's made to get the lot running.
Basically this guys motivation is security and stability. He puts the whole lot through a barrage of tests, and makes sure things work, or at least determines if there is a problem and makes note of it.
I told the RIAA that they'd piss the Aliens off with all this MP3 buisness, but did they listen? Nooooooo!!!! Now look what happens.
Well, there are a number of factors that are misleading here. Unfortunately a lot of people don't get the real picture. Here are some useful things to know about Debian and HP.
1. Debian's current "Project Leader" is now Bdale Garbee, who works for HP, making sure that Debian (and the Linux Kernel) runs quite happily on the IA64 platform. Most of Bdale's changes have gone back upstream to developers, and have since filtered down to RedHat. I would not be surprised if RedHat actively watches Bdale's code changes to speed this process up. A number of other HP employees work on Debian, and in some cases, were hired by HP after already starting work on Debian.
2. Woody is the only version of Debian that will work properly on IA64, and for the IA64 architechure it uses a 2.4 series kernel. If you haven't used Woody, or used the installer, don't even bother to comment.
3. HP provide a "base system" installed on their machines. They also provide a software loader, that allows you to "choose" what version of Linux is installed. This then copies a pre-installed copy of the chosen OS over the existing system. At least on IA64, the distributions that were going to be bundled were: Debian, RedHat, Suse, Mandrake. The reason I say were, is that I last heard about this directly from Bdale at LCA 2002 (Brisbane, Australia) and there is this whole United Linux thing that may have changed what will happen with Suse somewhat.
4. HP has put it's money where it's mouth is concerning Debian. A number of HP IA64 and HPPA machines have been GIVEN to the Debian community to use as development systems and package builders. They also paid the legal bill to find out just where the legal stance is on having crypto software directly in the main archive.
5. If you want to see JUST how many packages work under Debian (particularly in reference to the IA64 architecture), you should probably look at the Debian Builder Statistics page. Approximately 94% of all of packages in Woody build on IA64. There is over 8000 packages in Debian Woody.
6. Interestingly in reference to your "support" comment, perhaps you may not know that Debian's package update for the recent Apache "Chunked Transfer Encoding" vunerability was released by the security team recently. The update message I recieved from the Apache announce list and the Debian security mailing list (both announcing fixes for the bug) were within 90 minutes of each other, and in both cases files were on the mirrors at the time the notification was released. I personally think this is pretty efficient.
I use Debian in my workplace. It works very well for us. We used to use RedHat and it caused us lots of problems, particularly with upgrading and maintenance, but also when it came to configuration. This is my personal opinion, but I believe my reasons of choice are valid. YMMV.
With point to point links you really need to evaluate antennas and your area. Many people use antennas with a wider radiation distribution pattern than is necessary, simply because it does the job. A number of cheaper antennas also have terrible front-to-back noise ratio, so noise from behind or the side of the antenna can really affect the signal. Also remember that many antennas allow you to orient the polarisation of the signal by the way they are mounted, and some antennas even have circular polarisation.
With general network setups (eg: an office) many people have a tendancy to put an AP on the edge of the building, particularly in warehouses (simply because there is little else to support it). Semi-directional antennas (with 60-180 degree coverage patterns) are VERY useful for walls and corners, and usually have a higher gain in the direction you want (away from the wall or corner, into your business). The less signal that escapes your premesis, the less chance of interference, and also the harder it is to get an outside connection (ie: war driving).
If your setup doesn't allow for outside interference, and is very succeptable to it, you'll always have problems.
Phase matching the antennas is the biggest pain, simply due to the high frequency (and therefore small wavelength). Many AP's and some cards provide 2 antenna sockets for a system called diversity.
Diversity actually is best used to reduce multipath signals, as the radio listens to both signals, and "picks" the best signal to use from the 2 it received. Since both antennas are in different physical locations (from a few inches to about 2 feet is best), each antenna gets a different signal. Do not place these antennas in largely disparate locations, or seperated by some interfering object (like a steel support beam), as diversity works best when it can see the signal at BOTH antennas.
There are a huge variety of antennas out there, that produce different polarisation and radiation patterns. Some antennas have receiving amplifiers that produce huge (30+ dB) gain on receive, while only producing about 7dB gain on transmit. Semi-directional (from 60 degree to 180 degree coverage) antennas are great for outside walls. Some have clockwise or counter-clockwise "Circular" polarisation patterns instead of the average horizontal or vertical (circular polarisation tends to be better for point to point applications, and your antennas should match each other - CW will talk to CCW).
I think you missed his original idea, which is that you should implement a VPN, and still turn on WEP and ACL matching. This way, they'll break the ACL match, break WEP, and then go "Ahh crap! A VPN!", which at that point they may decide it's just too much to break. A VPN by itself, makes the job to break it easier, (even if not too much easier).
Would you still leave your car doors unlocked if you had an engine immobilizer?
You may consider deploying BOTH 802.11b and 802.11a. There are devices that support both, such as the Cisco 1200, but no wireless cards for 802.11a yet (due August/September 2002). There are also devices that work with your existing Access Point, such as Symbol's Mobius 5224, which sits over an existing Symbol 802.11b access point, uses the same network cable (provides a second network port for the 802.11b AP) and even provides power for the old AP.
If you go with 802.11a for any reason though, be warned, the cell sizes are MUCH smaller. The slowest 802.11a speed of 5 Mbit/s gives you coverage to about the same distance as 802.11b does at 5.5 Mbit/s. At least with 802.11b you can go slower in areas where the coverage is marginal.
Antennas can make a big difference to your coverage pattern, and should not be underestimated. Using semi-directional antennas is also a good way to avoid or reduce outside coverage on a building, which makes it that little bit harder for carpark hackers to get in. If you have a lot of metal around, look at using diversity (2 antennas seperated by a small distance - each antennas signals are compared and the best signal is used), which will improve coverage and reduce dropouts.
You will also want to consider the number and type of client radio's connecting to your 802.11b network. While 2 AP's might provide coverage, you may find the density of users brings everything to a crawl. Decent AP/Client card combo's will load balance across multiple AP's if the signal strength is there. Some AP's (particularly Cisco's) have a real problem delivering speed to more than 2 clients from a single AP at the same time, as they don't load balance (internally) properly. You will find 2 clients will get almost all the bandwidth, and the rest will get a tiny amount (eg: 4-10Kbit/sec). This is totally unacceptable for high user densities.
As for security, there are a number of authentication systems out there that seem reasonable, such as EAP/TLS, and Kerberos based implementations, all implemented in the AP. Authenticating using DHCP and MAC addresses is not worth it, as you can fake MAC addresses easily, and you can always use a fixed IP. That said, if the AP has MAC level Access Lists, USE THEM where possible, with other security methods. Just makes it that little bit harder.
EAP/TLS is the newcomer on the market, and usually relies on a Radius server for it's back end authentication. This is OK, as long as your users don't roam about at all. If they roam from one AP to the next, you will get delays of ~300ms as the AP re-authenicates itself with the Radius server. This might be OK if your users don't move around much, but is totally unacceptable if they are mobile in any way. All the Kerberos authentication systems I have seen distribute details to all the AP's at authentication time, so that roaming is about 50ms or less.
With encryption, if you have WEP, enable it. Once again, like with MAC level ACL's, it's just one more thing for them to get through. Many AP's now support Dynamic WEP, or TKIP (Temporal Key Integrity Protocol). There are also some devices that support AES based encryption methods, and I wouldn't be surprised to see TKIP implemented with AES instead of WEP out there as well.
Of course, you could also use a VPN solution like IPSec. I'd also recommend to use large keysizes, simply because you can. If you do use a VPN, STILL use WEP/TKIP/AES and ACL's, as it'll make it just that little bit harder to try and get into.
Remember, the object is deter them from trying to break into your network. If they try long enough, they'd probably still eventually break in. But if they can break into another system in 1/100th of the time, then unless they have a major grudge or very specific reason, they'll go that way.
Good luck!
This might be a good reason to look at the Symbol offering. Symbol have been working in the hand held computing area for a long time, and have developed a lot of very power-efficient hardware, particularly in the wireless arena. All of their radio cards have various power saving modes, many that you don't/won't see supported by other vendors.
Just like most Point Of Sale machines, they are just PC's with extra hardware. That is, if they bother. Many are just plain jane PC's, with things like the pole display and cash draw all driven by the printer, while the barcode scanner is plugged in through a keyboard wedge, so it emulates keyboard input.
If you're so interested in this, try developing a whole graphical (note: graphical as in has to look similar to their existing Windows setup) Point Of Sale system that will be using FrameBuffer, that will end up running on 486-dx33's, with 16 meg of RAM, and a whopping 420 meg of h/drive space. The place I work for is doing this for an Australia wide chain so that they can install it on their existing hardware. They are in a 'contract' with the old POS supplier to keep the hardware on the desks for a few more years. Poor bastards!
We have most of the extra hardware working (a whole 2 extra serial ports - and while it has a PCMCIA flash card reader, it isn't even worth the worry). The Point Of Sale program itself is written in Kylix (was originally a Delphi app on Windows), using SDL as an interface between the FrameBuffer and Kylix. Fun fun fun!!
You still really don't want any sort of radiation or radiation leak in Antartica, even if the risk might be low. One thing history has taught us is that statistics might make us feel safe, but we rarely are. We also grow complacent, and then disaster befalls us.
However Antartica and the Artic would be an ideal place to build a rail-gun transport system, using magnetism to build up speed and takeoff velocity. Getting up to speed from nothing is by far the most fuel consuming part of the process.
Once you leave the launch ramp, you can use conventional Liquid Oxygen/Hydrogren fuels to get out of the atmosphere. LOx & LH are probably the BEST choices for use, simply because the byproduct is water, and not a pollutant like most of the other propellant mixes. And dropping water vapor over the polar cap is not going to do it any harm, more likely do it some good.
The cold is a useful ally for such a setup. Less energy required to put oxygen and hydrogen into a liquid form, an abundance of water for producing oxygen and hydrogen via electrolysis, and a huge amount of wind and solar energy that can be harvested for power (in the right locations). There is also the semi-conductor properties that some substances exhibit in cold conditions that could be exploited.
Once launched, an orbiting docking facility can then fuel up a craft for longer hauls. With decent designs, the propulsion unit would be separate (and have a standard docking system) allowing changeover in orbit for another unit more suited for the job at hand, such as a nuclear propulsion unit for intra-solar missions, or one of the many other propulsion systems that are in the works.
If someone comes up with a smaller or more efficient engine design, a standard docking system between the propulsion unit and the craft allows easy retrofitting and upgrading. Craft returning to the Earth can bring back propulsion units so they can be tested, retrofitted, refueled and relaunched on the next craft.
Anyway, enough rant, I've got across my point.
There is this wonderful thing that people say when their package doesn't compile on another platform...
"But it works on my Pentium!"
So many apps out there are not 64 bit clean, and they will need to be in the not so far future. A hell of a lot of the Debian package people have been doing a brilliant job to make the packages available compile and work on 64 bit platforms. Bdale Garbee is probably the most well known identity working on this effort and has put a lot of effort into porting to Debian to new architectures.
Not all packages are destined to get ported to every architectures (eg: there is no sound device on an S/390, so no real need to have certain sound packages: But don't forget things like network sound architectures!), but most are, and a lot of it is developers who have no understanding of the issues caused by a 64 bit environment.
"But who cares about Alpha?"
If you think Alpha is the only platform that will benefit from 64 bit clean code, think again! There are a fair number of 64 bit platforms, like ia64 and PA-Risc. Fixing such problems will make such software work on all 64 bit platforms.
One last thing to note is that sometimes it's good to have a different perspective on things occasionly. Not everything revolves around the ia32 (i386, etc) platform like everyone generally seems to think.
Same, and I know a lot of people who currently dual-boot to play games like StarCraft who have said they would happily buy such a port.
I don't have Windows installed on my machine at home (thankfully!) and I've only used Wine to run the installer for Return To Castle Wolfenstein. Every install of Windows I've had has had 'issues' (particularly video and motherboard drivers), which I am glad to say I have not had under Linux. And since I didn't have to pay for Windows (since I don't use it), I got to spend just that little extra on my machine so I could buy decent, quality components - makes all the difference for stability, no matter what OS you run.
I'd ask this question of Valve & Sierra (re: Half-Life/CounterStrike) and of Blizzard (re: StarCraft). Loki only ported games, and unless they got the code and the permission to port the game from the authors, then they couldn't do it.
I'm really somewhat surprised that Sierra/Valve dissed the idea of a Linux client port. They had OpenGL code already, and they had a Linux server port. The audio shouldn't have proved that much of a problem, and I'm pretty sure it would have done QUITE well with Linux gamers. Almost all of Blizzard's stuff was Direct3D only, which does make it harder to port.
I'll miss 'em. I own Q3A (metal box), Unreal Tournament, Tribes2, Soldier of Fortune, Rune, and Kohan. I paid for every damn one of them, and I'm glad I did.
It was the graph that did it!
Lies, damn lies, and statistics.