Discussion:
SYSTEMD: Give us a option for upstart
(too old to reply)
Reindl Harald
2011-06-12 21:23:30 UTC
Permalink
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before

* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param

WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES

I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen.png
Type: image/png
Size: 16421 bytes
Desc: not available
Url : Loading Image...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/8e465e87/attachment-0001.bin
Josh Boyer
2011-06-12 21:35:27 UTC
Permalink
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
BULL***, I CAN'T HEAR YOU! SOUND OFF LIKE YOU GOT A PAIR!

josh
Reindl Harald
2011-06-12 21:39:17 UTC
Permalink
Post by Josh Boyer
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
BULL***, I CAN'T HEAR YOU! SOUND OFF LIKE YOU GOT A PAIR!
there is nothing bullshit

why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored

WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/ca6b6408/attachment.bin
John R. Dennison
2011-06-12 21:43:44 UTC
Permalink
Post by Reindl Harald
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
I don't agree with the design or the implementation of systemd at all
but to call the developers idiots is a little harsh, don't you think?
And you shouting in a public mailing list doesn't do much to help your cause.

You've a strong tendency to go off at the least little thing, and not
only here. Might you consider toning it down? Just a little?





John

--
To do just the opposite is also a form of imitation.

-- Georg Christoph Lichtenberg (1742-1799), German scientist,
satirist and philosopher, Notebook D (1773-1775)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/06a9c7a4/attachment.bin
Reindl Harald
2011-06-12 21:52:43 UTC
Permalink
Post by John R. Dennison
Post by Reindl Harald
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
I don't agree with the design or the implementation of systemd at all
i agree with the design and idea but not with forcing every user
with since years perfectly running systems to use it without any
reason - the are hughe differences between a new setup and a
upgrade

and even on a new setup this should be a decision of the user
at the very beginning what init-system he wants to use
Post by John R. Dennison
but to call the developers idiots is a little harsh, don't you think?
And you shouting in a public mailing list doesn't do much to help your cause.
sorry but it makes me crazy that intel-graphics on newer hardware
is slow and buggy like hell and thean cames somebody and says
"upgrade to Fedora 15" with his little desktop without any developer-tools
and services perfectly configured over years

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/b3f289b5/attachment.bin
Kevin Kofler
2011-06-13 03:58:26 UTC
Permalink
Post by Reindl Harald
and even on a new setup this should be a decision of the user
at the very beginning what init-system he wants to us
No, the choice of this kind of core under-the-hood system components should
be a decision of the distribution. To the user, it should be only an
implementation detail. To the software on the distribution, it should matter
that they can rely on the core system components being what they are and not
have a user replace something as central as the init system.

I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are
doing. I don't see any valid reason why you'd use it over systemd.

You complain about some bugs in systemd, those should be reported as bugs
and fixed.

Kevin Kofler
Reindl Harald
2011-06-13 07:14:23 UTC
Permalink
Post by Kevin Kofler
Post by Reindl Harald
and even on a new setup this should be a decision of the user
at the very beginning what init-system he wants to us
No, the choice of this kind of core under-the-hood system components should
be a decision of the distribution.
thats freedom?
Post by Kevin Kofler
To the user, it should be only an implementation detail. To the software on the
distribution, it should matter that they can rely on the core system components
being what they are and not have a user replace something as central as the init system.
and usually HE CAN NOT with the most new technologies introduced in Fedora
the first two releases (PulseAudio, KDE 4.0...)
Post by Kevin Kofler
I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are
doing. I don't see any valid reason why you'd use it over systemd.
https://bugzilla.redhat.com/show_bug.cgi?id=709681

because your fukcing holy cow is not well tested and stable enough
and that it was planned for Fedora 14 and reverted at the last moment
and now a version later /run was introduced and discussed
not long ago shows that there are some peopole in the fedora community
with the only interest getting their stuff to as many users as possible
without a real interest if they can live with it
Post by Kevin Kofler
You complain about some bugs in systemd, those should be reported as bugs
and fixed.
AND THAT IIS WHY YOZ SHOULD INSTALL SYSTEMD ONLY FOR NEW INSTALLATIONS TO GET
A USERBASE FOR BUGREPORTS AND LAVE SINCE YEARS LUCKY USERS FUCK IN PEACE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/3c03883a/attachment.bin
Kevin Kofler
2011-06-13 07:47:04 UTC
Permalink
Post by Reindl Harald
Post by Kevin Kofler
No, the choice of this kind of core under-the-hood system components
should be a decision of the distribution.
thats freedom?
You have the freedom to fork Fedora. Good luck!

A distribution is about integration of different components, not about a
random hodegepodge of stuff which doesn't work together. You should not
expect all the software to cooperate with an obsolete init system. (In
particular, why should services have to ship legacy initscripts (or native
upstart configuration) along with the native systemd modules (which are
required for efficiency)? systemd is also going to take up more and more
roles in the very near future, e.g. replacing ConsoleKit.)
Post by Reindl Harald
and usually HE CAN NOT with the most new technologies introduced in Fedora
the first two releases (PulseAudio, KDE 4.0...)
PulseAudio was actually replaceable when it was initially introduced. It
even still is to some extent. IMHO that only makes it harder to make things
just work.

For KDE, it was just plain impossible to support both 3.5 and 4.0 in the
same distribution without violating the FHS. All the other distributions
which offer both versions of KDE are installing at least one to a non-FHS
prefix. Supporting only 4.0 also meant we could tweak kdelibs3 to integrate
better into a KDE 4 environment, e.g. we use the KDE 4 KHelpCenter for help,
the KDE 4 DrKonqi if a kdelibs3 app crashes etc.
Post by Reindl Harald
https://bugzilla.redhat.com/show_bug.cgi?id=709681
As I said in another message, it's not systemd's fault if your fstab is
invalid. Fix your fstab.

(And systemd is even getting a workaround to accept such broken fstab
files.)
Post by Reindl Harald
and that it was planned for Fedora 14 and reverted at the last moment
I also consider that a mistake. The issues found during testing were all
fixed in time for the Fedora 14 release. Reverting the feature achieved
exactly nothing.
Post by Reindl Harald
and now a version later /run was introduced and discussed
not long ago shows that there are some peopole in the fedora community
with the only interest getting their stuff to as many users as possible
without a real interest if they can live with it
How would you not be able to live with /run?

Kevin Kofler
Reindl Harald
2011-06-13 18:36:01 UTC
Permalink
first sorry for some bad words from mine, but this is how i feel in a situation not
knowing how to act since upgraded short ago to F14 in the hope get my energy
refreshed staying there for some months and now realizing i will newer get new intel
hardware well supportd on it
______________________

please respect that some people are having really troubles with their health
(what is happening to me this time in a way i wish not for my worst enemy),
trying to make a great job at the same time as far as it is possible

many of them (as i) have taken responsible for a lot of systems running really well with
F14 and are having simply not the mental and physical energy to switch their whole
setup in an invasive way

