Concerning 2: The concensus of the list at present is not that "generic journalin" (sic) is a good idea, but rather that the VM system needed some way to apply pressure to journaling filesystems which have to pin pages in memory, and that a generic journaling layer would be one solution to do that. There are plenty of other approaches being discussed as well.
You are also making crossed-purpose demands; in 7 you state that the VFS is becoming more and more and more critical - absolutely! So you want us to (in 1+4) perform a major modification to the structure and allocation strategy of inodes, and to (in 3) open up the VFS architecture to whatever flaky whiz-bang "extensible" modification to its semantics anyone wants? Give me a break. When dealing with core APIs, "extensible" and "unstable" may not be identical, but they are certainly fraternal. Remember the KISS principle?
Granted, I too would like better VFS documentation, and would like it now, too. Richard Gooch has historically done a good job documenting it longer-term, while day-to-day patches from Al do tend to include at least notes about what the interface is expecting and expecting to break. Welcome to bleeding-edge development.
So what's your agenda? This kind of venom is rarely loosed without an ulterior motive, especially by someone who was presumably posting an innocent and curious "Ask Slashdot" question.
I encourage Slashdot readers to look up the recent exchanges between Hans, Al, Alan Cox (all-over-the-kernel guy), Rik van Riel (VM guy), and others, and form your own opinions about the involved parties.
Calling the kernel a "coalition of little feifdoms" is wildly inaccurate, because as the core systems of the kernel become more integrated with each other (think f.e. of the tangled web of interaction between VM/VFS/buffer cache/dcache/icache/swap cache/etc...), the "heads" of each work more and more cooperatively. Sure they still flame each other (time was, being called "pinhead" in linux-kernel was a mark of high esteem), but the amount of respect and degree of deference shown to each other's expertice is truly admirable.
Of course, politics show up every now and then... there are still people who think DevFS integration is the seventh sign of the coming of the antichrist. But even those who vehemently opposed it are now helping to make it really good by adapting the dcache and VFS to work better with it.
IMVHO, Hans made something of a spectacle of himself on the list. He ran around accusing everyone he could find of being corrupted by corporate influences (RedHat was his favorite target, since Alan and SCT of ext3 fame both work for them), while simultaneously admitting he had a strong financial incentive to get ReiserFS integrated with the kernel.
Of course, there are two sides to every story; Hans has been working on/with this thing for a long time, and has sunk a lot of his own blood, sweat, and tears into it, so I don't blame him for getting a little fanatical about it now and again.:-)
I haven't been able to find much in the way of handwriting recognition software for Linux. Anyone have any pointers? It would certainly make my Ricoh G-1200s a lot more useful.
Beowulf is for building large computational clusters. SCO is talking about high-availability clustering for the data server space.
Oh my god! It sounds like...XWindow!
Don't be dense, having 4 xterms open on your console isn't "single console" management. A real, honest-to-God, unified system manangement system would be really useful to those of us who actually have to deal with more than just a single desktop machine (hint: I help administer about 24 Redhat 6.X boxen, and it's a nightmare... the NIS server on our IRIX box is a breath of fresh air compared to trying to get these things in sync.)
Not quite accurate... Linux schedules tasks, which are a generalization representing "schedulable entities". A task could be a thread, could be a process, could be a strange beast that shares its FD array with another task but nothing else, etc.
The idea of introducing some sort of "process container" notion, so "threads" can be clumped together, comes up on the linux-kernel mailing list every now and then. The general opinion I pick up from the list is "it doesn't give you anything that you can't get from process groups and a well-planned userland library."
I think SCO is referring to helping the kernel internals scale up, i.e. fine-grained spinlocking, better code parallelization, etc.
I would be much more excited if Compaq would get on the ball and open source some of the Tru64 (nee Digital Unix) components. The debuggers, profilers, and general development tools kicked serious tail. And I still have wet dreams about AdvFS.
DaveM is notorious for his comments in the TCP/IP stack. Look especially through the 1.3.X and 2.1.X patches for some tasty examples. "Fscking Sun blows goats" has shown up a few times, if I remember correctly.
You can also search the linux-kernel mailing list archives for some lively debates about "cleaning up the language in the kernel source"...
The more features he puts in now, the more chance ReiserFS has of being accepted as a standard.
However, the more features he crams in now, the less change ReiserFS has of making it into the mainline kernel. Why?
Kernel hackers tend to distrust "cool new features". The KISS principle is important when you're dealing with something as important to system stability/utility/etc as the filesystem.
More features makes a subsystem harder to maintain, and Linus and Alan have been on something of a crusade lately to not accept features or patches into the mainline that won't be maintained.
There is also an issue (see recent linux-kernel archives) about the ReiserFS on-disk format having a history of being... uh... transient. Chris Mason says that the format has now stabilized, but when there were monthly (or more frequent) changes to the binary layout, up/down-gradability (i.e. "run a 2.4.X kernel; try out 2.5.Y; go back to 2.4.X without the system crapping out") was a real concern. If the binary-layout-freeze really holds, and Reiser et al commit to maintaining compatibility with the current binary layout for all future versions of ReiserFS, then it might have a chance of getting into 2.4.
In the "new research" portion of last year's SIGCOMM, there was a talk called "Let Fireflies Light Your Way". They talked about building a distributed braking system for trains (and proving its convergence to a 'correct' solution, grin) and mapping similar ideas to flow control and routing for faster convergence to stable behavior. Pretty cool stuff, and the talk is available via the mbone - go here and look at session 5, talk "5-1,2-ali,barford".
Bypass the phone company -- in fact, just ignore the phone company.
This was one of AT&T's motives in getting into the broadband market... a long-distance rate of $0.05/minute is 60% access fees to local phone carriers. If AT&T could bypass local access fees on one end of a LD phone call, that takes $0.015/minute off of their cost, and if they can bypass 'em on both eneds, $0.03/minute.
#1: Red Herring. We're talking about protocol-level enhancements that make attacks like TCP-based DDoS fundamentally difficult to perform. This is a totally different subject from "making sure all programs on my workstation are free of buffer overflows." It is also true that the types of solutions needed to correctly protect systems are usually fairly intrusive and systemic. As the article says (you did read the whole thing before posting, didn't you?),
These changes, while a very complete solution to the problem, probably face the same fate as almost any proposed TCP change -- they'll be ignored. The installed software base is too big and too hard to change.
#2: University IT departments treat researchers pretty uniformly as "clueless", and assume that their own employees are clueful. The result? Clueful hacker-researchers with well-maintained machines are all locked up behind firewalls and active monitoring unnecessarily, while wide-open boxen sit on the public subnets waiting for j0e h4x0r to set up a DDoS outpost.
Cross (makers of pens with three-or-more-digit price tags) makes writing pads that are a step towards smart paper; look here. The technology they use is a few years old, licensed from IBM. I believe they're also priced sub-$200.
There are some comments about this in the Linux kernel... see net/ipv4/tcp_timer.c: * [...] Note that 120 sec is * defined in the protocol as the maximum possible RTT. I guess * we'll have to use something other than TCP to talk to the * University of Mars. * * PAWS allows us longer timeouts and large windows, so once * implemented ftp to mars will work nicely. We will have to fix * the 120 second clamps though!
There is an interesting quirk in some arguments I've heard atheists make. They complain that theists have such limited imaginations when it comes to scientific theories - for example, that theists disbelieve the big bang because it woould require an "impossibly huge initial density" or that theists disbelieve evolution because it "requires such huge amounts of time".
And yet, here in RMS's words we see a choice example of an atheist making precisely the same mistake: he cannot imagine a being who, by its very nature, has created all else that exists and therefore knows the rules, knows the very NATURE of every situation, and is therefore easily capable of distinguishing right and wrong (Note "wrong" on m-w.com - all 6 definitions of the adjective form presume some pre-existing "correct" or "right" thing which "wrong" is defined in contrast to). Whether such a being chooses to ACT in accordance with what it knows is right is a completely different question - where "act" could include a deliberate self-delusion - but again, Stallman's assertion only holds true if you assume that such a being is not capable of self-consistency.
If you allow that all that exists is derivative of one being which is capable of total knowledge of all that is derivative from it, and that it is capable of total self-consistency, then... ta-da... RMS is wrong. (Or, more likely, he just didn't think through that statement very carefully.)
It is more useful (as well as correct, look it up at m-w.com) to think of freedom as the "absense of necessity, coercion, or constraint of choice in action" (stated differently, "the ability to not be obstructed from doing something by another party"). The freedom to modify software (aka "hack") exists only when you are not under the compulsion of either some law directly or some authority granted to another party under said law (copyrights and licensure) to not do so. In using proprietary software, I'm not "exchanging" any freedom, because I never had it to begin with.
The question then is whether
The laws or powers granted under law are morally or ethically "right" (for whatever definition you like of "right")
We should (for whatever definition of "should" you prefer) commit our resources and energies to supporting (whether financially or with our coding skills) products and/or entities which refuse to grant us freedoms that we feel are either "fundamentally right" (see 1) or "preferable, better, more productive, etc".
Mind you, I'm not disagreeing with you... but the meaning of "freedom" very quickly becomes murky in discussions like this...
Re:Please take a "philosophy of science" class
on
Thus Spake Stallman
·
· Score: 1
On what basis do you assume that 'evidence' (as you have defined it in an inductive, western logic sense) has anything to do with veracity?
As long as your belief that "induction works" relies upon an inductive system of proof and disproof, the validity of induction is completely unfalsifiable (because your argument is circular), so you have already defined away the possibility of disbelieving. Which, some could argue, is analogous to "taking it on faith", as you refuse to accept any system of knowledge in which your assumption (inductive proof/disproof as an indication of veracity) does not hold.
If you want a federal privacy guarantee, then (as your subject sugests) get an amendement passed that protects it instead of whining about supreme court justices applying the law as written instead of what they wish the law said.
The 9th and 10th amendments taken together tell us that people MAY have a right to privacy (enumeration "shall not be construed to deny or disparage others [rights]"), but one could argue that powers which are contrary to privacy may be among those "reserved to the States", allowing the states the choice of whether to make privacy a fundamental right or not.
Actually, a quick (15-second) perusal of the actual materials shows that their approach is more like:
< A HREF="http://my.outdatedsite.com/page?robusturlkey words=farts+sandler+zippo+methane+boom" >
So the "robust keywords" are just an HTTP query string attached to the usual URL. When the server goes to produce a 404, it presumably calls a CGI (the distribution's jar file probably contains a 404 servelet or some such beastie) which re-directs (301 or whichever) to google.com with an appropriate query string based on the keywords in "robusturlkeywords".
As an HTTP junkie, I have to say I'm not too fond of it; you're ruining the whole point of 404 semantics. (Kinda like sites that redirect you to their homepage when you give them a bogus URL - it irks me to no end.) It would be much more straightforward (and less prone to attacks and the general unreliability of search engines) for server administrators to start maintaining proper 301-Moved Permanently databases and perform lookups in those whenever the server hits a 404 condition.
However, all of that massive feature-set support and backwards compatibility and cross-kernel compatibility incurs a cost; doing a stat() is no longer just a system call, but instead has to pass through a layer of glibc code to convert whatever the kernel's struct stat du jour is to the glibc "standard" format. And symbol versioning, while extremely useful, adds complexity and latency to the start-up of processes which link against glibc (i.e. EVERYONE).
Linus has commented a few timees that glibc is a little too heavyweight for his tastes; others have noted that, while the Linux kernel's fork() rate and latency are incredible, it's the ld.so complexity and latency that kills us on exec()s.
I have often pondered a project to parallel glibc, called "tlibc" - the Thin C Library. This library would have to be compiled against the kernel it expects to run against; what's more, apps would then have to be compiled against the newly compiled tlibc, because it only guarantees source-compatibility (and that only so long as kernel interface structures don't change in fascinating and difficult-to-handle ways).
Sure, it would be a PITA to develop such a system, but imagine it in the context of a distribution... let the applications come as close to the "raw iron" of the kernel as possible to eek that extra 3% performance out of Apache/Samba/etc. Remember, most production systems pick a distribution and stick with it, WITHOUT DOING ANY NON-SECURITY UPGRADES, for a long time. This could actually be plausible.
Slashdot Mirror
Concerning 2: The concensus of the list at present is not that "generic journalin" (sic) is a good idea, but rather that the VM system needed some way to apply pressure to journaling filesystems which have to pin pages in memory, and that a generic journaling layer would be one solution to do that. There are plenty of other approaches being discussed as well.
You are also making crossed-purpose demands; in 7 you state that the VFS is becoming more and more and more critical - absolutely! So you want us to (in 1+4) perform a major modification to the structure and allocation strategy of inodes, and to (in 3) open up the VFS architecture to whatever flaky whiz-bang "extensible" modification to its semantics anyone wants? Give me a break. When dealing with core APIs, "extensible" and "unstable" may not be identical, but they are certainly fraternal. Remember the KISS principle?
Granted, I too would like better VFS documentation, and would like it now, too. Richard Gooch has historically done a good job documenting it longer-term, while day-to-day patches from Al do tend to include at least notes about what the interface is expecting and expecting to break. Welcome to bleeding-edge development.
So what's your agenda? This kind of venom is rarely loosed without an ulterior motive, especially by someone who was presumably posting an innocent and curious "Ask Slashdot" question.
Calling the kernel a "coalition of little feifdoms" is wildly inaccurate, because as the core systems of the kernel become more integrated with each other (think f.e. of the tangled web of interaction between VM/VFS/buffer cache/dcache/icache/swap cache/etc...), the "heads" of each work more and more cooperatively. Sure they still flame each other (time was, being called "pinhead" in linux-kernel was a mark of high esteem), but the amount of respect and degree of deference shown to each other's expertice is truly admirable.
Of course, politics show up every now and then... there are still people who think DevFS integration is the seventh sign of the coming of the antichrist. But even those who vehemently opposed it are now helping to make it really good by adapting the dcache and VFS to work better with it.
IMVHO, Hans made something of a spectacle of himself on the list. He ran around accusing everyone he could find of being corrupted by corporate influences (RedHat was his favorite target, since Alan and SCT of ext3 fame both work for them), while simultaneously admitting he had a strong financial incentive to get ReiserFS integrated with the kernel.
Of course, there are two sides to every story; Hans has been working on/with this thing for a long time, and has sunk a lot of his own blood, sweat, and tears into it, so I don't blame him for getting a little fanatical about it now and again. :-)
Not to be confused with 2.2.2pre4, the "Almost-valentines day", aka "horny greased weasel", aka "Presidents Day" release.
I haven't been able to find much in the way of handwriting recognition software for Linux. Anyone have any pointers? It would certainly make my Ricoh G-1200s a lot more useful.
The idea of introducing some sort of "process container" notion, so "threads" can be clumped together, comes up on the linux-kernel mailing list every now and then. The general opinion I pick up from the list is "it doesn't give you anything that you can't get from process groups and a well-planned userland library."
I think SCO is referring to helping the kernel internals scale up, i.e. fine-grained spinlocking, better code parallelization, etc.
I would be much more excited if Compaq would get on the ball and open source some of the Tru64 (nee Digital Unix) components. The debuggers, profilers, and general development tools kicked serious tail. And I still have wet dreams about AdvFS.
You can also search the linux-kernel mailing list archives for some lively debates about "cleaning up the language in the kernel source"...
no sure how you count
but syllables do matter
in the second line
On one side: "The Future Will Be A Totalitarian Government Dystopia".
On the other side: "The Future Will Be a Privatized Corporate Dystopia".
In the "new research" portion of last year's SIGCOMM, there was a talk called "Let Fireflies Light Your Way". They talked about building a distributed braking system for trains (and proving its convergence to a 'correct' solution, grin) and mapping similar ideas to flow control and routing for faster convergence to stable behavior. Pretty cool stuff, and the talk is available via the mbone - go here and look at session 5, talk "5-1,2-ali,barford".
#1: Red Herring. We're talking about protocol-level enhancements that make attacks like TCP-based DDoS fundamentally difficult to perform. This is a totally different subject from "making sure all programs on my workstation are free of buffer overflows." It is also true that the types of solutions needed to correctly protect systems are usually fairly intrusive and systemic. As the article says (you did read the whole thing before posting, didn't you?),
#2: University IT departments treat researchers pretty uniformly as "clueless", and assume that their own employees are clueful. The result? Clueful hacker-researchers with well-maintained machines are all locked up behind firewalls and active monitoring unnecessarily, while wide-open boxen sit on the public subnets waiting for j0e h4x0r to set up a DDoS outpost.
Cross (makers of pens with three-or-more-digit price tags) makes writing pads that are a step towards smart paper; look here. The technology they use is a few years old, licensed from IBM. I believe they're also priced sub-$200.
There are some comments about this in the Linux kernel... see net/ipv4/tcp_timer.c:
* [...] Note that 120 sec is
* defined in the protocol as the maximum possible RTT. I guess
* we'll have to use something other than TCP to talk to the
* University of Mars.
*
* PAWS allows us longer timeouts and large windows, so once
* implemented ftp to mars will work nicely. We will have to fix
* the 120 second clamps though!
And yet, here in RMS's words we see a choice example of an atheist making precisely the same mistake: he cannot imagine a being who, by its very nature, has created all else that exists and therefore knows the rules, knows the very NATURE of every situation, and is therefore easily capable of distinguishing right and wrong (Note "wrong" on m-w.com - all 6 definitions of the adjective form presume some pre-existing "correct" or "right" thing which "wrong" is defined in contrast to). Whether such a being chooses to ACT in accordance with what it knows is right is a completely different question - where "act" could include a deliberate self-delusion - but again, Stallman's assertion only holds true if you assume that such a being is not capable of self-consistency.
If you allow that all that exists is derivative of one being which is capable of total knowledge of all that is derivative from it, and that it is capable of total self-consistency, then... ta-da... RMS is wrong. (Or, more likely, he just didn't think through that statement very carefully.)
The question then is whether
- The laws or powers granted under law are morally or ethically "right" (for whatever definition you like of "right")
- We should (for whatever definition of "should" you prefer) commit our resources and energies to supporting (whether financially or with our coding skills) products and/or entities which refuse to grant us freedoms that we feel are either "fundamentally right" (see 1) or "preferable, better, more productive, etc".
Mind you, I'm not disagreeing with you... but the meaning of "freedom" very quickly becomes murky in discussions like this...As long as your belief that "induction works" relies upon an inductive system of proof and disproof, the validity of induction is completely unfalsifiable (because your argument is circular), so you have already defined away the possibility of disbelieving. Which, some could argue, is analogous to "taking it on faith", as you refuse to accept any system of knowledge in which your assumption (inductive proof/disproof as an indication of veracity) does not hold.
Thank God for liberal arts education...
...or standard Microsoft technology?
IBM is also contributing its JFS. So we have 4 journaled fs's on the horizon: ext3, journaled-Reiser, XFS, and JFS.
The 9th and 10th amendments taken together tell us that people MAY have a right to privacy (enumeration "shall not be construed to deny or disparage others [rights]"), but one could argue that powers which are contrary to privacy may be among those "reserved to the States", allowing the states the choice of whether to make privacy a fundamental right or not.
< A HREF="http://my.outdatedsite.com/page?robusturlkey words=farts+sandler+zippo+methane+boom" >
So the "robust keywords" are just an HTTP query string attached to the usual URL. When the server goes to produce a 404, it presumably calls a CGI (the distribution's jar file probably contains a 404 servelet or some such beastie) which re-directs (301 or whichever) to google.com with an appropriate query string based on the keywords in "robusturlkeywords".
As an HTTP junkie, I have to say I'm not too fond of it; you're ruining the whole point of 404 semantics. (Kinda like sites that redirect you to their homepage when you give them a bogus URL - it irks me to no end.) It would be much more straightforward (and less prone to attacks and the general unreliability of search engines) for server administrators to start maintaining proper 301-Moved Permanently databases and perform lookups in those whenever the server hits a 404 condition.
Just MHO.
However, all of that massive feature-set support and backwards compatibility and cross-kernel compatibility incurs a cost; doing a stat() is no longer just a system call, but instead has to pass through a layer of glibc code to convert whatever the kernel's struct stat du jour is to the glibc "standard" format. And symbol versioning, while extremely useful, adds complexity and latency to the start-up of processes which link against glibc (i.e. EVERYONE).
Linus has commented a few timees that glibc is a little too heavyweight for his tastes; others have noted that, while the Linux kernel's fork() rate and latency are incredible, it's the ld.so complexity and latency that kills us on exec()s.
I have often pondered a project to parallel glibc, called "tlibc" - the Thin C Library. This library would have to be compiled against the kernel it expects to run against; what's more, apps would then have to be compiled against the newly compiled tlibc, because it only guarantees source-compatibility (and that only so long as kernel interface structures don't change in fascinating and difficult-to-handle ways).
Sure, it would be a PITA to develop such a system, but imagine it in the context of a distribution... let the applications come as close to the "raw iron" of the kernel as possible to eek that extra 3% performance out of Apache/Samba/etc. Remember, most production systems pick a distribution and stick with it, WITHOUT DOING ANY NON-SECURITY UPGRADES, for a long time. This could actually be plausible.
Then again, maybe it's just pipe dream. I dunno.
Ooh! And I just noticed there's an article posted about the "death of usenet"! How apropos.