sysvinit vs systemd

[F Russell]

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.

RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while transmogrifying
it in the process.

[Aragorn]

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init
scripts (or simliar situations).
That's not much different from what systemd and other members of
the zoo offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.

If it was, then it would have been called initd. ;) It's called
systemd because it's intended as a kind of userland kernel — a watchdog
of some sorts.

Post by F Russell
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

No, that means that in RedHat *proper*, they are seeking to abandon the
sysvinit compatibility scripts which are currently still being used by
certain system services that haven't been ported to systemd yet.

Post by F Russell
RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while
transmogrifying it in the process.

Even version 2 of the GNU General Public License does not allow them to
proprietarize the Linux kernel, so what you're saying doesn't make any
sense.

Furthermore, I'm not going to deny that RedHat is definitely pushing
its own vision onto the rest of the GNU/Linux landscape, but it's not
going to go without resistance.

The code is still FLOSS, so as soon as someone's had enough of their
antics, the code will get forked. In addition to that, there are
plenty of distributions that have resisted the push toward systemd and
are still offering an alternative init system — of which there are
many, including the traditional sysvinit.

RedHat is never going to become a monopolist, for all of the above
reasons. Hell, Microsoft and Apple are both proprietary software
companies, and even they don't have an absolute monopoly.

Microsoft only got to its dominance in the desktop market — and mind
you, that's the only market segment they have any dominance in —
through its bundle sales with hardware vendors. If it were purely up
to the merits of the Windows platform, then they wouldn't have stood a
chance.

RedHat doesn't even have the financial means to pull off what Microsoft
did in the 1980s and 1990s — and what it's still doing today.

There is nothing to fear, as real as you perceive the threat to be.
It's FLOSS. You will *always* have a choice.

[Soviet_Mario]

Post by Aragorn

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init
scripts (or simliar situations).
That's not much different from what systemd and other members of
the zoo offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.

If it was, then it would have been called initd. ;) It's called
systemd because it's intended as a kind of userland kernel — a watchdog
of some sorts.

Post by F Russell
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

No, that means that in RedHat *proper*, they are seeking to abandon the
sysvinit compatibility scripts which are currently still being used by
certain system services that haven't been ported to systemd yet.

Post by F Russell
RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while
transmogrifying it in the process.

Even version 2 of the GNU General Public License does not allow them to
proprietarize the Linux kernel, so what you're saying doesn't make any
sense.
Furthermore, I'm not going to deny that RedHat is definitely pushing
its own vision onto the rest of the GNU/Linux landscape, but it's not
going to go without resistance.
The code is still FLOSS, so as soon as someone's had enough of their
antics, the code will get forked. In addition to that, there are
plenty of distributions that have resisted the push toward systemd and
are still offering an alternative init system — of which there are
many, including the traditional sysvinit.
RedHat is never going to become a monopolist, for all of the above
reasons. Hell, Microsoft and Apple are both proprietary software
companies, and even they don't have an absolute monopoly.

uhm ... but things might scale badly downwards to such a
point that, broken some minimal threshold in the developer
number, viability gets lost :\
Is this not a risk ? I dunno the numbers of the various
communities, I'm just speculating theoretically

Post by Aragorn
Microsoft only got to its dominance in the desktop market — and mind
you, that's the only market segment they have any dominance in —
through its bundle sales with hardware vendors. If it were purely up
to the merits of the Windows platform, then they wouldn't have stood a
chance.
RedHat doesn't even have the financial means to pull off what Microsoft
did in the 1980s and 1990s — and what it's still doing today.

sb told me RedHat was purchased by IBM. True news ?

Post by Aragorn
There is nothing to fear, as real as you perceive the threat to be.
It's FLOSS. You will *always* have a choice.

[Aragorn]

Post by Soviet_Mario

Post by Aragorn
Furthermore, I'm not going to deny that RedHat is definitely pushing
its own vision onto the rest of the GNU/Linux landscape, but it's
not going to go without resistance.
The code is still FLOSS, so as soon as someone's had enough of their
antics, the code will get forked. In addition to that, there are
plenty of distributions that have resisted the push toward systemd
and are still offering an alternative init system — of which there
are many, including the traditional sysvinit.
RedHat is never going to become a monopolist, for all of the above
reasons. Hell, Microsoft and Apple are both proprietary software
companies, and even they don't have an absolute monopoly.

uhm ... but things might scale badly downwards to such a
point that, broken some minimal threshold in the developer
number, viability gets lost :\
Is this not a risk ? I dunno the numbers of the various
communities, I'm just speculating theoretically

Well, systemd, and for that matter, GNOME, have been around for a long
time now — systemd since 2012, and GNOME since the late 1990s — and
there are still plenty of distributions that don't use either — almost
a new one every day. Code is getting forked all the time as well.

The FLOSS community is very large, very diverse, and very creative. So
I wouldn't worry too much about that. ;)

[Soviet_Mario]

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
From a only formal view, to define a single uniform
interface (a standardization of the interface layer) is a
good thing in itself.
Posix is an attempt in that direction, and separates the
interface layer (declarative) and its implementation

what could be (and seem to be bad) is another : to implement
the layer interface as a single monolithic behemoth instead
of independent modules.
There is no true necessity this should happen

This said, I do not have the particular skill even to assess
if this standard interface has been chosen as the best
possible. Ample discussion should precede a similar approach
(the longlasting birth of POSIX itself and its partial yet
coverage and support is symptomatic of the difficulty of
having everybody to agree to an external formal standard ...
but it is the only good way to describe interactions between
things loosely bound)

Post by F Russell
RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while transmogrifying
it in the process.

[William Unruh]

Post by Soviet_Mario

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
From a only formal view, to define a single uniform
interface (a standardization of the interface layer) is a
good thing in itself.
Posix is an attempt in that direction, and separates the
interface layer (declarative) and its implementation
what could be (and seem to be bad) is another : to implement
the layer interface as a single monolithic behemoth instead
of independent modules.
There is no true necessity this should happen

And is also not what systemd does. It sets up a huge buch of modules
(the .service files/programs) which acrually carry out the
initialisation, with rules as to dependencies so they can be run in
parallel. Many are C programs, which one could object to, but then all
of the kernel moduels are programs, not scripts.

Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

Post by Soviet_Mario
This said, I do not have the particular skill even to assess
if this standard interface has been chosen as the best
possible. Ample discussion should precede a similar approach
(the longlasting birth of POSIX itself and its partial yet
coverage and support is symptomatic of the difficulty of
having everybody to agree to an external formal standard ...
but it is the only good way to describe interactions between
things loosely bound)

Post by F Russell
RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while transmogrifying
it in the process.

absconding? Hardly. It is there for all to see and use. systemd is free
and open source.
And everybody writing programs "transmorgify" things.
In the spirit of Linux they have offered their program for others to
use. And others do use it because it does needed things.

[Mike Easter]

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

I also think that Poettering's adverse personality characteristics and
Siever's adverse behaviors shouldn't be part of the arguments weighed in
pro/con systemd considerations.

[Carlos E.R.]

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

And, traditional syslog implementations can also/instead store the logs
in binary format. In databases, such as mysql.

