Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Hans Reiser Speaks Freely About Free Software Development 241

Okay, here are Hans Reiser's answers to your questions about ReiserFS, starting and managing (and publicizing) a free software project, earning a living writing free software, and the good and bad points of being considered somewhat of a curmudgeon. As a free bonus, Hans adds a little insight into the politics of Linux kernel development, as in what gets accepted and what doesn't. Good stuff!

1) Guideposts? - by TopShelf

Having obtained financing for the project, how does that impact the future direction of development? How do you balance the interests of developers, users and sponsors to choose which updates to pursue?

Hans:

There will always be more features that I would like to implement than I can implement. Users and sponsors for the most part want good things to be added, and it is really not so bad to first implement the features that someone is willing to pay for, and hope that in a few years someone else will pay for other features. I take a 30 year perspective on the project, and I have as my final objective the elimination of reasons to not use the filesystem as the unifying namespace of the operating system. That makes for quite a lot of features that I am willing to add.;-)

There is an common situation though where pressure from sponsors is severely negative, and that is when they want a quick hack that meets their needs but lacks elegance. It is not usually the features they want that are wrong, it is the timeframe they want them in and the shortcuts they expect to be made to meet that timeframe. This happened with ACLs and extended attributes for instance. I turned away 4 different sponsors for ACLs before I was lucky enough to find DARPA.

All of the commercial sponsors wanted some quick hack that would not be consistent with the semantics I am evolving ReiserFS towards, and would leave us with unwanted additional primitives. To DARPA I proposed that filesystem designers were not providing security researchers with the right infrastructure that they needed, and this lack of the right infrastructure was leading to inelegant hacks. For instance, I argued that there was no need for extended attributes, that instead there was a need for *files* that

1. were efficiently accessed many at a time (new system call that reads and writes many files in one call)

2. were accessed atomically (transactions infrastructure)

3. had constraints on their allowed values not just who can write to them

4. inherit some contents/metadata from other files/directories (note that streams share a common metadata)

5. could be made invisible to readdir

6. could be both files and directories depending on whether you accessed them as files or directories

7. could be implemented via a rich plugin infrastructure that allowed one to compose new plugins by selecting methods from already existing plugins, and only writing from scratch that which was truly unique to the plugin

8. efficient storage of small files (V3 was suffering a performance loss when tails were turned on (that is, when small files are packed several to a block) that V4 cures)

You can probably imagine small appliance vendors not being willing to wait 18 months and spend lots of money when all they want is for ACLs to work well enough that they can sell a samba server, yes?

With DARPA, if you advance the field of security research by developing along an angle the proposal reviewers thought was interesting, it is enough to get the funding. It is easy to think that private industry is sufficiently well motivated to fund long-term research, but unfortunately long-term research tends to benefit a lot more than just its creators and funders, and only the government funds work whose benefits will be mostly diffused throughout society. Or at least that is one theory to explain what happens. The observed reality is that venture capital does not fund long term research, persons wanting to do long term research mostly must pursue government funding, and the readers are encouraged to suggest other explanations of that if they have them.

I would be curious to know if privately held companies without plans to go public (such as Namesys) generally tend towards more long term research. Surely society needs long term research.;-)

DARPA is really quite excellent to work for. Having the right customer is very important to the development of a product, and I learned an enormous amount about serious approaches to security that I would never have learned without participating in their environment. Their accounting requirements are exacting, but it all has a reason, and for each requirement you can easily imagine the taxpayer being abused by someone without it. Actually I was a bit reassured as a taxpayer about how the DoD spends our money by seeing them in action, and being a small company we learned a lot about generally good professional accounting practices by adopting their requirements.

2) Good business planning - by mao che minh

Did you embark on this project in hopes of making a profitable business? It certainly seems that way, considering that you went looking for sponsorship and even planned pay-per-incident support, showing that you were prepared to work the whole "support revenue" angle.

Now you just need to hire someone to desire a modern, more "commercially pleasing" website. =)

Hans:

We make enough from pay per incident at www.namesys.com to support 1/4 of a programmer, and monitoring all requests to ensure that a professional response is always given consumes some of my time. This revenue is steadily growing though, but since we make so little money from it we don't bother with trying to charge a lot ($25 currently), instead we just hope that word of mouth will make it continue to grow, and maybe in a few years it will become something more significant. I think we were key to deflating some of the excessive per incident support rates that were out there for Linux, and this is good, because who can afford $250 to be told how to make Xwindows work?

Where I had originally planned to make money was by using Linux as a market sampling methodology while selling to OS vendors. That a bunch of hackers who had written software I used myself would get to use it for free was ok with me, and a product that was used by the OS vendor's engineers at home would be an easier sell I thought.

Unfortunately, paying money just to catch up to Linux does not seem to excite OS vendors, even if in reality it is very important that they do so. It is theoretically irrational but reality real that the proprietary OS vendors have not yet bought a license.

Instead, I have sold to storage appliance startups who need a code base to start from, and this has been slightly more than half of our income.

We have only sold one priority support contract (this is where you have the right to wake us up and you pay in proportion to the amount of hardware you have), but we sold it to Lycos, and they keep doubling their usage of ReiserFS every year and increasing the contract accordingly. They have been very happy with the support we provided. This one contract is much larger than all our pay per incident fees combined, and thanks much to Lycos for being a customer.

It would be nice if I could sell some government a nice ReiserFS support contract....

Many users don't realize it, but we don't make a lot of money here at Namesys, the programmers are very much overdue for pay raises, and there are many good people I can't hire because we have no funds for it. Hopefully this will change though as ReiserFS increases its technical lead over other filesystems with time. Reiser4 is going to give us some very compelling performance and security advantages, and we will be the easiest filesystem to hack on thanks to the plugin infrastructure. That infrastructure is really going to accellerate development by a lot, and provide us with a compelling competitive advantage. It is interesting to watch Nikita casually toss together a couple of plugins in an afternoon when it suits his whimsy. We can already see how much easier it is going to make doing the semantic enhancements we have planned, and then once we have the semantic enhancements out there and in use, performance will no longer be the primary decision point for users.

As for the website, by "commercially pleasing" I assume you mean using bland and uninteresting graphics, and corporately styled, with lots of insincerity everywhere.;-) Forgive me if I read too much into your comment, but you would not be alone if I read you correctly.

It is important to be true to oneself. You should maybe understand that some years ago I put the suit my mother bought me into the fireplace along with all my ties. If a restaurant requires a suit and tie, I just don't go there, it is not for the likes of me. If you need some corporately commercial justification for our website design, then let it be that I am willing to be cool and appealing to the younger generation, etc., instead of bland. If a pedagogical justification will work for you, then let me point out that military manuals with their cartoon based approach are far more effective in engaging the reader than the pedagogical techniques employed by most college textbooks. The military is more advanced in its pedagogical technique than the university system, which is really rather amusing, and I think it is due to the greater pretentiousness of universities in this matter.

