1 |
On 2019-08-08 09:43, Neil Bothwick wrote: |
2 |
> On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote: |
3 |
> |
4 |
>> > As opposed to splitting binaries across four directories based on |
5 |
>> > arbitrary decisions made in the last century? :P |
6 |
>> |
7 |
>> LOL! You're missing the most important part: across different fs and |
8 |
>> partition layouts. |
9 |
>> |
10 |
>> Look, the pyramids were built before the last century, but that |
11 |
>> doesn't |
12 |
>> mean we should try to balance them upside down if they work fine as |
13 |
>> they are. |
14 |
> |
15 |
> Why not? As long as it's optional and controlled by a USE flag :) |
16 |
> |
17 |
>> Clearly different use cases have different requirements and |
18 |
>> correspondingly different optimal solutions. Can I please keep my |
19 |
>> bin/sbin directories separate and ditto for /usr and its subbies? :-) |
20 |
> |
21 |
> The /usr / split makes sense when you want different filesystems, |
22 |
> something I used to do but don't have any need for now. I've yet to see |
23 |
> a |
24 |
> convincing argument for the bin/sbin split in either location. |
25 |
|
26 |
Let me jump back into this hi-jacked thread somewhere. Unfortunately I |
27 |
didn't found an answer to the future directions at gentoo regarding the |
28 |
usr merge. And my fear is that the merge will be forced. As I use gentoo |
29 |
as a meta distro really, this change _could_ be put _me_ into trouble. |
30 |
But my 'gentoo-lfs' is not the typical use case. |
31 |
|
32 |
Now, even that there are my individual requirements behind, some short |
33 |
points of my POV to some points in the whole thread. All IMHO. |
34 |
|
35 |
An initramfs is a elegant and - more important - a very flexible |
36 |
solution. It is not required, but it makes things easier. It could solve |
37 |
more things than having /usr at a separate fs or loading drivers. I |
38 |
would also define it as a bootloader (like Rich) in a chain. More |
39 |
abstract I would see a classical bootloader like grub as a kernel by |
40 |
itself. |
41 |
|
42 |
I see 3 stages of security concerns of an initramfs: |
43 |
|
44 |
1. trust yourself and build your own one |
45 |
2. trust gentoo and use gentoo's initramfs |
46 |
3. download one (from a warez site) and stay hacked |
47 |
|
48 |
The usr merge itself is questionable workaround to consolidate things. |
49 |
Now, a consolidation is a good thing in general. But what is the real |
50 |
difference to have a symlink /bin against having a folder? I couldn't |
51 |
follow the given arguments. |
52 |
|
53 |
The core issue is the under laying folder structure. And depending on |
54 |
this hard coded path's. We still relying at a 50 years old concept - and |
55 |
time was moving on. Don't ask, I haven't a solution (yet). Just the |
56 |
dream/vision of the perfect system :). One point of the vision is to |
57 |
have a core (linux) OS (e.g. an extended stage3) separated from all user |
58 |
programs (similar to a ring0 kernel isolation). |
59 |
|
60 |
From all exiting concepts and implementations the best parts should be |
61 |
used. Not sure if this is ever possible. But forcing users to use a |
62 |
solution which is not required by 99% of them is a very bad thing. These |
63 |
'1-percent-solutions' have to be optional. |
64 |
|
65 |
Anyway, just an opinion beside the mainstream. I encourage people to |
66 |
have their own. :) It is not hard to create pro and con arguments. And I |
67 |
left enough room for misunderstandings. |
68 |
|
69 |
|
70 |
-- |
71 |
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail |