Centris 650 Debian 10 SID Installation

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Atari Falcon platform drivers

Michael Schmitz-4
Hi Geert,

On 20/06/19 9:05 PM, Michael Schmitz wrote:
>
>> pata_falcon.c alrwady creates its own platform device inside the driver,
>> so that's indeed the easiest to convert.
>
> Yep - I'll test Falcon IDE platform device creation and pata_falcon
> builtin ASAP but won't be able to test pata_falcon as a module. Maybe
> someone else can eventually do that.


RFC sent to linux-m68k and linux-ide now.

Cheers,

     Michael


Reply | Threaded
Open this post in threaded view
|

Re: Atari Falcon platform drivers

John Paul Adrian Glaubitz
On 6/20/19 11:11 PM, Michael Schmitz wrote:
> RFC sent to linux-m68k and linux-ide now.

That was fast. Thanks a lot!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Atari Falcon platform drivers

Michael Schmitz-4
Hi Adrian,

On 21/06/19 9:30 AM, John Paul Adrian Glaubitz wrote:
> On 6/20/19 11:11 PM, Michael Schmitz wrote:
>> RFC sent to linux-m68k and linux-ide now.
> That was fast. Thanks a lot!

No guarantees that it will work - I've tested this with the falconide
driver built-in, and probing before libata. All I've seen is that
pata_falcon returns -ENODEV on probe (as you'd expect, as the IO memory
resource was already claimed by falconide).

Have fun testing.

Cheers,

     Michael

>
> Adrian
>

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Finn Thain
In reply to this post by John Paul Adrian Glaubitz
On Thu, 20 Jun 2019, John Paul Adrian Glaubitz wrote:

> On 6/20/19 2:28 AM, Finn Thain wrote:
> >>> As with the Mac installation, the console-setup package changed the
> >>> framebuffer console font and mangled the window borders. You can see
> >>> the terminus font problem in this screenshot:
> >>> https://lists.debian.org/debian-68k/2019/06/msg00019.html
> >>
> >> Again, use a serial console. That's much easier.
> >>
> >
> > Again, this was Aranym.
>
> Well, this thread is growing too fast. You need to give me a chance to
> answer.
>

It's OK, I'm not paying for support.

Seriously though, I don't expect you or anyone else to treat the mailing
list as a kind of bug tracking system.

I started this thread so that any and all interested parties could share
anecdotes, solutions and workarounds.

--

> Adrian
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
On 6/21/19 1:18 AM, Finn Thain wrote:
> It's OK, I'm not paying for support.
>
> Seriously though, I don't expect you or anyone else to treat the mailing
> list as a kind of bug tracking system.

I'm just concerned that people make wrong assumptions because they don't
understand the background behind certain decisions and issues, e.g. the
problem with the separate /usr.

> I started this thread so that any and all interested parties could share
> anecdotes, solutions and workarounds.

Oh, sure. But we should try to keep some order so we can collect valid
bug reports and problem reports. I am interested in feedback.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Finn Thain
On Fri, 21 Jun 2019, John Paul Adrian Glaubitz wrote:

>
> I'm just concerned that people make wrong assumptions because they don't
> understand the background behind certain decisions and issues, e.g. the
> problem with the separate /usr.
>

Don't be. Readers can make assumptions at their own risk, as always.

Besides, those who have "left the reservation" and think the wrong things
surely haven't read the Official Documentation. They are doomed anyway.

;-)

--

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

userm57
On 6/20/19 5:31 PM, Finn Thain wrote:

> On Fri, 21 Jun 2019, John Paul Adrian Glaubitz wrote:
>
>>
>> I'm just concerned that people make wrong assumptions because they don't
>> understand the background behind certain decisions and issues, e.g. the
>> problem with the separate /usr.
>>
>
> Don't be. Readers can make assumptions at their own risk, as always.
>
> Besides, those who have "left the reservation" and think the wrong things
> surely haven't read the Official Documentation. They are doomed anyway.
>
> ;-)
>

