All the downsides of (1), with the additional downside that you have less control over the package and have to "play nice" with the distro's rules. Build and maintain packages yourself, and get them added to the official repo. Main upside: You have a real package manager handling installation, but at the same time, you retain maximal control over what that package manager will actually do.Ģ. Some users will complain that it's not in their distro's standard repo (which might even be a valid complaint, if the product happens to be FOSS).
#CHROMIUM BROWSERS BUILD THEMSELVES EACH TIME INSTALL#
Main downside: Have to do this for every distro you care about (probably Debian and/or Fedora at a minimum, but if you only do one, then users of the other will ask/demand that you support it, or else they will try to install it themselves with third-party deb2rpm/rpm2deb tools, and now you're in the business of de facto supporting that use case). Build and maintain packages yourself, and tell users to add your server as an extra repo. > If we need significant investment in application development at the distro level around things which aren't distro-specific, something is off track.įrom upstream's perspective, there are several options for providing up-to-date binaries, and they all suck in one way or another:ġ. And the distribution usually ends up having to just focus on one browser like Firefox because it is more 'community focused' versus 'throw over the wall LOL'. Which then rolls down to someone having to try and make it work until they break. This seems to cause a reset of all the complaints for a while but no additional staffing. 'wow that's too much, you have to be wrong'. And finally once you get all that dealt together you have an unending bikeshed problem because every user "knows art when they see it." but can't understand why no one else can.Īnd finally when you come up with the staffing needed to deal with this, you get from the community and if a business from management. Finally you have to deal with standards which are basically 'you should do this, but no one else does so if you do, it will look like crap'.
You have to have people who have to deal with at least 3 different embedded scripting languages: CSS, HTML and Javascript. There will be people who have to know compilers, people who have to know network latency, file latency, and video latency. In the end, you end up finding out you need to staff just as much as you do for the 'core' operating system. and then once you factor in those you find it is at best the algorithm you already had.
If you are lucky you get someone coming up with a fix they worked out in a thesis which is much faster but only under ideal situation. You have to fake/second-guess the main operating system in some many places because every slowdown causes an avalanche of soul-numbing 'Why is my page so slloooooow your browser sucks!'. Part of it is that most browsers are an operating system in themselves. When it comes to staffing it, it is always a 'Can we get someone else to do that for us?' over and over again. Everyone wants one that works perfectly, but very few people want to put in the work themselves to make it work. Internet Browsers are a NIMBY (Not In My BackYard) problem for distributions.
0 kommentar(er)