3) Versioning - by tjansen

Beside the finding and organizing files, the biggest problem for desktop users today is probably that changes on the file system are not recoverable. It is easy to accidentally overwrite a file and lose your work, and the only only sane way to solve these kinds of problems would be to make it possible to revert changes.

Several research systems have been created, like the Elephant File System, but none of them made it into the mainstream free and commercial operating systems. Are there any specific reasons why nobody offers recovery (high complexity in implementation, very bad effect on performance, etc) or is it just because FS designers don't see the need for it?

Hans:

Actually, there is a version control filesystem called Clearcase that costs thousands of dollars per seat. (If I wanted to make more money, I could return to working as a Clearcase sysadmin --- there are some jobs that pay very well because nobody wants to do them.;-) ) Clearcase was written a bit too quickly, and its performance sucks as a result (though I am told that has improved since I left that field). If it used Reiser4 as a backend it would be a lot quicker.

Version control definitely belongs in the filesystem. Clearcase may have a lot of implementation uglies, but as a concept it clearly works. Filesystems manage files, and that should include managing file versions. Our support for transactions and compression should make it easier to implement version control in Reiser4. As soon as someone offers to sponsor it, we will do it.

Larry McVoy makes a lot of arguments about how the economics of version control means it has to be expensive. I think this would not be true if three things changed simultaneously: 1) it was integrated into the filesystem, 2) it was free, 3) it was easy to understand for average users. For 3) to be true it has to become as easy as, say, .snapshot directories on a NetApp are, for the average user. It should also be as well integrated into apps as version control is in MS Word. I predict that in 20 years version control in filesystems will be standard and expected by all users as a basic feature.

4) Filesystems and metadata by androse

In your Future Vision white paper, last modified in January 2001, you outline several very interesting ideas about metadata.

Several developements have taken place since; the extensible attributes of BeFS has been buried with BeOS, the database-like metadata of Longhorn (aka Yukon) may actually be a separate layer from the filesystem altogether, and Apple is also moving all metadata out of the filesystem to XML files shared between applications (see iLife package).

My question: What is your current take on the metadata debate? Do you still think the filesystem is the right place to handle metadata? Any predictions?

Hans:

Reiser4 required some fundamental breakthroughs in tree balancing technology before small files could be combined into one block without adding additional seeks for typical usage patterns. In particular it required discarding the BLOB paradigm, recognizing that BLOBs unbalance the tree, and creating a new more height balanced tree. (See www.namesys.com/v4/v4.html) It does not surprise me that the other filesystems failed to find these techniques; until we had benchmarks no one but me on the team thought this new stuff would work. I think you can reasonably assume that MS abandoned its efforts to put the database into the filesystem because their algorithms failed to deliver good performance. Without these techniques, extensible metadata causes performance problems that constitute a market entry barrier.

I should be careful in my phrasing here: Reiser4 does not support attributes, it merely supports files that you can choose to use for metadata, and its files have all the functionality you need for doing the usual metadata tasks should you choose to use them that way.

Oh, and BeFS is probably not all that dead, Dominic Giampaolo the author is working for Apple now, and since he is very bright and capable there are likely to be interesting things coming out of Apple in the future (probably not called BeFS though).

5) Researching filesystems - by ProteusQ

I'm going back to school this fall, and in a year I hope to be admitted into a Masters of Computer Science program. I'd like my main research focus to be on filesystems.

I'm preparing by reading everything I can find: I'm working on Tanenbaum & Woodhull's "OS Design & Implementation"; I've read "Design and Implementation of the Second Extended Filesystem"; Steve Pate's "UNIX Filesystems" is waiting on my shelf; and of course, there's the FAQ and ReiserFS v.3 Whitepaper at www.namesys.com [namesys.com]. Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front? And are there any special tricks (above and beyond mastering your subject) to getting hired in this field once a degree is in hand?

Hans:

I was never able to get hired in this field, so I am probably not the one to ask about how to get hired.;-) Hmmm. Oh I know one! Don't tell your potential employer that you are working on your own file system nights and weekends, and you will retain all rights to it, and you won't stop work on it once they hire you.;-)

You should probably read about Plan 9, and about namespaces generally. The literature on namespaces seems to be just about hierarchical namespaces, but the notion present in that literature that they should be unified is a good one. I rather liked Gerard Salton's book on automatic text processing. Ted Nelson's Xanadu project was interesting reading, and you'll want to read Codd and Date about databases. Mikhail Gilula's book about set theoretic databases is a good one.

In regards to math, study the design of new mathematical models. Study closure, and its importance to various models ranging from algebra to relational algebra. Understand why mathematical models were designed to have the structure they have rather than learning what those structures are, so that you can learn to construct your own models. I don't know of any courses that teach that, but it is what is important to learn.

Are you sure that it wouldn't be better to hang out in cafes and bookstores for 4 years, and at the end of it write some piece of a filesystem? Cafes, bookstores, and attending random seminars will educate you better, and writing some piece of a filesystem will employ you better.

If only one could get student loans for the purpose of hanging out in cafes and bookstores for 4 years I would have been so happy....

6) where next? - by wfmcwalter

Hans,

Reiser FS is already a pretty mature, stable, usable product. Once V4 is done, is there really much work left to be done on ReiserFS proper? Do you have a giant to-do list that'll keep you and the guys occupied for years, or do you intent to work in a diffent direction (SAN, networkFS, databases, etc.)?

(or perhaps you'll just retire to Portugal and play lots and lots of golf)

Hans:

V4 is a local host storage layer. V5 will make it a distributed storage layer. V6 will enhance to the semantics to where one can do semi-structured data queries. Whether V5 or V6 comes first depends on funding.;-)

A new model for doing semi-structured data queries was my original goal, and it remains my primary goal, and the storage layer was just a necessary prerequisite to getting there. I describe the enhanced semantics I plan at www.namesys.com/whitepaper.html.

7) Starting Large Free Software Projects - by unsinged int

When you began a file system project as a free software project, you must have known that (assuming it worked) it had the potential to turn into a big project. How did you determine how long to work on it as your own project before making the first release? I imagine there must have been a strong temptation to just get it "out there" knowing its potential, yet certainly releasing too soon would make it look unprofessional and thrown together.

Hans:

When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings). Fortunately, there are people who like to play with technology, and they will help you find its bugs while understanding that it is still experimental code. Each order of magnitude increase in the number of users will find as many bugs as the previous order of magnitude. After some number of years, if you are kind to your users and only do new features on a new branch, the stable branch will get to where months go by and there are no bug reports at all even though there are millions of users. It was this way with V3, and it will soon start to happen with V4.

8) Raising Awareness - by blinder

One question I always have with regards to successful (meaning funded, wide acceptance, large user/developer community etc.) is how did you raise the awareness of your project to get it from just a side project to something that it is today?

Did you use traditional PR techniques, or just through a community of connections?

Hans:

There are two things that work, and not much else does:

1) Word of mouth from users brings people from seeming nowhere.