Post by Mike Easter
I also think that Poettering's adverse personality characteristics and
Siever's adverse behaviors shouldn't be part of the arguments weighed in
pro/con systemd considerations.

Well, we are human...

[William Unruh]

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Post by Carlos E.R.
And, traditional syslog implementations can also/instead store the logs
in binary format. In databases, such as mysql.

Post by Mike Easter
I also think that Poettering's adverse personality characteristics and
Siever's adverse behaviors shouldn't be part of the arguments weighed in
pro/con systemd considerations.

Well, we are human...

[Carlos E.R.]

Post by William Unruh

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Did you read about cryptographic keys and signatures?

[William Unruh]

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Did you read about cryptographic keys and signatures?

What has that to do with anything? youcan sign text logs just as easily
as binary logs. Or do you mean that say Mageia signs the logs, with a
cryptographic key on your machine, where you can get it and use it as
well after you have changed the logs? Ie, what are you trying to say?

[Carlos E.R.]

Post by William Unruh

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Did you read about cryptographic keys and signatures?

What has that to do with anything? youcan sign text logs just as easily
as binary logs. Or do you mean that say Mageia signs the logs, with a
cryptographic key on your machine, where you can get it and use it as
well after you have changed the logs? Ie, what are you trying to say?

Yes, that.

Systemd journal can sign each entry cryptographically and can thus prove
that nothing was modified. It is not a feature of particular interest to
me, so I have not looked into how to do this verification. But I know it
is one of the systemd journal features.

Google:

<https://unix.stackexchange.com/questions/347499/how-does-journalctl-sign-the-logs-if-the-the-verification-key-should-be-stored>



+++....................
Firstly, we need to understand some points given by the LWN article :
Forward secure sealing[1]

* FSS [Forward Secure Sealing] provides a way to at least detect
tampering using only a single system, though it won't provide all of the
assurances that external logging can.

* the binary logs handled by the systemd journal can be "sealed"
at regular time intervals. That seal is a cryptographic operation on the
log data such that any tampering prior to the seal can be detected.

* The algorithm for FSS is based on "Forward Secure Pseudo Random
Generators" (FSPRG),

* One key is the "sealing key" which is kept on the system, and
the other is the "verification key" which should be securely stored
elsewhere. Using the FSPRG mechanism, a new sealing key is generated
periodically using a non-reversible process. The old key is then
securely deleted from the system after the change.

* The verification key can be used to calculate the sealing key
for any given time range. That means that the attacker can only access
the current sealing key (which will presumably be used for the next
sealing operation), while the administrator can reliably generate any
sealing key to verify previous log file seals. Changing log file entries
prior to the last seal will result in a verification failure.
....................++-

[1] <https://lwn.net/Articles/512895/>

[William Unruh]

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Did you read about cryptographic keys and signatures?

What has that to do with anything? youcan sign text logs just as easily
as binary logs. Or do you mean that say Mageia signs the logs, with a
cryptographic key on your machine, where you can get it and use it as
well after you have changed the logs? Ie, what are you trying to say?

Yes, that.
Systemd journal can sign each entry cryptographically and can thus prove

Can not does. And you can sign the text logs almost as easily.

Post by Carlos E.R.
that nothing was modified. It is not a feature of particular interest to
me, so I have not looked into how to do this verification. But I know it
is one of the systemd journal features.
<https://unix.stackexchange.com/questions/347499/how-does-journalctl-sign-the-logs-if-the-the-verification-key-should-be-stored>
+++....................
Forward secure sealing[1]
* FSS [Forward Secure Sealing] provides a way to at least detect
tampering using only a single system, though it won't provide all of the
assurances that external logging can.
* the binary logs handled by the systemd journal can be "sealed"
at regular time intervals. That seal is a cryptographic operation on the
log data such that any tampering prior to the seal can be detected.
* The algorithm for FSS is based on "Forward Secure Pseudo Random
Generators" (FSPRG),
* One key is the "sealing key" which is kept on the system, and
the other is the "verification key" which should be securely stored
elsewhere. Using the FSPRG mechanism, a new sealing key is generated
periodically using a non-reversible process. The old key is then
securely deleted from the system after the change.
* The verification key can be used to calculate the sealing key
for any given time range. That means that the attacker can only access
the current sealing key (which will presumably be used for the next
sealing operation), while the administrator can reliably generate any
sealing key to verify previous log file seals. Changing log file entries
prior to the last seal will result in a verification failure.
....................++-
[1] <https://lwn.net/Articles/512895/>

[Carlos E.R.]

Post by William Unruh

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by William Unruh

Post by Carlos E.R.

Post by Mike Easter

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

systemd journald supporters allege that the binary logs are 'handled'
(analyzed, evaluated) much better/ more efficiently/ than if they
weren't so constructed.

Probably.

Post by Mike Easter
I'm only stating some opinions of others, as I'm not personally
conversant with how well the binary logs actually work compared to the
older text logs.

Well, it allows when you ask about the status of a service to get logs
pertaining to it. At least in theory. It is also easier to prove that
the logs have not been manipulated.

HOW? Just because it is binary does not really prevent someone from
learning the format of the journals, and alter them.

Did you read about cryptographic keys and signatures?

What has that to do with anything? youcan sign text logs just as easily
as binary logs. Or do you mean that say Mageia signs the logs, with a
cryptographic key on your machine, where you can get it and use it as
well after you have changed the logs? Ie, what are you trying to say?

Yes, that.
Systemd journal can sign each entry cryptographically and can thus prove

Can not does. And you can sign the text logs almost as easily.

Not really. There is no chain of custody.

[David W. Hodgins]

Post by William Unruh
What has that to do with anything? youcan sign text logs just as easily
as binary logs. Or do you mean that say Mageia signs the logs, with a
cryptographic key on your machine, where you can get it and use it as
well after you have changed the logs? Ie, what are you trying to say?

See "man journalctl", then search for setup-keys.

Regards, Dave Hodgins

[Carlos E.R.]

Post by William Unruh

Post by Soviet_Mario

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
From a only formal view, to define a single uniform
interface (a standardization of the interface layer) is a
good thing in itself.
Posix is an attempt in that direction, and separates the
interface layer (declarative) and its implementation
what could be (and seem to be bad) is another : to implement
the layer interface as a single monolithic behemoth instead
of independent modules.
There is no true necessity this should happen

And is also not what systemd does. It sets up a huge buch of modules
(the .service files/programs) which acrually carry out the
initialisation, with rules as to dependencies so they can be run in
parallel. Many are C programs, which one could object to, but then all
of the kernel moduels are programs, not scripts.
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

But you can easily use text log files as before. I do.

[William Unruh]

...

Post by Carlos E.R.

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

But you can easily use text log files as before. I do.

Sure you can, at the expense of the journal still taking up a huger amount
of disk space. You can also (if you figure out how) limit the size of
the journal. But again that is extra work, esp in learning how to do it.
Why should you have to?

You can also replace almost all of the startup programs by sysvinit
script within systemd.

[Carlos E.R.]

Post by William Unruh
...