Just my two cents.

It's neither right nor wrong for people to make assumptions based on
their prior experience.  The link that Adrian sent on a different thread
regarding a separate /usr was instructive:

https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

I now understand that the latest trend is that a separate /usr is not
recommended.  And it's clear that most major Linux distributions have
become dependent on systemd.  That's neither good nor bad; the GPL will
allow people to do whatever they want.  I have to say that I was a
little troubled by the supremely smug attitude in the above link.

But it's all good.  There's an active community (and Linux
distributions) that are still working to maintain sysvinit.

I was recently told by a Toyota salesman, while shopping for a new car,
that Toyota doesn't make many cars with a manual transmission anymore,
and I "may just have to buy one with an automatic transmission".  I
responded that Toyota not making manual transmission cars doesn't mean I
won't buy a car, it just means I won't buy a Toyota.

I won't rehash the systemd / sysvinit arguments here; it's clear the
direction that most distributions are taking.  People who want the
older, simpler way, especially for older systems, or who like to
maintain some compatibility with the BSD universe, will be able to find
a way.

-Stan

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
On 6/21/19 1:55 AM, [hidden email] wrote:
> It's neither right nor wrong for people to make assumptions based on
> their prior experience.  The link that Adrian sent on a different thread
> regarding a separate /usr was instructive:
>
> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

It's surely not wrong to make your own assumptions. But at least you should
give me a chance to explain the situation a bit. There are certain design
decisions that we cannot influence and there are certain issues that are
bugs that can be bugs.

If you give me some time to look at the issue you are experiencing, I can
tell you whether this is "as expected" or you actually stumbled into a bug.

> I now understand that the latest trend is that a separate /usr is not
> recommended.  And it's clear that most major Linux distributions have
> become dependent on systemd.  That's neither good nor bad; the GPL will
> allow people to do whatever they want.  I have to say that I was a
> little troubled by the supremely smug attitude in the above link.

Well, is there actually a valid reason to have a separate /usr? I don't
see any.

> But it's all good.  There's an active community (and Linux
> distributions) that are still working to maintain sysvinit.

This is not related to systemd vs. sysvinit.

> I won't rehash the systemd / sysvinit arguments here; it's clear the
> direction that most distributions are taking.  People who want the
> older, simpler way, especially for older systems, or who like to
> maintain some compatibility with the BSD universe, will be able to find
> a way.
Forking hundreds of shell instances for doing simple things like string
substitution isn't efficient. It's a brain-dead design. Anyone who thinks
that sysvinit is the original Unix design has never used an original
Unix. sysvinit has always been a hack.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
On 6/21/19 3:36 PM, John Paul Adrian Glaubitz wrote:
> Forking hundreds of shell instances for doing simple things like string
> substitution isn't efficient. It's a brain-dead design. Anyone who thinks
> that sysvinit is the original Unix design has never used an original
> Unix. sysvinit has always been a hack.

And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for anyone
who is still convinced the "old traditional Unix way" (TM) is the way to
go. It isn't. Original Unix sucks. I have used HP-UX, OSF/1 and old versions
of Solaris and they are all horrible to use.

Adrian

> [1] https://web.mit.edu/~simsong/www/ugh.pdf

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Geert Uytterhoeven
In reply to this post by John Paul Adrian Glaubitz
Hi Adrian,

On Fri, Jun 21, 2019 at 3:36 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> > I now understand that the latest trend is that a separate /usr is not
> > recommended.  And it's clear that most major Linux distributions have
> > become dependent on systemd.  That's neither good nor bad; the GPL will
> > allow people to do whatever they want.  I have to say that I was a
> > little troubled by the supremely smug attitude in the above link.
>
> Well, is there actually a valid reason to have a separate /usr? I don't
> see any.

Not anymore, given the size of modern hard drives.
It was when 240 MB was considered a very expensive hard drive.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Geert Uytterhoeven
In reply to this post by John Paul Adrian Glaubitz
Hi Adrian,

