Slashdot Mirror

I'm not really sure why C++ is so ill-favored lately. It may not be fully OO, but there are many times when a fully OO solution is counterintuitive. Instead, C++ allows the developer to choose whether they want an OO solution or not. I also see a lot of complaints about C++ performance in comparison to C performance, but really, when properly implemented there is little difference. The same goes for garbage collection. Granted you have to write it yourself, but program-specific garbage collection will ALWAYS be more efficient than automatic garbage collection.

I think it's generally agreed that C and C++ aren't going anywhere anytime soon, since a lower-level programming language will always be needed. However, sidelining C++ in favor of C is definitely not a good idea, as C++ does offer many advantages that C lacks. (Yes, even for kernel development.)

I'd go into more depth, but this article really does a good job of explaining it:
http://unthought.net/c++/c_vs_c++.html

This must be my favourite personal quest - because it was difficult, because I found a solution, and because that solution beat the crap out of some research groups rather respected solution (in a very sepcific use case though, but still).

The problem is to order rows and columns in a matrix so that a following QR factorization will be most efficient, computationally (the result of the factorization will not change with the ordering, but the amount of computational work changes as zeros and non-zeros are re-ordered by means of reordering rows or columns).

Tiny presentation of the optimization problem.

Page with pretty pictures of the original and re-ordered systems (a solution found by my optimizer).

And of course, you could just go ahead and read the whole deal - uh, did I mention the software is open source? :)

This must be my favourite personal quest - because it was difficult, because I found a solution, and because that solution beat the crap out of some research groups rather respected solution (in a very sepcific use case though, but still).

The problem is to order rows and columns in a matrix so that a following QR factorization will be most efficient, computationally (the result of the factorization will not change with the ordering, but the amount of computational work changes as zeros and non-zeros are re-ordered by means of reordering rows or columns).

Tiny presentation of the optimization problem.

Page with pretty pictures of the original and re-ordered systems (a solution found by my optimizer).

And of course, you could just go ahead and read the whole deal - uh, did I mention the software is open source? :)

This must be my favourite personal quest - because it was difficult, because I found a solution, and because that solution beat the crap out of some research groups rather respected solution (in a very sepcific use case though, but still).

The problem is to order rows and columns in a matrix so that a following QR factorization will be most efficient, computationally (the result of the factorization will not change with the ordering, but the amount of computational work changes as zeros and non-zeros are re-ordered by means of reordering rows or columns).

Tiny presentation of the optimization problem.

Page with pretty pictures of the original and re-ordered systems (a solution found by my optimizer).

And of course, you could just go ahead and read the whole deal - uh, did I mention the software is open source? :)

Yes, software RAID is great (effective, flexible, reliable, comparable in performance to cheap hw RAID) and we use it at our work but never would we deploy it for a customer... You say hardware RAID is a pain to manage? Compared to what? Surely not Linux software RAID! Are you kidding?

When the HDD fails with hardware RAID, you rip the drive out, replace it, and it starts rebuilding.

Linux software RAID only works on a per-partition basis.

When the HDD fails with Linux software RAID, you have to repartition the new drive, manually add it to the array that failed, and tell it to resync.

Not to mention the fact that if you are using software RAID on your /boot partition, you have to reload GRUB. And if you want to be able to boot from your secondary drive in 2xdisk RAID-1 mirror, you'll have to do this to install grub on the secondary disk:

grub
grub>device (hd0) /dev/hdc
grub>root (hd0,0)
grub>setup (hd0)

Otherwise, if your primary disk fails, you no longer have a bootable system. This is not good. This is not how hardware RAID would behave, as long as you have all your disks on seperate channels.

The software RAID HOWTO: Booting on RAID

Not so cool. A lot more hassle, overhead and oppurtunity for mistakes than hardware RAID.

So you're back to the old problem: cheap, good, fast, pick any two.

Is this the definitive article about software RAID under Linux?

Software-RAID HOWTO. In English and HTML: Software-RAID HOWTO.

--
Bush borrows money to kill Iraqis. 140 billion borrowed. With interest, you pay 200 billion. When Saudis attack, invade Iraq?

Is this the definitive article about software RAID under Linux?

Software-RAID HOWTO. In English and HTML: Software-RAID HOWTO.

--
Bush borrows money to kill Iraqis. 140 billion borrowed. With interest, you pay 200 billion. When Saudis attack, invade Iraq?

C++ is transparent - to anyone who understands the language.

Just like C is transparent to anyone who understands the language.

Neither language is transparent to those who do not understand. "Det er da ikke så svært at forstå, er det?" (see what I mean ;)

Read:
C vs C++
written by yours truly.

The major points in that article in relation to C++ in the kernel will be
*) Rewriting good C to C++ will be bad C++ and that's not a change to the better
*) Few (good kernel-) developers understand C++ or are willing to learn

However, it is interesting to see that Linus is working so much with the SParse tool - which, really, is just a type checking tool allowing to check annotated C types more strictly than the C language itself allows. This is one of the major benefits you get from C++ (and you can get this benefit with *zero* overhead compared to C - the stricter type system does not force you to use features that have overhead). Instead of developing SParse and running type checking in two steps (first the C compiler, then checking with SParse), they could move to C++ and have it all (and then some) in one go.

But again; I don't think rewriting the kernel to C++ would be reasonable - however, if you start up a new kernel project today, you'd be insane not to go with C++.

My 0.02 Euro on that one ;)

Depends.

If you're using hardware RAID or pseudo-hardware RAID (i.e. Promise FastTrack), then it should just be a matter of entering into the RAID controller's setup utility during bootup and tell it to add the second drive into the RAID array and it's seamless.

I'm not familiar enough with Linux's LVM or other software-RAID to know how to do it that way, but I'm sure there are utilities that allow you add disks to unmounted RAID arrays fairly easily. Let me search Google.....

....OK, I'm back (that was pretty quick). Here's exactly what you're looking for.

QED

Ok, something like this was bound to happen ;)

C++ bashers out there, please go read a short C++ vs. C "competition" sort-of.

It's a short explanation of some of the most common C++ vs. C misconceptions, and a funny little benchmarks (with a lot other than just hard numbers).

To be found at:
http://unthought.net/ssh-vuln.html

You might want to check out raidreconf (http://unthought.net/raidreconf/ which will allow you to add disks (although it's rather slow) to a RAID-0 or RAID-5. I cover this in the book, to a certain degree.

I do agree though, you hit on some issues with the md driver. There have been some recent discussions on linux-raid about how to help integrate RAID and LVM in the context of EVMS and other user space tools. I think that by this time next year, a lot of the mess/overlap between the two will be cleaned up.

One careful consideration with ATA RAID is that many of the controllers are not really hardware RAID. I don't think this is the case with the SX4000, but many low-end ATA RAID controllers (especially the on-motheboard flavors) are just software RAID in disguise.

Derek Vadala

You might want to check out raidreconf (http://unthought.net/raidreconf/ which will allow you to add disks (although it's rather slow) to a RAID-0 or RAID-5. I cover this in the book, to a certain degree.

I do agree though, you hit on some issues with the md driver. There have been some recent discussions on linux-raid about how to help integrate RAID and LVM in the context of EVMS and other user space tools. I think that by this time next year, a lot of the mess/overlap between the two will be cleaned up.

One careful consideration with ATA RAID is that many of the controllers are not really hardware RAID. I don't think this is the case with the SX4000, but many low-end ATA RAID controllers (especially the on-motheboard flavors) are just software RAID in disguise.

Derek Vadala

I used GNOME since the 0.4 days up to and including Ximian GNOME. I've used KDE in between, ever since my homepage was about the only page on the internet that Konqueror could render without crashing.

My first UNIX experience was with Solaris - at that time my home computer ran OS/2 2.1 and NT 3.51 (with me not being completely happy with either).

What I felt was cool about Solaris was that nothing would crash. Nothing would hang. Applications were few (but I had a pretty specific job to do and a pretty specific set of applications for that job) - but they worked perfectly. On the PC scene, applications were many, and virtually everything would crash every now and then - perhaps on a daily basis, perhaps weekly, but applications and OSes would crash.

Starting to run GNU/Linux on my box at home, I rediscovered the stability I had only seen on Solaris (and by then, HP-UX as well). The desktop was ugly compared to OS/2 - but it worked (my "desktop" must have been fvwm by then).

With GNOME and later KDE, some of the coolness of a real desktop environment came to the stable "PC" operating system - wow, the best of two worlds, or?

No. GNOME was looking good, but it crashed. Often. KDE was first unstable and ugly, and later on just ugly. Ugly on a CDE level :)

Both improved rapidly - I switched between them every now and then. In the end I ran Ximian GNOME (because I liked the GNOME panel and didn't like the KDE one), using Konqueror as the browser (because even though it wasn't fast or could render every page - it was still miles ahead of Mozilla 0.X).

Crashes are unacceptable. Even if it's just weekly crashes. I cannot work with a system I cannot count on. This, I think, is the major reason for my choice of desktop today.

Today, I use fluxbox as the window manager. I use Konqueror as my browser. I use a few GNOME apps too. Basically, I have taken the few elements that I need from the two desktop environments, but without any of the two environments in their entirety.

You may not want to do this. In fact, such a desktop may be horrible for you. In my job as a developer, emacs and rxvt take up about 90% of the screen real-estate on my eight 1600x1200 virtual desktops. I have no need for a fancy panel, all I need is hotkeys to switch between the virtual desktops and more free screen real-estate.

And I do not log out. I don't need no fancy session manager - the uptime of my emacs will top most non-UNIX web servers out there. Common themes? Well, my emacs isn't themed anyway, so I don't care.

My impression today of GNOME versus KDE, is that the KDE people have been very productive engineers (and have finally gathered some graphics artists to make the system look good too) - I think the GNOME team may be just as hard working, but I believe that their progress will be slower because of architecture (and programming language) inconveniences.

I see GNOME as an philosophically idealist project, where compromises on the architecture and engineering "soundness" are more acceptable. KDE seems to be a fantastic piece of engineering, where in the beginning the philosophical or ethical concerns were ignored (using non-free QT). Clearly, KDE does not have it's problem anymore - and I do not see an easy way for the GNOME project to suddenly come up with a better (as in robust, documented, well-defined and "sound") infrastructure. It is my impression that the GNOME project are working towards better infrastructure though - and they definitely have both clever and productive people around, so I am sure that they will be moving towards a stable and well defined infrastructure.

Infrastructure is key to gaining application support, and in the end to be able to deliver a stable and usable product.

Today I don't hold my breath for any of the desktop projects. I pick the few applications I need, and fluxbox let's me move them around on my desktop. My desktop does not crash, and I can worry about the things that matter - the job I have to do.