Uu Servicio email BlackBerry® xnet -----Original Message----- From: Michael Stauber <mstau...@blueonyx.it> Sender: blueonyx-boun...@mail.blueonyx.it Date: Tue, 28 May 2013 20:21:49 To: BlueOnyx General Mailing List<blueonyx@mail.blueonyx.it> Reply-To: BlueOnyx General Mailing List <blueonyx@mail.blueonyx.it> Subject: [BlueOnyx:13121] Re: Active Monitor "Support/Maintenance" messages
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 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx