/dev 'not updated'

Ian Molton spyro at f2s.com
Sat Mar 22 18:49:06 PST 2003


On Sun, 23 Mar 2003 01:39:28 +0000 (UTC)
dagmar.wants at nospam.com (Dagmar d'Surreal) wrote:

> > Not sure I follow your logic...
> 
> That much is obvious.

Is something going wrong in your life?

I mean that sincerely, as you arent *normally* this abrasive.

OTOH, you seem to get extremely angry whenever I tell you you're wrong
(and you are on this one, trust me).

> > Now, I can see that *arguably* My expectation was flawed, but that
> > presupposes I KNOW the channel is blown.
> > 
> > I dont see how you can argue that the second channel isnt broken
> > though.
> 
> I'm not.  You are.  However, you very conveniently deleted the part of
> my post which drew a /far/ more accurate parallel.  Your analogy does
> not apply because before devfs there was no "broken but unused
> channel" component to compare against.

I think you failed to understand my analogy.

what I was getting at is that MOST *GOOD* software (and we're talking
unix here, ok?) allows you to **specify** the device it uses somehow, at
runtime.

> Once in the past I plonked you for being abusively argumentative and
> overzealously editing posts to remove important points made by other
> people.  If you want to start being an ass full-time again, I'll be
> more than happy to start filtering your mails again.

I'll be happy for me not to see your (frankly, disgustingly offensive)
responses to me. I havent made ANY attempt to creatively edit posts now,
or in the past, EVER (except for humour in clearly stated cases).

> > IOW, its not devfs breaking software, its software making broken
> > assumptions. Probably crap, nonportable software, since other unices
> > have different dev names.
> 
> Other unices in these cases have different names because they're
> either not using /dev or they're using different drivers.

Irrelevant. the point isnt WHY they use different names. it doesnt even
matter which unix you pick. the point is that GOOD well written software
allows you to CHOOSE the device names you want to select.

>  Do you want
> to bitch that Win32 is broken because it doesn't have /dev at all?

Nope, but I want some of the crack you're smoking... I never mentioned
win32 at all. (btw. I think NT has a /dev, albeit hidden).

> > FWIW, I havent found ANYTHING in the base LFS that breaks with the
> > new names.
> 
> Whatever.  It doesn't include a whole lot of software so it doesn't
> make a good metric, especially since only a very small number of them
> even use the /dev interface, with the exception of some init scripts.

which are a good example FOR my case - the init scripts allow you to
specify the device agetty uses.

> > in fact, on my whole system, only TWO programs take issue with them:
> > 
> > Quake 3 and mplayer.
> 
> Astonishingly enough, these aren't in LFS, either.

I never said they were. the point is that on a complete desktop system
only *TWO* packages have a problem with the devfs names.

> > my ONLY compat symlink is therefore, /dev/sound/dsp -> /dev/dsp
> 
> ...which has next to nothing to do with the original point, but at
> least you're admitting that you are using a _compatibility_ symlink. 
> To spell it out, it wouldn't be called a _compatibility_ symlink
> unless it was there to fix a compatibility issue... as in devfs is in
> some ways_incompatible_ with the pre-existing /dev hierarchy being
> used by many.

I never claimed I wasnt using a compatability symlink you dolt.

The original point, btw. was by Tushar that 'devfs breaks a lot of
stuff'.

My argument is that the stuff itself is already broken if it has device
names hard coded. devfs didnt break it.

Hard coding baaaad. Configurable goooood.

devfs merely highlights the things that ARE broken.

(incidentally, an app that assumes you have (say) /dev/mouse or
/dev/dsp1 is your primary sound card *IS* broken, like it or not.)

-- 
Don't support the war. Join Bjorns boycott of American products.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list