BSD doesn't offer any particular features in this regard that I'm aware of. By and large, the same programs are available for both: Gnome, Festival, etc. Of course, it has an excellent package system, as we all know, so that may make it more useful to a newbie. The BSD-specific tools (such as package tools) also may be more likely to work in command-line or curses mode than some Linux analogues. (I use many BSD systems without displays, and command-line is faster for such issues than X.) I'm assuming that command-line utilities will be easier to work with a braille terminal than Gtk or other graphical utilities.
Is there a way to originate bittorrent from Unix? It looked like you needed Windows, and those of us serious enough about FreeBSD to care may not have Windows!
Because a lot of us believe that SCO has no actual basis in fact. First: their complaint is vague, and does not discuss the merits. It pretty much says, "It would impossible for Linux to be this good unless they ripped us off." (Read it. It's on SCO's homepage.) Second: they didn't follow procedures they would have if they had any basis in fact, such as filing for an injunction. Third: they have taken procedures-- such as filing in state court instead of federal-- to avoid disclosing facts.
These lead me (and probably others) to the conclusion that they are doing a lot of chest-beating and posturing, and their allegations likely have no basis in fact. They're trying to spread FUD and dissuade people from using Linux, taking advantage of the fact that a lot of people don't understand the issues (and indeed, shouldn't need to). They're doing a lot of posturing, likely on behalf of MS.
I haven't read the FSF's letter (I don't know where to find it), but they historically have been very up-front about specific issues, and have worked to a resolution. This isn't them trying to spread FUD. Some FUD may happen, but the FSF isn't pushing it.
Therefore computing the set of valid reachable states reduces to graph reachability, an O(N) algorithm.
I see that graph reachability would tell you that there exists an input for which the program will terminate. I don't (yet) believe, though, that it would tell you that it would terminate for any arbitrary input.
Let me try another tack. What aspect of the halting problem limits it to TMs? Could you not apply the same reasoning to DFAs? (Here, our halting-solver is implementable on a computer, therefore representable as a DFA, not just a TM.)
Now the reason that this algorithm is infeasible for modern computers has nothing to do with the halting problem; it's because even though the algorithm is linear, N in this case is monumentally huge.
Oh, I agree entirely that all this would be manifestly impractical; that aspect of the OP's question was answered long ago. I'm just playing with the mathematical feasibility of his thought.
While the computer has a finite set of states, there is still the question of whether any of the solution states are reachable given arbitrary input. That's why the halting problem would come into play.
Given a finite set of initial states S0, and an alphabet A, you could partition S0 into two groups. First, Sl: the states which will, for every token in A, enter a state in S0. Second, Sn: the states which will not. You can continue this process iteratively on Sn for further tokens in A. But here's the trick: even though the computer is finite, the number of possible inputs are not. To put it a different way, the number of finite substrings of inputs is infinite. That's why I feel you would have to be able to solve the halting problem to prove that an arbitrary program will halt with arbitrary finite input.
Yes, you can often prove that a given program halts, or doesn't. I was referring to the general case. To solve whether any arbitrary program is correct, you must be able to determine that an arbitrary program will terminate.
If you're willing to restrict yourself to a subset of programs, then yes, you can prove whether their output is correct.
The theoretical solution this suggests is to restrict yourself to writing programs which can be proven. In practice, people don't prove all their programs, but approaching this-- such as with preconditions and postconditions-- can improve reliability and aid analysis.
Proofs are, of course, rarely practical. Besides the time it takes, it's too easy to make mistakes in proofs. I believe that "Expert C Programming" (which I highly recommend, even to people who generally use languages other than C) has an excellent example of this.
Assuming that the hardware is ok, you can prove that a system is reliable for any given finite input (including, most importantly, all possible finite substrings of inputs,
That sounds like it would require you to solve the halting problem, so I'd say it wouldn't be possible.
I used to work in PC repair. A lot of cases don't need much at all. I've had a few where I didn't even turn the computer on to fix it, just to test it. (The volume knob was all the way down.) But a lot of cases need more extensive scrutiny.
Disk space is a common one. Porn archives are usually big. If you're tracing down where all the disk space has gone, you'll pretty quickly narrow it down to the 60 GB of porn.
How about routine maintenance? Virus scanners, scandisk, etc, etc? These sit there and list the files as they're scanning. If 80% of the drive is porn, then 80% of the time, there'll be a porn filename on the screen. Just checking the screen to see if a scan is done hands you a dead giveaway. Some users file their porn in C:\Windows\Temp. If you go to clear out temp as part of regular maintenance, or because of a busted install... (some install programs, if they failed or wrere cancelled, would keep failing until you clear their files out of Temp.)
On that thread, a lot of people file their porn in places that are routinely seen by technicians, mostly on the grounds that these are places the wife would never look. C:\Windows\DAVES-KRAD-PR0N is a bit obvious, but C:\Windows\Options\Cabs\FOO is also obviously out-of-place. If you're reinstalling from there, then you see the directories. I had one customer with a vast porn archive in C:\DOS. I noticed because I found that \command.com and \dos\command.com were out of sync, so I decided to check the rest of the directory.
Every now and then, you get a recurring problem that defies analysis. To fix those, you sometimes have to comb the computer looking for any sort of clues at all. Part of that is to see what all is on the computer. To continue from ColaMan's analogy, suppose you have a stash of porn under your back seat. (I'm not going to ask why.) You ask a mechanic to find a rattle. He checks the dash, looks for loose items on the floorboard and in the trunk, and checks out the engine and suspension. After failing to find the rattle, he may need to comb the entire car from bumper to bumper. While doing this, he's sure to find the porn stash.
The diary analogy is quite different. You assume purpose to open and examine the diary, rather than simply stumbling across an openly identifiable porn stash.
In my own dealings, I try to keep a level of professional integrity and privacy in my customers' personal files. I don't mention anything to coworkers who don't have a need to know. I certainly don't mention anything to SOs unless I'm already certain that they know (such as knowing about this from a personal relationship). To prevent the customer from embarrassment, I don't let on to the customer what I've seen, unless directly asked. If it becomes necessary (for example, they ask where all their disk space has gone), I may refer to the files as something like "a collection of files in C:\Junk" (no childish winks, nudges or other allusions that I even know the filenames).
I have never come across kiddie porn. Usually, I only see that there's a bunch of.JPG files in an obscurely named directory, and I don't normally see a need to examine the actual images. So I wouldn't know kiddie porn from any other large JPEG collection. I also have never done desktop support in a corporate environment. So I haven't tested my reactions in those circumstances. Fortunately, I don't do support anymore, so I hope I never will have to.
Because I mixed up theater names and was, in fact, talking about Century 21. The Mercado was in my head because somebody mentioned it the other day. Oops!
I don't usually like to drive all the way to SF for most movies. (I live and work in Sunnyvale.) I personally prefer to go to Century Great Mall in Milpitas: every screen THX certified! For some reason, though, it's usually easier to convince friends to go to AMC Mercado 20 in Santa Clara. Also a worthy theater, very easy to get to. For the AMC, be sure to get tickets online first.
I know, I was just yanking your chain. I started teaching myself Scheme from R4RS. At the time, I figured, "I want to write portable programs, so I'd better use only the essential syntax". I learned later that, in practice, you can use the "new" syntax.
Ask any LISP programmer how well they could work if they
weren't allowed to redefine the language (redefine it on-the-fly,
even). Operator overloading is not bad; it's reckless use of
overloading which is bad.
First: I am a Lisp programmer. I got lucky when my boss asked me
to write a particularly hairy program: I said, "I'll need to write it
in Lisp" and he said "Okay". And I agree with what you say about
changing the language.
Second: Non-Lisp programmers are going to be a bit confused by
this. For their benefit, I'll briefly say that Lisp defines methods
as specializations of functions, not as functions on classes. In
other words, you don't define class FOO and a method BAR on class FOO;
you define a generic function BAR, and a method for when BAR is called
on a FOO. This is called "generic function" OOP, as opposed to
"message passing" OOP like Smalltalk, Java, C++, Perl, etc use.
That said, I'm going to make the assertion that Common Lisp does
not quite allow operator overloading, although it gets close.
Consider the operator + that you use in your examples. Suppose that I
invent a type QUATERNION. (Google it if you care; it's a numeric type
often used in 3d simulation. I'd use complex numbers, but CL defines
them.) Now, even though addition of quaternions is defined, I can't
overload + to do this.
Okay, I'm ambiguous. I can make a QUATERNION:+ generic function,
and set its unqualified method to dispatch CL:+ if I want. But this
won't affect any code which isn't importing the QUATERNION:+ symbol.
Defining QUATERNION:+ in such a manner is the same as defining a
function QUATERNION:ADD. I'm not sure this would be usefully
considered operator overloading.
Of course, the limitation I'm describing is equivilent to a
limitation in C++: the relevant header file be #included. It's
necessary for C++, since it needs to know (for instance) which method
to dispatch based on the second arg, or how it needs to cast the
second arg.
So what's the point of my rant, you ask? Lisp operator overloading
is as good as overloading in any other language, right?
Well, not quite. Suppose in addition to QUATERNION:+, you also
have a HYPERCOMPLEX type (in the Davenport sense; again, it's another
numeric type that CL doesn't define). It defines its own
HYPERCOMPLEX:+. The two packages don't know about each other. So now
you have two + symbols (three if you count CL:+) and you can only
import one. One reasonable solution would be to import neither;
define your own CL-USER::+ generic function, with appropriate methods.
But that's exactly what operator overloading is supposed to do; you're
now doing the work of the OOP system. Granted, it's not particularly
onerous work. The advantages of CLOS far outweigh this minor
inconvenience. But I don't think it's fair to say that CL has
operator overloading.
Okay, this example is a bit contrived. Who's going to use all
these different numeric types? Well, let's switch to another
operator, then: EQUALP. This may be something you've heard about if
you read comp.lang.lisp. As you know, for any instance object, EQUALP
behaves as EQ: it doesn't descend the structure. A lot of people
define their own structures. The implementors of QUATERNION and
HYPERCOMPLEX certainly would like EQUALP (or even EQL) to do the
"obvious" things to their structures. So questions keep coming up
about making EQUALP a generic function.
Kent Pitman provides the most eloquent answers to this question.
You'll sometimes see them in c.l.l, such as this
article. (This article also discusses a similar problem with overloading +.) He also has written
Of course, that syntax wasn't guaranteed to work until R5RS, and even then it was done to conform with IEEE's doing away with optional ("non-essential") features in their own standard.
Not to mention that even R5RS uses (define foo (lambda...)) more often than (define (foo...)...)
You say this happened in Canada, but you used American money? I live nowhere near that border; what's up with that?
Anyway, regarding the guys with $1000 bills: The "legal tender" doesn't mean that somebody has to accept it, except the Federal Reserve. If the seller and the buyer can't agree on an instrument of payment, then there's just no sale. Yeah, the guy with the $1000 bill wouldn't have to pay-- but the store doesn't have to give him their product!
By the way: the $1000 bill hasn't been issued since 1969, and the Federal Reserve pulls them from circulation.
A user (who shall remain nameless) was learning Vi from a really bad tutorial, that didn't mention that bit. The user was confounded, until he used Vigor and got the hint. The user wrote me, and thanked me for writing Vigor! Since Vigor must be utterly useless, I had to change that hint. It now says:
You have not entered insert mode before. While you're in insert mode, remember that you need to return to command mode before entering Vigor commands!
As an aside: To make edits, I'll often open something like "/usr/local/src/vigor/vigor/vigor.tcl". There's something scary about saying his name three times like that...
Don't forget Yu-Gi-Oh, which while admittedly a half-hour commercial (which is why I quit watching it this season), very strongly follows the traditional "good vs evil" idea. Evil sorcerors from ancient egypt trying to conquer the world, and the only one who can stop them is the Pharoah's reincarnation in a young boy.
Digimon varied depending on when you watched it... it sometimes was the "band of friends" thing, but sometimes was the "fighting to overthrow oppressive tyrant" thing.
Your posts in this discussion seem unusually well-informed and thoughtful. You do realize this is/., right? You're supposed to make stuff up and spout it off the cuff!:-)
Seriously, though, what is your audio background, if I may ask?
Slashdot Mirror
I do. That's why I posted this comment... to bring the count up to 5.
What's that across the front that looks like a row of LEDs?
BSD doesn't offer any particular features in this regard that I'm aware of. By and large, the same programs are available for both: Gnome, Festival, etc. Of course, it has an excellent package system, as we all know, so that may make it more useful to a newbie. The BSD-specific tools (such as package tools) also may be more likely to work in command-line or curses mode than some Linux analogues. (I use many BSD systems without displays, and command-line is faster for such issues than X.) I'm assuming that command-line utilities will be easier to work with a braille terminal than Gtk or other graphical utilities.
Is there a way to originate bittorrent from Unix? It looked like you needed Windows, and those of us serious enough about FreeBSD to care may not have Windows!
Because a lot of us believe that SCO has no actual basis in fact. First: their complaint is vague, and does not discuss the merits. It pretty much says, "It would impossible for Linux to be this good unless they ripped us off." (Read it. It's on SCO's homepage.) Second: they didn't follow procedures they would have if they had any basis in fact, such as filing for an injunction. Third: they have taken procedures-- such as filing in state court instead of federal-- to avoid disclosing facts.
These lead me (and probably others) to the conclusion that they are doing a lot of chest-beating and posturing, and their allegations likely have no basis in fact. They're trying to spread FUD and dissuade people from using Linux, taking advantage of the fact that a lot of people don't understand the issues (and indeed, shouldn't need to). They're doing a lot of posturing, likely on behalf of MS.
I haven't read the FSF's letter (I don't know where to find it), but they historically have been very up-front about specific issues, and have worked to a resolution. This isn't them trying to spread FUD. Some FUD may happen, but the FSF isn't pushing it.
Therefore computing the set of valid reachable states reduces to graph reachability, an O(N) algorithm.
I see that graph reachability would tell you that there exists an input for which the program will terminate. I don't (yet) believe, though, that it would tell you that it would terminate for any arbitrary input.
Let me try another tack. What aspect of the halting problem limits it to TMs? Could you not apply the same reasoning to DFAs? (Here, our halting-solver is implementable on a computer, therefore representable as a DFA, not just a TM.)
Now the reason that this algorithm is infeasible for modern computers has nothing to do with the halting problem; it's because even though the algorithm is linear, N in this case is monumentally huge.
Oh, I agree entirely that all this would be manifestly impractical; that aspect of the OP's question was answered long ago. I'm just playing with the mathematical feasibility of his thought.
While the computer has a finite set of states, there is still the question of whether any of the solution states are reachable given arbitrary input. That's why the halting problem would come into play.
Given a finite set of initial states S0, and an alphabet A, you could partition S0 into two groups. First, Sl: the states which will, for every token in A, enter a state in S0. Second, Sn: the states which will not. You can continue this process iteratively on Sn for further tokens in A. But here's the trick: even though the computer is finite, the number of possible inputs are not. To put it a different way, the number of finite substrings of inputs is infinite. That's why I feel you would have to be able to solve the halting problem to prove that an arbitrary program will halt with arbitrary finite input.
Yes, you can often prove that a given program halts, or doesn't. I was referring to the general case. To solve whether any arbitrary program is correct, you must be able to determine that an arbitrary program will terminate.
If you're willing to restrict yourself to a subset of programs, then yes, you can prove whether their output is correct.
The theoretical solution this suggests is to restrict yourself to writing programs which can be proven. In practice, people don't prove all their programs, but approaching this-- such as with preconditions and postconditions-- can improve reliability and aid analysis.
Proofs are, of course, rarely practical. Besides the time it takes, it's too easy to make mistakes in proofs. I believe that "Expert C Programming" (which I highly recommend, even to people who generally use languages other than C) has an excellent example of this.
Assuming that the hardware is ok, you can prove that a system is reliable for any given finite input (including, most importantly, all possible finite substrings of inputs,
That sounds like it would require you to solve the halting problem, so I'd say it wouldn't be possible.
IIRC, the whistleblower laws only apply to somebody blowing the whistle on companies cheating the gov't.
I used to work in PC repair. A lot of cases don't need much at all. I've had a few where I didn't even turn the computer on to fix it, just to test it. (The volume knob was all the way down.) But a lot of cases need more extensive scrutiny.
Disk space is a common one. Porn archives are usually big. If you're tracing down where all the disk space has gone, you'll pretty quickly narrow it down to the 60 GB of porn.
How about routine maintenance? Virus scanners, scandisk, etc, etc? These sit there and list the files as they're scanning. If 80% of the drive is porn, then 80% of the time, there'll be a porn filename on the screen. Just checking the screen to see if a scan is done hands you a dead giveaway. Some users file their porn in C:\Windows\Temp. If you go to clear out temp as part of regular maintenance, or because of a busted install... (some install programs, if they failed or wrere cancelled, would keep failing until you clear their files out of Temp.)
On that thread, a lot of people file their porn in places that are routinely seen by technicians, mostly on the grounds that these are places the wife would never look. C:\Windows\DAVES-KRAD-PR0N is a bit obvious, but C:\Windows\Options\Cabs\FOO is also obviously out-of-place. If you're reinstalling from there, then you see the directories. I had one customer with a vast porn archive in C:\DOS. I noticed because I found that \command.com and \dos\command.com were out of sync, so I decided to check the rest of the directory.
Every now and then, you get a recurring problem that defies analysis. To fix those, you sometimes have to comb the computer looking for any sort of clues at all. Part of that is to see what all is on the computer. To continue from ColaMan's analogy, suppose you have a stash of porn under your back seat. (I'm not going to ask why.) You ask a mechanic to find a rattle. He checks the dash, looks for loose items on the floorboard and in the trunk, and checks out the engine and suspension. After failing to find the rattle, he may need to comb the entire car from bumper to bumper. While doing this, he's sure to find the porn stash.
The diary analogy is quite different. You assume purpose to open and examine the diary, rather than simply stumbling across an openly identifiable porn stash.
In my own dealings, I try to keep a level of professional integrity and privacy in my customers' personal files. I don't mention anything to coworkers who don't have a need to know. I certainly don't mention anything to SOs unless I'm already certain that they know (such as knowing about this from a personal relationship). To prevent the customer from embarrassment, I don't let on to the customer what I've seen, unless directly asked. If it becomes necessary (for example, they ask where all their disk space has gone), I may refer to the files as something like "a collection of files in C:\Junk" (no childish winks, nudges or other allusions that I even know the filenames).
I have never come across kiddie porn. Usually, I only see that there's a bunch of .JPG files in an obscurely named directory, and I don't normally see a need to examine the actual images. So I wouldn't know kiddie porn from any other large JPEG collection. I also have never done desktop support in a corporate environment. So I haven't tested my reactions in those circumstances. Fortunately, I don't do support anymore, so I hope I never will have to.
Because I mixed up theater names and was, in fact, talking about Century 21. The Mercado was in my head because somebody mentioned it the other day. Oops!
You mean there's still geeks in the Silicon Valley? I thought they all moved to Austin!
I don't usually like to drive all the way to SF for most movies. (I live and work in Sunnyvale.) I personally prefer to go to Century Great Mall in Milpitas: every screen THX certified! For some reason, though, it's usually easier to convince friends to go to AMC Mercado 20 in Santa Clara. Also a worthy theater, very easy to get to. For the AMC, be sure to get tickets online first.
They're suing IBM. This is like getting in a fistfight with a train.
I know, I was just yanking your chain. I started teaching myself Scheme from R4RS. At the time, I figured, "I want to write portable programs, so I'd better use only the essential syntax". I learned later that, in practice, you can use the "new" syntax.
First: I am a Lisp programmer. I got lucky when my boss asked me to write a particularly hairy program: I said, "I'll need to write it in Lisp" and he said "Okay". And I agree with what you say about changing the language.
Second: Non-Lisp programmers are going to be a bit confused by this. For their benefit, I'll briefly say that Lisp defines methods as specializations of functions, not as functions on classes. In other words, you don't define class FOO and a method BAR on class FOO; you define a generic function BAR, and a method for when BAR is called on a FOO. This is called "generic function" OOP, as opposed to "message passing" OOP like Smalltalk, Java, C++, Perl, etc use.
That said, I'm going to make the assertion that Common Lisp does not quite allow operator overloading, although it gets close. Consider the operator + that you use in your examples. Suppose that I invent a type QUATERNION. (Google it if you care; it's a numeric type often used in 3d simulation. I'd use complex numbers, but CL defines them.) Now, even though addition of quaternions is defined, I can't overload + to do this.
Okay, I'm ambiguous. I can make a QUATERNION:+ generic function, and set its unqualified method to dispatch CL:+ if I want. But this won't affect any code which isn't importing the QUATERNION:+ symbol. Defining QUATERNION:+ in such a manner is the same as defining a function QUATERNION:ADD. I'm not sure this would be usefully considered operator overloading.
Of course, the limitation I'm describing is equivilent to a limitation in C++: the relevant header file be #included. It's necessary for C++, since it needs to know (for instance) which method to dispatch based on the second arg, or how it needs to cast the second arg.
So what's the point of my rant, you ask? Lisp operator overloading is as good as overloading in any other language, right?
Well, not quite. Suppose in addition to QUATERNION:+, you also have a HYPERCOMPLEX type (in the Davenport sense; again, it's another numeric type that CL doesn't define). It defines its own HYPERCOMPLEX:+. The two packages don't know about each other. So now you have two + symbols (three if you count CL:+) and you can only import one. One reasonable solution would be to import neither; define your own CL-USER::+ generic function, with appropriate methods. But that's exactly what operator overloading is supposed to do; you're now doing the work of the OOP system. Granted, it's not particularly onerous work. The advantages of CLOS far outweigh this minor inconvenience. But I don't think it's fair to say that CL has operator overloading.
Okay, this example is a bit contrived. Who's going to use all these different numeric types? Well, let's switch to another operator, then: EQUALP. This may be something you've heard about if you read comp.lang.lisp. As you know, for any instance object, EQUALP behaves as EQ: it doesn't descend the structure. A lot of people define their own structures. The implementors of QUATERNION and HYPERCOMPLEX certainly would like EQUALP (or even EQL) to do the "obvious" things to their structures. So questions keep coming up about making EQUALP a generic function.
Kent Pitman provides the most eloquent answers to this question. You'll sometimes see them in c.l.l, such as this article. (This article also discusses a similar problem with overloading +.) He also has written
No, no, to really make your Scheme code better, you need to use obscure CS techniques that are very very rarely used in the real world!
As an aside: How are you supposed to preserve indentation within a /. ECODE? Is it a conspiracy against Python users?
Of course, that syntax wasn't guaranteed to work until R5RS, and even then it was done to conform with IEEE's doing away with optional ("non-essential") features in their own standard.
Not to mention that even R5RS uses (define foo (lambda ...)) more often than (define (foo ...) ...)
You say this happened in Canada, but you used American money? I live nowhere near that border; what's up with that?
Anyway, regarding the guys with $1000 bills: The "legal tender" doesn't mean that somebody has to accept it, except the Federal Reserve. If the seller and the buyer can't agree on an instrument of payment, then there's just no sale. Yeah, the guy with the $1000 bill wouldn't have to pay-- but the store doesn't have to give him their product!
By the way: the $1000 bill hasn't been issued since 1969, and the Federal Reserve pulls them from circulation.
Also see Snopes on legal tender, and the US Treasury FAQ.
Actually, I had to change the "press [esc]" hint.
A user (who shall remain nameless) was learning Vi from a really bad tutorial, that didn't mention that bit. The user was confounded, until he used Vigor and got the hint. The user wrote me, and thanked me for writing Vigor! Since Vigor must be utterly useless, I had to change that hint. It now says:
As an aside: To make edits, I'll often open something like "/usr/local/src/vigor/vigor/vigor.tcl". There's something scary about saying his name three times like that...
Don't forget Yu-Gi-Oh, which while admittedly a half-hour commercial (which is why I quit watching it this season), very strongly follows the traditional "good vs evil" idea. Evil sorcerors from ancient egypt trying to conquer the world, and the only one who can stop them is the Pharoah's reincarnation in a young boy.
Digimon varied depending on when you watched it... it sometimes was the "band of friends" thing, but sometimes was the "fighting to overthrow oppressive tyrant" thing.
So a wall's reflected frequency response is more or less flat?
Your posts in this discussion seem unusually well-informed and thoughtful. You do realize this is /., right? You're supposed to make stuff up and spout it off the cuff! :-)
Seriously, though, what is your audio background, if I may ask?