On Fri, Jun 21, 2019 at 3:39 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:

> On 6/21/19 3:36 PM, John Paul Adrian Glaubitz wrote:
> > Forking hundreds of shell instances for doing simple things like string
> > substitution isn't efficient. It's a brain-dead design. Anyone who thinks
> > that sysvinit is the original Unix design has never used an original
> > Unix. sysvinit has always been a hack.
>
> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for anyone
> who is still convinced the "old traditional Unix way" (TM) is the way to
> go. It isn't. Original Unix sucks. I have used HP-UX, OSF/1 and old versions
> of Solaris and they are all horrible to use.

Those all postdate SunOS4.1.3 ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

userm57
In reply to this post by John Paul Adrian Glaubitz
On 6/21/19 7:36 AM, John Paul Adrian Glaubitz wrote:

> On 6/21/19 1:55 AM, [hidden email] wrote:
>> It's neither right nor wrong for people to make assumptions based on
>> their prior experience.  The link that Adrian sent on a different thread
>> regarding a separate /usr was instructive:
>>
>> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
>
> It's surely not wrong to make your own assumptions. But at least you should
> give me a chance to explain the situation a bit. There are certain design
> decisions that we cannot influence and there are certain issues that are
> bugs that can be bugs.
>
> If you give me some time to look at the issue you are experiencing, I can
> tell you whether this is "as expected" or you actually stumbled into a bug.

ok, thanks

>
>> I now understand that the latest trend is that a separate /usr is not
>> recommended.  And it's clear that most major Linux distributions have
>> become dependent on systemd.  That's neither good nor bad; the GPL will
>> allow people to do whatever they want.  I have to say that I was a
>> little troubled by the supremely smug attitude in the above link.
>
> Well, is there actually a valid reason to have a separate /usr? I don't
> see any.

Yes, I think there are valid reasons, so we can disagree.  On a
production system, it makes sense to separate user files from system
files, including system logs.  So if user directories are in, for
example, /usr/people, but there's only a single filesystem for
everything, then users can fill up the filesystem, and then if there's a
crash it can be difficult to figure out what happened because the
filesystem filled up.  In the old days, it was common in a security
attack for a local non-privileged user to fill up the root filesystem
and then proceed with escalation attacks, which then would not be logged
(which is why /tmp should also not be on the root filesystem).  This
case can be addressed by having a separate filesystem for home
directories, such as /home.

A second case I can think of is if an administrator wants slightly
different executables with the same names that behave differently
whether called by a non-privileged user or root.  In that case, these
different executables can exist, for example, in /sbin and /usr/sbin,
where /sbin is not readable by users but exists before /usr/sbin in
root's path.

A third case involves corrupted filesystems.  If root is 2 GB and usr is
500 GB, and root becomes hopelessly corrupted, then only 2 GB needs to
be restored instead of 502 GB.  If usr becomes corrupted, then (ideally)
single user mode with critical files such as dump and restore in /sbin
can be used to restore usr without resorting to booting from an
alternate partition or installation media.

>
>> But it's all good.  There's an active community (and Linux
>> distributions) that are still working to maintain sysvinit.
>
> This is not related to systemd vs. sysvinit.

Of course it is.  Entire distributions have forked over the disagreement
in philosophy between systemd and sysvinit.

>
>> I won't rehash the systemd / sysvinit arguments here; it's clear the
>> direction that most distributions are taking.  People who want the
>> older, simpler way, especially for older systems, or who like to
>> maintain some compatibility with the BSD universe, will be able to find
>> a way.
> Forking hundreds of shell instances for doing simple things like string
> substitution isn't efficient. It's a brain-dead design. Anyone who thinks
> that sysvinit is the original Unix design has never used an original
> Unix. sysvinit has always been a hack.
>
> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for
> anyone who is still convinced the "old traditional Unix way" (TM)
> is the way to go. It isn't. Original Unix sucks. I have used HP-UX,
> OSF/1 and old versions of Solaris and they are all horrible to use.

