Brendan wrote:Awesome; I'll use a periodic timer and SIGSEGV to inform the process that 1 second has passed. If this causes compatibility problems for existing software, then obviously existing software is wrong because the meaning of SIGSEGV isn't defined by the C standard.
Yes, strictly "standard C" software shouldn't have any adverse reaction in that case. However, most software assumes at least some POSIX-like behaviour and since your behaviour isn't POSIX complaint, that software would have difficulties. If you don't want to have any POSIX support, that's just fine.
Brendan wrote:
The more important the data is the more important avoiding data loss is. For some things (e.g. calculator app) nothing is needed; for other things (games, common office applications) losing a few minutes of work is good enough; and for other things (e.g. DMBSs being used for accountancy) strict guarantees aren't required.
I agree completely.
Brendan wrote:
The important thing to understand is that (for minimising data loss) signals aren't useful for any case.
Even if you don't use it to help prevent data loss, it has possible beneficial usecases (e.g. my blacklisting plugins scenario). I see no harm in supporting it. Of course my documentation won't promote it as a data-loss prevention strategy, but I won't "ban" that either.
Brendan wrote:
I'm not sure which results you saw (Google has a nasty habit of giving different people different results based on their previous search history). The first page of results I see is almost all bug reports involving signals. The only one that isn't is a link to
a document by IBM explaining how to avoid signal handler bugs (and proposing "a model for dealing with reentrant functions at the compiler level" to help reduce the problem).
Most of the results I saw were problem/bug reports containing the line "signal handler triggered" and a stack trace. i.e. they were reports of other problems, with debugging information produced by a properly functioning signal handler (another possible usecase beyond data protection).
Brendan wrote:So mostly the only thing you disagree with is whether or not it's worthwhile providing POSIX compatibility.
Basically, yes.
Brendan wrote:
Let's test it by "accidentally" unmapping the wrong address (and freeing pages the executable is executing). This should trigger SIGSEGV and we can see how reliable the (now unmapped/freed) signal handler works. Alternatively, let's trash the heap with something like "memset(malloc(123), 0xCC, INT_MAX);" and see how well signal handler can allocate memory. Here's another idea - have some data protected by a mutex, and try to acquire the mutex twice (causing a deadlock), then (when the user tries to kill the process) see if the signal handler can acquire the same mutex (so it can safely access the data and write it to disk).
How about we have just have a loop that selects a random pointer and writes to it. It'd be interesting to see how often the signal handler crashes, how often the signal handler "works" (writes previously corrupted data to disk), and how often the signal handler actually works.
If something is wrong, a process may or may not crash (and I'm sure we've all seen dodgy C code that uses a dangling pointer or something that does not crash). If something is so wrong that the process actually does crash, then the risk involved in allowing it to attempt recovery is unacceptable.
Worst-case, the program hangs in the signal handler and has to be forcefully killed, no different to if it hung for some other reason.
If I were attempting data protection in a signal handler, I certainly wouldn't write the data to the same file, which would eliminate the possibility of overwriting good data with bad. (Microsoft Office auto-recovery works like this, including attempting to save data on crash.)
Brendan wrote:
Your right to do what you want with software that you've legally obtained (including giving copies to friends/family and anything else), mostly doesn't exist. It's because you do not have the rights to do what you want that it's illegal to distribute it.
While it may just be semantics, I don't consider distributing copies to be "doing what I want
with the software". It's something that happens externally to the software (unless it has a "copy me" feature).
Brendan wrote:You're right; it's not necessarily the OS's job to enforce copyright law. However, if you make it hard for software developers to protect their investment, they simply won't bother spending their time and money designing, implementing and then supporting applications for the OS; and you end up with little more than crappy applications (either low quality stuff slapped together by volunteers, or ported open source stuff that makes the OS look bad because it doesn't take advantage of the OS's unique features).
For an example, consider SteamOS. I can guarantee that it will contain some form of DRM (because if it doesn't no decent games will support it, and if no decent games support it then no end users will want it).
Honestly, I don't care about commercial development or DRM in my OS, it's a hobby, not a business plan. I won't write any, nor will I make any special effort to make it possible in my API design, but my kernel module API is completely open (and unlike Linux, has no licence restrictions), so if a commercial entity wants to add DRM to my OS, they're free to do so.
Note that SteamOS is a Linux distribution and there are existing implementations on Linux, which is an Open-Source OS.
Brendan wrote:
Copyright law doesn't say that you're not allowed to attach a debugger to a program. Copyright law says you have no rights at all (excluding a few exceptions - educational purposes, etc). It's the copyright owner (and not copyright law) who grants you whichever rights they feel like granting, and it's the copyright owner (and not copyright law) who can say "I only grant you the right to use this software if you agree not to debug it".
Copyright law is
way more complicated than that. Depending on the jurisdiction, there are certain rights you are assumed to have unless agreed otherwise (e.g. the ability to install/run software that you've legally obtained) and even some rights that you still have even if you do "agree" otherwise (e.g. the right to make backup copies, the right to reverse engineer software for interoperability purposes).
A copyright owner who says "I only grant you the right to use this software if you agree not to debug it", may or may not have the legal right to prevent you from debugging, depending on the purpose of the debugging and the legal jurisdiction you do it in.
See documents such as the
EU Software Directive:
"In the absence of specific contractual provisions, the acts referred to [...] shall not require authorisation by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction."
"The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do."
"The authorisation of the rightholder shall not be required where reproduction of the code and translation of its form [...] are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs, provided that the following [...]"
Brendan wrote:"Browsing the web (with HTTP, HTML, CSS, Java-script, etc)" is just one of infinitely many possible ways of using a computer for the purpose of viewing online/remote content.
Gopher is another one of those infinitely many ways. Java-script is NOT required for the purpose of viewing online/remote content.
If you think that an OS without the capability to run a modern web browser will be successful and that Gopher is a valid alternative in 2014, sure, go ahead. I somehow doubt that history will vindicate that position.