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

Groups > comp.os.linux.misc > #13117 > unrolled thread

Devuan

Back to article view | Back to comp.os.linux.misc

Contents

  Devuan Mladen Gogala <gogala.mladen@gmail.com> - 2014-12-29 17:13 +0000
    Re: Devuan Aragorn <thorongil@telenet.be.invalid> - 2014-12-29 18:32 +0100
      Re: Devuan Grant <omg@grrr.id.au> - 2014-12-30 05:23 +1100
      Re: Devuan Michael Black <et472@ncf.ca> - 2014-12-29 13:55 -0500
      Re: Devuan Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2014-12-29 19:28 +0000
        Re: Devuan Grant <omg@grrr.id.au> - 2014-12-30 07:25 +1100
          Re: Devuan "John F" <j@j.ii> - 2014-12-29 13:42 -0800
            Re: Devuan Grant <omg@grrr.id.au> - 2014-12-30 09:32 +1100
              Re: Devuan Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2014-12-29 14:57 -0800
                Re: Devuan "John F" <j@j.ii> - 2014-12-30 16:37 -0800
                  Re: Devuan Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2014-12-30 18:23 -0800
                  Re: Devuan notbob <notbob@nothome.com> - 2014-12-31 17:57 +0000
                    Re: Devuan Rich <rich@example.invalid> - 2014-12-31 19:07 +0000
                      Re: Devuan Grant <omg@grrr.id.au> - 2015-01-01 08:25 +1100
                      Re: Devuan Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-01-01 10:56 +0100
                        Re: Devuan Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2015-01-01 05:02 -0800
                          Re: Devuan John Hasler <jhasler@newsguy.com> - 2015-01-01 08:49 -0600
                            Re: Devuan Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-01-01 16:43 +0100
                            Re: Devuan notbob <notbob@nothome.com> - 2015-01-01 16:12 +0000
                              Re: Devuan Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-01-01 18:23 +0100
                                Re: Devuan notbob <notbob@nothome.com> - 2015-01-01 18:11 +0000
                                  Re: Devuan Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-01-01 22:05 +0100
                              Re: Devuan Grant <omg@grrr.id.au> - 2015-01-02 06:09 +1100
                            Re: Devuan Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-01-02 20:04 +0000
                              Re: Devuan notbob <notbob@nothome.com> - 2015-01-02 20:14 +0000
                                Re: Devuan Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2015-01-02 12:30 -0800
                                  Re: Devuan notbob <notbob@nothome.com> - 2015-01-02 21:31 +0000
                                    Re: Devuan Aragorn <thorongil@telenet.be.invalid> - 2015-01-03 08:03 +0100
                              Re: Devuan Michael Black <et472@ncf.ca> - 2015-01-02 15:35 -0500
                              Re: Devuan John Hasler <jhasler@newsguy.com> - 2015-01-02 14:37 -0600
                          Re: Devuan Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-01-01 16:42 +0100
                    Re: Devuan Dan Espen <despen@verizon.net> - 2014-12-31 16:30 -0500
                      Re: Devuan Mladen Gogala <gogala.mladen@gmail.com> - 2014-12-31 23:51 +0000
                        Re: Devuan Mladen Gogala <gogala.mladen@gmail.com> - 2014-12-31 23:55 +0000
                          Re: Devuan Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2014-12-31 16:49 -0800
                            Re: Devuan The Natural Philosopher <tnp@invalid.invalid> - 2015-01-01 01:50 +0000
                              Re: Devuan Dan Espen <despen@verizon.net> - 2014-12-31 22:03 -0500
                                Re: Devuan The Natural Philosopher <tnp@invalid.invalid> - 2015-01-01 08:46 +0000
                                  Re: Devuan Dan Espen <despen@verizon.net> - 2015-01-01 10:15 -0500
                                    Re: Devuan The Natural Philosopher <tnp@invalid.invalid> - 2015-01-01 16:01 +0000
                                    Re: Devuan William Unruh <unruh@invalid.ca> - 2015-01-01 16:40 +0000
                                      Re: Devuan Richard Kettlewell <rjk@greenend.org.uk> - 2015-01-01 17:00 +0000
                                        Re: Devuan William Unruh <unruh@invalid.ca> - 2015-01-01 17:08 +0000
                                          Re: Devuan Richard Kettlewell <rjk@greenend.org.uk> - 2015-01-01 17:35 +0000
                                      Re: Devuan Dan Espen <despen@verizon.net> - 2015-01-01 12:09 -0500
                                        Re: Devuan William Unruh <unruh@invalid.ca> - 2015-01-01 17:22 +0000
                                          Re: Devuan Dan Espen <despen@verizon.net> - 2015-01-01 13:17 -0500
                                      Re: Devuan Grant <omg@grrr.id.au> - 2015-01-02 06:14 +1100
                                        Re: Devuan Robert Riches <spamtrap42@jacob21819.net> - 2015-01-03 05:27 +0000
                                          Re: Devuan Aragorn <thorongil@telenet.be.invalid> - 2015-01-03 08:10 +0100
                                            Re: Devuan William Unruh <unruh@invalid.ca> - 2015-01-03 09:16 +0000
                                              Re: Devuan Aragorn <thorongil@telenet.be.invalid> - 2015-01-03 10:37 +0100
                                    Re: Devuan Grant <omg@grrr.id.au> - 2015-01-02 06:11 +1100
                                Re: Devuan Richard Kettlewell <rjk@greenend.org.uk> - 2015-01-01 15:23 +0000
                                  Re: Devuan Robert Riches <spamtrap42@jacob21819.net> - 2015-01-03 05:29 +0000
                                    Re: Devuan Richard Kettlewell <rjk@greenend.org.uk> - 2015-01-03 09:14 +0000
                  Re: Devuan Stephen Chadfield <stephen@chadfield.com> - 2015-01-05 02:33 +0000
                  Re: Devuan "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-02-09 16:57 -0500
              Re: Devuan "J. Clarke" <j.clarke.873638@gmail.com> - 2015-03-08 09:08 -0400
        Re: Devuan Aragorn <thorongil@telenet.be.invalid> - 2014-12-30 09:13 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#13164

