Re: [oi-dev] [developer] Feedback on Slurm patches

2016-05-06 Thread Alexander Pyhalov 

On 05/06/2016 23:02, Aurélien Larcher wrote:

You can compile code with -D_POSIX_PTHREAD_SEMANTICS to get standard
behavior (see getgrnam(3C).



This is already the case but glibc has a non-POSIX version if I understood
well.
Instead of:

group *getgrent_r(struct group *grp, char *buffer, int bufsize);

they use:

int getgrent_r(struct group *grp, char *buffer, int bufsize, group *
resultgrp);




Vice versa,  later variant is posixly correct.


--
С уважением,
Александр Пыхалов,
программист отдела телекоммуникационной инфраструктуры
управления информационно-коммуникационной инфраструктуры ЮФУ

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] Feedback on Slurm patches

2016-05-06 Thread Aurélien Larcher 
> You can compile code with -D_POSIX_PTHREAD_SEMANTICS to get standard
> behavior (see getgrnam(3C).
>

This is already the case but glibc has a non-POSIX version if I understood
well.
Instead of:

group *getgrent_r(struct group *grp, char *buffer, int bufsize);

they use:

int getgrent_r(struct group *grp, char *buffer, int bufsize, group *
resultgrp);


>
> Have you seen
> http://comments.gmane.org/gmane.comp.distributed.slurm.devel/6016 ?
>

So it seems defining the macros to zero is not harmful even if not sexy.


>
> BTW, it exists in latest Solaris (
> https://issues.apache.org/jira/browse/HADOOP-11655).
>

Alright, so this cannot be upstreamed.

How realistic would it be to have getgrouplist added to illumos ?

Thanks.

Aurélien



>
> --
> Best regards,
> Alexander Pyhalov,
> system administrator of Southern Federal University IT department
>



-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] Feedback on Slurm patches

2016-05-06 Thread Alexander Pyhalov 

On 05/06/2016 22:25, Aurélien Larcher wrote:

Hi,
in an attempt to compile Slurm [0] on OpenIndiana to add it to oi-userland
[1], I encountered several minor illumos-related issues:

1) getgrent_r has 3 arguments since it returns group * on illumos while
glibc has 4 and returns int: is checking that ret != NULL enough ?


You can compile code with -D_POSIX_PTHREAD_SEMANTICS to get standard 
behavior (see getgrnam(3C).



2) sched_getaffinity does not exist and I replaced it with pset [2]




3) cfmakeraw does not exist so I used the code snippet [3]

4) mount.h does not have MS_NOEXEC and MS_NODEV and I do not know what to
do [4]


Have you seen 
http://comments.gmane.org/gmane.comp.distributed.slurm.devel/6016 ?




5) getgrouplist does not exist and I used a patch from kde-solaris [5]



BTW, it exists in latest Solaris 
(https://issues.apache.org/jira/browse/HADOOP-11655).


--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Feedback on Slurm patches

2016-05-06 Thread Aurélien Larcher 
Hi,
in an attempt to compile Slurm [0] on OpenIndiana to add it to oi-userland
[1], I encountered several minor illumos-related issues:

1) getgrent_r has 3 arguments since it returns group * on illumos while
glibc has 4 and returns int: is checking that ret != NULL enough ?

2) sched_getaffinity does not exist and I replaced it with pset [2]

3) cfmakeraw does not exist so I used the code snippet [3]

4) mount.h does not have MS_NOEXEC and MS_NODEV and I do not know what to
do [4]

5) getgrouplist does not exist and I used a patch from kde-solaris [5]

I would be grateful if you have any input on these points.

Best regards

Aurelien

[0] http://slurm.schedmd.com/
[1]
https://github.com/alarcher/oi-userland/tree/slurm/components/sysutils/slurm
[2]
https://github.com/alarcher/oi-userland/blob/slurm/components/sysutils/slurm/patches/04-gres.patch
[3] https://www.perkin.org.uk/posts/solaris-portability-cfmakeraw.html
[4]
https://github.com/alarcher/oi-userland/blob/slurm/components/sysutils/slurm/patches/10-xcgroup.patch
[5]
https://github.com/alarcher/oi-userland/blob/slurm/components/sysutils/slurm/files/getgrouplist.h

-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] demonstration docs website

2016-05-06 Thread Aurélien Larcher 
On Fri, May 6, 2016 at 8:06 PM, WebDawg  wrote:

