You should always try and build as much of your rules into the db app server - thats what it is - an application server, don't put all your logic in your client app.
Yeah, the DB vendors love for you to do this because it locks you in to their DBMS -- portability of stored procedure (etc) code not being one of the database world's high points.
That said, you ought to be able to rely on the DBMS to enforce at least some constraints, and you should be taking advantage of at least the minimal subset of same that all real DB servers support. (And if you're building an enterprise-specific application where portability is much less of an issue than performance, go ahead and embed the code in the DB.)
And you ran it through a lossy compression codec at what point during that test?
Short answer: When I ran "md5sum" -- a very lossy compression algorithm.
Long answer: Are you seriously suggesting that even a lossy compression algorithm will produce different outputs for identical inputs?
I wasn't aware that any codec grabbed input from/dev/random. (Even calls to rand() will return the same sequence of pseudo-random numbers in successive runs of the same program unless the seed is changed.)
pure and simple greed. It should just be out and out illegal
Greed should be illegal? But you just said "If they can make a profit by selling the card for $200, they should sell it for $200". Surely making any profit at all is just being greedy, shouldn't they be forced to sell it at break-even pricing?
Of course, that doesn't leave any money in the coffers to pay for the R & D for the next product, so that next product might take a lot longer to ever be produced. On the other hand, if they had some of the extra cash from selling $400 parts to people who are perfectly willing to pay that money for what they're getting, then they could afford to pay a few more engineers so that the next product is ready sooner.
Come to think of it, aren't you being greedy by demanding a $400 product for only $200?
Well, the drive I tested with is a DVD drive, not a CD drive. Even though it's a low cost (unbranded, but IDs as Toshiba) DVD drive, the higher tolerances it needs to read DVDs may make it more consistent for ripping CDs.
Let me try it again now that the drive has been baking in my computer for a few hours (it hadn't been on long when I tried it earlier)...
Okay, different MD5s than from the DVD, but identical to each other. (In all cases these were clean rips, of course.) Although again, the tolerances on a burner may be better than on a plain CD-ROM drive.
Looks like under identical conditions (same drive) it'll rip consistently. Ripping off a different drive might give different results, that's more hassle than I want to try right now. If anyone wants to compare, the disc/track I ripped is Pink Floyd's Dark Side of the Moon, Capitol's catalog # CDP 7 46001 2, DIDX 226. (Different recordings will almost certainly give different results.)
To expand on that, give exaggerated estimates if it's something you really don't (for good reasons) want to do. Even better if you can get fellow developers on the project to agree.
This came up years ago when a couple of us were maintaining and developing a certain application. There were several luser requests for a (mis-)feature that would do violence to the overall architecture and lead to user headaches down the road. We could usually get the requestor to understand that when we took the time to explain it -- but then they'd forget the explanation and ask again. Eventually our boss asked for an estimate to implement the feature and -- independantly of each other -- we both came up with a ridiculously high estimate (3 months vs the actual 3 days, something like that, based on the rewrites we'd have to do to other parts of the app, and then multiplying by three). Nobody (well, nobody in the chain of command) ever asked for that feature again.
(Eventually we evolved the system to where that misfeature wasn't asked for anyway.)
OTOH, at another job one of the senior architects would occasionally come up with some wild suggestion, and I'd sometimes have to explain to him for about an hour exactly why that idea was really hare-brained (although sometimes it was a good idea). I finally figured out that with some of his suggestions, he was just testing me to see if I'd really thought out my designs and if I could be trusted with more design responsibility. If I'd just gone along with some stupid idea I'd have failed his test.
This is only the state Supreme Court. If the appeal makes its way to the US Supreme court, they might disagree with: "the state Supreme Court ruled that property and trade secrets rights outranked free speech rights in this case."
Last time I looked, the US Constitution specifically protects free speech, but only indirectly protects property rights (and specifically limits so-called intellectual property), and says nothing at all about trade secrets.
OTOH, courts -- even Supreme Courts -- have been known to come up with screwy decisions.
What if they have a different automobile than the ones that they design/sell, and the oil is changed differently?
If the automotive engineer doesn't know how to check the oil on any car but his own, he's incompetent. If he doesn't know what possibilities are out there now, he'll just reinvent the wheel (or dipstick), badly.
I am a linux programmer, and I don't know squat about MS windows, yet I am forced to run this on my workstation by the network gurus.
Right. So how do you test your linux programs?
Are you saying that I should learn the nuts and bolts of windows? Even though it has nothing to do with my job?
If you're running Windows on your desktop, then it does have something to do with your job, n'est ce pas?
As a programmer I have enough of a job, just staying on top of C, Perl, Shell etc.
Yeah, terrible how they make all those changes to them every week. Perhaps you should consider another line of work?
Yeah, developers usually have their systems set up and tweaked just so, and would no more want anyone else to mess with it than a mechanic or woodworker would lend someone his tools.
Agreed that developers aren't IT support (well, unless they're developing apps for IT). But they ought to know how to keep their desktops running.
Heck, I used to develop in a shop where any developer above "junior programmer" was expected to know how to reinstall the OS (Solaris, Ultrix or AIX), configure it for Oracle, install Oracle, install our software (a GIS system), and generally manage their own workstations. Ditto for the sales support guys'n'gals and the trainers (although the latter might need some phone support).
Would you have automotive engineers or even car salesmen that don't know how to drive, check the oil and put gas in the car?
BBC != all British TV. Kind of a pity, really. That leaves out The Avengers and hard or impossible to find stuff like The Sandbaggers or Starcops.
But what I'd really like is the original Bill & Ben, The Flowerpot Men;-). (Freaked me out to see the modern version on Australian TV on a business trip there a couple years ago.)
I've thought of that from time to time, if you can find an appropriate ink on acid-free paper. Not a laser printer -- the toner does wierd things in the presence of whatever fumes vinyl gives off.
Back in the early days of microcomputers, one of the magazines (Dr. Dobbs? Kilobaud?) used to publish "machine readable" code alongside its listings of BASIC programs -- some kind of B&W bar or matrix code. I don't recall how you were supposed to read it.
Sorry paper rots over time, and there is always danger of a fire.
It also tears, and in particular wear on the sprocket holes leads to misregistration and bad reads. There's a more durable replacement: a thick mylar (or similar tough plastic) tape with a slight metallic coating. I've seen that stuff used for special tapes that get a lot of use (eg a boot tape for ancient machines that booted off of paper -- or mylar -- tape).
The ultimate backup is cuneiform on clay tablets. They remain readable after thousands of years.
IBM, for one. Even if SCO drops their lawsuit against IBM (and if they don't, it'll go to trial eventually), IBM has countersued SCO for patent infringement and GPL license violations.
I think about the only thing IBM would take in order to drop the countersuit would be (a) all of SCO's cash and IP assets, and possibly (b) Darl McBride's head on a platter.
There has been some talk that "so and so didn't put a notice on the code and lost their copyright." Get better legal advice.
You might want to take your own advice. While it is certainly true now that copyright automatically applies, that wasn't the case in the US until the copyright law was changed, within the last 10 or 15 years. Prior to that -- when most of the UNIX code up to circa System III was written -- publishing something without a copyright notice effectively put it in the public domain. (Which explains the comment about "unpublished source code, copyright notice affixed in case of accidental publication" you sometimes see.)
However, before you go using somebody else's material with you think was published ages ago without a copyright notice, it would indeed be a good idea to seek legal advice.
common practice there and at other companies to remove the BSD copyright notices from the internally used source code
That's a large part of what cost AT&T in the ATT/USL vs BSD case -- AT&T had incorporated BSD code without the BSD copyright notices, violating the BSD license and thus BSD's copyrights. IIRC, AT&T ended up paying BSD's legal costs in that trial.
Hey SCO, how do you feel about paying IBM's (and anyone else you were thinking of suing) legal costs?
Heck, people have a hard time picking out a face in a crowd when all they've seen is a picture of it, and face recognition is one of the things the human brain and visual system is particularly good at. (So much so that we tend to see faces even in random structures like clouds, rock formations and water stains.)
I've no doubt computer systems could get pretty good at matching pictures of faces taken under reasonably controlled conditions (and "light compensating camera systems" are just an attempt to control the conditions), but we're a hell of a long way from systems that can pick individuals (from an arbitrarily large group) out of a random crowd without a lot of false positives and false negatives.
A more effective use of such systems from a security standpoint might be monitoring restricted or sensitive areas, where the comparison is against a database of authorized people -- any mis-match raises the alarm. It'd still take some tuning to reduce false alarms, but those authorized would be making efforts to look like themselves, rather than vice versa.
What Windows was 8+ years ago is irrelevant; the NT series was always GUI-based and even the Win9x series pretty much so (quick, how do you edit the registry without a GUI?).
Applescript may be verbose, but the point is that it gives you access to everything, as any decent systems scripting language should. The closest thing Windows has to an equivalent scripting language would be Dismal, er, Visual Basic.
Furthermore, that ancient historic code first appeared sometime between 3rd and 4th edition Unix, neither of which were copyrighted. (AT&T only acquired copyright certificates for 5th edition onward.) Under copyright law in effect at the time, that means that in essence when the code was first released outside of AT&T it became public domain.
The trial judge in the ATT/USL vs BSD suit said just about as much, that ATT wouldn't be able to prove copyright on older versions of Unix.
Of course, Ken might have lifted this from even earlier sources.
Yeah. It appears under directory "dmr" (Dennis M. Ritchie, perhaps?) in an earlier version (somewhere between 3rd and 4th edition) of the kernel.
See Nsys/sys/nsys/dmr/malloc.c.html for the listing, and back up from there for the explanation of the "nsys" files. It may well be that this code has been in since the very first C-language version of Unix.
All the admin languages they've tried really quite blow.
That's what happens when you design the system around a GUI rather than a command line. It's a lot easier to put a GUI on top of a command line base than the other way around.
On the other hand, Apple's scripting language for MacOS wasn't bad. Guess it's just a Microsoft thing.
Slashdot Mirror
You should always try and build as much of your rules into the db app server - thats what it is - an application server, don't put all your logic in your client app.
Yeah, the DB vendors love for you to do this because it locks you in to their DBMS -- portability of stored procedure (etc) code not being one of the database world's high points.
That said, you ought to be able to rely on the DBMS to enforce at least some constraints, and you should be taking advantage of at least the minimal subset of same that all real DB servers support. (And if you're building an enterprise-specific application where portability is much less of an issue than performance, go ahead and embed the code in the DB.)
And you ran it through a lossy compression codec at what point during that test?
/dev/random. (Even calls to rand() will return the same sequence of pseudo-random numbers in successive runs of the same program unless the seed is changed.)
Short answer: When I ran "md5sum" -- a very lossy compression algorithm.
Long answer: Are you seriously suggesting that even a lossy compression algorithm will produce different outputs for identical inputs?
I wasn't aware that any codec grabbed input from
pure and simple greed. It should just be out and out illegal
Greed should be illegal? But you just said "If they can make a profit by selling the card for $200, they should sell it for $200". Surely making any profit at all is just being greedy, shouldn't they be forced to sell it at break-even pricing?
Of course, that doesn't leave any money in the coffers to pay for the R & D for the next product, so that next product might take a lot longer to ever be produced. On the other hand, if they had some of the extra cash from selling $400 parts to people who are perfectly willing to pay that money for what they're getting, then they could afford to pay a few more engineers so that the next product is ready sooner.
Come to think of it, aren't you being greedy by demanding a $400 product for only $200?
Let me try it again now that the drive has been baking in my computer for a few hours (it hadn't been on long when I tried it earlier)......yep, same MD5. Somebody else want to try the experiment with a DVD-ROM drive?
I'll try it with my CD drive (a LiteOn R/RW burner -- it was busy before)...Okay, different MD5s than from the DVD, but identical to each other. (In all cases these were clean rips, of course.) Although again, the tolerances on a burner may be better than on a plain CD-ROM drive.
So did I, so I just ran the experiment:
Looks like under identical conditions (same drive) it'll rip consistently. Ripping off a different drive might give different results, that's more hassle than I want to try right now. If anyone wants to compare, the disc/track I ripped is Pink Floyd's Dark Side of the Moon, Capitol's catalog # CDP 7 46001 2, DIDX 226. (Different recordings will almost certainly give different results.)Oh, and to make RIAA happy:
;-)To expand on that, give exaggerated estimates if it's something you really don't (for good reasons) want to do. Even better if you can get fellow developers on the project to agree.
This came up years ago when a couple of us were maintaining and developing a certain application. There were several luser requests for a (mis-)feature that would do violence to the overall architecture and lead to user headaches down the road. We could usually get the requestor to understand that when we took the time to explain it -- but then they'd forget the explanation and ask again. Eventually our boss asked for an estimate to implement the feature and -- independantly of each other -- we both came up with a ridiculously high estimate (3 months vs the actual 3 days, something like that, based on the rewrites we'd have to do to other parts of the app, and then multiplying by three). Nobody (well, nobody in the chain of command) ever asked for that feature again.
(Eventually we evolved the system to where that misfeature wasn't asked for anyway.)
OTOH, at another job one of the senior architects would occasionally come up with some wild suggestion, and I'd sometimes have to explain to him for about an hour exactly why that idea was really hare-brained (although sometimes it was a good idea). I finally figured out that with some of his suggestions, he was just testing me to see if I'd really thought out my designs and if I could be trusted with more design responsibility. If I'd just gone along with some stupid idea I'd have failed his test.
Therefore!
This is only the state Supreme Court. If the appeal makes its way to the US Supreme court, they might disagree with: "the state Supreme Court ruled that property and trade secrets rights outranked free speech rights in this case."
Last time I looked, the US Constitution specifically protects free speech, but only indirectly protects property rights (and specifically limits so-called intellectual property), and says nothing at all about trade secrets.
OTOH, courts -- even Supreme Courts -- have been known to come up with screwy decisions.
What if they have a different automobile than the ones that they design/sell, and the oil is changed differently?
If the automotive engineer doesn't know how to check the oil on any car but his own, he's incompetent. If he doesn't know what possibilities are out there now, he'll just reinvent the wheel (or dipstick), badly.
I am a linux programmer, and I don't know squat about MS windows, yet I am forced to run this on my workstation by the network gurus.
Right. So how do you test your linux programs?
Are you saying that I should learn the nuts and bolts of windows? Even though it has nothing to do with my job?
If you're running Windows on your desktop, then it does have something to do with your job, n'est ce pas?
As a programmer I have enough of a job, just staying on top of C, Perl, Shell etc.
Yeah, terrible how they make all those changes to them every week. Perhaps you should consider another line of work?
Yeah, developers usually have their systems set up and tweaked just so, and would no more want anyone else to mess with it than a mechanic or woodworker would lend someone his tools.
Does the phrase 'minimal crust' mean anything?
Um, not that I recall at the moment, but it's been 10 years. Does 'VISION*' mean anything?
Agreed that developers aren't IT support (well, unless they're developing apps for IT). But they ought to know how to keep their desktops running.
Heck, I used to develop in a shop where any developer above "junior programmer" was expected to know how to reinstall the OS (Solaris, Ultrix or AIX), configure it for Oracle, install Oracle, install our software (a GIS system), and generally manage their own workstations. Ditto for the sales support guys'n'gals and the trainers (although the latter might need some phone support).
Would you have automotive engineers or even car salesmen that don't know how to drive, check the oil and put gas in the car?
The Prisoner
;-). (Freaked me out to see the modern version on Australian TV on a business trip there a couple years ago.)
Wasn't that ITV?
BBC != all British TV. Kind of a pity, really. That leaves out The Avengers and hard or impossible to find stuff like The Sandbaggers or Starcops.
But what I'd really like is the original Bill & Ben, The Flowerpot Men
I've thought of that from time to time, if you can find an appropriate ink on acid-free paper. Not a laser printer -- the toner does wierd things in the presence of whatever fumes vinyl gives off.
Back in the early days of microcomputers, one of the magazines (Dr. Dobbs? Kilobaud?) used to publish "machine readable" code alongside its listings of BASIC programs -- some kind of B&W bar or matrix code. I don't recall how you were supposed to read it.
Sorry paper rots over time, and there is always danger of a fire.
It also tears, and in particular wear on the sprocket holes leads to misregistration and bad reads. There's a more durable replacement: a thick mylar (or similar tough plastic) tape with a slight metallic coating. I've seen that stuff used for special tapes that get a lot of use (eg a boot tape for ancient machines that booted off of paper -- or mylar -- tape).
The ultimate backup is cuneiform on clay tablets. They remain readable after thousands of years.
As long as you don't drop them...
Who spoke about trial?
IBM, for one. Even if SCO drops their lawsuit against IBM (and if they don't, it'll go to trial eventually), IBM has countersued SCO for patent infringement and GPL license violations.
I think about the only thing IBM would take in order to drop the countersuit would be (a) all of SCO's cash and IP assets, and possibly (b) Darl McBride's head on a platter.
There has been some talk that "so and so didn't put a notice on the code and lost their copyright." Get better legal advice.
You might want to take your own advice. While it is certainly true now that copyright automatically applies, that wasn't the case in the US until the copyright law was changed, within the last 10 or 15 years. Prior to that -- when most of the UNIX code up to circa System III was written -- publishing something without a copyright notice effectively put it in the public domain. (Which explains the comment about "unpublished source code, copyright notice affixed in case of accidental publication" you sometimes see.)
However, before you go using somebody else's material with you think was published ages ago without a copyright notice, it would indeed be a good idea to seek legal advice.
Here's the
babelfish translation of the German article.
Now, can somebody please post a link that translates from babelfish English to real English?
common practice there and at other companies to remove the BSD copyright notices from the internally used source code
That's a large part of what cost AT&T in the ATT/USL vs BSD case -- AT&T had incorporated BSD code without the BSD copyright notices, violating the BSD license and thus BSD's copyrights. IIRC, AT&T ended up paying BSD's legal costs in that trial.
Hey SCO, how do you feel about paying IBM's (and anyone else you were thinking of suing) legal costs?
Heck, people have a hard time picking out a face in a crowd when all they've seen is a picture of it, and face recognition is one of the things the human brain and visual system is particularly good at. (So much so that we tend to see faces even in random structures like clouds, rock formations and water stains.)
I've no doubt computer systems could get pretty good at matching pictures of faces taken under reasonably controlled conditions (and "light compensating camera systems" are just an attempt to control the conditions), but we're a hell of a long way from systems that can pick individuals (from an arbitrarily large group) out of a random crowd without a lot of false positives and false negatives.
A more effective use of such systems from a security standpoint might be monitoring restricted or sensitive areas, where the comparison is against a database of authorized people -- any mis-match raises the alarm. It'd still take some tuning to reduce false alarms, but those authorized would be making efforts to look like themselves, rather than vice versa.
What Windows was 8+ years ago is irrelevant; the NT series was always GUI-based and even the Win9x series pretty much so (quick, how do you edit the registry without a GUI?).
Applescript may be verbose, but the point is that it gives you access to everything, as any decent systems scripting language should. The closest thing Windows has to an equivalent scripting language would be Dismal, er, Visual Basic.
Furthermore, that ancient historic code first appeared sometime between 3rd and 4th edition Unix, neither of which were copyrighted. (AT&T only acquired copyright certificates for 5th edition onward.) Under copyright law in effect at the time, that means that in essence when the code was first released outside of AT&T it became public domain.
The trial judge in the ATT/USL vs BSD suit said just about as much, that ATT wouldn't be able to prove copyright on older versions of Unix.
Of course, Ken might have lifted this from even earlier sources.
Yeah. It appears under directory "dmr" (Dennis M. Ritchie, perhaps?) in an earlier version (somewhere between 3rd and 4th edition) of the kernel.
See Nsys/sys/nsys/dmr/malloc.c.html for the listing, and back up from there for the explanation of the "nsys" files. It may well be that this code has been in since the very first C-language version of Unix.
All the admin languages they've tried really quite blow.
That's what happens when you design the system around a GUI rather than a command line. It's a lot easier to put a GUI on top of a command line base than the other way around.
On the other hand, Apple's scripting language for MacOS wasn't bad. Guess it's just a Microsoft thing.