Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178777 > unrolled thread

If Linux Is About Choice, Why Then ...

Back to article view | Back to linux.debian.user

Contents

  If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-03-13 20:40 +0100
    Re: If Linux Is About Choice, Why Then ... "John L. Ries" <jries@salford-systems.com> - 2017-03-13 20:50 +0100
    Re: If Linux Is About Choice, Why Then ... Greg Wooledge <wooledg@eeg.ccf.org> - 2017-03-13 20:50 +0100
      Re: If Linux Is About Choice, Why Then ... Erwan David <erwan@rail.eu.org> - 2017-03-13 20:50 +0100
        Re: If Linux Is About Choice, Why Then ... rhkramer@gmail.com - 2017-03-13 21:50 +0100
        Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-03-13 22:00 +0100
          Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-03-15 13:20 +0100
        Re: If Linux Is About Choice, Why Then ... Liam O'Toole <liam.p.otoole@gmail.com> - 2017-03-14 12:40 +0100
          Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-03-14 20:00 +0100
            Re: If Linux Is About Choice, Why Then ... Liam O'Toole <liam.p.otoole@gmail.com> - 2017-03-14 21:30 +0100
            Re: If Linux Is About Choice, Why Then ... Glenn Holmer <cenbe@kolabnow.com> - 2017-03-14 21:30 +0100
            Re: If Linux Is About Choice, Why Then ... Sven Hartge <sven@svenhartge.de> - 2017-03-14 21:50 +0100
      Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-03-13 22:00 +0100
        Re: If Linux Is About Choice, Why Then ... Andy Smith <andy@strugglers.net> - 2017-03-13 22:50 +0100
      Re: If Linux Is About Choice, Why Then ... Rick Thomas <rbthomas@pobox.com> - 2017-04-03 14:10 +0200
        Re: If Linux Is About Choice, Why Then ... Brad Rogers <brad@fineby.me.uk> - 2017-04-03 14:30 +0200
          Re: If Linux Is About Choice, Why Then ... Tom Browder <tom.browder@gmail.com> - 2017-04-03 16:40 +0200
            Systemd services (was Re: If Linux Is About Choice, Why Then ...) Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-03 18:00 +0200
              Re: Systemd services Teemu Likonen <tlikonen@iki.fi> - 2017-04-03 19:00 +0200
              Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...) Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-04-03 19:10 +0200
              Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...) deloptes <deloptes@gmail.com> - 2017-04-03 22:50 +0200
            Re: If Linux Is About Choice, Why Then ... Rick Thomas <rbthomas@pobox.com> - 2017-04-05 10:30 +0200
              Re: If Linux Is About Choice, Why Then ... Darac Marjal <mailinglist@darac.org.uk> - 2017-04-05 13:30 +0200
                Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-05 17:20 +0200
              Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-06 15:50 +0200
        Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-05 16:50 +0200
          Re: If Linux Is About Choice, Why Then ... Dan Ritter <dsr@randomstring.org> - 2017-04-05 17:10 +0200
            Re: If Linux Is About Choice, Why Then ... Michael Biebl <biebl@debian.org> - 2017-04-05 19:30 +0200
              Re: If Linux Is About Choice, Why Then ... Dan Ritter <dsr@randomstring.org> - 2017-04-05 20:10 +0200
                Re: If Linux Is About Choice, Why Then ... Michael Biebl <biebl@debian.org> - 2017-04-05 20:20 +0200
                  Re: If Linux Is About Choice, Why Then ... Latincom <latincom@vcn.bc.ca> - 2017-04-06 11:00 +0200
                    Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-06 17:20 +0200
            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-06 11:20 +0200
              Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 12:00 +0200
                Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-04-06 12:20 +0200
                  Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 12:40 +0200
                    Re: If Linux Is About Choice, Why Then ... Dejan Jocic <jodejka@gmail.com> - 2017-04-06 13:10 +0200
                      Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 13:40 +0200
                        Re: If Linux Is About Choice, Why Then ... Carl Fink <carl@finknetwork.com> - 2017-04-06 15:10 +0200
                          Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-04-06 16:10 +0200
                            Re: If Linux Is About Choice, Why Then ... Carl Fink <carl@finknetwork.com> - 2017-04-06 16:30 +0200
                          Re: If Linux Is About Choice, Why Then ... Dejan Jocic <jodejka@gmail.com> - 2017-04-06 16:20 +0200
                          Re: If Linux Is About Choice, Why Then ... John Hasler <jhasler@newsguy.com> - 2017-04-06 16:50 +0200
                Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-06 12:20 +0200
                  Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 13:00 +0200
                    Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-06 17:50 +0200
                      Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 19:10 +0200
                        Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-06 20:00 +0200
                          Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-06 20:20 +0200
    Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-03-14 00:40 +0100
      Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-03-14 01:30 +0100
        Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-03-14 02:00 +0100
      Re: If Linux Is About Choice, Why Then ... Sven Hartge <sven@svenhartge.de> - 2017-03-14 13:10 +0100
    Re: If Linux Is About Choice, Why Then ... Jan-Peter Rühmann <jan-peter@ruehmann.name> - 2017-03-14 12:20 +0100
    Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-03-15 13:10 +0100
    Re: If Linux Is About Choice, Why Then ... cbannister@slingshot.co.nz - 2017-04-01 13:50 +0200
      Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-02 01:40 +0200
        Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-02 02:30 +0200
          Re: If Linux Is About Choice, Why Then ... The Wanderer <wanderer@fastmail.fm> - 2017-04-03 13:10 +0200
            Re: If Linux Is About Choice, Why Then ... Rick Thomas <rbthomas@pobox.com> - 2017-04-03 13:50 +0200
              Re: If Linux Is About Choice, Why Then ... The Wanderer <wanderer@fastmail.fm> - 2017-04-03 14:10 +0200
              Re: If Linux Is About Choice, Why Then ... Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-03 14:30 +0200
            Re: If Linux Is About Choice, Why Then ... Carl Fink <carl@finknetwork.com> - 2017-04-03 14:40 +0200
              Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-03 15:20 +0200
                Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-03 16:20 +0200
                  Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-04 19:10 +0200
              Re: If Linux Is About Choice, Why Then ... Sven Hartge <sven@svenhartge.de> - 2017-04-03 16:00 +0200
                Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-03 16:40 +0200
              Re: If Linux Is About Choice, Why Then ... Latincom <latincom@vcn.bc.ca> - 2017-04-04 00:50 +0200
            Re: If Linux Is About Choice, Why Then ... Don Armstrong <don@debian.org> - 2017-04-04 18:20 +0200
              Re: If Linux Is About Choice, Why Then ... The Wanderer <wanderer@fastmail.fm> - 2017-04-05 05:10 +0200
          Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-03 18:10 +0200
            Re: If Linux Is About Choice, Why Then ... Don Armstrong <don@debian.org> - 2017-04-03 20:00 +0200
              Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-04 18:40 +0200
                Re: If Linux Is About Choice, Why Then ... Mark Fletcher <mark27q1@gmail.com> - 2017-04-05 00:50 +0200
                  Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-05 01:30 +0200
                  Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-05 11:10 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#179860

