Live data from Hacker News

Debian 7.0 "Wheezy" released

debian.org

121–130 of 132 posts

Re: Debian 7.0 "Wheezy" released

#121
post #39

So what would people's opinions be on running this vs. Ubuntu LTS on a server? What about one that relies on more recent features (LXC et al)?

We run ubuntu servers, but I'm thinking of changing over to debian. Ubuntu is a moving target with its 6-mo releases - every release has a new method for doing foo. For the 12.04 LTS, it's packages don't get version updates just like debian - meaning if you want something more recent you have to step in and install them yourself. So may as well just run debian in that case.

Ubuntu has a stronger desktop community when you run into problems (largely due to scale), but debian has a strong server community. And the Debian Way of doing things usually stays the same way for years for a given subsystem - google providing advice from 2009 is likely to still be helpful. The ubuntu philosophy... not so much. A colleague wanted to turn off thin scrollbars in the ubuntu desktop, and found that for the last four 6-mo releases, there were four separate ways to do this...

But, on the other hand, ubuntu LTS is better supported by a lot of vendors (eg AWS has an official ubuntu AMI, but no Debian one). It depends on your use case, I guess.

Re: Debian 7.0 "Wheezy" released

#122
post #120
post #118

Earlier quoted context omitted.

How is it not an apt comparison? What pip would do in this case is bypass apt and install the latest version of Django and its dependencies. If I'm going to do that I might as well build the database and server from source too to have the latest versions. But then why am I using Debian?

Because it provides a stable environment for all packages outside of the special one you're personally managing.

If my server is web site running Django then the special one that I'm manually managing happens to be the most important one.

Re: Debian 7.0 "Wheezy" released

#123
post #44

Earlier quoted context omitted.

/opt is basically for 3rd parties to install software, because they can't be trusted to behave and integrate with the regular filesystem. The last thing you want is Oracle farking around with anything under /usr or /var, because they will fuck up your entire OS for their benefit alone. That is why /opt exists, in my understanding. /srv is a bit questionable to me. Basically it's another /var. I always used directorie…

Because Oracle cannot install to /usr/local/oracle? I don't see the value of /opt.

/opt is a tradition inherited from older commercial unixes like SCO, AT-T et al. Made popular in the later days mainly by solaris 2 heavy usage of /opt.

Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse.

Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations.

Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory.

The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.

Re: Debian 7.0 "Wheezy" released

#124

Earlier quoted context omitted.

I'm using a mix between unstable and Mint for a Steam box (games, music, movies, web) and found out the label must be mistaken. It's a minimal installation, but everything from ATI drivers to multi-arch support worked perfectly out of the box. It already went through several dist-upgrades without any manual intervention (except maybe a couple of "yes/no" questions).

When did you install? Testing/Unstable are relatively quiet during a freeze, so just wait till everybody realises that Wheezy is out and you should get plenty of breakage :)

Several months ago... what you say makes sense, should I expect generally less breakage than Ubuntu or more? I wouldn't like having to install Ubuntu, mostly because it's too difficult to manage and troubleshoot...

Re: Debian 7.0 "Wheezy" released

#125
post #31
post #29

Earlier quoted context omitted.

/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var, /usr, or /usr/local. What /srv/ really stands for is NIH.

/opt is justified. /srv is indeed NIH (redundant with /var/ whatever ).

Your wildcard "whatever" says it all.

Re: Debian 7.0 "Wheezy" released

#127
post #8

Congratulations to everyone involved. I've been running wheezy on my home server for a while now (/var/www moved to /srv, apt diffs package lists...) and i look forward to upgrading the production servers over the coming months. As an aside, it's really interesting that the word 'Linux' is mentioned only once on this page - and only after the kFreeBSD kernel.

i've always wondered about /var/www vs /srv/www nginx on ubuntu now uses /usr/share/nginx/www i wonder how long these conventions will continue to be all over the place.

/usr/share/nginx is the default root path for nginx. It sounds like Ubuntu has just stopped trying.

Re: Debian 7.0 "Wheezy" released

#128
post #122
post #120

Earlier quoted context omitted.

Because it provides a stable environment for all packages outside of the special one you're personally managing.

If my server is web site running Django then the special one that I'm manually managing happens to be the most important one.

Isn't that the way it should be? Especially in a production environment - not upgrading unless you're sure your core packages don't break your product?

Re: Debian 7.0 "Wheezy" released

#129
post #127

Earlier quoted context omitted.

i've always wondered about /var/www vs /srv/www nginx on ubuntu now uses /usr/share/nginx/www i wonder how long these conventions will continue to be all over the place.

/usr/share/nginx is the default root path for nginx. It sounds like Ubuntu has just stopped trying.

The docroot path? That would indicate the Ubuntu devs who chose this location had little or no sysadmin experience. Files and dirs under /usr should not be mutable, that's what /var is for.

At least they didn't locate it on the root directory. Mount points should never be on root. See the sources for stat() for the main reason why not.

Re: Debian 7.0 "Wheezy" released

#130
post #118

Earlier quoted context omitted.

I dare say that's not really an apt comparison if you're going for sarcasm. If you're being serious, then um... yeah.

How is it not an apt comparison? What pip would do in this case is bypass apt and install the latest version of Django and its dependencies. If I'm going to do that I might as well build the database and server from source too to have the latest versions. But then why am I using Debian?

You seem to be missing my original point. My understanding is you want to run the latest and greatest python, best practice is pretty much to use pip & virtualenvs(I'm not a python dev, so don't quote me on that). If you want stable, use the debian packages with security updates. Best of both worlds, like I said, but it's an either/or choice.

Besides missing the origianl point, comparing pip to tarballs just seems wrong. One is pretty much manual, the other is via a package manager, albiet not the distro specific package manager, but one specific to the domain you are working within.

"But then why am I using Debian?"

Personally, I tend to stick with everything from debian direct, but there are lots of domain specific developers who'd rather have the up-to-date stuff and I can't entirely fault their desire when we're talking about real world benefits of new versions. You still benefit from the stable base even if you want to run something up-to-date. You don't see the benefit of that?

Going forward from that, you can still pip in specific versions, update projects seperatly, and obviously test them before doing so, so while you may lose some advantages, living in a specific pip world doesn't seem like the end of the world to me, as long as there's a positive reason for doing so.

Post reply on HN