1 |
<karl <at> aspodata.se> writes: |
2 |
|
3 |
|
4 |
> I'm new to gentoo, is there some special semantic to the "bgo #" ? |
5 |
WELCOME Karl! |
6 |
|
7 |
You'll find gentoo is full of traditional *nix users and minimalists. |
8 |
Don't let the progressives disturb your reticent ways... you are in good |
9 |
company. |
10 |
|
11 |
https://bugs.gentoo.org/show_bug.cgi?id=107875 |
12 |
|
13 |
|
14 |
|
15 |
> I have had no pain useing an old plain /dev. What's the pain ? |
16 |
|
17 |
I try to do to many things, and often get confused on what use to work, |
18 |
what may work and what might work. |
19 |
|
20 |
|
21 |
|
22 |
> > For explicit clarity, you've got a "/dev" from using dev-manager on the |
23 |
> > system previously, and now you desire to switch to a static-dev? (Why ?) |
24 |
> > Or did you derive from scratch (or other means) a '/dev' for a specific |
25 |
> > need you are working on by design, historical example etc? |
26 |
> |
27 |
> No, I never used udev et al on my boxes, there has simply been no need. |
28 |
|
29 |
|
30 |
On workstations, I use openrc and eudev; but I work on many many different |
31 |
devices that have /dev issues, particularly in an embedded platform. |
32 |
|
33 |
|
34 |
> > I apologize in advance, but this thread intersects some critical new |
35 |
> > thinking on systems cluster formation. I have ran into a small group of |
36 |
> > extraordinary coders that are building a Hi Performance Cluster out of C |
37 |
> > C Rust and a minimized static-dev. So I am very curious as to your |
38 |
> > specific and detailed motives for this 'static-dev'. If a private note > |
39 |
> is warranted, feel encourage for that type of response. If this |
40 |
> > unbounded curiosity of mine is unwelcome, you have my deepest apologies. |
41 |
|
42 |
> I never had any compelling reason to let some daemon with mess with |
43 |
> /dev. And I have had a compelling reason to avoid it, when doing an |
44 |
> "usual" stable dist-upgrade of Debian lenny to squeze (I think), Debian |
45 |
> installed udev per default and everything just stopped working. And |
46 |
> that darn thing wouldn't uninstall and /dev wouldn't unmount to get |
47 |
> back my /dev-entries. So udev have only giving me pain and no gain. |
48 |
> The only thing dynamic theese days are usb. Usb disks I can handle |
49 |
> manually, usb kbd/mouse has always worked. I usually don't use more |
50 |
> than one keyboard so I don't really need xkb, nor do I need something |
51 |
> to autodetect keyboard layout, since I change it to something else |
52 |
> anyhow. And udev woun't detect my serial mouse anyhow... so much for |
53 |
> that. |
54 |
|
55 |
|
56 |
Excellent! I like you quite a lot, Karl. Just so you know, folks are |
57 |
encouraged to maintain ebuilds here at Gentoo, via the proxy maintainer |
58 |
project. So if you find an orphaned packaged you like (equery m <ebuild>) |
59 |
then just drop them an email. [1] It's a good way to help customize gentoo |
60 |
in a move-at-your-pace platform. |
61 |
|
62 |
|
63 |
> That said, if I would like to test some "dev-manager" (except myself) |
64 |
> than I'd look into something that behaves nicely, like mdev (busybox) |
65 |
> or vdev (https://github.com/jcnelson/vdev.git). |
66 |
|
67 |
With gentoo, all things are possible. eudev + openrc might be a pleasant |
68 |
combo and they are both "gentoo source projects" or close enough. The folks |
69 |
that work on those are quite busy and would most likely welcome your input |
70 |
and participate. On the desktop, you might like lxqt or lxde? |
71 |
|
72 |
If you find codes you like, and there is no ebuild for them (eix -R |
73 |
<package>), then you can easily create an ebuild, most of the time. Complex |
74 |
dependency are a bit trickier. Check out the gentoo devmanual . |
75 |
|
76 |
> Regards, |
77 |
> /Karl Hammar |
78 |
|
79 |
|
80 |
Thanks for the info! ;-) |
81 |
|
82 |
James |
83 |
|
84 |
[1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers |