Re: cdrecord floating point exception
Am 04.02.2009, 12:07 Uhr, schrieb Thomas Schmitt <scdbackup@gmx.net>:
Hi,
Matthias Andree wrote:
http://www.freebsd.org/gnome/docs/halfaq.html#q2
I'll put that into libburn docs.
It's not quite the same and also FreeBSD-specific. You don't want that.
Johannes Meixner's comment quoted by Matthias
https://bugzilla.novell.com/show_bug.cgi?id=438867#c23
"Why the hell is this HAL stuff always all the time changing
arbitrarily ..."
I can only join in with his lament.
Since i hear about hald it is ever changing.
Well - it's only a small part of the story; read for instance Comments
#44, #48, 51 in the same bug (quoted above) - apparently HAL fails to
provide the promised abstraction and exposes kernel internals - which
subverts the whole point of "abstraction".
My very convenient killing of particular
hald-addon-storage processes does not work
for several users of my programs. They simply
see no such processes. Only the failures.
Which operating system does this happen on? Darwin, FreeBSD, NetBSD,
DragonflyBSD, openSolaris, Linux version X, Linux version Y, are all very
different beasts.
FreeBSD's GEOM layer has several, um, let's put it mildly, "interesting"
interactions. Write 0-length to a device to reprobe for labels. If you
don't do that, you miss the "slices" (partitions in Linux lingo). Same for
optical media, although it doesn't hurt you here to not have label and
partitions -- these media are unpartitioned.
But woe betide the poor soul who has a media with blanks in its label.
SonyEricsson phone somewhere? My Memory Stick was dubbed "PHONE CARD",
unmountable by FreeBSD+GNOME+HAL due to alleged hal bugs. Luckily, my
phone (W810i) doesn't care, so relabeling PHONE_CARD did the job.
The mess begins already with the project
docs which naturally assume that everybody
is using a Mac-Windows-style computer
which by accident is based on Linux.
I never bothered to check the background of the freedesktop folks.
If HAL shall be a central system component
then it must have a stable C API and a
stable model of operations.
Seems rather a mix-and-match for everything. Some kernel info here, some
kernel internals exposed there, gazillions of device-specific
"20thirdparty" annotations to fill in missing info because HAL apparently
can't identify subdevices in the same physical case (All-in-one-printers
seem very common here), policy there. Hm. I should have a second look if I
were really interested in this.
Another group of developers to blame are
those who began to depend on hald without
first insisting in said model and API.
That's IMO what let hald dependencies proliferate. Depend on something
that's not finished. OTOH, it's good that vendor-specific hacks such as
resmgr are going away now. But there's a lot of half-baked stuff around.
PolicyKit (which together with pulseaudio bug prevented my running the
latter with real-time scheduling on FreeBSD), HAL, and more cruft.
BTW, for testing if/how hald stomps over writing: can I trigger hald
corruption by just writing some data to CD-RW on a modern (MMC) DVD writer
(NEC) while hald is probing?
--
Matthias Andree
Reply to: