Please look up the word "albedo". Raising the albedo would be effectively making the earth's service more reflective, reducing solar heating. You seem to think it means "energy absorption".
I personally wish that this worked so we could use it for fusion fuel. Sadly, you need protons from somewhere to get even a _vaguely_ stable Helium atom, which is why all the even testable fusion reactors use deuterium and tritium.
I've explained this on Slashdot before: Even if such plants reach "break even", creating more available energy than they use to run, they can't possibly scale to production use because the tests that are even _slightly_ successful use tritium as a critical fuel component. And the only viable source of tritium is ordinary nuclear fission reactors: there is no scalable natural source for it.
There is _no_ fusion technology ever tested, nor realistically proposed that does not rely on tritium. And every source of tritium itself, either earth-bound fission or potentially solar sail collectors for solar tritium, is _itself_ far more efficiently used as a straight power supply by itself. Sustainable fusion is interesting as a technological accomplishment, but it's not a viable power source unless the need for tritum is eliminated.
What you describe is a political issue, not a technological one. Unless you've already made strong friends with the IT staff, and _earned_ their respect and trust, expect them to resist you at every step. In particular, expect their middle management layers to disagree with every move and sabotage them behind your back. And I'm afraid you're starting out with a basic confusion: "3000 employees" is not a medium sized, company, it's a _big_ company. I'm also afraid that if you think of it as a medium size company, you'll be tempted to micromanage individual employees and pet projects. You're not going to have time for this, really.
Earning the respect and trust of the existing staff is going to be awkward. You're going to need that: they're going to need questions answered, clear decisions made with clear justification, and a clear set of technology and social practices so they know what is expected. Documentation, backup, and standard practices for network and environment configuration are all going to come from or be signed off on by you. If they disagree with a practice, they need to be safe to express it safely, work with you to iron out the differences, and if it turns out one of you were dead wrong, to get the other's insight credited and the other person educated on why the right practice is just that.
And I'm afraid many practices aren't that clear-cut: flexibility versus recoverability, reliability versus expense, growth over repair are all going to require decisions coming from you, as an architect. And even when you make the "right" decision, sometimes things are going to break that the "wrong" decision would have avoided. Some of them are going to be _large_.
That's partly why the existing staff are afraid of handing over admin access. Another possibility is that they're _embarrassed_ and you'll have immediate visibility into what they're embarrassed about. I've had tremendous difficulty with staff leaving in unannounced backdoors "to get their jobs done" and not wanting me to know about them. I've even been booted right off a project because I kept going to the manager with "your technical leader is putting in backdoors for his telecommuting here, here, and here, in direct violation of SOX guidelines: I can't sign off on this".
Anecdotes aside, you're going to have to establish trust with these people. From your short description, it sounds like they've been thinking of you as the enemy. If they're unhappy and can't work with your vision, check if your vision is confused and you can accommodate their ideals and goals. If you can't incorporate their goals, or if they're just plain wrong, show them the door gracefully. And let them know what your "vision" is, so they can be sure if you'll like their plans or if they're going to have trouble convincing you something is workable.
The best way to show them the door is to help them get hired somewhere else better suited to their neds as well as yours. I've had good success with staff who'd outgrown our environments, or our environments had moved to new practices they didn't care for, helping them find work with partners and other companies who appreciated their approach. I've even done a few flat-out exchanges: "You need a new security expert, we need a new backup expert", we've swapped staff, and we both came out better for it.
Or both., I'm afraid. Or the survey was badly constructed. I've seen a number of security compliance surveys, especially now with HIPAA laws affecting health care security, that were designed to allow hospital IT departments to claim more or less security with subtle interpretation. The result is that for medical IT staff who needed more security funding, and wanted to justify the work, they'd answer the surveys one way and say "we have a problem, we need to spend money". And if they wanted to report success the next year, despite no genuine oerall change, they'd choose other similarly "interpritive" answers and point to the improvement in security.
The stroke he suffered while writing "Number of the Beast" affected Robert Heinlein a great deal. I'm afraid having so many adoring fans, and editors who grew up with his earlier work, gave him enough influence that editors didn't dare to rein in his works with the plot unification and cutting of excess themes that a good editor would apply to a less successful author. It's a common problem for successful authors, and coupled with his age and the stroke, I'm afraid Heinlein's work suffered.
The "Heinlein juveniles" were exciting and inspirational work for many people, especially engineers. His characters were humans, many were engineers by nature if not by trade, and they bothered to do the work to master their crafts and to use the available tools to their full extent. The Lazarus Long anecdotes were filled with the lessons of an old man who's learned tremendous wisdom and tries to share it, and the Moon is a Harsh Mistress explored family life and guerrilla warfare and space-based warfare and the moral ramifications of AI and shortsighted politcal thinking, all in the same story. Stranger in a Strange Land explored the idea that language shapes thinking, and that to fully understand something is to love and cherish it as it exists, but does _not_ mean accepting that it should continue to exist.
I recommend Heinlein's older work to youngsters today in much the same way I recommend Terry Pratchett's fantasy work. They're entertaining, they pay attention to the consequences of technology and technological shifts, and they carry interesting moral lessons.
> Account should not try to "get knowledgeable" in HTML and JavaScript. He will only seem more of an idiot.
Unless he learns a bare minimum, he will be _owned_ by the technical people, who will exploit his lack of knowledge to make irrelevant work seem more important. I've seen this a great deal, with pointless code churn and endless "meetings" used to justify the size of a group that is accomplishing very little, for group members to take on irrelevant projects, and to leave only a few core people doing any real work.
It's also not normally the job of an accountant to "make the work profitable", any more than it is the role of security to make the product usable. There are critical exchanges of power for speed, of cost for usability and scalability, that an accountant _can_ help with.
> Might be because the systems I was involved in where not supposed to run on washing machines.
Then you don't look at Linux device drivers, and apparently don't look at highly performance optimized daemons. That's fine: you may not have needed to do this.
> That is a non sense sentence. What exactly is an unreliable compilation?
"Unreliable compilaton" could mean many things. Code that is likely to give different results based on subtle compilaton option differences, such as optimization levels, due to assuming default population of uninitialized variables is my current favorite. Code that produces different binary functions dependent on compiler assumed architecture is another, such as using "int" versus "uint_32", is another older favorite from when I did more porting of 32-bit code to 64-bit environments. Code that relies on replacing system libraries with its own particular "tuned" versions of libraries or standard OS functions is another, since it becomes vulnerable to inconsistencies in the compiler flags and a developer who fails to set them correctly can get surprisingly inconsistent behavior.
Other features do not so much prevent compiler inconsistency, but help with programmer consistency. Following the local style guide, using consistent naming schemes for variables, keeping memory handling in one consistent area of code so "free" and "malloc" are easily tracked, and sanitizing I/O before relying on it are all aids to consistent behavior.
A great deal of professional code is published: it's key to the Apache foundation and the Free Software Foundation. And a great deal of the more straightforward being published as "C++" for lightweight applications is standards compliant C. I just went through a similar issue with a job applicant who wrote backend website processing: That person's code had _no_ C++ elements in it, written for the simplest and most reliable compilation. It was very lightweight, the libraries it required were very stable, and it had _no_ dependency confusion common to the "overloading" of C++ functions. I was quite pleased with their code.
> Gotta tell you - you sound like a real classy professional.
That seems confusing. Please, re-read what I said. I said that making multiple concealed copies of licensed software hidden by virtualization to violate their licensing would be illegal. Where, exactly did I say "but we do it anyway"? I don't, myself do it, and I would have a long professional talk with any of my colleagues I caught doing it.
I do that a great deal. Not with Windows 95 for some time now, but for node-locked licenses for some _very_ expensive software that companies are unwilling to upgrade. And it would be quite illegal of me or my people to explain to the customer, in detail, how to run the locked node inside a virtualized network, and run other copies of the same VM inside other virtualized private networks only connected via NAT to the outside world. No, that would be a license violation.
I've also done similar setups for numerous UNIX and Linux distributions as well.
Because they are both used with API compliant software to accomplish specific computer behavior, including I/O, programmed operations, and back end integration with style guides, QA verification, and clear functional success of the computer application if misused or if ocrrectly implemented. They may not be Turing complete and able to compile their own interpreters written in their own language as source code, but they're certainly "languages" as far as listing them on a resume or planning training are concerned.
Also, they're quite a _lot_ of the hosted code on github: it's certainly reasonable to acknowledge their roles in open source.
As soon as you put "removable" BIOS chips back, you have to provide physical access to that chip, you have to provide board space to mount it, it increases the price of the motherboard, and most important to security, it provides the possibility of corrupt vendor replacement of the BIOS chip with their _own_ socket replaced chip with only poweroff physical access, not console access to run the drivers or work with attached boot media.
I'm not saying this is a greater attack vector: but it's one that has to be considered for high security systems.
Servants to reduce their physical workload? Yes. Cooks to prepare food with little effort? Yes. One day's labor or income providing more than 10 days of food? Yes. Plenty of food all winter? Yes. Children somewhere else for much of the day? Yes.
Sugar is a _result_ of wealth and modern industry supported by that wealth. I'm afraid it's hardly the only factor modern obese people share with historically obese people.
> I'm pretty sure most dashslot readers have not even been accused of "molesting five children, including his own sisters",
Given the accusations and abuse heaped on various software project leaders or contributors, it's more common than you may realize.
Also, I'm afraid that the standards for what constitutes "molesting children" vary from culture to culture, and even from state to state. There are cultures where clitorectomy, which I would certainly classify as sexual abuse of children, is considered part of proper upbringing. Looking at https://www.cga.ct.gov/2003/ol... for rape statutes, the first state listed considers it a felony for an 18 year old to have sex with a 15 year old.
Even marriage among siblings has occurred in small communities, and among royalty, throughout history. And sexual play among siblings is surprisingly common among humans and other mammals. This doesn't mean that I, for one, recommend it. But by itself, without violence or threats or other harassment, it should not turn the recipient of sexual molestation into an automatic object of lifelong pity.
Administered by a skilled storage, hardware, and network team. Training up such a team and keeping them employed, without managerial or technical errors destroying the whole system, for years, is far beyond the skills of most IT departments.
I've built such offsite storage: I've helped people recover from the _inevitable_ sitewide disasters that overwhelm reasonable protections. Much like running your own mail server, Google has consistently outperformed and outlasted single company systems. Bulk data storage and handling is one of their core technologies, and this was a genuinely exceptional failure which very, very few home brew systems would have survived.
I'm afraid that had nothing to do with write speed for storage. It had a great deal to do with deliberately keeping the design very light, using very effective proxies for the very light and consistent images, and keeping tight reins on web designers who might want to front load the Google pages with exciting content that had no relationship to the service.
I'm confused why you mention it, unless you think that the wise practices and designs that led to such effective and quick interfaces affected their storage designs, as well.
That's very unlikely The "knee jerk response" is a spinal response to a sudden extension of the relevant leg muscle, and occurs in the base of the spinal cord, in the "lumbar" region. Without a full, functioning spinal cord, and muscles connected to it with nerves to train the response, you're unlikely to ever find any spinal responses.
Except when it can't There's a great deal of continued tube use in harsh environments, where the temperature sensitivity of semiconductors presents a very real limitation, or where their very small size makes them more vulnerable to radiation damage, there's the behavioral differences when overdriven, and the list goes on.
> Actually, there are sanctions for lawyers who are untruthful to a tribunal, and federal judges, as a rule, are not complete morons.
No, but too often judges and lawyers are complicit in guiding the decision they way they want, despite existing law. This is a part of why litigants "venue shop", to place a court in front of the court or in the jurisdictional most favorable to their own desires. And the penalties for their misbehavior, when applied, are often outrageously low. These include Canter&Siegel, the attorney team that committed the first Internet spams and persisted in the business for years, the patent troll attorneys who claim clearly nonsensical patent violations simply to get defendants to settle out of court, and the attorneys working for the SCO Group with their fraudulent claims about UNIX and Linux copyrighted material for which their client did not own and had no standing to file suit.
I know many competent and skilled lawyers whom I've developed trust with, but the punishments for legal abuse by lawyers are very light. You cannot rely on sanctions to stop abuse by lawyers.
There's no sign that the copyrights on Mickey Mouse will _ever_ enter the public domain. There are strong reasons that the relevant copyright law is called the "Mickey Mouse Protection Act". I expect another extension act to be signed, with strong movie and music industry lobby support, shortly before the existing copyright protections for Mickey Mouse expire.
XKCD is also much funnier if you read the text-over captions. And I've repeatedly found myself referring to specific XKCD cartoons in technical meetings, to explain the problem with someone's clever sounding approach. Examples from the last few months include:
Sudo make me a sandwich.
Universal connector box.
Standards.
ISO 8601.
Real programmers.
Workflow.
Not everything is as good as those, but I've enjoyed them a great deal with children of my acquaintance.
I was apparently unclear. "Could be a felony" referred to 609.765 . The full statute is at https://www.revisor.mn.gov/sta..., it's fascinating reading if you're interested in free speech. Whether it's a felony or not is unclear to me at first reading, but whether it was criminal according to that statute would seem pretty clear.
I'm _pleased_ that the statute was struck down later as overbroad and unconstitutional.
The more clear misdemenator reference you mention is for 609.77, which cites a misdemeanor for passing falsehoods to media.
Slashdot Mirror
Please look up the word "albedo". Raising the albedo would be effectively making the earth's service more reflective, reducing solar heating. You seem to think it means "energy absorption".
> H + H to make He
I personally wish that this worked so we could use it for fusion fuel. Sadly, you need protons from somewhere to get even a _vaguely_ stable Helium atom, which is why all the even testable fusion reactors use deuterium and tritium.
I've explained this on Slashdot before: Even if such plants reach "break even", creating more available energy than they use to run, they can't possibly scale to production use because the tests that are even _slightly_ successful use tritium as a critical fuel component. And the only viable source of tritium is ordinary nuclear fission reactors: there is no scalable natural source for it.
There is _no_ fusion technology ever tested, nor realistically proposed that does not rely on tritium. And every source of tritium itself, either earth-bound fission or potentially solar sail collectors for solar tritium, is _itself_ far more efficiently used as a straight power supply by itself. Sustainable fusion is interesting as a technological accomplishment, but it's not a viable power source unless the need for tritum is eliminated.
What you describe is a political issue, not a technological one. Unless you've already made strong friends with the IT staff, and _earned_ their respect and trust, expect them to resist you at every step. In particular, expect their middle management layers to disagree with every move and sabotage them behind your back. And I'm afraid you're starting out with a basic confusion: "3000 employees" is not a medium sized, company, it's a _big_ company. I'm also afraid that if you think of it as a medium size company, you'll be tempted to micromanage individual employees and pet projects. You're not going to have time for this, really.
Earning the respect and trust of the existing staff is going to be awkward. You're going to need that: they're going to need questions answered, clear decisions made with clear justification, and a clear set of technology and social practices so they know what is expected. Documentation, backup, and standard practices for network and environment configuration are all going to come from or be signed off on by you. If they disagree with a practice, they need to be safe to express it safely, work with you to iron out the differences, and if it turns out one of you were dead wrong, to get the other's insight credited and the other person educated on why the right practice is just that.
And I'm afraid many practices aren't that clear-cut: flexibility versus recoverability, reliability versus expense, growth over repair are all going to require decisions coming from you, as an architect. And even when you make the "right" decision, sometimes things are going to break that the "wrong" decision would have avoided. Some of them are going to be _large_.
That's partly why the existing staff are afraid of handing over admin access. Another possibility is that they're _embarrassed_ and you'll have immediate visibility into what they're embarrassed about. I've had tremendous difficulty with staff leaving in unannounced backdoors "to get their jobs done" and not wanting me to know about them. I've even been booted right off a project because I kept going to the manager with "your technical leader is putting in backdoors for his telecommuting here, here, and here, in direct violation of SOX guidelines: I can't sign off on this".
Anecdotes aside, you're going to have to establish trust with these people. From your short description, it sounds like they've been thinking of you as the enemy. If they're unhappy and can't work with your vision, check if your vision is confused and you can accommodate their ideals and goals. If you can't incorporate their goals, or if they're just plain wrong, show them the door gracefully. And let them know what your "vision" is, so they can be sure if you'll like their plans or if they're going to have trouble convincing you something is workable.
The best way to show them the door is to help them get hired somewhere else better suited to their neds as well as yours. I've had good success with staff who'd outgrown our environments, or our environments had moved to new practices they didn't care for, helping them find work with partners and other companies who appreciated their approach. I've even done a few flat-out exchanges: "You need a new security expert, we need a new backup expert", we've swapped staff, and we both came out better for it.
> 20% of Healthcare CIOs are idiots or liars.
Or both., I'm afraid. Or the survey was badly constructed. I've seen a number of security compliance surveys, especially now with HIPAA laws affecting health care security, that were designed to allow hospital IT departments to claim more or less security with subtle interpretation. The result is that for medical IT staff who needed more security funding, and wanted to justify the work, they'd answer the surveys one way and say "we have a problem, we need to spend money". And if they wanted to report success the next year, despite no genuine oerall change, they'd choose other similarly "interpritive" answers and point to the improvement in security.
The stroke he suffered while writing "Number of the Beast" affected Robert Heinlein a great deal. I'm afraid having so many adoring fans, and editors who grew up with his earlier work, gave him enough influence that editors didn't dare to rein in his works with the plot unification and cutting of excess themes that a good editor would apply to a less successful author. It's a common problem for successful authors, and coupled with his age and the stroke, I'm afraid Heinlein's work suffered.
The "Heinlein juveniles" were exciting and inspirational work for many people, especially engineers. His characters were humans, many were engineers by nature if not by trade, and they bothered to do the work to master their crafts and to use the available tools to their full extent. The Lazarus Long anecdotes were filled with the lessons of an old man who's learned tremendous wisdom and tries to share it, and the Moon is a Harsh Mistress explored family life and guerrilla warfare and space-based warfare and the moral ramifications of AI and shortsighted politcal thinking, all in the same story. Stranger in a Strange Land explored the idea that language shapes thinking, and that to fully understand something is to love and cherish it as it exists, but does _not_ mean accepting that it should continue to exist.
I recommend Heinlein's older work to youngsters today in much the same way I recommend Terry Pratchett's fantasy work. They're entertaining, they pay attention to the consequences of technology and technological shifts, and they carry interesting moral lessons.
> Account should not try to "get knowledgeable" in HTML and JavaScript. He will only seem more of an idiot.
Unless he learns a bare minimum, he will be _owned_ by the technical people, who will exploit his lack of knowledge to make irrelevant work seem more important. I've seen this a great deal, with pointless code churn and endless "meetings" used to justify the size of a group that is accomplishing very little, for group members to take on irrelevant projects, and to leave only a few core people doing any real work.
It's also not normally the job of an accountant to "make the work profitable", any more than it is the role of security to make the product usable. There are critical exchanges of power for speed, of cost for usability and scalability, that an accountant _can_ help with.
> Might be because the systems I was involved in where not supposed to run on washing machines.
Then you don't look at Linux device drivers, and apparently don't look at highly performance optimized daemons. That's fine: you may not have needed to do this.
> That is a non sense sentence. What exactly is an unreliable compilation?
"Unreliable compilaton" could mean many things. Code that is likely to give different results based on subtle compilaton option differences, such as optimization levels, due to assuming default population of uninitialized variables is my current favorite. Code that produces different binary functions dependent on compiler assumed architecture is another, such as using "int" versus "uint_32", is another older favorite from when I did more porting of 32-bit code to 64-bit environments. Code that relies on replacing system libraries with its own particular "tuned" versions of libraries or standard OS functions is another, since it becomes vulnerable to inconsistencies in the compiler flags and a developer who fails to set them correctly can get surprisingly inconsistent behavior.
Other features do not so much prevent compiler inconsistency, but help with programmer consistency. Following the local style guide, using consistent naming schemes for variables, keeping memory handling in one consistent area of code so "free" and "malloc" are easily tracked, and sanitizing I/O before relying on it are all aids to consistent behavior.
A great deal of professional code is published: it's key to the Apache foundation and the Free Software Foundation. And a great deal of the more straightforward being published as "C++" for lightweight applications is standards compliant C. I just went through a similar issue with a job applicant who wrote backend website processing: That person's code had _no_ C++ elements in it, written for the simplest and most reliable compilation. It was very lightweight, the libraries it required were very stable, and it had _no_ dependency confusion common to the "overloading" of C++ functions. I was quite pleased with their code.
> Gotta tell you - you sound like a real classy professional.
That seems confusing. Please, re-read what I said. I said that making multiple concealed copies of licensed software hidden by virtualization to violate their licensing would be illegal. Where, exactly did I say "but we do it anyway"? I don't, myself do it, and I would have a long professional talk with any of my colleagues I caught doing it.
I do that a great deal. Not with Windows 95 for some time now, but for node-locked licenses for some _very_ expensive software that companies are unwilling to upgrade. And it would be quite illegal of me or my people to explain to the customer, in detail, how to run the locked node inside a virtualized network, and run other copies of the same VM inside other virtualized private networks only connected via NAT to the outside world. No, that would be a license violation.
I've also done similar setups for numerous UNIX and Linux distributions as well.
> No one does C, unless he is forced by someone to do so, people usually do C++.
Or they write in C and use a C++ capable compiler, like "gcc". A lot of "C++" code being published has no elements specific to C++.
Because they are both used with API compliant software to accomplish specific computer behavior, including I/O, programmed operations, and back end integration with style guides, QA verification, and clear functional success of the computer application if misused or if ocrrectly implemented. They may not be Turing complete and able to compile their own interpreters written in their own language as source code, but they're certainly "languages" as far as listing them on a resume or planning training are concerned.
Also, they're quite a _lot_ of the hosted code on github: it's certainly reasonable to acknowledge their roles in open source.
As soon as you put "removable" BIOS chips back, you have to provide physical access to that chip, you have to provide board space to mount it, it increases the price of the motherboard, and most important to security, it provides the possibility of corrupt vendor replacement of the BIOS chip with their _own_ socket replaced chip with only poweroff physical access, not console access to run the drivers or work with attached boot media.
I'm not saying this is a greater attack vector: but it's one that has to be considered for high security systems.
Servants to reduce their physical workload? Yes.
Cooks to prepare food with little effort? Yes.
One day's labor or income providing more than 10 days of food? Yes.
Plenty of food all winter? Yes.
Children somewhere else for much of the day? Yes.
Sugar is a _result_ of wealth and modern industry supported by that wealth. I'm afraid it's hardly the only factor modern obese people share with historically obese people.
> I'm pretty sure most dashslot readers have not even been accused of "molesting five children, including his own sisters",
Given the accusations and abuse heaped on various software project leaders or contributors, it's more common than you may realize.
Also, I'm afraid that the standards for what constitutes "molesting children" vary from culture to culture, and even from state to state. There are cultures where clitorectomy, which I would certainly classify as sexual abuse of children, is considered part of proper upbringing. Looking at https://www.cga.ct.gov/2003/ol... for rape statutes, the first state listed considers it a felony for an 18 year old to have sex with a 15 year old.
Even marriage among siblings has occurred in small communities, and among royalty, throughout history. And sexual play among siblings is surprisingly common among humans and other mammals. This doesn't mean that I, for one, recommend it. But by itself, without violence or threats or other harassment, it should not turn the recipient of sexual molestation into an automatic object of lifelong pity.
Administered by a skilled storage, hardware, and network team. Training up such a team and keeping them employed, without managerial or technical errors destroying the whole system, for years, is far beyond the skills of most IT departments.
I've built such offsite storage: I've helped people recover from the _inevitable_ sitewide disasters that overwhelm reasonable protections. Much like running your own mail server, Google has consistently outperformed and outlasted single company systems. Bulk data storage and handling is one of their core technologies, and this was a genuinely exceptional failure which very, very few home brew systems would have survived.
I'm afraid that had nothing to do with write speed for storage. It had a great deal to do with deliberately keeping the design very light, using very effective proxies for the very light and consistent images, and keeping tight reins on web designers who might want to front load the Google pages with exciting content that had no relationship to the service.
I'm confused why you mention it, unless you think that the wise practices and designs that led to such effective and quick interfaces affected their storage designs, as well.
That's very unlikely The "knee jerk response" is a spinal response to a sudden extension of the relevant leg muscle, and occurs in the base of the spinal cord, in the "lumbar" region. Without a full, functioning spinal cord, and muscles connected to it with nerves to train the response, you're unlikely to ever find any spinal responses.
Except when it can't There's a great deal of continued tube use in harsh environments, where the temperature sensitivity of semiconductors presents a very real limitation, or where their very small size makes them more vulnerable to radiation damage, there's the behavioral differences when overdriven, and the list goes on.
> Actually, there are sanctions for lawyers who are untruthful to a tribunal, and federal judges, as a rule, are not complete morons.
No, but too often judges and lawyers are complicit in guiding the decision they way they want, despite existing law. This is a part of why litigants "venue shop", to place a court in front of the court or in the jurisdictional most favorable to their own desires. And the penalties for their misbehavior, when applied, are often outrageously low. These include Canter&Siegel, the attorney team that committed the first Internet spams and persisted in the business for years, the patent troll attorneys who claim clearly nonsensical patent violations simply to get defendants to settle out of court, and the attorneys working for the SCO Group with their fraudulent claims about UNIX and Linux copyrighted material for which their client did not own and had no standing to file suit.
I know many competent and skilled lawyers whom I've developed trust with, but the punishments for legal abuse by lawyers are very light. You cannot rely on sanctions to stop abuse by lawyers.
There's no sign that the copyrights on Mickey Mouse will _ever_ enter the public domain. There are strong reasons that the relevant copyright law is called the "Mickey Mouse Protection Act". I expect another extension act to be signed, with strong movie and music industry lobby support, shortly before the existing copyright protections for Mickey Mouse expire.
XKCD is also much funnier if you read the text-over captions. And I've repeatedly found myself referring to specific XKCD cartoons in technical meetings, to explain the problem with someone's clever sounding approach. Examples from the last few months include:
Sudo make me a sandwich.
Universal connector box.
Standards.
ISO 8601.
Real programmers.
Workflow.
Not everything is as good as those, but I've enjoyed them a great deal with children of my acquaintance.
I was apparently unclear. "Could be a felony" referred to 609.765 . The full statute is at https://www.revisor.mn.gov/sta..., it's fascinating reading if you're interested in free speech. Whether it's a felony or not is unclear to me at first reading, but whether it was criminal according to that statute would seem pretty clear.
I'm _pleased_ that the statute was struck down later as overbroad and unconstitutional.
The more clear misdemenator reference you mention is for 609.77, which cites a misdemeanor for passing falsehoods to media.
> There is nothing in the world he could possibly have said that was more likely to destroy the teacher's career and reputation.
"She gave me AIDS" would be worse. So would "she gave me hepatitis C".