but they are forced to do this because they needed new hardware and if you buy hardware
now which should work 5 years or longer you will take the latest generation :-(
______________________

REALLY:

Fedora should consider a not so invasive way like KDE4, GNOME3, systemd in an
early release especially for updated systems because what sometimes happens
here is that features are included at a time some people are hoping they are
ready and on the other hand kernel-updates like for F6/F7/F8 are stopped
in the latest releases -> 2.6.38 would support new intel-network cards

what after that happens with power-users which are not only insert a CD and
taking all as pre-configured is anger, frustration, fear....

try to fully support their configurations for two releases and only install KDE4,
GNOME3, systemd on new setups as default will bring you a real userbase to optimize
things without destroy the experience of users which are loving Fedora since "Fedora
Core 3" and showing their wish to have a little time to get warm with new features
without the feeling "take it or leave it" is respected

as said: i love the idea of systemd and i am sure this will finally be a great thing,
but we all know there are bugs in new and complex software - so if Fedora would try
not be so invasive to existing setups peopole with more than one machine have the option
to wait some weeks/months before the first after-release bugs are fixed while they can
update on new hardware for several reasons (Sandy Brdige network/graphics) without
Post by Kevin Kofler
For KDE, it was just plain impossible to support both 3.5 and 4.0
and so it was the wrong decision ship KDE4.0 which was really unusable
and upstream declared only for developers! before 4.2 KDE4 was buggy
like hell and missing a lot of options

nearly the same happens now with GNOME3 and is a spit in the face for
many users which are switched from KDE4.0 to GNOME because KDE4.0 was
not useable for them
Post by Kevin Kofler
in the same distribution without violating the FHS.
interesting argument
where do you find /run in the FHS

<anger>
oh i frgot this is for systemd and tech reasons
needed which are more important as the users which
have to live with "your" decisions....
</anger>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/7f7e24c8/attachment.bin
Andreas Tunek
2011-06-13 19:02:45 UTC
Permalink
Post by Reindl Harald
but they are forced to do this because they needed new hardware and if you buy hardware
now which should work 5 years or longer you will take the latest generation :-(
You always have a choice which hw to buy. Sometimes you have to buy hw
to support the sw you want to run. If you want to run F14 you should
buy hw that supports F14 (or hw that F14 supports, whichever you want
to put it).

/Andreas Tunek
Brian Wheeler
2011-06-13 19:02:43 UTC
Permalink
Post by Reindl Harald
first sorry for some bad words from mine, but this is how i feel in a situation not
knowing how to act since upgraded short ago to F14 in the hope get my energy
refreshed staying there for some months and now realizing i will newer get new intel
hardware well supportd on it
______________________
please respect that some people are having really troubles with their health
(what is happening to me this time in a way i wish not for my worst enemy),
trying to make a great job at the same time as far as it is possible
many of them (as i) have taken responsible for a lot of systems running really well with
F14 and are having simply not the mental and physical energy to switch their whole
setup in an invasive way
but they are forced to do this because they needed new hardware and if you buy hardware
now which should work 5 years or longer you will take the latest generation :-(
______________________
As others have said: you chose the wrong tool for the job. Fedora
isn't for running on anything you want to keep stable in service for a
long time. Heck, even the
http://fedoraproject.org/en/about-fedora
page explicitly says that fedora devs "don't mind shaking up the status
quo, when it means we can more effectively move free software forward"

So maybe you should consider switching your servers to a RHEL 6 (or
clone) so they'll be stable and have new hardware support. Heck, even
for my home servers I don't run fedora because shaking it up every 6
months or so is a pain...I can't imagine trying it on production
servers.

Brian

[For the record, I like systemd, but I couldn't stomach Gnome3. So the
F15 upgrade was a mixed bag for me. Switched to XFCE and I'm happy
again]
Kevin Kofler
2011-06-13 23:49:36 UTC
Permalink
Post by Reindl Harald
Fedora should consider a not so invasive way like KDE4, GNOME3, systemd in
an early release especially for updated systems because what sometimes
happens here is that features are included at a time some people are
hoping they are ready and on the other hand kernel-updates like for
F6/F7/F8 are stopped in the latest releases -> 2.6.38 would support new
intel-network cards
I also miss those kernel upgrades. I think we've become much too
conservative.
Post by Reindl Harald
and so it was the wrong decision ship KDE4.0 which was really unusable
and upstream declared only for developers! before 4.2 KDE4 was buggy
like hell and missing a lot of options
All this "4.0 is only for developers" messaging came way too late. We had
already worked hard on making everything work with 4.0 in pre-F9 Rawhide at
that point. In addition, the messaging back then was that 4.1 would be the
general public release. So our plan was, we'd push 4.1 as an update ASAP;
until then, Fedora 8 stayed supported (and as you wrote above, it did get
kernel upgrades for hardware support). What we couldn't know is that:
* 4.1 would also get redefined as "only for developers". This only happened
several weeks after Fedora 9 was released. That was well past the point of
no return.
* 4.1 would trigger several showstopper regressions we had to fix before
pushing it as a stable update.
* There would be a major Fedora infrastructure outage due to a security
breach which ended up delaying the 4.1 update for 2-3 more weeks when our
regression tracker was finally clear.

We also worked really hard to make 4.0 work as well as possible. I made
several (completely unpaid!) 30+ hour days to build bugfix releases, fix
showstoppers etc. The other KDE SIG developers also worked for many hours on
that stuff. We were able to ship Fedora 9 with no true showstopper and we
fixed the most annoying bugs in updates before or within days of the
release.

In addition, a big part of the complaints about 4.0 was about missing
applications. We made sure the KDE 3 versions of those applications stayed
available and worked fine in a KDE 4 environment (also with some patching
where needed to provide proper integration, e.g. we patched Kile to use
Okular for PDF/PS/DVI previews, something that wouldn't have been possible
if we had been supporting the KDE 3 workspace as well), or in some cases got
a KDE 4 version in ASAP (e.g. I imported alpha/beta versions of Okteta, the
hex editor, as soon as it became available; I also ported Kompare to kdelibs
4 in time for 4.0.0, which got it resurrected upstream with me as the
maintainer).

We really did what we could to make KDE 4.0 not suck.

Kevin Kofler
Reindl Harald
2011-06-14 00:19:38 UTC
Permalink
Post by Kevin Kofler
I also miss those kernel upgrades. I think we've become much too
conservative.
and the combination is which i really not understand

* kernel -> conservative
* kde4/gnome3/systemd -> go ahead with all consquences

and the kernel is really not a big deal because the updates
are normally not invasive
Post by Kevin Kofler
All this "4.0 is only for developers" messaging came way too late. We had
already worked hard on making everything work with 4.0 in pre-F9 Rawhide at
that point.
the mistake happended long before!

as KDE4.0 was anounced for F9 nobody did know if they are
ready and which state kde4 would have in the first release
Post by Kevin Kofler
We also worked really hard to make 4.0 work as well as possible. I made
several (completely unpaid!) 30+ hour days to build bugfix releases, fix
showstoppers etc. The other KDE SIG developers also worked for many hours on
that stuff. We were able to ship Fedora 9 with no true showstopper and we
fixed the most annoying bugs in updates before or within days of the
release.
nobod said that there was no hard work

but is it really needed to decide major upgrades without knwoing
what state the software finally would have instead take a breath and
fixing existing bugs since every 6 months is a new release and no
reason to hurry

it would be really a godd idea to take every second release only
for bugfixing and kernel-upgrades for hardware-support and only
every econd release to bring new stuff - there are so many small
bugs and edges everywhere that there is no need for such a hurry



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110614/d96767e1/attachment.bin
Kevin Kofler
2011-06-14 00:50:22 UTC
Permalink
Post by Reindl Harald
as KDE4.0 was anounced for F9 nobody did know if they are
ready and which state kde4 would have in the first release
We need to do some advance planning and development to provide a polished
release to our users, so we have to start importing prereleases of new
upstream software very early in the cycle, especially for a big change like
KDE 3?4. We have neither the infrastructure nor the human resources to do
this work on a separate development branch, so we have to do it in Rawhide,
at which point everything in Rawhide gets ported to the new technologies and
it's very hard to go back.

It is upstream's failure to not have communicated upfront that 4.0 would not
be a release they'd want shipped to end users. There were some developers
claiming it'd be a great new release with lots of new features they were
working on, and a few others merely cautioning that it'd be for "early
adopters" (whom Fedora users are expected to be). That "only for application
developers" claim came only later, when Rawhide was already upgraded to 4.0.
If the upstream developers had been less optimistic about their new release
right from the start, we might have taken a different decision.

That said, I actually think Fedora 9 turned out as a great release, KDE
4.0.3 wasn't quite as broken as some people (including some upstream
developers) were claiming, and KDE got better and better in updates.

Kevin Kofler
Scott Schmit
2011-06-14 00:54:30 UTC
Permalink
Post by Reindl Harald
Post by Kevin Kofler
I also miss those kernel upgrades. I think we've become much too
conservative.
and the combination is which i really not understand
* kernel -> conservative
* kde4/gnome3/systemd -> go ahead with all consquences
Not addressing specifically the issue with the kernel updates, but at
least in part, the answer is simple:
* Within a release, updates should try very hard to avoid breaking
things.
* Between releases, upgrades can change a lot. These changes are
advertised so that users can decide if/when they want to upgrade.
Post by Reindl Harald
and the kernel is really not a big deal because the updates
are normally not invasive
Not in my experience--I have had on occasion crippling kernel bugs that
come and go from update to update (hangs with no oops recorded to the
log, for example). Thankfully, that's rare, but I'd argue that it's
*because of* that conservatism, not in spite of it.
--
Scott Schmit
Genes MailLists
2011-06-14 04:57:19 UTC
Permalink
Post by Scott Schmit
Not addressing specifically the issue with the kernel updates, but at
* Within a release, updates should try very hard to avoid breaking
things.
* Between releases, upgrades can change a lot. These changes are
advertised so that users can decide if/when they want to upgrade.
Post by Reindl Harald
and the kernel is really not a big deal because the updates
are normally not invasive
Not in my experience--I have had on occasion crippling kernel bugs that
come and go from update to update (hangs with no oops recorded to the
log, for example). Thankfully, that's rare, but I'd argue that it's
*because of* that conservatism, not in spite of it.
The upstream kernel is a rolling release with Linus' law of protect
users as much as possible.

While a fresh released kernel in stable often gets a few updates and
fixes the .1 or .2 stable kernels are generally remarkably solid.

This is in large part attributable to the rolling release model.

Fedora could well benefit from switching to a rolling release model
as well (no not rawhide - a controlled rolling release much as the
kernel development follows).

gene
Rahul Sundaram
2011-06-14 05:22:32 UTC
Permalink
Post by Genes MailLists
The upstream kernel is a rolling release with Linus' law of protect
users as much as possible.
While a fresh released kernel in stable often gets a few updates and
fixes the .1 or .2 stable kernels are generally remarkably solid.
This is in large part attributable to the rolling release model.
Fedora could well benefit from switching to a rolling release model
as well (no not rawhide - a controlled rolling release much as the
kernel development follows).
I don't think you can call it a rolling release unless you only count
Linus branch and discount others like Linux next tree and even that is a
stretch since the "rc" releases are essentially development snapshots
that incrementally move towards less changes and more stability exactly
like the alpha and beta releases and release candidates in a Linux
distribution .

Rahul
Nicolas Mailhot
2011-06-14 19:29:52 UTC
Permalink
Post by Rahul Sundaram
Post by Genes MailLists
The upstream kernel is a rolling release with Linus' law of protect
users as much as possible.
While a fresh released kernel in stable often gets a few updates and
fixes the .1 or .2 stable kernels are generally remarkably solid.
This is in large part attributable to the rolling release model.
Fedora could well benefit from switching to a rolling release model
as well (no not rawhide - a controlled rolling release much as the
kernel development follows).
I don't think you can call it a rolling release unless you only count
Linus branch and discount others like Linux next tree and even that is a
stretch since the "rc" releases are essentially development snapshots
that incrementally move towards less changes and more stability exactly
like the alpha and beta releases and release candidates in a Linux
distribution .
The kernel is a rolling releases with streams that feed into it (like
personnal repos, unpackaged alpha software versions, etc). It's a
controlled rolling release because kernel devs can play with features
all they want, but at the first user-visible regression it's 'fix it now
or I revert'.

The problem with rawhide is that at the first sign of regression people
write about babies and defend the regression not being fixed for a long
time.
--
Nicolas Mailhot
&quot;Andy Green (林安廸)&quot;
2011-06-14 06:48:08 UTC
Permalink
Post by Genes MailLists
Fedora could well benefit from switching to a rolling release model
as well (no not rawhide - a controlled rolling release much as the
kernel development follows).
I've been living from rawhide on my main laptop for a few years, from my
POV the existing setup where rawhide never stops and it branches off
before the release is ideal already. I sometimes get the equivalent of
a "crossword puzzle" to do on the next boot after an update to get it up
again, but at least it keeps me aware of major developments.

Since the upstream projects never stop either, capturing that reality in
rawhide in packagable form as a first step all the time seems like it
must be part of a good solution.

BTW I am very happy someone is grasping the nettle of sysvinit, keep up
the good work everybody!

-Andy
Michael Ekstrand
2011-06-14 14:01:19 UTC
Permalink
Post by Genes MailLists
Fedora could well benefit from switching to a rolling release model
as well (no not rawhide - a controlled rolling release much as the
kernel development follows).
I ran rolling release distros on my laptops for a while - Gentoo, then
Debian Testing.

I came to the conclusion about 3 years ago that, personally, a rolling
release does not work for me, even though Debian Testing is very
reliable. If I have a rolling release, I am regularly looking for
what's new, trying it out, and tinkering with my system. This distracts
me from getting my actual work done. Having real stable releases allows
me to consolidate this exploration and tinkering in a week or two twice
a year, and I can always source-install or backport the few applications
where I do have a legit need for more recent versions (although 6 months
is generally often enough for upgrading them).

Now, this is just me and my psychology. But the 6-month release cycle
is very good for me, and I think many people likely benefit from
consolidating update adjustment into regular intervals.

- Michael
Karel Zak
2011-06-14 20:16:01 UTC
Permalink
Post by Reindl Harald
Post by Kevin Kofler
in the same distribution without violating the FHS.
interesting argument
where do you find /run in the FHS
It will be very probably in the next FSH version, for more information
see http://bugs.linuxfoundation.org/show_bug.cgi?id=718

Karel
--
Karel Zak <kzak at redhat.com>
http://karelzak.blogspot.com
Alexander Kurtakov
2011-06-13 11:11:01 UTC
Permalink
Post by Reindl Harald
Post by Kevin Kofler
Post by Reindl Harald
and even on a new setup this should be a decision of the user
at the very beginning what init-system he wants to us
No, the choice of this kind of core under-the-hood system components
should be a decision of the distribution.
thats freedom?
Yes, this is the freedom of the people that do the work to take some
decisions. Freedom is one of the rights for people that work on the
distribution too, don't you think so ?
Post by Reindl Harald
Post by Kevin Kofler
To the user, it should be only an implementation detail. To the software
on the distribution, it should matter that they can rely on the core
system components being what they are and not have a user replace
something as central as the init system.
and usually HE CAN NOT with the most new technologies introduced in Fedora
the first two releases (PulseAudio, KDE 4.0...)
Post by Kevin Kofler
I think it makes no sense whatsoever to even OFFER upstart in F15+ as we
are doing. I don't see any valid reason why you'd use it over systemd.
https://bugzilla.redhat.com/show_bug.cgi?id=709681
because your fukcing holy cow is not well tested and stable enough
and that it was planned for Fedora 14 and reverted at the last moment
and now a version later /run was introduced and discussed
not long ago shows that there are some peopole in the fedora community
with the only interest getting their stuff to as many users as possible
without a real interest if they can live with it
Post by Kevin Kofler
You complain about some bugs in systemd, those should be reported as bugs
and fixed.
AND THAT IIS WHY YOZ SHOULD INSTALL SYSTEMD ONLY FOR NEW INSTALLATIONS TO
GET A USERBASE FOR BUGREPORTS AND LAVE SINCE YEARS LUCKY USERS FUCK IN
PEACE
And who is gonna do the testing of 2 distributions? Because testing 2 different
init systems is like testing 2 different distributions. Fedora QA are already
overloaded enough so we can't make that on them.
And who is gonna do the work on all the patches for working with and making
use of the features of the 2 different init systems? I would not do such thing
for my packages for sure.
As soon as some core component changes I'll support it only whenever I'm
involved. YES, THIS IS MY FREEDOM TO DECIDE WHAT TO DO!
Though I'll let everyone that wants to comaintain smth to do the work to
support alternatives but I'm still failing to see the army of contributors
just sitting and waiting for what to do. Until this happens people should
remember that the one that do the works has freedom too and if they don't like
smth they are free to come with better implementation and offer it.

Alexander Kurtakov
Jared K. Smith
2011-06-13 14:55:02 UTC
Permalink
Post by Reindl Harald
because your fukcing holy cow
This type of language is inappropriate for a Fedora mailing list.
Please tone down the language.

--
Jared Smith
Fedora Project Leader
Matthew Garrett
2011-06-13 15:50:14 UTC
Permalink
Post by Jared K. Smith
Post by Reindl Harald
because your fukcing holy cow
This type of language is inappropriate for a Fedora mailing list.
Please tone down the language.
I'd go further than that. Swearing is not inherently an issue. The
problem is abusive and aggressive behaviour. We expect participants in
the community to demonstrate appropriate levels of respect for one
another. Not agreeing with the rationale for a decision does not
inherently mean that the decision was inappropriate, and is certainly
not grounds for abusing those who made that decision. Let's remember
that these lists are one of the public faces of the project and try to
make sure we don't alienate potential contributors through our
behaviour, swearing or otherwise.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Rudolf Kastl
2011-06-14 09:45:39 UTC
Permalink
Post by Kevin Kofler
Post by Reindl Harald
and even on a new setup this should be a decision of the user
at the very beginning what init-system he wants to us
No, the choice of this kind of core under-the-hood system components should
be a decision of the distribution. To the user, it should be only an
implementation detail. To the software on the distribution, it should matter
that they can rely on the core system components being what they are and not
have a user replace something as central as the init system.
I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are
doing. I don't see any valid reason why you'd use it over systemd.
From experience... i prefer having two tools available atleast to do
every single job (especially when they exist) because then i have an
easy fallback if one fails. Having upstart installed on rawhide during
the f15 rawhide cycles was quite helpful to work around boot bugs on
the fly without having to debug stuff or ending up with a nonbooting
system (which makes it hard to dig up ml threads with workarounds, or
up or downgrading packages). As long as someone maintains it i see no
reason to exclude upstart completly from the repos.

kind regards,
Rudolf Kastl

rhce rhca rhcss rhcx rhci
Red Hat Inc.
Post by Kevin Kofler
You complain about some bugs in systemd, those should be reported as bugs
and fixed.
? ? ? ?Kevin Kofler
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Rahul Sundaram
2011-06-14 09:49:32 UTC
Permalink
Post by Kevin Kofler
From experience... i prefer having two tools available atleast to do
every single job (especially when they exist) because then i have an
easy fallback if one fails. Having upstart installed on rawhide during
the f15 rawhide cycles was quite helpful to work around boot bugs on
the fly without having to debug stuff or ending up with a nonbooting
system (which makes it hard to dig up ml threads with workarounds, or
up or downgrading packages). As long as someone maintains it i see no
reason to exclude upstart completly from the repos.
What do you about glibc bugs? Do you want to get them fixed or
include alternatives? Having alternatives for each of the core
components is a costly affair. it isn't just about maintaining
upstart. It is also having to deal with two different type of init
configuration scattered across the system, differences in handling many
things including /etc/iniittab and /etc/fstab, having to maintain init
scripts or upstart configuration files in all the different packages in
addition to the systemd unit files and testing them regularly in the
development cycle to ensure that changes we make for systemd doesn't
impact negatively on upstart and so on. This is just silly. We have
to draw the line somewhere

Rahul
Rudolf Kastl
2011-06-14 11:06:37 UTC
Permalink
Post by Kevin Kofler
From experience... i prefer having two tools available atleast to do
every single job (especially when they exist) because then i have an
easy fallback if one fails. Having upstart installed on rawhide during
the f15 rawhide cycles was quite helpful to work around boot bugs on
the fly without having to debug stuff or ending up with a nonbooting
system (which makes it hard to dig up ml threads with workarounds, or
up or downgrading packages). As long as someone maintains it i see no
reason to exclude upstart completly from the repos.
What do you about ?glibc bugs? ? Do you want to get them fixed or
include alternatives?
its been many years since i have seen a glibc bug that makes my system
completly unbootable. i have had various issues during the last devel
cycle where my system wouldnt boot anymore and upstart was a good
shorttime fallback. having an alternative doesent mean that bugs
should be covered instead fixed. i never proposed this and i am not
sure why you start off like that on me.
Having alternatives for each of the core
components is a costly affair. ?it isn't just about maintaining
upstart. ?It is also having to deal with two different type of init
configuration scattered across the system, differences in handling many
things including /etc/iniittab and /etc/fstab, ?having to maintain init
scripts or upstart configuration files in all the different packages in
addition to the systemd unit files and testing them regularly in the
development cycle to ensure that changes we make for systemd doesn't
impact negatively on upstart and so on. ?This is just silly.
? We have to draw the line somewhere
I never proposed having alternatives for each of the core systems
either... There is already a viable alternative that works. inittab
contains atm exactly one line... the one with the default runlevel...
and /etc/fstab can be parsed differently if there are changes.

Also i do not understand the Argument with the unit files... they are
systemd related. upstart isnt affected. Since upstart isnt installed
by default anyways it also doesent matter for "critical path". Got a
hard time to follow your argumentation there. SystemV init scripts are
already present and work quite well aswell.
This is just silly.
Not commenting that.
? We have to draw the line somewhere
Draw your line ;)

kind regards,
Rudolf Kastl
Rahul Sundaram
2011-06-14 11:08:28 UTC
Permalink
Post by Rudolf Kastl
I never proposed having alternatives for each of the core systems
either... There is already a viable alternative that works. inittab
contains atm exactly one line... the one with the default runlevel...
and /etc/fstab can be parsed differently if there are changes.
systemd doesn't use /etc/inittab and upstart uses it. So you have to
account for the differences and test them.
Post by Rudolf Kastl
Also i do not understand the Argument with the unit files... they are
systemd related. upstart isnt affected. Since upstart isnt installed
by default anyways it also doesent matter for "critical path". Got a
hard time to follow your argumentation there. SystemV init scripts are
already present and work quite well aswell.
You miss the point. Packages are already dropping init scripts and
converting to using systemd unit files. To maintain upstart
compatibility you have to continue to maintain sys init scripts in
addition to systemd unit files and again make sure they don't diverge
and they both work equivalently. Who is volunteering for that?

Rahul
Steve Clark
2011-06-14 11:26:34 UTC
Permalink
Post by Rahul Sundaram
Post by Rudolf Kastl
I never proposed having alternatives for each of the core systems
either... There is already a viable alternative that works. inittab
contains atm exactly one line... the one with the default runlevel...
and /etc/fstab can be parsed differently if there are changes.
systemd doesn't use /etc/inittab and upstart uses it. So you have to
account for the differences and test them.
Post by Rudolf Kastl
Also i do not understand the Argument with the unit files... they are
systemd related. upstart isnt affected. Since upstart isnt installed
by default anyways it also doesent matter for "critical path". Got a
hard time to follow your argumentation there. SystemV init scripts are
already present and work quite well aswell.
You miss the point. Packages are already dropping init scripts and
converting to using systemd unit files. To maintain upstart
compatibility you have to continue to maintain sys init scripts in
addition to systemd unit files and again make sure they don't diverge
and they both work equivalently. Who is volunteering for that?
Rahul
You already are maintaining multiple UI systems which seem to me to be much more complex than
two different "init" systems.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110614/003ba113/attachment.html
Rahul Sundaram
2011-06-14 11:35:57 UTC
Permalink
Post by Steve Clark
You already are maintaining multiple UI systems which seem to me to be
much more complex than
two different "init" systems.
Not the same thing at all. Maintenance of desktop environments doesn't
affect people outside a few people who do that. If I don't care about
fluxbox, I can ignore it completely. Maintaining two init systems
actively affects everyone who has a init script in their packages which
is a lot more. This is non-trivial and I don't see why I should
volunteer to test both a init script and a equivalent systemd unit
file. If someone is interested in maintaining upstart for current
Fedora 15 and above, they should take care of this entirely and I will
do it for one init system which is the default one.

Rahul
Josh Boyer
2011-06-12 21:45:21 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
BULL***, I CAN'T HEAR YOU! ?SOUND OFF LIKE YOU GOT A PAIR!
there is nothing bullshit
Oh, you were trying to have a conversation about something? Sorry,
with all the shouting I thought we were doing impromptu Gunnery
Sergeant Hartman quotes from Full Metal Jacket.
Post by Reindl Harald
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
I actually don't know the answer to this question other than "Fedora
switched to systemd".
Post by Reindl Harald
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
Amazing what one motivated maintainer and their package can accomplish
while everyone else is shouting.

josh
Reindl Harald
2011-06-12 21:54:39 UTC
Permalink
Post by Josh Boyer
Post by Reindl Harald
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
I actually don't know the answer to this question other than "Fedora
switched to systemd"
cool - on linux the apple-way starts also?

great - the desicion force systemd for updated installations
is the best way to crap down the reputation of linux as a
system where the user can decide what he want to run


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/1e054ff7/attachment.bin
Frank Murphy
2011-06-12 21:58:55 UTC
Permalink
Post by Reindl Harald
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
<snip>

Try yum install upstart,
kernel arg init=/sbin/upstart
YMMV.
--
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
Reindl Harald
2011-06-12 22:06:38 UTC
Permalink
Post by Frank Murphy
Post by Reindl Harald
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
<snip>
Try yum install upstart,
kernel arg init=/sbin/upstart
and that this does not happen automatic on an UPGRADE
is a major fault!

it seems also not very well working and telling / is already mounted
Post by Frank Murphy
Dateisysteme pr?fen
/dev/md1: sauber, 48557/1905008 Dateien, 477525/7607040 Bl?cke
/dev/md0: sauber, 38/128016 Dateien, 47146/511988 Bl?cke
[ OK ]
Root-Dateisystem mit Schreib- und Lesezugriff neu einh?ngen[ OK ]
mount: Laut mtab ist /dev/md1 schon auf / eingeh?ngt
Lokale Dateisysteme einh?ngen: [FEHLGESCHLAGEN]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/74bc1872/attachment.bin
Steve Clark
2011-06-12 22:13:59 UTC
Permalink
Post by Reindl Harald
Post by Josh Boyer
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
BULL***, I CAN'T HEAR YOU! SOUND OFF LIKE YOU GOT A PAIR!
there is nothing bullshit
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
<sarcasm>don't you know you will save 15-30 seconds each time you boot up</sarcasm>
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/991d2a2e/attachment.html
Reindl Harald
2011-06-12 22:18:37 UTC
Permalink
Post by Steve Clark
Post by Reindl Harald
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
<sarcasm>don't you know you will save 15-30 seconds each time you boot up</sarcasm>
someone come out there and show me how will a 20 second-reboot on the
vmware-guest production servers will get 20 seconds faster

everybody out there is crying about boot / start times
have the peopole nothing to do as reboot their machines?

normally i start a computer and then it runs for a day, some weeks
or even some months, the same with open programs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/d1a5df4d/attachment.bin
Steve Clark
2011-06-12 22:23:00 UTC
Permalink
Post by Reindl Harald
Post by Steve Clark
Post by Reindl Harald
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
<sarcasm>don't you know you will save 15-30 seconds each time you boot up</sarcasm>
someone come out there and show me how will a 20 second-reboot on the
vmware-guest production servers will get 20 seconds faster
everybody out there is crying about boot / start times
have the peopole nothing to do as reboot their machines?
normally i start a computer and then it runs for a day, some weeks
or even some months, the same with open programs
I agree - saying a main feature of systemd is improved boot times is idiotic. I you boot your system in the morning and shut it down
at night what does 30 seconds mean out of 8*60*60 seconds? Nothing. If your are concerned with boot times suspend to disk!
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/7080b8fb/attachment-0001.html
Reindl Harald
2011-06-12 22:27:43 UTC
Permalink
Post by Steve Clark
Post by Reindl Harald
Post by Steve Clark
<sarcasm>don't you know you will save 15-30 seconds each time you boot up</sarcasm>
someone come out there and show me how will a 20 second-reboot on the
vmware-guest production servers will get 20 seconds faster
everybody out there is crying about boot / start times
have the peopole nothing to do as reboot their machines?
normally i start a computer and then it runs for a day, some weeks
or even some months, the same with open programs
I agree - saying a main feature of systemd is improved boot times is idiotic. I you boot your system in the
morning and shut it down
at night what does 30 seconds mean out of 8*60*60 seconds? Nothing. If your are concerned with boot times suspend
to disk!
suspend to disk with 16 GB RAM - have fun :-)

