Hacker News Reader

Comment by snarfy | Hacker News Reader

I remember installing it when it was relatively new and people were gushing over it. A few weeks later a new version came out. I tried upgrading when I found there was no upgrade path. Upgrading Mint means reinstalling Mint.

I remember the days before apt-get when there was only dpkg. Before Debian I used Slackware so I'm all too familiar with package management (or lack of).

The idea that someone would release a new distribution, based on Debian of all things, and it not be able to upgrade was repelling to my mind. Re-install Mint to upgrade? No thanks I'll install Ubuntu over it.

Cinnamon is nice but I never understood why it needs its own distribution. I should be able to apt-get install cinammon-desktop or whatever and it work like any other package.

View on HN

> Cinnamon is nice but I never understood why it needs its own distribution. I should be able to apt-get install cinammon-desktop or whatever and it work like any other package.

On Debian you actually can 'apt-get install cinnamon' and have the full desktop.

There is also a Fedora spin with Cinnamon as the default DE: https://spins.fedoraproject.org/en/cinnamon/

I'm sorry for the rant, it's a bit off topic and not called for, but would like to say my experience is sort of the opposite:

I've been a Slackware-current user for most of a decade, and I love that it's so easy to upgrade the OS using slackpkg. I can (and do) often only upgrade a subset of packages, and never even need to reboot afterwards, not even after replacing the kernel (although, obviously...). A simple package system without dependency tracking has had many advantages for me. But installing stuff not in the standard system is more of a pain; there are third party repos but no where near as convenient as Debian/Ubuntu. I compile a couple SlackBuilds (packages) per week. I admit I've spent a huge amount of time learning how to do things like that manually and wouldn't recommend Slackware to those who won't want to learn sysadmin.

On the other hand my experience with upgrading between Ubuntu releases is terrible. A number of things have broken, permanently, every time, and I can't trivially upgrade from Ubuntu 14.10, because they purposefully break the package manager in old releases by breaking URLs. Also other pain points, like it not allowing installing both 32 and 64 bit devel libraries. I need those! The package manager is too complex and clever for me. (Honestly, I don't want to spend time learning how to override it.) I'm planning to format the drive and reinstall from scratch because it seems easier than fixing it.

A simple package system without dependency tracking has had many advantages for me.

Are you equating "simple package system" with "per-package service isolation" here? Because otherwise I don't see how your example about upgrades not requiring a reboot ties in with the package system. Debian has probably the most extensive package system, yet it still allows you to do upgrades without reboot. The major exception to this is dbus, because it still can't do stateful restarts. But I don't think that's a problem that Slackware is able to avoid, unless it avoids dbus completely.

Also: since Wheezy, Debian allows parallel installation of many development and shared library packages from all (10!) arches, for example to facilitate cross-compilation. It's still a work-in-progress, but I believe over 80% of the archive (not including packages with binaries) should be co-installable now.

Thanks for the information. So I assume Ubuntu now also allows parallel multiarch devel packages?

I've never tried Debian, and my experience with Ubuntu is very limited. I guess my comment on reboots was off-base, and maybe more of it. I meant that packages aren't densely interconnected with dependencies. (macports has it really bad, seems every time I want to upgrade python I need to recompile gcc or something.) Anyway, the simplicity makes it easy to modify packages. E.g. last week I fiddled around with lua packages to allow parallel installing multiple versions (lua 5.1, 5.2, 5.3 are incompatible languages which are often mistaken for the same language by distro maintainers). However I realise creating .deb files is also easy, so I guess I could do just the same there. Also, Slackware's multiarch support is a very simple hack using a small script that works 100% of the time as far as I've seen. It's telling that Debian still only supports 80% of packages after who knows how much work put into it.

Ubuntu should be able to do it, as the multiarch spec was developed in collaboration [1]. I'm not sure how well-integrated it is with the rest of Ubuntu's archive and infrastructure though (for example, Ubuntu first used a modified syntax in sources.list vs Debian's dpkg --add-architecture approach [2]). My 80% figure is also just a wild guess, I've tried it very early and failed for some exotic packages, but right now I only use it for a few packages.

I understand what you mean about tightly integrated package dependencies, and for me Debian is the rare exception in that it mostly works. My main irk with it is that dpkg only allows one version of a package to be installed, so you end up with package names like gcc-4.9 to allow parallel installation. Or in your example, there's a lua5.1, lua5.2 and lua5.3 in the archive -- but that doesn't mean that every lua library is also available in all three versions.

But the package compatibility is still way better than ecosystems like Maven/Gradle or Stackage, where dependencies can be so tightly coupled that you end up working around old bugs in one package, or new bugs in another.

[1] https://wiki.ubuntu.com/MultiarchSpec

[2] https://wiki.debian.org/Multiarch/HOWTO

Thanks. Hmm, the MultiarchSpec page lists "Co-installable -dev packages" as an unresolved issue, but hasn't been updated since 2014. The MultiarchCross[1] page specifically about that issue hasn't been updated since 2013. I couldn't work out what the current situation is.

[1] https://wiki.ubuntu.com/MultiarchCross

Slackpkg is relatively new, it was part of the slackware 9.1 release. A lot of people, myself included, remember experiences with older releases without a real package manager.

That was my experience as well, and after interacting with them a couple of times on issues with name space collisions I realized that it was more like some person's distro rather than a new mainstream distro. The difference being are you in the release management business (hard) or in cobbling together a set of packages that you like for you (easier). I went back to Kubuntu and waited to see if they would grow into that. After all, everyone has to start somewhere.

The compromise on their site with Wordpress was sad, but the best description I've heard for Wordpress was that it was "a rootkit with a blogging package ride along." It is so hard to secure a wordpress install and keep it that way.

I have upgraded to the last version from the manager menu. From the Update Manager: Edit->Upgrade.

I understand Slackware is much better these days. It was Slackware 2.0 the last time I used it.

>I tried upgrading when I found there was no upgrade path. Upgrading Mint means reinstalling Mint.

I don't think that's true any more. I think they allow you to upgrade in place.

"why it needs its own distribution" Because....Linux ? Seriously, in theory in Linux you should be able to mix and match any DE with any windows manager. In practice it doesn't work like that at all.

Modularity has its price.

Reply on news.ycombinator.com