> > Date: Sun, 1 May 2016 00:30:55 -0400
> > From: Michael Kruger 
> > To: OpenIndiana Developer mailing list ,
> > Discussion list for OpenIndiana <
> openindiana-disc...@openindiana.org>
> > Subject: [oi-dev] demonstration docs website
> > Message-ID: <5725867f.9030...@gmail.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hello all,
> >
> > Here is a little something I have been working to help showcase
> > documentation for the OpenIndiana project.
> >
> > Currently hosted are:
> >
> > OpenIndiana FAQ (Complete, but still growing and improving)
> > OpenIndiana Handbook (little more than a template at this point)
> > OpenSolaris Books (41 titles from the 2009 redistributable docs release)
> >
> > All of this resides on github, so further evolution of this website and
> > it's content simply follows existing development practices.
> >
> > Here is the URL: http://makruger.github.io/website/
> >
> > Enjoy,
> >
> > Michael
> >
>
> I am starting from the first email because there have been so many
> replies and responses to this one and no one has provided anything but
> it seems negative feedback to this git site.  I also see very little
> contribution to the subject of documentation.
>
> Right now a majority of OpenIndiana docs are on the wiki here:
> http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home
>
> I have never even heard of http://dlc.openindiana.org/docs/ until it
> was mentioned a few days ago.
>
> I like wiki's.  Personally I use archlinux and they have one of the
> best wiki's I have ever used.  I like wikis because they are so
> dynamic.  It is easy for me to edit, easy for me to fix.
>
> 1) Place documentation under distributed version control.
>
> Not all documentation I think should be under version control.
> Though, documentation created by the people that help create OI I
> think would.  I really think that what you are creating is not a
> documentation site but a new handbook.  Is there a public, updatable,
> handbook right now?
>
> I would keep the wiki AND have this nice handbook.  I really think the
> front facing page should be integrated somewhere branching off of the
> main site to summarize the entirety of the OI documentation structure.
>
> It seems like, with the wiki and handbook approach, you would be
> duplicating work but then lets take a look at this page:
>
> http://wiki.openindiana.org/pages/viewpage.action?pageId=4883847
>
> That page needs updated, it looks like 4k problem has been fixed, or
> possibly not.  Why are people commenting instead of fixing the wiki
> itself?
>
> If you have a handbook that developers can edit simply and quickly
> once a problem has been fixed in OI, is this not better?  Or is this a
> problem solved by man pages?
>
> 2) Lower the bar of entry to the documentation process.
> I do not know why the bar is high right now?  Can you explain this
> more?  Making an account on the wiki is not hard.
> Making an account on git is not hard either but I would like to
> mention that most people are used to editing wikis.
>
> 3) Make changes and quickly deploy those changes in some kind of
> automated fashion (e.g. continuous integration).
> Once again, I already talked about developer -> git docs editing, but
> can you please explain this more?  Wikis are just click and edit.
>
> 4) Present the documentation in an organized and aesthetically pleasing
> way.
>
>  https://makruger.github.io/website/pages/docs/handbook.html does not
> work.  https is broken in your css.
>
> I agree a bit on this.  I do not like Confluence, but it does make for
> a nice looking index layout.  I am really a fan of mediawiki and I do
> not understand why they chose to go with the Atlassian Confluence
> Community License when mediawiki is FOSS.  To each there own and I am
> sure it was thought about.
>
> I like straightforward layouts that do not obfuscate things.  I want
> all the information on one pagenot a million different menus.  One
> large TOC/index and all the text at my fingertips.  i should not need
> a search engine to search a manual.  If I open up a handbook, I want
> the handbook.
>
> Though, if what you have created were to be accepted, you are adding
> more work.  I do not OI has a dev lead or team right now right?  Who
> is going to support it?  The support/work might not be in vain though
> because documentation should support the release.  It is very
> frustrating for users to use an OS and not find the docs they need.
> Or find out dated docs.  Do you think a developer would take time to
> fix docs though when they already have man pages and README's?
>
> If you were to link the docs via github to code changes, every release
> could have its handbook frozen in time/git releases/names for each
> release.  In fact I think this could be a powerful feature if OI ever
> does an LTS release.
>

Actually the

Re: [oi-dev] demonstration docs website

2016-05-06 Thread Aurélien Larcher 
> 1) Place documentation under distributed version control.
>
> Not all documentation I think should be under version control.
> Though, documentation created by the people that help create OI I
> think would.  I really think that what you are creating is not a
> documentation site but a new handbook.  Is there a public, updatable,
> handbook right now?
>
> I would keep the wiki AND have this nice handbook.  I really think the
> front facing page should be integrated somewhere branching off of the
> main site to summarize the entirety of the OI documentation structure.
>
> It seems like, with the wiki and handbook approach, you would be
> duplicating work but then lets take a look at this page:
>
> http://wiki.openindiana.org/pages/viewpage.action?pageId=4883847
>
> That page needs updated, it looks like 4k problem has been fixed, or
> possibly not.  Why are people commenting instead of fixing the wiki
> itself?
>

