actually, the more I think about this, the more I wonder what the issue might be. Driver-related, perhaps? Or some other aspect of the hardware I/O?
The reason I think it should be doable is exactly because, as some other poster pointed out, Apple is doing something similar, except with graphics, using the GPU for rendering of data which isn't, well, rendered, but is sent back to the bus... so it must be doable, it may just be not possible to hit the 'theoretical maximum', or there might be system or driver issues that need to be tackled...
Still, I've got to think you'd be better off with a DSP audio card than two PCI-X graphics cards, if sound is what you want to process...
um, except Apple is using the GPU for image data, not audio data?
Actually, the idea is similar in that the data is routed back to the bus, rather than just sent to the screen ( or I guess... routed back to the bus and not sent to the screen at all ). So you're right, they are similar, in concept.
Oh, and to continue my nit-pick, that's "Apple has created..."; there will be even more of this offload-graphics-work-to-the-GPU stuff in the next OS release, but a lot of it is in shipping versions, and developers already have prerelease versions of the next system.
At the risk of getting modded down by Intel fanboys, I'm going to point out that PowerPCs are already screaming floating-point chips, though, so there's probably a little less need for this type of trick for folks using PowerPC as compared to folks using x86... the reason you need "G4 or faster for GarageBand software instruments" is that they're real-time synth'd using Altivec, something you just wouldn't do on x86...
From the Tom's Hardware article: So far Cann cannot take as much performance away from the GPU as he would like. "Right now, getting the data back from the video card is very slow, so the overall performance isn't even close to the theoretical max of the card. I am hoping that the PCI Express architecture will resolve this. This will mean more instances of effects running at higher sample rates," he said.
so it appears that there may really be a problem here... a GPU will normally do a bunch of calculations, then the raster goes *out* to the monitor, not *back* to the bus... I can see how getting data back out to the bus might be an issue. A "real" DSP/audio card would certainly be better, and they aren't *all* as expensive as the original article would have you believe... a quick google found at least one decent-looking DSP card for ~$500 out there, and I'm sure there are others, probably for cheaper ( the quoted price is for a card *and* a stack of software ), if you looked around a bit... if you're considering plunking down the cash for a PCI-X machine and a good GPU, you probably have a ~$500 for a good DSP card, too, and a special-purpose solution *designed* for the purpose at hand is almost always going to be better than repurposing a *different* special-purpose product.
Did that make sense? What I'm trying to say is that you'd be much better off buying an actual DSP audio card than buying two GPUs. That'd just be silly. This repurposed GPU stuff is just for folks unwilling to buy an extra card, but who have a nice GPU already.
OK, geesh... but I *did* RTFA, and *nowhere*, in *either* article does it actually say that it serves no benifit to gaming. I double-checked... please point out where they say that if I missed it the second time...
What did jump out at me was this quote from the Tom's Hardware article :
So far Cann cannot take as much performance away from the GPU as he would like. "Right now, getting the data back from the video card is very slow, so the overall performance isn't even close to the theoretical max of the card. I am hoping that the PCI Express architecture will resolve this. This will mean more instances of effects running at higher sample rates," he said.
so it appears that there may really be a problem here... the cards normally do a bunch of calculations, then the raster goes *out* to the monitor, not *back* to the bus... I can see how doing that might be an issue. A real DSP/audio card would certainly be better, and they aren't *all* as expensive as the original article would have you believe...
I don't think moving the sound data from memory to GPU then to the sound card, mixing it with whatever was done by the CPU, in order to get my final sounds will help to speed things up significantly.
parent makes some excellent points, especially in wondering what sort of latency might be involved in doing this processing in the GPU. I'm thinking this type of approach is only going to see big rewards in certain conditions - like, say, you're running some sort of CPU with relatively poor floating-point performance ( OK, I'll just *say* Intel ) but you've blown a couple hundred bucks to get a killer GPU... certainly you'd want to move the processed data from the GPU to the sound hardware ASAP as well...
The answer to the thread's parent is also right on the mark. Go take a look at what's involved in a large number of actual audio processing algorithms; FFTs and such, it's almost *all* floating point.
You could get some sweet real-time full-bitrate audio effects out of that puppy. It was the only time I ever found assembly worth writing.
It actually seems a *little* odd to me that you'd use a chip designed strictly with video in mind to do something like audio processing, but why not? Actually... well, is there a reason you might not? What happens when your machine askes the GPU to do some 'normal' graphics work when you have this stuff installed? What's your regular CPU doing ( or how underpowered/unfit is it ) that you wouldn't just use it? I'm going to guess you wouldn't ideally want to have some game like UT2004 dropping frames so you could get an echo effect... so maybe this would just be something to do instead of buying a DSP board?
I'm really curious... who'd be using this, and why would they go this route instead of buying special-purpose hardware? Don't get me wrong, it's super cool, it just makes me wonder...
The only other thing that I'd add, literally the only thing that was any kind of a problem for me, was scanner support. SANE might be a decent workaround for some combinations of users/scanners, but you'll likely need to get a new scanner, if you use one that doesn't support OS X.
If your scanner is old enough, it might be time for an upgrade, anyway, though...
Aww, c'mon. I mean, it is Green Day, but at least "American Idiot" is the best song they've managed to put out since, well, they got big... not that I'm a huge Green Day fan, mind you, but that's a half-decent song your slammin', I'm impressed it's even on *any* top 10 list... it *almost* sounds like an actual punk band;-)
I mean, it's a top 10 list, fer cryin' out loud, what did you *think* would be on it?
With your clarifications, I'm going to ask a few questions and make an observation or two.
1) Have you done any design for your data restructure? Do you have a plan as to how to tackle that problem, the tough part of which is importing the legacy data into the new schema? It seems you have to do this work no matter what system you choose.
2) Couldn't you, in the absolute worst case scenario, have the FM client call a script/C tool/whatever that would pass SQL statements to a SQL backend and return data to the FM client? I have no experience with this, but have heard from an FM consultant that it's possible. Such a solution is likely to be far from the ideal, but it seems possible, and would let you use the FM client with some other data source.
3) Does your Java experience tell you that it'll be too difficult to re-implement your existing apps ?
You even have the option of using Interface Builder and going the Cocoa-Java route, and since your apps sound fairly basic in functionality, that should end up being fairly straight-forward should you decide to do that, and would be quicker than an all-Java Swing solution since you get Interface Builder to do the layout. I know you say you don't have the budget to do this, but... well, actually, maybe you do? You're talking about re-implementing the entire system ( or a large part of it ) in any event, even if you just upgrade to FM 7 ( which it seems you're saying you have to do for performance reasons? ).
There are definitely reporting and searching features built into the FM client that, in order to replace, you'd have to do some fairly serious work. On the other hand, perhaps you don't *really* have to replace *all* of those features? Perhaps there's a subset of those features that your users *really* use, which you could implement relatively quickly, to get the system useable, then take your time creating a more flexible UI crafted to meet the needs of the users ?
I almost hate to say it, but it sounds like you are saying "I have to have something just like the FM client", and that leaves you using the FM client, and short of 2) above ( or a good SQL-FM bridge ), using FM as a backend. Maybe you just want a script to dump the FM database contents to a SQL server DB on a frequent basis?? That's crude, but it could work if you don't have to write data back from the SQL side to the FM side.
If you aren't saying "I have to have something like the FM client", then you are talking about re-implementing the existing apps, in which case, well, everyone has a favorite RAD-type programming platform : Cocoa, Java, PHP, JSP, FM, etc... take your pick. I recommend Cocoa, Java, and JSP in that order, from my personal experience. YMMV, of course. Either way, you have a large job ahead of you, and you'd best be clear in communicating that to the folks who set your deliverables.
Clearly, this company is run by lunatic idiots. ICANN should sue them for breach of contract and give somebody else the job already.
Shouldn't the state court just refer to the already decided federal case??
As an interesting side note, I was about to submit this story, did a/. search to link to previous stories on the topic, and found that it had *just* been submitted... but didn't yet show up on my non-paid-subscription page! Fascinating little 'hole' in the subscription-only story-delay system, no? Next time I notice some big hot new story that isn't yet showing on my/. page, I now know I can search for it and comment on it early to 'beat the rush'...
While I also like the "lamp" design a little better - mainly because I don't like the CD/DVD drive placement on this design - I think it's worth pointing out that you can purchase an "optional VESA mount" which lets you slap this bad boy on a large range of pretty interesting mounting hardware.
This includes wall-mount options, and of course, they're all third-party designs.
Given the option ( and the extra cash ), I'd still go with a dual-processor PowerMac tower any day, though. I like my 'lamp' iMac, but dual processors and the ability to upgrade the GPU would be worth the extra cash... still, this is a nice-looking machine that fits in Apple's lineup pretty well. Now if only IBM can start putting out those G5s like they should...
I'm with you 100% on all of these reasons why web-based apps are often good things, I just want to point out one detail.
He said his school is an all-Macintosh environment. He has the luxury of going with a Macintosh-only solution, so a bit of the edge is taken off the "work from anywhere" argument. Not that he *should* build a platform-centric solution ( which FileMaker actually isn't ), but he could.
If he had the time/skill/resources, he'd probably write Cocoa apps. I know I would ( and do ).
Yea, 7 has a lot of spiffy new features that make Filemaker less of a file-sharing system and more of a real server DB ( a *little* more, anyway ). But *must* you upgrade? They'll support your current version for a little while, right ?
How about just looking into SQL-interconnect services, if you want to explore new front-end options ?
If you want to put a 'real' database on the backend, first ask why. Is FileMaker too slow, or are you just looking to cut costs? If you're looking to cut costs, and your current system is working, just don't upgrade. If performance is a problem, then you have a big job- you'll have to learn a lot, and someone will have to do some design and coding. I'll recommend my favorite enterprise DB- PostgreSQL. Sure, there's a little bit of a learning curve, but it's really not bad, and you can do *anything*.
So you want easy form design and reporting? Is that your main criteria? You might want to stick with FileMaker, then. On the other hand, you have a couple of good options, especially if you are a good enough programmer and have enough time to learn Objective-C.
Your options, as I see them, are basically 1) train yourself to learn Cocoa, 2) annoy your users with web-based forms, or 3) continue to annoy them ( and you ) with FileMaker.
We've found that, especially for simple DB lookup stuff, throwing together a nice-looking data viewer or editor in Interface Builder is pretty darn easy, especially once you do it a couple of times ( can you say code reuse? ), and writing a real document-based app lets you do some stuff that'd be darn difficult and/or ugly in a web form ( or in FileMaker ).
Of course, I don't know that all of your clients are on OS X, you don't mention. If you have a few OS 9 holdouts, you may want to go web-based or stay FileMaker.
I'm sure some folks will jump all over me for suggesting doing real Cocoa programming as an actual option for you, but really- it's not that hard, folks, especially if you're doing fairly basic database stuff. This year I took a guy who had only ever written shell-level C programs, got him pointed in the right direction with Objective-C and Interface Builder, and he's written *several* great-looking, highly functional release-quality applications in the past 6 months. He wipped together one multi-user database app in, seriously, like 3 days. It's a real option and I'm a little sad that nobody has offered it up. On the other hand, it's not a simple 'no-programming' solution with auto-generated reports... one of the toughest things for us was learning how to do proper text layout for printing in Cocoa. Then again, once we worked out some details, we have results we couldn't get with FileMaker, and certainly wouldn't get with a web-based forms approach.
Of course, I'm a bit biased towards a 'real programming' solution; before we went all OS X ( and for one project afterward where PC compatability was deemed worthwhile ), I was writing Java Swing database apps... which were totally useable, even with OS 9's antiquated JVM, and once the *design* was nailed down, implementation followed pretty quickly. If you're all Mac at your campus, your actual administration tasks should be light enough to let you do all that programming, right?;-)
Really, though, that's what we've found. I work at an all-Macintosh business, and our IT staff seems to have a lot of time to work on programming projects, rather than applying patches and fighting viruses. Writing database apps in Cocoa gets to be a pretty quick process, and PostgreSQL handles large, complex queries like a champ. It's a great combo.
But honestly, it sounds to me like you shouldn't touch your system, unless it's too slow or has become hard to support. If you do replace it, do it slowly, in phases, and give yourself plenty of time to do the job right.
I take that back. It looks like it has a pretty standard/weak video subsystem, and is certified to run Red Hat 7.1 ( kernel 2.4.2 ). Yes, you read that right, Linux is a *supported* OS on this puppy.
The list of video cards used in the 4694 makes me think that the claim 'incapable of displaying anything but text' sound more than a little fishy, too.
From the manual, again:
v 4694-244 and 205/245 - Cirrus GL5446 SVGA PCI video controller (model 244's have 1 MB of RAM installed, which yields up to 1024x768x256, while model 2x5's have 2MB of video RAM, yielding up to 1280x1024x256 or 1024x768x65535)
v 4694-207/247 and 307/347 models have AGP compatible video function embedded within the main system (VIA PM8601A) chip. Video RAM is part of system RAM and is reserved using the BIOS setup function. Once RAM is reserved as video RAM, it is no longer available for use as system memory. (For instance, a 32M system with 4M of RAM reserved for video will actually only have 28M of RAM available for system use (not counting memory required for BIOS shadowing, etc..)
v 4694-2x6- ATI Technologies Rage 128 Pro 4XL AGP2X video controller with 8MB of video DRAM, yielding support for resolutions up to 1280x1024x32M colors
frickin' Rage 128 Pro?!? I *just* retired a machine with that card in it...
a quick google search reveals that the IBM POS machine in question does indeed include models with a ( from the above PDF ) "Intel Celeron 566/66". So I don't know if they have their specs a bit off, or if I looked up the wrong model, but the truth is the cash register is not *that* old, the manual is dated 2001.
I'm not sure that makes this less cool, since
(1) it's a freekin' cash register
(2) it's definitely isn't your typical slashdot-geek's video subsystem.
The 'found in a dumpster' bit is pretty cool, too. As is the 'retooled industrial equipment as art' spin. I like it.
But, no, it's not something from the mid-80's or anything. It's 'just' a cash register.
one of your customers will be using Windows with Internet Explorer
Do you know that for a fact, huh? What do you do when my company becomes ( or wants to become ) a customer, and you learn that we all have Macintosh OS X machines on our desktops, and only one or two PCs in the building, which we won't want to use for your website?
If you think this is some sort of joke, it's not. There is at least one major business service we're dumping this year because their website supports only a specific version of Windows, and there are too many good alternate services for us to have to deal with that.
I can't say enough about how I dislike your assumption. It's wrong.
I never said it was un or anti patriotic, just not patriotic.
still no good. The song is *extremely* patriotic, and it takes a pretty skewed view of the term, and possibly the world, not to see that.
It's lyrics portray the land as beautiful, and calls upon it's people to appreciate and share it. What's *not* patriotic about that?!? The *sharing* part?!?
white folks in america are just lucky we see things this way.
I was just trying to point out to the parent post that folks in the US haven't always been completely on the up-and-up about their own history, since he'd laid out a list of things ( like slavery ) that we're fairly open about. I wasn't saying we're neglected, or that we're worse off than the Jews or any other invaded/displaced peoples.
I don't know if most of the Jewish folks I know are really ready to 'move on' and let Nazi 'concentration' camps be forgoten. Nor should they. I can understand living in Europe and not wanting to see a single swastika on a red emblem. Not that I think banning commerce is the solution, but I understand.
I also don't know that we get full equality yet, either. I mean, the feds didn't decide to put the national 'sacrifice' nuclear waste storage site on anything less than Big Mountain, now, did they??
70 years ain't a long time. I understand you have to get along with folks in ND and all, but you, your children, your neighbors, and the nations of the world shouldn't be allowed to forget, or we'll risk a repeat.
Naw, it's not *that* bad, docs just told 'em the procedure was reverseable. That's according to the article I linked to, of course. But, hey, what's a little lie to keep a poor indian woman with a drinking problem from breeding, huh?
We in the US do not hide the Civil War, slavery, or even racism. Any insight would be appreciated...
But we do a fine job of not mentioning the genocide of Native Americans, including but not limited to the fact that Indian Health Service routinely sterilized women as late as 1970. Recently we're getting a little better about this, as some modern advanced history books actually talk about stuff like The Longest Walk now, but this stuff happened much longer ago than WWII.
Also, they're not ( in theory ) so much trying to cover up the *history*, as to keep the *current* bunch of Nazis from preaching the gospel of hate, and gaining acceptability through their icons. Not that such a tack is likely to work... but these laws are in fact not unlike anti-gang laws in the US. Except you can still *buy* red and blue bandannas. Just don't try to wear one to school...
Slashdot Mirror
They call it Ever*CRACK* for a reason, you know...
It's not the *next* drug, it's the *current* drug.
The reason I think it should be doable is exactly because, as some other poster pointed out, Apple is doing something similar, except with graphics, using the GPU for rendering of data which isn't, well, rendered, but is sent back to the bus... so it must be doable, it may just be not possible to hit the 'theoretical maximum', or there might be system or driver issues that need to be tackled...
Still, I've got to think you'd be better off with a DSP audio card than two PCI-X graphics cards, if sound is what you want to process...
Actually, the idea is similar in that the data is routed back to the bus, rather than just sent to the screen ( or I guess... routed back to the bus and not sent to the screen at all ). So you're right, they are similar, in concept.
Oh, and to continue my nit-pick, that's "Apple has created..."; there will be even more of this offload-graphics-work-to-the-GPU stuff in the next OS release, but a lot of it is in shipping versions, and developers already have prerelease versions of the next system.
At the risk of getting modded down by Intel fanboys, I'm going to point out that PowerPCs are already screaming floating-point chips, though, so there's probably a little less need for this type of trick for folks using PowerPC as compared to folks using x86... the reason you need "G4 or faster for GarageBand software instruments" is that they're real-time synth'd using Altivec, something you just wouldn't do on x86...
So far Cann cannot take as much performance away from the GPU as he would like. "Right now, getting the data back from the video card is very slow, so the overall performance isn't even close to the theoretical max of the card. I am hoping that the PCI Express architecture will resolve this. This will mean more instances of effects running at higher sample rates," he said.
so it appears that there may really be a problem here... a GPU will normally do a bunch of calculations, then the raster goes *out* to the monitor, not *back* to the bus... I can see how getting data back out to the bus might be an issue. A "real" DSP/audio card would certainly be better, and they aren't *all* as expensive as the original article would have you believe... a quick google found at least one decent-looking DSP card for ~$500 out there, and I'm sure there are others, probably for cheaper ( the quoted price is for a card *and* a stack of software ), if you looked around a bit... if you're considering plunking down the cash for a PCI-X machine and a good GPU, you probably have a ~$500 for a good DSP card, too, and a special-purpose solution *designed* for the purpose at hand is almost always going to be better than repurposing a *different* special-purpose product.
Did that make sense? What I'm trying to say is that you'd be much better off buying an actual DSP audio card than buying two GPUs. That'd just be silly. This repurposed GPU stuff is just for folks unwilling to buy an extra card, but who have a nice GPU already.
What did jump out at me was this quote from the Tom's Hardware article :
So far Cann cannot take as much performance away from the GPU as he would like. "Right now, getting the data back from the video card is very slow, so the overall performance isn't even close to the theoretical max of the card. I am hoping that the PCI Express architecture will resolve this. This will mean more instances of effects running at higher sample rates," he said.
so it appears that there may really be a problem here... the cards normally do a bunch of calculations, then the raster goes *out* to the monitor, not *back* to the bus... I can see how doing that might be an issue. A real DSP/audio card would certainly be better, and they aren't *all* as expensive as the original article would have you believe...
parent makes some excellent points, especially in wondering what sort of latency might be involved in doing this processing in the GPU. I'm thinking this type of approach is only going to see big rewards in certain conditions - like, say, you're running some sort of CPU with relatively poor floating-point performance ( OK, I'll just *say* Intel ) but you've blown a couple hundred bucks to get a killer GPU... certainly you'd want to move the processed data from the GPU to the sound hardware ASAP as well...
The answer to the thread's parent is also right on the mark. Go take a look at what's involved in a large number of actual audio processing algorithms; FFTs and such, it's almost *all* floating point.
You could get some sweet real-time full-bitrate audio effects out of that puppy. It was the only time I ever found assembly worth writing.
It actually seems a *little* odd to me that you'd use a chip designed strictly with video in mind to do something like audio processing, but why not? Actually... well, is there a reason you might not? What happens when your machine askes the GPU to do some 'normal' graphics work when you have this stuff installed? What's your regular CPU doing ( or how underpowered/unfit is it ) that you wouldn't just use it? I'm going to guess you wouldn't ideally want to have some game like UT2004 dropping frames so you could get an echo effect... so maybe this would just be something to do instead of buying a DSP board?
I'm really curious... who'd be using this, and why would they go this route instead of buying special-purpose hardware? Don't get me wrong, it's super cool, it just makes me wonder...
The only other thing that I'd add, literally the only thing that was any kind of a problem for me, was scanner support. SANE might be a decent workaround for some combinations of users/scanners, but you'll likely need to get a new scanner, if you use one that doesn't support OS X.
If your scanner is old enough, it might be time for an upgrade, anyway, though...
I mean, it's a top 10 list, fer cryin' out loud, what did you *think* would be on it?
With your clarifications, I'm going to ask a few questions and make an observation or two.
1) Have you done any design for your data restructure? Do you have a plan as to how to tackle that problem, the tough part of which is importing the legacy data into the new schema? It seems you have to do this work no matter what system you choose.
2) Couldn't you, in the absolute worst case scenario, have the FM client call a script/C tool/whatever that would pass SQL statements to a SQL backend and return data to the FM client? I have no experience with this, but have heard from an FM consultant that it's possible. Such a solution is likely to be far from the ideal, but it seems possible, and would let you use the FM client with some other data source.
3) Does your Java experience tell you that it'll be too difficult to re-implement your existing apps ?
You even have the option of using Interface Builder and going the Cocoa-Java route, and since your apps sound fairly basic in functionality, that should end up being fairly straight-forward should you decide to do that, and would be quicker than an all-Java Swing solution since you get Interface Builder to do the layout. I know you say you don't have the budget to do this, but... well, actually, maybe you do? You're talking about re-implementing the entire system ( or a large part of it ) in any event, even if you just upgrade to FM 7 ( which it seems you're saying you have to do for performance reasons? ).
There are definitely reporting and searching features built into the FM client that, in order to replace, you'd have to do some fairly serious work. On the other hand, perhaps you don't *really* have to replace *all* of those features? Perhaps there's a subset of those features that your users *really* use, which you could implement relatively quickly, to get the system useable, then take your time creating a more flexible UI crafted to meet the needs of the users ?
I almost hate to say it, but it sounds like you are saying "I have to have something just like the FM client", and that leaves you using the FM client, and short of 2) above ( or a good SQL-FM bridge ), using FM as a backend. Maybe you just want a script to dump the FM database contents to a SQL server DB on a frequent basis?? That's crude, but it could work if you don't have to write data back from the SQL side to the FM side.
If you aren't saying "I have to have something like the FM client", then you are talking about re-implementing the existing apps, in which case, well, everyone has a favorite RAD-type programming platform : Cocoa, Java, PHP, JSP, FM, etc... take your pick. I recommend Cocoa, Java, and JSP in that order, from my personal experience. YMMV, of course. Either way, you have a large job ahead of you, and you'd best be clear in communicating that to the folks who set your deliverables.
Shouldn't the state court just refer to the already decided federal case??
As an interesting side note, I was about to submit this story, did a /. search to link to previous stories on the topic, and found that it had *just* been submitted... but didn't yet show up on my non-paid-subscription page! Fascinating little 'hole' in the subscription-only story-delay system, no? Next time I notice some big hot new story that isn't yet showing on my /. page, I now know I can search for it and comment on it early to 'beat the rush'...
This includes wall-mount options, and of course, they're all third-party designs.
Given the option ( and the extra cash ), I'd still go with a dual-processor PowerMac tower any day, though. I like my 'lamp' iMac, but dual processors and the ability to upgrade the GPU would be worth the extra cash... still, this is a nice-looking machine that fits in Apple's lineup pretty well. Now if only IBM can start putting out those G5s like they should...
He said his school is an all-Macintosh environment. He has the luxury of going with a Macintosh-only solution, so a bit of the edge is taken off the "work from anywhere" argument. Not that he *should* build a platform-centric solution ( which FileMaker actually isn't ), but he could.
If he had the time/skill/resources, he'd probably write Cocoa apps. I know I would ( and do ).
More to the point, why even upgrade to 7 ?
;-)
Yea, 7 has a lot of spiffy new features that make Filemaker less of a file-sharing system and more of a real server DB ( a *little* more, anyway ). But *must* you upgrade? They'll support your current version for a little while, right ?
How about just looking into SQL-interconnect services, if you want to explore new front-end options ?
If you want to put a 'real' database on the backend, first ask why. Is FileMaker too slow, or are you just looking to cut costs? If you're looking to cut costs, and your current system is working, just don't upgrade. If performance is a problem, then you have a big job- you'll have to learn a lot, and someone will have to do some design and coding. I'll recommend my favorite enterprise DB- PostgreSQL. Sure, there's a little bit of a learning curve, but it's really not bad, and you can do *anything*.
So you want easy form design and reporting? Is that your main criteria? You might want to stick with FileMaker, then. On the other hand, you have a couple of good options, especially if you are a good enough programmer and have enough time to learn Objective-C.
Your options, as I see them, are basically
1) train yourself to learn Cocoa,
2) annoy your users with web-based forms, or
3) continue to annoy them ( and you ) with FileMaker.
We've found that, especially for simple DB lookup stuff, throwing together a nice-looking data viewer or editor in Interface Builder is pretty darn easy, especially once you do it a couple of times ( can you say code reuse? ), and writing a real document-based app lets you do some stuff that'd be darn difficult and/or ugly in a web form ( or in FileMaker ).
Of course, I don't know that all of your clients are on OS X, you don't mention. If you have a few OS 9 holdouts, you may want to go web-based or stay FileMaker.
I'm sure some folks will jump all over me for suggesting doing real Cocoa programming as an actual option for you, but really- it's not that hard, folks, especially if you're doing fairly basic database stuff. This year I took a guy who had only ever written shell-level C programs, got him pointed in the right direction with Objective-C and Interface Builder, and he's written *several* great-looking, highly functional release-quality applications in the past 6 months. He wipped together one multi-user database app in, seriously, like 3 days. It's a real option and I'm a little sad that nobody has offered it up. On the other hand, it's not a simple 'no-programming' solution with auto-generated reports... one of the toughest things for us was learning how to do proper text layout for printing in Cocoa. Then again, once we worked out some details, we have results we couldn't get with FileMaker, and certainly wouldn't get with a web-based forms approach.
Of course, I'm a bit biased towards a 'real programming' solution; before we went all OS X ( and for one project afterward where PC compatability was deemed worthwhile ), I was writing Java Swing database apps... which were totally useable, even with OS 9's antiquated JVM, and once the *design* was nailed down, implementation followed pretty quickly. If you're all Mac at your campus, your actual administration tasks should be light enough to let you do all that programming, right?
Really, though, that's what we've found. I work at an all-Macintosh business, and our IT staff seems to have a lot of time to work on programming projects, rather than applying patches and fighting viruses. Writing database apps in Cocoa gets to be a pretty quick process, and PostgreSQL handles large, complex queries like a champ. It's a great combo.
But honestly, it sounds to me like you shouldn't touch your system, unless it's too slow or has become hard to support. If you do replace it, do it slowly, in phases, and give yourself plenty of time to do the job right.
The list of video cards used in the 4694 makes me think that the claim 'incapable of displaying anything but text' sound more than a little fishy, too.
From the manual, again :
frickin' Rage 128 Pro?!? I *just* retired a machine with that card in it...
I'm not sure that makes this less cool, since
(1) it's a freekin' cash register
(2) it's definitely isn't your typical slashdot-geek's video subsystem.
The 'found in a dumpster' bit is pretty cool, too. As is the 'retooled industrial equipment as art' spin. I like it.
But, no, it's not something from the mid-80's or anything. It's 'just' a cash register.
Do you know that for a fact, huh? What do you do when my company becomes ( or wants to become ) a customer, and you learn that we all have Macintosh OS X machines on our desktops, and only one or two PCs in the building, which we won't want to use for your website?
If you think this is some sort of joke, it's not. There is at least one major business service we're dumping this year because their website supports only a specific version of Windows, and there are too many good alternate services for us to have to deal with that.
I can't say enough about how I dislike your assumption. It's wrong.
definitely my new favorite metric. That makes the whole article worthwhile.
still no good. The song is *extremely* patriotic, and it takes a pretty skewed view of the term, and possibly the world, not to see that.
It's lyrics portray the land as beautiful, and calls upon it's people to appreciate and share it. What's *not* patriotic about that?!? The *sharing* part?!?
that song, and woodie guthrie, are more patriotic than you seem to be.
Unless you really think being fascist makes you patriotic, in which we'll just have to disagree.
white folks in america are just lucky we see things this way.
I was just trying to point out to the parent post that folks in the US haven't always been completely on the up-and-up about their own history, since he'd laid out a list of things ( like slavery ) that we're fairly open about. I wasn't saying we're neglected, or that we're worse off than the Jews or any other invaded/displaced peoples.
I don't know if most of the Jewish folks I know are really ready to 'move on' and let Nazi 'concentration' camps be forgoten. Nor should they. I can understand living in Europe and not wanting to see a single swastika on a red emblem. Not that I think banning commerce is the solution, but I understand.
I also don't know that we get full equality yet, either. I mean, the feds didn't decide to put the national 'sacrifice' nuclear waste storage site on anything less than Big Mountain, now, did they??
70 years ain't a long time. I understand you have to get along with folks in ND and all, but you, your children, your neighbors, and the nations of the world shouldn't be allowed to forget, or we'll risk a repeat.
Naw, it's not *that* bad, docs just told 'em the procedure was reverseable. That's according to the article I linked to, of course. But, hey, what's a little lie to keep a poor indian woman with a drinking problem from breeding, huh?
But we do a fine job of not mentioning the genocide of Native Americans, including but not limited to the fact that Indian Health Service routinely sterilized women as late as 1970. Recently we're getting a little better about this, as some modern advanced history books actually talk about stuff like The Longest Walk now, but this stuff happened much longer ago than WWII.
Also, they're not ( in theory ) so much trying to cover up the *history*, as to keep the *current* bunch of Nazis from preaching the gospel of hate, and gaining acceptability through their icons. Not that such a tack is likely to work... but these laws are in fact not unlike anti-gang laws in the US. Except you can still *buy* red and blue bandannas. Just don't try to wear one to school...
You call that *less* painful !?!
I call shenanigans ! You're not married !