2) Being open and eager to make a bit of effort to work with people makes you friends or at least allies.

Heinz wasn't able to get the time of day from the ext2 team, and he needed a resizer for LVM to happen. We said yes, sure, we'd be happy to do it. He introduced us to SuSE, and SuSE paid us $5k to write a resizer. That led to SuSE becoming a sponsor, and then once we were stable they made reiserfs the default filesystem.

Word of mouth from the users is the most powerful tool free software has. If you combine that with being open, willing to work with other people, and not being an exclusivist, things happen randomly out of nowhere that keep your business alive.

The only times I am not eager to work with people are when I think their technical direction is wrong (e.g. extended attributes), and this is sometimes the significant short term price paid for having clean design.

9) Rules of thumb - by realnowhereman

In your future visions paper early on you talk about Reiser's Rule of Thumb #2. However, I can't find Reiser's Rule of Thumb #1 -- what is it? Is it a secret? Does it contain the sum of all human knowledge?

Hans:

I think it was this, and when I write a book in a few years, I think I had better go looking through some of my old versions of that paper, because it used to have a lot more design principles in it, and I cut them in some ill-conceived effort to reduce the length for some reason I no longer clearly remember. For the convenience of readers I have included the entire context of it.

The Little Inconveniences Dominate What We Do

Do the small inconveniences caused by fragmentation of name spaces really add up to something that should dominate the design concerns for the name spaces of an OS?

Information Diffusion Rule of Thumb: The extent of information diffusion is divided by the effort required to navigate the name space.

Information owners tend to think of the cost of access as only subtracting from the value of their information. but it does much worse, it divides it. The economics are little different from what they would be if money rather than time were the cost, and since we all know that halving the monetary cost of a silicon chip more than doubles its usage, it should seem reasonable to the reader that halving the time cost of a piece of information would double its usage. Three seconds rather than 1/3 second of access time means that the same information will spread to an order of magnitude fewer people, be used by them an order of magnitude fewer times, and be an order of magnitude less useful to the organization as a whole. A common mistake by authors of information is to not realize that most of the total utility of their piece of information will be felt by those to whom its utility is either rather small, or for which its value is speculative to the person considering accessing it. The other common mistake is to not realize or care how much harm will be caused by others expending the time cost of accessing their information only to find it irrelevant. Since we all have limited lifespans in which to do our research, time spent accessing rather than reading information detracts from our ability to wander speculatively after information that might be useful. The quality of the name space design determines these costs.

Example of the evils of name space fragmentation at work: Every employee must create a job description, and then store it in the dreaded Hyped Document Storage System for easy access by all. Mr. B. Bizy just enters HDSS, types Bizy duties, and it pops onto his screen inside a full blown Hyped Editor with lots of features. Easy. Unfortunately the only editor he knows how to use is emacs. Emacs doesn't know how to navigate or edit Hyped Indexes. He takes a moment to swear at the paucity of features possessed by emacs, and then he spends fifteen minutes paging through the Hyped manual. Finally he figures out how to put the document into a file. He edits it using emacs masterfully to achieve a new level of job description ambiguity, and puts it back in HDSS.

His boss comes by, sees him working on his job description, and tells him to compare the list of employees, as entered into the REGRES payroll relational database, to the list of those who have entered a job description into HDSS, to make sure everyone is complying with the "describe your job" directive recently issued. Unfortunately, HDSS is a keyword system and REGRES is a relational system. Neither HDSS nor REGRES can use each others' indexes, and while he could write a program to compare the output from the two applications, he can eyeball the output from the two faster than he could write the program. His eyeballs grow tired.

In general, whenever Mr. B. Bizy wants to act on information namable within one application and operate on it with another application, he must extract it from the first application into a file (at best a pipe), sometimes he must hand massage it into a form that the other application can enter into its own database, then he must put it into the second application, do his work, re-extract it, possibly massage it some more, and finally put it back into its original application indexes. It is never a thoughtless read or save, though it is always tedious. Mr. B. Bizy would prefer to spend his thoughts on other activities.

This is why most of the time the employees of Mr. Bizy's company store most of their data in flat files in the semantically impoverished filesystem: the greater connectivity pulls them there.

10) On being one of those "outspoken" people - by salmo

Mr. Reiser, first off I have no complaints about ReiserFS (which is a high compliment), I use it on almost all my machines, except a couple are running EXT3 because they're not heavily used and I'm lazy at times. But thats neither here nor there.

You fall into an interesting subcategory of project managers or whatever you want to call them. I'll call it the "outspoken genius" category (even though the first word might be understated and the last is probably hyperbole). Basicly your work is technically interesting, applicable, etc. That's a give in. But there are quite a few people who have personal issues with you and your manner and usually cite some exchange or another. Sometimes this is the basis of an argument to reject the use of your work, which I think is somewhat silly. You're not the only one, and certainly not the first to be interviewed here.

So what do you think about this? ie. Do you think you made interpersonal mistakes that landed you here or do you think you've been misunderstood? Does it bother you? Why do you think people enjoy egging on folks such as yourself and then citing the moment you get annoyed with them? Do you think this question ever has a prayer of being moderated higher than someone following the method of the previous question?

Jeeze, I realize I just wrote an essay question in the style of one of my old Philosophy professors. You know the kind, here's a statement now write some stuff (I guess I'll give you a few ideas of where to go).

Hans:

I am not a genius, I am just never satisfied and very very persistent. I approach science like a blind man with a stick who is determined to fully understand what is going on. The difference between me and my competition is that I poke more than they do. I observe, find something to be unsatisfied with, try something to fix it, most of the time it fails and I try again. You don't see the failures because they don't get released. Why haven't other people already fixed the traditional balanced tree algorithms and made them effective enough for storing files? Because it was too much work, and they were smart enough to avoid the work, that is all. We simply rewrite more times and more deeply than others do, and that is how we get our results in our admittedly obscure field.

Now if you think about it, who wants to be around a blind man with a stick, someone who keeps insisting things aren't good enough and they need rewriting?

There is yet another way of looking at it though.

Linux is an ecosystem, and in this ecosystem there is fast growth vegetation and slow growth vegetation. The fast growth vegetation are the people who took what had already been done by Unix, and without changing its design they copied it while making coding improvements.

Then there are those who look at Unix, err, Linux, and see something just barely begun that needs a complete overhaul. These are the slow growth vegetation. Namesys is slow growth vegetation that got started a long time ago.

Now it is human nature that however a human being is, he is inclined to think that is the right way to be. There are those who think that design does not matter, and one should just make incremental coding improvements. There are also those who think that just coding without introducing fundamental new ideas is unimportant. Both of these sets of persons are fools. To say that one approach is better than another is like saying that grass is better than trees, or trees are better than grass. For Linux to prosper as an ecosystem it must have both.

Unfortunately the fast growth vegetation is actually developing a culture of exclusion, kind of like grass working to strangle the tree seedlings. Linux is developing more and more of an insider circle. Those who cannot code well enough to survive on the merits, must politick to exclude the threats....

