While I agree with you almost universally, I think in this case, the pricing is meant to be part of the loss aversion technique the creator is employing.
My problem is there is no such thing as a lifetime subscription anymore. More like "until the company gets acquired and the new parent company gets bored or until I get bored, whichever comes first".
There is an ecological cost to miles and miles of solar panels. Desert ecosystems are extremely fragile, and these kinds of projects can be very damaging. It’s not just wasteland. (Said as a desert Southwest denizen and lover who gets the impression that many people think, “oh, there’s no trees? It’s unimportant land.”)
I want the Utes to have success in this, but I don’t want the general attitude to be “trash the desert because there is sun there”.
The ecosystem will change, no doubt about that. Just like it changes when we start agriculture somewhere, or pastoralism. Even if we consider that the new ecosystem of desert with a lot of shade might affect neighboring pristine desert within quite a radius, there will still be a lot left in the foreseeable future. Very much unlike agriculture and pastoralism, which have been pushed into almost every corner even remotely viable for millennia.
It might be worthwhile to exclude certain areas of particularly rare variations of the ecosystem to be built in. But it's easy to end up with too much red tape that will be abused for NIMBY and by people who hide a fossil yolo attitude behind a facade of conservationism.
Perhaps there could be some mechanism for operating some veto quota, "pick the project you want most desperately to be stopped"? That scheme would probably end getting gamed in the ugliest ways, with sacrificial decoy projects getting proposed, not vetoed and then getting built to keep up appearances. Better not, heh.
There is the concept of "agrivoltaics" where solar and agriculture can be colocated. Apparently, certain fruits and veggies grow better with a bit of shade provided by solar panels.
The first series of courses in my CS program introduced us to building a pascal interpreter using scheme. It all depends on the pedagogical needs, I suppose.
I doubt it. A human should be able to tell whether they are breaking the law or doing something that is dangerous and, thus, stop. If a human moved forward with something they should have known was dangerous or illegal, it would be grounds for negligence or worse.
> A human should be able to tell whether they are breaking the law or doing something that is dangerous and, thus, stop.
Yes, but:
- When determining whether or not a process is automated is legally important, it's usually because it is fine (legally) if done by humans - it's doing it automatically, at scale, that is the issues.
- White-collar workers generally don't do things that are obviously dangerous. They're crunching numbers and typing data into forms, and their input is usually a small component of any danger materializing.
The way I see it, the difference here is whether a human worker is able to override their checklist in cases where the action is neither illegal nor dangerous, but they realize it's obviously wrong or unfair.
Extremely rare diseases and diseases that have no known treatment options are given more lax rules for testing. Without that, there would be no way to develop treatments for them, but it comes with a side benefit of providing a method to attempt new treatment modalities.
Ksplice is the leading technology that allows administrators to patch the
kernel on the fly with zero downtime and zero disruption. We're a
distributed team of engineers forming part of the Linux and Virtualization
group at Oracle with a passion for working on exciting technology, software
engineering and all things Linux. Ksplice powers some of Oracle's biggest
systems from massive databases to clouds. Join us on our quest to minimize
downtime and secure systems. We're looking for a systems engineer to join
us, helping Ksplice patch even more of the system, support new releases and
improving our workflow.
Required skills include:
* Deep understanding of developing the Linux/UNIX kernel
* Skilled with software development best practices including TDD
* Expert level C/C programming
* Understanding of security issues and defences in compiled languages
* Strong experience with Python
* Excellent problem solving and debugging skills
* Test automation
Send resumes (or questions) to travis.jensen (at) oracle.com.
Let's be clear here, though: it's the airlines who refuse to buy an aircraft with additional training requirements. Pilots can only fly one aircraft type, and retraining to a different type is an expensive proposition. If Boeing could make an aircraft that fit under the 737 type, they really had no choice but to do it.
They also probably could have succeeded, too, if not for other systemic problems within the company.
It is not clear to me that they probably could have succeeded in satisfying all these conflicting goals, if not for other systemic problems in the company. Even now, with (one hopes) everything in the open and the systemic problems pushed aside, they are having trouble getting it done.
You say Boeing had no choice, but one choice was to acknowledge the problems, aim to keep the type certification with additional training, and negotiate with its potential customers on that basis. There is no law of mankind or nature that says Boeing is entitled to a certain number of sales at a particular profit.
> Design a damned airframe that's airworthy without needing stabilization hacks.
The 737 Max is stable, as all commercial aircraft have to be. MCAS is not a system to take an unstable 737 and make it stable. It's a system that was meant to take a changed 737 and make it fly nearly identical to a previous 737, so pilots didn't have to get a new type rating (a very big deal for airlines).
Juan Brown, a commercial pilot and certified flight mechanic, on YouTube has a (great series of videos)[https://www.youtube.com/playlist?list=PL6SYmp3qb3uPp1DS7fDy7...] talking through the mess that is Boeing made of MCAS, including what the actual problem is.
One of the most important things I've learned over the years I've managed people is that processes and policies of any sort are two-edged swords. It's easy to add a policy, and to convince oneself of the advantage the policy will confer. What is very often ignored is the cost of a policy.
Every policy comes with an associated cost, and those costs can add up quickly. People always ask "what will this policy make better", but, just as important, is to ask, "what will this policy make worse".
I like to talk about trade-offs a lot, and opportunity cost is also a good way to look at it. But yeah, it’s not often I see that happen.
Even better, make that a function of time so your cost/benefit analysis looks further beyond your initial preference. Spending more to save more is a highly effective choice in the right circumstances, and equally so, a perceived rapid gain can cost a fortune a bit later on.
It’s never so easy as saying always do D, prefer Y, avoid Z. They’re prescriptive and reactionary.
My problem is there is no such thing as a lifetime subscription anymore. More like "until the company gets acquired and the new parent company gets bored or until I get bored, whichever comes first".