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.