Well, I've used IRIX, SunOS (Solaris) 4-7, ConvexOS and others, and they
all had something similar to sysvinit (startup scripts based on run
levels).  All operating systems have their pros and cons.  Regardless of
how inefficient the startup scripts are, they don't run very often, so
efficiency isn't that important.  When I see systemd taking several
minutes to do something relatively simple like adding swap, that doesn't
strike me as particularly efficient, especially on older, slower systems.

>
> Adrian
>

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
In reply to this post by Geert Uytterhoeven
Hi!

On 6/21/19 3:57 PM, Geert Uytterhoeven wrote:
>> Well, is there actually a valid reason to have a separate /usr? I don't
>> see any.
>
> Not anymore, given the size of modern hard drives.
> It was when 240 MB was considered a very expensive hard drive.

Oh sure. I don't deny that there was reason. I just say that basically no one
does it anymore and the majority of Linux applications is not tested for
this type of partitioning.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

userm57
On 6/21/19 8:25 AM, John Paul Adrian Glaubitz wrote:

> Hi!
>
> On 6/21/19 3:57 PM, Geert Uytterhoeven wrote:
>>> Well, is there actually a valid reason to have a separate /usr? I don't
>>> see any.
>>
>> Not anymore, given the size of modern hard drives.
>> It was when 240 MB was considered a very expensive hard drive.
>
> Oh sure. I don't deny that there was reason. I just say that basically no one
> does it anymore and the majority of Linux applications is not tested for
> this type of partitioning.
> ...

Then the Debian installer should mention that a separate /usr is not
supported instead of making it appear (in the partitioning phase) that
having a separate /usr is a viable option.  I realize that applies more
generally to Debian distributions and isn't directly related to the m68k
or powerpc ports.

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
In reply to this post by userm57
On 6/21/19 4:08 PM, [hidden email] wrote:
> Yes, I think there are valid reasons, so we can disagree.  On a
> production system, it makes sense to separate user files from system
> files, including system logs.

On production systems, you don't collect system logs locally but forward
them to a loghost. At least that's I know to be common.

> So if user directories are in, for
> example, /usr/people, but there's only a single filesystem for
> everything, then users can fill up the filesystem,

User directories haven't been in /usr for at least two decades now,
so that argument doesn't hold. User directories are in /home which
is always a separate filesystem in large production environments, the
rest of the system is more or less static.

> and then if there's a
> crash it can be difficult to figure out what happened because the
> filesystem filled up.

Sure. But user directories are not stored below /usr, so that argument
doesn't hold. On the contrary, I have seen a lot of cases where a separate
/var filled up.

> In the old days, it was common in a security
> attack for a local non-privileged user to fill up the root filesystem
> and then proceed with escalation attacks, which then would not be logged
> (which is why /tmp should also not be on the root filesystem).

As you say, "in the old days".

> This
> case can be addressed by having a separate filesystem for home
> directories, such as /home.

A separate /home is not the same as a separate /usr. A separate /home
is still fully supported.

> A second case I can think of is if an administrator wants slightly
> different executables with the same names that behave differently
> whether called by a non-privileged user or root.  In that case, these
> different executables can exist, for example, in /sbin and /usr/sbin,
> where /sbin is not readable by users but exists before /usr/sbin in
> root's path.

That's a constructed usecase and nothing that would exist in the real
world as the administrator can just use PATH variables and ACLs to
cover everything possible in this regard.

> A third case involves corrupted filesystems.  If root is 2 GB and usr is
> 500 GB, and root becomes hopelessly corrupted, then only 2 GB needs to
> be restored instead of 502 GB.  If usr becomes corrupted, then (ideally)
> single user mode with critical files such as dump and restore in /sbin
> can be used to restore usr without resorting to booting from an
> alternate partition or installation media.

How does that help if your root partition gets corrupted? This is, again,
a very constructed use case. Also, if your system doesn't boot, just use
a rescue boot medium which is the best thing to do anyway to prevent any
further filesystem damage.

