[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Dec 2014 22:38:36 +0300
From: "(GalaxyMaster)" <galaxy@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: owl-startup
All,
Sorry for a lengthy response -- if you don't have time: the last
paragraph has the message I tried to convey.
On Sun, Dec 28, 2014 at 04:28:44PM +0300, croco@...nwall.com wrote:
> On Thu, Dec 25, 2014 at 07:49:08AM +0300, (GalaxyMaster) wrote:
> > On Mon, Dec 22, 2014 at 03:22:32AM +0300, croco@...nwall.com wrote:
> > > hour, then, the problem is not with me but with the distro), I can't launch
> > > nor stop daemons, and I CAN'T VIEW LOGS!!! It was the first time in 20+
> > > years of my personal Unix experience when 'less /var/log/messages' gave me
> >
> > Well, this just means that you didn't install a syslog daemon, why blame
> > some developer for that?
>
> If I install syslogd, I know what I do and as the immediate consequence I
> don't expect 'less /var/log/messages' to work; furthermore, once I
[skipped]
> In the abovementioned situation, I never asked anyone to take my logs away
> and, more importnatly, I gained NOTHING I need, only the trouble.
I think you've missed the point: journald works _together_ with a syslog
daemon. If you don't run a syslog daemon, then you have an option to
have binary logs only (through journalctl), however, most people are
using syslog daemons to get textual logs.
> Well, here is what I consider THE wrong thing: if you look at your text
> again, you can notice that *YOU* try to convince *ME* that there's a
> problem with LILO which is so serios that definitely I should move from
> LILO to something else, and, hence, you (or someone else, this doesn't
> really matter) have the reason to replace the boot manager (or any other
> thing) and *FORCE* me to move -- for my own good.
I'm not forcing anyone, I just replied to your argument re: the stable
and proved bootloader solution showcasing why other bootloaders are
safer on a production system. BTW, one of the reasons we included
syslinux (in addition to making our ISO be a bit more modern) was that -
it's just safer :). However, if you want to play with matches it's you
right :).
> weird reason. So, for me the trouble that you explain simply doesn't exist
> and definitely doesn't need any solution: solving unexisting problems is in
It should be great to have such a smooth experience :). In my humble
15 years of systems administration I stumbled upon a dozen situations
when LILO was broken in non-deterministic ways or had bugs that were not
compatible with the environment. In any way, I see no point of
discussing personal preferences here. The topic I raised was about the
general direction we want to move to.
> > Anyway, this is irrelevant to the discussion.
>
> This is relevant, as the situatioin with systemd is generally the same,
> only it makes a lot more troubles.
I'm currently managing 100+ CentOS 7 VMs with systemd and see no
troubles or anything like that. So, it's a matter of perspective :).
> > You are using quite strong words, but just try to look from the other
> > side:
> >
> > * we claim to be RH compatible, but our compatibility is lacking and
> > behind like 8 years or so;
>
> So don't claim this any longer, that's all.
If we don't and if we do not provide compatibility, we are as good as
dead. Our packages repository is way too small and the ability to
"import" packages from a bigger distribution as easy as possible is the
lifeline our distribution requires.
> > * there is no active development going on and the option of installing
> > packages from other RPM distros is getting more and more unrealistic
> > since everybody else has moved on (much newer glibc, systemd
> > dependencies, etc.);
>
> Sure. Actually, I never had any success with installing RPMs from other
> distros under Owl and I was always confused with statements of such
> possibility. To my mind, Owl is way too different to make anything like
> that possible.
I (and AFAIK, Solar) was using some Fedora packages in the past (circa
2006). Since then things moved forward in other distros a lot, so yes,
we can't install anything from recent releases of CentOS and/or FC.
There is also the enterprise market and applications designed for RHEL.
This is the part we are starting to lose (the commercial, binary-only
packages start to move to RHEL 6/7). As an example, about 6 years ago I
was able to install Plesk on Owl (I believe I documented it here at the
time) and it was not hard, no it would be.
> > * it would be great to use Owl as a server VM distro on cloud providers,
> > but we don't have Xen support and DHCP client out of the box, so most
> > popular Clouds like AWS and RackSpace are not available to us out of
> > the box;
>
> So add them as packages, wy not? And what does all this have to do with
> systemd?
It's quite simple - there is a trend with the major distributions and
there are current solutions and practises on how a typical Linux
distribution is evolving. Since systemd is at the core of the
initialisation and process management the decisions on how to build a
system are different for distros based on systemd and for those which
are not. I can accept an opinion that systemd is "evil" and that Owl is
not going to use it, however, whoever pushes it should also contribute
man power to keep Owl floating against the trend. The amount of work
required to fight against the trend is huge and I fail to see this
effort to succeed. We don't have enough man power to do an obvious
(from the distribution going forward point of view) update of our glibc
package.
> > All in all, the original idea is indeed great, but if we do not invest
> > into moving the project forward I think we will lose whatever userbase
> > we currently have.
>
> This is entirely another problem. Definitely it exists.
Here I disagree that it's a different problem and I tried to explain my
point of view above.
> If we do the same things the other distros are doing, then there's no point
> in having an own distro: it is easier just to use other distros.
It's not "everything or nothing". The core values of Owl is that we
keep to the principle of the least privilege (we are one of very few
distros which does not have SUID binaries), we also put a lot of thought
into the default configurations, do audits and fix insecurities other
distros do not care about (e.g. insecure use of /tmp, etc.).
However, somethings should be the same architecturally otherwise we are
risking to be alone and incompatible. This is not an issue if you have
enough funds and fully paid staff to do that, but we have neither, so we
need to compromise.
> No, not a lot of people. As my experience shows, there's usually one or
You refer to your experience a lot, but, unfortunately, I didn't have an
opportunity to work with you on any large scale project, so I can't
trust you on just your word. I was monitoring the systemd flame wars
for a while (a couple of years, I think) and there are as many
supporters as opponents. If you think that a company like Red Hat goes
to switch to a different "initialisation platform" only because nobody
cares, you are wrong. There are many features systemd provides which
were long time waited (e.g. resource limiting using cgroups, etc.) --
yes, the implementation is imperfect, but... Work on it to improve,
influence by submitting patches, etc - a simple denial doesn't make any
good.
> > already switched to systemd: RH (RHEL, FC, CentOS), SuSE, Arch, ALT.
>
> I know. They are now out of my consideration -- unless they get rid of
> systemd again, they are absolutely useless for any purposes I have.
I envy you, really. I'm having hard time to sell Owl as a platform to
the SMBs here in Australia due to the effort required to support Owl
instances (we don't have Ruby and we don't have compatibility with
anything modern, hence Puppet and Chef are out of the question, and even
if we provide Ruby, we don't have a high level package management with
remote repositories so these configuration management tools would be
almose useless). The modern world systems administration is no
longer just about tinkering on servers in command-line, but deploying
tens of VMs using configuration management, CI (e.g. Jenkins), etc. and
Owl is simply falling behind.
> > The list is much longer, but the first two are what enterprises are
> > mostly using (at least here in Australia and in the United States),
> > others are extremely popular for home enthusiasts.
>
> The most popular operating system is still Windows; the vast majority of
> computer users (even Linux users) nowadays strongly bind the notion of
> 'file' with a pictogram that appears in GUI, and tend to panic when they
> see command line. Should we add X Window and all these GUIs to Owl, then?
> Nonsense.
Hmm, I'm trying to make a point and you are practising in sophism. Owl
is a server distribution, so is our market. Windows' market share in
the server segment is below 40%, so no majority here. Having GUI (e.g.
X Window System) is out of scope and goals of Owl, yet it should be
possible to install it from a compatible distribution (e.g. FC or
CentOS), and this _was_ working many years ago and was used by us.
For the last 2 years the only systems I was running Owl were my personal
ones since I believe that to contribute to something you should use it
yourself first. I'm slowly starting to get tired and quite frustrated
on the amount of time I spend to keep my systems up to date, to make
them suitable to run services I want to run, etc. I have more than a
hundred packages I'm maintaining and it takes significant amount of my
time to update them and to keep up with corresponding upstreams.
I have a feeling that Owl is currently stagnating since there are no
active packagers and that if we do not act in the nearest future the
effort required to recover and to bring Owl up-to-date would be
unjustified. In my opinion, we are approaching a point where it's just
much easier to take the best we have in our distribution and apply it on
top of a modern, mainstream one -- and my guess is that we won't lose
much. Maybe, this is what we should do after all.
--
(GM)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
