| 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[19]: lie-nux at it again. |
| By Laurence on 2012-10-28 11:35:41 |
|
> 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. But that's exactly what happens in Linux as well! > 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. I repeat, Windows Update. I've been polite but I sense we're now going round in circles. > 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. No, I'm getting the impression that you don't really know what you're talking about so grasping onto some anecdotal evidence as your reasoning. This is going to be a lengthy post, but I'll explain things properly. Firstly, Windows /DOES/ have dependency issues, but they're hidden. However to explain why, I'll first discus the way Windows dependencies work. In Linux, you can have more than one version of a shared object running concurrently, but that requires a manual configuration. The reason being is that all the shared libraries are stored by version number (eg ssl.so.0.9.5) then symlinked to the objects name (eg ssl.so). Applications are then ran against the symlinks. So applications expect to run against the latest versions of all the dependencies installed because that's typically what's symlinked - which then causes issues if the application is either newer than the dependencies (also an issue on OS X and Windows - obviously) or if the application is older than the dependencies. This can be worked around with additional directories with sets of symlinks to earlier libraries and then adding those directories to the environmental variables (LD_LIBRARY_PATH IIRC). However that's way more technical than any desktop user would be expected to go, so package managers instead keep a central repository of all applications and ensure that everything is compiled against the latest libraries to avoid any conflicts. Windows, on the other hand, has a system where applications are compiled against version numbers rather than library names. This means that you end up with a significantly bloated install as instead of one copy for each library, you need several (eg for .NET version 3, you also need every prior version installed as well). This is great for usability though as it means that: a) previous dependencies can be shipped with the OS as you know they'll be required b) users only need at least version 2 of .NET in order to run any .NET v2 applications. However, and to reiterate what i said above, that also means that the dependency disk footprint is massively greater than on Linux. eg a .NET v3 application will depend upon versions 3 and every version previously as well. Because without versions 1 and 2, version 3 cannot install. So a "standalone" .NET 3 application could quickly run into a dependency issue of several hundred megabytes instead of a few dozen megs on Linux. However on Linux, it may be a much more significant job getting an older application to run outside of installing it from the repos, but the dependency footprint would be significantly lower. To further confuse issues, Windows does also have some statically named dependencies as well (typically core Windows libraries). And that means that any application that depends upon newer versions of those libraries will force the users into installing a Windows Service Pack - another few hundred megabytes of dependencies on top of .NET et al. So yes, I do agree with you that the Linux shared object method is a pain at times, but every single example you've given thus far has been a grossly inaccurate representation of why Linux shared objects cause problems. The actual reason is Linux shared objects suck is because, by default behaviour, Linux doesn't prefer to run multiple versions of libraries running concurrently and thus provides no automated / spoon-feeding tools for users to perform such tasks. So it's down to a seasoned sysadmin to manually side-load libraries and create sandboxed shells for them to run from. But quite honestly, distros like Ubuntu do a decent job of eliminating the need to have multiple concurrent libraries anyway. It's more of an issue when running enterprise level distros on servers (which is why you've ran into problems), but in those cases sysadmins are expected to at least understand the basics of what I've just explained. Which goes back to my earlier point; if you want to be spoon-fed then don't bloody run an enterprise level distro. They're powerful OSs but designed to be handled by experienced users rather than noobs who read that Linux is good on servers and so then jump in with both feet. Much like how OS X is a great desktop version of Unix but that doesn't mean that your average OS X user would even have the slightest idea how set up a Solaris server. Choosing the right Linux/Unix for a job is as much choosing the right *nix for the user as it is choosing the right OS for the servers role. So yeah, you were kind of right that Linux shared objects can be an utter bind at times. But not for any of the reasons you'd given. |
 - Score: 3 |
