>Without copyright, nobody would have a legal right to prevent others from copying music, and thus would have no justification for asking for a tariff on equipment for recording music
How does the legal right to prevent others to do something allow them to set up and benefit from a tax?
I honestly fail to see how copyright becomes this thing where we assume that all hard-drives are used to infringe on it.
>the US Government continues to rely on contractors and subcontractors who have no interest or profit motive to secure USG networks
What makes you think that its the fault of contractors? Nothing in the articles say this. In fact one of them blames internal, highlevel staff.
From the ZDNet article; "We must get those at the very top, the decision makers, the ones accountable to the shareholders, the customers or the electorate, to recognize that lack of network security in an organization is a material weakness and one that deserves necessary resources and immediate action." "
>of course you cant to most of that with cd's... but the labels at least have to try.
They should. It would be well worth it for them to come out with a huge book sized packaging with one CD and lots of pages (pictures/text/lyrics), posters and what ever merchandising you can get in there.
You effectively can charge more, get free advertisement and make it worthwhile for people to go out and buy the product.
>we dealt with small closed source development companies, we always had code escrow agreements. If the vendor went out of business or dropped support of the product, we had the ability to get the source and support it ourselves.
Have you've ever had to do this?
Small company + out of business = "Here is the code we scraped together, no one left knows how it works or even if its all there. Good Luck and Good Bye!"
>This is probably what will take over if AES fails.
AES = Advanced Encryption Standard.
How arrogant were the designers to label it "Advanced"?
When I'm going to create a new encryption scheme I'm calling it "The Extra Special, Super-Duper, I-dare-you-no-I-triple-dare-you-to-break-it" Encryption Standard. (TESSDIDYNITDYTBIES)
How Insightful is this? Programmers as mis-understood starving artists which the general public is too dim witted to grasp the importance of?
>Professionals outside the world of engineering usually get a degree in communications or the like because it is the path of least resistance to getting a college degree, not because they are particularly interested. They probably will be "trained" when they reach the workforce, because their degrees didn't endow them with any particular abilities.
This statement is particularly dumb. Professionals like doctors?
You first cry about people making generalizations about Computer Science then you make ignorant generalization about every other field.
>I strongly feel that programming is a creative process,
I used to feel like that when I was younger. Some times its not really creative programming, its just that its new and orginal to you.
>It's like out-sourcing art-painters to an other country
They have out-sourced artists. An example is The Simpsons is animated mainly in Korea
One interesting part: "They don't allow guns in Korea; it's against the law," Kirkland said. "It was an automatic gun so they weren't quite sure how to make the bullet eject out, or the shell eject. So they were calling me: 'How does a gun work?"'
This art house also does Superman, Dilbert, Batman and a whole bunch of other shows.
>You can *not* have two different design specs implemented that *modify* the same data.
I totally agree with you, but I've just went through this situation and when the client is motivated you can't just throw out technical/"because its not clean" reasons. There are lots of things which should not happen but they do.
>how do you set up a FK relationship between a table that has a field that, depending on another integer field, can be a link to any of N other tables? Is there a standard for this?
I think something similar to this is sub/super-types. (A CHAIR and a DESK are sub types of a EXPENSIVE_OBJECT) You can lookup how its done for the db you are working with, but there is no standard SQL fixed way of handling this. But it usually always involves one FK.
Just because a technology does not fully captures a requirement doesn't mean that you should avoid it entirely. You really are doing a dis-service to your client since you are not using full use of the tools they bought/implemented.
Then you have these statements that assume that programmers do not make mistakes;
>good programmers find their mistakes and fix them
and
>if my query is doing joins between indexed keys, and I've ordered my
and
>why can't all the middleware be implemented using constraints?
People make mistakes. They happen. Thats why software development is evolving. Thats is why its good to have checks and double checks. Especially at very little cost.
> IMO it is still just one app if it modifies the same data.
Not strictly. Say you have a sales/accounting which feeds data, then you have budgeting people which needs to forcast. Say that they have two different IT departments. One uses an internal one, the other thinks that the internal is crappy and outsources. They can develop two different applications/design doc/programmer teams/end-user requirements, using the same database.
And yes this does happen.
>Well, you state it yourself: it is *not good*.
Yes its not good. But it happens and sometimes its out of your control. Its like saying "I dig holes this size and only holes this size. Don't ask me to dig a hole larger because I can't do it." Instead of "digging holes" you are saying "work with bad programmers".
Another way of looking at is that your methodology is only good if its in a very specific environment. Thats easy to say; give me enough time and I can make any product perfect.
In the real world, you have crappy code, crappy data, horrible users, horrible managers and even worse timelines.
>FKs: they're a band-aid for a bullet wound.
Its a tool which can save you one day. Your main reason for not using them seems to be "programmers should be good enough" so they are not needed. But in that light, programmers should be good enough that they don't need alot of things. Why not just program in assembly, they get a huge amount of speed and should produce bug-free code. C/C++/J2EE is just a crutch for bad programmers.
If you admit that programmers make mistakes, then you really have to try and minimize them. FK are just one tool which helps.
>I won't even begin to get in to the evil I've seen applications do to work around stupid NOT NULL declarations...
>but I will say I administer multiple complex databases for multiple clients under postgres, mysql, and oracle.
Um... You might want to pick up an db optimizer book to see why nulls in general are evil.
Nulls are funky beasts. They don't represent anything, including other Nulls themselves. This is as far as SQL standards define them and leave the ugly details to the vendors. What this means is that operators (=, , etc) on them don't work the way it normally does with actual values.
In the case of Oracle, finding a Null value in a middle name field will result in a table scan. (Unless you do some funky things on the back end for this exact situation) Table scans is not the best way to go about things especially with large tables.
> I graphical tools (Visio, etc.) useful when I'm coming in to a preexisting project, but when designing, or modifying, I do prefer vi as a modelling tool.
In a way I agree with you, but I still use the "pretty pictures" tool because its important to communicate to others your exact change.
>More specifically, do you not design your software such that all your business logic for a particular table is located in the same place?
Reasons why you still need FKs.
1. Programmers make mistakes. If they were perfect you wouldn't need a whole lot of things besides FKs. But people are human. Having a data architect and a programmer work on relations is better. (two heads are better than one?) Getting messed up data is one of the worst things you can do to the reliablity of an application. You can fix a display problem or a "missing button" functionality but once that crappy data is in, its a pain to fix it, if you can. 2. FKs don't cost alot. Only in the cases of extreme number of fks. 3. Helps others understand the database schema. Relational databases are not object orieniented. There is a "translation" that needs to be done from the database tables to the application objects. Just because I understand the business rules and object model doesn't mean that I understand the database model. 4. The reality is that if you are talking about a serious enterprise application, the logic for the tables might not be in one place. Either because of point 3. or because there are multiple applications accessing a singlular enterprise database. 5. Programmers are hacks. Ok not all of them but some of them are. And if they see that a quick fix is to use this table in this brand new way or this field as having its own special rule, they will. This is not good because it can and will break other parts of the program or reporting. (This is an extension of point 1.)
Slashdot Mirror
>Without copyright, nobody would have a legal right to prevent others from copying music, and thus would have no justification for asking for a tariff on equipment for recording music
How does the legal right to prevent others to do something allow them to set up and benefit from a tax?
I honestly fail to see how copyright becomes this thing where we assume that all hard-drives are used to infringe on it.
>why the piracy assumption?!?
From the question:
"I download gigabytes of stuff from Usenet and burn it onto CD's "
What exactly do you think he is downloading gigs of and burning?
I don't think its the informative and always new flame wars on os.advocacy.
I find the pornography subtext both welcomed and intriguing.
>the US Government continues to rely on contractors and subcontractors who have no interest or profit motive to secure USG networks
What makes you think that its the fault of contractors? Nothing in the articles say this. In fact one of them blames internal, highlevel staff.
From the ZDNet article;
"We must get those at the very top, the decision makers, the ones accountable to the shareholders, the customers or the electorate, to recognize that lack of network security in an organization is a material weakness and one that deserves necessary resources and immediate action." "
>Show you "buy american" spirit and protest or cancel your accounts or get your family switched off aol.
If you do this with alot of things you buy you almost will buy nothing.
Take a cellphone. Where was assembled? Where were the parts made? Where is the head/design/engineering office?
Its getting hard to not buy a true domestic technological product these days.
Boot time.
Compaired to Win98, RedHat9 takes forever to boot. Same machine.
And yes, shutting down is important. I just don't lower the volume on my radio when I am not using it.
> If it were expensive to upgrade
It IS expensive to upgrade. How long does it take to do it? How much time spent is acceptable to the non-Linux fanatic user?
In 1998 the current version of Red Hat was 5.1.
How many companies are stepping forward to fully support that product?
No no no.
h ess kill people.
Tactical nukes don't kill people, insane-military-super-computers-who-rather-play-c
Or do they want to harvest our bio-energies? I could never get those two straight.
.. a location or method of downloading patches to Win98?
There must be still alot of computers running out there.
>of course you cant to most of that with cd's... but the labels at least have to try.
They should. It would be well worth it for them to come out with a huge book sized packaging with one CD and lots of pages (pictures/text/lyrics), posters and what ever merchandising you can get in there.
You effectively can charge more, get free advertisement and make it worthwhile for people to go out and buy the product.
And they are always walking around with these X-ray glasses.
I've played Pac-Man all my life.
Now here I am big and fat from eating way too much. And I'm still stuck in this dammed maze.
>we dealt with small closed source development companies, we always had code escrow agreements. If the vendor went out of business or dropped support of the product, we had the ability to get the source and support it ourselves.
Have you've ever had to do this?
Small company + out of business = "Here is the code we scraped together, no one left knows how it works or even if its all there. Good Luck and Good Bye!"
>This is probably what will take over if AES fails.
AES = Advanced Encryption Standard.
How arrogant were the designers to label it "Advanced"?
When I'm going to create a new encryption scheme I'm calling it "The Extra Special, Super-Duper, I-dare-you-no-I-triple-dare-you-to-break-it" Encryption Standard. (TESSDIDYNITDYTBIES)
>having their software running on linux doesn't directly contribute to opensource software.
Its a huge thing. One of the biggest complaints of Linux is that it can't run stuff Windows does.
>how about open sourcing the admin tools?
At the heart of OpenSource is that you are not forced to do anything that you don't want to. Its "as is".
And who are you to say what Oracle should and shouldn't do? Who named you "King of OpenSource"?
How Insightful is this? Programmers as mis-understood starving artists which the general public is too dim witted to grasp the importance of?
>Professionals outside the world of engineering usually get a degree in communications or the like because it is the path of least resistance to getting a college degree, not because they are particularly interested. They probably will be "trained" when they reach the workforce, because their degrees didn't endow them with any particular abilities.
This statement is particularly dumb. Professionals like doctors?
You first cry about people making generalizations about Computer Science then you make ignorant generalization about every other field.
Insightful, my ass.
>Our project manager has so little to do, she actually has a second title and a second set of duties that take up most of her day.
That is a sign of a GOOD project manager.
Its like saying that a developer needs more things to do because his code doesn't need debugging since there were no problems found.
>I strongly feel that programming is a creative process,
I used to feel like that when I was younger. Some times its not really creative programming, its just that its new and orginal to you.
>It's like out-sourcing art-painters to an other country
They have out-sourced artists. An example is The Simpsons is animated mainly in Korea
One interesting part:
"They don't allow guns in Korea; it's against the law," Kirkland said. "It was an automatic gun so they weren't quite sure how to make the bullet eject out, or the shell eject. So they were calling me: 'How does a gun work?"'
This art house also does Superman, Dilbert, Batman and a whole bunch of other shows.
>You can *not* have two different design specs implemented that *modify* the same data.
I totally agree with you, but I've just went through this situation and when the client is motivated you can't just throw out technical/"because its not clean" reasons. There are lots of things which should not happen but they do.
>how do you set up a FK relationship between a table that has a field that, depending on another integer field, can be a link to any of N other tables? Is there a standard for this?
I think something similar to this is sub/super-types. (A CHAIR and a DESK are sub types of a EXPENSIVE_OBJECT) You can lookup how its done for the db you are working with, but there is no standard SQL fixed way of handling this. But it usually always involves one FK.
Just because a technology does not fully captures a requirement doesn't mean that you should avoid it entirely. You really are doing a dis-service to your client since you are not using full use of the tools they bought/implemented.
First;
>we all make mistakes
Then you have these statements that assume that programmers do not make mistakes;
>good programmers find their mistakes and fix them
and
>if my query is doing joins between indexed keys, and I've ordered my
and
>why can't all the middleware be implemented using constraints?
People make mistakes. They happen. Thats why software development is evolving. Thats is why its good to have checks and double checks. Especially at very little cost.
> IMO it is still just one app if it modifies the same data.
Not strictly. Say you have a sales/accounting which feeds data, then you have budgeting people which needs to forcast. Say that they have two different IT departments. One uses an internal one, the other thinks that the internal is crappy and outsources. They can develop two different applications/design doc/programmer teams/end-user requirements, using the same database.
And yes this does happen.
>Well, you state it yourself: it is *not good*.
Yes its not good. But it happens and sometimes its out of your control. Its like saying "I dig holes this size and only holes this size. Don't ask me to dig a hole larger because I can't do it." Instead of "digging holes" you are saying "work with bad programmers".
Another way of looking at is that your methodology is only good if its in a very specific environment. Thats easy to say; give me enough time and I can make any product perfect.
In the real world, you have crappy code, crappy data, horrible users, horrible managers and even worse timelines.
>FKs: they're a band-aid for a bullet wound.
Its a tool which can save you one day. Your main reason for not using them seems to be "programmers should be good enough" so they are not needed. But in that light, programmers should be good enough that they don't need alot of things. Why not just program in assembly, they get a huge amount of speed and should produce bug-free code. C/C++/J2EE is just a crutch for bad programmers.
If you admit that programmers make mistakes, then you really have to try and minimize them. FK are just one tool which helps.
... I would mod that post as "Sad but true".
>I won't even begin to get in to the evil I've seen applications do to work around stupid NOT NULL declarations...
>but I will say I administer multiple complex databases for multiple clients under postgres, mysql, and oracle.
Um... You might want to pick up an db optimizer book to see why nulls in general are evil.
Nulls are funky beasts. They don't represent anything, including other Nulls themselves. This is as far as SQL standards define them and leave the ugly details to the vendors. What this means is that operators (=, , etc) on them don't work the way it normally does with actual values.
In the case of Oracle, finding a Null value in a middle name field will result in a table scan. (Unless you do some funky things on the back end for this exact situation) Table scans is not the best way to go about things especially with large tables.
> I graphical tools (Visio, etc.) useful when I'm coming in to a preexisting project, but when designing, or modifying, I do prefer vi as a modelling tool.
In a way I agree with you, but I still use the "pretty pictures" tool because its important to communicate to others your exact change.
>More specifically, do you not design your software such that all your business logic for a particular table is located in the same place?
Reasons why you still need FKs.
1. Programmers make mistakes. If they were perfect you wouldn't need a whole lot of things besides FKs. But people are human. Having a data architect and a programmer work on relations is better. (two heads are better than one?) Getting messed up data is one of the worst things you can do to the reliablity of an application. You can fix a display problem or a "missing button" functionality but once that crappy data is in, its a pain to fix it, if you can.
2. FKs don't cost alot. Only in the cases of extreme number of fks.
3. Helps others understand the database schema. Relational databases are not object orieniented. There is a "translation" that needs to be done from the database tables to the application objects. Just because I understand the business rules and object model doesn't mean that I understand the database model.
4. The reality is that if you are talking about a serious enterprise application, the logic for the tables might not be in one place. Either because of point 3. or because there are multiple applications accessing a singlular enterprise database.
5. Programmers are hacks. Ok not all of them but some of them are. And if they see that a quick fix is to use this table in this brand new way or this field as having its own special rule, they will. This is not good because it can and will break other parts of the program or reporting. (This is an extension of point 1.)
You can do that just by giving permission to only SELECT and INSERT an object to a user. They will be denied any DELETE or UPDATE commands.
And then timestamp everything on a secondardy table not viewable by the end-user for every DML command performed.