Once upon a time I was part of a company acquired by a parent company. Sometime thereafter, parent company's product started displaying an error message and then exiting on all of their customers' computers at the same time. Apparently the (hard-coded) license key for some 3rd party component had expired and as a result hundreds if not thousands of people couldn't do their jobs. The affected product Team Leader's fix was to get a new license key, replace it in the source, compile and then get everyone on that new version as soon as possible. The problem was that good ol' parent company didn't have great source control procedures nor a build server prior to acquiring some real developers (us) so there was a huge variety of versions of the product across all of their customers, some of which were known to contain custom one-off features and changes that potentially never made it into source control in the first place... Also the product couldn't be upgraded without also upgrading some or all of the server pieces too. It was a big mess with potentially days of downtime to clean it up and their customers were losing money by the minute and rightfully PISSED.
My solution was to create a little utility that looked for copies of the product in the usual places and replace the expired license key (stored in UTF-16 in the.exe) with the new one. Since the keys were the same length, it worked perfectly and the support team was able to deploy that to all of their customers in the matter of hours.
Mod parent up. These other replies talking about marking packets and the whole stream of routers needing to respect them don't seem to have a clue about your standard home Internet connection.
Here's the deal, in a nutshell: Your cable modem or DSL line is the bottleneck. Your LAN is very fast and so is the rest if the Internet, if you can get your packet past your modem. It is your cable modem or DSL modem that is actually dropping packets when you saturate your upload bandwidth. It doesn't matter whether or not they have buffers or not (many cable modems have BIG upload buffers, causing all kinds of latency problems) the fact is, your DSL modem or cable modem DOES NOT RESPECT QoS priority flags on packets when it starts dropping. Sorry, they just don't.
So you need to do what the parent said and artifically limit your bandwidth in your router, so every packet your router sends to your cable modem or DSL modem WILL go out, because it hasn't hit its own limit. Then, with prioritization rules, you can make sure your outgoing VoIP packets will not be dropped - there's no need to reserve upload bandwidth for this.
The same thing works for downloading. You can't directly control what the other side sends you, but you CAN artificially limit your download speed, in your router, to make it the bottleneck. What happens is that your router will start dropping packets before your cable modem or DSL modem's download stream gets saturated. These dropped packets will cause a TCP connection's window to drop and the other end will be forced to resend data and slow down its sending rate. This achieves exactly what you want - the other end to stop saturating your connection (or close to it). In this way you can indirectly control what the other side sends you and which streams get priority.
The download throttling and prioritization obviously doesn't work (well) unless the majority of the traffic coming in is TCP. Otherwise reserving bandwidth for VoIP in this case works too.
You can do a great job of QoS on a typical DD-WRT modem, if you make it the bottleneck, which obviously requires knowing your sustainable upload and download rates on your connection. In my experience most DSL and cable limits are very stable. The exception might be cable connections in neighborhoods where they've oversold the headend and your bandwidth suffers during peek hours (6pm to midnight.)
As a developer on the other side, caching is not the solution to this problem. Caching is implemented client side as a *benefit to the client*, not the server. On some platforms (that need to verify XML) caching isn't even really possible. The extra overhead of caching (where do you put it, what program/process maintains it, how is it configured) is entirely unnecessary. The real problem lies in the spec and the various examples floating around.
Do not make attendance mandatory, subtractive, etc.
I had a professor in college that did exactly that - attendance was mandatory. You got 3 excused absences. After the 3rd, he dropped you 10% (a full letter grade) for every missed day.
The result? All the losers who didn't want to be there showed up to sign the attendance sheet. The result was a crowded clasroom (most every seat was taken) filled with people not paying attention. They were wispering to each other, studying for other classes, etc. Those of us actually TRYING to pay attention had a hard time just finding a seat, much less actually being able to pay attention to the lecture.
University students are adults, and they are capable of making their own decisions. Yes, they may be bad decisions, but that's not your problem.
Let me add a few more things that should steer you away from VB6, speaking from someone who worked on an EXTREMELY large VB6 application (think 200+ ActiveX dlls) for just over a year:
There are many BAD things you can do in VB6 that create some really ugly and broken code. Every language has these, but they are very prevaliant in VB6 like:
variants automatic variable declaration (not using option explicit) lack of parenthesis around method calls making for very hard to read and sometimes ambiguous code. integers are 16 bit, not 32.
This doesn't even get into the ActiveX/COM hell you can run into, especially across different versions of your software. Single apps work fine, but as soon as you start creating your own controls and modules, expect trouble at the customer site even just other developer's workstations during upgrades. There's some rules you need to follow about breaking compatibility and changing interfaces, not to mention registering the ocxs and dlls.
So, for the development team of 100+ I was a part of, these issues had been solved and a strict set of guidelines were followed to make things run smoothly. During my first few months working on it, these rules were beaten into me.
For your team of 10 developers, you're going to constantly be bumping heads against these issues and they will eat up gobs of time until you get them figured out and beaten into your coworkers.
Most, if not all of these issues have been resolved in the.NET environment. Couple that with the fact VB6 has been EOL'd and there are 1) a bunch of bugs in the built-in GUI components that need to be worked around and 2) few, if any, third party components still being actively developed for it.
Let me poke a few big gaping holes in your argument:
1. You cannot plan for every possible future feature.
Let me say that another way, in case that wasn't clear.
You cannot "anticipating the need to add future functionality at a later time" for every possible variation of future functionality. Yes, you can anticipate some, but not all.
2. Anticipating future functionality and building in the modularity to accomidate it is called speculative generality, and can KILL your productivity. There will always be a tradeoff between speculative generality and getting software out the door. At some point you will probably have to redesign and rewrite entire groupings of modules to accomplish a feature that simply wasn't though of during the original design. It can and WILL affect more than one module. An excellent example is something that was designed to be 1:1, and later needs to be 1:n. This affects everything from the low-level backend stuff up through the GUI. You cannot always plan for this sort of thing because it may not even make sense during the initial design.
3. You cannot test every possible scenario. This can be proven very easily.
Your theory is nice (as is the theory of Software "Engineering") but reality always falls somewhere short of ideal.
I'm sure it would be faster, but the goal was to get it to work with 30-100 nodes or more. Unfortunately, the basis of the algorithm while running degraded is gaussian elimination (in a Galois field so you're dealing with integers instead of floating points). However, if you managed to distribute the processing to the other nodes, you might get it to scale, since (I'm pretty sure) each byte you want to recover requires N multiplication/subtraction operations in the augmented matrix.
However, that would require a much more complicated setup and code, along with the requirement that each node's CPU be used, which doesn't fit the original requirement of using existing PCs in a lab or office environment.
This can be done quite easily with Reed-Solomon coding. In fact, you don't need the majority of the nodes, but simply an arbitrary N set of nodes, with an arbitrary M nodes as redundancy. N=1 and M=1 is basically RAID1. N = n and M = 1 is simply RAID5, N=n and M=2 is RAID 6.
In fact, I wrote a RSRaid driver for Linux for my thesis and did some performance testing on it. I'll save you the 30 pages and just tell you that the algorithm is far too CPU intensive to scale up very well for fileserver use (my original intent,) but I did conclude it could be used as a backup alternative to tape. Hmmmm.
Direct Link Google Cache
Please forgive the double brackets, I fought witH Word and lost.
Contact me if you'd like to play with the code. I never did any reconstruction code, but the system did work in a degraded state, and was written for the Linux 2.6 kernel.
According to that site, the manual actually claims it is only a 250 watt power supply when used on 120V. You might be able to scrape a decent system up to run at 300 watts, but 250 is almost out of the question.
After porting an MSSQL enterprise-level app to Oracle, I've concluded that some things in Oracle seem needlessly complex, starting with TNSNAMES.ORA. The entire connection path from the application->client->listener->instance->database is probably due to a lot of legacy. When you toss RAC into the mix, listeners gain the ability to redirect you to a different listener which can wreck all kinds of havoc if you're trying to use NAT or don't have your DNS setup quite right.
I wouldn't mind the complexity if I could find some decent documentation on things like this, and if the error messages were a little more robust. A INTERMITTANT name-resolution lookup error doesn't make a lot of sense by itself, but if it told you it had been redirected...
I did a couple Regional ACM competitions, a few local ones, etc. They were fun, after the first one. My recommendations:
1. Know your environment. The competitions I've been to give you some time on the computers before the competition to get to know the environment, compiler, IDE, etc. Make good use of it. If they have Eclipse, what version of Java, gcc, pascal, etc. Know the editor you are going to use. Do they have emacs, vi, etc? Knowing your environment will greatly reduce your write-compile-test time, which is critical during a competition.
2. If writing templates beforehand is not allowed, bring one in on paper and take the 2 minutes beforehand (with the fastest typest in the group) to type it up. Ours consisted of an input loop/string parser with a loop that could be easily changed to accept input from the terminal (required for submitted programs) or a file (easier for testing sample input files.)
3. Know your language(s). Know what's allowed in the competition, have several references handy for each language you plan to use. My team tended to use Java, but at the time there wasn't a built-in priority queue in Java. Dijkstra's shortest path algorithm requires a priority queue, so I spent some time before hand coming up with a very easy to type ( 1 page) general purpose priority queue. We weren't allowed any electronic resources, but if you can type fast enough, you can create any basic structure you need very quickly. When built-in structures are available, USE THEM, and use them extensively.
4. Do the easiest problems first. Simple math will show you that you get the most points this way.
5. Study existing problems. The local competitions tended to repeat problems from other regional (or national) competitions. We used those to practice from, so it made it a breeze when those problems came up.
6. Don't get hung up on a problem. You'll waste tons of time, and there's ALWAYS the possibility that the submission checker is WRONG and your problem is right. Its happened at both regional competitions. They eventually find their mistake and your previous submission will be counted as correct.
7. Practice. You'll get used to the problems and be able to analyze how long a particular problem will take much easier. You'll get to know your teammate's strengths and weaknesses. One teammate of mine was very good at solving problems but his coding skills were a bit off. He'd write up the solution, I'd debug his programs. We did quite well that way.
I've recently ported an mid-size level enterprise application to both MySQL and Oracle from MS SQL. Amongst this was a data layer in C# and about 200 stored procedures. I have this to say:
Besides the null/empty string thing, converting to Oracle was a breeze. Oracle even provides a migration wizard, that, with a little tuning, converted most of the stored procedures automatically.
On the other hand, working with stored procedures in a beta version of MySQL 5.x was a huge pain. The utilities didn't support them well, and crashed constantly. I eventually gave up trying to use the included utilities and stuck with the console. I would think beta meant "most usable", but that was nowhere near the case.
The.NET connector was buggy as heck. Just getting a stored procedure to run took me two days due to a case sensitivity problem. The error messages were hugely cryptic (stored procedure not found actually created a message like "Invalid attempt to access a field before calling Read()"). I had to dig down into the code and make fixes myself to get a reliably working connector, since it didn't handle all whitespace between parameters in a stored procedure properly.
As mentioned elsewhere, MySQL has no problem inserting bogus data into fields, such as 00/00/00 00:00:00 for a date/time. That wouldn't be so bad, except it completely borks up the.NET connector when trying to read that data (it throws an exception and won't return any data.)
Now, some of this I'd rack up to it being a beta, which is fine. Beta software has bugs. BUT, the length of time it took to get those bugs recognized and fixed was over a month! (see bugs 9722 and 9668.) It took another 2 months before those fixes were included in a release. One was erroneously marked as duplicate, even though there is no other bug in the system (earlier or later) describing the same problem. Requests to find out what it was "duplicating" went ignored. I have no idea if that bug is actually fixed or not now. I'd expect a company with a product in beta to be responsive to people putting it through its paces, and acknowledge and fix bugs quickly. Neither happened.
The kicker was when we contacted MySQL to get some sort of developer license. We wanted to include the.NET connector in our general release, since our data layer compiled against it. Their own sales people were clueless as to how to go about such a thing and eventually concluded it wasn't possible. What sort of company makes a developer component that you can't license?
We finally gave up on MySQL. We were 90% done converting, ran up against the licensing wall and simple dropped the project. We may revisit when 5.x is released and stable if they actually have some sort of developer license for their COM/ODBC components.
Along the same lines, I would think that a very pure, well-formed crystalline solid would be able to be super-heated, then jarred and the whole thing would melt instantly.
Googling for superheated solid returned a bunch of research papers, but that was about it.
The one thing you are missing is that the.doc format belongs to Microsoft Word. There is only 1 proper way of displaying the document - exactly how Microsoft Word does. Anything else is a bug. Whatever fixes/workaround OO has to do to get that functionality is irrelevant.
just imagine not just the invention of Google, but a Google that would change its results in real-time and which would do web page, image, PDF search etc. all at the same time.
You mean, like Google Suggest?
Ok, it doesn't actually show results in real-time, but it does give you the approximate number of results for what you've typed and what you might be about to type.
I keep seeing the distinction between the API and the source code, but more often than not the code is the only reliable documentation of the API anyway - original API specs get horribly out of date during implementation. Many API specs include sample implementations too. So saying MS needs to license the API but not the source is somewhat contradictory.
The easiest and cheapest way for MS to "license the API" is simply to license the source and let the purchaser dig through and find what they need.
Just a glance through the rantings of the Samba team will show you that the protocols they are trying to use are full of bugs and special cases that change with the operating system you are communicating with. The "full API" is probably a combination of the original design specs patched with bug reports and the comments within the implementation code.
To publish a complete API (without implementation code) would cost MS a decent amount of money to simply produce it in the first place.
Why would wide-spread distribution of Linux be good? Would it make games easier to install? Easier to install drivers?
Just because you don't like MS and/or Sony and/or Nintendo is not a good enough reason to push Linux for gamers.
In order to take over in any market, you not only have to do EVERYTHING your competetor does, but you need to do it BETTER. This is true of Linux in certain niche markets, but has a long way to go before it'll take over the general desktop for any purpose, gaming or otherwise.
What it sounds like you are doing is actually RAID 4, not RAID 3 (commonly confused, RAID 3 is basically never used, as it specifies a stripe size of a byte instead of a configurable block size).
You may want to try RAID 5. It has consistently better performance because the parity information is rotated around the drives so the single parity drive doesn't become the bottleneck.
Right now it is possible to get a degree in EE without ever having picked up a soldering iron.
That's like a Computer Science student getting a degree without ever having used a mouse or keyboard. Am I the only one who thinks this is insane?
I would think the department could assume a certain level of compentancy in basic electricity concepts and have some practical experience building circuits. Those that don't could either learn it from the guy down the hall who does, or take a pre-100 level EE course where they play with those Radio Shack xxx-in-one electronics kits.
The CS departments I've encountered all assume a basic knowledge of computers, and most require a working knowledge of *nix (or it is crammed down your throat in the first two lectures of CS 101). Those that don't can take one of the 3-week intro courses on using *nix or using a mouse.
Certainly it isn't too much to hold EE students to the same caliber? I would think by the time you sign up for an EE major you should at least know Ohm's law, and be ready to learn some theory instead of just connecting wires according to a book.
Slashdot Mirror
Once upon a time I was part of a company acquired by a parent company. Sometime thereafter, parent company's product started displaying an error message and then exiting on all of their customers' computers at the same time. Apparently the (hard-coded) license key for some 3rd party component had expired and as a result hundreds if not thousands of people couldn't do their jobs. The affected product Team Leader's fix was to get a new license key, replace it in the source, compile and then get everyone on that new version as soon as possible. The problem was that good ol' parent company didn't have great source control procedures nor a build server prior to acquiring some real developers (us) so there was a huge variety of versions of the product across all of their customers, some of which were known to contain custom one-off features and changes that potentially never made it into source control in the first place... Also the product couldn't be upgraded without also upgrading some or all of the server pieces too. It was a big mess with potentially days of downtime to clean it up and their customers were losing money by the minute and rightfully PISSED.
My solution was to create a little utility that looked for copies of the product in the usual places and replace the expired license key (stored in UTF-16 in the .exe) with the new one. Since the keys were the same length, it worked perfectly and the support team was able to deploy that to all of their customers in the matter of hours.
Mod parent up. These other replies talking about marking packets and the whole stream of routers needing to respect them don't seem to have a clue about your standard home Internet connection.
Here's the deal, in a nutshell: Your cable modem or DSL line is the bottleneck. Your LAN is very fast and so is the rest if the Internet, if you can get your packet past your modem. It is your cable modem or DSL modem that is actually dropping packets when you saturate your upload bandwidth. It doesn't matter whether or not they have buffers or not (many cable modems have BIG upload buffers, causing all kinds of latency problems) the fact is, your DSL modem or cable modem DOES NOT RESPECT QoS priority flags on packets when it starts dropping. Sorry, they just don't.
So you need to do what the parent said and artifically limit your bandwidth in your router, so every packet your router sends to your cable modem or DSL modem WILL go out, because it hasn't hit its own limit. Then, with prioritization rules, you can make sure your outgoing VoIP packets will not be dropped - there's no need to reserve upload bandwidth for this.
The same thing works for downloading. You can't directly control what the other side sends you, but you CAN artificially limit your download speed, in your router, to make it the bottleneck. What happens is that your router will start dropping packets before your cable modem or DSL modem's download stream gets saturated. These dropped packets will cause a TCP connection's window to drop and the other end will be forced to resend data and slow down its sending rate. This achieves exactly what you want - the other end to stop saturating your connection (or close to it). In this way you can indirectly control what the other side sends you and which streams get priority.
The download throttling and prioritization obviously doesn't work (well) unless the majority of the traffic coming in is TCP. Otherwise reserving bandwidth for VoIP in this case works too.
You can do a great job of QoS on a typical DD-WRT modem, if you make it the bottleneck, which obviously requires knowing your sustainable upload and download rates on your connection. In my experience most DSL and cable limits are very stable. The exception might be cable connections in neighborhoods where they've oversold the headend and your bandwidth suffers during peek hours (6pm to midnight.)
As a developer on the other side, caching is not the solution to this problem. Caching is implemented client side as a *benefit to the client*, not the server. On some platforms (that need to verify XML) caching isn't even really possible. The extra overhead of caching (where do you put it, what program/process maintains it, how is it configured) is entirely unnecessary. The real problem lies in the spec and the various examples floating around.
PLEASE DO NOT EVEN CONSIDER DOING THIS!
Do not make attendance mandatory, subtractive, etc.
I had a professor in college that did exactly that - attendance was mandatory. You got 3 excused absences. After the 3rd, he dropped you 10% (a full letter grade) for every missed day.
The result? All the losers who didn't want to be there showed up to sign the attendance sheet. The result was a crowded clasroom (most every seat was taken) filled with people not paying attention. They were wispering to each other, studying for other classes, etc. Those of us actually TRYING to pay attention had a hard time just finding a seat, much less actually being able to pay attention to the lecture.
University students are adults, and they are capable of making their own decisions. Yes, they may be bad decisions, but that's not your problem.
Let me add a few more things that should steer you away from VB6, speaking from someone who worked on an EXTREMELY large VB6 application (think 200+ ActiveX dlls) for just over a year:
.NET environment. Couple that with the fact VB6 has been EOL'd and there are 1) a bunch of bugs in the built-in GUI components that need to be worked around and 2) few, if any, third party components still being actively developed for it.
There are many BAD things you can do in VB6 that create some really ugly and broken code. Every language has these, but they are very prevaliant in VB6 like:
variants
automatic variable declaration (not using option explicit)
lack of parenthesis around method calls making for very hard to read and sometimes ambiguous code.
integers are 16 bit, not 32.
This doesn't even get into the ActiveX/COM hell you can run into, especially across different versions of your software. Single apps work fine, but as soon as you start creating your own controls and modules, expect trouble at the customer site even just other developer's workstations during upgrades. There's some rules you need to follow about breaking compatibility and changing interfaces, not to mention registering the ocxs and dlls.
So, for the development team of 100+ I was a part of, these issues had been solved and a strict set of guidelines were followed to make things run smoothly. During my first few months working on it, these rules were beaten into me.
For your team of 10 developers, you're going to constantly be bumping heads against these issues and they will eat up gobs of time until you get them figured out and beaten into your coworkers.
Most, if not all of these issues have been resolved in the
You, my friend, are obviously clearly in group 2.
Let me poke a few big gaping holes in your argument:
1. You cannot plan for every possible future feature.
Let me say that another way, in case that wasn't clear.
You cannot "anticipating the need to add future functionality at a later time" for every possible variation of future functionality. Yes, you can anticipate some, but not all.
2. Anticipating future functionality and building in the modularity to accomidate it is called speculative generality, and can KILL your productivity. There will always be a tradeoff between speculative generality and getting software out the door. At some point you will probably have to redesign and rewrite entire groupings of modules to accomplish a feature that simply wasn't though of during the original design. It can and WILL affect more than one module. An excellent example is something that was designed to be 1:1, and later needs to be 1:n. This affects everything from the low-level backend stuff up through the GUI. You cannot always plan for this sort of thing because it may not even make sense during the initial design.
3. You cannot test every possible scenario. This can be proven very easily.
Your theory is nice (as is the theory of Software "Engineering") but reality always falls somewhere short of ideal.
I'm sure it would be faster, but the goal was to get it to work with 30-100 nodes or more. Unfortunately, the basis of the algorithm while running degraded is gaussian elimination (in a Galois field so you're dealing with integers instead of floating points). However, if you managed to distribute the processing to the other nodes, you might get it to scale, since (I'm pretty sure) each byte you want to recover requires N multiplication/subtraction operations in the augmented matrix.
However, that would require a much more complicated setup and code, along with the requirement that each node's CPU be used, which doesn't fit the original requirement of using existing PCs in a lab or office environment.
This can be done quite easily with Reed-Solomon coding. In fact, you don't need the majority of the nodes, but simply an arbitrary N set of nodes, with an arbitrary M nodes as redundancy. N=1 and M=1 is basically RAID1. N = n and M = 1 is simply RAID5, N=n and M=2 is RAID 6.
In fact, I wrote a RSRaid driver for Linux for my thesis and did some performance testing on it. I'll save you the 30 pages and just tell you that the algorithm is far too CPU intensive to scale up very well for fileserver use (my original intent,) but I did conclude it could be used as a backup alternative to tape. Hmmmm.
Direct Link
Google Cache
Please forgive the double brackets, I fought witH Word and lost.
Contact me if you'd like to play with the code. I never did any reconstruction code, but the system did work in a degraded state, and was written for the Linux 2.6 kernel.
According to that site, the manual actually claims it is only a 250 watt power supply when used on 120V. You might be able to scrape a decent system up to run at 300 watts, but 250 is almost out of the question.
After porting an MSSQL enterprise-level app to Oracle, I've concluded that some things in Oracle seem needlessly complex, starting with TNSNAMES.ORA. The entire connection path from the application->client->listener->instance->database is probably due to a lot of legacy. When you toss RAC into the mix, listeners gain the ability to redirect you to a different listener which can wreck all kinds of havoc if you're trying to use NAT or don't have your DNS setup quite right.
I wouldn't mind the complexity if I could find some decent documentation on things like this, and if the error messages were a little more robust. A INTERMITTANT name-resolution lookup error doesn't make a lot of sense by itself, but if it told you it had been redirected...
Seems like we've crossed the line from honest critique to irrational hatred...
You're new here, aren't you?
Good thing I just switched to Opera. :)
I did a couple Regional ACM competitions, a few local ones, etc. They were fun, after the first one. My recommendations:
1. Know your environment. The competitions I've been to give you some time on the computers before the competition to get to know the environment, compiler, IDE, etc. Make good use of it. If they have Eclipse, what version of Java, gcc, pascal, etc. Know the editor you are going to use. Do they have emacs, vi, etc? Knowing your environment will greatly reduce your write-compile-test time, which is critical during a competition.
2. If writing templates beforehand is not allowed, bring one in on paper and take the 2 minutes beforehand (with the fastest typest in the group) to type it up. Ours consisted of an input loop/string parser with a loop that could be easily changed to accept input from the terminal (required for submitted programs) or a file (easier for testing sample input files.)
3. Know your language(s). Know what's allowed in the competition, have several references handy for each language you plan to use. My team tended to use Java, but at the time there wasn't a built-in priority queue in Java. Dijkstra's shortest path algorithm requires a priority queue, so I spent some time before hand coming up with a very easy to type ( 1 page) general purpose priority queue. We weren't allowed any electronic resources, but if you can type fast enough, you can create any basic structure you need very quickly. When built-in structures are available, USE THEM, and use them extensively.
4. Do the easiest problems first. Simple math will show you that you get the most points this way.
5. Study existing problems. The local competitions tended to repeat problems from other regional (or national) competitions. We used those to practice from, so it made it a breeze when those problems came up.
6. Don't get hung up on a problem. You'll waste tons of time, and there's ALWAYS the possibility that the submission checker is WRONG and your problem is right. Its happened at both regional competitions. They eventually find their mistake and your previous submission will be counted as correct.
7. Practice. You'll get used to the problems and be able to analyze how long a particular problem will take much easier. You'll get to know your teammate's strengths and weaknesses. One teammate of mine was very good at solving problems but his coding skills were a bit off. He'd write up the solution, I'd debug his programs. We did quite well that way.
I've recently ported an mid-size level enterprise application to both MySQL and Oracle from MS SQL. Amongst this was a data layer in C# and about 200 stored procedures. I have this to say:
.NET connector was buggy as heck. Just getting a stored procedure to run took me two days due to a case sensitivity problem. The error messages were hugely cryptic (stored procedure not found actually created a message like "Invalid attempt to access a field before calling Read()"). I had to dig down into the code and make fixes myself to get a reliably working connector, since it didn't handle all whitespace between parameters in a stored procedure properly.
.NET connector when trying to read that data (it throws an exception and won't return any data.)
.NET connector in our general release, since our data layer compiled against it. Their own sales people were clueless as to how to go about such a thing and eventually concluded it wasn't possible. What sort of company makes a developer component that you can't license?
Besides the null/empty string thing, converting to Oracle was a breeze. Oracle even provides a migration wizard, that, with a little tuning, converted most of the stored procedures automatically.
On the other hand, working with stored procedures in a beta version of MySQL 5.x was a huge pain. The utilities didn't support them well, and crashed constantly. I eventually gave up trying to use the included utilities and stuck with the console. I would think beta meant "most usable", but that was nowhere near the case.
The
As mentioned elsewhere, MySQL has no problem inserting bogus data into fields, such as 00/00/00 00:00:00 for a date/time. That wouldn't be so bad, except it completely borks up the
Now, some of this I'd rack up to it being a beta, which is fine. Beta software has bugs. BUT, the length of time it took to get those bugs recognized and fixed was over a month! (see bugs 9722 and 9668.) It took another 2 months before those fixes were included in a release. One was erroneously marked as duplicate, even though there is no other bug in the system (earlier or later) describing the same problem. Requests to find out what it was "duplicating" went ignored. I have no idea if that bug is actually fixed or not now. I'd expect a company with a product in beta to be responsive to people putting it through its paces, and acknowledge and fix bugs quickly. Neither happened.
The kicker was when we contacted MySQL to get some sort of developer license. We wanted to include the
We finally gave up on MySQL. We were 90% done converting, ran up against the licensing wall and simple dropped the project. We may revisit when 5.x is released and stable if they actually have some sort of developer license for their COM/ODBC components.
I had chili for dinner. 'scuse me.
Along the same lines, I would think that a very pure, well-formed crystalline solid would be able to be super-heated, then jarred and the whole thing would melt instantly.
Googling for superheated solid returned a bunch of research papers, but that was about it.
The one thing you are missing is that the .doc format belongs to Microsoft Word. There is only 1 proper way of displaying the document - exactly how Microsoft Word does. Anything else is a bug. Whatever fixes/workaround OO has to do to get that functionality is irrelevant.
just imagine not just the invention of Google, but a Google that would change its results in real-time and which would do web page, image, PDF search etc. all at the same time.
You mean, like Google Suggest?
Ok, it doesn't actually show results in real-time, but it does give you the approximate number of results for what you've typed and what you might be about to type.
I keep seeing the distinction between the API and the source code, but more often than not the code is the only reliable documentation of the API anyway - original API specs get horribly out of date during implementation. Many API specs include sample implementations too. So saying MS needs to license the API but not the source is somewhat contradictory.
The easiest and cheapest way for MS to "license the API" is simply to license the source and let the purchaser dig through and find what they need.
Just a glance through the rantings of the Samba team will show you that the protocols they are trying to use are full of bugs and special cases that change with the operating system you are communicating with. The "full API" is probably a combination of the original design specs patched with bug reports and the comments within the implementation code.
To publish a complete API (without implementation code) would cost MS a decent amount of money to simply produce it in the first place.
Why would you want to see it in person when you can see it via a controllable web-cam?
Doh. Forgot to login. Mod parent up.
Why would wide-spread distribution of Linux be good? Would it make games easier to install? Easier to install drivers?
Just because you don't like MS and/or Sony and/or Nintendo is not a good enough reason to push Linux for gamers.
In order to take over in any market, you not only have to do EVERYTHING your competetor does, but you need to do it BETTER. This is true of Linux in certain niche markets, but has a long way to go before it'll take over the general desktop for any purpose, gaming or otherwise.
What it sounds like you are doing is actually RAID 4, not RAID 3 (commonly confused, RAID 3 is basically never used, as it specifies a stripe size of a byte instead of a configurable block size).
You may want to try RAID 5. It has consistently better performance because the parity information is rotated around the drives so the single parity drive doesn't become the bottleneck.
Please mod parent down. Link is to the WRONG PAPER!
Right now it is possible to get a degree in EE without ever having picked up a soldering iron.
That's like a Computer Science student getting a degree without ever having used a mouse or keyboard. Am I the only one who thinks this is insane?
I would think the department could assume a certain level of compentancy in basic electricity concepts and have some practical experience building circuits. Those that don't could either learn it from the guy down the hall who does, or take a pre-100 level EE course where they play with those Radio Shack xxx-in-one electronics kits.
The CS departments I've encountered all assume a basic knowledge of computers, and most require a working knowledge of *nix (or it is crammed down your throat in the first two lectures of CS 101). Those that don't can take one of the 3-week intro courses on using *nix or using a mouse.
Certainly it isn't too much to hold EE students to the same caliber? I would think by the time you sign up for an EE major you should at least know Ohm's law, and be ready to learn some theory instead of just connecting wires according to a book.