FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 03-18-2012, 05:23 AM
Eric Bélanger
 
Default

On Sat, Mar 17, 2012 at 4:31 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-03-17 17:37:44 +0100] Thomas Bächler:
>> Am 17.03.2012 09:07, schrieb Arch Website Notification:
>> > == Incomplete signoffs for [core] (8 total) ==
>> > * lvm2-2.02.95-1 (i686)
>> > * * 1/2 signoffs
>>
>> We never get 2 i686 signoffs here (I already signed off after my test VM
>> booted). How do we handle user signoffs with the web-based solution?
>
> After a week or so, [testing] users would have opened bug reports if
> there were any issue; I'd say move it.
>
> --
> Gaetan

I was planning to move it to core later today (Sunday) as it has been
in testing for 4 days and not a lot of dev use it.
 
Old 03-18-2012, 06:28 AM
Canek Peláez Valdés
 
Default

On Sat, Mar 17, 2012 at 10:17 PM, Bruce Hill, Jr.
<daddy@happypenguincomputers.com> wrote:
>
>
>
> On March 17, 2012 at 10:57 PM "Canek Peláez Valdés" <caneko@gmail.com>
> wrote:
>
>> On Sat, Mar 17, 2012 at 8:48 PM, Bruce Hill, Jr.
>> <daddy@happypenguincomputers.com> wrote:
>> >
>> >
>> >
>> > On March 17, 2012 at 8:48 PM Nikos Chantziaras <realnc@gmail.com>
> wrote:
>> >
>> >> On 17/03/12 13:53, Alan Mackenzie wrote:
>> >> > Hello, Nikos.
>> >> >
>> >> > On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote:
>> >> >
>> >> >>> Happy Computer Users, systemd is on your horizon.
>> >> >
>> >> >> No, we don't. *I hope systemd arrives soon. *It's the best init
> system
>> > I
>> >> >> ever saw.
>> >> >
>> >> > What's so good about it? *What will it do for me?
>> >> >
>> >> > I have this horrible sneaking suspicion that it will be more
>> > complicated
>> >> > than /sbin/init + OpenRC, just like udev + initramfs is more
>> > complicated
>> >> > than udev, and CUPS is more complicated than classical lpr.
>> >> >
>> >> > Why do you find it so good?
>> >>
>> >> No idea. *I only posted this because the OP didn't say what's bad
> about
>> >> systemd :-) *I really don't know I should care whether my system runs
>> >> OpenRC or systemd.
>> >>
>> >>
>> >
>> >
>> > I'm the OP, and often I don't know how to express myself.
>> >
>> > It is my understanding that systemd is going to force an initramfs on
> you
>> > even if you only have / and no other partitions. (Could it be initrd
> and
>> > not initramfs?)
>> >
>> > I'm all for automounting a device when it's plugged in, if that's what
> the
>> > user chooses. But for me, with my workstation, laptop, wife's PC and
>> > daughter's laptop -- we just don't need or care for it. Seems a shame
> to be
>> > using udev and then have to completely change your system when 181
> comes
>> > out, or freeze it at .
>> >
>> > Therefore, we don't install anything to automount devices. We have
> lines
>> > such as these in fstab:
>> >
>> > UUID=6C5F-3742 * */Libby-Vivitar * vfat
>> > noauto,users,rw,gid=100,dmask=0002,fmask=0113 *0 0
>> >
>> > for those devices we own. When we get a new device, we add a new line.
>> >
>> > We don't use a DE either, just Fluxbox.
>> >
>> > The bottom line is that I don't like things being forced on me (hint,
> "get
>> > the vaseline, they're on the way!") And I don't like upstream forcing
> such
>> > nefarious changes on the distros. And for the Lennart fanboi, his
> coding is
>> > so questionable that "Lennartware" has become derogatory slang. (Of
> course,
>> > you already know that.)
>>
>> No need to get personal man, relax.
>
> I disagree ... there's every reason to get personal. Not getting personal
> doesn't assign the blame. Men stand up and take responsibility for their
> actions.

You called me "Lennart fanboi". That wasn't personal?

>> I'm getting my PhD in Computer Science
> <snip>
>
> I got my PhD in life before your parents met. So what? Just saying...

