Joel Roth via Dng - 05.08.22, 21:56:01 CEST:
> On Fri, Aug 05, 2022 at 03:05:54PM +, jkinney23--- via Dng wrote:
> > On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via
> > Dng wrote:
> > > I haven't followed more modern experimental operating systems.
> > > Mostly you don't
On Fri, Aug 05, 2022 at 03:05:54PM +, jkinney23--- via Dng wrote:
> On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via Dng
> wrote:
> > I haven't followed more modern experimental operating systems. Mostly you
> > don't hear as much about them these days, I think a
> > lot of
On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via Dng
wrote:
> I haven't followed more modern experimental operating systems. Mostly you
> don't hear as much about them these days, I think a
> lot of researchers use an existing Open Source OS as a base for some specific
>
On Thu, 2022-08-04 at 14:53 -0700, Bruce Perens via Dng wrote:
>
> This goes way back. Mach did lightweight messaging and more (and survives
> in MacOS, I think), Plan 9 did the graphics API == window system API.
I pretty much like GNU/Linux just as it is, but I'd love to have a sane graphics
On Thu, Aug 4, 2022 at 7:01 AM wrote:
> Do you have some pointers to thoose experimental operating systems
> so I can get a taste of what you are talking about ?
This goes way back. Mach did lightweight messaging and more (and survives
in MacOS, I think), Plan 9 did the graphics API == window
On Thu, Aug 04, 2022 at 05:19:18PM +0200, Didier Kryn wrote:
> Le 04/08/2022 à 00:36, Bruce Perens via Dng a écrit :
> > The fundamental OS concept is "Everything's an API" rather than
> > everything's a file.
> > APIs rather than libraries and linking.
>
> etc...
>
> It seems to me that
Le 04/08/2022 à 00:36, Bruce Perens via Dng a écrit :
The fundamental OS concept is "Everything's an API" rather than
everything's a file.
APIs rather than libraries and linking.
etc...
It seems to me that "everything is a file" could do it yet: the
kernel implements such an API though
Quite a few of these concepts for the new OS remind me of Erlang BEAM. Does
this comparison make sense?
On Wed, Aug 3, 2022 at 10:36 PM Bruce Perens via Dng
wrote:
> I came to the conclusion a while back that systemd was symptomatic of the
> fact that we had gone as far as the fundamental
What do we as a community need to do
to get S6 into a "corporate friendly" state?
What can I do to help?
"Corporate-friendly" is not really the problem here. The problem is
more "distro-friendly".
Distributions like integrated systems. Integrated systems make their
lives easier, because
What do we as a community need to do
to get S6 into a "corporate friendly" state?
What can I do to help?
Here are some ideas:
- easier access to the VCS (git, pijul, etc)
- Issue tracking system
- CI/CD build chain (being careful not to make it too painful to use)
- "idiot proof" website
-
Bruce Perens:
...
> But we should be looking forward to something else as the next OS paradigm.
> This would include features that have been seen mostly in experimental
> operating systems up to now. This is what I think the "next OS" might be:
>
> The fundamental OS concept is "Everything's an
On Wed, 2022-08-03 at 15:36 -0700, Bruce Perens wrote:
> I came to the conclusion a while back that systemd was symptomatic of the
> fact that we had gone as far as the fundamental assumptions of the Unix API
> could take us.
I find it symptomatic of the fact that a guy wrote some Rube Goldberg
On Wed, 2022-08-03 at 17:19 +, J.R. Hill wrote:
> There are a few things that need to be in place for a smooth transition.
>
> For general trust in the project...
>
> 1. the init system itself should be maintained by more than a single human.
This hasn't been the case with runit. It's so
I came to the conclusion a while back that systemd was symptomatic of the
fact that we had gone as far as the fundamental assumptions of the Unix API
could take us. It is 50 years old, after all.
There is room for replacement of systemd and continuation of Linux and BSD.
But we should be looking
There are a few things that need to be in place for a smooth transition.
For general trust in the project...
1. the init system itself should be maintained by more than a single human.
2. the maintainers should be willing to respond to a large audience. (If a
project is used widely across
Steve Litt:
...
Busybox doesn't do what I guess you want, for that you just
fire up a process supervisor, there are a few to choose among.
Remember busybox init is just a minimal init, everthing else
is some other programs responsibility. You can think of busybox
init as sysv init but with just
On Tue, 2022-08-02 at 11:25 +0200, k...@aspodata.se wrote:
> Steve Litt:
> ...
> > * Runit
> > * S6
> ...
>
> Why not busybox init, it handles gettys and the rest is up to
> /etc/rcS, which you are free to make it do whatever you like.
>
> As a direct replacement for sysv init, you can use
> for
Steve Litt:
...
> * Runit
> * S6
...
Why not busybox init, it handles gettys and the rest is up to
/etc/rcS, which you are free to make it do whatever you like.
As a direct replacement for sysv init, you can use
for i in /etc/rcS.d/S* /etc/rc2.d/S*
do
$i start
done
in rcS and similar for
18 matches
Mail list logo