On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 01/01/15 03:03, Dan Espen wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>
>>>> On 01/01/15 00:49, Keith Keller wrote:
>>>>> On 2014-12-31, Mladen Gogala <gogala.mladen@gmail.com> wrote:
>>>>>>
>>>>>> BTW, HatRed seems to plan doing the same thing with Wayward instead of
>>>>>> X11.
>>>>>
>>>>> It's hard (though not impossible) to imagine anything replacing X11
>>>>> could be worse than X11.
>>>>>
>>>>
>>>> It is surely a challenge, but I am sure they are up to it....
>>>
>>> Unlike systemd, which can do everything init does,
>>> Wayland is advertised to be missing a network protocol.
>>>
>>> You can do something like VNC, but not remote windows.
>>>
>>> So, with Wayland, there is a REAL issue.
>>> One that actually affects real people.
>>>
>> well that is not an issue in fact, its just moving the network
>> awareness of the GUI up the stack a little.
>
> Huh?
>
> You are telling me having an Emacs window from work on my home system is
> just the same as having a desktop with an Emacs window?
>
> I beg to differ.
>
>> I'd be delighted to ditch X - after 5 years of bug eradication in any
>> alternative.
>
> X11 has been working fine here.  I don't have a single issue
> I'd like changed.  The only issue I ever hear the Wayland
> developers claim that they are going to fix is "tearing".
>
> I've never seen this "tearing" that they talk  about.
>
>> 99% of the applications use less than 1% of its features.
>
> As it should be.
>
> If that is  supposed to justify removing a critical
> feature, I can't agree.
>
> In this case we have:
>
> systemd vs. init - No perceptible difference.

