Microsoft is coming to get you.
Printable View
As bad as this sounds now, I think it will definately be best in the long run. Too many people critisize how MS doesnt do anything against viruses. Well here ya go...but since it isn't as backwards compatible now people will critisize that, but I really don't see an alternative here. Oh well, whatever this will turn into a big flame.
I read an artical a while back about how the "monoculture" formed by Microsoft operating systems was a major cause of the outbreak of computer viruses. I guess problems like this are the only alternative but still, that sucks.
Basically, yeah. MS OSes are so common that virus writers really only need to target them.Quote:
Originally posted by sean_mackrory
I read an artical a while back about how the "monoculture" formed by Microsoft operating systems was a major cause of the outbreak of computer viruses. I guess problems like this are the only alternative but still, that sucks.
But I'm told Linux has the same "monoculture" problem. Could someone a little more Linux-Experienced fill me in.
- Is it as easy for viruses to get in, since most (if not all) things need to be compiled for the specific kernel.
- If there's a problem with programs that run fine on one Linux machine running on another, slightly different version of Linux, how come viruses still expericence a similar mono-culture?
The amount of people that use GNU/Linux at home is not that big, and most of them probably have experience of using it at work, where security would be stronger. Also, to do much work, a virus would have to run as the superuser (root), and people know they are not to use that account except when it's completely necessary.
Some viruses have been written for GNU/Linux, I think. However, Linux boxes are usually the ones that deliver them in the form of e-mail, rather than the end target.
I don't know any userspace applications that need to be specifically compiled for the current kernel. This only applies to kernel modules or applications that need to interface the kernel directly. Userspace applications interface with the kernel through the device system (basically a virtual filesystem). This doesn't require the application to even know the kernel version in most cases.Quote:
Originally posted by sean_mackrory
- Is it as easy for viruses to get in, since most (if not all) things need to be compiled for the specific kernel.
Usually this is not a kernel related problem but rather a spawn of Linux dependency hell. Yet it would still be possible to write software without any meaningful dependencies. A small thing like a virus will probably not suffer from dependency problems.Quote:
Originally posted by sean_mackrory
- If there's a problem with programs that run fine on one Linux machine running on another, slightly different version of Linux, how come viruses still expericence a similar mono-culture?
Theoretically. But did this ever stop a windows virus from doing harm? Windows XP has a similar user system as Linux has it. Just that "root" is called "administrator" (ok, and a few other things...). The only problem is, that there are exploits to gain administrator rights - and the fact that most windows home users work in administrator mode all the time.Quote:
Originally posted by -=SoKrA=-
Also, to do much work, a virus would have to run as the superuser (root), and people know they are not to use that account except when it's completely necessary.
Some viruses have been written for GNU/Linux, I think. However, Linux boxes are usually the ones that deliver them in the form of e-mail, rather than the end target.
However, even for Linux there are known exploits (that usually get fixed pretty fast) to gain superuser (root) privileges.
And of course, Linux just like Windows is mostly written in C and as such susceptible to buffer overflow exploits.
Looks like I switched to C# just in time..
What I am really worried about (that I haven't found any info yet) is if it is going to affect my ability to make tools that can detect hardware, or can we say goodbye to API oriented code? Hmm... I need to look more into how it is going to affect programming in the future...
Are you sure? :DQuote:
Looks like I switched to C# just in time..
"Another product that Microsoft needs to update is the.Net Framework. The new memory protection features in SP2 require developers of certain applications to mark their code with memory execution permissions. If they don't, the protection features could interfere with the application, according to Microsoft."
"The great bulk of applications will not be affected by memory protection. The number one that leaps to mind is execution environments with just-in-time code generation. The.Net Framework is one," Goodhew says.
Yep.
Not to mention that .Net is being built into all of their future OS's.
Look at here...Quote:
Some application behaviors are expected to be incompatible with execution protection. Applications which perform dynamic code generation (such as Just-In-Time code generation) that do not explicitly mark generated code with Execute permission might have compatibility issues with execution protection. Windows .NET Framework applications do not currently mark generated code with Execute permissions. XPSP2 recognizes the current, shipped versions of .NET Framework and runs them with NX off. Therefore existing .NET applications will continue to run. Microsoft is enhancing the .NET Framework to take advantage of NX and will ship service packs for each of the shipped versions in the XP SP2 RTM timeframe. The .NET Framework "Whidbey" will innately support NX.
I'm probably going to spend most of my time coding in C# after 2006, but right now I don't see myself switching. :)
Anyway, I like to do lots of OpenGL apps, and the .NET framework still hasn't any wrappers for it yet. :(
*cough*
http://www.moonwink.com/OpenglDotNet...dotnetapp.html
http://www.randyridge.com/Tao/Introduction/Default.aspx
http://csgl.sourceforge.net/
I am learning DirectX so that isn't a problem for me.
I know about those implementations. I never use them, because there is no guarantee that they'll be continually maintained. (Remember GLUT?) When I said a .NET wrapper, I meant one maintained by Microsoft.
That's partly why I chose DirectX. I like knowing that what I use is both of commercial quality, and will be continually supported because they have an interest in keeping it so.
I'd rather have MS introduce a codebreaking change than sitting around doing nothing. For one, the service pack is voluntary. There isn't a hitman from MS on his way to install it on your PC. Then, added security is neccessary. And if that comes with a price, that's ok, as long as it's known. And I guess this thread proves it is known :rolleyes: