4 ms·

Your CPU instructions follow an architecture written almost 40 years ago and JavaScript is itself 27 years old. They are actually museum worthy. The point of h

by vkaku 3y ago

Your CPU instructions follow an architecture written almost 40 years ago and JavaScript is itself 27 years old. They are actually museum worthy. The point of having any standard is to exactly prevent people from debugging things every few days. Despite this, many modern websites hardly follow any sort of compatibility despite using a polyfill library. So these professionals are either not doing a very good job or this argument is a non argument. :-)

speedgoose 3y ago
The instruction set of the CPU I use to reply to this comment is from 2018. It has been a long and constant evolution from the CPU architectures of the 70s to what it uses today. JavaScript is old and kept improving too. It does a lot more and much faster than the first version of JavaScript developed in about a week. Standards are very useful, but we can't keep using old things forever. We stopped using HTTP 0.9 or TLS 1.0 for example. Spending time to support unused obsolete hardware may be fun, but good luck to get funding for that activity.
- vkaku 3y ago
  1. What computer are you using? You do know that a lot of software developers do not take active advantage of instructions right? Mostly because developers aren't as aware of floating point rounding modes or availability of co-processors or even vector units. If it's a computer that uses an instruction set you made in 2018, well, kudos - but that is not a large set of people out there. 2. I don't think it's hard to add HTTP 0.9 support at all, maybe I will add it to https://github.com/guilt/phttpd https://github.com/guilt/phttpd. I will not bemoan TLS or SSL dying at all. As protocols used for system update - they've caused more problems than they have solved. The protocols will break once again when agencies end up factoring large numbers in the near future. There is a need for privacy but there is no need to break system updates in the name of increasing security - it does not work that way. 3. Keep breaking things enough and you'll find all your customers moving away from you. Good luck explaining to them why your software breaks day after day. You might be able to fool them for some time. 4. I do not need funding to fix obsolete things, a lot of people are already doing it - some are getting paid for it too. :-)
  - speedgoose 3y ago
    It’s a very common MacBook M1. I agree that most developers use an interpreter or a compiler with the default settings. At least on the mac everything seems to target a very recent instructions set. But it’s quite common to see hot paths being optimised using not so old instructions on amd64 too. I also agree that you should keep most of your users happy. How many users are using such old hardware and software? At work, we disabled old TLS versions and many cipher suites for security reasons because we knew no one would care. We kept TLSv1.2 enabled because we still had users using software incompatible with TLSv1.3 unfortunately.
    - vkaku 3y ago
      I hear you, I hear you. ARM is at least 30 years old, if not more :) My first computer (in school days) was a 6502 based BBC Micro - so, maybe half an ARM (and a leg) computer. I am well aware of the TLS/SSL issues, I was personally responsible for large scale patching of these ciphers at a large retailer for a very large fleet of machines on their datacenters. DM me if you want to know the details. Yet, Today - I am the one slamming this practice for web servers serving system and firmware updates, and I write about how Debian solves this problem well (in another thread on this HN page). It is okay to upgrade people to forward looking infrastructure, and the cost of not keeping sustainability is steep. The correct way to get people to TLS v1.3 is to allow some means by which people can get the updates needed for both algorithms, as well as the new certificates. And the deal is that TLS v1.3 may not be enough for a post quantum world. This may be the right time to undo our mistakes of the past.

by vkaku 3y ago

speedgoose 3y ago

The instruction set of the CPU I use to reply to this comment is from 2018. It has been a long and constant evolution from the CPU architectures of the 70s to what it uses today. JavaScript is old and kept improving too. It does a lot more and much faster than the first version of JavaScript developed in about a week. Standards are very useful, but we can't keep using old things forever. We stopped using HTTP 0.9 or TLS 1.0 for example. Spending time to support unused obsolete hardware may be fun, but good luck to get funding for that activity.

vkaku 3y ago
1. What computer are you using? You do know that a lot of software developers do not take active advantage of instructions right? Mostly because developers aren't as aware of floating point rounding modes or availability of co-processors or even vector units. If it's a computer that uses an instruction set you made in 2018, well, kudos - but that is not a large set of people out there. 2. I don't think it's hard to add HTTP 0.9 support at all, maybe I will add it to https://github.com/guilt/phttpd https://github.com/guilt/phttpd. I will not bemoan TLS or SSL dying at all. As protocols used for system update - they've caused more problems than they have solved. The protocols will break once again when agencies end up factoring large numbers in the near future. There is a need for privacy but there is no need to break system updates in the name of increasing security - it does not work that way. 3. Keep breaking things enough and you'll find all your customers moving away from you. Good luck explaining to them why your software breaks day after day. You might be able to fool them for some time. 4. I do not need funding to fix obsolete things, a lot of people are already doing it - some are getting paid for it too. :-)
- speedgoose 3y ago
  It’s a very common MacBook M1. I agree that most developers use an interpreter or a compiler with the default settings. At least on the mac everything seems to target a very recent instructions set. But it’s quite common to see hot paths being optimised using not so old instructions on amd64 too. I also agree that you should keep most of your users happy. How many users are using such old hardware and software? At work, we disabled old TLS versions and many cipher suites for security reasons because we knew no one would care. We kept TLSv1.2 enabled because we still had users using software incompatible with TLSv1.3 unfortunately.
  - vkaku 3y ago
    I hear you, I hear you. ARM is at least 30 years old, if not more :) My first computer (in school days) was a 6502 based BBC Micro - so, maybe half an ARM (and a leg) computer. I am well aware of the TLS/SSL issues, I was personally responsible for large scale patching of these ciphers at a large retailer for a very large fleet of machines on their datacenters. DM me if you want to know the details. Yet, Today - I am the one slamming this practice for web servers serving system and firmware updates, and I write about how Debian solves this problem well (in another thread on this HN page). It is okay to upgrade people to forward looking infrastructure, and the cost of not keeping sustainability is steep. The correct way to get people to TLS v1.3 is to allow some means by which people can get the updates needed for both algorithms, as well as the new certificates. And the deal is that TLS v1.3 may not be enough for a post quantum world. This may be the right time to undo our mistakes of the past.