I live on a road in a small town in ontario. The name of the road changed a year ago (They renamed most roads in town). The town itself can't even keep things straight, keep sending hydro bills to the old named address, and all the other big online map services list it wrong, if at all.
A solution with your requirements already exists and has been in use for thousands of years.
The trick is all in learning the technique required to stream all of that data through your tools and onto a chunk of stone with reasonable throughput.
No, that is absolutely NOT tiger's eye. What you are talking about does indeed exist, but it is entirely wrong to label it tigers eye.
Tiger's eye and Bird's eye both come from a particular type of diseased maple trees. The difference between Tiger's and Bird's eye is whether wood is cut across the grain, or with the grain. (Across giving Bird's eye, with giving Tiger's eye)
A little over the top sure, but mods, please have a heart. The guy at least managed to use both 'effects' and 'affects' properly, and in the same sentence no less. That's got to be a 1 in a million occurance around here;)
And who has the rights to create that new user that has sufficient rights to get at all of that critical data that the guy who just died left behind?
I see a bit of a chicken or an egg thing here.
There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.
So, no superuser. This means there must be some way to create an account with sufficient rights to recover lost data, which kinda undermines the security in the first place.
wtf? Where did that come from. You sure did take that wrong.
My point was that the problem is with ActiveX itself, not with MFC _or_ ATL. There's no point arguing the various tool boxes and languages that can be used to build ActiveX controls.
As for the rest of that large amount of energy directed at defaming me, really, what did I do to you to deserve that?
I certainly wasn't arguing the validity of ActiveX, bash away. I was arguing the credibility of the basher to do said bashing. The only argument put forth was the obvious security design flaw, which has been there since it's inception, and has already been beaten to death, and then some, many times.
I have my own thoughts on ActiveX which are outside of this thread really, but short and simple so voila:
Don't use it on the internet, it's not safe, period. Use it where it provides improved functionality for web-based intranet applications on private networks.
When you do use it, I don't care what language or technology you implement it in, as long as it meets the specs!
Sorry if that was less than obvious, but my point being that _what_ you code ActiveX in has no bearing on this whatsoever with regards to the underlying security issues in ActiveX. The fact that Hook chooses to argue the merits of ATL vs MFC, especially on an 'I don't use that one' statement, within the context of the security issue basically proves that he has no business commenting on the subject at all.
I'm really finding it hard to give this guy any credibility at all. First off, none of the issues he cites are in any way new, these problems are old hat. But then to get all nit picky about the details of these issues by professing things like 'I don't use ATL, I write my ActiveX in MFC.' Shit, I don't even know where to begin. The guys just now digging into ActiveX and has decided flat out that MFC is the way to do it? Strike 1, and strike 2. Not immediately dropping it and moving on to something more suitable, you're out man.
I'm dumbfounded by this.
And editors, you're not helping any by posting stories like this. It's all too obvious that this article was posted because it fits the anti-MS slant quite well. That's all fine and good, but this article brings absolutely NOTHING to the table except another excuse to bash MS and an OLD MS technology.
I'm getting a wee bit tired of how critical some people are being of this mission, especially when they obviously have absolutely NO understanding of it.
Pray tell, how would one illuminate the surface from 90km up? Oh, right, that wouldn't really work until it was quite close to the surface. Gee, they thought of that, and did have a large light they used at the appropriate point.
More battery power ehh? Well, it was designed to last for 20 minutes at least. Lasted for the full 2 hours that cassini was within communication sight. What would more do? Wait another month or more until cassini is back in view, surviving with power all that time at those temperatures? Or should they have 'stopped space' for long enough to ensure the probe could get as much information as _you_ want to cassini without worrying about it moving out of range.
Know what happens with your resume when it's submitted digitally? A HR person prints off a bunch of copies. One's usually stored in permament records, the others passed out to those doing the hiring. Chance of someone that matters ever seeing it in a digital format? Fat.
The paperless office is a myth, and the paperless hiring process is just pure fantasy.
Is bugzilla the simplest solution? (And I'm talking about installing it on linux, not the problematic windows installation)
Is bugzilla the right solution?
Your post is heavily assuming that Bugzilla is the right choice, actually, it's inferring that Bugzilla is the _only_ reasonable choice and that anyone that doesn't agree is a bigot and ignorant. Harsh. Your suggested course of action wouldn't get many people very far in this world. Don't like my way? then f'u. How's that supposed to help?
Anyways, my point is it's not as cut and dry as that.
Aside from that, I've now used a few different bug tracking systems. IMHO, Bugzilla is not the best, though it may be right for certain jobs. For a lot of projects, it's just confusing and overkill. Regardless, and this is the key point, linux vs windows has NO place in this argument. We're discussing bug tracking software. Choose your software based on your needs, and then deploy as appropriate. If the best choice ends up being Bugzilla on linux, then so be it. Notice that the decision here would be not choosing linux, but rather choosing the appropriate software.
We just went through this recently at my company. Our first though was Bugzilla, of course. But after looking into actually deploying it we realized it wasn't going to be that easy. So before we buried ourselves, we looked around to make sure Bugzilla was actually the right choice for us.
Turns out it wasn't.
We found Atlassian's JIRA. Installs like a breeze, easy to manage, no headaches, even actively tied into Atlassian's JIRA bugtracking system for itself! (And it works, seen bugs that we have submitted fixed in short order!)
We're not a really big shop, so I can't speak too much from the large scale deployment end, but aside from that this was a fantastic choice for us and I highly recommend it. (I am in no way affiliated with Atlassian or JIRA)
Because the difference with respect to what we are currently discussing is just a matter of scale.
Matter in point, the quad web server I mentioned above is actually a member of a 10 server cluster. As a whole, I'd consider that big iron, and as such I was talking about big iron;)
Or rather maybe the problem is that it's actually not that black and white a problem. It depends on what you are running for software.
If you're running a single processor intensive app that isn't threaded, the faster single processor machine will win out, hands down.
If you're running multiple apps, and/or apps that are threaded properly, than the multiproc should be able to at _least_ keep up with single proc machine.
I develop on a 2x800mhz PIII I've had now for over 3 years. The computers we've been buying recently for new guys are P4 ~3ghz. We also have older quad rack mount web servers we use for our external sites, and newer internal single proc machines running much faster single procs. Hands down, without a doubt, in this application the multiproc machines _kill_ the newer ones when under load.
Um, have you had your legitimately bought copy of HL2 banned? IE have they banned your key? That is what was asked, not whether you were having issues in general, and not whether you thought steam was spywear or anything like that (which there is absolutely ZERO proof that it is anyways).
As the guy you replied to meant, STFU unless you have something _objective_ to say.
That'd be fine if almost all last mile connections for broadband to the home weren't piggybacking on existing networks. (Cable/Phone) There is no last mile roleout required for broadband so your point is moot.
You didn't read the post you just responded to. He wasn't suggesting that you turn steam off, disconnect from the internet, and start up again to save time.
What he said was: Do that and the time to load will BE THE SAME.
His point being, quite obviously stated as well, that it is NOT steam that is slowing you down. His point is that it is the game itself that is taking time to load.
Slashdot Mirror
I live on a road in a small town in ontario. The name of the road changed a year ago (They renamed most roads in town). The town itself can't even keep things straight, keep sending hydro bills to the old named address, and all the other big online map services list it wrong, if at all.
Google maps has all the changes bang on.
A solution with your requirements already exists and has been in use for thousands of years.
The trick is all in learning the technique required to stream all of that data through your tools and onto a chunk of stone with reasonable throughput.
No, that is absolutely NOT tiger's eye. What you are talking about does indeed exist, but it is entirely wrong to label it tigers eye.
Tiger's eye and Bird's eye both come from a particular type of diseased maple trees. The difference between Tiger's and Bird's eye is whether wood is cut across the grain, or with the grain. (Across giving Bird's eye, with giving Tiger's eye)
A little over the top sure, but mods, please have a heart. The guy at least managed to use both 'effects' and 'affects' properly, and in the same sentence no less. That's got to be a 1 in a million occurance around here ;)
And who has the rights to create that new user that has sufficient rights to get at all of that critical data that the guy who just died left behind?
;)
I see a bit of a chicken or an egg thing here.
There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.
So, no superuser. This means there must be some way to create an account with sufficient rights to recover lost data, which kinda undermines the security in the first place.
Hope I'm missing something
wtf? Where did that come from. You sure did take that wrong.
My point was that the problem is with ActiveX itself, not with MFC _or_ ATL. There's no point arguing the various tool boxes and languages that can be used to build ActiveX controls.
As for the rest of that large amount of energy directed at defaming me, really, what did I do to you to deserve that?
I certainly wasn't arguing the validity of ActiveX, bash away. I was arguing the credibility of the basher to do said bashing. The only argument put forth was the obvious security design flaw, which has been there since it's inception, and has already been beaten to death, and then some, many times.
I have my own thoughts on ActiveX which are outside of this thread really, but short and simple so voila:
Don't use it on the internet, it's not safe, period.
Use it where it provides improved functionality for web-based intranet applications on private networks.
When you do use it, I don't care what language or technology you implement it in, as long as it meets the specs!
Sorry if that was less than obvious, but my point being that _what_ you code ActiveX in has no bearing on this whatsoever with regards to the underlying security issues in ActiveX. The fact that Hook chooses to argue the merits of ATL vs MFC, especially on an 'I don't use that one' statement, within the context of the security issue basically proves that he has no business commenting on the subject at all.
I'm really finding it hard to give this guy any credibility at all. First off, none of the issues he cites are in any way new, these problems are old hat. But then to get all nit picky about the details of these issues by professing things like 'I don't use ATL, I write my ActiveX in MFC.' Shit, I don't even know where to begin. The guys just now digging into ActiveX and has decided flat out that MFC is the way to do it? Strike 1, and strike 2. Not immediately dropping it and moving on to something more suitable, you're out man.
I'm dumbfounded by this.
And editors, you're not helping any by posting stories like this. It's all too obvious that this article was posted because it fits the anti-MS slant quite well. That's all fine and good, but this article brings absolutely NOTHING to the table except another excuse to bash MS and an OLD MS technology.
Fine, you go do better then.
I'm getting a wee bit tired of how critical some people are being of this mission, especially when they obviously have absolutely NO understanding of it.
Pray tell, how would one illuminate the surface from 90km up? Oh, right, that wouldn't really work until it was quite close to the surface. Gee, they thought of that, and did have a large light they used at the appropriate point.
More battery power ehh? Well, it was designed to last for 20 minutes at least. Lasted for the full 2 hours that cassini was within communication sight. What would more do? Wait another month or more until cassini is back in view, surviving with power all that time at those temperatures? Or should they have 'stopped space' for long enough to ensure the probe could get as much information as _you_ want to cassini without worrying about it moving out of range.
Cheekyboy is right.
Know what happens with your resume when it's submitted digitally? A HR person prints off a bunch of copies. One's usually stored in permament records, the others passed out to those doing the hiring. Chance of someone that matters ever seeing it in a digital format? Fat.
The paperless office is a myth, and the paperless hiring process is just pure fantasy.
My appologies, good cite thank you. Learn something new every day.
Got any statistics to back that up? I'd really like to take a crack at them if you do, but as is what can one say to refute that?
Wasn't legal to posess either. It was exactly the same as marijuana laws are now. Not illegal to partake in, but illegal to have, buy or sell.
So yes, it was legal to drink, but it's hard to drink something you can't posess.
Yes, it certainly doesn't do a very good job of propagating ignorance does it?
Point: Do you really think that this ad is targeted at those people that don't know or care what a web browser even is? How would one do that?
An audio player that meets your needs, but now that's not good enough. You want one that _only_ plays ogg?
I'm a _huge_ fan and supporter of ogg, and you're really not helping any, please stop now.
Is bugzilla the simplest solution? (And I'm talking about installing it on linux, not the problematic windows installation)
Is bugzilla the right solution?
Your post is heavily assuming that Bugzilla is the right choice, actually, it's inferring that Bugzilla is the _only_ reasonable choice and that anyone that doesn't agree is a bigot and ignorant. Harsh. Your suggested course of action wouldn't get many people very far in this world. Don't like my way? then f'u. How's that supposed to help?
Anyways, my point is it's not as cut and dry as that.
Aside from that, I've now used a few different bug tracking systems. IMHO, Bugzilla is not the best, though it may be right for certain jobs. For a lot of projects, it's just confusing and overkill. Regardless, and this is the key point, linux vs windows has NO place in this argument. We're discussing bug tracking software. Choose your software based on your needs, and then deploy as appropriate. If the best choice ends up being Bugzilla on linux, then so be it. Notice that the decision here would be not choosing linux, but rather choosing the appropriate software.
We just went through this recently at my company.
Our first though was Bugzilla, of course. But after looking into actually deploying it we realized it wasn't going to be that easy. So before we buried ourselves, we looked around to make sure Bugzilla was actually the right choice for us.
Turns out it wasn't.
We found Atlassian's JIRA. Installs like a breeze, easy to manage, no headaches, even actively tied into Atlassian's JIRA bugtracking system for itself! (And it works, seen bugs that we have submitted fixed in short order!)
We're not a really big shop, so I can't speak too much from the large scale deployment end, but aside from that this was a fantastic choice for us and I highly recommend it. (I am in no way affiliated with Atlassian or JIRA)
Because the difference with respect to what we are currently discussing is just a matter of scale.
;)
Matter in point, the quad web server I mentioned above is actually a member of a 10 server cluster. As a whole, I'd consider that big iron, and as such I was talking about big iron
BS plain and simple.
Or rather maybe the problem is that it's actually not that black and white a problem. It depends on what you are running for software.
If you're running a single processor intensive app that isn't threaded, the faster single processor machine will win out, hands down.
If you're running multiple apps, and/or apps that are threaded properly, than the multiproc should be able to at _least_ keep up with single proc machine.
I develop on a 2x800mhz PIII I've had now for over 3 years. The computers we've been buying recently for new guys are P4 ~3ghz. We also have older quad rack mount web servers we use for our external sites, and newer internal single proc machines running much faster single procs. Hands down, without a doubt, in this application the multiproc machines _kill_ the newer ones when under load.
Um, have you had your legitimately bought copy of HL2 banned? IE have they banned your key?
That is what was asked, not whether you were having issues in general, and not whether you thought steam was spywear or anything like that (which there is absolutely ZERO proof that it is anyways).
As the guy you replied to meant, STFU unless you have something _objective_ to say.
That'd be fine if almost all last mile connections for broadband to the home weren't piggybacking on existing networks. (Cable/Phone) There is no last mile roleout required for broadband so your point is moot.
And who forced this on you?
I'm crying a river, really, I am.
You didn't read the post you just responded to.
He wasn't suggesting that you turn steam off, disconnect from the internet, and start up again to save time.
What he said was: Do that and the time to load will BE THE SAME.
His point being, quite obviously stated as well, that it is NOT steam that is slowing you down. His point is that it is the game itself that is taking time to load.
Yeah, that's nice and unbiased.
Really man, wtf is that?
A Bunch of odds on a bunch of console games, and then there's HL2. Do you see the problem?