I'm not bragging; I just explained my credentials as to why I say that
Lennart's code is actually quite good. Because I have actually studied
it, besides tried it. Have you? And, are you gonna keep saying you are
not getting personal, by the way?

>> So again, please, [citation needed]. You still haven't provided any
>> reference to support your claim that Lennart's code (specifically
>> systemd's code) is "poorly" done.
>
> Mate, have you heard of the world wide web? The internet?

And "the Internet" has always the same opinion. And it's never wrong.

> Seriously, mate ... are you his boyfriend, on his payroll, related, or
> what?

No, I don't even know him. Are you gonna keep saying you are not
getting personal, by the way?

> You search LKML for yourself. I've been there since 2003 and have numerous
> memories.

Me too. Lennart has actually code accepted into the Linux Kernel, and
he's a member of the Linux Kernel Plumbers. How's that as proof of
the quality of his code?

> How about:
> http://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal

Really? A petition on-line? With 235 votes? That's the best reference
you can present?

On one side, we have a guy whose code is included in all the levels on
the stack, from kernel to end-user application. On the other, we have
an open internet petition with 235 votes.

Yeah, I'm gonna side with the on-line poll.

> Sorry, mate ... many of us here are allergic to FUD <:-)}

I would say that you are allergic to Lennart's work. But I'm pretty
sure that you haven't take the time at least once to actually study it
or at least try it, and given the level of discussion you present, I'm
starting to think you don't actually have the capacity to study it.
So, in that sense, the one spreading the FUD is you.

All I keep saying is that I use systemd (and udev, and GNOME 3), and
that I like it, and that I agree with the technical decisions behind
it.

That's it. Of course you don't have to agree with me (as I don't agree
with you). But at least I'm not resort to name-calling, and I actually
have tried (and studied) both systemd and OpenRC (which is the topic
of this particular branch of the thread we are in).

I'm out of this thread. As always, I give my opinion, do whatever you
want with it.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-18-2012, 07:02 AM
Graham Murray
 
Default

Canek Peláez Valdés <caneko@gmail.com> writes:

> * Really simple service unit files: The service unit files are really
> small, really simple, really easy to understand/modify. Compare the 9
> lines of sshd.service:
>
> $ cat /etc/systemd/system/sshd.service
> [Unit]
> Description=SSH Secure Shell Service
> After=syslog.target
>
> [Service]
> ExecStart=/usr/sbin/sshd -D
>
> [Install]
> WantedBy=multi-user.target
>
> with the 84 of /etc/init.d/sshd (80 without comments).

But the 80 lines of /etc/init.d/sshd do a lot more than just and stop
the service. They ensure that there is an sshd configuration file and
give a meaningful message (including where to find the sample) if it is
not present, and check for the presence of the hostkeys (again which are
needed) and create them if they are not present. Your 9 lines of
sshd.service do none of this.
 
Old 03-18-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 6 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (6 total) ==

* cdemu-daemon-1.5.0-2 (i686)
0/2 signoffs
* directfb-1.5.3-1 (i686)
0/2 signoffs
* qingy-1.0.0-3 (i686)
0/2 signoffs
* cdemu-daemon-1.5.0-2 (x86_64)
0/2 signoffs
* directfb-1.5.3-1 (x86_64)
0/2 signoffs
* qingy-1.0.0-3 (x86_64)
0/2 signoffs


== Top five in signoffs in last 24 hours ==

1. bluewind - 3 signoffs
2. eric - 3 signoffs
 
Old 03-18-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 7 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 10 fully signed off packages
* 25 packages missing signoffs
* 3 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (7 total) ==

* bash-4.2.024-2 (i686)
* openldap-2.4.30-1 (i686)
* bash-4.2.024-2 (x86_64)
* openldap-2.4.30-1 (x86_64)
* bash-completion-1.99-1 (any)
* libdrm-2.4.32-1 (i686)
* libdrm-2.4.32-1 (x86_64)


== Incomplete signoffs for [core] (11 total) ==

