Rather, it's ``... they have no right to distribute "stuff that they [...] own" along with GPLd stuff they don't own. They can do whatever they like with their own stuff, but they can't distribute it comingled with GPLd code unless they license it under the GPL. Guess I didn't make myself clear on that originally.
I know what you're saying, but the GPL also imposes a burden of support on them: _having_ innocently distributed their own proprietary code (after someone else allegedly put it in), they are required to continue making the source available. This is precisely what they are doing.
Their precise actions on this FTP site would be highly commendable if they were prosecuting only the company responsible for the violation, and promising to license under the GPL as soon as reasonably possible (and not doing so many OTHER things...) -- after all, nobody could reasonably demand that they GPL their software in the middle of a legal battle (thereby automatically losing the battle). Therefore, there's nothing wrong with the FTP site; it's their other actions that are wrong.
The problem is that it's a catch-22; they violate the GPL either way, but they way they've chosen they also support their customers. I suspect that a judge would agree. Of course, I again note that there's a third way: to release their code under GPL; but the court would definitely frown upon that (in the sense that it would enforce no punishment on the defendant).
Another issue with SCO's efforts to license ``their'' code is IBM's patents. It's quite probable that the code in question (whatever it may turn out to be) infringes upon one or more of IBM's patents.
So you haven't read anything about them, huh? Okay, take a break now; go look them up. Reply to my message after you've confirmed that three of the four patents couldn't possibly apply to the kernel (they're user-interface-specific), and the remaining one doesn't apply to any of the specific claims they've made (although I'll admit that it might apply to something they're hiding, or something otherwise in the Linux kernel).
It's not illegal to use a patented idea; it's merely prosecutable. If IBM ignores it, it doesn't matter. When they stop ignoring it, it suddenly matters.
That would be the only way that they could get away with distributing the kernel: if it's all GPLd. So, SCO believes that no-one needs an SCO license for the 2.4.13 (I think it was) kernel, or SCO believes that it is violating various copyrights, or SCO is cynically engaging in barratry.
OR, SCO wishes to legally punish someone who (unbeknownst to them) inserted their copyrighted code into the kernel, but SCO also wishes to honor their obligations to customers as documented in the GPL.
Which one of the four do you think SCO will present to the judge? Do you have any reason for him to disbelieve the one they'll obviously choose?
I do -- but it STARTS by looking at all the obviously wrong things they've done, and ends at the catch-22 technicalities like this, AFTER their bad faith has been proven.
Yes, but. Just a couple days ago I went to their ftp site and downloaded a 2.4 kernel. I am not, and never have been, a SCO customer.
Yet their FTP site says that it's only for SCO customers; they explicitly put it up for that purpose, and they explicitly express a licence to their old customers to download that code. This doesn't mean that you're doing anything wrong (in particular because both you and I know that SCO's case is preposterous), but it does mean that you're not the licensed audience.
They are deliberately distributing the kernel, knowing that stuff they claim to own is in there.
First, you can't claim that they have no right to distribute "stuff that they [...] own".
Second, much of the "stuff that they claim to own" was added to a later version of the kernel.
Unless they are distributing it under the GPL, they have no right to distribute it at all. Thus, they are either:
Actually, they're attempting to meet their contractual obligations to their customers, which involves (according to their claims, for the sake of argument):
1. Distributing Linux's legally GPLed code. 2. Distributing their code which someone illegally copied into the GPLed code, but which isn't covered by ANY valid licence. 3. Conveying a licence to their customers to make getting, installing, and using that illegally copied code legal.
According to SCO, by no fault of their own someone else inserted vast amounts of their code into Linux, from which SCO (like many other companies) gained customers and revenue; if this were true, SCO shouldn't be forced to stop supporting their customers simply in order to stop someone else's infringement of their rights.
Now, setting aside all those "for the sake of argument" claims, we can see that SCO's claims are, by and large, baloney; and their actions in hiding their code are cowardly, indicative of something to hide (duh), not conducive to allowing good-willed people to reduce SCO's damages, and useless for prosecution of their case. However, the action of continuing to provide support for their old product is correct and valid.
The one thing which might trip them up with respect to the GPL is if they've violated the GPL, but I'm not sure that they have -- they are, after all, providing all the source as the GPL demands (and you're telling them to violate the GPL by stopping!), and their current court actions are,/prima facia/, legitimate attempts to stop abuses of their own properly owned copyrights and/or contract violations. Their blabbering and preposterous press releases are, of course and unfortunately, not applicable to the GPL.
Keep in mind that I'm not saying they're right; I'm only saying that THIS defence against them is useless. Switch! See also Eric's analysis of their code, and LWN.net's analysis of that, pointing out that Eric was probably wrong and SCO was probably right, even though it doesn't help their court case. It's important to tell the truth and do the right thing, even when it makes bad people look better.
Actually, I've read nothing but the magazine articles and interviews about this half-baked ``theory''. I'm inclined to believe that what SCO's shysters are proposing is radically different than what is being reported.
As far as I can tell, you're correct. It looks to me like they're not claiming the GPL itself is invalid; rather, they're claiming that the GPL doesn't apply to that code _because_ they own the copyright and they didn't apply it.
Yup, that's essentially what Enron was about. And it was a good idea, too.
But this whole scheme is a waste of time. You can do it right/now/. Just buy+install+have_inspected a generator of some kind (solar's probably the easiest), call the power company and switch your billing to demand-based, so that they charge you a LOT during peak hours and very little during off-peak hours. Turn the generator on... And boom, they pay you for what you produce during peak hours (which happen, of course, to be when the sun's out), and you pay them for what you consume while the sun's unavailable (which is almost always off-peak).
The only problem is that they won't ever write you a check; you can only cancel your own bill. But the incentive is still pretty strong!
(But not strong enough for me to want to put all that work and tens of thousands of dollars into a solar system -- my bills aren't that high yet.)
Burning gasoline or propane and feeding the hot gases through the thing directly might be workable but probably isn't that fuel efficient. Or we'd have a Tesla engine in every car today since it's more or less vibration free compared to a regular piston engine.
You haven't studied the topic.
Steam powered turbines have their uses, and even with the boilers can compete in their own areas. But turbines ARE some of the lightest, most efficient engines we make; that's why they're used both in aircraft and generators (and in some tanks).
Or we'd have a Tesla engine in every car today since it's more or less vibration free compared to a regular piston engine.
The real reason is that tesla turbines, like regular turbines, run at speeds well in excess of 10,000 RPM. Cars don't need that kind of speed, and the parts needed to gear it down wear out too fast.
The quasiturbine, on the other hand, runs at a quite carlike speed, and is pretty much vibration-free. But unlike the tesla turbine, you can't build a working quasiturbine out of paper.
It only takes three bonehead gamblers to make up for one counter's winnings.
For a counter who's working as small-time as the boneheads, yes. Those are harmless, and in fact most casinos will simply gently let them know that they're watching (unless they get too persistent; not only do the casinos not want to take sustained losses, they also don't want to risk missing the professional operating off the simple counter). The losses the casinos receive from small-time counting are more than offset by the "boneheads" drawn in by the sight of winning.
But counters aren't all small-time. A team working counting WILL take home 150% of their sizable investment in a day, and can be very subtle at it. There's a group at MIT that used to do that, and wrote it up. If it's profitable and allowed, someone will make a job of it, and casinos simply CAN'T allow that kind of losses all day every day. So they make it impossible to do it regularly, and they're well within their rights.
Casino management just can't stand the thought of anyone taking money based on skill:
Sure they can. They pay people to do that -- cooks, mechanics, architects, engineers... And they expect people to use their skills to earn the money that they spend at the casino.
it's got to be a gamble, all the time, in the house's favor.
Yup. That's why it's a casino; that's why it's there. In fact, that's why it's called "gambling" instead of "work". If you want to earn money by using skill, go use that skill to do something useful for someone who gives you money willingly in return.
And you're absolutely right that wavelength and intensity aren't enough; I was incorrect in saying that.
But I stand by my statement: the CIE standard specifies three components (as far as I know, the most recent one uses L, A, and B), but reduces them internally to two components, called 'xy'. The resulting 2D space isn't linear, but it covers all of human vision plus a good area that's invisible to us.
I posted a link to a black and white diagram of the resulting colorspace; a colorized version would almost be a waste, since monitors can only reproduce a triangle in the middle of the curve; but here's one anyway. Nice; that page gives several versions, with a few different perspectives.
For the rest of us, RGB centered at our own visual peaks makes the most sense of any encoding scheme possible. Not only can we not see another color,
Not true. We can see colors that monitors can't display -- IIRC, mainly deep purples. Oh, of course, as long as we're using modern monitor technology with RGB additive, storing images in RGB makes perfect sense. However, in general, there are other more general schemes; wavelength+amplitude would be one, and CIE is an internationally accepted standard to describe human vision.
Ah, here we are. A little graph showing how much of the human vision RGB can't cover. Check it out!
but it wastes space in the image (ie, some optimal conversion function can, by physical necessity, reduce those four colors to an RGB triad indistinguishable from the original quartet by a normal human.
And more manipulation could reduce it to TWO numbers, related to wavelength and frequency. And even more could reduce it to two numbers related to the eye's response to wavelength and frequency. I don't think that's been done, but the CIE system reduces to three numbers.
More information does seem better, agreed. However, due to the physiological limitations of human vision, this scheme does not convey any more information, thus my biggest complaint. It seems everyone else missed this as nothing more than a meaningless marketing ploy.
I'm sure it's occurred to you that if you disagree with everyone else, it's sometimes possible that you're missing something.
So you all go out and buy this toy so you can brag about having "better" color, and I'll continue taking perceptually identical pics with my boring 'ol RGB cam that cost $800 less.:-)
We'll have to wait to see real reviews to make a judgement on this one -- the previews I've seen look very positive, regardless of filter technology. It looks like it's a substantial improvement on other cameras in the same price range.
Lisp alone is only Lisp, if at all, some should use a lisp with oo extensions.
You mean perhaps CLOS (Common Lisp Object System), the first international standard for an object-oriented language?
Even the simplest pascal algorith is hard to be coded in "pure" lisp, as you have to do the trick of converting all "record" like data structures in list/lisp like equivalences.
Why would you do that? Why code in someone else's idea of "pure" Lisp, when you have the full language available, with structures, arrays, hash tables, multimethods, and so on all before you?
Lisp isn't Scheme. Scheme is a purist's language, with limited iteration and data but lots of clean, clever ways to recurse over lists. Lisp is a pragamtic, powerful language with TONS of datatypes and library functions. Oh, and the most powerful object system I've seen.
For me lisp is just a fence of paranthesis. I find it incredibel hard to read. And, no, the idea that this is only a matter of practicing, is a myth.
Why do you say it's a myth?
Braces like in Java/C++ are absolutely clear markers and do not confuse in any way with the mathematical idioms I learned for 13 years in school, and use since nearly 30 years in all day life.
It's interesting that so many people defend as "intuitive" something that they spent 13 years learning, and still often don't get right. You're not making that mistake, fortunately:-).
Sorry, but for me the function name or class name has to be in front of the () nd not inside.
This doesn't make any difference at all.
Controll structures have to be easy spotted and not to be hidden inside of () signs.
This does make a difference, definitely. It's why indentation is so important, and why Lisp programmers tend to STRONGLY recommend using a good editor, to make sure that you NEVER forget (and even to help you by syntax highlighting).
Unfortunatly I know that this is not just me, you need to have a mind to be suited with lisp. About 50% of my lisp class failed... I only had luck to pass it.
Well, you've been confusing Lisp and Scheme; I'd say that your class probably wasn't a good one. I'm sorry.
He did the search, as you said, but he didn't use Google's conversion; instead, he looked directly inside the DOC file, where Word keeps a bunch of information for its own purposes -- stuff that was deleted, stuff that was just in the wrong memory location when the save happened -- whatever.
He found legitimate docs, with legit contents; but they also contained some stuff that the authors didn't intend to publish.
No, I'm building something with a specific purpose: to scan emails sent to *my* box to determine whether they're worth *my* time. In the process I visit links in the emails provided allegedly for the purpose of providing the information I'll need to make that decision. I'll then run a Bayesian filter over that text, using MY processor time. (This is in the original proposal.)
None of this is in any faint way illegal, immoral, or possible to construe as such.
Now, there are some people who have so much against spammers that they're willing to twist this a lot. I suspect that anyone fetching the same page multiple times, or throwing away the results of a fetch without analysing it, or sharing clock information in order to synchronise fetches will be vulnerable to charges of deliberate DDoSing -- but those activities are THEMSELVES attempted denials of service, in effect acts of violence regardless of their target.
I will admit, though, that I do share Paul Allen's expectation that even proper, polite usage of his system will hammer spammers hard, and harder the spammier they are. I shed no tears for that; they're stealing small amounts of resources from everyone, and everyone who uses this will be asking them to devote a *tiny* amount of resources to confirming their validity. If they have even the tiniest bit of honesty, they've prepared a server that can handle the people they're advertising to, so this system will cost them nothing.
Your reading skills aren't misleading you -- some people are picturing this as a way to get poetic justice. But in reality, this doesn't deliver justice; it simply delivers more information to the targets of the advertisement.
The "justice" only comes if the sender of the advertisement wasn't capable of serving as many people as he advertised directly to -- and that's certainly not an encroachment on our part.
I can think of a nice way for spammers to get around this antispam AND avoid server overload at the same time. The worst load this can ever cause on your server would appear soon after you send out the spam; therefore, just put a dummy webpage up using a superlight static page server. The dummy can be completely innocent-looking, of course, which would further help the spam make it into even protected mailboxes. Let a few minutes pass, possibly watching web traffic; once it tapers off a little, put up the real page. Your polite proxy may cost you one or two real customers, but odds are your ad targets aren't watching their email accts precisely when you sent the message anyhow.
SpamAssassin is nice, but it's not very clever in its Bayesian filter. DSPAM is much smarter; in particular, it automatically ages its corpus, thus keeping you up to date.
And for the Shakespeare poisoning -- I have a hard time seeing how that would work. I don't use Spamassassin, but for my emails Shakespeare is relatively rare; almost 100% of the words in it would be never-seen-before (neutral), and thus wouldn't show up at all on the spam calculations.
Well, giving that you do that with the intent of DDoSing their website, I find it hard for you to tell me that this is just a normal click.
I'm not sure that the intent is to DDoS. The basic intent is to gather more information about the email with the purpose of determining whether it's interesting to read.
A DDoS will only happen if the URL was deliberately publicised to more people than the server can handle. Admittedly, this is possible.
Your argument is wrong. "Trust" is not belief with evidence; it's the capability of acting on a belief. Amount of evidence and level of proof are irrelevant. I trust the chair I'm sitting in; I have faith that it'll hold me. I also have a lot of evidence. I trust my coworker (that one over there); I have faith that he will do what he's said.
Faith is a close synonym for trust, even in fine detail: for example, if I say I trust that chair, I may never sit in it; if I say I have trust in that chair, it means that I sit in it. Having faith _that_ something will happen is likewise different from having faith _in_ something or someone.
Correct, and perhaps a hole in my choice of words for that definition. HOWEVER, I would claim that [ 3 ] in Postscript is a token, in spite of the spaces, in the same sense that "[ 3 ]" (a string) is a token in C. In C, "[ 3 ]" is a single literal string; in Postscript, [ 3 ] is a single literal list.
Hmm, perhaps I should have used the term "lexeme" rather than "token". That way maybe people would stop asking me what I'd been tokin' (drum roll).
Seriously, what do you think? Would "lexeme" make more sense?
What the heck does that mean? Latency isn't cyclic, and you don't have back-to-back latency either.
Sorry, I used the wrong word. I don't design chips (well, not since that one class in college) and don't know the terminology. I meant that each bus can accept new data 2,400,000,000 times every second.
with 10 independant busses, that means an upper bound of 10*2400M*18=432,000Mbps internal.
So... is that supposed to be maximum throughput
Not in the sense I understand it; perhaps you might call it "maximum combined internal throughput", though.
especially since the processor-to-processor maximum throughput sounds like a useless variable.
The processor-to-processor maximum throughput is, of course, a constant, not a variable -- 2400MHz*18 bits = 43200Mbps. That's not a useless number; it's the actual speed that two adjacent processors within this chip can burst data to each other. This can become very useful when one of the processors is controlling a high-speed external device, such as an optical receiver at the end of an OC48 fiber. Maximum chip throughput would probably be half the chip-to-chip burst, since each processor would take one cycle to send the data and one to receive it (but that could be sustained indefinitely, so long as the bus being used for the two to communicate isn't being used by any other chips).
By the way: The outer processors in the grid are connected directly to the pins, giving the 25x a programmable pinout. The originally designed configuration had a pinout that exactly matched a 4ns SRAM (and the software driver for talking to the SRAM in on-chip ROM), thus allowing the chip to hook up to the SRAM and use it with the addition of a bit of solder and a power hookup -- a nice trick.
Postscript is no more "written" than 386 machine code. Both are generated by a computer processing a higher-level description that is more amenable to human understanding. (Rare tinkerers can manually create the low level code, but they are abberations)
Here, I think, we have a false distinction operating. If Postscript isn't written in order to produce Postscript printouts, than neither is Lisp written when Lisp macros execute; yet that IS the common terminology.
By the way, Postscript isn't a hard language to understand -- it's quite simple and beautiful. The higher-level representations aren't MORE amenible to human understanding, they simply allow a person possibly unskilled in Postscript to control a subset of PS.
Some aspects of postscript (or any powerful graphical description language) seem very tree-like. Particularly the system of pushing transformations onto a stack. A human reading a postscript file can visualize the tree formed by the transformation stack over time, just like a C program represents a function-call tree over time.
First, my point is that the/language's syntax/ isn't a tree, not that you can't express trees in the language. Second, there are many operations that form DAGs rather than trees in concatenative languages. And third, there are a few operations (frowned upon by the communities of the language, usually for intuitive reasons) which make it impossible to statically build a tree (they take their arguments dynamically).
On the message board you link to, I find you mention that "in order for a language to be concatenative, it must be true that any single program can be split at any token boundary to produce two valid programs."
Yes, although I will say that this is the hardest part of the definition of concatenativity to explain -- and perhaps it hasn't yet been reduced to a correct formulation. But the example you give is not an exception.
I don't see how postscript meets this criteria. I'm not an expert, but if a postscript stream ended in "pop" and you split off just that last token, you'd have an invalid program.
You'd have one program whose result was to leave one more item on the stack than it did before, and one program whose sole result was to remove one item from the stack. Neither of those are "invalid", although either one may fail if given the wrong data.
Try this with C -- split an arbitrary C function in half, and create two new functions (you're allowed, of course, to avoid splitting in the middle of expressions or otherwise creating syntax errors; in C this limits you to splitting between statements, while in colorForth this rule only limits you to splitting at whitespace, and in Joy or Postscript, you can split anywhere outside of a literal or function name). Now try to compile. Unless your function takes no parameters, the result won't work; the local variables defined in one half of the function are used but not defined in the other half.
I've allowed you to use a very restrictive rule in deciding where to "cut" the function in half. In general, I could use the rule that you have to allow your function to be cut anywhere that's not in the middle of a literal or a function name, in which case Joy and most of Postscript would be the only languages I know of which pass the test of being concatenative. (This IS actually the test I recommend.)
And the negative results for so many other languages should not be a surprise; the entire idea of concatenativity was only recently discovered. Forth, Postscript, HP-RPN, and many others were developed for other purposes.
One might argue that a "stackunderflow" is just an error, and not a sign of an invalid program.
One might, but you have to recognise that the error isn't in the "pop". The error is calling the "pop" with the wrong data -- in this case, the only possible wrong data is no data at all.
However, since you consider even assembly-code to be tree-like (I don't agree, because the "trees" making an opcode are of fixed height),
A single simple opcode, perhaps. Add in the possibility for size overrides and indirect addressing and the tree gets more variable.
But I don't believe variability is the issue; the point is that it's a tree, not that it's variable in some way.
I'll answer my riddle, though. The language I was hinting at is Postscript, and the family of languages includes Forth, HP-RPN, Joy, and a few others. All of these languages have a linear parse, which is so simple that the term "parse" is an exaggeration. Real systems using these languages don't parse; they lex then compile.
Postscript is the most commonly used programming language because it shares one major feature with the other languages in its family: for any two valid programs, their concatenation is also a valid program. Thus, machine-constructing a Postscript or Forth program is simple: select the functionality you want, and concatenate the programs which give that functionality.
You could mean either machine code, or deoxyribonucleic acid.
Very nice guesses. But DNA isn't a computer language because it's not for computers, and machine code isn't a computer language because it's not a language. Okay, I'm being a little slippery on that last one:-). I will admit that machine language is a very, very good guess, but it's not even close to what I'm thinking of.
The languages I'm thinking of are text-based; they are programming languages in the classical meaning of the word (although one computer historian refused to document one of these languages because its linear structure made it so different from what she considered a "true" programming language).
However, claiming "more programs are written in this language" seems a stretch, as I don't consider an activity "writing" without an intelligence behind it.
What does "behind it" mean to you? Obviously, someone *wants* all these programs written, enough to waste all the -- um -- display space their output takes up.
A human can write any of these languages, including the one to which I was referring with the hint you're talking about.
But anyhow, use any word you like if you don't like "written". Composed? "Designed" doesn't work.
Are you on drugs? Pretty much every source code file I have jacked with over the past 20 years is a text file
Of course. The "visual languages" tend to display the tree directly, but they're certainly no easier to manipulate -- I definitely prefer manipulating text (no statement made about the ease of programming the visual languages).
But that doesn't impact the statement I made: [most languages are semantically trees] "so it's hard to portray source code in a text file."
It's hard, but it's the most common way to do it, and I would say the easiest commonly available way.
The reason it's hard is that you need 2 dimensions to display a simple tree, and text files with newlines can give you 2 dimensions; but you need one more dimension to write names and such. Since you don't have that dimension, you have to squeeze the name into the tree's space, thus making the tree distorted and hard to see.
(Some strongly tree-structured dataflow languages have a user tradition of using single-character names, for pretty much this reason. Consider the derivatives of APL [A+, J, and K] for an example; and APL itself is almost unique in using single characters to represent very complex dataflow.)
And now for your guess at my riddle: And assembly (machine language) is pretty much linear with lots of jumping around, but I can read it (decipher is more like it) by looking at a hex dump... at least get a general feel for what is going on, and I am human.
Very nice work, but no. Assembly language is more like a forest than a tree, much like BASIC, FORTRAN, or Perl (contrast to Scheme or ML); but it's still fundamentally tree-structured. For example, MOV AX, BX can be diagrammed with MOV at the root, AX on the left branch, and BX on the right. More complex tree parses are available, for example with indirect addressing.
Just a clarification: I wasn't intending to convey that no human CAN read it; I was trying to claim that in most cases, no human will read it.
It's a bit harder than you portray. Source code for most programming languages is a tree, not a linear list; and text is much closer to being a linear list than a tree, so it's hard to portray source code in a text file.
But like you say, there are ways of handling it, and they result in better code.
But what would I know? I use a Trackpoint keyboard, so I can scroll around in any direction without even lifting my hands from the alphanumeric keys. I'm so disappointed and puzzled that those horrible touchpads so completely wiped out trackpoints.
BTW, extra points for the first response identifying a programming language that doesn't use a tree structure internally, even conceptually. Let me give a little hint for one of the possible answers: probably more programs are written in this language every day than all the other languages combined, but normally no human writes them and no human reads them.
If you remember the interview with Chuck Moore (of Forth fame) a while back, he was promoting a chip kinda like this. 25 CPUs all on one chip (5x5), with a grid of 18-bit busses, 5 each way, connecting them all to each other horizontally and vertically. He hadn't built any, but based on his previous chips at much larger scales, he was estimating about 2400MHz maximum bus input latency; with 10 independant busses, that means an upper bound of 10*2400M*18=432,000Mbps internal.
Of course, that's all noise -- none of the chips would have time to do real work:-), nor to listen for any of that "information". But the sheer magnitude of the number is a bit staggering. But anyhow, yes, on-chip busses are pretty fun.
Oh, latest rumor: he took the 25x page down because he'd found a buyer. Very little other info available.
Slashdot Mirror
Rather, it's ``... they have no right to distribute "stuff that they [...] own" along with GPLd stuff they don't own. They can do whatever they like with their own stuff, but they can't distribute it comingled with GPLd code unless they license it under the GPL. Guess I didn't make myself clear on that originally.
I know what you're saying, but the GPL also imposes a burden of support on them: _having_ innocently distributed their own proprietary code (after someone else allegedly put it in), they are required to continue making the source available. This is precisely what they are doing.
Their precise actions on this FTP site would be highly commendable if they were prosecuting only the company responsible for the violation, and promising to license under the GPL as soon as reasonably possible (and not doing so many OTHER things...) -- after all, nobody could reasonably demand that they GPL their software in the middle of a legal battle (thereby automatically losing the battle). Therefore, there's nothing wrong with the FTP site; it's their other actions that are wrong.
The problem is that it's a catch-22; they violate the GPL either way, but they way they've chosen they also support their customers. I suspect that a judge would agree. Of course, I again note that there's a third way: to release their code under GPL; but the court would definitely frown upon that (in the sense that it would enforce no punishment on the defendant).
Another issue with SCO's efforts to license ``their'' code is IBM's patents. It's quite probable that the code in question (whatever it may turn out to be) infringes upon one or more of IBM's patents.
So you haven't read anything about them, huh? Okay, take a break now; go look them up. Reply to my message after you've confirmed that three of the four patents couldn't possibly apply to the kernel (they're user-interface-specific), and the remaining one doesn't apply to any of the specific claims they've made (although I'll admit that it might apply to something they're hiding, or something otherwise in the Linux kernel).
It's not illegal to use a patented idea; it's merely prosecutable. If IBM ignores it, it doesn't matter. When they stop ignoring it, it suddenly matters.
That would be the only way that they could get away with distributing the kernel: if it's all GPLd. So, SCO believes that no-one needs an SCO license for the 2.4.13 (I think it was) kernel, or SCO believes that it is violating various copyrights, or SCO is cynically engaging in barratry.
OR, SCO wishes to legally punish someone who (unbeknownst to them) inserted their copyrighted code into the kernel, but SCO also wishes to honor their obligations to customers as documented in the GPL.
Which one of the four do you think SCO will present to the judge? Do you have any reason for him to disbelieve the one they'll obviously choose?
I do -- but it STARTS by looking at all the obviously wrong things they've done, and ends at the catch-22 technicalities like this, AFTER their bad faith has been proven.
-Billy
Yes, but. Just a couple days ago I went to their ftp site and downloaded a 2.4 kernel. I am not, and never have been, a SCO customer.
/prima facia/, legitimate attempts to stop abuses of their own properly owned copyrights and/or contract violations. Their blabbering and preposterous press releases are, of course and unfortunately, not applicable to the GPL.
Yet their FTP site says that it's only for SCO customers; they explicitly put it up for that purpose, and they explicitly express a licence to their old customers to download that code. This doesn't mean that you're doing anything wrong (in particular because both you and I know that SCO's case is preposterous), but it does mean that you're not the licensed audience.
They are deliberately distributing the kernel, knowing that stuff they claim to own is in there.
First, you can't claim that they have no right to distribute "stuff that they [...] own".
Second, much of the "stuff that they claim to own" was added to a later version of the kernel.
Unless they are distributing it under the GPL, they have no right to distribute it at all. Thus, they are either:
Actually, they're attempting to meet their contractual obligations to their customers, which involves (according to their claims, for the sake of argument):
1. Distributing Linux's legally GPLed code.
2. Distributing their code which someone illegally copied into the GPLed code, but which isn't covered by ANY valid licence.
3. Conveying a licence to their customers to make getting, installing, and using that illegally copied code legal.
According to SCO, by no fault of their own someone else inserted vast amounts of their code into Linux, from which SCO (like many other companies) gained customers and revenue; if this were true, SCO shouldn't be forced to stop supporting their customers simply in order to stop someone else's infringement of their rights.
Now, setting aside all those "for the sake of argument" claims, we can see that SCO's claims are, by and large, baloney; and their actions in hiding their code are cowardly, indicative of something to hide (duh), not conducive to allowing good-willed people to reduce SCO's damages, and useless for prosecution of their case. However, the action of continuing to provide support for their old product is correct and valid.
The one thing which might trip them up with respect to the GPL is if they've violated the GPL, but I'm not sure that they have -- they are, after all, providing all the source as the GPL demands (and you're telling them to violate the GPL by stopping!), and their current court actions are,
Keep in mind that I'm not saying they're right; I'm only saying that THIS defence against them is useless. Switch! See also Eric's analysis of their code, and LWN.net's analysis of that, pointing out that Eric was probably wrong and SCO was probably right, even though it doesn't help their court case. It's important to tell the truth and do the right thing, even when it makes bad people look better.
-Billy
Actually, I've read nothing but the magazine articles and interviews about this half-baked ``theory''. I'm inclined to believe that what SCO's shysters are proposing is radically different than what is being reported.
:-).
As far as I can tell, you're correct. It looks to me like they're not claiming the GPL itself is invalid; rather, they're claiming that the GPL doesn't apply to that code _because_ they own the copyright and they didn't apply it.
This is a highly rational defence.
Never mind the rest of their problems
-Billy
Yup, that's essentially what Enron was about. And it was a good idea, too.
/now/. Just buy+install+have_inspected a generator of some kind (solar's probably the easiest), call the power company and switch your billing to demand-based, so that they charge you a LOT during peak hours and very little during off-peak hours. Turn the generator on... And boom, they pay you for what you produce during peak hours (which happen, of course, to be when the sun's out), and you pay them for what you consume while the sun's unavailable (which is almost always off-peak).
But this whole scheme is a waste of time. You can do it right
The only problem is that they won't ever write you a check; you can only cancel your own bill. But the incentive is still pretty strong!
(But not strong enough for me to want to put all that work and tens of thousands of dollars into a solar system -- my bills aren't that high yet.)
-Billy
Burning gasoline or propane and feeding the hot gases through the thing directly might be workable but probably isn't that fuel efficient. Or we'd have a Tesla engine in every car today since it's more or less vibration free compared to a regular piston engine.
You haven't studied the topic.
Steam powered turbines have their uses, and even with the boilers can compete in their own areas. But turbines ARE some of the lightest, most efficient engines we make; that's why they're used both in aircraft and generators (and in some tanks).
Or we'd have a Tesla engine in every car today since it's more or less vibration free compared to a regular piston engine.
The real reason is that tesla turbines, like regular turbines, run at speeds well in excess of 10,000 RPM. Cars don't need that kind of speed, and the parts needed to gear it down wear out too fast.
The quasiturbine, on the other hand, runs at a quite carlike speed, and is pretty much vibration-free. But unlike the tesla turbine, you can't build a working quasiturbine out of paper.
-Billy
It only takes three bonehead gamblers to make up for one counter's winnings.
For a counter who's working as small-time as the boneheads, yes. Those are harmless, and in fact most casinos will simply gently let them know that they're watching (unless they get too persistent; not only do the casinos not want to take sustained losses, they also don't want to risk missing the professional operating off the simple counter). The losses the casinos receive from small-time counting are more than offset by the "boneheads" drawn in by the sight of winning.
But counters aren't all small-time. A team working counting WILL take home 150% of their sizable investment in a day, and can be very subtle at it. There's a group at MIT that used to do that, and wrote it up. If it's profitable and allowed, someone will make a job of it, and casinos simply CAN'T allow that kind of losses all day every day. So they make it impossible to do it regularly, and they're well within their rights.
Casino management just can't stand the thought of anyone taking money based on skill:
Sure they can. They pay people to do that -- cooks, mechanics, architects, engineers... And they expect people to use their skills to earn the money that they spend at the casino.
it's got to be a gamble, all the time, in the house's favor.
Yup. That's why it's a casino; that's why it's there. In fact, that's why it's called "gambling" instead of "work". If you want to earn money by using skill, go use that skill to do something useful for someone who gives you money willingly in return.
-Billy
Grin, blush -- you're right, my typo.
And you're absolutely right that wavelength and intensity aren't enough; I was incorrect in saying that.
But I stand by my statement: the CIE standard specifies three components (as far as I know, the most recent one uses L, A, and B), but reduces them internally to two components, called 'xy'. The resulting 2D space isn't linear, but it covers all of human vision plus a good area that's invisible to us.
I posted a link to a black and white diagram of the resulting colorspace; a colorized version would almost be a waste, since monitors can only reproduce a triangle in the middle of the curve; but here's one anyway. Nice; that page gives several versions, with a few different perspectives.
-Billy
For the rest of us, RGB centered at our own visual peaks makes the most sense of any encoding scheme possible. Not only can we not see another color,
:-)
Not true. We can see colors that monitors can't display -- IIRC, mainly deep purples. Oh, of course, as long as we're using modern monitor technology with RGB additive, storing images in RGB makes perfect sense. However, in general, there are other more general schemes; wavelength+amplitude would be one, and CIE is an internationally accepted standard to describe human vision.
Ah, here we are. A little graph showing how much of the human vision RGB can't cover. Check it out!
but it wastes space in the image (ie, some optimal conversion function can, by physical necessity, reduce those four colors to an RGB triad indistinguishable from the original quartet by a normal human.
And more manipulation could reduce it to TWO numbers, related to wavelength and frequency. And even more could reduce it to two numbers related to the eye's response to wavelength and frequency. I don't think that's been done, but the CIE system reduces to three numbers.
More information does seem better, agreed. However, due to the physiological limitations of human vision, this scheme does not convey any more information, thus my biggest complaint. It seems everyone else missed this as nothing more than a meaningless marketing ploy.
I'm sure it's occurred to you that if you disagree with everyone else, it's sometimes possible that you're missing something.
So you all go out and buy this toy so you can brag about having "better" color, and I'll continue taking perceptually identical pics with my boring 'ol RGB cam that cost $800 less.
We'll have to wait to see real reviews to make a judgement on this one -- the previews I've seen look very positive, regardless of filter technology. It looks like it's a substantial improvement on other cameras in the same price range.
-Billy
Lisp alone is only Lisp, if at all, some should use a lisp with oo extensions.
:-).
... I only had luck to pass it.
You mean perhaps CLOS (Common Lisp Object System), the first international standard for an object-oriented language?
Even the simplest pascal algorith is hard to be coded in "pure" lisp, as you have to do the trick of converting all "record" like data structures in list/lisp like equivalences.
Why would you do that? Why code in someone else's idea of "pure" Lisp, when you have the full language available, with structures, arrays, hash tables, multimethods, and so on all before you?
Lisp isn't Scheme. Scheme is a purist's language, with limited iteration and data but lots of clean, clever ways to recurse over lists. Lisp is a pragamtic, powerful language with TONS of datatypes and library functions. Oh, and the most powerful object system I've seen.
For me lisp is just a fence of paranthesis. I find it incredibel hard to read. And, no, the idea that this is only a matter of practicing, is a myth.
Why do you say it's a myth?
Braces like in Java/C++ are absolutely clear markers and do not confuse in any way with the mathematical idioms I learned for 13 years in school, and use since nearly 30 years in all day life.
It's interesting that so many people defend as "intuitive" something that they spent 13 years learning, and still often don't get right. You're not making that mistake, fortunately
Sorry, but for me the function name or class name has to be in front of the () nd not inside.
This doesn't make any difference at all.
Controll structures have to be easy spotted and not to be hidden inside of () signs.
This does make a difference, definitely. It's why indentation is so important, and why Lisp programmers tend to STRONGLY recommend using a good editor, to make sure that you NEVER forget (and even to help you by syntax highlighting).
Unfortunatly I know that this is not just me, you need to have a mind to be suited with lisp. About 50% of my lisp class failed
Well, you've been confusing Lisp and Scheme; I'd say that your class probably wasn't a good one. I'm sorry.
-Billy
Incorrect. You didn't read the article.
He did the search, as you said, but he didn't use Google's conversion; instead, he looked directly inside the DOC file, where Word keeps a bunch of information for its own purposes -- stuff that was deleted, stuff that was just in the wrong memory location when the save happened -- whatever.
He found legitimate docs, with legit contents; but they also contained some stuff that the authors didn't intend to publish.
-Billy
No, I'm building something with a specific purpose: to scan emails sent to *my* box to determine whether they're worth *my* time. In the process I visit links in the emails provided allegedly for the purpose of providing the information I'll need to make that decision. I'll then run a Bayesian filter over that text, using MY processor time. (This is in the original proposal.)
None of this is in any faint way illegal, immoral, or possible to construe as such.
Now, there are some people who have so much against spammers that they're willing to twist this a lot. I suspect that anyone fetching the same page multiple times, or throwing away the results of a fetch without analysing it, or sharing clock information in order to synchronise fetches will be vulnerable to charges of deliberate DDoSing -- but those activities are THEMSELVES attempted denials of service, in effect acts of violence regardless of their target.
I will admit, though, that I do share Paul Allen's expectation that even proper, polite usage of his system will hammer spammers hard, and harder the spammier they are. I shed no tears for that; they're stealing small amounts of resources from everyone, and everyone who uses this will be asking them to devote a *tiny* amount of resources to confirming their validity. If they have even the tiniest bit of honesty, they've prepared a server that can handle the people they're advertising to, so this system will cost them nothing.
-Billy
Your reading skills aren't misleading you -- some people are picturing this as a way to get poetic justice. But in reality, this doesn't deliver justice; it simply delivers more information to the targets of the advertisement.
The "justice" only comes if the sender of the advertisement wasn't capable of serving as many people as he advertised directly to -- and that's certainly not an encroachment on our part.
I can think of a nice way for spammers to get around this antispam AND avoid server overload at the same time. The worst load this can ever cause on your server would appear soon after you send out the spam; therefore, just put a dummy webpage up using a superlight static page server. The dummy can be completely innocent-looking, of course, which would further help the spam make it into even protected mailboxes. Let a few minutes pass, possibly watching web traffic; once it tapers off a little, put up the real page. Your polite proxy may cost you one or two real customers, but odds are your ad targets aren't watching their email accts precisely when you sent the message anyhow.
-Billy
SpamAssassin is nice, but it's not very clever in its Bayesian filter. DSPAM is much smarter; in particular, it automatically ages its corpus, thus keeping you up to date.
And for the Shakespeare poisoning -- I have a hard time seeing how that would work. I don't use Spamassassin, but for my emails Shakespeare is relatively rare; almost 100% of the words in it would be never-seen-before (neutral), and thus wouldn't show up at all on the spam calculations.
-Billy
Well, giving that you do that with the intent of DDoSing their website, I find it hard for you to tell me that this is just a normal click.
I'm not sure that the intent is to DDoS. The basic intent is to gather more information about the email with the purpose of determining whether it's interesting to read.
A DDoS will only happen if the URL was deliberately publicised to more people than the server can handle. Admittedly, this is possible.
-Billy
Your argument is wrong. "Trust" is not belief with evidence; it's the capability of acting on a belief. Amount of evidence and level of proof are irrelevant. I trust the chair I'm sitting in; I have faith that it'll hold me. I also have a lot of evidence. I trust my coworker (that one over there); I have faith that he will do what he's said.
Faith is a close synonym for trust, even in fine detail: for example, if I say I trust that chair, I may never sit in it; if I say I have trust in that chair, it means that I sit in it. Having faith _that_ something will happen is likewise different from having faith _in_ something or someone.
-Billy
Correct, and perhaps a hole in my choice of words for that definition. HOWEVER, I would claim that [ 3 ] in Postscript is a token, in spite of the spaces, in the same sense that "[ 3 ]" (a string) is a token in C. In C, "[ 3 ]" is a single literal string; in Postscript, [ 3 ] is a single literal list.
Hmm, perhaps I should have used the term "lexeme" rather than "token". That way maybe people would stop asking me what I'd been tokin' (drum roll).
Seriously, what do you think? Would "lexeme" make more sense?
-Billy
What the heck does that mean? Latency isn't cyclic, and you don't have back-to-back latency either.
Sorry, I used the wrong word. I don't design chips (well, not since that one class in college) and don't know the terminology. I meant that each bus can accept new data 2,400,000,000 times every second.
with 10 independant busses, that means an upper bound of 10*2400M*18=432,000Mbps internal.
So... is that supposed to be maximum throughput
Not in the sense I understand it; perhaps you might call it "maximum combined internal throughput", though.
especially since the processor-to-processor maximum throughput sounds like a useless variable.
The processor-to-processor maximum throughput is, of course, a constant, not a variable -- 2400MHz*18 bits = 43200Mbps. That's not a useless number; it's the actual speed that two adjacent processors within this chip can burst data to each other. This can become very useful when one of the processors is controlling a high-speed external device, such as an optical receiver at the end of an OC48 fiber. Maximum chip throughput would probably be half the chip-to-chip burst, since each processor would take one cycle to send the data and one to receive it (but that could be sustained indefinitely, so long as the bus being used for the two to communicate isn't being used by any other chips).
By the way: The outer processors in the grid are connected directly to the pins, giving the 25x a programmable pinout. The originally designed configuration had a pinout that exactly matched a 4ns SRAM (and the software driver for talking to the SRAM in on-chip ROM), thus allowing the chip to hook up to the SRAM and use it with the addition of a bit of solder and a power hookup -- a nice trick.
-Billy
Postscript is no more "written" than 386 machine code. Both are generated by a computer processing a higher-level description that is more amenable to human understanding. (Rare tinkerers can manually create the low level code, but they are abberations)
/language's syntax/ isn't a tree, not that you can't express trees in the language. Second, there are many operations that form DAGs rather than trees in concatenative languages. And third, there are a few operations (frowned upon by the communities of the language, usually for intuitive reasons) which make it impossible to statically build a tree (they take their arguments dynamically).
Here, I think, we have a false distinction operating. If Postscript isn't written in order to produce Postscript printouts, than neither is Lisp written when Lisp macros execute; yet that IS the common terminology.
By the way, Postscript isn't a hard language to understand -- it's quite simple and beautiful. The higher-level representations aren't MORE amenible to human understanding, they simply allow a person possibly unskilled in Postscript to control a subset of PS.
Some aspects of postscript (or any powerful graphical description language) seem very tree-like. Particularly the system of pushing transformations onto a stack. A human reading a postscript file can visualize the tree formed by the transformation stack over time, just like a C program represents a function-call tree over time.
First, my point is that the
On the message board you link to, I find you mention that "in order for a language to be concatenative, it must be true that any single program can be split at any token boundary to produce two valid programs."
Yes, although I will say that this is the hardest part of the definition of concatenativity to explain -- and perhaps it hasn't yet been reduced to a correct formulation. But the example you give is not an exception.
I don't see how postscript meets this criteria. I'm not an expert, but if a postscript stream ended in "pop" and you split off just that last token, you'd have an invalid program.
You'd have one program whose result was to leave one more item on the stack than it did before, and one program whose sole result was to remove one item from the stack. Neither of those are "invalid", although either one may fail if given the wrong data.
Try this with C -- split an arbitrary C function in half, and create two new functions (you're allowed, of course, to avoid splitting in the middle of expressions or otherwise creating syntax errors; in C this limits you to splitting between statements, while in colorForth this rule only limits you to splitting at whitespace, and in Joy or Postscript, you can split anywhere outside of a literal or function name). Now try to compile. Unless your function takes no parameters, the result won't work; the local variables defined in one half of the function are used but not defined in the other half.
I've allowed you to use a very restrictive rule in deciding where to "cut" the function in half. In general, I could use the rule that you have to allow your function to be cut anywhere that's not in the middle of a literal or a function name, in which case Joy and most of Postscript would be the only languages I know of which pass the test of being concatenative. (This IS actually the test I recommend.)
And the negative results for so many other languages should not be a surprise; the entire idea of concatenativity was only recently discovered. Forth, Postscript, HP-RPN, and many others were developed for other purposes.
One might argue that a "stackunderflow" is just an error, and not a sign of an invalid program.
One might, but you have to recognise that the error isn't in the "pop". The error is calling the "pop" with the wrong data -- in this case, the only possible wrong data is no data at all.
-Billy
However, since you consider even assembly-code to be tree-like (I don't agree, because the "trees" making an opcode are of fixed height),
A single simple opcode, perhaps. Add in the possibility for size overrides and indirect addressing and the tree gets more variable.
But I don't believe variability is the issue; the point is that it's a tree, not that it's variable in some way.
I'll answer my riddle, though. The language I was hinting at is Postscript, and the family of languages includes Forth, HP-RPN, Joy, and a few others. All of these languages have a linear parse, which is so simple that the term "parse" is an exaggeration. Real systems using these languages don't parse; they lex then compile.
Postscript is the most commonly used programming language because it shares one major feature with the other languages in its family: for any two valid programs, their concatenation is also a valid program. Thus, machine-constructing a Postscript or Forth program is simple: select the functionality you want, and concatenate the programs which give that functionality.
-Billy
You could mean either machine code, or deoxyribonucleic acid.
:-). I will admit that machine language is a very, very good guess, but it's not even close to what I'm thinking of.
Very nice guesses. But DNA isn't a computer language because it's not for computers, and machine code isn't a computer language because it's not a language. Okay, I'm being a little slippery on that last one
The languages I'm thinking of are text-based; they are programming languages in the classical meaning of the word (although one computer historian refused to document one of these languages because its linear structure made it so different from what she considered a "true" programming language).
However, claiming "more programs are written in this language" seems a stretch, as I don't consider an activity "writing" without an intelligence behind it.
What does "behind it" mean to you? Obviously, someone *wants* all these programs written, enough to waste all the -- um -- display space their output takes up.
A human can write any of these languages, including the one to which I was referring with the hint you're talking about.
But anyhow, use any word you like if you don't like "written". Composed? "Designed" doesn't work.
-Billy
Are you on drugs? Pretty much every source code file I have jacked with over the past 20 years is a text file
... at least get a general feel for what is going on, and I am human.
Of course. The "visual languages" tend to display the tree directly, but they're certainly no easier to manipulate -- I definitely prefer manipulating text (no statement made about the ease of programming the visual languages).
But that doesn't impact the statement I made: [most languages are semantically trees] "so it's hard to portray source code in a text file."
It's hard, but it's the most common way to do it, and I would say the easiest commonly available way.
The reason it's hard is that you need 2 dimensions to display a simple tree, and text files with newlines can give you 2 dimensions; but you need one more dimension to write names and such. Since you don't have that dimension, you have to squeeze the name into the tree's space, thus making the tree distorted and hard to see.
(Some strongly tree-structured dataflow languages have a user tradition of using single-character names, for pretty much this reason. Consider the derivatives of APL [A+, J, and K] for an example; and APL itself is almost unique in using single characters to represent very complex dataflow.)
And now for your guess at my riddle:
And assembly (machine language) is pretty much linear with lots of jumping around, but I can read it (decipher is more like it) by looking at a hex dump
Very nice work, but no. Assembly language is more like a forest than a tree, much like BASIC, FORTRAN, or Perl (contrast to Scheme or ML); but it's still fundamentally tree-structured. For example, MOV AX, BX can be diagrammed with MOV at the root, AX on the left branch, and BX on the right. More complex tree parses are available, for example with indirect addressing.
Just a clarification: I wasn't intending to convey that no human CAN read it; I was trying to claim that in most cases, no human will read it.
-Billy
It's a bit harder than you portray. Source code for most programming languages is a tree, not a linear list; and text is much closer to being a linear list than a tree, so it's hard to portray source code in a text file.
But like you say, there are ways of handling it, and they result in better code.
But what would I know? I use a Trackpoint keyboard, so I can scroll around in any direction without even lifting my hands from the alphanumeric keys. I'm so disappointed and puzzled that those horrible touchpads so completely wiped out trackpoints.
BTW, extra points for the first response identifying a programming language that doesn't use a tree structure internally, even conceptually. Let me give a little hint for one of the possible answers: probably more programs are written in this language every day than all the other languages combined, but normally no human writes them and no human reads them.
-Billy
If you remember the interview with Chuck Moore (of Forth fame) a while back, he was promoting a chip kinda like this. 25 CPUs all on one chip (5x5), with a grid of 18-bit busses, 5 each way, connecting them all to each other horizontally and vertically. He hadn't built any, but based on his previous chips at much larger scales, he was estimating about 2400MHz maximum bus input latency; with 10 independant busses, that means an upper bound of 10*2400M*18=432,000Mbps internal.
:-), nor to listen for any of that "information". But the sheer magnitude of the number is a bit staggering. But anyhow, yes, on-chip busses are pretty fun.
Of course, that's all noise -- none of the chips would have time to do real work
Oh, latest rumor: he took the 25x page down because he'd found a buyer. Very little other info available.
-Billy
Window-breaking also creates a lot of jobs, both for window-breakers and for glassmakers.
It's harder to see the jobs it destroys, and even harder to see the lost opportunities. But they're still lost.
The same for spammers. (Less so for telemarketers, since they're not actually charging the recipients to listen; but still true.)
-Billy
I don't want the annoying sound, but DC-comics-style sound-captions would be ...um... welcome!
/whammo/
*BING*
**CLICK**
+POW+
etc...
-Billy