Post by Carlos E.R.

Post by William Unruh
Journald using a database rather than a text file I still think is a
stupid idea. (You need logs when almost nothing is working).

But you can easily use text log files as before. I do.

Sure you can, at the expense of the journal still taking up a huger amount
of disk space.

Nope. Zero bytes if you want. Easy peasy.

It is easier in fact that learning about logrotate for syslog, where
each log has to be handled differently.

Post by William Unruh
You can also (if you figure out how) limit the size of
the journal. But again that is extra work, esp in learning how to do it.
Why should you have to?

Don't you love learning?

It is the current default in the distro I use, anyway.

Post by William Unruh
You can also replace almost all of the startup programs by sysvinit
script within systemd.

No reason to waste that time. Didn't you say something about effort above?

[Carlos E.R.]

Post by Soviet_Mario

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace.  This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
From a only formal view, to define a single uniform interface (a
standardization of the interface layer) is a good thing in itself.
Posix is an attempt in that direction, and separates the interface layer
(declarative) and its implementation
what could be (and seem to be bad) is another : to implement the layer
interface as a single monolithic behemoth instead of independent modules.
There is no true necessity this should happen

But it is not a behemoth:

-rwxr-xr-x 1 root root 1161608 Feb 18 2019 /usr/lib/systemd/systemd*

one megabyte...

Post by Soviet_Mario
top - 19:46:21 up 1 day, 7:21, 2 users, load average: 0.52, 0.54, 0.47
Tasks: 460 total, 1 running, 458 sleeping, 0 stopped, 1 zombie
%Cpu(s): 5.6 us, 1.5 sy, 0.1 ni, 91.7 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8161224 total, 1394832 free, 5257324 used, 1509068 buff/cache
KiB Swap: 25165820 total, 23194540 free, 1971280 used. 2352116 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11994 root 20 0 40216 3780 2916 R 17.65 0.046 0:00.04 top
1 root 20 0 233124 8508 5072 S 0.000 0.104 0:24.52 systemd

5 megabits in shared ram, 5 in shared ram.


And it is modular, in fact.

Post by Soviet_Mario
This said, I do not have the particular skill even to assess if this
standard interface has been chosen as the best possible. Ample
discussion should precede a similar approach (the longlasting birth of
POSIX itself and its partial yet coverage and support is symptomatic of
the difficulty of having everybody to agree to an external formal
standard ... but it is the only good way to describe interactions
between things loosely bound)

VERY ample discussion was made. I saw it, in the distribution I use
places. Similarly on many other places.
What was possibly was what was available, though. Anybody or group was
free to create other candidates.

[Soviet_Mario]

Post by Carlos E.R.

Post by Soviet_Mario

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace.  This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
From a only formal view, to define a single uniform interface (a
standardization of the interface layer) is a good thing in itself.
Posix is an attempt in that direction, and separates the interface layer
(declarative) and its implementation
what could be (and seem to be bad) is another : to implement the layer
interface as a single monolithic behemoth instead of independent modules.
There is no true necessity this should happen

-rwxr-xr-x 1 root root 1161608 Feb 18 2019 /usr/lib/systemd/systemd*
one megabyte...

I was not speaking about its disk or ram footprint ...
I've read SystemD has surpassed some a million lines of
code, just this

Post by Carlos E.R.

Post by Soviet_Mario
top - 19:46:21 up 1 day, 7:21, 2 users, load average: 0.52, 0.54, 0.47
Tasks: 460 total, 1 running, 458 sleeping, 0 stopped, 1 zombie
%Cpu(s): 5.6 us, 1.5 sy, 0.1 ni, 91.7 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8161224 total, 1394832 free, 5257324 used, 1509068 buff/cache
KiB Swap: 25165820 total, 23194540 free, 1971280 used. 2352116 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11994 root 20 0 40216 3780 2916 R 17.65 0.046 0:00.04 top
1 root 20 0 233124 8508 5072 S 0.000 0.104 0:24.52 systemd

5 megabits in shared ram, 5 in shared ram.
And it is modular, in fact.

Post by Soviet_Mario
This said, I do not have the particular skill even to assess if this
standard interface has been chosen as the best possible. Ample
discussion should precede a similar approach (the longlasting birth of
POSIX itself and its partial yet coverage and support is symptomatic of
the difficulty of having everybody to agree to an external formal
standard ... but it is the only good way to describe interactions
between things loosely bound)

VERY ample discussion was made. I saw it, in the distribution I use
places. Similarly on many other places.
What was possibly was what was available, though. Anybody or group was
free to create other candidates.

[Carlos E.R.]

Post by Soviet_Mario

Post by Soviet_Mario

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace.  This means
that ALL software that is written for Linux will have to be written
for systemd.

the abstract question and practical aspect here diverge a lot.
 From a only formal view, to define a single uniform interface (a
standardization of the interface layer) is a good thing in itself.
Posix is an attempt in that direction, and separates the interface layer
(declarative) and its implementation
what could be (and seem to be bad) is another : to implement the layer
interface as a single monolithic behemoth instead of independent modules.
There is no true necessity this should happen

-rwxr-xr-x 1 root root 1161608 Feb 18  2019 /usr/lib/systemd/systemd*
one megabyte...

I was not speaking about its disk or ram footprint ...
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.


***@Telcontar:~> rpm -ql systemd | wc -l
686
***@Telcontar:~>

That's not a single huge program. Not a "single monolithic behemoth".

[F Russell]

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.

Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.

Welcome to the new Linux.

[Carlos E.R.]

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.

*you* are not using a distribution unmodified init system. Your
comparison is invalid.

[Aragorn]

Post by Carlos E.R.

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of
the programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.

*you* are not using a distribution unmodified init system. Your
comparison is invalid.

And his line count does not include that of the services his init
system starts. If it even starts something as small as ntpd, then his
3415 bytes aren't going to cover it anymore.

systemd is more than an init system. It's a system daemon. It starts
and monitors userspace services, and it automatically restarts them if
they crash, which is essentially what GNU HURD also does on top of the
Mach microkernel, except that HURD controls lower-level userspace
daemons for things which in the Linux kernel run in kernelspace itself,
such as the driver modules, filesystems, security/authentication, et al.

[Kenny McCormack]

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.

Care to post it? I assume from your comment about comments that it is 3415
bytes of source code, not binary.

Seriously, I'm quite interested. I'd like to setup a system running such a
minimalist style. I'm not bullshitting here. I'm not asking you to post
it the way most Usenet requests would be doing so.

[F. Russell]

Post by Kenny McCormack
Care to post it? I assume from your comment about comments that it is 3415
bytes of source code, not binary.

I'll post it either later this evening or sometime tomorrow.
I'm stuck with the MS junk at my job right now.

Keep in mind that my solution applies to a stand-alone,
desktop, workstation with only a single user (me) and no
network other than an Internet connection through a
router/modem.

But it's also not just the init script.

Since I assemble my own hardware, I use static device
nodes (with no udev and no ram disk) and these must be prepared
beforehand.

My setup also depends on a custom configured kernel to eliminate
most dependencies that are found in most distros.

