Well, then don't buy a DRM version of the Shrek movie.
Nobody is required to release non DRM products and nobody is required to buy a DRM product. As long as you can find out if it's DRM before you buy it, I don't see any problem at all. We can just vote with our dollars.
Consider if they just released it in movie theaters and never made a dvd. You would still never really get access to the original format of the movie. That seems to me very much like DRM, except that since movie theaters are old we don't call a movie theater DRM.
I could be wrong, but I think the author of the articcle was trying to show you tools written in perl that can help you template your website and gain advantages that you can't with server-side includes (whether the includes are in perl, php, SSI, or whatever). I don't think he was implying that developers should all develop in perl, just use the template tools that happen to be written in perl.
Although they haven't stated any harms aside from it's an unproven platform, they haven't found any benefits, either. So they said why bother.
Apache 2 was originally released with visions of a "perchild" MPM. What ever happened to that? That would be a real improvement for security on a name-based virtualhosting system. Is anyone working on it? Can I donate a little money to encourage its development somewhere?
There is still no good way of doing several sites on the same server in a good way. The options, as I see it are: (1) Several instances of apache, each on a seperate IP. Administration difficult because of all the extra daemons. (2) Name-based virtual hosting with safe_mode php: works fine, but requires safe mode which breaks many apps and is cumbersome to work with. You can't do mod_perl without trying to find some way of restricting its access. (3) Suexec on ip based virtualhosts. Requires a lot of IPs, and CGIs are performance hogs (and also not what people are used to, and breaks many apps).
This is a serious question. If you have any pointers please respond. Or even tell me a better place to ask, because I'm usually ignored.
Tablespaces are NOT the same as table partitioning, however tablespaces are a great addition to PostgreSQL 8.0.
Table spaces allow you to store any table or index in any physical location. For example, you can put a small, frequently accessed table on your expensive RAID, and leave the big tables on slower, cheaper disks.
Table partitioning is when you have one table and break it up accross seperate physical locations. Useful for very large tables, but much more difficult technically.
As far as "clustering natively", the developers do not even think that clustering/replication belong in the server itself for many reasons: (1) Having it a seperate system means that it can work with a variety of PostgreSQL versions all at once. You can replicate 7.4 to 8.0 with no problem. (2) Moving seperate tasks out of the main server source allows for a faster release cycle on all products. If everything that makes PostgreSQL great was in the same tree, the release would take a long time, and many important developers wouldn't be able to spend their time writing new features. It also allows faster bug fix releases for the same reason. (3) There are many different uses for replication and clustering. Many people use those terms to mean different things that require different solutions based on your need. For example, are the machines connected 99% of the time, or are you just using replication to sync the data nightly? If one machine is seperated from the rest (by network failure), what should the replication server do when you try to commit a transaction on that lone server? There are many cases to consider that depend on your business need, and the commercial companies gloss over all the details by just saying that they "support clustering", which may or may not meet your actual needs.
Blaming parents is a cop-out. You can't make parents care. And you certainly can't expect all parents to be educated enough to teach their kids effectively.
If a child wants to learn, he should be able to accomplish that at school. That is nearly impossible in many places.
Teachers need to be accountable, and they need to FAIL kids who don't know. That's what failing is, right? Well, if you don't pass a final exam covering all the material for the year/semester, you should FAIL. Then you retake the class and LEARN it. Then teachers don't waste everyone's time reviewing material.
Of course, people are too concerned about children's self-esteem. Nobody wants to be the person to tell a child: "You just don't know the material well enough to move to the next level". But how else will they learn?
That keeps the kids who want to learn moving, and seperates them from the kids who are holding them back (by demanding review of topics the other kids knew years ago). Everyone can learn at their own pace.
Maybe that would bring back the antiquated concept of shame? Poorly performing kids would realize "Hey, all the other people my age are moving right past me. Perhaps I should get my act together.". It might also make a high school diploma worth something again.
I don't think you understood my post at all. I wasn't advocating oracle, I was just pointing out that an 80GB database is quite common, and in order to impress someone with a database, you need to show what you can do with 80GB, not that you have 80GB.
Access's backend DB sucks. Access does not suck. It's a valuable tool to manage databases and also to create client access software to distribute to the people who need to access the data. Web interfaces have made it less necessary, but I bet it's a lot quicker in Access still.
I like postgresql, but thanks for trashing that guy's post.
PostgreSQL has great recovery from a power failure. But if the bytes aren't there, the bytes aren't there. In fact, if the inodes aren't there, as far as postgresql is concerned, the bytes aren't there.
I assume that MySQL has some basic ability to recover from power failure. I'd be a little concerned that the database would be inconsistant, but it would probably not be corrupt. I'd like to know if anyone has any experience with power failure corrupting a DB of either type (pg or mysql).
FAT32 can hold 80GB of mp3s with no problem, and FAT32 is not exactly Oracle.
It's not how much a DB can hold, it's how easy/fast it is to get exactly the information about your information you want; nothing more, nothing less. The ease and performance of getting such information must scale also, not just the amount the DB can hold.
Heck, you know what's a great database?/dev/null. It can take the INSERTs as fast as I can send them, and never bogs down my system with pesky I/O bandwidth, and never tells me it's full.
So, 80GB can be a lot if you have demanding requirements about the details of your data and the relationships with other data. If not, it's just some bytes (that you optionally want back). Then it doesn't matter, just use FAT32.
Also, if you consider an application where data is only ever input through the web or some other front-end GUI, foreign key contrains aren't necessarily needed (I'll admit they're still good to have and use), because you can control the input through restricted UI elements like drop-downs, radio buttons, etc.
I know a lot of people do that (myself guilty on occasion), but you're the first person to publicly admit it:)
Constraints are very important.
First, in the app, you check the input for basic security reasons (remove quotes and backslashes and whatnot). Even if it's a radio button, that wouldn't slow me down from sending your website invalid data. Check it every time.
The constraints are important because if you have several parts to an application, or perhaps several applications all accessing the same data, you don't want one part to adversely affect another. If one part of the app tries to insert invalid data that would confuse another part of the application, the constraint will prevent the insertion and raise an error right there. Then you very quickly know where the bug is. If you had no constraint, the bug could appear 3 days later in some report of sales data, and you'd have no idea where to find the bug.
Constraints have saved me a LOT of time bug-hunting.
There are some applications where it doesn't matter much what DB you use. For those it's great to be "DB agnostic".
However, let me warn you that what often happens is that you end up going with the lowest common denominator and use no specific optimizations. That might not be so bad in the really simple cases. However, in all other cases it means that the application has to pick up the slack, and do the stuff that you would normally ask the DB to do.
That means that your data abstraction layer becomes huge and unweildly, and distracts from the purpose of the application. If one of your supported DBs doesn't support proper constraints, that means that every piece of your app has to maintain and check the consistency of the data in the database in excrutiating detail. If it doesn't, than it could create bugs very difficult to find, and create inconsistencies in the DB that you have to fix manually.
I've heard of a large application that tried to be DB agnostic (to attract more customers) and just the consistency maintaining/checking code was as many lines as the rest of the application, and caused major performance problems.
So, it's a tradeoff (like everything else, I suppose): are those extra users who use the DB that brings the lowest-common denominator down 5 notches worth the client-side work? Maybe. Just make sure you know what you're getting into. It seems easy at first, but as the application grows, your ultimate responsibility (if making a high-quality application) will be the client-side reimplmentation of all the features in the DB that you need but can't use because some other DB on your "supported platforms" list doesn't offer the feature. That's a big price for a "We support Foo RDBMS" checkmark on the product page.
And really... is that what you want to spend your time debugging? The same stuff that DB projects have spent many years debugging already? And then asking the clients to buy more hardware to support the performance-hog client-side database layer is not going to go over very well.
First, I'd like to point you to my favorite book about database theory, even though it's not exactly what you asked for:
"An Introduction to Database Systems" by C.J. Date. It's a great book and I liked it so much I bought another by the same author: "Foundation for Future Database Systems - The Third Manifesto". Both are very theoretical and also very precise.
On a more practical level: * Stored Procedures: In postgres, these are the same as functions. They have several distinct purposes:
(1) Produce data in the form of a relation that you might not otherwise be able to produce with a query alone. An example might be some kind of query that is hard to express otherwise (if there are lots of bizarre if..then's or loops that are based on the contents of the records), or if you want to make a socket connection in the function and return a table of the current headlines from slashdot.
(2) functions are vital to making a proper user-defined data type: you need the input and output functions, the comparison functions (if you want it to be indexable), etc.
(3) Making a user-defined aggregate function is very useful if you need something other than the basics, and an aggregate function requires several other functions (accumulator, for instance).
(4) Basic batching of statements so you don't have to send so many queries.
(5) if you need to execute several statements and try to recover from various errors in a graceful way, without having to have client-side logic. A simple example might be to make a function that tries to INSERT, and if it gets a duplicate key violation, than it does UPDATE.
(6) triggers require functions also
(7) Stored procedures/functions allow you to express your logic in languages other than SQL, like perl, for instance.
(8) functional indexes are very useful for query optimization.
* Views: In postgresql, views are a rewriting rule that is very useful for being a DBA, because you can optimize a query or change the physical storage without modifying the app at all (or even interrupting it). However, some databases go beyond that and have materialized views, which can improve performance by holding the data seperately, ready to access.
* Triggers: two main types (1) Constraint triggers: very powerful constraint tool that allows you to check the database for any inconsistencies before committing the transaction. This is very helpful when you have complex business rules, especially when you have several applications accessing the same database. Each application will be expecting the data in a certain way, and if the constraints weren't there, you could have a very elusive bug.
(2) Regular Triggers: I don't find myself using these very often, but sometimes they're necessary. Some have developed very powerful packages, like http://www.slony.info/, which is a very advanced replication system that wouldn't be possible without triggers. Triggers are a very powerful tool, although not used in day-to-day stuff. When you find yourself thinking "I know what I need to do, but I don't know if I can make my database do that", think triggers. Remember since triggers use functions, you can do pretty much anything, like emailing yourself.
-- To find examples and more explanation, the postgresql.org docs are good. If you have more specific questions, email the postgres lists and I'll be there.
Views are great if you have a dataset that just doesn't change much because it allows for the data to be sitting there ready.
I think you're talking about materialized views. Views in postgres are, as of now, just query rewriting, so they serve no purpose other than organization.
However, views are a very valuable organization tool because they allow you to make changes to the way the query is structured without changing the application at all.
Those are a hell of a lot more specific and narrow than "protecring citizens from violence". You certainly can't apply either of those clauses to the automated monitoring of violent areas hoping to catch a criminal.
The market works much better when the person who consumes something also pays for it.
Now, insurance has its place. But it's not the place of insurance to pay for some routine prescriptions and doctor visits. If it started becoming more rare for people to use insurance, than I believe that the bill padding would decrease dramatically.
And yes, I've had to call my insurance company to tell them not to pay someone also. The suppliers pad the bill and most of the time the insurance just pays. It's not my money, but I feel I have a responsibility.
This argument that "if you aren't doing anything illegal..." is similar to saying "If you're not guilty than it doesn't really matter if you go to jail, there's still food and water there".
I know going to jail is worse. My point is that being searched is bad in and of itself, guilty or not, and that's why the power to search is restricted by the 4th amendment. You don't need a reason to not want to be searched, being searched is bad all by itself.
Free people like to know what is being watched, how, and why. Undercover cops are relatively rare and expensive (inherently), so you can imagine that they are used sparingly and narrow in scope. Uniformed officers are more common, less expensive, and more visible. Compare that to cameras: cheap, invisible, and does not require the cooperation of the rank-and-file officers to do something wrong. A lot easier to run a conspiracy if nobody has to be in on the scheme.
Protecting citizens from violence is one of the very few jobs the federal government is actually SUPPOSED to be doing, according to the Constitution.
Perhaps you can point out the passage, I haven't found it yet.
I always thought that was a responsibility of the state. In this case it should be O.K. since the city is the one setting it up and the state prosecutes.
But the person walking by me isn't being paid with my own money to spy on me. So they probably just don't care and they'll keep walking.
Re:Mixed feeling
on
HIV Vaccine
·
· Score: 5, Insightful
I think our philosophies are very different, but your observation is very true. Insurance companies ARE very similar to socialism.
The problem is that medical insurance became widespread when companies started offering health plans in lieu of pay.
Everyone has some basic levels of medical costs: vaccinations, pediatrician visits for their children, eye care, dental care, occasional medical situations (perhaps a broken bone or infection), etc. If you buy insurance against something that everyone knows will happen to you, then the only result is that the insurance company wins big time, just like Las Vegas: they know the numbers and they know that they will win.
What you buy insurance against are the high costs that you probably won't suffer, but would create a hardship if you did. These include tragic accidents that are rare but require hundreds of thousands of dollars to fix, or bizarre diseases or something.
What we have is a situation where basic medical needs are being covered by insurance, which means the customer is always losing (just like if you spend enough time at the blackjack table).
The only thing that makes sense is to drop the insurance policy that you lose out on, and get a cheaper policy that only covers the big stuff. Then pay the little stuff yourself.
Then you also benefit because your premiums aren't covering the costs of high-risk lifestyles of other people. The insurance companies can't discriminate and charge those people more, sometimes because the law won't let them (i.e. they can't charge more to gay people) and sometimes because they don't know (druggies or something).
Don't be silly. All it takes is hard work to succeed in the meritocracy that is the land of the free.
Hard work doesn't do anyone else any good if you're the wrong worker in the wrong place among the wrong people.
If you're a construction worker you need to go where the work is and meet the people doing the big contracting jobs. This isn't exactly news. Same for Computer Science/Engineering.
So no, it takes hard work as well as proper allocation of resources to be productive (and to deserve merit), and then you can be successful.
With only hard work, you're no more worthy of merit than a construction worker trying to build an office building with his bare hands. Admirable, perhaps, but doesn't do any good to an accountant waiting 10 years for the office to be built.
I think you're right, but you're neglecting an important reason people go to big-name schools.
If you attend a prestigous university, you will know important people who will offer you a job. There will also be more jobs nearby related to what makes the university prestigous due to successful alumni.
Slashdot Mirror
Well, then don't buy a DRM version of the Shrek movie.
Nobody is required to release non DRM products and nobody is required to buy a DRM product. As long as you can find out if it's DRM before you buy it, I don't see any problem at all. We can just vote with our dollars.
Consider if they just released it in movie theaters and never made a dvd. You would still never really get access to the original format of the movie. That seems to me very much like DRM, except that since movie theaters are old we don't call a movie theater DRM.
I could be wrong, but I think the author of the articcle was trying to show you tools written in perl that can help you template your website and gain advantages that you can't with server-side includes (whether the includes are in perl, php, SSI, or whatever). I don't think he was implying that developers should all develop in perl, just use the template tools that happen to be written in perl.
I say, "you reap what you sow."
That works both ways. If the employer sows dishonesty, so shall he reap. If the potential employee sows dishonesty, so shall he reap.
Also, your statement that "you reap what you sow" is inconsistant with the idea that people are rewarded for greed and dishonesty.
Although they haven't stated any harms aside from it's an unproven platform, they haven't found any benefits, either. So they said why bother.
Apache 2 was originally released with visions of a "perchild" MPM. What ever happened to that? That would be a real improvement for security on a name-based virtualhosting system. Is anyone working on it? Can I donate a little money to encourage its development somewhere?
There is still no good way of doing several sites on the same server in a good way. The options, as I see it are:
(1) Several instances of apache, each on a seperate IP. Administration difficult because of all the extra daemons.
(2) Name-based virtual hosting with safe_mode php: works fine, but requires safe mode which breaks many apps and is cumbersome to work with. You can't do mod_perl without trying to find some way of restricting its access.
(3) Suexec on ip based virtualhosts. Requires a lot of IPs, and CGIs are performance hogs (and also not what people are used to, and breaks many apps).
This is a serious question. If you have any pointers please respond. Or even tell me a better place to ask, because I'm usually ignored.
Very interesting post. I never thought about it that way before.
Tablespaces are NOT the same as table partitioning, however tablespaces are a great addition to PostgreSQL 8.0.
Table spaces allow you to store any table or index in any physical location. For example, you can put a small, frequently accessed table on your expensive RAID, and leave the big tables on slower, cheaper disks.
Table partitioning is when you have one table and break it up accross seperate physical locations. Useful for very large tables, but much more difficult technically.
As far as "clustering natively", the developers do not even think that clustering/replication belong in the server itself for many reasons:
(1) Having it a seperate system means that it can work with a variety of PostgreSQL versions all at once. You can replicate 7.4 to 8.0 with no problem.
(2) Moving seperate tasks out of the main server source allows for a faster release cycle on all products. If everything that makes PostgreSQL great was in the same tree, the release would take a long time, and many important developers wouldn't be able to spend their time writing new features. It also allows faster bug fix releases for the same reason.
(3) There are many different uses for replication and clustering. Many people use those terms to mean different things that require different solutions based on your need. For example, are the machines connected 99% of the time, or are you just using replication to sync the data nightly? If one machine is seperated from the rest (by network failure), what should the replication server do when you try to commit a transaction on that lone server? There are many cases to consider that depend on your business need, and the commercial companies gloss over all the details by just saying that they "support clustering", which may or may not meet your actual needs.
Blaming parents is a cop-out. You can't make parents care. And you certainly can't expect all parents to be educated enough to teach their kids effectively.
If a child wants to learn, he should be able to accomplish that at school. That is nearly impossible in many places.
Teachers need to be accountable, and they need to FAIL kids who don't know. That's what failing is, right? Well, if you don't pass a final exam covering all the material for the year/semester, you should FAIL. Then you retake the class and LEARN it. Then teachers don't waste everyone's time reviewing material.
Of course, people are too concerned about children's self-esteem. Nobody wants to be the person to tell a child: "You just don't know the material well enough to move to the next level". But how else will they learn?
That keeps the kids who want to learn moving, and seperates them from the kids who are holding them back (by demanding review of topics the other kids knew years ago). Everyone can learn at their own pace.
Maybe that would bring back the antiquated concept of shame? Poorly performing kids would realize "Hey, all the other people my age are moving right past me. Perhaps I should get my act together.". It might also make a high school diploma worth something again.
I don't think you understood my post at all. I wasn't advocating oracle, I was just pointing out that an 80GB database is quite common, and in order to impress someone with a database, you need to show what you can do with 80GB, not that you have 80GB.
Access's backend DB sucks. Access does not suck. It's a valuable tool to manage databases and also to create client access software to distribute to the people who need to access the data. Web interfaces have made it less necessary, but I bet it's a lot quicker in Access still.
I like postgresql, but thanks for trashing that guy's post.
PostgreSQL has great recovery from a power failure. But if the bytes aren't there, the bytes aren't there. In fact, if the inodes aren't there, as far as postgresql is concerned, the bytes aren't there.
I assume that MySQL has some basic ability to recover from power failure. I'd be a little concerned that the database would be inconsistant, but it would probably not be corrupt. I'd like to know if anyone has any experience with power failure corrupting a DB of either type (pg or mysql).
FAT32 can hold 80GB of mp3s with no problem, and FAT32 is not exactly Oracle.
/dev/null. It can take the INSERTs as fast as I can send them, and never bogs down my system with pesky I/O bandwidth, and never tells me it's full.
It's not how much a DB can hold, it's how easy/fast it is to get exactly the information about your information you want; nothing more, nothing less. The ease and performance of getting such information must scale also, not just the amount the DB can hold.
Heck, you know what's a great database?
So, 80GB can be a lot if you have demanding requirements about the details of your data and the relationships with other data. If not, it's just some bytes (that you optionally want back). Then it doesn't matter, just use FAT32.
Also, if you consider an application where data is only ever input through the web or some other front-end GUI, foreign key contrains aren't necessarily needed (I'll admit they're still good to have and use), because you can control the input through restricted UI elements like drop-downs, radio buttons, etc.
:)
I know a lot of people do that (myself guilty on occasion), but you're the first person to publicly admit it
Constraints are very important.
First, in the app, you check the input for basic security reasons (remove quotes and backslashes and whatnot). Even if it's a radio button, that wouldn't slow me down from sending your website invalid data. Check it every time.
The constraints are important because if you have several parts to an application, or perhaps several applications all accessing the same data, you don't want one part to adversely affect another. If one part of the app tries to insert invalid data that would confuse another part of the application, the constraint will prevent the insertion and raise an error right there. Then you very quickly know where the bug is. If you had no constraint, the bug could appear 3 days later in some report of sales data, and you'd have no idea where to find the bug.
Constraints have saved me a LOT of time bug-hunting.
There are some applications where it doesn't matter much what DB you use. For those it's great to be "DB agnostic".
However, let me warn you that what often happens is that you end up going with the lowest common denominator and use no specific optimizations. That might not be so bad in the really simple cases. However, in all other cases it means that the application has to pick up the slack, and do the stuff that you would normally ask the DB to do.
That means that your data abstraction layer becomes huge and unweildly, and distracts from the purpose of the application. If one of your supported DBs doesn't support proper constraints, that means that every piece of your app has to maintain and check the consistency of the data in the database in excrutiating detail. If it doesn't, than it could create bugs very difficult to find, and create inconsistencies in the DB that you have to fix manually.
I've heard of a large application that tried to be DB agnostic (to attract more customers) and just the consistency maintaining/checking code was as many lines as the rest of the application, and caused major performance problems.
So, it's a tradeoff (like everything else, I suppose): are those extra users who use the DB that brings the lowest-common denominator down 5 notches worth the client-side work? Maybe. Just make sure you know what you're getting into. It seems easy at first, but as the application grows, your ultimate responsibility (if making a high-quality application) will be the client-side reimplmentation of all the features in the DB that you need but can't use because some other DB on your "supported platforms" list doesn't offer the feature. That's a big price for a "We support Foo RDBMS" checkmark on the product page.
And really... is that what you want to spend your time debugging? The same stuff that DB projects have spent many years debugging already? And then asking the clients to buy more hardware to support the performance-hog client-side database layer is not going to go over very well.
First, I'd like to point you to my favorite book about database theory, even though it's not exactly what you asked for:
"An Introduction to Database Systems" by C.J. Date. It's a great book and I liked it so much I bought another by the same author: "Foundation for Future Database Systems - The Third Manifesto". Both are very theoretical and also very precise.
On a more practical level:
* Stored Procedures: In postgres, these are the same as functions. They have several distinct purposes:
(1) Produce data in the form of a relation that you might not otherwise be able to produce with a query alone. An example might be some kind of query that is hard to express otherwise (if there are lots of bizarre if..then's or loops that are based on the contents of the records), or if you want to make a socket connection in the function and return a table of the current headlines from slashdot.
(2) functions are vital to making a proper user-defined data type: you need the input and output functions, the comparison functions (if you want it to be indexable), etc.
(3) Making a user-defined aggregate function is very useful if you need something other than the basics, and an aggregate function requires several other functions (accumulator, for instance).
(4) Basic batching of statements so you don't have to send so many queries.
(5) if you need to execute several statements and try to recover from various errors in a graceful way, without having to have client-side logic. A simple example might be to make a function that tries to INSERT, and if it gets a duplicate key violation, than it does UPDATE.
(6) triggers require functions also
(7) Stored procedures/functions allow you to express your logic in languages other than SQL, like perl, for instance.
(8) functional indexes are very useful for query optimization.
* Views: In postgresql, views are a rewriting rule that is very useful for being a DBA, because you can optimize a query or change the physical storage without modifying the app at all (or even interrupting it). However, some databases go beyond that and have materialized views, which can improve performance by holding the data seperately, ready to access.
* Triggers: two main types
(1) Constraint triggers: very powerful constraint tool that allows you to check the database for any inconsistencies before committing the transaction. This is very helpful when you have complex business rules, especially when you have several applications accessing the same database. Each application will be expecting the data in a certain way, and if the constraints weren't there, you could have a very elusive bug.
(2) Regular Triggers: I don't find myself using these very often, but sometimes they're necessary. Some have developed very powerful packages, like http://www.slony.info/, which is a very advanced replication system that wouldn't be possible without triggers. Triggers are a very powerful tool, although not used in day-to-day stuff. When you find yourself thinking "I know what I need to do, but I don't know if I can make my database do that", think triggers. Remember since triggers use functions, you can do pretty much anything, like emailing yourself.
-- To find examples and more explanation, the postgresql.org docs are good. If you have more specific questions, email the postgres lists and I'll be there.
Why are suppliers given direct access to your RDBMS? You should provide a frontend for them that only allows what you want.
Views are great if you have a dataset that just doesn't change much because it allows for the data to be sitting there ready.
I think you're talking about materialized views. Views in postgres are, as of now, just query rewriting, so they serve no purpose other than organization.
However, views are a very valuable organization tool because they allow you to make changes to the way the query is structured without changing the application at all.
Those are a hell of a lot more specific and narrow than "protecring citizens from violence". You certainly can't apply either of those clauses to the automated monitoring of violent areas hoping to catch a criminal.
The preamble gives no powers or responsibilities to anyone. Period.
If you read it again that's quite apparent from the language, in addition to the fact that it's called "the preamble".
I wholeheartedly agree.
The market works much better when the person who consumes something also pays for it.
Now, insurance has its place. But it's not the place of insurance to pay for some routine prescriptions and doctor visits. If it started becoming more rare for people to use insurance, than I believe that the bill padding would decrease dramatically.
And yes, I've had to call my insurance company to tell them not to pay someone also. The suppliers pad the bill and most of the time the insurance just pays. It's not my money, but I feel I have a responsibility.
This argument that "if you aren't doing anything illegal..." is similar to saying "If you're not guilty than it doesn't really matter if you go to jail, there's still food and water there".
I know going to jail is worse. My point is that being searched is bad in and of itself, guilty or not, and that's why the power to search is restricted by the 4th amendment. You don't need a reason to not want to be searched, being searched is bad all by itself.
Free people like to know what is being watched, how, and why. Undercover cops are relatively rare and expensive (inherently), so you can imagine that they are used sparingly and narrow in scope. Uniformed officers are more common, less expensive, and more visible. Compare that to cameras: cheap, invisible, and does not require the cooperation of the rank-and-file officers to do something wrong. A lot easier to run a conspiracy if nobody has to be in on the scheme.
Protecting citizens from violence is one of the very few jobs the federal government is actually SUPPOSED to be doing, according to the Constitution.
Perhaps you can point out the passage, I haven't found it yet.
I always thought that was a responsibility of the state. In this case it should be O.K. since the city is the one setting it up and the state prosecutes.
How did this become a federal issue?
But the person walking by me isn't being paid with my own money to spy on me. So they probably just don't care and they'll keep walking.
I think our philosophies are very different, but your observation is very true. Insurance companies ARE very similar to socialism.
The problem is that medical insurance became widespread when companies started offering health plans in lieu of pay.
Everyone has some basic levels of medical costs: vaccinations, pediatrician visits for their children, eye care, dental care, occasional medical situations (perhaps a broken bone or infection), etc. If you buy insurance against something that everyone knows will happen to you, then the only result is that the insurance company wins big time, just like Las Vegas: they know the numbers and they know that they will win.
What you buy insurance against are the high costs that you probably won't suffer, but would create a hardship if you did. These include tragic accidents that are rare but require hundreds of thousands of dollars to fix, or bizarre diseases or something.
What we have is a situation where basic medical needs are being covered by insurance, which means the customer is always losing (just like if you spend enough time at the blackjack table).
The only thing that makes sense is to drop the insurance policy that you lose out on, and get a cheaper policy that only covers the big stuff. Then pay the little stuff yourself.
Then you also benefit because your premiums aren't covering the costs of high-risk lifestyles of other people. The insurance companies can't discriminate and charge those people more, sometimes because the law won't let them (i.e. they can't charge more to gay people) and sometimes because they don't know (druggies or something).
Don't be silly. All it takes is hard work to succeed in the meritocracy that is the land of the free.
Hard work doesn't do anyone else any good if you're the wrong worker in the wrong place among the wrong people.
If you're a construction worker you need to go where the work is and meet the people doing the big contracting jobs. This isn't exactly news. Same for Computer Science/Engineering.
So no, it takes hard work as well as proper allocation of resources to be productive (and to deserve merit), and then you can be successful.
With only hard work, you're no more worthy of merit than a construction worker trying to build an office building with his bare hands. Admirable, perhaps, but doesn't do any good to an accountant waiting 10 years for the office to be built.
I think you're right, but you're neglecting an important reason people go to big-name schools.
If you attend a prestigous university, you will know important people who will offer you a job. There will also be more jobs nearby related to what makes the university prestigous due to successful alumni.