On Thu, Apr 06, 2017 at 03:08:33PM +0100, Martin Read wrote:
> On 06/04/17 14:03, Carl Fink wrote:
> > Second set of hardware is a false requirement. Go to, say,
> > http://nosupportlinuxhosting.com and rent a VM for $1/month
> 
> *cough* That site does not offer VM hosting for $1/month. It offers *web*
> hosting for $1/month. (The sister site offers VPS hosting... for $15/month.)

Well, that changed in the two or three years since I was actually using
virtual servers from them.

Sorry.

> Also, you seem to be presupposing that nothing about the system in question
> requires functioning local peripherals.

At the least I was assuming that this wouldn't be any more of a hassle than
the originally-proposed server migration.
-- 
Carl Fink                           nitpicking@nitpicking.com 

Read my blog at blog.nitpicking.com.  Reviews!  Observations!
Stupid mistakes you can correct!

[toc] | [prev] | [next] | [standalone]

#179859

On 06-04-17, Carl Fink wrote:
> On Thu, Apr 06, 2017 at 12:35:37PM +0100, Joe wrote:
> 
> > If I was a paid admin looking after multiple servers, yes, that's the
> > obvious thing to do. But this isn't my job, and I can't afford to buy a
> > second set of hardware, so the only practical test is to actually do
> > it.
> 
> Second set of hardware is a false requirement. Go to, say,
> http://nosupportlinuxhosting.com and rent a VM for $1/month and set up your
> server there. Make it work. If you insist on physical hardware, you can then
> clone the working setup back to your physical server.
> -- 
> Carl Fink                           nitpicking@nitpicking.com 
> 
> Read my blog at blog.nitpicking.com.  Reviews!  Observations!
> Stupid mistakes you can correct!
> 

