moonlit

A smartphone will do the job if you have one, there are several GPS capable wardriving apps for Windows Mobile, for example, and I'm sure there are similar apps for other mobile platforms too. A built in GPS is nice, but a seperate GPS will work too. If you don't have/want a smartphone, however, a simple $40 bluetooth GPS will handle it just fine, and as an added bonus works with anything which has bluetooth rather than just USB or serial. A handheld one will work just fine, but they're often a little larger, my bluetooth GPS cost very little, works very well, and is barely bigger than a small box of matches.

Looks to be a single track strip with weird placement on the card. If you cut some of the card off or mod a reader, you should be able to read it just like any other. I'm guessing it's a travel card of some description.

I don't really have much to add, but I will say that you probably won't even notice it's 64bit. Pretty much all 32bit apps run just fine, as VaKo said, drivers are the main issue really, and given that you're buying most/all of the parts new they should come with 64bit drivers right out of the box. Some old peripherals may have issues, but if you're not going to use any then no problem at all.

What Cooper said (also, hey Cooper, good to see you're still alive ;) Considering you barely seem to know where to start, you're more likely to fail the project entirely trying to bite off more than you can chew. A simple game won't be super amazingly awesome and you probably won't win any points for style, but at least you'll have something functional to hand in for your project.

A game isn't really a good starting project, it's big, it's complicated, it'll require some serious patience and you're going to have to learn an awful lot in a very short time. However, it can be done, and I wish you all the best with it. As for 3DSMax, there are various model and tutorial resources around the net, so a little googling should help you there. Given the size of the task in hand, I'd probably recommend using stock/free downloadable models to get you on your way and worry about the art later. Get the code done first, it's not going to be easy, and a bunch of static models isn't going to make much of a game.

Absolutely, it's all about "doing stuff". If you don't want to know how x, y or z works then you probably won't care much about finding out, but if you're interested in anything and everything, you're probably going to want to try your hardest to do something with it. The skills involved are vast, from problem solving and troubleshooting through to physics, electronics and mathematics. You could be right about a natural predisposition to hacking, I think it's a point which could be debated, but I do think you have to have some prior interest - the fact you created this thread here though suggest you do, so you're half way to beginning already. Now you just need to find some stuff to hack about with. :D

I'd convert it to NTFS personally, Windows has tools which will do that very thing. The alternative is to back up and reformat the thing. While I'd recommend backing up before converting anyway, you can convert while the data is still in place so if you just don't have anywhere to back up to, you still have an option. See here.

That. Security is all fine and good, but hacking is much broader. See, here's how it works for me: I've been interested in a great number of things over the course of my productive computing life, and they pretty much all bleed in together. What I learn, when messing with bluetooth or IR or GPS or whatever often comes in very handy while doing just about anything else. While experimenting I code as much as I can myself, because simply using a premade app won't give me the understanding I need. As an example, if I just fire up TomTom, yes, I can get the information I need to know where I am, but that tells me nothing of how TomTom works, or how a GPS receiver works, or what data is provided, or how it's formatted or interpreted. By writing my own code, I get to see every last bit of data which is required, and I get to see how it all fits together, what it means, how it's used. Even the stuff you don't normally get to see because it's used in internal calculations or is just extraneous data. Simply by wondering what goes over a GPS cable (or over the bluetooth airwaves, in this case) I learnt: 1) How to listen to a device over serial 1a) How to do that over bluetooth 2) How to XOR checksum data both for integrity checking incoming data and to provide integrity data while transmitting 3) What the NMEA GPS data was and what it meant 4) I sharpened up my coding skills by writing more reusable code 5) How to better dissect incoming data as quickly and efficiently as possible 6) How to send commands to control the GPS chipset, including the correct way to send the data (CR/LF/etc) I then realised I could use the data in combination with other things. I used the programming knowledge I got from the project to integrate SMS capabilities into my test programs so I could SMS my laptop and have it SMS me back with info on where it was using the GPS data, so I then had to learn how to talk to a serial GSM modem (commonly found in 3G modems), which automatically meant more learning: 1) How to listen and talk to GSM modems (they often have similar command sets, based on the Hayes/AT set) 2) Further refining of reusable code and efficient transmission/reception of data 3) How to send and receive SMS messages using AT commands (it's trickier than you might think) 4) How to multithread my code (read: how not to make my apps lock hard) and how to pass data between threads I also used the GPS stuff I'd learnt to write an prototype app for Windows Mobile which clocked speeds of RC vehicles, the threading I've used for a Teletext simulator. I could use the same information to talk to set top TV boxes, or create a custom piece of hardware which I could control using my phone, or to find out how magstripes or RFID work. Bluetooth's RFCOMM/SPP (serial port profile) is excellent for beginners, it's basically a serial cable without the cable, what goes in one end comes out the other end, no special driver or protocol knowledge required. Basically what I'm saying is this: I personally hack to learn. I don't learn to hack. You can't "learn to hack". It's impossible. You can learn things by hacking, but you can't learn hacking. Never disregard knowledge, one day it might be important to something else you need to do. Try everything, I couldn't dream of doing half the crap I do now without learning the zillions of things I've put hours, days, weeks, months, years of effort into learning, and I'm ever thankful that I've done so. Maybe one day I'll become interested in security a little more, but if and when I eventually do, I can be sure that there will be a lot of things I need to learn, but because I've tried as many things as I have so far, I'll know just that little more before I start. It's important to be able to find things out on your own, and every scrap of knowledge you have will help you, sometimes it helps to have a starting point, but you can't always rely on people to give you the end of the piece of rope. The number of things I've tried or suggested and people have responded with "what? why? seems like a waste of time to me" is staggering, there's no way I would've tried half as much as I have if I hadn't gone out of my way to find out how to start.

