Nuxified GNU/Linux Help Forums - performance - Comments

Thoughts

reptiler — Fri, 05 Oct 2007 16:08:23 +0200

albertfx wrote:

To push the idea further, Linux should be able to have the kernel build fully automated with no user intervention.

This actually is a tough one. I tried this for EasyLFS, my own little distro, and so far I didn't find a way that really makes me happy. For now I have a pre-configuration, that is based on a standard-setup I constructed, plus patches based on the choice of software, like when you choose to install dmraid you'll also have device-mapper support in the kernel.
The user then, more or less, only has to select the proper CPU and drivers for drive-access and things like that (like NICs, sound, etc.) But many, or most, of the "overwhelming" choices, like all these options most people have no idea what they do before you read the docs and stuff on the net, are done already by my pre-configuration.
But anyway, I wouldn't claim my project to be userfriendly, it's a source-distro, so I just try to not make it unnecessarily complicated.

As for most distros, usually the kernel come with the full set of modules, and by now these usually get loaded quite reliable, so that manual modprobing should not be necessary anymore, except for a few exceptions like KQEmu or NDISWrapper.

albertfx wrote:

Also, hardware detection capabilities should be a modular and expandable utility so that a running Linux can have its autodetection module updated like any other packageg; that way the system can truly update itself without the need for reinstallation. Linux distros need to achieve an install and the system able to keep itself fully up-to-date, optimized, and able to auto-reconfigure itself on-the-fly as per hardware requirements and capabilities.

This, I guess, is where UDev and HAL are destined to go. They already work quite nicely, UDev can create and remove decices on demand, even with really useful names, like /dev/mp3stick, and HAL can integrate these devices throughout the system, like creating a mount-icon on your KDE-desktop.

article is a very fine piece of reflection

albertfx — Fri, 05 Oct 2007 15:47:09 +0200

I very much like this article. It brings up something very important, quality as usabiltiy. Linux distros have many fine things about them, but there are only a few that come ready to rock as full multimedia desktop OSs without the infamous "post-install attentions." Now personally when a users has to do extensive post-install activity to get things going, I feel that is a bad thing. Sabayon linux is a fine example of a distro not needing the user to do anything after installation except enjoy it.
.
Another issue is upgrading. Too often upgrading the system amounts to reinstallation with /home partition separate and untouched. I have often experienced Grub being smacked down with kernel related upgrades through the built-in upgrade features be it apt, adept, or Synaptic: that is why I stay with Aptitude.
.
Autodetection was "invented," I believe, with Knoppix. but autodetection needs to be more agressively pushed: why does the user not have install choices that include optimization choices on kernel just as he might choice Kde, Gnome or Xfce. To push the idea further, Linux should be able to have the kernel build fully automated with no user intervention.
.
Also, hardware detection capabilities should be a modular and expandable utility so that a running Linux can have its autodetection module updated like any other packageg; that way the system can truly update itself without the need for reinstallation. Linux distros need to achieve an install and the system able to keep itself fully up-to-date, optimized, and able to auto-reconfigure itself on-the-fly as per hardware requirements and capabilities. The need for distros to keep releasing new ISOs as the primary way to make the next version available should be a sure sign that the updating process is unacceptable.
.
Another important area of usability, is for the user to be able to identify (tag) software for upgrading, because the current way of upgrading everything is too high risk. I have done upgrades to a bunch of things and then added a few hundred packages and my linux craps out. So the Debian apt updating is not bullet-proof -- hence it needs to be oriented to being fully user controlled as per the user easily able to select a subset of packages that the system should monitor for upgrading.
.
Performance is a great idea, vista's window manager makes me shudder, but that is only one aspect or type of resource waste. The user-base does drive development; the user-base is not the enemy of the developer -- you made this point very well.
I will stop here... now this may all seem like pie-in-the-sky so I will just say that some of the things I talked about is currently happening on OS X.
.
OS X, after a single install, can be upgraded - including the kernel - and be kept fully up-to-date. And after a year of poking around, I can't find maintenance chores to do on this system. It does not require me to do anything to keep it up-to-date and pumped.
.
For the record, I have Debian Linux, Windows XP and OS X boxes on a home network, with my primary workstation being the Linux box ... the wife and kids live on the OS X: Whenever I user OS X I feel like I am having an affair.