But I think with this example you are exactly pointing out the fact that
documentation covers different things:
- developer notes
- ephemeral information (i.e workarounds)
- end user documentation (fairly static)
- etc...

So Wiki and Michael's proposal are complementary as they address different
types of documentation and it was never the question to replace the Wiki.
The Wiki does not allow you to generate to different media as it would be
required for the Handbook.


>
> If you have a handbook that developers can edit simply and quickly
> once a problem has been fixed in OI, is this not better?  Or is this a
> problem solved by man pages?
>
> 2) Lower the bar of entry to the documentation process.
> I do not know why the bar is high right now?  Can you explain this
> more?  Making an account on the wiki is not hard.
> Making an account on git is not hard either but I would like to
> mention that most people are used to editing wikis.
>

Ability to ask for review comes to my mind.


>
> 3) Make changes and quickly deploy those changes in some kind of
> automated fashion (e.g. continuous integration).
> Once again, I already talked about developer -> git docs editing, but
> can you please explain this more?  Wikis are just click and edit.
>
> 4) Present the documentation in an organized and aesthetically pleasing
> way.
>
>  https://makruger.github.io/website/pages/docs/handbook.html does not
> work.  https is broken in your css.
>
> I agree a bit on this.  I do not like Confluence, but it does make for
> a nice looking index layout.  I am really a fan of mediawiki and I do
> not understand why they chose to go with the Atlassian Confluence
> Community License when mediawiki is FOSS.  To each there own and I am
> sure it was thought about.
>
> I like straightforward layouts that do not obfuscate things.  I want
> all the information on one pagenot a million different menus.  One
> large TOC/index and all the text at my fingertips.  i should not need
> a search engine to search a manual.  If I open up a handbook, I want
> the handbook.
>
> Though, if what you have created were to be accepted, you are adding
> more work.  I do not OI has a dev lead or team right now right?  Who
> is going to support it?  The support/work might not be in vain though
> because documentation should support the release.  It is very
> frustrating for users to use an OS and not find the docs they need.
> Or find out dated docs.  Do you think a developer would take time to
> fix docs though when they already have man pages and README's?
>

I would actually be more confortable editing source files and doing PRs.
In a math/physics research environment everything is written in LaTeX (also
mark-up language for  algo/code-related documents).
Even applications for fundings are shared in git and merged from different
branches.


> If you were to link the docs via github to code changes, every release
> could have its handbook frozen in time/git releases/names for each
> release.  In fact I think this could be a powerful feature if OI ever
> does an LTS release.
>

I think so too.


>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>



-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] demonstration docs website

2016-05-06 Thread WebDawg 
> Date: Sun, 1 May 2016 00:30:55 -0400
> From: Michael Kruger 
> To: OpenIndiana Developer mailing list ,
> Discussion list for OpenIndiana 
> Subject: [oi-dev] demonstration docs website
> Message-ID: <5725867f.9030...@gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello all,
>
> Here is a little something I have been working to help showcase
> documentation for the OpenIndiana project.
>
> Currently hosted are:
>
> OpenIndiana FAQ (Complete, but still growing and improving)
> OpenIndiana Handbook (little more than a template at this point)
> OpenSolaris Books (41 titles from the 2009 redistributable docs release)
>
> All of this resides on github, so further evolution of this website and
> it's content simply follows existing development practices.
>
> Here is the URL: http://makruger.github.io/website/
>
> Enjoy,
>
> Michael
>

I am starting from the first email because there have been so many
replies and responses to this one and no one has provided anything but
it seems negative feedback to this git site.  I also see very little
contribution to the subject of documentation.

Right now a majority of OpenIndiana docs are on the wiki here:
http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home

I have never even heard of http://dlc.openindiana.org/docs/ until it
was mentioned a few days ago.

I like wiki's.  Personally I use archlinux and they have one of the
best wiki's I have ever used.  I like wikis because they are so
dynamic.  It is easy for me to edit, easy for me to fix.

1) Place documentation under distributed version control.

Not all documentation I think should be under version control.
Though, documentation created by the people that help create OI I
think would.  I really think that what you are creating is not a
documentation site but a new handbook.  Is there a public, updatable,
handbook right now?