Given the nature of the question (that is, to wire a cheap 12v string of LEDs to an amp), the easiest way of doing it is to do as I said. Now, I agree that it's 1) not the best way, 2) not going to give the LEDs a long life, 3) going to distort the audio and 4) not advisable to spit 30v into that string of lights, but clearly it's a cheap and nasty project, and it would "work" as long as you don't ramp the volume too high. It's also worth noting that if the amp is running bridged, those LEDs are probably gonna go pop pretty quickly if you crank it to any sort of volume but given that he said "to each speaker" I gathered that it's not. What I meant by + to +, - to - is that the positive wire of the LEDs should be connected to the positive speaker terminal, and the negative wire to the negative terminal on one single channel (requiring two strings for two channel operation). That particular string is supposed to run on 12v and will not cause a direct short across the amplifier terminals. The chances of that string having a lower impedance than the speaker attached to it are next to nil, if for no other reason than it's very likely to have a current limiting resistor many times the resistance of the speaker itself (ignoring the fact that the 15 LEDs themselves consume power too).

+ to +, - to -, in parallel, and not in line, with the speaker.

Trouble is with a vreg, he's looking for the lights to flash to the bass, and while they would do that on one, they'd trigger quite easily and not vary in brightness at all. I suppose the proper way to do it would be to use a digital potentiometer and a PWM circuit, but I imagine that's a little more complex than he was hoping. I still reckon hooking them up directly will be fine, though. The way to be certain is to not turn up the volume very high to begin with, then ramp up until the LEDs look to be their brightest without burning.

The lights are rated for 12v, the amplifier will likely peak around 12v (possibly 11-14v, depending on whether the engine's running and how good the battery is), you shouldn't need a resistor.

Nah, it'll be fine, try it and see. Consider the fact that those lights are designed to be hooked to a 12v car battery which can pump 100s of Amps at any given time, I don't think a little amp is gonna give 'em much trouble.

That, basically (minus the bit about the battery, just hook to the speaker terminals, + to +, - to -), though given that the output voltages will probably peak somewhere around 12v or so anyway, you might not need to add the resistor (those strips are rated for 12v anyway). If they seem too bright, throw in a resistor.

No, that wouldn't work. Edit: Actually, I suppose if you tried to look down through the liquid it might, but it won't see through the label. Still, you'd look pretty suspect running around trying to scan bottles in IR.

Gut it, install laptop or very small PC insides in it, add capture card, DIY DVR or media centre.

This. A million times this. Computer security is a fraction of "hacking" and is by no means all of it. Get screwdrivers, get emulators, get old crap to take apart (and fix, broken stuff is often free or cheap and can be mae useful again), put things together, stick electronic bits together and make things, experiment, make computers do things you've never made them do before, maybe learn to write your own software, there's so many possibilities that to limit yourself to "heh, heh, white hat hacking, heh" would be a mistake. The process of learning anything is important, it can be transferred to anything else you need to learn, and once you're used to learning things you can do it day in and day out, whatever your end goal.

The problem is that there's a huge amount of potential machines and there's a huge number of requirements people might have. Not only that, but if you're looking for a "hacking" computer then you'd better get used to doing your own research and finding machines and tools which do the job you're trying to do, because there's gonna be an awful lot more of it to come. If you can't figure out which laptop to buy, you're not gonna get very far in much beyond that.

Why do people keep asking this? There's no such thing as a "hacking" or "hacker's" laptop, the hacking is the part YOU do, not the laptop. Pick a laptop you like. Get an idea of what sort of spec you want, look within the budget you have, and choose accordingly. It's really not difficult.

FYI, quite a lot of (all?) netbooks are 32bit only, especially the Celeron M based 701. It will run Windows Vista or Windows 7 if you so desire, though it takes a lot of fiddling. XP runs fine on it even at stock configuration and with a full install. As for VMs, they work, but don't expect it to be speed demon, they're not meant to be powerhouses, they're portable convenience machines. Emulation, however, works great, many emulated old computers and consoles will happily chug along on even a stock-clocked 701, but grab eeectl to boost your clock speeds back up to the CPU's factory spec'd 900MHz.

The Best of Season One DVD is still available here (HTTP download).

https://wiki.ubuntu.com/ARM might be of some use, but I should mention that it's probably very unlikely that you'll find a precompiled distro for that device. You may be able to compile it yourself but it's not a task to be taken lightly, and if you haven't the first clue about compiling your own distro then I'd recommend giving up now.

You should be able to run any ARM Windows CE apps on that machine, though since finding CE apps is a lot more tricky than finding Windows Mobile apps, you could try this, which can apparently extract Windows Mobile apps from their CAB files, some of which may or may not run on Windows CE.

Good to hear, take it easy, here's hoping it won't come back. *raises an xmas beer*

Best wishes. If it's stones, I know what that's like, absolutely no fun at all. The painkillers help, th... ergh... ifffff... *zzzzzz*.