- 9
- 0
- NAS
- crow216p2, dove216
- Operating system
- Linux
- macOS
- Windows
- other
Last edited:
This is puzzling. Web Station installs, runs, and does not see any HTML/CSS, so I'm stuck with a File Station set of foldered lists. No text. Just titles. Not much of a presentation.
So I moved to what was easy on Ubuntu, FreeBSD, Debian, and Fedora: Apache, accessing the DS216+II structure with my administrative SSH connection.
The problem is that there is no documentation on what gets installed, where it gets installed, and with what defaults.
That's what is called a "BOM" (Bill Of Materials); it's a basic of any qualified installations. It's needed if you ever want to run, modify, upgrade, or uninstall. It's an integral focus of ISO 9001.
So, I cannot find install or runtime logs, which will help me to backfill (reverse engineer) the missing details.
The path was not appended to (path=$path:newcmd) so that command line call (e.g., start, reload, and synoserrvicectl) existences/locations are unknown.
Time wasting becomes a substitute for life time when this shortcut passes on what amounts to 'software incompleteness' to end users.
The saddest guess is that the Apache 2.4 install didn't add anything except the "Running" indication.
Alas, I'm still hoping for more, and only coming from users, as Support tends to refer all levels of a configuration back to the same 'living proof' example-free documentation, which may not even reflect the current DSM or install's release version, so that menus, options, files/folders may not even correspond or exist.
When versions change, so must doc. However, as we all have no doubt experienced, that can easily get out of synch when modules change between major and minor releases. Very easily! And, the more contributing parties that are baking something the more the end result may never "look like" or taste like" the reciped item. If all module permutations are not tested, then expect some sort of glitch, incorrectness, and/or failure. Branched code can also break working features if no regression test suites are run. [A bad example: Apple probably killed their test/QA department years ago, while boosting their management and marketing budgets; the proof is in their unpublicized bug counts, if they even track bugs; users cannot file them, so who does?! Insiders.
And, doc needs to have been tested and verified... which means that example sites with code should already exist and be available to be put on a site showing proof of the conceptual ability to run, robustly, without high severity/priority bugs, and correctly. Nowhere that I can find.
I've found this w/r/t FreeBSD and coding-by-committee projects, as well as in most every "rapid development" project. They may skip testing and thus, use "quality" as if the word comes for free, like "natural" on food wrappers. So ambiguous is its conception, that the "science" in "computer science" disappears as steps, phases, testing, definitions, qualification standards, and process get abbreviated or skipped.
Sure, it's easy to say all this? Nope. I did this for decades. It's all that stands between garbage and efficient, modular, high-performing, and maintainable software. It also helps to make software actually do what marketing and sales say they want it to do. Meeting quotas is not the same as meeting standards of quality! That said, they're both needed. But maybe we need to take on the software quality assurance (verifying/fixing) technical documentation ourselves?!
So, rather than give up to garbage and frustration, I think we can construct a method where documentation is synchronized with a web example and with regularly being tested and updated. In short, we would be creating a Project Plan to propose to Synology so that their benefit from said [user-inspired] processes is a higher ranking in the 'needs no support because it self-documents, and works' department, which, in turn, then benefits us when they release software requiring robustness as-and-before it's released.
If anyone else is interested in bypassing 'what is', which doesn't appear to be much at all, then we can salvage "science" from the 'billboarded' version that prevails, and in the process, save each other vast headaches, heartaches, and rapid hair-loss ( or at leat the greying aspect). It could be rather fun. We could set up a repository and segment it by our own critical-path topics (maybe just along a tool-by-tool basis) so that the most pertinent and needed solutions can be tackled and publicized for all of us. There's also what we have already succeeded at as well. Anything that builds our community as our community. Waiting for Synology to solve these issues is slow since it involves assignments and time, and they are already locked into budgeting both I'm sure. I'm immediately interested in Apache. I have temporarily quit working on Web Station and Web Radio. Too little doc, no working examples, no successes, and no high-level experts. Interested? Please contat me and we can allocate some collaborative time and design a living document as a roadmap. Thanks.
best wishes,
ff
So I moved to what was easy on Ubuntu, FreeBSD, Debian, and Fedora: Apache, accessing the DS216+II structure with my administrative SSH connection.
The problem is that there is no documentation on what gets installed, where it gets installed, and with what defaults.
That's what is called a "BOM" (Bill Of Materials); it's a basic of any qualified installations. It's needed if you ever want to run, modify, upgrade, or uninstall. It's an integral focus of ISO 9001.
So, I cannot find install or runtime logs, which will help me to backfill (reverse engineer) the missing details.
The path was not appended to (path=$path:newcmd) so that command line call (e.g., start, reload, and synoserrvicectl) existences/locations are unknown.
Time wasting becomes a substitute for life time when this shortcut passes on what amounts to 'software incompleteness' to end users.
The saddest guess is that the Apache 2.4 install didn't add anything except the "Running" indication.
Alas, I'm still hoping for more, and only coming from users, as Support tends to refer all levels of a configuration back to the same 'living proof' example-free documentation, which may not even reflect the current DSM or install's release version, so that menus, options, files/folders may not even correspond or exist.
When versions change, so must doc. However, as we all have no doubt experienced, that can easily get out of synch when modules change between major and minor releases. Very easily! And, the more contributing parties that are baking something the more the end result may never "look like" or taste like" the reciped item. If all module permutations are not tested, then expect some sort of glitch, incorrectness, and/or failure. Branched code can also break working features if no regression test suites are run. [A bad example: Apple probably killed their test/QA department years ago, while boosting their management and marketing budgets; the proof is in their unpublicized bug counts, if they even track bugs; users cannot file them, so who does?! Insiders.
And, doc needs to have been tested and verified... which means that example sites with code should already exist and be available to be put on a site showing proof of the conceptual ability to run, robustly, without high severity/priority bugs, and correctly. Nowhere that I can find.
I've found this w/r/t FreeBSD and coding-by-committee projects, as well as in most every "rapid development" project. They may skip testing and thus, use "quality" as if the word comes for free, like "natural" on food wrappers. So ambiguous is its conception, that the "science" in "computer science" disappears as steps, phases, testing, definitions, qualification standards, and process get abbreviated or skipped.
Sure, it's easy to say all this? Nope. I did this for decades. It's all that stands between garbage and efficient, modular, high-performing, and maintainable software. It also helps to make software actually do what marketing and sales say they want it to do. Meeting quotas is not the same as meeting standards of quality! That said, they're both needed. But maybe we need to take on the software quality assurance (verifying/fixing) technical documentation ourselves?!
So, rather than give up to garbage and frustration, I think we can construct a method where documentation is synchronized with a web example and with regularly being tested and updated. In short, we would be creating a Project Plan to propose to Synology so that their benefit from said [user-inspired] processes is a higher ranking in the 'needs no support because it self-documents, and works' department, which, in turn, then benefits us when they release software requiring robustness as-and-before it's released.
If anyone else is interested in bypassing 'what is', which doesn't appear to be much at all, then we can salvage "science" from the 'billboarded' version that prevails, and in the process, save each other vast headaches, heartaches, and rapid hair-loss ( or at leat the greying aspect). It could be rather fun. We could set up a repository and segment it by our own critical-path topics (maybe just along a tool-by-tool basis) so that the most pertinent and needed solutions can be tackled and publicized for all of us. There's also what we have already succeeded at as well. Anything that builds our community as our community. Waiting for Synology to solve these issues is slow since it involves assignments and time, and they are already locked into budgeting both I'm sure. I'm immediately interested in Apache. I have temporarily quit working on Web Station and Web Radio. Too little doc, no working examples, no successes, and no high-level experts. Interested? Please contat me and we can allocate some collaborative time and design a living document as a roadmap. Thanks.
best wishes,
ff