Yes, when I've mentioned cloning I thought of virtual clone, not cloning
on hardware. There are many virtual solutions for your problem.

[toc] | [prev] | [next] | [standalone]

#179861

Carl Fink writes:
> Go to, say, http://nosupportlinuxhosting.com and rent a VM for
> $1/month

That looked interesting, but it doesn't appear that they offer VMs: just
Cpanels.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#179846

[Multipart message — attachments visible in raw view] — view raw

Le septidi 17 germinal, an CCXXV, Joe a écrit :
>		   Even if that could be fixed afterwards, then there
> will be server downtime and a manual procedure involved which will not
> be part of the upgrade procedure and therefore will not have been tested
> by the upgrade designers.

Does that mean that apart from the systemd issue you expect dist-upgrade
to have been tested on your particular setup and to finish without
downtime and manual procedure?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#179851

On Thu, 6 Apr 2017 12:13:06 +0200
Nicolas George <george@nsup.org> wrote:

> Le septidi 17 germinal, an CCXXV, Joe a écrit :
> >		   Even if that could be fixed afterwards, then there
> > will be server downtime and a manual procedure involved which will
> > not be part of the upgrade procedure and therefore will not have
> > been tested by the upgrade designers.  
> 
> Does that mean that apart from the systemd issue you expect
> dist-upgrade to have been tested on your particular setup and to
> finish without downtime and manual procedure?
> 

On the whole, yes. I have only packages from the Debian repositories
installed, plus some of my own scripts. If I follow the upgrade release
notes to the letter, I expect every package to upgrade cleanly, with
possibly some minor problems with scripts. I expect some problems with
web pages from different versions of apache, php, etc., but I don't
consider them to be operating system upgrade issues.

Granted, there have been more little niggles with each upgrade (this
machine started life as sarge), things get more complicated with each
version. I'm not that bothered about downtime (within reason, the
Debian lists get very stroppy when their emails bounce) but some people
are. What is more worrying is having to wing it through a procedure
which has not been tested fully and described in the upgrade documents,
but it does appear that will not be the case here.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#179866

On Thu 06 Apr 2017 at 11:50:56 (+0100), Joe wrote:
> On Thu, 6 Apr 2017 12:13:06 +0200
> Nicolas George <george@nsup.org> wrote:
> 
> > Le septidi 17 germinal, an CCXXV, Joe a écrit :
> > >		   Even if that could be fixed afterwards, then there
> > > will be server downtime and a manual procedure involved which will
> > > not be part of the upgrade procedure and therefore will not have
> > > been tested by the upgrade designers.  
> > 
> > Does that mean that apart from the systemd issue you expect
> > dist-upgrade to have been tested on your particular setup and to
> > finish without downtime and manual procedure?
> > 
> 
> On the whole, yes. I have only packages from the Debian repositories
> installed, plus some of my own scripts. If I follow the upgrade release
> notes to the letter, I expect every package to upgrade cleanly, with
> possibly some minor problems with scripts. I expect some problems with
> web pages from different versions of apache, php, etc., but I don't
> consider them to be operating system upgrade issues.
> 
> Granted, there have been more little niggles with each upgrade (this
> machine started life as sarge), things get more complicated with each
> version.

I thought lenny→squeeze was the most complicated, because lenny's
standard kernel was not compatible with the upgrade process and
had to be upgraded in a preliminary step. That could then lead to
knock-on effects with non-free firmware. And, for safety, udev
had to be immediately upgraded because of the new kernel, then
the system rebooted to bring them into operation before the
upgrade.

> I'm not that bothered about downtime (within reason, the
> Debian lists get very stroppy when their emails bounce) but some people
> are.

A few minutes later you posted:

> If I was a paid admin looking after multiple servers, yes, that's the
> obvious thing to do. But this isn't my job, and I can't afford to buy a
> second set of hardware, so the only practical test is to actually do
> it.

How about getting those freeloading critics to fork out for
a new drive so that you can build and test a second system
(dual-bootable) during your scheduled downtimes.

> What is more worrying is having to wing it through a procedure
> which has not been tested fully and described in the upgrade documents,
> but it does appear that will not be the case here.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#179868

