Since GPS software for Sprint cellphones costs as little as $20, and gives you an unlimited number of fixes with no monthly fee for GPS use, the load on the servers can't be very high.
Frankly, I think cell phone companies should be, but probably aren't (there was an old story about how Sprint refused to locate a cellphone in a stolen car when the car had a baby in it), willing to report coordinates to law enforcement when a theft report has been filed. (In fact, I think they should be required to do such reporting if the data is easily available to them, perhaps for a nominal service fee.)
Around here, muggers regularly steal cellphones. If one could locate the cellphone quickly, the police would be much better able to nab the mugger, unless the batteries have run out or the mugger had the sense to turn it off. Since sometimes the muggers also beat, stab or shoot people (even when the people cooperate), this would be a definite benefit.
Sprint restricts some APIs (notoriously, location services) to signed MIDlets, but otherwise you can load MIDlets and ringtones by a USB or serial cable. I think you can also set up your own server and load them up from there, but it's easier to use a cable and doesn't require data service.
It's true that they don't tell you how to use a data cable. But they haven't done anything positive to prevent it.
The claim that the computer program will have the same amount of free will that a human brain has does not follow from the premises of the argument. What follows from the premises of the argument is that the computer program's behavior will be indistinguishable from the behavior of a being with free will. (Maybe that's why "free will" was in quotation marks in the post?)
It does not logically follow from indistinguishability of behavior that there is internal indistinguishability. Indeed, the hypothesis as described does have internal distinguishability: one is silicon-based and the other is carbon-based. Both produce the same behavior, and there is nothing absurd about that. Likewise, there is nothing logically absurd about the idea that something without free will might have the same actual behavior as something with free will. Of course, one might try to argue that something deterministic cannot have the same observable behavior as something indeterministic, but that is false (any results produced by an indeterministic process could have been produced by a deterministic one instead; counterfactual results would differ, but counterfactual results are, as such, not observable).
That said, I agree that the idea that human behavior is entirely determined by the physical structure of the human brain is at odds with the idea of deserved reward and punishment. But while we are in a position to know that human behavior is significantly affected by the physical structure of the brain, we are not in a position to know that human behavior is entirely determined by the physical structure of the brain.
I am also kind of amused by the way the poster presupposes that one particular outcome would come of the brain-simulation experiment, namely that the simulated brain would behave just like the living person. It is quite a leap (of faith?) to suppose that we know what the experiment would show (viz., sameness of behavior). And if we don't know what the experiment would show, then we don't know that there is any issue to worry about.
I've used Palms/Clies for ebooks (lots of stuff can be stored on a 1gb SD card, and I have a lot of books relevant to my academic work), movies (tcpmp is great, except for the MPEG-4 patent issues which I solved by actually getting a patent license from MPEG LA), WiFi-based web browsing and email, audio books, games, notes, appointments and addresses.
For those of us who need good search capabilities for ebooks (e.g., scholarly texts), dedicated ebook readers are not an option (despite how nice e-ink is). Cellphones are definitely not an option for ebook reading, given their small screens. I like to have the complete works of St Thomas Aquinas in my pocket, seven volumes of Leibniz, a bunch of stories and novels, etc., mostly in Plucker format. I actually prefer reading in ebook format--no need to think about bookmarking (though of course if I have a crash, I might lose my place), I can carry around lots and lots of books, access lexical tools, search, insert annotations (Plucker's annotation support is now adequate but not very good--I need to improve it), read in the dark, etc.
The 320x480 screen of a hi-res+ device is a good option for movies--iPods have smaller screens, I think. My four-year-old daughter gets to watch movies on trips. When we get a new movie at home, she asks me to "make a copy" for putting on the PDA. (I've had to explain to her that I can't do that if we don't own the DVD.)
Text input is better than on a cell-phone (I use the ATOMIK on-screen keyboard on a TX; it's not quite as good as a Clie's keyboard, which in turn isn't quite as good as a blackberry's or Treo's, but it's OK, apart from some hardware flaws in the TX digitizer (I am the developer for the keyboard software, so I'm biased)). It's OK for short emails, notes that are one or two sentences long.
I don't do much in the way of gaming these days, but I have a couple of games loaded.
Unfortunately, the TX is not perfectly stable (the worst of what I use is the included VersaMail email client). But it's pretty good if one is careful about what one installs. I rarely get a reset, unless I'm testing buggy pre-release software (say, my own).
It would be nice if the TX was also a cellphone--one less thing to carry--but Treo screens are too small for extensive ebook use, I suspect.
When the T5 came out, it had significantly longer battery life than the T3, in part due to shifting to flash instead of RAM as the main storage medium. All TX accessories are backwards compatible with the T5, so the T5 is a device that was off the market for more than three months--indeed for more than a year--and has the same connector and the accessories are all compatible. I find the screen on my TX just fine. In fully bright sunlight, you can even turn off the backlight (using a third party utility). Yes, it would be nice if it worked better in bright sunlight, but it's OK.
The no-hacks claim is simply false. Igor Nestorov's YAHM is an excellent, stable hack manager for OS 5 (and pre-OS 5) devices, and developing hacks for OS 5 is about as easy as for pre-OS 5. Yes, when OS 5 came out, that killed earlier hacks, because those were meant for patching a 68K-based OS. But now we have YAHM and a perfectly good SDK for it, with a number of examples included, and there are or have been a number of YAHM-based hacks to do things like emulating arrow keys for different devices, supporting serial keyboards, antialiasing fonts, forcing a particular display mode, making hidden volumes visible, etc.
Of course, YAHM is not supported by Palm, and theoretically a new OS revision could break it. But the same was always true for hacks.
Actually, with tools like Peal (open source, I am pretty sure), doing completely or almost completely ARM-based applications (e.g., tcpmp) is not hard at all. One issue is calling back to the OS, which normally goes ARM->68K->ARM, but this can be fixed by using the unofficial Mobile-Stream SDK which lets you call the OS directly from ARM code.
I do a lot of programming on the ARM side as I sell an antialiased font hack (FontSmoother), and in my experience ARM code is, if anything, more stable.
That said, for standard applications, one doesn't need ARM, except maybe for some small CPU-intensive procedure. With practice, these are easy to do and do not affect stability.
It would have been nice if Palm/PalmSource released an SDK for doing ARM-only applications, but the reverse-engineered stuff in the Mobile-Stream SDK is pretty good.
Yes, this works but it is counterintuitive (F2 isn't intuitive, except maybe to Excel users, btu it also isn't counterintuitive). One would expect ENTER on a file to launch the file, ENTER being a standard key for execute, confirm, do, etc.
Moreover, remember the poster who said that the right criterion is not whether it is obvious, but whether it is obvious given the problem. I don't know patent law, so I don't know if this is the right criterion, but if it is, then a portable device for email IS obvious. It's obvious as a solution to the problem of how a businessperson can get email while traveling without carrying a large device and without the device having to be connected by wire to anything. Namely, he does it by carrying... gasp... a small device and connecting it... gasp... wirelessly. Now HOW to do this may involve some non-obvious, patentable processes (how to make a small enough device with enough computing power, how to make powerful enough batteries, etc.) But the idea of doing this in some way or other is obvious once one is clear on what the problem is.
Does anybody know if the conditional formulation "obvious given the problem" is the right one in US patent law? I agree with the poster that this would probably rule out a ton of patents, since once one identifies the problem, often--but not always--the solutions are pretty obvious. But identifying the problem can be hard.
Ditto on the Palm TX. It's looking like they couldn't have tested on any Palm devices (or maybe any NVFS-based ones), because I have yet to hear of it working with some Palm device.
How about testing, manufacturing (new box, new CD/DVDs), modifying documentation, training customer support to deal with an OS they're not used to, etc.? Sure, one could skip the testing, manufacturing, documenting and customer support and mail out the software on CD-Rs in generic jewel cases with handwritten "NO SUPPORT AVAILABLE" labels (and even that takes work), but the company has a reputation to keep up, and people would probably feel odd about paying $50 for that. (But then I am not much of a gamer--I've never spent more than $10 on a single computer game.)
All currently produced phones in the US have GPS or AGPS (assisted GPS--works better in urban areas, by adding information from a server) for E911 purposes. Whether one can use the GPS or AGPS system for one's own purposes depends on the provider. For Nextel phones where the GPS can be handled entirely on board, the API is fully available to third-party java developers.
On the other hand, current Sprint CDMA phones require ephemeris data from a Sprint location server in order to locate the GPS satellites, and the relevant Qualcomm API is restricted up in four annoying ways: - the class file is no longer distributed (not a big deal as one can write one's own based on the official Qualcomm docs) - unsigned java applications are restricted from accessing the API (one can get one's own certificate and then enable developer access, but this is expensive; alternately, one can edit the permissions on the phone, but this might be a DMCA violation) - the IP address of Sprint's location server is not made public (and even if one got it, presumably use of it would be illegal, since it would be unauthorized use of their computer) - in case one should want to write a partial implementation of a location server to give the ephemeris data to the phone, the protocol is undocumented
On phones where GPS access is wide-open, one can either in practice or in theory run Mologogo and do this for free. On other phones, there are commercial, subscription-based services.
IANAL. But the point of this seems to be that the access to the protected data is duly authorized, since an authorized media player is used. The authorized media player then decodes the data. It is the decoded data that is captured. The decoded data is not protected, and hence the DMCA may not apply to it (but don't trust me, ask a lawyer).
I was assuming that FDE of originals would be matched by encryption of backups, and similar issues apply to the backups. Moreover, I can have a decent chance of reading unencrypted.tar.gz (or some other very standard format), or better.tar, backups in thirty years or so. But encrypted backups add one more issue--to read the backups in the future, I would need to remember the key (a serious problem for me over such a long time, and an even more serious problem if someone else is trying to recover the data on my behalf after I'm dead), and would need to have compatible decryption software.
I suppose one solution to the compatible decryption software issue is to use file encryption on the backups and store uncompressed clear-text of the source code of all the backup/restore/crypt utilities. (A strong argument for using open source for backups.) But there is still the key memory issue.
My context may differ from yours. I'm an academic in the humanities, and in my field (philosophy) data can remain useful for centuries, indeed sometimes millenia.
In a number of contexts, loss of data is a more serious concern than loss of confidentiality. For the vast majority of self-generated data on my hard drive, I would be seriously inconvenienced by the loss of the data, but would not at all mind the data becoming public. For a significantly smaller amount of data, I would seriously mind the data becoming public, but I would more mind losing the data. Only a very small fraction of data on my computer is such that I would mind the data becoming public more than I would losing it.
In such a context, given that FDE makes data recovery harder and more time-consuming, it can make sense to encrypt only that tiny fraction of data where one would more mind its becoming public than one's losing it. In other contexts, it will be different.
Re:The problem with guis is they don't work
on
GUIs Get a Makeover
·
· Score: 3, Interesting
GUIs are great for utilities that one uses only once in a while, say every two months. Going through a man page, keeping track of options, etc., is a nuisance, and memorization is not worthwhile for rare use. Likewise, well-organized GUI menus are nice for allowing access to commands that one uses rarely. Ideally, there are keyboard shortcuts for common commands.
Don't sf.net rules require that source be available?
You could embed some comments asserting your authorship in the middle of the code. I wouldn't be surprised if the cheaters just lop off headers at the top and don't look inside the code. But the professor will, or at least should, look at all of the code.
It is, though, a good idea to put an attribution on the bottom of a slide that includes verbatim material from other sources, where it is not obvious. This provides a good example for the students, gives credit where credit is due, alerts students to possible weaknesses in the data (one needs to know the source to evaluate reliability), and might even (though I am not a lawyer) help with a fair-use legal justification of copying copyrighted material.
That said, I agree that the lecture isn't supposed to originate primarily from the professor. In fact, while there is a value in presenting some material that is purely mine, it would be vanity to do so always--for the students shouldn't care too much about what I think on a topic, but what people smarter than me thought about this.
Unfortunately, in some areas, exams are counterproductive. Exams are time limited. In some fields, serious questions take a lot more time than would be available during an exam. In the humanities, an essay may be needed to check that the student can think in depth and originally rather than merely regurgitate material, and to require in-depth, original thinking within a 2-4 hour time span is too much. Moreover, exams penalize those students who think more slowly. In some work areas, speed matters. In others, it matters much less. If one is a researcher, it can be sufficient for a glorious life-time of accomplishment to write one truly seminal paper, no matter how long it takes.
In my own teaching experience in philosophy, students gain little gradewise through plagiarism. Typically, a paper goes up by one notch, e.g., from a B- to B, as a result of plagiarized material being inserted. It's no surprise, because the students who are more likely to cheat are ones whose judgment about the quality of material to plagiarize is less to be trusted.
Indeed, clearly, a rational decision calculation makes the cheating a bad idea. For instance, maybe you have a 1/4 chance of getting caught (given the foolishness of many of my cheaters, I think that with turnitin.com, it may be as high as 1/2). If you don't get caught, your paper grade goes up, say, 10% from 80% to 90%. But this is only one of several papers in the class, typically, so your actual grade may only go up 2%. But if you do get caught, you have a high chance of failing the course (that's my default penalty), and getting additional penalties levied by the university (e.g., getting a note on your record that bars you from certain types of employment or study, e.g., law school, until the note is removed). Let's say, you've got a 2/3 chance of failing the course, and a 1/3 chance of getting away with a zero on the paper (if there are extenuating circumstances). So, not even counting the additional penalties, and assuming that without cheating your course grade would be 80%, your expected loss in course grade is 13%, and the maximum gain you can expect is anyway about 2%. Greater gains can be had by cheating on each paper, but the chance of getting caught is greater.
There seems to be a clear distinction between DRM and use of a medium that only a few have access to. The DRM is designed IN ORDER TO limit distribution. A medium or format without DRM, is not generally designed IN ORDER TO limit distribution. It may happen to limit distribution if it is rare or expensive or requires expensive equipment to read, but limiting distribution is not the POINT of it. Moreover, DRM carries different legal requirements with it: it is legal in the US to develop a cheap reader for media that otherwise would be expensive to read if there is no DRM; but if the media are designed to limit use, then the DMCA (yes, yes, it's bad, but it's the law) kicks in.
While it is difficult to test on every part of the material, one can test a random sampling of it. If a student knows 90% of a random sampling of the material, and the sample is large enough, then it is pretty likely that the student knows between 87 and 93% (say) of the material in course.
Of course in med school, flight school, and other places where failure to know a single detail could be fatal, random sampling may not be good enough. But in most other cases, I suspect it is.
In the humanities, back-and-forth on-the-spot discussion skills are important, and so grading class participation seems quite appropriate. Yes, it's subjective, but so is the grading of other materials in the humanities (and there is usually some subjectivity in the sciences, too, say with regard to partial credit allotment, or taking points off in advanced math classes if the proofs aren't as elegant as they should be).
But class participation and class attendance are very different things.
Personally, I do think the podcasts should be posted when conveniently available, if the professor wants them posted at all. Personally, I tend to post detailed lecture notes as my own speaking style is too halting for me to be comfortable with having audiorecordings available online. Ideally, I think I should be posting the notes just before or just after the class, though at times I fall behind given other tasks.
I think it's important to treat students as responsible adults in order that those who are not yet such should become such. If the student misuses the podcast, this is unfortunate, but I think it is unfair to artificially deprive the more responsible students of a useful resource in order to prevent this. Moreover, the student who misuses the podcast is either going to suffer for it grade-wise or not. If not, then (assuming the grading system is correctly set up to sample the material), there was no harm done. If so, then the student will have a chance for learning a lesson about how to learn.
Slashdot Mirror
Since GPS software for Sprint cellphones costs as little as $20, and gives you an unlimited number of fixes with no monthly fee for GPS use, the load on the servers can't be very high.
Frankly, I think cell phone companies should be, but probably aren't (there was an old story about how Sprint refused to locate a cellphone in a stolen car when the car had a baby in it), willing to report coordinates to law enforcement when a theft report has been filed. (In fact, I think they should be required to do such reporting if the data is easily available to them, perhaps for a nominal service fee.)
Around here, muggers regularly steal cellphones. If one could locate the cellphone quickly, the police would be much better able to nab the mugger, unless the batteries have run out or the mugger had the sense to turn it off. Since sometimes the muggers also beat, stab or shoot people (even when the people cooperate), this would be a definite benefit.
Sprint restricts some APIs (notoriously, location services) to signed MIDlets, but otherwise you can load MIDlets and ringtones by a USB or serial cable. I think you can also set up your own server and load them up from there, but it's easier to use a cable and doesn't require data service.
It's true that they don't tell you how to use a data cable. But they haven't done anything positive to prevent it.
The claim that the computer program will have the same amount of free will that a human brain has does not follow from the premises of the argument. What follows from the premises of the argument is that the computer program's behavior will be indistinguishable from the behavior of a being with free will. (Maybe that's why "free will" was in quotation marks in the post?)
It does not logically follow from indistinguishability of behavior that there is internal indistinguishability. Indeed, the hypothesis as described does have internal distinguishability: one is silicon-based and the other is carbon-based. Both produce the same behavior, and there is nothing absurd about that. Likewise, there is nothing logically absurd about the idea that something without free will might have the same actual behavior as something with free will. Of course, one might try to argue that something deterministic cannot have the same observable behavior as something indeterministic, but that is false (any results produced by an indeterministic process could have been produced by a deterministic one instead; counterfactual results would differ, but counterfactual results are, as such, not observable).
That said, I agree that the idea that human behavior is entirely determined by the physical structure of the human brain is at odds with the idea of deserved reward and punishment. But while we are in a position to know that human behavior is significantly affected by the physical structure of the brain, we are not in a position to know that human behavior is entirely determined by the physical structure of the brain.
I am also kind of amused by the way the poster presupposes that one particular outcome would come of the brain-simulation experiment, namely that the simulated brain would behave just like the living person. It is quite a leap (of faith?) to suppose that we know what the experiment would show (viz., sameness of behavior). And if we don't know what the experiment would show, then we don't know that there is any issue to worry about.
I've used Palms/Clies for ebooks (lots of stuff can be stored on a 1gb SD card, and I have a lot of books relevant to my academic work), movies (tcpmp is great, except for the MPEG-4 patent issues which I solved by actually getting a patent license from MPEG LA), WiFi-based web browsing and email, audio books, games, notes, appointments and addresses.
For those of us who need good search capabilities for ebooks (e.g., scholarly texts), dedicated ebook readers are not an option (despite how nice e-ink is). Cellphones are definitely not an option for ebook reading, given their small screens. I like to have the complete works of St Thomas Aquinas in my pocket, seven volumes of Leibniz, a bunch of stories and novels, etc., mostly in Plucker format. I actually prefer reading in ebook format--no need to think about bookmarking (though of course if I have a crash, I might lose my place), I can carry around lots and lots of books, access lexical tools, search, insert annotations (Plucker's annotation support is now adequate but not very good--I need to improve it), read in the dark, etc.
The 320x480 screen of a hi-res+ device is a good option for movies--iPods have smaller screens, I think. My four-year-old daughter gets to watch movies on trips. When we get a new movie at home, she asks me to "make a copy" for putting on the PDA. (I've had to explain to her that I can't do that if we don't own the DVD.)
Text input is better than on a cell-phone (I use the ATOMIK on-screen keyboard on a TX; it's not quite as good as a Clie's keyboard, which in turn isn't quite as good as a blackberry's or Treo's, but it's OK, apart from some hardware flaws in the TX digitizer (I am the developer for the keyboard software, so I'm biased)). It's OK for short emails, notes that are one or two sentences long.
I don't do much in the way of gaming these days, but I have a couple of games loaded.
Unfortunately, the TX is not perfectly stable (the worst of what I use is the included VersaMail email client). But it's pretty good if one is careful about what one installs. I rarely get a reset, unless I'm testing buggy pre-release software (say, my own).
It would be nice if the TX was also a cellphone--one less thing to carry--but Treo screens are too small for extensive ebook use, I suspect.
Some of these claims are false.
When the T5 came out, it had significantly longer battery life than the T3, in part due to shifting to flash instead of RAM as the main storage medium. All TX accessories are backwards compatible with the T5, so the T5 is a device that was off the market for more than three months--indeed for more than a year--and has the same connector and the accessories are all compatible. I find the screen on my TX just fine. In fully bright sunlight, you can even turn off the backlight (using a third party utility). Yes, it would be nice if it worked better in bright sunlight, but it's OK.
The no-hacks claim is simply false. Igor Nestorov's YAHM is an excellent, stable hack manager for OS 5 (and pre-OS 5) devices, and developing hacks for OS 5 is about as easy as for pre-OS 5. Yes, when OS 5 came out, that killed earlier hacks, because those were meant for patching a 68K-based OS. But now we have YAHM and a perfectly good SDK for it, with a number of examples included, and there are or have been a number of YAHM-based hacks to do things like emulating arrow keys for different devices, supporting serial keyboards, antialiasing fonts, forcing a particular display mode, making hidden volumes visible, etc.
Of course, YAHM is not supported by Palm, and theoretically a new OS revision could break it. But the same was always true for hacks.
Actually, with tools like Peal (open source, I am pretty sure), doing completely or almost completely ARM-based applications (e.g., tcpmp) is not hard at all. One issue is calling back to the OS, which normally goes ARM->68K->ARM, but this can be fixed by using the unofficial Mobile-Stream SDK which lets you call the OS directly from ARM code.
I do a lot of programming on the ARM side as I sell an antialiased font hack (FontSmoother), and in my experience ARM code is, if anything, more stable.
That said, for standard applications, one doesn't need ARM, except maybe for some small CPU-intensive procedure. With practice, these are easy to do and do not affect stability.
It would have been nice if Palm/PalmSource released an SDK for doing ARM-only applications, but the reverse-engineered stuff in the Mobile-Stream SDK is pretty good.
Yes, this works but it is counterintuitive (F2 isn't intuitive, except maybe to Excel users, btu it also isn't counterintuitive). One would expect ENTER on a file to launch the file, ENTER being a standard key for execute, confirm, do, etc.
Moreover, remember the poster who said that the right criterion is not whether it is obvious, but whether it is obvious given the problem. I don't know patent law, so I don't know if this is the right criterion, but if it is, then a portable device for email IS obvious. It's obvious as a solution to the problem of how a businessperson can get email while traveling without carrying a large device and without the device having to be connected by wire to anything. Namely, he does it by carrying... gasp... a small device and connecting it... gasp... wirelessly. Now HOW to do this may involve some non-obvious, patentable processes (how to make a small enough device with enough computing power, how to make powerful enough batteries, etc.) But the idea of doing this in some way or other is obvious once one is clear on what the problem is.
Does anybody know if the conditional formulation "obvious given the problem" is the right one in US patent law? I agree with the poster that this would probably rule out a ton of patents, since once one identifies the problem, often--but not always--the solutions are pretty obvious. But identifying the problem can be hard.
Ditto on the Palm TX. It's looking like they couldn't have tested on any Palm devices (or maybe any NVFS-based ones), because I have yet to hear of it working with some Palm device.
How about testing, manufacturing (new box, new CD/DVDs), modifying documentation, training customer support to deal with an OS they're not used to, etc.? Sure, one could skip the testing, manufacturing, documenting and customer support and mail out the software on CD-Rs in generic jewel cases with handwritten "NO SUPPORT AVAILABLE" labels (and even that takes work), but the company has a reputation to keep up, and people would probably feel odd about paying $50 for that. (But then I am not much of a gamer--I've never spent more than $10 on a single computer game.)
But it's pretty hard to develop the client software without actually testing it, and the testing would violate the ToS.
All currently produced phones in the US have GPS or AGPS (assisted GPS--works better in urban areas, by adding information from a server) for E911 purposes. Whether one can use the GPS or AGPS system for one's own purposes depends on the provider. For Nextel phones where the GPS can be handled entirely on board, the API is fully available to third-party java developers.
On the other hand, current Sprint CDMA phones require ephemeris data from a Sprint location server in order to locate the GPS satellites, and the relevant Qualcomm API is restricted up in four annoying ways:
- the class file is no longer distributed (not a big deal as one can write one's own based on the official Qualcomm docs)
- unsigned java applications are restricted from accessing the API (one can get one's own certificate and then enable developer access, but this is expensive; alternately, one can edit the permissions on the phone, but this might be a DMCA violation)
- the IP address of Sprint's location server is not made public (and even if one got it, presumably use of it would be illegal, since it would be unauthorized use of their computer)
- in case one should want to write a partial implementation of a location server to give the ephemeris data to the phone, the protocol is undocumented
On phones where GPS access is wide-open, one can either in practice or in theory run Mologogo and do this for free. On other phones, there are commercial, subscription-based services.
IANAL. But the point of this seems to be that the access to the protected data is duly authorized, since an authorized media player is used. The authorized media player then decodes the data. It is the decoded data that is captured. The decoded data is not protected, and hence the DMCA may not apply to it (but don't trust me, ask a lawyer).
Pocket DVD Studio apparently does this for DVDs.
Doing this anonymously would surely have looked a lot more suspicious.
I was assuming that FDE of originals would be matched by encryption of backups, and similar issues apply to the backups. Moreover, I can have a decent chance of reading unencrypted .tar.gz (or some other very standard format), or better .tar, backups in thirty years or so. But encrypted backups add one more issue--to read the backups in the future, I would need to remember the key (a serious problem for me over such a long time, and an even more serious problem if someone else is trying to recover the data on my behalf after I'm dead), and would need to have compatible decryption software.
I suppose one solution to the compatible decryption software issue is to use file encryption on the backups and store uncompressed clear-text of the source code of all the backup/restore/crypt utilities. (A strong argument for using open source for backups.) But there is still the key memory issue.
My context may differ from yours. I'm an academic in the humanities, and in my field (philosophy) data can remain useful for centuries, indeed sometimes millenia.
In a number of contexts, loss of data is a more serious concern than loss of confidentiality. For the vast majority of self-generated data on my hard drive, I would be seriously inconvenienced by the loss of the data, but would not at all mind the data becoming public. For a significantly smaller amount of data, I would seriously mind the data becoming public, but I would more mind losing the data. Only a very small fraction of data on my computer is such that I would mind the data becoming public more than I would losing it.
In such a context, given that FDE makes data recovery harder and more time-consuming, it can make sense to encrypt only that tiny fraction of data where one would more mind its becoming public than one's losing it. In other contexts, it will be different.
GUIs are great for utilities that one uses only once in a while, say every two months. Going through a man page, keeping track of options, etc., is a nuisance, and memorization is not worthwhile for rare use. Likewise, well-organized GUI menus are nice for allowing access to commands that one uses rarely. Ideally, there are keyboard shortcuts for common commands.
Shouldn't the honest ones be glad that their papers are kept in a database designed to keep dishonest students from copying from them?
Don't sf.net rules require that source be available?
You could embed some comments asserting your authorship in the middle of the code. I wouldn't be surprised if the cheaters just lop off headers at the top and don't look inside the code. But the professor will, or at least should, look at all of the code.
It is, though, a good idea to put an attribution on the bottom of a slide that includes verbatim material from other sources, where it is not obvious. This provides a good example for the students, gives credit where credit is due, alerts students to possible weaknesses in the data (one needs to know the source to evaluate reliability), and might even (though I am not a lawyer) help with a fair-use legal justification of copying copyrighted material.
That said, I agree that the lecture isn't supposed to originate primarily from the professor. In fact, while there is a value in presenting some material that is purely mine, it would be vanity to do so always--for the students shouldn't care too much about what I think on a topic, but what people smarter than me thought about this.
Unfortunately, in some areas, exams are counterproductive. Exams are time limited. In some fields, serious questions take a lot more time than would be available during an exam. In the humanities, an essay may be needed to check that the student can think in depth and originally rather than merely regurgitate material, and to require in-depth, original thinking within a 2-4 hour time span is too much. Moreover, exams penalize those students who think more slowly. In some work areas, speed matters. In others, it matters much less. If one is a researcher, it can be sufficient for a glorious life-time of accomplishment to write one truly seminal paper, no matter how long it takes.
In my own teaching experience in philosophy, students gain little gradewise through plagiarism. Typically, a paper goes up by one notch, e.g., from a B- to B, as a result of plagiarized material being inserted. It's no surprise, because the students who are more likely to cheat are ones whose judgment about the quality of material to plagiarize is less to be trusted.
Indeed, clearly, a rational decision calculation makes the cheating a bad idea. For instance, maybe you have a 1/4 chance of getting caught (given the foolishness of many of my cheaters, I think that with turnitin.com, it may be as high as 1/2). If you don't get caught, your paper grade goes up, say, 10% from 80% to 90%. But this is only one of several papers in the class, typically, so your actual grade may only go up 2%. But if you do get caught, you have a high chance of failing the course (that's my default penalty), and getting additional penalties levied by the university (e.g., getting a note on your record that bars you from certain types of employment or study, e.g., law school, until the note is removed). Let's say, you've got a 2/3 chance of failing the course, and a 1/3 chance of getting away with a zero on the paper (if there are extenuating circumstances). So, not even counting the additional penalties, and assuming that without cheating your course grade would be 80%, your expected loss in course grade is 13%, and the maximum gain you can expect is anyway about 2%. Greater gains can be had by cheating on each paper, but the chance of getting caught is greater.
There seems to be a clear distinction between DRM and use of a medium that only a few have access to. The DRM is designed IN ORDER TO limit distribution. A medium or format without DRM, is not generally designed IN ORDER TO limit distribution. It may happen to limit distribution if it is rare or expensive or requires expensive equipment to read, but limiting distribution is not the POINT of it. Moreover, DRM carries different legal requirements with it: it is legal in the US to develop a cheap reader for media that otherwise would be expensive to read if there is no DRM; but if the media are designed to limit use, then the DMCA (yes, yes, it's bad, but it's the law) kicks in.
While it is difficult to test on every part of the material, one can test a random sampling of it. If a student knows 90% of a random sampling of the material, and the sample is large enough, then it is pretty likely that the student knows between 87 and 93% (say) of the material in course.
Of course in med school, flight school, and other places where failure to know a single detail could be fatal, random sampling may not be good enough. But in most other cases, I suspect it is.
In the humanities, back-and-forth on-the-spot discussion skills are important, and so grading class participation seems quite appropriate. Yes, it's subjective, but so is the grading of other materials in the humanities (and there is usually some subjectivity in the sciences, too, say with regard to partial credit allotment, or taking points off in advanced math classes if the proofs aren't as elegant as they should be).
But class participation and class attendance are very different things.
Personally, I do think the podcasts should be posted when conveniently available, if the professor wants them posted at all. Personally, I tend to post detailed lecture notes as my own speaking style is too halting for me to be comfortable with having audiorecordings available online. Ideally, I think I should be posting the notes just before or just after the class, though at times I fall behind given other tasks.
I think it's important to treat students as responsible adults in order that those who are not yet such should become such. If the student misuses the podcast, this is unfortunate, but I think it is unfair to artificially deprive the more responsible students of a useful resource in order to prevent this. Moreover, the student who misuses the podcast is either going to suffer for it grade-wise or not. If not, then (assuming the grading system is correctly set up to sample the material), there was no harm done. If so, then the student will have a chance for learning a lesson about how to learn.