The argument for Perl6 was to fix a lot of problems that scripting languages in 2000 were suffering from. For example no effective way to compile them. No way to run them safely (i.e sandboxing). No way to run multiple scripting languages on multiple environments.... Those were good objectives to solve. The project just took way too long.
Looks over at the stock market, Apple's stock price this fine Sunday morning is $117.81
Apple in 2015 isn't going through a OS restructuring that started almost 20 years ago. The company survived the transition. Look at the stock price in the mid 1990s through early 2000s. Counting the splits around $.60-$1.50.
J - Non process managed systems are simply not going to be supported. P - Unsupported by who? Who gets to decide what is supported and what is not?
The GUI developers. Developers are who get to decide what OS components are going to be dependencies for their software. Debian changed because there were strong signs that developers were starting to introduce hard dependencies for systemd. While those could be overcome for Jessie, the feeling of the Debian people is that in 2 1/2 years there wouldn't be a choice. And while the switch in 2014/5 introduced some bugs the switch in 2017 would be much worse. The anti-systemd people (who are mainly low end system admins) refused to accept that developers don't want to deal with the ever increasing complexity managing complex process management using init. The issue was upstream from Debian, having the argument with Debian was living in denial.
As hardware gets more complex making a more complex uses possible, the underlying OS needs to become more complex to support it. There was a very disruptive change in PCs when people moved from single tasking to multi-tasking. It destroyed Amiga. It cost Microsoft something like $8b. It essentially destroyed Apple. Lots of people argued that task switching was good enough and much less disruptive. But ultimately everyone (excluding some embedded systems) switched to vastly more complex systems which had kernels with more in common mini computer kernels from a decade earlier than the CP/M, DOS and simple Unix kernels of a decade earlier. Notification is the beginning, but once notification works you are 80% of the way there to really exciting features. 10 years from now the idea of a human trying to manage service dependency will be as quant as writing assembler is today.
A simple window manager wouldn't be dependent on a process manager. A GUI however is going to be dependent on a process manager. Kwin and Mutter don't require systemd, KDE and Gnome do. GUIs need many processes to be running and communicating with each other. Which means when things go wrong they need to resolve it. A GUI needs to provide process management. Modern GUIs in particular, where there is an expectation of dozens of processes running notifying the user require quite sophisticated process management. Arguably the thing that drove the biggest change in Gnome 3 / KDE 4 from Gnome 2 / KDE 3 was introducing a framework dependent on much more sophisticated process management because they wanted notification to work well.
So for Linux either:
a) Each GUI provides process management and most applications can't be cross GUI b) The GUIs agree to share a process management framework and then there is a hard dependency between the GUI and this process management framework.
In the days of Gnome 1, KDE 1/2 the world looked more like (a) where neither GUI had a desire for the other GUIs apps to run well. Linux was then in the process of forking into two incompatible operating systems. The customer base however objected to this fork and since then the move has been towards (b). There is no reason in 2015 to object to process management while using a modern GUI. FVWM, Fluxbox, Sawfish etc... never claimed to provide this kind of service so of course those window manager are likely to continue to run fine on distributions that don't use systemd. As time goes on the less sophisticated Linux products are going to need to provide viable means of running large numbers of processes that have dependencies on one another and resolving dependency issues in real time. Non process managed systems are simply not going to be supported.
I would say it's a 90% solution if you have RAID and dual power supplies on separate circuits (this is common in x86 servers these days). Add in dual network connections and you're certainly on the threshold of diminishing returns.
And if the network to that location goes down? If the location loses power for an extended period? If there is a fire?
but few machines go down for other failures.
I've seen lots of machines go down from an upstream network problem. 50k+ servers go down because of a configuration error in a in a telco router during a routine upgrade that takes the system down for hours.
Sure, for only 100x more money you could get a non-stop like solution but few applications justify that outlay.
Mainframes aren't 100x more money.
I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.
Simply not true..add rootflags=degraded in GRUB_CMDLINE_LINUX
Very few (very expensive) machines go all in on HA. By far, the most common case is RAID (which is implemented on x86 hardware all the time).
I wouldn't call RAID in and of itself HA. So I'm going to strongly disagree with a characterization of saying this "destroys HA". It does nothing of the kind. If you are using x86 non clustered you aren't HA. So at best it destroys booting by default a non-HA system on a damaged RAID.
In any case systemd is designed to handle error conditions. You tell it what to do on errors. In this case there is a flag to tell systemd to mount a degraded raid that can be added so you change the default behavior. I can see the argument that this is perhaps not the best default to just drop you to emergency shell, but I can also imagine the other side where systemd feels it is too dangerous to allow the system to risk total data loss by continuing to run. Pick the default you like.
Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.
Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...
Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.
He's happy to accept a fix the segfault. He will take a patch or just have systemd refuse to boot. You were misrepresenting his position by saying he refused to fix the segfault.
Again think of systemd as a process manager. Once you have process management you don't want an init system. Why would you want to distinguish the move from init to everything running from other process management? Whether you want a process manager or just want an init system is a different question than being able to break apart a process manager.
No I'm saying that there is no difference between non sensible error messaging resulting in a crash and and just crashing. Obviously full error handling is better. But no system survives every possible case. Cases get logged they get fixed. That takes time and all software is vulnerable to being tricked into failing to boot properly.
As for the VM. If the VM doesn't have access and systemd is running on the VM then you are missing a hard dependency for your boot system. You wouldn't expect the kernel to boot without ram installed.
That sounds more like a kernel problem. You make a config error you get a boot problem. Systemd doesn't know what you are did. Change the config outside the VM and try again. How is that any different than throwing an error?
We wouldn't if the kernel provided sophisticated process management, logging... But since it doesn't yes you do need that.
So systemd is an operating system in itself, in this view. Why not. Not sure that how it has been sold, though.
It has. Pottering has always said that he wants systemd to be the interface for userspace the way the kernel is for kernel space. Every application that doesn't need low level interfaces with the kernel should would be using systemd to provide services. Effectively Linux kernel + systemd + X11/Wayland... become the OS.
The primary use cases for Linux are embedded systems and very large server farms. Niche system admins running 1-100 boxes are an important constituency but not even 1% of 1% of the Linux out there. Linux as a cloud based OS is more important than Linux as a strictly hardware based OS. I don't agree that systemd creates problems for hardware, as you mention it is popular on desktop. But if ultimately one of the other has to go overboard...
I'll give you something you couldn't do in 2008 but can do today that I've been able to do on mainframes for 2 decades. Start running a process, take the node running that process and yank the plug, keep all session data fully intact as the process moves to another node. What systemd is doing is creating the application hooks so that this becomes possible in most rather than just a few applications.
How exactly has a binary log format cost you time unless you are making it painful on yourself? If you can get to the filesystem you just read it using any number of tools that understand the binary format.
What you are missing is verb tenses. The decision to move to more modern architectures was being made around 2007. The specifics then got rolled out in 2010. Now the effects are being felt. The choice isn't starting to be taken away, that happened a long time ago.
There is going to be choice among modern configuration but not the choice to use "modern" software in 1990s style configurations. Same thing that happened to CP/M users.
W agree. My opinion is that IE4 is where IE crushed Netscape the transition happened then. Certainly sites had problems working with both browsers then. But the shift started happening quickly and the push for web standards would only start after Microsoft was dominant. Both of them were proprietary at at that point. Microsoft outspent Netscape, was more creative than Netscape and moved much faster than Netscape anticipated they could. The browser wars were over quickly. It was after Netscape lost that Mozilla, along with other players like Sun, the Linux community... became advocates of standards.
That seems a little one-sided. As I remember it, the biggest battle in the browser war of that generation was probably IE4 against Netscape 4
I'd put it a little earlier IE 3 vs. Netscape 3. IE 4 vs. Netscape 4, Netscape had already lost. The Mosaic era stuff had died out by IE 2. As far as Websites being more serious for communication that had already happened by the IE3 era. ActiveX was when web applications became more serious. As for standards... there was no serious push towards standards until years later. W3C as a formal organization doesn't even exist until the tail end of the browser wars, though there are a lot of European companies getting involved in the idea of web standards as early as 1994. Developing for IE and Netscape wasn't that hard. Java, Flash, ActiveX are all standards for web applications.
They happen all within 5 years of one another but they aren't sequenced the way you have them.
Microsoft came in for increasing criticism over their embrace-and-extend strategy in the face of those standards.
Yes and no. Embrace-extend-extinguish is more a charge by the workstation guys. The internet is a "unix thing" and Microsoft is focusing on not internet networking technologies. So in some sense it is earlier. Its just as a much a play in things like the spreadsheets and Lotus was getting replaced by Excel, or more importantly hardware standards for other desktop platforms. When it hits the web, it is from Microsoft creating a defacto browser standard which is not OS/platform independent. So again overlapping and certainly the web is an important example but I'd disagree with the causation you have here. The attacks start before anyone really cares much about http/web and continue being about many issues.
There is also the small issue that those three sources represent close to 100% of preinstalled, default browsers today.
Absolutely. Firefox was able to thrive over IE only when it was much better than IE. People deliberately switched from IE to Firefox. The same way that people who had IE 2 installed bought Netscape 3. I'm writing to you on my Mac / Safari. My question is not "which is the best browser in Nov 2015" but rather "are any of the browsers better enough than Safari to be worth switching?". That's a harder battle for Firefox to win. They can't do deep OS integration.
If Mozilla team can get Servo out the door quickly they may have something far better.
I find it hard to imagine that Google, Microsoft or Apple with the dominance that Firefox once had would not have made XUL based applications standard. In Gecko/XUL they had the same kind of stack as KHTML/Cocoa Webcore and chance to have invented WebKit. They didn't and as a result Apple and Google picked up Webkit.... They deserve blame for not having utilized the opportunity when they had it. OTOH I think they were overwhelmed by the complexity of keeping up as the web exploded in the age of Firefox dominance. As I said, not able to play at that level.
It's somewhat ironic that just as Microsoft have been paying a bit more respect to web standards with IE10-11, both Google and Apple have overly shunned them.
They are in the same boat now as IE was. What does it mean to be a "standard" that Webkit doesn't follow?
I think that was a huge strategic mistake that will probably lead to the collapse of their business within the next 3-5 years unless something dramatic happens to their product line.
Their business collapsed a long time ago as Firefox was being born. Mozilla was the open source core of Netscape. They failed to advance fast enough and the open source product was the living fragment of Netscape. Then AOL funded them for 5 years to maintain an alternative to IE. Once there were other alternatives... They don't really have a business now.
Ubiquitous computing = applications freely moving to different form factors (remember at this point Microsoft aggressively saw themselves as a contender of pure tablet and phone) Azure integration = the local device moving towards being a low latency computation system for cloud applications
Both of these steps required moving away from and killing off the legacy Win32/.NET paradigm. Windows8 was a transitional operating system good enough to run both the old and the new stuff. Users had to be trained to associate "desktop application" with legacy-Windows not Windows. The point was not that the desktop system wasn't in use, it was the core of the Windows experience. The point was to transition users away from desktop the same way that in the Windows 2.0 - Windows XP days they had transitioned users off DOS applications.
The Web evolved from infancy to arguably the most effective communications system and knowledge repository in the history of humanity without needing six-weekly updates.
The web surpassed gopher and usenet when there were a very small number of browsers. Netscape Navigator being essentially the only important one with: Mosaic, WebExplorer, Spyglass / Internet Explorer being distant 2nd tier. HTML was what rendered on Netscape.
The push for standards came well after as Microsoft overtook Netscape and the Mozilla organization began to push for an open (not tied to Windows / ActiveX) web.
____
As for Firefox dropping share I think that has to do with the them being outclassed. When Firefox was thriving Microsoft had killed off the browser market and then let their browser stagnate for years to hold back the shift towards web applications. In a static environment it was easy for Firefox to thrive. That's entirely different than the world that came to exist as Apple, Google and Microsoft are investing heavily in web rendering technology. I think the more reasonable explanation is that Mozilla foundation just can't play the game at that level. When the field was empty they were king, when it isn't they become a niche product and they keep struggling to find their niche.
OK I stand corrected. I had heard different things from the Microsoft guys during the move towards 8. But that is a name quote so... guess I gotta eat some crow.
It can be handled the same way. That's likely what they are trying to do. Start to limit the number of elements that can be acted upon by web contact while passing information all the way to the rendering engine. Keep the engine more isolated and just allow for minor interface variants. Keep the interface variants isolated from preferences in engine handling.... All that is probably best handled through dropping "features" while allowing "extensions" to have the functionality that formally existed in at a lower level.
Slashdot Mirror
The argument for Perl6 was to fix a lot of problems that scripting languages in 2000 were suffering from. For example no effective way to compile them. No way to run them safely (i.e sandboxing). No way to run multiple scripting languages on multiple environments.... Those were good objectives to solve. The project just took way too long.
Apple in 2015 isn't going through a OS restructuring that started almost 20 years ago. The company survived the transition. Look at the stock price in the mid 1990s through early 2000s. Counting the splits around $.60-$1.50.
So as for lack of clue....
The GUI developers. Developers are who get to decide what OS components are going to be dependencies for their software. Debian changed because there were strong signs that developers were starting to introduce hard dependencies for systemd. While those could be overcome for Jessie, the feeling of the Debian people is that in 2 1/2 years there wouldn't be a choice. And while the switch in 2014/5 introduced some bugs the switch in 2017 would be much worse. The anti-systemd people (who are mainly low end system admins) refused to accept that developers don't want to deal with the ever increasing complexity managing complex process management using init. The issue was upstream from Debian, having the argument with Debian was living in denial.
As hardware gets more complex making a more complex uses possible, the underlying OS needs to become more complex to support it. There was a very disruptive change in PCs when people moved from single tasking to multi-tasking. It destroyed Amiga. It cost Microsoft something like $8b. It essentially destroyed Apple. Lots of people argued that task switching was good enough and much less disruptive. But ultimately everyone (excluding some embedded systems) switched to vastly more complex systems which had kernels with more in common mini computer kernels from a decade earlier than the CP/M, DOS and simple Unix kernels of a decade earlier. Notification is the beginning, but once notification works you are 80% of the way there to really exciting features. 10 years from now the idea of a human trying to manage service dependency will be as quant as writing assembler is today.
A simple window manager wouldn't be dependent on a process manager. A GUI however is going to be dependent on a process manager. Kwin and Mutter don't require systemd, KDE and Gnome do. GUIs need many processes to be running and communicating with each other. Which means when things go wrong they need to resolve it. A GUI needs to provide process management. Modern GUIs in particular, where there is an expectation of dozens of processes running notifying the user require quite sophisticated process management. Arguably the thing that drove the biggest change in Gnome 3 / KDE 4 from Gnome 2 / KDE 3 was introducing a framework dependent on much more sophisticated process management because they wanted notification to work well.
So for Linux either:
a) Each GUI provides process management and most applications can't be cross GUI
b) The GUIs agree to share a process management framework and then there is a hard dependency between the GUI and this process management framework.
In the days of Gnome 1, KDE 1/2 the world looked more like (a) where neither GUI had a desire for the other GUIs apps to run well. Linux was then in the process of forking into two incompatible operating systems. The customer base however objected to this fork and since then the move has been towards (b). There is no reason in 2015 to object to process management while using a modern GUI. FVWM, Fluxbox, Sawfish etc... never claimed to provide this kind of service so of course those window manager are likely to continue to run fine on distributions that don't use systemd. As time goes on the less sophisticated Linux products are going to need to provide viable means of running large numbers of processes that have dependencies on one another and resolving dependency issues in real time. Non process managed systems are simply not going to be supported.
And if the network to that location goes down? If the location loses power for an extended period? If there is a fire?
I've seen lots of machines go down from an upstream network problem. 50k+ servers go down because of a configuration error in a in a telco router during a routine upgrade that takes the system down for hours.
Mainframes aren't 100x more money.
Simply not true. .add rootflags=degraded in GRUB_CMDLINE_LINUX
I wouldn't call RAID in and of itself HA. So I'm going to strongly disagree with a characterization of saying this "destroys HA". It does nothing of the kind. If you are using x86 non clustered you aren't HA. So at best it destroys booting by default a non-HA system on a damaged RAID.
In any case systemd is designed to handle error conditions. You tell it what to do on errors. In this case there is a flag to tell systemd to mount a degraded raid that can be added so you change the default behavior. I can see the argument that this is perhaps not the best default to just drop you to emergency shell, but I can also imagine the other side where systemd feels it is too dangerous to allow the system to risk total data loss by continuing to run. Pick the default you like.
He didn't cheerfully refuse to fix it:
Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.
Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...
Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.
He's happy to accept a fix the segfault. He will take a patch or just have systemd refuse to boot. You were misrepresenting his position by saying he refused to fix the segfault.
Again think of systemd as a process manager. Once you have process management you don't want an init system. Why would you want to distinguish the move from init to everything running from other process management? Whether you want a process manager or just want an init system is a different question than being able to break apart a process manager.
No I'm saying that there is no difference between non sensible error messaging resulting in a crash and and just crashing. Obviously full error handling is better. But no system survives every possible case. Cases get logged they get fixed. That takes time and all software is vulnerable to being tricked into failing to boot properly.
As for the VM. If the VM doesn't have access and systemd is running on the VM then you are missing a hard dependency for your boot system. You wouldn't expect the kernel to boot without ram installed.
High availability never runs raw on X86 hardware. The hardware isn't reliable enough for HA. They aren't the ones who don't know about HA.
That sounds more like a kernel problem. You make a config error you get a boot problem. Systemd doesn't know what you are did. Change the config outside the VM and try again. How is that any different than throwing an error?
How is that a bug in systemd? That's a dependency. Having dependencies isn't a bug. Any program can be deliberately broken by tricking it.
We wouldn't if the kernel provided sophisticated process management, logging... But since it doesn't yes you do need that.
It has. Pottering has always said that he wants systemd to be the interface for userspace the way the kernel is for kernel space. Every application that doesn't need low level interfaces with the kernel should would be using systemd to provide services. Effectively Linux kernel + systemd + X11/Wayland... become the OS.
The primary use cases for Linux are embedded systems and very large server farms. Niche system admins running 1-100 boxes are an important constituency but not even 1% of 1% of the Linux out there. Linux as a cloud based OS is more important than Linux as a strictly hardware based OS. I don't agree that systemd creates problems for hardware, as you mention it is popular on desktop. But if ultimately one of the other has to go overboard...
I'll give you something you couldn't do in 2008 but can do today that I've been able to do on mainframes for 2 decades. Start running a process, take the node running that process and yank the plug, keep all session data fully intact as the process moves to another node. What systemd is doing is creating the application hooks so that this becomes possible in most rather than just a few applications.
How exactly has a binary log format cost you time unless you are making it painful on yourself? If you can get to the filesystem you just read it using any number of tools that understand the binary format.
You've been around this debate to know that systemd isn't an init system. One of the many systems it is replacing is an init system.
What you are missing is verb tenses. The decision to move to more modern architectures was being made around 2007. The specifics then got rolled out in 2010. Now the effects are being felt. The choice isn't starting to be taken away, that happened a long time ago.
There is going to be choice among modern configuration but not the choice to use "modern" software in 1990s style configurations. Same thing that happened to CP/M users.
W agree. My opinion is that IE4 is where IE crushed Netscape the transition happened then. Certainly sites had problems working with both browsers then. But the shift started happening quickly and the push for web standards would only start after Microsoft was dominant. Both of them were proprietary at at that point. Microsoft outspent Netscape, was more creative than Netscape and moved much faster than Netscape anticipated they could. The browser wars were over quickly. It was after Netscape lost that Mozilla, along with other players like Sun, the Linux community... became advocates of standards.
I'd put it a little earlier IE 3 vs. Netscape 3. IE 4 vs. Netscape 4, Netscape had already lost. The Mosaic era stuff had died out by IE 2. As far as Websites being more serious for communication that had already happened by the IE3 era. ActiveX was when web applications became more serious. As for standards... there was no serious push towards standards until years later. W3C as a formal organization doesn't even exist until the tail end of the browser wars, though there are a lot of European companies getting involved in the idea of web standards as early as 1994. Developing for IE and Netscape wasn't that hard. Java, Flash, ActiveX are all standards for web applications.
They happen all within 5 years of one another but they aren't sequenced the way you have them.
Yes and no. Embrace-extend-extinguish is more a charge by the workstation guys. The internet is a "unix thing" and Microsoft is focusing on not internet networking technologies. So in some sense it is earlier. Its just as a much a play in things like the spreadsheets and Lotus was getting replaced by Excel, or more importantly hardware standards for other desktop platforms. When it hits the web, it is from Microsoft creating a defacto browser standard which is not OS/platform independent. So again overlapping and certainly the web is an important example but I'd disagree with the causation you have here. The attacks start before anyone really cares much about http/web and continue being about many issues.
Absolutely. Firefox was able to thrive over IE only when it was much better than IE. People deliberately switched from IE to Firefox. The same way that people who had IE 2 installed bought Netscape 3. I'm writing to you on my Mac / Safari. My question is not "which is the best browser in Nov 2015" but rather "are any of the browsers better enough than Safari to be worth switching?". That's a harder battle for Firefox to win. They can't do deep OS integration.
If Mozilla team can get Servo out the door quickly they may have something far better.
I find it hard to imagine that Google, Microsoft or Apple with the dominance that Firefox once had would not have made XUL based applications standard. In Gecko/XUL they had the same kind of stack as KHTML/Cocoa Webcore and chance to have invented WebKit. They didn't and as a result Apple and Google picked up Webkit.... They deserve blame for not having utilized the opportunity when they had it. OTOH I think they were overwhelmed by the complexity of keeping up as the web exploded in the age of Firefox dominance. As I said, not able to play at that level.
They are in the same boat now as IE was. What does it mean to be a "standard" that Webkit doesn't follow?
Their business collapsed a long time ago as Firefox was being born. Mozilla was the open source core of Netscape. They failed to advance fast enough and the open source product was the living fragment of Netscape. Then AOL funded them for 5 years to maintain an alternative to IE. Once there were other alternatives... They don't really have a business now.
The Microsoft guys had two objectives:
Ubiquitous computing = applications freely moving to different form factors (remember at this point Microsoft aggressively saw themselves as a contender of pure tablet and phone)
Azure integration = the local device moving towards being a low latency computation system for cloud applications
Both of these steps required moving away from and killing off the legacy Win32/.NET paradigm. Windows8 was a transitional operating system good enough to run both the old and the new stuff. Users had to be trained to associate "desktop application" with legacy-Windows not Windows. The point was not that the desktop system wasn't in use, it was the core of the Windows experience. The point was to transition users away from desktop the same way that in the Windows 2.0 - Windows XP days they had transitioned users off DOS applications.
The web surpassed gopher and usenet when there were a very small number of browsers. Netscape Navigator being essentially the only important one with: Mosaic, WebExplorer, Spyglass / Internet Explorer being distant 2nd tier. HTML was what rendered on Netscape.
The push for standards came well after as Microsoft overtook Netscape and the Mozilla organization began to push for an open (not tied to Windows / ActiveX) web.
____
As for Firefox dropping share I think that has to do with the them being outclassed. When Firefox was thriving Microsoft had killed off the browser market and then let their browser stagnate for years to hold back the shift towards web applications. In a static environment it was easy for Firefox to thrive. That's entirely different than the world that came to exist as Apple, Google and Microsoft are investing heavily in web rendering technology. I think the more reasonable explanation is that Mozilla foundation just can't play the game at that level. When the field was empty they were king, when it isn't they become a niche product and they keep struggling to find their niche.
OK I stand corrected. I had heard different things from the Microsoft guys during the move towards 8. But that is a name quote so... guess I gotta eat some crow.
It can be handled the same way. That's likely what they are trying to do. Start to limit the number of elements that can be acted upon by web contact while passing information all the way to the rendering engine. Keep the engine more isolated and just allow for minor interface variants. Keep the interface variants isolated from preferences in engine handling.... All that is probably best handled through dropping "features" while allowing "extensions" to have the functionality that formally existed in at a lower level.
They didn't have nearly the same number of components then. The web was a much simpler place and browsers were much simpler.