On Thu, 6 Apr 2017 10:45:23 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Thu 06 Apr 2017 at 11:50:56 (+0100), Joe wrote:

> > 
> > Granted, there have been more little niggles with each upgrade (this
> > machine started life as sarge), things get more complicated with
> > each version.  
> 
> I thought lenny→squeeze was the most complicated, because lenny's
> standard kernel was not compatible with the upgrade process and
> had to be upgraded in a preliminary step. That could then lead to
> knock-on effects with non-free firmware. And, for safety, udev
> had to be immediately upgraded because of the new kernel, then
> the system rebooted to bring them into operation before the
> upgrade.

I don't remember that, though I must have gone through it. I wouldn't
dare try skipping a version. The only serious problem I had was when
exim4 jumped a version, and the new one didn't accept debconf
directives, and I hadn't noticed. Upgrading with the old configuration
file being kept turned out to be a big no-no, it got into a state where
even dpkg wouldn't uninstall the broken bits, and I had to resort to
deleting files manually.

> 
> > I'm not that bothered about downtime (within reason, the
> > Debian lists get very stroppy when their emails bounce) but some
> > people are.  
> 
> A few minutes later you posted:
> 
> > If I was a paid admin looking after multiple servers, yes, that's
> > the obvious thing to do. But this isn't my job, and I can't afford
> > to buy a second set of hardware, so the only practical test is to
> > actually do it.  
> 
> How about getting those freeloading critics to fork out for
> a new drive so that you can build and test a second system
> (dual-bootable) during your scheduled downtimes.
> 

My what? It's a home server/firewall/mail server. There is no scheduled
downtime. I migrated to a new hard drive a few months ago, and that
gave me some unscheduled downtime until I discovered what the BIOS was
doing with drive naming... it was one of those 'no, this *cannot* be
happening' moments where I copied /etc/fstab between the wrong pair of
drives, thereby breaking both old and new installations.

It still seems to be unreasonably difficult to use a working
installation to install the correct grub information to another drive
which is intended to become the new working installation, still a matter
of messing around with chroot and a sequence of mounts and unmounts.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#179870

On Thu 06 Apr 2017 at 18:02:22 (+0100), Joe wrote:
> On Thu, 6 Apr 2017 10:45:23 -0500
> David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> > On Thu 06 Apr 2017 at 11:50:56 (+0100), Joe wrote:
> 
> > > 
> > > Granted, there have been more little niggles with each upgrade (this
> > > machine started life as sarge), things get more complicated with
> > > each version.  
> > 
> > I thought lenny→squeeze was the most complicated, because lenny's
> > standard kernel was not compatible with the upgrade process and
> > had to be upgraded in a preliminary step. That could then lead to
> > knock-on effects with non-free firmware. And, for safety, udev
> > had to be immediately upgraded because of the new kernel, then
> > the system rebooted to bring them into operation before the
> > upgrade.
> 
> I don't remember that, though I must have gone through it. I wouldn't
> dare try skipping a version. The only serious problem I had was when
> exim4 jumped a version, and the new one didn't accept debconf
> directives, and I hadn't noticed. Upgrading with the old configuration
> file being kept turned out to be a big no-no, it got into a state where
> even dpkg wouldn't uninstall the broken bits, and I had to resort to
> deleting files manually.
> 
> > 
> > > I'm not that bothered about downtime (within reason, the
> > > Debian lists get very stroppy when their emails bounce) but some
> > > people are.  
> > 
> > A few minutes later you posted:
> > 
> > > If I was a paid admin looking after multiple servers, yes, that's
> > > the obvious thing to do. But this isn't my job, and I can't afford
> > > to buy a second set of hardware, so the only practical test is to
> > > actually do it.  
> > 
> > How about getting those freeloading critics to fork out for
> > a new drive so that you can build and test a second system
> > (dual-bootable) during your scheduled downtimes.
> > 
> 
> My what? It's a home server/firewall/mail server. There is no scheduled
> downtime.

Sorry, I misunderstood your use of "some people". I thought they were
the users that your MTA transfers emails to.

