Slashdot

OK, here's the scoop; I may, through my own stupidity, have fried the motherboard in my desktop PC at home, and am facing the prospect of getting a new one, and I'd like to get some input on which direction I should take, since it's been almost 5 years since I last did this.

The PC that may be dead has a P4 3Ghz processor on an ASUS P4C800 Deluxe motherboard, 1GB RAM (DDR400) and some peripherals worth salvaging (hard drives, DVD drive, etc.). I was trying to plug in some additional memory, decided to take it back out and check a few things online before proceeding, and closed up the box. When I fired it up, a rather nasty smell starting coming out of the case, and when I powered back down, I realized I hadn't taken the memory card out after all, and worse yet, it was sitting halfway into the slot. Now when I try to boot I get one long beep followed by two short ones, and endlessly repeating cycle that I haven't been able to get definitive info on as to what it means (some say main memory failure, others the video adapter).

I'm trying to figure out if perhaps the existing memory got fried and putting different DIMMs in might resolve the issue, but I'd rather not pay for that only to find out that's not the problem, and the mobo is indeed toast. So I've started browsing online for a new rig...

What I Do: A little gaming (NHL08), but mostly intensive database and spreadsheet work. I have a blog where I dig into statistical analysis of the NHL, and I'm in the process of designing a database that would be updated after each night's games.

Since it's been so long since I've had a box built, I don't even know where to start. AMD? Intel? 2 or 4 CPU? 2GB RAM? 4GB? 32-bit or 64? I assume, based on everything I've read, that XP is the way to go over Vista (Windows only, please). I'm not looking to blow huge sums of money here, so I like to find sweet spots where the diminishing returns for that extra $ start to tail off.

Post a comment to this thread, and I will:

1. Tell you why I befriended you.
2. Associate you with something - fandom, a song, a color, a photo, etc..
3. Tell you something I like about you.
4. Tell you a memory I have of you.
5. Ask something I've always wanted to know about you.
6. Tell you my favorite user pic of yours.
7. In return, you must post this in your Journal/Blag/whatever.

At the risk of starting a classic flame war, I have a pressing request for assistance.

As a hobby, I blog about NHL hockey, in particular the extension of statistical analysis which until recent years has been about as sophisticated as ancient cave drawings. For the last year or so, I've pursued this by compiling data in spreadsheets for a series of ad-hoc analytical pursuits, but the time has come to formalize my data structures into a database with tables fed by scripts that parse game data as posted at NHL.com. But which free database should I use?

Some operational parameters to consider: I'm envisioning some basic data import tables (I'm developing scripts in Excel to pull the web data down and parse into columns), followed by a series of tables fed by programs which pull data together from a variety of sources (stored in table form for ease of reporting). Most of these tables would only run in the 1,000 - 100,000 range, while one in particular could run as high as 5,000,000 or so. There aren't many instances where multiple indexes over a given table would be required, but the reporting built off these tables could be computationally intense (i.e. exponential moving averages built off of subtotals).

So which DB should I choose? MySQL, PostgreSQL, Open Office's Base? I'm at a bit of a loss as to which direction to go in, and I'd rather not head down a particular path only to find it's not going to pan out.

I've recently been tasked with leading the integration effort for a large systems implementation here at work, and am facing a challenge more daunting than any mere technical obstacle; how does one best get hardcore old-school programmers to embrace a new way of integrating our applications?

We're replacing a large, homegrown COBOL application on a mainframe with a more modular, Java-based ERP on a midrange platform. The kicker is that we need to replace over 100 interface points between other internal systems and the legacy app, and the direction we're headed in is to leverage a GUI-based middleware product to accomplish that task, and take initial steps towards establishing a more loosely coupled, flexible systems architecture. I'm convinced this is technically feasible and will reap many benefits going forward (particularly as other major projects come along), but our developers have a hard time letting go of their point-to-point, custom programs with lots of embedded information directing processing for specific customers or situations.

This group is throwing every conceivable objection to the middleware approach, and most of them are failing to make much headway as we develop some pilot projects to build expertise, despite having had ample training and the services of a consultant to provide mentorship as they work their way up the learning curve.

The bottom line is that they are resisting this new method by any means available: submitting lots of trouble tickets for minor issues, not digging through the documentation and throwing up their hands in futility, etc. Has anybody else here in the /. community dealt with such a generational change in development technique with existing IT staff? We're all sympathetic for experienced workers getting pushed aside for younger talent, but if the old dog can't learn new tricks, perhaps it's time to head to the pet store...

Just when you thought managerial spying was the exclusive field for tech-savvy firms like HP, the details are now coming out about an electronic spying scandal that brought down the head of the National Hockey League Players Association, Ted Saskin. Over the course of fifteen months, Saskin and an associate regularly accessed the email accounts of NHL player reps who wanted to have Saskin's hiring investigated. In addition, the results of a secret ballot ratifying the league's Collective Bargaining Agreement were provided to Saskin by members of the NHLPA's IT group - so watch out for any resumes listing NHLPA Network Security as a working experience!