Time to end this thread, folks.
-Matt
I would have preferred not to respond to any of this, but ...
On 9/10/2013 17:35, Dmitrij D. Czarkoff wrote:
> Put otherwise: I can do quite a lot of things using awk alone. What can I do
> with XML alone?
You are comparing a data format to an program. This question doesn't
merit a response.
>
On Tue, Sep 10, 2013 at 09:42:48AM +0200, John Marino wrote:
> Service recovery. I shouldn't have to manually restart web servers, php
> spawn, mail, etc., etc. for whatever reason. If it can be recovered
> automatically, it should happen.
Everyone would agree. The question here is: what prevents
On Tue, Sep 10, 2013 at 07:24:45AM +1000, Petr Janda wrote:
> I also think it's silly the best argument people can come up against SMF
> is "It's made by Sun." or "It uses XML, which is bad because I don't
> understand it".
Apparently, the main reason against SMF itself was that it doesn't provide
On Tue, Sep 10, 2013 at 08:18:13AM +1000, Petr Janda wrote:
> Using the same argument, we should replace everything, including Bourne
> shell(often hard to read syntax), awk (it's short for awkward yeah?),
> the user might have hard time understanding.
Flawed analogy: unlike awk and Bourne shell X
On the other hand, it makes sense. XML isn't a "programming" or
"scripting" language.
Somethings have to be done programatically.
The point is splitting execution and configuration.
--
Please use PGP to encrypt your email to ensure our privacy is respected.
signature.asc
Description: OpenPG
> Do those shell scripts belong to the program itself as opposed to a
> script that simply launched the executable?
>
> I guess I'd have to comb each of the 59 to ascertain...
I believe at least some of them are actually former SysV init scripts
that haven't been fully converted to manifests.
On 9/10/2013 13:54, joris dedieu wrote:
> 2013/9/10 Petr Janda :
>>
>> Have a look at the manifests, vast majority of them don't need shell
>> scripting.
>
> I disagree this point.
> Here a basic OpenIndiana distribution (SunOS blandine1 5.11 oi_151a7
> i86pc i386 i86pc Solaris) :
>
> - 172 manif
2013/9/10 Petr Janda :
>
>> So sure rcNG looses some process, does not understand parallel jobs,
>> spend time to fork, sleep, grep and so on, but it provides shell
>> conventions and tools to write proper startup scripts in any
>> situations and avoid the need to reinvent the wheel each time you h
http://www.oreillynet.com/pub/a/sysadmin/2006/04/13/using-solaris-smf.html
Excellent write up on SMF.
Petr
signature.asc
Description: OpenPGP digital signature
> See above -- it sacrifices everything important to me in conserve
> something that is not.
Absolutely, the entire field of Linux's and Unix's is slowly moving
towards something smarter than shell scripts.
In my opinion, DragonFly should keep on striding to be ahead of other
BSDs in it's own (so
> So sure rcNG looses some process, does not understand parallel jobs,
> spend time to fork, sleep, grep and so on, but it provides shell
> conventions and tools to write proper startup scripts in any
> situations and avoid the need to reinvent the wheel each time you have
> a non standard case. I
On 9/10/2013 09:30, joris dedieu wrote:
> expressiveness is IMHO the first need of a boot process. You tell the
> machine the way you want it to start. For me SMF does not answer this.
> Shell does.
I think we just got down to the crux of this.
You're talking about "boot process", how you want th
2013/9/9 John Marino :
> On 9/9/2013 18:40, joris dedieu wrote:
>>> - controlled shutdown
>>> - restart
>>> - dependancy map
>>> - parallelism
>>> could easily be tacked on to rcng with a bit of ingenuity, and probably by
>>> using
>>> simple shell conventions or minor tweaks to 'rcorder'/'rc.subr
On 9/10/2013 07:39, james wrote:
> On 09/09/2013 23:21, John Marino wrote:
>> 5) XML is parsed faster than YAML or JSON. It's superior that way.
>> Maybe we are talking milliseconds here but...
>
> Since when was XML parsed faster than JSON?
>
> Compliant XML parsing has a whole lot of complexity
On Tue, Sep 10, 2013 at 2:19 AM, joris dedieu wrote:
> 2013/9/10 John Marino :
> > On 9/10/2013 00:31, Outback Dingo wrote:
> >>
> >> actually i mentiioned it weeks ago... easier to integrate,
> >
> > Integrate into the BSD codebase? Where is the analysis to prove that
> > assertion?
> >
2013/9/10 John Marino :
> On 9/10/2013 00:31, Outback Dingo wrote:
>>
>> actually i mentiioned it weeks ago... easier to integrate,
>
> Integrate into the BSD codebase? Where is the analysis to prove that
> assertion?
>
>> easier to manage,
>
> Easier than what? Is there a survey or analy
On 09/09/2013 23:21, John Marino wrote:
5) XML is parsed faster than YAML or JSON. It's superior that way.
Maybe we are talking milliseconds here but...
Since when was XML parsed faster than JSON?
Compliant XML parsing has a whole lot of complexity that JSON does not have.
On Tuesday, September 10, 2013 08:18:13 Petr Janda wrote:
> Just how often does anyone admin need to write/change the start scripts?
Not very often, but it does happen. I wrote one called /etc/rc.d/henet which
starts a Hurricane Electric tunnel so that I have IPv6 addresses.
Pierre
--
gau do li
On 9/10/2013 00:31, Outback Dingo wrote:
>
> actually i mentiioned it weeks ago... easier to integrate,
Integrate into the BSD codebase? Where is the analysis to prove that
assertion?
> easier to manage,
Easier than what? Is there a survey or analysis to support that it is
easier tha
On Mon, Sep 9, 2013 at 6:26 PM, John Marino wrote:
> On 9/10/2013 00:13, Outback Dingo wrote:
> > i still believe launchd easier and the best solution
>
> Nobody until today was talking about launchd
> You don't define "easier".
> What is easier? Easier to port from Linux? Easier for a sysadmin
On 9/10/2013 00:13, Outback Dingo wrote:
> i still believe launchd easier and the best solution
Nobody until today was talking about launchd
You don't define "easier".
What is easier? Easier to port from Linux? Easier for a sysadmin to
run? Did anyone do a scientific study? If you were a lawy
On 9/9/2013 23:57, Tobias Weingartner wrote:
> "It uses XML, which is bad because I don't understand it" is a very
> reasonable argument. Especially if a significant portion of your
> customers/users say the same thing...
You're talking generically, which is fine.
However, this is a specific case
Using the same argument, we should replace everything, including Bourne
shell(often hard to read syntax), awk (it's short for awkward yeah?),
the user might have hard time understanding.
Just how often does anyone admin need to write/change the start scripts?
Petr
On 10/09/2013 7:57 AM, Tobias W
On Mon, Sep 9, 2013 at 5:57 PM, Tobias Weingartner wrote:
> "It uses XML, which is bad because I don't understand it" is a very
> reasonable argument. Especially if a significant portion of your
> customers/users say the same thing...
>
> Note, I didn't say you could not change it from what is th
"It uses XML, which is bad because I don't understand it" is a very
reasonable argument. Especially if a significant portion of your
customers/users say the same thing...
Note, I didn't say you could not change it from what is there now, but
changing it to something that less people understand is
> I think Chris's statement a silly thing to say. Have your heard the
> phrase, "If my aunt had a package, she'd be my uncle" ?
>
> rcng doesn't have these things. Until it does, it's not in the same
> conversation. Saying it would be equal if it had these things means
> nothing.
I also think
On 9/9/2013 18:40, joris dedieu wrote:
>> - controlled shutdown
>> - restart
>> - dependancy map
>> - parallelism
>> could easily be tacked on to rcng with a bit of ingenuity, and probably by
>> using
>> simple shell conventions or minor tweaks to 'rcorder'/'rc.subr', etc. rather
>> than strict /
> could easily be tacked on to rcng with a bit of ingenuity, and probably by
> using
> simple shell conventions or minor tweaks to 'rcorder'/'rc.subr', etc. rather
> than strict / annoying / static verification, and without destryoing the
> simplicity and elegance of rcng either for the common cas
On Tue, Sep 3, 2013 at 8:47 AM, Chris Turner
wrote:
> On 08/27/13 06:44, John Marino wrote:
>
>> Also, really there should be a front-end tool for designing SMF
>> manifests, there's nothing saying it has to be written directly. I'm
>> guessing there are already such tools.
>>
>
> If you need a f
On 08/27/13 06:44, John Marino wrote:
Also, really there should be a front-end tool for designing SMF
manifests, there's nothing saying it has to be written directly. I'm
guessing there are already such tools.
If you need a front end tool to configure your init system,
you're doing it wrong.
On Tue, Aug 27, 2013 at 1:44 PM, John Marino wrote:
> On 8/27/2013 13:20, Petr Janda wrote:
Personally, I think smf manifests being in XML(i dislike) may be a
problem with many users who
are not used to reading and writing XML files.
>>>
>>>
>>> That's one of the things I
On 8/27/2013 13:20, Petr Janda wrote:
>>> Personally, I think smf manifests being in XML(i dislike) may be a
>>> problem with many users who
>>> are not used to reading and writing XML files.
>>
>>
>> That's one of the things I hated on SMF!
>> But I guess the configuration can be easily
>> Personally, I think smf manifests being in XML(i dislike) may be a
>> problem with many users who
>> are not used to reading and writing XML files.
>
>
> That's one of the things I hated on SMF!
> But I guess the configuration can be easily translated from XML to
> text and vice-ver
On Tue, Aug 27, 2013 at 1:20 AM, Edward Martinez
wrote:
> On 8/26/2013 2:16 AM, Petr Janda wrote:
>>
>> and would it be advantageous for DragonFly BSD?
>
>
> Personally, I think smf manifests being in XML(i dislike) may be a
> problem with many users who
> are not used to reading and wr
On 8/26/2013 2:16 AM, Petr Janda wrote:
and would it be advantageous for DragonFly BSD?
Personally, I think smf manifests being in XML(i dislike) may be a
problem with many users who
are not used to reading and writing XML files.
On Mon, Aug 26, 2013 at 3:14 PM, John Marino wrote:
> On 8/27/2013 00:09, Freddie Cash wrote:
> > So, by looking at the LibreOffice codebase, you're looking at:
> > - original, ancient StarOffice code
> > - Sun Microsystem's updated OpenOffice.org code
> > - Oracle OpenOffice.org code
> >
On 8/27/2013 00:09, Freddie Cash wrote:
> So, by looking at the LibreOffice codebase, you're looking at:
> - original, ancient StarOffice code
> - Sun Microsystem's updated OpenOffice.org code
> - Oracle OpenOffice.org code
> - Apache OpenOffice.org code (maybe)
> - LibreOffice code
>
>
On Mon, Aug 26, 2013 at 2:52 PM, Petr Janda wrote:
>
> > Having looked at the LibreOffice code base, I can say for sure Sun did
> > many unlogical things with it. We could even call that crap.
> >
> > NIH syndrom, groupthink, ingrained development practices etc... were
> > probably more likely mot
> Having looked at the LibreOffice code base, I can say for sure Sun did
> many unlogical things with it. We could even call that crap.
>
> NIH syndrom, groupthink, ingrained development practices etc... were
> probably more likely motivators than maintaining long term code quality
> and cleanli
>
> It also can perform recovery when a daemon goes down and it has a
> detailed map of all the dependencies the service needs. I find it
> interesting that someone with experience with both finds them basically
> equivalent.
>
According to Wikipedia, SMF also provides parallel start-up of serv
On Mon, Aug 26, 2013 at 06:18:45PM +0200, John Marino wrote:
>
> Why would Sun Microsystems invest so much to replace a system with an
> equivalent one? That is not logical to me.
Having looked at the LibreOffice code base, I can say for sure Sun did
many unlogical things with it. We could even
On 8/26/2013 17:49, Luca Ferrari wrote:
>
> If I remember right, SMF not only does a controlled startup of a
> service, but also a controlled shutdown, that is something that seems
> to me lacks in rc. In other words, once the network is going down,
> also all daemons that rely on the network are,
On Mon, Aug 26, 2013 at 4:55 PM, Andrey Oktyabrskiy wrote:
> I do not see any crucial advantages over rcNG.
If I remember right, SMF not only does a controlled startup of a
service, but also a controlled shutdown, that is something that seems
to me lacks in rc. In other words, once the network i
On 26.08.2013 13:16, Petr Janda wrote:
What's the general consensus on the System Management Facility
(developed for Solaris), and would it be advantageous for DragonFly BSD?
I do not see any crucial advantages over rcNG.
(I've managed Solaris servers about a 7 years)
On 8/26/2013 11:16, Petr Janda wrote:
> Hi,
>
> What's the general consensus on the System Management Facility
> (developed for Solaris), and would it be advantageous for DragonFly BSD?
I bring up the subject from time to time and I'm a huge fan of it.
I actually have a long term goal of trying t
Hi,
What's the general consensus on the System Management Facility
(developed for Solaris), and would it be advantageous for DragonFly BSD?
How difficult would it be to port on scale to 1-10?
Is there any kernel related bits that would need to be ported as well?
Petr
signature.asc
Descriptio
47 matches
Mail list logo