> I migrated to a new hard drive a few months ago, and that
> gave me some unscheduled downtime until I discovered what the BIOS was
> doing with drive naming... it was one of those 'no, this *cannot* be
> happening' moments where I copied /etc/fstab between the wrong pair of
> drives, thereby breaking both old and new installations.
> 
> It still seems to be unreasonably difficult to use a working
> installation to install the correct grub information to another drive
> which is intended to become the new working installation, still a matter
> of messing around with chroot and a sequence of mounts and unmounts.

You're not still using /dev/sda, /dev/sdb, are you?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#179871

On Thu, 6 Apr 2017 12:56:51 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Thu 06 Apr 2017 at 18:02:22 (+0100), Joe wrote:
> > 
> > My what? It's a home server/firewall/mail server. There is no
> > scheduled downtime.  
> 
> Sorry, I misunderstood your use of "some people". I thought they were
> the users that your MTA transfers emails to.

No, that's just the wife. But many people running stable and wanting to
do in-place upgrades are running servers for more serious purposes.
> 
> > I migrated to a new hard drive a few months ago, and that
> > gave me some unscheduled downtime until I discovered what the BIOS
> > was doing with drive naming... it was one of those 'no, this
> > *cannot* be happening' moments where I copied /etc/fstab between
> > the wrong pair of drives, thereby breaking both old and new
> > installations.
> > 
> > It still seems to be unreasonably difficult to use a working
> > installation to install the correct grub information to another
> > drive which is intended to become the new working installation,
> > still a matter of messing around with chroot and a sequence of
> > mounts and unmounts.  
> 
> You're not still using /dev/sda, /dev/sdb, are you?

Not in general, it's nearly all LVM on UUIDs, but when I'm juggling
three drives in and out of a frame and mounting manually, yes. I'm
accustomed to having the drives assigned by position and/or jumper, but
this BIOS is 'helpful' and remembers drives it has seen recently. But
now I know that. The thing is, I'm not a professional admin, and I'm not
doing this kind of thing every day of the week, if I was then all of my
mistakes would be far in the past...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#178799

On 13/03/17 19:30, Patrick Bartek wrote:
> The Linux mantra has always been "choice," plethoras of choices. So why
> at install time, is there no choice for the init system?

Looking at the BTS page for package 'debian-installer', nobody seems to 
have filed a wishlist bug requesting this feature.

This seems like at least a contributory reason.

[toc] | [prev] | [next] | [standalone]

#178802

On 3/13/17 4:33 PM, Martin Read wrote:

> On 13/03/17 19:30, Patrick Bartek wrote:
>> The Linux mantra has always been "choice," plethoras of choices. So why
>> at install time, is there no choice for the init system?
>
> Looking at the BTS page for package 'debian-installer', nobody seems 
> to have filed a wishlist bug requesting this feature.
>
> This seems like at least a contributory reason.

Actually, there have been numerous bugs filed against both 
debian-installer and debootstrap about failures of the --include and 
--exclude statements --- that directly effect the ability to specify 
sysvinit instead of systemd.  I don't recall seeing close messages about 
all of them.

Miles Fidelman



-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]

#178803

On 14/03/17 00:20, Miles Fidelman wrote:
> Actually, there have been numerous bugs filed against both
> debian-installer and debootstrap about failures of the --include and
> --exclude statements --- that directly effect the ability to specify
> sysvinit instead of systemd.  I don't recall seeing close messages about
> all of them.

Ah. I hadn't gone delving into the details of the bugs, so I was just 
going by bug titles.

[toc] | [prev] | [next] | [standalone]

#178823

Martin Read <zen75502@zen.co.uk> wrote:
> On 13/03/17 19:30, Patrick Bartek wrote:

>> The Linux mantra has always been "choice," plethoras of choices. So
>> why at install time, is there no choice for the init system?

> Looking at the BTS page for package 'debian-installer', nobody seems
> to have filed a wishlist bug requesting this feature.

> This seems like at least a contributory reason.

Besides there are already solutions with pre-seeding to install
sysv-init instead of systemd.

Those really wanting an installation medium with systemd can easily
modify the existing ones to do just that instead of requiring that the
Debian Developers do this for them.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#178819

I can´t understand this Discussion, as Normal user I even had not known that there are
more than one Init System (SystemV) and I don´t think that this should be chooseable. The
Installation is complicated enough dont make it more complex by adding choices which no
one understands.

By the way I am using Linux since 20Years. For me personally there is no Problem in
Installing another Init after Installation Therefore I don´t think it is needed as long
everything is running fine. I am using systemd and beeing perfectly happy with it had only
to do with it one time as I configured on access scan with clamd what is  not the most
important thing too I think.