>>> But it's all good.  There's an active community (and Linux
>>> distributions) that are still working to maintain sysvinit.
>>
>> This is not related to systemd vs. sysvinit.
>
> Of course it is.  Entire distributions have forked over the disagreement
> in philosophy between systemd and sysvinit.

No, it's absolutely not. A lot of applications nowadays assume for /usr
not to be separated anymore. As explained in the linked Freedesktop
article, a separate /usr is simply no longer tested by most userspace
applications and hence broken.

>>> I won't rehash the systemd / sysvinit arguments here; it's clear the
>>> direction that most distributions are taking.  People who want the
>>> older, simpler way, especially for older systems, or who like to
>>> maintain some compatibility with the BSD universe, will be able to find
>>> a way.
>> Forking hundreds of shell instances for doing simple things like string
>> substitution isn't efficient. It's a brain-dead design. Anyone who thinks
>> that sysvinit is the original Unix design has never used an original
>> Unix. sysvinit has always been a hack.
>>
>> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for
>> anyone who is still convinced the "old traditional Unix way" (TM)
>> is the way to go. It isn't. Original Unix sucks. I have used HP-UX,
>> OSF/1 and old versions of Solaris and they are all horrible to use.
>
> Well, I've used IRIX, SunOS (Solaris) 4-7, ConvexOS and others, and they
> all had something similar to sysvinit (startup scripts based on run
> levels).
Modern Solaris has SMF, macOS (which officially is a UNIX(TM)) has launchd.


> All operating systems have their pros and cons.  Regardless of
> how inefficient the startup scripts are, they don't run very often, so
> efficiency isn't that important.

Yes, but you can't bring up the efficiency argument against systemd and now
say it's not an argument. Furthermore, classical sysvinit is static. It doesn't
understand what to do when you insert a USB drive or a wireless network
suddenly becomes available.

Seriously, I absolutely don't understand why people think that they have to
stick to a 30+-year-old solution when the requirements have changed a lot. I
would think that no one would argue that a modern laptop, smartphone or
smart TV is the same as a DEC3000 running OSF/1 in a local network. The latter
doesn't know anything about dynamic networks, hardware and power management,
but the former do. systemd supports dynamic changes, sysvinit does not. It's
an absolute no-brainer what to use in 2019.

> When I see systemd taking several
> minutes to do something relatively simple like adding swap, that doesn't
> strike me as particularly efficient, especially on older, slower systems.

It runs perfectly fine on my Amiga 4000/060/50 MHz.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

John Paul Adrian Glaubitz
In reply to this post by userm57
On 6/21/19 4:47 PM, [hidden email] wrote:

>> Oh sure. I don't deny that there was reason. I just say that basically no one
>> does it anymore and the majority of Linux applications is not tested for
>> this type of partitioning.
>> ...
>
> Then the Debian installer should mention that a separate /usr is not
> supported instead of making it appear (in the partitioning phase) that
> having a separate /usr is a viable option.  I realize that applies more
> generally to Debian distributions and isn't directly related to the m68k
> or powerpc ports.
Feel free to report a bug against the src:debian-installer package so that
such a change gets incorporated.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Andreas Schwab-2
In reply to this post by Geert Uytterhoeven
On Jun 21 2019, Geert Uytterhoeven <[hidden email]> wrote:

> Hi Adrian,
>
> On Fri, Jun 21, 2019 at 3:39 PM John Paul Adrian Glaubitz
> <[hidden email]> wrote:
>> On 6/21/19 3:36 PM, John Paul Adrian Glaubitz wrote:
>> > Forking hundreds of shell instances for doing simple things like string
>> > substitution isn't efficient. It's a brain-dead design. Anyone who thinks
>> > that sysvinit is the original Unix design has never used an original
>> > Unix. sysvinit has always been a hack.
>>
>> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for anyone
>> who is still convinced the "old traditional Unix way" (TM) is the way to
>> go. It isn't. Original Unix sucks. I have used HP-UX, OSF/1 and old versions
>> of Solaris and they are all horrible to use.
>
> Those all postdate SunOS4.1.3 ;-)