I would keep the wiki AND have this nice handbook.  I really think the
front facing page should be integrated somewhere branching off of the
main site to summarize the entirety of the OI documentation structure.

It seems like, with the wiki and handbook approach, you would be
duplicating work but then lets take a look at this page:

http://wiki.openindiana.org/pages/viewpage.action?pageId=4883847

That page needs updated, it looks like 4k problem has been fixed, or
possibly not.  Why are people commenting instead of fixing the wiki
itself?

If you have a handbook that developers can edit simply and quickly
once a problem has been fixed in OI, is this not better?  Or is this a
problem solved by man pages?

2) Lower the bar of entry to the documentation process.
I do not know why the bar is high right now?  Can you explain this
more?  Making an account on the wiki is not hard.
Making an account on git is not hard either but I would like to
mention that most people are used to editing wikis.

3) Make changes and quickly deploy those changes in some kind of
automated fashion (e.g. continuous integration).
Once again, I already talked about developer -> git docs editing, but
can you please explain this more?  Wikis are just click and edit.

4) Present the documentation in an organized and aesthetically pleasing way.

 https://makruger.github.io/website/pages/docs/handbook.html does not
work.  https is broken in your css.

I agree a bit on this.  I do not like Confluence, but it does make for
a nice looking index layout.  I am really a fan of mediawiki and I do
not understand why they chose to go with the Atlassian Confluence
Community License when mediawiki is FOSS.  To each there own and I am
sure it was thought about.

I like straightforward layouts that do not obfuscate things.  I want
all the information on one pagenot a million different menus.  One
large TOC/index and all the text at my fingertips.  i should not need
a search engine to search a manual.  If I open up a handbook, I want
the handbook.

Though, if what you have created were to be accepted, you are adding
more work.  I do not OI has a dev lead or team right now right?  Who
is going to support it?  The support/work might not be in vain though
because documentation should support the release.  It is very
frustrating for users to use an OS and not find the docs they need.
Or find out dated docs.  Do you think a developer would take time to
fix docs though when they already have man pages and README's?

If you were to link the docs via github to code changes, every release
could have its handbook frozen in time/git releases/names for each
release.  In fact I think this could be a powerful feature if OI ever
does an LTS release.

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OpenIndiana Docs (proof of concept) - What is it all about?

2016-05-06 Thread Aurélien Larcher 
>
> You need to understand WHY you support some actual project, possibly using
> it and wanting to have sucsess because you NEED it to work out.  Not just
> some side-hobby because it is good place to spend your time without
> personal involvement part.
> So think again about your motivation and get back when you have something
> more positive to say about OI.
>

Please stay on-topic: technical feedback on a demonstration.


> Coming from isolated environment, you misplace open reactions and idea and
> project building for hostility. Actually, ANY request for actual hostility
> creation toward individuals , that you recommend as a way of doing things
> must be squashed instantly.
> Trolling this project with "exclusion" of people as way of doing things
> will not be accepted.
> ANYONE asking for any other person to be disgarded should be disgarded
> itself so that such unfriendly and inhumane requests you propose don't tore
> this community apart.
>
> This idea of yours is a cancer and you are just reading a cure for it.
> Also if you base your "inclusion" in "excluding" people as a main tool,
> you surely are _not_ a material for any type of human and project
> management in OI.
>

Same applies here, your attitude is dismissive and you do not provide input
regarding the technical merits or shortcomings of the proposal.


>
> This is all already solved by Openindiana Wiki.
> http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home
> Acually illumos even turned it's main page to wiki, to have less BS to be
> worried about.
>


> Surely this is not true and Openindiana is documented through Wiki and
> Opensolaris docs that need renewal,
> while large part of Openindiana functionality is mutual with illumos, too.
> Opensolaris docs are very large and very well written and there is not
> many project on internet with so many good docs like OI, you just choose
> not to see it.
> So this is not positive assertion at all toward the project nor reflects
> real  state of things.
>


> This is also false statement.
> One with a positive attitude tend to improve, not replace with something
> newer and wit less merit.
> You surely should spend more time on it and TALK to people about improving
> it, before jumping conclusions.
>

This you personal opinion only and the points listed by Michael are
objectively not completely addressed by the Wiki.
The matter has been discussed several times, including on IRC with you.
You have the right to disagree but please do not make generalities.

Instead of leaving the discussion getting out off hand and having to
reconnect pieces scattered across several emails, may I suggest that you
formalize your take on documentation ?
Please do it in a reasonable time frame so that we can keep the momentum of
Michael's initiative.

