DebianThis forum is for the discussion of Debian Linux.
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.
View Poll Results: systemd vs. upstart, or else?
sysVinit: if they can't decide just keep the status quo, it has worked for 40+ years.
I don't know where you got this from, but jails are a completely different thing. You can use cgroups and containers to achieve something similar to jails, but you don't have to use it that way, mostly it is used it to limit resources for specific processes and make it easier to reliably shut down their child processes, without separating them from the original system.
Wrong, jails have had the capability to cap cpu, RAM and other resources for some years now, as to clean child murder do the terms process group and session ring a bell?
Wrong, jails have had the capability to cap cpu, RAM and other resources for some years now, as to clean child murder do the terms process group and session ring a bell?
Yes, jails have that capability, but cgroups does not have the other capabilities of jails, so saying cgroups = jails is plain wrong. If you want to compare jails with anything on Linux you might better compare it to LXC and/or chroot in conjunction with ggroups.
Yes, jails have that capability, but cgroups does not have the other capabilities of jails, so saying cgroups = jails is plain wrong. If you want to compare jails with anything on Linux you might better compare it to LXC and/or chroot in conjunction with ggroups.
So, to summarize:
Jails provide you with more features, and have been around longer, ergo they are a superior solution.
Also it seems like nobody is mentioning things like cpu sets, ulimits, quotas and the other UNIX/linux ways to cap resource usage that have been around since forever.
Again, to sum things up, cgroups is basically just a bunch of old tricks made easier to use by idiots and idiot applications with an ugly virtual file system interface that just clogs mount output.
So, to summarize:
Jails provide you with more features, and have been around longer, ergo they are a superior solution.
I wouldn't say that, because cgroups doesn't aim to have the functionality of jails. In the same way you could say that XFCE is a superior solution to LXDE, because it is around for longer and provides more functionality, but that would be missing the point in the same way.
Quote:
Also it seems like nobody is mentioning things like cpu sets, ulimits, quotas and the other UNIX/linux ways to cap resource usage that have been around since forever.
Again, to sum things up, cgroups is basically just a bunch of old tricks made easier to use by idiots and idiot applications with an ugly virtual file system interface that just clogs mount output.
If you want to see it that way, do it. I wouldn't consider that to be true. cgroups for example provides an easy way to track child processes and reliably kill them, something that is very hard to do using the existing tools. Making things easier is not always a bad thing.
If you want to see it that way, do it. I wouldn't consider that to be true. cgroups for example provides an easy way to track child processes and reliably kill them, something that is very hard to do using the existing tools. Making things easier is not always a bad thing.
Did you actually read any of my previous posts, hint hint, there is one about process groups above.
i dont like changing what works so i vote and would vote in future for sysvinit!
also i did a test with a stopwatch.. my slackware boots faster than my mother mageia which uses systemd. 0:58 to 1:18.
i dont like changing what works so i vote and would vote in future for sysvinit!
also i did a test with a stopwatch.. my slackware boots faster than my mother mageia which uses systemd. 0:58 to 1:18.
Lol, that is still slow compared to the test Gentoo on KVM I built, 11 seconds to boot into the equivalent of runlevel 3 then a few more (3-4 max)seconds to start X with twm. Again.This is for a Virtual Machine!
Would be interesting to know which DEs are started, which services/daemons are started and so on. Just saying: "Hey, my Slackware boots faster than your Mandriva" or "Gentoo is faster than both" without sharing any details is as useless as benchmark as it can be.
Would be interesting to know which DEs are started, which services/daemons are started and so on. Just saying: "Hey, my Slackware boots faster than your Mandriva" or "Gentoo is faster than both" without sharing any details is as useless as benchmark as it can be.
ssh, ntp, an nginx web server and I am using dhcp on the system rather than static addresses(I should definitely disable that and go to static, since it will probably shave off a few parts of a second, considering how slow DHCP can be.)
All thad said I am planning to do a lot more where kernel compilation and other optimizations are concerned, for example I am only using -O2 compilation optimization since I am conservative, but i plan to try and use -O3 for a number of packages.
Still though I believe I am making decent headway for less than half a week of active experimentation/use.
standard/default slackware64 14.1 to xfce without any autostart.
standard/default mageia 3 to kde4 without any autostart.
i did not change any package or service on installation or after. i installed both as is.
i tested my windows (i still have - shame on me!) too. 2:58, vista ultimate 32bit with autostart of antivir, fdm, drivers for mouse and gameing devices and programs displaying cpu and gpu temperature.
i think up to 1 minute is a acceptable time for an pc to boot, for me that feels fast enough!
LOL no, Bare metal:
appp-->kernel-->drivers--hardware
VM appinguest-->kernelinguest-->driversinguest-->virtualization infrastructure and host kernel virtualization components-->on-metal hardware
It would only be useful if you are using a jail, and that is not what I am doing, the I/O wait and memory access time would be higher since VM mapping would have to go through 2 kernels instead of one, and since the disk is a file on the host system.
I like upstart a lot as it boots a lot faster than traditional SysV. I've written countless scripts for SysV and only started using upstart 6 months or so. Upstart scripts are a lot easier to write. Not just that, but I can easily specify when it should start (on filesystem, network, loopback interface, etc) and have all my boot processes start in parallel. And THAT is why SysV should be replaced.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.