That is pretty shortsighted...

KarlNapf — Fri, 27 Jul 2007 20:53:19 +0200

You can go out and buy 4 CPUs in one little package right now (Quad-Core CPUs). So how long do you think will it take for 16 core boxes to become available in the hardware store next to you?

How can you get some use out of all those cores? The only way I see is by running virtual machines on them! Virtualisation is the big thing in commercial setups, because of this... just wait a year or two for that realisation to drift down to the home users.

Starting to develop that kind of feature once users are crying for it will be too late.

Although I understand the

reptiler — Fri, 27 Jul 2007 09:23:17 +0200

Although I understand the points I prefer staying on the site supporting the current model of "one kernel for everybody".
As said before the kernel has seen big improvements over the past years, not only in terms of features nobody needs for the next 5 or 10 years, but also in terms of performance.
Also, if you configure the kernel yourself, I know all the options are intimidating, but it's really not that hard (okay, probably still too hard for Joe User), you can get a nice slim kernel that only has what you need, and not a lot of other stuff you don't need. Also building everything static into the kernel can speed things up a little, at least at boot-time.

Another thing is that boot-time varies from distro to distro. I can boot EasyLFS in QEmu on my notebook and can login after 20 seconds, from Lilo to login, including startup of LVM, SSH and HAL.
Fedora 7, which is installed on my notebook, so no QEmu in between to slow things down, takes one minute and ten seconds from Grub to login.
Linux from Scratch on my PC presents the login screen after around 35 seconds, and that is a much more complete system than the EasyLFS-installation I have running in QEmu.

It depends alot on what distros do, and what kind of stuff they want to fire up at boot-time. I think you can easily see the difference of the distros in the previous paragraph.
Fedora and my Linux from Scratch both are fully usable systems, including graphical login and everything I need for my daily work and fun. EasyLFS is a pretty naked development-image in QEmu, but although it runs in an emulated environment it's ready for login after about 20 seconds. Imagine how fast it could be there if running directly on the CPU!

So, that mentioned maybe we should better think about something that's far easier than deslacking the kernel: Deslacking distros to get better boottimes and better responsiveness.

faster yet slower

stolennomenclature — Fri, 27 Jul 2007 08:32:50 +0200

It is galling that despite computers getting faster and faster, the software seems to get slower and slower. Ive also noticed that often dual core makes little difference (especially under Windows XP more so than Linux), where software still hangs waiting while an optical disc is loaded despite the second cpu.

It makes perfect sense about the influence of the server marketplace in Linux. So many of the new features introduced into the kernel have a corporate feel to them. One good example is virtualisation. How many ordinary desktop users are really likely to want this feature, and now there are three or four versions of it. Also the amount of work gone in to enable support and performance with 16 or more cpu's - again not a desktop profile.

Perhaps it is time for some group to fork the kernel, and domesticate it. Get rid of the unwanted enterprise bloat, and make a lean and mean desktop real time kernel with features that appeal to the mainstream and much more numerous users.

After all, the enterprise people have lots of dough and can afford to patronise Microsoft.

I agree

Brotherred — Fri, 27 Jul 2007 04:43:38 +0200

I have been thinking the same thing for some time. Don't get me wrong I love thinking that our kernel runs everything from mainframes to cell phones but this is just to much for one OS or kernel as it were. Yes each distro does special build its own kernel however those customizations are higher level than they really need to be.

I have read on Slashdot and others some criticism of the Con for his actions here. I ask just how long do people expect a man who is probably the best advocate for us desktop users to bang his head on the wall?

Honestly what should happen is that Conical or Fedora should pick up other really good hackers like the Con and pay them full time. The server side has this already as anyone knows. What we do not have is commercial viability for desktop kernel hacking.

We do not have it and the kernel will regress until we do.

Brotherred

The problem is userspace.

yosumiru — Fri, 27 Jul 2007 02:43:40 +0200

all this blame on the kernel is totally unfounded. Linux Kernel is a high perfomance kernel which is as good or better than any. but in glibc and other crucial userspace libraries, portability over perfomance is the main objective (imho). Perfomance has only recently been a priority in gcc/glibc and that too on x86-class.

