@FaheemMitha Yep. Thankfully, it'd be from Jessie, so its not like it'd be changing a lot... so maybe I'll do it. Wonder if I can get the boss's OK to do it at work. (Maybe, these are all work machines I'm doing it for.)
If you are not a Debian Developer, please upload your backport somewhere (binaries and sources, e.g. to mentors.debian.net), post a link to its .dsc file on debian-backports@lists.debian.org and ask for review and upload.
Some important note
Please note, that you are responsible for this backport from the time on when it was accepted on debian-backports. This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing and provide security updates when needed. If you are not willing or capable of doing this, you better ask someone else (e.g. on the mentioned mailinglist) to create and maintain the backport.
Sounds like a lot of fairly thankless work. Especially the keeping track of things.
@FaheemMitha Yep. Not sure if its worth it. I don't think that many people are actually using SSSD on Debian, and I'm not sure we will be more than a month or so past Jessie's release.
(due to upgrading to Jessie)
Though it could be worse than boring thankless work. You could be working on systemd in Debian. I imagine the systemd maintainers must have to buy extra hard disk space to store their email killfiles.
@FaheemMitha Yeah. There are a few things I've had to fix here and there, but that's pretty normal with testing. Actually, the last testing cycle or two have been pretty breakage free.
And fix a thing here or there applied to sysv init as well, and fixing them is often more of a PITA with sysv init. At least, once you get past the systemd learning curve, as it's definitely different
@FaheemMitha freeze, release, thaw, huge backlog of migrations, months pass, freeze, etc.
Yeah. The one for Jessie has been fairly free of breakage, amazing considering systemd. So was the one for Wheezy. I think the one for Squeeze, OTOH, was broken routinely.
(But that's been a while, so I may be remember wrong)
@FaheemMitha systemd became a political issue, unfortunately, not a technical one.
It actually tooks me months to get around to upgrading to wheezy, as I recall.
@derobert so, people don't like something different?
By that logic, git should have got lots of hate.
[Luke Kenneth] how to remove libsystemd0 from a live-running debian desktop system
Hmm.
"the reasons for demonstrating that this is possible have absolutely nothing to do with my *personal* (technically-based) dislike of systemd, although my reasons for actually removing libsystemd0 from personal systems *are* based on a technical assessment (mostly with a sysadmin eye). but, i repeat: my *personal* choice has *nothing to do* with the reason for posting this documentation."
This thread is like 100 messages long. Mid-February approximately.
@FaheemMitha yes, and as gets pointed out in that thread, that's BS. libsystemd0 is pretty tiny. Its main purposes are things like standardizing "does this system run systemd?" checks.
@FaheemMitha That's part of it. I don't know why it gets so much hate otherwise. It does do a lot of stuff, though mainly that's folding a bunch of daemons into one project. (People never complain about Apache, for some reason).
I guess it's pretty annoying that all the knowledge you've gained about how to make sysvinit work over the years is suddenly useless—the first time it didn't work right, I was certainly annoyed. How the #(@!*# do I fix this? What do all these parts do?! WTF is a unit file, etc.
Why have almost all the shared libraries in /usr/lib/ have the executable permission bit set? I don't see any use case for executing them. Some do manage to hook-up some form of main function to print a short copyright and version note, but many don't do even that and segfault upon execution.
So...
And having written unit files and init scripts... I'm a heck of a lot more confident that the unit files are right. Even when the init scripts are copied from /etc/init.d/skeleton.
systemd does plenty of things I don't like (e.g., it's silly RedHat-esque way of handling local config changes), and it feels like it could be more elegant (but I don't know how to pull that off).
anthony@Zia:/etc/systemd/system$ cat vpn-really-up.service
[Unit]
Description=Ping Einstein to make sure the VPN is really up
Requires=openvpn@derobert.net.service
After=openvpn@derobert.net.service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/ping -c 2 -w 300 192.168.65.24
TimeoutStartSec=330
An alternative to backports is putting stuff in ones own repository. Of course, you have to have a stable machine on a fast connection to the net with plenty of bandwidth for that to be an option.
@FaheemMitha the binary issue was related to logfiles, which, if you let systemd do system logging, can either be in binary or plain text. Some of the embedded folks like binary logs because they can be smaller and the rest of everyone likes plain text. Systemd can do both, but because it can do one that some people did not like, those people got upset.
and some people just want to complain. I saw one guy ranting at how much more complicated his mount output was with systemd and how that makes systemd bad (more mounts due to cgroup utilization by systemd)
@casey Hmmm, the journal can be plain text? It forwards to syslog in plain text, but I don't think you can actually store /var/log/journal in plain text.
i haven't dug too deeply into the drama on the list so I can't really say.
but I'm firmly in the "I don't care" camp, as my use case is not greatly affected by either choice. 99% of my use case boils down to starting/stopping services, which is just a slightly different command for either. For the 1%, I'd rather write a systemd unit than a sysvinit script.
@FaheemMitha defending an ideology. system do does too much, is more than a simple replacement for init, violates the "unix way", binary data = closed data, is limited to x86/amd64 systems, etc
the last one is the only one I see as really valid, as it necessitates supporting a different init system on some platforms
@derobert I haven't followed the discussions either, that nugget of (mis?)information was from a gentoo list on how to implement systemd on gentoo/kfreebsd
im bad about knowing exactly what it needs. Though I build my own kernels, gentoo has a patch that adds "CONFIG_GENTOO_LINUX_INIT_SYSTEMD" to the config and if you turn that on it forces on the relevant options for systemd to work
@FaheemMitha yea, its one of the reasons I use the gentoo-sources kernel vs the vanilla-sources kernel in gentoo. The difference is a few pretty minor patches like that
I need to audit my SO [fortran] answers to see the frequency they use the phrasing "Fortran arrays are column major..." because it seems that I type that way too often
Gotten frustrated with a user? Want to vent? Feel like punching them?
Don't worry, here's a script that adds a "Punch" button to every gravatar. You can punch all the worst users now:
Installation
Click here to install. Will work in Chrome or Firefox (the latter requires Greasemonkey). S...
Most of the next-gen sequencing methods sequence small bits of sequence which are then assembled into the genome or whatever they were sequencing. Each small piece is called a read.
I saw your question on biology and I'll post an answer when I get the chance
@stackunderflow Because it's much faster. They take many copies of a genome, break it up into many pieces and sequence in parallel. It's just like parallel computing really.
It also has something to do with the way they sequence, the size of the wells and the like. Read the wikipedia articles on the various sequencing methods, that should give you a general idea.
Or post another Q on Biology, we need more next-get sequencing questions.
Gotten frustrated with a user? Want to vent? Feel like punching them?
Don't worry, here's a script that adds a "Punch" button to every gravatar. You can punch all the worst users now:
Installation
Click here to install. Will work in Chrome or Firefox (the latter requires Greasemonkey). S...
