It's not a question of

Story: Should Debian be forked because of systemd?Total Replies: 15
Author Content

Oct 21, 2014
1:02 AM EDT
If you think the fork is necessary, and you care enough about it, then GO FOR IT. That's how Free/Open Software works: those who can do, decide what gets done.


Oct 21, 2014
9:50 AM EDT
What i find incredible is that if you tried to get a massive new system into the kernel Torvalds would demand that you develop it fully and knock the kinks out on a parallel source tree.

As such, the Systemd proponents at Debian are the ones that should do the forking. And build a variant of Debian with Systemd as the init etc. Thus showing that the packages and such work before being moved over into the Debian tree proper.

Oct 21, 2014
11:26 AM EDT
I guess there will simply be another long Debian "freeze" cycle to work all the kinks out before it's considered "stable".

Oct 21, 2014
11:49 AM EDT
@750: Agreed. What corporate developer would be able to promote something to a production system without fully testing it and showing that it's stable. It seems to be a lot easier at Red Hat than I would have thought. (Some might say that systemd should still be in 'Rawhide', if RH still has that development process.) I am finding myself more and more agreeing with those that feel that systemd is too monolithic and taking on too many additional functions to be stable in the long-term. The worst thing is that other userspace applications will require systemd and new application development will force the use of systemd. Even if SYSV init has been working for you perfectly well.

For me, this will be much like the decision at the major Linux distributors to force users to use CUPS for printing when there were already perfectly fine printing applications available. Select a word processor and you find that CUPS is a required subset. The user is not required to install just any printing subsystem, it must be CUPS. Not lpd, not LPRng, only CUPS. Why?

Linux users want to have the final say in what software runs on their system. Slowly but surely, it seems that that say is being taken away from them.

Oct 21, 2014
3:13 PM EDT

>> I guess there will simply be another long Debian "freeze" cycle to work all the kinks out before it's considered "stable".

In a similar manner, I guess that many Debianistas will simply stick with their non-systemd Wheezy FAR PAST the end of the unfrozen new and "improved"(right, with ::rolling eyes::!!) Debian stable.


Oct 21, 2014
3:23 PM EDT
That's what I'm planning to do, Fluff. Just like I did when KDE4 was rolled in.

Oct 22, 2014
1:08 AM EDT
@750: The development model of the kernel is vastly different from the development model of a distro. Non sequitur.

Oct 22, 2014
10:43 AM EDT

CUPS saved me hundreds of hours in debugging printer problems. The ubiquitous web server at port 631 is a real lifesaver and allows me to remotely fix print queue problems. It's truly one the clear bright stars coming out of Apple to the FOSS world. Surely you can't be serious that CUPS was a bad move. I would personally love to see xsane merged with CUPS. That way maybe I could actually use the single button scan options on my flatbed scanner. Although the network options in xsane do allow a nice network scan experience... but, oh! to have it all sitting there in front of me on port 631. That would make my day!

'Linux' users always have the final say in what runs and what doesn't. GNU/BSD/Linux users do too.

If you, as an end-user wish to run lpd instead of CUPS -- you can certainly do that. It may be tons of work -- but FOSS is about the freedom to use the source code -- not the freedom to have a ready-made, binary packaged, pre-built, nicely integrated -- but also custom tailored -- platform.

There's a saying... beggars can't be choosers... If you're a FOSS free-loader, you get what you get... if you've got the time, skill set, or money to play the game... fork it!

Oct 22, 2014
1:30 PM EDT
> That way maybe I could actually use the single button scan options on my flatbed scanner.

sane does support button scanning options I believe via saned. You do have to switch it on though.

Oct 22, 2014
2:27 PM EDT

Nope. There is a secondary library+service required...

The fun part is: "If you are lucky, your scanner might work almost out of the box and you would only want to modify the action scripts, which define what is done when a particular button is pressed."

This never happens - unless you happen to have the precise scanner the scanbd developer has...

...And this is the sort of issue I had with printing before CUPS. However, CUPS eliminated the need to understand print driver files in microscopic detail... and printing suddenly became very easy, so that actual productive work could be done.

Oct 22, 2014
3:18 PM EDT
One problem I have with the CUPS Web site since Apple took over is the description:

"CUPS is the standards-based, open source printing system developed by Apple Inc. for OS X® and other UNIX®-like operating systems."

The implication here is that CUPS was developed by Apple and was originally targeted at OS X, which is certainly not the case. CUPS is currently being developed by Apple and targeting OS X, which could be another interpretation of this sentence. However, it seems to me that it is intentionally worded in a way that most would misinterpret it, so it can seem that Apple is totally responsible for CUPS. I used CUPS before Apple took over, and while Apple has done a fine job with it since they took over, there is nothing about the direction that seems out of line with what was happening before they took over (though development may have sped up, which is a good thing).

I don't like to complain about Apple's stewardship of CUPS because I think they're doing a great job, but why do they always seem to want to take credit for every computer technology ever developed?

One thing I will say about CUPS is that it is portable and standardized and its developers don't try to make other programs dependent on it; they just try to make it work really well. I wish I could say some of these things about systemd.

Oct 22, 2014
3:33 PM EDT
Apple? Self serving? I'm aghast!

Oct 22, 2014
4:17 PM EDT
> Nope. There is a secondary library+service required...

My mistake, I meant scanbd not saned (which is for network scanning of course.)

Oct 22, 2014
4:26 PM EDT

I think you are conflating two things here:

1) CUPS is well written and APPLE are presumably putting a lot of time and effort into making it work. That's great. I wish more developers/money/time was put into these things particularly by the hardware manufacturers that are ultimately responsible for their hardware working with software. Windows printing works well because the printer manufacturers can be ar*ed to write decent drivers for Windows. Most drivers for scanners and printers are written by unpaid amateurs despite many manufacturer's best interests to prevent them, jealously guarding their protocols (although the situation is improving somewhat).

2) That CUPS has a web browser is not a problem in itself. Good design would suggest that the CUPS web browser could be packaged separately and interact with CUPS using the same well defined interface that is open to everyone else, ideally an interface that could be designed to be compatible with other print system implementations. That's good modular design surely? I have no idea if that is the case here but it would seem to me to make sense.

Certainly, for the web portion, I'm a big fan of the implementations like webmin which try to add GUI convenience without stamping all over the components that they are trying to support. Webmin modules are modular in design, conform to a defined standard, and interact using well-known (i.e. not backdoor) interfaces. It also means that you don't have to rewrite a lot of code to implement it.

The objections to systemd are not related to the quality of the code itself, or of the documentation. It is the pervasive nature of the implementation.

Oct 22, 2014
5:23 PM EDT
> That CUPS has a web browser

News to me. My installation of CUPS has a web server (yeah, picky, picky...).

And I suppose the CUPS http interface could be a built as a CGI process running on the system's httpd (Apache, etc) if the system's so constrained that yet-another-daemon is a problem (though running its own httpd on-demand via x/inetd-with-wrappers might be more practical -- since it's already selective in who it'll take orders from, unlike the usual Apache installation -- unless you're trying to conserve disk space as well).

Oct 22, 2014
5:28 PM EDT
> The objections to systemd are not related to the quality of the code itself, or of the documentation. It is the pervasive nature of the implementation.

And the fact that so far it doesn't seem to be interested in stopping that mission-creep anytime soon.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!