The _turf_ of bottom dwelling creatures can be quite small, especially of mollusks. Injuring them, or driving away their predators, is likely to have quite large ecological consequences. Even driving away vegetarian creatures from their feeding grounds is likely to interfere with stable ecologies.
Thank you for pointing out those examples. I'll be quite curious to see if they manage to survive even a single generation.
It can take time for the factors I mentioned to destroy a private currency. The "Miracle of Worgl", for example was shut down by the Austrian National Bank. (Avoiding federal taxes and control of the economy is always grounds to shut down private or semi-public experiments.) The Egyptian example had actual backing for the currency, and seems to have been government controlled. I'll acknowledge that "government" and "private" currencies might not have meant the same thing in ancient Egypt.
I'm afraid that I'm not clear on what you mean by the "cathedral economy". The manufacture of cathedrals seems to have been a government sponsored "public work" in the modern sense. Can you point to a better description of what you mean?
The Ithaca and Berkshires cases are interesting, but only several of the dozens, perhaps hundreds of such currencies in US history. Are you aware of any that have lasted even a single generation? I'm aware of several that have _failed_ in other cities, in my lifetime.
Inventing new, private currencies seems designed for abuse, and the harvesting of all money in the system by arbitrage traders with no practical regulation or control of the abuse. Such "non-currencies" have been tried before, and are inevitably brought down by one of these factors:
Governments concerned about taxes not being collected on the barter scrip.
Arbitrage abuse bleeding all the value out of the relevant currencies and destroying smaller investors.
Fraud by the central scrip maintainers.
All of these occurred with the "company scrip" that was used by many railroads to pay workers and tie their economy to the "company store" in the US expansion west.
From experience, you might be quite surprised at how many are transferable or retrainable to new roles. During the last few economic crashes in the US, quite a few younger or mid-level engineers had to withdraw from the higher tech markets because they needed to _eat_, or to support a family. They're now chronically under employed, and find it very difficult to get their next job to get back on the technology or professional hierarchical employment ladder.
Working with these people, and making sure they get _credit_ for the insights they bring to a workplace, is one of the pleasures of doing technology consultation or partnership. Finding out what they think and re-wrapping it with support and confirmation from an outsider can save tremendous amounts of work, and they're often _shocked_ when we make sure they get credit for it. These are people, in house, who should be taught whatever they were missing and transferred or promoted to the right role to use their skills. They've often been stuck behind various glass ceilings due to age, gender, native language, or cultural differences. If we can help open that glass ceiling for them, it's one of the delights of our work.
[ I speak as an older programmer, with plenty of diabetic acquaintances and family. ]
I'm afraid there are plenty of Type 2 diabetics whose weight gain was _triggered_ or at least ballooned, under the influence of Type 2 diabetes. The insulin resistance can also cause high insulin levels, which triggers hunger. The spiral of high insulin levels and weight gain can get out of hand very quickly. The result is that people believe that the weight gain triggered the Type 2, not the reverse, especially as the early symptoms are quite modest and only show up with regular blood testing or a glucose tolerance test. It also makes treatment quite difficult, since lapses can leave the victims feeling surprisingly hungry and eager to break their treatment regimes.
There are certainly millions of Type 2 diabetics who'd welcome a much simpler treatment approach: the oral medications do have complications. Injections are awkward, but there are certainly millions of Type 1 diabetics who absolutely need frequent insulin injections or insulin pumps who will say "get over it".
There are levels of sophistication. Surprisingly, "The Science of Discworld" has an excellent narrative explanation of how evolution creates new types of organism. It's partly by expanding opportunities for current organism by creating sophisticated ecosystems which stabilize the environment, and make energy and resources available that new types of organism attempt to use est and, occasionally, prosper.
It's also entertaining science, with a fine appreciation of how catastrophe has shaped biological history.
Oh, dear. _Energy_ is half the mass times the velocity squared. I'm afraid that's directly tied to the amount of fuel needed, not counting losses, to achieve that speed without friction. It's not really tied to the capabilities of the engines involved.
The difficulty is the necessary _thrust_, or force, needed to overcome resistance and _accumulate_ that much energy, and that much momentum, in the train itself. Even a well designed train will have considerable friction losses, at those speeds, in its own wheels and bearings. And the air resistance of a not-well-streamlined object can go up as the cube or more of the velocity, as turbulence forms and makes the resistive losses even worse.
I'm afraid that the current "whois" practices were deliberately set up to allow plausibility deniability, to protect the domain owners from being actually reached by the spammers and numerous sales people or lawyers with cause to contact domain owners. The domain vendors benefit from this: they can follow the letter of the law, but not actually support contacting the domain owners to handle criminal or abuse behavior, and wait for days, weeks, or years while lawyers collect the evidence and chain of repeated contact failures before a court order can be obtained.
In the meantime, they're collecting the registration fees, in bulk, for the relevant domain and all the related domain names. The current system is a critical revenue stream, which the domain and SSL key vendors have no need or desire to encumber by enforcing legitimate contact information.
For highly reliable code, knowing that the code you review is the code you compile with is vital both for stability and security. This can't be done by visual inspection: it requires good provenance at every stage of the game.
This is actually a security problems with many opensource and freeware code repositories. The authors fail to provide GPG signatures for their tarballs, or to GPG sign tags for their code. So anyone who can steal access can alter the code at whim. And anyone who can forge an SSL certificate can replace the HTTPS based websites and cause innocent users to download corrupted, surreptitiously patched code or tarballs.
I'm actually concerned for the day that someone sets up a proxy in front of github.com for a localized man-in-the-middle attack to manipulate various targeted projects.
Much of the data is free and available elsewhere. All the public domain content, in fact is freely accessible.
What JSTOR especially provides, and part of what Aaron was reaping wholesale, was its organization and links, basically the indexing and cross-indexing. _That_ is what makes JSTOR so useful, and what people pay JSTOR for: the breadth and searchability of the data. JSTOR is already a non-profit agency, whose fees are quite reasonable for the service they provide. And Aaron kept _breaking_ parts of JSTOR by downloading too much too fast, and overwhelming the servers.
Activism, or hacktivism, is one thing. Breaking critical research tools for millions of customers worldwide is abuse, and clearly criminal in several ways. I'm afraid that Aaron earned prosecution. The extent of the prosecution seems severe, but as best I can tell, the prosecutors were quite willing to "deal" for a a very low sentence, as long as the deal included a felony conviction. I'm afraid that that haggling over the charges and the sentence is _normal_ for prosecutors.
Not usually. the call centers are in India or other countries. A number of my H1B holding colleagues in the US spent some time working in those centers. They were very busy, and wound up learning some useful approaches, in some cases from people like me who walked them through what the real problem was and what we really needed.
Several years ago, while helping a corporate partner's personnel with a printer that their company manufactured and getting it working with Linux, one of their personnel recognized my style and my voice, because he'd come to the US. He was a visiting colleague from the printer company's India location, not an H1B holder, but as I mentioned having contacted the manufacturer about the issue, he recognized my voice and my style from working the call center before his promotion.
We had an interesting chat. He'd apparently been learning more about the systems, and going offscript and taking longer on the calls, which caused him trouble keeping the job. But he was also submitting suggestions to improve the tech support scripts and to cover weird cases, which got him noticed by a wise manager. And he'd worked for, and earned, promotions that now had him visiting the company's main offices to help improve system reliability. He was very much a "hacker" in the old sense of the word, and was delighted to be promoted where he could do more interesting work. I'd have hired him in a minute if my company's contracts did not prevent poaching.
> America has lots of room compared to the rest of the world
And let's keep it that way. A great deal of the rest of the world is having real problems with fresh water, arable land, and pollution. Highly industrialized nations require space, per capita, to provide the energy resources and the comfortable living space they enjoy. There are serious issues with health care costs and manpower for the elderly as the population ages, but H1B visas are not likely to help with that.
> Many, many businesses have learned the hard way that core software development needs to be in close (as in immediate, face-to-face) contact with the business side to translate requirements (often inchoate in the minds of the execs and product managers) into concrete requirements and actual software quickly in a very competitive market place.
Many business are trying to pretend that it's not relevant for IT work, and scatter their IT groups around the world. It's something I've tried to advise against when collaborating with or supporting other groups: the costs can be quie profound.
That's because the call center is in India. They're not H1B visa holders. And let's be honest: It's boring, tedious work that does not pay well _of course_ it will be outsourced.
> Not true. A factory is not built where the demand is, but where the labor is available. The goods can be shipped.
These are hardly the only factors. Power, raw materials, and taxation, the cost of land, regulatory restraints on traid, and handling refuse from manufacture also strongly influence factory location. "Goods can be shipped" also ignores the cost of shipping:
> the fall in unemployment follows rather than precedes the liberalization of immigration
The potential fallacy here is called "post hoc, ergo proctor hoc". It means "after, therefore because of". The timing you describe makes sense, but the rise you describe was tied to the creation of the European Union and the easing of trade across all the EU borders. The British were suddenly able to export and import a lot more freely, and _that_ helped with the employment boom.
I'm afraid that the "liminiferous aether" was the medium on which electromagenetic waves were carried. It was disproven by the Michelson Moreley experiment, which led to a lot of _other_ fascinating theories. Phlogiston was no more "thermal energy" than vacuum is what you pour into vacuum tubes. It was what came _out_ of burning substances and was contained in them to leak out as fire.
Please don't rewrite the history of physics and chemistry to try and invent "privatives", the measurable absence of a something found elsewhere, as a a "real" substance.
These are new designs, effectively release candidates. It is _extremely_ difficult, and hideously expensive, to pre-test everything in final configuration, and these are very complex systems that are subjected to enormous stresses on launch and recovery. Complex modeling and mechanical specifications cannot hope to catch the surprises that may be found in final reviews and checklists, on the ground, before launching the craft.
I'm afraid "improve build quality" could be a managerial directive, like "safety first" that doesn't actually describe any real, individual process that's not already in place.
> this being said, I can't really see filing the charges as being more cumbersome than doing the paperwork for letting them go.
I'm afraid it's not uncommon, especially at first. Handwritten documents have room for describing circumstances, many automated systems do not, or lack the necessary categories and wind up with the documents miscategorized or misdirected when first used. It's certainly common with trouble ticket and budget systems: I'm facing several such cases right now.
> Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).
Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.
I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.
The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.
The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.
Slashdot Mirror
The _turf_ of bottom dwelling creatures can be quite small, especially of mollusks. Injuring them, or driving away their predators, is likely to have quite large ecological consequences. Even driving away vegetarian creatures from their feeding grounds is likely to interfere with stable ecologies.
Thank you for pointing out those examples. I'll be quite curious to see if they manage to survive even a single generation.
It can take time for the factors I mentioned to destroy a private currency. The "Miracle of Worgl", for example was shut down by the Austrian National Bank. (Avoiding federal taxes and control of the economy is always grounds to shut down private or semi-public experiments.) The Egyptian example had actual backing for the currency, and seems to have been government controlled. I'll acknowledge that "government" and "private" currencies might not have meant the same thing in ancient Egypt.
I'm afraid that I'm not clear on what you mean by the "cathedral economy". The manufacture of cathedrals seems to have been a government sponsored "public work" in the modern sense. Can you point to a better description of what you mean?
The Ithaca and Berkshires cases are interesting, but only several of the dozens, perhaps hundreds of such currencies in US history. Are you aware of any that have lasted even a single generation? I'm aware of several that have _failed_ in other cities, in my lifetime.
Or the way it _doesn't_ work, I'm afraid.
Inventing new, private currencies seems designed for abuse, and the harvesting of all money in the system by arbitrage traders with no practical regulation or control of the abuse. Such "non-currencies" have been tried before, and are inevitably brought down by one of these factors:
Governments concerned about taxes not being collected on the barter scrip.
Arbitrage abuse bleeding all the value out of the relevant currencies and destroying smaller investors.
Fraud by the central scrip maintainers.
All of these occurred with the "company scrip" that was used by many railroads to pay workers and tie their economy to the "company store" in the US expansion west.
From experience, you might be quite surprised at how many are transferable or retrainable to new roles. During the last few economic crashes in the US, quite a few younger or mid-level engineers had to withdraw from the higher tech markets because they needed to _eat_, or to support a family. They're now chronically under employed, and find it very difficult to get their next job to get back on the technology or professional hierarchical employment ladder.
Working with these people, and making sure they get _credit_ for the insights they bring to a workplace, is one of the pleasures of doing technology consultation or partnership. Finding out what they think and re-wrapping it with support and confirmation from an outsider can save tremendous amounts of work, and they're often _shocked_ when we make sure they get credit for it. These are people, in house, who should be taught whatever they were missing and transferred or promoted to the right role to use their skills. They've often been stuck behind various glass ceilings due to age, gender, native language, or cultural differences. If we can help open that glass ceiling for them, it's one of the delights of our work.
[ I speak as an older programmer, with plenty of diabetic acquaintances and family. ]
I'm afraid there are plenty of Type 2 diabetics whose weight gain was _triggered_ or at least ballooned, under the influence of Type 2 diabetes. The insulin resistance can also cause high insulin levels, which triggers hunger. The spiral of high insulin levels and weight gain can get out of hand very quickly. The result is that people believe that the weight gain triggered the Type 2, not the reverse, especially as the early symptoms are quite modest and only show up with regular blood testing or a glucose tolerance test. It also makes treatment quite difficult, since lapses can leave the victims feeling surprisingly hungry and eager to break their treatment regimes.
There are certainly millions of Type 2 diabetics who'd welcome a much simpler treatment approach: the oral medications do have complications. Injections are awkward, but there are certainly millions of Type 1 diabetics who absolutely need frequent insulin injections or insulin pumps who will say "get over it".
In order to protect turf and progeny from your own species. One's own species is often the fiercest competition in the local ecology.
There are levels of sophistication. Surprisingly, "The Science of Discworld" has an excellent narrative explanation of how evolution creates new types of organism. It's partly by expanding opportunities for current organism by creating sophisticated ecosystems which stabilize the environment, and make energy and resources available that new types of organism attempt to use est and, occasionally, prosper.
It's also entertaining science, with a fine appreciation of how catastrophe has shaped biological history.
Oh, dear. _Energy_ is half the mass times the velocity squared. I'm afraid that's directly tied to the amount of fuel needed, not counting losses, to achieve that speed without friction. It's not really tied to the capabilities of the engines involved.
The difficulty is the necessary _thrust_, or force, needed to overcome resistance and _accumulate_ that much energy, and that much momentum, in the train itself. Even a well designed train will have considerable friction losses, at those speeds, in its own wheels and bearings. And the air resistance of a not-well-streamlined object can go up as the cube or more of the velocity, as turbulence forms and makes the resistive losses even worse.
I'm afraid that the current "whois" practices were deliberately set up to allow plausibility deniability, to protect the domain owners from being actually reached by the spammers and numerous sales people or lawyers with cause to contact domain owners. The domain vendors benefit from this: they can follow the letter of the law, but not actually support contacting the domain owners to handle criminal or abuse behavior, and wait for days, weeks, or years while lawyers collect the evidence and chain of repeated contact failures before a court order can be obtained.
In the meantime, they're collecting the registration fees, in bulk, for the relevant domain and all the related domain names. The current system is a critical revenue stream, which the domain and SSL key vendors have no need or desire to encumber by enforcing legitimate contact information.
For highly reliable code, knowing that the code you review is the code you compile with is vital both for stability and security. This can't be done by visual inspection: it requires good provenance at every stage of the game.
This is actually a security problems with many opensource and freeware code repositories. The authors fail to provide GPG signatures for their tarballs, or to GPG sign tags for their code. So anyone who can steal access can alter the code at whim. And anyone who can forge an SSL certificate can replace the HTTPS based websites and cause innocent users to download corrupted, surreptitiously patched code or tarballs.
I'm actually concerned for the day that someone sets up a proxy in front of github.com for a localized man-in-the-middle attack to manipulate various targeted projects.
> Outlook is particularly nasty.
Well, yes. There's a reason that so many partners and clients have swithed to Gmail and Google Docs.
You're quite correct. I've certainly worked with, and given my time for, non-profits who earned the label.
Much of the data is free and available elsewhere. All the public domain content, in fact is freely accessible.
What JSTOR especially provides, and part of what Aaron was reaping wholesale, was its organization and links, basically the indexing and cross-indexing. _That_ is what makes JSTOR so useful, and what people pay JSTOR for: the breadth and searchability of the data. JSTOR is already a non-profit agency, whose fees are quite reasonable for the service they provide. And Aaron kept _breaking_ parts of JSTOR by downloading too much too fast, and overwhelming the servers.
Activism, or hacktivism, is one thing. Breaking critical research tools for millions of customers worldwide is abuse, and clearly criminal in several ways. I'm afraid that Aaron earned prosecution. The extent of the prosecution seems severe, but as best I can tell, the prosecutors were quite willing to "deal" for a a very low sentence, as long as the deal included a felony conviction. I'm afraid that that haggling over the charges and the sentence is _normal_ for prosecutors.
Not usually. the call centers are in India or other countries. A number of my H1B holding colleagues in the US spent some time working in those centers. They were very busy, and wound up learning some useful approaches, in some cases from people like me who walked them through what the real problem was and what we really needed.
Several years ago, while helping a corporate partner's personnel with a printer that their company manufactured and getting it working with Linux, one of their personnel recognized my style and my voice, because he'd come to the US. He was a visiting colleague from the printer company's India location, not an H1B holder, but as I mentioned having contacted the manufacturer about the issue, he recognized my voice and my style from working the call center before his promotion.
We had an interesting chat. He'd apparently been learning more about the systems, and going offscript and taking longer on the calls, which caused him trouble keeping the job. But he was also submitting suggestions to improve the tech support scripts and to cover weird cases, which got him noticed by a wise manager. And he'd worked for, and earned, promotions that now had him visiting the company's main offices to help improve system reliability. He was very much a "hacker" in the old sense of the word, and was delighted to be promoted where he could do more interesting work. I'd have hired him in a minute if my company's contracts did not prevent poaching.
> America has lots of room compared to the rest of the world
And let's keep it that way. A great deal of the rest of the world is having real problems with fresh water, arable land, and pollution. Highly industrialized nations require space, per capita, to provide the energy resources and the comfortable living space they enjoy. There are serious issues with health care costs and manpower for the elderly as the population ages, but H1B visas are not likely to help with that.
> Many, many businesses have learned the hard way that core software development needs to be in close (as in immediate, face-to-face) contact with the business side to translate requirements (often inchoate in the minds of the execs and product managers) into concrete requirements and actual software quickly in a very competitive market place.
Many business are trying to pretend that it's not relevant for IT work, and scatter their IT groups around the world. It's something I've tried to advise against when collaborating with or supporting other groups: the costs can be quie profound.
> Yes, they're all from India. ALL OF THEM! Th
That's because the call center is in India. They're not H1B visa holders. And let's be honest: It's boring, tedious work that does not pay well _of course_ it will be outsourced.
> Not true. A factory is not built where the demand is, but where the labor is available. The goods can be shipped.
These are hardly the only factors. Power, raw materials, and taxation, the cost of land, regulatory restraints on traid, and handling refuse from manufacture also strongly influence factory location. "Goods can be shipped" also ignores the cost of shipping:
> the fall in unemployment follows rather than precedes the liberalization of immigration
The potential fallacy here is called "post hoc, ergo proctor hoc". It means "after, therefore because of". The timing you describe makes sense, but the rise you describe was tied to the creation of the European Union and the easing of trade across all the EU borders. The British were suddenly able to export and import a lot more freely, and _that_ helped with the employment boom.
I'm afraid that the "liminiferous aether" was the medium on which electromagenetic waves were carried. It was disproven by the Michelson Moreley experiment, which led to a lot of _other_ fascinating theories. Phlogiston was no more "thermal energy" than vacuum is what you pour into vacuum tubes. It was what came _out_ of burning substances and was contained in them to leak out as fire.
Please don't rewrite the history of physics and chemistry to try and invent "privatives", the measurable absence of a something found elsewhere, as a a "real" substance.
Perhaps on your projects: on mine, I'm afraid they represent direct expense and lost income
These are new designs, effectively release candidates. It is _extremely_ difficult, and hideously expensive, to pre-test everything in final configuration, and these are very complex systems that are subjected to enormous stresses on launch and recovery. Complex modeling and mechanical specifications cannot hope to catch the surprises that may be found in final reviews and checklists, on the ground, before launching the craft.
I'm afraid "improve build quality" could be a managerial directive, like "safety first" that doesn't actually describe any real, individual process that's not already in place.
> this being said, I can't really see filing the charges as being more cumbersome than doing the paperwork for letting them go.
I'm afraid it's not uncommon, especially at first. Handwritten documents have room for describing circumstances, many automated systems do not, or lack the necessary categories and wind up with the documents miscategorized or misdirected when first used. It's certainly common with trouble ticket and budget systems: I'm facing several such cases right now.
> Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).
Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.
I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.
The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.
The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.