Tell me of FS of the same quality like ZFS and I will follow. BTRFS is broken by design. My data are more valuable to me, than everything else.Head_on_a_Stick wrote:So the GPL means nothing to you then? (Just curious)
Is it not the same for others? (Just curious)
Actually I started with FreeBSD, those guys say the same about freedom... They think GPL is bad and switched to clang. I leave the fight for others.
My opinion - it is stupid to be religious about practical things. What really matters is it works or it doesn't. Everything else is just blah-blah-blah.
Too much work. Too high risk to fail. Actually I was fine with sid only. Few user relevant packages were broken. System relevant things were fully OK.Head_on_a_Stick wrote: Not true: you could add stable, testing or even experimental repsoitories to your sid system and pin older versions from there
I was not able to downgrade certain packages and therefore have to start dancing with repos. Frankly FBSD is quite reasonable to split system from apps.
It's just too old from design point of view, driver support and crazy of licenses.
First I haven't installed ANY single package while pinning backports. I was trying this and that to succeed. No change has been made to the system. After discovering, that pinning doesn't helpHead_on_a_Stick wrote: Please read apt_preferences(5) before attempting this though — as you have already discovered, unskilled use of the pinning system can very easily b0rk a system
I switched that off. So if base is broken by default, then yes it is broken, otherwise it is not. In other words it is broken as much as "debootstrap stretch /mnt/linux" can be broken.
Frankly the most powerful under Linux Umbrella is Gentoo. No one can compete with that. While doing a simple "apt install package" I am always missing:Head_on_a_Stick wrote:Yes, it is amongst the most powerful and capable of all the package management systems but this does make it more difficult to understand and use correctly — I too came from Arch and it took me a while to "up-skill" to Debian, in fact the process still continues
1. Dependency tree, which I can get with emerge -t
2. Versions of packages going to be installed, which I can get with emerge -a
3. There is no way to list installing package if it is the only one before installation to confirm it or prevent it - emerge -a
In many cases I wish to see what will happen if doing apt install something and may be say yes or no. I am aware of apt -s.
4. I can't get why after removing some packages debian wish to install something as replacement. That way once I've got apache installed and starred at it while thinking what could led it to happen.
Yes, I am not an expert in Debian, but it makes me wonder more times, than I wish it to happen. There might be some ideas behind it, but _I am_ not capable to get it.
Arch is kind of restricted or binary Gentoo. It's a bit more cutting edge and has smaller user base, but my head is more compatible to it. Gentoo 10-15 years ago was perfect, after Daniel left it
it became a mess distro.
Nope. Debian is not aware of groups. Packages within one group are not in dependence relation to each other. They all installed manually, but at once. Deleting of any signle of them should not lead to uninstall others. Installing GNOME might bring up network-manager, but uninstall of GNOME should not kill the latter. There is no dependency between two! And there is none one who can disagree on it.Head_on_a_Stick wrote:As debiman notes, this is clearly nonsense and you didn't pay attention to the terminal output before accepting APT's suggestion, that behavior will also break Arch, FWIW.
I do not blame any one. Debian has to stay the way it thinks fine for developers. My only wish is to enable backports repo as any other repo available in the system.Head_on_a_Stick wrote:It is worth noting here that the nvidia-driver package is not part of the official release and is only provided as a convenience so perhaps you are expecting too much here, a similar argument can be applied to backports: the devs focus on older hardware rather than shiny new crap (and I applaud this approach).
It is disabled by default - fine. Tell me how to enable it if I wish to. End of discussion.
Wait. The manual said, that backports are packages build with stable libs. Why it should be a problem? I have failed with only one.Head_on_a_Stick wrote: You don't because that is a very silly idea: as you have seen the dependency tree in backports may not be complete so favouring them by default would break your box on a boringly regular basis
They are. I had to add -t stretch-backports to succeed. It was my fault if that special option is required. The same option doesn't work with nvidia-driver. And I worry if it might not work with other packages too.Head_on_a_Stick wrote:^ This is more vexing, the headers should be installable.The problem has been discovered with linux-headers
I can't boot. I am in chroot. There will be no boot, till everything works.Head_on_a_Stick wrote: Remove that stupid preferences file, run `apt update` and then use the recommended method to install the backported headers:^ This presumes that you are already booted with the backported kernel.Code: Select all
# apt install module-assistant # m-a prepare