Heh, it's not that the command itself isn't simple. Just finding out how took a little effort. I can't imagine someone taking a week or two to figure that one out.
Who in their right mind uses r* and sendmail on anything connected to the public internet?
Actually, as the article pointed out, sendmail hasn't had any serious problems in the past 2 years. Quite frankly, it's quite powerful and its default install is kinda simple to use except (except!) for that stupid map command to build virtual users, access tables and the likes.
It's not the end of the world if you use it, just like it's not the end of the world if you use proftpd.
Hold on a second. Just so that we can enjoy more callories, we justify more exercise.. to give back the callories... wtf.. doesn't this seem a little silly?
Silly slashdotter. RIAA is a.org, thus an organizatoin. It doesn't make money... just helps the airheads of the big-5. So stop talking bad about the RIAA.. it's the big 5 you wanna go after.. really!
Yes, you'll save time, but you it'll be a little longer than 10 minutes.
First off, i have to learn a whole new set of DB function names since all of them have different names. Some functionality doesn't exist between the two db api's.. such as mysql and a prepare like statement. What if I switched from oracle to mysql? Now i have to restructure my code heavily. A prepare should remember what the query is and return a statement handler.
Secondly, most queries will stay the same. Most queries would be simple selects, insert's and deletes which are SQL (92?) compliant in the first place.
This is exactly the reason why php is not as enterprise level as say java. Even C++ has it's advantages, but it's all in the OO.
MySQL has no concept of prepare_statement, what would you do in that case? The names of the functions are the actual names exposed by the underlying C client libraries. The Perl abstraction layer has to call these exact functions with their wierd names. Sure, it hides that from you. But that's just what PEAR::DB does.
Right. PEAR::DB does a great job. Now hide the extra functions!:)
As for your mysql thing, you make prepare remmeber the statement you want to run, like a good abstraction layer normally does (that we've seen so far, like pear::db or perl's dbi).
Unless you know the future of everything you'll ever do, you will never know if something wont' come along.
You start with a specific idea but make things general enough that if you change certain variables it won't be the death of everything. DB's, db strucutre, template engines are major points for speed improvements. So if one DB is faster than another or another template engine is better, the work becomes less.
And I'll skip the sarcasm since you're familiar with the subject you're talking about:)
Thank you my liege!;) heh
Agreed in some cases the difference might not be worth using the old way but there is still a need for it in some applications.
My argument is in MOST ways you'll not see much speed differece, and the bit you see in load you can throw one more server in the load balancer pool AND... (and...) what you lose in speed, you'll win back in development flexibility, wether it's changing DB's or developing new code. I'm sorry, having oci and oracle libs at the same time, and not deprecating one really.. bugs me.
I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!
I would. Because it depends on the position of the programmer. Is he a junior programmer? If so, I wouldn't want to fire him since he may not have the knowledge to do any better. That's why a good language or api would support the programmer and not be a wasteland (severity not intended) of things you can do.
And just 'cause things are obvious to you, maynot be obvious to you.:)
Granted. Just like we all take different roads to get to different places. By allowing people to do bad things is just as bad as promoting. Writing bad algorithms is a better limit to buggy code than writing code that causes overflows or structual limitations on the architecture.
Yes, but by not preventing people from making bad decisions is just as bad as promoting it. It's a bad mark on the language to allow bad things to occur. Look at c. buffer-over-flow city. If you knwo what you are doing, of course you'll win out, but you brin in a developer who doesn't think of the long term effects of gets() or the long term effects of using functions that are only usable with one db (switching db's becomes a pain), you lose.
Yes, but abstracting is such a minimal performance loss that there's no reason why it houldn't happen. In fact, if the DB was made common, we wouldn't need an abstraction layer on top of it. Since everything
The problem with php, is if the application's require/include tree get's large, it has compilation problems at times. Granted, you may not see it easily, but I've seen it happen on files that just declare variables.
And my knowledge is based on C, C++, perl, java and php, so no need to get sarcastic;P
The performance increase between using exposed and hidden functions is minimal. If you should want to write your own abstraction layer, it could be done on top of a common one. Say I don't like perl's DBI and i like procedural programming. I can write a layer on top of it. If I also want to, i can replace DBI using what DBD provides. And perl's method of db communication isnt' hidden by far. Just like php's module interface isnt' hidden, though VERY poorly documented.
PEAR::DB and ADO:BD are carpets which the dust has been swept under. By leaving them exposed, they allow people to make things more difficult. It's like putting a cardbord box over a gun in your house. Sure, the problem doesn't look like it's there, but you can easily find the gun and shoot someone.
What I'm saying, is that the mix-matched-names are bad. VERY bad. They show no relationship to a higher level of commoonality. There's no common prepare_statement(databse_handle,statement) type structure. Everyone does what they want. And if you have to switch db types, you have to relearn everything.
Yeah, that's cause it's not a database layer. The database API is the one exposed by the database client library. Every API is different because every database vendor does something different. This is not the fault of PHP. Most languages FORCE you to go through some kind of abstraction (Microsoft has ADO and ODBC) which just does exactly what PEAR::DB does. But if you only use one DB type, or need some special functionality of the API, then for best performance and compatibility you'll want to use those base APIs.
I for one don't use PEAR::DB. I have my own database abstraction for my own projects which, of course, makes direct calls to the database. So I'm happy for the ability. (Same goes for the other API's as well) You can't shoot yourself in the foot using the database-specific API's.
Ok, layer is a word i use only because it should be seperated somehow.. perhaps i'll just use the word api. Fine, every DB vendor does things differently, but there is a LOT in common. How do you think perl's DBI layer works? They use dbd (iirc) for the specifics and interface it into dbi, a common ground.
The disadvantage of using the specific api's? Try switching databases and watch the chaos ensue:)
Right, but being able to shoot yourself in the foot in arcane ways. I.e. c's gets() function. There are alternatives that aren't buggy when used wrong.
It's kinda why I like java so much. It assumes to some degree that programmers are either careless, make mistakes, or just plain stupid:)
What makes it worse is they are trying to make it more OO by re-inventing the wheel. If they used an OO language underneath, they can make it more OO like.
PHP always acted like a complete hack of a language vs something that was engineered. Look at the database layer? No common functionality. Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.
Sorry, bitter from trying to do enterprise programming with it.
Is it possible to stop thinking about what evils there are today? I know it doesn't seem like the biggest deal they shut off their ads. Live and let live, eh?
It's their little tribute. Let them have it and if you don't like it, that's ok. I kinda like it. Right now, today is all about me and just getting things straight in my head. I'll still think of slashdot as only an outlet and not a place to have many intelligent conversations, but let those of us who choose to acknowledge what they've done as something nice.
Some of them should be remembered, true. But you have to remember, 9/11 was just last year. A lot more of us are still feeling the effects of it. On top of it, it was an act of war that killed 3000ish, that affected the stock market and our entire economy in one of the largest cities of the world. Plus, the Pentagon was hit, with the intent to take out a good chunk of our leaders.
I'm not saying that any other disaster isn't worth remembering. You are right, we should have it on our calendars at least as a reminder of all the wrong that has occured, due to falt and due to fate.
It's just not as easy to forget what happened, when you don't know where your loved one was or will never see them again, just 350-something days ago. I'm mostly over it, but to some degree, it still saddens me to think that the skyline that was NY, with two very awesome towers, whre I used to lay down on the promenade between the buildings and just look up at the endless towers with someone I loved once. It's not a place I wanted to give up but was forced to. Then there's the lives that were lost and a constant blanket of fear of what will happen next.
Sorry if I sound preachy, or a little sentimental, but today, for me, and many others... many many others is a very important day of rememberance. Maybe next year or two years from now when time has healed wounds more, it won't seem so hypocrytical.
Slashdot Mirror
Heh, it's not that the command itself isn't simple. Just finding out how took a little effort. I can't imagine someone taking a week or two to figure that one out.
Who in their right mind uses r* and sendmail on anything connected to the public internet?
Actually, as the article pointed out, sendmail hasn't had any serious problems in the past 2 years. Quite frankly, it's quite powerful and its default install is kinda simple to use except (except!) for that stupid map command to build virtual users, access tables and the likes.
It's not the end of the world if you use it, just like it's not the end of the world if you use proftpd.
Just sue your slashdot "freaks". http://yro.slashdot.org/~Knightfall/freaks :)
Does this mean you would endorse a DRM system like Palladium?
It probably means they should put a unique identifier on each dvd, ala hard drives, and you can have an X-day warantee for replacement.
Someone posted something like that and got a +Funny :)
Isn't that how drugs are? The first hit is free....
Hold on a second. Just so that we can enjoy more callories, we justify more exercise.. to give back the callories... wtf.. doesn't this seem a little silly?
You mean "too me".
:)
Liar
Silly slashdotter. RIAA is a .org, thus an organizatoin. It doesn't make money... just helps the airheads of the big-5. So stop talking bad about the RIAA.. it's the big 5 you wanna go after.. really!
Yes, you'll save time, but you it'll be a little longer than 10 minutes.
First off, i have to learn a whole new set of DB function names since all of them have different names. Some functionality doesn't exist between the two db api's.. such as mysql and a prepare like statement. What if I switched from oracle to mysql? Now i have to restructure my code heavily. A prepare should remember what the query is and return a statement handler.
Secondly, most queries will stay the same. Most queries would be simple selects, insert's and deletes which are SQL (92?) compliant in the first place.
This is exactly the reason why php is not as enterprise level as say java. Even C++ has it's advantages, but it's all in the OO.
MySQL has no concept of prepare_statement, what would you do in that case? The names of the functions are the actual names exposed by the underlying C client libraries. The Perl abstraction layer has to call these exact functions with their wierd names. Sure, it hides that from you. But that's just what PEAR::DB does.
:)
Right. PEAR::DB does a great job. Now hide the extra functions!
As for your mysql thing, you make prepare remmeber the statement you want to run, like a good abstraction layer normally does (that we've seen so far, like pear::db or perl's dbi).
Unless you know the future of everything you'll ever do, you will never know if something wont' come along.
You start with a specific idea but make things general enough that if you change certain variables it won't be the death of everything. DB's, db strucutre, template engines are major points for speed improvements. So if one DB is faster than another or another template engine is better, the work becomes less.
And I'll skip the sarcasm since you're familiar with the subject you're talking about :)
;) heh
Thank you my liege!
Agreed in some cases the difference might not be worth using the old way but there is still a need for it in some applications.
My argument is in MOST ways you'll not see much speed differece, and the bit you see in load you can throw one more server in the load balancer pool AND... (and...) what you lose in speed, you'll win back in development flexibility, wether it's changing DB's or developing new code. I'm sorry, having oci and oracle libs at the same time, and not deprecating one really.. bugs me.
I wouldn't hesitate for a moment to fire a programmer who accidentally wrote a PHP application using the mysql-specific calls when the requirements of the project included database portability. Wouldn't you?!
:)
I would. Because it depends on the position of the programmer. Is he a junior programmer? If so, I wouldn't want to fire him since he may not have the knowledge to do any better. That's why a good language or api would support the programmer and not be a wasteland (severity not intended) of things you can do.
And just 'cause things are obvious to you, maynot be obvious to you.
Granted. Just like we all take different roads to get to different places. By allowing people to do bad things is just as bad as promoting. Writing bad algorithms is a better limit to buggy code than writing code that causes overflows or structual limitations on the architecture.
Yes, but by not preventing people from making bad decisions is just as bad as promoting it. It's a bad mark on the language to allow bad things to occur. Look at c. buffer-over-flow city. If you knwo what you are doing, of course you'll win out, but you brin in a developer who doesn't think of the long term effects of gets() or the long term effects of using functions that are only usable with one db (switching db's becomes a pain), you lose.
Yes, but abstracting is such a minimal performance loss that there's no reason why it houldn't happen. In fact, if the DB was made common, we wouldn't need an abstraction layer on top of it. Since everything
;P
The problem with php, is if the application's require/include tree get's large, it has compilation problems at times. Granted, you may not see it easily, but I've seen it happen on files that just declare variables.
And my knowledge is based on C, C++, perl, java and php, so no need to get sarcastic
The performance increase between using exposed and hidden functions is minimal. If you should want to write your own abstraction layer, it could be done on top of a common one. Say I don't like perl's DBI and i like procedural programming. I can write a layer on top of it. If I also want to, i can replace DBI using what DBD provides. And perl's method of db communication isnt' hidden by far. Just like php's module interface isnt' hidden, though VERY poorly documented.
PEAR::DB and ADO:BD are carpets which the dust has been swept under. By leaving them exposed, they allow people to make things more difficult. It's like putting a cardbord box over a gun in your house. Sure, the problem doesn't look like it's there, but you can easily find the gun and shoot someone.
What I'm saying, is that the mix-matched-names are bad. VERY bad. They show no relationship to a higher level of commoonality. There's no common prepare_statement(databse_handle,statement) type structure. Everyone does what they want. And if you have to switch db types, you have to relearn everything.
Yeah, that's cause it's not a database layer. The database API is the one exposed by the database client library. Every API is different because every database vendor does something different. This is not the fault of PHP. Most languages FORCE you to go through some kind of abstraction (Microsoft has ADO and ODBC) which just does exactly what PEAR::DB does. But if you only use one DB type, or need some special functionality of the API, then for best performance and compatibility you'll want to use those base APIs.
I for one don't use PEAR::DB. I have my own database abstraction for my own projects which, of course, makes direct calls to the database. So I'm happy for the ability. (Same goes for the other API's as well) You can't shoot yourself in the foot using the database-specific API's.
Ok, layer is a word i use only because it should be seperated somehow.. perhaps i'll just use the word api. Fine, every DB vendor does things differently, but there is a LOT in common. How do you think perl's DBI layer works? They use dbd (iirc) for the specifics and interface it into dbi, a common ground.
The disadvantage of using the specific api's? Try switching databases and watch the chaos ensue
Right, but being able to shoot yourself in the foot in arcane ways. I.e. c's gets() function. There are alternatives that aren't buggy when used wrong.
:)
It's kinda why I like java so much. It assumes to some degree that programmers are either careless, make mistakes, or just plain stupid
What makes it worse is they are trying to make it more OO by re-inventing the wheel. If they used an OO language underneath, they can make it more OO like.
PHP always acted like a complete hack of a language vs something that was engineered. Look at the database layer? No common functionality. Pear is cool and all, but by making the old calls avail, you allow users to still shoot themselves in the foot.
Sorry, bitter from trying to do enterprise programming with it.
What do I look like, a .com millionaire? *snicker*
Is it possible to stop thinking about what evils there are today? I know it doesn't seem like the biggest deal they shut off their ads. Live and let live, eh?
It's their little tribute. Let them have it and if you don't like it, that's ok. I kinda like it. Right now, today is all about me and just getting things straight in my head. I'll still think of slashdot as only an outlet and not a place to have many intelligent conversations, but let those of us who choose to acknowledge what they've done as something nice.
I hear you. The idea is nice though. Just the presentation is wrong in a few ways.
I'm a fellow NY'er who was scared and all that day. I'd like to remember what happened. Maybe not so.. intense.. but at least something.
Don't be angry about what's going on today. Just allow some of us to wallow in our sadness just for a moment, today.
Some of them should be remembered, true. But you have to remember, 9/11 was just last year. A lot more of us are still feeling the effects of it. On top of it, it was an act of war that killed 3000ish, that affected the stock market and our entire economy in one of the largest cities of the world. Plus, the Pentagon was hit, with the intent to take out a good chunk of our leaders.
I'm not saying that any other disaster isn't worth remembering. You are right, we should have it on our calendars at least as a reminder of all the wrong that has occured, due to falt and due to fate.
It's just not as easy to forget what happened, when you don't know where your loved one was or will never see them again, just 350-something days ago. I'm mostly over it, but to some degree, it still saddens me to think that the skyline that was NY, with two very awesome towers, whre I used to lay down on the promenade between the buildings and just look up at the endless towers with someone I loved once. It's not a place I wanted to give up but was forced to. Then there's the lives that were lost and a constant blanket of fear of what will happen next.
Sorry if I sound preachy, or a little sentimental, but today, for me, and many others... many many others is a very important day of rememberance. Maybe next year or two years from now when time has healed wounds more, it won't seem so hypocrytical.