3 ms·

The maintainer's reply is a sad statement on how hard it is just to package and distribute a modern web browser.

api 11y ago
Packaging and distributing anything for endpoint devices is a profound exercise in pain and suffering. If your target is anything other than a Mac or a phone, multiply it even further. It's a major driver of Internet centralization: things must be centralized to escape the deployment nightmare. It's exponentially easier to manage deployment on a handful of servers than it is to actually ship an app to users. With our app, we test our Windows build on Windows Vista, 2008 Server, 7, 2012 Server, 8, 8.1, and 10, on both x86 and x86_64. It always passes before we ship. Then inevitably we get bug reports: the UI won't open, device drivers won't install, the app mysteriously crashes, etc. Investigation always reveals some weird little variation or clashing piece of software on the customer's machine. Every Windows machine is a special snowflake, and as Windows machines run they accumulate 'OS rot' and gradually become less reliable (due to the mutability of the OS and dependencies). To fully test deployment you'd have to test hundreds of thousands of VMs with different software install histories, etc. In the end we have to tell people 'sorry, we tested with clean Windows installs on eight different versions, you're on your own.' Mac is the only tolerable deployment target and that's because it's a fascist dictatorship compared to Windows: uniform hardware, strict restrictions on OS modification, and enforced software conformity. Phones aren't too bad either but that's because they're also fascist dictatorships with locked-down OSes. Basically the modern OS is broken. Things are mutable that shouldn't be, process isolation is a joke, etc. Server OSes are broken too but at least if you own all the servers you can make sure they're all broken in the same way. Even there the trend is toward statically linked binaries (Go) and packaging apps as entire containers with their own OS (Docker) to basically deprecate the OS and achieve predictable deployment.
- r0m4n0 11y ago
  A fairly common practice is shipping applications utilizing Citrix to have end users remote into a citrix server to minimize the various configurations of a desktop application. Personally I dislike the architecture in that the user experience is compromised (glitchy/laggy/hacks for interfacing with the client) but it does return some of the control back to those managing the host
- skrebbel 11y ago
  Insightful! I didn't know it was that bad. Did your team ever consider using something like Turbo Studio (called Spoon Studio until recently), which is a bit like Docker, but different, and for Windows? Their promise is that they basically solve most of the problems you mention, so I'm curious how well it stands up in practice or why you choose not to use it. https://turbo.net/studio https://turbo.net/studio EDIT: I'm a bit confused: I just got two downvotes for asking a question. So just to be absolutely clear: I don't have any relationship with Turbo or whatsoever.
  - given 11y ago
    You shouldn't be confused. It's all just numbers and ideas. There isn't really such a thing as a "vote" or "clear" or even "Hacker News" apart from the idea you have of it in your mind.
wsloth514 11y ago
This is in the Debian bug list, not on the chromium bug list. The maintainer who replied is not a chromium developer, so I don't blame him that he doesn't have a lot of time to look at chromium's source code since a 'modern web browser' is really big. I have built chromium from source before. The android application alone is 44MB, not including the libraries, just saying, for one person to 'look' at chromium will take awhile to do so. The person who replied did have a good comment with the 'chrome://net-internals/#sockets'. It will list specifically what this person is looking for.
gjm11 11y ago
How so? He just says: this seems like it'll be hard to track down and I don't have much time to dedicate to it. I don't see how that says anything about (1) packaging and distributing specifically or (2) modern web browsers specifically. It just says that complex pieces of software can require a lot of work to debug. What am I missing?

api 11y ago

Packaging and distributing anything for endpoint devices is a profound exercise in pain and suffering. If your target is anything other than a Mac or a phone, multiply it even further. It's a major driver of Internet centralization: things must be centralized to escape the deployment nightmare. It's exponentially easier to manage deployment on a handful of servers than it is to actually ship an app to users. With our app, we test our Windows build on Windows Vista, 2008 Server, 7, 2012 Server, 8, 8.1, and 10, on both x86 and x86_64. It always passes before we ship. Then inevitably we get bug reports: the UI won't open, device drivers won't install, the app mysteriously crashes, etc. Investigation always reveals some weird little variation or clashing piece of software on the customer's machine. Every Windows machine is a special snowflake, and as Windows machines run they accumulate 'OS rot' and gradually become less reliable (due to the mutability of the OS and dependencies). To fully test deployment you'd have to test hundreds of thousands of VMs with different software install histories, etc. In the end we have to tell people 'sorry, we tested with clean Windows installs on eight different versions, you're on your own.' Mac is the only tolerable deployment target and that's because it's a fascist dictatorship compared to Windows: uniform hardware, strict restrictions on OS modification, and enforced software conformity. Phones aren't too bad either but that's because they're also fascist dictatorships with locked-down OSes. Basically the modern OS is broken. Things are mutable that shouldn't be, process isolation is a joke, etc. Server OSes are broken too but at least if you own all the servers you can make sure they're all broken in the same way. Even there the trend is toward statically linked binaries (Go) and packaging apps as entire containers with their own OS (Docker) to basically deprecate the OS and achieve predictable deployment.

r0m4n0 11y ago
A fairly common practice is shipping applications utilizing Citrix to have end users remote into a citrix server to minimize the various configurations of a desktop application. Personally I dislike the architecture in that the user experience is compromised (glitchy/laggy/hacks for interfacing with the client) but it does return some of the control back to those managing the host
skrebbel 11y ago
Insightful! I didn't know it was that bad. Did your team ever consider using something like Turbo Studio (called Spoon Studio until recently), which is a bit like Docker, but different, and for Windows? Their promise is that they basically solve most of the problems you mention, so I'm curious how well it stands up in practice or why you choose not to use it. https://turbo.net/studio https://turbo.net/studio EDIT: I'm a bit confused: I just got two downvotes for asking a question. So just to be absolutely clear: I don't have any relationship with Turbo or whatsoever.
- given 11y ago
  You shouldn't be confused. It's all just numbers and ideas. There isn't really such a thing as a "vote" or "clear" or even "Hacker News" apart from the idea you have of it in your mind.

wsloth514 11y ago

This is in the Debian bug list, not on the chromium bug list. The maintainer who replied is not a chromium developer, so I don't blame him that he doesn't have a lot of time to look at chromium's source code since a 'modern web browser' is really big. I have built chromium from source before. The android application alone is 44MB, not including the libraries, just saying, for one person to 'look' at chromium will take awhile to do so. The person who replied did have a good comment with the 'chrome://net-internals/#sockets'. It will list specifically what this person is looking for.

gjm11 11y ago

How so? He just says: this seems like it'll be hard to track down and I don't have much time to dedicate to it. I don't see how that says anything about (1) packaging and distributing specifically or (2) modern web browsers specifically. It just says that complex pieces of software can require a lot of work to debug. What am I missing?