For reference, my PG&E bill splits out transmission/delivery and generation very conveniently, since SF provides its own power generation utility service. It appears to be closer to 60/40. At PG&E generation rates (a little higher), perhaps up to 55/45.
Incidentally, $0.13748/kWh in generation costs, with an increase of only $0.01/kWh for exclusive wind/solar sourcing.
That generation cost is also far far higher than the cost of new solar. New floating offshore wind, a new technology that is "expensive," is about at that generation cost.
Even the $6B here amounts to roughly $0.08/kWh, which is far higher than the alternative uses of the money.
Electricity is expensive in California not because we use renewables, but because we have not switched to them, and because PG&E has astronomical costs for its grid. We need CPUC to start pushing back harder here.
That must be an average including lots of old, expensive installations.
Even five years ago, PG&E estimated for new solar was less than $0.06/kWh, and they tend to overestimate these things, and underestimate the rate of cost decreases with solar.
In evaluating the difference between maintaining an existing nuclear site, or building new solar, the new cost is the more accurate estimate.
If you look at new solar deployments in California, nearly all include storage, because it increases profitability to be able to deliver during the evening. Storage is profitable today, meaning that it necessarily costs less than market rates.
Yeah people keep claiming that solar is cheaper in these threads but when asked for proof they point solely at panel prices like that’s anything. The data I’ve been about to find puts hydro, fossil fuels, nuclear, and wind on par with each other with solar about ~2-3x the production cost (not including batteries) if I recall correctly.
Not case sensitive, huh? How about not even distinguishing between letters and numbers?
When I called a prominent bank* recently, I was asked to enter my password via the phone. As in, the digit-equivalent of my password. At least I finally figured out why their password length is capped so low - user experience!
*I began this post with the bank name, and then wondered if given their approach to security, even that might be a bad idea.
17" screen + powerful GPU doesn't leave too many sleek options a la macbook. But if you look towards gaming laptops you'll find plentiful options.
Ubuntu might be a little more difficult, depends on driver support I suppose. Most come with either no OS or Windows.
Here's a search for 17" + 1060/1070 + 4k. I'd probably stick with 1060 to keep some sort of handle on heat management unless you really need more. I've had a good experience ordering from here in the past (Sager NP8660, great machine with an unfortunately large power brick).
Also, while this store sounds like a great place and one that I would visit... this article is the first time I have seen the name. I live in SF, I could have been going here, and yet I did not know it existed (and close enough that I could have combined it with Tartine visits to boot). Sure, it's partially my failure, but it's also a marketing failure.
I just moved to CA for the last election, and I voted for her. This was after already sending her mail saying she was doing a bad job. But as much as I didn't want to vote for her, the opponent did not look like a "moderate Republican." Stood for a ton of things I disagreed with. Maybe it's just party lines, but then they should have strayed from those lines if they wanted broader support to capitalize on anti-Feinstein.
Almost all of the presentations I have seen at work have been shared with people on the phone as well (using terrible sharing tech, I might add). I agree with other posters that having an offline backup solution is important, but given how losing network connectivity already breaks meetings for us, I think having to load up from a USB drive would be an acceptable delay.
A portion of our meetings have demo sections. Either showing off features of some web app from their computer, or VNCing into a server and demo'ing functionality from terminals.
We have to hook up a computer to the projector in a room regardless - there isn't one already there. Having multiple presenters in one meeting would definitely go smoother, though it doesn't happen that often. Startup time would definitely be faster though, as noted our web conference software sucks.
I also like the idea (posted elsewhere) to be able to draw on the slides / point things out.
Some web sites will require you to login again if your IP address changes, no matter what cookies you have. Additionally, the cookie expires. For these websites, the password is much better.
As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction.
Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.
Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.
1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...
2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.
If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.
The idea behind vendor prefixes is that they are implementations of ideas before conventions have been established. When two vendors implement something simultaneously but pre-spec, it's hard to tell which one will end up being canonical.
Your general convention is probably good, but in 5 years time when n parameters have ended up in your {additional} parameter, people will ask why that, too, doesn't follow a convention. The answer is definitionally that the convention doesn't exist yet, and the vendor prefix is a step on the way to establishing one.
I don't know if it's really a big deal to set up a general convention, and when new features appear, just discuss it with W3C and/or other vendors, and use it. These are the minor kinds of problems that can be solved in theory with a few emails and in practice with a 2 months thread on a discussion board (but still better than a mess)
But it isn't a mess. Finalized names are selected as part of the standardization process. That's exactly what TFA was saying: the standardization process works, but web developers are being exceptionally lazy.
What you're asking for is that the browser engineers should wait until part of the standardization process is done (the naming) before they start on implementation, only to potentially have to rewrite things once a finalized name is selected. Not going to happen.
The problem is those are BS differences that in the end don't matter much.
border-bottom-right-radius vs border-radius-bottomright, please.
Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.
If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.
If you honestly believe that a naming dispute could be resolved in 1 hour, then I'd wager you haven't been programming very long. As the famous saying goes -- "The two hardest things in programming are: naming, cache invalidation, and off-by-one errors."
This was just the quickest/most famous/easiest example I could think of. The other I referenced is more subtle. For gradients before standardization, Firefox included the type of gradient in the property definition, "background: -moz-linear-gradient(...)", whereas Webkit made it a parameter to the function, "background: -webkit-gradient(linear, ...)".
Webkit Dev (speaking to Webkit Program Manager) -- Hey! I've figured out a way we can give divs rounded corners.
Webkit PM -- That's cool, what do you call it?
Webkit Dev -- Well, for the bottom right it's "border-bottom-right-radius"
Webkit PM -- Cool.
<some time later...>
Webkit PM (to Webkit Dev) -- Hey! I just got off the phone with Firefox PM. He says they've also developed a way to give divs rounded corners.
Webkit Dev -- That's cool! I guess it was a needed feature.
Webkit PM -- Yeah...only problem is the name. They decided to call theirs "border-radius-bottomright".
Webkit Dev -- Oh.
Webkit PM -- Sooo, yeah. If you could just change that name.
Webkit Dev -- But we already GM'd the build with that name in it. To change it we'll have to back out of the GM, requalify the build, change the documentation, send out new seeds, redo internationalization, send it back to QA, and declare a new GM. That will push out the release by 3 weeks, and besides, I have 20 bugs in my current backlog that are completely unrelated to border radii. How important is this?
