My other pet peeve phrase is "Absence of evidence is not evidence of absence" which is misleading at best. A more correct statement would be "Absence of evidence before reasonable investigation is not evidence of absence". Once a reasonable search for evidence has been made, especially if said evidence should be reasonably detectable by currently available methods, then an absence of evidence IS evidence of absence.
This only works if it is understood by both sides of the debate what the evidence looks like and that it's possible for it to exist. People tend to use this phrase when talking about atheism / agnosticism, because some people state "There's no evidence that there's a God" to imply "Therefore there is no God". The problem with this is that it's logical positivism, which in my view is a fallacy. In that particular debate, no-one can define what evidence for or against the existence of a God would look like, hence the only evidence-based conclusion is to say "I don't know". Absence of evidence is most certainly not evidence of absence.
But I take your point, for most topics, if you look hard enough and at least know what you're looking for, you'll find evidence either for, or against your hypothesis. Otherwise it's a crap hypothesis.
Re:Why the need to 'discover' the elements?
on
Element 114 Verified
·
· Score: 3, Funny
You mean, every IPv4 application you can conceive of....?
Don't lets limit the rest of the world because you're too stupid to realise that NAT and IPv4 causes huge problems on a day to day basis for a lot of people.
As I commented to a different poster, you're incorrect. You need a license if you watch or record TV as it's broadcast. From the TV licensing site:
You must be covered by a valid TV Licence if you watch or record television programmes as they're being shown on TV. It makes no difference what equipment you use - whether itâ(TM)s a laptop, PC, mobile phone, digital box, DVD recorder or a TV set - you still need a licence.
Wrong. You have to pay if you watch live TV. Owning a TV has nothing to do with it.
You must be covered by a valid TV Licence if you watch or record television programmes as they're being shown on TV. It makes no difference what equipment you use - whether itâ(TM)s a laptop, PC, mobile phone, digital box, DVD recorder or a TV set - you still need a licence.
GP's general point is right, but he was wrong to suggest that it 'can be cracked'.
The general point is that if someone wants your data badly enough, they'll get your data. Whether it's worth it for what it'll cost is a completely different question. Using a BB over an iPhone just closes off one of the many vulnerabilities that exist when humans try to handle confidential information.
Think it's Cain and Able that can work out successive securID values based on 3 or 4 sequential correct values. What we really need is challenge response, done properly.
It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
No, it's about having less issues by using modern tools, rather than trying to find who's to blame.
If HTML/JS/CSS/HTTP could be redesigned today, do you think that the way a browser manage cookies, XHR requests and sandboxing in general would be the same as it is today? Do you think that the SMTP protocol that was good enough 30 years ago is not a big pile of crap nowadays, even, just like ORMs, their content is now shown in webmails? SQL is just like SMTP. Or the FAT filesystem. An old thing. There are worthy proposals and even working products that could superscede them, but because of legacy applications and people who want to stick with the same technologies till the end of the universe, these old things remain. They just get bloated with new extensions instead, in order to keep up with mandatory requirements.
Of course, if you were designing something today to do the job of 'relational database', you'd probably get something different from SQL. That doesn't change the fact that today, the SQL / RDBMS combo is the best tool for solving a lot of problems. That doesn't mean that people won't try and use it improperly, but those people are idiots. People don't stick with SQL because it's old, they stick with SQL because it gets the job done, and in the hands of someone who knows what they're doing, it gets the job done well as long as the job is a sensible one for which a relational database makes sense. Like storing millions of customer records.
they exist because of the crappy programmer who doesn't know how to use the database
"Our GUI _is_ user-friendly! Customers just don't understand how to use it because _they_ are clueless!"
"hey, and there's a workaround to make them use it properly. Just tell them to top an GUIORM (pick one out of hundreds), an extra layer that hides our wonderful GUI and shows another GUI that's closer to reality, and transparently translates events both way, while introducing some new limitations (thinking about that other ORM that has no way to issue OR-like statements) and some grain of extra sluginess!"
Typically, you don't have any control over how smart your users are, so you make GUIs nice and simple to use. However, the analogy doesn't hold for developer tools and technologies. You do have control over how smart your developers are, and if they're stupid to use SQL properly, they're idiots. It's not the fault of the technology that muppets use it improperly.
SQL injection vulnerabilities don't exist because of the database, they exist because of the crappy programmer who doesn't know how to use the database being let loose writing production code. It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
And there's nothing wrong with SQL. There's a lot wrong with people who think SQL will solve every single problem under the sun. Unfortunately, those people seem to be employed writing 3rd-party abstraction layers and ORMs.
I had the same issue. Features are great. Reliability sucks.
I guess if you're enterprisy, you could deploy the servers as resiliant pairs (I believe it supports that), but I couldn't afford that for my smallish system.
I had a horrible experience trying to get zabbix to work. Initially, it works great and looks useful and pretty. But then the zabbix-server process just stops reporting on stuff for no apparent reason at all. The processes are still there, they're just not updating anything. The log files are also giving no indication as to what's going on. Worst of all, you have no way of knowing when or why it stops working, so I ended up writing a cron job to restart it every 6 hours. Then I ditched it.
It's got great functionality, but crappy reliability. And I like my monitoring systems to be reliable.
Mission critical systems usually have redundant systems they can fail over to in almost real-time. Patch your hot-standby (after testing of course), fail over to that, then patch the other side.
Did they solve the issue of different versions not being able to talk to each other? I remember playing with it trying to sync cygwin with a debian box, and it just complained that the versions were different...
Ah, interesting, this makes more sense. Yes, I think I'd agree with you that the BB model works best with huge deployments and probably is less suitable to the small / medium size, mainly for cost reasons.
It tends to be the really big shops that (a) have the cash and (b) draw the attention of the regulators meaning they have to have devices and systems that follow the regulations. I believe, but am not authoritative on this, that the BB system is the only mobile email device that's certified for use under certain regulations. I work in financial services and know that there's a whole bunch of law that intersects with IT there.
But absolutely. If you've got a small shop, winmo is probably the best bang / buck from what I can see. Doesn't make BB a bad platform though, just makes it the wrong tool for that particular job.
Slashdot Mirror
Now is the month of May-ing, and merry lads are playing?
Fa la la la la la la, Fa la la la la la la?
?
Anyone got any idea on how to boot the ISO from a USB drive? I don't have a CD/DVD drive :(
My other pet peeve phrase is "Absence of evidence is not evidence of absence" which is misleading at best. A more correct statement would be "Absence of evidence before reasonable investigation is not evidence of absence". Once a reasonable search for evidence has been made, especially if said evidence should be reasonably detectable by currently available methods, then an absence of evidence IS evidence of absence.
This only works if it is understood by both sides of the debate what the evidence looks like and that it's possible for it to exist. People tend to use this phrase when talking about atheism / agnosticism, because some people state "There's no evidence that there's a God" to imply "Therefore there is no God". The problem with this is that it's logical positivism, which in my view is a fallacy. In that particular debate, no-one can define what evidence for or against the existence of a God would look like, hence the only evidence-based conclusion is to say "I don't know". Absence of evidence is most certainly not evidence of absence.
But I take your point, for most topics, if you look hard enough and at least know what you're looking for, you'll find evidence either for, or against your hypothesis. Otherwise it's a crap hypothesis.
You failed chemistry, didn't you?
What's IPv6 got to do with information security?
You mean, every IPv4 application you can conceive of....?
Don't lets limit the rest of the world because you're too stupid to realise that NAT and IPv4 causes huge problems on a day to day basis for a lot of people.
TV License site
GP's general point is right, but he was wrong to suggest that it 'can be cracked'.
The general point is that if someone wants your data badly enough, they'll get your data. Whether it's worth it for what it'll cost is a completely different question. Using a BB over an iPhone just closes off one of the many vulnerabilities that exist when humans try to handle confidential information.
Novell Response
Novell points out that the Judge affirmed the payment ($3million) SCO was ordered to make to Novell, so there's hope yet.
Think it's Cain and Able that can work out successive securID values based on 3 or 4 sequential correct values. What we really need is challenge response, done properly.
They probably felt the need to do this given that all of Hull ISPs are crap.
No. The taxpayers will laugh at him.
It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
No, it's about having less issues by using modern tools, rather than trying to find who's to blame.
If HTML/JS/CSS/HTTP could be redesigned today, do you think that the way a browser manage cookies, XHR requests and sandboxing in general would be the same as it is today? Do you think that the SMTP protocol that was good enough 30 years ago is not a big pile of crap nowadays, even, just like ORMs, their content is now shown in webmails? SQL is just like SMTP. Or the FAT filesystem. An old thing. There are worthy proposals and even working products that could superscede them, but because of legacy applications and people who want to stick with the same technologies till the end of the universe, these old things remain. They just get bloated with new extensions instead, in order to keep up with mandatory requirements.
Of course, if you were designing something today to do the job of 'relational database', you'd probably get something different from SQL. That doesn't change the fact that today, the SQL / RDBMS combo is the best tool for solving a lot of problems. That doesn't mean that people won't try and use it improperly, but those people are idiots. People don't stick with SQL because it's old, they stick with SQL because it gets the job done, and in the hands of someone who knows what they're doing, it gets the job done well as long as the job is a sensible one for which a relational database makes sense. Like storing millions of customer records.
they exist because of the crappy programmer who doesn't know how to use the database
"Our GUI _is_ user-friendly! Customers just don't understand how to use it because _they_ are clueless!"
"hey, and there's a workaround to make them use it properly. Just tell them to top an GUIORM (pick one out of hundreds), an extra layer that hides our wonderful GUI and shows another GUI that's closer to reality, and transparently translates events both way, while introducing some new limitations (thinking about that other ORM that has no way to issue OR-like statements) and some grain of extra sluginess!"
Typically, you don't have any control over how smart your users are, so you make GUIs nice and simple to use. However, the analogy doesn't hold for developer tools and technologies. You do have control over how smart your developers are, and if they're stupid to use SQL properly, they're idiots. It's not the fault of the technology that muppets use it improperly.
SQL injection vulnerabilities don't exist because of the database, they exist because of the crappy programmer who doesn't know how to use the database being let loose writing production code. It's a bit like saying "Lets blame the internet for Cross-site scripting vulnerabilities!".
And there's nothing wrong with SQL. There's a lot wrong with people who think SQL will solve every single problem under the sun. Unfortunately, those people seem to be employed writing 3rd-party abstraction layers and ORMs.
I had the same issue. Features are great. Reliability sucks.
I guess if you're enterprisy, you could deploy the servers as resiliant pairs (I believe it supports that), but I couldn't afford that for my smallish system.
Oh god - zabbix - nooooooo.
I had a horrible experience trying to get zabbix to work. Initially, it works great and looks useful and pretty. But then the zabbix-server process just stops reporting on stuff for no apparent reason at all. The processes are still there, they're just not updating anything. The log files are also giving no indication as to what's going on. Worst of all, you have no way of knowing when or why it stops working, so I ended up writing a cron job to restart it every 6 hours. Then I ditched it.
It's got great functionality, but crappy reliability. And I like my monitoring systems to be reliable.
Mission critical systems usually have redundant systems they can fail over to in almost real-time. Patch your hot-standby (after testing of course), fail over to that, then patch the other side.
It's how we like to deliberately confuse foreigners :)
'Perpetual motion' is a bad term to use, because perpetual motion is guaranteed by Newton's first law.
How many do they have?
Link says £60 pm contract, not £30 - unless I'm blind?
Did they solve the issue of different versions not being able to talk to each other? I remember playing with it trying to sync cygwin with a debian box, and it just complained that the versions were different...
What if your house burns down?
Ah, interesting, this makes more sense. Yes, I think I'd agree with you that the BB model works best with huge deployments and probably is less suitable to the small / medium size, mainly for cost reasons.
It tends to be the really big shops that (a) have the cash and (b) draw the attention of the regulators meaning they have to have devices and systems that follow the regulations. I believe, but am not authoritative on this, that the BB system is the only mobile email device that's certified for use under certain regulations. I work in financial services and know that there's a whole bunch of law that intersects with IT there.
But absolutely. If you've got a small shop, winmo is probably the best bang / buck from what I can see. Doesn't make BB a bad platform though, just makes it the wrong tool for that particular job.