The system boots into console mode with a bash shell. Nothing
else is running. For example, if you want sound then you can
invoke that when needed. The same for the network. The same
for X. All that requires short, extra scripts, which involve
only the loading of modules.

If you understand how Linux works, then, IMO, it is the best
way to go. Every aspect of the system is under your control.
Nothing is automatic.

I have been running Linux this way for over 10 years and
have had nearly zero maintenance issues and nearly zero
problems. All my software, including the kernel, is the
very latest.

[Kenny McCormack]

Post by F. Russell

Post by Kenny McCormack
Care to post it? I assume from your comment about comments that it is 3415
bytes of source code, not binary.

I'll post it either later this evening or sometime tomorrow.
I'm stuck with the MS junk at my job right now.
Keep in mind that my solution applies to a stand-alone,
desktop, workstation with only a single user (me) and no
network other than an Internet connection through a
router/modem.
But it's also not just the init script.
Since I assemble my own hardware, I use static device
nodes (with no udev and no ram disk) and these must be prepared
beforehand.
My setup also depends on a custom configured kernel to eliminate
most dependencies that are found in most distros.
The system boots into console mode with a bash shell. Nothing
else is running. For example, if you want sound then you can
invoke that when needed. The same for the network. The same
for X. All that requires short, extra scripts, which involve
only the loading of modules.
If you understand how Linux works, then, IMO, it is the best
way to go. Every aspect of the system is under your control.
Nothing is automatic.
I have been running Linux this way for over 10 years and
have had nearly zero maintenance issues and nearly zero
problems. All my software, including the kernel, is the
very latest.

Sounds cool.

I think for a first pass, I'd be just interested in taking a look at it, to
get some idea of what you're about.

If it reaches the point where I actually want to try running it, I'd
probably ask you for more details (and more code).

Maybe you should wrap it all up into a distro - call it FRLinux.

[F. Russell]

Post by Kenny McCormack
If it reaches the point where I actually want to try running it, I'd
probably ask you for more details (and more code).

There's no so much code involved as there is configuration.
One just has to know how most things fit together.

But Linux really is very, very simple.

I started Linux with a distro, but as I began to explore
the innards of the distro I always kept asking myself
why do they do it this way. It's not necessary.

So I did it myself. It worked and it kept on working.

[Kenny McCormack]

Post by F. Russell

Post by Kenny McCormack
If it reaches the point where I actually want to try running it, I'd
probably ask you for more details (and more code).

There's no so much code involved as there is configuration.
One just has to know how most things fit together.
But Linux really is very, very simple.

I hear ya!

For a long time, I booted (and used) quite usable Linux systems from floppy.
I was a big fan of Tom's RTBT system. I wonder if that still exists in any
form nowadays...

Of course, kids these days have it so easy, what with their bootable CDs,
DVDs, and USB sticks...

[Cybe R. Wizard]

On Mon, 14 Oct 2019 15:28:45 -0000 (UTC)

Post by Kenny McCormack

Post by F. Russell

Post by Kenny McCormack
If it reaches the point where I actually want to try running it,
I'd probably ask you for more details (and more code).

There's no so much code involved as there is configuration.
One just has to know how most things fit together.
But Linux really is very, very simple.

I hear ya!
For a long time, I booted (and used) quite usable Linux systems from
floppy. I was a big fan of Tom's RTBT system. I wonder if that still
exists in any form nowadays...

There is Peter Garrett's "INX ...is not X"
...but its a hundred ninety one MB of data so no floppy and it is
several years old and no longer being developed, I think. That doesn't
hurt its usefulness, though. I read that it _can_ be installed to a
hard drive (wants it all) or inside a virtual machine.

;-]

Post by Kenny McCormack
Of course, kids these days have it so easy, what with their bootable
CDs, DVDs, and USB sticks...

Yep, the only bootable thing in my youth was my arse when I got caught.

[William Unruh]

Post by Kenny McCormack

Post by F. Russell

Post by Kenny McCormack
Care to post it? I assume from your comment about comments that it is 3415
bytes of source code, not binary.

I'll post it either later this evening or sometime tomorrow.
I'm stuck with the MS junk at my job right now.
Keep in mind that my solution applies to a stand-alone,
desktop, workstation with only a single user (me) and no
network other than an Internet connection through a
router/modem.
But it's also not just the init script.
Since I assemble my own hardware, I use static device
nodes (with no udev and no ram disk) and these must be prepared
beforehand.
My setup also depends on a custom configured kernel to eliminate
most dependencies that are found in most distros.
The system boots into console mode with a bash shell. Nothing
else is running. For example, if you want sound then you can
invoke that when needed. The same for the network. The same
for X. All that requires short, extra scripts, which involve
only the loading of modules.
If you understand how Linux works, then, IMO, it is the best
way to go. Every aspect of the system is under your control.
Nothing is automatic.
I have been running Linux this way for over 10 years and
have had nearly zero maintenance issues and nearly zero
problems. All my software, including the kernel, is the
very latest.

Sounds cool.
I think for a first pass, I'd be just interested in taking a look at it, to
get some idea of what you're about.
If it reaches the point where I actually want to try running it, I'd
probably ask you for more details (and more code).
Maybe you should wrap it all up into a distro - call it FRLinux.

There was once an operating sysem called DOS. It all fit onto a little
floppy disk. Dropped you into a terminal window. If you needed anything
you ran a program to do it. In fact there was no init system. It was jus
the kernel that did it all (well, and the tiny BIOS). Maybe that is what
he is talking about?

[Soviet_Mario]

Post by William Unruh

Post by Kenny McCormack

Post by F. Russell

Post by Kenny McCormack
Care to post it? I assume from your comment about comments that it is 3415
bytes of source code, not binary.

I'll post it either later this evening or sometime tomorrow.
I'm stuck with the MS junk at my job right now.
Keep in mind that my solution applies to a stand-alone,
desktop, workstation with only a single user (me) and no
network other than an Internet connection through a
router/modem.
But it's also not just the init script.
Since I assemble my own hardware, I use static device
nodes (with no udev and no ram disk) and these must be prepared
beforehand.
My setup also depends on a custom configured kernel to eliminate
most dependencies that are found in most distros.
The system boots into console mode with a bash shell. Nothing
else is running. For example, if you want sound then you can
invoke that when needed. The same for the network. The same
for X. All that requires short, extra scripts, which involve
only the loading of modules.
If you understand how Linux works, then, IMO, it is the best
way to go. Every aspect of the system is under your control.
Nothing is automatic.
I have been running Linux this way for over 10 years and
have had nearly zero maintenance issues and nearly zero
problems. All my software, including the kernel, is the
very latest.

Sounds cool.
I think for a first pass, I'd be just interested in taking a look at it, to
get some idea of what you're about.
If it reaches the point where I actually want to try running it, I'd
probably ask you for more details (and more code).
Maybe you should wrap it all up into a distro - call it FRLinux.

There was once an operating sysem called DOS. It all fit onto a little
floppy disk. Dropped you into a terminal window. If you needed anything
you ran a program to do it. In fact there was no init system.

