Well, the v2.2.xx USB-support is a backport if I'm not all
wrong, and this backport was done simply because a lot of people
needed USB. If you can help find the problem, then please, do so.
I repeat my question, have you reported the problem together with
a decoded oops? And have you tried the latest kernel pre-patch?
It contains a LOT of USB-fixes (I've checked it out.)
The difference between test6 and test10pre3 is quite amazing.
test10pre4, to be honest, isn't very good however, because for the
purpose of finding bugs, two extraoneous BUG() statements were
added. They causes the kernel to oops while it shouldn't.
As for the off-list posting with you being put in Alan's killfile,
this sounds a little strange. I can well imagine you being put in
Viro's killfile, however; he's quite easy to irritate sometimes.
You might well have been blocked out by Alan's VERY aggresive spamfilter,
however. Oh, and this might well be the reason why you haven't heard
anything about the printk-thingie; he might have missed your post
altogether.
As for interoperability support for filesystems, it's simply a fact
that non-native filesystems ARE less important to support than native
ones. And thus we can allow ourselves to leave the planning of that
support to the future and focus on the more urgent issues instead. But
sooner or later, NTFS, BeFS and HFS/HFS+ will get full support, I'm
pretty confident. They all have some form of support already (apart
from HFS+, which stems from the fact that HFS+ is totally impossible
(it seems) to get documentation for.)
As for Linus accepting JFFS into the kernel, I see no reason why
Alexander Viro should have a say there; he doesn't make the calls on
what filesystems go into the kernel, unless they require
changes to the VFS. As for DevFS, yes, that was a little rash move
by Linus. In the long run, however, I think it'll turn out good;
after all, it forced Viro to make his VFS-changes earlier than
planned.
Please submit your proposals for streams/EA's again to the
kernellist. But do as soon as v2.5.0 is released, or at least AFTER
v2.4.1 has been released. Now is not the right time
for such discussions. We're having enough noise as it is with the
ongoing discussion about in-kernel use of C++ (sigh!).
The kernel, does however have some quite clear areas of
responisibility; the ISDN subsystem, the VFS, NFS, ext2, the network
subsystem, the different ports etc. And almost every device-driver has
its own maintainer. The reason why Linus goes through all the patches
anyway is because he's acting as an integrator and supervisor. He
doesn't make sure all drivers work properly, what he does (tries to)
make sure is that no drivers make other drivers fuck up. The same goes
for other parts of the kernel, of course. This is why some bigger
changes, like ReiserFS, takes quite some time to get into the
kernel.
If you think that the 64-bit printk support really is needed, then
submit it again. And if needed, again.
The kernel, does however have some quite clear areas of
responisibility; the ISDN subsystem, the VFS, NFS, ext2, the network
subsystem, the different ports etc. And almost every device-driver has
its own maintainer. The reason why Linus goes through all the patches
anyway is because he's acting as an integrator and supervisor. He
doesn't make sure all drivers work properly, what he does (tries to)
make sure is that no drivers make other drivers fuck up. The same goes
for other parts of the kernel, of course. This is why some bigger
changes, like ReiserFS, takes quite some time to get into the
kernel.
If you think that the 64-bit printk support really is needed, then
submit it again. And if needed, again.
Yes, Viro is quite (in)famous for making changes. Close to all of
them have been very clueful and needed, however. And he's done a decent
job fixing up the mess after himself. And in the cases he hasn't he
has at least informed people about the breakage.
Not true. If I simply hated Linux and didn't care if it
improved, I would simply have kept my mouth shut and used FreeBSD, or
something. THe fact is, I want it to improve. I like it. I'm not blinded
to its faults, though.
Actually, no. I think you'd complain + use FreeBSD. Quite like what
you're doing right now. However, I'm glad to hear this is not the
case...
First, MacOS X doesn't treat directories as files, only the GUI does. Proof: you can cd into any application-"fork" in MacOS X (and NeXTstep for that matter). Perfectly tar-able, perfectly Posix.
However, Linus own suggestion was indeed to treat streams both as files and directories. There are a lot of considerations here, however, and that's one reason why we don't have streams-support in the kernel yet. The VFS is perfectly ready for
such an approach, but we have to think this through.
Yes, BeFS is documented. So is NTFS, and probably HFS too. But they are still proprietary. Be/Microsoft/Apple can make changes without any further notice, and at least when it comes to NTFS, it is not a question of IF it will change, but when...
As for the EA's of BeFS, they'll be easy to preserve. What I was talking about was any possible streams. As I also wrote, I don't know whether BeOS uses streams or not. But IF there are streams in BeFS, and IF they contain vital information, then obviously, it'll require a lot of thought to make support for it good.
Well, I can't speak for v2.2.16; I don't use a v2.2 kernel. Have you tried v2.2.18pre17? After all, that's 4 months worth of bugfixes, and
whether it does fix that particular problem or not, it should fix other things you want fixed. The OOM-killer I was talking about is the one in
v2.4.0test10pre3, as I wrote. That one is quite simple and fully logical: if a process goes haywire and eats all memory, it gets the bullet. It might take a while, but it'll die. Generally, no other
processes get killed in the process. I've tried this with various workloads and it works 100%, on system with very varying configurations
(from 486's with 16MB memory to K6-3's with 256 MB memory.)
If you can oops your kernel by plugging in an USB-scanner, have you supplied a translated copy of the oops to the LKML? Oh, and after a brief look at v2.2.18pre17, I found tons of USB-fixes. Maybe one of those fixes your bug?
You can't possibly believe that Linux is the only operatingsystem that has got buggy device-drivers. Device-drivers ARE fully capable of
crashing your machine. This holds for virtually any operatingsystem (can't say how things hold for beasts such as Z/OS, formerly known as OS/390 and MVS.) The only thing that is special with Linux is that it contains drivers for the hardware. Most other operatingsystems doesn't, barring Windows. But for Windows, the vendors write the
drivers. And they still are buggy. Go figure.
What's so broken about the semaphores/spinlocks in the v2.4 kernel?
Oh, and consider that Linux has support for more filesystems than any
other operatingsystem that I know of...
How do you plan to support all the features of NTFS, XFS,
BeFS, HFS and HPFS on a VFS that respects only Posix?
Well, if I'm not ALL wrong, both XFS and HPFS only contain EA's,
not streams, so they won't be that hard to support. As for HFS, NTFS
and BeFS, I can't say, and I don't feel ashamed to say so. But imho,
none of the proposals posted on the LKML during the entire debate was
sane either. But face it, NTFS, HFS and BeFS will never be the native
filesystems on a Linux-machine. They are all proprietary, for one thing.
The support for them exists first and foremost to help people to
migrate files. The reason there exists a superugly hack for HFS is
that any binary will break without its resourcefork. If I'm not all
wrong, neither BeFS nor NTFS stores any vital information (just
configuration-data, extended attributes etc.) in their streams, so
if they get lost, at least your computer will survive. I might be
off here, though.
We do submit things. Cox even rejected a patch to provide
64-bit printk output on 32-bit platforms, twice. This, after developers
are told they should use printk and not a debugger. Never mind that
even printk is lacking.
I'm pretty confident Alan must have given you an explanation why?
Why not including it here? Might it have been because this was a
patch against a stable kernel-series? Oh, and doesn't printk("%Lu")
work for you? It should print long long's without any trouble,
at least in the v2.4-series.
No, Linus doesn't have to accept code he doesn't like, but if you
try to imagine how much code he has to accept every week, you'd
realise, it isn't really possible for him to find ALL bugs. He does
a DAMN good job, though. And the rest of the people on the LKML
certainly does their part to help him.
There are plenty first-year CS-students that write decent code,
but yes, it is social engineering too. People who don't realise that
they can't patch their own kernel to add the kernel debugger, and
thus won't submit a patch, are probably just as well kept from
submitting their code.
And, why won't Linus use CVS? Accidental additions can be
backed out, the commit logs with provide a start for documentation
(since the inner circle of kernel developers themselves don't write
any), and it will allow better control of the process at large. Right
now, all the major decisions are made off list between Viro, Cox, Linus,
etc. and the rest of us get to hear about them only the next patch is
released. There is never and intent or direction advertised before, and
there's no documentation after. If they at least used CVS and let people
read the histories, we would have a better idea of what few design
decisions are made actually mean.
Well, this is a question I think only Linus can answer. However,
I believe he will sooner or later begin using BitKeeper. Maybe already
for v2.5. Who knows? Only time will tell, I guess.
Quite a lot of the "inner circle" of kernel developers document
their API's. Alan has written a lot of kdoc lately, Peter Anvin
writes very good documentation, Richard Gooch documents everything he
does, etc. But you have to realise, that it's impossible to work
48 hours/day.
A lot of the design discussions are kept on list and has gone on
on for several months before actually turning into code. Other things
are thought up outside of the list. The LKML sometimes simply isn't the
right place to design new things. Live with it. Nowadays, Linus writes
changelogs for every single pre-patch, Alan has done so for ages.
I don't think that you'll get much more information from CVS commitlogs
than from these. But you seem already to have decided that Linux isn't
your thing, so you'd probably not appreciate the kernel no matter what
changes are made. Or am I totally wrong? I mean, your point of view is
that almost no changes are actually thought through. This is a quite
negative attitude.
The reason I considered your post trolling wasn't because of your
opinions on Linux, but because you implied that people reading Slashdot
automatically would flame you, send spam to you, direct ICBM's at your
house etc., just because you have a different opinion.
It is VERY unlikely that people are uninterested in the v2.4test
kernels because they've lost their faith in the kernel development
process. Why? Simple. Because most people that don't hang around
on LKML or Slashdot don't even know about how the development
process works. For that matter, most people hanging on/. probably
don't.
And, yes, people have often critized the development process of
Linux. But face it, the development process works, and is rather
unique. People that critize it are generally those who are new in
the game; one person who yelled and critized a LOT initially was
the CEO of Timpanogas; Jeff V Merkey. He wanted the entire VFS
rewritten to look more like the VFS of Windows NT, simply because
he was used to programming versus that VFS and because he considered
it superior. This was before he came to know the inner guts of
the Linux VFS, before Alexander Viro explained how things were meant
to be done. Nowadays, he comes with a lot of constructive ideas, and help people with legal advice (he's a licensed lawyer, not just a good programmer...)
And believe it or not, constructive criticism that comes with
realistic suggestions for improvements or patches to fix up the
problems does get attention. You mention the code with
undefined C behaviour in your post. This got fixed in the very
next pre-patch. How's that for response?
Not all criticism get heeded right away, not all ideas make it
into the kernel right off. For instance, DevFS had to wait quite
some time. Not because it was a bad idea, but because the VFS-issues
weren't as simple as Richard Gooch initially expected them to be
when he designed DevFS. With a LOT of work by Alexander Viro, it's
now merged. This merge was one of the major points of delay to the
development process. But was it worth it? Definitely.
The reason ReiserFS isn't merged yet is simple: ReiserFS wasn't
working properly until early in the v2.4.0test-series. Hans Reiser
did not admit this, but Chris Mason, the major programmer in the
ReiserFS project, did. Linus thus decided that it was better not
to hold back the testing of the kernel to add a new filesystem that
required rewriting of other parts of the kernel.
Yes, quite a lot of the kernel has been spaghetti-code (lots of
it still is), and the SMP-support has been below par. THIS is the
reason the v2.4 development has taken so long. Not because of
"meaningless" feature freezes and lack of documentation (eventhough
the latter IS a major problem; feel free to do your part!), but because
the v2.3-series has been spent rewriting the VFS and the Network
layer to be clean, neat and scalable under SMP.
I am doing quite some kernel-programming. It's nowhere near
as complicated as you make it out to be. But face it, writing a
driver or a filesystem for a multitasking, multiprocessor operating-system
isn't exactly a piece of cake. If it was, the world might have
been a better place. But the VFS in Linux is not very hard to
write a filesystem for, and making a devicedriver, especially for
PCI or MCA equipment, is almost trivial.
The VM is broken. Yes, the VM is broken. This is a problem. And
it's not one that will be fully taken care of in the v2.4-kernel.
Because we don't want to open full development again. The VM
will be completely rewritten to v2.5, adding memory-pressure
support for journaling filesystems. But you ARE making it looks
far worse than it is. The OOM-killer (at least as of test10pre3) does NOT kill kswapd or X11, unless those really ARE the villains.
And if they are, they deserve to die. Because if kswapd,
a kernel-thread, is buggy, your system will die anyway. But it
isn't, and it won't get killed. There are still a lot of
tuning to do, but this is typically what does belong in the
test-process of a kernel, don't you agree?
Narrow-minded religious devotion to Posix? This isn't
about narrow-mindedness, it's about sanity and interoperability.
It's about not making the same mistakes Microsoft keep doing over
and over again. NTFS streams ARE a complete mess. Try to map them
sanely into the Unix-world, and you'll see. Try to use
tar to backup an NTFS-volume and see how much
you'll preserve...
And v2.4.0test doesn't mean that nothing will be added. It just
means that it's getting ready for the mainstream to start testing
it, because it's nearing feature-completeness and the most problems
are known and documented on Theo's TODO list.
Oh, and about kernel-debuggers. Yes, Linus is violently opposed to those. But does that prevent YOU, or anyone else for that matter, from using one? Several different kernel-debuggers exists for everyones pleasure. Use one of those. What Linus is stubbornly opposed to is having these in the kernel. Because he believes that debuggers are bad. Not because they're helpful, not because they are less cool than doing printk-debugging, but simply because he knows that a lot of people will abstain from reading larger parts of the source to get the picture of the complexity rather than finding out what makes this particular part croak and just add an if (blaha == NULL) clause. He's probably right; I've seen far too many assignments for different CS-classes simply having the bugs patched over by if-clauses, from people that have traced the code to see where it fails. This is not something unique for people using debuggers; people using printf debugging does the same mistakes, but not quite as often.
The claim that Linus won't work with people that use debuggers is bullshit. There are a LOT of developers on the kernellist that do, and he cooperates with them just fine.
Yes, a lot of people complain that things aren't as easy as they'd wish them to be. Amongst them IBM, HP, SGI, Hans Reiser etc. Yes those very same contributes stuff non-the-less. IBM ported Linux to the S/390, HP has been involved with the HP/PA-Risc port (and the IA-64 port?!) if I'm not all wrong, SGI are in the process of porting XFS to Linux, has done a lot of helpful work with NFSv3 etc., and ReiserFS will probably go into v2.4.1 or so.
You know, you ARE really trolling. Not with the substance of this post, but with the last few paragraphs. They are nothing but flamebait. Pray tell me, if you don't want the kernel-developers to tell you to fork your own kernel, and you don't want to submit changes to the kernel to clean things up because you don't like the development
process, why DO you worry? Linux will go to hell anyway, as every other major OS is better designed, performs better, better implemented and run more reliably that Linux.
Uhmmm. Maybe because their product isn't as good as the original?!
Not that this is relevant here anyway. But I think Microsoft is slowly but inevitably digging their own grave. Not just by attacking Linux, but because they don't realise that most people, including the US DoJ is getting pretty much fed up with their business practices.
Well, it IS true that some people have compared Red Hat to Micro$oft lately. Some because they seem to have a paranoid fear of anything commercial, be it open-source or not. But what has been the most voiced opinion lately, is not that Red Hat's goal, intentions or business methods are Micro$oftish, but rather that Red Hat's.0 releases, and especially the latest, RH-Linux 7.0, has a lot of Redmondish features.
Which, one might wonder?! Well, for one, the.0 releases seem to have been rushed out before going through enough beating. It is indeed impossible to fix every bug, but if the bugs hit the everyday users rather than "just" the geeks, maybe something is wrong with the quality assurance process?
Another thing is the handling of the gcc 2.96beta issue. There is no gcc 2.96, despite what the name of the package in Red Hat Linux 7 might be. There was a developmental branch of gcc named 2.96 which hadn't been blessed as finished yet. This branch is now renamed to 2.97 to avoid
misunderstandings. The reason for releasing RH7 with the gcc 2.96 beta branch rather than gcc 2.95.2 is, unless I've misunderstood things completely, because of the flakey C++ support in the latter one. This I can understand, support and
agree with. What I don't support, however, is
naming this compiler anything else than gcc2.96cvs
or gcc2.96beta, something it is.
To quote directly from gcc.gnu.org:
We would like to point out that GCC 2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code-name for our development branch that will
eventually become GCC 3.0. More...
The bottom line is, that the handling of gcc in RH Linux 7 was clumsy. And rather than just saying that "You're wrong", Red Hat should admit that something didn't come out right and at least
apologise to the community. Do not give those who believe that there's a secret agenda behind the acquiring of Cygnus get even more reasons to be paranoid. They're far enough from the reality already.
Like it or not, Red Hat has become synonymous with Linux in large parts of the non-initiated computerworld. And therefore it falls on the shoulders of Red Hat to do their utmost to make their product better than any other Linux distribution. Because the verdict of Linux from the "real world" won't be based on the stability and security of Debian Linux or the cutting-edge features of SuSE. It will almost entirely be based on how bugfree, secure, easy to use and easy to install Red Hat is.
Maybe with time, this will change, but until then, Red Hat must never, ever race to a release
or include beta-software that isn't clearly labeled so. And indeed, this should be in Red Hat's own interest more than anything else, right?
Uhmmm, yeah, sorry. I knew that bit about Manga/Anime, I'm just too darn tired... Yup, many movies are more complete in their non-US versions (just like Debian is...:^) ), mostly when it comes to censoring of explicit sexuality, violence etc. At least in Sweden, almost no movies get censored at all (for some stupid reason, however, they cut a little from American Pie; it's the same version as the US version. The original version is, if I'm not all wrong, almost 5 minutes longer.) If they get cut, it's to shorten them. And IF any censorship is performed, you can still go to "Svenska Censurnämnden" (Swedish institute of Censorship) and demand to see every bleeding second they cut away.
I must admit to have seen some Telesync's/Screeners etc. now and then, and when I then see the movie at the cinema, I often get surprised when I notice scenes that has been cut away in the US versions, often for no apparent reason, except out of fear of sexual content, perhaps...
Mmmm, and of course, some of the best movies are made in Europe anyway, such as Lukas Moodyson's movies "Fucking Åmål" (US title "Show Me Love") and "Tillsammans" (no US title yet; still running on Swedish cinemas), Krzysztof Kieslowski (everything he's made, basically), all the movies based on Astrid Lindgren's books, the Danish Dogma movies, British comedy etc.
Well, I guess most people not living in zone 1 do. I mean, why wait for a year extra to get the movie when you can get the same movie, sans the subtitles right away?! Oh, and many zone 1 residents import movies from other zones. Think
Hong Kong action, Manga, etc.
Alexander Viro might be arrogant, but the VFS is still something extraordinary. Of course, there are major bugs. After all, he did a major overhaul of it. The performance gains with the new VFS is mostly on the SMP level. And the major gain isn't even the performance question. The VFS rewrite was done to make the code sane.
The rewrite is not finished; Al is still working on fixing the remaining non-working filesystems. But some of the filesystems doesn't have a maintainer anymore, and they'll probably remain broken. But we can't possibly set the VFS in stone forever on just to make sure filesystems that lack a maintainer still work for all coming kernels. Drivers/subsystems without a maintainer is a breed-reactor damn closed to having a nuclear meltdown.
The problem isn't that Linus says "the kernel will be out a month from now", every now and then, because generally he hasn't. He's said things like "if we're lucky, we might get this out before the summer", etc. The problem is that people try to put words in his mouth and claim a release is close or misinterpret the numbering of kerenels (v2.4.0test) to mean that the stable version is imminent.
Don't expect a v2.4.0 before seeing at least a few kernels named v2.4.0preX, where X probably should be at least 6 or 7.
Oh, and consider that the v2.1 series went to v2.1.132 before going into pre-patches...
One of the main reasons that the v2.4 kernel has taken so long is the late rewrite of the VM. However, as of a released fix today by Rik van Riel, it's REALLY looking nice. I've tried extremely hard to make my 16MB memory/64 MB swap box to croak, and yet failed so far.
And the new VFS in the kernel leaves most, if not all other OS's NFS:es far behind, imho. Alexander Viro is a genious in this regard.
Some things will simply have to wait for v2.5, such as a good journalling layer for the journaling filesystems, but it would not be too wild a guess that we'll see a journaling filesystem going into the v2.4 series before v2.4.6.
Linus still decides over the kernels. When it comes to the v2.2 kernel, Alan Cox maintains it (he'll probably take over v2.4 sometime in the future when Linus takes on v2.5, but who knows?) and your truly maintains the v2.0 kernel. Linus has the final say on everything though, if he so chooses. The distro's can't force Linus to include anything.
Linus includes what's good technically, not what's good for business. It companies makes good
patches, he includes it. Simple as that.
I'm in general against prenatal analysis, BUT: consider that if they had not done this, they already living daughter would have died. Instead, they managed to save her life. They didn't chose this particular featus because of any superhuman capabilities, they chose it because it had the capability to save the life of their daughter. Rather than taking a chance, letting nature take its course and probably end up with another child that'd die within a few years in the same disease, they managed to put another child to life which was healthy and at the same time rescue their already existing.
Yes, it's a bitchingly hard issue. But, I'd say that it would've been equally unethical to let their daughter die eventhough a way existed to save her.
This is not the use of genetic analysis we need to beware. It's the genetic engineering specifically made for breeding out the weakest for "their own best"...
I'm happy to live far up north in Sweden to be able to see northern lights quite often. It is one of natures most beautiful phenomenon, and I feel sorry for those who miss it out; I really hope that you all can experience a real aurora some day.
Northern lights wander
Dance across the winter sky
Full colour fire
I don't think so, because:
a.) there's no end to be found,
b.) whatever your input is, you get the
same response (this is not a bug) and
c.) interactive fiction usually don't grow exponentially...
For the first time, I'm starting to consider Linux a real competitor for my business. I'm not ready to turn in my E10K yet, but....
Of course, this is soon not a problem anymore, as Linux has been ported (and at least successfully booted) on E10K now. A post on LKML two days ago was on this very subject (and NO, I'm not confusing things with the Alpha announcement, which was made a few hours later; one 20K BogoMIPS (the E10K) and one 40K BogoMIPS (the Alphaserver) computer announced on the kernel-list in just a few hours. That's majorly cool. I wish I had one, and someone who could pay the electricity.
The IBM developerworks page announces that IBM will open-source AFS later on, which is far more important than their open-sourcing of JFS, imho. While ARLA exists and is cool et al., the real thing is still a notch better.
IBM is growing in my regard every second. Now if they only sent me some old hardware with the MCA-bus...:^)
Of course, it'd be a lot better if everyone would sprinkle their <acronym title="eXtended
HyperText Markup Language">XHTML</acronym>-code with <acronym> and <abbrev title="abbrevation"><abbrev></abbrev> in a way that should be quite self-explanatory from the use meta-use above. Those tags
are, if I'm not all wrong, mandatory to pass
Bobby-certification. Too bad no (?) graphical
browsers support them in a sensible manner.
Slashdot Mirror
Well, the v2.2.xx USB-support is a backport if I'm not all wrong, and this backport was done simply because a lot of people needed USB. If you can help find the problem, then please, do so. I repeat my question, have you reported the problem together with a decoded oops? And have you tried the latest kernel pre-patch? It contains a LOT of USB-fixes (I've checked it out.)
The difference between test6 and test10pre3 is quite amazing. test10pre4, to be honest, isn't very good however, because for the purpose of finding bugs, two extraoneous BUG() statements were added. They causes the kernel to oops while it shouldn't.
As for the off-list posting with you being put in Alan's killfile, this sounds a little strange. I can well imagine you being put in Viro's killfile, however; he's quite easy to irritate sometimes. You might well have been blocked out by Alan's VERY aggresive spamfilter, however. Oh, and this might well be the reason why you haven't heard anything about the printk-thingie; he might have missed your post altogether.
As for interoperability support for filesystems, it's simply a fact that non-native filesystems ARE less important to support than native ones. And thus we can allow ourselves to leave the planning of that support to the future and focus on the more urgent issues instead. But sooner or later, NTFS, BeFS and HFS/HFS+ will get full support, I'm pretty confident. They all have some form of support already (apart from HFS+, which stems from the fact that HFS+ is totally impossible (it seems) to get documentation for.)
As for Linus accepting JFFS into the kernel, I see no reason why Alexander Viro should have a say there; he doesn't make the calls on what filesystems go into the kernel, unless they require changes to the VFS. As for DevFS, yes, that was a little rash move by Linus. In the long run, however, I think it'll turn out good; after all, it forced Viro to make his VFS-changes earlier than planned.
Please submit your proposals for streams/EA's again to the kernellist. But do as soon as v2.5.0 is released, or at least AFTER v2.4.1 has been released. Now is not the right time for such discussions. We're having enough noise as it is with the ongoing discussion about in-kernel use of C++ (sigh!).
The kernel, does however have some quite clear areas of responisibility; the ISDN subsystem, the VFS, NFS, ext2, the network subsystem, the different ports etc. And almost every device-driver has its own maintainer. The reason why Linus goes through all the patches anyway is because he's acting as an integrator and supervisor. He doesn't make sure all drivers work properly, what he does (tries to) make sure is that no drivers make other drivers fuck up. The same goes for other parts of the kernel, of course. This is why some bigger changes, like ReiserFS, takes quite some time to get into the kernel.
If you think that the 64-bit printk support really is needed, then submit it again. And if needed, again.
The kernel, does however have some quite clear areas of responisibility; the ISDN subsystem, the VFS, NFS, ext2, the network subsystem, the different ports etc. And almost every device-driver has its own maintainer. The reason why Linus goes through all the patches anyway is because he's acting as an integrator and supervisor. He doesn't make sure all drivers work properly, what he does (tries to) make sure is that no drivers make other drivers fuck up. The same goes for other parts of the kernel, of course. This is why some bigger changes, like ReiserFS, takes quite some time to get into the kernel.
If you think that the 64-bit printk support really is needed, then submit it again. And if needed, again.
Yes, Viro is quite (in)famous for making changes. Close to all of them have been very clueful and needed, however. And he's done a decent job fixing up the mess after himself. And in the cases he hasn't he has at least informed people about the breakage.
Actually, no. I think you'd complain + use FreeBSD. Quite like what you're doing right now. However, I'm glad to hear this is not the case...
First, MacOS X doesn't treat directories as files, only the GUI does. Proof: you can cd into any application-"fork" in MacOS X (and NeXTstep for that matter). Perfectly tar-able, perfectly Posix.
However, Linus own suggestion was indeed to treat streams both as files and directories. There are a lot of considerations here, however, and that's one reason why we don't have streams-support in the kernel yet. The VFS is perfectly ready for such an approach, but we have to think this through.
Yes, BeFS is documented. So is NTFS, and probably HFS too. But they are still proprietary. Be/Microsoft/Apple can make changes without any further notice, and at least when it comes to NTFS, it is not a question of IF it will change, but when...
As for the EA's of BeFS, they'll be easy to preserve. What I was talking about was any possible streams. As I also wrote, I don't know whether BeOS uses streams or not. But IF there are streams in BeFS, and IF they contain vital information, then obviously, it'll require a lot of thought to make support for it good.
Well, I can't speak for v2.2.16; I don't use a v2.2 kernel. Have you tried v2.2.18pre17? After all, that's 4 months worth of bugfixes, and whether it does fix that particular problem or not, it should fix other things you want fixed. The OOM-killer I was talking about is the one in v2.4.0test10pre3, as I wrote. That one is quite simple and fully logical: if a process goes haywire and eats all memory, it gets the bullet. It might take a while, but it'll die. Generally, no other processes get killed in the process. I've tried this with various workloads and it works 100%, on system with very varying configurations (from 486's with 16MB memory to K6-3's with 256 MB memory.)
If you can oops your kernel by plugging in an USB-scanner, have you supplied a translated copy of the oops to the LKML? Oh, and after a brief look at v2.2.18pre17, I found tons of USB-fixes. Maybe one of those fixes your bug?
You can't possibly believe that Linux is the only operatingsystem that has got buggy device-drivers. Device-drivers ARE fully capable of crashing your machine. This holds for virtually any operatingsystem (can't say how things hold for beasts such as Z/OS, formerly known as OS/390 and MVS.) The only thing that is special with Linux is that it contains drivers for the hardware. Most other operatingsystems doesn't, barring Windows. But for Windows, the vendors write the drivers. And they still are buggy. Go figure.
What's so broken about the semaphores/spinlocks in the v2.4 kernel? Oh, and consider that Linux has support for more filesystems than any other operatingsystem that I know of...
Well, if I'm not ALL wrong, both XFS and HPFS only contain EA's, not streams, so they won't be that hard to support. As for HFS, NTFS and BeFS, I can't say, and I don't feel ashamed to say so. But imho, none of the proposals posted on the LKML during the entire debate was sane either. But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine. They are all proprietary, for one thing. The support for them exists first and foremost to help people to migrate files. The reason there exists a superugly hack for HFS is that any binary will break without its resourcefork. If I'm not all wrong, neither BeFS nor NTFS stores any vital information (just configuration-data, extended attributes etc.) in their streams, so if they get lost, at least your computer will survive. I might be off here, though.
I'm pretty confident Alan must have given you an explanation why? Why not including it here? Might it have been because this was a patch against a stable kernel-series? Oh, and doesn't printk("%Lu") work for you? It should print long long's without any trouble, at least in the v2.4-series.
No, Linus doesn't have to accept code he doesn't like, but if you try to imagine how much code he has to accept every week, you'd realise, it isn't really possible for him to find ALL bugs. He does a DAMN good job, though. And the rest of the people on the LKML certainly does their part to help him.
There are plenty first-year CS-students that write decent code, but yes, it is social engineering too. People who don't realise that they can't patch their own kernel to add the kernel debugger, and thus won't submit a patch, are probably just as well kept from submitting their code.
Well, this is a question I think only Linus can answer. However, I believe he will sooner or later begin using BitKeeper. Maybe already for v2.5. Who knows? Only time will tell, I guess.
Quite a lot of the "inner circle" of kernel developers document their API's. Alan has written a lot of kdoc lately, Peter Anvin writes very good documentation, Richard Gooch documents everything he does, etc. But you have to realise, that it's impossible to work 48 hours/day.
A lot of the design discussions are kept on list and has gone on on for several months before actually turning into code. Other things are thought up outside of the list. The LKML sometimes simply isn't the right place to design new things. Live with it. Nowadays, Linus writes changelogs for every single pre-patch, Alan has done so for ages. I don't think that you'll get much more information from CVS commitlogs than from these. But you seem already to have decided that Linux isn't your thing, so you'd probably not appreciate the kernel no matter what changes are made. Or am I totally wrong? I mean, your point of view is that almost no changes are actually thought through. This is a quite negative attitude.
The reason I considered your post trolling wasn't because of your opinions on Linux, but because you implied that people reading Slashdot automatically would flame you, send spam to you, direct ICBM's at your house etc., just because you have a different opinion.
It is VERY unlikely that people are uninterested in the v2.4test kernels because they've lost their faith in the kernel development process. Why? Simple. Because most people that don't hang around on LKML or Slashdot don't even know about how the development process works. For that matter, most people hanging on /. probably
don't.
And, yes, people have often critized the development process of Linux. But face it, the development process works, and is rather unique. People that critize it are generally those who are new in the game; one person who yelled and critized a LOT initially was the CEO of Timpanogas; Jeff V Merkey. He wanted the entire VFS rewritten to look more like the VFS of Windows NT, simply because he was used to programming versus that VFS and because he considered it superior. This was before he came to know the inner guts of the Linux VFS, before Alexander Viro explained how things were meant to be done. Nowadays, he comes with a lot of constructive ideas, and help people with legal advice (he's a licensed lawyer, not just a good programmer...)
And believe it or not, constructive criticism that comes with realistic suggestions for improvements or patches to fix up the problems does get attention. You mention the code with undefined C behaviour in your post. This got fixed in the very next pre-patch. How's that for response?
Not all criticism get heeded right away, not all ideas make it into the kernel right off. For instance, DevFS had to wait quite some time. Not because it was a bad idea, but because the VFS-issues weren't as simple as Richard Gooch initially expected them to be when he designed DevFS. With a LOT of work by Alexander Viro, it's now merged. This merge was one of the major points of delay to the development process. But was it worth it? Definitely.
The reason ReiserFS isn't merged yet is simple: ReiserFS wasn't working properly until early in the v2.4.0test-series. Hans Reiser did not admit this, but Chris Mason, the major programmer in the ReiserFS project, did. Linus thus decided that it was better not to hold back the testing of the kernel to add a new filesystem that required rewriting of other parts of the kernel.
Yes, quite a lot of the kernel has been spaghetti-code (lots of it still is), and the SMP-support has been below par. THIS is the reason the v2.4 development has taken so long. Not because of "meaningless" feature freezes and lack of documentation (eventhough the latter IS a major problem; feel free to do your part!), but because the v2.3-series has been spent rewriting the VFS and the Network layer to be clean, neat and scalable under SMP.
I am doing quite some kernel-programming. It's nowhere near as complicated as you make it out to be. But face it, writing a driver or a filesystem for a multitasking, multiprocessor operating-system isn't exactly a piece of cake. If it was, the world might have been a better place. But the VFS in Linux is not very hard to write a filesystem for, and making a devicedriver, especially for PCI or MCA equipment, is almost trivial.
The VM is broken. Yes, the VM is broken. This is a problem. And it's not one that will be fully taken care of in the v2.4-kernel. Because we don't want to open full development again. The VM will be completely rewritten to v2.5, adding memory-pressure support for journaling filesystems. But you ARE making it looks far worse than it is. The OOM-killer (at least as of test10pre3) does NOT kill kswapd or X11, unless those really ARE the villains. And if they are, they deserve to die. Because if kswapd, a kernel-thread, is buggy, your system will die anyway. But it isn't, and it won't get killed. There are still a lot of tuning to do, but this is typically what does belong in the test-process of a kernel, don't you agree?
Narrow-minded religious devotion to Posix? This isn't about narrow-mindedness, it's about sanity and interoperability. It's about not making the same mistakes Microsoft keep doing over and over again. NTFS streams ARE a complete mess. Try to map them sanely into the Unix-world, and you'll see. Try to use tar to backup an NTFS-volume and see how much you'll preserve...
And v2.4.0test doesn't mean that nothing will be added. It just means that it's getting ready for the mainstream to start testing it, because it's nearing feature-completeness and the most problems are known and documented on Theo's TODO list.
Oh, and about kernel-debuggers. Yes, Linus is violently opposed to those. But does that prevent YOU, or anyone else for that matter, from using one? Several different kernel-debuggers exists for everyones pleasure. Use one of those. What Linus is stubbornly opposed to is having these in the kernel. Because he believes that debuggers are bad. Not because they're helpful, not because they are less cool than doing printk-debugging, but simply because he knows that a lot of people will abstain from reading larger parts of the source to get the picture of the complexity rather than finding out what makes this particular part croak and just add an if (blaha == NULL) clause. He's probably right; I've seen far too many assignments for different CS-classes simply having the bugs patched over by if-clauses, from people that have traced the code to see where it fails. This is not something unique for people using debuggers; people using printf debugging does the same mistakes, but not quite as often.
The claim that Linus won't work with people that use debuggers is bullshit. There are a LOT of developers on the kernellist that do, and he cooperates with them just fine.
Yes, a lot of people complain that things aren't as easy as they'd wish them to be. Amongst them IBM, HP, SGI, Hans Reiser etc. Yes those very same contributes stuff non-the-less. IBM ported Linux to the S/390, HP has been involved with the HP/PA-Risc port (and the IA-64 port?!) if I'm not all wrong, SGI are in the process of porting XFS to Linux, has done a lot of helpful work with NFSv3 etc., and ReiserFS will probably go into v2.4.1 or so.
You know, you ARE really trolling. Not with the substance of this post, but with the last few paragraphs. They are nothing but flamebait. Pray tell me, if you don't want the kernel-developers to tell you to fork your own kernel, and you don't want to submit changes to the kernel to clean things up because you don't like the development process, why DO you worry? Linux will go to hell anyway, as every other major OS is better designed, performs better, better implemented and run more reliably that Linux.
Uhmmm. Maybe because their product isn't as good as the original?!
Not that this is relevant here anyway. But I think Microsoft is slowly but inevitably digging their own grave. Not just by attacking Linux, but because they don't realise that most people, including the US DoJ is getting pretty much fed up with their business practices.
Several 'big iron' vendors has done exactly this. IBM will provide AIXv5 with a Linux-compatibily-layer, etc.
Well, it IS true that some people have compared Red Hat to Micro$oft lately. Some because they seem to have a paranoid fear of anything commercial, be it open-source or not. But what has been the most voiced opinion lately, is not that Red Hat's goal, intentions or business methods are Micro$oftish, but rather that Red Hat's .0 releases, and especially the latest, RH-Linux 7.0, has a lot of Redmondish features.
Which, one might wonder?! Well, for one, the .0 releases seem to have been rushed out before going through enough beating. It is indeed impossible to fix every bug, but if the bugs hit the everyday users rather than "just" the geeks, maybe something is wrong with the quality assurance process?
Another thing is the handling of the gcc 2.96beta issue. There is no gcc 2.96, despite what the name of the package in Red Hat Linux 7 might be. There was a developmental branch of gcc named 2.96 which hadn't been blessed as finished yet. This branch is now renamed to 2.97 to avoid misunderstandings. The reason for releasing RH7 with the gcc 2.96 beta branch rather than gcc 2.95.2 is, unless I've misunderstood things completely, because of the flakey C++ support in the latter one. This I can understand, support and agree with. What I don't support, however, is naming this compiler anything else than gcc2.96cvs or gcc2.96beta, something it is.
To quote directly from gcc.gnu.org:
The bottom line is, that the handling of gcc in RH Linux 7 was clumsy. And rather than just saying that "You're wrong", Red Hat should admit that something didn't come out right and at least apologise to the community. Do not give those who believe that there's a secret agenda behind the acquiring of Cygnus get even more reasons to be paranoid. They're far enough from the reality already.
Like it or not, Red Hat has become synonymous with Linux in large parts of the non-initiated computerworld. And therefore it falls on the shoulders of Red Hat to do their utmost to make their product better than any other Linux distribution. Because the verdict of Linux from the "real world" won't be based on the stability and security of Debian Linux or the cutting-edge features of SuSE. It will almost entirely be based on how bugfree, secure, easy to use and easy to install Red Hat is.
Maybe with time, this will change, but until then, Red Hat must never, ever race to a release or include beta-software that isn't clearly labeled so. And indeed, this should be in Red Hat's own interest more than anything else, right?
Uhmmm, yeah, sorry. I knew that bit about Manga/Anime, I'm just too darn tired... Yup, many movies are more complete in their non-US versions (just like Debian is... :^) ), mostly when it comes to censoring of explicit sexuality, violence etc. At least in Sweden, almost no movies get censored at all (for some stupid reason, however, they cut a little from American Pie; it's the same version as the US version. The original version is, if I'm not all wrong, almost 5 minutes longer.) If they get cut, it's to shorten them. And IF any censorship is performed, you can still go to "Svenska Censurnämnden" (Swedish institute of Censorship) and demand to see every bleeding second they cut away.
I must admit to have seen some Telesync's/Screeners etc. now and then, and when I then see the movie at the cinema, I often get surprised when I notice scenes that has been cut away in the US versions, often for no apparent reason, except out of fear of sexual content, perhaps...
Mmmm, and of course, some of the best movies are made in Europe anyway, such as Lukas Moodyson's movies "Fucking Åmål" (US title "Show Me Love") and "Tillsammans" (no US title yet; still running on Swedish cinemas), Krzysztof Kieslowski (everything he's made, basically), all the movies based on Astrid Lindgren's books, the Danish Dogma movies, British comedy etc.
Well, I guess most people not living in zone 1 do. I mean, why wait for a year extra to get the movie when you can get the same movie, sans the subtitles right away?! Oh, and many zone 1 residents import movies from other zones. Think Hong Kong action, Manga, etc.
s/NFS/VFS/ -- Yup, wishful typo... :^)
Alexander Viro might be arrogant, but the VFS is still something extraordinary. Of course, there are major bugs. After all, he did a major overhaul of it. The performance gains with the new VFS is mostly on the SMP level. And the major gain isn't even the performance question. The VFS rewrite was done to make the code sane.
The rewrite is not finished; Al is still working on fixing the remaining non-working filesystems. But some of the filesystems doesn't have a maintainer anymore, and they'll probably remain broken. But we can't possibly set the VFS in stone forever on just to make sure filesystems that lack a maintainer still work for all coming kernels. Drivers/subsystems without a maintainer is a breed-reactor damn closed to having a nuclear meltdown.
The problem isn't that Linus says "the kernel will be out a month from now", every now and then, because generally he hasn't. He's said things like "if we're lucky, we might get this out before the summer", etc. The problem is that people try to put words in his mouth and claim a release is close or misinterpret the numbering of kerenels (v2.4.0test) to mean that the stable version is imminent.
Don't expect a v2.4.0 before seeing at least a few kernels named v2.4.0preX, where X probably should be at least 6 or 7.
Oh, and consider that the v2.1 series went to v2.1.132 before going into pre-patches...
One of the main reasons that the v2.4 kernel has taken so long is the late rewrite of the VM. However, as of a released fix today by Rik van Riel, it's REALLY looking nice. I've tried extremely hard to make my 16MB memory/64 MB swap box to croak, and yet failed so far.
And the new VFS in the kernel leaves most, if not all other OS's NFS:es far behind, imho. Alexander Viro is a genious in this regard.
Some things will simply have to wait for v2.5, such as a good journalling layer for the journaling filesystems, but it would not be too wild a guess that we'll see a journaling filesystem going into the v2.4 series before v2.4.6.
Hmmm. From this comment, it seems evident YOU haven't had a look at the SMP support in upcoming v2.4 kernel either... Please do.
Yes, the SMP in v2.0 kernels suck majorly.
Yes, the SMP in v2.2 leaves a lot to be desired.
But the v2.4 support is really looking ok.
Linus still decides over the kernels. When it comes to the v2.2 kernel, Alan Cox maintains it (he'll probably take over v2.4 sometime in the future when Linus takes on v2.5, but who knows?) and your truly maintains the v2.0 kernel. Linus has the final say on everything though, if he so chooses. The distro's can't force Linus to include anything.
Linus includes what's good technically, not what's good for business. It companies makes good patches, he includes it. Simple as that.
I'm in general against prenatal analysis, BUT: consider that if they had not done this, they already living daughter would have died. Instead, they managed to save her life. They didn't chose this particular featus because of any superhuman capabilities, they chose it because it had the capability to save the life of their daughter. Rather than taking a chance, letting nature take its course and probably end up with another child that'd die within a few years in the same disease, they managed to put another child to life which was healthy and at the same time rescue their already existing.
Yes, it's a bitchingly hard issue. But, I'd say that it would've been equally unethical to let their daughter die eventhough a way existed to save her.
This is not the use of genetic analysis we need to beware. It's the genetic engineering specifically made for breeding out the weakest for "their own best"...
I'm happy to live far up north in Sweden to be able to see northern lights quite often. It is one of natures most beautiful phenomenon, and I feel sorry for those who miss it out; I really hope that you all can experience a real aurora some day.
Northern lights wander
Dance across the winter sky
Full colour fire
You mean, like BeOS, OS/390, OS/400, RTOS, AmigaOS...
If you read his post more carefully, you'll notice that he's talking about MacOS X Server, not MacOS X. Quite some difference.
I don't think so, because:
a.) there's no end to be found,
b.) whatever your input is, you get the same response (this is not a bug) and
c.) interactive fiction usually don't grow exponentially...
Of course, this is soon not a problem anymore, as Linux has been ported (and at least successfully booted) on E10K now. A post on LKML two days ago was on this very subject (and NO, I'm not confusing things with the Alpha announcement, which was made a few hours later; one 20K BogoMIPS (the E10K) and one 40K BogoMIPS (the Alphaserver) computer announced on the kernel-list in just a few hours. That's majorly cool. I wish I had one, and someone who could pay the electricity.
The IBM developerworks page announces that IBM will open-source AFS later on, which is far more important than their open-sourcing of JFS, imho. While ARLA exists and is cool et al., the real thing is still a notch better.
IBM is growing in my regard every second. Now if they only sent me some old hardware with the MCA-bus... :^)
Of course, it'd be a lot better if everyone would sprinkle their <acronym title="eXtended HyperText Markup Language">XHTML</acronym>-code with <acronym> and <abbrev title="abbrevation"><abbrev></abbrev> in a way that should be quite self-explanatory from the use meta-use above. Those tags are, if I'm not all wrong, mandatory to pass Bobby-certification. Too bad no (?) graphical browsers support them in a sensible manner.
Nope. Emacs exists in many different variants; GNU Emacs being one of them. The beast has got many faces. But why care? Go Go VIM!
Ahhh, but .PNG isn't animated. .MNG is.