i have really no problem with "systemd" but it would be wise to
use it only for new installations to get a wider userbase without
spit current users in their face instead give them time to play
and decide while have the benefit of nerwer kernels and better
hardware-support

this time "systemd" is not trustable since if there is a problem
with httpd the anser of a "service start" is OK and the service was
not started
[root at testserver:~]$ service httpd start
Starting httpd (via systemctl): [ OK ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/c0b97f93/attachment.bin
drago01
2011-06-12 23:27:15 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
Post by Steve Clark
<sarcasm>don't you know you will save 15-30 seconds each time you boot up</sarcasm>
someone come out there and show me how will a 20 second-reboot on the
vmware-guest production servers will get 20 seconds faster
everybody out there is crying about boot / start times
have the peopole nothing to do as reboot their machines?
normally i start a computer and then it runs for a day, some weeks
or even some months, the same with open programs
I agree - saying a main feature of systemd is improved boot times is idiotic. ?I you boot your system in the
morning and shut it down
at night what does 30 seconds mean out of 8*60*60 seconds? Nothing. If your are concerned with boot times suspend
to disk!
suspend to disk with 16 GB RAM - have fun :-)
i have really no problem with "systemd" but it would be wise to
use it only for new installations to get a wider userbase without
spit current users in their face instead give them time to play
and decide while have the benefit of nerwer kernels and better
hardware-support
1) You said you aren't going to start a flamewar but still opened a
new thread shouting some random "I hate change, how dare you FORCE
something new on me" BS
2) No users upgrading should not have a degraded user experience
because some users are afraid of changes (those shouldn't be running a
distro like fedora in the first place) and to use your words they
shouldn't be "FORCED" to take manual steps to get current software
(i.e that is what the upgrade was all about after all).
3) We have a site called "bugzilla" where problems are supposed to be
reported, flamewars do not really solve problems
Michael Schwendt
2011-06-13 19:44:30 UTC
Permalink
Post by Reindl Harald
this time "systemd" is not trustable since if there is a problem
with httpd the anser of a "service start" is OK and the service was
not started
[root at testserver:~]$ service httpd start
Starting httpd (via systemctl): [ OK ]
Then use /bin/systemctl instead of the "service" wrapper, e.g.
# systemctl start httpd.service
# systemctl status httpd.service
Denys Vlasenko
2011-06-13 16:30:01 UTC
Permalink
Post by Reindl Harald
Post by Josh Boyer
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
BULL***, I CAN'T HEAR YOU! SOUND OFF LIKE YOU GOT A PAIR!
there is nothing bullshit
why are users of running systems are forced to change their
init-system to "systemd"? "upstart" is in the repos but ignored
WTF every three years a new pig is forced to run through the city
and if any subsystem is runnign well and debugged some idiot
comes out of his hole and try replace and force everybody
to use it
I totally disagree with the way you phrase your arguments.
It is inappropriate, and actually hurts the point you are trying to
make.

