Yes, certainly, this is the way to go. It is convenient to treat corporations and people the same in many matters, but they are fundamentally different from people and should be recognized as such. As you said, corporations should have no right to free speech, etc.
heck yeah the constitution guarantees the right to overthrow the government through armed struggle. Or at least, the ability to own arms so that the government might be overthrown if necessary -- I guess that the act of overthrowing the government itself is still illegal.
> To be a skilled generalist programmer, you really need at least familiarity with every layer below the one you're using (this is why many Computer Science desgrees include at least one simple assembly class and one introductory electronics class).
I probably don't have as much experience as most people posting on this thread, but I feel that you don't have to always go beneath the abstractions, and your post has helped me to clarify why:
We really don't have to know introductory electronics in order to program computers.
I conjecture that you should have to know less and less about the layers below you as they become more and more distant. If this is not the case currently, this is because we as a human race have not designed sufficiently good abstractions yet (b/c either the field is young, or it changes too fast).
There might be some abstractions way down deep that you have to know anyhow (if quantum physics gives us the ability to tell when someone is listening to your transmission, I guess all of us would be interested in that, and there's no way to avoid it). But this should be exceedingly rare.
I think the number of leaks that you need to know about decreases with your distance to the leak. If that is not the case now in software, I think it is because the newness (and constant change) in the field, not because it is theoretically impossible.
Bravo to Washington, Rochester, Toronto, Cornell, Columbia, Ohio State and especially MIT! As I was under the impression that universites were chartered to increase public knowledge or something like that, I am surprised that more universites aren't jumping at this opportunity to fulfill their mandate.
I hope that anyone thinking about donating to a university takes this into account. Donate to one that will most do the most good for the public (it seems right now these are Washington, Rochester, Toronto, Cornell, Columbia, Ohio State and MIT).
My guess is that the answer is to keep working within the current system, attempting to vote into office folks who will restrain this before it becomes unstoppable. At this point (unless the conspiracy theorists are right) democracy still functions when the public feels strongly about something, and when the machine deigns to put that something on the agenda (and items can still be forced onto the agenda from grassroots).
Simply trying to get our views out to others until there is a mass of public opinion which sees the dire long term consequences of these things seems like the best course of action to me, although as I've said, I'm not sure.
Also, I don't think the outlook is necessarily as bad as it seems. At times in the past this country lived with less civil rights than it has now, and yet we got better. And other countries around the world have progress from less to move civil rights. The only thing to fear is that technology will change the dynamics of things in such a way that this will become impossible. But who knows what technology will do? This suggests a second course of action; favor working on technologies that seem like they would help liberties, rather than oppression.
Which these are is uncertain. My current guess is that information processing and collaboration technologies may help citizens organize to watch government more effectively than they help government fight citizens. Many people these days would probably agree that government is overreaching with the libraries thing, the problem is that no one has time to keep track of more than a few issues. Superior information processing and collaboration may help us educate ourselves better, making it easier for a critical mass of citizens to come together on an issue.
what i want is a low priced version of the device that tracks the 3d position of each of your fingers (maybe you have to wear caps on the tips of the ringers, or rings, or something like that).
I'm sure it'll have a few uses up front but the real uses will come when we start to experiement with it.
with that many degrees of freedom we could make typing much faster. what's more, we could develop entirely new ways to communicate with the command line, and perhaps ultimately faster ways to communicate with other humans.
i haven't read much else of what he's written, but I liked that talk a lot. I was interested to here his views on postmodernism, because I don't know much about it. Also, it definitely revealed a little bit of the spirit behind Perl. Parts of Larry Wall's thought pattern on Perl that I didn't know about before.
I do agree that the talk could cut many parts out and become more readable, though.
Below I've appended some parts of the talk that I think are real gems, although I'm not sure if they'll make as much sense out of context. But hopefully this will support my contention that the talk does contain "valuable insight" into the way that Larry Wall came up with/comes up with Perl.
``Well, of course not,'' I replied, ``all these things go together, but some disciplines change at different rates. The reason I'm giving this talk on Wednesday is because I think there's still a big streak of Modernism running through the middle of computer science, and a lot of people are out of touch with their culture. On the other hand, I'm not really out to fight Modernism, since postmodernism includes Modernism as just another valid source of ideas. In fact, Perl contains lots of modern ideas from computer science. Along with all the rest of the ideas in there.
Heidi said, ``You wanna know something really funny. In my IMP class, our class slogan is, 'There's more than one way to do it.'''
More than that, I combined these cool features in a way that makes sense to me as a postmodern linguist, not in a way that makes sense to the typical Modernistic computer scientist. Recall that the essence of Modernism is to take one cool idea and drive it into the ground. It's not difficult to look at computer languages and see which ones are trying to be modern by driving something into the ground. Think about Lisp, and parentheses. Think about Forth, and stack code. Think about Prolog, and backtracking. Think about Smalltalk, and objects. (Or if you don't want to think about Smalltalk, think about Java, and objects.)
Think about Python, and whitespace. Hi, Guido.
Or think about shell programming, and reductionism. How many times have we heard the mantra that a program should do one thing and do it well?
Well...Perl does one thing, and does it well. What it does well is to integrate all its features into one language. More importantly, it does this without making them all look like each other. Ducts shouldn't look like girders, and girders shouldn't look like ducts. Neither of those should look like water pipes, and it's really important that water pipes not look like sewer pipes. Or smell like sewer pipes. Modernism says that we should make all these things look the same (and preferably invisible). Postmodernism says it's okay for them to stick out, and to look different, because a duct ought to look like a duct, and a sewer pipe ought to look like a sewer pipe, and hammer ought to look like a hammer, and a telephone ought to look like either a telephone, or a Star Trek communicator. Things that are different should look different.
Modernism oversimplifies. Modernism puts the focus squarely on the hammer and the nail.
In contrast, postmodernism puts the focus back onto the carpenter.
Fortunately, I am not Perl. Perl was my servant before it was anyone else's, so I taught Perl to be a better servant than I could ever teach myself to be. Perl is like the perfect butler. Whatever you ask Perl to do, it says ``Very good, sir,'' or ``Very good, madam.'' Only occasionally does Perl give you a stiff upper lip, or say ``Tsk, tsk.'' But if you ask Perl its opinion, it will advise you on matters of taste. ``I'm sorry sir, but bareword 'foo' is not allowed while 'strict subs' is in use.''
Contrast that with the Modern idea of how a computer should behave. It's really rather patronizing: ``I'm sorry Dave. I can't allow you to do that.''
The trouble with having a submissive servant is that it puts the burden back on you to make the decisions. Come to think of it, that's the problem with having a submissive wife too. My wife is very submissive. She's always saying, ``I submit this problem to you because I don't want to decide it.''
Many modern computer languages aspire to be minimalistic. They either succeed in being minimalistic, in which case they're relatively useless, or they don't succeed in being truly minimalistic, in which case you can actually solve real problems with them. A number of languages give lip service to the idea of minimalism, but merely sweep the complexity of the problem under the carpet of the programmer. C is a minimalistic language, but only if you don't count all the libraries that are necessary to use it usefully. C++ is obviously not trying to be minimalistic. Unix is considered by some to be a minimalistic operating system, but the fact of the matter is that if you think of Unix as a programming language, it's far richer than even Perl. Perl is, by and large, a digested and simplified version of Unix. Perl is the Cliff Notes of Unix.
>> the actual root of everything which is programming and this cannot be denied
> Programming is not the goal, nor the root, of computer science. Programming is the means, not the ends.
I think there is a legitimate disagreement here (the authors of the papers know that there is another point of view here). I don't know on which side I stand. I tend to think in terms of programs myself, but I can't decide if that is a bad thing or a good one.
As for "the actual root of architecture is trowling cement onto bricks", in some sense it is. But more so for programming; you have to look at context. Some reasons why "architecture" and "cement laying" are less distinct in programming:
1) the "bricklayers" and the "architects" of programming must have similar training and are often considered to be in the same profession
2) programs are somewhat malleable and so it is possible for the blueprints to change in the middle or to become muddled with the program itself
> Once you have a secure financial base, go ahead and explore the world, get married, etc. Do whatever your heart desires, but do not get started without some money saved away for your retirement, or you will be screwed when you're older.
I've heard it argued (and I tend to agree, although I don't have first hand experience, and I am not training in finance) that you are better off keeping money in mid-term accounts so that you can use it to pay off loans for cars and houses faster. You will be losing more interest as a debtor than you will be gaining as an investor, so paying off future loans quick should take priority over saving for retirement.
As for whether you should save up for those things or tour the world, though, I am conflicted. Sure, you need to save. But you only live once, and if there are plenty of people who tour the world young and don't starve later on, and fewer who do it when they are older, then that should be a factor that you consider.
this is a duplicate story, but I'm only mentioning that to point out that I like duplicate stories. It takes away that "oh no i didn't check slashdot for a week, i wonder what i missed" feeling.
> Try telling them this; The kernel developers would laugh in your face. They've said before (Linus Especially) that they're not going to use an inferior tool just because it's free.
I'm not telling them because I don't think I will convince Linus. Some others on lkml already feel BK is a bad idea, and they haven't changed his mind. It's still worth it to post my views here to try to convince others.
> Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.
Not being a kernel hacker, I don't know how much of a second-class citizen a non-BK user might become. If the others in the group really make it a priority to make things easy & inviting for non-BK users, I expect they can do it. On the other hand, while I don't follow lkml, Slashdot user fv believes that Linus is subtly encouraging BK.
Software with non-restrictive licenses should be used for important free software projects even when it is not seemingly the best tool for the job.
A license like this makes things harder for someone who wants to hack on the kernel but who is prohibited by BitKeeper from getting the source the way the rest of the kernel team does.
the problem is not with BitKeeper's putting weird terms on a license for a product that they're giving away.
the problem is that important (free?) software is being developed under that license. Fault is with the kernel developers for using the restricted tool, not with BitKeeper for making the restrictions.
This may make it harder for people who can't adhere to BitKeeper's license to be truly a part of the kernel team (as I understand it, they have to get their source from a third party, which may be very slightly out of date, and then email their code to Linus, whereas others checkout and submit their code through the system.)
As PhxBlue said, "And consider that an internet government would be at least as crooked as any other - and who would it answer to when it ran amok with whatever powers it was given?"
The other reason is that there is currently no (really practical) way for a citizen to be a citizen of cyberspace without also being a citizen of some other country too. Hence there can't be any citizens of cyberspace who are not also vulnerable to the laws of some nation.
i think $10,000 is too much (the fee should be comparable to the currently proposed fees, around $1500 or so), but the basic idea is just what we need! i really hope this gets adopted. i am going to write my congresspeople and try and get the word out on this one.
> What the applicant would do to avoid complete rejection (and avoid paying your added rejection fee) is just to modify the claims so as to avoid all prior art...
you mean avoid mentioning prior art, right? isn't this what happens now (for instance, when patenting linking, i assume the patenter didn't mention that linking was invented by someone else before them) anyway?
>The problem with your scheme is that it chills potential innovation, which is what the original patent idea was all about--grant a monopoly for a few years in return for disclosure of good stuff, heretofore unknown.
innovation is chilled by patent application fees anyhow. if there has to be a certain amount of fees, why not charge those fees for rejection rather for all applications? since we had to have some fees anyhow, this way we get to give an incentive to people not to make bogus claims
>The PTO itself isn't rejecting the application, it's the examiners who examine the patents that reject it, and they don't see a cent of the money charged for maintenance.
I think the PTO managers will do a good job of transmitting the incentive signals that the PTO itself receives to the employees.
> Furthermore, your idea is flawed. The examination process is there so that prior art can be found.
right now it is, but that doesn't mean that that is the best system. i think what's being proposed is a better system. if we really want the patent office to search for prior art as a service to inventors before the main application, (and i see no reason why this shouldn't be privatized), then it could be separate from the actual application process (in which a rejection fee is charged if prior art is found).
> Heaping on another deposit (the original having been forfeit by that application becoming abandoned) just multiplies the risk, unneccessarily IMHO.
you are arguing that the total money at stake for the applicant should be low. however, the idea of charging a rejection fee should be evaluated against the idea of charging a straight application fee, not against charging no additional fee; the important thing is that the rejection fee idea is better than an application fee, so some application fees should be lessened and a rejection fee should be added instead.
Slashdot Mirror
Yes, certainly, this is the way to go. It is convenient to treat corporations and people the same in many matters, but they are fundamentally different from people and should be recognized as such. As you said, corporations should have no right to free speech, etc.
heck yeah the constitution guarantees the right to overthrow the government through armed struggle. Or at least, the ability to own arms so that the government might be overthrown if necessary -- I guess that the act of overthrowing the government itself is still illegal.
See the posts by jgalun and seanadams.com.
> To be a skilled generalist programmer, you really need at least familiarity with every layer below the one you're using (this is why many Computer Science desgrees include at least one simple assembly class and one introductory electronics class).
I probably don't have as much experience as most people posting on this thread, but I feel that you don't have to always go beneath the abstractions, and your post has helped me to clarify why:
We really don't have to know introductory electronics in order to program computers.
I conjecture that you should have to know less and less about the layers below you as they become more and more distant. If this is not the case currently, this is because we as a human race have not designed sufficiently good abstractions yet (b/c either the field is young, or it changes too fast).
There might be some abstractions way down deep that you have to know anyhow (if quantum physics gives us the ability to tell when someone is listening to your transmission, I guess all of us would be interested in that, and there's no way to avoid it). But this should be exceedingly rare.
I think the number of leaks that you need to know about decreases with your distance to the leak. If that is not the case now in software, I think it is because the newness (and constant change) in the field, not because it is theoretically impossible.
yeah, i agree with this post. this is a good law.
i disagree with the submitter's take.
Bravo to Washington, Rochester, Toronto, Cornell, Columbia, Ohio State and especially MIT! As I was under the impression that universites were chartered to increase public knowledge or something like that, I am surprised that more universites aren't jumping at this opportunity to fulfill their mandate.
I hope that anyone thinking about donating to a university takes this into account. Donate to one that will most do the most good for the public (it seems right now these are Washington, Rochester, Toronto, Cornell, Columbia, Ohio State and MIT).
> Unfortunately, I don't see a quick solution.
> Now what?
I feel the same lack of power.
My guess is that the answer is to keep working within the current system, attempting to vote into office folks who will restrain this before it becomes unstoppable. At this point (unless the conspiracy theorists are right) democracy still functions when the public feels strongly about something, and when the machine deigns to put that something on the agenda (and items can still be forced onto the agenda from grassroots).
Simply trying to get our views out to others until there is a mass of public opinion which sees the dire long term consequences of these things seems like the best course of action to me, although as I've said, I'm not sure.
Also, I don't think the outlook is necessarily as bad as it seems. At times in the past this country lived with less civil rights than it has now, and yet we got better. And other countries around the world have progress from less to move civil rights. The only thing to fear is that technology will change the dynamics of things in such a way that this will become impossible. But who knows what technology will do? This suggests a second course of action; favor working on technologies that seem like they would help liberties, rather than oppression.
Which these are is uncertain. My current guess is that information processing and collaboration technologies may help citizens organize to watch government more effectively than they help government fight citizens. Many people these days would probably agree that government is overreaching with the libraries thing, the problem is that no one has time to keep track of more than a few issues. Superior information processing and collaboration may help us educate ourselves better, making it easier for a critical mass of citizens to come together on an issue.
cool, thanks. b/c of ICANN's latest move, i just put openNIC first in my /etc/resolv.conf
what i want is a low priced version of the device that tracks the 3d position of each of your fingers (maybe you have to wear caps on the tips of the ringers, or rings, or something like that).
I'm sure it'll have a few uses up front but the real uses will come when we start to experiement with it.
with that many degrees of freedom we could make typing much faster. what's more, we could develop entirely new ways to communicate with the command line, and perhaps ultimately faster ways to communicate with other humans.
I do agree that the talk could cut many parts out and become more readable, though.
Below I've appended some parts of the talk that I think are real gems, although I'm not sure if they'll make as much sense out of context. But hopefully this will support my contention that the talk does contain "valuable insight" into the way that Larry Wall came up with/comes up with Perl.
``Well, of course not,'' I replied, ``all these things go together, but some disciplines change at different rates. The reason I'm giving this talk on Wednesday is because I think there's still a big streak of Modernism running through the middle of computer science, and a lot of people are out of touch with their culture. On the other hand, I'm not really out to fight Modernism, since postmodernism includes Modernism as just another valid source of ideas. In fact, Perl contains lots of modern ideas from computer science. Along with all the rest of the ideas in there.
Heidi said, ``You wanna know something really funny. In my IMP class, our class slogan is, 'There's more than one way to do it.'''
More than that, I combined these cool features in a way that makes sense to me as a postmodern linguist, not in a way that makes sense to the typical Modernistic computer scientist. Recall that the essence of Modernism is to take one cool idea and drive it into the ground. It's not difficult to look at computer languages and see which ones are trying to be modern by driving something into the ground. Think about Lisp, and parentheses. Think about Forth, and stack code. Think about Prolog, and backtracking. Think about Smalltalk, and objects. (Or if you don't want to think about Smalltalk, think about Java, and objects.)
Think about Python, and whitespace. Hi, Guido.
Or think about shell programming, and reductionism. How many times have we heard the mantra that a program should do one thing and do it well?
Well...Perl does one thing, and does it well. What it does well is to integrate all its features into one language. More importantly, it does this without making them all look like each other. Ducts shouldn't look like girders, and girders shouldn't look like ducts. Neither of those should look like water pipes, and it's really important that water pipes not look like sewer pipes. Or smell like sewer pipes. Modernism says that we should make all these things look the same (and preferably invisible). Postmodernism says it's okay for them to stick out, and to look different, because a duct ought to look like a duct, and a sewer pipe ought to look like a sewer pipe, and hammer ought to look like a hammer, and a telephone ought to look like either a telephone, or a Star Trek communicator. Things that are different should look different.
Modernism oversimplifies. Modernism puts the focus squarely on the hammer and the nail.
In contrast, postmodernism puts the focus back onto the carpenter.
Fortunately, I am not Perl. Perl was my servant before it was anyone else's, so I taught Perl to be a better servant than I could ever teach myself to be. Perl is like the perfect butler. Whatever you ask Perl to do, it says ``Very good, sir,'' or ``Very good, madam.'' Only occasionally does Perl give you a stiff upper lip, or say ``Tsk, tsk.'' But if you ask Perl its opinion, it will advise you on matters of taste. ``I'm sorry sir, but bareword 'foo' is not allowed while 'strict subs' is in use.''
Contrast that with the Modern idea of how a computer should behave. It's really rather patronizing: ``I'm sorry Dave. I can't allow you to do that.''
The trouble with having a submissive servant is that it puts the burden back on you to make the decisions. Come to think of it, that's the problem with having a submissive wife too. My wife is very submissive. She's always saying, ``I submit this problem to you because I don't want to decide it.''
Many modern computer languages aspire to be minimalistic. They either succeed in being minimalistic, in which case they're relatively useless, or they don't succeed in being truly minimalistic, in which case you can actually solve real problems with them. A number of languages give lip service to the idea of minimalism, but merely sweep the complexity of the problem under the carpet of the programmer. C is a minimalistic language, but only if you don't count all the libraries that are necessary to use it usefully. C++ is obviously not trying to be minimalistic. Unix is considered by some to be a minimalistic operating system, but the fact of the matter is that if you think of Unix as a programming language, it's far richer than even Perl. Perl is, by and large, a digested and simplified version of Unix. Perl is the Cliff Notes of Unix.
>> the actual root of everything which is programming and this cannot be denied
> Programming is not the goal, nor the root, of computer science. Programming is the means, not the ends.
I think there is a legitimate disagreement here (the authors of the papers know that there is another point of view here). I don't know on which side I stand. I tend to think in terms of programs myself, but I can't decide if that is a bad thing or a good one.
As for "the actual root of architecture is trowling cement onto bricks", in some sense it is. But more so for programming; you have to look at context. Some reasons why "architecture" and "cement laying" are less distinct in programming:
1) the "bricklayers" and the "architects" of programming must have similar training and are often considered to be in the same profession
2) programs are somewhat malleable and so it is possible for the blueprints to change in the middle or to become muddled with the program itself
Also, wikis in general are group authorship, although most don't aim to produce books. See the Portland Pattern Repository's WikiWikiWeb for an example.
neat project, why not donate a small amount to help them along? I gave $10.
> Once you have a secure financial base, go ahead and explore the world, get married, etc. Do whatever your heart desires, but do not get started without some money saved away for your retirement, or you will be screwed when you're older.
I've heard it argued (and I tend to agree, although I don't have first hand experience, and I am not training in finance) that you are better off keeping money in mid-term accounts so that you can use it to pay off loans for cars and houses faster. You will be losing more interest as a debtor than you will be gaining as an investor, so paying off future loans quick should take priority over saving for retirement.
As for whether you should save up for those things or tour the world, though, I am conflicted. Sure, you need to save. But you only live once, and if there are plenty of people who tour the world young and don't starve later on, and fewer who do it when they are older, then that should be a factor that you consider.
this is a duplicate story, but I'm only mentioning that to point out that I like duplicate stories. It takes away that "oh no i didn't check slashdot for a week, i wonder what i missed" feeling.
true enough, the convincing others part would have more of an effect on other projects than on the kernel.
I'm not telling them because I don't think I will convince Linus. Some others on lkml already feel BK is a bad idea, and they haven't changed his mind. It's still worth it to post my views here to try to convince others.
> Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.
Not being a kernel hacker, I don't know how much of a second-class citizen a non-BK user might become. If the others in the group really make it a priority to make things easy & inviting for non-BK users, I expect they can do it. On the other hand, while I don't follow lkml, Slashdot user fv believes that Linus is subtly encouraging BK.
(link is copied from fv's slashdot post)
here, here! well said.
Software with non-restrictive licenses should be used for important free software projects even when it is not seemingly the best tool for the job.
A license like this makes things harder for someone who wants to hack on the kernel but who is prohibited by BitKeeper from getting the source the way the rest of the kernel team does.
the problem is not with BitKeeper's putting weird terms on a license for a product that they're giving away.
the problem is that important (free?) software is being developed under that license. Fault is with the kernel developers for using the restricted tool, not with BitKeeper for making the restrictions.
This may make it harder for people who can't adhere to BitKeeper's license to be truly a part of the kernel team (as I understand it, they have to get their source from a third party, which may be very slightly out of date, and then email their code to Linus, whereas others checkout and submit their code through the system.)
As PhxBlue said, "And consider that an internet government would be at least as crooked as any other - and who would it answer to when it ran amok with whatever powers it was given?"
The other reason is that there is currently no (really practical) way for a citizen to be a citizen of cyberspace without also being a citizen of some other country too. Hence there can't be any citizens of cyberspace who are not also vulnerable to the laws of some nation.
awesome!
wonderful idea!
i think $10,000 is too much (the fee should be comparable to the currently proposed fees, around $1500 or so), but the basic idea is just what we need! i really hope this gets adopted. i am going to write my congresspeople and try and get the word out on this one.
> What the applicant would do to avoid complete rejection (and avoid paying your added rejection fee) is just to modify the claims so as to avoid all prior art...
you mean avoid mentioning prior art, right? isn't this what happens now (for instance, when patenting linking, i assume the patenter didn't mention that linking was invented by someone else before them) anyway?
>The problem with your scheme is that it chills potential innovation, which is what the original patent idea was all about--grant a monopoly for a few years in return for disclosure of good stuff, heretofore unknown.
innovation is chilled by patent application fees anyhow. if there has to be a certain amount of fees, why not charge those fees for rejection rather for all applications? since we had to have some fees anyhow, this way we get to give an incentive to people not to make bogus claims
>The PTO itself isn't rejecting the application, it's the examiners who examine the patents that reject it, and they don't see a cent of the money charged for maintenance.
I think the PTO managers will do a good job of transmitting the incentive signals that the PTO itself receives to the employees.
> Furthermore, your idea is flawed. The examination process is there so that prior art can be found.
right now it is, but that doesn't mean that that is the best system. i think what's being proposed is a better system. if we really want the patent office to search for prior art as a service to inventors before the main application, (and i see no reason why this shouldn't be privatized), then it could be separate from the actual application process (in which a rejection fee is charged if prior art is found).
> Heaping on another deposit (the original having been forfeit by that application becoming abandoned) just multiplies the risk, unneccessarily IMHO.
you are arguing that the total money at stake for the applicant should be low. however, the idea of charging a rejection fee should be evaluated against the idea of charging a straight application fee, not against charging no additional fee; the important thing is that the rejection fee idea is better than an application fee, so some application fees should be lessened and a rejection fee should be added instead.