Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

lists.busybox.net

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#121

Post by majewsky »

dredmorbius wrote: post #96
majewsky wrote: post #82

Earlier quoted context omitted.

mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to /proc/self/mounts. As for the recovery partition, you don't need the split for that, either. Just have a live system on the recovery partition that mounts the normal root FS. Then you can chroot into there for recovery tasks.

Right, that seemed to be the mtab solution Debian were angling toward. I think there were some odd edge cases where it didn't behave well, though I don't recall what those were. Perhaps the ability to specifically edit the contents to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of which get quite twitchy at times. I don't recall my precise thinking on a clean root vs. /usr split on the re…

> Not being able to mount a separate /usr would negate that option.

You can mount the root to e.g. /mnt and symlink (or bind-mount) /mnt/usr to /usr, if that's what you need.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#122

Post by paxcoder »

eridius wrote: post #116
paxcoder wrote: post #107

Earlier quoted context omitted.

I explicitly said a superior copyleft license. That is, I stated the value I presuppose, and in this context GPLv3's superiority to GPLv3 is clear. What's "extreme" is denying users control of their own devices, not the reverse.

GPLv3 is still not clearly superior to GPLv2. GPLv3 is only superior if you agree with the new restrictions added in GPLv3, but again, not everybody does. And you know damn well that this is purely opinion, because you already referenced Linus Torvalds's stance on this matter. There's two issues at play with copyleft licenses. The first is making the source available to others, and the second is allowing others to in…

Copyleft is those user-protecting restrictions. I'll refrain from repeating myself.

By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft. Again, the purpose of copyleft is proliferating "freedom-respecting" software, not amassing - open source. Code that is open, but you can't utilize freely because of a locked-down device or a patent - "misses the point". Preceding references emerged organically and... whoa.

Most GPLv2 bias which isn't caused by Linux' licensing is due to the kind of FUD you've perpetuated in this thread, not any actual issue with GPLv3.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#123

Post by malka »

eridius wrote: post #119
gherkin0 wrote: post #117

Earlier quoted context omitted.

The device should not have the private key loaded onto it at all, just the corresponding public key. The private key would only exist on the sticker and thus be unrecoverable if you threw it out or destroyed it. The IMEI example was just to demonstrate the ability to slap a device-unique code + matching sticker on something during manufacturing at scale.

