Post by Stefano Zamboniwell, with your experience and considering our (community) manpower,
you can just make a guess
We're just talking about ideas, nothing is defined yet, so no, I can't
estimate anything atm. Having a minimal POC running is probably a matter
of a few hours, which I'll try to find ASAP.
well.. a POC of what? of the new framework with a usable panel? really? :-)
cool
I guess that you are referring to a POC with mojo to demonstrate that
things can be done.. no doubt about it..
but, as you said, the way is to have an homemade framework.. we can't
make a comparison..
I created panels that work inside a framework using its features, you
won't, IIUC
programming with cockpit "just" need js/jquery/json/nodejs skills,
which are "a bit" more common nowadays than perl's one.. aren't they?
Well, maybe. I'm not even sure. I mean, here, in this community, who has
those skills ? In fact, I don't see in which situation someone would
only write a panel without anything else on the server-side (so perl
skills will always be needed).
touchÚ..
let's say I want to announce "out there" something like
"hi there.. we're starting developing some modules for cockpit to create
a new server manager for SME, are you interested?" on our forums (but not
only)
do you think that announcing something like "hi there.. we're starting
to develop a framework with mojo to be able, in the future, to create the
new server manager for SME, are you interested?" will have the same appeal?
don't you think that maybe many of our users just use SME as a web server
to serve or just develop web app? and that many of them maybe are using
jquery, angularjs and so on?
ands what about people using nodejs? cockpit uses some libraries from
node.. there's no node instance, anyway.
we need perl skills, sure.. if we just concentrate them into the core, to
have modern api to be used from anykind of web app capable of using
json/rest, we're done.. we'd have 10 different kind of S-M, people could
create and sell customized solutions
no.. we want to create our own toy in our backyard.. in 2016.. with
everybody out there just sharing code and ideas and projects on github, we
want something homemade, stored on our CVS
to really work on cockpit and C7 we need base and lib rpm.. meaning
that once I can call a signal event, read a db, write on it, the logic
is ready
Ok, it'll be ready. Ready to wait for the rest of the system to be
ready. Something working on SME9 would mean it could be used sooner,
have more feedback, show more active development.
ok..
<premise>
as I said, english is not my language, so I apologize since now if in the
next lines I could sound harsh or rude or impolite.. I'll try to do my best
to avoid it, but I can't promise that I will succeed
no personal attack, no flame, no offence, I promise
I'd add also that diplomacy is not on my chords, even if in the past
here, via private emails or just on the forums I acted as a peace maker.
</premise>
some things here (in this community) are not clear to me and this distro
is just laying (dying ?)
- this ML is almost dead for 99% of the time (archives are out there
there).. it sounds to me like that *there's no* active development and the
only activity is aimed to bug fixing.. this makes SME just laying and makes
people leave (no interests, no enthusiasm, no fun)
- to make something move it's necessary, how I'm used to say, to "drop a
bomb".. it happened when Filippo told us about NS fork, it's happening now,
again.. and this is happening *not* since I wrote my first email "*SME
on centos7 - let's start playing*" (almost ignored), but since I just
wrote about my playing with cockpit.. from that moment, this ML has become
a beehive.. isn't it? there was a sudden acceleration toward C7
- our product is a rock solid one
- our server manager, in a single word definition, sucks
- people are leaving us: users (going to other products that maybe offer
the same features but with a more modern eye catching interface) and
developers.. those are leaving because of our being stuck on formagik and
the objective difficulty to work in an environment where new ideas are
simply.. chocked.. for example, the code to add dummy interface capability
just to make SME available on VPS (real world usage, nowadays) took more
than 2 years to be accepted (see #7200)
- the need of a new, modern UI, was stated with #6821, more than 3 years
ago.. since then, *not* a single line of code has been written.. ask
yourself why and give yourself an answer (hint: formagick is a PITA)
since then, *not* a single line of code.. since now..
- we need to involve more people: investors and developers.. the first
must be abstracted by the opportunity of have a investment return, the
latter with something that is, simply, interesting.
and in this case money is not to make us rich persons, but just to pay
the bills and (but this is simply fantasy dreams) pay the coders.
- we need to improve our products to give answers to people demanding for
features nowadays not negligible, like Samba4 and AD interaction, multiwan
and so on
the items above are, simply, facts.. you (and everybody else, of course)
can obviously confute them, and you'll be welcome.. but in (not only) mine
opinion, they are *facts*.
now.. I'm a board member, just like you Dani.. the board is in charge for
(citing from the costitution act)
"*To this end, the corporation shall foster the creation, distribution,
and maintenance of a free integrated, all-in-one server operating system
with bundled applications designed for homes, small businesses, medium-size
businesses, and non-profit organizations, and it will be licensed under the
GNU General Public License. The server operating system will be focused on
simplicity, stability and security, designed to be operated by people with
no technical background, while providing a platform for technical users to
extend.*"
and I'm seriously convinced that we must take decisions.. we can't simply
wait and see what happens, because I see this product is sinking and no one
seems to be really interested in moving forward.. maybe I'm wrong, but (*my
personal opinion*) there are some interests in keeping the status quo i.e.
moving de facto all our packages to C7 and keep everything just how is it
now.
what about mojo? I have no doubts, *no one*, that it's a good product,
rock solid and so on.. but we need to find something usable by a wider base
of coders..
in the past Charlie (but not only him) said NO many times to the idea of
converting our S-M to php.. all of us agreed, sure.. but the FACT is that
we're still using the same S-M we had in SME 6.. if not exactly the same,
done with the same approach.
question (and I beg your pardon, but I pretend an answer): why mojo
become so interesting *now*? why are there people writing code and POCs
using it *now* if till 10 days ago almost no one was interested in it? why?
why the cockpit proposal was so scaring?
when Filippo told us about their fork, many argumentations were "oh,
dear, why did you change qmail with postfix?", "why did you choose php for
the web UI? I won't use it"..
the relevant *fact* is that they *did* something.. we're still here, still.
if you or anybody else is really convinced and sure that mojo is the way
to go, well, show me/us, here (devinfo ML and bugzilla) that it is really
easy to use, that permits to have result in a reasonable amount of time and
that it's interesting.. something that will abtract developers' curiosity.
we (the board) needs *facts*.
there are people that are interested in SME developing, infact we have
hundreds of custom values in our dbs, but almost *no one* (except, maybe,
Steph) worked on web interface to make them visible because creating a web
page now is not trivial and will just make our S-M more unusable.. and just
thinking to add some features (the password expiration panel, for example)
to the core pages sounds absurd because of the approach often found here
and in bugzilla.. using the smeserver-password contrib as an example, I was
told "*no, it won't be in the core since we non't need to set password
expiration here in $whatever_country*".. well, here (italy) we must, and
password's expitation policy is a good thing, aimed to security.. so, why
not?
the *fact* is that everytime someone propose a change, the first answer
is "no", often with *no reason*, followed by months of silence.
we have a Space Shuttle (
http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_960.jpg)
in our hands but with the cockpit of a piper (
<http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg>
http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg)..
just compare the images..
SME's perl core is a rock, and *no one* is asking for something
different.. it just needs some improvements to be available in another way
from another tool like cockpit..
cockpit: I personally started to play with it last saturday, 10 days ago,
in a cafeteria, at Fosdem. *I never saw it before*.. in 15 mins I
branded it, in 3 hours I created my first trivial plugin that gets values
from a SME's db, shows them and saves them.. just using the db command.. it
tooks me more time just to have a working environment.
but since I start talking about it... wowowowowow!!! I see now that "mojo
is the way", "cockpit is unsecure".. and other things that make me think
that the reasons not to move on are not technical but political..
the funny thing is that we offer SME to te people saying "why would you
start from a bare minimal centos setup and become crazy to install, config
and make all the things you need just work in a secure and easy manner?
just use SME.. easy, reliable, fast, secure"..
and now you (generally speaking) are telling me that instead of start
working/collaborating on an existing framework integrated with the OS we'd
start to create something from ground zero reinventing the wheel..
now, if mojo is the way to go, I expect that somebody will tell me/us
exactly *why*, with an argumented answer and with *facts*.. and if so, I
will expect an argumented list of reasons why we can't/should not move to
cockpit too.
no, I'm saying that if we need 2 years to have the new interface,
we're already dead..
What did I say last time about being dramatic ? ;-)
Dani.. if we're talking about phylosophy, no problem at all.
we are on the board, we must give directions, take decisions.. and in
this perspective, 2 years is a sucide
please, stop thinking like a sysadmin ad start thinking in a business
perspective, thank you
cockipt has a community.. if there's a bug (a security one) we can
just raise a bug there, concentrating ourselves to other things.
I'm not too worried about bugs (although, cockpit core being in C,
fixing bugs will be harder). I'm worried about the whole design, I'm not
sure it'll be any easier for us to work with.
well.. first of all, maybe it is not perfect, but it is just real and in
active development
comparing a *real* thing with just ideas (our framework) doesn't make
sense to me
well.. first of all if you think that there's a security bug, just
test it, demonstrate and let's open an issue there..
The problem here is the design: we either can't have a user portal, or
we're exposed to security issues. I'm not sure which one is true (the
documentation is lacking), but unless I missed something, it's one or
the other. Or maybe you can tell me: how an unprivileged user could
modify only some of its own props in the account DB without being able
to modify the others ? I see no other way than rewritting the db command
to check for permissions. Which will be complex. And require perl
skills. And time. So no, cockpit most likely won't be a solution we can
use as-is.
again (maybe my english is faulty): we have few resources but skilled in
- porting everything to C7
- creating from 0 a new framework, test is, document it, debug it
- creating the new S-M
they should just concentrate theirselves on porting and enhancing our core
you're still thinking in how things work now
Of course I am, because, unless we're talking about rewritting
everything, things are going to work more or less the same way they do
now won't they ?
well.. take a look at my user panel for cockpit and compare it with the
relevant part of code needed now to just publish the user table..
do you think they are the same? do you think that the needed effort is
the same?
one dimension you are "just" forgetting is *time*
I don't think I forgot anything. I'm too well aware that we lack
manpower. But doing things in a hurry because it seems to be fatser is
not always a good solution. The time gained at some point can be lost at
some other because of design issues. IMHO, we should start a wiki page
where we list the features and goal we want to achieve.
this sounds reasonable
if we need 3 years to have something cool, secure, ours, well.. we
just trying a new way to commercially suicide ourselves.
(too dramatic)
And that's an argument against using cockpit. If you want to go with
cockpit, it won't be ready before SME10 is, that's a fact. SME10 will
take a lot of time and effort to be ready (and is another project, not
directly related to the new S-M)
SME10 must be released with the new interface.. from a business
perspective, anything different is just, again, shooting on our feet.
there are people that sells services based on SME.. will they have to
wait 3 years to have SME10? don't you think that if it will be the
case, they just start to see if there's something to migrate to? can
we afford the loosing of coders, users, interest? I don't think so
The time it'll take to have SME10 ready is unrelated to the new S-M
effort. I even think designing and writting the new S-M is a small task
compared to having SME10 finalized.
ok.. so, please, don't waste your time on S-M and just concentrate
yourself on the other issues :-)
people that want to integrate SME into a lan where there are windows
servers *can't* do it (well.. they can.. they only have to replicate
all users on both sides.. scaring and just absurd in 2016)
I have no problem joining latest Windows servers to the good old NT4
domain controller. I don't have to replicate anything. But that's
unrelated to this discussion.
the fact that you don't personally need AD is unrelevant..
times where I can go to a customer and say him "ok, I'll install you a
SME that will take care of everything" are gone..
now I go to customers that have windows servers with AD and they need
some features they can't simply afford (money) or they don't want to be M$
made (exchange anybody?).. I can't go there and tell "ok.. we have 2
options.. A) remove your server and use SME for everything B) install SME
and replicate all the settings on both sides", because it is simply
impossible..
For example, a feature NS has and is very usefull is AD integration: I
can join NS to an AD domain and offer services to the users.
Samba4 and AD and other features are a must.
once I finished my POC with cockpit, I'll start to work on S4.. I kindly
ask everybody, since now, to not start saying "oh, dear, S4 is a PITA,
uneeded, I don't need it, M$ is crap" and so on
here I talking not as a developer or as a sysadmin, here I'm talking as a
board member.
And I'm keeping the discussion here to have *technical facts and answers*
features offered by SME nowadays can be found on appliances like nas you
take from the shelves in the local store..
we had some plus in the past comparing with our competitors, now we have
not.
@HSF, would you mind to create a wiki page about features? TIA
S.
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/
Through IP Pty. Ltd. - AUSTRALIA