gitolite/c3d2-wiki
gitolite/c3d2-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

/* Transcript KenMoore/KrisMoore zum aktuellen Stand */

Browse Source
This commit is contained in:
TonyBoston 2015-09-28 16:32:34 +00:00
parent 7de61e48f3
commit 44e522ae1c
1 changed files with 93 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

93
Yocage.mw
View File

@ -59,3 +59,96 @@ In Anlehnung an den Erfolg vom [[Matemat]] wird [[Yesod]] eingesetzt. Yeah!
===== Transcript KenMoore/KrisMoore zum aktuellen Stand =====
tboston: is it okay if we try to make a web interface for iocage?
thats our plan for now
or is it not needed since you want to keep that in AppCafé?
kmoore: hey, if you guys want to make one, go for it, I can't stop ya :)
The plan is to put one into AppCafe also, but having alternatives is always good
tboston: but if you don't use it in the end its somehow senseless
kmoore: '''true. The plan is to have one in AppCafe which is also in FreeNAS / TrueOS, etc'''
tboston kenmoore: what was that admin-tool you talked about?
kenmoore: tboston: admin-tool?
tboston: yeah you said something about an admin gui for pcbsd would be nice
'''kenmoore: Oh, I was talking about a unified administration framework/system (such as a library) for the system'''
so yeah, I guess this would start counting as that
basically need something on the low-level to know about all the various FreeBSD files/settings/etc, so top level GUI's/tools only need to run CMDs through a single util
makes it a lot easier to maintain system tools and UI's down the road
tboston 4:29 PM okay, I'll keep that in mind
tboston 4:41 PM kenmoore: can you be more specific on that low-level tool? Like what would it need and what is the OS/Admin getting out of it?
kenmoore 4:42 PM Well, I was thinking about 2-components:
1) A single libary (something like libSysAdmin), with all the various low-level system interface routines (in C/C++/QtCore - any of them will work)
This is the "unifier" for accessing all the various FreeBSD subsystems (networking, user management, etc..)
because every subsystem seems to have their own files/formats/etc
2) The user interface (web-based, or local) which just needs to load that single library to read/change things on the system as necessary
This webclient tool that we are working on could easily become a #2, but #1 does not exist yet
#1 will probably need a couple different libs actually - a "user" level one for providing read-access for supported things, and a "root" level one for modifications
so maybe a libsysadmin-[user/root] setup
tboston 4:47 PM okay, I think I got it
kenmoore 4:47 PM that way the #2 interfaces can only load the libs they are able to actually use
this would be nice because unlike systemd and other Linux-y tools it does not ​replace​ the FreeBSD admin tools - it simple provides a simple interface to them
all the old methods will still work just fine - the libs just provide a single point of entry to be maintained/updates as FreeBSd changes
tboston 4:49 PM do you know of a linux equivalent?
kenmoore 4:49 PM not really - I am not too familiar with Linux utilities aside from some basic generalities
tboston 4:49 PM k
kenmoore 4:50 PM I think this type of setup would be unique to FreeBSD - since I hear the Linux people complain all the time about a new system meaning how they change setting X is now completely different
this would basically provide a standard API for system calls without changing the underlying OS/infrastructure
tboston 4:51 PM understood
kenmoore 4:53 PM I started working on one for a little bit (networking first), you can see what I have in pcbsd/src-lib/pc-utils
specifically the NetDevice.cpp file
that does a lot of the network probing on a very low C interface level
oh, and the pcbsd-network.[cpp/h] files
tboston 4:54 PM let me check that
kenmoore 4:55 PM note that I was creating the library with C++/Qt though - so if you want to do a pure C library implementation you might need to change some things
kenmoore 4:56 PM mainly convert the QString's to a C string
and things like that
tboston 4:57 PM gotta look into that when I get home
4:57
still at work
kenmoore 4:57 PM that is fine - no rush
tboston 4:58 PM but guess woul'd be fine as a base
kenmoore 4:58 PM I had to put that effort on hold since I just got too busy with other stuff
tboston 4:58 PM if you dont mind
kenmoore 4:58 PM I don't mind
tboston 4:58 PM anyway, our Haskell guy is unemployed then...
kenmoore 4:58 PM :simple_smile:
This is easily a full/huge project, so I started tackling it by breaking it up into all the various subsystems
I recommend a similar approach so that you can simple add/enable new subsystems instead of breaking existing stuff
keep it all compartmentalized
tboston 5:00 PM is pbsd/pc-utils all part of it?
kenmoore 5:01 PM pcbsd/src-lib/pc-utils was all of it
tboston 5:01 PM ahh yeah thats what I meant
kenmoore 5:01 PM I created the shell for the GUI interactions (src-lib/pc-gui) but there is really nothing there
the lib needs to be more complete first so the API is set before we can start writing GUI interactions with it
note that for some subsystems (like networking) FreeBSD is designed around OS-utility use - not direct library access/control (such as using "ifconfig"), so for making changes you might need to actually run that utility
otherwise you might end up duplicating a lot of the code within ifconfig, and break the future-proofing of the API (basically maintaining a fork of an OS tool)
just FYI
:simple_smile:
usually just reading the system info can all be done through libs though
tboston 5:06 PM well, sounds huge like you just said :simple_smile:
but hey, we're 4 ppl wanting to get involved
kenmoore 5:06 PM give each person a subsystem and get started!
:stuck_out_tongue:
tboston 5:07 PM haha yeah
and we need to integrate Haskell somewhere :stuck_out_tongue:
kenmoore 5:07 PM yeah, that too
I recommend making a general class of static functions for use across all subsystems
such as reading a sysctl
tboston 5:08 PM yep
kenmoore 5:08 PM anything to make it easy for others to read/update later is good... :simple_smile:
tboston 5:10 PM Haskell can talk json/websockets, we might test that out some time
kenmoore 5:11 PM yeah, JSON/websockets are fairly universal
because it is basically a standardized ​format​ rather than a standardized ​utility​
so any tool/utility can support the format as necessary
That is actually my problem with a lot of the linux stuff - they have recently been pushing standards in the form of particular utilities/tools instead of a standardized interface format
DBUS/systemd are good examples
tools are restrictive (OS-support, library requirements, etc)
while formats are universal