CK patcheset was great, but part of what Con is talking about in the interview, "not being able to measure and quantify with certainty" is because of the userspace libs. One can only add so much to the kernel in terms of perfomance without breaking everything. If Perfomance improvements has to happen, start with glibc and xlib.

Forking a kernel is an

libervisco — Fri, 27 Jul 2007 02:38:07 +0200

Forking a kernel is an idea, albeit a provocative one I would admit, but that makes it a very good discussion starter which is really a point of this article. CK made certain points I believe should not go unnoticed and I've wrapped them up and fired up a suggestion that some might find appalling and others perhaps brilliant, but at least we're talking about something other than the status quo, about potential alternative ways forward and also other ways of thinking.

So maybe fork is not a best thing to do, but maybe this discussion results in more emphasis being put on the points that CK made and on doing at least *something* about them.

You know, I just don't buy

libervisco — Fri, 27 Jul 2007 02:29:04 +0200

You know, I just don't buy the "too many to choose from" argument anymore. It's a dead argument if you ask me. If people don't wanna choose then they can let someone else choose for them, and there are plenty of people who would do that for them to go around, from local geeks to companies specifically aiming at the undecided crowd looking for a best "default" option. I think Ubuntu is playing that role quite well as it's increasingly becoming obvious that if they don't know which distro to go with, they'll likely just get Ubuntu and start there.

So why is choice such a big problem?

And besides, how is forking a kernel really gonna affect desktop users? They barely even know what a kernel is. All they hear about these days is Ubuntu, Mandriva, SuSE and whatnot and also about the "Linux" thing though many barely know what the heck that "Linux" thing actually represents. Not everyone even agrees that this "Linux" thing is "Linux" because it might as well be "GNU/Linux".

Which is why I mentioned the "kill an OS" part. Just do away with the whole notion of there being this boundary between one system and another based on which kernel it runs, as if that really matters to end users. And in the Free Software world, what runs on GNU/Linux will likely run on any other *nix, and even further (because there is the source code) making what were once considered solid lines dividing various systems largely irrelevant. It is all just Free Software.

So if forking a kernel is a way for a certain segment of Free Software developers, advocates and companies to strengthen their focus on the desktop market, making it possible for them to innovate and evolve on the desktop faster than anyone else, then why not just go and do it? All this boo hoo about supposed divisions, fragmentation etc. are just illusions stemming from an old way of thinking about computing, in terms of boundaries which are not really relevant anymore. Why? Because of the very free nature of Free Software.

These may have been relevant for UNIX and they may be relevant for other proprietary platforms, but that's exactly because they were *proprietary*.

It's time to stop being so damn afraid of forking. Forking is what made Free Software what it is today. Free Software is largely exactly about the freedom to fork, or in other words, freedom to innovate *your way* for *your needs* if you believe that to be better for you.

And there is absolutely nothing wrong with that.

Welcome aboard Alphaman.

The problem is choice and authority not the kernel

xylifyx — Thu, 26 Jul 2007 22:41:10 +0200

The problem for desktop Linux is not the kernel, it is all the choices that is involved in using Linux. We need a single distribution that drives those choices, similar to what the OLPC people have done. Nobody in the Linux world dares to make choices because of all the discussions that follows. Define some goals and design the system according to those and have people in authority to make the necessary choices. If the kernel is too bloated, configure it and remove the unneeded features.

Another problem we need to adress is the underlying assumption of UNIX, that there is a technically capable system administrator that can configure and administrate the system.

servers vs desktop

phobos — Thu, 26 Jul 2007 21:38:57 +0200

"MidnightBSD was forked from FreeBSD 6.1 beta. [...] With MidnightBSD, we wish to focus on optimization and usability improvements for desktop users. The FreeBSD project has developed a reliable server operating environment, but often usability and performance on the desktop is overlooked. Scheduling, allocation of resources, security settings, and available application support should be tailored to desktop users. Many of the BSD projects are tailored to servers or older hardware. Others are distributions of FreeBSD with a nice graphical user interface, but still suffer from server centric design under the hood. We did not fork FreeBSD as a result of a falling out, but rather as an excellent starting point. It should be viewed as a compliment to the FreeBSD developers who have worked very hard on FreeBSD 5.x and 6.x." http://midnightbsd.org/about/index.html

