Tomáš Solař, autor české knihy Oracle Database 11g – Hotová řešení, nabízí kontrolu databáze Oracle zdarma. Jedná se o bezplatnou službu, která vám může pomoci odhalit slabé místo vaší databáze, aniž byste za to museli platit. Služba je určená všem, kdo využívají databáze Oracle, ale nikterak se o ně nestarají, přestože v nich uchovávají veškerá firemní data. Více se dočtete přímo na webu dba4refence.
1) Where do you stand in the microkernel vs monolithic kernel debate?
I'm not greatly bothered by it. If you start talking about Microkernel versus Monolithic and assuming there is an either/or decision you lose sight of the fact that there are advantages to both and there are alternatives that get some of the benefits of each. Linux conciously tried to steal the best bits from both while avoiding the overhead many microkernels impose.
2) What about the modern L4 microkernel (especially the L4Ka::Pistachio and Fiasco implementations) and the L4Linux project (Linux on top of L4)?
I'm not really familiar enough with the internals of the L4 project to comment.
3) There is a system in Minix that allows device drivers recovery (by killing and restarting). Are there any plans for a similar functionality in Linux? Is it even possible?
It actually works today for a lot of devices. If you unconfigure a device, rmmod the driver and insmod it again it will effectively be reloaded and restarted. You don't have the needed protection/control to do that forcibly or to guarantee that such a restart is always possible - but that is very expensive to do.
4) What part of the kernel would you label as the best (in terms of programming)? And which is the worst?
I find this goes in cycles as code is modified, hacked about and updated it gets worse and then at some point it gets tidied and rewritten so that the hacks and changes made over time become part of the design not afterthoughts.
There is one candidate for "worst code" that has lasted a very long time and that is probably the floppy driver.
5) Is there a technology that you would like to be included in the kernel?
At the moment no, although one will no doubt come along in time. There are some I'd like to see sorted out however - notably the whole X versus framebuffer versus console situation.
6) There have been a lot of discussions in LKML (and LWN) recently about asynchronous system calls. We have fibrils, syslets/threadlets, and kevents. Which one would you prefer? And why do you think it's so hard to push kevents through when it seems to be an interesting and complex solution?
I like the syslet/fibril approach and I can see real advantages in that if we can avoid the extra parallelism simply causing more thrashing and overhead later on. I find kevents a lot less interesting simply because event based programming isn't how a lot of people want to program systems. They should of course all learn how to use co-routines properly 8).
7) Of the kernel developers, who do you like to work with the most?
It doesn't really work like that. There are certainly people I don't get on with, and people who I work better with - but that itself can be dangerous. Often the people you get along with are the people who think the same way and you can end up missing other viewpoints.
Generally it works very well, and there are a lot of very bright people in the kernel community which makes it very interesting and ensures there is a lot to learn.
8) What hardware vendors do you consider the best from a kernel developer's point of view -- in that they provide specification, cooperate, etc?
Of the big vendors I deal with I would say Intel are probably the most co-operative today, they provide good documentation, errata information and also fund or write key drivers for their hardware such as the 3D support (done by Tungsten Graphics) and the wireless. That has really paid off and made their systems hardware of choice.
A lot of other vendors are very helpful, some of the small ones like Jmicron especially so. Others can be very strange in their behaviour - AMD for example used to be very helpful but now they own ATI are being extremely problematic. At the end of the day it is important to remember that most of them are helping Linux because they see it as a revenue earner and that can mean they will be helpful in some areas and not others. IBM support for Linux for example is ultimately about IBM's interests - likewise almost anyone else.
It isn't just specifications that help, vendors like Dell wanting to ship Linux ready systems and willing to make sure this happens don't neccessarily provide documentation and write code (although Dell do) but they provide a business reason for other vendors to do so, and that is also very helpful.
9) Where do you see the Linux kernel in five years? Any radical changes coming up?
The big ones that are visible are probably scaling ones - particularly memory sizes and storage. These also trigger concerns about reliability and error rates which mean changes right down to the disk interface level, some of which need operating system support.
People are looking at new file systems - file systems you can fsck parts of so it is possible to recover a disk in realistic time scales, and which can handle and detect corruption on the link or disk better.
10) Do you think that licensing Solaris under the GPLv3 might weaken the position of Linux (which is about to continue using the GPLV2)? Are you worried about the possibility of Linux developers leaving to work on Solaris?
Not greatly. In fact I would hope we will see sensible discussions about dual licensing bits of code so that we can all benefit from them.
11) What is your take on the Novell - Microsoft deal? Should Red Hat be a party to such agreement sometime in the future, what would that mean for you?
Personally I think it's a bad idea and that Novell are going to get stung by the GPLv3, and rightfully so. The license is designed to keep the software free, if it fails to do this then it needs fixing, so GPLv3 hopefully will fix this flaw.
If Red Hat did deals with Microsoft I'd hope they would find a better way to do things, to co-operate on things that help end users but not to compromise the freedom of the code or play any funny games.
12) Do you share some people's fear of Microsoft's threats (concerning patents and intellectual property)?
I don't think they are the biggest danger. As Microsoft has been finding out recently it is the patent trolls, and organisations with buried patents in interesting areas that are the biggest threat in the USA. The real answer to that problem however is to pull the USA back into line with the majority of the world which simply does not recognize patents on software but respects them as literary works subject to copyright law. Also therefore we have to make sure the continuing US attempts to spread bogus patent law into the EU are defeated.
13) What is a kernel developer's life like? How much time do you spend writing code (or testing) and how much do you study? What are your other hobbies (besides Welsh)? And what about your family? Is it possible to work so much without becoming a workoholic?
Pretty good. Most of the time I am working on the things I think need doing, sometimes on the things Red Hat thinks need doing (usually the two co-incide but not always). I try and keep sensible hours so I have time for other things, which include family, railway related stuff (both full size heritage railway and model), and things like Welsh lessons.
I try not to spend too much time on work stuff, and there is good evidence anyway that spending too much time on work actually ends up getting less done than working sensibly.
14) What beer did you enjoy the most and where?
Good question and one I suppose I should expect from .CZ. I'm not actually a great beer fan however. I do like some of the Belgian blonde beers and the German weißbeers. I've tried a couple of Czech beers and either they don't travel well or they are not very good ;)
Many of those who asked questions wanted to use this opportunity to thank you for your work on the Linux kernel. I also thank you for your time and goodwill regarding this interview.
Nástroje: Tisk bez diskuse