You mean no difference you have perceived. 
Here are a few
-- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
cannot user /tmp as a repostitory for temporary files, since any
shutdown or crash will destroy them. 
-- If one of your partitions fails for whatever reason the system will
refuse to boot. If you are lucky it will drop you into a "rescue" shell.
If not (and systemd is buggy so this is a strong possibility" you will
get a black screen of death. YOU must put a "nofail" into every line of
your /etc/fstab to prevent this, and then you get no warning that one of
your partitions has failed to mount. 
Are thos important features? 

> X11 vs. Wayland - Clear difference and  lack of an important feature.
>

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

#13165

William Unruh <unruh@invalid.ca> writes:
> On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
>> In this case we have:
>>
>> systemd vs. init - No perceptible difference.
>
> You mean no difference you have perceived. 
> Here are a few
> -- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
> cannot user /tmp as a repostitory for temporary files, since any
> shutdown or crash will destroy them. 

No, systemd does not force you to have /tmp on tmpfs.

-- 
http://www.greenend.org.uk/rjk/

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

#13166

On 2015-01-01, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
>>> In this case we have:
>>>
>>> systemd vs. init - No perceptible difference.
>>
>> You mean no difference you have perceived. 
>> Here are a few
>> -- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
>> cannot user /tmp as a repostitory for temporary files, since any
>> shutdown or crash will destroy them. 
>
> No, systemd does not force you to have /tmp on tmpfs.

More or less. You cannot disable that. It does not work. You can mask it
systemctl mask tmp.mount 
which is hardly something most people could figure out how to do (or
understand the difference between mask and disable). So I stand by
"forced".
And I used the term "disable" very deliberately. You cannot disable it.
You can mask it. 

>

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

#13170

William Unruh <unruh@invalid.ca> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> -- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
>>> cannot user /tmp as a repostitory for temporary files, since any
>>> shutdown or crash will destroy them. 
>>
>> No, systemd does not force you to have /tmp on tmpfs.
>
> More or less. You cannot disable that. It does not work.

I can, I have, it works fine.

  # mount | grep /tmp
  # systemctl status tmp.mount
  ● tmp.mount - Temporary Directory
     Loaded: loaded (/lib/systemd/system/tmp.mount; disabled)
     Active: inactive (dead)
      Where: /tmp
       What: tmpfs
       Docs: man:hier(7)
             http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

-- 
http://www.greenend.org.uk/rjk/

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

#13167

William Unruh <unruh@invalid.ca> writes:

> On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 01/01/15 03:03, Dan Espen wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>
>>>>> On 01/01/15 00:49, Keith Keller wrote:
>>>>>> On 2014-12-31, Mladen Gogala <gogala.mladen@gmail.com> wrote:
>>>>>>>
>>>>>>> BTW, HatRed seems to plan doing the same thing with Wayward instead of
>>>>>>> X11.
>>>>>>
>>>>>> It's hard (though not impossible) to imagine anything replacing X11
>>>>>> could be worse than X11.
>>>>>>
>>>>>
>>>>> It is surely a challenge, but I am sure they are up to it....
>>>>
>>>> Unlike systemd, which can do everything init does,
>>>> Wayland is advertised to be missing a network protocol.
>>>>
>>>> You can do something like VNC, but not remote windows.
>>>>
>>>> So, with Wayland, there is a REAL issue.
>>>> One that actually affects real people.
>>>>
>>> well that is not an issue in fact, its just moving the network
>>> awareness of the GUI up the stack a little.
>>
>> Huh?
>>
>> You are telling me having an Emacs window from work on my home system is
>> just the same as having a desktop with an Emacs window?
>>
>> I beg to differ.
>>
>>> I'd be delighted to ditch X - after 5 years of bug eradication in any
>>> alternative.
>>
>> X11 has been working fine here.  I don't have a single issue
>> I'd like changed.  The only issue I ever hear the Wayland
>> developers claim that they are going to fix is "tearing".
>>
>> I've never seen this "tearing" that they talk  about.
>>
>>> 99% of the applications use less than 1% of its features.
>>
>> As it should be.
>>
>> If that is  supposed to justify removing a critical
>> feature, I can't agree.
>>
>> In this case we have:
>>
>> systemd vs. init - No perceptible difference.
>
> You mean no difference you have perceived. 
> Here are a few
> -- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
> cannot user /tmp as a repostitory for temporary files, since any
> shutdown or crash will destroy them. 

My Fedora system used tmpfs before the advent of systemd.
I can't see how the 2 things are tied together.
I don't put stuff I intend to keep in /tmp.  /var/tmp works fine for that.
How hard could it be to mount /tmp on disk?
Also used a tmpfs type /tmp on Solaris for years.
Got me used to the way it looses stuff and sort of like it.

> -- If one of your partitions fails for whatever reason the system will
> refuse to boot. If you are lucky it will drop you into a "rescue" shell.
> If not (and systemd is buggy so this is a strong possibility" you will
> get a black screen of death. YOU must put a "nofail" into every line of
> your /etc/fstab to prevent this, and then you get no warning that one of
> your partitions has failed to mount. 
> Are thos important features? 

As you say, put nofail in /etc/fstab.
Getting a warning should be simple enough if you need it.
I had a heat sensitive backup disk.
When it unmounted itself, I'd get warnings when cron tried to use it.
Not  a big problem.

I seem to remember having the same "can't boot" issues before systemd.

-- 
Dan Espen

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

#13168

On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
> William Unruh <unruh@invalid.ca> writes:
>
>> On 2015-01-01, Dan Espen <despen@verizon.net> wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
....
>>> systemd vs. init - No perceptible difference.
>>
>> You mean no difference you have perceived. 
>> Here are a few
>> -- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
>> cannot user /tmp as a repostitory for temporary files, since any
>> shutdown or crash will destroy them. 
>
> My Fedora system used tmpfs before the advent of systemd.

Yes, which is why systemd forced it on people. 

> I can't see how the 2 things are tied together.

I never said that before systemd one could, in /etc/fstab, tell the
system to use tmpfs for /tmp. It was in one, very obvious and
traditional place. Now it was transfered to systemd, and is the default
in the bowels of systemd and is hard to figure out how to get rid of it.
You cannot disable it (systemctl disable tmp.mount does not work). 

> I don't put stuff I intend to keep in /tmp.  /var/tmp works fine for that.

As always with Linux, one of its strengths is that one can easily make
it do what  you want it to do, not necessarily what others want. You
might like /tmp to be tmpfs, and take up ram. Others may want the
permanance over boots of /tmp. It used to be easy. Now you have to dig
to figure out that tmp.mount is the systemd item that controls this, and
that you cannot disable it, you must mask it. (or put
a link from /etc/systemd/system/tmp.mount to /dev/null)
I simple configuration is no longer in a file which deals with mounting
things, it is lost in a thicket of other stuff. 


> How hard could it be to mount /tmp on disk?

Precisely.

> Also used a tmpfs type /tmp on Solaris for years.
> Got me used to the way it looses stuff and sort of like it.

Fine. Noone is disputing your right to have things your way. 

>
>> -- If one of your partitions fails for whatever reason the system will
>> refuse to boot. If you are lucky it will drop you into a "rescue" shell.
>> If not (and systemd is buggy so this is a strong possibility" you will
>> get a black screen of death. YOU must put a "nofail" into every line of
>> your /etc/fstab to prevent this, and then you get no warning that one of
>> your partitions has failed to mount. 
>> Are thos important features? 
>
> As you say, put nofail in /etc/fstab.
> Getting a warning should be simple enough if you need it.

No. 

> I had a heat sensitive backup disk.
> When it unmounted itself, I'd get warnings when cron tried to use it.

And if you had it listed in /etc/fstab, and you tried to boot, that boot
would fail. A boot should NOT fail for a failed mount, unless it were
mounting the / partition. 
I have no idea how you do backups. If you do rsync, it will create the
path for you. thus when your backup disk is not mounted on /backup, say,
rsync will create the backup tree on /backup, which is now part of your
/ partition, and raplidly fill it up, as root (so no spare room left)
and suddenly your system is unseable. Ie, no warnings are certainly an
inconvenience. 


> Not  a big problem.

For you  again. You are not the world. 

>
> I seem to remember having the same "can't boot" issues before systemd.
>

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

#13172

William Unruh <unruh@invalid.ca> writes:

> I have no idea how you do backups. If you do rsync, it will create the
> path for you. thus when your backup disk is not mounted on /backup, say,
> rsync will create the backup tree on /backup, which is now part of your
> / partition, and raplidly fill it up, as root (so no spare room left)
> and suddenly your system is unseable. Ie, no warnings are certainly an
> inconvenience. 

On the contrary.

I do use rsync.
I rsync $HOME as a user, not root.
When /back isn't mounted, the rsync fails.

If I was backing up as root, it  would be an error
in my script if I didn't check that status of /back.

-- 
Dan Espen

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

#13175

On Thu, 1 Jan 2015 16:40:28 +0000 (UTC), William Unruh <unruh@invalid.ca> wrote:

...
>You mean no difference you have perceived. 
>Here are a few
>-- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
>cannot user /tmp as a repostitory for temporary files, since any
>shutdown or crash will destroy them. 

Since when were files in /tmp meant to survive reboot?  If you have 
important work in progress, store it in the main filesystem, not the 
scratch memory, it's volatile.

Grant.

>-- If one of your partitions fails for whatever reason the system will
>refuse to boot. If you are lucky it will drop you into a "rescue" shell.
>If not (and systemd is buggy so this is a strong possibility" you will
>get a black screen of death. YOU must put a "nofail" into every line of
>your /etc/fstab to prevent this, and then you get no warning that one of
>your partitions has failed to mount. 
>Are thos important features? 
>
>> X11 vs. Wayland - Clear difference and  lack of an important feature.
>>

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

#13189

On 2015-01-01, Grant <omg@grrr.id.au> wrote:
> On Thu, 1 Jan 2015 16:40:28 +0000 (UTC), William Unruh <unruh@invalid.ca> wrote:
>
> ...
>>You mean no difference you have perceived. 
>>Here are a few
>>-- /tmp is now a tmpfs file, forced. You cannot disable it. Thus you
>>cannot user /tmp as a repostitory for temporary files, since any
>>shutdown or crash will destroy them. 
>
> Since when were files in /tmp meant to survive reboot?  If you have 
> important work in progress, store it in the main filesystem, not the 
> scratch memory, it's volatile.
>
> Grant.

Thank you for asking the question:

Since the mid-1980s on every Unix/Linux system I have used from
then until now, /tmp has been a filesystem on spinning rust--or
maybe SSD in the past few years.  When you say "main filesystem",
which one are you referring to on the Unix machines I have used
that had a separate physical disk and filesystem for at least a
few of /, /usr, /tmp, and /var--not to mention in the old days
/a, /b, /c, and so forth for home directories for the many users
on the system (VAX department development server).

If you want /tmp to be volatile, that's fine; have it your way.
Others don't want it to be volatile.  I seem to recall reading
that it can be done with systemd, but I have not tested it
myself.

At the time my first systemd-based Mageia 2 test VM hung for
several minutes on first boot and then came up with about half
the RAIDs not formed and the system in a very crippled state, I
decided I would not voluntarily use systemd on systems under my
control if there was any other acceptable solution.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

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

#13192

On Saturday 03 January 2015 06:27, Robert Riches conveyed the following 
to comp.os.linux.misc...

> [...] If you want /tmp to be volatile, that's fine; have it your way.
> Others don't want it to be volatile.

According to the Filesystem Hierarchy Standard version 2.3...

[QUOTE]

 Purpose

  The /tmp directory must be made available for programs that require
  temporary files.

  Programs must not assume that any files or directories in /tmp are
  preserved between invocations of the program.

 Rationale
 	
  IEEE standard P1003.2 (POSIX, part 2) makes requirements that are
  similar to the above section.

  Although data stored in /tmp may be deleted in a site-specific manner,
  it is recommended that files and directories located in /tmp be
  deleted whenever the system is booted.

  FHS added this recommendation on the basis of historical precedent and
  common practice, but did not make it a requirement because system
  administration is not within the scope of this standard. 

[/QUOTE]

> I seem to recall reading that it can be done with systemd, but I have
> not tested it myself.

systemd does support not using a tmpfs for /tmp, yes.

> [...] I decided I would not voluntarily use systemd on systems under
> my control if there was any other acceptable solution.

I share that sentiment.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13195

On 2015-01-03, Aragorn <thorongil@telenet.be.invalid> wrote:
> On Saturday 03 January 2015 06:27, Robert Riches conveyed the following 
> to comp.os.linux.misc...
>
>> [...] If you want /tmp to be volatile, that's fine; have it your way.
>> Others don't want it to be volatile.
>
> According to the Filesystem Hierarchy Standard version 2.3...
>
> [QUOTE]
>
>  Purpose
>
>   The /tmp directory must be made available for programs that require
>   temporary files.
>
>   Programs must not assume that any files or directories in /tmp are
>   preserved between invocations of the program.
>
>  Rationale
>  	
>   IEEE standard P1003.2 (POSIX, part 2) makes requirements that are
>   similar to the above section.
>
>   Although data stored in /tmp may be deleted in a site-specific manner,
>   it is recommended that files and directories located in /tmp be
>   deleted whenever the system is booted.
>
>   FHS added this recommendation on the basis of historical precedent and
>   common practice, but did not make it a requirement because system
>   administration is not within the scope of this standard. 

And the FSHS is honoured more in the breach than in the observance. As
they say, system administration is not within the scope of this
standard. And many people use /tmp as a scratch that in general is
preserved over reboots. But no guarentees. 

>
> [/QUOTE]
>
>> I seem to recall reading that it can be done with systemd, but I have
>> not tested it myself.
>
> systemd does support not using a tmpfs for /tmp, yes.

It does however make it hard to do so. As I said, trying to disable that
(systemctl disable tmp.mount)
does not work. You must do 
systemctl mask tmp.mount
or 
ln -s /dev/null /etc/systemd/system/tmp.mount
will manage not to have /tmp be /tmpfs. Why not just allow disable as
with most other services? Well, it is either a bug of Poettinger
involving himself in system administration .

>
>> [...] I decided I would not voluntarily use systemd on systems under
>> my control if there was any other acceptable solution.
>
> I share that sentiment.
>
Unfortunately I like the rest of Mageia too much. Does not mean systemd
does not annoy me, and the bugs ( which are all features, not bugs) keep
wasting my time.  Why in the world should I have to dig into the bowels
of systemd to find out that I have to mask, not disable /tmp as tmpfs?
Why do Ihave to waste hours because systemd decides that if it cannot
mount a partition it will give up on the whole boot, unless the stupidly
named nofail option is used? (that was 4 hours of my life).

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

#13196

On Saturday 03 January 2015 10:16, William Unruh conveyed the following 
to comp.os.linux.misc...

> On 2015-01-03, Aragorn <thorongil@telenet.be.invalid> wrote:
>
>> On Saturday 03 January 2015 06:27, Robert Riches conveyed the
>> following to comp.os.linux.misc...
>>
>>> [...] If you want /tmp to be volatile, that's fine; have it your
>>> way. Others don't want it to be volatile.
>>
>> According to the Filesystem Hierarchy Standard version 2.3...
>>
>> [QUOTE]
>>
>>  Purpose
>>
>>   The /tmp directory must be made available for programs that require
>>   temporary files.
>>
>>   Programs must not assume that any files or directories in /tmp are
>>   preserved between invocations of the program.
>>
>>  Rationale
>>  
>>   IEEE standard P1003.2 (POSIX, part 2) makes requirements that are
>>   similar to the above section.
>>
>>   Although data stored in /tmp may be deleted in a site-specific
>>   manner, it is recommended that files and directories located in
>>   /tmp be deleted whenever the system is booted.
>>
>>   FHS added this recommendation on the basis of historical precedent
>>   and common practice, but did not make it a requirement because
>>   system administration is not within the scope of this standard.
>>
>> [/QUOTE]
> 
> And the FSHS is honoured more in the breach than in the observance. As
> they say, system administration is not within the scope of this
> standard. And many people use /tmp as a scratch that in general is
> preserved over reboots. But no guarentees.

Historically, the reason why most people started using /tmp is actually 
because they were trying to circumvent the quota on their $HOME 
directories.

Anyone who wants a scratch directory can always create a $HOME/tmp.  
Most distributions create one by default upon installation, even, by 
having it listed in /etc/skel.

 [localhost:/dev/pts/0][/home/aragorn]
 [10:29:54][aragorn] $ ll -A /etc/skel
 total 28
 -rw-r--r--   1 root root   24 May  9  2011 .bash_logout
 -rw-r--r--   1 root root  201 Nov  1  2011 .bash_profile
 -rw-r--r--   1 root root  134 Nov  1  2011 .bashrc
 drwxr-xr-x   2 root root    6 Sep 22  2011 .gnome2/
 drwxr-xr-x   2 root root    6 Sep 22  2011 .mozilla/
 -rw-r--r--   1 root root 3793 Jan  8  2011 .screenrc
 drwx------   2 root root    6 Jan 11  2011 tmp/

>>> I seem to recall reading that it can be done with systemd, but I
>>> have not tested it myself.
>>
>> systemd does support not using a tmpfs for /tmp, yes.
> 
> It does however make it hard to do so. As I said, trying to disable
> that (systemctl disable tmp.mount)
> does not work. You must do
> systemctl mask tmp.mount
> or
> ln -s /dev/null /etc/systemd/system/tmp.mount
> will manage not to have /tmp be /tmpfs. Why not just allow disable as
> with most other services? Well, it is either a bug of Poettinger
> involving himself in system administration .

I'm afraid that Lennart/Poettering/ and RedHat assume a far more pompous 
attitude than that, even.  Their goal is to prescribe what a GNU/Linux 
system should look like, and for RedHat to become the de facto leader ─ 
if not the only distribution left ─ of GNU/Linux development.

>>> [...] I decided I would not voluntarily use systemd on systems under
>>> my control if there was any other acceptable solution.
>>
>> I share that sentiment.
>>
> Unfortunately I like the rest of Mageia too much. Does not mean
> systemd does not annoy me, and the bugs ( which are all features, not
> bugs) keep wasting my time.  Why in the world should I have to dig
> into the bowels of systemd to find out that I have to mask, not
> disable /tmp as tmpfs? Why do Ihave to waste hours because systemd
> decides that if it cannot mount a partition it will give up on the
> whole boot, unless the stupidly named nofail option is used? (that was
> 4 hours of my life).

Mageia is a Mandriva spin-off.  So is PCLinuxOS, but unlike Mageia and 
Mandriva, PCLinuxOS is still using sysvinit.  

The initial look & feel of PCLinuxOS may be a little different from 
Mageia's or Mandriva's, but under the hood it's pretty much the same 
trusted environment.  You still get all the typical "draktools", 
including the mcc and msec.

PCLinuxOS is also a rolling release distro, and it uses .rpm packages in 
combination with Debian's package management system and its Synaptic 
front-end.  It only ships in the form of an installable live CD or live 
DVD, but once you choose to install the system, it's pretty much the 
same as Mageia and Mandriva... but without systemd. :-)

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#13174

On Thu, 01 Jan 2015 10:15:15 -0500, Dan Espen <despen@verizon.net> wrote:

...
>I'd like changed.  The only issue I ever hear the Wayland
>developers claim that they are going to fix is "tearing".

Them's the tears in their eyes, nobody understands them ;o)

Grant.
>
>I've never seen this "tearing" that they talk  about.
>
>> 99% of the applications use less than 1% of its features.
>
>As it should be.
>
>If that is  supposed to justify removing a critical
>feature, I can't agree.
>
>In this case we have:
>
>systemd vs. init - No perceptible difference.
>X11 vs. Wayland - Clear difference and  lack of an important feature.

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

#13159

Dan Espen <despen@verizon.net> writes:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 01/01/15 00:49, Keith Keller wrote:
>>> On 2014-12-31, Mladen Gogala <gogala.mladen@gmail.com> wrote:

>>>> BTW, HatRed seems to plan doing the same thing with Wayward instead
>>>> of X11.
>>>
>>> It's hard (though not impossible) to imagine anything replacing X11
>>> could be worse than X11.
>>
>> It is surely a challenge, but I am sure they are up to it....
>
> Unlike systemd, which can do everything init does,
> Wayland is advertised to be missing a network protocol.
>
> You can do something like VNC, but not remote windows.
>
> So, with Wayland, there is a REAL issue.
> One that actually affects real people.

Since an X server can render to Wayland surfaces, I’m not sure what the
complaint is here.

-- 
http://www.greenend.org.uk/rjk/

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

#13190

On 2015-01-01, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> Dan Espen <despen@verizon.net> writes:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> On 01/01/15 00:49, Keith Keller wrote:
>>>> On 2014-12-31, Mladen Gogala <gogala.mladen@gmail.com> wrote:
>
>>>>> BTW, HatRed seems to plan doing the same thing with Wayward instead
>>>>> of X11.
>>>>
>>>> It's hard (though not impossible) to imagine anything replacing X11
>>>> could be worse than X11.
>>>
>>> It is surely a challenge, but I am sure they are up to it....
>>
>> Unlike systemd, which can do everything init does,
>> Wayland is advertised to be missing a network protocol.
>>
>> You can do something like VNC, but not remote windows.
>>
>> So, with Wayland, there is a REAL issue.
>> One that actually affects real people.
>
> Since an X server can render to Wayland surfaces, I???m not sure what the
> complaint is here.

Can an arbitrary X client running remotely be made to display on Wayland
without requiring a whole X server to display to the Wayland surface?

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

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

#13194

Robert Riches <spamtrap42@jacob21819.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> Dan Espen <despen@verizon.net> writes:
>>> Unlike systemd, which can do everything init does,
>>> Wayland is advertised to be missing a network protocol.
>>>
>>> You can do something like VNC, but not remote windows.
>>>
>>> So, with Wayland, there is a REAL issue.
>>> One that actually affects real people.
>>
>> Since an X server can render to Wayland surfaces, I’m not sure what
>> the complaint is here.
>
> Can an arbitrary X client running remotely be made to display on
> Wayland without requiring a whole X server to display to the Wayland
> surface?

X clients always require a whole X server, by definition.

-- 
http://www.greenend.org.uk/rjk/

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

#13248

John F <j@j.ii> wrote:
> And that, my friend, is going to be the big problem! New users will not have 
> the opportunity to learn about config files and the way linux works;

The way Linux *used* to work. If it still worked that way they would be able to learn...

-- 
Stephen Chadfield

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

#13669

On Tue, 30 Dec 2014 19:37:01 -0500, John F <j@j.ii> wrote:

> And that, my friend, is going to be the big problem! New users will not have
> the opportunity to learn about config files and the way linux works; and how
> different it is from MessWindows - with systemd it seems to be heading that
> way. Almost like a registry, except in binary executable format. Where are
> the config files for it? there must be some!

The config files are text only, in /lib/systemd/system

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

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

#13984

In article <02l3aa58lpapn0au55a9b61kkgt7qmbldu@4ax.com>, omg@grrr.id.au 
says...
> 
> On Mon, 29 Dec 2014 13:42:43 -0800, "John F" <j@j.ii> wrote:
> 
> >
> >"Grant" <omg@grrr.id.au> wrote in message 
> >news:14e3aadmjhov6stqo7s6fr0t48baf0k3ep@4ax.com...
> >> On Mon, 29 Dec 2014 19:28:32 +0000 (UTC), Jens Stuckelberger 
> >> <Jens_Stuckelberger@nowhere.net> wrote:
> >>
> >>>On Mon, 29 Dec 2014 18:32:55 +0100, Aragorn wrote:
> >>>
> >>>> On Monday 29 December 2014 18:13, Mladen Gogala conveyed the following
> >>>> to comp.os.linux.misc...
> >>>>
> >>>>> Finally:
> >>>>>
> >>>>> http://debianfork.org
> >>>>>
> >>>>> Death to systemd, may it burn in the depths of cvs!
> >>>>
> >>>> I'm pretty sure HatRed is going to keep it alive, though. :grin:
> >>>
> >>> Is it official then that Red Hat is evil and despicable? I
> >>>haven't liked them myself for a decade or so, but I still thought they
> >>>might not be utterly evil. The systemd fracas though has put them, in my
> >>>books, only slightly above Microsoft.
> >>
> >> Too right.  I left redhat when they stuffed 6.2 and failed to improve.
> >>
> >> Becoming a fedora redhat beta tester was not appealing.
> >>
> >> Grant.
> >
> >Unfortunately that seems to be what is happening (some linii are becoming 
> >more like  Microsoft)  I think systemd has too much control - could lead to 
> >easy hacking if someone took control of it from outside, too many eggs in 
> >one basket 
> >
> Yep.  Back in mid-2004 when I got ADSL switched on, I refused to 
> let Microsoft have 24/7 access directly to the 'net.  
> 
> Prior to ADSL I was using dialup, though mostly to my uni's server 
> as I had free access.
> 
> So I surveyed several Linux distros, chose slackware because it 
> felt closest to the unix I met at uni.  A friend was on Slackware 
> at the time, but he moved onto SuSE.
> 
> I like that people can choose a flavour of GNU/Linux to suit their 
> own ideas of using a computer.
> 
> I really dislike this new (last decade?) notion of people looking 
> for a free windows replacement.  
> 
> I like windows, I write this on windows, but right now I have 
> eight PuTTY terminals open the three Slackware boxen. 
> 
> This systemd stuff doesn't suit me.  As you say, too much a huge 
> point of failure.
> 
> I thought the same when Microsoft introduced the registry, was 
> hoping they'd fix windows and take out the registry in favour of 
> unix-like text configuration files.

Not gonna happen.  At this point the registry is too heavily embedded in 
their network administration system.  Taking it out would require that 
they rewrite an awful lot of code.

And network admins generally like it--it gives them a lot of control--
security on the registry isn't at the file level, it's at the line-item 
level.
 
> Even with config file we have this complexity of xml, I can't 
> help think that key-value pairs are all that is required, people 
> forgot their relational algebra and data normalisation?
> 
> Grant.

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

#13131

On Monday 29 December 2014 20:28, Jens Stuckelberger conveyed the 
following to comp.os.linux.misc...

> On Mon, 29 Dec 2014 18:32:55 +0100, Aragorn wrote:
> 
>> On Monday 29 December 2014 18:13, Mladen Gogala conveyed the
>> following to comp.os.linux.misc...
>> 
>>> Finally:
>>> 
>>> http://debianfork.org
>>> 
>>> Death to systemd, may it burn in the depths of cvs!
>> 
>> I'm pretty sure HatRed is going to keep it alive, though. :grin:
> 
> Is it official then that Red Hat is evil and despicable?

Well, I wouldn't put it that sharply ─ and certainly not yet on par with 
Oracle ─ but they are sufficiently evil and sufficiently despicable in 
my book, yes. ;-)

> I haven't liked them myself for a decade or so, but I still thought
> they might not be utterly evil. The systemd fracas though has put
> them, in my books, only slightly above Microsoft.

Or Google, for that matter. I'm inclined to agree, yes.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.os.linux.misc

csiph-web