Unluckily, that interface works only because nobody lives in the polar region (well... yes, nearly nobody). For the sky, polar area is a frequently watched part of it, which is hopelessly distorted. Perhaps they should make an alternative view for those?
> I don't think the process of migrating packages from unstable to testing is quite as > automatic as you describe. At least, the most important packages (like linux, gcc, glibc, > dpkg, python, xorg, gnome, kde,...) don't migrate automatically. These transitions are > made only when the maintainers think they're ready to be included in the next stable > debian release and when they're sure that they don't break anything.
The process is automatic. There is even a script to tell you why a particular package in unstable is not yet in testing (see http://bjorn.haxx.se/debian/testing.pl?package=firefox). The following description is from Debian (http://www.debian.org/devel/testing):
> The "testing" distribution is an automatically generated distribution. It is generated > from the "unstable" distribution by a set of scripts which attempt to move over packages > which are reasonably likely to lack release-critical bugs. They do so in a way that > ensures that dependencies of other packages in testing are always satisfiable.
Given the rule that new upload cannot break dependencies before entering testing, it is natural that unless there is some "manual pushing", major updates to these highly depended on packages nearly never happen automatically. The manual manipulation is done to let (force?) them in testing anyway, even though some other package would become uninstallable.
This is inaccurate, as a long time Debian user I really cannot resist in correcting them.
> Debian "unstable" Sid is upgraded every day, or at least several times per week.
True.
> Debian "testing" is upgraded several times a month.
Wrong. Debian testing is updated automatically from packages in Debian unstable. The difference is simply that a package has to sit in Debian unstable for a few days, and no significant bugs can be introduced by the new package, before it is updated. Since the process is automatic, Debian testing is updated just slightly less continuously as unstable (it depends on the robot to check the package dependencies and bug reports rather than the maintainer to upload a new version).
The only time when the update rate is seen as low as less than that is when testing is in deep freeze, i.e., a new stable is about to be created.
> Debian "stable" is upgraded every one or two years.
It usually takes slightly longer than two years.
> The only one I have avoided is "Debian experimental"...:)
You cannot have a pure "Debian experimental" system. Debian experimental are subsystems that could have profound effect on the rest of the system, and so is provided for trial in isolation. E.g., back in the Gnome 1 to Gnome 2 transition days, or XFree 3 to XFree 4 days, these subsystems are tested in experimental before moving to unstable. These packages are supposed to be used on top of or to replace some unstable packages. Since they affects one particular subsystem, experienced testers can try one particular one based on their needs.
I've seen one during a ride on the train, the one just besides me pull out his Eee and start editing his homework during that 2 hour ride. I think there are quite a lot of things that those little PC-like devices do much better than a smartphone or even than a palm. This is especially true for those of us who are not addicted to listening to music or watching movies (even if they have to resort to tiny screens).
> The purpose of the GPL was supposed to be that non-open source can't directly call into GPLed code to avoid > compatibility problems if the open source code changed.
This has never been the purpose of GPL. GPL is a political license. It is written to oppose whoever trying to limit the freedom of users. It is built to partition the whole world of software into "free" and "non-free", and so that they cannot easily cooperate. The hope is that with a world of free software being inter-operable, each individual non-free software, even those large and evil ones, will fail to compete. And the few "license compatibility issue" is seen as technicalities that might make the license less desirable, but is a necessary evil and never so much to worth ditching the effort. In this sense, NDISwrapper is against the whole idea, so it has every reason to have been denied access to other GPL software.
If you hate GPL for this (or whatever) reason, you are free not to use it. But don't expect you can ask projects using GPL to stop using it. They do so for a reason, many of them feel really unhappy if non-free software end up using them as a platform.
The problem is that this is simply not true. Most people can continue with IPv4 under NAT until the first IPv6 big site arrives. But, nobody's going to be that first guy.
I think there is one question that DJB asks is worth thinking: which big site gonna be the first one to run an IPv6-only site? Until we have an answer to that question, we are kept with the chicken-and-egg problem: no one runs dual stack because no one run IPv6 (I wouldn't lose anything if I wait), no one run IPv6 because no one run dual stack (I can't reach anyone if I use IPv6).
> Try writing a schema to validate it... ok I admit, that wasn't so hard, just some > Javascript right? But now you have to write a new batch of code to validate the next > type of JSON you use.
If you constantly need to validate JSON (which I doubt I need it), and then start validating each with "a new batch of code" rather than a generic library with configurations that you can quickly adapt to your new type of JSON, I doubt your programming competence.
Of course, same goes with transformation. And of course, XSLT is one of the worst language that I have ever seen. Try look at any nontrivial XSLT that you have written a couple of months ago. If you can still understand what it does, count yourselves atypical.
XML have their strengths, but I doubt that it is because of validation or transformation.
From Perl 6 FAQ (http://dev.perl.org/perl6/faq.html)
> Will I be able to convert my Perl 5 programs to Perl 6?
> Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.
> In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.
Depending on who you talk to, this can be said to be backward compatible.
Oops... I were to write ~ instead, but suddenly I think I might recall wrong so I check the Apocalypse at http://dev.perl.org/perl6/doc/design/apo/A03.html. It turned out that it is dangerous to skim an entry there without reading it carefully to find the "[Update]" line.
> What motivation can anyone have for upgrading to this new version
See their FAQ at http://dev.perl.org/perl6/faq.html to see the feature list of the Perl 6 language. Myself is very impressed, and probably will have no problem finding motivation if the language is really there.
> when the first thing they'll have to do is go back through all their old scripts and change out every "." to an "_" ?
My understanding about the plan is that you don't have to (most of the time). For code that is still actively maintained, a converter will turn it from using the v5 syntax to using v6 syntax, and you will then catch up the imperfection manually which is hopefully not too much to deal with. You will have to retrain your fingers to type "_" when you would now type ".", though. For code that is no longer maintained, the code will run unchanged, which means they will not be able to use any of the new features of the language, but at the same time this doesn't matter so much (it is not maintained, right?). Furthermore, it probably will be able to detect whether a library is written in Perl 5 or Perl 6, since Perl 6 do not use the "package" keyword that appears in essentially every Perl 5 library (it uses "module" and "class" instead).
Under the new architecture of Perl 6, its runtime (called Parrot) will be able to handle not just Perl 6, but also Perl 5, as well as a whole suite of other languages like BASIC, C, Lisp, Lua, M4, Python, Ruby, Scheme, Tcl, etc. Each of them, like Perl 6, will be interpreted by a separate interpreter into some intermediate representation (PIR) or into the Perl assembly language (PASM) before getting JIT compiled into machine code. PIR and PASM are Perl-aware but not Perl-specific. In other words, the Perl 5 under Perl 6 is not really a "compatibility mode", but instead a "new implementation" of the Perl 5 syntax (as well as other language syntax) targeting Parrot. And once in PASM or PIR, the code written in all these languages looks the same, so it is possible to write Perl 6 that create objects from classes written in Python, which then call functions written in Scheme, etc., which is also a rather exciting promise for me.
> why the fuck did they change it to an "_" in the first place ?
I think the idea is that it want to be in line with other recent languages, all using "." (rather than something like "->") as separator between object identifier and method name. Which is quite reasonable given that the language is on design not backward compatible and should, as I've said, be treated as a completely new language rather than a new version. There are a lot of habits that you will have to break anyway.
> I'll be sticking with 5.005 which has served me well for 7 years.
For me it didn't. There are many useful stuffs in CPAN that will not work at all under 5.005. Upgrade to 5.10 is not that bad, why not make a try?
> Perl 6 received a fair amount of hype when the project began. With no realistic timetable > publicly announced, it seems that people forgot or gave up on it. In fact, in that time > Python has become very popular; I wonder if it has taken some of the 'market share' that > would have otherwise gone to Perl 6.
I tend to think Perl 6 as a completely new language, rather than a new version of an old language. If you have even the concatenation operation changed from "." to "_", and if array indexing that you had written as "$arr[$i]$" now must look like "@arr[$i]" instead, and if you'd lose RAII on the way because garbage collection is now no longer at predictable time, it mean all programs will have to be significantly modified or at least converted. This is not exactly what I'd expect from a new version.
As a new language, it emerge probably slower than what most of us hope, but is probably not as slow as most of us perceived. After all, Perl 6 is a very ambitious language that have all features of Perl 5 and quite a bit more, and it has a completely new low-level engine as well. That slowness is probably due to the lack of any people dedicated to its implementation until very recently.
By the way, Python is not new. The first version of Python is released in approximately the same time as the first version of Perl. Python is first conceived in the 80's, first implementation started being written late 1989, completed 1991, and did not gain general acceptance until 2000. FYI, Perl 6 is conceived in 2000, Pugs starts to be implemented in early 2005, although it is still quite rudimentary.
Don't think it is just funny... it might be truth. BA is a customer of SPARKAda (as listed in http://www.praxis-his.com/sparkada/customers.asp). I expect the software run by the aircraft is proved to be correct to its specification using that, which is a variant of Ada.
The failure of the engines had cut the main power. The 777 does not have cables connecting wing flaps and rudder to the pilots' controls. It is all done by sending electronic signals. However, the plane has several back-up batteries that enable the instruments to work until the emergency power units kick in.
"If they had done nothing, the autopilot would have tried to fly the glide path," said a former pilot. The plane would probably then have stalled and crashed. "So they have to lower the nose to maintain speed, then lift it just before hitting the ground."
...
But he and Burkill, said one former pilot, did "a brilliant job". If the angle is right, a plane gets the benefit of "ground effect" - the wings in effect trap a cushion of air underneath them that softens the landing.
> I followed Brook's advice to study on the data structures and found it good.
This is often underestimated. Understanding the data structure (and, if available, database entries) of a system usually give you everything you need to understand, especially for applications that are not heavy on mathematics and algorithms. Of course, there are programs for which the data structures don't make any sense, and for those it is going to be very difficult to understand using whatever method.
> What if everyone starts relying on say Wikipedia and then that site goes?
My feeling is that if you want current knowledge rather than history, all you need to do is to move along---there will be something better that you can search. On the other hand, if you want history instead, library is still a better choice. If you want to write a paper and cite materials to show the understanding of the world at the time of writing, it is still better off referring to something available in the library.
I feel just the opposite. I find that knowing facts, or at least being able to acquire a large amount of fact quickly, is critical when you want understanding. The web allows the former to be achieved with much greater ease, so this generation is much better off than the previous generation in understanding the world. (It is not to say that web searching did not help in the understanding: I usually find that web search gives me something much easier to digest than whatever I can find in textbooks.)
It is probably true that many people nowadays are much less tolerant to waiting for information, as compared to a decade ago. But that is not an indication that people now don't want understanding. Instead it is because there are now a lot of different choices, and of course any individual will try to maximize return when making choices. If going to a library let him find a result he needs in a morning, while just searching on Google get him to the same information (or perhaps more) in just 10 minutes, it won't be difficult to see which is the winner.
More and more I see library as something to hold history rather than to hold knowledge (both facts and understanding). The web is being changed in every instant, the search result of Google change every day. In contrast, the collection of books in a library hardly change in a year, much less in a month. The content of any individual book never change, except for the damages by other users. While any particular piece of knowledge doesn't really change, the collection of knowledge the community knows change every minute, something previously unknown is now known, something previously thought to be true is now invalidated. So if you want to know what people think about the world now, it is probably more appropriate to search on the web than in the library, at least to get you started by having the facts and the pointers.
> Public education, science education in particular, should not mention gods at all.
I beg to differ. Public education should not include god *in the way it happen now*. But public education should include god, or more exactly, gods, because they are there in all literature. Students should understand that different parts of the world have, historically, has a very different idea about how the world starts out to be. They should know how different Europeans, Chinese, Indians, and other people view the world. It should not be just a single word saying "Catholic", "Hindu" and "Nui Wo". Instead it should be the essence of theory that they believe. And then it should be compared against what scientists currently believe in. Most importantly, it should be made clear that there is no clear winner, because early people lacks the knowledge that we currently possess.
And science education should go one step further. It should give some sort of explanation about why religion is there. The combination of biological, historical, political and scientific interplay that generate religious everywhere should be explained. As well as the reason why it is still there.
> There are some technical details that are new, but capabilities are > extremely old and have been available for Linux for almost a decade.
I don't think so. Process capabilities are there for a long time, but file capabilities has not been there (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"). Without file capabilities, only programmers can make use of process capabilities, system admins cannot. Since programs are usually written with portability in mind, this means they are never used. With file capabilities, a whole new class of users now can make use of the interface, in particular system admins and distribution maintainers. The article did provide very useful information for them.
By "proprietary", I think Nokia refers to the lack of an industrial standardization body controlling Ogg/Theora+Vorbis, meaning they are hopeless in attempting to exert influence in the direction of the standard, say by stuffing committees. And in particular, if they want DRM to please Hollywood people, there is no way to get it. I'm unsure about whether this is a reasonable interpretation of that word, though.
> No-one knows if Ogg Vorbis or Ogg Theora are encumbered by patents. > They were developed to be free of the main known patents, > but they could still be encumbered by some submarine patent. >... > The first concern though is more interesting. Basically Nokia seems to be saying that they'd rather > pay predictable patent licensing fees for H.264/AAC than face unknown risk.
Um... you mean other formats cannot have "submarine" patents because they have some known patents on them? You must be among those who will bring a bomb onto an aircraft because then you have a known bomb and thus, with the same argument, no unknown bombs you cannot control...
> Sounds to me like a bunch of Perl coders with a few million lines of corporate code who thought this would be > easier than learning another language for one specific smallish project.
Sounds to me like a bunch of Perl coders looked at their friends' code and find their ideas interesting, and is worthwhile to implement in their favorite language. Why people never learn to admit that some people think Perl looks nicer than the language they love most?
> > Please, let's not go back to the "guess if there's a closing tag" game.
> There is no "guessing". The rules are perfectly well-defined.
They are well-defined only if you have the DTD to refer to. To ordinary programmers who don't remember the DTD by heart, they are exactly that: guess the place where the closing tag would be put. The most important difference between XML and SGML is that XML does not require a DTD to turn the document into its tree.
> Well, you could do that anyway, but someone else can now do that and package Qmail with it.
Yes, that "someone else" will be all distributors like Debian, Fedora, etc. There's no point asking all users to learn svc when they already have to know inittab, init.d and inetd.
djb really should have allowed that long long ago. What's the point complaining "every distribution has their own way to starting deamons" when each distribution happily support their users by writing the required code and have forums/IRC channels answering questions from users about them.
By the way, I don't see/etc/rc*.d to be going away anytime soon. If you think there is any important features missing from it, the best way to go is probably to file a wishlist bug in the bug tracking systems of the distributors.
Slashdot Mirror
Unluckily, that interface works only because nobody lives in the polar region (well... yes, nearly nobody). For the sky, polar area is a frequently watched part of it, which is hopelessly distorted. Perhaps they should make an alternative view for those?
> I don't think the process of migrating packages from unstable to testing is quite as ...) don't migrate automatically. These transitions are
> automatic as you describe. At least, the most important packages (like linux, gcc, glibc,
> dpkg, python, xorg, gnome, kde,
> made only when the maintainers think they're ready to be included in the next stable
> debian release and when they're sure that they don't break anything.
The process is automatic. There is even a script to tell you why a particular package in unstable is not yet in testing (see http://bjorn.haxx.se/debian/testing.pl?package=firefox). The following description is from Debian (http://www.debian.org/devel/testing):
> The "testing" distribution is an automatically generated distribution. It is generated
> from the "unstable" distribution by a set of scripts which attempt to move over packages
> which are reasonably likely to lack release-critical bugs. They do so in a way that
> ensures that dependencies of other packages in testing are always satisfiable.
Given the rule that new upload cannot break dependencies before entering testing, it is natural that unless there is some "manual pushing", major updates to these highly depended on packages nearly never happen automatically. The manual manipulation is done to let (force?) them in testing anyway, even though some other package would become uninstallable.
This is inaccurate, as a long time Debian user I really cannot resist in correcting them.
:)
> Debian "unstable" Sid is upgraded every day, or at least several times per week.
True.
> Debian "testing" is upgraded several times a month.
Wrong. Debian testing is updated automatically from packages in Debian unstable. The difference is simply that a package has to sit in Debian unstable for a few days, and no significant bugs can be introduced by the new package, before it is updated. Since the process is automatic, Debian testing is updated just slightly less continuously as unstable (it depends on the robot to check the package dependencies and bug reports rather than the maintainer to upload a new version).
The only time when the update rate is seen as low as less than that is when testing is in deep freeze, i.e., a new stable is about to be created.
> Debian "stable" is upgraded every one or two years.
It usually takes slightly longer than two years.
> The only one I have avoided is "Debian experimental"...
You cannot have a pure "Debian experimental" system. Debian experimental are subsystems that could have profound effect on the rest of the system, and so is provided for trial in isolation. E.g., back in the Gnome 1 to Gnome 2 transition days, or XFree 3 to XFree 4 days, these subsystems are tested in experimental before moving to unstable. These packages are supposed to be used on top of or to replace some unstable packages. Since they affects one particular subsystem, experienced testers can try one particular one based on their needs.
I've seen one during a ride on the train, the one just besides me pull out his Eee and start editing his homework during that 2 hour ride. I think there are quite a lot of things that those little PC-like devices do much better than a smartphone or even than a palm. This is especially true for those of us who are not addicted to listening to music or watching movies (even if they have to resort to tiny screens).
> The purpose of the GPL was supposed to be that non-open source can't directly call into GPLed code to avoid
> compatibility problems if the open source code changed.
This has never been the purpose of GPL. GPL is a political license. It is written to oppose whoever trying to limit the freedom of users. It is built to partition the whole world of software into "free" and "non-free", and so that they cannot easily cooperate. The hope is that with a world of free software being inter-operable, each individual non-free software, even those large and evil ones, will fail to compete. And the few "license compatibility issue" is seen as technicalities that might make the license less desirable, but is a necessary evil and never so much to worth ditching the effort. In this sense, NDISwrapper is against the whole idea, so it has every reason to have been denied access to other GPL software.
If you hate GPL for this (or whatever) reason, you are free not to use it. But don't expect you can ask projects using GPL to stop using it. They do so for a reason, many of them feel really unhappy if non-free software end up using them as a platform.
> ... it'll be IPv6 or nothing.
The problem is that this is simply not true. Most people can continue with IPv4 under NAT until the first IPv6 big site arrives. But, nobody's going to be that first guy.
I think there is one question that DJB asks is worth thinking: which big site gonna be the first one to run an IPv6-only site? Until we have an answer to that question, we are kept with the chicken-and-egg problem: no one runs dual stack because no one run IPv6 (I wouldn't lose anything if I wait), no one run IPv6 because no one run dual stack (I can't reach anyone if I use IPv6).
> Try writing a schema to validate it ... ok I admit, that wasn't so hard, just some
> Javascript right? But now you have to write a new batch of code to validate the next
> type of JSON you use.
If you constantly need to validate JSON (which I doubt I need it), and then start validating each with "a new batch of code" rather than a generic library with configurations that you can quickly adapt to your new type of JSON, I doubt your programming competence.
Of course, same goes with transformation. And of course, XSLT is one of the worst language that I have ever seen. Try look at any nontrivial XSLT that you have written a couple of months ago. If you can still understand what it does, count yourselves atypical.
XML have their strengths, but I doubt that it is because of validation or transformation.
From Perl 6 FAQ (http://dev.perl.org/perl6/faq.html)
> Will I be able to convert my Perl 5 programs to Perl 6?
> Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.
> In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.
Depending on who you talk to, this can be said to be backward compatible.
Oops... I were to write ~ instead, but suddenly I think I might recall wrong so I check the Apocalypse at http://dev.perl.org/perl6/doc/design/apo/A03.html. It turned out that it is dangerous to skim an entry there without reading it carefully to find the "[Update]" line.
> What motivation can anyone have for upgrading to this new version
See their FAQ at http://dev.perl.org/perl6/faq.html to see the feature list of the Perl 6 language. Myself is very impressed, and probably will have no problem finding motivation if the language is really there.
> when the first thing they'll have to do is go back through all their old scripts and change out every "." to an "_" ?
My understanding about the plan is that you don't have to (most of the time). For code that is still actively maintained, a converter will turn it from using the v5 syntax to using v6 syntax, and you will then catch up the imperfection manually which is hopefully not too much to deal with. You will have to retrain your fingers to type "_" when you would now type ".", though. For code that is no longer maintained, the code will run unchanged, which means they will not be able to use any of the new features of the language, but at the same time this doesn't matter so much (it is not maintained, right?). Furthermore, it probably will be able to detect whether a library is written in Perl 5 or Perl 6, since Perl 6 do not use the "package" keyword that appears in essentially every Perl 5 library (it uses "module" and "class" instead).
Under the new architecture of Perl 6, its runtime (called Parrot) will be able to handle not just Perl 6, but also Perl 5, as well as a whole suite of other languages like BASIC, C, Lisp, Lua, M4, Python, Ruby, Scheme, Tcl, etc. Each of them, like Perl 6, will be interpreted by a separate interpreter into some intermediate representation (PIR) or into the Perl assembly language (PASM) before getting JIT compiled into machine code. PIR and PASM are Perl-aware but not Perl-specific. In other words, the Perl 5 under Perl 6 is not really a "compatibility mode", but instead a "new implementation" of the Perl 5 syntax (as well as other language syntax) targeting Parrot. And once in PASM or PIR, the code written in all these languages looks the same, so it is possible to write Perl 6 that create objects from classes written in Python, which then call functions written in Scheme, etc., which is also a rather exciting promise for me.
> why the fuck did they change it to an "_" in the first place ?
I think the idea is that it want to be in line with other recent languages, all using "." (rather than something like "->") as separator between object identifier and method name. Which is quite reasonable given that the language is on design not backward compatible and should, as I've said, be treated as a completely new language rather than a new version. There are a lot of habits that you will have to break anyway.
> I'll be sticking with 5.005 which has served me well for 7 years.
For me it didn't. There are many useful stuffs in CPAN that will not work at all under 5.005. Upgrade to 5.10 is not that bad, why not make a try?
> 2. Did it take too long?
> Perl 6 received a fair amount of hype when the project began. With no realistic timetable
> publicly announced, it seems that people forgot or gave up on it. In fact, in that time
> Python has become very popular; I wonder if it has taken some of the 'market share' that
> would have otherwise gone to Perl 6.
I tend to think Perl 6 as a completely new language, rather than a new version of an old language. If you have even the concatenation operation changed from "." to "_", and if array indexing that you had written as "$arr[$i]$" now must look like "@arr[$i]" instead, and if you'd lose RAII on the way because garbage collection is now no longer at predictable time, it mean all programs will have to be significantly modified or at least converted. This is not exactly what I'd expect from a new version.
As a new language, it emerge probably slower than what most of us hope, but is probably not as slow as most of us perceived. After all, Perl 6 is a very ambitious language that have all features of Perl 5 and quite a bit more, and it has a completely new low-level engine as well. That slowness is probably due to the lack of any people dedicated to its implementation until very recently.
By the way, Python is not new. The first version of Python is released in approximately the same time as the first version of Perl. Python is first conceived in the 80's, first implementation started being written late 1989, completed 1991, and did not gain general acceptance until 2000. FYI, Perl 6 is conceived in 2000, Pugs starts to be implemented in early 2005, although it is still quite rudimentary.
I mean "Boeing" is a customer of SPARKAda as listed, not "BA". Sorry for confusion.
Don't think it is just funny... it might be truth. BA is a customer of SPARKAda (as listed in http://www.praxis-his.com/sparkada/customers.asp). I expect the software run by the aircraft is proved to be correct to its specification using that, which is a variant of Ada.
It seems you didn't RTFM. Here's some help...
> I followed Brook's advice to study on the data structures and found it good.
This is often underestimated. Understanding the data structure (and, if available, database entries) of a system usually give you everything you need to understand, especially for applications that are not heavy on mathematics and algorithms. Of course, there are programs for which the data structures don't make any sense, and for those it is going to be very difficult to understand using whatever method.
> What if everyone starts relying on say Wikipedia and then that site goes?
My feeling is that if you want current knowledge rather than history, all you need to do is to move along---there will be something better that you can search. On the other hand, if you want history instead, library is still a better choice. If you want to write a paper and cite materials to show the understanding of the world at the time of writing, it is still better off referring to something available in the library.
I feel just the opposite. I find that knowing facts, or at least being able to acquire a large amount of fact quickly, is critical when you want understanding. The web allows the former to be achieved with much greater ease, so this generation is much better off than the previous generation in understanding the world. (It is not to say that web searching did not help in the understanding: I usually find that web search gives me something much easier to digest than whatever I can find in textbooks.)
It is probably true that many people nowadays are much less tolerant to waiting for information, as compared to a decade ago. But that is not an indication that people now don't want understanding. Instead it is because there are now a lot of different choices, and of course any individual will try to maximize return when making choices. If going to a library let him find a result he needs in a morning, while just searching on Google get him to the same information (or perhaps more) in just 10 minutes, it won't be difficult to see which is the winner.
More and more I see library as something to hold history rather than to hold knowledge (both facts and understanding). The web is being changed in every instant, the search result of Google change every day. In contrast, the collection of books in a library hardly change in a year, much less in a month. The content of any individual book never change, except for the damages by other users. While any particular piece of knowledge doesn't really change, the collection of knowledge the community knows change every minute, something previously unknown is now known, something previously thought to be true is now invalidated. So if you want to know what people think about the world now, it is probably more appropriate to search on the web than in the library, at least to get you started by having the facts and the pointers.
> Public education, science education in particular, should not mention gods at all.
I beg to differ. Public education should not include god *in the way it happen now*. But public education should include god, or more exactly, gods, because they are there in all literature. Students should understand that different parts of the world have, historically, has a very different idea about how the world starts out to be. They should know how different Europeans, Chinese, Indians, and other people view the world. It should not be just a single word saying "Catholic", "Hindu" and "Nui Wo". Instead it should be the essence of theory that they believe. And then it should be compared against what scientists currently believe in. Most importantly, it should be made clear that there is no clear winner, because early people lacks the knowledge that we currently possess.
And science education should go one step further. It should give some sort of explanation about why religion is there. The combination of biological, historical, political and scientific interplay that generate religious everywhere should be explained. As well as the reason why it is still there.
> There are some technical details that are new, but capabilities are
> extremely old and have been available for Linux for almost a decade.
I don't think so. Process capabilities are there for a long time, but file capabilities has not been there (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"). Without file capabilities, only programmers can make use of process capabilities, system admins cannot. Since programs are usually written with portability in mind, this means they are never used. With file capabilities, a whole new class of users now can make use of the interface, in particular system admins and distribution maintainers. The article did provide very useful information for them.
By "proprietary", I think Nokia refers to the lack of an industrial standardization body controlling Ogg/Theora+Vorbis, meaning they are hopeless in attempting to exert influence in the direction of the standard, say by stuffing committees. And in particular, if they want DRM to please Hollywood people, there is no way to get it. I'm unsure about whether this is a reasonable interpretation of that word, though.
> No-one knows if Ogg Vorbis or Ogg Theora are encumbered by patents. ...
> They were developed to be free of the main known patents,
> but they could still be encumbered by some submarine patent.
>
> The first concern though is more interesting. Basically Nokia seems to be saying that they'd rather
> pay predictable patent licensing fees for H.264/AAC than face unknown risk.
Um... you mean other formats cannot have "submarine" patents because they have some known patents on them? You must be among those who will bring a bomb onto an aircraft because then you have a known bomb and thus, with the same argument, no unknown bombs you cannot control...
> Sounds to me like a bunch of Perl coders with a few million lines of corporate code who thought this would be
> easier than learning another language for one specific smallish project.
Sounds to me like a bunch of Perl coders looked at their friends' code and find their ideas interesting, and is worthwhile to implement in their favorite language. Why people never learn to admit that some people think Perl looks nicer than the language they love most?
> > Please, let's not go back to the "guess if there's a closing tag" game.
> There is no "guessing". The rules are perfectly well-defined.
They are well-defined only if you have the DTD to refer to. To ordinary programmers who don't remember the DTD by heart, they are exactly that: guess the place where the closing tag would be put. The most important difference between XML and SGML is that XML does not require a DTD to turn the document into its tree.
> Well, you could do that anyway, but someone else can now do that and package Qmail with it.
/etc/rc*.d to be going away anytime soon. If you think there is any important features missing from it, the best way to go is probably to file a wishlist bug in the bug tracking systems of the distributors.
Yes, that "someone else" will be all distributors like Debian, Fedora, etc. There's no point asking all users to learn svc when they already have to know inittab, init.d and inetd.
djb really should have allowed that long long ago. What's the point complaining "every distribution has their own way to starting deamons" when each distribution happily support their users by writing the required code and have forums/IRC channels answering questions from users about them.
By the way, I don't see