Exactly. Now, on the other hand... Why not use a Linux/BSD/Unix solution? Have you considered Mac? A few beefy Mac servers, with MS Office (Mac) installed, and dumb X consoles (similar to Sun's offering). You keep the simple, centralized management of Unix, keep Office (and probably Groupwise, etc... are available for OS X), and save on all your licenses. Sure, it costs a bit for the server hardware, but it costs next to nothing for the clients (and you only buy them once, no upgrades needed), and saves a ton of money in administration. (Ever tried applying the latest MS patch to 1000 machines? It takes a while, or more money for a good patch system. Ever tried applying patches to 1000 dumb terminals, oh... right... you won't ever have to.)
Also, check into Wine/WineX/Crossover Office to run your apps in Linux/BSD/etc. If you can run all your critical applications, you shouldn't have a problem. If the PHB's don't like Linux or *BSD, use a commercial Unix, it'll still be much cheaper and easier.
As an added bonus, if you want to reuse your old workstations for some of the terminals, you can try Knoppix/Gnoppix/your own Live CD. Time to upgrade? Just burn new copies for all the workstations and reboot....And by the way, great topic, I run into the same thing at work, where it's only two or three applications that hold things up.
I think it's more like -MORESTABLETHANCURRENT. In other words, it's sort of like a point release (the xx part) in Linux's Stable tree (2.4.xx). It means something like "We've tested this, and it looks good, but let us know if anything breaks", as opposed to -CURRENT's "We've run this once or twice, still working on it, please help us get it to work correctly", and -RELEASE's "You didn't complain when it was STABLE, so we're not planning on fixing any bugs for a long time".
So basically, CURRENT is like the 2.5.xx/2.6.xtest series of Linux, STABLE is like 2.4.xx, and RELEASE is more like 2.4.x9. Unless there are extreme circumstances, or important new hardware, RELEASE versions aren't put out that often. Hell, 4.7 and 4.8 were 6 months apart, and it'll be at least six months since 4.8 (April 3) before 4.9 is out.
I agree [almost] completely, except that you should not pay unless ordered to by a court, and you should file a lawsuit. Since you don't live in the US (and hance the parent's mention of HomeSec doesn't help), I'm not sure what laws you have to protect you, or how discovery proceedings work, but I would assume that there is some method to see all of the information they have on the subject, and from there you should easily be able to prove that it is not something you should be responsible for.
While you're waiting for the court proceedings to finish, it might be a good time to change providers, and make sure you have a good lawyer go over the contract, so you don't get stuck with things like this again. If you are to be billed for bandwidth usage, you should have a clause in there stipulating what types of packets count, and connectionless protocols should not count, or should at least be billed at a [much] lower rate.
Exactly, it may not be a person's favorite distribution, but RedHat has done, and continues to do a lot for Linux. Personally, I use Gentoo, but I'm happy to see a company succeed that puts as much legal, economic, and coding effort into Linux as RedHat does. It seems like RedHat and SuSe are behind a lot of good media coverage, and are usually the first ones to step up when needed (SuSe in Europe, and RedHat in North America, like in the SCO case).
Sure, they sell a free product, but what they're really selling is updates, pretty manuals, and their continued commitment to Linux, and support. Without RedHat and SuSe, Linux would probably be three years behind where it is now, and you wouldn't see as many companies switching to Linux, and as many Linux stories in the news.
That's exactly why the chances of a zero-day exploit are higher on open source software than closed source. *OUCH*
You've got a good point, except that it also means that someone can notice the problem and fix it. Besides, given the recent string of M$ security holes, wouldn't it be easier to just start throwing strings at all the services until one crashes? If throwing random data at a service crashes it, it's probably a good bet that there's another buffer overflow there. Apparently Microsoft doesn't seem to find bounds checking to be important. Maybe they should write Longhorn in Ada (actually, that might not be a bad idea). Hell, if you're going to write bloatware anyways, why not start with the most bloated language? (Don't get me wrong, Ada is a great language, but the standard library is rediculously large).
Yes, the deep pipelines ARE there for a reason, to do a ton of integer and floating point operations as fast as possible (so that SPECint and SPECfp scores are high). Now, back in the real world, we have real programs, and real programs branch. If the branch prediction fails, or if there is an unconditional jump or function call, the rest of the pipeline has to be thrown out. Wasting 19 clock cycles is bad, especially if you have a situation (like simulation) where branch prediction is unusable or usually fails, and you have 5 or 6 instructions, then a jump. In 26/27 clock cycles, you executed 6/7 instructions (assuming no fp, which could delay the pipeline further). This may seem like an extreme example, but it really isn't when you consider that most real programs deal with input of some sort.
As for the branch and load delay slots, yeah, they needed them when the MIPS ISA was set, but since the R10K, branch delays have been unnecessary. HP's PA-RISC doesn't use a branch delay, either (it just starts executing the next op, and throws it out if the branch is taken). Load delays will happen, but if the Memory stage is split for cache hits/misses, and cache is increased, the delay can be significantly reduced, and the result could be forwarded back to the execute stage, with maybe a half-cycle delay, rather than the current complete cycle.
And finally, no, compatibility doesn't matter more than performance/efficiency (depending on use), and the x86 ISA limits performance/efficiency. The Pentium 4s may be fast, but they are far from efficient. Market factors being what they are, it's all academic, but there really are serious performance problems with Intel's chips, it's just not economically practical to use the alternatives. And yes, I've read H&P, and they're mostly right, except that once the economics of speed reach a certain point (which happened probably 2 years ago), the processing power available allows large scale data processing (data mining, graphics, simulation, intelligent network filters, [anything that has a lot of data to make decisions on]) to be feasable, and there is an increase in the density of jumps in code. With more jumps, there are more pipeline stalls, and the longer pipelines multiply this problem. For a lot of these applications, a 400MHz MIPS processor will run circles around the latest 3.2+GHz Pentium.
...Pentium Extreme is much better than a 64 bit CPU, especially for the Pentium Extreme target market.
What, you mean for people who run 32-bit code? The cache is something that's been sorely needed though, maybe Intel's finally going to make decent processors for people who need to run more than Word and Madden 2004. The problem is, they're stuck with the x86 instruction set architecture, which is crufty at best. Maybe once people start buying Itaniums (if ever), they'll get better.
Tips for Intel designers: 1) Get rid of 20-stage pipeline, it's too long for anything serious. 2) As a follow up to 1, try to actually get some work done in a clock cycle. 3) Throw out the x86 ISA. 4) Look at the MIPS ISA. 5) Realize that it's actually possible to understand the MIPS arch, and that it still works great for multimedia, math, and general use. 6) Buy the rights to the MIPS ISA, make small improvements (get rid of branch delay slot, load delay slot), speed it up, and design new Intel processors from the improved ISA. 7) Release versions of processors with 4MB Cache (2MB each I$, D$) for consumers, and 24MB Cache (8MB I$, 16MB D$) for servers/clustering/etc. 8) Release Motherboards for 1, 2, and 4 CPU configurations. 9)... 10) Profit!
Or, you know, we could just use an efficient processor (one that provides better performance, with less power, and less heat)... Nah, we'll just change Motherboard layouts again. From Intel's viewpoint, that's much easier.
And yes, I do use x86-architecture processors, but that doesn't mean that I can't realize that the architecture sucks. Ia64 looks good, though, hopefully x86 will go away in 10 years or so.
n : a precise rule (or set of rules) specifying how to solve some problem
Sounds like a method to me... But just to be sure, let's check the thesaurus: ...machine, method, principle, process...
Yup, an algorithm is a method. Algorithm = Method, Algorithm != Code (code is an implementation of an algorithm). You can patent the algorithm, and copyright the implementation of the algorithm, but you can't stop people from finding another algorithm that accomplishes the same task.
Thanks, and on the other side of the case, would it matter? As far as I'm aware, the courts have always allowed the copying of functionality/appearance, just not the methods used. Since this is a compatibility issue, I doubt MS would have a case anyways, unless the methods used to be compatible were the same as their patented methods.
The only thing you can patent is an algorithm, not functionality. If you get a really broad patent on the algorithm, you might have a case, but it's a pretty weak one (since you may lose the patent). As I see it, software patents really aren't worth the trouble, since the only thing they really protect is your algorithm for doing something, but it tells everyone how you do it (making it easier to copy functionality). If MS does sue, who would they sue, and what would they get? It's pretty much guaranteed that they'll spend more in legal fees than they'll ever see if they win.
4k seems good for conventional oil, but a good synthetic should be good for around 8k or so. If you want the best oil possible, look into Red Line or Royal Purple synthetics. Both of those oils will last well beyond the regular synthetics (I believe they recommend 15,000, but it depends). As an added benefit, the lubrication properties of these are better than other oils, so you'll see a power/mileage/efficiency increase as well, and you'll reduce the wear on your engine. Sure, it's expensive (about 6x the price of a conventional), but it will pay for itself in the efficiency increases. I'd also recommend looking into the transmission products (ATF or Gear Lube), since you'll see the same benefits there, too.
Another thought.... If you have a transaction server, where you can split the load logically to the servers where the data is located, why couldn't you get both? If you have two major tables (as an example), and a few dozen trivial ones, split the tables between them (either at the table level, or at the row level, according to a hash on the key), and use queries on the transaction server to run commands on the individual servers.
If a server is unavailable, go to it's alternate, etc... This way, a complete copy of every table should be on 2-3 machines, but the load from an actual query run in your application is split (on average) evenly between all the servers in the cluster. If only 2-3 machines have the table, replication is easier, but you still maintain availability, and by splitting the data (since smaller tables/fewer queries mean less work), you scale performance pretty linearly. Sounds like a win-win to me, but I haven't tried it yet. Do any OSS transaction servers (for distributed transaction coordination) exist? If not, you'd have to do most of the coordination manually, but it shouldn't be that bad, as long as you do everything through well-designed stored procedures.
I was thinking along the same lines, but you'd have to handle the replication issues, which MySQL is still pretty weak on. PostgreSQL would probably be better in that case. If speed is really an issue (and downtime isn't as bad), you could split the data logically between systems, and use stored procedures running on a server that executes commands on multiple servers concurrently.
I remember using a space invaders type spelling program, but can't remember what it was called. Once you got to the higher levels, you had to know where every key was. It was simple (on an IBM PC it had to be [yes, the original, complete with 2 5.25" floppies and an Amber monochrome monitor]) but it was damn effective at getting you to learn where keys are.
I'm sure someone makes something similar to this, as it would be a little difficult to keep up with even the slower levels on modern hardware. Anyways, letters fall down from the sky, and you have to type them before they reach the bottom. Sounds simple, yes, until you have two or three of them falling about every other second, and you include the shifted symbols.
Cute story, but there's one major problem (besides the fact that it's simply untrue)....
Ok, I'm only going to say this one time, so don't forget it: Moore's law applies to the size of the gates, not the speed! For some reason, people seem to think that it applies to speed, but it is simply an observation on gate density. Gate speed has never followed Moore's observation for more than a very short period of time. The reason today's chips are so much faster is that (a) gate speed has increased due to more efficient designs and better materials, (b) gate density has increased roughly according to Moore's "law", and (c) die size has increased due to better manufacturing processes, since the better yields allow larger dies to be cost-effective. Moore's law is a great trend, but in reality it has nothing to do with speed increases, except that decreasing the size of a gate decreases propagation delays. The improvements in speed that have been made are more due to the number of transistors on a die, which have shot up due to (b) and (c), while each gate is faster due to (a), and only slightly (b). We have faster gates, on a bigger die, at a higher density.
As a follow up, once you have the scripts right, just write your code to print the labels, inserting data from your database where needed. If you don't use that many different formats, then you could just code everything straight into the program, kinda like embedding data in HTML in CGI scripts, except with output to the serial port.
Also, doing it this way will allow you to use the daisy-chain feature of the printers, since directing output to any printer on the chain is just another ZPL command. The ZPL manuals are available (reg. required) at Zebra's site (www.zebra.com, under support->manuals->Programming Language Manuals).
We use the Zebra printers where I work, and from my experience, you can do any label you need by sending the ZPL commands. All of the typesetting, graphics, and text can be coded into the fields, as well as the fonts and logic for printing barcodes. You can print to them in raster mode, too, but why do you need to?
Depending on your needs, it should only take a matter of an hour or two to code up something to generate ZPL from the user's requests, or you may be able to lex/yacc it from another format. Read the programmers manual that came with the printers (or at least should have). There are plenty of examples in there for barcodes, text, images, reverse printing, vertical printing, etc. I've done this for inventory coding (probably simpler than your needs), and it only took about 20 minutes of trial-and-error to get my ZPL script right. (And for reference, the format is a lot like a simplified PCL, so if you've had experience with PCL, it should be cake.)
I know there are other ways to generate all the parameters, but I try to avoid trusting Microsoft to implement something correctly. If you use the DeriveParameters function, or a data layer generator, can you be sure that it won't be broken in the next version? Hell, are you sure it works now? Keeping things as simple as possible allows complete control over how your code will behave, and the DeriveParameters function IMHO can't be trusted to work with all database vendors, and for all stored procedures. Building the SqlCommand object this way allows control over each parameter, the type, length, and any other attributes, which may or may not be handled correctly by generators or deriveparameters.
There are some great products out there for building simple database applications, but most of them don't scale well for large projects, or put unneccesary load on the server.
Whether strongly typed languages are quaint or not, they are important for situations where the software has to work, like medical, database (as in my example), or military uses. VB can be strongly typed (with option explicit), and in cases where you can get away with variables bound at compile time, it is really helpful in making sure your code works as intended.
Having said that, VB sucks at doing strongly typed variables. Use Ada, where if it compiles, it will work.
Good point, and you're right. The only other IDE I know of that is IMHO as good as VS is Anjuta. Automatic word completion and pop-up class heirarchies are the most productive thing in an IDE ever created. I can fly through sets of code used on an object in less than half the time, because I only need to type 10 letters on an average line. Things like param = cmd.Parameters.Add("@username", SqlDbType.Char, 15), can be typed in with cmd.P.A("@username", [down 3], 15).
Do that a hundred times or so for different strings or objects, and you'll appreciate it. Don't get me wrong, I type very fast, but why should I have to? Especially on repetitive things like that.
The only complaints I have are in VB, where a lot of things have been removed, and only about half of them are implemented in.NET. Try opening a com port in VB.NET (hint: you'll be using the C APIs the entire time). And no, I don't like VB/C#/VC++, but I do like paychecks.
Agreed, why not just have everyone buy a scooter? They're much faster, more intuitive, and can be used on the street, to actually go somewhere. I've seen 49cc scooters that get 110 mpg around here selling for about $800... Which when you consider the price of a segway, kinda makes you wonder why anyone would want a segway. Sure, you look goofy on a scooter, but you look goofy on a segway, so what difference does it make. At least on a scooter at 45mph, you won't have to see them make fun of you for as long.
Besides, if you didn't want to walk for 2.5 hours, why would you want to stand on a segway that long? Let's try educating the public on important things (like not running into things with their cars while gawking at a segway on the sidewalk), then worry about building machines to save them from the hassle of walking.
If you want a processor, and not just a microcontroller, but still want it fairly simple, you might want to check Motorola's Dragonball chips. It sounds like you want something with a low pin count, and simple ISA, so that'd be my first suggestion, followed very closely by ARM.
If you want a microcontroller, then maybe the 68HCxx series, or a RISC-ish PIC. The 68HCxx series is probably the most popular there, and you can easily find code and design samples for them.
Sorry, I forgot... There is parallelism at the process level, of course, since you could spread out the load (similar to Mosix), but then again, why would you use $2000+ new hardware to simulate something slower than what you can find on ebay for $50. We have several VAXes, all about 10-15 years old, and I can't even beat the slowest ones (about 15 VAX MIPS [VUPs]) with the best machines available.
Of course, I/O is quite a bit faster, but the simulated CPU is so much slower that it doesn't make a difference.
Slashdot Mirror
Exactly. Now, on the other hand... Why not use a Linux/BSD/Unix solution? Have you considered Mac? A few beefy Mac servers, with MS Office (Mac) installed, and dumb X consoles (similar to Sun's offering). You keep the simple, centralized management of Unix, keep Office (and probably Groupwise, etc... are available for OS X), and save on all your licenses. Sure, it costs a bit for the server hardware, but it costs next to nothing for the clients (and you only buy them once, no upgrades needed), and saves a ton of money in administration. (Ever tried applying the latest MS patch to 1000 machines? It takes a while, or more money for a good patch system. Ever tried applying patches to 1000 dumb terminals, oh... right... you won't ever have to.)
...And by the way, great topic, I run into the same thing at work, where it's only two or three applications that hold things up.
Also, check into Wine/WineX/Crossover Office to run your apps in Linux/BSD/etc. If you can run all your critical applications, you shouldn't have a problem. If the PHB's don't like Linux or *BSD, use a commercial Unix, it'll still be much cheaper and easier.
As an added bonus, if you want to reuse your old workstations for some of the terminals, you can try Knoppix/Gnoppix/your own Live CD. Time to upgrade? Just burn new copies for all the workstations and reboot.
I think it's more like -MORESTABLETHANCURRENT. In other words, it's sort of like a point release (the xx part) in Linux's Stable tree (2.4.xx). It means something like "We've tested this, and it looks good, but let us know if anything breaks", as opposed to -CURRENT's "We've run this once or twice, still working on it, please help us get it to work correctly", and -RELEASE's "You didn't complain when it was STABLE, so we're not planning on fixing any bugs for a long time".
So basically, CURRENT is like the 2.5.xx/2.6.xtest series of Linux, STABLE is like 2.4.xx, and RELEASE is more like 2.4.x9. Unless there are extreme circumstances, or important new hardware, RELEASE versions aren't put out that often. Hell, 4.7 and 4.8 were 6 months apart, and it'll be at least six months since 4.8 (April 3) before 4.9 is out.
I agree [almost] completely, except that you should not pay unless ordered to by a court, and you should file a lawsuit. Since you don't live in the US (and hance the parent's mention of HomeSec doesn't help), I'm not sure what laws you have to protect you, or how discovery proceedings work, but I would assume that there is some method to see all of the information they have on the subject, and from there you should easily be able to prove that it is not something you should be responsible for.
While you're waiting for the court proceedings to finish, it might be a good time to change providers, and make sure you have a good lawyer go over the contract, so you don't get stuck with things like this again. If you are to be billed for bandwidth usage, you should have a clause in there stipulating what types of packets count, and connectionless protocols should not count, or should at least be billed at a [much] lower rate.
At the end it's all about $.
Wait, so we're capitalists now?... In America?... When did THAT happen?...
Exactly, it may not be a person's favorite distribution, but RedHat has done, and continues to do a lot for Linux. Personally, I use Gentoo, but I'm happy to see a company succeed that puts as much legal, economic, and coding effort into Linux as RedHat does. It seems like RedHat and SuSe are behind a lot of good media coverage, and are usually the first ones to step up when needed (SuSe in Europe, and RedHat in North America, like in the SCO case).
Sure, they sell a free product, but what they're really selling is updates, pretty manuals, and their continued commitment to Linux, and support. Without RedHat and SuSe, Linux would probably be three years behind where it is now, and you wouldn't see as many companies switching to Linux, and as many Linux stories in the news.
That's exactly why the chances of a zero-day exploit are higher on open source software than closed source. *OUCH*
You've got a good point, except that it also means that someone can notice the problem and fix it. Besides, given the recent string of M$ security holes, wouldn't it be easier to just start throwing strings at all the services until one crashes? If throwing random data at a service crashes it, it's probably a good bet that there's another buffer overflow there. Apparently Microsoft doesn't seem to find bounds checking to be important. Maybe they should write Longhorn in Ada (actually, that might not be a bad idea). Hell, if you're going to write bloatware anyways, why not start with the most bloated language? (Don't get me wrong, Ada is a great language, but the standard library is rediculously large).
Yes, the deep pipelines ARE there for a reason, to do a ton of integer and floating point operations as fast as possible (so that SPECint and SPECfp scores are high). Now, back in the real world, we have real programs, and real programs branch. If the branch prediction fails, or if there is an unconditional jump or function call, the rest of the pipeline has to be thrown out. Wasting 19 clock cycles is bad, especially if you have a situation (like simulation) where branch prediction is unusable or usually fails, and you have 5 or 6 instructions, then a jump. In 26/27 clock cycles, you executed 6/7 instructions (assuming no fp, which could delay the pipeline further). This may seem like an extreme example, but it really isn't when you consider that most real programs deal with input of some sort.
As for the branch and load delay slots, yeah, they needed them when the MIPS ISA was set, but since the R10K, branch delays have been unnecessary. HP's PA-RISC doesn't use a branch delay, either (it just starts executing the next op, and throws it out if the branch is taken). Load delays will happen, but if the Memory stage is split for cache hits/misses, and cache is increased, the delay can be significantly reduced, and the result could be forwarded back to the execute stage, with maybe a half-cycle delay, rather than the current complete cycle.
And finally, no, compatibility doesn't matter more than performance/efficiency (depending on use), and the x86 ISA limits performance/efficiency. The Pentium 4s may be fast, but they are far from efficient. Market factors being what they are, it's all academic, but there really are serious performance problems with Intel's chips, it's just not economically practical to use the alternatives. And yes, I've read H&P, and they're mostly right, except that once the economics of speed reach a certain point (which happened probably 2 years ago), the processing power available allows large scale data processing (data mining, graphics, simulation, intelligent network filters, [anything that has a lot of data to make decisions on]) to be feasable, and there is an increase in the density of jumps in code. With more jumps, there are more pipeline stalls, and the longer pipelines multiply this problem. For a lot of these applications, a 400MHz MIPS processor will run circles around the latest 3.2+GHz Pentium.
...Pentium Extreme is much better than a 64 bit CPU, especially for the Pentium Extreme target market.
...
What, you mean for people who run 32-bit code?
The cache is something that's been sorely needed though, maybe Intel's finally going to make decent processors for people who need to run more than Word and Madden 2004. The problem is, they're stuck with the x86 instruction set architecture, which is crufty at best. Maybe once people start buying Itaniums (if ever), they'll get better.
Tips for Intel designers:
1) Get rid of 20-stage pipeline, it's too long for anything serious.
2) As a follow up to 1, try to actually get some work done in a clock cycle.
3) Throw out the x86 ISA.
4) Look at the MIPS ISA.
5) Realize that it's actually possible to understand the MIPS arch, and that it still works great for multimedia, math, and general use.
6) Buy the rights to the MIPS ISA, make small improvements (get rid of branch delay slot, load delay slot), speed it up, and design new Intel processors from the improved ISA.
7) Release versions of processors with 4MB Cache (2MB each I$, D$) for consumers, and 24MB Cache (8MB I$, 16MB D$) for servers/clustering/etc.
8) Release Motherboards for 1, 2, and 4 CPU configurations.
9)
10) Profit!
Or, you know, we could just use an efficient processor (one that provides better performance, with less power, and less heat)... Nah, we'll just change Motherboard layouts again. From Intel's viewpoint, that's much easier.
And yes, I do use x86-architecture processors, but that doesn't mean that I can't realize that the architecture sucks. Ia64 looks good, though, hopefully x86 will go away in 10 years or so.
From dictionary.com:
algorithm
n : a precise rule (or set of rules) specifying how to solve some problem
Sounds like a method to me... But just to be sure, let's check the thesaurus:
...machine, method, principle, process...
Yup, an algorithm is a method. Algorithm = Method, Algorithm != Code (code is an implementation of an algorithm). You can patent the algorithm, and copyright the implementation of the algorithm, but you can't stop people from finding another algorithm that accomplishes the same task.
Thanks, and on the other side of the case, would it matter? As far as I'm aware, the courts have always allowed the copying of functionality/appearance, just not the methods used. Since this is a compatibility issue, I doubt MS would have a case anyways, unless the methods used to be compatible were the same as their patented methods.
The only thing you can patent is an algorithm, not functionality. If you get a really broad patent on the algorithm, you might have a case, but it's a pretty weak one (since you may lose the patent). As I see it, software patents really aren't worth the trouble, since the only thing they really protect is your algorithm for doing something, but it tells everyone how you do it (making it easier to copy functionality). If MS does sue, who would they sue, and what would they get? It's pretty much guaranteed that they'll spend more in legal fees than they'll ever see if they win.
4k seems good for conventional oil, but a good synthetic should be good for around 8k or so. If you want the best oil possible, look into Red Line or Royal Purple synthetics. Both of those oils will last well beyond the regular synthetics (I believe they recommend 15,000, but it depends). As an added benefit, the lubrication properties of these are better than other oils, so you'll see a power/mileage/efficiency increase as well, and you'll reduce the wear on your engine. Sure, it's expensive (about 6x the price of a conventional), but it will pay for itself in the efficiency increases. I'd also recommend looking into the transmission products (ATF or Gear Lube), since you'll see the same benefits there, too.
Another thought....
If you have a transaction server, where you can split the load logically to the servers where the data is located, why couldn't you get both? If you have two major tables (as an example), and a few dozen trivial ones, split the tables between them (either at the table level, or at the row level, according to a hash on the key), and use queries on the transaction server to run commands on the individual servers.
If a server is unavailable, go to it's alternate, etc... This way, a complete copy of every table should be on 2-3 machines, but the load from an actual query run in your application is split (on average) evenly between all the servers in the cluster. If only 2-3 machines have the table, replication is easier, but you still maintain availability, and by splitting the data (since smaller tables/fewer queries mean less work), you scale performance pretty linearly. Sounds like a win-win to me, but I haven't tried it yet. Do any OSS transaction servers (for distributed transaction coordination) exist? If not, you'd have to do most of the coordination manually, but it shouldn't be that bad, as long as you do everything through well-designed stored procedures.
I was thinking along the same lines, but you'd have to handle the replication issues, which MySQL is still pretty weak on. PostgreSQL would probably be better in that case. If speed is really an issue (and downtime isn't as bad), you could split the data logically between systems, and use stored procedures running on a server that executes commands on multiple servers concurrently.
Hey, at least barbed wire is twisted pair!
I remember using a space invaders type spelling program, but can't remember what it was called. Once you got to the higher levels, you had to know where every key was. It was simple (on an IBM PC it had to be [yes, the original, complete with 2 5.25" floppies and an Amber monochrome monitor]) but it was damn effective at getting you to learn where keys are.
I'm sure someone makes something similar to this, as it would be a little difficult to keep up with even the slower levels on modern hardware. Anyways, letters fall down from the sky, and you have to type them before they reach the bottom. Sounds simple, yes, until you have two or three of them falling about every other second, and you include the shifted symbols.
Cute story, but there's one major problem (besides the fact that it's simply untrue)....
Ok, I'm only going to say this one time, so don't forget it: Moore's law applies to the size of the gates, not the speed!
For some reason, people seem to think that it applies to speed, but it is simply an observation on gate density. Gate speed has never followed Moore's observation for more than a very short period of time. The reason today's chips are so much faster is that (a) gate speed has increased due to more efficient designs and better materials, (b) gate density has increased roughly according to Moore's "law", and (c) die size has increased due to better manufacturing processes, since the better yields allow larger dies to be cost-effective.
Moore's law is a great trend, but in reality it has nothing to do with speed increases, except that decreasing the size of a gate decreases propagation delays. The improvements in speed that have been made are more due to the number of transistors on a die, which have shot up due to (b) and (c), while each gate is faster due to (a), and only slightly (b). We have faster gates, on a bigger die, at a higher density.
As a follow up, once you have the scripts right, just write your code to print the labels, inserting data from your database where needed. If you don't use that many different formats, then you could just code everything straight into the program, kinda like embedding data in HTML in CGI scripts, except with output to the serial port.
Also, doing it this way will allow you to use the daisy-chain feature of the printers, since directing output to any printer on the chain is just another ZPL command. The ZPL manuals are available (reg. required) at Zebra's site (www.zebra.com, under support->manuals->Programming Language Manuals).
We use the Zebra printers where I work, and from my experience, you can do any label you need by sending the ZPL commands. All of the typesetting, graphics, and text can be coded into the fields, as well as the fonts and logic for printing barcodes. You can print to them in raster mode, too, but why do you need to?
Depending on your needs, it should only take a matter of an hour or two to code up something to generate ZPL from the user's requests, or you may be able to lex/yacc it from another format. Read the programmers manual that came with the printers (or at least should have). There are plenty of examples in there for barcodes, text, images, reverse printing, vertical printing, etc. I've done this for inventory coding (probably simpler than your needs), and it only took about 20 minutes of trial-and-error to get my ZPL script right. (And for reference, the format is a lot like a simplified PCL, so if you've had experience with PCL, it should be cake.)
I know there are other ways to generate all the parameters, but I try to avoid trusting Microsoft to implement something correctly. If you use the DeriveParameters function, or a data layer generator, can you be sure that it won't be broken in the next version? Hell, are you sure it works now? Keeping things as simple as possible allows complete control over how your code will behave, and the DeriveParameters function IMHO can't be trusted to work with all database vendors, and for all stored procedures. Building the SqlCommand object this way allows control over each parameter, the type, length, and any other attributes, which may or may not be handled correctly by generators or deriveparameters.
There are some great products out there for building simple database applications, but most of them don't scale well for large projects, or put unneccesary load on the server.
Whether strongly typed languages are quaint or not, they are important for situations where the software has to work, like medical, database (as in my example), or military uses. VB can be strongly typed (with option explicit), and in cases where you can get away with variables bound at compile time, it is really helpful in making sure your code works as intended.
Having said that, VB sucks at doing strongly typed variables. Use Ada, where if it compiles, it will work.
Good point, and you're right. The only other IDE I know of that is IMHO as good as VS is Anjuta. Automatic word completion and pop-up class heirarchies are the most productive thing in an IDE ever created. I can fly through sets of code used on an object in less than half the time, because I only need to type 10 letters on an average line. Things like param = cmd.Parameters.Add("@username", SqlDbType.Char, 15), can be typed in with cmd.P.A("@username", [down 3], 15).
.NET. Try opening a com port in VB.NET (hint: you'll be using the C APIs the entire time). And no, I don't like VB/C#/VC++, but I do like paychecks.
Do that a hundred times or so for different strings or objects, and you'll appreciate it. Don't get me wrong, I type very fast, but why should I have to? Especially on repetitive things like that.
The only complaints I have are in VB, where a lot of things have been removed, and only about half of them are implemented in
Agreed, why not just have everyone buy a scooter? They're much faster, more intuitive, and can be used on the street, to actually go somewhere. I've seen 49cc scooters that get 110 mpg around here selling for about $800... Which when you consider the price of a segway, kinda makes you wonder why anyone would want a segway. Sure, you look goofy on a scooter, but you look goofy on a segway, so what difference does it make. At least on a scooter at 45mph, you won't have to see them make fun of you for as long.
Besides, if you didn't want to walk for 2.5 hours, why would you want to stand on a segway that long? Let's try educating the public on important things (like not running into things with their cars while gawking at a segway on the sidewalk), then worry about building machines to save them from the hassle of walking.
If you want a processor, and not just a microcontroller, but still want it fairly simple, you might want to check Motorola's Dragonball chips. It sounds like you want something with a low pin count, and simple ISA, so that'd be my first suggestion, followed very closely by ARM.
If you want a microcontroller, then maybe the 68HCxx series, or a RISC-ish PIC. The 68HCxx series is probably the most popular there, and you can easily find code and design samples for them.
Sorry, I forgot... There is parallelism at the process level, of course, since you could spread out the load (similar to Mosix), but then again, why would you use $2000+ new hardware to simulate something slower than what you can find on ebay for $50. We have several VAXes, all about 10-15 years old, and I can't even beat the slowest ones (about 15 VAX MIPS [VUPs]) with the best machines available.
Of course, I/O is quite a bit faster, but the simulated CPU is so much slower that it doesn't make a difference.