Thumbs up for the future!
Could you briefly outline why? :)
- old arch single config file, with '@' syntax for parallelism got me hooked; sure it's different in systemd days
- early problem free systemd adoption
- simplified, close to upstream distribution (don't want to dig for src, dev, docs etc)
- their wiki is the one that speaks the most to my mind, I try to be gentle and objective, but every time, I find solutions in a short amount of time, and even more ideas. They hit a very very sweet spot to me. (gentoo was like that before the data loss)
- no installer, might seem stupid but it's a bit easier to reason with it; I don't have to learn an install framework, it's very bare and unixy.
- very thin tooling from arch, debian does a lot, but it's too heavy for my mind. Things might have changed since I last live in debian but I run a few debian live isos and derivatives and it always feels like "too much", administrative (as the debian documentation)
- rolling by default, debian has testing but it feels riskier
- AUR felt simpler (again) than custom apt repos
Also I might add that I distanced myself from the OS quest (or if I could I'd run a lisp or smalltalk fork or something similar). I'd be happy to hear your suggestions about my points if you have time for that.
I'm a debian user, and I love the arch wiki. The debian wiki is often stale and/or incomplete, and usually you're told to go to the mailing lists (which are an awkward way to get info). The arch wiki is great at being clear and concise and I find arch's mediawiki to be more easily legible than debian's bare html.
I found Arch has quicker updates to the kernal and overall is super quick to adopt the latest tech. What made me completely switch to Arch for every day use, was the day the GTX 1080 came out, I could set it up on Arch with the beta drivers. If I wanted to do the same on Debian, I had to figure out how to update the kernal to a version not typically used, then find or figure out how to install the beta drivers, etc. Etc.
Debian is more stable, so when I need to do something where I don't need the latest drivers, I like to use it.
Typically, my servers, my company laptop(s), etc.
A common issue with Debian style distros is that you can install packages easily but it often comes with lots of configuration afterwards. It doesn't "just work"
AUR community scripts are like APT but for less popular programs that aren't supported in the main repos and, more importantly, packages that come with more complete installation scripts with necessary configs and supporting tooling.
Like any OSS community it's benefited most from a lively active community.
ArchLinux is easily the best experience you will find for desktop Linux usage. Plus the Wiki is the best around for Linux.
It's the only distro where using GRSecurity is as simple as installing a package. That's just not possible on Debian.
I'd still use Debian for servers as most VPS companies don't support ArchLinux natively, the set-up process for Arch is a bit intense, and if anyone else needs to get access it's better for portability.
The ArchWiki is a gift to all the community. Rolling releases, not testing. With Arch there's a feeling of owning your OS without going full LFS. I am currently planning a summer reformatting for a laptop and I can't imagine not using Arch.
But those are concerns only for my personal computers. On my servers or quick VMs I still prefer Debian.
I've used Debian privately and professionally on servers and desktop since the 90's, altogether several hundred systems. I've also used Slackware and LFS years ago. My personal laptop runs Arch the last few years (with Debian stable as backup partition); my work computer runs Debian unstable or testing (depending on release cycle).
The reason I like Arch is that it's close to the source. Debian often adds more patches and layers, policies and complexity to the building process. In Arch I can get an updated package in hours straight from the source origin, either built by the maintainer or built and packaged myself. It's very helpful if you are tracking, fixing or reporting bugs to upstream developers. True rolling release model is handy if you'd like to be part of open-source development or need to get something working at the bleeding edge.
Note that Debian's added complexity and stability is much appreciated for all other systems, it's just a bit more difficult to pull straight from the source for many packages. I do not need and would not want to run bleeding edge on most systems.
Edit: and thanks!
I run Arch because it's so bare by default, without an installer. As a power user, the fact that I know exactly how my whole system is wired together and what is there means when things go wrong or need to change, I know where to go.
That and I often want to be on the bleeding edge, and the rolling release and AUR makes that super easy.
My biggest gripe with debian is apt. Compared to pacman, it is just so much worse in just about everything. I realize that it has a slightly more difficult job, but still.
I have found myself too often in situations, where I simply couldn't fix whatever apt was complaining about. With pacman you just specify -d and you're fine (or --force if there's a file conflict).
Also, I've never managed to successfully create my own debian package. With Arch PKGBUILD system, it's a breeze.
Just my 2 cents.
I use apt and it works fine for me (I can't say the same about yum on Redhats).
However here are two examples of the sort of problems I mean. Both are non-issues with pacman, I can simply choose to ignore dependencies entirely and fix the problem.
Also I just realized I wrote "apt" before, but I really meant the packaging system itself, not just apt. Which also begs the question, why are there at least 4 seperate programs for package management (apt, apt-get, aptitude, dpkg)?
for me makepkg/PKGBUILD and abs keep me coming back to arch.
Even though I only started using Debian with Jessie (was using Ubuntu and Arch before that), I've come to love and depend on Debian's quality, stability, and reliability.
Here's to infinite more years of Debian!
If you're already running a trusted Debian system, then install the debian-keyring package. Packages are signed and verified, so those keys don't need further verification.
Otherwise, fetch the keys in  with gpg:
$ gpg --keyserver keyring.debian.org --recv-keys <...> # e.g. 0x6294BE9B
$ gpg --fingerprint
Finally download the checksum and their signature files, and verify their signatures:
$ gpg --verify <...> # e.g. SHA512SUMS.sign
$ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-role-keys.gpg --verify <...> # if using debian-keyring package
gpg --auto-key-retrieve SHA512SUMS.sign
Most distributions have signed checksum files, but also post those checksums in a HTTPS location. I, and I suspect most people, just check against that and call it good. AFAIK Debian don't have that, and between using GPG or thinking "F* it, I'll take my chances", I suspect many would choose the latter. I was trying to give people who's security conscious but not paranoid^W^Wlazy an option.
# gpg --keyserver keyring.debian.org --recv-keys EF0F382A1A7B6500
gpg: requesting key 1A7B6500 from hkp server keyring.debian.org
gpgkeys: key EF0F382A1A7B6500 can't be retrieved
gpg: no valid OpenPGP data found.
From what I read  Debian 8 will be supported until April 2020 and Debian 9 until June 2022.
So in 2020 I will have to decide to either switch to Debian 9 or to Debian 10 which probably will be out by then. Is that correct? My feeling is that it might make things easier for me to skip Debian 9 and go directly with Debian 10.
I did the same with 7. My server used Debian 6 until I switched to Debian 8.
> If you use debhelper/9.20151219 or newer in Debian, it will generate debug symbol packages (as <package>-dbgsym) for you with no additional changes to your source package. These packages are not available from the main archive. Please fetch these from debian-debug or snapshot.debian.org.
No more shipping -dbg packages with full binaries. And less storage space is always a win.
> dh_strip --dbg-package=nginx-$(*)-dbg
Which is the exact same command I use in my rules file. But instead of giving me a -dbg package with symbol files debuild gives me a -dbg package with the unstripped binary. Not sure what I am missing. I am following the DebugPackage guide on the Debian Wiki.
Also, make sure that you build with debug symbols enabled in the first place; the default CFLAGS should do that.
This is surprising though:
> Python 2.7.13 and 3.5.3
I thought 3.6 was in Stretch out of the box. Why 3.5 only (especially on a LTS)? :\
I'm in process of moving my company's main web app to python 3, and standardized on 3.5 to match Debian 9.
But python 3.6 has so many cpu & memory improvements (not to mention things like f'' strings), seriously considering installing custom copy of 3.6... though not sure if I want the burden of maintaining my own copy of everything that will affect.
Then again... "Debian stable" being rock solid stable is why I stick with it for production; if their caution in this is the price I pay, it's worth it.
You are left with third-party repositories until we come with another solution, like Ubuntu PPA.
As always, with debian, you’re stuck with older softwares for the lifetime of their latest release.
For example, I can’t use any C++17 feature for the next 2-3 years in my projects, just because I want to support debian…
It's inevitable that you're going to get mismatches between OS support and "official" support for the specific packages that go into that release. Not all projects provide supported releases over a period of years, so distros just do their best to patch any issues that upstream has stopped caring about past that point.
In practice the only thing that's going to be a big worry are new security issues, which upstream is usually willing to go out of their way to fix for versions still used in the wild, even for technically "unsupported" releases, at least the Perl project is, I don't know about Python.
3.x derailed that language :(
Although Alpine Linux is my personal choice.
Edit: the uploads are complete, v1.2.0 of debian9-amd64 and debian9-i386 are released.
If there is user demand for it, we can look into vmware boxes, and possibly hyper-v too.
Apologies if anyone feels this is off-topic/opportunistic - AFAIK all other Debian 9 boxes on Atlas target Virtualbox only, and while projects like Boxcutter (which we forked from) do support Parallels/etc, they aren't always the quickest to produce new boxes.
Sid (Debian unstable) is named after the guy that breaks the toys.
I have an awful habit of re-using old tech instead of throwing it out. Hopefully I can eventually get rid of the stuff that still works at the MIT FLEA or something.
I've been running stretch on a lenovo carbon x1 for the last 2 years and it's been one of the first problem-free experiences running linux on the desktop (linux user for.. 18 years). Really awesome. Thanks!
Boy, was this a hard process. It took some months until my system worked without GDM crashes. After that I changed over to Arch and been a happy Arch-er since than. I wouldn't recommend running testing.
I've heard that unstable is more like Arch linux and the rolling release model of Arch Linux works very well for me.
How well is Chromium supported on Debian?
I like it as a secondary browser for its excellent support of multiple profiles but I run Ubuntu and had to switch to Chrome because Chromium doesn't seem to be updated promptly.
As someone commented elsewhere in this thread, you can get FF version 52 in the security repo of Stretch, even if the default browser is Firefox ESR.
Expected to spend a weekend getting it all working. It's not for everyone, but if you want to better understand Linux, running it everyday is a great way to be fully immersed. It's also nice to have a desktop environment (openbox/lxde) that only uses 263MB ram on startup instead of a massive OS full of features I do not need or use. So yea, let's say the machine rarely swaps.
This is by no means exhaustive, but some things that I'm running and work well for me:
How to setup rEFInd for dual boot
Wifi driver (using non-free Broadcom-sta driver)
One thing that is new in this release is the availability of mod_http2, for Apache. I'm looking forward to seeing if that will increase the response-time of my various websites.
I suppose the idea of reducing freeze time with "always releasable testing" didn't really work out (lack of resources?).
Unstable is almost always a better choice. Things may occasionally break, but fixes will arrive very quickly.
Unstable is the Debian branch to use if stable is too slow for one's tastes. The testing branch is just for testing and it's really not safe to use on the internet.
Can't you make the same argument against using stable for the same reason?
> If something breaks, it will stay broken for quite a long time until the fix makes it out of unstable [and testing].
This won't happen with stable, since it will get the consistent result in the end.
on stable you don't get data corruption bugs, and you shutdown or filter security holes until they are confirmed fixed.
on testing/unstable you can have data corruption bugs and everything else. but you may bet that security fixes are done faster. emphasis on bet.
Basically you install the Stable system to get a stable system, and then 'bring forward' just those packages you need.
I was talking about the freeze itself though. It affects testing too which is normally rolling. So if the freeze is too long, things start becoming annoying.
In version 45 (released on March 8, 2016)
I think 52 is in the security repo now, though
An ESR is more useful for use cases like education or companies that roll their own SOEs and like to document things for users. Browsers love randomly changing the UI or other behaviour on a whim (and on a 6-week cycle). So, it's a browser's ESR by default, and you can always install another one.
But Debian Jessie was the "Stable" version for roughly two years. Mozilla's end-of-life for ESR 52 is on June 26, 2018. If Stretch has the same lifetime as Jessie, that leaves roughly one year during which Firefox ESR 52 will be end-of-life.
So how will Debian Stretch remain stable during a period when it is shipping an end-of-life Firefox for which-- as Mozilla states-- "no further updates will be offered for that version?"
They are few exceptions: any Oracle product (Oracle doesn't provide security patches and discourage people from making them) and Chromium (patches are too big) and Firefox (idem). For Chromium, the exception is to use the latest version. For Firefox, the exception is to switch to the next ESR once the current one becomes unmaintained.
Do you know if these exceptions are documented somewhere deep in the Debian doc maze?
They don't mention the Oracle debacle, though.
Jeez. I guess this means most people will be using other node binaries in production.
Jessie shipped with Golang 1.3, but has 1.7 via backports.
Luckily Go is quite easy to install and use from an isolated directory, and the majority of Debian usage here would be as a target OS where the Go compiler version doesn't matter.
Also jessie shipped Go 1.3 but it was updated to Go 1.7 in jessie-backports, so you can probably expect further Go updates in stretch-backports when it's released.
I'd rather manage golang the golang way.
Here's a quick command to build a golang-1.8.3 package with fpm (download and extract go1.8.3.linux-amd64.tar.gz first; get fpm from https://github.com/jordansissel/fpm):
fpm -s dir -t deb -n golang-go -v 1.8.3-$DEBIAN_REVISION go1.8.3.linux-amd64/bin/go=/usr/local/bin/go go1.8.3.linux-amd64/bin/gofmt=/usr/local/bin/gofmt go1.8.3.linux-amd64/bin/godoc=/usr/local/bin/godoc go1.8.3.linux-amd64/=/usr/local/go
but isn't nice that absolutely everything else on the system and the build stuff you need is easily installable?
then even for things packaged but which I care a lot, e.g. apache, I will compile anyway.
In the past Debian was considered to be one of the most stable Linux distributions available. Stability and quality was a priority above anything else. However, around 2014 something changed when systemd was forced into Debian in a way that would never have happened before the new generation of developers took over the project.
Maybe this is just something we have to get used to, young developers seems to value ease above quality and stability, this also explains the current flood of Electron apps.
why? that's like packaging flash games!