[BlueOnyx:13121] Re: Active Monitor "Support/Maintenance" messages

[Michael Stauber]

Hi Chris and all others,

> If I'm remembering right, I believe that NewLinQ is simply the
> re-badged version of BlueLinQ, which was the way that Cobalt rolled
> out updates "back in the day".

That's correct. It's based on that and the protocol that the Sun Cobalt
ControlStation provided to make updates available in a similar fashion.
It has progressed a bit beyond what the initial developers had in mind,
though.

> 1. Documentation as to how other parties might deliver their PKGs via
> NewLinQ.

The general concept was (and still is) to provide a central platform
from which third party updates and add-ons can be released. At the
moment there are only Compass Networks and Solarspeed PKGs in it. Some
free, others requiring an upfront payment (with or without subscription
to updates). We're also currently working on a third option, where
commercial PKGs (including their updates) can be "leased" and can be
paid for with small monthly payments instead of paying a considerably
larger sum upfront.

So in the future it will be possible to "rent" individual PKGs (or
bundles of PKGs) for usage on a monthly basis. However, our payment
system provider isn't exactly very helpful and the integration of that
new feature has been "in progress" for the last three months now. With
little movement. Personally I can't wait until it's finally available.

> 2. A method for 3rd party developers to submit their PKGs for inclusion 
> in the BlueOnyx Shop.

That's already touched lightly in the previous answer. But yes: The
current "shop.blueonyx.it" was never thought to be an exclusive and
vendor locked platform. We're looking forward to make it available to
other PKG vendors as well.

However, third party PKGs will need to fulfil a certain minimum standard
that we will eventually be written down and be put up for scrutiny and
public review. It'll be common sense stuff like this: PKG must be safe
to operate, free of back-doors, must install and uninstall cleanly,
vendor must be verified and known to us (in case a client wants to press
legal actions against the PKG maker for whatever reasons), a support
channel must be made available for users and maybe a couple of other
things that I can't think of right now. In any case the "bar" will be
higher for third party commercial PKGs. Because then we'd be acting as a
"toll booth" for them the liabilities and legal hurdles are of a
slightly different nature.

> 3. Streamlined PKG management for datacenters / resellers.

Yeah, we talked about this before offlist. We've been going over our
ideas and plans and made the necessary adjustments for that. We'll be
fully able to accommodate datacenters and resellers once the monthly
payment option becomes viable and operatively ready.

> 4. Better underlying system redundancy and performance, especially as it 
> relates to connections in North America.

Yes, I'm also not happy about that situation and it has been a very
pressing matter for me to get it sorted.

However, in the last two weeks several measures were taken which reduced
the impact that the botnets had on both the different shops and the
NewLinQ architecture. Over the next weekend we'll diversify the
architecture further to spread it a bit more around and throw in a few
extra layers of redundancy and caching.

> I may be talking to myself here (because I'm not sure that anyone else 
> is really interested in what I'm saying) but I believe that we could 
> take a page from the book of successful projects like WordPress, Joomla, 
> WHMCS etc.  Those projects (2 are Open Source, one is proprietary) have 
> all embraced a developer community with clear documentation and some 
> amount of transparency.   By creating a larger marketplace, they have 
> also broadened the appeal of the core software.

Yeah, the documentation of the Sausalito interface has always been a
sour point. I can now fully appreciate and understand why it is so
shoddy: Those people that knew the platform inside out had no time to
write a proper documentation. When they were forced by management to do
a write up, the resulting docs often assumed intimate prior knowledge to
certain key aspects, were too technical, too short and naturally lacking
examples. The sole existing somewhat more detailed documents were
probably written by newcomers who quickly lost themselves in
generalizations and meaningless phrases, because they didn't fully know
or comprehend what they were writing about. They were probably told:
"Just ask if you need something", but when they did, the person that had
the info was probably too busy with other things to really set them
straight.

The "Sausalito Developer’s Guide" is a prime example of that. It
contains roughly 10% useful information, 80% meaningless babble, 5% of
stuff that was (at the time of the writing) either already outdated or
not yet built in and 5% of stuff that's just plain wrong to begin with.
In the end the readme's and ToDoList's in the actual SVN code (and the
code itself) were the best reference and they tell the whole story in
brilliant details. But that takes time to digest and to appreciate.

With the introduction of the "new" BlueOnyx 5207R/5208R it'll get even
slightly worse, as most of the immediate architectural changes will
initially not be documented at all - except in form or comments inside
the actual code itself. And again in readme's and ToDoList's in the
actual SVN repository.

But once things have settled down post release documentation will be
pretty high on the list. The immediate basics will cover how to code new
GUI pages and how to create PKGs for the new platform, as that
information needs to get out to interested parties first.

However, due to the nature of things I daresay the number of people
capable and willing to build and release PKGs will be small. A good
documentation can help, but at the end of the day it will still require
some good Linux craftmanship such as good RPM building skills, some
basic understanding of i18n and at least a moderate proficiency in PHP,
Perl and Shell-scripting. Which are and always will be outside of the
scope of a platform specific documentation.

A "good" PKG stands and falls with the ability to install and uninstall
cleanly. Which for the most part depends on the quality of the RPM's it
contains. With a few hours of reading and trial and error anyone can
build RPM's. But when all is said and done, it still requires practice,
a purpose and lots of dedication to hone these skills to a certain
degree of proficiency before it really becomes useful.

The PKG format makes it even easier to "clean up" some mess from a
sloppy RPM install. But it can also be used to make things worse.

Over the years (especially back in the Cobalt days) there were some self
proclaimed "experts" around releasing third party PKGs which really made
me cringe. PKGs that didn't have the add-ons as RPMs, but compiled stuff
on the fly, or "chucked" tarballs with pre-compiled binaries aboard and
then copied them around. With total ignorance and disregard of any
architectural considerations or safety concerns. That is certainly
something that I don't want to see happening to BlueOnyx.

Hence the need for a better documentation, to point out the DO's and
DON'T's. But also for some quality control as far as it comes to adding
third party PKGs to the official BlueOnyx shop. Greg and I want to make
it a trusted platform for all third party PKGs, which then will also -
to a certain degree - put our good names to a risk if we'd pass
something along that isn't up to everyone's expectations.

-- 
With best regards

Michael Stauber