However, I partially agree with the argument itself. Gnome 3 Shell
is an example of a far worse surprise, IMO, than systemd.
It's a disaster, especially for those poor souls which convinced some
firm or school or university to use Fedora, and now have to face angry
mobs of users pissed off by abrupt switch to a different desktop
manager. Talk about ruined reputations...

But at least there F15 has an alternative. Now I use XFCE.
--
vda
Mike Chambers
2011-06-12 22:00:51 UTC
Permalink
Post by Reindl Harald
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
Why run Fedora itself on 20 servers? Those are mission capable and in a
production environment? Might be free, but not sure I would run all
those on this type environment. A slower and more stable platform that
is free might be better.

That's beside the point, why are you not testing upgrades and working
out the issues yourself before even trying, in a test environment?
Actually, if they need no magic and are fast enough, why upgrade at all
right now and wait until everything is worked out?

Not telling you what to do, just bringing up different
points/suggestions.
--
Mike Chambers
Madisonville, KY

"The best town on Earth!"
Reindl Harald
2011-06-12 22:16:00 UTC
Permalink
Post by Mike Chambers
Post by Reindl Harald
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
Why run Fedora itself on 20 servers?
Because it works perfectly with one version behind
Post by Mike Chambers
Those are mission capable and in a production environment?
yes and this time on F14 but the clock goes fast around
and since F14 is not supporting the hardware of my new
work station (Intel graphics / Sandy Brdige) i have
to play around with F15
Post by Mike Chambers
A slower and more stable platform that
is free might be better.
Running Fedora since F7 in production environments without
any downtime bcause the OS or any upgrade-problems showing
that i know what i do
Post by Mike Chambers
That's beside the point, why are you not testing upgrades and working
out the issues yourself before even trying, in a test environment?
what do you believe what i am doing here?

the test says " i do not want this crap in this early devel-state
on my servers end of the year" nobody knows what "systemd" mislikes
on /mnt/storage because if i uncomment it the system starts without any
issue and manually mounting works

on the other hand this crap tells me the follwoing without bringing httpd up
[root at testserver:~]$ service httpd start
Starting httpd (via systemctl): [ OK ]

[Sun Jun 12 23:30:40 2011] [error] (2)No such file or directory: could not create /var/run/httpd/httpd.pid
[Sun Jun 12 23:30:40 2011] [error] httpd: could not log pid to file /var/run/httpd/httpd.pid

well this is the F14 build of Apache but shows me that i will go to hell
if the output of "service start" is no longer trustable as years before
Post by Mike Chambers
Actually, if they need no magic and are fast enough, why upgrade at all
right now and wait until everything is worked out?
because i do not update the servers, i try to bring up my test/build-environemt
to get my workstation supported which relys on the same packages as
production-servers (ffmpeg, newer httpd-versions, newer php-versions)
Post by Mike Chambers
Not telling you what to do, just bringing up different
points/suggestions
i knowing my job very well and because this is so i have to upgrade
to F15 a longer time before the servers and i see NO SINGLE REASON
for systemd on a server at all!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/4c40e683/attachment.bin
Michal Schmidt
2011-06-13 00:42:00 UTC
Permalink
could not create /var/run/httpd/httpd.pid [Sun Jun 12 23:30:40 2011]
[error] httpd: could not log pid to file /var/run/httpd/httpd.pid
well this is the F14 build of Apache but shows me that i will go to
hell if the output of "service start" is no longer trustable as years
before
The F14 build does not have the necessary /etc/tmpfiles.d/httpd.conf
file to ensure /var/run/httpd is created on boot.

Running F14 packages on F15 is not expected to work. Don't do that.

Michal
Reindl Harald
2011-06-13 00:44:36 UTC
Permalink
Post by Michal Schmidt
could not create /var/run/httpd/httpd.pid [Sun Jun 12 23:30:40 2011]
[error] httpd: could not log pid to file /var/run/httpd/httpd.pid
well this is the F14 build of Apache but shows me that i will go to
hell if the output of "service start" is no longer trustable as years
before
The F14 build does not have the necessary /etc/tmpfiles.d/httpd.conf
file to ensure /var/run/httpd is created on boot.
i am not merlin to build packages before upgrade
Post by Michal Schmidt
Running F14 packages on F15 is not expected to work. Don't do that.
i will not do that, my F15 package is built after that

but it shows that the widely use of "systemd" is too soon because
this crap has to say "FAILED" and not "OK" in this case!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/727bbcc0/attachment.bin
Michal Schmidt
2011-06-13 01:03:01 UTC
Permalink
Post by Reindl Harald
but it shows that the widely use of "systemd" is too soon because
this crap has to say "FAILED" and not "OK" in this case!
Apparently the httpd initscript returned with exit code 0.
A service can fail after starting successfully.

Michal
John Dulaney
2011-06-12 22:04:35 UTC
Permalink
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
No one is stopping you from packaging upstart (assuming someone hasn't done so) for F15.
Post by Reindl Harald
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
No one is forcing you to use F15
Post by Reindl Harald
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
If you're running that many servers, then why are you running Fedora? Considering
that Fedora has a stated mission to be the first to introduce new software and that
releases are only supported for thirteen months, would it not be wise to go with a
distribution that has a) more mature code and b) longer support?

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/529b8e2e/attachment.html
Reindl Harald
2011-06-12 22:21:47 UTC
Permalink
Post by John Dulaney
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
No one is stopping you from packaging upstart (assuming someone hasn't done so) for F15.
it is in the repos
and it is replaced by "systemd" via yum dist-upgrade
this is bullshit and should never happen by an upgrade
Post by John Dulaney
Post by Reindl Harald
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
No one is forcing you to use F15
not today but in some months

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/7df99844/attachment.bin
Christoph Wickert
2011-06-12 22:54:13 UTC
Permalink
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
systems upgraded with yum still have upstart installed (I did it myself)
and you can select the init as a kernel parameter, so obviously nobody
is forced.

Regards,
Christoph
Reindl Harald
2011-06-12 23:47:46 UTC
Permalink
Post by Christoph Wickert
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
systems upgraded with yum still have upstart installed (I did it myself)
and you can select the init as a kernel parameter, so obviously nobody
is forced.
my first test-setup had no upstart after upgrade
this was only a minimal-installation with RAID10 to look
if the RAID is alive after update to F15

the test-machine with the troubles was even not able to reboot after
yum-upgrade, after hard restart systemd meant it can not relabel
(the system was started with selinux=0 param) and not mount a volume

after found out how to ignore this a manual "mount /mnt/storage"
mounted the volume systemd meant it could not without any issue

forcing "upstart" gives error-messages while botting about /sys and /
Post by Christoph Wickert
Dateisysteme pr?fen
/dev/md1: sauber, 48557/1905008 Dateien, 477525/7607040 Bl?cke
/dev/md0: sauber, 38/128016 Dateien, 47146/511988 Bl?cke
[ OK ]
Root-Dateisystem mit Schreib- und Lesezugriff neu einh?ngen[ OK ]
mount: Laut mtab ist /dev/md1 schon auf / eingeh?ngt
Lokale Dateisysteme einh?ngen: [FEHLGESCHLAGEN]
this is a bad user experience and shows my that "systemd" had been better
delayed again for Fedora 16 to not repeat the bad things happended with
the way too early incldunfig of "pulseaudio" and "KDE4.0" AND we are
speaking here about the absolutely core-system and not a sound-daemon
or a desktop environment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/338464be/attachment.bin
Christoph Wickert
2011-06-13 15:30:30 UTC
Permalink
Post by Reindl Harald
Post by Christoph Wickert
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
systems upgraded with yum still have upstart installed (I did it myself)
and you can select the init as a kernel parameter, so obviously nobody
is forced.
my first test-setup had no upstart after upgrade
You did read the instructions about upgrading with yum and ran 'yum
distrosync', right?
Post by Reindl Harald
this is a bad user experience and shows my that "systemd" had been better
delayed again for Fedora 16 to not repeat the bad things happended with
the way too early incldunfig of "pulseaudio" and "KDE4.0" AND we are
speaking here about the absolutely core-system and not a sound-daemon
or a desktop environment
Please keep in mind that that one of Fedora's foundation is to be first.
Please read https://fedoraproject.org/wiki/Foundations

Both KDE 4 and pulseaudio were ready for inclusion when we first had
them in our distribution. Software is always changing, development never
stops. If you want to move on, you need to draw a line at some point and
put it into production in order to get wider feedback. Without this
feedback neither pulseaudio nor KDE would be where they are right now.

Fedora is a distribution for early adopters. If you really need the
latest kernel for your new hardware but also long term stability please
get an enterprise distribution.

Regards,
Christoph
Kevin Kofler
2011-06-13 04:01:40 UTC
Permalink
Post by Christoph Wickert
systems upgraded with yum still have upstart installed (I did it myself)
This has been fixed since:
https://bugzilla.redhat.com/show_bug.cgi?id=707507

Kevin Kofler
John Dulaney
2011-06-13 00:28:28 UTC
Permalink
Post by Reindl Harald
Post by John Dulaney
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
No one is stopping you from packaging upstart (assuming someone hasn't done so) for F15.
it is in the repos
and it is replaced by "systemd" via yum dist-upgrade
this is bullshit and should never happen by an upgrade
No, it does happen with upgrade. systemd is supposed to replace upstart
whenever an upgrade from F15 is installed. It is explicitly stated that systemd
is the default feature, and, as such, it will be installed by default. Therefore,
it should happen, and the fact that it does mean that it is working. Essentially,
if you do not want systemd, don't use Fedora 15. It is that simple.
Post by Reindl Harald
Post by John Dulaney
Post by Reindl Harald
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
No one is forcing you to use F15
not today but in some months
How so? How is it that in 'some months' you will be forced to use
systemd? Are the Chinese going to torture you until you make the
switch?

Why not go with another distro that does not use systemd, rather
than complaining on here and mommicking the rest of us? It really
seems that Fedora is not the distribution that fits your application.

John Dulaney

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/df46162e/attachment.html
Reindl Harald
2011-06-13 00:36:06 UTC
Permalink
Post by John Dulaney
Post by Reindl Harald
not today but in some months
How so? How is it that in 'some months' you will be forced to use
systemd? Are the Chinese going to torture you until you make the
switch?
F14 EOL?

No Kernel 2.6.38 while Kernel-Update in the support-cycle not so long ago
were absolutly normal - results in F14 bot supporting the Network-Card
of my new Workstation, the intel graphcics drivers in F14 are a joke

so F14 does not support my hardware because some release changes in the shorter past
F15 is a breakage in core-system
Post by John Dulaney
Why not go with another distro that does not use systemd, rather
than complaining on here and mommicking the rest of us? It really
seems that Fedora is not the distribution that fits your application.
I am using Fedora
* since "Fedora Core 3" in production
* since "Fedora Core 5" on Desktops
* since "Fedora 7" on VOIP Server
* since "Fedora 9" on all Web/Mail-Servers

and NOW it should be the wrong distribution?
other things you are dreaming about?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/7d219258/attachment.bin
Michal Schmidt
2011-06-13 00:38:29 UTC
Permalink
Post by Reindl Harald
* now see screenshot
That's probably
https://bugzilla.redhat.com/show_bug.cgi?id=709681
Post by Reindl Harald
* WTF is there to relabel if started with "selinux=0"-kernel-param
Although fedora-autorelabel.service is there, it does not imply that
anything is being relabeled.

Michal
Reindl Harald
2011-06-13 00:42:15 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
* now see screenshot
That's probably
https://bugzilla.redhat.com/show_bug.cgi?id=709681
Post by Reindl Harald
* WTF is there to relabel if started with "selinux=0"-kernel-param
Although fedora-autorelabel.service is there, it does not imply that
anything is being relabeled.
and why does it STOP the boot-process at a point no network is available?

i thought "systemd" is magic and does everytime know what is needed
why does it start the relabel service i never see with selinux=0
and break the system?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/c77a5481/attachment-0001.bin
Michal Schmidt
2011-06-13 00:56:55 UTC
Permalink
Post by Reindl Harald
and why does it STOP the boot-process at a point no network is
available?
Mounts from /etc/fstab are considered required unless they are marked
with the "nofail" option.
Post by Reindl Harald
why does it start the relabel service i never see with selinux=0
and break the system?
The relabel service was NOT started according to the screenshot. It was
"aborted".
When you manage to fix the mnt-storate.mount problem, it will not start
the relabel either. A condition for it to start will not be met.

Michal
Reindl Harald
2011-06-13 01:01:19 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
and why does it STOP the boot-process at a point no network is available?
Mounts from /etc/fstab are considered required unless they are marked
with the "nofail" option.
Post by Reindl Harald
why does it start the relabel service i never see with selinux=0
and break the system?
The relabel service was NOT started according to the screenshot. It was
"aborted".
When you manage to fix the mnt-storate.mount problem, it will not start
the relabel either. A condition for it to start will not be met
and because this systemd stopped booting in "emergency mode"
after root-pwd and "systemctl default" it finsihed starting

interesting: "mount /mnt/storage" manually works after that
exclude the mountpint in /etc/fstab results in normal boot
and you have everytime mount the LVM manually

you call this ready for endusers?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/f42c23fa/attachment.bin
Michal Schmidt
2011-06-13 01:26:51 UTC
Permalink
Post by Reindl Harald
Post by Michal Schmidt
Post by Reindl Harald
and why does it STOP the boot-process at a point no network is available?
Mounts from /etc/fstab are considered required unless they are
marked with the "nofail" option.
Post by Reindl Harald
why does it start the relabel service i never see with selinux=0
and break the system?
The relabel service was NOT started according to the screenshot. It
was "aborted".
When you manage to fix the mnt-storate.mount problem, it will not
start the relabel either. A condition for it to start will not be
met
and because this systemd stopped booting in "emergency mode"
after root-pwd and "systemctl default" it finsihed starting
Sorry, I am having trouble parsing this. Are you saying that
the relabel service was started then?
Post by Reindl Harald
interesting: "mount /mnt/storage" manually works after that
exclude the mountpint in /etc/fstab results in normal boot
and you have everytime mount the LVM manually
Have you looked at the bug I linked to?
Post by Reindl Harald
Post by Michal Schmidt
Post by Reindl Harald
https://bugzilla.redhat.com/show_bug.cgi?id=709681
Is it relevant for your situation?

Michal
Reindl Harald
2011-06-13 01:34:28 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
interesting: "mount /mnt/storage" manually works after that
exclude the mountpint in /etc/fstab results in normal boot
and you have everytime mount the LVM manually
Have you looked at the bug I linked to?
Post by Reindl Harald
Post by Michal Schmidt
https://bugzilla.redhat.com/show_bug.cgi?id=709681
Is it relevant for your situation?
Jesus christ - yes this can be the reason
can not try now because the machine is building
F15-RPMs for some hours now

THAN YKOU
i will review all /etc/fstab-configurations in a hurry

one reason more to switch not to "sytsemd" while upgarding and
get the needed "test-user-base" with new installations, so they
deal easier with "systemd" while existing users are not forced
to troubles

really - i love the idea of "sytemd" but not the way it is
introduced for existing users with perfectly working systems
and since i am developer as my amin-job a know really that
it is impossible to replace complex things without mistakes
and that is why i would never force a update this way

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/e3bef0ee/attachment.bin
Orcan Ogetbil
2011-06-13 02:14:27 UTC
Permalink
Post by Michal Schmidt
Have you looked at the bug I linked to?
Post by Michal Schmidt
https://bugzilla.redhat.com/show_bug.cgi?id=709681
Is it relevant for your situation?
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
Did we hurry too much to serve this plate to end users?

Orcan
Michal Schmidt
2011-06-13 06:48:45 UTC
Permalink
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
Strictly speaking, it parses the slash correctly and it's a bug
in /bin/mount. But I understand that's hardly a consolation for those
who are affected by this bug.

Michal
Reindl Harald
2011-06-13 07:18:44 UTC
Permalink
Post by Michal Schmidt
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
Strictly speaking, it parses the slash correctly and it's a bug
in /bin/mount. But I understand that's hardly a consolation for those
who are affected by this bug.
this is not a point of understand
"mount /mnt/storage" works and finds /mnt/storage/ in /etc/fstab
before upstart it worked for years, i even did not know that the slash
must not be at the end

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/4e3cda2c/attachment.bin
Orcan Ogetbil
2011-06-14 01:05:14 UTC
Permalink
Post by Michal Schmidt
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
Strictly speaking, it parses the slash correctly and it's a bug
in /bin/mount. But I understand that's hardly a consolation for those
who are affected by this bug.
Right, if it was working before and stopped working now, pointing
fingers at this point will not help the situation. Such a trivial
scenario could have been tested and fixed by the author of the code
before it was released to public. I hope this will stay as worst bug
in systemd (or triggered by systemd, however you want to put it).

Orcan
drago01
2011-06-14 07:25:30 UTC
Permalink
Post by Orcan Ogetbil
Post by Michal Schmidt
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
Strictly speaking, it parses the slash correctly and it's a bug
in /bin/mount. But I understand that's hardly a consolation for those
who are affected by this bug.
Right, if it was working before and stopped working now, pointing
fingers at this point will not help the situation. Such a trivial
scenario could have been tested and fixed by the author of the code
before it was released to public. I hope this will stay as worst bug
in systemd (or triggered by systemd, however you want to put it).
Well you can't expect him to test every possible scenario (no matter
how trivial it is). I never saw an fstab with a trailing slash so I
wouldn't have though about testing it either.
Jeff Spaleta
2011-06-14 13:15:27 UTC
Permalink
Post by drago01
Well you can't expect him to test every possible scenario (no matter
how trivial it is). I never saw an fstab with a trailing slash so I
wouldn't have though about testing it either.
Same here. I actually spent a good chunk of my _volunteer_ testing
time budget pre-release poking at systemd's capabilities for handling
auto mounting because I really want to make use of it... and I didn't
hit this bug. I guess I'm just conditioned to write my fstab entries
a certain way. And if I've been conditioned to write them a certain
way, it's not shocking that the mount command has an implicit
assumption about the format as well.