I'm not so sure how to classify CONFIG.SYS and AUTOEXEC.BAT
In order to get most peripherals drivers work you had to
manually load these with config (prequel) or autoexec
(sequel), so imho they were sort of halfway between
configuration files and init system, as they affected the
way the DOS would start

Post by William Unruh
It was jus
the kernel that did it all

in DOS????? dos kernel did very very little basic work, not
even able to see the whole memory without some further
drivers such as "highmem or himem.SYS" (i cant recall the
exact spell).
It just managed to support FAT and low / middle level disk
operations. Also the CD was not supported natively by many
DOS, and had to be "inited" by another external driver
loaded in config.sys

windows itself relied on these and other hybrid
parameters/instruction configuration files, before passing
on to the "registry"

Post by William Unruh
(well, and the tiny BIOS). Maybe that is what
he is talking about?

[Aragorn]

Post by Soviet_Mario

Post by William Unruh
There was once an operating sysem called DOS. It all fit onto a
little floppy disk. Dropped you into a terminal window. If you
needed anything you ran a program to do it. In fact there was no
init system.

I'm not so sure how to classify CONFIG.SYS and AUTOEXEC.BAT
In order to get most peripherals drivers work you had to
manually load these with config (prequel) or autoexec
(sequel), so imho they were sort of halfway between
configuration files and init system, as they affected the
way the DOS would start

It's a good analogy, yes. CONFIG.SYS would load device drivers and a
few TSRs, and AUTOEXEC.BAT would set up the runtime environment, which
could also include the loading of TSRs.

Post by Soviet_Mario

Post by William Unruh
It was just the kernel that did it all

in DOS????? dos kernel did very very little basic work, not
even able to see the whole memory without some further
drivers such as "highmem or himem.SYS" (i cant recall the
exact spell).

HIMEM.SYS (later HIMEM.EXE) for XMS support, and EMM386.SYS (later
EMM386.EXE) for either EMS or UMB support — it could not do both at the
same time.

In addition to that, all Windows versions up until and including
Windows ME — but excluding the NT-based Windows versions — still ran all
code and data in the processor's ring 0, using DPMS (DOS Protected Mode
Specification).

Post by Soviet_Mario
It just managed to support FAT and low / middle level disk
operations. Also the CD was not supported natively by many
DOS, and had to be "inited" by another external driver
loaded in config.sys

I think what Bill means is that in DOS, *everything* ran in kernel
mode — even user applications — because the 8086/8088 processor (and
any later x86 processor when running in real mode) doesn't have
privilege separation, nor does it have access to the processor's memory
management unit.

So there were plenty of occasions where DOS didn't have a device driver
for a specific device to be used in a certain application, but whereby
the application itself came with its own device driver.

For instance, WordPerfect 5.x came with its own mouse driver, its own
printer drivers and its own graphics driver. So did Lotus 123, dBASE
III/IV, TurboPascal, Freehand, and several other applications.

DOS was therefore not a real operating system. It was essentially an
executable loader on top of the BIOS firmware, and it had some
rudimentary file management and memory management utilities.

As soon as an application was loaded into memory, DOS would take a step
back, and the application had full control over the machine until it
exited again. Then DOS had to reload its command interpreter
COMMAND.COM, either from the hard-coded default — i.e. the root
directory of the boot drive — or the path to COMMAND.COM as set via the
%COMSPEC variable, which was commonly set in AUTOEXEC.BAT.

[Eric Pozharski]

with <***@nx-74205> Aragorn wrote:

*SKIP*

Post by Aragorn
As soon as an application was loaded into memory, DOS would take a
step back, and the application had full control over the machine until
it exited again. Then DOS had to reload its command interpreter
COMMAND.COM, either from the hard-coded default — i.e. the root
directory of the boot drive — or the path to COMMAND.COM as set via
the %COMSPEC variable, which was commonly set in AUTOEXEC.BAT.

No. command.com was/is(?) executing autoexec.bat line-by-line. If last
line of autoexec.bat was some kind of shell (in my corner of the world
nc was hugely popular; but I was special snowflake -- I did everything
with 4dos; good thing I wasn't exposed to crowd, it would be
mind-blowing) then command.com would stay behind until that shell would
finish. And then command.com would go in prompt mode, eg

C:\> _

However, indeed, anything spawned from whatever was found in
autoexec.bat by command.com would overtake control and that (found)
would stay behind doing nothing only eating memory.

I have no experience with FreeDOS though. I've been told it does some
incredible things -- like true multitasking, background and such. But I
don't have first-hand experience.

[Aragorn]

Post by Eric Pozharski
*SKIP*

Post by Aragorn
As soon as an application was loaded into memory, DOS would take a
step back, and the application had full control over the machine
until it exited again. Then DOS had to reload its command
interpreter COMMAND.COM, either from the hard-coded default — i.e.
the root directory of the boot drive — or the path to COMMAND.COM
as set via the %COMSPEC variable, which was commonly set in
AUTOEXEC.BAT.

No. command.com was/is(?) executing autoexec.bat line-by-line.

Yes, I know that.

Post by Eric Pozharski
If last line of autoexec.bat was some kind of shell (in my corner of the
world nc was hugely popular; but I was special snowflake -- I did
everything with 4dos; good thing I wasn't exposed to crowd, it would
be mind-blowing) then command.com would stay behind until that shell
would finish. And then command.com would go in prompt mode, eg
C:\> _
However, indeed, anything spawned from whatever was found in
autoexec.bat by command.com would overtake control and that (found)
would stay behind doing nothing only eating memory.

Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...

SET COMSPEC=C:\DOS\COMMAND.COM

And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.

Then, after WordPerfect or dBASE were shut down, DOS would reload
COMMAND.COM into memory from where the COMSPEC variable says it should
be loaded from.

Post by Eric Pozharski
I have no experience with FreeDOS though. I've been told it does some
incredible things -- like true multitasking, background and such.
But I don't have first-hand experience.

I didn't know FreeDOS could do multitasking, but I'm not surprised. I
haven't had a chance to experiment with it yet, although I do have an
old Pentium MMX box that I was given for free sitting in a corner
somewhere, and that I've reserved that box for testing FreeDOS.

[Carlos E.R.]

Post by Aragorn

Post by Eric Pozharski
*SKIP*

Post by Aragorn
As soon as an application was loaded into memory, DOS would take a
step back, and the application had full control over the machine
until it exited again. Then DOS had to reload its command
interpreter COMMAND.COM, either from the hard-coded default — i.e.
the root directory of the boot drive — or the path to COMMAND.COM
as set via the %COMSPEC variable, which was commonly set in
AUTOEXEC.BAT.

No. command.com was/is(?) executing autoexec.bat line-by-line.

Yes, I know that.

Post by Eric Pozharski
If last line of autoexec.bat was some kind of shell (in my corner of the
world nc was hugely popular; but I was special snowflake -- I did
everything with 4dos; good thing I wasn't exposed to crowd, it would
be mind-blowing) then command.com would stay behind until that shell
would finish. And then command.com would go in prompt mode, eg
C:\> _
However, indeed, anything spawned from whatever was found in
autoexec.bat by command.com would overtake control and that (found)
would stay behind doing nothing only eating memory.

Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...
SET COMSPEC=C:\DOS\COMMAND.COM
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.

