4 ms·

I wish to award massive kudos to the Author, because it's about time that somebody began the onerous (yet absolutely necessary!) task of backporting Chrome/Chro

I wish to award massive kudos to the Author, because it's about time that somebody began the onerous (yet absolutely necessary!) task of backporting Chrome/Chromium to older simpler/more understandable -- systems. I don't think that everyone truly understands the nature of the larger problem, so I'll briefly explain it here... You see, a long time ago in computer history, OS adoption -- drove corresponding software development. That was the case with various versions of Microsoft Windows -- for many years. These days, it's not the Operating System but the Browser -- of which (Google) Chrome (and its open-source counterpart, Chromium) -- which drives corresponding OS adoption... Basically, if a given OS can't run the latest version of Chrome / Chromium -- then it's basically a dead OS! That's a huge problem because by way of this, Chrome/Chromium unintentionally forces adoption of increasingly complex newer OS'es on the general public... That's a problem because these increasingly complex newer OS'es are orders of magnitude more lines of code (LOC) than their predecessors. If the complaint is that older OS'es are not secure, then guess what? That complaint also applies at least doubly (and perhaps exponentially!) to newer OS's as well, which comprise exponentially more lines of code than the older OS'es! In the future, it would be great to see the simplest (least amount of lines of code) OS that could successfully run Chrome/Chromium -- but even going a step farther than that, it might be an idea to freeze the Chrome/Chromium source at a certain point, then simplify Chrome/Chroumium such that its dependencies on an underlying OS were minimized! In other words, develop a fork of Chrome/Chromium in lock-step with developing the simplest OS that Chrome/Chromium could possibly run on, with the corresponding idea of refactoring all of that software into the simplest, cleanest, most documented, most modular piece of software that is or could exist. It is not in that form now. That is because Chrome/Chromium has incorporated source code from a lot of third party software. Does any single person, much less a single person at Google (as bright as everyone is at Google?) truly understand ALL of those lines of code? ? Based on the source code hierarchy -- I highly doubt it. That's because if they truly did -- then all repeated functionality in all third party libraries would be merged in the most minimum form necessary. Don't get me wrong, I love Google, I love everyone that works for Google, I love their products -- but I have to believe after looking at the Chromium source that there isn't a single person (compare to Linus Torvalds and the BDL concept) "running the show"... In other words, Chrome/Chromium is a "diffusion of responsibility" system, with multiple parties taking responsibility for different parts of Chrome/Chromium at different times... Compare that concept to that of a Maintenance Programmer Vs. a Chief Architect... A Maintenance Programmer typically changes a few lines of code at a time in a system in response to support tickets and customer requests. A Maintenance Programmer might very well implement the change or feature requested -- but with their changes they also might introduce subtle future bugs into the system because their view is local in scope, and they lack full global awareness of all of the rules and constraints that the entirety of the system must obey. A Chief Architect on the other hand -- will have that global knowledge -- and will harmonize any changes they make with the broader rules, constraints, goals and caveats of the entire system... In other words, the changes they make to a system, should they make them -- will be more finessed, more nuanced, more filled with understanding -- than those made by a Maintenance Programmer in response to a support ticket, customer request, or bug fix... Anyway, great job (so far!) with Supermium!!! We need Chrome/Chromium on those older OS'es!

npteljes 3y ago
Browser is central, but an OS is more than just a host for the browser. It's a separate system, and thus, a separate attack vector. Backporting the browsers are not as crucial as keeping the security updates flowing - those are what really make or break any connected piece, software and hardware alike. And when talking about keeping the lights on, consider that support is not cheap. As things progress, the supported platform diversifies naturally, so you have to actively remove from it too, so that the resources are not spread too thin. This means stopping to support older platforms, especially those that themselves are EOL, and diversify the platforms by not supporting X new function, requiring a shim or other such complexity. Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did. The closest people come to this when they write everything themselves, like how Terry did with TempleOS. But even then, understanding stops at the hardware level. At a point, you have to let go, and trust, and manage. Consider looking into management. The issues you describe are not technological, but rather stem from product management, project management.
- peter_d_sherman 3y ago
  >Browser is central, but an OS is more than just a host for the browser. It's a separate system A Browser is a piece of software that has dependencies on the underlying Operating System. If you have a mechanical Machine A and Machine A depends on Machine B to function -- then Machine A's working is dependent that Machine B work. Security is of secondary concern than that Machine A actually works... If Machine A doesn't work -- well, what's the point of security in that scenario? Putting security before Machine A working -- is like proverbially "putting the cart before the horse" (possessing a working horse is a higher priority than possessing a cart, because without the horse, the cart cannot work as intended -- it cannot move!) A Browser is a complex machine. An OS is a complex machine. But you see, if the Browser increases in complexity and that increased complexity forces the dependency on an increasingly complex OS -- then what we've done is evolved a machine that may have been understandable and controllable by some people in society (mechanics) -- to something so unwieldy and complex that fewer and fewer people can work with it, much less control it (compare to the current AI debate). >Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did. We do, at minimum, know that there were groups of people who worked on all of those things; that is, to have been created the collective knowledge must have existed in some form somewhere. If anyone sought such understanding, then I would suggest a quote by the esteemed (and very learned!) Software Engineer, Grady Booch, who wisely stated: "Complex systems evolve from simpler ones" While it may be impossible or impractical for someone to rigorously study all of the systems you have mentioned, if someone did want an understanding of all of them, yes, all of them -- what they first might do is recognize that "Complex systems evolve from simpler ones", and then seek to find the simplest working example of such systems, i.e.: Chromimum Code -> First version of NCSA Mosaic (whose soure code later became Netscape, which later became Firefox, which later became Chrome/Chromium...) Compiler -> Simplest of simple C compilers. x64 CPU -> Simplest RISC CPU on an FPGA (then study VAX or other early CPU's microcode for the microcode aspect) X11 -> Simplest earliest graphical window manager / GUI. etc., etc. Also, Terry A. Davis, the creator of TempleOS, deserves to be praised for his effort, not shamed because he was not a member of the "I'll let other people do it for me" managerial class... >Consider looking into management. Consider looking into Dilbert: https://en.wikipedia.org/wiki/Dilbert https://en.wikipedia.org/wiki/Dilbert https://www.google.com/search?q=dilbert&tbm=isch https://www.google.com/search?q=dilbert&tbm=isch https://scottadams.locals.com/ https://scottadams.locals.com/

