Edward Bartolo writes:
So, I joined Devuan to contribute code. But, I am NOT appreciated, and
to be sincere, sometimes I even think about leaving the project
altogether. I am being denigrated just because I make a conscious
effort to write simple code.
I think not. Because you say things like "
On 20/06/16 00:40, Steve Litt wrote:
On Sun, 19 Jun 2016 17:18:48 +0200
Edward Bartolo wrote:
So, I joined Devuan to contribute code. But, I am NOT appreciated, and
to be sincere, sometimes I even think about leaving the project
altogether. I am being denigrated just because I make a conscious
On 2016-06-19 16:35, Steve Litt wrote:
> On Sun, 19 Jun 2016 17:18:48 +0200
> Edward Bartolo wrote:
>
> > So, I joined Devuan to contribute code. But, I am NOT appreciated, and
> > to be sincere, sometimes I even think about leaving the project
> > altogether. I am being denigrated just because I
Edward Bartolo writes:
> System initialisation is NO religiously enshrined mystery that is
> highly claimed to be beyond human comprehension.
Was this supposed to have any relation to the text I wrote? If so, I'm
oblivious to it. As I tried to describe below, system initialization is
really not c
Hi Edward,
On 06/19/2016 06:15 PM, Edward Bartolo wrote:
So, I joined Devuan to contribute code. But, I am NOT appreciated, and
to be sincere, sometimes I even think about leaving the project
altogether. I am being denigrated just because I make a conscious
effort to write simple code. But thi
On Sun, 19 Jun 2016 17:18:48 +0200
Edward Bartolo wrote:
> So, I joined Devuan to contribute code. But, I am NOT appreciated, and
> to be sincere, sometimes I even think about leaving the project
> altogether. I am being denigrated just because I make a conscious
> effort to write simple code.
On Sun, Jun 19, 2016 at 12:20:46PM -0400, Steve Litt wrote:
> On Sun, 19 Jun 2016 08:30:00 +0200
> Edward Bartolo wrote:
>
> > Hi,
> >
> > System initialisation is NO religiously enshrined mystery that is
> > highly claimed to be beyond human comprehension.
>
> The preceding sentence is a quote
On Sun, 19 Jun 2016 13:54:29 +
Stephanie Daugherty wrote:
> When recovering from systermd-related breakage while first trying out
> Debian jesse, I ended up booting with init=/bin/bash a lot.
>
> You can rather easily bring up a fully functional system that way, at
> least for long enough t
On Sun, 19 Jun 2016 08:30:00 +0200
Edward Bartolo wrote:
> Hi,
>
> System initialisation is NO religiously enshrined mystery that is
> highly claimed to be beyond human comprehension.
The preceding sentence is a quote I think should be viewed far and
wide. With Edward's permission, I'd like to
Hi,
Thanks for taking some of your time to give me advice. I appreciate
such people who instead of flushing their anger in the mailing list on
innocent contributed remain positive to contribute tangibly.
I have been suggested to read books about Unix/Linux systems and the C
language. However, the
On Sun, 6/19/16, Stephanie Daugherty wrote:
Subject: Re: [DNG] Mini init script written in Perl boots.
To: "Edward Bartolo" , "Rainer Weikusat"
Cc: dng@lists.dyne.org
Date: Sunday, June 19, 2016, 8:54 AM
>
> When recovering from systermd-related breakage whi
When recovering from systermd-related breakage while first trying out
Debian jesse, I ended up booting with init=/bin/bash a lot.
You can rather easily bring up a fully functional system that way, at least
for long enough to fire up a browser, find the problem, and then recover.
My process for d
Hi,
System initialisation is NO religiously enshrined mystery that is
highly claimed to be beyond human comprehension. I can understand the
position help by anyone that an init is so central to an OS that it
must be coded scrupulously. And, given time, I think, I will
eventually come back with som
Lars Noodén writes:
> On 06/17/2016 09:36 PM, KatolaZ wrote:
> [snip]
>> Unfortunately, system initialisation is really a bit more complicated
>> than that, whether you like it or not.
> [snip]
>
> Is there a concise summary somewhere of what system initialization
> entails? Or is it dependent on
On Sat, Jun 18, 2016 at 02:50:04PM +0200, Edward Bartolo wrote:
> Hi,
>
> On DNG I was suggested a book or two about unix. The aim was to read
> about how processes are handled by the OS and what is important to
> understand to properly write code for unix. However, when I checked
> the prices I w
Edward:
...
> The question is, can I read some *reliable* free ebook to enhance my
> knowledge of both Unix OSs and C?
Doing a quick search I find:
https://en.wikibooks.org/wiki/C_Programming
http://www.computer-books.us/c.php
http://www.cs.cf.ac.uk/Dave/C/CE.html
http://publications.gbdirect.co.
Hi,
On DNG I was suggested a book or two about unix. The aim was to read
about how processes are handled by the OS and what is important to
understand to properly write code for unix. However, when I checked
the prices I was let down: they are too expensive for me considering I
am coding on a volu
Le 18/06/2016 10:41, Arnt Gulbrandsen a écrit :
Didier Kryn writes:
Did you try it? The documentation of Bash is not clear. I think
it says that a bash script can only wait the processes it has
launched. Does it mean it maintains a list of them, or is it just the
consequence of the fact th
Arnt:
...
> Processes cannot adopt children; the kernel foists processes on pid 1
> without asking either pid 1 or any other process.
??? I see no problems doing a wait() in a program to catch a childs
termination. There even is an example in wait()'s manpage.
> Bash's source code is very, very
Edward Bartolo:
> So to replace my car's battery, I have to first have an understanding
> like that of a car engineer.
...
No, good engineering practice is to to modularize, to make parts
replacable, to make them more independent.
> What I am being repeatedly battered to
> accept, is the irratio
Didier Kryn writes:
Did you try it? The documentation of Bash is not clear. I
think it says that a bash script can only wait the processes it
has launched. Does it mean it maintains a list of them, or is it
just the consequence of the fact that any process but pid1
cannot adopt others' chi
Le 17/06/2016 21:44, Adam Borowski a écrit :
Why would you even need a separate process to spawn the shell? /bin/bash is
a perfectly capable init that can reap zombies, start processes, do any
interactive tasks, or be automated (.bashrc, trap EXIT, etc).
Did you try it? The documentation of
Didier Kryn writes:
BTW, I'm not sure what sysvinit does with gettys. Does it
launch them once for all or does it supervise them?
It acts as directed by /etc/inittab, which generally says to respawn.
Arnt
___
Dng mailing list
Dng@lists.dyne.org
https
Le 17/06/2016 20:06, Steve Litt a écrit :
So my personal, and obviously your mileages do vary, priority is the
simplicity of a do-one-thing PID1, because the "PID1 alone in the
forest" happens so rarely, and at least in my situation the results
aren't earth shaking.
My argument was a tentativ
You don't have to understand the universe. But you do have to
understand that to the professional programmers on the list, it is more
than possible to feel no awe at the sight of sysvinit. It is quite
reasonable. After all, it is a small, easily understood program. Modern
programs are a hundred
Hi,
So to replace my car's battery, I have to first have an understanding
like that of a car engineer. What I am being repeatedly battered to
accept, is the irrationality that the whole always entirely affects
the parts! I take this as an attack on my intelligence: this is
insulting my intelligenc
On 06/17/2016 04:25 PM, KatolaZ wrote:
On Fri, Jun 17, 2016 at 09:44:56PM +0200, Adam Borowski wrote:
>On Fri, Jun 17, 2016 at 08:19:12PM +0100, KatolaZ wrote:
> >Then you can provide any other alternative definition of "init
> >system", but if there is no procedure that does those things fo
On Fri, 2016-06-17 at 20:19 +0100, KatolaZ wrote:
> On Fri, Jun 17, 2016 at 03:02:54PM -0400, Steve Litt wrote:
>
> Well, if your definition of "initialisation" is just "getting
> something that can boot and shut down without requiring journal
> restores or fsck", then I don't see why Edward is ca
Hi,
So, in essence I am being told to get away as otherwise I would be
ruining my reputation or coding broken code by design.
I will recount what I did when GRUB2 started insisting on using
scripts. As I have a multiboot system, I understood immediately that
the 'new' GRUB version could become a
On Fri, Jun 17, 2016 at 09:25:06PM +0100, KatolaZ wrote:
> On Fri, Jun 17, 2016 at 09:44:56PM +0200, Adam Borowski wrote:
> > Specifying init=/bin/bash via grub on the cmdline is a common rescue
> > technique for systems with a broken init. Guess what init implementation
> > needs to be rescued th
On Fri, Jun 17, 2016 at 09:44:56PM +0200, Adam Borowski wrote:
> On Fri, Jun 17, 2016 at 08:19:12PM +0100, KatolaZ wrote:
> > Then you can provide any other alternative definition of "init
> > system", but if there is no procedure that does those things for you,
> > then you have to manually do tho
On Fri, Jun 17, 2016 at 07:48:11PM +0100, KatolaZ wrote:
>
> I would say that nowadays things like:
>
> - Mounting filesystems
> - Configuring networking
> - Configuring consoles
> - Launching daemons for different services
> - Offering logins
>
> are all part fo what I consider "system initiali
On Fri, Jun 17, 2016 at 08:19:12PM +0100, KatolaZ wrote:
> Then you can provide any other alternative definition of "init
> system", but if there is no procedure that does those things for you,
> then you have to manually do those tasks, at each reboot. In that case
> the 12-lines init might just s
On Fri, Jun 17, 2016 at 03:02:54PM -0400, Steve Litt wrote:
> KatolaZ wrote:
>
[cut]
> > I am sorry to look harsh here, but what the DNG list might have
> > "learned" from this "experiment" is just to create a process which
> > forks a child and wait forever for its children and grand-children
On Fri, 17 Jun 2016 19:36:49 +0100
KatolaZ wrote:
> On Fri, Jun 17, 2016 at 02:14:10PM -0400, Steve Litt wrote:
> > On Fri, 17 Jun 2016 15:31:28 +0200
> > Irrwahn wrote:
> >
> > > As for the educational value: I fail to see what good does
> > > learning things already proven wrong.
> >
> >
On Fri, 17 Jun 2016 21:40:11 +0300
Lars Noodén wrote:
> On 06/17/2016 09:36 PM, KatolaZ wrote:
> [snip]
> > Unfortunately, system initialisation is really a bit more
> > complicated than that, whether you like it or not.
> [snip]
>
> Is there a concise summary somewhere of what system initiali
On Fri, Jun 17, 2016 at 09:40:11PM +0300, Lars Noodén wrote:
> On 06/17/2016 09:36 PM, KatolaZ wrote:
> [snip]
> > Unfortunately, system initialisation is really a bit more complicated
> > than that, whether you like it or not.
> [snip]
>
> Is there a concise summary somewhere of what system initi
On Fri, 17 Jun 2016 20:19:40 +0200
Irrwahn wrote:
> Far from it. You are humiliating yourself by showing more than
> just reluctance to accept anything beyond your preconceptions.
Urban, let it go. Edward has a different way of going about stuff than
you. No biggy.
Edward, don't be so sensit
On 06/17/2016 09:36 PM, KatolaZ wrote:
[snip]
> Unfortunately, system initialisation is really a bit more complicated
> than that, whether you like it or not.
[snip]
Is there a concise summary somewhere of what system initialization
entails? Or is it dependent on accumulated experience and not co
On Fri, Jun 17, 2016 at 02:14:10PM -0400, Steve Litt wrote:
> On Fri, 17 Jun 2016 15:31:28 +0200
> Irrwahn wrote:
>
> > As for the educational value: I fail to see what good does learning
> > things already proven wrong.
>
> I don't know what got proven wrong, but as a result of this thread, th
On Fri, 17 Jun 2016 16:55:40 +0200
Irrwahn wrote:
> A minimal PID1 (written in whatever language) is not an init
> system.
Everyone should note the preceding sentence. A lot of people use PID1
and "init" interchangeably, and that's wrong and leads to problems. As
a matter of fact, it seems li
On Fri, 17 Jun 2016 20:01:37 +0200, Edward Bartolo wrote:
> On Fri, Jun 17, 2016 at 04:55:40PM +0200, Irrwahn wrote:
>>
>> It's this arrogant attitude of "alright, got it, easy enough,
>> now I'm gonna improve on it" without bothering to actually
>> get to the bottom of even the basic concepts behi
On Fri, 17 Jun 2016 15:31:28 +0200
Irrwahn wrote:
> As for the educational value: I fail to see what good does learning
> things already proven wrong.
I don't know what got proven wrong, but as a result of this thread, the
average DNG inhabitant now knows as much about init as I, the author
of
On Fri, 17 Jun 2016 12:56:16 -0400, Hendrik Boom wrote:
> On Fri, Jun 17, 2016 at 04:55:40PM +0200, Irrwahn wrote:
>>
>> It's this arrogant attitude of "alright, got it, easy enough,
>> now I'm gonna improve on it" without bothering to actually
>> get to the bottom of even the basic concepts behi
On Fri, Jun 17, 2016 at 04:55:40PM +0200, Irrwahn wrote:
>
> It's this arrogant attitude of "alright, got it, easy enough,
> now I'm gonna improve on it" without bothering to actually
> get to the bottom of even the basic concepts behind it, that
> brought us systemd and other crap. If you keep thi
On Fri, 17 Jun 2016 12:02:35 +0200
Didier Kryn wrote:
> However I think init must do more on the long run than reaping
> zombies. It should ensure in some way that at least someone can login
> to the system to do something, for example it should supervise a
> supervisor, or at least superv
On Fri, Jun 17, 2016 at 04:55:40PM +0200, Irrwahn wrote:
>
> It's this arrogant attitude of "alright, got it, easy enough,
> now I'm gonna improve on it" without bothering to actually
> get to the bottom of even the basic concepts behind it, that
> brought us systemd and other crap. If you keep
On Fri, 17 Jun 2016 17:42:39 +0200, Edward Bartolo wrote:
>> what the heck did you think the
>> last line of Felker's original code did?
> Felker's last line:
> return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
>
> In Devuan rc is found in /etc/init.d meaning I had to edit the
Hi,
<<
what the heck did you think the
last line of Felker's original code did?
>>
Felker's last line:
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
In Devuan rc is found in /etc/init.d meaning I had to edit the code.
Second, to load XFCE4.10 I had to also call "rc 2". Calli
On Fri, 17 Jun 2016 16:09:00 +0200, Edward Bartolo wrote:
> Hi,
>
> <<
> If 16 lines of C pose a mystery, one should look for another hobby.
> Or get a clue already.
>>>
> I was NOT referring to 16 lines of code, but to the source code for
> established inits like sysvinit, runit and systemd.
Ap
Hi,
<<
If 16 lines of C pose a mystery, one should look for another hobby.
Or get a clue already.
>>
I was NOT referring to 16 lines of code, but to the source code for
established inits like sysvinit, runit and systemd. If *at the first
glance*, these projects do not instill some feeling of awe,
On Fri, 17 Jun 2016 07:54:33 +0200, Edward Bartolo wrote:
[...]
> I think it is a mistake to expect a few lines of code written in
> whatever language to outperform other init projects written in several
> thousand lines of code that are well debugged and mature. The place
> for these little script
Le 17/06/2016 14:44, Joel Roth a écrit :
Edward Bartolo wrote:
>PID 1 should fork only once to run the first script that loads the
>operating system. Once execution enters the infinite loop there is no
>way of it jumping to somewhere else.
I'm guessing the loop doesn't actually loop, as the
wai
Edward Bartolo wrote:
> PID 1 should fork only once to run the first script that loads the
> operating system. Once execution enters the infinite loop there is no
> way of it jumping to somewhere else.
I'm guessing the loop doesn't actually loop, as the
wait call just blocks.
> Therefore, only
Le 17/06/2016 12:22, Irrwahn a écrit :
On Fri, 17 Jun 2016 12:04:03 +0200, Didier Kryn wrote:
>Le 17/06/2016 07:24, Steve Litt a écrit :
>>Edward's pid1 shellscript has exactly one child, /sbin/osloader.sh.
>>That child can fork off a whole lot more processes. So theoretically,
>>with Edward's
On Fri, 17 Jun 2016 03:44:17 +0200, Adam Borowski wrote:
> Yeah, we need to use an efficient language!
>
> .globl _start
> .data
> nopid1: .ascii "No pid 1, no fun.\n"
[assemly snipped]
> Hmmm... I think I'd go with Perl after all.
Or C, which in the case of init.c is really used
as some
On Fri, 17 Jun 2016 12:04:03 +0200, Didier Kryn wrote:
> Le 17/06/2016 07:24, Steve Litt a écrit :
>> Edward's pid1 shellscript has exactly one child, /sbin/osloader.sh.
>> That child can fork off a whole lot more processes. So theoretically,
>> with Edward's PID1 instead of sysvinit, only one proc
On Thu, 16 Jun 2016 14:14:48 -1000, Joel Roth wrote:
> I did a test with Memory::Usage, that reports the
> interpreter's virtual memory size as 22MB. Seems cheap
> to me.
Depends: It is not cheap compared to the whopping < 10 KB
executable size and < 200 byte of VSZ that suckless init[1]
cashes
Le 17/06/2016 07:24, Steve Litt a écrit :
Edward's pid1 shellscript has exactly one child, /sbin/osloader.sh.
That child can fork off a whole lot more processes. So theoretically,
with Edward's PID1 instead of sysvinit, only one process would have a
PPID of 1, that being /sbin/osloader.sh.
Y
Le 16/06/2016 23:16, Steve Litt a écrit :
If the machine were anything but a demonstration experimental machine,
so would I contemplate suicide or systemd. Same with Python, Ruby, and
(urk) Javascript. But truth be told, if PID1 were written in Lua, I
would not be dismayed in the slightest.
Hi,
<<
The part I am wondering about has to do with what kind of model actual
sysvinit follows. In regular devuan, I see that my daemons are children
of PID 1 which is /sbin/init.
>>
As far as I have understood, /sbin/init calls /etc/init.d/rc X to load
the OS which means it is the script that l
On 06/17/2016 08:54 AM, Edward Bartolo wrote:
[snip]
> PID 1 should fork only once to run the first script that loads the
> operating system. Once execution enters the infinite loop there is no
> way of it jumping to somewhere else. Therefore, only one child is
> forked. This child should terminate
Hi,
Initially I started with C and still believe it is the best language
as it avoids having to link to external .so libraries and gcc
compiles efficient code. However, I was shown that there was interest
by some who wanted a script. Therefore, I produced a minimal
rudimentary Perl script that ma
On Fri, 17 Jun 2016 04:43:28 +0300
Lars Noodén wrote:
> On 06/16/2016 11:01 PM, Edward Bartolo wrote:
> [snip]
> > if (fork()) {
> > # We are in the parent which must reap zombies.
> > while(1) {
> > $status = wait();
> > }
> > } else {
> > # We are in the child which must load
On Thu, Jun 16, 2016 at 10:47:42PM +0200, Irrwahn wrote:
> For the record: Should I ever find myself sitting at a
> machine running a Perl interpreter for PID1, I'd either
> immediately kill myself or drink the SystemD Kool-Aid
> by the gallon. (The net effect not being that different.)
On Thu,
On 06/16/2016 11:01 PM, Edward Bartolo wrote:
[snip]
> if (fork()) {
> # We are in the parent which must reap zombies.
> while(1) {
> $status = wait();
> }
> } else {
> # We are in the child which must load the operating system by executing a
> script
>
> exec("/sbin/oslo
Steve Litt wrote:
> Bear in mind that Perl is different on every computer due to CPAN.
??
I did a test with Memory::Usage, that reports the
interpreter's virtual memory size as 22MB. Seems cheap
to me.
We've come a long way since the IBM-PC with 20MB hard disk.
> But as an educational thing,
On Thu, 16 Jun 2016 17:16:38 -0400, Steve wrote in message
<20160616171638.42400...@mydesk.domain.cxm>:
> If the machine were anything but a demonstration experimental machine,
> so would I contemplate suicide or systemd. Same with Python, Ruby, and
> (urk) Javascript. But truth be told, if PID1
If the machine were anything but a demonstration experimental machine,
so would I contemplate suicide or systemd. Same with Python, Ruby, and
(urk) Javascript. But truth be told, if PID1 were written in Lua, I
would not be dismayed in the slightest.
SteveT
Steve Litt
June 2016 featured book: Trou
On Thu, 16 Jun 2016 22:01:32 +0200
Edward Bartolo wrote:
> Hi,
>
> The following simple Perl script successfully booted a useable
> XFCE4.10 session. Orderly shutdown was done through using "agetty tty1
> &", logging in as root in the tty1 terminal, and issuing the command:
> "/etc/init.d/rc 0".
P.S.:
For the record: Should I ever find myself sitting at a
machine running a Perl interpreter for PID1, I'd either
immediately kill myself or drink the SystemD Kool-Aid
by the gallon. (The net effect not being that different.)
U.
On Thu, 16 Jun 2016 22:28:31 +0200, Irrwahn Grausewitz wrote
On Thu, 16 Jun 2016 22:01:32 +0200, Edward Bartolo wrote:
> The Perl script:
> --
>
> #!/usr/bin/perl -w
>
> if ($<) {
> printf "Only root can run this program.\n";
> exit 1;
> }
The real user ID the script is running under (represented
by "$<") should be of no conc
72 matches
Mail list logo