Slapping stickers on something is not a scaling issue. The secure storage and transmission of private keys is. The idea that you'd just slap the private key on a sticker and have no other record of it is not something I even considered because that's very user-hostile behavior (unless they already have the intention to mod the device software before they buy it, they're unlikely to retain the sticker). It also screws…

maybe a physical button to generate a new private key + QR code for the PK displayed on screen ?

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#124

Post by soupbowl »

gkya wrote: post #93
orik wrote: post #4

Earlier quoted context omitted.

I was about to ask if any BSD's handle this better, great to see that NixOS does.

In FreeBSD the base system stuff goes into /bin /lib and /etc, and all the ports target /usr/local as the prefix. Even the config files of the ports go to /usr/local/etc.

I really like how freebsd does it, nixos has me interested too.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#125

Post by eridius »

paxcoder wrote: post #122
eridius wrote: post #116

Earlier quoted context omitted.

GPLv3 is still not clearly superior to GPLv2. GPLv3 is only superior if you agree with the new restrictions added in GPLv3, but again, not everybody does. And you know damn well that this is purely opinion, because you already referenced Linus Torvalds's stance on this matter. There's two issues at play with copyleft licenses. The first is making the source available to others, and the second is allowing others to in…

Copyleft is those user-protecting restrictions. I'll refrain from repeating myself. By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft. Again, the purpose of copyleft is proliferating "freedom-respecting" software, not amassing - open source. Code that is open, but you can't utilize freely because of a locked-down device or a patent - "misses the point". Preceding references emerg…

> By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft

Please don't strawman me. I already explained how there's two different freedoms that copyleft licenses seek to protect, and it's perfectly valid for someone to care only about the first freedom but not the second, and for such a person the GPLv2 is superior.

> Most GPLv2 bias which isn't caused by Linux' licensing is due to the kind of FUD you've perpetuated in this thread, not any actual issue with GPLv3.

Contrary to what you may believe, FUD is not defined as "any opinion you disagree with". And by calling my arguments FUD instead of actually trying to address the points I made, you're just telling me that you can't actually argue against what I said so you'd rather try and discredit me.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#126

Post by eridius »

malka wrote: post #123
eridius wrote: post #119

Earlier quoted context omitted.

Slapping stickers on something is not a scaling issue. The secure storage and transmission of private keys is. The idea that you'd just slap the private key on a sticker and have no other record of it is not something I even considered because that's very user-hostile behavior (unless they already have the intention to mod the device software before they buy it, they're unlikely to retain the sticker). It also screws…

maybe a physical button to generate a new private key + QR code for the PK displayed on screen ?

You're confusing physical access with ownership. If I have physical access to a device, that does not mean I should have the power to install compromised software on it, because it may not be my device at all.

This is a surprisingly common oversight that the hardware freedom crowd keeps ignoring. I don't understand why so many people just implicitly assume that physical access means security should be thrown out the window.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#127

Post by dredmorbius »

majewsky wrote: post #121
dredmorbius wrote: post #96

Earlier quoted context omitted.

Right, that seemed to be the mtab solution Debian were angling toward. I think there were some odd edge cases where it didn't behave well, though I don't recall what those were. Perhaps the ability to specifically edit the contents to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of which get quite twitchy at times. I don't recall my precise thinking on a clean root vs. /usr split on the re…

> Not being able to mount a separate /usr would negate that option. You can mount the root to e.g. /mnt and symlink (or bind-mount) /mnt/usr to /usr, if that's what you need.

Bind-mounting does give you some options. Still doesn't help if root's hosed.

And it wasn't an option when I'd first come up with this clever scheme.

One of my current challenges with Linux is identifying which information/education of mine is wholly outdated. This will happen to you in time as well....

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#128

Post by gkya »

soupbowl wrote: post #124
gkya wrote: post #93

Earlier quoted context omitted.

In FreeBSD the base system stuff goes into /bin /lib and /etc, and all the ports target /usr/local as the prefix. Even the config files of the ports go to /usr/local/etc.

I really like how freebsd does it, nixos has me interested too.

Though NixOS and Guix form a different approach than the FreeBSD's, that is they treat packages as isolated immutable objects and use an unconventional directory layout (wanted to note this, because someone who doesn't know the OSs named may have thought that FreeBSD and NixOS/Guix approaches are similar).

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#129

Post by paxcoder »

eridius wrote: post #125
paxcoder wrote: post #122

Earlier quoted context omitted.

Copyleft is those user-protecting restrictions. I'll refrain from repeating myself. By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft. Again, the purpose of copyleft is proliferating "freedom-respecting" software, not amassing - open source. Code that is open, but you can't utilize freely because of a locked-down device or a patent - "misses the point". Preceding references emerg…

> By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft Please don't strawman me. I already explained how there's two different freedoms that copyleft licenses seek to protect, and it's perfectly valid for someone to care only about the first freedom but not the second, and for such a person the GPLv2 is superior. > Most GPLv2 bias which isn't caused by Linux' licensing is due to the…

Ignore, pretend, you'll still be wrong. I'll call it like I see it.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#130

Post by arthur2e5 »

yrro wrote: post #64
Pxtl wrote: post #19

Earlier quoted context omitted.

Still, clutters and confuses new users. In wonder if some of the fs apis could hide the silly/redundant directories?

I much prefer compatibility symlinks actually existing in the file system over some complex, hidden pathname resolution override riles lurking in the kernel. That way, Windows lies.

> lurking in the kernel. That way, Windows lies.

Windows implements many overrides (e.g. "My Documents") as NTFS junctions with some hidden (+ system?) property set. (Sometimes you will find a proper hidden property handy, like in this case.)

Stuff like CON, NUL in non-UNC paths do hurt, though. Device files from an age without directories....

Post reply on HN