npteljes 3y ago

Browser is central, but an OS is more than just a host for the browser. It's a separate system, and thus, a separate attack vector. Backporting the browsers are not as crucial as keeping the security updates flowing - those are what really make or break any connected piece, software and hardware alike. And when talking about keeping the lights on, consider that support is not cheap. As things progress, the supported platform diversifies naturally, so you have to actively remove from it too, so that the resources are not spread too thin. This means stopping to support older platforms, especially those that themselves are EOL, and diversify the platforms by not supporting X new function, requiring a shim or other such complexity. Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did. The closest people come to this when they write everything themselves, like how Terry did with TempleOS. But even then, understanding stops at the hardware level. At a point, you have to let go, and trust, and manage. Consider looking into management. The issues you describe are not technological, but rather stem from product management, project management.

peter_d_sherman 3y ago
>Browser is central, but an OS is more than just a host for the browser. It's a separate system A Browser is a piece of software that has dependencies on the underlying Operating System. If you have a mechanical Machine A and Machine A depends on Machine B to function -- then Machine A's working is dependent that Machine B work. Security is of secondary concern than that Machine A actually works... If Machine A doesn't work -- well, what's the point of security in that scenario? Putting security before Machine A working -- is like proverbially "putting the cart before the horse" (possessing a working horse is a higher priority than possessing a cart, because without the horse, the cart cannot work as intended -- it cannot move!) A Browser is a complex machine. An OS is a complex machine. But you see, if the Browser increases in complexity and that increased complexity forces the dependency on an increasingly complex OS -- then what we've done is evolved a machine that may have been understandable and controllable by some people in society (mechanics) -- to something so unwieldy and complex that fewer and fewer people can work with it, much less control it (compare to the current AI debate). >Another thing is the understanding. Why would anyone need to understand the entirety of X? Suppose a person understands every line of Chromium code. Do they also understand the compiler? The x64 CPU that the software runs on? I don't think anyone ever did. We do, at minimum, know that there were groups of people who worked on all of those things; that is, to have been created the collective knowledge must have existed in some form somewhere. If anyone sought such understanding, then I would suggest a quote by the esteemed (and very learned!) Software Engineer, Grady Booch, who wisely stated: "Complex systems evolve from simpler ones" While it may be impossible or impractical for someone to rigorously study all of the systems you have mentioned, if someone did want an understanding of all of them, yes, all of them -- what they first might do is recognize that "Complex systems evolve from simpler ones", and then seek to find the simplest working example of such systems, i.e.: Chromimum Code -> First version of NCSA Mosaic (whose soure code later became Netscape, which later became Firefox, which later became Chrome/Chromium...) Compiler -> Simplest of simple C compilers. x64 CPU -> Simplest RISC CPU on an FPGA (then study VAX or other early CPU's microcode for the microcode aspect) X11 -> Simplest earliest graphical window manager / GUI. etc., etc. Also, Terry A. Davis, the creator of TempleOS, deserves to be praised for his effort, not shamed because he was not a member of the "I'll let other people do it for me" managerial class... >Consider looking into management. Consider looking into Dilbert: https://en.wikipedia.org/wiki/Dilbert https://en.wikipedia.org/wiki/Dilbert https://www.google.com/search?q=dilbert&tbm=isch https://www.google.com/search?q=dilbert&tbm=isch https://scottadams.locals.com/ https://scottadams.locals.com/