It just points you to a section of copyright law you didn't know about. For computer programs, there is an explicit exception written into the law allowing modifications if:
1) Someone owns a copy of a program 2) The modifications are an essential step in the utilization of the program 3) The modified program is used "for no other purpose". I'm not sure what this means, but presumably it doesn't let you run a web service with a modified version of Word 5.
Written licenses are able to change all or most of this, by converting the case into one of contract violation instead of copyright infringement, but part of the point in this case was the lack of an explicit written license.
This case appeared to be a lot closser to the latter case than it does to the former.
That's only because of the summary and sloppy reporting in TFA. The programmer in question was an independent contractor, as the opinion makes clear.
So it's analogous to hiring Joe from Joe's Photography to come and take pictures, and then making modifications to the pictures as an essential step to utilizing them. I'm not sure what that means with pictures (maybe, clipping them to fit in a frame?), but I think we all have some idea what it means with software.
Officially, there's no policy against IRC or IM, and in fact IM is heavily used for business purposes here. However, there is a corporate policy that VirusScan Enterprise (from McAfee) be installed on all windows machines, and installed via the central configuration, so that no one can change any settings.
Starting with version 8.0, (did I mention that automatic upgrades were part of the locked down configuration?) all communication to "IRC ports" is blocked by VirusScan Enterprise. I can see the setting that does this; it's pretty clearly labeled and check-marked, but I cannot change it.
So there's a resource that the company will never benefit from; I hope the satisfaction of having virus control nailed down is worth the tradeoff...
Actually, thinking about it, I'd be much calmer about their code if the safeEvalPerl sub read like this:
# Allow only simple math with operators - + * / % ( ) # (shh... don't tell anyone, we support comparison operators) my ($termre, $opre, $expre); $opre = qr{ [!<>=]= | [<>-+*/%] }x; $termre = qr{ [0-9]+(?:\.[0-9]*)? | \( (??{$expre}) \) }x; $expre = qr{ $termre (?: $opre $termre )* }x; sub safeEvalPerl {
my( $theText ) = @_;
$theText =~ s/\s+//g; # spaces don't change meaning; simplifies our regexp above
$theText =~ m{^($expre)$}
or return "ERROR: syntax error or unsafe construct in '$theText'";
$theText = $1; # untainted variable
return "" unless( $theText );
local $SIG{__DIE__} = sub { TWiki::Func::writeDebug($_[0]); warn $_[0] };
my $result = eval $theText;
# at this point, put in the result of their code here
With that code it's much easier to glance at it and verify that it is indeed allowing through only what is intended by explicitly specifying a grammar to match, instead of hoping that perl will throw syntax errors when the jumble of characters your regexp let through doesn't make sense.
I like what you've done by way of replacing backticks/qx with something that calls the multi-arg form of system. However, I do take issue with this statement:
SpreadSheetPlugin uses regular expressions to ensure that strings which are passed to eval are harmless. While I could not discover an exploit, this approach should be considered poor engineering from a security standpoint.
While it is certainly easy to use regular expressions in this manner to produce code that qualifies as poor engineering from a security standpoint, the regular expressions that SpreadSheetPlugin uses are actually simple enough to be easily verifiable, or would be if they reduced their excessive use of backslashes down to something readable.
For instance, I would rewrite the first half of their safeEvalPerl subroutine as:
sub safeEvalPerl {
my( $theText ) = @_;
# Allow only simple math with operators - + * / % ( )
# (shh... don't tell anyone, we support comparison operators)
$theText =~ m{^(!<=>-+*/0-9.()%\s]*)$}
or return "ERROR: unsafe eval attempted";
$theText = $1; # untainted variable
if ($theText =~ m{(^|[^0-9.\)\s])\s*[%*]}) {
# catch attempted hash/glob access
return "ERROR: unsafe eval attempted";
}
return "" unless( $theText );
local $SIG{__DIE__} = sub { TWiki::Func::writeDebug($_[0]); warn $_[0] };
my $result = eval $theText;
# at this point, put in the result of their code here
I will admit that the excessive use of eval elsewhere in that module (why are they using the string form of eval, and not the block form?) gives me the security heebie-jeebies. Every spot I found was good, but I had to check too closely.
In your "For Developers" section I would add these suggestions:
When you discuss Perl's open function, tell everyone to use the three-argument form when possible. This has been available since at least perl 5.6 and eliminates a whole host of potential security problems.
If you are using eval only to trap die(), and not to do the kind of thing that requires extensive security checking, then use the block form of eval, not the string form. (e.g. the only two places SpreadSheetPlugin should be using the string form of eval are inside safeEvalPerl and when they need to use tr///)
Don't attempt to defang malicious input. If input is not demonstrably benign, reject it outright. (I mean, escape or quotemeta() stuff what needs escaping, but if you find yourself removing "unsafe" characters or replacing them with spaces, that's a good sign that you should be rejecting the input instead)
What on earth is it about perl that makes it any less secure than python? I've seen some doosies in python caused by people casually encoding object.repr() into a link parameter and then eval()'ing it on the webserver when someone clicks on the link.
Perl, not having a default repr() method that spits out eval()-able code doesn't encourage that particular brand of insecurity. Also, one would think that taint mode would prevent many similar web programming bugs. (No, taint mode isn't a panacea, but it's better than nothing)
And yet, I'll agree that the press for perl has lately been exceedingly bad. What's going on here?
((The particular commercial python application referenced above was still doing this last I checked, only now they use some homegrown encryption scheme on the repr() bit and tag each link with a checksum of the included data and the session id. They aren't using a real stream or block cipher (the same characters in the same string position always map to the same characters, regardless of what precedes or follows), and the checksum appears to be only 16 bits, so they're still moderately insecure, but I haven't gone through the exercise of cracking it. At least it's no longer a big huge red flashing light saying "hack us here; we're flamingly insecure".))
I decided to try out google earth and the first thing I do is look up my house an the church about a mile down the road where I got married - and the pictures there were slightly better than what can be seen on google maps, so not terribly impressive.
Then I tried to look at pictures of my alma mater. And got... nothing. Some indistinct mottled red and green.
It's not as though Northfield, MN is really all that rural; I kind of expected bad results when searching for some really rural place in wisconsin, but I got nothing better when looking at a town that is, essentially, a far-flung suburb of Minneapolis.
And what's with the entire state of Indiana being provided in a different color from surrounding states?
I worry a bit that you're conflating the academic background associated with CS departments with a piece of paper that certifies one has done time near a CS department and paid the appropriate tuition. (I paid the requisite tuition but did my time one door to the left and so have a degree in math)
I agree that the academic side of CS is at least interesting, even if I find precious little application in my day job. However, I'm not sure how important the undergraduate CS curriculum is as an introduction to the area of study - in CS, there are today so many cutting-edge academic papers available freely online, and so many wonderfully readable introductions, not to mention newsgroups, discussion boards, wikis, etc. that any motivated student needs only a web browser and time.
An unmotivated student isn't going to learn the theory if you sit over them with a whip and a chair, or is going to have forgotten all their academic CS work within 3 years of graduation.
I suppose that there is a middle category of partially motivated students for whom a CS degree program will make some difference, but I wonder how big that category really is - I tend to figure that after a few years away from college, these students will have migrated into either the group that continues to learn, seek out, and read about CS theory or the group that ignores it. There might be a difference after two or three years in the workforce between someone who went through a CS degree program and someone who didn't, but after 5, 10, or more years your major won't mean squat. What will matter is whether during that time you have tried to become a better programmer, and whether you have continued to learn, study, or think about CS since you left school.
Sure it's no big deal, unless you're dealing with a pregnant woman and then the consequences for the fetus are really fucking scary. Congenital toxoplasmosis isn't as bad as some birth defects and in-utero diseases, but it's up there.
This is why my dad always made sure that emptying the litterboxes was one of my sisters' jobs when they were around so that they'd be exposed, get past it, and develop an immunity.
I alwas thought that ps script was an extension of the forth language.
Uh, no. And not the other way around either as some poster claimed. (at least your direction is more historically plausible, since Postscript first appeared in 1984 whereas Forth dates from the late 60's)
The two languages happen to both be stack-based languages, and as such are bound to look a little bit similar, but really not any more similar than, say, pascal and java.
The memory model is completely different - postscript defines commands based on dictionaries that are loaded into a separate dictionary stack, and pushing and poping the contents of that stack is a common operation, whereas Forths generally have one (or sometimes two) global dictionary that can occasionally be switched out. Also, Forth systems often deal very closely with the underlying physical memory - using a single pointer for allocating memory, for example - whereas postscript was designed to be easily runnable inside a sandbox environment, and provides no easy access to arbitrary memory locations. Also, postscript has a much more uniform syntax than Forth, lacking any feature similar to those Forth words (such as " or:) which can gobble up what follows them - this means that in postscript, you must be much more explicit whenever you need to quote anything. (usually with/)
If I ever have a child, I will instill in him the importance of intelligence and a hard work ethic if he wants to be financially successful as well as the importance of taking excellent physical care of himself if he ever wants to be desired by women or respected by society.
Yeah, because Hugh Heffner is surrounded by beautiful women constantly only because he's such an excellent physical specimen.
Most public schools promote a materialistic secular humanistic world-view. Kids that do not come from strong homes cannot fend off the destructive effects of this philosophy.
What on earth does this mean?
No, seriously: what is this world-view of materialistic secular humanism and how do public schools promote it? How does this harm children? Do you mean that the children are harmed by the absence of overt religious symbols which they experience while attending public school? What philosophy is it that you see in the schools which is radically at odds with the "real world"? (I see certain glaring differences between the world-view of, say, school and the workplace, but none of those differences are what I would label as "secular humanism")
It's not a matter of one person trespassing on the service of another person, but rather of the recording of phone conversations, which bears on the whole "hey, you became a broadcaster of your own free will" thing. In the days of analog cordless phones it used to be common that cordless phones could be heard faintly on neighbors' handsets or baby monitors, or with radio scanners.
Now, consider that anyone having conversations of an even vaguely secretive nature - that is, conversations they wouldn't want public - would be a fool to use such a cordless phone. However, people did, and sometimes their neighbors recorded the conversations, and the whole situation wound up in court. The case is McKamey v. Roach. The court found exactly the standard being advocated here - that there was no expectation of privacy when speaking over an open-air medium. In other words, your neighbors are completely free to record your conversations when they're conducted over analog broadcast signals. The courts have already ruled on this: if you become a broadcaster, you give up the right to refuse people to receive your signal, even if you became a broadcaster by buying a piece of consumer electronic equipment.
The obvious extension to sniffing unencrypted wireless packets is left as an exercise for the reader.
That's nothing - near the same place are the towns of "Blue Ball" and "Paradise", and the route between them leads, if not directly through Intercourse, pretty damn close.
I'm curious - what about writing that sort of program bothers you? I wrote such a thing in just a few lines of shell code, so I don't think it's the drudgery...
There's also the seriously hard problem of connecting good employers to good potential employees, which leads both sides to think that the other side doesn't exist.
As we've been recently going through the process of trying to hire someone, I have arrived at the conclusion that there's so much crap out there that the people who eventually are hired are hired because: 1) they were lucky and their resume was randomly picked out of the pile, and 2) they weren't obviously unqualified in any of the initial or screening interviews. Note that being extraordinarily well qualified as opposed to merely qualified is not an actual advantage to getting a job. It may affect the salary offer, but not as much as you might think. (Want a bigger salary? Ask for a bigger one initially. You'll have to then prove that you're worth it, but no one is going to notice that you're worth more and offer more without being asked.) The situation may seem slightly different at small start-ups, but only because the initial cut-off for "qualified" is often higher; it's still a case where there's no advantage in terms of getting hired beyond the "good enough" cutoff.
Seriously; we've had people come in for a job with java, dealing heavily with SQL, who couldn't write a simple query involving a "group by" aggregate. We've had people who couldn't write code that accessed an element of a two-dimensional array. It's not as though the language of the position was hidden from them - they were told well in advance of the interview that they'd be asked to write some java and SQL during the interview. More commonly than that, we've had people who appeared to have trouble working out how to structure a relatively simple algorithm that involved two nested for loops - not syntactic stuff, now, but basic thinking of the type a programmer needs to do dozens of times a day.
Those interviews are painful. Probably they're also stressful for the candidate, but they're painful for us too. Each one of them pulls us away from the real work we have to be doing, of which there's already way too much (which is why we're hiring in the first place). With that crap to wade through, we're so grateful to get an interview candidate that is a halfway decent programmer that we jump at the first chance; and unless we're hiring more people we just drop the rest of the resumes in the trash. Why would we want to subject ourselves to more of the pain of discovering more unqualified candidates? We have better things to be doing.
Now, if we had significantly lower standards for candidates, the interview process would be much less painful on both sides. We might even be able to hire people over the phone after a quick reference and background check, with no need for multi-person several-hour interviews. Of course, the pay would be considerably less, and our end products would probably reflect that. On the other hand, we'd get back to more people who submit their resumes, and the chances of a candidate being offered some job at all would go up.
This leads to the following state of affairs:
The programmer hiring process royally sucks, on both sides. On the programmer side, it appears that well over half the places he sends his resumes to are black holes, and those that do get back are the businesses that make hiring large numbers of people for cheap a priority. (Or the scammers; they'll get back to you too) On the employer side, you either have to put up with hiring low-skilled employees or put up with the pain of wading through the mass of unqualified applicants until you stumble upon someone who can in fact code their way out of a wet paper bag.
(By the way, anyone not totally repulsed by the above description of finding a job in the industry and who would like a job as a java programmer (with moderate use of SQL) in midtown Manhattan is welcome to contact me. Willingness to work as part of a small team for a soulless conglomerate serving the financial industry a plus)
As sad as this is, we've been looking for a Java developer and actually did get a resume that had college spelled "collage"; I joked to my boss that maybe an IT degree from there meant that you could take a sledgehammer to a PC and make pretty art with the results...
(By the way, know any good java people who'd be interested in working in midtown Manhattan for a soulless conglomerate implementing all sorts of buzzword-compliant stuff for the financial industry? Extra bonus points if you are comfortable making subversion do all sorts of entertaining things.)
The FCC will spank down anyone who tries to enforce "don't broadcast your evil wifi radio waves into my airspace/apartment complex/living room". However, anyone is free to say "don't connect my wired network to wireless", assuming that the network is indeed theirs.
This has usually come up in the context of landowners (airport operators, universities acting as landlords to "off campus" housing, etc.) trying to enforce a monopoly on wireless internet access while on their property. However, in the US the FCC regulates the wireless spectrum exclusively, hence the smackdowns on all "though shalt not broadcast" prohibitions. (related smackdowns occur occasionally against homeowners associations who try to prevent an FCC-licensed ham radio operator from putting an ugly-looking antenna in her yard)
But the issue of offering connectivity to a particlar (non-public) network through an unatuhorized interface is something else entirely.
It seems that your major concern is people who get a virus a second or third time.
Getting sick is no one's fault, but no one likes being known as Typhoid Mary. With the chronic offenders, publicize their identity to everyone else on the network (bulletin board, maybe an ad in the campus newspaper).
Of course, announce this policy ahead of time, make it clear and objective what someone has to do to get listed.
Technical tools to help solve a social problem are sometimes neat toys, but don't ignore the social tools to attack the social problem.
Ok, so doing this in ruby is significantly less painful than it is in perl, primarily because in perl you constantly have to watch which $ symbols you need to backslash and which you don't. Ruby, by having a string-interpolation syntax that looks nothing like its variable-access syntax, avoids this mess. (Because of this, in perl I end up just quoting the code I'm dealing with in q[] and then doing regular expression substitutions rather than relying on string interpolation)
I'm not talking about read-macros, I agree that those can get truly hairy.
However, the thing that's really nice about lisp macros (just regular macros, not read-macros) that's not handled in ruby there is that the macros create special forms. What I mean is that to invoke a function which creates a method like that in ruby you have to say:
macro_thing('new_method_name')
That is, you have to quote the new method name. (or use ruby's symbol syntax, which is a shorthand for quoting and calling intern) In lisp, the macro can handle all the quoting for you so that you just say:
(macro-thing new-method-name)
In other words, there's no second-class status imposed on macros as compared to built-in language constructs. This means that extending the language itself is natural and easy for someone writing libraries of code in the language. I believe this feature is unique to Lisp and Forth. (though I suppose that bits could be emulated through perl source filters, but those are hairy for reasons previously mentioned)
Huh. Actually, thinking about it, a string interpolation syntax that doesn't get in the way of writing stuff that is code combined with a very light-weight quoting syntax (:new_method_name) goes a long way towards lisp macros, at least towards simple ones. (I'd hate to write a macro like that in ruby that needed to expand to code that did a bunch of string interpolation, for example, which tends to put the kibosh on macros that write macros)
Re:This is not a troll, but a query...
on
Practical Common Lisp
·
· Score: 3, Informative
No, that's not what I'm asking for; although I will admit that I like Ruby's ability to pass a following code block into any function, this is really something completely different. (For non-rubyers: the poster is talking about a facility that's similar to being able to pass an anonymous function as an argument with nice, clean syntax that doesn't get in your way - similar to the way that the perl builtin sort and map functions let you pass in a block)
A macro basically allows you to rewrite code completely, reaching into the bowels (if necessary) to rip out and mangle what needs to be done.
A basic example is the setf macro. This macro is used for basic assignments:
(setf captain "Picard") (setf answer (+ 23 42))
Except, of course, that the first argument can be more than just a simple symbol:
So far... so what, right? After all, this "fancy" syntax is just equivalent to the java code:
array[0][10] = new_value; mypair.car = mynewcar;
Okay, but how about this - suppose I define some functions dealing with a simple berkeley-style database. Say, (get-from-db dbrefkeyvalue) and (set-to-db dbrefkeyvaluenewvalue). Now, if I set things up properly, I can make setf work with these functions too, so that the user can do:
(setf myprevval (get-from-db id key)) ; some calculations on the previous value here ; do some other stuff here ; some calculations to get the new value (setf (get-from-db id key) newvalue)
See how I never explicitly call my database setting function? The last line there never actually calls my get-from-db function - instead, it reaches into the parentheses and rewrites the code so that what happens is a call to set-to-db.
That is, the user never has to know about the set function. Essentially, setf means "here, in the code, where I've said setf, instead go ahead and use whatever the appropriate setter function is for a reference of this type". (when I defined my db functions, I would have to call some macros to tell setf about get-from-db and set-to-db)
Now, for this specific case - creating a unifrom set syntax for any "get"-type function you wish - Ruby has specific explicit syntax support. (just name the "set" method the same as the "get" method but add an "=" to the end of the name) Lisp, however, handles setf through the more general macro mechanism. This means that it can be extended in a bunch of different ways. For example, Lisp defines incf to mean roughly what C's "++" operator does, except again without special language support. (And incf will automaticaly take advantage of the setup I've already done for setf)
In order to do its magic, setf has to be able to access the reference (get-from-db id newval) exactly as I typed it, and has to be able to rip apart and inspect the innards. This is something only a macro can do.
Slashdot Mirror
It just points you to a section of copyright law you didn't know about. For computer programs, there is an explicit exception written into the law allowing modifications if:
1) Someone owns a copy of a program
2) The modifications are an essential step in the utilization of the program
3) The modified program is used "for no other purpose". I'm not sure what this means, but presumably it doesn't let you run a web service with a modified version of Word 5.
Written licenses are able to change all or most of this, by converting the case into one of contract violation instead of copyright infringement, but part of the point in this case was the lack of an explicit written license.
That's only because of the summary and sloppy reporting in TFA. The programmer in question was an independent contractor, as the opinion makes clear.
So it's analogous to hiring Joe from Joe's Photography to come and take pictures, and then making modifications to the pictures as an essential step to utilizing them. I'm not sure what that means with pictures (maybe, clipping them to fit in a frame?), but I think we all have some idea what it means with software.
Officially, there's no policy against IRC or IM, and in fact IM is heavily used for business purposes here. However, there is a corporate policy that VirusScan Enterprise (from McAfee) be installed on all windows machines, and installed via the central configuration, so that no one can change any settings.
Starting with version 8.0, (did I mention that automatic upgrades were part of the locked down configuration?) all communication to "IRC ports" is blocked by VirusScan Enterprise. I can see the setting that does this; it's pretty clearly labeled and check-marked, but I cannot change it.
So there's a resource that the company will never benefit from; I hope the satisfaction of having virus control nailed down is worth the tradeoff...
While it is certainly easy to use regular expressions in this manner to produce code that qualifies as poor engineering from a security standpoint, the regular expressions that SpreadSheetPlugin uses are actually simple enough to be easily verifiable, or would be if they reduced their excessive use of backslashes down to something readable.
For instance, I would rewrite the first half of their safeEvalPerl subroutine as:I will admit that the excessive use of eval elsewhere in that module (why are they using the string form of eval, and not the block form?) gives me the security heebie-jeebies. Every spot I found was good, but I had to check too closely.
In your "For Developers" section I would add these suggestions:
What on earth is it about perl that makes it any less secure than python? I've seen some doosies in python caused by people casually encoding object.repr() into a link parameter and then eval()'ing it on the webserver when someone clicks on the link.
Perl, not having a default repr() method that spits out eval()-able code doesn't encourage that particular brand of insecurity. Also, one would think that taint mode would prevent many similar web programming bugs. (No, taint mode isn't a panacea, but it's better than nothing)
And yet, I'll agree that the press for perl has lately been exceedingly bad. What's going on here?
((The particular commercial python application referenced above was still doing this last I checked, only now they use some homegrown encryption scheme on the repr() bit and tag each link with a checksum of the included data and the session id. They aren't using a real stream or block cipher (the same characters in the same string position always map to the same characters, regardless of what precedes or follows), and the checksum appears to be only 16 bits, so they're still moderately insecure, but I haven't gone through the exercise of cracking it. At least it's no longer a big huge red flashing light saying "hack us here; we're flamingly insecure".))
I decided to try out google earth and the first thing I do is look up my house an the church about a mile down the road where I got married - and the pictures there were slightly better than what can be seen on google maps, so not terribly impressive.
Then I tried to look at pictures of my alma mater. And got... nothing. Some indistinct mottled red and green.
It's not as though Northfield, MN is really all that rural; I kind of expected bad results when searching for some really rural place in wisconsin, but I got nothing better when looking at a town that is, essentially, a far-flung suburb of Minneapolis.
And what's with the entire state of Indiana being provided in a different color from surrounding states?
I worry a bit that you're conflating the academic background associated with CS departments with a piece of paper that certifies one has done time near a CS department and paid the appropriate tuition. (I paid the requisite tuition but did my time one door to the left and so have a degree in math)
I agree that the academic side of CS is at least interesting, even if I find precious little application in my day job. However, I'm not sure how important the undergraduate CS curriculum is as an introduction to the area of study - in CS, there are today so many cutting-edge academic papers available freely online, and so many wonderfully readable introductions, not to mention newsgroups, discussion boards, wikis, etc. that any motivated student needs only a web browser and time.
An unmotivated student isn't going to learn the theory if you sit over them with a whip and a chair, or is going to have forgotten all their academic CS work within 3 years of graduation.
I suppose that there is a middle category of partially motivated students for whom a CS degree program will make some difference, but I wonder how big that category really is - I tend to figure that after a few years away from college, these students will have migrated into either the group that continues to learn, seek out, and read about CS theory or the group that ignores it. There might be a difference after two or three years in the workforce between someone who went through a CS degree program and someone who didn't, but after 5, 10, or more years your major won't mean squat. What will matter is whether during that time you have tried to become a better programmer, and whether you have continued to learn, study, or think about CS since you left school.
Sure it's no big deal, unless you're dealing with a pregnant woman and then the consequences for the fetus are really fucking scary. Congenital toxoplasmosis isn't as bad as some birth defects and in-utero diseases, but it's up there.
This is why my dad always made sure that emptying the litterboxes was one of my sisters' jobs when they were around so that they'd be exposed, get past it, and develop an immunity.
Uh, no. And not the other way around either as some poster claimed. (at least your direction is more historically plausible, since Postscript first appeared in 1984 whereas Forth dates from the late 60's)
The two languages happen to both be stack-based languages, and as such are bound to look a little bit similar, but really not any more similar than, say, pascal and java.
The memory model is completely different - postscript defines commands based on dictionaries that are loaded into a separate dictionary stack, and pushing and poping the contents of that stack is a common operation, whereas Forths generally have one (or sometimes two) global dictionary that can occasionally be switched out. Also, Forth systems often deal very closely with the underlying physical memory - using a single pointer for allocating memory, for example - whereas postscript was designed to be easily runnable inside a sandbox environment, and provides no easy access to arbitrary memory locations. Also, postscript has a much more uniform syntax than Forth, lacking any feature similar to those Forth words (such as " or
No, seriously: what is this world-view of materialistic secular humanism and how do public schools promote it? How does this harm children? Do you mean that the children are harmed by the absence of overt religious symbols which they experience while attending public school? What philosophy is it that you see in the schools which is radically at odds with the "real world"? (I see certain glaring differences between the world-view of, say, school and the workplace, but none of those differences are what I would label as "secular humanism")
I ask because I often see the phrase "secular humanism" thrown around as a code-word to say "those evil people who aren't Christians". It is supposed to encompass all the wild hedonistic boogeymen the listener can think up. (Such as in this sample) As such, it is often used as a term without any meaning, but with a nudge-nudge wink-wink "they're not good like us" appeal. ("God, I thank thee, that I am not as other men are, extortioners, unjust, adulterers, or even as this publican")
So what had you in mind?
It's not a matter of one person trespassing on the service of another person, but rather of the recording of phone conversations, which bears on the whole "hey, you became a broadcaster of your own free will" thing. In the days of analog cordless phones it used to be common that cordless phones could be heard faintly on neighbors' handsets or baby monitors, or with radio scanners.
Now, consider that anyone having conversations of an even vaguely secretive nature - that is, conversations they wouldn't want public - would be a fool to use such a cordless phone. However, people did, and sometimes their neighbors recorded the conversations, and the whole situation wound up in court. The case is McKamey v. Roach. The court found exactly the standard being advocated here - that there was no expectation of privacy when speaking over an open-air medium. In other words, your neighbors are completely free to record your conversations when they're conducted over analog broadcast signals. The courts have already ruled on this: if you become a broadcaster, you give up the right to refuse people to receive your signal, even if you became a broadcaster by buying a piece of consumer electronic equipment.
The obvious extension to sniffing unencrypted wireless packets is left as an exercise for the reader.
See, now I just remember the simple equivalences:
i.e. == d.h.
e.g. == z.B.
But I'm one of those freak Americans who speak more than just one language...
That's nothing - near the same place are the towns of "Blue Ball" and "Paradise", and the route between them leads, if not directly through Intercourse, pretty damn close.
I'm curious - what about writing that sort of program bothers you? I wrote such a thing in just a few lines of shell code, so I don't think it's the drudgery...
And here I thought it was a mark of divine sanction for the Axiom of Choice. After all, doesn't it just scream Banach-Tarski Paradox to you?
There's also the seriously hard problem of connecting good employers to good potential employees, which leads both sides to think that the other side doesn't exist.
As we've been recently going through the process of trying to hire someone, I have arrived at the conclusion that there's so much crap out there that the people who eventually are hired are hired because: 1) they were lucky and their resume was randomly picked out of the pile, and 2) they weren't obviously unqualified in any of the initial or screening interviews. Note that being extraordinarily well qualified as opposed to merely qualified is not an actual advantage to getting a job. It may affect the salary offer, but not as much as you might think. (Want a bigger salary? Ask for a bigger one initially. You'll have to then prove that you're worth it, but no one is going to notice that you're worth more and offer more without being asked.) The situation may seem slightly different at small start-ups, but only because the initial cut-off for "qualified" is often higher; it's still a case where there's no advantage in terms of getting hired beyond the "good enough" cutoff.
Seriously; we've had people come in for a job with java, dealing heavily with SQL, who couldn't write a simple query involving a "group by" aggregate. We've had people who couldn't write code that accessed an element of a two-dimensional array. It's not as though the language of the position was hidden from them - they were told well in advance of the interview that they'd be asked to write some java and SQL during the interview. More commonly than that, we've had people who appeared to have trouble working out how to structure a relatively simple algorithm that involved two nested for loops - not syntactic stuff, now, but basic thinking of the type a programmer needs to do dozens of times a day.
Those interviews are painful. Probably they're also stressful for the candidate, but they're painful for us too. Each one of them pulls us away from the real work we have to be doing, of which there's already way too much (which is why we're hiring in the first place). With that crap to wade through, we're so grateful to get an interview candidate that is a halfway decent programmer that we jump at the first chance; and unless we're hiring more people we just drop the rest of the resumes in the trash. Why would we want to subject ourselves to more of the pain of discovering more unqualified candidates? We have better things to be doing.
Now, if we had significantly lower standards for candidates, the interview process would be much less painful on both sides. We might even be able to hire people over the phone after a quick reference and background check, with no need for multi-person several-hour interviews. Of course, the pay would be considerably less, and our end products would probably reflect that. On the other hand, we'd get back to more people who submit their resumes, and the chances of a candidate being offered some job at all would go up.
This leads to the following state of affairs:
The programmer hiring process royally sucks, on both sides. On the programmer side, it appears that well over half the places he sends his resumes to are black holes, and those that do get back are the businesses that make hiring large numbers of people for cheap a priority. (Or the scammers; they'll get back to you too) On the employer side, you either have to put up with hiring low-skilled employees or put up with the pain of wading through the mass of unqualified applicants until you stumble upon someone who can in fact code their way out of a wet paper bag.
(By the way, anyone not totally repulsed by the above description of finding a job in the industry and who would like a job as a java programmer (with moderate use of SQL) in midtown Manhattan is welcome to contact me. Willingness to work as part of a small team for a soulless conglomerate serving the financial industry a plus)
As sad as this is, we've been looking for a Java developer and actually did get a resume that had college spelled "collage"; I joked to my boss that maybe an IT degree from there meant that you could take a sledgehammer to a PC and make pretty art with the results...
(By the way, know any good java people who'd be interested in working in midtown Manhattan for a soulless conglomerate implementing all sorts of buzzword-compliant stuff for the financial industry? Extra bonus points if you are comfortable making subversion do all sorts of entertaining things.)
The FCC will spank down anyone who tries to enforce "don't broadcast your evil wifi radio waves into my airspace/apartment complex/living room". However, anyone is free to say "don't connect my wired network to wireless", assuming that the network is indeed theirs.
This has usually come up in the context of landowners (airport operators, universities acting as landlords to "off campus" housing, etc.) trying to enforce a monopoly on wireless internet access while on their property. However, in the US the FCC regulates the wireless spectrum exclusively, hence the smackdowns on all "though shalt not broadcast" prohibitions. (related smackdowns occur occasionally against homeowners associations who try to prevent an FCC-licensed ham radio operator from putting an ugly-looking antenna in her yard)
But the issue of offering connectivity to a particlar (non-public) network through an unatuhorized interface is something else entirely.
In "The Silver Chair" was just an absolutely brilliant bit of casting. The perfect actor for that role.
If you're doing a destructive action based on a GET request, then your application is broken.
h tml
I could quote the chapter and verse, but I'll instead assume that you can read, especially the last sentence of section 9.1.1.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.
It seems that your major concern is people who get a virus a second or third time.
Getting sick is no one's fault, but no one likes being known as Typhoid Mary. With the chronic offenders, publicize their identity to everyone else on the network (bulletin board, maybe an ad in the campus newspaper).
Of course, announce this policy ahead of time, make it clear and objective what someone has to do to get listed.
Technical tools to help solve a social problem are sometimes neat toys, but don't ignore the social tools to attack the social problem.
I'm not talking about read-macros, I agree that those can get truly hairy.
However, the thing that's really nice about lisp macros (just regular macros, not read-macros) that's not handled in ruby there is that the macros create special forms. What I mean is that to invoke a function which creates a method like that in ruby you have to say:That is, you have to quote the new method name. (or use ruby's symbol syntax, which is a shorthand for quoting and calling intern) In lisp, the macro can handle all the quoting for you so that you just say:In other words, there's no second-class status imposed on macros as compared to built-in language constructs. This means that extending the language itself is natural and easy for someone writing libraries of code in the language. I believe this feature is unique to Lisp and Forth. (though I suppose that bits could be emulated through perl source filters, but those are hairy for reasons previously mentioned)
Huh. Actually, thinking about it, a string interpolation syntax that doesn't get in the way of writing stuff that is code combined with a very light-weight quoting syntax (:new_method_name) goes a long way towards lisp macros, at least towards simple ones. (I'd hate to write a macro like that in ruby that needed to expand to code that did a bunch of string interpolation, for example, which tends to put the kibosh on macros that write macros)
A macro basically allows you to rewrite code completely, reaching into the bowels (if necessary) to rip out and mangle what needs to be done.
A basic example is the setf macro. This macro is used for basic assignments:Except, of course, that the first argument can be more than just a simple symbol:So far... so what, right? After all, this "fancy" syntax is just equivalent to the java code:Okay, but how about this - suppose I define some functions dealing with a simple berkeley-style database. Say, (get-from-db dbref keyvalue) and (set-to-db dbref keyvalue newvalue). Now, if I set things up properly, I can make setf work with these functions too, so that the user can do:See how I never explicitly call my database setting function? The last line there never actually calls my get-from-db function - instead, it reaches into the parentheses and rewrites the code so that what happens is a call to set-to-db.
That is, the user never has to know about the set function. Essentially, setf means "here, in the code, where I've said setf, instead go ahead and use whatever the appropriate setter function is for a reference of this type". (when I defined my db functions, I would have to call some macros to tell setf about get-from-db and set-to-db)
Now, for this specific case - creating a unifrom set syntax for any "get"-type function you wish - Ruby has specific explicit syntax support. (just name the "set" method the same as the "get" method but add an "=" to the end of the name) Lisp, however, handles setf through the more general macro mechanism. This means that it can be extended in a bunch of different ways. For example, Lisp defines incf to mean roughly what C's "++" operator does, except again without special language support. (And incf will automaticaly take advantage of the setup I've already done for setf)
In order to do its magic, setf has to be able to access the reference (get-from-db id newval) exactly as I typed it, and has to be able to rip apart and inspect the innards. This is something only a macro can do.