Not sure what you're talking about with having to update WP every week. The releases tend to be on a 2 or 3 month cycle. There hasn't been a security related push-it-out-now type of release for quite a while.
Sounds like you need to get some actual programmers instead of script kiddies. PHP is an okay language, but it is very easy to learn, so a lot of "new" programmers don't really have the background necessary to use it properly.
As with any programming language, it is possible to shoot yourself in the foot with it.
PHP's mysqli supports parameterized queries just fine.
Admittedly, old versions of PHP didn't have this stuff, but seriously, PHP 5 has been around for several years. Why people haven't switched yet is beyond me.
It's a conundrum indeed. Trying to convince web hosts to support PHP 5 has been an uphill battle for years and years, and major software like WordPress won't move past PHP 4 compatibility because some web hosts still don't support it.
We really need to get rid of PHP 4 everywhere. It would help a lot with this sort of thing.
Most USB devices I've seen will charge whenever they detect enough power on the line to allow them to do it. Like anything coming at them higher than 100mA triggers them into charge mode. This is because many self-powered hubs will throw 500mA at everything regardless of enumeration, so charging on-demand makes more sense. Of course, the driver is needed for a machine to kick out more than 100mA on a port, but not all ports require that, so it's best to charge whenever you can.
Your monitor has a self-powered USB hub built into it, and the phone is designed to charge whenever it has enough power coming to it. The monitor gives it that much, so it charges, no drivers needed.
A USB port on the computer acts differently than a port on a hub.
I take it this means that if I have a USB hub then my cell phone is always on low power charge mode. Otherwise I don't see how a computer could decide how much current to supply when multiple devices are attached in parallel via a hub.
USB hubs are more than mere wiring, they have to have some minor amount of intelligence. There's two basic kinds of hubs: bus-powered and self-powered. Self-powered hubs have a separate power source (wall outlet, etc) and are allowed to provide up to 500 mA to devices connecting to them, which is the same as the high-power mode for normal USB ports. This allows those devices to charge. Bus-powered hubs can't do this, they're basically limited to the amount of power they get from the USB port itself.
A second question is, why don't devices supply their own drivers when you plug them in?
Because that's not possible in the USB specification. The "no-driver" devices really use a default set of drivers that have their characteristics predefined in the USB specs.
Also, it's a bit of a security risk for a device to be able to send executable code to the PC and actually have it get executed.
Ok, I have to ask, I keep seeing replies that boil down to "that's what backups are for" in response to key loss issues. I am wondering how a backup helps if you lose the key.
Umm... You keep a backup of the key itself. That way, when you lose the key, you have it somewhere else safe and secure.
Modern encryption systems generally use a sort of dual layer method of encryption. First, you have the main key, which encrypts your data itself. This key is usually rather large, because a short key is pointless when you're encrypting a LOT of data. However, this key is too large to remember, so you keep that key somewhere else.
Naturally, having that key stored is not safe, so you encrypt it as well, using some other encryption method, and which you secure with a more common means of securing things, like a password. This is your "keyring". Since the keyring is small, it doesn't matter that the password used to secure it is small(ish) too.
Now, if you keep a backup of the unencrypted (or encrypted with a known password that you won't forget) keyring in a safe and secure place, then losing your password to your normal keyring is not a disaster. Just get your backup keyring and use it to access the data.
"Argh, I lost my key! I lost all those files that we need to get the government off our backs, and all our customer lists, and everything! Shit! We just went out of business!".
Ever heard of a backup? If you don't have backups, then what happens when your hard drives fail?
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on.
What kind of freakin' "bug" takes a bloody week to work on?
PROTIP: Start your task by breaking big bugs into smaller bugs. Seriously, use that bug tracker to full advantage. As you figure out the issue, make new bug reports for each of the (small) pieces of the problem. Then put in the original bug that it has been subdivided into bug A, B, C, etc. Then start working on each one of those, closing them as you go.
Advantages to this: a) In a multi-developer environment, one of the other devs might come along and fix one of the pieces for you, closing it in the process. Less work for you is a good thing. b) If your bugtracker is worth a damn, then you'll be able to see the status of the sub-bugs on the original report, and when they're all closed, you can write "fixed" and get on with your life. c) Dependencies won't stop you dead in the water, you'll be able to keep tracking what you're doing and when. d) Management number inflation. We fixed X bugs this week!
Bug trackers work great for small problems. And all large problems are just a series of small problems.:)
But 89% of the houses in Iceland are heated with geothermal energy (http://iceland.ednet.ns.ca/schedule.htm).
Yes, because Iceland is a lot colder above the ground than Hawaii is. It's all about temperature difference.
Underground is pretty warm, everywhere on the planet. Above ground varies. So anywhere where that difference is big enough is a good candidate for geothermal energy.
Iceland: Good candidate. Warm underground, cold above ground.
Hawaii: Only an okay candidate. Warm above ground, very freaking hot in certain spots underground.
Why? Because I doubt that you are intimately familiar with the underlying technology of your car. The electronic control systems, the fuel delivery system, the air delivery system, the exhaust, etc...
Do you honestly know the composition of all of the catalitic converters on your car and the temperatures they require to opperate correctly and the exact chemical reactions they produce to reduce your car's emissions? Do you know the composition of your engine block, it's rate of expansion, it's ability to transfer heat? Do you know the displacement of your heads, the valve presure, the oil gally routes? etc...
I am a poor example, as I have done much work for many automotive manufacturers, so yes, I have done much work on automobiles and know them quite well.;)
As for the rest of your diatribe there, involving the heat transfer and composition and all that, knowing specific facts is not particularly useful, however knowing that these things occur is quite handy. Knowing that heat makes metal expand, for example, is a useful fact in and of itself, even if you don't know exactly how much a specific piece of metal expands.
And to my point, does knowing any of that make you a better driver?
Yes, it absolutely does.
More to the point, it makes you a more knowledgeable human being, and makes you a better person overall, in everything you do. You never know how the facts will come together, and so a general knowledge of everything is very handy to have.
As for the GC issue. So long as a developer understands scope, and the basics of how memory works (this is the heap, this is the stack) then they are perfectly capable of making such a decision.
But will that decision be a good one or a bad one? Anybody can be lucky. A wider and deeper knowledge of the subject matter could lead one to a better decision.
Just as knowing the simple basics of how a car works allows a person to make decisions about their means of transportation, even if they can't tell a wankle from a otto.
There are a couple of smaller scale geothermal plants there in Hawaii. The problem is how do you tap that power?
You cannot control lava/magma, as the stuff melts everything. Plus, anywhere near the volcano is incredibly unstable and unsafe. So, you have to get at the heat indirectly, and from a good distance. You have to tap the inherent heat of the island itself, basically. All that lava heats up the entire underground area quite well.
Current way they're doing it is to drill deep holes, which essentially become wells. Go deep enough, the water table spills down the hole, and gets closer to the underground heat sources. Water heats up, comes out as steam, and you use the steam to turn a generator. Done.
Doesn't scale well, and can't work everywhere. There's other approaches, but the real problem is that to tap the heat, you have to dig down fairly close to it to make it efficient enough to bother with.
I would venture a guess that many of the people who have contributed code to the/. code base do not know how garbage collection works.
Hell, I have no doubt of THAT. Have you ever looked at the monstrosity that is the Slash code?
Is it good to know? Sure. But it will not make them a better application developer....The tools already exist, use them.
Without knowing how it works, you have no way to gauge whether it is the correct tool to use or not.
Knowing the right way to do things makes you better at anything, programming included. It's not about creating the tools from scratch or even needing to do so, it's about knowing how things work in order to choose wisely.
Nonsense. There is no technical reason that a subset of the English language cannot be compiled directly to the X86 either, but that doesn't mean that knowing English makes you a programmer or makes you understand how the things work.
C is closer to the metal than Java is, for anything that currently runs Java. When you understand C, you have a better understanding of the underlying architecture. When you understand Java, you don't.
Is it good to understand how garbage collection works? Sure. Is it great to have the knowledge of how compilers work? absolutely! Will either make you a better developer in the vast majority of software development positions in the world? nope.
Wow. Okay, we're just going to have to agree to disagree on this one, because that is by far one of the stupidest things I've ever read.
If you don't know how garbage collection and compilers work, then IMO, you are not a Programmer. You're only a code-monkey at best, somebody who can bang rocks together and can make things happen, but is incapable of anything higher-level than that. One of those useless management types, at best.
Magic. How is it attached? What type of model does it use to interact? And most importantly, who cares?
How it is attached is explained by showing the code how it is attached, and the way memory works, and so forth. It's all easily understood, and something that CS students will, at some point, need to understand.
As for who cares, well, a CS student should care, and a CS teacher should care that his students know. It's a fundamental piece of computer science to understand how the fucking things work, don't you think?
Again, magic. System.out is a stream object that by default prints to the console. In either case the cout function and the System.out namespace are functionally identical for our intended use at this point.
False, because the "console" is not defined except in the context of a Virtual Machine that is outside the scope of the Java language itself.
In Java, you cannot explain the console without going outside the language and into the Virtual Machine itself, because that machine is all there is. The "System" namespace is defined by the particular JVM implementation, it doesn't exist outside of that particular JVM implementation.
In C++, you can delve deeper into C and memory and pointers and such, and explain how the console is hooked up, without referring to the specifics of the particular machine. Yes, you can then go even further and explain assembly and machine language and down to the wiring that hooks up the bloody screen if you want, but again, why?
Which requires the explaination of stream opperators, functions, and inputs..Println requires the explaination of functions and inputs. IMO it is much easier to explain how System.out.PrintLn works because there is less technicalities exposed.
Those technicalities are what you're trying to teach. Or you should be, anyway.
The user needs to understand...
Your argument only makes any sense if you define "user". Because the "user" I'm thinking of is a Programmer. And IMO yes, a Programmer does need to know low-level details about the architecture he's working on. Because when it all goes wrong, then he'll have no fucking idea why unless he understands the details.
Your way does not produce programmers. It produces script-kiddies.
Slashdot Mirror
Not sure what you're talking about with having to update WP every week. The releases tend to be on a 2 or 3 month cycle. There hasn't been a security related push-it-out-now type of release for quite a while.
Sounds like you need to get some actual programmers instead of script kiddies. PHP is an okay language, but it is very easy to learn, so a lot of "new" programmers don't really have the background necessary to use it properly.
As with any programming language, it is possible to shoot yourself in the foot with it.
PHP's mysqli supports parameterized queries just fine.
Admittedly, old versions of PHP didn't have this stuff, but seriously, PHP 5 has been around for several years. Why people haven't switched yet is beyond me.
+1 for use of frameworks.
I'm not big on CakePHP though. Strikes me as confusing. I like the more minimalist Zend Framework for my day to day stuff.
It's a conundrum indeed. Trying to convince web hosts to support PHP 5 has been an uphill battle for years and years, and major software like WordPress won't move past PHP 4 compatibility because some web hosts still don't support it.
We really need to get rid of PHP 4 everywhere. It would help a lot with this sort of thing.
Bah. Nevermind. Hulu broke it again just this morning. It was working last night.
That has been fixed. Check the SVN Repo.
But the load (device) cannot "detect" available current except by trying to draw it and seeing if it gets it.
Correct, that's exactly how it works. Do you consider this an invalid use of the word "detect" or something?
Seriously, just because you don't understand what I'm writing doesn't mean it's wrong.
Hulu provides 720p versions of some of their content. It looked pretty good too, over XBMC.
You don't (and can't) "detect" power on a line, nor can a hub "throw" power at them.
Yes, actually, you can.
http://en.wikipedia.org/wiki/Current_limiting
Most USB devices I've seen will charge whenever they detect enough power on the line to allow them to do it. Like anything coming at them higher than 100mA triggers them into charge mode. This is because many self-powered hubs will throw 500mA at everything regardless of enumeration, so charging on-demand makes more sense. Of course, the driver is needed for a machine to kick out more than 100mA on a port, but not all ports require that, so it's best to charge whenever you can.
Your monitor has a self-powered USB hub built into it, and the phone is designed to charge whenever it has enough power coming to it. The monitor gives it that much, so it charges, no drivers needed.
A USB port on the computer acts differently than a port on a hub.
I take it this means that if I have a USB hub then my cell phone is always on low power charge mode. Otherwise I don't see how a computer could decide how much current to supply when multiple devices are attached in parallel via a hub.
USB hubs are more than mere wiring, they have to have some minor amount of intelligence. There's two basic kinds of hubs: bus-powered and self-powered. Self-powered hubs have a separate power source (wall outlet, etc) and are allowed to provide up to 500 mA to devices connecting to them, which is the same as the high-power mode for normal USB ports. This allows those devices to charge. Bus-powered hubs can't do this, they're basically limited to the amount of power they get from the USB port itself.
A second question is, why don't devices supply their own drivers when you plug them in?
Because that's not possible in the USB specification. The "no-driver" devices really use a default set of drivers that have their characteristics predefined in the USB specs.
Also, it's a bit of a security risk for a device to be able to send executable code to the PC and actually have it get executed.
Ok, I have to ask, I keep seeing replies that boil down to "that's what backups are for" in response to key loss issues.
I am wondering how a backup helps if you lose the key.
Umm... You keep a backup of the key itself. That way, when you lose the key, you have it somewhere else safe and secure.
Modern encryption systems generally use a sort of dual layer method of encryption. First, you have the main key, which encrypts your data itself. This key is usually rather large, because a short key is pointless when you're encrypting a LOT of data. However, this key is too large to remember, so you keep that key somewhere else.
Naturally, having that key stored is not safe, so you encrypt it as well, using some other encryption method, and which you secure with a more common means of securing things, like a password. This is your "keyring". Since the keyring is small, it doesn't matter that the password used to secure it is small(ish) too.
Now, if you keep a backup of the unencrypted (or encrypted with a known password that you won't forget) keyring in a safe and secure place, then losing your password to your normal keyring is not a disaster. Just get your backup keyring and use it to access the data.
More like,
"Argh, I lost my key! I lost all those files that we need to get the government off our backs, and all our customer lists, and everything! Shit! We just went out of business!".
Ever heard of a backup? If you don't have backups, then what happens when your hard drives fail?
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on.
What kind of freakin' "bug" takes a bloody week to work on?
PROTIP: Start your task by breaking big bugs into smaller bugs. Seriously, use that bug tracker to full advantage. As you figure out the issue, make new bug reports for each of the (small) pieces of the problem. Then put in the original bug that it has been subdivided into bug A, B, C, etc. Then start working on each one of those, closing them as you go.
Advantages to this:
a) In a multi-developer environment, one of the other devs might come along and fix one of the pieces for you, closing it in the process. Less work for you is a good thing.
b) If your bugtracker is worth a damn, then you'll be able to see the status of the sub-bugs on the original report, and when they're all closed, you can write "fixed" and get on with your life.
c) Dependencies won't stop you dead in the water, you'll be able to keep tracking what you're doing and when.
d) Management number inflation. We fixed X bugs this week!
Bug trackers work great for small problems. And all large problems are just a series of small problems. :)
No. Newegg caved. Amazon, on the other hand, is still suing New York state over it, IIRC.
RSA encryption: c = m^e mod n.
It really is something a 5th grader could write. The security is in the selection of e and n (and d, for decryption).
But 89% of the houses in Iceland are heated with geothermal energy (http://iceland.ednet.ns.ca/schedule.htm).
Yes, because Iceland is a lot colder above the ground than Hawaii is. It's all about temperature difference.
Underground is pretty warm, everywhere on the planet. Above ground varies. So anywhere where that difference is big enough is a good candidate for geothermal energy.
Iceland: Good candidate. Warm underground, cold above ground.
Hawaii: Only an okay candidate. Warm above ground, very freaking hot in certain spots underground.
Why? Because I doubt that you are intimately familiar with the underlying technology of your car. The electronic control systems, the fuel delivery system, the air delivery system, the exhaust, etc...
Do you honestly know the composition of all of the catalitic converters on your car and the temperatures they require to opperate correctly and the exact chemical reactions they produce to reduce your car's emissions? Do you know the composition of your engine block, it's rate of expansion, it's ability to transfer heat? Do you know the displacement of your heads, the valve presure, the oil gally routes? etc...
I am a poor example, as I have done much work for many automotive manufacturers, so yes, I have done much work on automobiles and know them quite well. ;)
As for the rest of your diatribe there, involving the heat transfer and composition and all that, knowing specific facts is not particularly useful, however knowing that these things occur is quite handy. Knowing that heat makes metal expand, for example, is a useful fact in and of itself, even if you don't know exactly how much a specific piece of metal expands.
And to my point, does knowing any of that make you a better driver?
Yes, it absolutely does.
More to the point, it makes you a more knowledgeable human being, and makes you a better person overall, in everything you do. You never know how the facts will come together, and so a general knowledge of everything is very handy to have.
As for the GC issue. So long as a developer understands scope, and the basics of how memory works (this is the heap, this is the stack) then they are perfectly capable of making such a decision.
But will that decision be a good one or a bad one? Anybody can be lucky. A wider and deeper knowledge of the subject matter could lead one to a better decision.
Just as knowing the simple basics of how a car works allows a person to make decisions about their means of transportation, even if they can't tell a wankle from a otto.
Some decisions, yes. Others, no.
There are a couple of smaller scale geothermal plants there in Hawaii. The problem is how do you tap that power?
You cannot control lava/magma, as the stuff melts everything. Plus, anywhere near the volcano is incredibly unstable and unsafe. So, you have to get at the heat indirectly, and from a good distance. You have to tap the inherent heat of the island itself, basically. All that lava heats up the entire underground area quite well.
Current way they're doing it is to drill deep holes, which essentially become wells. Go deep enough, the water table spills down the hole, and gets closer to the underground heat sources. Water heats up, comes out as steam, and you use the steam to turn a generator. Done.
Doesn't scale well, and can't work everywhere. There's other approaches, but the real problem is that to tap the heat, you have to dig down fairly close to it to make it efficient enough to bother with.
I would venture a guess that many of the people who have contributed code to the /. code base do not know how garbage collection works.
Hell, I have no doubt of THAT. Have you ever looked at the monstrosity that is the Slash code?
Is it good to know? Sure. But it will not make them a better application developer. ...The tools already exist, use them.
Without knowing how it works, you have no way to gauge whether it is the correct tool to use or not.
Knowing the right way to do things makes you better at anything, programming included. It's not about creating the tools from scratch or even needing to do so, it's about knowing how things work in order to choose wisely.
Nonsense. There is no technical reason that a subset of the English language cannot be compiled directly to the X86 either, but that doesn't mean that knowing English makes you a programmer or makes you understand how the things work.
C is closer to the metal than Java is, for anything that currently runs Java. When you understand C, you have a better understanding of the underlying architecture. When you understand Java, you don't.
Is it good to understand how garbage collection works? Sure. Is it great to have the knowledge of how compilers work? absolutely! Will either make you a better developer in the vast majority of software development positions in the world? nope.
Wow. Okay, we're just going to have to agree to disagree on this one, because that is by far one of the stupidest things I've ever read.
If you don't know how garbage collection and compilers work, then IMO, you are not a Programmer. You're only a code-monkey at best, somebody who can bang rocks together and can make things happen, but is incapable of anything higher-level than that. One of those useless management types, at best.
Magic. How is it attached? What type of model does it use to interact? And most importantly, who cares?
How it is attached is explained by showing the code how it is attached, and the way memory works, and so forth. It's all easily understood, and something that CS students will, at some point, need to understand.
As for who cares, well, a CS student should care, and a CS teacher should care that his students know. It's a fundamental piece of computer science to understand how the fucking things work, don't you think?
Again, magic. System.out is a stream object that by default prints to the console. In either case the cout function and the System.out namespace are functionally identical for our intended use at this point.
False, because the "console" is not defined except in the context of a Virtual Machine that is outside the scope of the Java language itself.
In Java, you cannot explain the console without going outside the language and into the Virtual Machine itself, because that machine is all there is. The "System" namespace is defined by the particular JVM implementation, it doesn't exist outside of that particular JVM implementation.
In C++, you can delve deeper into C and memory and pointers and such, and explain how the console is hooked up, without referring to the specifics of the particular machine. Yes, you can then go even further and explain assembly and machine language and down to the wiring that hooks up the bloody screen if you want, but again, why?
Which requires the explaination of stream opperators, functions, and inputs. .Println requires the explaination of functions and inputs. IMO it is much easier to explain how System.out.PrintLn works because there is less technicalities exposed.
Those technicalities are what you're trying to teach. Or you should be, anyway.
The user needs to understand...
Your argument only makes any sense if you define "user". Because the "user" I'm thinking of is a Programmer. And IMO yes, a Programmer does need to know low-level details about the architecture he's working on. Because when it all goes wrong, then he'll have no fucking idea why unless he understands the details.
Your way does not produce programmers. It produces script-kiddies.