* bash-4.2.024-2 (i686)
1/2 signoffs
* dirmngr-1.1.0-4 (i686)
0/2 signoffs
* linux-lts-3.0.24-1 (i686)
0/2 signoffs
* lvm2-2.02.95-1 (i686)
1/2 signoffs
* openldap-2.4.30-1 (i686)
0/2 signoffs
* openssl-1.0.1-1 (i686)
0/2 signoffs
* psmisc-22.16-1 (i686)
1/2 signoffs
* syslinux-4.05-4 (i686)
1/2 signoffs
* bash-4.2.024-2 (x86_64)
1/2 signoffs
* dirmngr-1.1.0-4 (x86_64)
1/2 signoffs
* openldap-2.4.30-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (11 total) ==

* bash-completion-1.99-1 (any)
1/2 signoffs
* libdrm-2.4.32-1 (i686)
0/2 signoffs
* neon-0.29.6-4 (i686)
0/2 signoffs
* nx-common-3.5.0-4 (i686)
0/2 signoffs
* proftpd-1:1.3.4a-4 (i686)
0/2 signoffs
* xf86-video-mga-1.4.13-6 (i686)
0/2 signoffs
* libdrm-2.4.32-1 (x86_64)
0/2 signoffs
* neon-0.29.6-4 (x86_64)
0/2 signoffs
* nx-common-3.5.0-4 (x86_64)
0/2 signoffs
* proftpd-1:1.3.4a-4 (x86_64)
0/2 signoffs
* xf86-video-mga-1.4.13-6 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (3 total) ==

* archlinux-keyring-20120303-1 (any)
0/2 signoffs
* cups-filters-1.0.1-1 (i686)
0/2 signoffs
* cups-filters-1.0.1-1 (x86_64)
1/2 signoffs


== Completed signoffs (10 total) ==

* iproute2-3.2.0-3 (i686)
* openssh-5.9p1-6 (i686)
* iproute2-3.2.0-3 (x86_64)
* linux-lts-3.0.24-1 (x86_64)
* lvm2-2.02.95-1 (x86_64)
* openssh-5.9p1-6 (x86_64)
* openssl-1.0.1-1 (x86_64)
* psmisc-22.16-1 (x86_64)
* syslinux-4.05-4 (x86_64)
* namcap-3.2.3-1 (any)


== All packages in [testing] for more than 14 days (3 total) ==

* cups-filters-1.0.1-1 (i686), since 2012-02-17
* cups-filters-1.0.1-1 (x86_64), since 2012-02-17
* archlinux-keyring-20120303-1 (any), since 2012-03-03


== Top five in signoffs in last 24 hours ==

1. bluewind - 3 signoffs
2. eric - 3 signoffs
 
Old 03-18-2012, 07:17 AM
Lukáš Jirkovský
 
Default

On 17 March 2012 20:39, member graysky <graysky@archlinux.us> wrote:
> I adopted the 'celtx-bin' package and updated it to the latest version as
> well as enhanced the support to cover both i686 and x86_64. Â*There is also
> a package called celtx-bin64 which is now redundant. Â*The maintainer of
> this package agrees that we should remove it.
> https://aur.archlinux.org/packages.php?ID=46977

I've merged celtx-bin64 into celtx-bin. Thanks.
 
Old 03-18-2012, 07:49 AM
Canek Peláez Valdés
 
Default

On Sun, Mar 18, 2012 at 2:02 AM, Graham Murray <graham@gmurray.org.uk> wrote:
> Canek Peláez Valdés <caneko@gmail.com> writes:
>
>> * Really simple service unit files: The service unit files are really
>> small, really simple, really easy to understand/modify. Compare the 9
>> lines of sshd.service:
>>
>> $ cat /etc/systemd/system/sshd.service
>> [Unit]
>> Description=SSH Secure Shell Service
>> After=syslog.target
>>
>> [Service]
>> ExecStart=/usr/sbin/sshd -D
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> with the 84 of /etc/init.d/sshd (80 without comments).
>
> But the 80 lines of /etc/init.d/sshd *do a lot more than just and stop
> the service.

Yes, it does.

> They ensure that there is an sshd configuration file and
> give a meaningful message (including where to find the sample) if it is
> not present, and check for the presence of the hostkeys (again which are
> needed) and create them if they are not present. Your 9 lines of
> sshd.service do none of this.

