Windows Critical Update

[PJS]

I am firmly rooted in reality thanks. The reality that having to download security patches every week for years is unacceptable. It's you who is in a dreamworld that contains no competent programmers and quality control procedures.

 

[yaruar]

I am firmly rooted in reality thanks. The reality that having to download security patches every week for years is unacceptable. It's you who is in a dreamworld that contains no competent programmers and quality control procedures.

All operating systems patch holes on a regular basis.

Have you checked the redhat errata recently?

Large codebases will always have vulnerabilities, especially now they are written by huge teams of people working on small individual areas.

I can't think of one large program which had no vulnerabilities or errors which has been released in the last 15 years.

As I've said before, the solution is redesigning the current hardware architecture and impliment proper ringfencing of memory segments, but for some reason the manufacturers don't want to.

 

[Driwen]

As I've said before, the solution is redesigning the current hardware architecture and impliment proper ringfencing of memory segments, but for some reason the manufacturers don't want to.

changing how hardware works, might resolve in having to change how software talks to the hardware. Which means it can only be done if it is really needed.
Example: 64 bits cpu's are actually better than 32 bits, but the OS does have to support it as otherwise your cpu might not even work (64 bits cpu's do work, but thats prolly because the change from 32 to 64 was worth the hassle of making OS/progs work with both).

Off course I have no real idea what has to happen to the memory to make sure it is safe against that, but it might cause more problems than it solves or you might need to change a little how the OS talks to the cpu.

 

[yaruar]

changing how hardware works, might resolve in having to change how software talks to the hardware. Which means it can only be done if it is really needed.
Example: 64 bits cpu's are actually better than 32 bits, but the OS does have to support it as otherwise your cpu might not even work (64 bits cpu's do work, but thats prolly because the change from 32 to 64 was worth the hassle of making OS/progs work with both).

Off course I have no real idea what has to happen to the memory to make sure it is safe against that, but it might cause more problems than it solves or you might need to change a little how the OS talks to the cpu.

i don't disagree, but it wouldn't take a huge shift to allow for allocated memory segments which would more or less remove buffer overflow problems which only work because memory is allowed to be overwritten sloppily.

 

[Driwen]

i don't disagree, but it wouldn't take a huge shift to allow for allocated memory segments which would more or less remove buffer overflow problems which only work because memory is allowed to be overwritten sloppily.

It could be that the hardware factories think it is the task of the makers of software languages to prevent this or that it might cost some load on the cpu to prevent this that it isnt worth it (better to let programmers have that load).
Anyway I might be able to answer the question why dont manufacters do this in 2 years, until then you just have to live with it I guess.