Did you mean SunOS4.1.1?  4.1.3 didn't support Sun-3 any more.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Geert Uytterhoeven
Hi Andreas,

On Fri, Jun 21, 2019 at 7:16 PM Andreas Schwab <[hidden email]> wrote:

> On Jun 21 2019, Geert Uytterhoeven <[hidden email]> wrote:
> > On Fri, Jun 21, 2019 at 3:39 PM John Paul Adrian Glaubitz
> > <[hidden email]> wrote:
> >> On 6/21/19 3:36 PM, John Paul Adrian Glaubitz wrote:
> >> > Forking hundreds of shell instances for doing simple things like string
> >> > substitution isn't efficient. It's a brain-dead design. Anyone who thinks
> >> > that sysvinit is the original Unix design has never used an original
> >> > Unix. sysvinit has always been a hack.
> >>
> >> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for anyone
> >> who is still convinced the "old traditional Unix way" (TM) is the way to
> >> go. It isn't. Original Unix sucks. I have used HP-UX, OSF/1 and old versions
> >> of Solaris and they are all horrible to use.
> >
> > Those all postdate SunOS4.1.3 ;-)
>
> Did you mean SunOS4.1.1?  4.1.3 didn't support Sun-3 any more.

I did mean the pre-Solaris version that ran on SPARC.

But 4.1.1 was fine, too, I guess ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Michael Schmitz-4
In reply to this post by John Paul Adrian Glaubitz
Can we move systemd vs. sysvinit discussions to a more general forum?
I'm sure it would be welcome there.

Cheers,

        Michael

(who didn't realize how much he missed the good old usenet and mailing
list flamewars of the past... )

Am 22.06.2019 um 03:02 schrieb John Paul Adrian Glaubitz:

> On 6/21/19 4:08 PM, [hidden email] wrote:
>> Yes, I think there are valid reasons, so we can disagree.  On a
>> production system, it makes sense to separate user files from system
>> files, including system logs.
>
> On production systems, you don't collect system logs locally but forward
> them to a loghost. At least that's I know to be common.
>
>> So if user directories are in, for
>> example, /usr/people, but there's only a single filesystem for
>> everything, then users can fill up the filesystem,
>
> User directories haven't been in /usr for at least two decades now,
> so that argument doesn't hold. User directories are in /home which
> is always a separate filesystem in large production environments, the
> rest of the system is more or less static.
>
>> and then if there's a
>> crash it can be difficult to figure out what happened because the
>> filesystem filled up.
>
> Sure. But user directories are not stored below /usr, so that argument
> doesn't hold. On the contrary, I have seen a lot of cases where a separate
> /var filled up.
>
>> In the old days, it was common in a security
>> attack for a local non-privileged user to fill up the root filesystem
>> and then proceed with escalation attacks, which then would not be logged
>> (which is why /tmp should also not be on the root filesystem).
>
> As you say, "in the old days".
>
>> This
>> case can be addressed by having a separate filesystem for home
>> directories, such as /home.
>
> A separate /home is not the same as a separate /usr. A separate /home
> is still fully supported.
>
>> A second case I can think of is if an administrator wants slightly
>> different executables with the same names that behave differently
>> whether called by a non-privileged user or root.  In that case, these
>> different executables can exist, for example, in /sbin and /usr/sbin,
>> where /sbin is not readable by users but exists before /usr/sbin in
>> root's path.
>
> That's a constructed usecase and nothing that would exist in the real
> world as the administrator can just use PATH variables and ACLs to
> cover everything possible in this regard.
>
>> A third case involves corrupted filesystems.  If root is 2 GB and usr is
>> 500 GB, and root becomes hopelessly corrupted, then only 2 GB needs to
>> be restored instead of 502 GB.  If usr becomes corrupted, then (ideally)
>> single user mode with critical files such as dump and restore in /sbin
>> can be used to restore usr without resorting to booting from an
>> alternate partition or installation media.
>
> How does that help if your root partition gets corrupted? This is, again,
> a very constructed use case. Also, if your system doesn't boot, just use
> a rescue boot medium which is the best thing to do anyway to prevent any
> further filesystem damage.
>
>>>> But it's all good.  There's an active community (and Linux
>>>> distributions) that are still working to maintain sysvinit.
>>>
>>> This is not related to systemd vs. sysvinit.
>>
>> Of course it is.  Entire distributions have forked over the disagreement
>> in philosophy between systemd and sysvinit.
>
> No, it's absolutely not. A lot of applications nowadays assume for /usr
> not to be separated anymore. As explained in the linked Freedesktop
> article, a separate /usr is simply no longer tested by most userspace
> applications and hence broken.
>
>>>> I won't rehash the systemd / sysvinit arguments here; it's clear the
>>>> direction that most distributions are taking.  People who want the
>>>> older, simpler way, especially for older systems, or who like to
>>>> maintain some compatibility with the BSD universe, will be able to find
>>>> a way.
>>> Forking hundreds of shell instances for doing simple things like string
>>> substitution isn't efficient. It's a brain-dead design. Anyone who thinks
>>> that sysvinit is the original Unix design has never used an original
>>> Unix. sysvinit has always been a hack.
>>>
>>> And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for
>>> anyone who is still convinced the "old traditional Unix way" (TM)
>>> is the way to go. It isn't. Original Unix sucks. I have used HP-UX,
>>> OSF/1 and old versions of Solaris and they are all horrible to use.
>>
>> Well, I've used IRIX, SunOS (Solaris) 4-7, ConvexOS and others, and they
>> all had something similar to sysvinit (startup scripts based on run
>> levels).
> Modern Solaris has SMF, macOS (which officially is a UNIX(TM)) has launchd.
>
>
>> All operating systems have their pros and cons.  Regardless of
>> how inefficient the startup scripts are, they don't run very often, so
>> efficiency isn't that important.
>
> Yes, but you can't bring up the efficiency argument against systemd and now
> say it's not an argument. Furthermore, classical sysvinit is static. It doesn't
> understand what to do when you insert a USB drive or a wireless network
> suddenly becomes available.
>
> Seriously, I absolutely don't understand why people think that they have to
> stick to a 30+-year-old solution when the requirements have changed a lot. I
> would think that no one would argue that a modern laptop, smartphone or
> smart TV is the same as a DEC3000 running OSF/1 in a local network. The latter
> doesn't know anything about dynamic networks, hardware and power management,
> but the former do. systemd supports dynamic changes, sysvinit does not. It's
> an absolute no-brainer what to use in 2019.
>
>> When I see systemd taking several
>> minutes to do something relatively simple like adding swap, that doesn't
>> strike me as particularly efficient, especially on older, slower systems.
>
> It runs perfectly fine on my Amiga 4000/060/50 MHz.
>
> Adrian
>

Reply | Threaded
Open this post in threaded view
|

Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation

Finn Thain
In reply to this post by John Paul Adrian Glaubitz
On Fri, 21 Jun 2019, John Paul Adrian Glaubitz wrote:

> Forking hundreds of shell instances for doing simple things like string
> substitution isn't efficient. It's a brain-dead design.

That was a limitation of the shell that was fixed over a decade before
systemd came along. I could not find a weaker justification for tossing
out sysvinit if I tried.

> Anyone who thinks that sysvinit is the original Unix design has never
> used an original Unix. sysvinit has always been a hack.
>

This really is a straw man. No one claimed that sysvinit was anything more
than the lesser evil.

Anyway, attacking/defending sysvinit is boring. Far more useful is to
consider the design decisions made by Ubuntu in upstart, by Apple in
lunchd, by Sun in SMF, by Gentoo in OpenRC, etc. That's interesting
because the comparison with systemd tells us something about how Red Hat
operates.

--

> Adrian
>
>

12345