* [bug#62584] [PATCH] services: Add error/success service type.
@ 2023-04-01 7:28 Ludovic Courtès
2023-04-01 10:34 ` 宋文武 via Guix-patches via
2023-04-27 3:53 ` Jakob Honal
0 siblings, 2 replies; 8+ messages in thread
From: Ludovic Courtès @ 2023-04-01 7:28 UTC (permalink / raw)
To: 62584; +Cc: Ludovic Courtès
* gnu/services/base.scm (error/success-boot-gexp): New procedure.
(error/success-service-type): New variable.
(%base-services): Add an instance of it.
* doc/guix.texi (Base Services): Document it.
---
doc/guix.texi | 26 ++++++++++++++++++++++++++
gnu/services/base.scm | 27 +++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
Hello Guix!
A while back, we committed a change that removed the boot-time
message we’d been seeing, “error in finalization thread: Success”:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=168a7933c0e138dc7061a3f0dc96871e16da5c5f
This change was not universally acclaimed. Some complained that
the boot process had seemingly become opaque because it’s now harder
to tell whether it’s making progress successfully, while others
were disappointed that their newly acquired sticker had become
obsolete.
This patch reinstates that message. The previous implementation
worked by closing a file descriptor that Guile relied on internally.
The new implementation takes a different approach, with the
error-reporting device implemented right into the service, which
should give us more flexibility—e.g., the service could be extended
to report other error codes.
The new ‘error/success-service-type’ is added to ‘%base-services’,
the default list of system services. I think it’s good to have it
by default, but that’s something we can discuss.
Feedback welcome!
Ludo’.
diff --git a/doc/guix.texi b/doc/guix.texi
index a58ea8f9ec..605ed648c4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -19007,6 +19007,32 @@ about the Pluggable Authentication Module (PAM) limits, refer to the
@samp{pam_limits} man page from the @code{linux-pam} package.
@end defvar
+@cindex success, and error (service type)
+@cindex error, and success (service type)
+
+@defvar error/success-service-type
+This is the service type for the iconic ``error in finalization thread:
+Success'' boot-time message that long-time Guix System users are
+familiar with. It is part of @code{%base-services} (enabled by
+default).
+
+New users who do not feel the need for this service can disable it by
+filtering it out of their service list. For instance, if you are using
+@code{%desktop-services}, you can change your operating system
+configuration like so (@pxref{Service Reference,
+@code{modify-services}}):
+
+@lisp
+(operating-system
+ ;; @dots{}
+ (services (modify-services %desktop-services
+ (delete error/success-service-type))))
+@end lisp
+
+However, we do not recommend it as you could lose sight of how weird and
+beautiful your system is.
+@end defvar
+
@defvar greetd-service-type
@uref{https://git.sr.ht/~kennylevinsen/greetd, @code{greetd}} is a minimal and
flexible login manager daemon, that makes no assumptions about what you
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index e063828d3b..5479cd63cf 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -248,6 +248,8 @@ (define-module (gnu services base)
pam-limits-service-type
pam-limits-service ; deprecated
+ error/success-service-type
+
greetd-service-type
greetd-configuration
greetd-terminal-configuration
@@ -2990,6 +2992,29 @@ (define %qemu-static-networking
(provision '(networking))
(name-servers '("10.0.2.3"))))
+\f
+;;;
+;;; The iconic error/success message service.
+;;;
+
+(define (error/success-boot-gexp _)
+ #~(begin
+ (display "error in finalization thread: Success\n"
+ (current-error-port))
+ (sleep 2))) ;let the user notice--all this hasn't been in vain
+
+(define error/success-service-type
+ (service-type
+ (name 'error/success)
+ (extensions
+ (list (service-extension boot-service-type
+ error/success-boot-gexp)))
+ (default-value 42)
+ (description
+ "This service prints the iconic error/success message at boot time. The
+message acts as a lighthouse for seasoned users--and seasoned users to
+be!--who immediately know, when they see it, that everything's alright.")))
+
\f
;;;
;;; greetd-service-type -- minimal and flexible login manager daemon
@@ -3364,6 +3389,8 @@ (define %base-services
(service sysctl-service-type)
+ (service error/success-service-type)
+
(service special-files-service-type
`(("/bin/sh" ,(file-append bash "/bin/sh"))
("/usr/bin/env" ,(file-append coreutils "/bin/env"))))))
--
2.39.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-01 7:28 [bug#62584] [PATCH] services: Add error/success service type Ludovic Courtès
@ 2023-04-01 10:34 ` 宋文武 via Guix-patches via
2023-04-01 16:51 ` Ludovic Courtès
2023-04-01 16:52 ` Ludovic Courtès
2023-04-27 3:53 ` Jakob Honal
1 sibling, 2 replies; 8+ messages in thread
From: 宋文武 via Guix-patches via @ 2023-04-01 10:34 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 62584
Ludovic Courtès <ludo@gnu.org> writes:
> I think it’s good to have it by default, but that’s something we can
> discuss.
Okay, I don't think so...
> +(define (error/success-boot-gexp _)
> + #~(begin
> + (display "error in finalization thread: Success\n"
> + (current-error-port))
> + (sleep 2))) ;let the user notice--all this hasn't been in vain
How about make the message and delay customable?
I prefer "No error in finalization thread: Success",
and 2 seconds may not be enough for a slow reader like me!
> +
> +(define error/success-service-type
> + (service-type
> + (name 'error/success)
> + (extensions
> + (list (service-extension boot-service-type
> + error/success-boot-gexp)))
> + (default-value 42)
What are this 42 is for?
Otherwise look good to me, thank you!
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-01 10:34 ` 宋文武 via Guix-patches via
@ 2023-04-01 16:51 ` Ludovic Courtès
2023-04-01 16:52 ` Ludovic Courtès
1 sibling, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2023-04-01 16:51 UTC (permalink / raw)
To: 宋文武; +Cc: 62584
Hi 宋文武,
宋文武 <iyzsong@envs.net> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> I think it’s good to have it by default, but that’s something we can
>> discuss.
>
> Okay, I don't think so...
Well, naming and defaults are two hard issues in programming.
>> +(define (error/success-boot-gexp _)
>> + #~(begin
>> + (display "error in finalization thread: Success\n"
>> + (current-error-port))
>> + (sleep 2))) ;let the user notice--all this hasn't been in vain
>
> How about make the message and delay customable?
>
> I prefer "No error in finalization thread: Success",
> and 2 seconds may not be enough for a slow reader like me!
Ah yes, good points! We could probably have a configuration record like
we do for other services. That way, one could write, say:
(service error/success-service-type
(error/success-configuration
(errno EINVAL)
(message-type 'no-error)
(delay 10)))
I’d prefer to leave that for a subsequent patch though, so we can first
restore the previous situation.
>> +(define error/success-service-type
>> + (service-type
>> + (name 'error/success)
>> + (extensions
>> + (list (service-extension boot-service-type
>> + error/success-boot-gexp)))
>> + (default-value 42)
>
> What are this 42 is for?
It’s currently unused but increases the chances that it’ll give the
right answer.
Thanks for your feedback!
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-01 10:34 ` 宋文武 via Guix-patches via
2023-04-01 16:51 ` Ludovic Courtès
@ 2023-04-01 16:52 ` Ludovic Courtès
2023-04-02 13:32 ` Ludovic Courtès
1 sibling, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2023-04-01 16:52 UTC (permalink / raw)
To: 宋文武; +Cc: 62584
BTW, I wrote about the rationale in more detail in a blog post:
https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-01 16:52 ` Ludovic Courtès
@ 2023-04-02 13:32 ` Ludovic Courtès
2023-04-03 9:48 ` 宋文武 via Guix-patches via
2023-04-04 10:59 ` Simon Tournier
0 siblings, 2 replies; 8+ messages in thread
From: Ludovic Courtès @ 2023-04-02 13:32 UTC (permalink / raw)
To: 宋文武; +Cc: 62584
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
> BTW, I wrote about the rationale in more detail in a blog post:
>
> https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/
In hindsight, seen from April 2nd, it seems that the status quo might be
preferable after all.
Closing!
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-02 13:32 ` Ludovic Courtès
@ 2023-04-03 9:48 ` 宋文武 via Guix-patches via
2023-04-04 10:59 ` Simon Tournier
1 sibling, 0 replies; 8+ messages in thread
From: 宋文武 via Guix-patches via @ 2023-04-03 9:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 62584
Ludovic Courtès <ludo@gnu.org> writes:
>> BTW, I wrote about the rationale in more detail in a blog post:
>>
>> https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/
A interesting story, thank you!
> In hindsight, seen from April 2nd, it seems that the status quo might be
> preferable after all.
>
> Closing!
Heh, I was asked by several people how to run a command/script
during (or at the end of) system booting, this service does seems a good
to place to satisfy that use case :)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type.
2023-04-02 13:32 ` Ludovic Courtès
2023-04-03 9:48 ` 宋文武 via Guix-patches via
@ 2023-04-04 10:59 ` Simon Tournier
1 sibling, 0 replies; 8+ messages in thread
From: Simon Tournier @ 2023-04-04 10:59 UTC (permalink / raw)
To: Ludovic Courtès, 宋文武; +Cc: 62584
Hi Ludo,
On Sun, 02 Apr 2023 at 15:32, Ludovic Courtès <ludo@gnu.org> wrote:
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> BTW, I wrote about the rationale in more detail in a blog post:
>>
>> https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/
>
> In hindsight, seen from April 2nd, it seems that the status quo might be
> preferable after all.
>
> Closing!
Well, I am not sure to understand if it is an April’s fool (so a good
one! ;-)) or a serious patch.
In both cases, I am missing why it would not be possible to have the
default “error = success“, since it is potentially possible to turn it
off and so have something as no error => success.
Emacs has ton of historical weird defaults. Basically, I do not see the
issue with such defaults if there is an explanation (in the manual,
say).
Cheers,
simon
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bug#62584] [PATCH] services: Add error/success service type
2023-04-01 7:28 [bug#62584] [PATCH] services: Add error/success service type Ludovic Courtès
2023-04-01 10:34 ` 宋文武 via Guix-patches via
@ 2023-04-27 3:53 ` Jakob Honal
1 sibling, 0 replies; 8+ messages in thread
From: Jakob Honal @ 2023-04-27 3:53 UTC (permalink / raw)
To: 62584
[-- Attachment #1: Type: text/html, Size: 976 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-04-27 13:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-01 7:28 [bug#62584] [PATCH] services: Add error/success service type Ludovic Courtès
2023-04-01 10:34 ` 宋文武 via Guix-patches via
2023-04-01 16:51 ` Ludovic Courtès
2023-04-01 16:52 ` Ludovic Courtès
2023-04-02 13:32 ` Ludovic Courtès
2023-04-03 9:48 ` 宋文武 via Guix-patches via
2023-04-04 10:59 ` Simon Tournier
2023-04-27 3:53 ` Jakob Honal
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.