Slashdot Mirror

I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".

This is a common misunderstanding. No one is saying "don't replace the init system" they're saying "replace it with one that doesn't try to do everything". There are lots of other good options, I'm particularly partial to runit. The init system should be pluggable, I should get a choice of which init system I want to use, just like almost every piece of software on my system.

t's impossible to do so under sysv

No, you have been able to do it even under sysv since 2004.

The fundamental design of SysV is as good as any, it just needs a new major version number update.

I positively cannot agree.

Look at some of your system's SysV init scripts, and then have a look at some of the run scripts at http://smarden.org/runit/runsc....

Is the configuration complexity you're getting from every process having its own, bespoke set of init scripts rather than something that simple -- coupled with responding to standard signals -- really buying you anything?

Pffft, arguing about changing something that hasn't broken. "Hey, my left arm works just fine, but I really think I should cut it off and get a shiny new model!"

What world do you live in where modern SysV init isn't broken?

Hell, the old approach, where everything went in inittab and then init(1) supervised processes, starting things up when they failed, was closer to right than the approach taken by "modern" distros is, where you have everyone trying their own mechanism at self-daemonization and absolutely nobody responding to SIGCHLD events.

And then you have SysV init scripts. Look at the contents of your /etc/rc.d/* directory and then compare them to the examples at http://smarden.org/runit/runsc..., and tell me you really, honestly think they're the right way to do things.

"Not broken"? Seriously, WTF.

If a daemon has problems and needs to restart itself how does it do that?

...Monit? runit? Two completely different approaches to service monitoring, one not even in an init system. And there are more (s6, daemontools, etc.).

hundreds or thousands of daemons

...What the heck are you running that puts thousands of daemons on a single server? If you're doing something this large, you might want to consider virtualization. Thousands of daemons is a gigantic attack surface to have on a single system, and a mess if something were to go wrong with one of them that takes down everything.

I'm... sorry?

You think SysV init scripts are in any way, shape or form moderately acceptable?!

I have a very simple refutation to that -- the collection of run scripts behind this link.

Go ahead -- have a look. Keep in mind that systems using those mostly one-line scripts all provide not just startup/shutdown/status, but also the ability to auto-restart on failure and lack the propensity for race conditions that pidfile-based locking almost universally used by SysV scripts is so very, very prone to.

Holding up SysV init scripts as a thing that doesn't have to be changed... it beggars belief.

I use qconfirm myself but there's also tmda and others.
*If* you are serious about getting rid of the spam then just do it. The technical part is readily available.

I deployed that almost a year ago and never looked back. I still see the occassional spam in a
mailing list folder because those go through unfiltered for obvious reasons but I couldn't care less.
My inbox has been spam-free since then and that's what matters.

I don't quite get why people are still bothering with greylisting, spamassassin, razor, dcc, bayes and
the ilk. I tried them all and they're more trouble than it's worth. You get false positives, false negatives,
it's a stupid game that you can't win.

Init being the grandfather of every Linux process on every Linux system (except in highly specialized applications), it better be simple, clean, fast and efficient. Something with an XML parser violates at least two if not three of those qualifications.

I don't think we need to stick with old fashioned init forever, though. I like some of the ideas brought up by this approach:

http://smarden.org/runit/

which is based on Daniel Bernstein's daemontools.

Amazing. I've just read four or five comments on launchd from people diminishing how boot time has been decreased (by roughly an order of magnitude, it seems) by Apple. How would you like a car that took two minutes to "boot?" Resistance to change seems to be human nature to some. The arrogance is so palpable one could cut it with a knife.

My debian linux firewall/gateway box has been booting with runit as process 1 for years. Most of the "services" on the box are controlled by runit/daemontools. It has worked flawlessly for me. launchd seems to extend this paradigm very elegantly. I welcome launchd with open arms, and I hope a debian package is available at some point. BTW, 10.4 server is using lanchd, too. This is not just for desktops.

Think about all the customers who will boot their new mac and be amazed by the quick startup. Seems like Apple has their priorities straight. It's hard for me to see a downside to faster boot. Perhaps the more anxiety-prone will wonder if something is wrong?

daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.

Brave Deian owners can apt-get install runit-run which will start your system with /sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.

And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more :-)

daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.

Brave Deian owners can apt-get install runit-run which will start your system with /sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.

And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more :-)

Gerrit Pape's runit -- an enhanced, GPL'd workalike of DJB's daemontools might be worth a gander if you haven't noticed it already.

Confirmed. I haven't had any spam since I started using qconfirm.

Rik

People wouldn't be reimplementing DJB's tools under less restrictive licensing (BSD in the case of ipsvd and runit, GPL in the case of libowfat) if he used a reasonable license in the first place, instead of giving out his software with no license to redistribute whatsoever.

I'm using runit rather than daemontools at work because we can't comply with DJB's non-license. Please be a bit more careful before calling bullshit.

People wouldn't be reimplementing DJB's tools under less restrictive licensing (BSD in the case of ipsvd and runit, GPL in the case of libowfat) if he used a reasonable license in the first place, instead of giving out his software with no license to redistribute whatsoever.

I'm using runit rather than daemontools at work because we can't comply with DJB's non-license. Please be a bit more careful before calling bullshit.

Simple: support for views, and licensing that allows redistribution.

I absolutely, positively require view support, which nobody but BIND that I know of supports. TinyDNS might, but I can't so much as consider it due to the license; we're distributing servers with a fairly custom software environment, and DJB's terms make that a no-no. (This is also why we're using runit rather than daemontools).

Support views in something that supports pulling info (not just zone info, but definition of what the zones are, what the views are, what the ACLs are, etc a la named.conf) directly from a database and I'll be happy as a clam. 'Till then, I run BIND.

The second script runs something analagous to daemontools's svscan and runs svdirs, which are obviously superior to init scripts because you do not replicate any code. All of the start/stop/etc handling is done by the process that controls the daemon.

The most obvious benefits are that .pid files are obsolete as it's obvious which process is being run by the system (as it is a child of a runsv process that monitors it) and that services can be started in parallel with dependency handling. Additionally, runit will automatically restart processes that die/crash and handle logging their stderr to rotated logfiles via multilog.

Debian users can apt-get install runit runit-run and experience this themselves. I have run runit as process 0 on my laptop and desktop machines for months and use it on servers to monitor daemon processes, it has worked without a hitch. I highly recommend it (and wish that Debian would provide more runit svdirs for daemon processes :))

I sent an email to SCO recently, they are using qconfirm which basically sends you an email asking you to confirm your email address before it will deliver your enquiry. Now, SCO probably has its reasons to use a system like that right now, but a singificant percentage of leads will probably just ignore the confirmation message, especially if they're wary of fakes like the paypal ones that are going around.

Anyway two days later and SCO still haven't bothered to reply to me so either the system doesn't work or they're too busy to be interested in my business...

1. It's not proftpd, it's pure-ftpd. 2. I don't like silly command line wrappers. 3. Only communists required you te be like everybody else

Also xinetd eats up a whole lot more memory than minit:

root 28484 0.0 0.0 24 16 ? S Jun22 0:00 /sbin/minit

Try to match that with any other superserver! Well maybe runit or daemontools would yeld close figures. I also like the way you can start and stop services.

In the example given, the spam harvester used a unique User-Agent string and a constant IP address for spidering.

It's not so easy. What you say is true, most of them use a constant IP address. But more sofisticated spammers are now using open proxies to both harvest email addresses from websites and spam referer logs. In my domain, for example, there's one guy who's trying to spam my logs since several months ago. I receive several hundred hits every day, each of them from a different IP address. He's using open proxies around the Net.

Right now, I see only two practical solutions for spam:

- A blacklist service like Spamhaus:

Pros: easy to setup, no maintenance.
Cons: some spam still goes through.

- A sender confirmation program like qconfirm:

Pros: no spam gets through, ever. Can be configured on a per user basis.
Cons: requires some maintenance, installation is not to easy as a blacklist.

Yes, not at all!

I can think of Active Spam Killer (ASK), TMDA and Qconfirm (QMail Only).

I personally use ASK and it works well. TMDA also works very well but requires complete control of your mailserver to install. Qconfirm is Qmail only .

All these are absolutely free.

The fact is, the licensing of qmail makes it a legal liability to distribute, and is avoided by groups like Debian and RedHat. I have no hate for qmail but let's get our terminology right.

Wrong. Again, more FUD. It is perfectly legal to distribute qmail if the binaries match his. He does this to promote compatibility. Debian does not distribute qmail because it is not Free Software, not because it isn't Open Source. Find out exactly why qmail is not in Debian as a binary package. qmail is in Debian non-free as a source package.