Not completely. A small stub remained.

Yes, MsDOS was an operating system, but limited by today's standards. It
was not only the 3 system files (io.sys, command.com and another one I
forget), but all the utilities in the \dos directory.

[Aragorn]

Post by Carlos E.R.

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...
SET COMSPEC=C:\DOS\COMMAND.COM
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite
as much of the used RAM as possible, including COMMAND.COM.

Not completely. A small stub remained.
Yes, MsDOS was an operating system, but limited by today's standards.
It was not only the 3 system files (io.sys, command.com and another
one I forget), [...

For Microsoft MS-DOS, the three system files were...

- IO.SYS
- MSDOS.SYS
- COMMAND.COM

For IBM PC-DOS, the three system files were...

- IBMBIO.COM
- IBMDOS.COM
- COMMAND.COM

COMMAND.COM was only the command interpreter. The core system was
MSDOS.SYS/IBMDOS.COM, with IO.SYS/IMBIO.COM being essentially the boot
loader, as an extension of the legacy BIOS firmware.

Post by Carlos E.R.
...] but all the utilities in the \dos directory.

Yes, it did have utilities, but not all that many, and DOS did not
distinguish between "kernel" and "userland", because the processor did
not support privilege separation.

Every application running on DOS had full control of the machine,
including full write access to all writeable memory addresses and to
the memory addresses between the 640 KiB boundary and the 1024 KiB
boundary that were reserved for hardware access.

So in essence, once you loaded an application into memory, the
application in question would effectively become the operating system,
and DOS would move out of the way.

[Carlos E.R.]

Post by Aragorn

Post by Carlos E.R.

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...
SET COMSPEC=C:\DOS\COMMAND.COM
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite
as much of the used RAM as possible, including COMMAND.COM.

Not completely. A small stub remained.
Yes, MsDOS was an operating system, but limited by today's standards.
It was not only the 3 system files (io.sys, command.com and another
one I forget), [...

For Microsoft MS-DOS, the three system files were...
- IO.SYS
- MSDOS.SYS
- COMMAND.COM
For IBM PC-DOS, the three system files were...
- IBMBIO.COM
- IBMDOS.COM
- COMMAND.COM
COMMAND.COM was only the command interpreter. The core system was
MSDOS.SYS/IBMDOS.COM, with IO.SYS/IMBIO.COM being essentially the boot
loader, as an extension of the legacy BIOS firmware.

Post by Carlos E.R.
...] but all the utilities in the \dos directory.

Yes, it did have utilities, but not all that many, and DOS did not
distinguish between "kernel" and "userland", because the processor did
not support privilege separation.
Every application running on DOS had full control of the machine,
including full write access to all writeable memory addresses and to
the memory addresses between the 640 KiB boundary and the 1024 KiB
boundary that were reserved for hardware access.

All correct :-)

Post by Aragorn
So in essence, once you loaded an application into memory, the
application in question would effectively become the operating system,
and DOS would move out of the way.

I would not go that far. The BIOS was there, and applications made
extensive use of it. Int 21, for instance. The operating system was
bypassed when one needed more speed or things that were not supported.
The typical one was the screen. Nobody replaced the disk file operation,
for instance, unless you were writing a disk editor, repair tool,
defrager...

[Kenny McCormack]

In article <***@nx-74205>,
Aragorn <***@telenet.be> wrote:
...

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...
SET COMSPEC=C:\DOS\COMMAND.COM
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.
Then, after WordPerfect or dBASE were shut down, DOS would reload
COMMAND.COM into memory from where the COMSPEC variable says it should
be loaded from.

Since this thread seems to have degenerated into us old farts displaying
our archaic knowledge of archaic OSes, let me add this:

In DOS 2.x, the COMSPEC variable existed, but was not recognized as such,
for the purpose of re-loading COMMAND.COM. As far as I can tell, it
existed for the purpose of telling programs what to use when "shelling
out", much like $SHELL does in Unix-land.

That is, if you booted from a floppy (as we all did back in those days), a
common trick was to create a small RAM disk, and stash a copy of
COMMAND.COM there. Then you'd set COMSPEC=F:\COMMAND.COM (assuming the
ramdisk was F:) and expect it do the right thing. Unfortunately, this
didn't work, because the system still expected COMMAND.COM to be on the
floppy. If you had removed/swapped/changed the floppy since booting,
you'd get the dreaded "Can't load COMMAND.COM. System halted" message.

Notes on the above:
1) Somebody wrote a little utility (called, I think, SHELL.COM) that
allowed you to do what "set COMSPEC" should have done; namely,
change the actual data value inside DOS that tells it from whence
to reload COMMAND.COM. This little utility was quite handy, back
in the day.
2) The underlying bug was fixed in DOS 3.x (and beyond), so that
setting COMSPEC did the right thing.

[Carlos E.R.]

Post by Kenny McCormack
...

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...
SET COMSPEC=C:\DOS\COMMAND.COM
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.
Then, after WordPerfect or dBASE were shut down, DOS would reload
COMMAND.COM into memory from where the COMSPEC variable says it should
be loaded from.

Since this thread seems to have degenerated into us old farts displaying
In DOS 2.x, the COMSPEC variable existed, but was not recognized as such,
for the purpose of re-loading COMMAND.COM. As far as I can tell, it
existed for the purpose of telling programs what to use when "shelling
out", much like $SHELL does in Unix-land.
That is, if you booted from a floppy (as we all did back in those days), a
common trick was to create a small RAM disk, and stash a copy of
COMMAND.COM there. Then you'd set COMSPEC=F:\COMMAND.COM (assuming the
ramdisk was F:) and expect it do the right thing. Unfortunately, this
didn't work, because the system still expected COMMAND.COM to be on the
floppy. If you had removed/swapped/changed the floppy since booting,
you'd get the dreaded "Can't load COMMAND.COM. System halted" message.

Huh?

Post by Kenny McCormack
1) Somebody wrote a little utility (called, I think, SHELL.COM) that
allowed you to do what "set COMSPEC" should have done; namely,
change the actual data value inside DOS that tells it from whence
to reload COMMAND.COM. This little utility was quite handy, back
in the day.
2) The underlying bug was fixed in DOS 3.x (and beyond), so that
setting COMSPEC did the right thing.

Ah, So that's why the behaviour you described was foreign to me. The
first DOS I saw was 3. something. 11 or 20. It always worked for me.

[Kenny McCormack]

In article <rf3i7g-***@Telcontar.valinor>,
Carlos E.R. <***@es.invalid> wrote:
...

Post by Carlos E.R.

Post by Kenny McCormack
1) Somebody wrote a little utility (called, I think, SHELL.COM) that
allowed you to do what "set COMSPEC" should have done; namely,
change the actual data value inside DOS that tells it from whence
to reload COMMAND.COM. This little utility was quite handy, back
in the day.
2) The underlying bug was fixed in DOS 3.x (and beyond), so that
setting COMSPEC did the right thing.

Ah, So that's why the behaviour you described was foreign to me. The
first DOS I saw was 3. something. 11 or 20. It always worked for me.

So, you figured it out, right? I was talking about DOS 2.x, where the
problem exists (and SHELL.COM was the antidote).

You know, it is possible for Usenet posters to edit their posts before
hitting the final "OK" (or "Send" or whatever). You might have considered
going back and editing out the "Huh?".

BTW (and going back to the original subject matter), the main reason why it
was good practice to change the COMSPEC when booting from floppy was so
that then you did need to reload, it would reload quickly. Reloading
COMMAND.COM from the floppy was a slow and painful operation...

[Carlos E.R.]

Post by Kenny McCormack
...

Post by Carlos E.R.

Post by Kenny McCormack
1) Somebody wrote a little utility (called, I think, SHELL.COM) that
allowed you to do what "set COMSPEC" should have done; namely,
change the actual data value inside DOS that tells it from whence
to reload COMMAND.COM. This little utility was quite handy, back
in the day.
2) The underlying bug was fixed in DOS 3.x (and beyond), so that
setting COMSPEC did the right thing.

Ah, So that's why the behaviour you described was foreign to me. The
first DOS I saw was 3. something. 11 or 20. It always worked for me.

So, you figured it out, right? I was talking about DOS 2.x, where the
problem exists (and SHELL.COM was the antidote).
You know, it is possible for Usenet posters to edit their posts before
hitting the final "OK" (or "Send" or whatever). You might have considered
going back and editing out the "Huh?".

On the contrary. I went back and added the "Huh". :-P

You might have my post analyzed at the forensic lab, doing an ink ageing
analysis to find out :-P

Post by Kenny McCormack
BTW (and going back to the original subject matter), the main reason why it
was good practice to change the COMSPEC when booting from floppy was so
that then you did need to reload, it would reload quickly. Reloading
COMMAND.COM from the floppy was a slow and painful operation...

Yes, indeed.

[Eric Pozharski]

*SKIP*

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...

Well, more then just setting variables. I'm proud to report, that my
486DX2-80 was reaching prompt in whooping three minutes (with
incremental backups and staff). Fscking real-mode, linux was ready in
20sec.

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

Post by Aragorn
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.
Then, after WordPerfect or dBASE were shut down, DOS would reload
COMMAND.COM into memory from where the COMSPEC variable says it should
be loaded from.

Only heavy thing that I've used was Borland C++ 3.0 (it was popular back
then; it's hard not to be popular when you you're the only player).
But it was doing it with DPMS. However, if something older than DPMS
would be in ring0 it could all crazy things like taking over memory with
plugs in the interrupt table.

Also, still something is hairy. If environment was set up / corrected /
whatnot with autoexec.bat (what is subject to command.com or whatever
else interpreter it could be), how those io.sys / msdos.sys / or
whatever other dos would know about that comspec?

p.s. I've believed staff about dos too. I was wrong. It was proven to
be urban legend.

*CUT*

[Carlos E.R.]

Post by Eric Pozharski
*SKIP*

Post by Aragorn
Yes, but I'm afraid you've misread me. My reference to AUTOEXEC.BAT
was merely that this is commonly where DOS environment variables are
set, and so it was quite common — especially for hard disk
installations — to have something in AUTOEXEC.BAT like...

Well, more then just setting variables. I'm proud to report, that my
486DX2-80 was reaching prompt in whooping three minutes (with
incremental backups and staff). Fscking real-mode, linux was ready in
20sec.

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

Post by Aragorn
And if you were to start a heavyweight application from the likes of
WordPerfect 5.x or dBASE IV, then this application would overwrite as
much of the used RAM as possible, including COMMAND.COM.
Then, after WordPerfect or dBASE were shut down, DOS would reload
COMMAND.COM into memory from where the COMSPEC variable says it should
be loaded from.

Only heavy thing that I've used was Borland C++ 3.0 (it was popular back
then; it's hard not to be popular when you you're the only player).

They were not the only player. Microsoft had their own compiler,
probably 10 times more expensive - guessing, I knew the price comparison
for Pascal.

Borland compilers were fast and good. They came with a good IDE, online
help, a debugger with a TUI..., good paper books... They were the best
those years by far.

Post by Eric Pozharski
But it was doing it with DPMS. However, if something older than DPMS
would be in ring0 it could all crazy things like taking over memory with
plugs in the interrupt table.
Also, still something is hairy. If environment was set up / corrected /
whatnot with autoexec.bat (what is subject to command.com or whatever
else interpreter it could be), how those io.sys / msdos.sys / or
whatever other dos would know about that comspec?

They did not need to. At the point they would need to, when booting,
they would try to find it at the same disk, then the environment var was
written.

Post by Eric Pozharski
p.s. I've believed staff about dos too. I was wrong. It was proven to
be urban legend.

staff?

Post by Eric Pozharski
*CUT*

[Eric Pozharski]

*SKIP*

Post by Carlos E.R.

Post by Eric Pozharski
p.s. I've believed staff about dos too. I was wrong. It was proven
to be urban legend.

staff?

Bloody English. One letter, and so much difference.

[Carlos E.R.]

...

Post by Eric Pozharski

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

This is only necessary/relevant if you are booting from floppy disk.
Once everybody had moved to booting from HD, the issue evaporated.
The issue was that if you were booting from floppy, you would want to
change the value of COMSPEC to point to a copy of COMMAND.COM residing on
faster media (presumably, a RAM disk [*]). If you were booting from HD,
then COMSPEC would already have the correct value, so no setting of it was
needed.
[*] I say "RAM disk" because if it was on HD (as the example shown above
seems to imply), then you would, presumably, have booted from HD, and, as
noted in the previous paragraph, it would then already be set to the
correct value.
So, again, all of this is really only relevant in the very bad old days
when we were booting from floppy disk.

As compared to booting from ROM and having only BASIC? :-D
Or worse, from audio tape.

[Yrrah]

Post by Eric Pozharski

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

This is only necessary/relevant if you are booting from floppy disk.

Or using another command-line interpreter, e.g. 4dos.com.


Yrrah

[Kenny McCormack]

Post by Yrrah

Post by Eric Pozharski

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

This is only necessary/relevant if you are booting from floppy disk.

Or using another command-line interpreter, e.g. 4dos.com.

You're saying that 4DOS has this problem to this day.

That's sad. In most respects, 4DOS is much better than COMMAND.COM.

[Yrrah]

Post by Kenny McCormack

Post by Yrrah

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

This is only necessary/relevant if you are booting from floppy disk.

Or using another command-line interpreter, e.g. 4dos.com.

You're saying that 4DOS has this problem to this day.

Perhaps I was wrong:
"Under MS-DOS and PC-DOS you probably won't need to set the COMSPEC
directory on the SHELL= line or in AUTOEXEC. 4DOS sets it
automatically in most cases, provided that you specify the full path
for 4DOS.COM in the name you use on the SHELL= line in CONFIG.SYS"

Post by Kenny McCormack
In most respects, 4DOS is much better than COMMAND.COM.

In all respects, I would say, except perhaps memory usage.

