back to article Linux greybeards release beta of systemd-free Debian fork

The effort to create a systemd-free Debian fork has borne fruit, with a beta of “Devuan Jessie” appearing in the wild. Devuan came into being after a rebellion by a self-described “Veteran Unix Admin collective” argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected …

I love Linux, but I hate the boring, predictable responses to changes major or minor that pervade the mindset of a whole bunch of my fellow enthusiasts. Systemd is a positive for me. Sorry (not sorry), but it is.

I'm not a massive fan of Lennart or his attitude, and I dislike the tendency toward feature creep (but I turn those features off), but a supported init system that has at least the intention of integrating well, and which has support and inertia is a good thing for Linux. Sorry (not sorry), but that's how I, and obviously a majority of maintainers, feel. Let's face it, systemd isn't just popular because of Red Hat. It's popular because it works better than anything else.

From my perspective, the systemd situation exemplifies one of the major advantages and two of the major problems with Linux and other FLOSS. The major advantage is that anything can be forked. Which is great, and how it should be.

But then, moving to the problems, anything can be forked, and people use that freedom to try and fork things at the slightest provocation (like LibreSSL, which was founded with a stated purpose and has arguably failed to live up to that intent). Alright, an in init system is a big change and therefore not technically "the slightest provocation", and Devuan will probably just fall into the category of minor distros that have crappy maintenance and flounder for a while before failing. But the failure of a minority to get on board with changes that distros have made because the maintainers see the benefit highlights the other problem with Linux and other FLOSS: the almost Luddite resistance to change that we see now, and we saw in PulseAudio, that has you banging your head on the table and wondering if everyone who refuses to use anything new still walks around with a Nokia 5110 in their pocket and has a rotary phone on their landline. You know what I put this down to? I don't want to change and I don't want to learn.

But yeah. Enjoy your "freedom".

25
72
Linux

It's popular because it works better than anything else.

If this were true, I would expect the BSD distros to consider it and they couldn't be bothered with systemd. In my view, it's "right tool for the right job" and systemd certainly makes some sense on desktops (especially if using GNOME) but I can hardly understand how it could be considered as "working better than anything else" for servers. Specifically, my biggest gripe is the lack of feedback/console logging after issuing a service start/stop/restart/reload action. There are others to be sure (like the NTP tirade that some have voiced).

As you point out, choice is a good and healthy thing and I'm glad that some choices are still available. But those choices are shrinking with so many distros on the systemd train. It's not about not wanting to learn, but far more about suitability and there should NEVER EVER EVER be a one-size-fits-all solution. If I wanted that, I would use Windows.

60
5
Silver badge

"...there should NEVER EVER EVER be a one-size-fits-all solution. If I wanted that, I would use Windows."

At the moment the one size fits all Windows isn't fitting anyone.

49
1

BSD isn't a great example of how an OS should progress. It has neither the market share or manpower to even maintain the kernel for new hardware, let alone make a change as drastic as an init system. Let's face it, Linux rules the server market, Red Hat rules the Linux server market, and as much as you might dislike Poettering or systemd, Red Hat aren't going to start taking something as drastic from upstream as an init system change without it benefiting their core market. They know where the majority of their money comes from.

Most of the problems with systemd stem from not knowing or not caring about how to use it. I don't have issues with the amount of information I can get from journalctl. I haven't not been able to debug any issues with systemd. In fact, it's been a lot easier, because I only have to look in one place, and I get relevant targeted information.

There's actually about 70 Linux distros that don't use systemd. But they will all have key software in common to which there is no alternative. And even if a distro does use systemd, that's just the init system - and a lot of work has gone into backward and cross compatibility. Look at the way Debian has implemented it. It's actually awesome. It'll only be like Windows when a single company maintains a single solution incompatible with other distros that uses only its own closed source, proprietary software to do the job.

18
28

FWIW you can downvote me all you like. Just because you disagree with what I said, that won't affect either the truth of what I'm saying, systemd's market share or its position as the default init system, Red Hat's popularity or massive contribution to FLOSS, or the fact that no other init system - not OpenRC, Upstart, Runit - has garnered the support or gained enough inertia to take SysV's place as the standard.