sounds awfuly similar as an idea.. separating a server OS from a desktop OS.. itÂ´s the same as main Windows vs. their server line (2003 and the new one with vista) and also Mac OS X vs their own mac os server .. and the desktop and server versions are not incompatible between themselves.. if it works for them, it might work for linux too... a linux more solaris-like for the servers and one more like mac os X and plain XP (or Vista) for the desktop, maybe?

Wow, great idea!

KarlNapf — Thu, 26 Jul 2007 18:49:38 +0200

So linux is bloated, does not communicate properly and is not innovative. I can understand, that somebody gets this impression, but how does forking help?

Do you really think that all of a sudden all the bloat will just magically melt away? It won't. It will be a huge amount of work to get the fork debloated and you will see heated discussions: Is e.g. devicemapper bloat? Does a desktop user really need LVM, crypted partitions, etc.? And do not forget that today's mainframes are tomorrows desktop systems: Where would dual-core support be today without the SMP work done for the "mainframes" in the 90?

Where is the innovation going to come from all of a sudden? Splitting up a developer community does not automatically do that! You need to draw lots of new developers to get one or two with some fresh ideas... I doubt that this will happen without some really overpowering personality as a core developer. Where are you going to take that one from? Are you volunteering? I doubt that you are the right person for that job (both technically and PR-wise).

That leaves the communication issue. I doubt that a fork will do much good there. Most users just do not care about the kernel: It is just something that works (or sometimes does not). Why do you think that perception will change all of a sudden? Desktop users will not happily jump onto the fork-bandwagon and turn into kernel hackers overnight, being innovative.

After forking you are going to do a lot of work to keep up with the original you forked from: You want to get the good ideas, the drivers, etc. into your fork. So you have to stay pretty close to the original or spend a huge amount of time adapting patches so that they will work on your fork. Where do you take the time for your innovations from then?

Forking is not worth the effort. Improving the communication to the kernel developers is. We would all be better of with more people like CK (just in case you are reading this: Thanks for the work you did, sad to see you leave for greener pastures), mediating between the users and with the technical understanding to interface their desires to the kernel hackers. Developers are a special bunch of people... they just are not compatible with the Joe User.

Best Regards,
Karl

"Keeping the kernel whole

Alphaman — Thu, 26 Jul 2007 18:33:02 +0200

Alphaman wrote:

Keeping the kernel whole and unforked and uniform is the only way to gain market share on the desktop and the server.

I think that in and of itself is enough of a reason. It's bad enough that most regular Joe's that are toying with the thought of switching to Linux get put off by the 300 active distros. Now could you imagine the 300 active distros PLUS different kernel variations? Talk about a cluster f*ck. It also wouldn't help in making CIOs decisions any easier especially if they are on the fence. As for the BSDs and Solaris that's FOUR out of how many? Let's start.

OSF/1
Tru64
HP-UX
AIX
MINIX
DG/UX
Irix
SCO Unixware
Unisys
Xenix
Ultrix
QNX
Dynix
Acorn RISCiX
Concentrix 4.1
UTS 2.4 and UTSV 5.2.6b
DomainOS SR10.0 and 10.4
A/UX
MachTen 2.1.1.D
MiNT
MINIX ST 1.5
BOS/X
UNOS
Convex/OS
DNIX
UMax
FPX
TOS

Those are the failures I can think of off the top of my head. I am sure there are WAY more to list but I got tired of thinking. Point is it is a plain old BAD IDEA. period.

if you read my post above

free-zombie — Thu, 26 Jul 2007 17:58:02 +0200

if you read my post above carefully, you'll see that forking Linux wouldn't have to make it any less unforked and uniform. It'd be all about marketing a specific developer's linux version which participates in the Linux git code-sharing ecosystem there is as anyone else can do already. (The "usual" type of fork involving two repositories that eventually diverge strongly would indeed be VERY undesirable)

Is there a "why YOU should be using MY tree instead of Linus'" wiki out there ?

Although I also think that

reptiler — Thu, 26 Jul 2007 16:32:55 +0200

Although I also think that forking might be not the best way, as explained above, I would prefer you to give some reasons for that, instead of just pointing around at other stuff, that's, like Bob, not really related.
Also I think that at least some Unix-forks didn't do so bad, just look at the BSDs, still in active development and pretty spread. Also Solaris isn't doing so bad.