That is completely true. I also think that those checks does not
belong into the init script: I think the configuration file presence
should be guarantee by the package manager at install time, and so the
creation of the hostkeys.

Having said that, systemd provides ConditionPathExists, which allows
you to set a file as necessary for a service execution. So my 9 lines
transform into

$ cat /etc/systemd/system/sshd.service
[Unit]
Description=SSH Secure Shell Service
After=syslog.target
ConditionPathExists=/etc/ssh/sshd_config

[Service]
ExecStart=/usr/sbin/sshd -D

[Install]
WantedBy=multi-user.target

If the config file doesn't exists, the service will not start, and you
can check the reason why with

systemctl status sshd.service

And of course you can set another mini sevice unit file to create the
hostkeys. But I repeat: I think those tasks belong into the package
manager, no the init script.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-18-2012, 10:23 AM
Pandu Poluan
 
Default

On Mar 18, 2012 3:52 PM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:

>

> If the config file doesn't exists, the service will not start, and you

> can check the reason why with

>

> systemctl status sshd.service

>

> And of course you can set another mini sevice unit file to create the

> hostkeys. But I repeat: I think those tasks belong into the package

> manager, no the init script.

>


Between installation by package manager and actual execution by the init system, things might happen on the required file(s). Gentoo's initscript guards against this possibility *plus* providing helpful error messages in /var/rc.log



Or, said configuration files might be corrupted; the OpenRC initscript -- if written defensively -- will be able to detect that and (perhaps) fallback to something sane. systemd can't do that, short of putting all required intelligence into a script which it executes on boot.



Now, if one has to put all the intelligence into a script file which gets executed by systemd, that results in a system that's more complex than plain OpenRC. Not only would one need to maintain the starting script, but one must also maintain systemd + dbus.



So, the *only* benefit I can see about systemd is the smarter parallel startup of services. And believe me if I say that server guys (the ones handling tens or even hundreds of servers) would much prefer sequential startup of services than parallel ones. The former is deterministic, the latter is not.



Rgds,
 
Old 03-18-2012, 12:15 PM
Alan McKinnon
 
Default

On Sat, 17 Mar 2012 19:45:06 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).

I'm having a wet dream right about now :-)

init has been my pet peeve for years, starting with sysvinit. Why do I
need 9 runlevels all fully configured, when me, my machines, the
company's server, every Linux user in the company and every other use I
have ever personally met, only use 1 of them? Let's not even discuss
the amount of complexity that gets pushed into the init scripts
themselves.

Here's what I want:

When the machine starts, I want services X, Y and Z to run. The
software figures out what order they must start in and how the deps
work. Clean, neat, easy.

Maintenance mode is handled easily with two stages in startup:
early_start and late_start. Maintenance mode is what you have between
them. Again - nice, clean and simple.

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-18-2012, 12:56 PM
Dale
 
Default

Alan McKinnon wrote:
> On Sat, 17 Mar 2012 19:45:06 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> * Finally, and what I think is the most fundamental difference between
>> systemd and almost any other init system: The service unit files in
>> systemd are *declarative*; you tell the daemon *what* to do, not *how*
>> to do it. If the service files are shell scripts (like in
>> OpenRC/SysV), everything can spiral out of control really easily. And
>> it usually does (again, look at sshd; and that one is actully nicely
>> written, there are all kind of monsters out there abusing the power
>> that shell gives you).
>
> I'm having a wet dream right about now :-)
>
> init has been my pet peeve for years, starting with sysvinit. Why do I
> need 9 runlevels all fully configured, when me, my machines, the
> company's server, every Linux user in the company and every other use I
> have ever personally met, only use 1 of them? Let's not even discuss
> the amount of complexity that gets pushed into the init scripts
> themselves.
>
> Here's what I want:
>
> When the machine starts, I want services X, Y and Z to run. The
> software figures out what order they must start in and how the deps
> work. Clean, neat, easy.
>
> Maintenance mode is handled easily with two stages in startup:
> early_start and late_start. Maintenance mode is what you have between
> them. Again - nice, clean and simple.
>


Well, I am not normal. I, on a regular basis, use single, boot and
default runlevels. So there !! lol

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 

Thread Tools




All times are GMT. The time now is 08:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org