[Novalug] Device naming.

Alan Grimes agrimes@speakeasy.net
Mon Mar 15 11:04:03 EDT 2010


Peter Larsen wrote:
> On Mon, 2010-03-15 at 00:35 -0400, James Ewing Cottrell 3rd wrote:

>>> Clearly in this context referenced to the claim it was poorly
>>> documented. The fact that over time, the methodology change and things
>>> don't work as they used to, doesn't mean it doesn't work. KUDZU has
>>> nothing to do with devices on a running system (it detects changes on
>>> boot only). udev=devfs; and for the purpose of this discussion HAL can
>>> be ignored. You even left out DM/LVM a major differentiator these days.
>> I generally avoid these at home. Ironically, these tend to identify 
>> themselves quite well by their own labels.

> There's a lot more good reasons for dropping partitions and switching to
> LVM.

I hesitate to ask: Huh??? What???

I learned about partitions the hard way in the late (fuck, can't type
numbers today; talking about the eighties...) Oh numbers just started
working again, ARGH!!!

> No, sysfs != devfs/udev. sysfs is pretty much everything hal found, plus
> the ability to change/manipulate device settings (it supports both reads
> and writes). This is where you'll manipulate your SCSI setup, force a
> bus rescan etc.  sysfs is usually mounted on /sys.

/me recites his mantra

SHOW ME THE DOCS!!!
GIVE ME LINKS!!!!
GIVE ME GOOGLE SEARCH TERMS THAT WILL FIND THE DOCS IN THE FIRST TEN
RESULTS!!!

Otherwise, STFU.

>> In any case, I have seen what kudzu does sometimes...pops up and redoes 
>> your devices when you move disks from one computer to another. Cool. 

> Well, kudzu is no more ;) Replaced permanently by udev. Kudzu's job was
> to try to fix the static files you have in /etc when hardware changes -
> there's no longer a need for you to change those files (they're actually
> missing now). There were plenty of complaints about kudzu too. You're
> damned if you do, you're damned if you don't. 

Then how does it know what partition has my programs and which has my
anime?

In DOS it didn't matter because no program really cared what drive it
was on or where it data was; In many cases you could manual set the
drive letter. You could also mount drives to paths as in linux and you
could treat directories as separate drives, DOS RULED. In linux you have
to mount crap in a specific place

> I think the point here may be a different target audience for the
> manuals. You're moving close to the kernel when you talk udev, and the
> "speak" in the manuals can tend to become overly "ivory tower" technical
> quick. That's why I like groups like this - there's always someone out
> there to "translate". It doesn't take a lot of google searches to find
> fairly comprehensive descriptions of udev and other areas, such as
> http://www.reactivated.net/writing_udev_rules.html. 

I hereby retract 10% of the above.

> in /etc/modules.conf (it's gone actually). No need
> for /etc/X11/xorg.conf. We have a more unified hardware configuration
> utility now in udev. I think that should be celebrated - not
> criticized. 

Because xorg ignores my console keyboard settings, there's no way for it
to know that I'm a dvorak typist unless I tell it explicitly.
Furthermore, it's default swaps the physical locations of my monitors.
Both issues must be fixed manually.

Furthermore, the xorg penguins have lost their heads just as the udev
penguins have and, unless you basically shout at them in xorg.conf, they
will ignore what you wrote there and lock you into a desktop with no
keyboard or mouse input!!! There is supposed to be some kind of
autodetection involving HAL but since

-- A: I don't need anything HAL does.
-- B: I don't know how HAL works.
and
-- C: HAL is probably not documented just as most of the kernel and the
rest of the system is not documented,

I therefore removed and masked HAL from my system, and done everything I
can think of to force xorg to basically behave as TRON did at the IO tower.

> We'll leave the issue of Sacret to the religions :D
> I don't agree that we should keep things around just for the sake of
> keeping them around. But I have a feeling that Bryans many explanations
> of how disks have become "common" has gone overheard here. We've
> achieved exactly what you want - a straight forward common access to
> hard-drives. Maybe not in the way you had envisioned it done - I grant
> you that. But I haven't seen anything yet presented here that would make
> things as "simple" as they are now. 

Use case:

Write out a plan to add an IDE HD to my computer. You know (will be
given) all the relevant details of my system as it is now. You must
write out the plan entirely before hand. It will be given to an idiot
who will perform the steps exactly as specified. None of the steps may
involve reading or reacting to the output of the system.

In the old scheme, that challenge would be a piece of cake.

In the new system you must first *GUESS* (with scant evidence) which of
the sd* devices your new drive is, and then adjust all of your plans
accordingly. If the new drive displaced other drives in the system,
you're SCREWED.... You have to go back and figure out where all of your
drives are again and adjust your fstab accordingly.

> I think that speaks volumes to why you're having problems. The old ways
> were harder than they are now. You had several areas to modify to add a
> device; today you have one: udev. Yes, it's a new thing to learn - but
> you can now unlearn so many other things, that it should make plenty of
> room for the new knowledge (hehe - just thought of that one).

Once again:

SHOW ME THE DOCS!!!
I need to know exactly how it works, with no detail omitted.

> Nobody is forcing you to do anything. But it's a little hard to take
> complaints seriously about a technology, when you refuse to learn about
> it first.

SHOW ME THE DOCS!!! =|

I'm sick to death of trying to figure stuff out on my own on my own
computer with alegedly free software. I usually get it wrong and then
get flamed when I go to explain what I think I've learned.

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.




More information about the Novalug mailing list