2 ms·

Not just to be contrarian, but because this is how I have lived for a while... Why wouldn't you run Debian Sid on your laptop? (FWIW I have also experimented w

by yebyen 9y ago

Not just to be contrarian, but because this is how I have lived for a while... Why wouldn't you run Debian Sid on your laptop? (FWIW I have also experimented with stable versions of Debian and, when I am not seeking the newest software which has been the case in the recent years, it works just as well for me as unstable distribution. But FWIW2, the Debian Sid on your Workstation paradigm has only bit me twice in nearing twenty years, and both times were valuable learning experiences.) My advice would be to use whatever you're most comfortable with. With an addendum to use whatever you have running in production if possible, because that will maximize the chances that you discover a bug in production before it bites you hard.

ohazi 9y ago
I used sid on my laptop for several years with similar results. These days I use testing. Testing is usually only behind sid by a few weeks, but I've found that the more annoying breakages tend to get resolved in sid before anyone in testing sees them, so the already infrequent headaches are basically non-existent now.
- yebyen 9y ago
  They must have improved testing then, or improved their processes, because the last time I evaluated testing it was properly "half unstable, half unusable" Admittedly that was a while ago! Testing, depending on what part of the release cycle you are in, can be a few weeks behind Sid or significantly more, though. Most upstream release managers probably pay some attention to the release cycles nowadays so, with luck you wouldn't notice this too much. (The start date of the testing freeze is well publicized in advance and known, so competent release managers should avoid potentially breaking/broken updates immediately before that date, if I remember correctly how this works.)