8
50
Devil

"systemd isn't just popular because of Red Hat...."

Actually, it's popular because of the so-called "Linux Standards Base", which was a circlejerk between RedHat, Intel, and Microsoft.

The intention was to create "binary-compatibility" within Linux, so that proprietary, closed-source software (and, presumably, malware) would have an easier time. It's completely contrary to what GNU are trying to do, and for this reason, Debian was late (or not invited) to the party.

LSB standardised a lot of things, and it all came from RedHat.

This is why, for example, that MeeGo (which is the abomination that replaced Nokia's Maemo OS) went with RPM instead of DPKG (deb/apt) for package-management, because RPM is specified by the LSB.

That doesn't mean that RPM/Yum is better than DPKG/Apt. It just got standardised by the LSB.

Consequently, Debian and Ubuntu are "non-compliant" until they adopt RPM format. They are fudging it with 'Alien', but eventually Debian will die thanks to the LSB.

Personally, I would love to go back to a time before Systemd. It has given me nothing but problems.

I also, for a while, used Trinity - a backport of KDE 3.5 onto QT4. I stopped using it when KDE4 became stable and usable.

Now that Plasma5 is being forced down my throat, with a shedload of bugs, I would love a backport of KDE4!

Next you'll be telling me to move from X11 to Wayland.

31
12
Silver badge

"It's popular because it works better than anything else."

For you, perhaps. It doesn't necessarily follow that it works better for everyone else. Linux server installations still outnumber desktops and laptops by a long shot. How popular is it with server admins? I suspect not so popular.

39
3
Anonymous Coward

Perhaps you were downvoted

because you mentioned RedHat rather than Ubuntu?

To the hard core anti-redHat (because they make money from free software??? or because systemd came from them?) brigade only Ubuntu or for the really hard core, Debian are where it is at.

Some will even say that there are more Ubuntu servers on the internet than RedHat ones.

Personally, I got fed up with Canonical some years ago and have not bothered with anything they release since. So, for me, the goto distro of choice is CentOS 6 (no systemd) and will remain so for a few years yet.

and, my beard and hair are very grey.

23
3
Silver badge

"Red Hat rules the Linux server market, and as much as you might dislike Poettering or systemd, Red Hat aren't going to start taking something as drastic from upstream as an init system change without it benefiting their core market."

That would be the core market which they can supply with the systemd-free RH6 and earlier. AFAIK pre-systemd SEL is coming to the end of support. That leaves Red Hat with the only commercially supported systemd-free product. Having your cake and eating it?

5
1
Windows

Nokia 5110

As a matter of fact, I do still use a Nokia phone.

I never bought a smart phone, and now prices are tumbling while hardware specs have flat-lined.

But you know what, I'm going to put it off a little longer, because I feel smartphones are not quite "there yet".

6
6
Silver badge

systemd is all about making GNU/Linux the new POSIX

>If this were true, I would expect the BSD distros to consider it

Uh no. Red Hat went out its way to make systemd Linux only and through very strategic placement in some major projects (the udev dependency changed everything) got it in the dependency web so it will make more and more FOSS over time largely Linux only which guess who sells the most maintenance contracts for? Take a look at how much work it is already to port Gnome (another project Red Hat has their hooks in deep) to any other POSIX.

16
0
Silver badge

Also systemd is the svchost.exe for Linux

Title says it all.

27
2
Devil

Re: Perhaps you were downvoted

Blarg. I knew that Ubuntu were the reason that systemd got forced into Debian, but I wasn't aware they were part of the whole LSB madness. I'd have thought that would be shooting themselves in the foot, given that their strength comes from Debian. If they really threw their weight behind LSB, then they would have to ditch APT/DPKG in favour of Yum/RPM.

But I wouldn't put that past Shuttleworth & co.

Personally I've only ever used Debian, since before Ubuntu was a thing, but neither my beard nor my hair are grey (yet).

Hard-core anti red-hat not just for systemd, but for LSB as a whole. The money from free-software thing only partially - everyone has to make a living - but I tend to distrust those with an axe to grind, especially when it has negative impacts on MY software @:

And that applies just as much to Canonical too.

6
2
Silver badge

Re: Also systemd is the svchost.exe for Linux

Systemd and the rest of the Freedesktop.borg is basically making Linux windows lite. Honestly I don't like it but have accepted it as Red Hat write a lot more code than I do. It does play much better on most hardware for non server roles than say FreeBSD (laptop suspend and resume good luck with that one) and Linux one killer feature for many home users is Steam which runs like shit emulated on FreeBSD. More and more it just works even for Grandma. That said I still do my banking using OpenBSD and do what I can at work to discourage its use in mission critical server roles (fsck SELinux also which exists to silently fsck you over instead of the bad guys). POSIX is all but dead with proprietary UNIX dead. Sigh.

8
3

"Most of the problems with systemd stem from not knowing or not caring about how to use it. I don't have issues with the amount of information I can get from journalctl. I haven't not been able to debug any issues with systemd. In fact, it's been a lot easier, because I only have to look in one place, and I get relevant targeted information."

I find it hilarious that people are downvoting you to hell when you are completely right. Redhat wouldn't have done this if there wasn't an identified need and desire.

I can't yet use systemd as fluidly as I can init scripts, but as you said, that's just due to lack of familiarity. As a concept, I consider systemd to be infinitely simpler and cleaner than a cacophony of init scripts, that need to be manually debugged when something strange goes on.

Other people claim to have run into problems getting systemd to handle logging 'n whatnot. I dunno what they're doing, but I have so far moved the majority of our linux servers to systemd based distros, and I haven't had a single problem yet.

Individual daemons should not be responsible for maintaining their own security contexts. That's why things like SELinux exists (although the vast majority of people find it "too hard" and just shut it off). Yet daemon-provided init scripts have to manage things like making sure the daemon runs as a non-privileged user. With systemd, this kind of management is now a core part of the OS, like it should have been to begin with.

4
18
Gold badge

Re: Perhaps you were downvoted

"I knew that Ubuntu were the reason that systemd got forced into Debian, "

S'funny what different people know. I knew that Ubuntu wanted to stick with upstart but were strong-armed into adopting systemd because the Debian community had a big vote and systemd got more votes than either upstart or "stick with the present system".

Mind you, I also knew that Devuan posted a formal notice around March time that they were abandoning the whole project because of lack of interest, so this article surprises me too.

12
1
Trollface

FWIW you can downvote me all you like.

OK.

12
2

Specifically, my biggest gripe is the lack of feedback/console logging after issuing a service start/stop/restart/reload action.
It gives the same or more feedback as sysvinit.

0
1

Re: Also systemd is the svchost.exe for Linux

Title says that you don't understand what systemd is.

Please give one feature that is the same between svchost.exe and systemd.

2
8

Re: Perhaps you were downvoted

I knew that Ubuntu were the reason that systemd got forced into Debian,

But that is the opposite of the truth. Ubuntu (as represented by Ian Jackson) wanted Debian to use upstart. When Debian chose systemd that forced Ubuntu's hand.

3
0

Other people claim to have run into problems getting systemd to handle logging 'n whatnot. I dunno what they're doing,
Mostly they're just lying trolls.

2
10
Anonymous Coward

http://without-systemd.org/wiki/index.php?title=Arguments_against_systemd&oldid=778

1
1
Silver badge

Re: Also systemd is the svchost.exe for Linux

>Please give one feature that is the same between svchost.exe and systemd.

Written by someone much more elegant than me - http://www.infoworld.com/article/2608798/data-center/systemd--harbinger-of-the-linux-apocalypse.html . Basically its less about features and more about similarity in design and philosphy. The apocalypse came and still kind of sucks but far less than using the spyware pretending to be an OS that is Win10.

3
1
Silver badge

>That's why things like SELinux exists (although the vast majority of people find it "too hard" and just shut it off).

Funny how that happens after you spend nearly a day diagnosing why a user can't run X apps remotely through ssh and then find out SELinux is silently not allowing sshd access to .Xauthority (not an admin but do help users around my workplace alot). Failing shit silently and in weird ways and wasting users time is why SELinux sucks balls. Yes maybe for an out of the box internet facing server I can see its use but even then you are most certainly better off using OpenBSD whose developers also believe code correctness in a tightly audited base along with proper UNIX permissions and best practices beat the shit out of bolted on RBAC systems which generally just end up locking the door after the horse as bolted and fsck over normal users 1000x more often than the baddies.

7
0

Re: "systemd isn't just popular because of Red Hat...."

>This is why, for example, that MeeGo (which is the abomination that replaced Nokia's Maemo OS) went with RPM instead of DPKG (deb/apt) for package-management, because RPM is specified by the LSB.

Pardon?

My N9 runs Meego and applications are installed from .deb files. Have I missed something fundamental about RPM and dpkg?

1
0

Re: Mostly they're just lying trolls. (@Ken)

I rid all my (personal) Debian machines of systemd (then later switched them to Devuan when it became available, a year ago or so) because I ran into a flurry of problems, mostly with hardware. Most of the problems were caused by systemd itself (some were, notably on older hardware) but what was caused by systemd is that a wonky USB peripheral could bring the whole system down by crashing the init system, which is, simply put, unacceptable in this day and age.

6
1
Silver badge

> Most of the problems with systemd stem from not knowing or not caring about how to use it

I think that's a little unfair, but, that said, the very presence of systemd on a system can also lead to a systemd blinker coming down when troubleshooting.

I actually spent some time dealing with an issue earlier. For some reason systemd-udevd had started deciding to rename a NIC from it's configured name to "rename2".

I'm sure Lennart's ears were burning for a little while, until I looked a little closer and remembered what fuckwits Realtek are.

The NIC in question is part of a bond, and on the reboot just before the issue, systemd got impatient waiting for the network to come down cleanly, so just shut it off. On boot, the RTL driver reads the MAC from the NICs volatile storage (instead of the PHY) so got the bond's IP instead, which of course matches the other slave. So two NICs matched the same udev rule...oops

Blaming the (sometimes) clusterfuck that is systemd is too easy and rarely solves the problem itself.

But systemd isn't faultless either, just as some distros managed to ship flawed selinux configs (apache context? Nah, won't need /var/www/html). It's got it's problems and journalctl is a fair example (system hung and want to know why? Sorry the binary log is corrupted). Being able to pass through to rsyslogd is a bandaid not a fix for the issue

Or, as others have pointed out, the NTP issues.

5
0
Silver badge

@ Ilsa Loving: Doesn't systemd make log files binary, in which case it is not a lack of familiarity but rather it does stupid useless shit. grep or awk your binary log file? Tail it? No, chances are there's some reinvented wheel command to perform each action.

5
0
Anonymous Coward

@John Hughes - Re: Also systemd is the svchost.exe for Linux

Erm, feature creep for example ?

4
0

Re: Also systemd is the svchost.exe for Linux

And, if you read that screed you find that the similarity is "I don't like systemd, svchost is bad, therefore they are the same":

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want.

A totally unsupported fact-free assertion.

What is the similarity of design between systemd and svchost.exe?

1
8
Silver badge

Re: Perhaps you were downvoted

"But that is the opposite of the truth. Ubuntu (as represented by Ian Jackson) wanted Debian to use upstart."

And the systemd promoters couldn't allow that to happen. Not that a choice between systemd and upstart is one I'd want.

1
0

Regarding Lennart

The man destroys more value than what he creates. He breaks things, and then blames everyone but himself. In short, he is nothing less than a vandal.

7
1

Systemd doesn't have enough popular support to replace SysVInit, either. It has a more widely installed base, at the moment, but only because RedHat's goons strategically placed dependencies in completely unrelated software so as to cause systemd to be brought in at system installation time.

The vast majority of Linux machines are run and/or owned by people who wish systemd had never been written... and frankly, that Lennart the vandal had never got his hands on a computer, ever.

5
1

Re: Also systemd is the svchost.exe for Linux

Sad, but true. RedHat and Shuttleworth are basically trying to destroy any non-commercial Linux distros.

0
1

"I can't yet use systemd as fluidly as I can init scripts, but as you said, that's just due to lack of familiarity."

And you never will. SysVInit is easily comprehended with less than a page of documentation. It does ONE THING -- it stops and starts deamons.

In contrast, systemd requires HUNDREDS of pages of documentation, and Poettering and his crew of asshole vandals presume that they know how to do EVERYTHING, such as mountd, better than the mountd subject-matter experts. And whenever their code causes some problems, the excuse is always the same --- "XYZ's code is broken" -- not only with system, but with earlier projects these jerks have worked on as well.

I am so glad that Linux called them out on that bullshit, when they were doing incredibly STUPID things in the kernel to cover up for the fact that systemd was spazzing out.

There is some very serious Narcissistic Personality Disorder, if not full blown Borderline Personality Disorder going on with that crew.

8
1

Yes, because when a well-understood, imperfect, but robust system is FORCIBLY replaced with a brittle, fragile, overly complicated, MORE IMPERFECT system which, which immediately commandeers cgroups for itself so that cgroups is unavailable for apps, and which fails to even meet a single one of its publicly announced design goals, run by a software team whose answer to anything is "you people suck!" and "you haven't read the 1000 pages of documentation" and "I'm not breaking things --- EVERYONE ELSE'S PROGRAMS ARE BROKEN! NOT MINE! NEENER NEENER NEENER!", yes, indeed, the response IS predictable.

Why would the response to this steaming pile of s h i t be any different? Why SHOULD it be any different.

A replacement for SysVInit should be an IMPROVEMENT, not shoehorning some Frankenstein's Monster sort of C:\Windows\svchost.exe into Linux

If you can't see the myriad problems with systemd, and don't understand how systemd is a step backwards on the level of going to the pre-MULTICS days of OS/360, then you're either too wet behind the ears to appreciate what's actually going on, or too stupid to ever comprehend what's really going on.

7
1

"I don't have issues with the amount of information I can get from journalctl."

You've never had a system get horked so badly that journalctl wasn't available, resulting in having to parse the damned thing using od(1), more(1) and much much much more wall-clock time than was in any way reasonable.

Clue for the clueless -- BINARY SYSTEM LOGS ARE BAD, M'KAY.

G o d d a m n, some of the people posting here are utterly fucking stupid and too short for this ride.

5
0

Re: Mostly they're just lying trolls. (@Ken)

Ok, that sounds frightening.

What's the bug report#, I'd like to see what was happening.

0
0
Silver badge

Re: Also systemd is the svchost.exe for Linux

>What is the similarity of design (and philosophy) between systemd and svchost.exe?

Sorry in advance for length. Stolen from http://forums.funtoo.org/topic/626-my-2-cents-on-systemd/page-5 but hits my points better than I could.

"It's simple really: systemd is wrong for Linux.

It may be right for something else, but not (default) Linux.

It violates the "UNIX Philosophy", which is best summarized by the famous quote from the inventor of the UNIX-pipe, McIlroy:

Quote

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

This is important for very many reasons.

If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. This results in that if any of those sub-functionalities "goes nuts", even if it's one that the user does not care about at all, the entire process with all its hosted sub-functionality is immediately affected. Also made obvious by the svchost.exe example is how it makes granular permissions management impossible even with third party tools like anti-virus and firewalls as if you have even ONE svchost.exe sub-functionality requiring network access to do its job, you must grant network access to the entire process and thus to everything else hosted by the same binary and this can lead to very undesirable security implications.

I use svchost.exe as the example because we Linux- (and UNIX- in general) users used to laugh at Windows' poor design in this regard for these reasons... but now when Windows is moving more and more away from this design, Linux is moving to it.

What's even worse is that there used to be several alternatives to chose from regarding system init provider, but now there are only two main ones and one that is being migrated away from, so if any major flaw is discovered in for example systemd, there is now effectively only ONE choice left.

With software now increasingly being made specifically designed for systemd, they build bi-directional dependencies so that the user can not really choose individual components anymore, which again can cause very bad security results as well as very much waste in system resources.

Imagine for example if there is a bug that causes the boot process to take half an hour each time using systemd and OpenRC can't be used because the core functionality of the system specifically depends on systemd... This can cause very expensive fines for corporations with Service Level Agreements to honor.

The migration to systemd results in user-unfriendly, bloated, unnecessarily restricted and potentially very costly systems.

It could be AN option, but should definitely not become the ONLY option as it is becoming now.

If you want a Windows/Mac-like system where the user is put out of control through the assumption that the programmers will be able to predict every usage scenario and never write flawed code so no options are needed, then it should be considered as an option.

I could go on, but I fear I have already passed the wall-of-text/TL;DR-threshold.

P.S.: The example scenarios in this post are all ones that I have personally encountered, so not at all hypothetical."

4
1

This post has been deleted by its author

Silver badge

Re: Also systemd is the svchost.exe for Linux

>If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. (ie - Grouping multiple services into a single process conserves computing resources However, if one of the services causes an unhandled exception, the entire process may crash.)

And this is the crux of his argument (though I admit spelled out implicitly). PID 1 is special (it can't fail or your system shits itself) and should being doing as little as possible not as much as is possible. The following link shows what can go wrong with having a kitchen sink PID 1 - http://blog.darknedgy.net/technology/2015/10/11/0/

2
0
Silver badge

Re: Also systemd is the svchost.exe for Linux

Credit due to http://ewontfix.com/14/ - for the idea Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies.

1
0
Silver badge

Re: Also systemd is the svchost.exe for Linux

In fact http://ewontfix.com/14/ for the high level overview and http://blog.darknedgy.net/technology/2015/10/11/0/ for the down and dirty details do more to explain why systemd design is fundamentally broken than almost anything out there.

0
0

Re: Mostly they're just lying trolls. (@Ken)

> What's the bug report#, I'd like to see what was happening.

I filed a few, back in the days (that was a few years back). On older hardware systemd was just assuming too much, that _could_ have been dealt with by configuring it better perhaps, too much effort for no added value compared to just wiping the whole damned thing. On more modern machines, touchpad or mouse transcient misbehaviour would cause a system freeze for example. Power supply wonkiness, idem (on machines with built-in batteries!). Slightly wonky network adapter? Down she goes! Etc...

Basically having PID1 take charge of extremely high-level roles is the stupidest design choice ever. Gremlins do happen, and when they do the last thing you want is PID1 dealing directly with them. Specialised tools designed by experts in that precise area with well-documented error codes is the way to go. "look 'ma, I can do it all, no hands" clusterfucks like systemd are the way to downtime.

2
0
Silver badge

Re: Also systemd is the svchost.exe for Linux

There you go John Hughes satisfied? Took a fair amount of work but I still stand by statement. Assuming no other post from you at this point so consider this the mic drop.

0
0

"because it works better than anything else"

Until it doesn't, when you are completely in the shit.

1
1

In days of yore

In days of yore I helped develop the initial version of OS/360. systemd

corresponds to the portion of OS/360 known as the Master Scheduler. All of the

rest of OS/360 had to conform to the specs laid down by the Master Scheduler

just as systemd tries to force the rest of GNU/Linux to conform to the systemd

specs. The difference is that the Master Scheduler was designed before the rest

of OS/360 and systemd is an add-on afterthought. That is why systemd is such a

design mess and why the systemd designers rail at the stupidity of

other GNU/Linux designers for not anticipating the systemd specs 10 years ago.

----------------------------------

Steve Stites

1
0

Init freedom

You have "init freedom" as demonstrated by your new distro, easily created with your favourite init system. Other people exercise their "init freedom" by choosing to use systemd. And others are aware they have an "init freedom" but are unsure how best to use it so they stuck to what they knew.

In short, some people didn't like a new feature so they used the free software to make a version they were comfortable with. This is perfect, however much you do or don't give a shite about systemd, you have to love that people have the tools to do what they want.

Not sure it is "news", but then El Reg has the freedom to decide what it calls news, not I.

14
4
Anonymous Coward

Re: Init freedom

Not sure it is "news"

Well, yes, but your comment wasn't a summary of the article.

The "news" aspect that you think is missing, was that they've released a beta version. The other fluff is for people who haven't kept up with these things.

16
0
Silver badge

Re: Init freedom

Well, to me it is news - I regularly give money to Devuan and it is good to see the fruit of this work.

29
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018