Quotes from: https://www.4dos.info/4doshist/h4d4.htm

However, that's all irrelevant, for who uses MS-DOS or equivalent
nowadays?

Yrrah

[Carlos E.R.]

Post by Yrrah

Post by Kenny McCormack

Post by Yrrah

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

This is only necessary/relevant if you are booting from floppy disk.

Or using another command-line interpreter, e.g. 4dos.com.

You're saying that 4DOS has this problem to this day.

"Under MS-DOS and PC-DOS you probably won't need to set the COMSPEC
directory on the SHELL= line or in AUTOEXEC. 4DOS sets it
automatically in most cases, provided that you specify the full path
for 4DOS.COM in the name you use on the SHELL= line in CONFIG.SYS"

Post by Kenny McCormack
In most respects, 4DOS is much better than COMMAND.COM.

In all respects, I would say, except perhaps memory usage.
Quotes from: https://www.4dos.info/4doshist/h4d4.htm
However, that's all irrelevant, for who uses MS-DOS or equivalent
nowadays?

Some use FreeDos, maybe to use old proprietary software. I know some
people that maintain systems that connects to external machinery, say an
automatic employee entry control with custom made software, which was
paid at the same time Microsoft changed to Windows, and as the price was
very expensive they insist on using it till amortized.


I chanced to hit a site with old msdos games that I liked, like this one:

<https://www.myabandonware.com/game/688-attack-sub-ks>

It says it works under dosbox. I wonder if I can run it inside Linux
with Wine or DosEmu, or alternatively with full blown VirtualBox.

[Bud Frede]

Post by Carlos E.R.
<https://www.myabandonware.com/game/688-attack-sub-ks>
It says it works under dosbox. I wonder if I can run it inside Linux
with Wine or DosEmu, or alternatively with full blown VirtualBox.

A few years ago I tried running some of the old Commander Keen games in
dosbox and rather enjoyed the feelings of nostalgia. :-) IIRC, I tried
one of the original Duke Nukem (non-3D) games too.

I saw a video about this the other day and it's
intriguing. https://github.com/MiSTer-devel/Main_MiSTer/wiki

It's rather expensive compared to an RPi with emulation software, but
might provide a more authentic experience.

[Bud Frede]

Post by Yrrah

Post by Eric Pozharski

Post by Aragorn
SET COMSPEC=C:\DOS\COMMAND.COM

Never had to resort to this.

This is only necessary/relevant if you are booting from floppy disk.

Or using another command-line interpreter, e.g. 4dos.com.

I used DR-DOS with 4DOS. I later used 4OS2. Then I started using Unix
and bash, and kind of lost interest in 4OS2. (Not too long after that I
lost interest in OS/2 itself.)

[Soviet_Mario]

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

You are surely right, but to somewhat "attenuate" the
comparison, BASH seems a language mid-to-high level, even
very high in some features, with very concise constructs
doing much work under the hood

SystemD is written in C (maybe with some asm inside), which,
used in old-style, entails nearly 1:1 C code to asm ratio
(well, not exactly 1:1 literally, but is mid-to-low level
language so not at all concise).

So comparable task are done with a well different amount of code

[Bud Frede]

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of the
programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

I saw somewhere that you can use an FPGA to emulate the Altair 8800 and
toggle in your programs with switches and see the results in blinking
lights on a panel.

That way you wouldn't have to descend into the enormous bloat that is
modern hardware and software. (You can stick with the technical
madness if you'd like.)

Or you could just shuck all of that icky modern civilization and go live
in a cave.

(In other words, I see your reductio ad absurdum, and raise you.)

[Aragorn]

Post by Bud Frede

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of
the programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

I saw somewhere that you can use an FPGA to emulate the Altair 8800
and toggle in your programs with switches and see the results in
blinking lights on a panel.
That way you wouldn't have to descend into the enormous bloat that is
modern hardware and software. (You can stick with the technical
madness if you'd like.)
Or you could just shuck all of that icky modern civilization and go
live in a cave.
(In other words, I see your reductio ad absurdum, and raise you.)

I'll see yours and I raise you an abacus. :p

[Bud Frede]

Post by Aragorn

Post by Bud Frede

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all of
the programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

I saw somewhere that you can use an FPGA to emulate the Altair 8800
and toggle in your programs with switches and see the results in
blinking lights on a panel.
That way you wouldn't have to descend into the enormous bloat that is
modern hardware and software. (You can stick with the technical
madness if you'd like.)
Or you could just shuck all of that icky modern civilization and go
live in a cave.
(In other words, I see your reductio ad absurdum, and raise you.)

I'll see yours and I raise you an abacus. :p

Fingers and toes. ;)

[Aragorn]

Post by Bud Frede

Post by Aragorn

Post by Bud Frede

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all
of the programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

I saw somewhere that you can use an FPGA to emulate the Altair 8800
and toggle in your programs with switches and see the results in
blinking lights on a panel.
That way you wouldn't have to descend into the enormous bloat that
is modern hardware and software. (You can stick with the technical
madness if you'd like.)
Or you could just shuck all of that icky modern civilization and go
live in a cave.
(In other words, I see your reductio ad absurdum, and raise you.)

I'll see yours and I raise you an abacus. :p

Fingers and toes. ;)

Damn! You win! :p

[Ken Hart]

Post by Aragorn

Post by Bud Frede

Post by Aragorn

Post by Bud Frede

Post by F Russell

Post by Carlos E.R.

Post by Soviet_Mario
I've read SystemD has surpassed some a million lines of code, just this

Yes, but not in one program. In hundreds of them. Adding up all
of the programs and modules makes up that million lines.

My "init" program is 3415 bytes -- that's bytes and not kilo-
or mega-bytes -- and about half of those bytes are comments.
Thus, there is no possible way to justify the enormous bloat
that is systemd without descending into technical madness
and mass delusion.
Welcome to the new Linux.

I saw somewhere that you can use an FPGA to emulate the Altair 8800
and toggle in your programs with switches and see the results in
blinking lights on a panel.
That way you wouldn't have to descend into the enormous bloat that
is modern hardware and software. (You can stick with the technical
madness if you'd like.)
Or you could just shuck all of that icky modern civilization and go
live in a cave.
(In other words, I see your reductio ad absurdum, and raise you.)

I'll see yours and I raise you an abacus. :p

Fingers and toes. ;)

Damn! You win! :p

Numbers and letters are the tools of the swamp demons. All
communications should be in grunts.

[Bud Frede]

Post by F Russell

Another large part can be condensed into a set of
support tools written in C which can be reused in other init scripts (or
simliar situations).
That's not much different from what systemd and other members of the zoo
offer, it's just more flexible

For some odd reason, the author of the article assumes that systemd
is just an init system.
RedHat's goals for systemd, as they have clearly stated, are to make
it the sole interface between the kernel and userspace. This means
that ALL software that is written for Linux will have to be written
for systemd.
RedHat, rather than forking Linux for its own purposes, is instead
totally absconding a free and open source project while transmogrifying
it in the process.

It's all a Communist Plot! There are Reds everywhere. Check under your
bed. And you wondered why a "Red" hat?