A sad thing about this is that the most talented young security researcher I know doesn't want to develop for Linux because of the attitude of the inner circle to new people, and I can't really blame him, it is why I didn't develop ReiserFS for BSD back when BSD was....

Almost certainly he is not alone....

It is all very fine to discuss the sociology of herd formation, exclusion, and prejudice in the abstract, but one should never say that particular persons are making particular decisions on the basis of their herd instincts unless one wants to be truly hated by them and all of their numerous friends, and this was my mistake over and above the choice of what sub-herd to be part of.

I don't think anyone "eggs me on" though. I press released benchmarks of ReiserFS vs. ext3 the day ext3 was formally released at a conference, before ReiserFS had been included, and is it a surprise one of them was pissed at me? My competitors didn't and don't want ReiserFS in the kernel, and I wanted and want it in, and the result has all the dignity of a food fight. Filesystems that are less threatening nobody cares enough about to seek to exclude them. Many thanks to Linus, who chooses to allow healthy competition among the filesystems in his kernel.

If only the largest distro was so permissive....

You do all understand that while the GPL doesn't permit tying by license, distros have now moved to using threats of invalidating support contracts to achieve the market leverage they need to exclude competitors, yes? By doing this they can exclude mainstream official kernels from being used, exclude rival filesystems, exclude whatever might lead to less customer lockin.....

This is why you should try to avoid buying support contracts from distros and only buy support from those who agree to support you the customer doing whatever you choose to do, even if it is something fringe like using a kernel from Linus.;-)

They will tell you all this nonsense about how they can't support whatever software you choose to use. Buy better support from an independent and you won't hear this nonsense (www.Namesys.com/support.html is $25 a question and there are plenty of others). Most independents will support you using whatever distro you want, using whatever configuration you want, and they have the skill to cope with that. Sure, they will tell you that such and such gcc release on such and such distro was a lemon, or maybe even that the only reasonable fix for your bug is to upgrade to a recent release, but your support provider should never be telling you that you can only use what they sold you.

I am trying to convince the GSA that they should avoid procuring free software support that constrains the government's choice of what software to use, and they are at least considering the point of view. Why bother to have the GPL if you accept this loss of freedom?

Ummh, maybe these sorts of statements are why I am not so popular....;-) Well, glad to have answered your question!

We should all keep in mind though that there aren't any hard core greedy evil people in our industry. They are all basically good hearted people who chose trying to create a better society as their life's work at a substantial cost in personal income. Petty, bickering, overly impressed with ourselves, flaming, yes that describes most of us Linux kernel developers, but there isn't enough money floating around to attract any genuinely bad folks into our industry.

Not yet....;-)

--

Hans

This discussion has been archived. No new comments can be posted.

Hans Reiser Speaks Freely About Free Software Development

Comments Filter:
  • Well done... (Score:5, Insightful)

    by TopShelf ( 92521 ) on Wednesday June 18, 2003 @11:15AM (#6234305) Homepage Journal
    I can't recall an interview that came back with such well thought out answers. Major kudos!
    • Re:Well done... (Score:5, Interesting)

      by EZmagz ( 538905 ) on Wednesday June 18, 2003 @11:49AM (#6234567) Homepage
      I can't recall an interview that came back with such well thought out answers. Major kudos!

      Oh, you're just saying that because your question got answered and the rest of ours didn't... ;)

      1) Guideposts? - by TopShelf Having obtained financing for the project, how does that impact the future direction of development? How do you balance the interests of developers, users and sponsors to choose which updates to pursue?

      Honestly though, I agree. This was a good interview, and I found most of the answers satisfying (with the exception of the whole Linux = ecosystem skewed analogy). I'm an ext3 man myself...mostly by convenience, since I run RH on about 1/2 of my linux boxen and it's enabled by default. However, I definitely plan on giving Reiserfs a shot one of these days though even though I don't expect to see a huge difference (vs. ext3 on a single-user, low-access system). Maybe if I was running a huge db farm, it'd be different.

      An interesting point he brought up was in answer to the fella who is contemplating going back to get his MSci and focus on file systems. Hans told him to basically save his money and hang out in bookstores instead for 4 years, spending his time developing his own gig (a shitty parapharse, I apologize). Hans' answer especially hit home to me, because I've been contemplating grad school as well as of late. However, I know for a fact that I've done way more learning (at least CS-related) since I graduated and got OUT of undergrad than I ever did slaving through a Programming Languages course (Sorry Prof. Allen, Scheme will never be fun no matter what you say). Does anyone else feel like they've learned more on their own than in school?

      Just a thought...

      • Oh, you're just saying that because your question got answered and the rest of ours didn't... ;)

        That's why I said the answers rocked. Although, it was pretty neat to get my question included (a first).
      • Re:Well done... (Score:5, Insightful)

        by lars_stefan_axelsson ( 236283 ) on Wednesday June 18, 2003 @12:54PM (#6235205) Homepage
        Hans' answer especially hit home to me, because I've been contemplating grad school as well as of late. However, I know for a fact that I've done way more learning (at least CS-related) since I graduated and got OUT of undergrad than I ever did slaving through a Programming Languages course (Sorry Prof. Allen, Scheme will never be fun no matter what you say). Does anyone else feel like they've learned more on their own than in school?

        Well, two points. The first is that grad school is a bit different than undergrad in that you decide yourself to a much higher degree what to work on. I.e. it's not so much an education as time to pursue your own interests. (And time is scarce when you have to work for a living). This is perhaps more true here in Sweden where a PhD position (a Master's degree is at undergrad level in Europe) is a salaried position which pays decently. (You USians make it up in spades when you graduate though).

        The other point is that while you'll always learn more when you're really interested (especially when you're interested enough to spend every waking hour learning more about your subject) you'll tend not to bother at all with the stuff that does not interest you. That's where a University education comes in handy; in forcing you to learn about the areas of your chosen field that you aren't interested in, or even don't agree much with.

        This brings perspective, which IMHO is much lacking in industry. In your case even though you still might hate Scheme you now know something about functional programming, which is an important paradigm. Having made the switch myself (from hating SML which is was we studied) to embracing the functional programming paradigm as superior (compared to OO) in my field, that perspective was important, even though I didn't much care for it at the time. The same was also true when I took psychology, I don't care for Freud one iota, and I still don't, but now I at least know what I don't like about his theories, something I would never had studied with out the pressure to do so.

        Perhaps ironically, when taking the grad course in operating systems, I had to learn something about filesystems, something I couldn't be bothered with when hacking Minix in the late eighties since filesystems are boooring. Little did I know, and I've since mended my ways. :-)

        P.S. If you're ready for some practical industrial strength functional programing check out Erlang.

        • If you're ready for some practical industrial strength functional programing check out Erlang.

          Ericsson employee or ex Ericsson employee?

          Erlang was really different from anything I had seen before. Certainly boosted my understanding of how to use recursion.

      • I had the same comment hit home to me and am also considering grabbing another piece of paper to hang on the wall and list on a resume.

        However, I think I've hit on the "solution". It's Western Governors University [wgu.edu], which is fully regionally accredited and does competency based classes.

        In other words, if you already know it or want to learn it from a book or doing it, you can then just take a test and get the credit.

        Reviewing the requirements, I figure I can handle one semester of tuition to learn the two
      • "Does anyone else feel like they've learned more on their own than in school?"

        Amen. I'm not regretting avoiding $X0,000 (hm, at an ivy league rate that would be what, $120,000 total for 4 years?), debt also.
      • Learned different (Score:5, Interesting)

        by Jerf ( 17166 ) on Wednesday June 18, 2003 @01:52PM (#6235750) Journal
        Sure, I've "learned" more out of class. It's almost impossible for class to keep up with a motivated learner; it's only a handful of hours a week.

        But I've learned different getting my grad degree. I would not have my familiarity with graph theory, algorithmic complexity, internals of compilers, etc. While perhaps none of these things were as in depth as you'd need to actually do work, the framework I've acquired to handle these in two years in grad school would easily have taken me 10 years of my own to learn... because on your own you get very focused on the task(s) at hand and never learn anything more.

        Also, unless you're a rare genius with math, having accountability to a professor to really learn the material, and not just skim a book and fool myself into thinking I understood intensely mathematical material, is invaluable. It's a rare person that can truly force themselves to learn material like that... and for things like graph theory that can be important.

        Each of those things is paying off, too, in my work. Graph theory in particular, though it's hard to point at a useless class.

        (Of course, if you go into the classes assuming that you'll never get anything useful out of them, you won't.)

        Note that I did a Masters, and I did not do a thesis; IMHO two years is too small for a thesis, so I actively chose to take the classes instead, which were more valuable to me. (I feel like this was my thesis [jerf.org], since I was writing it the whole time I was in grad school, but they'd never give me a masters in computer science for that.)
      • Re:Well done... (Score:4, Insightful)

        by Angst Badger ( 8636 ) on Wednesday June 18, 2003 @02:02PM (#6235847)
        I know for a fact that I've done way more learning (at least CS-related) since I graduated and got OUT of undergrad than I ever did slaving through a Programming Languages course (Sorry Prof. Allen, Scheme will never be fun no matter what you say). Does anyone else feel like they've learned more on their own than in school?

        Well, in my own case, certainly, as my formal CS education consists of exactly one course on C taken at a local community college more than a decade ago. On the weight of totally unrelated skills, I sneaked into the business chiefly as a designer, writing a little code here and there, until I do nothing but write code ten years later.

        I was programming for about half that time before I sat down with several textbooks on algorithms and design methodologies and finally flashed on the fact that knowing a programming language is probably the least part of being a programmer, just as knowing a natural language doesn't make you a good novelist. I suppose I could have learned that in school, but the impression I got from friends who were students was that it wasn't a major focus. Of course, my friends weren't attending MIT, and I suspect it's different there.

        The biggest part of being a "real programmer" can't be taught in school, and that's the reality of programming in a business environment. No book will adequately prepare you for office politics or time management. Despite my lack of formal training, I've been considered an excellent programmer everywhere I've worked. When I entered the field, I thought that was all that mattered. The big secret, I learned, was knowing where and when to write shitty, sloppy, hastily conceived code in order to get a project out the door on time and under budget, and when to push back to get more time to write good code, because shitty code in that particular case will come back to bite you in the ass and wreck schedules further down the road. That is the job skill par excellence of programming, and you can only learn it from experience.

        OTOH, if you're basically perfectionist, the shame of writing corporate code will lead you to spend your spare time writing textbook-perfect open source projects. Occupational hazard, I guess.

        You won't learn the fine arts of ass kissing or blame shifting in books, either, but that's something everyone but the receptionist and the mailboy needs to know, not just programmers.
      • Does anyone else feel like they've learned more on their own than in school?

        Is there even anybody that feels like they learned more in school?!?
    • Totally agree. (Score:4, Insightful)

      by ashitaka ( 27544 ) on Wednesday June 18, 2003 @12:04PM (#6234702) Homepage
      I got flamed before for pointing out the flat, thoughtless answers submitted by previous respondents. (Mr. Shatner for example)

      Typical justification where: "He's a busy man", "What did you expect deep insight?", etc.

      Here we had someone who is no doubt busy but provided, in-depth, insightful and complete answers.
  • It's kinda sad (Score:3, Insightful)

    by Anonymous Coward on Wednesday June 18, 2003 @11:18AM (#6234337)
    This one little interview puts last night's WinFS story [slashdot.org] to complete shame.
  • Wow. (Score:5, Interesting)

    by bwhaley ( 410361 ) * <bwhaley@gmai[ ]om ['l.c' in gap]> on Wednesday June 18, 2003 @11:23AM (#6234382)
    You do all understand that while the GPL doesn't permit tying by license, distros have now moved to using threats of invalidating support contracts to achieve the market leverage they need to exclude competitors, yes?

    I wasn't aware of this at all. I'd like to see this expanded, i.e. what distros are doing this? Does it violate any GPL issues? Why are these distros undermining the glue that holds Linux together? What does Linux think?

    Competition is important. Hans is exactly right when he says that no support contract should tie a customer to a specific piece of software. Free software is all about choice!

    As The Dude would say, "this is a bummer, man..."

    Ben
    • What does Linux think?

      Linus*

      Damned slashcode. Why can't I go fix it?

      • by cwernli ( 18353 )

        Damned slashcode. Why can't I go fix it?

        A hundred obvious reasons.

        The first one is: use your imagination. When it says "Use the preview button" it acutally means "re-read your comment, and watch out for logical inconsistencies, spelling errors and ECHOLON-triggering expressions". :)

        • ECHOLON-triggering expressions". :)

          What is this E-COLON thing? Tracking information through the bowels of the internet? Sounds like something the government would fund ;)

    • Re:Wow. (Score:5, Insightful)

      by IamTheRealMike ( 537420 ) on Wednesday June 18, 2003 @11:39AM (#6234495)
      Competition is important. Hans is exactly right when he says that no support contract should tie a customer to a specific piece of software. Free software is all about choice!

      So if a company doesn't support your software, go find somebody who will. I'm sure various trolls will turn this into a "Red Hat are EVILLLLL!" issue, but of course the reality isn't like that.

      Support is hard, because software has a nearly infinite number of combinations. If you're going to provide reliable, accurate support, you can only have expertise in a small subset of those configurations.

      Can YOU imagine being on the end of the phone, trying to help somebody recover a server and every few minutes find that they were running with experimental kernel patches, or ancient/buggy software, or that a fault seemed to be caused by a random frob off SourceForge that you'd never heard of? Total nightmare! You have to draw the line somewhere.

      This is why CodeWeavers only support a subset of the available Win32 applications, and don't support you if you hack CrossOver to use a pre-existing Windows installation etc, the number of unknowns gets so high that it's not only not profitable, but you run the risk of giving the customer bad advice.

      • Re:Wow. (Score:5, Interesting)

        by bwhaley ( 410361 ) * <bwhaley@gmai[ ]om ['l.c' in gap]> on Wednesday June 18, 2003 @12:07PM (#6234723)
        Support is hard, because software has a nearly infinite number of combinations. If you're going to provide reliable, accurate support, you can only have expertise in a small subset of those configurations.

        Agreed, support IS hard. But I disagree that "you can only have expertise in a small subset of those configurations." Take, for instance, a typical University or ISP helpdesk. There is a HUGE variety of issues that must be supported, almost all due to user error. The point of the helpdesk is to be helpful in as wide a variety of areas as possible. Well-organized helpdesks accomplish this invaluable service with just a few weeks of training.

        Your examples are not valid here. "experimental kernel patches, or ancient/buggy software, or that a fault seemed to be caused by a random frob off SourceForge that you'd never heard of" are not the software in question. ReiserFS is a stable and mature filesystem in use by millions (read: made up statistic) of people. It is not fair for a distribution, who should be promoting competition rather than inhibiting it, to disallow use of software because of personal issues.

        I'm glad Linus has enough foresight to include it in the kernel.

        • Take, for instance, a typical University or ISP helpdesk.

          The kind of support Red Hat provide is not the same kind as the kind a helpdesk provides.

          Red Hat are there to support the help desk. An answer of, "Umm, dunno" is not acceptable. If they don't know the answer, they have to be able to say, "we'll get our engineers right on it, you'll have an answer soon". They can't do that for a piece of code they have no expertise on.

          Support in this context also means patches and updates. Obviously if you ins

        • by ajs ( 35943 )
          In the example that you give, the college helpdesk a) does not lose customers if they can't solve your problem b) does not have to QA everything that they support.

          Those two factors should be answer enough to the question of why Red Hat doesn't just support "stuff that runs on my box".
      • Re:Wow. (Score:4, Insightful)

        by PetWolverine ( 638111 ) on Wednesday June 18, 2003 @12:13PM (#6234789) Journal
        Can YOU imagine being on the end of the phone, trying to help somebody recover a server and every few minutes find that they were running with experimental kernel patches, or ancient/buggy software, or that a fault seemed to be caused by a random frob off SourceForge that you'd never heard of?

        No, I can't imagine Hell. I can, however, imagine a company claiming to support Linux at least making an attempt to support kernels that are fully official and straight from Linus. This is what Hans was complaining about: that some distros don't support official releases of the kernel because they don't like this or that feature.

        If you say you support Linux, then support Linux.
        • --If $DISTRO doesn't run/support a stock Linus kernel, I won't use it. Period. About the 1st thing I did when installing SuSE 7.3 (years ago) is upgrade the outdated (2.4.10?) kernel to the latest Linus 2.4 source code. Everything still worked.
        • Depending on official kernels is hopeless. What will you do if the official kernel leaves a local root exploit open for months? If you patch it yourself, you are not using the official kernel anymore...
      • Re:Wow. (Score:5, Insightful)

        by justins ( 80659 ) on Wednesday June 18, 2003 @12:18PM (#6234845) Homepage Journal
        So if a company doesn't support your software, go find somebody who will. I'm sure various trolls will turn this into a "Red Hat are EVILLLLL!" issue, but of course the reality isn't like that.


        Support is hard, because software has a nearly infinite number of combinations. If you're going to provide reliable, accurate support, you can only have expertise in a small subset of those configurations.

        And yet, SuSE and even Mandrake manage to package good, stable, working Reiserfs (not to mention XFS) code, and have for years. It's not unreasonable to ask, what is Redhat's problem?
        • Truly. I've been using SuSE 8.0 for almost a year now, and have had *zero* problems with it what-so-ever.
        • by emil ( 695 )

          I seem to remember two reasons offered by RedHat for resistance to ReiserFS:

          • ext2 filesystems can be easily upgraded to ext3
          • The fsck_ext(2|3) userland utility is very mature, and anything beyond a journal replay under ReiserFS has some probably of a corrupt filesystem (which may have improved in the years since this claim was made)

          I think that Bero made these arguments here on slashdot sometime before he and RedHat parted company. Still, there is no excuse for refusing the tremendous gift of XFS from

        • Re:Wow. (Score:5, Informative)

          by ajs ( 35943 ) <ajs.ajs@com> on Wednesday June 18, 2003 @02:27PM (#6236078) Homepage Journal
          Red Hat ships with Reiser.
          $ rpm -qi kernel
          Name : kernel Relocations: (not relocateable)
          Version : 2.4.20 Vendor: Red Hat, Inc.
          Release : 8 Build Date: Thu Mar 13 18:01:52 2003Install Date: Wed Jun 11 17:18:16 2003 Build Host: porky.devel.redhat.com
          Group : System Environment/Kernel Source RPM: kernel-2.4.20-8.src.rpm
          Size : 31954258 License: GPL
          Signature : DSA/SHA1, Thu Mar 13 18:20:14 2003, Key ID 219180cddb42a60e
          Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
          Summary&nbs p; : The Linux kernel (the core of the Linux operating system)
          Description :
          The kernel package contains the Linux kernel (vmlinuz), the core of your
          Red Hat Linux operating system. The kernel handles the basic functions
          of the operating system: memory allocation, process allocation, device
          input and output, etc.
          $ rpm -ql kernel | grep reiser
          /lib/modules/2.4.20-8/kernel/fs/reiserfs
          /lib/modules/2.4.20-8/kernel/fs/reiserfs/reiserfs. o
          Nuff said?
        • According to bugzilla it's a resource/man hours issue (for installer integration).

          I hope it gets in soon, but I'm not going to crucify Red Hat for this omission.

      • Look at RedHat's hardware compatibility lists... They have tier 1, 2, 3 hardware. RedHat itself has tacitly stated that their support will be less accurate if you are not using tier 1 hardware. The users always have a role to play in the odds of a successful support call.

        I am happy that RedHat made a profit this quarter, and I wish them well.

        However, I think that their changes to support will hurt them in a number of ways:

        • They are placing restrictions on the distribution and use of GPL software, whic

      • Can YOU imagine being on the end of the phone, trying to help somebody recover a server and every few minutes find that they were running with experimental kernel patches, or ancient/buggy software, or that a fault seemed to be caused by a random frob off SourceForge that you'd never heard of?

        Yes, unfortunately.

    • Umm why? A distro doesn't have to include GPLd software in their distro; and they certainly don't need to support it. If you don't like it, pick another distro/support contract. The GPL will ensure that the distro provides the source so that you may do your own support if needs be, and that others can provide competative support [unlike microsoft for example because they're the only ones that *can* provide support/fixes on certain issues]
    • Re:Wow. (Score:3, Insightful)

      by kinnell ( 607819 )
      Competition is important. Hans is exactly right when he says that no support contract should tie a customer to a specific piece of software. Free software is all about choice!

      To play devils advocate, when a support contract is negotiated, it has to be costed by the company providing the support. Supporting a uniform system is much easier/cheaper than supporting a system which not uniform, and could have all sorts of unanticipated problems. Allowing the customer to mess around with the distro in whatever

      • I agree completely. There is definitely room in the market for both the big commercial distros and the independent support. However, my personal opinion is if you have enough in house expertise to make a non-standard system, that you probably have enough in house expertise to support the non-standard stuff (or at least you should).

        For example, I really wanted the usb-storage updates in the new 2.4.21 kernel. However, I use Win4Lin and netraverse hadn't released a kernel patch for 2.4.21 yet (they have s

  • by lpontiac ( 173839 ) on Wednesday June 18, 2003 @11:27AM (#6234415)

    I thought it not being in the filesystem was adequate until I saw a demo of Katie [netcraft.com.au], which lets you mount the repository as an NFS filesystem and access snapshots of the repository at certain points as different directories, take diffs just by running the standard diff between these directories, etc.

    If only there was a stable (Katie's author describes it as "pre-alpha") and free piece of software to do it...

  • >If only the largest distro was so permissive....

    can somebody explain this sentence to me? I am not sure what he is talking about.
    • Re:explanation pls (Score:4, Informative)

      by sheddd ( 592499 ) <<jmeadlock> <at> ... beachresort.com>> on Wednesday June 18, 2003 @11:39AM (#6234492)
      Redhat doesn't 'easily' support ReiserFS.
    • Re:explanation pls (Score:3, Informative)

      by Feztaa ( 633745 )
      >If only the largest distro was so permissive....

      can somebody explain this sentence to me? I am not sure what he is talking about.


      If you've ever done a RedHat install recently, you might have noticed that while it will let you use a pre-existing ReiserFS partition, it won't let you format a partition as ReiserFS before using it.

      So, if you really, really, really want to use ReiserFS with RedHat, you have to preformat the partition before starting the installer, then tell the installer not to format t
  • He takes a moment to swear at the paucity of features possessed by emacs,

    Never have I expected to see this comment.
    Pigs must be a flying.
  • Versioning (Score:5, Interesting)

    by marktoml ( 48712 ) * <marktoml@hotmail.com> on Wednesday June 18, 2003 @11:37AM (#6234482) Homepage Journal
    Automatic versioning of files is one thing I actually miss from VMS. Certainly not most of the rest of it :)

    • Haha, I was going to post the same thing. I'm suprised many people even remember VMS versioning, but it was done pretty good I would say. Maybe listing all the versions with an ls was a bad idea, that should probably be a different command. Besides, I hate seeing file~ whenever an editor wants to save a backup copy.

      I, for one, will be the first idiot to jump on the versioning train when it gets here in a pre-alpha form that is gauranteed to crash. It's such a useful concept, and implementing it at appl
      • I hate seeing file~ whenever an editor wants to save a backup copy.
        That's why I have
        set backupdir=$HOME/.vim_backups
        in my .vimrc. The backups are still there in case I ever do something stupid, but I don't have to look at them all the time. I'm sure emacs has something similar. I liked VMS versioning too, but my directories did fill up really fast.
    • " Automatic versioning of files is one thing I actually miss from VMS. Certainly not most of the rest of it :)"

      I agree completely. As an aside, when you want this kind of versioning, you can get emacs to write out versions as somestuff.~1~, somestuff.~2~,...with the most recent copy named just somestuff. The biggest reason I don't use this is because I can't get ls to sort them the way I would like, especially when it gets to version ~10~.

  • by botzi ( 673768 ) on Wednesday June 18, 2003 @11:58AM (#6234657)
    I know doesn't want to develop for Linux because of the attitude of the inner circle to new people,

    I recall that in an interview a few months ago, Eric Raymond said that on the Linux kernel list there're some dinosaures, that have a hard time acception anything/anyone new.
    Back at that time, I didn't take him seriously(because the reason of his statement was that his kernel configuration tool was not accepted, and he was really affected by it....) and I marked the phrase as an act of anger.
    However, now a second (respected) personality is saying almost a similar thing and I'm starting to wonder. Is there anybody out there who has had similar experience when he wanted to join some Open source project?? Do you think that OS developpers guard their "territory" even more than at the workplace??? Finally, when you're new somewhere, the integration in the team is somehow easier due to the fact that it's the boss who put you on that job...

    PS: For the Eric Raymond interview, google something about his last book and it'll come out....

    • This is common in any dynammicaly evolving system. As it grows, it's becoming more and more complex, which leads it into being more and more conservative.

      So this 'inner circle' thing is a natural way of developement ...
    • I can't comment on the lkml specifically, but I think I've got an idea to explain part of the bad attitude towards newbies. I think it comes from the fact that many start by commenting about how they would do/change things without even understanding the software first. This is the best way to annoy developers and after a while some of the developers might get a "bias against newbies".
    • This piece in Hans' answer puzzled me:

      It is all very fine to discuss the sociology of herd formation, exclusion, and prejudice in the abstract, but one should never say that particular persons are making particular decisions on the basis of their herd instincts unless one wants to be truly hated by them and all of their numerous friends, and this was my mistake over and above the choice of what sub- herd to be part of.

      And all along I thought it was spelled "the HURD"!
  • by pen ( 7191 ) on Wednesday June 18, 2003 @12:03PM (#6234694)
    In case you wonder what he looks like, here are a few pictures of Hans giving a lecture over at LUGOD [lugod.org].
  • by RimmerExperience ( 456643 ) on Wednesday June 18, 2003 @12:12PM (#6234782)

    Reiser4 seems pretty nice, but you still have to pay for the disk space in the first place.

    That's why I'm excited about SpamFS - the first POP3/SMTP-based file system, leveraging the preponderance of free email accounts available on the internet.

    Need more disk space? Sign up for some more email accounts. One advantage ReiserFS has is that it will work a lot better if you have an internet connection problem ... props on that.

    However, Hormel Systems [hormel.com] is really taking a revolutionary approach that I expect Reiser5, Longhorn, and OSX will be forced to incorporate.

  • by Harbinjer ( 260165 ) on Wednesday June 18, 2003 @12:17PM (#6234829) Journal
    Wow! What a great interview. Sometimes you get basically yes/no answers, but I'm really, really impressed with this one. I never really looked much into filesystems, but boy, this was interesting. I would say hurray for SuSe and Mandrake who use ReiserFS. Moreso for Mandrake because they are completely OSS.

    It really seems like ReiserFS is going places. I wonder is there much going on in the developement of the other filysystems? (JFS, XFS, Ext3fs?). I haven't heard any long term plans from any other filesystem guys, but maybe its worth looking into. I'd be curious of other [filesystem] people are actually developing long term, or just fixing stuff.

    I definitely agree with his point about long term research. You just can't do something in a couple weeks or even months. The really great achievements are usually done over a period of years, and as we (humans) learn more and more, the great discoveries will take longer and longer. While it does make sense for buisinesses to want short term research, the government should do things long term, as should the larger companies. I'm especially impressed with IBM, because you sometimes hear of fun stuff(writing IBM in atoms) that is definitely long term being done there, which is cool.

    Again kudos to Hans for this great interview.
  • by moriya ( 195881 ) on Wednesday June 18, 2003 @12:22PM (#6234883) Homepage
    "Is it done yet?"
    "Is what done? Can you rephrase?"
    "I can't... otherwise, you'd charge me for two questions."
  • I'm wondering how exactly filesystem-based version-control would work? Would that mean that a versioned backup of each file is made, or have it optional as to which files are backed up.

    The only version control I've used is MS SourceSafe (insert boos and hisses here, no I don't like it) and also when editing COBOL files on a VAX. Now, it seems to me that the versioning was a property of the VAX and not the editor (as it automatically incremented versions with up to 2 backups) regardless of editor, and/or i
    • The most well-known filesystem-based version control system is Clearcase. Essentially, the user sets up a view, which has a config spec. The config spec specifies what versions of each directory and file the user wants to see. Checkins and checkouts are done as in CVS, except that directories and file renames are tracked as well.

      • It's worth mentioning that both ClearCase and a couple of other version control systems (like Perforce) have had "second gen" features for a few years now.

        Basically, it revolves around using the tools to encourage/compell best practices, hopefully avoiding a lot of the classic pitfalls that people encounter when they try using a version control system on a large-scale basis (hopelessly fragmented file trees, users conflicting with each other's checkouts unnecessarily, an overcomplexity in the use of the v

    • ...I would imagine that he pictures versions being kept until explicitly dealt with.

      This isn't actually as big a deal as it might sound -- really, at least from a user level (as opposed to system), most people have a ton of static files and a few that are updated with any regularity. Assuming that the evolving versions are stored in a halfway intelligent manner (such as ClearCase's file deltas), the amount of "extra" space such a filesystem would consume should be reasonable when put in the context of the

    • It should be optional which files are backed up. Now the interesting question is, what should the interface for that be? For instance, should only one version be maintained until you do the first commit, then two versions until you do the second commit?

      Or, alternatively, should one specify that for a particular file every write creates a new version, or that every close creates a new version, or is there a place for all three approaches, depending on the user's needs?
    • Re:Version Control (Score:2, Interesting)

      by hachete ( 473378 )
      It seems to me like there's "version control" for file-versioning (VMS - which would be great for automatic rollover of log-files) and there's version control for the big projects - a couple hundred+ branches, checkpoints, merge-control (merge control in Clear Case seems less than optional - particularly for the people forced to do it), parallel lines of development etc etc. Then on top of that, you've got distributed working, product release etc etc. Pushing that stuff down to the filesystem is definitely
  • Reiser and the GPL (Score:3, Interesting)

    by lspd ( 566786 ) on Wednesday June 18, 2003 @12:24PM (#6234905) Journal
    You do all understand that while the GPL doesn't permit tying by license, distros have now moved to using threats of invalidating support contracts to achieve the market leverage they need to exclude competitors, yes?

    Although I agree with Reiser's statement that tying support contracts to a GPL product is/should be illegal, some of his other statements about the GPL have been questionable.

    RMS responded [debian.org] to a question about some of Reiser's statements about the GPL v3 indicating that Reiser was incorrect about GPL3 including ad-removal restrictions.

    The entire thread [debian.org] is an interesting read about the GFDL, GPL, and possible crossover between the two. Take a look at the author index [debian.org] for some other interesting tidbits.
  • by Alderete ( 12656 ) * <slashdot@ a l d e r e t e . c om> on Wednesday June 18, 2003 @12:30PM (#6234958) Homepage
    Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front?

    You might find Dominic Giampaolo's book about implementing the BeOS File System (BeFS) interesting:

    Practical File System Design with the Be File System [amazon.com]
    by Dominic Giampaolo

    * Paperback: 237 pages
    * Publisher: Morgan Kaufmann (January 15, 1999)
    * Average Customer Review: 4 out of 5 stars
  • Re: Versioning (Score:5, Interesting)

    by plsuh ( 129598 ) <plsuh@@@goodeast...com> on Wednesday June 18, 2003 @12:32PM (#6234968) Homepage
    Version control definitely belongs in the filesystem. Clearcase may have a lot of implementation uglies, but as a concept it clearly works. Filesystems manage files, and that should include managing file versions.

    One place to look for (sort of) file system versioning support is Subversion [tigris.org], an Apache-licensed replacement for CVS. You can mount this via webdav_fs, and you get automatic versioning that works with just about any application, although right now you need to use a separate client to get access to older versions of the files. Still in alpha, but very stable and worth checking out.

    --Paul
  • B man (Score:2, Funny)

    Now if you think about it, who wants to be around a blind man with a stick,

    I am a blind man without a stick. I swing code around instead...

    The answers were excellent though.
  • #1 is THE answer (Score:5, Insightful)

    by jafac ( 1449 ) on Wednesday June 18, 2003 @01:30PM (#6235549) Homepage
    The question, much asked, is;
    Why does software SUCK?

    The answer is Commercial Constraints on the development process.
    Yes - business pays the bills. But rarely looks to the future, in favor of making a quick buck.

    Can purely academic software suck? Yes. Ivory-towerism leads to a steadfast refusal to meet user requirements.

    Is there a middle-ground approach that might work?
    Certainly.
    But when it becomes a contest of egos between an Academic Founder of a company, and the MBA Suits to prove who's "better" or who has the "power" - guess who wins out more often than not? The middle ground suffers. After all, we're only human, aren't we?
  • Debian (Score:2, Interesting)

    by Anonymous Coward
    My question is, why does Debian consider ReiserFS to be a "less mature, less stable" filesystem than EXT3? ReiserFS was stable in the kernel long before EXT3 had the "experimental" tag removed.
    • Re:Debian (Score:3, Informative)

      by yanestra ( 526590 ) *
      My question is, why does Debian consider ReiserFS to be a "less mature, less stable" filesystem than EXT3? ReiserFS was stable in the kernel long before EXT3 had the "experimental" tag removed.

      There seem to be different philosophies in the use of the "experimental" tag. In fact, ReiserFS kept to be fragile under certain circumstance until about 2.4.16, much later then when it was officially incorporated into the Linux kernel.

  • We should all keep in mind though that there aren't any hard core greedy evil people in our industry. They are all basically good hearted people who chose trying to create a better society as their life's work at a substantial cost in personal income. Petty, bickering, overly impressed with ourselves, flaming, yes that describes most of us Linux kernel developers, but there isn't enough money floating around to attract any genuinely bad folks into our industry.

    Ha ha, bravo, bravo! I like this guy, he see

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Working...