what used to lead /bin being full and creation of /usr/bin?
I am and was reading https://lwn.net/Articles/773342/ where the current move of migrating whole lot of filesystem from /usr/$something to simply /usr . Some of the comments again and again comment on the fact that /usr/bin was created because /bin became full but it doesn't go in any details as to why /bin used to become full ? Where there any real or artificial limits to /bin then ? Also I'm not able to co-relate or find out when these events happened in some sort of chronological order. The only assumption I can make is we had too small hard disks or tapes (which were and are still expensive to run and maintain) . If anybody can throw light on this obscure history .
In today's world, I usually recommend newbies something like /boot - say something like 200 mbish, / for 15-20% of the hdd and the rest for /home with swap at around 1:1 . Having this new structure should, at least in theory simplify maintainance quite a bit although have no clue from a security viewpoint.
Anyways, if somebody can share some of the history it might give people like me a bit more how things are, the way they are.
linux debian filesystems history gnu
asked Dec 15 at 23:23
shirish
3,65362983
add a comment |
I am and was reading https://lwn.net/Articles/773342/ where the current move of migrating whole lot of filesystem from /usr/$something to simply /usr . Some of the comments again and again comment on the fact that /usr/bin was created because /bin became full but it doesn't go in any details as to why /bin used to become full ? Where there any real or artificial limits to /bin then ? Also I'm not able to co-relate or find out when these events happened in some sort of chronological order. The only assumption I can make is we had too small hard disks or tapes (which were and are still expensive to run and maintain) . If anybody can throw light on this obscure history .
In today's world, I usually recommend newbies something like /boot - say something like 200 mbish, / for 15-20% of the hdd and the rest for /home with swap at around 1:1 . Having this new structure should, at least in theory simplify maintainance quite a bit although have no clue from a security viewpoint.
Anyways, if somebody can share some of the history it might give people like me a bit more how things are, the way they are.
linux debian filesystems history gnu
asked Dec 15 at 23:23
shirish
3,65362983
1
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
1
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10
add a comment |
I am and was reading https://lwn.net/Articles/773342/ where the current move of migrating whole lot of filesystem from /usr/$something to simply /usr . Some of the comments again and again comment on the fact that /usr/bin was created because /bin became full but it doesn't go in any details as to why /bin used to become full ? Where there any real or artificial limits to /bin then ? Also I'm not able to co-relate or find out when these events happened in some sort of chronological order. The only assumption I can make is we had too small hard disks or tapes (which were and are still expensive to run and maintain) . If anybody can throw light on this obscure history .
In today's world, I usually recommend newbies something like /boot - say something like 200 mbish, / for 15-20% of the hdd and the rest for /home with swap at around 1:1 . Having this new structure should, at least in theory simplify maintainance quite a bit although have no clue from a security viewpoint.
Anyways, if somebody can share some of the history it might give people like me a bit more how things are, the way they are.
linux debian filesystems history gnu
asked Dec 15 at 23:23
shirish
3,65362983
I am and was reading https://lwn.net/Articles/773342/ where the current move of migrating whole lot of filesystem from /usr/$something to simply /usr . Some of the comments again and again comment on the fact that /usr/bin was created because /bin became full but it doesn't go in any details as to why /bin used to become full ? Where there any real or artificial limits to /bin then ? Also I'm not able to co-relate or find out when these events happened in some sort of chronological order. The only assumption I can make is we had too small hard disks or tapes (which were and are still expensive to run and maintain) . If anybody can throw light on this obscure history .
In today's world, I usually recommend newbies something like /boot - say something like 200 mbish, / for 15-20% of the hdd and the rest for /home with swap at around 1:1 . Having this new structure should, at least in theory simplify maintainance quite a bit although have no clue from a security viewpoint.
Anyways, if somebody can share some of the history it might give people like me a bit more how things are, the way they are.
linux debian filesystems history gnu
linux debian filesystems history gnu
asked Dec 15 at 23:23
shirish
3,65362983
asked Dec 15 at 23:23
shirish
3,65362983
asked Dec 15 at 23:23
shirish
3,65362983
asked Dec 15 at 23:23
shirish
3,65362983
asked Dec 15 at 23:23
shirish
3,65362983
3,65362983
1
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
1
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10
add a comment |
1
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
1
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10
1
1
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
1
1
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10
add a comment |
1 Answer
1
active
oldest
votes
Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!
...
So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great. Until they ran out of space on disk 1.
https://twitter.com/Foone/status/1059308377740726272
The above retelling includes pictures. It cites a mailing list post by Rob Landley:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489234%2fwhat-used-to-lead-bin-being-full-and-creation-of-usr-bin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!
...
So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great. Until they ran out of space on disk 1.
https://twitter.com/Foone/status/1059308377740726272
The above retelling includes pictures. It cites a mailing list post by Rob Landley:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
add a comment |
Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!
...
So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great. Until they ran out of space on disk 1.
https://twitter.com/Foone/status/1059308377740726272
The above retelling includes pictures. It cites a mailing list post by Rob Landley:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
add a comment |
Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!
...
So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great. Until they ran out of space on disk 1.
https://twitter.com/Foone/status/1059308377740726272
The above retelling includes pictures. It cites a mailing list post by Rob Landley:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Bell Labs bought the PDP-11/20 with a RK11 controller (supporting up to EIGHT hard drives), and initially fitted it with two RK05 hard drives. Each of these drives had a MASSIVE 2.5 megabytes of storage!
...
So disk 1 contained /bin and other files, and disk 2 was /usr. All the users now had NEARLY INFINITE SPACE and everything was great. Until they ran out of space on disk 1.
https://twitter.com/Foone/status/1059308377740726272
The above retelling includes pictures. It cites a mailing list post by Rob Landley:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
edited Dec 15 at 23:45
community wiki
2 revs
sourcejedi
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
add a comment |
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
see also askubuntu.com/questions/130186/…
– Rui F Ribeiro
Dec 15 at 23:39
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489234%2fwhat-used-to-lead-bin-being-full-and-creation-of-usr-bin%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Was feeling your thinking until the /boot comment....some glue lacking? In my template vms I did away with /boot, one less partition to care, and one less being too small when after 2-5 Debian versions in the future, the kernel becomes significantly bigger.
– Rui F Ribeiro
Dec 15 at 23:26
1
I had bad experience with bootups couple of times and had to resort to external hacks which took lot of time and wasn't able to even know why they didn't boot properly. Was it some sort of boot-sector file corruption or something else. With /boot I never have had a problem yet, touch wood. I have corrupted my installs in other ways but once I'm on a shell things can be fixed 99.99% of the time.
– shirish
Dec 16 at 0:10