3 ms·
My suggestion is to focus on inconveniences. So far, the ones I've found most frustrating are: - poor support for a dual monitor configuration with one 4K an
by grandalf 10y ago
My suggestion is to focus on inconveniences. So far, the ones I've found most frustrating are:
- poor support for a dual monitor configuration with one 4K and one 1080p monitor.
- please include in the official deb repo multiple versions of important libraries where users are likely to download source code that depend on the version not included in the Ubuntu distro. The libraries to do this with are likely indicated by the current versions found in other distros. If a developer is working on something on a current version of Redhat, for example, maybe the pulseaudio version is different and incompatible. Offering both (installed in separate paths) would make life easier to avoid installing a bunch of custom stuff in /usr/local just to work with source code that leans on popular library versions that are current in other distros. Why not just strongly version each lib and let maintainers adapt. It's far easier (and more secure) to just apt-get install a binary version of the right version than to manage a significant amount of stuff in /usr/local or download an untrusted version from universe.
- add additional signing or cryptographic vetting to universe. It shouldn't just be a zoo of everything not official, organizations should be able to vet specific maintainers of universe packages, specific packages, etc. This way we can decide whether to install something from universe without flying blind and without doing our own source code audit. I realize that custom PPAs are intended to solve this, but I'd rather use the official package as often as possible, closely followed by a broadly vetted universe package, and my last choice is to replace an important package with one from a PPA which was customized only to support one application. I get squeamish when I add a PPA and it wants to replace any core library with its own "improved" version. This happens largely because universe does not support a security model that would allow the maintainers of that app to contribute to a broadly sanctioned unofficial repo while still guaranteeing security and compatibility with their own app. Enhancing the security model for universe would let arrangements emerge to solve this which would be stable and would add a lot of value to universe for people who might be reluctant to use universe packages for security reasons.
- tighter integration with other package managers (pip, npm, rubygems, cabal, etc.). In an ideal world the deb would specify a specific configuration contract and the implementation would make it happen while keeping the other package manager's conventions intact. We could then run a command to simply verify if those other package managers had subsequently violated the contract expected by the deb and warn appropriately (and offer to fix the situation using the package manager in question).
- OR, if the above suggestion is stupid, it would be great if pip actually used apt internally, on windows, linux, and OSX, so perhaps there is a way to try to grow apt as a superb package management solution and remove the need for nearly every project to create its own home grown system (or at least make the tradeoff favor using apt more appealing). We're approaching an era where we have virtual open source "distros" like homebrew which are essentially a package manager. Since filesystem size is less and less of a concern, I think the logical end-point (per my second suggestion) is to have package managers which create secure, rolling updates where multiple versions of many libraries are supported. Apt is one of the most powerful systems for doing this, so it should (in my opinion) win.