Please end this Diskussion and get on with important things.

Am 13.03.2017 um 20:40 schrieb Patrick Bartek:
> The Linux mantra has always been "choice," plethoras of choices. So why
> at install time, is there no choice for the init system?  You get what
> the developers decide. Yes, you can install a new one -- I've done it
> and it works -- but only after the install.  It'd be a lot easier, if
> there were a choice to begin with just like whether you want a GUI and
> which one.
>
> Now, I know with LFS, you get to choose everything, etc.  But is a
> choice of init at install time so outrageous that no one ever
> considered it or is it technically unfeasible or something else.
>
> Just curious.
>
> B
Till then,

-- 

-=============================== Jan-Peter Rühmann & Kuma ===============================-
 Gubkower Str.7               [  Tel.:  +49 (38205) 65484  ]       jan-Peter@ruehmann.name
 18195 Prangendorf            [  FAX:   +49 (38205) 65212  ]      http://www.ruehmann.name
                              [  Tel.:  +49 (38205) 65215  ]
                              [  Mobil: +49 (162) 1316054  ]           IT-Servicetechniker
Skype: jan-peter_ruehmann / ICQ: 288192920 / WhatsApp: 491621316054 / Twitter: @JPRuehmann
-========================================================================================-
                  Die Verwendung der Daten zu Werbezwecken ist verboten.

[toc] | [prev] | [next] | [standalone]

#178859

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 13, 2017 at 12:30:11PM -0700, Patrick Bartek wrote:
> The Linux mantra has always been "choice," plethoras of choices. So why
> at install time, is there no choice for the init system?  You get what
> the developers decide. Yes, you can install a new one -- I've done it
> and it works -- but only after the install.  It'd be a lot easier, if
> there were a choice to begin with just like whether you want a GUI and
> which one.

Adding more options to the installer is not free: it's at a cost of complexity
for the installer code-base, complexity and length for users selecting options
when they install and risks confusion for users who aren't familiar with the
background and might not know what choice to make. When weighing up whether to
add a question or not, the developers need to take all that into consideration.
For something like the init system, the vast majority of users will either be
happy with the default, or simply not care. I think it makes sense the way
things are.

For advanced users, asides from using pre-seeding as someone else has
mentioned, with the 'expert mode' installer you have the option for manual
package selection; so you can use that to set things as you want them during
the install.

Everyone gets their cake and can eat it!

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#179678

On Mon, Mar 13, 2017 at 12:30:11PM -0700, Patrick Bartek wrote:
> The Linux mantra has always been "choice," plethoras of choices. So why
> at install time, is there no choice for the init system?  You get what
> the developers decide. Yes, you can install a new one -- I've done it
> and it works -- but only after the install.  It'd be a lot easier, if
> there were a choice to begin with just like whether you want a GUI and
> which one.
> 
> Now, I know with LFS, you get to choose everything, etc.  But is a
> choice of init at install time so outrageous that no one ever
> considered it or is it technically unfeasible or something else.
> 
> Just curious.

Some interesting links:
http://islinuxaboutchoice.com/

https://www.reddit.com/r/linux/comments/4hutww/is_linux_about_choice/

http://pusling.com/blog/?p=366

https://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/

OK, sure, they're the first 4 hits in a google search but they *are*
interesting. :)

-- 
The media's the most powerful entity on earth. 
They have the power to make the innocent guilty 
and to make the guilty innocent, and that's power.
 -- Malcolm X

[toc] | [prev] | [next] | [standalone]

#179704

On Sun, 2 Apr 2017 00:42:00 +1300 cbannister@slingshot.co.nz wrote:

> On Mon, Mar 13, 2017 at 12:30:11PM -0700, Patrick Bartek wrote:
> > The Linux mantra has always been "choice," plethoras of choices. So
> > why at install time, is there no choice for the init system?  You
> > get what the developers decide. Yes, you can install a new one --
> > I've done it and it works -- but only after the install.  It'd be a
> > lot easier, if there were a choice to begin with just like whether
> > you want a GUI and which one.
> > 
> > Now, I know with LFS, you get to choose everything, etc.  But is a
> > choice of init at install time so outrageous that no one ever
> > considered it or is it technically unfeasible or something else.
> > 
> > Just curious.
> 
> Some interesting links:
> http://islinuxaboutchoice.com/
> 
> https://www.reddit.com/r/linux/comments/4hutww/is_linux_about_choice/
> 
> http://pusling.com/blog/?p=366
> 
> https://blogs.gnome.org/hughsie/2009/09/23/linux-is-about-choice/
> 
> OK, sure, they're the first 4 hits in a google search but they *are*
> interesting. :)

