That's a rather silly response to someone who basically just made the quite logical, straightforward statement that he switched to folding@home because it has more chance of producing useful results within his lifetime!
Way back in the DOS days, around '91 or so, when polymorphic viruses first became 'popular', I seem to remember there was a polymorphic virus that changed it's signature on each infection to such a degree that each infection only had one byte in common.
Of course this was in the days when viruses were written in assembler, mostly spread by finding other.exe and.com files on your hard disk and infecting them directly, the concept of an e-mail virus wasn't even a silly joke yet, and viruses didn't call system calls in DLLs etc.
Well many of us unfortunately have to use Windows because (a) our work requires it and/or (b) more critically, our clients have Windows, and only know how to use Windows. So you have to develop your products for Windows if you actually want to sell anything:(:(...
Yes, it's actually impossible to be protected against the 'latest virus that just came out', because it's impossible that your AV vendor has protection against a brand new immediately (unless the AV vendor wrote it themselves). There always must be a "window" between time of discovery of a new virus and the time that your AV is updated to protect against it during which you are vulnerable, and this is typically anything from a few hours to a few days.
But just try to explain this logic to the damn "if you run an AV and keep your definitions up to date you'll have no problems" crowd..
I've been in this business for nearly a decade now, and quite frankly, there is ONE MAJOR reason that software still sucks. The majority of programmers are (a) damn lazy and (b) don't think properly about what they're doing. Simple as that.
The point of Hungarian is you don't need to "figure out" what the variable type is. You just look at it and you ALREADY KNOW. There are no better/faster tools than that in existence, nothing beats the speed of interpretation. Mouse float-overs and other such things are helpful, but certainly slower than the 'instant' decoding available from reading a 'Hungarian-compliant' variable name.
Hungarian Notation is not a "Microsoft thing". If you've ever bothered to read the original Charles Simonyi paper, it has nothing to do with Windows, and the original seemed more tailored for e.g. physics concepts than window and process handles. Microsoft later adopted an adapted version of this for their own coding. It's not a "Microsoft thing" or a "Windows thing", sheez, if I had a cent for every time someone repeated that bit of misinformation.
Hmm.. good point. I couldn't be bothered to 'mod my car', and I guess part of the reason is that I just plain hardly ever drive anywhere, except to work and back, a short trip. OTOH I use my computer pretty much all day long, so spending time 'tweaking' it for better performance (e.g. for faster compile times etc) is worthwhile. Maybe if my job required more hours on the road and less behind a computer, I'd care more about optimising the performance of my car.
They should make it less obtrusive, and optional. Say something on the right side of the web page with a link you can click on to speak to a human operator (and perhaps something that indicates if there are any available).
But I guess that's not the point, the point is to be pushy because they probably sell more stuff that way.
So something is acceptable simply because "many companies are doing this?" Jeez, that's pathetic and insulting. Right up there with excuses like "It's company policy...".
Well I'm sure asteroids and the like aren't really scattered uniformly throughout space, many many are formed by processes resulting in 'clusters' of objects (such as Leonids). I would guess, or at least it even seems likely to me, that it would be natural to have some variation then even over longer periods (e.g. months, days, years, decades, centuries) as various bits of various such 'clusters' in the galaxy pass through our solar system. The duration would depend on the nature of the objects (e.g. a long destroyed planet or moon or asteroid (cf. asteroid belt?)), and the speed and distribution of the objects. So if we imagine some event similar to e.g. what created the asteroid belt, but without the objects remaining in orbit around something large but rather simply 'floating off' into space and slowly becoming relatively widely spread out, then those bits and pieces, were they to pass through our solar system, could conceivably create a statistically measurable increase in such 'fireballs' over the course of years or decades. If you've been observing for twenty or thirty years, that is just a 'blink of the eye' on the planet's timescale, such fluctuations probably occur all the time over millenia.
So now you're just saying it's different in OpenGL, aha, you've backed down from your "can't be done" stance. Yes, vertex buffers are different in GL. Shaders are different in GL too, as are a number of things, but you can still do anything you can do in D3D in GL (and yes you need extensions, that's exactly what I said).
"your are mistaking binary compatibility with source compatibility"
Huh? If you have binary compatibility, then all you need are the headers with the definitions and the import libs. AND THESE ARE PROVIDED. FACT, we are still maintaining compiling supporting & updating Direct3D *3* and *5* applications (with DirectSound, DirectPlay, DirectDraw AND Direct3D) using the DirectX9 API. Are you saying I'm imagining it?
Some people like you might view a job as some authoritarian school-like structure where you sit and shuddup and just do what the boss tells you to "'cuz he's the boss". But just be aware NOT everyone sees it that way, some people prefer to work at organizations where their input is valued and they are an active part of a team that works together to achieve something. Just two different approaches.
Look, anything you can do in Direct3D, you can do in OpenGL, but the more advanced features you need to use (usually) vendor-specific extensions to access.
You're wrong about source code compatibility of DirectX too. All DirectX programs are source compatible with older versions. Each release of DirectX includes ALL the older COM objects (with the COM object version numbers attached being part of the object names), complete even with all the old bugs to keep apps working (e.g. upside down textures in very early versions, hehe).
We are maintaining and supporting apps written using DirectX 3, 5, 6 all through to 9, and they compile 100% fine on the latest DirectX SDK. Usually the ONLY thing you need to add to the source to get them to compile is a #define that causes the preprocessor to parse older definitions in header files instead of conflicting newer ones (e.g. "#define DIRECTSOUND_VERSION 0x0600").
If you went and rewrote all that old code because you didn't realise you could just use a couple of #define's here and there in your code, ha, that's pretty sad.
So let him opt-in, and let the rest of us opt-out. And then back that up with legislation and enforcement. Then we have 100% freedom, as we can all decide what we want. Right now we don't have the "freedom" to say 'no' outright to spam.
Tsk, always giving MS the benefit of the doubt. Microsoft has almost ALWAYS "slipped" on major projects in the past, usually be anything up to several years. This is nothing new, and has never implied that they were about to produce a quality product in the past.
Microsoft don't "slip" on deadlines: they deliberately start out providing fake, earlier deadlines to the press. So they'll say for example "next SQL server will be out in 2004". This has two effects: (a) companies that might have been thinking about using the gap to produce a competing system consequently don't, "next great MS version will be out too soon" they say. And (b) clients using an older version that need to upgrade to something 'bigger' think "hey, next great MS version will be out soon enough, let's wait for that rather than switch to Oracle".
Then the deadline approaches and Microsoft says "whoops we're slipping". But too late for the many who've now made the decision, so they just wait out the extra time and stick with MS.
Come on, this is an OLD game from MS. Don't be so naive. Those who don't study history..
The Romans also understood this: http://users.erols.com/mwhite28/us_rome.htm: 'The Empire lasted as long as it did because the Romans weren't idiots. When the governor of Egypt sent Tiberius more taxes than he was supposed to, Tiberius reminded him: "I want my sheep shorn, not shaven."'
Re:Cha ching, reloaded.
on
Gates on Spam
·
· Score: 1
So why bother with the whole client/server computation thing, couldn't the SMTP server just sleep for a few seconds for each mail a client attempts to send? This would have the same "benefit" of delaying the client (i.e. the 'penalty'), except it would be better in several ways: firstly the delay wouldn't depend on the speed of the client's computer, secondly it is more efficient from an energy consumption point of view as the CPU will issue HLTs if idle, as opposed to consuming full power doing some pointless computation?
Straw-man straw-man straw-man... *sigh*, now *that* is tiresome. Yeah, that's the ticket, claim the parent made all sorts of claims that he/she very obviously didn't.
I think the two most common reasons for this sort of disregard for typos etc in business communications, at ANY level (i.e. from top management down), are: (a) not caring, (b) in a hurry. In the first case, you have some people who just don't really care if they have a few mistakes in their typing. In the second case, and I believe likely here, very busy people (such as top management in virtually any company) are too pressed for time to go around proofreading every one of the dozens (or hundreds) of business communications that they must do EVERY DAY. Really, if you spend up to several hours a day just typing email, you just don't have time anymore to proof every last one.
Even less clued up tech guys fall for the FUD:(:(... the other day one of the programmers in our company said something along the lines of 'we can't legally use OpenSource code for our software projects', then implied we'd have to then give our code away or something. So I not only explained the truth to him, but showed him that we've been using some LGPL libraries in our software for years! He was pretty surprised... he had actually used the LGPL libraries indirectly before, without knowing it.
Slashdot Mirror
That's a rather silly response to someone who basically just made the quite logical, straightforward statement that he switched to folding@home because it has more chance of producing useful results within his lifetime!
'PCs are only cheaper (than Macs) if your time has no value'.
Way back in the DOS days, around '91 or so, when polymorphic viruses first became 'popular', I seem to remember there was a polymorphic virus that changed it's signature on each infection to such a degree that each infection only had one byte in common.
Of course this was in the days when viruses were written in assembler, mostly spread by finding other .exe and .com files on your hard disk and infecting them directly, the concept of an e-mail virus wasn't even a silly joke yet, and viruses didn't call system calls in DLLs etc.
Well many of us unfortunately have to use Windows because (a) our work requires it and/or (b) more critically, our clients have Windows, and only know how to use Windows. So you have to develop your products for Windows if you actually want to sell anything :( :( ...
Yes, it's actually impossible to be protected against the 'latest virus that just came out', because it's impossible that your AV vendor has protection against a brand new immediately (unless the AV vendor wrote it themselves). There always must be a "window" between time of discovery of a new virus and the time that your AV is updated to protect against it during which you are vulnerable, and this is typically anything from a few hours to a few days.
But just try to explain this logic to the damn "if you run an AV and keep your definitions up to date you'll have no problems" crowd ..
Uh, or perhaps he just learned from his mistake? The person who understands something the best is often the person who has made the mistakes.
I've been in this business for nearly a decade now, and quite frankly, there is ONE MAJOR reason that software still sucks. The majority of programmers are (a) damn lazy and (b) don't think properly about what they're doing. Simple as that.
The point of Hungarian is you don't need to "figure out" what the variable type is. You just look at it and you ALREADY KNOW. There are no better/faster tools than that in existence, nothing beats the speed of interpretation. Mouse float-overs and other such things are helpful, but certainly slower than the 'instant' decoding available from reading a 'Hungarian-compliant' variable name.
Hungarian Notation is not a "Microsoft thing". If you've ever bothered to read the original Charles Simonyi paper, it has nothing to do with Windows, and the original seemed more tailored for e.g. physics concepts than window and process handles. Microsoft later adopted an adapted version of this for their own coding. It's not a "Microsoft thing" or a "Windows thing", sheez, if I had a cent for every time someone repeated that bit of misinformation.
Hmm .. good point. I couldn't be bothered to 'mod my car', and I guess part of the reason is that I just plain hardly ever drive anywhere, except to work and back, a short trip. OTOH I use my computer pretty much all day long, so spending time 'tweaking' it for better performance (e.g. for faster compile times etc) is worthwhile. Maybe if my job required more hours on the road and less behind a computer, I'd care more about optimising the performance of my car.
They should make it less obtrusive, and optional. Say something on the right side of the web page with a link you can click on to speak to a human operator (and perhaps something that indicates if there are any available).
But I guess that's not the point, the point is to be pushy because they probably sell more stuff that way.
So something is acceptable simply because "many companies are doing this?" Jeez, that's pathetic and insulting. Right up there with excuses like "It's company policy ...".
Don't you have a life? You really are a geek.
Uh, yeah, spoken by someone reading and posting to /. close to Friday evening.
Well I'm sure asteroids and the like aren't really scattered uniformly throughout space, many many are formed by processes resulting in 'clusters' of objects (such as Leonids). I would guess, or at least it even seems likely to me, that it would be natural to have some variation then even over longer periods (e.g. months, days, years, decades, centuries) as various bits of various such 'clusters' in the galaxy pass through our solar system. The duration would depend on the nature of the objects (e.g. a long destroyed planet or moon or asteroid (cf. asteroid belt?)), and the speed and distribution of the objects. So if we imagine some event similar to e.g. what created the asteroid belt, but without the objects remaining in orbit around something large but rather simply 'floating off' into space and slowly becoming relatively widely spread out, then those bits and pieces, were they to pass through our solar system, could conceivably create a statistically measurable increase in such 'fireballs' over the course of years or decades. If you've been observing for twenty or thirty years, that is just a 'blink of the eye' on the planet's timescale, such fluctuations probably occur all the time over millenia.
So now you're just saying it's different in OpenGL, aha, you've backed down from your "can't be done" stance. Yes, vertex buffers are different in GL. Shaders are different in GL too, as are a number of things, but you can still do anything you can do in D3D in GL (and yes you need extensions, that's exactly what I said).
"your are mistaking binary compatibility with source compatibility"
Huh? If you have binary compatibility, then all you need are the headers with the definitions and the import libs. AND THESE ARE PROVIDED. FACT, we are still maintaining compiling supporting & updating Direct3D *3* and *5* applications (with DirectSound, DirectPlay, DirectDraw AND Direct3D) using the DirectX9 API. Are you saying I'm imagining it?
Some people like you might view a job as some authoritarian school-like structure where you sit and shuddup and just do what the boss tells you to "'cuz he's the boss". But just be aware NOT everyone sees it that way, some people prefer to work at organizations where their input is valued and they are an active part of a team that works together to achieve something. Just two different approaches.
Disk streaming?
Look, anything you can do in Direct3D, you can do in OpenGL, but the more advanced features you need to use (usually) vendor-specific extensions to access.
You're wrong about source code compatibility of DirectX too. All DirectX programs are source compatible with older versions. Each release of DirectX includes ALL the older COM objects (with the COM object version numbers attached being part of the object names), complete even with all the old bugs to keep apps working (e.g. upside down textures in very early versions, hehe).
We are maintaining and supporting apps written using DirectX 3, 5, 6 all through to 9, and they compile 100% fine on the latest DirectX SDK. Usually the ONLY thing you need to add to the source to get them to compile is a #define that causes the preprocessor to parse older definitions in header files instead of conflicting newer ones (e.g. "#define DIRECTSOUND_VERSION 0x0600").
If you went and rewrote all that old code because you didn't realise you could just use a couple of #define's here and there in your code, ha, that's pretty sad.
Scary isn't it, I had the same reaction recently when I first saw a palm-sized switch!
So let him opt-in, and let the rest of us opt-out. And then back that up with legislation and enforcement. Then we have 100% freedom, as we can all decide what we want. Right now we don't have the "freedom" to say 'no' outright to spam.
Tsk, always giving MS the benefit of the doubt. Microsoft has almost ALWAYS "slipped" on major projects in the past, usually be anything up to several years. This is nothing new, and has never implied that they were about to produce a quality product in the past.
Microsoft don't "slip" on deadlines: they deliberately start out providing fake, earlier deadlines to the press. So they'll say for example "next SQL server will be out in 2004". This has two effects: (a) companies that might have been thinking about using the gap to produce a competing system consequently don't, "next great MS version will be out too soon" they say. And (b) clients using an older version that need to upgrade to something 'bigger' think "hey, next great MS version will be out soon enough, let's wait for that rather than switch to Oracle".
Then the deadline approaches and Microsoft says "whoops we're slipping". But too late for the many who've now made the decision, so they just wait out the extra time and stick with MS.
Come on, this is an OLD game from MS. Don't be so naive. Those who don't study history ..
The Romans also understood this: http://users.erols.com/mwhite28/us_rome.htm: 'The Empire lasted as long as it did because the Romans weren't idiots. When the governor of Egypt sent Tiberius more taxes than he was supposed to, Tiberius reminded him: "I want my sheep shorn, not shaven."'
Reading up on Bush's plans/vision, it would seem they understand this too (http://www.newamericancentury.org/).
So why bother with the whole client/server computation thing, couldn't the SMTP server just sleep for a few seconds for each mail a client attempts to send? This would have the same "benefit" of delaying the client (i.e. the 'penalty'), except it would be better in several ways: firstly the delay wouldn't depend on the speed of the client's computer, secondly it is more efficient from an energy consumption point of view as the CPU will issue HLTs if idle, as opposed to consuming full power doing some pointless computation?
Straw-man straw-man straw-man ... *sigh*, now *that* is tiresome. Yeah, that's the ticket, claim the parent made all sorts of claims that he/she very obviously didn't.
I think the two most common reasons for this sort of disregard for typos etc in business communications, at ANY level (i.e. from top management down), are: (a) not caring, (b) in a hurry. In the first case, you have some people who just don't really care if they have a few mistakes in their typing. In the second case, and I believe likely here, very busy people (such as top management in virtually any company) are too pressed for time to go around proofreading every one of the dozens (or hundreds) of business communications that they must do EVERY DAY. Really, if you spend up to several hours a day just typing email, you just don't have time anymore to proof every last one.
Even less clued up tech guys fall for the FUD :( :( ... the other day one of the programmers in our company said something along the lines of 'we can't legally use OpenSource code for our software projects', then implied we'd have to then give our code away or something. So I not only explained the truth to him, but showed him that we've been using some LGPL libraries in our software for years! He was pretty surprised ... he had actually used the LGPL libraries indirectly before, without knowing it.