Thanks for the great tip. The Latin-1 glyphs repertoire is obsolete--even popular English-language print publications such as Time and Newsweek have NEVER limited themselves to such a pitiful set of characters.
The full text of a 1980s Time Magazine article ought to be completely and correctly displayable anywhere text is displayed on a 21st Century computer, including the command line. For this, we need fonts such as this Gentium as standard. (Of course, we need UTF-8-based shells as standard, too, among other things, and it's starting to happen....)
I can't help thinking that it would end up a better language if you employed your "thinking out loud" essay technique in which people could respond to you and then to one another with ideas that you would study before making the final decisions.
It seems to me that a multipartite (written) discussion forum is the natural extension of an essay by an individual writer when it comes to "searching for truth".
But with Arc you seem to be talking to yourself, which you decry in your essay on essays as likely to lead to the petering out of a project. That or talking to a select handful of colleagues whose opinions you probably trust because they're so similar to your own, which is not so different from talking to yourself.
If you want interesting surprises, why not open the discussion to people who care about things that you and your friends might not have put much thought into?
What are the security implications of your design ideas? Some people don't care about dynamic vs. static typing per se but care a lot about the security issues, some of which might be impacted by this decision. Is there some relatively minor issue that might hamstring automatic decomposition into massive parallelism that you could change now but not later? Are there text models that would dramatically improve your chances of ending up with powerful text processing libraries? And what text model would be most likely to survive the radical changes in computer architectures that we will see over the next century?
You say the world has waited for 45 years for a good Lisp, and you're correct in the sense you intended, but in another sense, of course, the world hasn't waited for Lisp at all. It has left it behind and built up massive ecosystems around its competitors. Those ecosystems are relentlessly growing and create a moving target for what a language is expected to have if it is to be a contender.
Any really successful Lisp will need a lot of time after release to build up such an ecosystem, and the longer it takes to release it, the longer it will take *after* release to become a contender. I think it *will* make a difference whether it is released in 2 years or 10, though even if I'm right, you aren't obligated to do anything about it, of course.
It just seems to me that you'd have a better chance of creating a better overall language if you had an open discussion of the design while change is still easy. You might even get things done sooner by delegating more of the implementation of everything from design comparison prototypes to docs.
That's part of the problem. Paul has a great reputation as an expert in Lisp. He has stated that he is in the middle of building Arc, with all sorts of improvements that many of us want.
--His stated goals for Arc closely match what many of us want, including those that overcome both the shortcomings in non-Lisp languages and in all current Lisps
--He has the technical knowledge of Lisp, including what has and hasn't worked out in practice
--He has the practical experience of creating a large, successful software project using Lisp
--He has the financial resources to do it without need to find corporate sponsors
--He would appear to have the time
--He has the reputation around which to form both a solid team of technical contributors and a passionate community of users
--And he appeared, at least, to have the passion and committment to doing it
With that to contend with, who is going to risk making a big committment of time and resources to starting another Arc with the knowledge that the real Arc could be released at any time?
The only parties I can think of would be large corporations who could put a lot more resources into it than Graham and could own and control the results, but I don't see any that would be interested.
If Graham would give us an update on his plans, it might break the stalemate. If he's not interested, he could say so, making it less risky for others to attempt. He could even post his design notes to help.
If he's still interested, I can't help thinking that Arc would end up better if its design decisions were discussed publicly for a while before it's "too late to change it now". No matter how much of an expert he is, there are those with even more expertise in each of the thousands of little specialty areas that a good, modern, general-purpose language ought to handle well.
No experienced developer is going to blame another one for eventually deciding to drop an exciting project that ended up being too time-consuming. But since we don't know what the story is with Arc, and he has posted "don't even ask for a status report", he has blocked both attempts to help him and attempts to compete with him. Ironically, this approach has ended up "FUDding" the New Lisp market with a vaporware campaign that Microsoft would be proud of.
I enjoy reading Paul's various works, but I'd sure rather have Arc.
After generating considerable excitement about Arc, a lot of discussion, and frequent updates to his Arc website, Paul simply went silent regarding Arc.
Yes, it's true that he'll attend conferences to give keynotes. He'll be billed as the guy behind Arc, but then his talk won't so much as give a status report.
Some have lamented that he has appparently chosen to take the cathedral approach instead of the bazaar with Arc, but I don't see any signs of a cathedral, either. For a language to stand some chance of success these days, it needs a lively developer community. I see no signs that Paul is even interested in hearing from anyone else, much less soliciting help. For the guy who built Yahoo Stores, putting up a discussion board for Arc discussion wouldn't be much of a challenge, but he's never done so.
His site claims to solicit ideas, but that site has been a "cobweb site" for years now. The page on which he was collecting ideas stopped being updated a few weeks after it opened and hasn't been updated for years.
I'd love to have something like Arc. So would a lot of people. It looks as though Paul has lost interest but doesn't want to say so.
Instead, we get interesting essays, which is admittedly more that I deserve, but still less that a lot of us were hoping for.
Yes, the "Dragon Chip" has a special version of Linux, which was designed with a "back door" to allow the Chinese Communist Party to observe what its users are doing.
Interested in using it? Depending on who you work for, the Chinese might give you a special discount.;-)
It seems likely that we'll soon see high octane media coprocessors as standard equipment on PCs. Before long, all PCs will be "audio workstations", as well as video workstations, photo processors, movie theaters, two-way video telephones, game boxes, etc.--a lot of it simultaneously.
Oh, wait. They already are, but they're just trying to do most of this stuff with an x86 chip. Silly. It's not inconceivable that the future of PCs is a block of powerful media processors where the x86 chip will end up being the "code coprocessor"....
most of the stuff you mentioned had been planned to be included in the next releases of java long long time before C# was born.
No, it wasn't. It's not that Sun had never considered these features. They had considered them and rejected (most of) them.
As long as there was no direct competition, Sun was famous for repeatedly informing developers (like me) who requested most of these things that they "didn't get it" and that they knew what we really needed better than we did, and we didn't need these things. They talked about "language stability" and how extreme the circumstances would have to be to get them to make any change in the Java language, which had undergone no changes since 1.1.
Well, that "extreme circumstance" was serious competition in the form of C#. When Sun claims that they are not copying C# they are correct in the sense that they didn't have to be shown *how* to do these things, but without C# they would have gone on telling us "no" for a very long time.
I have about the same credentials as the parent AC, and I COMPLETELY agree.
I've seen just how happy people were to get their own PCs and declare independence from the priests of the mainframe. I've seen how happy business people were to use Lotus and later Excel to liberate themselves from what we now call the IT department.
Filemaker is in the same category as Excel or the PC itself. Its basic functionality is very empowering to ordinary business people and even consumers. People who aren't programmers or sysadmin types can whip up their own personal or departmental databases and do all sorts of useful things with surprising ease.
The fact that these PC or Excel or Filemaker projects occasionally evolve into something larger and need to be "repotted" is NO EXCUSE for disempowering the front line users.
We NEED a FOSS Filemaker equivalent in our FOSS Office suites.
It depends entirely on the context. Unstructured data is an oxymoron in information theory. Calling it an "incoherent term" is essentially correct. If there is no structure, there is no information. If there is information, there must be structure.
In the database world, on the other hand, it essentially means that the structure is something other than the record/field structure used by databases.
Data mining is sort of in between, and "unstructured" there just means that the particular analysis tools you're using can't parse it, not that it couldn't be parsed.
If I write, "three point one four one five ", your data mining tool would probably call it unstructured, but if you know that the next characters will be "nine", you have proven that it is not unstructured at all.
So the database and data mining terms are weak, though meaningful in the context of their own tools. The information theory definition is the most fundamental in that it depends only on the data itself.
I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well....
So why didn't YOU answer the OP's question instead of merely criticizing other people's answers?
Of course I may have missed your answer because the posts can be read in several different orders. It's possible that you provided a great answer and I just haven't reached it yet. Apologies in advance if that's the case, but so far I haven't seen YOUR answer, though I've seen more than one of your comments on other answers.
Your criticism of this guy's answer, though, makes me think that you're more interested in defending cygwin than in being helpful. The OP wanted to know what problems he might have to deal with if he tried to use cygwin for production, and he didn't say, "please don't mention any problem that might be considered common sense to people with lots of experience", did he?
RMS doesn't want proprietary backends to be able to read the GCC IR, and so we don't ever write it out in a machine-readable format.
Then open source backends won't be able to read it either, but that's apparently okay with RMS, given his priorities. Since only REALLY good commercial software would have a chance against a no-cost incumbent, he is willing to keep great open source alternatives from becoming available in order to keep great commercial alternatives from becoming available.
This is the guy who proclaims that ALL commercial software developers are "unethical".
Open Source to me is about openness: the source is yours to use as you wish, the code can be scripted externally via a command-line interface, it can be incorporated as a library into your own code with minimal effort with a nice API intentionally designed for that purpose, it has a modular architecture that encourages others to compete at the replacement module level without having to rebuild the whole app, etc.--all the ways code can be opened: the least restrictions and the greatest usability.
This is not RMS's agenda. RMS has made his priorities clear. He has never claimed to support the "open source movement", only to be somewhat allied with it to the extent it supports his own anti-commercial software movement.
We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP.
Having heard him speak on many occasions over the years, it's my impression that this characterization is correct and "anything other" applies to more than just programming languages, though not to everything.
I think RMS is right on in many (but not all) of his compaints about IP laws. He's a very bright and skilled guy with a lot of great ideas, but his old-fashioned leftist political philosophies are more "anti" than they are "pro" and handicap the usefulness of his products in some unfortunate ways, and that appears to include GCC.
To the extent that LLVM and other technologies compete with GCC, I'm all for it.
One of the reasons rooms get so hot is that ordinary glass is already blocking a lot of infrared--from getting out. Non-infrared (ordinary visible) light comes through easily and strikes whatever is inside. In doing so, it heats it, so a portion of the visible light is converted to infrared. But, since the glass isn't very permeable to infrared, it can't get out, so the inside space heats up.
This innovation will make it even harder for infrared to get out, but it also reduces the infrared that gets in. So the question is whether the inside heats up more with visible light converted to infrared that can't get out at all, or visible plus some infrared converted to even more infrared that can get out a little bit.
I suppose they've done the experiment, but it's not obvious to me which one would be superior or by how much.
Great, another Michael Moore. "How can I trick people into voting my way?"
A mailbox full of V1@gra spam doesn't make me hate Pfizer. I think Michael Moore is an obnoxious liar, but his propaganda tactics aren't going to get me to change my mind and vote for Bush in protest.
I'm so sick of the emotion-laden nonsense from both sides, when there are genuine, thoughtful, interesting, and useful arguments to be made that might allow for creative solutions. Instead, though, people like this questioner seem to feel that deceit is a better approach for dealing with significant issues.
Yes, I've even heard MS employees complain about this. Unlike Java, C# has operator overloading, which lets you do lots of useful things, but also lets you go overboard, as in this case. Though this is Python, it's using an overloaded "+=" operator to an event handler to an event, the same way that C# does it.
I certainly think
button.Clicked.AddHandler(hello_world)
would be clearer, but the use of delegates in.Net/Mono languages is a nice improvement over Java's interface-based event handling.
I don't care a bit about the malware makers at Real, but what's uncool is people massively buying iPods instead of players that support multiple, vendor-neutral standards.
I want my player to be a big file system in a small box that supports OGG, MP3, FLAC, WAV, SPEEX, and eventually popular video formats, HTML, etc. as well. I want it to be able to record to those formats, too, off the built-in AM/FM radio and from line-in. I want it to support downloadable codec plug-ins.
If it holds "several thousand songs" and I buy that many at a dollar a piece from an online store, I want my wife to be able to play them, too, and if some other maker of these little media boxes comes out with a box that I like more, I want to be able to just drag my files out of the old box and into the new box with no loss of files or file quality.
I'd like to reward manufacturers (such as iRiver) that take this approach by giving them my business, and I wish more people did likewise to drive the competition in open media players.
Holy cow Bat Man! You managed to write that much without really adding anything to what I had already mentioned in the question.
My question was about whether there was a place for "undo" support at the file system level so all access to the file system, even by low level utilities like rm, would have the ability to call on features of the FS itself to support undoing of FS operations. This might obviate the need for custom "recycle bins" or a GUI or of special file recovery utilities (all of which I mentioned already) to obtain this functionality and of most need for the primitive "are you sure...?" hack before a FS operation, which is a classic usability design error.
I did, however, say that there may be issues that I'm overlooking that may make this functionality something that should ALWAYS be at a higher level than the file system. I'd be interested to know if anyone has an informed opinion on the point, especially regarding a FS such as Reiser with extended file metadata.
I don't know enough about the implementation issues to know whether these belong in the FS or should remain in some layer above it, but it always seemed odd to me that "rm" in *nix is unrecoverable unless you custom build something that makes rm an alias for something that isn't rm.
Why not have rm mark the file as being in the special "deleted" directory and have all such files fully recoverable until the moment their space is needed. (If you don't WANT a file to be recoverable, use something like rm --scrub and the file system would intentionally make it unrecoverable.)
Likewise for file renaming. If you rename a batch of files and then realize that you screwed up (perhaps sorted alphabetically instead of numerically, so they're renamed in the wrong order), you just issue an undo command of some sort and the the damage is undone.
Yes, I know this sort of thing can be a feature of your GUI, but I'm wondering why it couldn't just be a standard feature at the command line so even on servers you would have the ability to undo things and wouldn't need that very unhelpful and primitive "Are you sure...?" confirmation hack for so many operations.
With all of this intense solar storm activity we've been seeing lately, how can anyone with a properly raised consciousness doubt that human beings are upsetting the delicate solar environment? In fact, I hear Michael Moore has another documentary coming up which will PROVE that Americans in general, and Republicans especially, can be entertainingly blamed for most of it.
Yes, of course, because the fact that open source has some advantages doesn't negate the risk pointed out in the article. It just means that their are risks both ways.
ANY piece of software that you run on a secure system has the potential of subverting the system. I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right? Well, anyone who has ever seen the entries in an obfuscated C contest and wondered what that code could possibly do ought to be able to see the flaw in that argument. For that matter, anyone who has ever gone over and over HIS OWN CODE looking for a bug and not finding it ought to ask himself, what if it weren't even my own code and I didn't even know that a bug existed?
Closed source is even worse in this respect, though, but at least we know who wrote it, right?
Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.
And I haven't even STARTED on the horrors of trying to run a free mailing list (with or without a confirmation email at signup).
How about this: a legitimate email list would have its own bond, which is a bit larger than normal email bonds. To sign up, you have to send an email to the list subscription address, and when you do, your bond is collected (which you are warned of in advance), even though you are whitelisted.
When the mailing list then sends you messages, if you ever confiscate the mailing list's bond, they cut you off the list. The money the list loses is paid from the money you "lost" when you signed up. (If your bond is bigger than the sign-up bond of the list, it won't send any messages to you, which you are informed of when you sign up.)
Of course, adding this logic will take extra work, but that's no big deal. It's just another protocol to support. It could provide a simple way to charge a subscription to offset costs of running the list, it would tend to keep spam off your mailing list (you both collect someone's bond and blacklist them if they spam), and the above technique would keep people from signing up just to collect a bond from the list owner.
It would be a nice feature for mailing list management software to have.
Slashdot Mirror
Thanks for the great tip. The Latin-1 glyphs repertoire is obsolete--even popular English-language print publications such as Time and Newsweek have NEVER limited themselves to such a pitiful set of characters.
The full text of a 1980s Time Magazine article ought to be completely and correctly displayable anywhere text is displayed on a 21st Century computer, including the command line. For this, we need fonts such as this Gentium as standard. (Of course, we need UTF-8-based shells as standard, too, among other things, and it's starting to happen....)
I can't help thinking that it would end up a better language if you employed your "thinking out loud" essay technique in which people could respond to you and then to one another with ideas that you would study before making the final decisions.
It seems to me that a multipartite (written) discussion forum is the natural extension of an essay by an individual writer when it comes to "searching for truth".
But with Arc you seem to be talking to yourself, which you decry in your essay on essays as likely to lead to the petering out of a project. That or talking to a select handful of colleagues whose opinions you probably trust because they're so similar to your own, which is not so different from talking to yourself.
If you want interesting surprises, why not open the discussion to people who care about things that you and your friends might not have put much thought into?
What are the security implications of your design ideas? Some people don't care about dynamic vs. static typing per se but care a lot about the security issues, some of which might be impacted by this decision. Is there some relatively minor issue that might hamstring automatic decomposition into massive parallelism that you could change now but not later? Are there text models that would dramatically improve your chances of ending up with powerful text processing libraries? And what text model would be most likely to survive the radical changes in computer architectures that we will see over the next century?
You say the world has waited for 45 years for a good Lisp, and you're correct in the sense you intended, but in another sense, of course, the world hasn't waited for Lisp at all. It has left it behind and built up massive ecosystems around its competitors. Those ecosystems are relentlessly growing and create a moving target for what a language is expected to have if it is to be a contender.
Any really successful Lisp will need a lot of time after release to build up such an ecosystem, and the longer it takes to release it, the longer it will take *after* release to become a contender. I think it *will* make a difference whether it is released in 2 years or 10, though even if I'm right, you aren't obligated to do anything about it, of course.
It just seems to me that you'd have a better chance of creating a better overall language if you had an open discussion of the design while change is still easy. You might even get things done sooner by delegating more of the implementation of everything from design comparison prototypes to docs.
That's part of the problem. Paul has a great reputation as an expert in Lisp. He has stated that he is in the middle of building Arc, with all sorts of improvements that many of us want.
--His stated goals for Arc closely match what many of us want, including those that overcome both the shortcomings in non-Lisp languages and in all current Lisps
--He has the technical knowledge of Lisp, including what has and hasn't worked out in practice
--He has the practical experience of creating a large, successful software project using Lisp
--He has the financial resources to do it without need to find corporate sponsors
--He would appear to have the time
--He has the reputation around which to form both a solid team of technical contributors and a passionate community of users
--And he appeared, at least, to have the passion and committment to doing it
With that to contend with, who is going to risk making a big committment of time and resources to starting another Arc with the knowledge that the real Arc could be released at any time?
The only parties I can think of would be large corporations who could put a lot more resources into it than Graham and could own and control the results, but I don't see any that would be interested.
If Graham would give us an update on his plans, it might break the stalemate. If he's not interested, he could say so, making it less risky for others to attempt. He could even post his design notes to help.
If he's still interested, I can't help thinking that Arc would end up better if its design decisions were discussed publicly for a while before it's "too late to change it now". No matter how much of an expert he is, there are those with even more expertise in each of the thousands of little specialty areas that a good, modern, general-purpose language ought to handle well.
No experienced developer is going to blame another one for eventually deciding to drop an exciting project that ended up being too time-consuming. But since we don't know what the story is with Arc, and he has posted "don't even ask for a status report", he has blocked both attempts to help him and attempts to compete with him. Ironically, this approach has ended up "FUDding" the New Lisp market with a vaporware campaign that Microsoft would be proud of.
I enjoy reading Paul's various works, but I'd sure rather have Arc.
After generating considerable excitement about Arc, a lot of discussion, and frequent updates to his Arc website, Paul simply went silent regarding Arc.
Yes, it's true that he'll attend conferences to give keynotes. He'll be billed as the guy behind Arc, but then his talk won't so much as give a status report.
Some have lamented that he has appparently chosen to take the cathedral approach instead of the bazaar with Arc, but I don't see any signs of a cathedral, either. For a language to stand some chance of success these days, it needs a lively developer community. I see no signs that Paul is even interested in hearing from anyone else, much less soliciting help. For the guy who built Yahoo Stores, putting up a discussion board for Arc discussion wouldn't be much of a challenge, but he's never done so.
His site claims to solicit ideas, but that site has been a "cobweb site" for years now. The page on which he was collecting ideas stopped being updated a few weeks after it opened and hasn't been updated for years.
I'd love to have something like Arc. So would a lot of people. It looks as though Paul has lost interest but doesn't want to say so.
Instead, we get interesting essays, which is admittedly more that I deserve, but still less that a lot of us were hoping for.
Yes, the "Dragon Chip" has a special version of Linux, which was designed with a "back door" to allow the Chinese Communist Party to observe what its users are doing.
;-)
Interested in using it? Depending on who you work for, the Chinese might give you a special discount.
Well, while you're at it, why don't you write your own operating system, too? ;-)
It seems likely that we'll soon see high octane media coprocessors as standard equipment on PCs. Before long, all PCs will be "audio workstations", as well as video workstations, photo processors, movie theaters, two-way video telephones, game boxes, etc.--a lot of it simultaneously.
Oh, wait. They already are, but they're just trying to do most of this stuff with an x86 chip. Silly. It's not inconceivable that the future of PCs is a block of powerful media processors where the x86 chip will end up being the "code coprocessor"....
most of the stuff you mentioned had been planned to be included in the next releases of java long long time before C# was born.
No, it wasn't. It's not that Sun had never considered these features. They had considered them and rejected (most of) them.
As long as there was no direct competition, Sun was famous for repeatedly informing developers (like me) who requested most of these things that they "didn't get it" and that they knew what we really needed better than we did, and we didn't need these things. They talked about "language stability" and how extreme the circumstances would have to be to get them to make any change in the Java language, which had undergone no changes since 1.1.
Well, that "extreme circumstance" was serious competition in the form of C#. When Sun claims that they are not copying C# they are correct in the sense that they didn't have to be shown *how* to do these things, but without C# they would have gone on telling us "no" for a very long time.
I have about the same credentials as the parent AC, and I COMPLETELY agree.
I've seen just how happy people were to get their own PCs and declare independence from the priests of the mainframe. I've seen how happy business people were to use Lotus and later Excel to liberate themselves from what we now call the IT department.
Filemaker is in the same category as Excel or the PC itself. Its basic functionality is very empowering to ordinary business people and even consumers. People who aren't programmers or sysadmin types can whip up their own personal or departmental databases and do all sorts of useful things with surprising ease.
The fact that these PC or Excel or Filemaker projects occasionally evolve into something larger and need to be "repotted" is NO EXCUSE for disempowering the front line users.
We NEED a FOSS Filemaker equivalent in our FOSS Office suites.
It depends entirely on the context. Unstructured data is an oxymoron in information theory. Calling it an "incoherent term" is essentially correct. If there is no structure, there is no information. If there is information, there must be structure.
In the database world, on the other hand, it essentially means that the structure is something other than the record/field structure used by databases.
Data mining is sort of in between, and "unstructured" there just means that the particular analysis tools you're using can't parse it, not that it couldn't be parsed.
If I write, "three point one four one five ", your data mining tool would probably call it unstructured, but if you know that the next characters will be "nine", you have proven that it is not unstructured at all.
So the database and data mining terms are weak, though meaningful in the context of their own tools. The information theory definition is the most fundamental in that it depends only on the data itself.
I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well....
So why didn't YOU answer the OP's question instead of merely criticizing other people's answers?
Of course I may have missed your answer because the posts can be read in several different orders. It's possible that you provided a great answer and I just haven't reached it yet. Apologies in advance if that's the case, but so far I haven't seen YOUR answer, though I've seen more than one of your comments on other answers.
Your criticism of this guy's answer, though, makes me think that you're more interested in defending cygwin than in being helpful. The OP wanted to know what problems he might have to deal with if he tried to use cygwin for production, and he didn't say, "please don't mention any problem that might be considered common sense to people with lots of experience", did he?
RMS doesn't want proprietary backends to be able to read the GCC IR, and so we don't ever write it out in a machine-readable format.
Then open source backends won't be able to read it either, but that's apparently okay with RMS, given his priorities. Since only REALLY good commercial software would have a chance against a no-cost incumbent, he is willing to keep great open source alternatives from becoming available in order to keep great commercial alternatives from becoming available.
This is the guy who proclaims that ALL commercial software developers are "unethical".
Open Source to me is about openness: the source is yours to use as you wish, the code can be scripted externally via a command-line interface, it can be incorporated as a library into your own code with minimal effort with a nice API intentionally designed for that purpose, it has a modular architecture that encourages others to compete at the replacement module level without having to rebuild the whole app, etc.--all the ways code can be opened: the least restrictions and the greatest usability.
This is not RMS's agenda. RMS has made his priorities clear. He has never claimed to support the "open source movement", only to be somewhat allied with it to the extent it supports his own anti-commercial software movement.
We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP.
Having heard him speak on many occasions over the years, it's my impression that this characterization is correct and "anything other" applies to more than just programming languages, though not to everything.
I think RMS is right on in many (but not all) of his compaints about IP laws. He's a very bright and skilled guy with a lot of great ideas, but his old-fashioned leftist political philosophies are more "anti" than they are "pro" and handicap the usefulness of his products in some unfortunate ways, and that appears to include GCC.
To the extent that LLVM and other technologies compete with GCC, I'm all for it.
Though I'll be "voting against" Bush myself, I'd give you a "+1 insightful" if I could.
Thanks for the info. +1 informative virtual mod point to you.
Hey, all of you hard core programmers with non-CS degrees, this guy is going to be your boss in a couple of years. You were warned. ;-)
One of the reasons rooms get so hot is that ordinary glass is already blocking a lot of infrared--from getting out. Non-infrared (ordinary visible) light comes through easily and strikes whatever is inside. In doing so, it heats it, so a portion of the visible light is converted to infrared. But, since the glass isn't very permeable to infrared, it can't get out, so the inside space heats up.
This innovation will make it even harder for infrared to get out, but it also reduces the infrared that gets in. So the question is whether the inside heats up more with visible light converted to infrared that can't get out at all, or visible plus some infrared converted to even more infrared that can get out a little bit.
I suppose they've done the experiment, but it's not obvious to me which one would be superior or by how much.
Great, another Michael Moore. "How can I trick people into voting my way?"
A mailbox full of V1@gra spam doesn't make me hate Pfizer. I think Michael Moore is an obnoxious liar, but his propaganda tactics aren't going to get me to change my mind and vote for Bush in protest.
I'm so sick of the emotion-laden nonsense from both sides, when there are genuine, thoughtful, interesting, and useful arguments to be made that might allow for creative solutions. Instead, though, people like this questioner seem to feel that deceit is a better approach for dealing with significant issues.
Yes, I've even heard MS employees complain about this. Unlike Java, C# has operator overloading, which lets you do lots of useful things, but also lets you go overboard, as in this case. Though this is Python, it's using an overloaded "+=" operator to an event handler to an event, the same way that C# does it.
.Net/Mono languages is a nice improvement over Java's interface-based event handling.
I certainly think
button.Clicked.AddHandler(hello_world)
would be clearer, but the use of delegates in
I don't care a bit about the malware makers at Real, but what's uncool is people massively buying iPods instead of players that support multiple, vendor-neutral standards.
I want my player to be a big file system in a small box that supports OGG, MP3, FLAC, WAV, SPEEX, and eventually popular video formats, HTML, etc. as well. I want it to be able to record to those formats, too, off the built-in AM/FM radio and from line-in. I want it to support downloadable codec plug-ins.
If it holds "several thousand songs" and I buy that many at a dollar a piece from an online store, I want my wife to be able to play them, too, and if some other maker of these little media boxes comes out with a box that I like more, I want to be able to just drag my files out of the old box and into the new box with no loss of files or file quality.
I'd like to reward manufacturers (such as iRiver) that take this approach by giving them my business, and I wish more people did likewise to drive the competition in open media players.
Thanks.
Holy cow Bat Man! You managed to write that much without really adding anything to what I had already mentioned in the question.
My question was about whether there was a place for "undo" support at the file system level so all access to the file system, even by low level utilities like rm, would have the ability to call on features of the FS itself to support undoing of FS operations. This might obviate the need for custom "recycle bins" or a GUI or of special file recovery utilities (all of which I mentioned already) to obtain this functionality and of most need for the primitive "are you sure...?" hack before a FS operation, which is a classic usability design error.
I did, however, say that there may be issues that I'm overlooking that may make this functionality something that should ALWAYS be at a higher level than the file system. I'd be interested to know if anyone has an informed opinion on the point, especially regarding a FS such as Reiser with extended file metadata.
I don't know enough about the implementation issues to know whether these belong in the FS or should remain in some layer above it, but it always seemed odd to me that "rm" in *nix is unrecoverable unless you custom build something that makes rm an alias for something that isn't rm.
Why not have rm mark the file as being in the special "deleted" directory and have all such files fully recoverable until the moment their space is needed. (If you don't WANT a file to be recoverable, use something like rm --scrub and the file system would intentionally make it unrecoverable.)
Likewise for file renaming. If you rename a batch of files and then realize that you screwed up (perhaps sorted alphabetically instead of numerically, so they're renamed in the wrong order), you just issue an undo command of some sort and the the damage is undone.
Yes, I know this sort of thing can be a feature of your GUI, but I'm wondering why it couldn't just be a standard feature at the command line so even on servers you would have the ability to undo things and wouldn't need that very unhelpful and primitive "Are you sure...?" confirmation hack for so many operations.
With all of this intense solar storm activity we've been seeing lately, how can anyone with a properly raised consciousness doubt that human beings are upsetting the delicate solar environment? In fact, I hear Michael Moore has another documentary coming up which will PROVE that Americans in general, and Republicans especially, can be entertainingly blamed for most of it.
do we even need another comment on this story?
Yes, of course, because the fact that open source has some advantages doesn't negate the risk pointed out in the article. It just means that their are risks both ways.
ANY piece of software that you run on a secure system has the potential of subverting the system. I think open source does create the illusion that it couldn't contain hidden malware because where could it hide in open source, right? Well, anyone who has ever seen the entries in an obfuscated C contest and wondered what that code could possibly do ought to be able to see the flaw in that argument. For that matter, anyone who has ever gone over and over HIS OWN CODE looking for a bug and not finding it ought to ask himself, what if it weren't even my own code and I didn't even know that a bug existed?
Closed source is even worse in this respect, though, but at least we know who wrote it, right?
Well, I think that's yet another illusion. Think disgruntled employees being paid by Bad Guys to insert a bit of code.... You may trust the company that made your software, but how can you possibly trust every one of their employees? And once it's in, since it's trusted it could be there for years.
And I haven't even STARTED on the horrors of trying to run a free mailing list (with or without a confirmation email at signup).
How about this: a legitimate email list would have its own bond, which is a bit larger than normal email bonds. To sign up, you have to send an email to the list subscription address, and when you do, your bond is collected (which you are warned of in advance), even though you are whitelisted.
When the mailing list then sends you messages, if you ever confiscate the mailing list's bond, they cut you off the list. The money the list loses is paid from the money you "lost" when you signed up. (If your bond is bigger than the sign-up bond of the list, it won't send any messages to you, which you are informed of when you sign up.)
Of course, adding this logic will take extra work, but that's no big deal. It's just another protocol to support. It could provide a simple way to charge a subscription to offset costs of running the list, it would tend to keep spam off your mailing list (you both collect someone's bond and blacklist them if they spam), and the above technique would keep people from signing up just to collect a bond from the list owner.
It would be a nice feature for mailing list management software to have.