Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If you think so. I see nothing wrong in showing him which OSes support POSIX fully when he asks that only those that do can call themselves UNIX-like, but to each his own.
Which is only a chicken and egg problem when /usr is hosted on the newtwork and even then easily solved with an initramfs. Talking about weaseling out.
Dude, read my whole actual post there is a lot of stuff U'r not addressing, and for the record, I have always considered initramfs an ugly hack, sure it can be useful on occasion, but I'd rather use a custom kernel with all essential functionality like fs support for the root and other essential fs-es built in.
and for the record, I have always considered initramfs an ugly hack, sure it can be useful on occasion, but I'd rather use a custom kernel with all essential functionality like fs support for the root and other essential fs-es built in.
What you'd rather use and what initrd/initramfs is good for are too entirely different things. If someone putting together a distribution was to use a kernel with all file systems, scsi host adapter drivers built into the kernel, that would be huge kernel and not in the end user's best interests.
Dude, read my whole actual post there is a lot of stuff U'r not addressing, and for the record, I have always considered initramfs an ugly hack, sure it can be useful on occasion, but I'd rather use a custom kernel with all essential functionality like fs support for the root and other essential fs-es built in.
I have read your entire post, but you preferred to make changes after I posted. I will not sit here and press Refresh every minute on your posts for the case you have made changes. But I will happily address them now, let's see:
Quote:
thus giving us a chicken and egg problem, since everything necessary for a minimal boot must be in /bin or /sbin as stated above.Repeating.Bolding.And Underlining for better visibility, I hope you ACTUALLY understand it now, LOL!.
Who again says that it must be there? Did you miss the part where I stated that (almost) no distro adheres anymore to standards like FHS and LSB. Did you also miss the point where I stated that many distros nowadays don't even have a /sbin or /bin separate from those in /usr? Regarding initramfs as an ugly hack, again, think about it what you want. Fact is that initramfs is standard in Debian for years, so here will exactly change this for Debian: Nothing.
Quote:
As to your larger installations, I belie that maintaining everything from a single point, means single point of failure, laziness is a good thing at times, but there is such a thing as diminishing returns, there is also the minor issue of network faults and having your NFS/SAMBA/Whatever servers going down for maintenace.
And you think in this case, having a single point of failure where an actual error can be fixed for all systems at once is worse than having to update and make sure that they are in a consistent state for hundreds or even thousands of systems? And you think that in large installations the server downtime is not planned in a way that people can continue their work?
I have read your entire post, but you preferred to make changes after I posted. I will not sit here and press Refresh every minute on your posts for the case you have made changes. But I will happily address them now, let's see:Who again says that it must be there? Did you miss the part where I stated that (almost) no distro adheres anymore to standards like FHS and LSB. Did you also miss the point where I stated that many distros nowadays don't even have a /sbin or /bin separate from those in /usr? Regarding initramfs as an ugly hack, again, think about it what you want. Fact is that initramfs is standard in Debian for years, so here will exactly change this for Debian: Nothing.
Seperate /bin and /sbin exist for a good reason, and the standard should be adhered to, the fact that some distros do not do that just shows that their maintainers need to be done away with.
Once again you read selectively and don't get to the heart of the matter.
IMO you should improve your reading comprehension.
Quote:
Originally Posted by TobiSGD
And you think in this case, having a single point of failure where an actual error can be fixed for all systems at once is worse than having to update and make sure that they are in a consistent state for hundreds or even thousands of systems? And you think that in large installations the server downtime is not planned in a way that people can continue their work?
Or mess things up royally if you do something wrong, also why in hell should we not use rync, or parallel ssh with a few scripts, or just do an upgrade via kickstart(Or by utilizing the capabilities of excellent commercial UNIX solutions, like Slowaris' Jumpstart server and flash archives, or AIX's NIM and mksysb, HP-UX had something similar, but I can't remember the name just now.)
Finally a shared /usr will only work if all the systems are close enough so as to be identical where necessary libraries are concerned, if your shop is not hardware or software-homogenous you should forget that, it would also mean adding at least 2 KPE systems(because it would be better if you run the server where the shares are on a cluster to prevent screwups to at least some extent.), and improving the network's reliability and fault tolerance to make sure your laziness does not cost you dearly, and I haven't even gotten into things like load-balancing, and the need for things like pre-production and DR environments.
So you would probably need at least 6 more machines(Or VM's but I'd rather not use those for something like that.)And a number of improvements across your *NIX environment.
And a lot more uniformity.
Seperate /bin and /sbin exist for a good reason, and the standard should be adhered to, the fact that some distros do not do that just shows that their maintainers need to be done away with.
Once again you read selectively and don't get to the heart of the matter.
IMO you should improve your reading comprehension.
You are entitled to your opinion, but I don't think that anything is wrong with my reading comprehension.
Quote:
Or mess things up royally if you do something wrong, also why in hell should we not use rync, or parallel ssh with a few scripts, or just do an upgrade via kickstart(Or by utilizing the capabilities of excellent commercial UNIX solutions, like Slowaris' Jumpstart server and flash archives, or AIX's NIM and mksysb, HP-UX had something similar, but I can't remember the name just now.)
Finally a shared /usr will only work if all the systems are close enough so as to be identical where necessary libraries are concerned, if your shop is not hardware or software-homogenous you should forget that, it would also mean adding at least 2 KPE systems(because it would be better if you run the server where the shares are on a cluster to prevent screwups to at least some extent.), and improving the network's reliability and fault tolerance to make sure your laziness does not cost you dearly, and I haven't even gotten into things like load-balancing, and the need for things like pre-production and DR environments.
So you would probably need at least 6 more machines(Or VM's but I'd rather not use those for something like that.)And a number of improvements across your *NIX environment.
And a lot more uniformity.
And despite that it is done nonetheless in large installations. So what was again your point?
And despite that it is done nonetheless in large installations. So what was again your point?
My point was stated pretty well in my original post, and yes, I think that a number of your replies to my posts indicate that you do have problems with with reading comprehension that you should address ASAP, trust me it is important that you deal with them, it could be a great benefit to you.
Furthermore I am sure that you are aware of the fact that the fact something can be done, or that it has/is been done most certainly does not make it a good idea.
I've also worked for environments with hundreds of Unix systems for various organizations, none of them had anything like that, although other convoluted stuff was done galore.
My point was stated pretty well in my original post, and yes, I think that a number of your replies to my posts indicate that you do have problems with with reading comprehension that you should address ASAP, trust me it is important that you deal with them, it could be a great benefit to you.
At this point any further discussion with you is mood. Have a nice day.
At this point any further discussion with you is mood. Have a nice day.
Ah, I see, a ragequit, well farewell, although you still haven't addressed a number of my concerns in the quoted post as well as in a number of prior ones.
And my suggestion stems from genuine concern for a fellow penguin and UNIXite.
I would guess that he has given it up as a bad job because your posts have become increasingly ad hominen in nature.
//edit: Just read further back and it's astonishing that some people in this thread took shuttleworth's crystal clear blog post and concluded that 'buntu are not switching to systemd... it's obvious to me from the post that 'buntu are almost certainly moving to systemd.
Distribution: Debian Wheezy, Jessie, Sid/Experimental, playing with LFS.
Posts: 2,900
Rep:
Quote:
Originally Posted by cynwulf
//edit: Just read further back and it's astonishing that some people in this thread took shuttleworth's crystal clear blog post and concluded that 'buntu are not switching to systemd... it's obvious to me from the post that 'buntu are almost certainly moving to systemd.
And here I thought you had blocked me just like you said you would
I would guess that he has given it up as a bad job because your posts have become increasingly ad hominen in nature.
//edit: Just read further back and it's astonishing that some people in this thread took shuttleworth's crystal clear blog post and concluded that 'buntu are not switching to systemd... it's obvious to me from the post that 'buntu are almost certainly moving to systemd.
Well, the choice of a superior OS is not a guarantee of superior all-round intelligence I guess, because it is quite easy to see that Shuttlworth did not say Ubuntu wil be using systemd from now on.
You really need to learn to read between the lines, and to understand legalese/political communications more easily.
PS: as for the BSD's ... you'll be unpleasantly surprised about the next FreeBSD announcements ...
But isn't that impossible? Isn't one of the criticisms of systemd that it's Linux-only and can't be ported to the BSDs? So there you have it, your safe haven from systemd -- maybe Volkerding will choose to have it in Slackware some day (probably the day pigs fly) but in BSD you have a 100% guarantee that it will never happen.
Distribution: Debian Wheezy, Jessie, Sid/Experimental, playing with LFS.
Posts: 2,900
Rep:
Shuttleworth has made announcements in the past, that were clear and concise, and then not implemented the decision made in the announcement. Nothing with Ubuntu is ever clear until it happens.
And here I thought you had blocked me just like you said you would
I unblocked you some time ago, can't remember when - can't remember what I blocked you for either. (Not really into bearing grudges).
Quote:
Originally Posted by vl23
Well, the choice of a superior OS is not a guarantee of superior all-round intelligence I guess, because it is quite easy to see that Shuttlworth did not say Ubuntu wil be using systemd from now on.
You really need to learn to read between the lines, and to understand legalese/political communications more easily.
Yep... just resort to doing what you do best. That really does prove that you're the clever chap and we're all idiots...
Quote:
Originally Posted by k3lt01
Shuttleworth has made announcements in the past, that were clear and concise, and then not implemented the decision made in the announcement. Nothing with Ubuntu is ever clear until it happens.
That's a valid point, but it doesn't really change that shuttle said they're going to systemd, so shuttle changing his mind is possible - but would be a u turn on his part. For me, his blog clearly says that they are following Debian and moving to systemd and he talks about upstart in the past tense.
I unblocked you some time ago, can't remember when - can't remember what I blocked you for either. (Not really into bearing grudges).
Yep... just resort to doing what you do best. That really does prove that you're the clever chap and we're all idiots...
That's a valid point, but it doesn't really change that shuttle said they're going to systemd, so shuttle changing his mind is possible - but would be a u turn on his part. For me, his blog clearly says that they are following Debian and moving to systemd and he talks about upstart in the past tense.
Could you please stop hijacking this discussion, Tobi's damage was enough, thanks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.