| News | Features | Interviews |
| Blog | Contact | Editorials |
| SCHED_DEADLINE v6 released |
| By special contributor cloud on 2012-10-27 01:05:38 |
| A new version of the real-time Linux scheduler called SCHED_DEADLINE has been released on the Linux Kernel Mailing List. For people who missed previous submissions, it consists of a new deadline-based CPU scheduler for the Linux kernel with bandwidth isolation (resource reservation) capabilities. It supports global/clustered multiprocessor scheduling through dynamic task migrations. This new version takes into account previous comments/suggestions and is aligned to the latest mainline kernel. A video about SCHED_DEADLINE is also available on YouTube. |
|
| RE[5]: lie-nux at it again. |
| By Soulbender on 2012-10-28 02:25:01 |
|
> the good os is simple in architecture, which makes it reliable and easy to add to ( modules ) or remove. You're confusing your own opinion with facts. > so this talk about "user-land" is shouting out that in linux there is not natural separation between kernel and "what ever one might call it" Say what? The fact that one is kernel space and the other is user land says exactly that: that there is a separation. > i have 512 megabyte in my desktop ( mint linux ). i have to restart most days. it just hangs. It's not 2002 anymore, use the right tool for the job. Mint is obviously not the right choice for such a resource starved system. > i only use mint linux because the windows xp machine was not allowing me to access the win-xp boot partition. How is this relevant? What does it even mean? > don't forget the aspect of these complicated "dependencies" when one has to "install" some program. It's 2012, we have reliable tools to handle these tings now. > what happened to the unix method of copy some program to a directory and just use it ?? I think you're confusing Unix and DOS. |
 - Score: 4 |
| RE[6]: lie-nux at it again. |
| By Soulbender on 2012-10-28 02:28:25 |
|
> Please don't insult our intelligence with such blatant lies. Scroll to the end: http://www.openqnx.com/phpbbforu... Still, it's the one and only reference to this OS I can find. |
| - Score: 4 |
| RE[7]: lie-nux at it again. |
| By WereCatf on 2012-10-28 02:54:28 |
|
> > Please don't insult our intelligence with such blatant lies. Scroll to the end: http://www.openqnx.com/phpbbforu... Still, it's the one and only reference to this OS I can find. That's the one I googled, too. He says he started working on it in 2002 and by 2006 he still didn't have any sort of a GUI or task-switching, ie. it was merely a single-process OS. And there is no actual indication that he had done any of the coding himself -- with his clear misunderstanding of basic concepts I feel it's highly likely he has just borrowed code from others. An interesting fellow. |
| - Score: 3 |
| RE[15]: lie-nux at it again. |
| By demosthenese on 2012-10-28 04:07:54 |
|
"On a server, without GUI, it downloaded X11 + its dependencies because I wanted to install some graphic conversion utility (CLI based!). Removing that tool removes the tool, but not X11." apt-get install --no-install-recommends foo I suspect would have been the way to avoid installing X. apt-get remove --auto-remove foo will get rid of all unused dependencies. You could clean up all unused dependencies with apt-get autoremove or use deborphan for those who prefer a gui. Also apt-get --simulate .... will allow you to see what the results will be before you mess things up. I recommend you have a look at man apt-get |
| - Score: 2 |
| RE[6]: lie-nux at it again. |
| By Hiev on 2012-10-28 04:13:09 |
|
I think you're confusing Unix and DOS. Well, to be honest, that's the way Unix works, just copy the files to a directory and works. |
| - Score: 2 |
| RE[8]: lie-nux at it again. |
| By Alfman on 2012-10-28 04:42:25 |
|
Gullible Jones, "Have to disagree; IMO the entire goal and purpose of a multiuser OS is to prevent users from stepping on each other's toes. Obviously some of this is the sysadmin's responsibility; but I do think it's good to have default setups that are more fool-proof in multiuser environments, since that's probably where Linux sees the most use." I agree with the goal and that there may be better defaults to that end, however sometimes there isn't anything an OS can do to solve the problem if resources are oversubscribed in the first place. For instance, on a server with 10K hosting accounts, one cannot simply divide the resources by 10K since obviously most accounts aren't busy at any given time and those that are may be seriously underpowered. As a compromise, the policy on shared hosts is to over-subscribe the available resources to make service good enough for active users most of the time. Unfortunately an over subscribed service will necessarily suffer if too many users try to make use of it at the same time. Every single shared hosting provider I've used has had performance problems at one time or another. I confess, one time I was guilty of bringing down the websites of everyone on a shared server :( Apparently apache/mod_php has an open file limit and I was running an application that consumed too many of them. It was neither memory nor cpu intensive, but the system was never the less unable to serve any further requests. Using any ulimit quotas at all on shared daemons like apache can result in this kind of denial of service. The issue gets even more complicated because it's impossible to determine which domain (and therefore user account) an incoming request is for until the HTTP headers are read. It means there's nothing the OS can do anything about this case and the shared daemon itself has to be responsible; it's quite the dilemma! "Re handling of OOM conditions. IIRC the BSDs handle this by making malloc() fail if there's not enough memory for it. From what I recall of C, this will probably cause the calling program to crash..." I agree that malloc should fail if there isn't enough ram. To me the deferred allocation scheme under linux is like a broken promise that memory is available when it isn't. It should always return a null, (which can be handled by the caller without crashing). Edited 2012-10-28 04:47 UTC |
| - Score: 3 |
| RE[7]: lie-nux at it again. |
| By Soulbender on 2012-10-28 05:20:27 |
| From the context I think he mean you don't need to worry about libraries, dependencies and such. |
| - Score: 2 |
| RE[18]: lie-nux at it again. |
| By MOS6510 on 2012-10-28 06:45:13 |
|
> However you keep making comparisons to Windows, yet Windows doesn't do any dependancy management what so ever. If an application says it requires a specific framework, then the user is required to download and install that themselves and subsiquently uninstall it themselves when they're done. Just like OS X, but the point is that the need for installing dependancies is very rare and if it occurs the installer will do it for you. Hence there is no need for a package system with dependacy checking. On Linux this need is much greater, explaining a number of package systems. Perhaps it's better I'll leave it at that, because you keep getting the impressing I'm complaining about Linux while glorifying Windows and OS X: I'm not. I happily use Linux on servers and prefer it to Windows and OS X. On the desktop I prefer OS X. The 2nd best choice would be Windows 7, but I'd still pick Linux. |
| - Score: 2 |
| RE[12]: lie-nux at it again. |
| By Sodapop on 2012-10-28 08:46:32 |
| Which is more than I can say for Win-sux. |
| - Score: 0 |
| RE[8]: lie-nux at it again. |
| By Soulbender on 2012-10-28 09:22:30 |
|
> Re handling of OOM conditions. IIRC the BSDs handle this by making malloc() fail if there's not enough memory for it. From what I recall of C, this will probably cause the calling program to crash, which I think is what you want in most cases - unless the calling program is something like top or kill! The reason Linux has OOM is because Linux allows you to over-commit memory. I'm a bit hazy on the exact reason for this but it had something to do with effective fork'ing of processes that used a lot of memory. The BSD's does not allow over-commit and instead malloc (or whatever) will fail. Which approach is better can be discussed at great length but hopefully not here. |
| - Score: 3 |
| News | Features | Interviews |
| Blog | Contact | Editorials |