6:54 a.m.
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very
very small minority of Fedora users.
Comments?
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
7:15 a.m.
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very
very small minority of Fedora users.
Comments?
Why does it matter to you? Why make this change, which will
at best inconvenience that very small minority of Feedora users.?
If it is maintained, and works then it should stay.
7:25 a.m.
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
> I'd like to remove:
> ddate - converts Gregorian dates to Discordian dates
> command from rawhide (F17). IMHO this crazy command is used by very
> very small minority of Fedora users.
> Comments?
Why does it matter to you? Why make this change, which will
at best inconvenience that very small minority of Feedora users.?
If it is maintained, and works then it should stay.
+1. I don't use vim or rythmbox or play tremulous, and their presence
doesn't hurt me or my mirror. :)
-J
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
7:34 a.m.
On Mon, 29 Aug 2011 07:25:18 -0500, JC (Jon) wrote:
> On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote:
>> I'd like to remove:
>> ddate - converts Gregorian dates to Discordian dates
>
>> command from rawhide (F17). IMHO this crazy command is used by very
>> very small minority of Fedora users.
>> Comments?
>
> Why does it matter to you? Why make this change, which will
> at best inconvenience that very small minority of Feedora users.?
>
> If it is maintained, and works then it should stay.
+1. I don't use vim or rythmbox or play tremulous, and their presence
doesn't hurt me or my mirror. :)
$ rpm -qf /usr/bin/ddate
util-linux-2.19.1-1.4.fc15.x86_64
As such it is part of every installation. It could be optional instead.
$ man ddate
[...]
|NOTE
| After `X-Day' passed without incident, the Church of the SubGenius
| declared that it had got the year upside down - X-Day is actually in
| 8661 AD rather than 1998 AD. Thus, the True X-Day is Cfn 40, 9827.
[...]
Strange humor to install something like that in a util-linux package.
7:42 a.m.
On 08/29/2011 02:54 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very
very small minority of Fedora users.
Comments?
Please do. This isn't really something that should be dragged in for
every single Fedora installation as part of the util-linux package. If
someone actually misses the command, it can always be resurrected later
in a subpackage.
--
Kalev
8:05 a.m.
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
On 08/29/2011 02:54 PM, Karel Zak wrote:
>
> I'd like to remove:
>
> ddate - converts Gregorian dates to Discordian dates
>
> command from rawhide (F17). IMHO this crazy command is used by very
> very small minority of Fedora users.
>
> Comments?
Please do. This isn't really something that should be dragged in for
every single Fedora installation as part of the util-linux package. If
someone actually misses the command, it can always be resurrected later
in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that
person will volunteers as the maintainer of a separate package then?
Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or
a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable:
|
| Comic book art files
| Religious texts
| ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
8:32 a.m.
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
> On 08/29/2011 02:54 PM, Karel Zak wrote:
> >
> > I'd like to remove:
> >
> > ddate - converts Gregorian dates to Discordian dates
> >
> > command from rawhide (F17). IMHO this crazy command is used by very
> > very small minority of Fedora users.
> >
> > Comments?
>
> Please do. This isn't really something that should be dragged in for
> every single Fedora installation as part of the util-linux package. If
> someone actually misses the command, it can always be resurrected later
> in a subpackage.
Someone? A single Discordian follower already, for example? Perhaps that
person will volunteers as the maintainer of a separate package then?
Or wait, if it's just one, why include it in the distribution?
Based on
http://en.wikipedia.org/wiki/Discordianism
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
http://en.wikipedia.org/wiki/Church_of_the_SubGenius
the ddate command and its manual's level of relationship to a religion (or
a joke religion) enters a grey area with regard to the packaging policies:
| Some examples of content which are not permissable:
|
| Comic book art files
| Religious texts
| ...
https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
-J
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
8:39 a.m.
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote:
> On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
>
>> On 08/29/2011 02:54 PM, Karel Zak wrote:
>> >
>> > I'd like to remove:
>> >
>> > ddate - converts Gregorian dates to Discordian dates
>> >
>> > command from rawhide (F17). IMHO this crazy command is used by very
>> > very small minority of Fedora users.
>> >
>> > Comments?
>>
>> Please do. This isn't really something that should be dragged in for
>> every single Fedora installation as part of the util-linux package. If
>> someone actually misses the command, it can always be resurrected later
>> in a subpackage.
>
> Someone? A single Discordian follower already, for example? Perhaps that
> person will volunteers as the maintainer of a separate package then?
> Or wait, if it's just one, why include it in the distribution?
>
> Based on
>
> http://en.wikipedia.org/wiki/Discordianism
> http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
> http://en.wikipedia.org/wiki/Church_of_the_SubGenius
>
> the ddate command and its manual's level of relationship to a religion (or
> a joke religion) enters a grey area with regard to the packaging policies:
>
> | Some examples of content which are not permissable:
> |
> | Comic book art files
> | Religious texts
> | ...
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate"
also
in "man date"?
8:47 a.m.
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote:
>
> > On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
> >
> >> On 08/29/2011 02:54 PM, Karel Zak wrote:
> >> >
> >> > I'd like to remove:
> >> >
> >> > ddate - converts Gregorian dates to Discordian dates
> >> >
> >> > command from rawhide (F17). IMHO this crazy command is used by
> very
> >> > very small minority of Fedora users.
> >> >
> >> > Comments?
> >>
> >> Please do. This isn't really something that should be dragged in for
> >> every single Fedora installation as part of the util-linux package.
> If
> >> someone actually misses the command, it can always be resurrected
> later
> >> in a subpackage.
> >
> > Someone? A single Discordian follower already, for example? Perhaps
> that
> > person will volunteers as the maintainer of a separate package then?
> > Or wait, if it's just one, why include it in the distribution?
> >
> > Based on
> >
> > http://en.wikipedia.org/wiki/Discordianism
> > http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
> > http://en.wikipedia.org/wiki/Church_of_the_SubGenius
> >
> > the ddate command and its manual's level of relationship to a religion
> (or
> > a joke religion) enters a grey area with regard to the packaging
> policies:
> >
> > | Some examples of content which are not permissable:
> > |
> > | Comic book art files
> > | Religious texts
> > | ...
> >
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
>
> The Julian and Gregorian calendars are also of religious origin.
Apples and oranges.
Do you find anything like in the "SEE ALSO" section of "man ddate"
also
in "man date"?
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
That may be (both are human constructs, it's like say "hey, that's
made up
word!", but no, I don't. My point is simply that while it is extremely
silly code, it is in fact code provided by upstream. It's still
maintained, is of a valid license, and I don't see a valid reason to break
with upstream here. If you can convince upstream to split it out or drop
it, great. If not, and there isn't a compelling disk space or security
argument, I really don't see why this should be dropped. I'm looking for
a clear example of demonstrable harm. It's 14k of silliness, not a
rootkit.
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
10 a.m.
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
That may be (both are human constructs, it's like say "hey,
that's made up
word!", but no, I don't. My point is simply that while it is extremely
silly code, it is in fact code provided by upstream. It's still
maintained, is of a valid license, and I don't see a valid reason to break
with upstream here. If you can convince upstream to split it out or drop
it, great.
That's simple, I'm upstream maintainer. The command has been disabled
by default in the last stable release. And yes, one I day I'll drop it...
If not, and there isn't a compelling disk space or security
argument, I really don't see why this should be dropped. I'm looking for
a clear example of demonstrable harm. It's 14k of silliness, not a
rootkit.
- it's joke rather than anything useful
- it's installed on all systems, but almost nobody uses this crap
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
10:14 a.m.
On 08/29/2011 05:00 PM, Karel Zak wrote:
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
> That may be (both are human constructs, it's like say "hey, that's made
up
> word!", but no, I don't. My point is simply that while it is extremely
> silly code, it is in fact code provided by upstream. It's still
> maintained, is of a valid license, and I don't see a valid reason to break
> with upstream here. If you can convince upstream to split it out or drop
> it, great.
That's simple, I'm upstream maintainer. The command has been disabled
by default in the last stable release. And yes, one I day I'll drop it...
> If not, and there isn't a compelling disk space or security
> argument, I really don't see why this should be dropped. I'm looking for
> a clear example of demonstrable harm. It's 14k of silliness, not a
> rootkit.
- it's joke rather than anything useful
Then have upstream remove it from
_their_ sources.
Ralf
10:25 a.m.
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote:
> That may be (both are human constructs, it's like say "hey, that's made
> up
> word!", but no, I don't. My point is simply that while it is extremely
> silly code, it is in fact code provided by upstream. It's still
> maintained, is of a valid license, and I don't see a valid reason to
> break
> with upstream here. If you can convince upstream to split it out or
> drop
> it, great.
That's simple, I'm upstream maintainer. The command has been disabled
by default in the last stable release. And yes, one I day I'll drop it...
> If not, and there isn't a compelling disk space or security
> argument, I really don't see why this should be dropped. I'm looking
> for
> a clear example of demonstrable harm. It's 14k of silliness, not a
> rootkit.
- it's joke rather than anything useful
- it's installed on all systems, but almost nobody uses this crap
Really? How do you know that?
-J
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
10:03 a.m.
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote:
>> The Julian and Gregorian calendars are also of religious
origin.
>
> Apples and oranges.
>
> Do you find anything like in the "SEE ALSO" section of "man
ddate" also
> in "man date"?
That may be (both are human constructs, it's like say "hey,
that's made up
word!", but no, I don't. My point is simply that while it is extremely
silly code, it is in fact code provided by upstream. It's still
maintained, is of a valid license, and I don't see a valid reason to break
with upstream here. If you can convince upstream to split it out or drop
it, great. If not, and there isn't a compelling disk space or security
argument, I really don't see why this should be dropped. I'm looking for
a clear example of demonstrable harm. It's 14k of silliness, not a
rootkit.
With that point of view, it's probably impossible to convince you.
I won't try. I just encourage Karel to get rid of ddate somehow.
A "valid reason" IMO is to build a base distribution, a product -- our
product -- which does not consist of "extremely silly code" and which
does not advertise dubious religions. Not even with links as found in the
manual. There are several scenarios where we divert from upstream due
to various circumstances.
Whether it's harmful to distribute ddate, I don't know. Isn't it enough
reason to not offer something because it's considered silly/crazy crap?
Or if it doesn't make sense to ship it as part of a default OS environment?
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
| Most common Linux operating system-distributions have the command ddate
| to show the current Discordian date.
Strange people these Linux people.
http://en.wikipedia.org/wiki/Discordian_calendar#Implementations
| ddate, a program that prints the current date in the Discordian calendar,
| is part of the util-linux package of basic system utilities.[6] As such,
| it is included in nearly all Linux distributions, despite some
| resistance.[7] There are many other programs with similar functionality.
-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321
10:27 a.m.
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote:
> >> The Julian and Gregorian calendars are also of religious origin.
> >
> > Apples and oranges.
> >
> > Do you find anything like in the "SEE ALSO" section of "man
ddate"
> also
> > in "man date"?
> That may be (both are human constructs, it's like say "hey, that's made
> up
> word!", but no, I don't. My point is simply that while it is extremely
> silly code, it is in fact code provided by upstream. It's still
> maintained, is of a valid license, and I don't see a valid reason to
> break
> with upstream here. If you can convince upstream to split it out or
> drop
> it, great. If not, and there isn't a compelling disk space or security
> argument, I really don't see why this should be dropped. I'm looking
> for
> a clear example of demonstrable harm. It's 14k of silliness, not a
> rootkit.
With that point of view, it's probably impossible to convince you.
I won't try. I just encourage Karel to get rid of ddate somehow.
A "valid reason" IMO is to build a base distribution, a product -- our
product -- which does not consist of "extremely silly code" and which
does not advertise dubious religions. Not even with links as found in the
manual. There are several scenarios where we divert from upstream due
to various circumstances.
Sure, for sufficient reasons.
Whether it's harmful to distribute ddate, I don't know.
Isn't it enough
reason to not offer something because it's considered silly/crazy crap?
Or if it doesn't make sense to ship it as part of a default OS
environment?
I'm not suggesting ddate is mission-critical, I just want reasons for it's
removal or re-packaging to be well thought-out, not simply "gosh, I don't
sue that, so. . .". Otherwise we'll start dropping games.
http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
| Most common Linux operating system-distributions have the command ddate
| to show the current Discordian date.
Strange people these Linux people.
http://en.wikipedia.org/wiki/Discordian_calendar#Implementations
| ddate, a program that prints the current date in the Discordian
calendar,
| is part of the util-linux package of basic system utilities.[6] As such,
| it is included in nearly all Linux distributions, despite some
| resistance.[7] There are many other programs with similar functionality.
-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:09 a.m.
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote:
I'm not suggesting ddate is mission-critical, I just want reasons
for it's
removal or re-packaging to be well thought-out, not simply "gosh, I don't
sue that, so. . .". Otherwise we'll start dropping games.
Sure (and not limited to games, which are in optional packages, however).
We do that all the time, if a package maintainer no longer considers
a game (or package in general) worthwhile, and if nobody else volunteers
to take over a package. Of course, you're free to adapt as many orphans
as you like, whether actively maintained upstream or ancient.
Eventually, you'll be in the same situation, where you would like to
drop something, be it a completely optional package or a plugin [*] you
consider useless, close to useless, or just broken. [*] or a program
with alternative user-interfaces
11:25 a.m.
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote:
> I'm not suggesting ddate is mission-critical, I just want reasons for
> it's
> removal or re-packaging to be well thought-out, not simply "gosh, I
> don't
> sue that, so. . .". Otherwise we'll start dropping games.
Sure (and not limited to games, which are in optional packages, however).
We do that all the time, if a package maintainer no longer considers
a game (or package in general) worthwhile, and if nobody else volunteers
to take over a package. Of course, you're free to adapt as many orphans
as you like, whether actively maintained upstream or ancient.
Eventually, you'll be in the same situation, where you would like to
drop something, be it a completely optional package or a plugin [*] you
consider useless, close to useless, or just broken. [*] or a program
with alternative user-interfaces
Absolutely! I've been there. It's not the retirement of software I
object to in this case, though I prefer to avoid that, it's the arbitrary
deviation from upstream. If the deviation isn't arbitrary, I generally
support it.
All that aside, I'd be sad to see ddate go, but that's totally beside the
point. :)
-J
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
12:06 p.m.
On Mon, Aug 29, 2011 at 08:32:01AM -0500, Jon Ciesla wrote:
> On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote:
>
>> On 08/29/2011 02:54 PM, Karel Zak wrote:
>> >
>> > I'd like to remove:
>> >
>> > ddate - converts Gregorian dates to Discordian dates
>> >
>> > command from rawhide (F17). IMHO this crazy command is used by very
>> > very small minority of Fedora users.
>> >
>> > Comments?
>>
>> Please do. This isn't really something that should be dragged in for
>> every single Fedora installation as part of the util-linux package. If
>> someone actually misses the command, it can always be resurrected later
>> in a subpackage.
>
> Someone? A single Discordian follower already, for example? Perhaps that
> person will volunteers as the maintainer of a separate package then?
> Or wait, if it's just one, why include it in the distribution?
>
> Based on
>
> http://en.wikipedia.org/wiki/Discordianism
> http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar
> http://en.wikipedia.org/wiki/Church_of_the_SubGenius
>
> the ddate command and its manual's level of relationship to a religion (or
> a joke religion) enters a grey area with regard to the packaging policies:
>
> | Some examples of content which are not permissable:
> |
> | Comic book art files
> | Religious texts
> | ...
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The Julian and Gregorian calendars are also of religious origin.
OTOH including tiny programs that remind people that real religious
belief is nonsense has to be a good thing.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
9:32 a.m.
On Mon, Aug 29, 2011 at 11:06 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
OTOH including tiny programs that remind people that real religious
belief is nonsense has to be a good thing.
On the contrary, biting one's tongue instead of offering off-topic
gratuitous insults to fellow Fedorans has to b a good thing.
--
Jerry James
http://www.jamezone.org/
10:48 a.m.
Yes, it was a joke and off-topic for this list. (Not on my blog though ..)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
12:17 p.m.
New subject: [HEADS UP] Fedora OCaml link down
I was looking for stuff on your website and noticed that the Fedora
OCaml project link is down:
http://www.cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
12:43 p.m.
New subject: [HEADS UP] Fedora OCaml link down
On Wed, Aug 31, 2011 at 01:17:44PM -0400, Przemek Klosowski wrote:
I was looking for stuff on your website and noticed that the Fedora
OCaml project link is down:
http://www.cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Yes, this has unfortunately been broken for a while. It was running
on an old Debian machine that needed an urgent update and at the same
time I had to rebuild the wiki software, and TBH it was too much, I
just took the whole thing down.
Shame really though. Is there a way to get a nice summary of what
versions of package(s) are in Fedora, grouped by project (comps
group)?
This is what it used to look like:
http://web.archive.org/web/20100424032649/http://cocan.org/getting_starte...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
11:40 a.m.
2011-08-31 16:32 keltezéssel, Jerry James írta:
On Mon, Aug 29, 2011 at 11:06 AM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> OTOH including tiny programs that remind people that real religious
> belief is nonsense has to be a good thing.
On the contrary, biting one's tongue instead of offering off-topic
gratuitous insults to fellow Fedorans has to b a good thing.
<sarcarm_mode>
How about removing fortune-mod as well in one go?
A lot of its quotes can be offending to some people.
</sarcasm_mode>
Best regards,
Zoltán Böszörményi
8:55 a.m.
On 08/29/2011 05:24 PM, Karel Zak wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very
very small minority of Fedora users.
Comments?
IIRC, you are upstream for this and could do this change upstream and
then, there wouldn't be a debate about this here. Otherwise, make
ddate a sub package and don't install it by default. Solved?
Rahul
9 a.m.
On 08/29/2011 05:24 PM, Karel Zak wrote:
> I'd like to remove:
>
> ddate - converts Gregorian dates to Discordian dates
>
> command from rawhide (F17). IMHO this crazy command is used by very
> very small minority of Fedora users.
>
> Comments?
IIRC, you are upstream for this and could do this change upstream and
then, there wouldn't be a debate about this here. Otherwise, make
ddate a sub package and don't install it by default. Solved?
Acceptable to me, but is the extra metadata for another RPM worth the
space savings?
-J
Rahul
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
9:20 a.m.
Once upon a time, Jon Ciesla <limb(a)jcomserv.net> said:
> On 08/29/2011 05:24 PM, Karel Zak wrote:
> IIRC, you are upstream for this and could do this change upstream and
> then, there wouldn't be a debate about this here. Otherwise, make
> ddate a sub package and don't install it by default. Solved?
>
Acceptable to me, but is the extra metadata for another RPM worth the
space savings?
Is that why this is being done? Space savings? On my F15 system,
ddate, the README, and the manual pages account for 22k.
If space is the justification, there's lots of better places to start.
Why does util-linux have two floppy disk formatters (/usr/bin/floppy and
/usr/sbin/fdformat)? How many tools do we really need for partitioning
disks and managing partitions (util-linux has fdisk, sfdisk, cfdisk,
partx, blockdev, all with associated documentation)?
Note: I am NOT saying any of that should be removed. I'm just saying
that "space savings" as justification of removing ddate is stupid.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:37 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote:
Why does util-linux have two floppy disk formatters (/usr/bin/floppy
and
/usr/sbin/fdformat)?
Why does it have any floppy tools any more? The kernel maintainers don't
support the floppy module and the module hasn't been auto-loaded for
several releases.
9:44 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote:
> Why does util-linux have two floppy disk formatters (/usr/bin/floppy and
> /usr/sbin/fdformat)?
Why does it have any floppy tools any more? The kernel maintainers don't
support the floppy module and the module hasn't been auto-loaded for
several releases.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Because there are still people with floppy drives?
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
9:58 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Mon, Aug 29, 2011 at 09:44:33AM -0500, Jon Ciesla wrote:
Because there are still people with floppy drives?
+1
It's ridiculous to think that older HW doesn't exist because systems
with that HW are not sold anymore (I don't even know id the latter
is true at all -- some special purpose systems might still have it).
We just have to wait till people come up with the argument that serial
or parallel ports don't exist anymore.
Don't let us all fall in the GNOME3 trap (assuming that all hardware
now has accelerated graphics support, which is even more ridiculous,
although GNOME3 has become useless for most people I know anyway).
Sorry, I couldn't resist...
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
10:13 a.m.
New subject: floppy support
Jos Vos wrote:
We just have to wait till people come up with the argument that
serial
or parallel ports don't exist anymore.
No. You're making an apples to orange comparison. Just like Jon has done
this whole thread.
This bike shedding as gone on long enough.
Remove ddate. Karel, you're upstream. Do it.
P.S. Your argument will be moot when the kernel drops the floppy module.
10:31 a.m.
New subject: floppy support
Jos Vos wrote:
> We just have to wait till people come up with the argument that serial
> or parallel ports don't exist anymore.
No. You're making an apples to orange comparison. Just like Jon has done
this whole thread.
This bike shedding as gone on long enough.
Playing devil's advocate != bikeshedding. But, I agree that this
discussion is aging rapidly.
Remove ddate. Karel, you're upstream. Do it.
Now *this* makes sense. I never advocated ddate being preserved in lucite
forevermore. I just wanted a sane reason to deviate from upstream. if
upstream drops it, the point is moot, and I think that's fine.
P.S. Your argument will be moot when the kernel drops the floppy
module.
Is there actually a plan for this to happen? Curious, not arguing here.
-J
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
1:41 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Mon, 2011-08-29 at 16:58 +0200, Jos Vos wrote:
Don't let us all fall in the GNOME3 trap (assuming that all
hardware
now has accelerated graphics support, which is even more ridiculous,
although GNOME3 has become useless for most people I know anyway).
GNOME 3 does not do that. It has an entire alternative shell - the
fallback mode - which exists expressly to support systems which cannot
run Shell.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:23 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote:
Chris Adams wrote:
> Why does util-linux have two floppy disk formatters (/usr/bin/floppy and
> /usr/sbin/fdformat)?
Why does it have any floppy tools any more?
because we still support floppy devices?
The kernel maintainers don't
support the floppy module and the module hasn't been auto-loaded for
several releases.
Does it mean that "modprobe floppy" does not work?
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
8:33 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Karel Zak wrote:
On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote:
> The kernel maintainers don't
> support the floppy module and the module hasn't been auto-loaded for
> several releases.
Does it mean that "modprobe floppy" does not work?
No, it means that (unless this was recently fixed) you have to modprobe it
manually (e.g. from rc.local) because nothing bothers trying to modprobe it
for you anymore. IMHO, this is really broken, but the bug reports about it
were ignored or declared NOTABUG.
Similarily, analog joystick support (yes, those joysticks you plug on the
MIDI ports of those old sound cards) also has to be modprobed manually.
And yes, I have all that stuff plugged on this machine. I barely ever use
it, but that doesn't mean I don't want it to work…
Kevin Kofler
10:22 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
No, it means that (unless this was recently fixed) you have to
modprobe it
manually (e.g. from rc.local) because nothing bothers trying to modprobe it
for you anymore. IMHO, this is really broken, but the bug reports about it
were ignored or declared NOTABUG.
It is very irritating, since I only use floppies when I really need to,
and usually I've upgraded the system (I typically do clean installs)
since the last time. I always have to stop and manually configure the
floppy drive again.
For a while, USB floppy drives got correctly configured when you plugged
them in (a udev rule was added to get /dev/floppy links and ownership),
but that was removed somewhere along the line. I own the package for
formatting floppies in USB drives (ufiformat), and it is also irritating
when I go test it for new releases. With changes over time, I don't
know how to get the device nodes with the correct access for the desktop
user anymore, and I figure if somebody went to the trouble of removing
the udev rules, there's not much point in asking to have them added
back.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:58 p.m.
New subject: floppy support
On 08/29/2011 10:22 PM, Chris Adams wrote:
It is very irritating, since I only use floppies when I really need
to,
Is this due to the need to boot into DOS to run a firmware utility or
something similar? If so, you can create a bootable, DOS USB flash
drive. I haven't had a need for a floppy disk in years.
12:06 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 1:58 PM, Michael Cronenworth <mike(a)cchtml.com>wrote:
On 08/29/2011 10:22 PM, Chris Adams wrote:
> It is very irritating, since I only use floppies when I really need to,
Is this due to the need to boot into DOS to run a firmware utility or
something similar? If so, you can create a bootable, DOS USB flash
drive. I haven't had a need for a floppy disk in years.
I can't see any reason for floppies these days considering their extreme
price per data unit as opposed to usb memory.
I don't flash much these days. And for times when I feel the need to, I go
about it by whatever other means is necessary to avoid anything to do with
floppies.
That's not to say that the Linux kernel should not support floppy drives.
That's an entirely different discussion really.
Regards
Chris Jones
[image: linux.png]
1:36 a.m.
New subject: floppy support
On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
I can't see any reason for floppies these days considering their
extreme
price per data unit as opposed to usb memory.
For some people the price of floppies is a sunk cost, or was never a cost at
all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years
ago, some at 0 price).
Unlike USB chips in most budgets, each floppy is cheap enough to be
disposable after one use or dedicated to one small file.
Floppies have enough room on them to write down something legible about their
content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz
brand AMI BIOS; etc.) which won't interfere with insertion or removal from
its reader.
Floppies are large enough to be much less likely than a USB stick to get lost
between couch cushions or fit through a pocket hole.
Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
A rude installer might unset a bootable flag or fail to install boot code in
the MBR of the only available internal storage, leaving the primary boot
device unbootable, and a floppy the only available device to boot from
without opening up the machine, if opening up is even any option at all.
IOW, poor as they are, floppies still have both advantages and uses.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
1:40 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata <mrmazda(a)earthlink.net> wrote:
On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
> I can't see any reason for floppies these days considering their extreme
> price per data unit as opposed to usb memory.
For some people the price of floppies is a sunk cost, or was never a cost at
all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years
ago, some at 0 price).
Unlike USB chips in most budgets, each floppy is cheap enough to be
disposable after one use or dedicated to one small file.
Floppies have enough room on them to write down something legible about their
content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz
brand AMI BIOS; etc.) which won't interfere with insertion or removal from
its reader.
Floppies are large enough to be much less likely than a USB stick to get lost
between couch cushions or fit through a pocket hole.
Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
A rude installer might unset a bootable flag or fail to install boot code in
the MBR of the only available internal storage, leaving the primary boot
device unbootable, and a floppy the only available device to boot from
without opening up the machine, if opening up is even any option at all.
CD/DVD ?
4:48 a.m.
New subject: floppy support
On Tue, 2011-08-30 at 08:40 +0200, drago01 wrote:
On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata
<mrmazda(a)earthlink.net> wrote:
> On 2011/08/30 15:06 (GMT+1000) Chris Jones composed:
>
>> I can't see any reason for floppies these days considering their extreme
>> price per data unit as opposed to usb memory.
>
> For some people the price of floppies is a sunk cost, or was never a cost at
> all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years
> ago, some at 0 price).
>
> Unlike USB chips in most budgets, each floppy is cheap enough to be
> disposable after one use or dedicated to one small file.
>
> Floppies have enough room on them to write down something legible about their
> content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz
> brand AMI BIOS; etc.) which won't interfere with insertion or removal from
> its reader.
>
> Floppies are large enough to be much less likely than a USB stick to get lost
> between couch cushions or fit through a pocket hole.
>
> Not everyone uses hardware with installed and functional OM, bootable USB or PXE.
>
> A rude installer might unset a bootable flag or fail to install boot code in
> the MBR of the only available internal storage, leaving the primary boot
> device unbootable, and a floppy the only available device to boot from
> without opening up the machine, if opening up is even any option at all.
CD/DVD ?
"Write Once Read Many"? Wait... "Write Once Read Once" in this case.
Not
cheap enough for that.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:30 a.m.
New subject: floppy support
On 2011/08/30 08:40 (GMT+0200) drago01 composed:
Felix Miata wrote:
> ...OM...
CD/DVD ?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
8:02 a.m.
New subject: floppy support
Once upon a time, Michael Cronenworth <mike(a)cchtml.com> said:
On 08/29/2011 10:22 PM, Chris Adams wrote:
> It is very irritating, since I only use floppies when I really need to,
Is this due to the need to boot into DOS to run a firmware utility or
something similar? If so, you can create a bootable, DOS USB flash
drive. I haven't had a need for a floppy disk in years.
That's nice that you haven't needed one, but I have. I try all kinds of
alternatives first (up to PXE booting syslinux to load memdisk and a
floppy image), but I have run into things that just really need an
actual floppy.
It isn't why I use floppies under Linux, but my mother's very expensive
computerized embroidery machine uses floppies to transfer patterns.
There are still things in the real world that exclusively use floppy
disks, and they aren't going away as rapidly as some seem to think.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:47 a.m.
New subject: floppy support
On 08/30/2011 08:02 AM, Chris Adams wrote:
There are still things in the real world that exclusively use floppy
disks, and they aren't going away as rapidly as some seem to think.
No need to tell me. I work everyday with SCO Unix machines that have no
idea what a USB device is. I've just found alternatives.
2:04 p.m.
New subject: floppy support
On 08/30/2011 09:02 AM, Chris Adams wrote:
It isn't why I use floppies under Linux, but my mother's very
expensive
computerized embroidery machine uses floppies to transfer patterns.
There are still things in the real world that exclusively use floppy
disks, and they aren't going away as rapidly as some seem to think.
I feel your pain; a lot of perfectly good lab equipment has floppies
too, but whenever practical, I'd recommend a USB floppy drive emulator
from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or
http://www.floppytousb.com/
2:18 p.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski <
przemek.klosowski(a)nist.gov> wrote:
I feel your pain; a lot of perfectly good lab equipment has floppies
too, but whenever practical, I'd recommend a USB floppy drive emulator
from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or
http://www.floppytousb.com/
I take it those usb based external floppy readers are auto-detected like
sane hardware should be?
-jef
2:20 p.m.
New subject: floppy support
On 08/30/2011 03:18 PM, Jef Spaleta wrote:
On Tue, Aug 30, 2011 at 11:04 AM, Przemek Klosowski
<przemek.klosowski(a)nist.gov <mailto:przemek.klosowski@nist.gov>> wrote:
I feel your pain; a lot of perfectly good lab equipment has floppies
too, but whenever practical, I'd recommend a USB floppy drive emulator
from ipcas or http://www.rioc.us/ufr-usb-floppy-replacement.php or
http://www.floppytousb.com/
I take it those usb based external floppy readers are auto-detected like
sane hardware should be?
They connect to the floppy cable and look like a floppy drive.
2:36 p.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski <
przemek.klosowski(a)nist.gov> wrote:
They connect to the floppy cable and look like a floppy drive.
Bah, I'd think you'd want to go the other way if you could get an external
usb based floppy reader which is autodetected on the usb bus. Anything that
hangs off the onboard floppy controller is going to need some lovin.
-jef
2:49 p.m.
New subject: floppy support
On 08/30/2011 03:36 PM, Jef Spaleta wrote:
On Tue, Aug 30, 2011 at 11:20 AM, Przemek Klosowski
<przemek.klosowski(a)nist.gov <mailto:przemek.klosowski@nist.gov>> wrote:
They connect to the floppy cable and look like a floppy drive.
Bah, I'd think you'd want to go the other way if you could get an
external usb based floppy reader which is autodetected on the usb bus.
Anything that hangs off the onboard floppy controller is going to need
some lovin.
Problem with the old equipment is that it often does not have USB or
indeed predates USB
2:53 p.m.
New subject: floppy support
Once upon a time, Jef Spaleta <jspaleta(a)gmail.com> said:
Bah, I'd think you'd want to go the other way if you could
get an external
usb based floppy reader which is autodetected on the usb bus. Anything that
hangs off the onboard floppy controller is going to need some lovin.
These are for embedded systems that use a standard PC-style floppy
controller. Replace the floppy drive with something else that still
looks to the system like a regular floppy drive.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:50 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 03:33:04 +0200,
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
No, it means that (unless this was recently fixed) you have to modprobe it
manually (e.g. from rc.local) because nothing bothers trying to modprobe it
for you anymore. IMHO, this is really broken, but the bug reports about it
were ignored or declared NOTABUG.
There was significant discussion about this issue on the mailing lists
and Kyle thought he had a good solution to having the floppy drive
recognized when it was there and not adding long delays to the boot up
for people with incorrectly configured (your supposed to disable the floppy
drive in the bios when you don't have one) or broken bios. I am not sure
what happened with the implementation of the solution.
Similarily, analog joystick support (yes, those joysticks you plug on the
MIDI ports of those old sound cards) also has to be modprobed manually.
I also have a gamepad which is like a joystick and need to do
modprobe analog to get it recognized.
7:41 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 03:33:04 +0200,
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>
> No, it means that (unless this was recently fixed) you have to modprobe it
> manually (e.g. from rc.local) because nothing bothers trying to modprobe it
> for you anymore. IMHO, this is really broken, but the bug reports about it
> were ignored or declared NOTABUG.
There was significant discussion about this issue on the mailing lists
and Kyle thought he had a good solution to having the floppy drive
recognized when it was there and not adding long delays to the boot up
for people with incorrectly configured (your supposed to disable the floppy
drive in the bios when you don't have one) or broken bios. I am not sure
what happened with the implementation of the solution.
ACPI turned out to be full of lies. The real problem is that machines
will report a floppy controller even if they have no floppy drives
attached, and the ACPI function that's supposed to return a list of
drives usually returns a mixture of falsehoods and untruths. Merely
havig a floppy controller is enough to get the floppy driver loaded,
which then hangs for ages looking for a drive.
The "easiest" solution would be to fix the floppy driver to probe in the
background but I suspect most people would prefer to empty biohazard
containers full of used needles by hand than touch floppy.c.
>
> Similarily, analog joystick support (yes, those joysticks you plug on the
> MIDI ports of those old sound cards) also has to be modprobed manually.
I also have a gamepad which is like a joystick and need to do
modprobe analog to get it recognized.
There's no way to get any feedback from the gameport driver as to (a)
whether there's anything plugged in, or (b) what is plugged in. We could
have the gameport driver automatically pull in analog but that'd
probably break people doing midi or using some more specialised input
device. It's a hard problem that only impacts a pretty tiny set of
people, so it's prioritised somewhere below the hard problems that
impact a pretty large set of people.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:31 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 13:41:57 +0100,
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
ACPI turned out to be full of lies. The real problem is that machines
will report a floppy controller even if they have no floppy drives
attached, and the ACPI function that's supposed to return a list of
drives usually returns a mixture of falsehoods and untruths. Merely
havig a floppy controller is enough to get the floppy driver loaded,
which then hangs for ages looking for a drive.
Thanks for the explanation.
There's no way to get any feedback from the gameport driver as to
(a)
whether there's anything plugged in, or (b) what is plugged in. We could
have the gameport driver automatically pull in analog but that'd
probably break people doing midi or using some more specialised input
device. It's a hard problem that only impacts a pretty tiny set of
people, so it's prioritised somewhere below the hard problems that
impact a pretty large set of people.
Again thanks for the explanation. I had figured gameports might be hard
to detect so I wasn't too worried about this. I did want to mention
what you needed to include on the modprobe command to get the the driver
loaded in case someone wandered accross the thread later.
8:20 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote:
On Tue, Aug 30, 2011 at 06:50:11AM -0500, Bruno Wolff III wrote:
> On Tue, Aug 30, 2011 at 03:33:04 +0200,
> Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> >
> > No, it means that (unless this was recently fixed) you have to modprobe it
> > manually (e.g. from rc.local) because nothing bothers trying to modprobe it
> > for you anymore. IMHO, this is really broken, but the bug reports about it
> > were ignored or declared NOTABUG.
>
> There was significant discussion about this issue on the mailing lists
> and Kyle thought he had a good solution to having the floppy drive
> recognized when it was there and not adding long delays to the boot up
> for people with incorrectly configured (your supposed to disable the floppy
> drive in the bios when you don't have one) or broken bios. I am not sure
> what happened with the implementation of the solution.
ACPI turned out to be full of lies. The real problem is that machines
will report a floppy controller even if they have no floppy drives
attached, and the ACPI function that's supposed to return a list of
drives usually returns a mixture of falsehoods and untruths. Merely
havig a floppy controller is enough to get the floppy driver loaded,
which then hangs for ages looking for a drive.
That seems like a clear opportunity to add a simple "configure legacy
hardware" button to anaconda, that would do the modprobe floppy/gameport
etc. stuff so it is loaded. Perhaps there could be switches: I have
these legacy hardware:
Floppy disk
Analog joystick
.... whatever
8:26 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 03:20:22PM +0200, Tomas Mraz wrote:
On Tue, 2011-08-30 at 13:41 +0100, Matthew Garrett wrote:
> ACPI turned out to be full of lies. The real problem is that machines
> will report a floppy controller even if they have no floppy drives
> attached, and the ACPI function that's supposed to return a list of
> drives usually returns a mixture of falsehoods and untruths. Merely
> havig a floppy controller is enough to get the floppy driver loaded,
> which then hangs for ages looking for a drive.
That seems like a clear opportunity to add a simple "configure legacy
hardware" button to anaconda, that would do the modprobe floppy/gameport
etc. stuff so it is loaded. Perhaps there could be switches: I have
these legacy hardware:
Floppy disk
Analog joystick
.... whatever
Or just add floppy-support and analog-joystick-support packages that
include appropriate modprobe.conf fragments, and have documentation that
instructs the user to install them.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:09 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:26:39 +0100,
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
Or just add floppy-support and analog-joystick-support packages that
include appropriate modprobe.conf fragments, and have documentation that
instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to
perhaps put floppy.conf or joystick.conf in /etc/modprode.d?
With a post install script to run modprobe manually?
Are pretty much all joysticks handled by analog or is that situation more
complicated?
8:37 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
On Tue, Aug 30, 2011 at 14:26:39 +0100,
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
>
> Or just add floppy-support and analog-joystick-support packages that
> include appropriate modprobe.conf fragments, and have documentation that
> instructs the user to install them.
To make this more precise, woulf the appropriate way to do this would be to
perhaps put floppy.conf or joystick.conf in /etc/modprode.d?
With a post install script to run modprobe manually?
That seems like it'd work.
Are pretty much all joysticks handled by analog or is that situation
more
complicated?
Most are. There are some devices that need their own drivers, and as far
as I know there's no defined PNP protocol for joysticks.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:23 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:37:16 +0100,
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
> On Tue, Aug 30, 2011 at 14:26:39 +0100,
> Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> >
> > Or just add floppy-support and analog-joystick-support packages that
> > include appropriate modprobe.conf fragments, and have documentation that
> > instructs the user to install them.
>
> To make this more precise, woulf the appropriate way to do this would be to
> perhaps put floppy.conf or joystick.conf in /etc/modprode.d?
> With a post install script to run modprobe manually?
That seems like it'd work.
I'll need to test it. Right now I use explicit modprobe commands in
rc.local, which isn't good for packages. I looked at modprobe.conf
documentation and it doesn't seem like it uses those files to determine
what to load, only what to do if it is loaded. So it may be that udev
is really the correct place to do things.
I'll investigate that. Once I know the right thing to do, the packaging
should be pretty easy.
8:50 a.m.
New subject: floppy support
On 30/08/11 14:23, Bruno Wolff III wrote:
I'll need to test it. Right now I use explicit modprobe commands
in
rc.local, which isn't good for packages. I looked at modprobe.conf
documentation and it doesn't seem like it uses those files to determine
what to load, only what to do if it is loaded. So it may be that udev
is really the correct place to do things.
Or modules-load.d if you want to force load a module.
tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:38 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 14:50:10 +0100,
Tom Hughes <tom(a)compton.nu> wrote:
On 30/08/11 14:23, Bruno Wolff III wrote:
> I'll need to test it. Right now I use explicit modprobe commands in
> rc.local, which isn't good for packages. I looked at modprobe.conf
> documentation and it doesn't seem like it uses those files to determine
> what to load, only what to do if it is loaded. So it may be that udev
> is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Thanks, that sounds better.
I'll add making packages to do this to my to do list. They should be pretty
easy to do, so there's a good chance I'll get to it soon. I'll add a comment
to the thread when I have something ready for review.
8:51 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
On 30/08/11 14:23, Bruno Wolff III wrote:
>I'll need to test it. Right now I use explicit modprobe commands in
>rc.local, which isn't good for packages. I looked at modprobe.conf
>documentation and it doesn't seem like it uses those files to determine
>what to load, only what to do if it is loaded. So it may be that udev
>is really the correct place to do things.
Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:49 a.m.
New subject: floppy support
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
> On 30/08/11 14:23, Bruno Wolff III wrote:
>
> >I'll need to test it. Right now I use explicit modprobe commands in
> >rc.local, which isn't good for packages. I looked at modprobe.conf
> >documentation and it doesn't seem like it uses those files to determine
> >what to load, only what to do if it is loaded. So it may be that udev
> >is really the correct place to do things.
>
> Or modules-load.d if you want to force load a module.
Oops. Yes, that's what I meant.
Is there a reason that (at least for the one case) this wouldn't just
go in the joystick package?
Bill
11:11 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote:
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
> > Or modules-load.d if you want to force load a module.
>
> Oops. Yes, that's what I meant.
Is there a reason that (at least for the one case) this wouldn't just
go in the joystick package?
Joystick seems to be part of the default install (it handles USB devices
as well as legacy ones), and we probably wouldn't want this by default.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:56 a.m.
New subject: floppy support
On Tue, 2011-08-30 at 17:11 +0100, Matthew Garrett wrote:
On Tue, Aug 30, 2011 at 11:49:37AM -0400, Bill Nottingham wrote:
> Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> > On Tue, Aug 30, 2011 at 02:50:10PM +0100, Tom Hughes wrote:
> > > Or modules-load.d if you want to force load a module.
> >
> > Oops. Yes, that's what I meant.
>
> Is there a reason that (at least for the one case) this wouldn't just
> go in the joystick package?
Joystick seems to be part of the default install (it handles USB devices
as well as legacy ones), and we probably wouldn't want this by default.
Yes,
but it could be a subpackage of it. No need to create new source
package for just this simple configuration file.
Tomáš Mráz
10:41 p.m.
New subject: floppy support
Below is a proposed specfile for the floppy case. (Analog joystick would be
very similar.) I haven't tested the package for functionality yet, but did
test it with rpmbuild and rpmlint. Is this what we want? Is this ready
for a formal review?
Name: floppy-support
Version: 1.0
Release: 1%{?dist}
Summary: Load floppy driver at boot time
Group: System Environment/Kernel
License: MIT
# The package is built just using this specfile.
#URL:
#Source0:
Requires(post): module-init-tools
BuildArch: noarch
%description
By default the floppy driver is not loaded at boot time. Installing this
package will load the floppy driver as part of the install and will set
things so that it will be loaded during future boots.
%prep
#No setup, since no source outside the specfile.
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%files
%{_libdir}/modules-load.d/floppy.conf
%post
/sbin/modprobe floppy
%changelog
* Tue Aug 30 2011 Bruno Wolff III <bruno(a)wolff.to> 1.0-1
- Initial package creation
4:39 a.m.
New subject: floppy support
Hi,
On 08/31/2011 05:41 AM, Bruno Wolff III wrote:
Below is a proposed specfile for the floppy case. (Analog joystick
would be
very similar.) I haven't tested the package for functionality yet, but did
test it with rpmbuild and rpmlint. Is this what we want?
I don't know about others, but I love it. Actually a constructive solution
to the problem being discussed, we could even put it in comps (as not enabled
by default) :)
Is this ready
for a formal review?
Putting it up for formal review gets my vote, but first lets see what other think
for a bit.
As always many thanks for you excellent and constructive work on Fedora.
Regards,
Hans
Name: floppy-support
Version: 1.0
Release: 1%{?dist}
Summary: Load floppy driver at boot time
Group: System Environment/Kernel
License: MIT
# The package is built just using this specfile.
#URL:
#Source0:
Requires(post): module-init-tools
BuildArch: noarch
%description
By default the floppy driver is not loaded at boot time. Installing this
package will load the floppy driver as part of the install and will set
things so that it will be loaded during future boots.
%prep
#No setup, since no source outside the specfile.
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
echo floppy> $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%files
%{_libdir}/modules-load.d/floppy.conf
%post
/sbin/modprobe floppy
%changelog
* Tue Aug 30 2011 Bruno Wolff III<bruno(a)wolff.to> 1.0-1
- Initial package creation
4:58 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 10:41:45PM -0500, Bruno Wolff III wrote:
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%{_sysconfdir} instead of %{_libdir} everywhere.
%files
%{_libdir}/modules-load.d/floppy.conf
Jakub
7:07 a.m.
New subject: floppy support
On Wed, Aug 31, 2011 at 11:58:41 +0200,
Jakub Jelinek <jakub(a)redhat.com> wrote:
On Tue, Aug 30, 2011 at 10:41:45PM -0500, Bruno Wolff III wrote:
> %install
> rm -rf $RPM_BUILD_ROOT
> mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
> echo floppy > $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%{_sysconfdir} instead of %{_libdir} everywhere.
> %files
> %{_libdir}/modules-load.d/floppy.conf
I am willing to do that, but before going there I want to not this passage
from the modules-load.d man page:
Packages
should install their configuration files in /usr/lib/, files in /etc/
are reserved for the local administration, which possibly decides to
overwrite the configurations installed from packages.
8:49 a.m.
New subject: floppy support
Once upon a time, Bruno Wolff III <bruno(a)wolff.to> said:
Below is a proposed specfile for the floppy case. (Analog joystick
would be
very similar.) I haven't tested the package for functionality yet, but did
test it with rpmbuild and rpmlint. Is this what we want? Is this ready
for a formal review?
That loads the module, but what about configuring device access for
desktop users? That's the more irritating part to me (that has changed
over time and I no longer know how to fix it). Once loaded, the floppy
device should be treated just like any other removable media device as
far as user access is concerned.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:28 a.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 22:41:45 -0500,
Bruno Wolff III <bruno(a)wolff.to> wrote:
Below is a proposed specfile for the floppy case. (Analog joystick
would be
very similar.) I haven't tested the package for functionality yet, but did
test it with rpmbuild and rpmlint. Is this what we want? Is this ready
for a formal review?
I tested this out and it seems to load the floppy module on install and
on boot. It does not trigger creating the /dev/floppy sym link and I am
not sure if anything affecting how the desktop treats floppies should
also be included. (I would think checking for inserted floppies would
be annoying in general and shouldn't be the default, but maybe there should
be something done to make them mountable by users by default.)
While it is possible to expand the scope a bit later (e.g. include a udev
rule in addition), I figured I'd check now to see if anyone had any suggestions
about additions before I submit it for review.
8:58 a.m.
New subject: floppy support
I have submitted a review request for floppy-support:
https://bugzilla.redhat.com/show_bug.cgi?id=735554
9:25 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:23, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Aug 30, 2011 at 14:37:16 +0100,
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote:
> > On Tue, Aug 30, 2011 at 14:26:39 +0100,
> > Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> > >
> > > Or just add floppy-support and analog-joystick-support packages that
> > > include appropriate modprobe.conf fragments, and have documentation that
> > > instructs the user to install them.
> >
> > To make this more precise, woulf the appropriate way to do this would be to
> > perhaps put floppy.conf or joystick.conf in /etc/modprode.d?
> > With a post install script to run modprobe manually?
>
> That seems like it'd work.
I'll need to test it. Right now I use explicit modprobe commands in
rc.local, which isn't good for packages. I looked at modprobe.conf
documentation and it doesn't seem like it uses those files to determine
what to load, only what to do if it is loaded. So it may be that udev
is really the correct place to do things.
I'll investigate that. Once I know the right thing to do, the packaging
should be pretty easy.
"man modules-load.d" looks promising too.
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
11:25 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Matthew Garrett wrote:
ACPI turned out to be full of lies. The real problem is that
machines
will report a floppy controller even if they have no floppy drives
attached, and the ACPI function that's supposed to return a list of
drives usually returns a mixture of falsehoods and untruths. Merely
havig a floppy controller is enough to get the floppy driver loaded,
which then hangs for ages looking for a drive.
I think it's sad that we're sacrificing hardware support for boot times.
We should probe for everything by default. Users who don't have a floppy
drive and want to save some boot time can blacklist the driver manually.
Kevin Kofler
noon
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 18:25 +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
> ACPI turned out to be full of lies. The real problem is that machines
> will report a floppy controller even if they have no floppy drives
> attached, and the ACPI function that's supposed to return a list of
> drives usually returns a mixture of falsehoods and untruths. Merely
> havig a floppy controller is enough to get the floppy driver loaded,
> which then hangs for ages looking for a drive.
I think it's sad that we're sacrificing hardware support for boot times.
We should probe for everything by default. Users who don't have a floppy
drive and want to save some boot time can blacklist the driver manually.
It seem much more intelligent to add a package owners of floppies can
install, so that 99.9% of the others do not have to wait forever for no
reason.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
2:13 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Simo Sorce wrote:
It seem much more intelligent to add a package owners of floppies
can
install, so that 99.9% of the others do not have to wait forever for no
reason.
This goes against the principle that Fedora should Just Work on any hardware
it encounters if at all possible.
Kevin Kofler
2:24 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 09:13:05PM +0200, Kevin Kofler wrote:
Simo Sorce wrote:
> It seem much more intelligent to add a package owners of floppies can
> install, so that 99.9% of the others do not have to wait forever for no
> reason.
This goes against the principle that Fedora should Just Work on any hardware
it encounters if at all possible.
There's plenty of hardware that Fedora could work on but doesn't because
the maintainers aren't willing to make the tradeoffs.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:26 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 21:13 +0200, Kevin Kofler wrote:
Simo Sorce wrote:
> It seem much more intelligent to add a package owners of floppies can
> install, so that 99.9% of the others do not have to wait forever for no
> reason.
This goes against the principle that Fedora should Just Work on any hardware
it encounters if at all possible.
I guess you need to define 'Just Work', and 'if at all possible'.
Making boot hang for long periods can easily be seen as 'Not working
properly' and therefore make default floppy support 'not possible'.
At least this is the reasoning I see and agree with.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
2:55 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce <simo(a)redhat.com> said:
Making boot hang for long periods can easily be seen as 'Not
working
properly' and therefore make default floppy support 'not possible'.
At least this is the reasoning I see and agree with.
How many systems are there that "hang forever" when the floppy module is
loaded? I have never seen that happen, on systems with or without
floppy drives, yet you seem to be saying it happens on vast numbers of
them (99.9% in an earlier message).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:01 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 14:55 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce <simo(a)redhat.com> said:
> Making boot hang for long periods can easily be seen as 'Not working
> properly' and therefore make default floppy support 'not possible'.
> At least this is the reasoning I see and agree with.
How many systems are there that "hang forever" when the floppy module is
loaded? I have never seen that happen, on systems with or without
floppy drives, yet you seem to be saying it happens on vast numbers of
them (99.9% in an earlier message).
Don't put words in my mouth that I have never said please.
I said:
A) 99.9% of users do not needed the floppy anymore
B) I said hang for "long periods" and not "forever", where here
"long"
is of course relative to modern machine boot times.
A and B are not related of course, and that was clear from the context.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:12 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce <simo(a)redhat.com> said:
I said:
A) 99.9% of users do not needed the floppy anymore
B) I said hang for "long periods" and not "forever", where here
"long"
is of course relative to modern machine boot times.
You said:
It seem much more intelligent to add a package owners of floppies can
install, so that 99.9% of the others do not have to wait forever for no
reason.
http://lists.fedoraproject.org/pipermail/devel/2011-August/156261.html
To me, that reads as "99.9% of non-floppy owners have to wait forever".
In any case, instead of arguing semantics, can you answer my actual
question? How many systems hang when floppy.ko is loaded? If it is a
large number, it should be easy to point to lots of data.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:17 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 2011-08-30 at 15:12 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce <simo(a)redhat.com> said:
> I said:
> A) 99.9% of users do not needed the floppy anymore
> B) I said hang for "long periods" and not "forever", where here
"long"
> is of course relative to modern machine boot times.
You said:
It seem much more intelligent to add a package owners of floppies can
install, so that 99.9% of the others do not have to wait forever for no
reason.
http://lists.fedoraproject.org/pipermail/devel/2011-August/156261.html
To me, that reads as "99.9% of non-floppy owners have to wait forever".
Ok, reasonable misunderstanding, I didn't mean it that way, sorry.
In any case, instead of arguing semantics, can you answer my actual
question? How many systems hang when floppy.ko is loaded? If it is a
large number, it should be easy to point to lots of data.
They do not 'hang', they just take longer to boot, sometimes a lot
longer. The point is that given most machines do not even ship with a
floppy drive anymore it seem entirely reasonable to spare the wait to
most users because they do not need that support anyway (and even most
of those who have a floppy driver do not use it ever). While for those
few that need it, then having to install a simple package to enable the
support by default seem sensible and good enough.
I don't think I have anything more to add to that.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:22 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce <simo(a)redhat.com> said:
They do not 'hang', they just take longer to boot, sometimes
a lot
longer.
How much longer? How many such machines? Again, I've booted systems
without floppy drives but with floppy support loaded, and I haven't seen
any significant hang.
Leaving known-working hardware unusable at install is just rude and
irritating when it is needed. There should be good justification, not
just "a bunch of developers don't use it anymore, so we don't think
anybody else needs it".
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:51 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote:
Leaving known-working hardware unusable at install is just rude and
irritating when it is needed. There should be good justification, not
just "a bunch of developers don't use it anymore, so we don't think
anybody else needs it".
+1
Kevin Kofler
4:37 a.m.
New subject: floppy support
Hi,
On 08/30/2011 10:22 PM, Chris Adams wrote:
Once upon a time, Simo Sorce<simo(a)redhat.com> said:
> They do not 'hang', they just take longer to boot, sometimes a lot
> longer.
How much longer?
Much much longer, when I was still on the anaconda team we had
numerous bug reports about this (esp during RHEL-6 testing), in many
cases people filed bugs with a description along the lines of:
"Installation DVD does not boot", because it took so long they thought
the install was just hanging forever.
How many such machines?
I've no hard numbers but enough to generate numerous bug reports
during the non public testing phase of RHEL-6 alone.
Also see:
https://bugzilla.redhat.com/show_bug.cgi?id=565693
https://bugzilla.redhat.com/show_bug.cgi?id=587909
https://bugzilla.redhat.com/show_bug.cgi?id=682426
http://lists.fedoraproject.org/pipermail/kernel/2010-April/002394.html
http://lists.fedoraproject.org/pipermail/kernel/2010-April/002420.html
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technic...
And search for "IBM ThinkPad T43 notebook"
Note this is in no way an exhaustive list of all bugs about this,
just something a really really quick search turned up.
Again, I've booted systems
without floppy drives but with floppy support loaded, and I haven't seen
any significant hang.
Yes the hang is not guaranteed to be there, or to take very long,
but often it is there, and sometimes it takes very long (which is
the real problematic case). If you're really interested in seeing this fixed
go talk to the kernel guys:
anaconda loads the floppy driver by default when booting of the install
DVD, because of driverdisk support, thus the anaconda team has been getting
its share of bug reports wrt this. But AFAIK there are no such issues
in RHEL-5, where we auto-load the floppy driver too, so something
has changed in the kernel causing the hang when no drive is attached to the
controller. I could swear I filed a bug against the kernel about this
regression, but I cannot find it.
Leaving known-working hardware unusable at install is just rude and
irritating when it is needed. There should be good justification, not
just "a bunch of developers don't use it anymore, so we don't think
anybody else needs it".
Is it delays bootup by up to 10-30 minutes on various modern systems
a good enough justification?
Regards,
Hans
8:47 a.m.
New subject: floppy support
Once upon a time, Hans de Goede <hdegoede(a)redhat.com> said:
anaconda loads the floppy driver by default when booting of the
install
DVD, because of driverdisk support, thus the anaconda team has been getting
its share of bug reports wrt this. But AFAIK there are no such issues
in RHEL-5, where we auto-load the floppy driver too, so something
has changed in the kernel causing the hang when no drive is attached to the
controller. I could swear I filed a bug against the kernel about this
regression, but I cannot find it.
So, it sounds like it is a kernel bug, and the "fix" was to just ignore
it and stop loading the module. <sigh>...
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:29 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 21:12, Chris Adams <cmadams(a)hiwaay.net> wrote:
In any case, instead of arguing semantics, can you answer my actual
question? How many systems hang when floppy.ko is loaded? If it is a
large number, it should be easy to point to lots of data.
Ok, just some very approximate stats for a group of approximately 50
computers i used to run (this was about 2 years ago and with various
linux distributions but i doubt floppy support varies much). The
computers with floppy drives enabled in the BIOS even though there was
no actual drive attached took mostly between 2 and 20 seconds longer
to boot. 2 of them (probably very broken controllers) actually took 2
minutes longer to boot. These extra boot times are far from being the
end of the world but certainly not worth inflicting on everyone to
satisfy the rare use from a tiny proportion of users.
I may be way wide of the mark but if floppy drives were enabled either
on demand or as a service in systemd could the module perhaps be
loaded later on during boot and in parallel with the rest of the boot.
That would make any potential hang completely irrelevant.
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
3:25 p.m.
New subject: floppy support
On 08/30/2011 03:55 PM, Chris Adams wrote:
How many systems are there that "hang forever" when the
floppy module is
loaded? I have never seen that happen, on systems with or without
floppy drives, yet you seem to be saying it happens on vast numbers of
them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember
those
sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the
floppy drive does a head seek during floppy controller init at boot.
3:28 p.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 04:25:18PM -0400, Przemek Klosowski wrote:
On 08/30/2011 03:55 PM, Chris Adams wrote:
> How many systems are there that "hang forever" when the floppy module is
> loaded? I have never seen that happen, on systems with or without
> floppy drives, yet you seem to be saying it happens on vast numbers of
> them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember
those
sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the
floppy drive does a head seek during floppy controller init at boot.
No, it really takes 30÷45 seconds before floppy module timeouts after
access to /dev/fd0. Seems like eternity, especially if you have
no other output on screen during this time.
--
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl "God is more forgiving."
6:30 p.m.
New subject: floppy support
The argument that some older hardware do not have USB support and require
floppy support is moot.
I have 3 PCs in total. 2 desktops and 1 file server. The 2 desktops run
Ubuntu/Linux and the server running BSD. The server is an old desktop system
that has had various upgrades and various transformations throughout its
life. But when I go back to its origins, it will be 10 years old now. And
even in its early beginnings, it still had full usb support. And effectively
having no 'real' use for floppies. Even though it did come with a floppy
drive ootb.
I see it all the time. "Some older hardware still requires floppies..." It
just seems like a generic defense statement for the fans of floppies and for
those who insist on using them for god knows what reason.
Any hardware that is true to that statement must be at least 15 years old
surely!
And for the cheap price of PCs these days, whether it is building your own
or grabbing an oem system, just upgrade to something that does have full usb
support.
USB sticks may be small and easy to lose, correct. But I don't know how many
times I've put several of mine through the washing machine and they still
continue to work. Try putting a floppy disk through the washing machine and
then try reading the data and see what happens.
And as far as losing them, they always turn up again. And for permanent
loss, I really don't care as I encrypt all my data when using usb sticks
anyway. And if I don't find it, for $10 I can easily get another 8GB anyway.
Regards
Chris Jones
[image: linux.png]
6:40 p.m.
New subject: floppy support
Once upon a time, Chris Jones <chrisjones(a)comcen.com.au> said:
I see it all the time. "Some older hardware still requires
floppies..." It
just seems like a generic defense statement for the fans of floppies and for
those who insist on using them for god knows what reason.
Again, please stop trying to tell me what hardware to use. I have run
into several situations where I _must_ use a floppy. I don't want to,
and I've tried lots of other things first, but the floppy worked.
Any hardware that is true to that statement must be at least 15 years
old
surely!
Hardly. I have a 6 year old notebook that will not book from USB.
And for the cheap price of PCs these days, whether it is building
your own
or grabbing an oem system, just upgrade to something that does have full usb
support.
Feel free to PayPal me money for a new notebook.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:47 p.m.
New subject: floppy support
On 08/30/2011 06:40 PM, Chris Adams wrote:
Again, please stop trying to tell me what hardware to use.
Manufacturers will tell you what hardware to use. Very few manufacturers
still produce drives and media. Sony has stopped[1] as of last year.
So, if it takes the death of your floppy drive to change your mind (and
your mother's embroidery, wow, what a stretch there) then I hope death
meets it soon.
[1] http://news.bbc.co.uk/2/hi/uk_news/magazine/8646699.stm
P.S. I think I'm done with the Internet for this week. I've made a
bike-shedding thread instead a bike-shedding thread.
10 p.m.
New subject: floppy support
Michael Cronenworth wrote:
Manufacturers will tell you what hardware to use. Very few
manufacturers
still produce drives and media. Sony has stopped[1] as of last year.
Unless the EU bans them (like those standard incandescence lightbulbs), I
don't think floppies will become completely unavailable all that soon. (And
unlike for those old lightbulbs, I don't think there's any reason for
politicians to ban floppies.)
Kevin Kofler
6:52 p.m.
New subject: floppy support
On 2011/08/31 09:30 (GMT+1000) Chris Jones composed:
And for the cheap price of PCs these days, whether it is building
your own
or grabbing an oem system, just upgrade to something that does have full usb
support.
So old PCs should fill landfills instead of going to people with no money for
upgrades, much less for any PC at all? It must be comforting to be oblivious
to world ecology and have an unlimited money supply. Upgrading is simply no
option for many users of FOSS.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
8:19 p.m.
New subject: floppy support
On 08/30/2011 06:30 PM, Chris Jones wrote:
I see it all the time. "Some older hardware still requires
floppies..."
It just seems like a generic defense statement for the fans of floppies
and for those who insist on using them for god knows what reason.
Any hardware that is true to that statement must be at least 15 years
old surely!
And for the cheap price of PCs these days, whether it is building your
own or grabbing an oem system, just upgrade to something that does have
full usb support.
I am not defending floppies - I think the current approach of "ship the
module, but don't load it by default" is quite sensible - but there is
an additional use case: perhaps the machine itself does not need
floppies, but being able use it to prepare floppies for another machine
that does (e.g. some old piece of electronics that can save data to
floppy, a dedicated-use computer for running scientific experiments, etc.).
- Michael
6:43 p.m.
New subject: floppy support
On Tue, Aug 30, 2011 at 10:25 PM, Przemek Klosowski
<przemek.klosowski(a)nist.gov> wrote:
On 08/30/2011 03:55 PM, Chris Adams wrote:
> How many systems are there that "hang forever" when the floppy module is
> loaded? I have never seen that happen, on systems with or without
> floppy drives, yet you seem to be saying it happens on vast numbers of
> them (99.9% in an earlier message).
It's not really 'forever', it just seems like 'forever'---remember
those
sounds that go 'bzzzzzzut.... bzzzzzzzut... bzzzzzzut...' when the
floppy drive does a head seek during floppy controller init at boot.
I hope no
software is still doing this - that was idiotic 10 years
ago, let alone now. (The purpose of the seek is to detect drives that
can support only "double density", i.e. 360K, 5.25" disks, not "high
density", i.e. 1.2M disks. It doesn't do anything useful for 3.5"
drives.)
Mirek
6:49 p.m.
New subject: floppy support
2011/8/30 Miloslav Trmač <mitr(a)volny.cz>
I hope no software is still doing this - that was idiotic 10 years
ago, let alone now. (The purpose of the seek is to detect drives that
can support only "double density", i.e. 360K, 5.25" disks, not "high
density", i.e. 1.2M disks. It doesn't do anything useful for 3.5"
drives.)
bah you 3.5 inch floppy elitists!!!!!! I have an original wolfenstein 3-D
on 5.25 '' floppy...its its original sleeve...that I still use. How dare
you suggest that I give up my 5.25 inch floppy. Its actually "floppy"
unlike those hard plastic 3.5 inch cases.
-jef"Now if you wanted to suggest we finally drop support for the 8 inch
floppy drives, than I would definitely support that."spaleta
7:04 p.m.
New subject: floppy support
On Wed, Aug 31, 2011 at 1:49 AM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
2011/8/30 Miloslav Trmač <mitr(a)volny.cz>
>
> I hope no software is still doing this - that was idiotic 10 years
> ago, let alone now. (The purpose of the seek is to detect drives that
> can support only "double density", i.e. 360K, 5.25" disks, not
"high
> density", i.e. 1.2M disks. It doesn't do anything useful for 3.5"
> drives.)
bah you 3.5 inch floppy elitists!!!!!! I have an original wolfenstein 3-D
on 5.25 '' floppy...its its original sleeve...that I still use. How dare
you suggest that I give up my 5.25 inch floppy. Its actually "floppy"
unlike those hard plastic 3.5 inch cases.
I wouldn't dare to say anything
against a Wolfenstein 3-D medium.
That's fine, any 5.25" floppy _disk_ is fine.
The seek is there to detect the double-density _drive_ that was last
shipped in PC XT: PC AT already had a high-density drive. Wikipedia
tells me that the seek is there to detect hardware that became
obsolete in 1984.
Mirek
7:09 p.m.
New subject: floppy support
2011/8/30 Miloslav Trmač <mitr(a)volny.cz>
The seek is there to detect the double-density _drive_ that was last
shipped in PC XT: PC AT already had a high-density drive. Wikipedia
tells me that the seek is there to detect hardware that became
obsolete in 1984.
you take the fun out of everything.
But now I'm going to hunt around and see if I can find one of those here at
the U. that might still work.
-jef
10:04 p.m.
New subject: floppy support
Björn Persson wrote:
Kevin Kofler wrote:
> Users who don't have a floppy
> drive and want to save some boot time can blacklist the driver manually.
s/Us/Hack/ to make that sentence true.
No. Users who want to tweak their system to the point of shaving a few
seconds off their boot times should be able to RTFM!
On the other hand, users who just want the hardware in their computer to
actually WORK shouldn't be expected to. (With the current setup, they are,
which is why it is entirely backwards!)
Kevin Kofler
11:30 a.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Matthew Garrett wrote:
There's no way to get any feedback from the gameport driver as to
(a)
whether there's anything plugged in, or (b) what is plugged in. We could
have the gameport driver automatically pull in analog but that'd
probably break people doing midi or using some more specialised input
device. It's a hard problem that only impacts a pretty tiny set of
people, so it's prioritised somewhere below the hard problems that
impact a pretty large set of people.
An Arch Linux user once pointed out to me that Arch (at the time) probed for
analog joysticks using this udev rule:
SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", ATTRS{id}=="PNPb02f",
RUN+="/lib/udev/load-modules.sh analog"
(They have since dropped that rule in their trunk.) I don't know whether it
makes any sense though. I presume this is just testing for the presence of a
gameport without caring about what is connected, right?
Kevin Kofler
12:17 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 06:30:30PM +0200, Kevin Kofler wrote:
An Arch Linux user once pointed out to me that Arch (at the time)
probed for
analog joysticks using this udev rule:
SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*",
ATTRS{id}=="PNPb02f",
RUN+="/lib/udev/load-modules.sh analog"
(They have since dropped that rule in their trunk.) I don't know whether it
makes any sense though. I presume this is just testing for the presence of a
gameport without caring about what is connected, right?
Right.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:18 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Matthew Garrett wrote:
> There's no way to get any feedback from the gameport driver as to (a)
> whether there's anything plugged in, or (b) what is plugged in. We could
> have the gameport driver automatically pull in analog but that'd
> probably break people doing midi or using some more specialised input
> device. It's a hard problem that only impacts a pretty tiny set of
> people, so it's prioritised somewhere below the hard problems that
> impact a pretty large set of people.
An Arch Linux user once pointed out to me that Arch (at the time) probed for
analog joysticks using this udev rule:
SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*",
ATTRS{id}=="PNPb02f",
RUN+="/lib/udev/load-modules.sh analog"
(They have since dropped that rule in their trunk.) I don't know whether it
makes any sense though. I presume this is just testing for the presence of a
gameport without caring about what is connected, right?
If the PNP device with the ID "PNPb02f" is an analog joystick port then
instead of hacking userspace rules like this the analog.ko kernel module
should just gain a modinfo alias for it like for example parport_pc has
for its PNP device ids. See "modinfo parport_pc" as an example.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:25 p.m.
New subject: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 07:18:40PM +0200, Lennart Poettering wrote:
On Tue, 30.08.11 18:30, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
> An Arch Linux user once pointed out to me that Arch (at the time) probed for
> analog joysticks using this udev rule:
> SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*",
ATTRS{id}=="PNPb02f",
> RUN+="/lib/udev/load-modules.sh analog"
> (They have since dropped that rule in their trunk.) I don't know whether it
> makes any sense though. I presume this is just testing for the presence of a
> gameport without caring about what is connected, right?
If the PNP device with the ID "PNPb02f" is an analog joystick port then
instead of hacking userspace rules like this the analog.ko kernel module
should just gain a modinfo alias for it like for example parport_pc has
for its PNP device ids. See "modinfo parport_pc" as an example.
The id is already present in ns558, which is the driver for the typical
PC game port. However, this is only the driver for the controller, not
for the joystick itself. In theory we could have the driver probe for a
connected device and request_module("analog") if it finds something, but
(a) that'd only work at boot, and (b) it'd be less than ideal if there's
something other than a standard analog joystick connected.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:16 a.m.
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram <metherid(a)gmail.com> wrote:
Otherwise, make
ddate a sub package and don't install it by default. Solved?
As an upstream the willingness of distributions to strip out commands
which I wanted to provide and don't offer a build option to disable
via sub-packaging will simply encourage me to pack more functionality
into single binaries that the distributions won't strip.
So I think Fedora shouldn't be more willing to strip ddate than it
would be willing to patch out ddate functionality if it were embedded
in 'hwclock'.
There is a reasonable argument that util-linux ought to go on a diet:
Right now it appears to take up 6424k on disk.
(Though, most of that is localizations— and several of the various
NEWS/readme files it includes are bigger than ddate, as is its copy of
the GPL. This silly thread has probably taken up more disk space than
ddate, or it soon will)
9:20 a.m.
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram
<metherid(a)gmail.com>
wrote:
>Â Otherwise, Â make
> ddate a sub package and don't install it by default. Â Solved?
As an upstream the willingness of distributions to strip out commands
which I wanted to provide and don't offer a build option to disable
via sub-packaging will simply encourage me to pack more functionality
into single binaries that the distributions won't strip.
So I think Fedora shouldn't be more willing to strip ddate than it
would be willing to patch out ddate functionality if it were embedded
in 'hwclock'.
There is a reasonable argument that util-linux ought to go on a diet:
Right now it appears to take up 6424k on disk.
(Though, most of that is localizationsâ and several of the various
NEWS/readme files it includes are bigger than ddate, as is its copy of
the GPL. This silly thread has probably taken up more disk space than
ddate, or it soon will)
I think it has. :)
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:35 a.m.
On 08/29/2011 07:46 PM, Gregory Maxwell wrote:
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram wrote:
> Otherwise, make
> ddate a sub package and don't install it by default. Solved?
As an upstream the willingness of distributions to strip out commands
which I wanted to provide and don't offer a build option to disable
via sub-packaging will simply encourage me to pack more functionality
into single binaries that the distributions won't strip.
That argument totally doesn't apply since the thread was started by the
upstream maintainer. Besides, upstream cannot and should not try to
control how packaging is done. Playing dirty tricks isn't the way to
yield cooperation.
Rahul
12:29 p.m.
On Mon, Aug 29, 2011 at 6:54 AM, Karel Zak <kzak(a)redhat.com> wrote:
I'd like to remove:
ddate - converts Gregorian dates to Discordian dates
command from rawhide (F17). IMHO this crazy command is used by very
very small minority of Fedora users.
Comments?
That would make me very sad. Instead please consider adding
robotfindskitten to util-linux which would make me very happy.
John
4612
days inactive
4617
days old
106 comments
38 participants
participants (38)
-
Adam Williamson -
Al Dunsmuir -
Bill Nottingham -
Björn Persson -
Bruno Wolff III -
Chris Adams -
Chris Jones -
Dave Jones -
drago01 -
Felix Miata -
Gregory Maxwell -
Hans de Goede -
inode0 -
Jakub Jelinek -
Jef Spaleta -
Jerry James -
John5342 -
Jon Ciesla -
Jos Vos -
Kalev Lember -
Karel Zak -
Kevin Kofler -
Lennart Poettering -
Matthew Garrett -
Michael Cronenworth -
Michael Ekstrand -
Michael Schwendt -
Miloslav Trmač -
Nils Philippsen -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius -
Richard W.M. Jones -
Simo Sorce -
Tom Hughes -
Tomas Mraz -
Tomasz Torcz -
Zoltan Boszormenyi