I am personally very positive about the proposed system as it solves
several shortcomings of the existing one. If not better proposition is
voiced and *implemented* I do not see why the idea cannot move forward.
If criticism does not lead to a better solution and offers no
implementation, one cannot justify not moving forward.

This is a discussion, let us remain open and courteous and let us get back
to the topics: technical benefits + contribution process.
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OpenIndiana Docs (proof of concept) - What is it all about?

2016-05-06 Thread Nikola M 

On 05/ 4/16 07:00 AM, Michael Kruger wrote:


* Community conduct
* Project visibility
* Proof of concepts

* Version control
* Hosting infrastructure
* Project marketing, SEO

* Existing docs (OSOL Docs)
* Viability/Usability of Wiki
* dlc.openindiana.org/docs
* Documentation Standards (media types, etc.)
* Licensing/Contributer agreements/copyrights, branding etc.


As I see you haven't start talking on any of this topics. Ah well.



So, this is my creative outlet. This is a place where I can express 
myself, learn, try new things, and explore new ideas. It's a place 
where I can (hopefully) make a difference.


So basically, you need a place to vent?
i think OI community can recognize there is much more then this to be 
connected to OI.


You need to understand WHY you support some actual project, possibly 
using it and wanting to have sucsess because you NEED it to work out.  
Not just some side-hobby because it is good place to spend your time 
without personal involvement part.
So think again about your motivation and get back when you have 
something more positive to say about OI.



If not, the project will eventually curl up and die.


No it will not cur.. and it surely does not depend on you..
Are you injecting to us some feeling of bad taste?

However, before any of that happens, people may find themselves 
needing to work alone or in small groups 


That way of working is not positive , all work needs to be public 
(therefore no submarines).
Constant communicating plans, intentions and work has a positive way of 
having feedback that can correct you in early stages and make it better.

So we should not support constantly including new submarines as a process.
You should as frequently and to many people: "what do you think?", "have 
any idea?" and not thinking you always (or ever) having the best one.
So accepting other peoples' reactions an guidance is crucial if you 
don't want to go underwater.


specifically and intentionally excluding individuals with problematic 
behaviors. This will occur because it's simply not possible to get 
anything done in an atmosphere of hostility, jumping to premature 
conclusions, or where kvetching is the rule of the day.


Coming from isolated environment, you misplace open reactions and idea 
and project building for hostility.


Actually, ANY request for actual hostility creation toward individuals , 
that you recommend as a way of doing things must be squashed instantly.
Trolling this project with "exclusion" of people as way of doing things 
will not be accepted.
ANYONE asking for any other person to be disgarded should be disgarded 
itself so that such unfriendly and inhumane requests you propose don't 
tore this community apart.


This idea of yours is a cancer and you are just reading a cure for it.
Also if you base your "inclusion" in "excluding" people as a main tool, 
you surely are _not_ a material for any type of human and project 
management in OI.


This leads me to suggest there should be an OpenIndiana 'Code of 
Conduct' to help reign in people with troublesome behaviors. After 
all, such individuals effectively prevent others from achieving 
anything meaningful. The future of the project may very well depend on 
it.


You just broke unofficial existing Code of conduct, that is not calling 
people themselves "kvetching" and bad names and therefore lowering 
discussions to off-topic and personal attacks.
Presenting my comments above I see you are not understanding how things 
are done openly, I suggest you don't get yourself into any type of 
creating Codes of conduct, especially not for OI.


Doing things openly - it is normal to have reactions and having them is 
exactly what IS positive.
And it is not normal to replicate closed, isolated and excluding 
environment that you are maybe used to.




 I wrote it all for the pure joy of writing. And in the spirit of 
community, it's free and available to all.


As said, you got to work on your motivations, but that's again, your 
personal thing and not putting personal things is a good way not to be 
ditched in off-topic.



1) Place documentation under distributed version control.
2) Lower the bar of entry to the documentation process.
3) Make changes and quickly deploy those changes in some kind of 
automated fashion (e.g. continuous integration).
4) Present the documentation in an organized and aesthetically 
pleasing way.


This is all already solved by Openindiana Wiki.
http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home
Acually illumos even turned it's main page to wiki, to have less BS to 
be worried about.


It's been said that a project lives or dies by it's documentation. 
Whether that's really true or not, I don't know, but the general 
perception for OpenIndiana is it's largely an undocumented project.


Surely this is not true and Openindiana is documented through Wiki and 
Opensolaris docs that need renewal,

while large part of Openindiana functionality is mutual with illumos,