So in an effort to turn the corner of this and make a constructive discussion.

Is directory path handling with regard to trailing slashes something
worth adding as an autoQA test target in the future? Not just for
mount but for a group of commands? Something worth considering? I'm
happy to write the initial test script if this is something that makes
sense to try to automate.


-jef
Reindl Harald
2011-06-14 13:32:09 UTC
Permalink
Post by Jeff Spaleta
Is directory path handling with regard to trailing slashes something
worth adding as an autoQA test target in the future? Not just for
mount but for a group of commands? Something worth considering? I'm
happy to write the initial test script if this is something that makes
sense to try to automate.
i think this would be a good idea

PHP (my main language) is fighting with traling slash or not troubles
over all the years, but there is nothing to stop the boot-process and
systemd is a very different level of software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110614/f517911e/attachment.bin
Jeff Spaleta
2011-06-14 14:10:51 UTC
Permalink
Post by Reindl Harald
i think this would be a good idea
PHP (my main language) is fighting with traling slash or not troubles
over all the years, but there is nothing to stop the boot-process and
systemd is a very different level of software
Let's be clear...the bug was actually in mount...not systemd. And the
fix has been committed for the mount binary according the bug ticket
against the utils-linux package. So the problem has been solved very
quickly after the _correct_ developers were notified via the
established bug tracking mechanism.

And its a weird bug for mount...not what I would have expected.

Simple test outside of systemd for everyone falling along using a ntfs
disk I just happened to have.
First using an entry like this without a slash
/dev/sdb1 /mnt ntfs defaults 0 0

mount /mnt and mount /mnt/ both work and the drive mounts

Second using an entry like this with a slash
/dev/sdb1 /mnt/ ntfs defaults 0 0

mount /mnt fails to mount with an error and mount /mnt/ succeeds


What my very simple test shows is that this is totally inconsistent
behavior on the part of mount in handling trailing slashes or the lack
thereof. There's no good reason why that 1 failure should be
happening especially when clearly the mount binary is internally
manipulating trailing slashes in some cases. If it wasn't then I
should have gotten a failure in the first case.

Reindi,
If you want to be passionate and be upset about system breakage, that
is absolutely your right to do so. But I caution you that you are not
channeling your passion effectively. I hope in the future you budget
some time as a volunteer to be involved in the pre-release testing so
you can help catch problems prior to release. I also hope you learn
to be less aggressive when discussing issues with people with whom you
don't have an established working relationship.

And please, avoid prejudicing a new component of the software stack
when things like this happen. New code typically does a better job at
tickling implicit assumptions than experienced sysadmins and testers.
In this case, mount is broken, and has been broken for years, and
we've all been living with that brokenness and not realizing it
because we've conditioned ourselves to interact with mount in a way
that avoids the breakage. Please, lay the blame at the feet of the
correct piece of software. In this case the mount binary is behaving
inconsistently and has undocumented quirks that have gone unfixed for
YEARS until this bug was filed and fixed. FIXED...I can't stress that
enough...the fix has already been committed and we are just waiting
for packages now.

All systemd was doing was breaking an _undocumented_ _implicit_
_assumption_ that the mount command was using to map mount cmdline
mountpoints to fstab entry mountpoints. Mount was assuming that when
an fstab entry had a trailing slash then the mount cmdline mntpoint
argument would also have a trailing slash and mount was failing when
the trailing slash was missing in the cmdline argument. Is there a
good reason for mount to do this? I can't think of one so far noone
has defended mount's behavior in this regard. And as far as I know its
not a documented behavior of mount. And since its not documented there
was no reason that anyone (including the systemd authors) could know
that stripping the trailing slash when parsing the fstab entry would
cause mount to fail. Doubly so when the slash is missing mount
processes cmndline mountpoints with trailing slashes without issue.

Undocumented implicit assumptions are _bugs_ that cause all sorts of
problem up and down the software stack. Spending days and days and
days complaining about the piece of software that runs into such an
implicit assumption is not the way to work through the problem.
Identifying the software with the implicit assumption and either
getting it documented or fixed to behave in a consistent,
programmatic, robust manner is _always_ the proper way forward.

This will be my last response to you on any of these threads. And
while I understand why you are upset, and I respect your right to be
upset over this issue, I am extremely disappointed in the choices you
have made in expressing your opinions on the matter. I will not reward
you further with interaction and attention until such time that its
clear that you've learned how to tempter your emotion and can approach
discussion over problems with more humility and less aggression.

Good day,

-jef
Orcan Ogetbil
2011-06-14 14:32:47 UTC
Permalink
Post by Reindl Harald
i think this would be a good idea
PHP (my main language) is fighting with traling slash or not troubles
over all the years, but there is nothing to stop the boot-process and
systemd is a very different level of software
Let's be clear...the bug was actually in mount...not systemd. ?And the
fix has been committed for the mount binary according the bug ticket
against the utils-linux package. So the problem has been solved very
quickly after the _correct_ developers were notified via the
established bug tracking mechanism.
And its a weird bug for mount...not what I would have expected.
Simple test outside of systemd for everyone falling along using a ntfs
disk I just happened to have.
First using an entry like this without a slash
/dev/sdb1 ? ? ? ? ? ? ? /mnt ? ? ? ? ? ? ? ? ? ntfs ? ?defaults ? ? ? ?0 0
mount /mnt ?and mount /mnt/ ? both work and the drive mounts
Second using an entry like this with a slash
/dev/sdb1 ? ? ? ? ? ? ? /mnt/ ? ? ? ? ? ? ? ? ? ntfs ? ?defaults ? ? ? ?0 0
mount /mnt ?fails to mount with an error ?and mount /mnt/ ?succeeds
What my very simple test shows is that this is totally inconsistent
behavior on the part of mount in handling trailing slashes or the lack
thereof. ?There's no good reason why ?that 1 failure should be
happening especially when clearly the mount binary is internally
manipulating trailing slashes in some cases. If it wasn't then I
should have gotten a failure in the first case.
Reindi,
If you want to be passionate and be upset about system breakage, that
is absolutely your right to do so. ?But I caution you that you are not
channeling your passion effectively. ?I hope in the future you budget
some time as a volunteer to be involved in the pre-release testing so
you can help catch problems prior to release. ?I also hope you learn
to be less aggressive when discussing issues with people with whom you
don't have an established working relationship.
And please, avoid prejudicing a new component of the software stack
when things like this happen. New code typically does a better job at
tickling implicit assumptions than experienced sysadmins and testers.
In this case, mount is broken, and has been broken for years, and
we've all been living with that brokenness and not realizing it
because we've conditioned ourselves to interact with mount in a way
that avoids the breakage. ?Please, lay the blame at the feet of the
correct piece of software. ?In this case the mount binary is behaving
inconsistently and has undocumented quirks that have gone unfixed for
YEARS until this bug was filed and fixed. FIXED...I can't stress that
enough...the fix has already been committed and we are just waiting
for packages now.
All systemd was doing was breaking an _undocumented_ _implicit_
_assumption_ that the mount command was using to map mount cmdline
mountpoints to fstab entry mountpoints. ?Mount was assuming that when
an fstab entry had a trailing slash then the mount cmdline mntpoint
argument would also have a trailing slash and mount was failing when
the trailing slash was missing in the cmdline argument. ?Is there a
good reason for mount to do this? I can't think of one so far noone
has defended mount's behavior in this regard. And as far as I know its
not a documented behavior of mount. And since its not documented there
was no reason that anyone (including the systemd authors) could know
that stripping the trailing slash when parsing the fstab entry would
cause mount to fail. Doubly so when the slash is missing mount
processes cmndline mountpoints with trailing slashes without issue.
I understand the inconsistency and it is indeed a bug in mount.

Nevertheless you are missing the point. If X worked before (X=mounting
at boot with fstab containing trailing slashes), and stops working now
because of the change Y I made, I am responsible for fixing X or Y.
The question of 'which one contains the bug' is irrelevant for the
user. Some folks think that this is a corner case and it is easy to
miss. I think that this is a fundamental mistake and this should be
one of the first things a programmer should learn. It pretty much
compares a physicist forgetting F=ma. Well, we all do mistakes.

Unfortunately, it caused problems for at least a couple people.
Hopefully the programmer learned his lesson.

Orcan
Jeff Spaleta
2011-06-14 15:12:15 UTC
Permalink
Post by Orcan Ogetbil
I understand the inconsistency and it is indeed a bug in mount.
Nevertheless you are missing the point. If X worked before (X=mounting
at boot with fstab containing trailing slashes), and stops working now
because of the change Y I made,
I can't remember seeing ever seeing an fstab that uses trailing
slashes in an operational system that I've had access to. We don't
auto-generate trailing slash mount points entries in fstab. I didn't
even _think_ to test it when I was doing my due diligence for systemd
testing during pre-release. And since I know I'm smarter than
everyone involved with systemd development put together, it would be
unfair of me to expect them to have caught this

