An NDA is a legal agreement. It's entirely possible to organise coordinated disclosures without a legal agreement. The folks pushing NDAs, however, don't seem to be interested in other sorts of agreements.
The alternative would be a "gentleman's agreement"? An NDA would seem to be much more transparent with everyone understanding what was agreed to rather than something agreed upon over cigars and cognac. Refusing to sign NDAs as a matter of principal doesn't seem like a very mature way to conduct business.
It doesn't have to be a handshake and a nod. Things can still be clearly written down. But formal contracts with consequences take it up a notch. And this isn't about how you "conduct business"; that's a very business-oriented view of what's going on.
To be clear, we do routinely operate on the basis of "gentlemen's agreements"... but Intel is a corporation full of lawyers, so I would be astonished if they were willing to work on that basis.
One big reason for shutdown rules with home PV systems is to keep firefighters safe. If your house is on fire, the firefighters really don't want to be contending with high voltage electricity as well.
I've been noticing ground level external emergency shutoff switches for roof based solar around my city, so i imagine its something thats been making its way into fire/electrical/building codes recently.
They're unsecured as far as i have noticed, so i imagine the troublemakers will be pulling them sooner or later.
They likely can't, but they can fine EPAG, which is a German domain registrar. The matter at hand is that ICANN was trying to allegedly force EPAG to violate GDPR.
> To search for anything about Go in your search engine of choice use the word golang rather than go when searching. For example to search for how to open a file I would search for golang open file.
This seems to be a recurring chestnut, but I would have expected the author to actually test it. If I search for [go open file], 8 of the first 10 results on Google show useful information.
$35 is, what, 30 minutes of an engineer's time from a company's perspective? If the management of the service would take any more than that every month (and it easily could!), you're ahead.
Even then, I think it'd be unlikely that the time-cost wouldn't make it worthwhile. People generally underestimate how much time gets soaked up by managing a computer service.
$35 seems to be 3x more cost than AWS's smallest tier (no further comparison of features/value beyond price), so it does seem expensive for an introductory project, considering a single $35~ Digital Ocean VPS might all some companies need their first year. On the other hand, the number of times I've seen an engineer suggest spending $500-$2000 in labor/hours (when already behind on mission critical work) as alternative to spending $5/month in some SaaS is just staggering.
That's true, but the standard library also has strictures about backward compatibility that have ossified some bad choices. The crypto examples you give are arguably exactly this; even the later ones are probably a mistake, but are at least consistent with what can't be changed.
context.Context is an interface because it is known there are multiple implementers (several in the context package itself). The sql driver.Value is actually the other way around: the sql package is the consuming package (for the driver).
Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.
I don't agree. There is a default configuration, and that configuration is very good (I've been following the process of nailing it down, and IMO it's been done very tastefully), and is the formatting used by official Rust codebases, lending it the weight of authority. I have no reason to configure it to do anything differently. But I also have no reason to forbid anyone else from formatting code as they please. What's the possible harm? If you're on a team, and you want code uniformity, you require the default configuration. If you're worried about pulling some random code and having it use {tabs|spaces} instead of {spaces|tabs} (which, btw, is, without hyperbole, the dumbest argument in the entire human history of programming) then you set your editor to run rustfmt on files before opening them.
The gofmt argument isn't the final word here. There's plenty of Go users who don't like gofmt's style, so they just don't use gofmt. It's easy to imagine other users who don't like gofmt's style, and don't like being pressured to use it, so they just don't use Go at all. How is that any better than just having a configurable tool with sane defaults? It's one thing for a tool to be opinionated; it's another thing entirely to be dictatorial and stubbornly inflexible.
"And guess what?" Richard angrily replies, "That's never going to happen now. Because there's no way I'm going to be with someone who uses spaces over tabs."
Man, there's something cathartic in seeing your industry and self-identified group's ridiculousness aired for all the world to see.
If rustfmt were not configurable, it would get a lot less use. Rust has been around for quite some time now, and there's a lot of code out there. We can't force anybody to run rustfmt, and if they don't like the results, they won't use it. It's not a choice between different code styles and a single code style; it's a choice between different code styles with a tool to keep things tidy and different code styles with a tool nobody uses. Things were different for Go for a variety of historical reasons, one important reason being that gofmt existed early on.
To take a concrete example, adopting gofmt's choice to not have a line length limit would have been a nonstarter, because lots of code out there uses long expressions manually wrapped to be readable. A lot of the work in rustfmt has gone into playing nicely with community conventions like these.
Agreed - I am an example. I had vim format my rust code on save, but there was one single bit of formatting which drove me nuts, so I turned the plugin off.
That would be an enormous problem for us. We need rustfmt to be configurable because it let's us use it to make MISRA-like style guidelines automatically enforceable for our codebase, which would be likely summarily rejected without them, so then we'd be forced to either do it manually or reinvent most of rustfmt ourselves.
I often have to zoom into code a lot more than others. This means that I will often want to format my code differently. I change the settings and I can use defaults before committing the code.
Programming causes me a lot of eye strain as it is, a configurable syntax formatter really does help.
I never see anyone discuss syntax the way you're describing. Not at work, not online. Actually the only place I see it is when discussing what the default is, so I think having a default is far more likely to cause those discussions as people will have more reason to complain.
I've never once seen or experienced any discussion about whitespace layout in Rust. OTOH, I've had several discussions about whitespace layout in Go in less than a year of programming in it due to gofmt not enforcing a maximum line length. Previous to writing Go, I worked on a C++ project that used clang-format (with a custom configuration), and we never had to have any formatting discussions because it also handled maximum line lengths.
We have a strong culture of convention over configuration; these two things are not inherently at odds.
To get the default formatting with rustfmt, you just run it. You can configure it via some file but I've never needed to. I don't even know what the options are.
Ok so what happens if I contribute to a open source project with my default fmt configuration if that project doesn't use the default configuration? Will people yell at me to "fix" the formatting?
That'd depend on the project, but even then, you'd just run `cargo fmt` and be done with it. That project would have a rustfmt.toml in the repo, so it would just make the changes for you.