Never came across those during my research before posting my initial
query here.  And I read a lot of articles.  Still have found nothing
stating exactly why Linux distros don't offer a choice of inits during
install, even in "expert" mode.  You can choose just about
everything else.  I doubt that particular option was even considered.

Thanks for your reply.

B

[toc] | [prev] | [next] | [standalone]

#179705

[Multipart message — attachments visible in raw view] — view raw

Sent from my iPad
> On Apr 1, 2017, at 7:30 PM, Patrick Bartek <nemommxiv@gmail.com> wrote:
> 
> Never came across those during my research before posting my initial
> query here.  And I read a lot of articles.  Still have found nothing
> stating exactly why Linux distros don't offer a choice of inits during
> install, even in "expert" mode.  You can choose just about
> everything else.  I doubt that particular option was even considered.
> 
The Debian page: https://wiki.debian.org/Debate/initsystem/systemd
does a pretty good job of explaining the reasons for the switch.

My best guess as to the lack of an init system choice would be the huge
ripple effect on documentation, making it harder to document Debian when 
the user may be using either a sysvinit shell script or a systemd utility. Not
to mention the added developer time of maintaining two init systems. 

Choices in things like appearance, aptitude vs. Synaptic, Blackbox vs. Gnome
do not effect how the system itself operates, but the init system does.

YMMV

Cathy

[toc] | [prev] | [next] | [standalone]

#179722

[Multipart message — attachments visible in raw view] — view raw

On 2017-04-01 at 20:08, Catherine Gramze wrote:

>> On Apr 1, 2017, at 7:30 PM, Patrick Bartek <nemommxiv@gmail.com>
>> wrote:
>> 
>> Never came across those during my research before posting my
>> initial query here.  And I read a lot of articles.  Still have
>> found nothing stating exactly why Linux distros don't offer a
>> choice of inits during install, even in "expert" mode.  You can
>> choose just about everything else.  I doubt that particular option
>> was even considered.
> 
> The Debian page: https://wiki.debian.org/Debate/initsystem/systemd 
> does a pretty good job of explaining the reasons for the switch.
> 
> My best guess as to the lack of an init system choice would be the
> huge ripple effect on documentation, making it harder to document
> Debian when the user may be using either a sysvinit shell script or a
> systemd utility. Not to mention the added developer time of
> maintaining two init systems.

Eh? You *do* have a choice of which init system to run; many people
running Debian are still using sysvinit, myself included. The system
handles this just fine; if you file a bug report via e.g. reportbug, it
will automatically detect which init system you're running and include
that information in the bug report.

What you don't have is a choice *in the installer* of which init system
to *start out with*. The installer will always set up systemd (possible
unusual situations involving preseeding aside); if you want sysvinit
instead, you have to break out of the do-things-for-you friendly install
process and do some package installs + uninstalls by hand.

This makes it harder for people to get a non-systemd init system in
place (particularly people with less technical experience), and harder
to be sure that all traces of systemd-used-as-init-system have really
been removed from the machine.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#179724

On 4/3/2017 4:01 AM, The Wanderer wrote:
> Eh? You *do* have a choice of which init system to run; many people
> running Debian are still using sysvinit, myself included. The system
> handles this just fine; if you file a bug report via e.g. reportbug, it
> will automatically detect which init system you're running and include
> that information in the bug report.
>
> What you don't have is a choice *in the installer* of which init system
> to *start out with*. The installer will always set up systemd (possible
> unusual situations involving preseeding aside); if you want sysvinit
> instead, you have to break out of the do-things-for-you friendly install
> process and do some package installs + uninstalls by hand.
>
> This makes it harder for people to get a non-systemd init system in
> place (particularly people with less technical experience), and harder
> to be sure that all traces of systemd-used-as-init-system have really
> been removed from the machine.
Would you be willing to share the steps you use to change to sysvinit on 
a newly installed machine?

Thanks!
Rick

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web