So why have I never seen a trailing slash on an operational fstab
mount point on a linux system? Why don't we generate trailing slash
mountpoints automatically in our default fstab config on install?
Most likely, because experienced sysadmins over the years have
probably conditioned themselves to avoid using trailing slash entries
because of mount's existing cmdline quirk and everyone's been too
busy/lazy to file the bug to get mount fixed. Until you run into it on
the cmdline yourself, its not noticable. And even then its easier to
just fix your custom mountpoints and remove the slash.
Post by Orcan Ogetbil
I am responsible for fixing X or Y.
Fixed.The utils-linux developers have fixed it very quickly once
someone actually filed a bug.
Post by Orcan Ogetbil
The question of 'which one contains the bug' is irrelevant for the
user.
Sure...I'm not saying otherwise. But this isn't a user list. This is a
devel list and we are having a discussion about development. From a
user perspective it just needs to get fixed...and it is going to get
fixed with an updated utils-linux as soon as possible. From a strict
user perspective problem solved.
Post by Orcan Ogetbil
Some folks think that this is a corner case and it is easy to
miss.
I didn't think to test it. Did you test it? There is no evidence
what-so-ever that anyone actually tested this prior to release. And as
far as I know the person who ran into this is the only person on the
planet who writes trailing slash fstab entries. And since we..in
Fedora...don't populate fstab entries by default in the install or
live images with trailing slashes there's no _expectation_ that this
will be tested as part of QA testing. I'm going to re-iterate that.
QA has finite resources and a narrowly defined testing mandate.
Syntax quirks of this nature which are not used in the install targets
will not be found prior to release without the help of people out in
the userbase who are willing to volunteer and test their real world
setups which diverge from the default configs.

If trailing slashes were so common as to not be thought of as a
corner-case then it is reasonable to assume someone would have hit
this prior to release and shouted about it on one of the lists. Didn't
happen.
Post by Orcan Ogetbil
I think that this is a fundamental mistake and this should be
one of the first things a programmer should learn. It pretty much
compares a physicist forgetting F=ma. Well, we all do mistakes.
Speaking as a PhD physicist who develops and maintains software for
experimental research that an international collaboration of PhD
physicists and students blindly rely on in order to do science without
being expected to understanding how the actual hardware or software
works in detail... I think you are very wrong.
Simply put, F=ma is well documented. Mount's slash handling behavior
is undocumented. If its undocumented behavior there is no expectation
that it can be tested or verified.
Post by Orcan Ogetbil
Unfortunately, it caused problems for at least a couple people.
Hopefully the programmer learned his lesson.
Sure a couple of people, who did not invest in the pre-release testing
process. I hope those couple of people learned their lesson.

-jef
Kevin Kofler
2011-06-13 07:08:02 UTC
Permalink
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?

Kevin Kofler
Michal Schmidt
2011-06-13 07:15:57 UTC
Permalink
Post by Kevin Kofler
How is it systemd's fault that the user's fstab is invalid?
A trailing slash in the mountpoint is not too common, but valid.

Michal
Reindl Harald
2011-06-13 07:21:33 UTC
Permalink
Post by Kevin Kofler
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?
sorry but you are an idiot!

this mountpoint existed before F15 and was no problem
release-ready software should not be too stupid for such things
and i am pretty sure that the trailing slash is no problem since
10 years and then came upstart in an early devel state and startet
to spit the uses in the face

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/75c04129/attachment.bin
Michal Schmidt
2011-06-13 07:25:52 UTC
Permalink
Stop the profanities and insults, or stop posting to this mailing
list.
Reindl Harald
2011-06-13 07:30:13 UTC
Permalink
Post by Michal Schmidt
Stop the profanities and insults, or stop posting to this mailing
list.
sorry but for a answer like below form Kevin Kofler i have no other
words as "idiot", really! where is defined taht it is invalid
and why only for systemd if it is so well designed and production
ready like some cowboys are thinking which decides for the rest
of the users too?

it is ALPHA software and some are not realizing that we are not
speaking about a sound-daemon stopping you hear music

we are speaking about the most important component of the system!
Post by Michal Schmidt
Post by Kevin Kofler
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/4b9935e2/attachment.bin
Kevin Kofler
2011-06-13 07:59:07 UTC
Permalink
and some are not realizing that we are not speaking about a sound-daemon
stopping you hear music
we are speaking about the most important component of the system!
That's exactly why we shouldn't let users replace it at random.

Kevin Kofler
Stephen John Smoogen
2011-06-13 15:39:02 UTC
Permalink
Post by Reindl Harald
Post by Michal Schmidt
Stop the profanities and insults, or stop posting to this mailing
list.
sorry but for a answer like below form Kevin Kofler i have no other
words as "idiot", really! where is defined taht it is invalid
and why only for systemd if it is so well designed and production
ready like some cowboys are thinking which decides for the rest
of the users too?
I do not regularly agree with Kevin Kofler, but you can call him what
you want in private email til the days are done. At this point I am
going to ask for someone from the Community Working Group to step in
and see how we can better get along here. If you have a problem with
that, I think it would be better if you took some time off and did
something else for a couple of hours/days.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
Matthew Garrett
2011-06-13 15:45:57 UTC
Permalink
Post by Stephen John Smoogen
I do not regularly agree with Kevin Kofler, but you can call him what
you want in private email til the days are done. At this point I am
going to ask for someone from the Community Working Group to step in
and see how we can better get along here. If you have a problem with
that, I think it would be better if you took some time off and did
something else for a couple of hours/days.
I've emailed Reindl privately to remind him of the standards of
behaviour we expect on mailing lists.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Kevin Fenzi
2011-06-13 15:55:45 UTC
Permalink
On Mon, 13 Jun 2011 16:45:57 +0100
Post by Matthew Garrett
Post by Stephen John Smoogen
I do not regularly agree with Kevin Kofler, but you can call him
what you want in private email til the days are done. At this point
I am going to ask for someone from the Community Working Group to
step in and see how we can better get along here. If you have a
problem with that, I think it would be better if you took some time
off and did something else for a couple of hours/days.
I've emailed Reindl privately to remind him of the standards of
behaviour we expect on mailing lists.
As have I.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/778cd56b/attachment.bin
Genes MailLists
2011-06-13 16:40:49 UTC
Permalink
On 06/13/2011 11:39 AM, Stephen John Smoogen wrote:
. At this point I am
Post by Stephen John Smoogen
going to ask for someone from the Community Working Group to step in
and see how we can better get along here. If you have a problem with
that, I think it would be better if you took some time off and did
something else for a couple of hours/days.
I agree - we can disagree on issues (technical, design or whatever)
but lets keep this discourse professional.

Sure, there are issues - there are and always will be - but tone it
down and try be constructive not destructive in communicating your
thoughts and concerns.

We all understand the emotions that hit you when things don't work
they way you want ... so contribute and help make it better - just
yelling and complaining about how -you- are impacted is not the way.

Be polite - be respectful ... be a partner with all the other
Fedorians (Fedorans? Fedoronians ? Fedoras ? Fedorafolks?)

You've had polite responses in varying degrees - take the cue - be
constructive even when being critical which is healthy if done right.


gene
Lucas
2011-06-13 07:26:46 UTC
Permalink
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
My opinion:

You know what was wrong, sir - you put on your 20 servers Fedora - free software.
And that means that you can't get personal support, because most of real developers are employees of
Redhat.
Have you notice that they use Fedora like a toy, to play with, to test a new ideas, to try new
things on it. Developers do not count it like anything serious - it is a toy for them. Today they
decided that upstart is wrong and they need systemd, tomorrow they can change their mind, they going
to implement btrfs soon. Fedora is a test toy. Do not expect any respect for the long time use. And
that is why linux is not so popular - it has always been a TOY and nothing more. Consider to use
something different for your server or solve your problems by your self.

Thanks.
Michal Schmidt
2011-06-13 07:37:34 UTC
Permalink
Post by Lucas
Have you notice that they use Fedora like a toy, to play with, to
test a new ideas, to try new things on it. Developers do not count it
like anything serious - it is a toy for them. Today they decided that
upstart is wrong and they need systemd, tomorrow they can change
their mind, they going to implement btrfs soon. Fedora is a test toy.
Do not expect any respect for the long time use. And that is why
linux is not so popular - it has always been a TOY and nothing more.
Consider to use something different for your server or solve your
problems by your self.
I disagree. Fedora is much more than a toy to me. I use it every day
for work. I hope it is the same for the most of the developers.

Michal
Reindl Harald
2011-06-13 07:40:46 UTC
Permalink
Post by Michal Schmidt
Post by Lucas
Have you notice that they use Fedora like a toy, to play with, to
test a new ideas, to try new things on it. Developers do not count it
like anything serious - it is a toy for them. Today they decided that
upstart is wrong and they need systemd, tomorrow they can change
their mind, they going to implement btrfs soon. Fedora is a test toy.
Do not expect any respect for the long time use. And that is why
linux is not so popular - it has always been a TOY and nothing more.
Consider to use something different for your server or solve your
problems by your self.
I disagree. Fedora is much more than a toy to me. I use it every day
for work. I hope it is the same for the most of the developers.
and if not they should be quickly sorted out before shortly after
systemd will get stable sooner or later the next one comes out
with a new replacement and all peopole forget how long sysvinit
worked very well and that this should be the measure for quality

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/866abd63/attachment.bin
Lucas
2011-06-13 07:57:10 UTC
Permalink
Post by Reindl Harald
Post by Michal Schmidt
Post by Lucas
Have you notice that they use Fedora like a toy, to play with, to
test a new ideas, to try new things on it. Developers do not count it
like anything serious - it is a toy for them. Today they decided that
upstart is wrong and they need systemd, tomorrow they can change
their mind, they going to implement btrfs soon. Fedora is a test toy.
Do not expect any respect for the long time use. And that is why
linux is not so popular - it has always been a TOY and nothing more.
Consider to use something different for your server or solve your
problems by your self.
I disagree. Fedora is much more than a toy to me. I use it every day
for work. I hope it is the same for the most of the developers.
and if not they should be quickly sorted out before shortly after
systemd will get stable sooner or later the next one comes out
with a new replacement and all peopole forget how long sysvinit
worked very well and that this should be the measure for quality
Also, be prepared - Fedora 13 end of life on 2011-06-24, next is yours Fedora 14 and it will be very
soon.
After that time no one will talk to you.
Alexander Kurtakov
2011-06-13 11:27:49 UTC
Permalink
Post by Lucas
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
You know what was wrong, sir - you put on your 20 servers Fedora - free
software. And that means that you can't get personal support, because most
of real developers are employees of Redhat.
Have you notice that they use Fedora like a toy, to play with, to test a
new ideas, to try new things on it. Developers do not count it like
anything serious - it is a toy for them. Today they decided that upstart
is wrong and they need systemd, tomorrow they can change their mind, they
going to implement btrfs soon. Fedora is a test toy. Do not expect any
respect for the long time use. And that is why linux is not so popular -
it has always been a TOY and nothing more. Consider to use something
different for your server or solve your problems by your self.
The generalization that we(Red Hat associates) see Fedora as a toy is
INSULTING.
Do you know how many of us are spending their free time to get Fedora better?
Do you know how many of us have worked on Fedora(or related things) before
working for Red Hat?
Do you know how big part of the Red Hat work is available in Fedora without
being available in RHEL?

Yes, we have opinions and we stick to them - most of the time without our
managers even know - because it's smth we do on our own. Speaking personally
everyone can accuse me of not fullfilling some user's wishes (which I'm not
oblided to do) but someone saying that I(we) look at Fedora as a toy is really
hurting a lot of feelings.

