Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
-Original Message- From: Pascal J. Bourguignon Sent: Monday, December 31, 2012 4:22 PM To: Fundamentals of New Computing Subject: Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot Carl Gundel ca...@psychesystems.com writes: “If there are contradictions in the design, the program shouldn't compile.” How can a compiler know how to make sense of domain specific contradictions? I can only imagine the challenges we would face if compilers operated in this way. Contradictions are often not really contradictions. I was referring to the contradictions that really are contradictions. ;-) It's a question of representation, that is, of mapping of the domain, to some other domain, usually a formal system. Yet another dimension in which we can make a mistake? Would this be another kind of unit test? Unit tests can be useful, but they have to be correct and there is a cost to maintaining them. Now we know that a given formal system cannot be at the same time complete and consistent, but nothing prevents an automatic system to work with an incomplete system or an inconsistent system (or even a system that's both incomplete and inconsistent). The only thing, is that sometimes you may reach conclusions such as 1=2, but if you expect them, you can deal with them. We do everyday. Notably, by modifying the mapping between the domain and the formal system: for different parts of the domain, you can use different formal systems, or avoid some axioms or theorems leading to a contradiction, to find some usable conclusion. Are you just talking about a system which will run real time uber lint checks that you can refer to while writing code? Daily, we use formal rules, that are valid just in some context. The conclusions we reach can easily be invalidated, if the context is wrong for the application of those rules. If we tried to take into account all the possible rules, we'd get soon enough inconsistencies. But by restricting the mapping of the domain to some contextual rules, we can read usable conclusions (most of the time). When the conclusion doesn't match the domain, we may ask where the error is, and often it's just the context that was wrong, not the rules. Okay, but if I have to waste my time struggling through the mostly usable conclusions to figure out which ones are usable, and whether or not I actually care about the conclusion, then the value of such a system is debatable. We will have to embrace Artifical Intelligence, even in compilers, eventually. Yeah, let me know when it is finally invented so I can give it a big hug. -Carl ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/31/2012 10:47 PM, Marcus G. Daniels wrote: On 12/31/12 8:30 PM, Paul D. Fernhout wrote: So, I guess another meta-level bug in the Linux Kernel is that it is written in C, which does not support certain complexity management features, and there is no clear upgrade path from that because C++ has always had serious linking problems. But the ABIs aren't specified in terms of language interfaces, they are architecture-specific. POSIX kernel interfaces don't need C++ link level compatibility, or even extern C compatibility interfaces. Similarly on the device side, that's packing command blocks and such, byte by byte. Until a few years ago, GCC was the only compiler ever used (or able) to compile the Linux kernel. It is a feature that it all can be compiled with one open source toolchain. Every aspect can be improved. granted. typically, the actual call into kernel-land is a target-specific glob of ASM code, which may then be wrapped up to make all the various system calls. as for ABIs a few things could help: if the C++ ABI was defined *along with* the C ABI for a given target; if the C++ compilers would use said ABI, rather than each rolling their own; if the ABI were sufficiently general to be more useful to multiple languages (besides just C and C++); ... in this case, the C ABI could be considered a formal subset of the C++ ABI. admittedly, if I could have my say, I would make some changes to the way struct/class passing and returning is handled in SysV / AMD64. namely make it less complicated/evil, like, say, the struct is either passed in a single register, or passed as a reference (no decomposition and passing via multiple registers). more-so, probably also provide spill-space for arguments passed as registers (more like in Win64). granted, this itself may illustrate part of the problem: with many of these ABIs, not everyone is happy, so there is a lot of temptation for compiler vendors to go their own way (making going mix and match with code compiled by different compilers, or sometimes with different compiler options, unsafe...). sometimes, it may usually work, but sometimes fail, due to minor ABI differences. From that thread I read that those in the Linus camp are fine with abstraction, but it has to be their abstraction on their terms. An later in the thread, Theodore T'so gave an example of opacity in the programming model: a = b + /share/ + c + serial_num; Arguing where you can have absolutely no idea how many memory allocations are done, due to type coercions, overloaded operators Well, I'd say just write the code in concise notation. If there are memory allocations they'll show up in valgrind runs, for example. Then disassemble that function and understand what the memory allocations actually are. If there is a better way to do it, then either change abstractions, or improve the compiler to do it more efficiently. Yes, there can be an investment in a lot of stuff. But just defining any programming model with a non-obvious performance model as a bad programming model is shortsighted advice, especially for developers outside of the world of operating systems. That something is non-obvious is not necessarily a bad thing. It just means a bit more depth-first investigation. At least one can _learn_ something from the diversion. yep. some of this is also a bit of a problem for many VM based languages, which may, behind the scenes, chew through memory, while giving little control of any of this to the programmer. in my case, I have been left fighting performance in many areas with my own language, admittedly because its present core VM design isn't particularly high performance in some areas. though, one can still be left looking at a sort of ugly wall: the wall separating static and dynamic types. dynamic types is a land of relative ease, but not particularly good performance. static types is a land of pain and implementation complexity, but also better performance. well, there is also the fixnum issue, where a fixnum may be just slightly smaller than an analogous native type (it is the curse of the 28-30 bit fixnum, or the 60-62 bit long-fixnum...). this issue is annoying specifically because it specifically gets in the way of having an efficient fixnum type and also map it to a sensible native type (like int) while keeping the usual definition intact that int is exactly 32-bits and/or that long is exactly 64-bits. but, as a recent attempt at trying to switch to untagged value types revealed, even with an interpreter core that is mostly statically typed, making this switch may still open a big can of worms in some other cases (because there are still holes in the static type-system). I have been left considering the possibility of instead making a compromise: int, float, and double can be represented directly; long, however, would (still) be handled as a boxed-value. this
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
My take is that crafting software is essentially creating a formal system. No doubt there is some clean, normalized way to construct each one, but given that the work is being done by humans, a large number of less than optimal elements find their way into the system. Since everyone is basically distinct, their own form of semi-normalization is unique. Get a bunch of these together in the same system and there will be inevitable clashes. But given that it#39;s often one variant of weirdness vs another, there is no basis for rational arguments, thus tempers and frustration flair. In the long run however, it#39;s best to pick one weirdness and stick with it (as far as it goes). We don#39;t yet have the knowledge or skills to harmonize these types of systems. Paul.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
I would hope that something like http://en.wikipedia.org/wiki/Z_notationcould be used to specify computer systems. No, I've never used Z notation. It looks like WSDL 2.0 contains it. Cucumber seems more practical, but along the same lines. I've never used Cucumber either. The problem is that specification languages seem to include extra overhead. One has to prove productivity. That is the question, how do we improve productivity while decreasing bugs. Don't do things twice seems to be a good rationale, if the language/system can support it. John On Mon, Dec 31, 2012 at 9:51 AM, Paul Homer paul_ho...@yahoo.ca wrote: My take is that crafting software is essentially creating a formal system. No doubt there is some clean, normalized way to construct each one, but given that the work is being done by humans, a large number of less than optimal elements find their way into the system. Since everyone is basically distinct, their own form of semi-normalization is unique. Get a bunch of these together in the same system and there will be inevitable clashes. But given that it's often one variant of weirdness vs another, there is no basis for rational arguments, thus tempers and frustration flair. In the long run however, it's best to pick one weirdness and stick with it (as far as it goes). We don't yet have the knowledge or skills to harmonize these types of systems. Paul. -- * From: * BGB cr88...@gmail.com; * To: * fonc@vpri.org; * Subject: * Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot * Sent: * Mon, Dec 31, 2012 7:32:31 AM On 12/30/2012 10:49 PM, Paul D. Fernhout wrote: Some people here might find of interest my comments on the situation in the title, posted in this comment here: http://slashdot.org/comments.pl?sid=3346421cid=42430475 After citing Alan Kay's OOPSLA 1997 The Computer Revolution Has Not Happened Yet speech, the key point I made there is: Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance? Another comment I made in that thread cited Andrew Tanenbaum's 1992 comment that it is now all over but the shoutin': http://developers.slashdot.org/comments.pl?sid=3346421threshold=0commentsort=0mode=threadcid=42426755 So, perhaps now we finally twenty-years see the shouting begin as the monolithic Linux kernel reaches its limits as a community process? :-) Still, even if true, it was a good run. The main article can be read here: http://developers.slashdot.org/story/12/12/29/018234/linus-chews-up-kernel-maintainer-for-introducing-userspace-bug This is not to focus on personalities or the specifics of that mailing list interaction -- we all make mistakes (whether as leaders or followers or collaborators), and I don't fully understand the culture of the Linux Kernel community. I'm mainly raising an issue about how software design affects our emotions -- in this case, making someone angry probably about something they fear -- and how that may point the way to better software systems like FONC aspired to. dunno... in this case, I think Torvalds was right, however, he could have handled it a little more gracefully. code breaking changes are generally something to be avoided wherever possible, which seems to be the main issue here. sometimes it is necessary though, but usually this needs to be for a damn good reason. more often though this leads to a shim, such that new functionality can be provided, while keeping whatever exists still working. once a limit is hit, then often there will be a clean break, with a new shiny whatever provided, which is not backwards compatible with the old interface (and will generally be redesigned to address prior deficiencies and open up routes for future extension). then usually, both will coexist for a while, usually until one or the other dies off (either people switch to the new interface, or people rebel and stick to the old one). in a few cases in history, this has instead leads to forks, with the old and new versions developing in different directions, and becoming separate and independent pieces of technology. for example, seemingly unrelated file formats that have a common ancestor, or different CPU ISA's that were once a single ISA, ... likewise, at each step, backwards compatibility may be maintained, but this doesn't necessarily mean that things will remain static. sometimes, there may still be a common-subset, buried off in there somewhere, or in other cases the loss of occasional archaic details, will cause what remains of this common subset to gradually fade away. as for design and emotions: I
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
I don#39;t think a more formalized language really gets around the problem. If that were true, we#39;d have already fallen back to the most consistent, yet simple languages available, such as assembler. But on top of these we build significantly more complex systems, bent by our own internal variations on logic. It#39;s that layer that causes the problems. What seems like it might be successful is to pair our constructions with many languages that more closely match how people think. Now I know that sounds weird, but not if one accepts that a clunky, ugly language like COBOL was actually very successful. Lots of stuff was written, much of it still running. Its own excessive verbosity helps in making it fixable by a broader group of people. Of course there is still a huge problem with that idea. Once written, if the author is no longer available, the work effectively becomes frozen. It can be built upon, but it is hard to truly expand. Thus we get to what we have now, a rather massive house of cards that becomes ever more perilous to build upon. If we want to break the cycle, we have to choose a new option. The size of the work is beyond any individual#39;s capacity, combining different people#39;s work is prone to clashes, the more individualized we make the languages the harder they are to modify, and the more normalized we make the hard they are to use. Paul. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/31/12 10:30 AM, Paul Homer wrote: Now I know that sounds weird, but not if one accepts that a clunky, ugly language like COBOL was actually very successful. Lots of stuff was written, much of it still running. Its own excessive verbosity helps in making it fixable by a broader group of people. For the waterfall approach used by designers behind COBOL implementations, the philsophy of measure twice; cut once is consistent with a formal approach.But if there are so many bugs that last for decades, and bugs that can just be fixed by superficial analysis as facilitated by COBOL's verbosity, then there is something seriously wrong with the design and/or verification in the process. I think design without automated code generation and proof-checking support is passing the buck. Ideally, the principles underlying a program should be in that program, and not just as comments. If there are contradictions in the design, the program shouldn't compile. As the design is fleshed out to make a useful program, the programmer (now also a designer) should have the tools to continue to prove all of the pieces. At the end of the day, all bugs should be considered the responsibility of highest level designers. There should be no `cut' at all. Of course, there is rarely the time or incentive structure to do any of this. Productive programmers are the ones that get results and are fast at fixing (and creating) bugs. In critical systems, at least, that's the wrong incentive structure. In these situations, it's more important to reward people that create tests, create internal proofs, and refactor and simplify code. Having very dense code that requires investment to change is a good thing in these situations. A `bad change' should be trivial in practice to identify: The compiler and/or test suite would not let it through -- an objective fact, not an opinion of `experts'. Marcus ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
Most programs are models of our irrational world. Reflections of rather informal systems that are inherently ambiguous and contradictory, just like our species. Nothing short of #39;intelligence#39; could validate that those types of rules match their intended usage in the real world. If we don#39;t build our internal systems models with this in mind, then they#39;d be too fragile to solve real problems for us. Like it or not, intelligence is a necessary ingredient, and we don#39;t yet have any alternatives but ourselves to fill it. Paul.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
+1 From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Paul Homer Sent: Monday, December 31, 2012 3:09 PM To: fonc@vpri.org Subject: Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot Most programs are models of our irrational world. Reflections of rather informal systems that are inherently ambiguous and contradictory, just like our species. Nothing short of 'intelligence' could validate that those types of rules match their intended usage in the real world. If we don't build our internal systems models with this in mind, then they'd be too fragile to solve real problems for us. Like it or not, intelligence is a necessary ingredient, and we don't yet have any alternatives but ourselves to fill it. Paul. _ From: Marcus G. Daniels mar...@snoutfarm.com; To: fonc@vpri.org; Subject: Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot Sent: Mon, Dec 31, 2012 7:50:13 PM On 12/31/12 12:25 PM, Carl Gundel wrote: If there are contradictions in the design, the program shouldn't compile. How can a compiler know how to make sense of domain specific contradictions? I can only imagine the challenges we would face if compilers operated in this way. In the case of numerical method development, the math is represented in Mathematica (Maple, Sage, Macsyma, etc.) and simulations are done using the same or Matlab (Octave, Scipy, R, etc.). The foundational work is already a program. One practical way to advance the state of the art would be to ensure that the symbolic math packages had compilers that created executables that performed as well as Fortran. In general, I'm imagining more programmers adopting languages like Agda, Coq, and ATS, and elaborating their compilers and runtimes to be practical for programming in the large. Marcus ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
I agree with Paul... As programmers we have too many degrees of freedom, too many chances for random variation that needs to be negotiated at every interface between components, etc. Imagine building a car with randomly varying bolt and nut sizes, with no two cars following the same pattern. Craziness I say... make it stop, make it stop! :-/ I think these things are better off simplified in the extreme and carried out by automatons, get the humans out of the picture... Humans should focus on higher level requirements not the nuts and bolts of software construction. Or perhaps a more stochastic process like biology and let order emerge from chaos - maybe the logic will be less brittle that way... But that may be a ways off yet. Clearly whatever we are doing isn't working - it is pure madness to continue in this way. Alan Moore On Dec 31, 2012, at 12:09 PM, Paul Homer paul_ho...@yahoo.ca wrote: Most programs are models of our irrational world. Reflections of rather informal systems that are inherently ambiguous and contradictory, just like our species. Nothing short of 'intelligence' could validate that those types of rules match their intended usage in the real world. If we don't build our internal systems models with this in mind, then they'd be too fragile to solve real problems for us. Like it or not, intelligence is a necessary ingredient, and we don't yet have any alternatives but ourselves to fill it. Paul. -- * From: * Marcus G. Daniels mar...@snoutfarm.com; * To: * fonc@vpri.org; * Subject: * Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot * Sent: * Mon, Dec 31, 2012 7:50:13 PM On 12/31/12 12:25 PM, Carl Gundel wrote: “If there are contradictions in the design, the program shouldn't compile.” How can a compiler know how to make sense of domain specific contradictions? I can only imagine the challenges we would face if compilers operated in this way. In the case of numerical method development, the math is represented in Mathematica (Maple, Sage, Macsyma, etc.) and simulations are done using the same or Matlab (Octave, Scipy, R, etc.). The foundational work is already a program. One practical way to advance the state of the art would be to ensure that the symbolic math packages had compilers that created executables that performed as well as Fortran. In general, I'm imagining more programmers adopting languages like Agda, Coq, and ATS, and elaborating their compilers and runtimes to be practical for programming in the large. Marcus ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/31/12 2:32 AM, BGB wrote: in this case, I think Torvalds was right, however, he could have handled it a little more gracefully. code breaking changes are generally something to be avoided wherever possible, which seems to be the main issue here. While many people posting in the slashdot thread would agree with both your points, it seems that this particular kernel patch had problems for other reasons, and that distinction has been ignored by most commenters. According to the submitter of the patch being criticized, it seems like the patch was intended to move towards unifying the error codes issued by a set of related drivers. What seems to have happened was that the patch submitter by (IMHO poor) design used an error code internally to indicate an error condition that was not meant to leak out back the the user of the driver. The error code was supposed to be transformed as it passed the driver boundary, but was not in this case. So the error code leaked out of the driver (where the meaning of the specific numerical value would thus change as it passed the driver boundary), and then Linus interpreted this situation as an intent by the programmer's or maintainer's to provide an unexpected and inappropriate error codes (thus the strong language). But it was more like there was some sloppy programming on top of a problematical design choice (problematical because exactly this sort of thing could happen) on top of the maintainer not seeing that. Granted, that provides plenty of room for complaint, but it is questionable if Linus saw this when he replied. More specifics on that in a comment I posted with a link to supporting posts on the kernel list: http://slashdot.org/comments.pl?sid=3346421cid=42417029 But here are direct links to related kernel mailing list posts by the patch submitter and the kernel maintainer: https://lkml.org/lkml/2012/12/23/89 https://lkml.org/lkml/2012/12/24/125 So, the human emotions are on top of an issues that seemed incompletely understood. Psychological studies, like of novice vs. expert fire fighters, have shown that where the novice generally tries to use reason to solve a problem (What is going on here based on thinking about the details? What will be the consequences of various choices?), the expert tends to use pattern matching (I've seen this situation before and here is what we should do.) So, that is why experts can make quick judgements and prescribe successful strategies. The experts work in bigger chunks. Still, a downside to that sort of expert reasoning through pattern matching is that it is easy to leap to a conclusion and incorrect prescription when the underlying situation is very close to a common one but has some unexpected twist (as seems to be the case here). Anyway, good to see this sparked some interesting discussion. --Paul Fernhout http://www.pdfernhout.net/ The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those thinking in terms of scarcity. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On Mon, Dec 31, 2012 at 12:24 PM, Paul D. Fernhout pdfernh...@kurtz-fernhout.com wrote: On 12/31/12 2:32 AM, BGB wrote: in this case, I think Torvalds was right, however, he could have handled it a little more gracefully. code breaking changes are generally something to be avoided wherever possible, which seems to be the main issue here. While many people posting in the slashdot thread would agree with both your points, it seems that this particular kernel patch had problems for other reasons, and that distinction has been ignored by most commenters. According to the submitter of the patch being criticized, it seems like the patch was intended to move towards unifying the error codes issued by a set of related drivers. What seems to have happened was that the patch submitter by (IMHO poor) design used an error code internally to indicate an error condition that was not meant to leak out back the the user of the driver. The error code was supposed to be transformed as it passed the driver boundary, but was not in this case. So the error code leaked out of the driver (where the meaning of the specific numerical value would thus change as it passed the driver boundary), and then Linus interpreted this situation as an intent by the programmer's or maintainer's to provide an unexpected and inappropriate error codes (thus the strong language). But it was more like there was some sloppy programming on top of a problematical design choice (problematical because exactly this sort of thing could happen) on top of the maintainer not seeing that. Granted, that provides plenty of room for complaint, but it is questionable if Linus saw this when he replied. More specifics on that in a comment I posted with a link to supporting posts on the kernel list: http://slashdot.org/comments.pl?sid=3346421cid=42417029 But here are direct links to related kernel mailing list posts by the patch submitter and the kernel maintainer: https://lkml.org/lkml/2012/12/23/89 https://lkml.org/lkml/2012/12/24/125 So, the human emotions are on top of an issues that seemed incompletely understood. Psychological studies, like of novice vs. expert fire fighters, have shown that where the novice generally tries to use reason to solve a problem (What is going on here based on thinking about the details? What will be the consequences of various choices?), the expert tends to use pattern matching (I've seen this situation before and here is what we should do.) So, that is why experts can make quick judgements and prescribe successful strategies. The experts work in bigger chunks. Still, a downside to that sort of expert reasoning through pattern matching is that it is easy to leap to a conclusion and incorrect prescription when the underlying situation is very close to a common one but has some unexpected twist (as seems to be the case here). Anyway, good to see this sparked some interesting discussion. --Paul Fernhout Thank you for elucidating the situation like you have. Your evaluation agrees with my own, which I find gratifying, but even if it didn't I am excited to see the social process happen publicly and transparently. (As opposed to the kind of primate politics that an incident like this might trigger in, for example, a tradition corporation or other institution.) I see it as a win for open methods even if Torvalds might have a bit of egg on his face. ~Simon Forman -- http://twitter.com/SimonForman http://www.dendritenetwork.com/ The history of mankind for the last four centuries is rather like that of an imprisoned sleeper, stirring clumsily and uneasily while the prison that restrains and shelters him catches fire, not waking but incorporating the crackling and warmth of the fire with ancient and incongruous dreams, than like that of a man consciously awake to danger and opportunity. --H. P. Wells, A Short History of the World ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
Carl Gundel ca...@psychesystems.com writes:
“If there are contradictions in the design, the program shouldn't
compile.”
How can a compiler know how to make sense of domain specific
contradictions? I can only imagine the challenges we would face if
compilers operated in this way.
Contradictions are often not really contradictions.
It's a question of representation, that is, of mapping of the domain,
to some other domain, usually a formal system.
Now we know that a given formal system cannot be at the same time
complete and consistent, but nothing prevents an automatic system to
work with an incomplete system or an inconsistent system (or even a
system that's both incomplete and inconsistent).
The only thing, is that sometimes you may reach conclusions such as 1=2,
but if you expect them, you can deal with them. We do everyday.
Notably, by modifying the mapping between the domain and the formal
system: for different parts of the domain, you can use different formal
systems, or avoid some axioms or theorems leading to a contradiction, to
find some usable conclusion.
Daily, we use formal rules, that are valid just in some context. The
conclusions we reach can easily be invalidated, if the context is wrong
for the application of those rules. If we tried to take into account
all the possible rules, we'd get soon enough inconsistencies. But by
restricting the mapping of the domain to some contextual rules, we can
read usable conclusions (most of the time). When the conclusion doesn't
match the domain, we may ask where the error is, and often it's just the
context that was wrong, not the rules.
We will have to embrace Artifical Intelligence, even in compilers, eventually.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On Dec 31, 2012, at 1:21 PM, Pascal J. Bourguignon p...@informatimago.com wrote: Now we know that a given formal system cannot be at the same time complete and consistent, but nothing prevents an automatic system to work with an incomplete system or an inconsistent system (or even a system that's both incomplete and inconsistent). The only thing, is that sometimes you may reach conclusions such as 1=2, but if you expect them, you can deal with them. We do everyday. Notably, by modifying the mapping between the domain and the formal system: for different parts of the domain, you can use different formal systems, or avoid some axioms or theorems leading to a contradiction, to find some usable conclusion. In chemical engineering, you design complex, dynamic systems that look like distributed computing systems in software, except that you replace bits with molecules. In the abstract, they are incredibly similar. I've often stated that my chemical engineering education was a valuable foundation for my later work in distributed and parallel systems. Chemical engineering systems commonly have an interesting property: despite being built from a system of physics equations and carefully measured facts about reality, you can reduce that single set of inputs to multiple mutually inconsistent models of system behavior with material differences. The discipline has a rich set of heuristics and methods for dealing with complex distributed system problems that have significant internal contradictions, and with obviously good results, but you rarely see explicit analogues applied in software systems. Computer science, perhaps due to its direct mathematical derivation, is not comfortable with an equivalent state of affairs where 1=2. Nonetheless, models of real complex systems tend to have this property. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/31/12 1:44 PM, Paul D. Fernhout wrote: So, it was a meta-bug in that sense about an unexpected meaning shift when a number leaked beyond a boundary that was supposed to contain it. [..] I'm not sure what sort of automated systems could deal with that kind of unexpected semantic shift? Still, for that one case, probably one could come up with a way of defining symbols that could not leak across boundaries because of compiler checks or using public/private typed aspects of languages to do that (like for example even in Java where you had a public enum for error codes to return to user space, but a different private enum for internal state). In practice the C language the Linux kernel is written in may not make that easy to enforce programmatically though. Yup. Add more opaque types in the kernel implementation so that a type conversion (to the POSIX semantics) _must_ occur. GCC recently converted to compiling itself in stricter C++ mode, and the world did not end. In spite of advice such as.. http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 Marcus ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/31/12 8:30 PM, Paul D. Fernhout wrote: So, I guess another meta-level bug in the Linux Kernel is that it is written in C, which does not support certain complexity management features, and there is no clear upgrade path from that because C++ has always had serious linking problems. But the ABIs aren't specified in terms of language interfaces, they are architecture-specific. POSIX kernel interfaces don't need C++ link level compatibility, or even extern C compatibility interfaces. Similarly on the device side, that's packing command blocks and such, byte by byte. Until a few years ago, GCC was the only compiler ever used (or able) to compile the Linux kernel. It is a feature that it all can be compiled with one open source toolchain. Every aspect can be improved. From that thread I read that those in the Linus camp are fine with abstraction, but it has to be their abstraction on their terms. An later in the thread, Theodore T'so gave an example of opacity in the programming model: a = b + /share/ + c + serial_num; Arguing where you can have absolutely no idea how many memory allocations are done, due to type coercions, overloaded operators Well, I'd say just write the code in concise notation. If there are memory allocations they'll show up in valgrind runs, for example. Then disassemble that function and understand what the memory allocations actually are. If there is a better way to do it, then either change abstractions, or improve the compiler to do it more efficiently. Yes, there can be an investment in a lot of stuff. But just defining any programming model with a non-obvious performance model as a bad programming model is shortsighted advice, especially for developers outside of the world of operating systems. That something is non-obvious is not necessarily a bad thing. It just means a bit more depth-first investigation. At least one can _learn_ something from the diversion. Marcus ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot
On 12/30/2012 10:49 PM, Paul D. Fernhout wrote: Some people here might find of interest my comments on the situation in the title, posted in this comment here: http://slashdot.org/comments.pl?sid=3346421cid=42430475 After citing Alan Kay's OOPSLA 1997 The Computer Revolution Has Not Happened Yet speech, the key point I made there is: Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance? Another comment I made in that thread cited Andrew Tanenbaum's 1992 comment that it is now all over but the shoutin': http://developers.slashdot.org/comments.pl?sid=3346421threshold=0commentsort=0mode=threadcid=42426755 So, perhaps now we finally twenty-years see the shouting begin as the monolithic Linux kernel reaches its limits as a community process? :-) Still, even if true, it was a good run. The main article can be read here: http://developers.slashdot.org/story/12/12/29/018234/linus-chews-up-kernel-maintainer-for-introducing-userspace-bug This is not to focus on personalities or the specifics of that mailing list interaction -- we all make mistakes (whether as leaders or followers or collaborators), and I don't fully understand the culture of the Linux Kernel community. I'm mainly raising an issue about how software design affects our emotions -- in this case, making someone angry probably about something they fear -- and how that may point the way to better software systems like FONC aspired to. dunno... in this case, I think Torvalds was right, however, he could have handled it a little more gracefully. code breaking changes are generally something to be avoided wherever possible, which seems to be the main issue here. sometimes it is necessary though, but usually this needs to be for a damn good reason. more often though this leads to a shim, such that new functionality can be provided, while keeping whatever exists still working. once a limit is hit, then often there will be a clean break, with a new shiny whatever provided, which is not backwards compatible with the old interface (and will generally be redesigned to address prior deficiencies and open up routes for future extension). then usually, both will coexist for a while, usually until one or the other dies off (either people switch to the new interface, or people rebel and stick to the old one). in a few cases in history, this has instead leads to forks, with the old and new versions developing in different directions, and becoming separate and independent pieces of technology. for example, seemingly unrelated file formats that have a common ancestor, or different CPU ISA's that were once a single ISA, ... likewise, at each step, backwards compatibility may be maintained, but this doesn't necessarily mean that things will remain static. sometimes, there may still be a common-subset, buried off in there somewhere, or in other cases the loss of occasional archaic details, will cause what remains of this common subset to gradually fade away. as for design and emotions: I think people mostly prefer to stay with familiar things. unfamiliar things will often drive people away, especially if they look scary of different, whereas people will be more forgiving of things which look familiar, even if they are different internally. often this may well amount to shims as well, where something familiar will be emulated as a shim on top of something different. even if it is actually fake, people will not care, they can just keep on doing what they were doing before. granted, yes, when some people look into the heart of computing, and see this seeming mountain of things held together mostly by shims and some amount of duct tape, they regard it as a thing of horror. others may see it, and be like this is just how it is. luckily, it doesn't go on indefinitely, as often with enough shims, it will create a sufficiently thick layer of abstraction to where it may become more reasonable to rip out a lot of it, while only maintaining the surface-level details (for sake of compatibility). compatibility may be maintained, even if a lot of what goes on in-between has since changed, and things can be extended that much longer... granted, by this point, it is often less the thing it once was so much as an emulator. but, under the surface, what is the real-thing, and what is an emulator, isn't really always all that certain. what usually defines an emulator then, is not so much about what it actually does, but how much of a big ugly seam there is in it doing so. or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
