Or handling symlinks in svnadmin hotcopy, which fails silently and continues the rest of the operation successfully, last time I looked. It makes synchronizing pre-commit hooks or authorization setups among repositories quite awkward.
What's sad is that Linus Torvalds did most of this correctly, in far less time, than the Collabnet developers and their assistants. While git's 'branching' structure takes time to understand, the better security models, the performance, and far, far better support for remote development work win hands-down.
It's on every backup tape. Anyone with access to your (potentially NFS shared or CIFS shared) home directory also has access to the plain-text files. You may as well tattoo it on your forehead, because every script kiddie in the world knows to go looking for these, and they've been silently stored on Subversion clients all over the world. (Subversion 1.6.x at least asks before storing them, but that's hardly enough.)
You may think your local system admin and backup manager, whether it is you, your son, your daughter, or your systems administrator at work, is perfectly trustworthy with that information. But Subversion has already made that decision for you. And no, they _should not_ have access to my passwords simply because they can access my machine.
Password caching is on _by default_ and is awkward if impossible to set on a system wide basis. It's also client behavior wired into every source-code built client. This should never, never, never have been the case: it should specifically require an extra, manual step to allow password caching, to force people to think about it and not do so by accident.
And while a "Keyring" or "Kwallet" can be useful, they are entirely reliant on GUI's to manage them, and do not in general operate on the command line. It's more reasonable to use svn+ssh, but there is no published management tool for handling user keys for that. (Git has gitosis, which works fairly well.)
This is one of the instances where Linus Torvald's description of Subversion being "CVS done right" is like gold-plating dogshit has real meaning. The security model was broken from day one.
Have you ever tried to cut ice cleanly without a powerful and potentially dangerous tool? For large scale work on good, hard ice, chain saws are very efficient.
I'm thinking back to some winter work at a logjam on a relative's property, a few years ago. I brought them lunch and stayed out of the way, but they did indeed use chain saws effectively the ice that had formed on the downstream side of the barrier and on various projecting pieces of debris.
Seriously. If all it is is a 'messaging protocol', why can't we just use UUCP or, say, something whose underlying compiler is stable? I've been having tremendous issues with having to install subtlely different JVM's for different applications because they cannot keep straight where the JVM's are installed, how to name them, or whether they are compatible with one different appliations. (Sun is no help with this, by the way: the 'write once, run everywhere' model for Java has been more of a 'write once, run nowhere' one this last year due to version drift.) If I see one more application installer overwrite '/etc/profile' by manually setting JAVA_HOME to its own desired location, it's going to get ugly in my workspace.
Java has been useful for large protocols and projects where programmers like to say "and then a miracle occurs" when they hand off processing to other programmers, but for performance sensitive, business critical, programs? I'm just not seeing the reason for it. And this particular field is suffering, badly, from having far too many "application servers".
The one obvious advantage of JBoss is that it is LGPL. And that is not a small feature. But is it really needed? OK, so it has a Tomcat 5.5 component. Tomcat 6 has been out for years, and and Topmcat 5 should have been dropped about 2007.
Please do. For many corporate purposes Subversion is opular, but its truly awful security models (storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted, and refusal to publish workable configuraitons for purely anonymous access), coupled with its designers absolute refusal to support deleting contents from the repository (even if they're accidentally stored DVD images or copyrighted code) leads to a very harsh conflict between the idea of "source control deletes nothing, ever" and the idea of "throwing useless things away makes cleaner code".
I've come to profoundly hate Subversion for just these reasons, although I do administer it locally for certain projects.
What truly amazing twaddle. The concept of a solar sail that cannot _steer_ to correct any errors in its original launch is simply amazing. This would be a very expensive spacecraft, not an arrow. It's going to need some control in order to keep its sail aligned for maximum effective thrust, lest it twist very slightly and get pushed slightly wrong for days or years. Even the slightest control of the sails, very slightly pulling in one corner or even two, could be used over a voyage to avvect its course.
And this is the whole point of "Trusted Computing", Microsoft's much applauded "security" suite that fortunately seems to be have shown as seriously flawed that I'm just not seeing anyone developing for it. The signature/authentication/encryption chip was built into the motherboard or the CPU: there was a very tight toolchain to have signed tools open other signed tools to access data, designed to prevent non-authorized tools from reading media but also able to protect data files.
The problem was it was also clearly designed to control bootability and hardware access, although that got little attention: if you don't have a Microsft signed key boot loader, kernel, and application set, you can't boot the box or open a hard drive. Period. And even other company's keys would reside in Microsoft's hands, since they would hold the backup copies of everyone's _private_ keys.
It was nasty, nasty, nasty stuff. and I'm glad it seems to be stillborn.
So not having hardware for six weeks loses you that time from your "uptime" right up front. In my businesses, "delay to installation" is often counted as "downtime".
Buy spare disks at NewEgg's much lower price, start cycling in once a month after two years, and continue with that kind of schedule as long as the server lasts. You'll be ahead on price and massively ahead on reliability because large arrays tend to have multiple drives failing at the same time due to consistent wear.
"Four-hour" response time is a bad joke. It's typically 2 hours getting your call escalated from some call center in India to an engineer with a clue to actually start that 4-hour clock ticking, and it's vastly faster and cheaper to have the spare server or box of spares you bought with the money saved by skipping that insanely expensive service level. Yes, I do this, and it's very effective in a large installation.
If you have a teeny site where no one available has the expertise to do that 4-hour repair, pay for the external expertise. But be aware that for many people it makes little sense.
No. They can't. NVidia very carefully does not _publish_ kernels with the modifications. They publish a downloadable patch that you must manually apply on top of your existing kerneal, and the agreement on that patch says you _may not_ distribute it as part of a kernel.
Sending boxes to people's homes pre-installed with non-GPL modifications would be a much more blatant GPL violation, because it would constitute distribution of the "tainted" kernel, rather than allowing people to taint their own kernels. They have similar problems with modifications to glibc, which is far more likely, since that's a component other set-top box and Linux appliance manufacturers have been caught violating the GPL on as well.
No, it's perfectly reasonable to sell an up-to-date hardcopy of what is primarily open source material. The Subversion book does precisely this, and their websites always contain the bleeding edge version of the book, which is basically a well-written FAQ.
Because they're not allowed to share their ideas with IT, and vice versa. I can't list the number of times developers have published brain-scrambled vomit as part of their projects, because it didn't interest them and no one with experience was around to explain the inevitable problems. The maintenance model for subversion where you have to completely rebuild the repository to completely delete an accidentally stored DVD image is a classic example.
Conversely, I've expressed extreme doubts about projects that turned out to be effective and workable because my knowledge of file system behavior or hardware limitations was 3 weeks behind the times. I even spiked a project once for such reasons, although when the developer and I spoke without the confused manager in the way it became clear that the hardware _could_ support his needs.
Yes, it does. If you've ever tried either to install someplace out of the way where tools and replacement parts are difficult to obtain, or where the data center staff are cage monkeys who've never actually read their own contract and how they're supposed ot have a console and keyboard available within 20 minutes of a phone call plugged into the correct server because you "economized" by paying for a "higher service level" and didn't buy remote KVM's or power controllers, then you know exactly what I've encountered a dozen times in the last decade. Having to leave my desk, drive to a facility in another state or country, and show them how it's done.
Richard is a fanatic. But his fanaticism is founded in genius, and foresight. He's been very correct about the edge cases and misuses of open source tools, and the attempts to limit open source tools in innovative ways (such as the Tivo has done). Richard is responsible for _creating_ GNU: his core work on tools such as gcc and glibc created the environment for Linux, the kernel, to unleash the somewhat confusing "Linux" operating systems. Linus should be, and is, grateful for that foundation, and wisely focuses his limited resources on the kernel itself. As irritating as the naming war is, Richard has a point.
As a project leader, Linus is amazing. I'd love to be like him when I grow up, although I'm not skilled enough as a leader nor a programmer to do so. As a prophet leading people to new ways of thinking and living, however, Richard is the clear winner. Bathed or not, Richard led the way into the land of milk and honey that Linus's farm is built in.
Software patents were created to fill a business opportunity. The absense of that opportunity is not, in itself, necessarily a bad thing because the filing and management and avoidance of infringement of such patents has become amazingly burdensome to developers and to the public.
Worse, many software patents are nonsensical: they act as a barrier to entry to small companies and small scale developers, because larger companies can and do invest in patent portfolios as a basic business practice. The result is that innovation is stifled. Not completely, but I've had software and hardware patent issues go to court, and it was burdensome on me as a developer.
The hammer itself is patentable. The new use of a hammer, without fundamental modification to the hammer itself, is not. So now that general purpose computers exist. That's part of what Bilski is revealing: the patenting of usages of tools, without modifying the tool itself, is a serious issue that should block the patent.
A general tool of almost any kind, used in a different way, is _not patentable_. It's using the tool for what it was designed for, it does not change the physical construction of the machine nor its number of parts nor its general capabilities.
The "actually implemented algorithm" is protected in its specific implementation by copyright, and should not receive the double protection of patent law against writing similar algorithms.
"What open source packages do employees here contribute to or publish?" If a workplace uses Linux, or the Free Software Foundation toolchain of gcc, make, tar, and gzip, and their employee agreement is as restrictive as what I've had to renew or sign during my career, they need serious editing to allow me to publish my patches to open source or free software. I always write that in and get it counter-signed as part of my hiring process. That allows me to get fixes published upstream so I don't have to re-patch them.
"When do you update software?" If they say "we don't fix what isn't broken", I worry. You can waste hundreds of man-hours backporting features to old operating systems or old toolkits, and that work doesn't actually improve the next round of products: it wastes your efforts in ways that do not get you bonuses or advance your career. (Admittedly, my career now includes an incredible amount of this sort of thing, but that's because I'm old and considered expert in the older technologies.)
"What build system do you use?" Every single workplace that I've seen that built their own from scratch, usually by some brilliant developer frustrated with build systems they never fully understood, spent hundreds or thousands of man-hours on learning it and using it, only to see it fall apart as the developer ran into the same problems "make" and "autoconf" solved more than a decade ago.
Yes, it does. PAM is part of how it's integrated into various authentication tools. I use it just that way. Unfortunately, environments that insist on "don't change it if it's not broken!!!!" remain roughly five years behind the times in OpenSSH features, and the result is considerable difficulty in integrating Kerberos and especially true "single-sign-on" into a working environment.
I recently had a fascinating chat with an RHEL environment where getting them off of RHEL 4 was a serious, many layers of management playing phone-tag involved process because no one there could be permitted to take responsibility for maintaining anything, and thus they agreed to spend 3 times as much money and effort to have security and other updates backported, with no certainty of stability or success.
They're also easily forged. The paper at http://cryptome.org/gummy.htm [cryptome.org] is seven years old, I'm _amazed_ that those expensive pieces of wishful thinking are still in use.
PAM _does not help_. In fact, it reverses the problem, and makes various passwords able to access your account, especially in a carelessly configured multiple OS environment, all able to work on your poor victim of a Linux system.
Please allow me to be a serious geek here for a bit.
_Kerberos_ solved this problem years ago for user authentication. LDAP coupled with it, well-managed, provides the user and account management. Both are fundamental to Active Directory, oddly enough, which can support quite a lot of well-managed single-sign-on access. But it's not well integrated to a huge variety of pen source tools, whether it's from Active Directory or well-managed Kerberos sites like many major universities and companies.
The result is stupid holes in the process: OpenSSH on RHEL 4 and older SuSE and Fedora systems does not support the necessary GSSAPI. The configuration tools don't provide the critical hooks for permitting multiple upstream Kerberos domain authentication for shared environments, and you have to edit krb.conf by hand. The enormously popular "Putty" tool for SSH use does not support Kerberos. (There are forks that do, but the work has languished for years.)
I'll save my comments on Subversion silently and automatically saving your passwords in $HOME/.subversion/auth/svn.simple/ for another time. Do go check your directory on any machines you do work on, though.
Define "spam". Unfortunately, both the EU and the US have laws that are very generous in permitting bulk email: even if the blatantly illegal and fraudulent material is controlled, there remains a lot of protected material that can be and is sent.
Is the EU law any better than the truly stupid US's 'CAN-SPAM' act?
Look again at the source code, the copyrights and authorship. It is most certainly _not_ a clone, neither legally nor functionally nor in quite a number of its core kernel functions. It's why cross-porting core software is sometimes so awkward.
You forgot number 0: "scheduling". Scheduling time for each other, time for household tasks, time for shopping, time for yourselves, and overtall the time to actually do that "work" you mention.
And divorce is not a failure like dying is not a "failure to berathe".
Slashdot Mirror
Or handling symlinks in svnadmin hotcopy, which fails silently and continues the rest of the operation successfully, last time I looked. It makes synchronizing pre-commit hooks or authorization setups among repositories quite awkward.
What's sad is that Linus Torvalds did most of this correctly, in far less time, than the Collabnet developers and their assistants. While git's 'branching' structure takes time to understand, the better security models, the performance, and far, far better support for remote development work win hands-down.
It's on every backup tape. Anyone with access to your (potentially NFS shared or CIFS shared) home directory also has access to the plain-text files. You may as well tattoo it on your forehead, because every script kiddie in the world knows to go looking for these, and they've been silently stored on Subversion clients all over the world. (Subversion 1.6.x at least asks before storing them, but that's hardly enough.)
You may think your local system admin and backup manager, whether it is you, your son, your daughter, or your systems administrator at work, is perfectly trustworthy with that information. But Subversion has already made that decision for you. And no, they _should not_ have access to my passwords simply because they can access my machine.
Password caching is on _by default_ and is awkward if impossible to set on a system wide basis. It's also client behavior wired into every source-code built client. This should never, never, never have been the case: it should specifically require an extra, manual step to allow password caching, to force people to think about it and not do so by accident.
And while a "Keyring" or "Kwallet" can be useful, they are entirely reliant on GUI's to manage them, and do not in general operate on the command line. It's more reasonable to use svn+ssh, but there is no published management tool for handling user keys for that. (Git has gitosis, which works fairly well.)
This is one of the instances where Linus Torvald's description of Subversion being "CVS done right" is like gold-plating dogshit has real meaning. The security model was broken from day one.
Have you ever tried to cut ice cleanly without a powerful and potentially dangerous tool? For large scale work on good, hard ice, chain saws are very efficient.
I'm thinking back to some winter work at a logjam on a relative's property, a few years ago. I brought them lunch and stayed out of the way, but they did indeed use chain saws effectively the ice that had formed on the downstream side of the barrier and on various projecting pieces of debris.
Seriously. If all it is is a 'messaging protocol', why can't we just use UUCP or, say, something whose underlying compiler is stable? I've been having tremendous issues with having to install subtlely different JVM's for different applications because they cannot keep straight where the JVM's are installed, how to name them, or whether they are compatible with one different appliations. (Sun is no help with this, by the way: the 'write once, run everywhere' model for Java has been more of a 'write once, run nowhere' one this last year due to version drift.) If I see one more application installer overwrite '/etc/profile' by manually setting JAVA_HOME to its own desired location, it's going to get ugly in my workspace.
Java has been useful for large protocols and projects where programmers like to say "and then a miracle occurs" when they hand off processing to other programmers, but for performance sensitive, business critical, programs? I'm just not seeing the reason for it. And this particular field is suffering, badly, from having far too many "application servers".
The one obvious advantage of JBoss is that it is LGPL. And that is not a small feature. But is it really needed? OK, so it has a Tomcat 5.5 component. Tomcat 6 has been out for years, and and Topmcat 5 should have been dropped about 2007.
Please do. For many corporate purposes Subversion is opular, but its truly awful security models (storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted, and refusal to publish workable configuraitons for purely anonymous access), coupled with its designers absolute refusal to support deleting contents from the repository (even if they're accidentally stored DVD images or copyrighted code) leads to a very harsh conflict between the idea of "source control deletes nothing, ever" and the idea of "throwing useless things away makes cleaner code".
I've come to profoundly hate Subversion for just these reasons, although I do administer it locally for certain projects.
Of course there's a pattern, even a simple and elegant one. It's equal to:
4 * (1 -1/3 + 1/5 -1/7 +1/9 -1/11 +1/13 -1/15 etc., etc., etc.)
Just because the pattern doesn't come out pretty in a decimal representation doesn't mean it's not elegant or not a pattern.
It's a solar sail. Without significant solar thrust, it _will_ drag against the interstellar gas, and it's likely to gain mass as it does so.
What truly amazing twaddle. The concept of a solar sail that cannot _steer_ to correct any errors in its original launch is simply amazing. This would be a very expensive spacecraft, not an arrow. It's going to need some control in order to keep its sail aligned for maximum effective thrust, lest it twist very slightly and get pushed slightly wrong for days or years. Even the slightest control of the sails, very slightly pulling in one corner or even two, could be used over a voyage to avvect its course.
And this is the whole point of "Trusted Computing", Microsoft's much applauded "security" suite that fortunately seems to be have shown as seriously flawed that I'm just not seeing anyone developing for it. The signature/authentication/encryption chip was built into the motherboard or the CPU: there was a very tight toolchain to have signed tools open other signed tools to access data, designed to prevent non-authorized tools from reading media but also able to protect data files.
The problem was it was also clearly designed to control bootability and hardware access, although that got little attention: if you don't have a Microsft signed key boot loader, kernel, and application set, you can't boot the box or open a hard drive. Period. And even other company's keys would reside in Microsoft's hands, since they would hold the backup copies of everyone's _private_ keys.
It was nasty, nasty, nasty stuff. and I'm glad it seems to be stillborn.
So not having hardware for six weeks loses you that time from your "uptime" right up front. In my businesses, "delay to installation" is often counted as "downtime".
Buy spare disks at NewEgg's much lower price, start cycling in once a month after two years, and continue with that kind of schedule as long as the server lasts. You'll be ahead on price and massively ahead on reliability because large arrays tend to have multiple drives failing at the same time due to consistent wear.
"Four-hour" response time is a bad joke. It's typically 2 hours getting your call escalated from some call center in India to an engineer with a clue to actually start that 4-hour clock ticking, and it's vastly faster and cheaper to have the spare server or box of spares you bought with the money saved by skipping that insanely expensive service level. Yes, I do this, and it's very effective in a large installation.
If you have a teeny site where no one available has the expertise to do that 4-hour repair, pay for the external expertise. But be aware that for many people it makes little sense.
No. They can't. NVidia very carefully does not _publish_ kernels with the modifications. They publish a downloadable patch that you must manually apply on top of your existing kerneal, and the agreement on that patch says you _may not_ distribute it as part of a kernel.
Sending boxes to people's homes pre-installed with non-GPL modifications would be a much more blatant GPL violation, because it would constitute distribution of the "tainted" kernel, rather than allowing people to taint their own kernels. They have similar problems with modifications to glibc, which is far more likely, since that's a component other set-top box and Linux appliance manufacturers have been caught violating the GPL on as well.
No, it's perfectly reasonable to sell an up-to-date hardcopy of what is primarily open source material. The Subversion book does precisely this, and their websites always contain the bleeding edge version of the book, which is basically a well-written FAQ.
Because they're not allowed to share their ideas with IT, and vice versa. I can't list the number of times developers have published brain-scrambled vomit as part of their projects, because it didn't interest them and no one with experience was around to explain the inevitable problems. The maintenance model for subversion where you have to completely rebuild the repository to completely delete an accidentally stored DVD image is a classic example.
Conversely, I've expressed extreme doubts about projects that turned out to be effective and workable because my knowledge of file system behavior or hardware limitations was 3 weeks behind the times. I even spiked a project once for such reasons, although when the developer and I spoke without the confused manager in the way it became clear that the hardware _could_ support his needs.
Yes, it does. If you've ever tried either to install someplace out of the way where tools and replacement parts are difficult to obtain, or where the data center staff are cage monkeys who've never actually read their own contract and how they're supposed ot have a console and keyboard available within 20 minutes of a phone call plugged into the correct server because you "economized" by paying for a "higher service level" and didn't buy remote KVM's or power controllers, then you know exactly what I've encountered a dozen times in the last decade. Having to leave my desk, drive to a facility in another state or country, and show them how it's done.
Richard is a fanatic. But his fanaticism is founded in genius, and foresight. He's been very correct about the edge cases and misuses of open source tools, and the attempts to limit open source tools in innovative ways (such as the Tivo has done). Richard is responsible for _creating_ GNU: his core work on tools such as gcc and glibc created the environment for Linux, the kernel, to unleash the somewhat confusing "Linux" operating systems. Linus should be, and is, grateful for that foundation, and wisely focuses his limited resources on the kernel itself. As irritating as the naming war is, Richard has a point.
As a project leader, Linus is amazing. I'd love to be like him when I grow up, although I'm not skilled enough as a leader nor a programmer to do so. As a prophet leading people to new ways of thinking and living, however, Richard is the clear winner. Bathed or not, Richard led the way into the land of milk and honey that Linus's farm is built in.
Software patents were created to fill a business opportunity. The absense of that opportunity is not, in itself, necessarily a bad thing because the filing and management and avoidance of infringement of such patents has become amazingly burdensome to developers and to the public.
Worse, many software patents are nonsensical: they act as a barrier to entry to small companies and small scale developers, because larger companies can and do invest in patent portfolios as a basic business practice. The result is that innovation is stifled. Not completely, but I've had software and hardware patent issues go to court, and it was burdensome on me as a developer.
The hammer itself is patentable. The new use of a hammer, without fundamental modification to the hammer itself, is not. So now that general purpose computers exist. That's part of what Bilski is revealing: the patenting of usages of tools, without modifying the tool itself, is a serious issue that should block the patent.
A general tool of almost any kind, used in a different way, is _not patentable_. It's using the tool for what it was designed for, it does not change the physical construction of the machine nor its number of parts nor its general capabilities.
The "actually implemented algorithm" is protected in its specific implementation by copyright, and should not receive the double protection of patent law against writing similar algorithms.
"What open source packages do employees here contribute to or publish?" If a workplace uses Linux, or the Free Software Foundation toolchain of gcc, make, tar, and gzip, and their employee agreement is as restrictive as what I've had to renew or sign during my career, they need serious editing to allow me to publish my patches to open source or free software. I always write that in and get it counter-signed as part of my hiring process. That allows me to get fixes published upstream so I don't have to re-patch them.
"When do you update software?" If they say "we don't fix what isn't broken", I worry. You can waste hundreds of man-hours backporting features to old operating systems or old toolkits, and that work doesn't actually improve the next round of products: it wastes your efforts in ways that do not get you bonuses or advance your career. (Admittedly, my career now includes an incredible amount of this sort of thing, but that's because I'm old and considered expert in the older technologies.)
"What build system do you use?" Every single workplace that I've seen that built their own from scratch, usually by some brilliant developer frustrated with build systems they never fully understood, spent hundreds or thousands of man-hours on learning it and using it, only to see it fall apart as the developer ran into the same problems "make" and "autoconf" solved more than a decade ago.
Yes, it does. PAM is part of how it's integrated into various authentication tools. I use it just that way. Unfortunately, environments that insist on "don't change it if it's not broken!!!!" remain roughly five years behind the times in OpenSSH features, and the result is considerable difficulty in integrating Kerberos and especially true "single-sign-on" into a working environment.
I recently had a fascinating chat with an RHEL environment where getting them off of RHEL 4 was a serious, many layers of management playing phone-tag involved process because no one there could be permitted to take responsibility for maintaining anything, and thus they agreed to spend 3 times as much money and effort to have security and other updates backported, with no certainty of stability or success.
They're also easily forged. The paper at http://cryptome.org/gummy.htm [cryptome.org] is seven years old, I'm _amazed_ that those expensive pieces of wishful thinking are still in use.
PAM _does not help_. In fact, it reverses the problem, and makes various passwords able to access your account, especially in a carelessly configured multiple OS environment, all able to work on your poor victim of a Linux system.
Please allow me to be a serious geek here for a bit.
_Kerberos_ solved this problem years ago for user authentication. LDAP coupled with it, well-managed, provides the user and account management. Both are fundamental to Active Directory, oddly enough, which can support quite a lot of well-managed single-sign-on access. But it's not well integrated to a huge variety of pen source tools, whether it's from Active Directory or well-managed Kerberos sites like many major universities and companies.
The result is stupid holes in the process: OpenSSH on RHEL 4 and older SuSE and Fedora systems does not support the necessary GSSAPI. The configuration tools don't provide the critical hooks for permitting multiple upstream Kerberos domain authentication for shared environments, and you have to edit krb.conf by hand. The enormously popular "Putty" tool for SSH use does not support Kerberos. (There are forks that do, but the work has languished for years.)
I'll save my comments on Subversion silently and automatically saving your passwords in $HOME/.subversion/auth/svn.simple/ for another time. Do go check your directory on any machines you do work on, though.
Define "spam". Unfortunately, both the EU and the US have laws that are very generous in permitting bulk email: even if the blatantly illegal and fraudulent material is controlled, there remains a lot of protected material that can be and is sent.
Is the EU law any better than the truly stupid US's 'CAN-SPAM' act?
Look again at the source code, the copyrights and authorship. It is most certainly _not_ a clone, neither legally nor functionally nor in quite a number of its core kernel functions. It's why cross-porting core software is sometimes so awkward.
You forgot number 0: "scheduling". Scheduling time for each other, time for household tasks, time for shopping, time for yourselves, and overtall the time to actually do that "work" you mention.
And divorce is not a failure like dying is not a "failure to berathe".