Alexander Kurtakov
Post by Lucas
Thanks.
Lucas
2011-06-13 12:23:51 UTC
Permalink
Post by Alexander Kurtakov
Post by Lucas
Post by Reindl Harald
PLEASE give us a option for systems upgraded with yum
NOT USING "systemd" and force "upstart" as before
* the system is running since years
* every dist-upgrade via yum was no problem
* now see screenshot
* WTF is there to relabel if started with "selinux=0"-kernel-param
WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE
THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER
ON UPDATES
I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING
FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START
IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS
You know what was wrong, sir - you put on your 20 servers Fedora - free
software. And that means that you can't get personal support, because most
of real developers are employees of Redhat.
Have you notice that they use Fedora like a toy, to play with, to test a
new ideas, to try new things on it. Developers do not count it like
anything serious - it is a toy for them. Today they decided that upstart
is wrong and they need systemd, tomorrow they can change their mind, they
going to implement btrfs soon. Fedora is a test toy. Do not expect any
respect for the long time use. And that is why linux is not so popular -
it has always been a TOY and nothing more. Consider to use something
different for your server or solve your problems by your self.
The generalization that we(Red Hat associates) see Fedora as a toy is
INSULTING.
Do you know how many of us are spending their free time to get Fedora better?
Do you know how many of us have worked on Fedora(or related things) before
working for Red Hat?
Do you know how big part of the Red Hat work is available in Fedora without
being available in RHEL?
Yes, we have opinions and we stick to them - most of the time without our
managers even know - because it's smth we do on our own. Speaking personally
everyone can accuse me of not fullfilling some user's wishes (which I'm not
oblided to do) but someone saying that I(we) look at Fedora as a toy is really
hurting a lot of feelings.
Alexander Kurtakov
Post by Lucas
Thanks.
What do you think I thought when found that udev was compiled:

* Fri May 20 2011 Harald Hoyer <harald at redhat.com> 170-1
- version 170
- removed /sbin/start_udev

REMOVED /sbin/start_udev - this means that upstart wont be able to start udev without manual tweak.
Upstart reads rc.sysinit and there is still "/sbin/start_udev". And also this means that any one
who will try to use upstart in Fedora 16 (now rawhide) wont get udev works.

What do you think I thought about all of this?
I wont be really upset if I'll lose upstart, I can clean systemd as I need, but the idea is wrong.
Systemd is just a project, project which may tomorrow be changed, so why all others have to follow.
It should be like selinux, which can be easily disabled "selinux=0".

That is what I think.
Michael Schwendt
2011-06-13 20:16:40 UTC
Permalink
Post by Lucas
I wont be really upset if I'll lose upstart, I can clean systemd as I need, but the idea is wrong.
Systemd is just a project, project which may tomorrow be changed,
And Upstart is not?
Post by Lucas
so why all others have to follow.
You also follow in many other similar situations when components are
replaced or upgraded, and you either cannot avoid that, or perhaps
sometimes you simply haven't noticed. Even normal applications sometimes
change fundamentally between version 1.0 and 2.0, causing interruptions,
affecting or interchanging their user-base.
Post by Lucas
It should be like selinux, which can be easily disabled "selinux=0".
That is what I think.
Not feasible. Where to start? Where to stop?

Only theoretically you can try to keep _everything_ alive (including but
not limited to forks, legacy software, abandonded APIs for previously
popular libs) and shipped with a distribution, but who will do all the
work (including the re-/testing)?
Kevin Kofler
2011-06-13 23:56:17 UTC
Permalink
Post by Lucas
REMOVED /sbin/start_udev - this means that upstart wont be able to start
udev without manual tweak. Upstart reads rc.sysinit and there is still
"/sbin/start_udev". And also this means that any one who will try to use
upstart in Fedora 16 (now rawhide) wont get udev works.
What do you think I thought about all of this?
That's exactly why I think it's a mistake to try to continue supporting
upstart.

Kevin Kofler
Steve Clark
2011-06-13 11:58:08 UTC
Permalink
Post by Kevin Kofler
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?
Kevin Kofler
Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff.
I get the impression Fedora doesn't care about users and is only interested in pushing the agenda
of the developers. It is too bad that Fedora doesn't have a reasonable benevolent dictator like
Linus.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/7507df7b/attachment.html
Emmanuel Seyman
2011-06-13 12:23:59 UTC
Permalink
Post by Steve Clark
Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff.
Linus has no such thing. Google the min/max incident and the amount of drivers
that were removed from the kernel tree before 2.4.0's release if you want proof.

Emmanuel
Steve Clark
2011-06-13 12:40:50 UTC
Permalink
Post by Emmanuel Seyman
Post by Steve Clark
Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff.
Linus has no such thing. Google the min/max incident and the amount of drivers
that were removed from the kernel tree before 2.4.0's release if you want proof.
Emmanuel
http://apcmag.com/linus_torvalds_on_regression_laziness_and_having_his_code_rejected.htm
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/f8c878a6/attachment.html
Rahul Sundaram
2011-06-13 13:02:43 UTC
Permalink
Post by Steve Clark
Post by Emmanuel Seyman
Post by Steve Clark
Maybe Fedora should adhere to Linus's rule that we don't have regressions that break users stuff.
Linus has no such thing. Google the min/max incident and the amount of drivers
that were removed from the kernel tree before 2.4.0's release if you want proof.
Emmanuel
http://apcmag.com/linus_torvalds_on_regression_laziness_and_having_his_code_rejected.htm
This article doesn't really justify your point. Reading LKML would
show you the reality. If you actually believe that any one person can
stop kernel regressions, that is remarkably naive and avoiding
regressions at the distribution level is many times more impossible
because of the number of components. We can make reasonable attempts to
avoid them. That's all.

Rahul
Rahul Sundaram
2011-06-13 12:50:44 UTC
Permalink
Post by Steve Clark
Maybe Fedora should adhere to Linus's rule that we don't have
regressions that break users stuff.
I get the impression Fedora doesn't care about users and is only
interested in pushing the agenda
of the developers. It is too bad that Fedora doesn't have a reasonable
benevolent dictator like
Linus.
Linux kernel routinely has many regressions that affect end users.
Kernel developers try to solve known regressions before the release and
so does Fedora. The problem with have distribution level dictators is
the potential for abuse of power. I don't think you want that. Atleast
in this case, the bug was actually filed long after the release and
hence wasn't a known regression that was ignored. I don't think you can
blame Fedora here.

Rahul
Adam Williamson
2011-06-17 01:49:43 UTC
Permalink
Post by Steve Clark
Post by Kevin Kofler
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?
Kevin Kofler
Maybe Fedora should adhere to Linus's rule that we don't have
regressions that break users stuff.
This is impossible. Every piece of software has bugs, hence every piece
of software also has regressions. Some of these 'break user stuff'.

You can't write categorical rules like this, because all software has
bugs. All you can do is set appropriate policies for prioritizing how
you fix those bugs. Significant regressions are generally fixed at quite
a high priority in Fedora, and that is the case here: the bug in
question was addressed quickly after it was reported.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Nicolas Mailhot
2011-06-17 06:00:04 UTC
Permalink
Post by Adam Williamson
Post by Steve Clark
Post by Kevin Kofler
Post by Orcan Ogetbil
Having a quick look at the link and at the steps to reproduce the bug
gave me shivers. Are we really sure that systemd is ready? I mean, I
don't even call my code "alpha" if it can't parse a slash correctly.
How is it systemd's fault that the user's fstab is invalid?
Kevin Kofler
Maybe Fedora should adhere to Linus's rule that we don't have
regressions that break users stuff.
This is impossible. Every piece of software has bugs, hence every piece
of software also has regressions. Some of these 'break user stuff'.
The actual Linus rule is that if it breaks user stuff it must be fixed
now or it will be reverted. Which is not impossible
--
Nicolas Mailhot
Rahul Sundaram
2011-06-17 06:31:47 UTC
Permalink
Post by Nicolas Mailhot
The actual Linus rule is that if it breaks user stuff it must be fixed
now or it will be reverted. Which is not impossible
If we know about the bugs we can fix them. This bug was only reported
after the release.

Rahul
Reindl Harald
2011-06-17 08:43:03 UTC
Permalink
Post by Rahul Sundaram
Post by Nicolas Mailhot
The actual Linus rule is that if it breaks user stuff it must be fixed
now or it will be reverted. Which is not impossible
If we know about the bugs we can fix them. This bug was only reported
after the release.
a needed TWO WEEKS to go in updates-testing, this is way roo long for
such a major bug preventing the user from booting the system and
it takes time until it is for normal users in stable repos too!

why this is a bug in "util-linux" i do not undertsand because
"mount /mnt/storage/" works - in the fstab is "/jmnt/storage/"

so why in the world is systemd calling mount without the trailing slash?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110617/e5ae1fad/attachment.bin
Rahul Sundaram
2011-06-17 10:03:21 UTC
Permalink
Post by Reindl Harald
a needed TWO WEEKS to go in updates-testing, this is way roo long for
such a major bug preventing the user from booting the system and
it takes time until it is for normal users in stable repos too!
It is not a major bug since it is not common for people to put a
trailing slash in the mount points. It was so uncommon that nobody even
hit it until the release and unless a mount point is specifically marked
as optional, it is expected behaviour that the system would stop
booting on a failed mount and it is not mandatory for any update to stay
in updates-testing for two weeks. If three testers to give positive
feedback, then it can be pushed to stable immediately.

Rahul

Ps: As many people have already told you in the same thread, caps =
shouting online and it is rude to do that. I request you to stop doing that
Karel Zak
2011-06-14 20:43:31 UTC
Permalink
Post by Michal Schmidt
Post by Reindl Harald
and why does it STOP the boot-process at a point no network is available?
Mounts from /etc/fstab are considered required unless they are marked
with the "nofail" option.
Is it backwardly compatible with traditional "mount -a"?

The "nofail" means "do not report errors for this device if it does
not exist".

The "mount -a" stops on fatal errors (e.g. ENOMEM) only.

Karel
--
Karel Zak <kzak at redhat.com>
http://karelzak.blogspot.com
Hans de Goede
2011-06-13 07:33:50 UTC
Permalink
Hi,

On 06/12/2011 11:23 PM, Reindl Harald wrote:

<snip>

May I point out that we've a be excellent to each other
policy on this mailing list. Your latest series of emails
seems to be anything but excellent, please stop this.

You're clearly unhappy about the switch to systemd,
my cents on that are that wrt the switch to systemd,
that ship has sailed. Fedora has made the move and I believe
a large majority of the Fedora users / contributors is in
favor of the move.

What you could do is give it a serious try and learn how
it works. I had to learn because of various issues with
iscsi initscripts which were not systemd's fault but did
get triggered by the move to systemd. It took me a while
but, once you get the hang of it, systemd is really nice.

Once you have seriously tried systemd we certainly welcome
constructive politely worded criticism. Preferably through
filing high quality (so what all needed info included) bugs
in bugzilla.

Regards,

Hans
Continue reading on narkive:
Loading...