It has a longer bed than the shortest bed option of the F-150, but shorter than the other two options. It's about a foot narrower than all of then though.
229 karma · joined December 14, 2012
That is, mostly the same people who already buy four-door pickups with 5.5 foot beds.
It could also be good for around-town trades, especially if they tow light trailers -- like landscape crews.
Perhaps this means the tractors can be less powerful if most trailers also provide some motive power.
For example, the fructose corn syrup subsidies exist, as far as I can tell, in order to on-shore agricultural profits and ensure sufficient slack in the domestic agricultural system to ensure that restrictions on imports of food, such as in the case of war, would not seriously affect the USA. That is, it's a subsidy towards food security.
For example, consider a paved rural road into farmland. In dollar terms paving that road is a subsidy from the nearest city to the people living in that rural area. However, in part the road is paved rather than gravel only to support heavier trucks to more efficiently transport agricultural products destined for the city. It is also paved in part to support larger, faster, heavier agricultural equipment which brings economies of scale to agriculture and reduces the per-unit price of the result -- again destined mostly for the city.
Residents themselves don't need the more expensive paved and it isn't their relatively light private vehicles causing most of the wear on the road in the first place.
Considered this way, a not insubstantial fraction of the cost of non-city areas is the city indirectly subsidizing itself. The full costs could be incorporated directly into the goods sourced from the supposedly subsidized areas, but that would be less efficient overall. For example, good roads reduces the cost of agricultural products for, say, three months a year. Instead of directly paying capital costs to pave the rural road the city could pay operational costs in higher food prices while missing the other cost advantages of the paved road the rest of the year in reduced recreational costs, policing costs, education costs, etc. If those other costs were higher there would be less of them and people would be less willing to live in those areas, increasing wage and commuting costs.
For example, it's well known that EV range decreases by 20-30% in cold weather and a recent study is claiming about the same loss in hot weather. And on long drives you tend to be more heavily loaded than normal, also cutting a few percent off actual range. Further, you need a reserve in case you get stuck on the road for some reason. Also you need a further reserve to ensure you can make it to the next next charger should the next charger be unavailable for some reason. And the advertised ranges are in better-than-average driving conditions at slower-than-average speeds, so you lose another few percent there as well.
All these derates stack which means if you want to ensure low stress in an EV you might have to derate the advertised range 50% or more depending on charger density for long drives when you decide to purchase. ICEs also need derating, but 25% is usually lots and ICEs tend to have much longer ranges to begin with.
"gut sync" merged in all the changes from the branch's parent into a single child branch, fetching if appropriate. We never got around to automating sequential syncing since the CI setup was weak in this project.
"gut create" created a new cascaded branch with the necessary tracking information from an arbitrary parent branch.
"gut review" posted the cascaded branch to the code review system so the diff would turn out correct.
"gut pdiff" would show the diff of the branch relative to the merge-base of the parent.
"gut reparent" would change the parent of a branch.
"gut insert" would insert a new cascaded branch between two existing branches -- useful for inserting refactors earlier in the series.
"gut merge" which merged the branch into the parent only once various checks, like review approval and passing tests and being at the head of the stack, were satisfied.
Suppose you have the stacked PRs in the following sequence: A, B, C, D, E, F
If you implement stacked PRs using branches in git, then they will be a series of branches. For example, A will be a child branch of master, and B a child of A. To bring new changes in from master all the way down to F requires at least three commands and a build per stack member:
git fetch
git checkout A
git merge master
build_and_run_tests
git checkout B
git merge A
build_and_run_tests
git checkout C
git merge B
build_and_run_tests
...
You've covered the major pros at a high level, but I think the details matter. For example "smaller PR" is a rather high-level pro which is true. But it's not just that PRs are smaller, but that they can be ordered to build functionality as a story and justify each change. This is much like how the Linux Kernel wants patch series and not just a single big patch. I find this helps make reviewing easier and faster. It can also help clarify some people's thinking.
Similarly, "keep working" is a high level truth, but it has important organizational consequences. For example, if there is no rush to merge things it means the entire team doesn't need to be interrupted several times a day to merge something. It also mean it's OK to open a deep discussion on something in the MR. I find both these make the team as a whole more productive because they can take the time to think. For example, I push my team to only do reviews once a day so they don't need to context switch and it gives discussions time for well thought out replies instead of rushed single-sentence responses.
There are some cons which are by no means insurmountable, but aren't free to solve.
The biggest one is teaching everybody on the team how to use cascaded MRs in a technical sense. The details depend on how you implement them, but I prefer cascaded branches with full merge commits. Tooling can help, but if they don't understand the underlying mechanics there will undoubtedly be problems where people can't get the review to look like what they want.
Secondary to this is teaching what a good patch series looks like and how to use the VCS to create it. Each PR really needs to pass CI on its own, which requires ordering code changes in a particular way which is opposite the order they were mostly likely implemented. For example, while working on something you'll probably notice a bug or refactor which needs to be done, but you only notice it mid-way through the work. So you want to move the refactor/fix to before the main work in the series. There are different ways to do this with different trade-offs and developers need to understand how and when to use them.
Finally, the biggest problem I've seen with stacked PRs is difficulty bringing in changes from master or whatever the parent is. With a single PR this is an easy merge/rebase. With a long series of these it's a repetitive series of merges (my preference) or rebases. Doing this manually is annoying and writing automation for it requires formalizing branch (or whatever) parent-child relationships. This isn't terribly difficult, but ideally the command line and IDE and repository viewer and code review software all agree on it, which is a bunch of tedious work.
Stacked PRs is _how_ you can break up your changes into small components to merge more quickly and block development less.
With stacked PRs the changes are broken into smaller pieces because a later PR can depend on an earlier PR. This means it can be developed while earlier PRs are still under review. It also means each review is smaller and therefore likely to complete more quickly.
Stacked PRs can also work like patch series in the Linux Kernel development where a large change is broken into smaller independent changes done in the logical order, even if their order of discovery was probably reverse. For example, if you discover you need a refactor or bug fix while halfway through developing a feature. In that case you simply insert a PR earlier in the stack/graph which contains just that isolated fix.
In your feature flag example, a common patten would be to have a dozen or so stacked PRs. The early ones do necessary refactors and bug fixes. The middle few add the feature flag and code. The last make the feature flag the default and delete the now obsolete !feature path. Then the prereqequites (which you didn't discover until half-way through) can be reviewed and merged quickly. The meat of the feature is broken up into easily digestible pieces for quick review, but reviewers can get a sense of the entire feature by considering the PR series as a whole; this is especially useful where one PR adds some infrastructure that a later PR uses but both PRs together would be too large to effectively review. As PRs are ready to merge, they can. Often the last couple of PRs which make the feature the default and delete the obsolete code do not merge for quite some time, but they were written when everything was still fresh in the developers head.
Using a rebase workflow with stacked/cascaded PRs is an anti-pattern that trips up people used to other git workflows where the history depth is effectively only one level deep instead of arbitrarily deep as in stacked/cascaded PRs.
LCOE is (lifetime costs)/(lifetime generation), but the value of that generation is very different between intermittent sources and dispatchable sources and the difference is very important at grid scale.
For example, solar has become quite cheap -- when the sun is shining. At midnight the cost per KWh from solar is infinite. The cost per KWh for a coal plant, however, doesn't really change based on the time of day. This distinction isn't captured by LCOE.
That distinction is important because grid per-KWh costs are a weighted average of generation costs. Mathematically, that cost correlates nearly perfectly when most of the generation is supplied by baseload generation. LCOE and actual grid per-KWh cost correlates well when most of the generation is arbitrarily dispatchable. The simple numerical average LCOE correlates poorly to average grid per-KWh cost when much of the generation is intermittent if that intermittent supply doesn't line up well with demand.
For example, from your link if you want a solar system which provides power overnight, you need to sum up the generating cost (busy charging the batteries during the day) with matching storage cost. From your link utility solar ($30-$41) plus wholesale four hour (100MW/400MWh) storage ($131-$232) results in a "windless night" cost of $161-$273 which compares unfavourably with coal ($65-$152) and very unfavourably with gas combined cycle ($45-$74).
https://www.energyforgrowth.org/memo/lcoe-and-its-limitation...
1. The sun doesn't shine at night and the wind doesn't always blow strongly 2. People want to use power at all times of the day 3. Fixed costs in fossil fuel electricity generation are non-trivial 4. The utility scale electricity storage story is dire
The result is that renewables need to be overbuilt compared to their nameplate capacities to make up for less-than ideal weather and expected daily and annual weather cycles. I've heard those renewables produce something like 30% of their annual nameplate where a coal or gas plant will produce 90+%.
This overbuilding then ruins the wholesale price of electricity during high production times. For example, on a bright sunny spring day solar might push wholesale spot electricity prices negative. So the generating companies don't make as much money as you would expect from looking at average wholesale prices.
But people still want to use power after the sun has gone down and even if the wind has stopped blowing. So those generating companies need generating capacity to fill in that several hour long gap. Utility scale power storage in batteries isn't anywhere near being able to affordably store several hours worth of electricity. Also a cloud can roll across quickly or the wind might die suddenly. Therefore that backup generation is almost uniformly natural gas turbines because they can spin up and down quickly.
But even if no power is being sold by those plants, they need to be kept running to be instantly ready. So they are constantly burning some fuel to keep hot and spinning. The maintenance hours still keep racking up. There still needs to be people working 24/7. The costs of all that "idle" time need to be made up in the twelve hours of active generation.
So you end up with essentially double the generating capacity, half solar/wind half natural gas, and are continually paying the costs for both. Obviously that's going to be more expensive than simply burning a bit more fuel to run the natural gas plants near capacity full time. Or even build more efficient base-load plant types like coal or nuclear which have troubles scaling up and down quickly enough to balance out changeable renewable generation.
Most of the pickup trucks in the Lightning form factor (four door, short box, half ton) are bought by people living in suburbia because they make great family vehicles: comfortable passenger space, tons of storage for luggage and toys, good for the home renovation project, good in winter, can move a boat or jetski or ATV, ample power and braking for a comfortable drive.
Suburbia owners tend to only rarely combine cold weather travel with long distance travel. EVs can do each of those, but not both at the same time very well. Suburban owners don't tend to tow heavy often and usually not long distances (if they do they don't own an F-150, but rather something larger).
Rural and off-road users (which are distinct groups) need more range to handle inclement weather, longer average driving distance, more towing, rougher roads, and poor charging infrastructure. For example, many rural homes have electrical service that cannot be depended upon (outages are frequent and sometimes long) and may be weak (old houses may only have 65amp service). There may be no way to park the vehicle close enough to the house to access L2 charging. Parking a pickup truck in a garage is normally impossible.
Adding weight to the bed has nearly zero aerodynamic penalty and so doesn't change mileage much at all as long as the road is level and is not start and go traffic.
Towing on a highway, is primarily an aerodynamic concern because most trailers have the aerodynamics of bricks and are (partially) outside the designed aerodynamic envelope of the rest of the vehicle.
ICE vehicles take a noticeable hit on range when towing, even considering ICEs become more efficient when under moderate loads. There's no reason to hope that EVs won't suffer at least as bad, and 50% range loss is normal in an ICE when towing something large like a camper.
There is a qualitative difference between needing to spend 40+ hours a week to sustain yourself versus spending 0 hours. If one need to spend those hours anyways it makes sense to maximize the income from doing so.
It may take a generation, but I think most people would eventually come to the conclusion that the rat race isn't worth it when zero hours is an option.
Understandably people choose "iphone", but that's doesn't negate that the choice exists. Yes it's very expensive to live a modern lifestyle with fewer direct O&G inputs. It's however really cheap to live a subsistence lifestyle in the middle of nowhere without all the environment wrecking conveniences; it's not near as comfortable though.
I believe, rather, that this woman is suffering from opportunity costs for decisions she did not realize she was making at the time. She seems to know the type of mate she wants, which is more than most, though unfortunately for her what she wants went "off the market", for her at least, while she was in graduate school. She wants an educated, intelligent, supportive, successful, committed and sacrificing man in his thirties. These exists in sufficient abundance, it's merely that most of those men are either already in committed, long term relationships with people they met while in their twenties, or are not seeking a woman in her thirties with a settled career. Successful men in their thirties tend to be, by definition, successful and so most of them have already successfully found what they want at that moment, whether that's long term or non-committal.
1. Use fcc_clear=yes to not encrypt the copy in your sent folder
2. Use GPG's encrypt-to in your GPG configuration: https://www.gnupg.org/gph/en/manual/r1261.html
3. Add --encrypt-to to the GPG commands mutt uses: https://dev.mutt.org/trac/wiki/MuttGuide/UseGPG#TheCodeSourc...
For example, I use Colemak on a Kinesis Advantage and QWERTY on all flat keyboards. Since the physicality of they keyboards are so different I don't have any confusion while typing, though sometimes I'll mix up single character presses. That is, if I type a sentence I never have troubles, but if I want to hit just the 't' key I may mistype the first time. Other than that I can seamlessly switch between the two and my speeds are comparable across both layouts.
My big question is why distributed bug trackers aren't more popular considering the popularity of distributed version control and the general weakness of the bug trackers on sites like github or bitbucket.
http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...
Everybody is more satisfied this way, users get quick feedback that their problem is being looked at, developers get enough information put into the bug tracker to be useful in fixing the issue and the number of useless bugs to wade through goes down immensely.
If I pass "void g(int a)" to "f(int func(struct foo f))" the standard says everything is fine, but it's almost certainly going to blow up. GCC helpfully notifies me of this.
The only case where this warning isn't what I want is where some of the pointer types have been replaced with void. That is, passing "void g(void a)" to "f(int func(struct foo f))" should work just like "struct foo f = (void *a);" and output no warning.
The proposal from the article supports this case and other similar recursive cases.
The three rules to apply to quite directly to standard OO C:
1. If t1 is a subclass of t2, t1 is also consistent with t2. (But not the other way around.)
Using the standard OO C method of subclassing structs, ie.
struct t2 {...}; struct t1 {struct t2 t2; ...};
This is obviously true and the normal subclass relationship, though the C syntax to use this is a bit awkward:
t2_method(&t1->t2, arg1, arg2);
2. Any is consistent with every type. (But Any is not a subclass of every type.)
In C the Any type is void. Using the class definitions above this is entirely valid and produces no warnings:
void v;
struct t1 = v;
So if you have an object of void type you can use it wherever you might require a stricter type. If you pass in something which is not consistent you'll get a runtime error (usually a segfault in the case of C).
3. Every type is a subclass of Any. (Which also makes every type consistent with Any, via rule 1.)
This just says that you can do the following without getting any warnings: struct t1 t1; void v = t1;
And this works quite well in C.
The extension to the C type system, beyond the type inference, is to make these rules recursive, especially in function types. For example, this produces a warning under GCC, though it will compile and run fine:
void f(int* func(int b, int c)) {}
void* g(void b, void c) {return b;}
f(g);
That might just be a limitation of GCC's type checking though.
I think this is quite a good direction to take. C's type system has proven sufficiently powerful over the decades to build large systems and at the same time is trivially bypassed when you paint yourself into a typed corner or you want flexibility strict static type checking finds cumbersome to provide.
Instead your node is no more statistically likely to have any portion of the objects you've uploaded than any other objects throughout Freenet. When an upload is complete your node doesn't have a full copy, all the chunks are spread out amongst the nodes within a few hops of you instead.
It's certainly true that selfish mining strategy A which gave a 5% increase in results would lose out to another selfish mining strategy B which gave 10% increases in results. However that's not an argument that strategy A doesn't break the system, merely that the optimal selfish strategy breaks the system at least badly as strategy A.
Now it is possible that there isn't a stable strategy to use. If we supposed for the purposes of argument that the fair weather strategy was more profitable than the selfish strategy described in the first article you posted, then it would seem that the optimal strategy would oscillate. As more people participate in a selfish pool consistently the more profitable it is to be a fair weather miner. However, supposing that leads to a dissolution of the selfish pool all those fair weather miners turn honest. Against honest miners, however, the selfish strategy is proven to be more profitable. And so you'd see an oscillation where people constantly shift between being honest, selfish and fair weather.
Of course, if the long run gains keeping up on this strategy treadmill is less than simply sticking to the selfish strategy through thick and thin, then perhaps the fair weather strategy isn't better in reality.