| RE[4]: lie-nux at it again. |
| By Laurence on 2012-10-28 11:48:56 |
|
> Not quite true, that's what Linux should do. ;) What Linux usually does (unless vm.oom_kill_allocating_task is set to 1) is attempt to kill programs that look like memory hogs, using some kind of heuristic. In my experience, that heuristic knocks out the offending program about half the time... The other half the time, it knocks out X. I stand corrected. Thank you :) |
| - Score: 2 |
| RE[8]: lie-nux at it again. |
| By Laurence on 2012-10-28 11:53:19 |
| Ahh yes sorry. Thanks for the correction :) |
| - Score: 2 |
| RE[20]: lie-nux at it again. |
| By MOS6510 on 2012-10-28 12:02:15 |
|
> > 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. But that's exactly what happens in Linux as well! Yes, if the product you are installing is in the defined repositories you have a good chance it will do that. Anyway, if you install stuff on Linux you encounter dependancies. I don't mean this as a bad thing, it's just something that pops in to view. When I install stuff on Windows or OS X it's not something that pops in to view or is any issue. Download a random piece of Window software and chances are very low it will fail because you are missing something. > I repeat, Windows Update. I've been polite but I sense we're now going round in circles. Windows Update updates Windows and some Microsoft products, it's not comparable to apt, yum, rpm or any other package manager. > Which goes back to my earlier point; if you want to be spoon-fed then don't bloody run an enterprise level distro. They're powerful OSs but designed to be handled by experienced users rather than noobs who read that Linux is good on servers and so then jump in with both feet. Much like how OS X is a great desktop version of Unix but that doesn't mean that your average OS X user would even have the slightest idea how set up a Solaris server. Choosing the right Linux/Unix for a job is as much choosing the right *nix for the user as it is choosing the right OS for the servers role. I've been working with Linux since 1998 or so. At work I have a number of Linux servers, physical and virtual. I'm not looking for a spoon feeding Linux distribution to use on a desktop. It's my job to install Linux and Windows servers and to maintain them. That's how I got the money to buy all that Apple stuff. I've even got a fluffy Tux and a Geeko. Sure I've had my share of 'challenges' with dependancies, but it wouldn't be a reason I'd use to tell someone about the downsides of Linux. My technical Linux knowledge exceeds my OS X one by far, because I have no idea how OS X works as I never had to bother with under-the-hood stuff. That's why I switched from Linux to OS X, because I was wasting too much time getting things to work and jumping distributions to find something that did get its act together. The only point I'm trying to make is that dependancies are a far bigger issue on Linux system than they are on Windows and OS X ones for users. If a Linux user starts talking about some piece of software and you ask about its dependancies he may or may not know them, but he would know what you mean. Ask a Windows or OS X user about them and they wouldn't know what you are talking about. I'm not saying dependancies are a bad or nasty thing, or that Windows/OS X are better. From a standpoint of having most control the Linux way is probably much better, but that's not my point. And that point is: Windows and OS X users don't know about dependancies, because they are never an issue. |
| - Score: 2 |
| RE[21]: lie-nux at it again. |
| By WereCatf on 2012-10-28 12:19:23 |
|
> Yes, if the product you are installing is in the defined repositories you have a good chance it will do that. Anyway, if you install stuff on Linux you encounter dependancies. I don't mean this as a bad thing, it's just something that pops in to view. This is not directly a reply to you, but this is a good place to explain this to the other people here: Under Windows and OSX there is already a common base to target so it's easy enough to target that. Under Linux there is no such a common base so often you do end up needing to install some extra packages. Also, under Windows and OSX there is no system service that would handle installation of external dependencies, so any application you install under those operating systems has to package all of its dependencies with it. Compare this to Linux where there is such a system service and therefore applications do not need to package all of the dependencies along -- this results in much less system bloat and much better sharing of resources. If you have a Windows - installation just go and check the size of your WinSxS - folder... It may seem complicated and annoying, but there are clear reasons for why the system is implemented like this. Sure, it could be improved to automatically remove unneeded dependencies if one removes a package, and to handle multiple versions of the same package with differing dependencies -- like e.g. package Y could have two different versions, one with support for X11 and one without, and it'd install the one with less dependencies by default and switch over to the one with X11 as dependency if the user installs X11 at a later date. Alas, no one seems to care enough about this. |
| - Score: 2 |
| RE[9]: lie-nux at it again. |
| By Alfman on 2012-10-28 17:24:20 |
|
Soulbender, "The reason Linux has OOM is because Linux allows you to over-commit memory." It's not strictly the only reason to have OOM killer, even if memory hasn't been "overcommitted", requests for more memory can still fail. Linux will apply heuristics to kill a process other than the one requesting memory. "Which approach is better can be discussed at great length but hopefully not here." I was hoping to hear more opinions about it, but maybe most people aren't familiar enough to have an opinion. |
| - Score: 2 |
| RE: lie-nux at it again. |
| By KrustyVader on 2012-10-28 17:48:23 |
|
Linux have lots of problems, GNome and KDE create, from my point of view, create a madness with the libraries dependence. Sometimes for installing a simple program i need 30 libraries. Thankfully there are lot of option in Linux, and for some reason i keep choosing Slackware as a base installation (but without KDE). And for Real Time O.S. QNX is (sadly) no more a valid option. It belongs to RIM and you can guess what will happen. |
| - Score: 1 |
| RE[21]: lie-nux at it again. |
| By Laurence on 2012-10-28 18:09:57 |
|
> Yes, if the product you are installing is in the defined repositories you have a good chance it will do that. Anyway, if you install stuff on Linux you encounter dependancies. I don't mean this as a bad thing, it's just something that pops in to view. When I install stuff on Windows or OS X it's not something that pops in to view or is any issue. Download a random piece of Window software and chances are very low it will fail because you are missing something. But you're not supposed to install stuff outside of the repos in Linux. Do you even have a slightest idea how to use Linux, but that's an insanely weak point to make. > Windows Update updates Windows and some Microsoft products, it's not comparable to apt, yum, rpm or any other package manager. It's not the same, but it is comparable. They both manage security patches and API dependencies. > I've been working with Linux since 1998 or so. At work I have a number of Linux servers, physical and virtual. I'm not looking for a spoon feeding Linux distribution to use on a desktop. It's my job to install Linux and Windows servers and to maintain them. That's how I got the money to buy all that Apple stuff. I've even got a fluffy Tux and a Geeko. Yet you've failed to grasp every single point about Windows and Linux raised? > My technical Linux knowledge exceeds my OS X one by far, because I have no idea how OS X works as I never had to bother with under-the-hood stuff. That's why I switched from Linux to OS X, because I was wasting too much time getting things to work and jumping distributions to find something that did get its act together. That I can sympathise with :) > The only point I'm trying to make is that dependancies are a far bigger issue on Linux system than they are on Windows and OS X ones for users. And I agreed with you on that. However every other point you've made to back up that assertion has being wrong and often bording on complete ignorance. > If a Linux user starts talking about some piece of software and you ask about its dependancies he may or may not know them, but he would know what you mean. Ask a Windows or OS X user about them and they wouldn't know what you are talking about. I have no idea what software have what dependencies and I run one of the more hands on distros. And to say Windows users aren't aware of .NET, DirectX and such like is just laughable. Edited 2012-10-28 18:10 UTC |
| - Score: 2 |
| RE[2]: lie-nux at it again. |
| By Gullible Jones on 2012-10-28 18:45:47 |
|
Linux desktops have (IMHO) taken a turn for the worse lately, but don't mistake that for what's happening under the hood. Newer kernels have some really cool features (and IMO perform better on ancient hardware than the old 2.6 series). (And fortunately there are still Mate and Xfce on the desktop front. Also Trinity, though that doesn't seem to be as functional right now.) |
| - Score: 2 |
| RE[6]: lie-nux at it again. |
| By foregam on 2012-10-28 18:53:20 |
|
man sh Scroll down to ulimit and read about all things you can put limits on. dd is not a problem by itself. |
| - Score: 4 |
| News | Features | Interviews |
| Blog | Contact | Editorials |