[Info-vax] Intel proposal to simplify x86-64

Arne Vajhøj arne at vajhoej.dk
Sun Jun 11 13:42:30 EDT 2023


On 6/11/2023 9:34 AM, Johnny Billquist wrote:
> On 2023-06-11 03:34, Arne Vajhøj wrote:
>> On 6/10/2023 7:20 AM, Scott Dorsey wrote:
>>> Unfortunately the focus today is on speed and low cost.  People toss 
>>> together
>>> rapid prototypes and put them into production systems.  Back in the 
>>> eighties
>>> software engineering people talked about code reusability as being a 
>>> goal
>>> for improving code quality.  Now people just cut and paste library calls
>>> that they don't understand off of websites and wonder why their 
>>> machine is
>>> so slow and insecure.
>>>
>>> Pretty much all of the things we need to implement very safe computing
>>> systems were developed in the 1970s and 1980s and prototype capability
>>> architectures have been tested and used.  Back then, people were not 
>>> willing
>>> to live with the substantial performance hit.  Today, that 
>>> performance hit
>>> is even more of a problem because so much code is written so much 
>>> more poorly.
>>
>> Code reuse means library use.
>>
>> Todays developers knows less about the library functions they use than
>> they did 40 years ago. Because the number of library functions increased
>> by a factor 100 or so.
> 
> True. However, I also feel that people in general are less writing 
> libraries, and more just using them. And instead they copy code and have 
> several versions of the same code for every different project they work on.
> 
> Most people don't even know how to create a library anymore.

A lot of people still know how and actually do.

The number of available libraries (libraries not functions!) via
Maven (Java), NuGet (.NET), npm (JS) and PyPi (Python) are all
all counted in hundreds of thousands.

>> Computers are way more secure today than they were 40 years
>> ago. They have to because the threats have evolved dramatically.
> 
> I'm not sure I agree with that. However, the security problems and 
> issues have shifted a lot.
> 
> 40 years ago, you had a lot of rather stupid, simple security problems. 
> Like no encryption on network traffic, little authentication, little 
> audited code, and so on. So it was very insecure in that way.
> 
> Nowadays, those kind of problems are getting scarce. However, programs 
> these days are so complex, and contain so many components. That means 
> pretty much noone can really audit or understand the code anymore, and 
> noone even tries. In addition, since so many things are in the form of 
> libraries or services that you depend on, any kind of problem in any of 
> them can potentially affect a whole lot of systems and programs, meaning 
> any security issue is potentially a very large and severe one. That was 
> not the case 40 years ago.
> 
> So security problems are harder to identify, and have a potentially way 
> larger impact today. So are we more secure? If you go by the impact of 
> the security problems 40 years ago and security problems today, then the 
> impact today is way higher. (Obvious, since people exploiting security 
> issues have also become way more sophisticated over 40 years, along with 
> the tools available.)
> 
> 40 years ago, social engineering was the biggest exploit vector. 
> Probably not different than today. Just think of War Games as a good 
> example (pretty close to 40 years ago now).

There are 3 aspects:

practices 40 years ago vs practices today
applications 40 years ago vs applications today
threats 40 years ago vs threats today

Applications has become way more complex and are usually
more openly accessible than 40 years ago.

Exploiting vulnerabilities has become an industry with
both criminals and socalled "state actors".

If practices from 40 years ago was used today to develop
applications, then I don't think that would go well.

It is not really surprising. The world progresses. And
it is not unique for IT. Try design a car using 40 year
old practices and compare the result to a modern car.

Arne





More information about the Info-vax mailing list