Avshalom 9y ago
RHEL (and thus usually centos) and Ubuntu (not Sid, not debian stable) are the two distros that companies distribute for. It's rarely but occasionally important depending on what your doing with your computers. As to why not to use CentOS/RHEL: they're not supported by half the companies that Ubuntu is so if you buy commercial software (indie video games at least) Ubuntu is the better option.
- yebyen 9y ago
  Ubuntu is based on Debian, tho. I've used Ubuntu in production for years (because that's what companies use), and that hasn't dissuaded me from using Debian on desktop, or on my non-critical servers. I've seen enough things that are "fine in sid" but broken in every Ubuntu distro including next, that your argument against Debian does not sound convincing to me. Yeah, things can break in sid, but are you better off using Ubuntu Next? I don't know anyone who would seriously argue this. Nobody develops on or targets Ubuntu Next that I am aware of, unless a release is imminent. Lots of developers pay attention to Debian Sid all the time, because that's where new releases land first (maybe you find them in rawhide first if the developers are RH-focused, I wouldn't know.) Debian Sid actually has the lowest barrier to entry for release managers, the changes just need to successfully make it out of Experimental.
  - Avshalom 9y ago
    I mean I certainly haven't done any sort of side by side testing, I just generally assume the various Debian releases (stable, testing, sid) are--at any given moment--not quite in-sync with whatever Ubuntu is doing with it's releases, and so assume problems are more likely when downloading shit off the Humble Store or whatever. I'm sure they're usually close enough that I'm not going to dispute anecdata though.
    - yebyen 9y ago
      No certainly! I never had a drivers issue when I was an Ubuntu user, to be sure (not one that was more solvable on Debian at least) and I have done some Linux games, I agree it was much easier after Ubuntu landed. Hardware makers target Ubuntu and game makers target Ubuntu. Libc differences can give you a real hard time when it comes to running binaries that are not compiled on your target OS. I have definitely seen that! It's no fun and you may not be able to solve it based on strange timing of libc versions with respect to the Debian 2-annually release cycle. Game developers certainly don't care what versions of libc made it into Debian stable or Debian testing these cycles, so you may be out of luck for two cycles in a row and it's no better in Sid. I mean, this is anecdata too. But it's real and if you haven't had this problem, it's because you didn't use Debian, but used Ubuntu instead. I suspect RHEL/CentOS users didn't have this issue either for one reason or another, and Fedora users neither. But it sure is a problem in Debian, if that's what you're into. To clear things up if it sounds like I'm talking in circles, I ran my share of games on Debian and I had definitely hit this type of issue, and ultimately failed to solve it for myself. If I was using closed-source software or intending to play games, you'd get no disagreement from me I'd rather do it on Ubuntu, and that's a fundamental disagreement with Debian policy and any either closed-source or other than rolling release target (eg. one-and-done) game developer or realistically any other code system that needs either kind of g/libc as a specific version of shared library to link to. You may genuinely be onto something here. But in my production systems, I tend to target using 100% open solutions, so I'm not sure I would have ever run into this at dayjob. Farewell!

by yebyen 9y ago

ohazi 9y ago

I used sid on my laptop for several years with similar results. These days I use testing. Testing is usually only behind sid by a few weeks, but I've found that the more annoying breakages tend to get resolved in sid before anyone in testing sees them, so the already infrequent headaches are basically non-existent now.

yebyen 9y ago
They must have improved testing then, or improved their processes, because the last time I evaluated testing it was properly "half unstable, half unusable" Admittedly that was a while ago! Testing, depending on what part of the release cycle you are in, can be a few weeks behind Sid or significantly more, though. Most upstream release managers probably pay some attention to the release cycles nowadays so, with luck you wouldn't notice this too much. (The start date of the testing freeze is well publicized in advance and known, so competent release managers should avoid potentially breaking/broken updates immediately before that date, if I remember correctly how this works.)

Avshalom 9y ago

RHEL (and thus usually centos) and Ubuntu (not Sid, not debian stable) are the two distros that companies distribute for. It's rarely but occasionally important depending on what your doing with your computers. As to why not to use CentOS/RHEL: they're not supported by half the companies that Ubuntu is so if you buy commercial software (indie video games at least) Ubuntu is the better option.

yebyen 9y ago
Ubuntu is based on Debian, tho. I've used Ubuntu in production for years (because that's what companies use), and that hasn't dissuaded me from using Debian on desktop, or on my non-critical servers. I've seen enough things that are "fine in sid" but broken in every Ubuntu distro including next, that your argument against Debian does not sound convincing to me. Yeah, things can break in sid, but are you better off using Ubuntu Next? I don't know anyone who would seriously argue this. Nobody develops on or targets Ubuntu Next that I am aware of, unless a release is imminent. Lots of developers pay attention to Debian Sid all the time, because that's where new releases land first (maybe you find them in rawhide first if the developers are RH-focused, I wouldn't know.) Debian Sid actually has the lowest barrier to entry for release managers, the changes just need to successfully make it out of Experimental.
- Avshalom 9y ago
  I mean I certainly haven't done any sort of side by side testing, I just generally assume the various Debian releases (stable, testing, sid) are--at any given moment--not quite in-sync with whatever Ubuntu is doing with it's releases, and so assume problems are more likely when downloading shit off the Humble Store or whatever. I'm sure they're usually close enough that I'm not going to dispute anecdata though.
  - yebyen 9y ago
    No certainly! I never had a drivers issue when I was an Ubuntu user, to be sure (not one that was more solvable on Debian at least) and I have done some Linux games, I agree it was much easier after Ubuntu landed. Hardware makers target Ubuntu and game makers target Ubuntu. Libc differences can give you a real hard time when it comes to running binaries that are not compiled on your target OS. I have definitely seen that! It's no fun and you may not be able to solve it based on strange timing of libc versions with respect to the Debian 2-annually release cycle. Game developers certainly don't care what versions of libc made it into Debian stable or Debian testing these cycles, so you may be out of luck for two cycles in a row and it's no better in Sid. I mean, this is anecdata too. But it's real and if you haven't had this problem, it's because you didn't use Debian, but used Ubuntu instead. I suspect RHEL/CentOS users didn't have this issue either for one reason or another, and Fedora users neither. But it sure is a problem in Debian, if that's what you're into. To clear things up if it sounds like I'm talking in circles, I ran my share of games on Debian and I had definitely hit this type of issue, and ultimately failed to solve it for myself. If I was using closed-source software or intending to play games, you'd get no disagreement from me I'd rather do it on Ubuntu, and that's a fundamental disagreement with Debian policy and any either closed-source or other than rolling release target (eg. one-and-done) game developer or realistically any other code system that needs either kind of g/libc as a specific version of shared library to link to. You may genuinely be onto something here. But in my production systems, I tend to target using 100% open solutions, so I'm not sure I would have ever run into this at dayjob. Farewell!